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

"associated scalars" in WRF registry

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.

S

stepheba

New member
Hi all,

I am working with a customized version of WRF and trying to get something right about the declaration of a new package in Registry.EM_COMMON. Usually a package declaration looks something like this:

Code: 
package  morr_two_moment  mp_physics==10    -      moist:qv,qc,qr,qi,qs,qg;scalar:qni,qns,qnr,qng

where the "moist..." part at the end are "associated 4d scalars". My question is what are these scalars that are being declared as part of the package? Why are "state" variables sometimes included? How do I know what should be included? Is this important to the running of the model or is it not critical? I've been looking around online for answers and I came across a PowerPoint about the registry, but it didn't help me much.

Thanks!
Ben
 
Ben,

The "package" keyword that is used in the WRF registry files is specifically set up to make the memory footprint as small as possible. For example, if the WRF model is selected at run-time for a dry ideal case, there is no need to consider the various "moist" components (vapor, rain mixing ratio, snow mixing ratio, ice mixing ratio, cloud water mixing ratio, etc).

There are several 4d arrays in the standard WRF Registry: moist, scalar (mostly these are the number concentration arrays associated with some of the moist species for the double moment microphysics schemes), tracer (passive tracers that are available for trajectory analysis), and chem (3d chemical constituents). For these (and all other 4d arrays), no space is allocated at run-time unless a specific request is made. The request is in the form of listing the variables in a package statement.

Here are a few lines of the Registry.EM_COMMON file, where the moist fields are defined.
Code: 
state   real    qv             ikjftb   moist       1         -     \
  i0rh01usdf=(bdy_interp:dt) "QVAPOR"           "Water vapor mixing ratio"      "kg kg-1"
state   real    qc             ikjftb   moist       1         -     \
  i0rhusdf=(bdy_interp:dt)   "QCLOUD"           "Cloud water mixing ratio"      "kg kg-1"
state   real    qr             ikjftb   moist       1         -     \
  i0rhusdf=(bdy_interp:dt)   "QRAIN"            "Rain water mixing ratio"       "kg kg-1"

Here is a package declaration for a warm rain microphysics scheme:
Code: 
package   kesslerscheme   mp_physics==1 - moist:qv,qc,qr

The syntax is to list the 4d array name (moist, in this case), and then list the components that are required for this microphysics option (qv, qc, qr for mp_physics==1).

There are some schemes in the WRF model that require extra variables, that are not needed by other schemes. The stochastic capability, the data assimilation options, the NoahMP scheme, the urban options are all examples of schemes that have a large number of state fields that are not part of a 4d encapsulating array. To save memory space, those are put into package statements also.

For example, the WSM5 scheme uses qv, qc, qr, qi (ice), qs (snow) from moist. It also uses a few state fields that are the effective radii of cloud, ice, and snow - which are all just members of the state keyword.
Code: 
package wsm5scheme   mp_physics==4 - moist:qv,qc,qr,qi,qs;state:re_cloud,re_ice,re_snow

Every state field that is NOT part of a 4d array is always available to the WRF model, UNLESS it is listed in a package. If the field is listed in a package, then that field is available ONLY if that package is requested at run-time.

The rules are pretty simple:
1. If you are adding 2d and 3d arrays that are specific to your scheme, they should be part of the package declaration for your scheme.
2. If your scheme needs access to components of existing 4d arrays (for example, moist or scalar), then those encapsulating 4d arrays and the list of required 3d components need to be in your package declaration.
3. If your scheme needs access to components of existing 2d or 3d arrays that ALREADY exist in some package statement, then you must include those fields in your new package statement to use those fields.
4. If you are adding components to an existing 4d array, follow the templates of the existing 4d arrays.
 
Thanks very much for your thorough response to my question about the WRF Registry associated scalars, that was very helpful. If you don't mind I had two hopefully short follow-up questions about it. The main reason I was asking about this was that I have a case where WRF fails at the first time step, and after a lot of testing I was able to trace it to one of these associated scalars. This customized version of WRF includes a new microphysics package where in addition to some "moist" and "scalar" variables there are several "state" variables associated with it: refl_10cm, rqrcuten, rqscuten, and rqicuten. The WRF test case that failed was not using that microphysics package, but the cumulus package being used (wsm3scheme) does require those tendency variables, so it sounds like this may be why the model was failing.

If I understand your response to my post correctly, there's no particular need to explicitly associate these variables with this new microphysics package in the Registry, since they are all 3d variables, not 4d. So there shouldn't be any problem if I remove those associations in the Registry? This is what I'm finding, but just trying to understand it better.

