Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

THM is mandatory WRF temp variable #733

Merged
merged 9 commits into from
Oct 22, 2024
Merged
13 changes: 13 additions & 0 deletions models/wrf/model_mod.f90
Original file line number Diff line number Diff line change
Expand Up @@ -694,6 +694,19 @@ subroutine static_init_model()

! JPH now that we have the domain ID just go ahead and get type indices once
! NOTE: this is not strictly necessary - can use only stagger info in the future (???)

! If using WRF temperature variable 'T' instead of 'THM' fail immediately to
! prevent boundscheck errors. For WRFv4 and later version variable 'T' is
! diagnostic, thus updating the 'THM' variable (prognostic) is preferred.

if ( wrf%dom(id)%type_t >= 0 .and. get_type_ind_from_type_string(id,'T') >=0) then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so at the comment, this check isn't checking that THM is in state and type_t

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so at the comment, this check isn't checking that THM is in state and type_t

I went back and forth on this -- yes, the code will error out if user includes 'T' as temperature variable. It does not error out if 'THM' is in the DART state, but does give that information in the error message.

I could expand the error by saying:

if ( wrf%dom(id)%type_t >= 0 .and. (get_type_ind_from_type_string(id,'T') >=0 .or. get_type_ind_from_type_string(id,'THM') <=0)) then

Is that preferable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested edit will now error out if THM is not in DART state but type_t WRF variable is declared.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line 702:
if ( wrf%dom(id)%type_t >= 0 .and. get_type_ind_from_type_string(id,'T') >=0) then

wrf%dom(id)%type_t isn't defined at this stage (unless I'm missing something) so this check wrf%dom(id)%type_t >= 0 is using an uninitialized value for type_t

line 713 is where wrf%dom(id)%type_t is set.
wrf%dom(id)%type_t = get_type_ind_from_type_string(id,'THM')

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so to back up a bit, what has to be true to run wrf-dart?

THM has to be in the state and type_t has to be THM?

What's not allowed?
T can not be in the state vector?
T can be in the state vector but can not be type_t?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so to back up a bit, what has to be true to run wrf-dart?

THM has to be in the state and type_t has to be THM?

What's not allowed? T can not be in the state vector? T can be in the state vector but can not be type_t?

The only thing that is not allowed is having the WRF variable 'T' in the DART state because it can throw the 'boundscheck' error which gives a non-intuitive error as described in #728 . There are other secondary reasons to not include 'T' in WRF -- because its diagnostic in WRFv4+, not prognostic, so updating it will not improve the forecast. Users who are used to older WRF versions may not be aware of this.

I also believe that including a 'type_t' WRF variable in the DART state is mandatory because of the way the WRF model_mod.f90 works. Even if you don't intend the 'type_t' variable to be updated by DART, the code still does boundchecks on the type_t variable for many (all?) WRF-DART simulations.

Given the 'type_t' requirement, and secondly, that using variable 'T' is not permitted, this makes including 'THM' mandatory because it is the only replacement variable that I know of for 'T' (3D temperature).


write(errstring,*)'WRF temperature variable T in model_nml must be replaced &
with THM for WRFv4 and later'
call error_handler(E_ERR,'static_init_model', errstring, source, revision, revdate)

endif

wrf%dom(id)%type_u = get_type_ind_from_type_string(id,'U')
wrf%dom(id)%type_v = get_type_ind_from_type_string(id,'V')
wrf%dom(id)%type_w = get_type_ind_from_type_string(id,'W')
Expand Down
13 changes: 12 additions & 1 deletion models/wrf/readme.rst
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,10 @@ Some important WRF-DART updates include:
operator calculations.

- Version 11.5.0: Improves compatibility with WRFv4+ versions where
the prognostic 3D temperature variable is THM.
the prognostic 3D temperature variable is THM. It is now mandatory to
include THM instead of T in the ``wrf_state_variables`` namelist.



It is always recommended that you update your DART version to the
`latest release <https://github.com/NCAR/DART/releases>`__ before beginning new research.
Expand Down Expand Up @@ -336,6 +339,14 @@ For example:
'PSFC','QTY_PRESSURE','TYPE_PS','UPDATE','999',


.. Important::

It is mandatory to include ``THM`` instead of ``T`` as the ``TYPE_T`` WRF
temperature variable. This is because ``THM`` is the prognostic temperature variable
that will impact the forecast when updated. Also, including ``T`` can give
boundscheck errors as described in `issue #728. <https://github.com/NCAR/DART/issues/728>`__
braczka marked this conversation as resolved.
Show resolved Hide resolved


- polar, periodic_x

The ``Polar`` and ``periodic_x`` namelist values are used in global WRF simulations.
Expand Down
6 changes: 5 additions & 1 deletion models/wrf/tutorial/README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -19,12 +19,16 @@ either WRF or DART.
versions 11.4.0 and earlier because those older versions do not account
for different coordinate systems including the sigma hybrid coordinates as
described in `DART Issue #650 <https://github.com/NCAR/DART/pull/650>`__.

Furthermore, older versions do not account for the prognostic temperature variable
switch from ``T`` (perturbation potential temperature) to ``THM``, (either perturbation
potential temperature or perturbation moist potential temperature) as described in
`DART issue #661 <https://github.com/NCAR/DART/issues/661>`__. The current implementation
of the code sets ``T=THM`` because within &dynamics section of ``namelist.input``
``use_theta_m=0``.
``use_theta_m=0``. For this reason, It is mandatory to include ``THM`` instead of
``T`` as the ``TYPE_T`` within the wrf_state_variables namelist. Furthermore, including
``T`` in the namelist can lead to errors in the WRF model_mod bounds check as
described in `Issue #728. <https://github.com/NCAR/DART/issues/728>`__
braczka marked this conversation as resolved.
Show resolved Hide resolved

Earlier version of WRF (v3.9) may run without errors with more recent versions of
DART (later than 11.4.0), but the assimilation performance will be deprecated.
Expand Down