Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Accessing variables on head_grid

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.


New member

I am running WRF as the atmospheric component of a coupled atmosphere/ocean/wave model. I need to export variables from WRF to my coupler during each time step. After importing head_grid from module_domain, variables can be accessed via a command like

p_to_coupler(i,k,j) = head_grid % p(i,k,j)

For most variables I am interested in, the variable name in head_grid is the same as the name used in wrfout* files. This is not the case for two variables: T (perturbation potential temperature) and QVAPOR (water vapor mixing ratio). I am trying to figure out what names to request for these. I believe that T_1 is WRF's internal name for dry potential temperature and T_2 is the internal name for moist potential temperature, so I think I need to use T_1 to request T, but I'm not sure. Moisture in WRF seems to be handled with an array called 'moist', with water vapor mixing ratio accessed as moist:),:,:,P_QV). I am looking for the variable to request that will give me this array from head_grid.

Can anyone enlighten me on these two issues? Thank you very much.
If you are using V4.0 or later, then the perturbation potential temperature is handled a bit differently. From the Registry/Registry.EM_COMMON file, you can see:
state    real   t              ikjb     dyn_em      2         -     \
       i0rhusdf=(bdy_interp:dt)   "thm"      "either 1) pert moist pot temp=(1+Rv/Rd Qv)*(theta)-T0, or 2) pert dry pot temp=theta-T0; based on use_theta_m setting" "K"

So if you have 'use_theta_m = 1' set in your namelist (this is the default setting), then variable "t" is the perturbation moist potential temp used inside the model. Otherwise, it's the dry potential temp. The variable in the output will be 'THM.

QVAPOR is listed as:
state   real    qv             ikjftb   moist       1         -     i0rh01usdf=(bdy_interp:dt) "QVAPOR"           "Water vapor mixing ratio"      "kg kg-1"

So the variable in output is QVAPOR, but inside the model 'qv' is used.

Thanks for your reply. Unfortunately, I am currently using WRF V3.9, as we have not performed the task of making our coupler compatible with V4.0 yet. Do your comments below about potential temperature apply to V3.9 as well? When I try to access head_grid%t, I get a compile error saying that the field is not defined on the encompassing structure. When I try either head_grid%t_1 or head_grid%t_2, there is no error. For some context, my ultimate goal is to calculate air temperature, but since that is not carried in the model, I am trying to calculate it using dry potential temperature. If there's a better solution to get what I want, I'd be happy to listen.

Regarding qv, I still get a similar error (field not defined on the encompassing structure) when accessing water vapor mixing ratio using head_grid%qv. Could it be that this variable is not accessible via head_grid, or that it has a different name in V3.9?

Thanks again for your help.
You are on the right track.

The reason that you do not see
head_grid % t(i,k,j)
is that we keep two time levels of some dynamics variables to support the RK time integration scheme. You want
head_grid % t_2(i,k,j)

If you want temperature, take a look in dyn_em/module_big_step_utilities.F in subroutine phy_prep. Look for variable t_phy (temperature for physics routines). Use those types of calculations and you are OK.

For the water vapor mixing ratio, this is stored in an aggregated array, think of it as a 1d array of 3d arrays. We want the index in the 1d array that points to Qv. We get this from
head_grid % moist(:,:,;,P_Qv)

With version 3.9, you do need to be careful with the distinction between moist and dry theta, but only within the confines of the dyn_em solver and dynamics routines. If you are above dyn_em directory, for v3.9 the t_2 variable is always dry perturbation potential temperature.

... also

You will need to have
USE module_state_description
in the routine where you are using P_Qv.


Thank you very much for the explanation. This makes sense. I am passing fields to the coupler in between WRF timesteps (rather than from within a subroutine), so it looks like t_2 will give me what I want (dry potential temperature), which I can easily convert to temperature. Regarding moisture, I had seen moist:),:,:,P_QV) used in the source code, but wasn't sure if it could be accessed since it is not in the Registry.

I have made these changes, and the code now compiles. Thank you very much for your help!

Remember that that grid%t_2 (and t_1 for that matter) is a PERTURBATION potential temperature. We subtract 300 K from total dry theta.