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

The associated variables in WRF registry "Registry.EM_COMMON"

Jason Hou

New member
Hi all,

I find these package declarations in Registry.EM_COMMON, for example:
package thompson mp_physics==8 - moist:qv,qc,qr,qi,qs,qg;scalar:qni,qnr;state:re_cloud,re_ice,re_snow
or
package myjpblscheme bl_pbl_physics==2 - state:tke_pbl,el_pbl

So, my first question is: Are all the variables listed here is the complete set of input and output variables for the corresponding physical parameterization scheme?
If so, how can I distinguish which variables are input variables and which are output variables?


Thanks!!
Hou
 
Please see my answers below:
Hi all,

I find these package declarations in Registry.EM_COMMON, for example:
package thompson mp_physics==8 - moist:qv,qc,qr,qi,qs,qg;scalar:qni,qnr;state:re_cloud,re_ice,re_snow
or
package myjpblscheme bl_pbl_physics==2 - state:tke_pbl,el_pbl

So, my first question is: Are all the variables listed here is the complete set of input and output variables for the corresponding physical parameterization scheme?

No, this is not true. Variables list after a package tell WRF that they are allocated only when the package (scheme) is activated.
If so, how can I distinguish which variables are input variables and which are output variables?

Please look at the codes for the specific scheme, in which variables are specified at intent(in) or intent(out). I guess this is a good indicator to tell input/output variables
Thanks!!
Hou
 
Please see my answers below:


No, this is not true. Variables list after a package tell WRF that they are allocated only when the package (scheme) is activated.


Please look at the codes for the specific scheme, in which variables are specified at intent(in) or intent(out). I guess this is a good indicator to tell input/output variables
Thank you for your reply!

Currently I want to output the specific variables that related to specific physics parametrization scheme and I am aware that any variables that can be found in Registry.EM_COMMON can be output in auxhist* files.

For example, I used the thompson scheme for micro physics, so I read the codes in module_mp_thompson.F, I find something like
INTEGER, INTENT(IN):: ids,ide, jds,jde, kds,kde, &
ims,ime, jms,jme, kms,kme, &
its,ite, jts,jte, kts,kte
REAL, DIMENSION(ims:ime, kms:kme, jms:jme), INTENT(INOUT):: &
qv, qc, qr, qi, qs, qg, ni, nr, th
REAL, DIMENSION(ims:ime, kms:kme, jms:jme), OPTIONAL, INTENT(INOUT):: &
nc, nwfa, nifa
REAL, DIMENSION(ims:ime, jms:jme), OPTIONAL, INTENT(IN):: nwfa2d
REAL, DIMENSION(ims:ime, kms:kme, jms:jme), INTENT(INOUT):: &
re_cloud, re_ice, re_snow
INTEGER, INTENT(IN):: has_reqc, has_reqi, has_reqs

some variables can be found in Registry.EM_COMMON and some cannot. For example, I cannot find the "nwfa" variable in Registry.EM_COMMON, so my question is that how to determine the actual name of variables (such as "nwfa") in Registry.EM_COMMON so I can output them in auxhist* files.

Hou
 
Hou,
If a variable is not listed in Registry, you need to define it in Registry, add it as a dummy argument to the driver, and pass it from the physics to the driver. This is the common method we follow to output new variables in WRF.
 
Top