THM WRF v3 vs v4

[hkershaw-brown]

You mean THM is prognostic in v4. The WRF userguide says

The prognostic variable for temperature is moist potential temperature by default.

And if you set use_theta_m=0 then THM is the dry potential temperature and happens to be the same as T.
But if you update T by assimilation then this update is not used by the forecast model since only THM is prognostic but not T.

Originally posted by @lkugler in #367 (comment)

Edit: v4 changes on https://github.com/NCAR/DART/tree/wrf-thm

[hkershaw-brown]

Is a namelist option the cleanest way to deal with this since we have mostly wrf v3 users and some v4 users?

default v3
switch to v4

[lkugler]

Users have to define their state variables in the namelist &model_nml like this

   wrf_state_variables = 'U',     'QTY_U_WIND_COMPONENT',     'TYPE_U',    'UPDATE','999',
                         'V',     'QTY_V_WIND_COMPONENT',     'TYPE_V',    'UPDATE','999',
                         'W',     'QTY_VERTICAL_VELOCITY',    'TYPE_W',    'UPDATE','999',
                         'PH',    'QTY_GEOPOTENTIAL_HEIGHT',  'TYPE_GZ',   'UPDATE','999',
                         'THM',   'QTY_POTENTIAL_TEMPERATURE','TYPE_T',    'UPDATE','999',

Wouldn't it be most intuitive to use the 'THM' string from there to define the name of the netCDF output variable?

There will be a problem if there are two QTY_POTENTIAL_TEMPERATURE but I don't think that this is possible?!

[syha]

Is a namelist option the cleanest way to deal with this since we have mostly wrf v3 users and some v4 users?

default v3 switch to v4

I think so. But we already released WRF v4.4.1, so having v3 as default may not last long, just so you know.

[syha]

Users have to define their state variables in the namelist &model_nml like this

   wrf_state_variables = 'U',     'QTY_U_WIND_COMPONENT',     'TYPE_U',    'UPDATE','999',
                         'V',     'QTY_V_WIND_COMPONENT',     'TYPE_V',    'UPDATE','999',
                         'W',     'QTY_VERTICAL_VELOCITY',    'TYPE_W',    'UPDATE','999',
                         'PH',    'QTY_GEOPOTENTIAL_HEIGHT',  'TYPE_GZ',   'UPDATE','999',
                         'THM',   'QTY_POTENTIAL_TEMPERATURE','TYPE_T',    'UPDATE','999',

Wouldn't it be most intuitive to use the 'THM' string from there to define the name of the netCDF output variable?

There will be a problem if there are two QTY_POTENTIAL_TEMPERATURE but I don't think that this is possible?!

Agree. In fact, theta_m is one of the prognostic variables in MPAS, which is a potential temperature "modified" by moisture (theta_m = theta*(1+1.61*Qv)).
I'm not sure exactly what THM points to, but it sounds like theta_m, which is a function of both potential temperature (theta) and water vapor mixing ratio (Qv).

[metrta]

Revisiting this subject, I have run into an odd issue with T vs. THM in WRF v4.5 when using DART. I am using the master version from a couple of months ago with the changes for THM listed above. However, I get a few NaN points in the top model layer in the updated wrfinput files for all members during the second assimilation cycle when using THM as a state variable. The pre-assimilation files do not have the NaN points. If I revert to "T" everything works fine, but that is not really an option going forward since it is no-longer prognostic. I have use_theta_m set to zero in both cases. Any thoughts on what might be going on? One related question, does update_wrf_bc work correctly with THM?

Thanks,Thomas

[lkugler]

Hi Thomas,
I've never had this issue. So you are saying, that you get NaN in the wrfinput files. Are there also NaN in the filter output files?
The model top is not treated differently than the rest (except in CAM where there is increment damping), I think.
Are the dimensions of T and THM the identical in the DART input files (wrfout/wrfinput)?

A quick hack would be to use T in DART, and then to write the output for T into WRF's THM (which is identical to T with use_theta_m=0).

Something else:
I wasted a long time trying to initialize WRF with wrfinput files after assimilation for my ideal WRF simulations. In the end I switched to using WRF restart files (wrfrst), because using wrfinput-files I could have zero increments but I still got a different forecast compared to a non-interrupted forecast.

[metrta]

Thanks for the reply....after some digging, it turns out it was the difference in a "<" vs. "<=" in the boundary check portion of model mod between the T and THM versions of the code.

[hkershaw-brown]

closing, not fixed but see #661 for larger DART with WRF 4+