Finally, and strangely, the only "associated" variable that seemed to cause the test case to fail was rqrcuten, not the other two tendency variables, even though all three are used in the wsm3scheme cumulus package. In other words, if I leave rqscuten and rqicuten "associated" with the new microphysics package, the test case using the 'wsm3scheme' cumulus package runs fine, but if I include the rqrcuten with the microphysics package, the test case fails. Can you think of any reason why only one of these would be causing a problem?
 
Thanks very much for your thorough response to my question about the WRF
Registry associated scalars, that was very helpful. If you don't mind I
had two hopefully short follow-up questions about it. The main reason I
was asking about this was that I have a case where WRF fails at the first
time step, and after a lot of testing I was able to trace it to one of
these associated scalars. This customized version of WRF includes a new
microphysics package where in addition to some "moist" and "scalar"
variables there are several "state" variables associated with it:
refl_10cm, rqrcuten, rqscuten, and rqicuten. The WRF test case that failed
was not using that microphysics package, but the cumulus package being used
(wsm3scheme) does require those tendency variables, so it sounds like this
may be why the model was failing.

If I understand your response to my post correctly, there's no particular
need to explicitly associate these variables with this new microphysics
package in the Registry, since they are all 3d variables, not 4d. So there
shouldn't be any problem if I remove those associations in the Registry?
This is what I'm finding, but just trying to understand it better.

Finally, and strangely, the only "associated" variable that seemed to cause
the test case to fail was rqrcuten, not the other two tendency variables,
even though all three are used in the wsm3scheme cumulus package. In other
words, if I leave rqscuten and rqicuten "associated" with the new
microphysics package, the test case using the 'wsm3scheme' cumulus package
runs fine, but if I include the rqrcuten with the microphysics package, the
test case fails. Can you think of any reason why only one of these would
be causing a problem?

Thanks for all your help!
 
Ben,

Let me make a general statement, then get into your specifics.

General Statement

Let's assume that you have a vanilla version of WRF (called WRF_vanilla) that works OK - it has no source mods. Let's also assume that you have a version of WRF where you have introduced a new physics scheme or have modified a physics scheme enough so that it requires new arguments (we shall call this version WRF_mods). Further assume that the WRF_mods code dies in the first time step (possibly without even using the new scheme in WRF_mods). Many times, this failure is able to be traced back to the package declarations that are in the registry files. This is frustrating for users as the whole benefit of the package declarations is unlikely to be for the original developer, but for later users of possibly contributed code.

To see if the package statement in the registry file is indeed the culprit, remove all of the state variables from the new package list for the new (or modified) scheme that are not in another package. An example would be for NoahMP sf_surface_physics==4 (if we were developing that new scheme). We could remove the variable "cropcat" (along with 50 or so more!) since no other scheme uses that variable in a package.

Typically, if this type of test (removing optional variables from the package statement) fixes the code (WRF_mods runs past the first time step, admittedly a low bar, but a big step), then this is an indicator that the WRF_mods packaging in the registry is a problem. Note that in many cases where the package statement in the registry needs to be fixed, the WRF_mods code will fail when selecting or NOT selecting to use the new code.

  • When NOT using the new code in WRF_mods causes the the model to stop in the first time step, likely what has happened is that a developer has INCLUDED a state variable to the new package, and that state variable used to be unpackaged.
  • When using the new code in WRF_mods causes the the model to stop in the first time step, likely what has happened is that a developer has MISSED adding a state or 4d variable to the new package, and that state variable needs to be packaged.

Generally, developers must include the following variables to their packages. These are always "safe" to do (i.e. the model won't incorrectly die in the first time step from a packaging error, however, there may be more memory used than is required).
  • All new variables declared in the registry file for the new scheme.
  • All 4d arrays that have constituents used in the scheme, and explicitly list the constituents.
  • For the new physics scheme that is being included, if there are required input or output arguments in the new scheme that are also listed in a package for the same type of physics (let's say some other microphysics package), then also include those variables in the new package list. Some variables have complicated dependencies that rely on derived namelist options which are handled in the source code.

When the new physics scheme is ready to be folded back into the WRF repository as a contributed scheme, we can assist with meeting more stringent requirements.

Specific Statement

The radar reflectivity may be your problem. Take a look at the file share/module_check_a_mundo.F, and search for the string "compute_radar_ref". There is a list of microphysics packages that are known to use this field. If your new MP scheme does use the refl_10cm variable, add your scheme to this list.

Sometimes the behavior of the model when things are incorrect is difficult to explain. Why the model would fail reproducibly when one variable is incorrect in a package (as compared to a different variable being incorrectly used in a package) may not be worth unraveling.

Bottom line, working code is a priority over packaging niceities. There are aspects of the packaging that are mandatory. If your new code works, you have met that goal. The "niceities" will remove extra memory, stop unnecessary communications, and get rid of zero-ed out values of unused fields in your output files.
 
You must log in or register to reply here.
Top