TEMPO Microphysics for NCAR MPAS by AndersJensen-NOAA · Pull Request #1393 · MPAS-Dev/MPAS-Model

AndersJensen-NOAA · 2026-01-09T01:00:56Z

This PR connects TEMPO microphysics to MPAS.

- adds TEMPO registry - adds include flags and module use statements to connect tempo to microphysics driver

- adds substepping to tempo microphysics when dt > 90s - adds tempo and aerosolaware options to interface

- adds initialization routines for tempo with aerosolaware option

TYPE: new feature KEYWORDS: Microphysics, Operational models SOURCE: Anders Jensen NOAA/GSL DESCRIPTION OF CHANGES: Problem: Microphysics development of a Thompson-Eidhammer based scheme for operational applications has advanced to a submodule, TEMPO. This new development should be made available to WRF users. Solution: Connect TEMPO to WRF. A cleaned and refactored version of TEMPO is being tested in the UFS community's MPAS. Additionally, a PR, MPAS-Dev/MPAS-Model#1393, to add TEMPO to NCAR's MPAS is in progress. This current PR will allow the community to use this same microphysics across the UFS, MPAS, and WRF. LIST OF MODIFIED FILES: M .gitmodules M main/depends.common M Makefile M clean M phys/Makefile M phys/module_physics_init.F M phys/module_microphysics_driver.F M Registry.EM_COMMON M dyn_em/module_initialize_real.F TESTS CONDUCTED: 1. compiled and ran em_quarter_ss 2. restart test with em_quarter_ss 3. bit-for-bit with different number of processes using em_quarter_ss. 4. Passed regression tests. RELEASE NOTE: TEMPO is the Thompson-Eidhammer Microphysics Parameterization for Operations. TEMPO lives here: https://github.com/NCAR/TEMPO and technical documentation lives here: https://ncar.github.io/TEMPO/. TEMPO specific release notes are here: https://github.com/NCAR/TEMPO/releases/tag/tempo_v3.0.0 TEMPO version 3.0.0 is the current release version. TEMPO is being tested in the ufs-community fork of MPAS for next-generation convection-allowing forecast systems (https://github.com/ufs-community/MPAS-Model). Thus, TEMPO is being continually evaluated for improvement. Additionally, there is a PR in progress to connect TEMPO (v3.0.0) to NCAR's MPAS (MPAS-Dev/MPAS-Model#1393). The version of TEMPO currently in the CCPP (https://github.com/ufs-community/ccpp-physics) will be updated to v3.0.0 soonish. TEMPO is connected to WRF, MPAS, and CCPP as a submodule, and the same v3.0.0 code will be connected to WRF (this PR), MPAS, and CCPP. In WRF, supported namelist options include `tempo_aerosolaware==1` to use the aerosol-aware version, and `tempo_hailaware==1` to use the hail-aware version. Both options are on by default. Key improvements include: - TEMPO is in a submodule that allows for flexibility when connecting TEMPO to dynamical cores - Code modularity was been improved and technical documentation has been added - Bux fix for cloud droplet number concentration during evaporation - Surface emissions of water-friendly aerosols have been reduced based on a sensitivity simulation that aimed to better constrain water-friendly aerosol concentrations over 24-36 hour forecast periods and reduce the accumulation of aerosols in the atmosphere - A few modifications were made to graupel number concentration tendencies (when using the hail-aware option) for processes that cause rain to freeze to increase reflectivity in deep convective storms - Added simple sedimentation tests - Added unit tests - Added a program to build lookup tables with MPI capability - Lookup tables have been unified

mgduda · 2026-04-23T19:24:37Z

                <package name="met_stage_out" description="Active only if meteorological fields are being interpolated"/>
                <package name="first_guess_field" description="3-d atmospheric or land-surface fields on first-guess levels"/>
                <package name="mp_thompson_aers_in" description="initialization of GOCART-based Thompson water- and ice-friendly aerosols"/>
+                <package name="tempo_aerosolaware_in" description="initialization of GOCART-based TEMPO water- and ice-friendly aerosols"/>


It looks like tempo_aerosolaware_in is active if and only if mp_thompson_aers_in is active. If this is the case, perhaps we don't need to add a new package for TEMPO? Or, if you'd prefer, we could generalize the name of the existing mp_thompson_aers_in package?

It looks like tempo_aerosolaware_in is active if and only if mp_thompson_aers_in is active. If this is the case, perhaps we don't need to add a new package for TEMPO? Or, if you'd prefer, we could generalize the name of the existing mp_thompson_aers_in package?

I think that generalizing the name should be the way to go for now.

Ok, this sounds like something I'd be able to take care of with a separate PR. Do you have any suggestions for the name of the package? Maybe microphysics_aerosols with a description of Initialization of GOCART-based water- and ice-friendly aerosols?

(Maybe extending the description to Initialization of GOCART-based water- and ice-friendly aerosols for Thompson and TEMPO microphysics?)

I've just opened PR #1449 with these changes, and I'll add you as a reviewer. One that PR has been merged, we can rebase this PR onto the HEAD of the develop branch.

mgduda · 2026-04-23T19:29:12Z

When building with Make using the gnu build target, there are a couple of compilation errors (perhaps because we include the -std=f2008 flag):

src/module_mp_tempo_diags.F90:119:28:

  119 |       dbz(k) = max(-35._wp, 10._wp*log10((ze_rain(k)+ze_snow(k)+ze_graupel(k))*1.e18_dp))
      |                            1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_diags.F90:53:59:

   53 |         re_qs(k) = max(5.01e-6_wp, min(0.5_wp*(smoc/smob), 999.e-6_wp))
      |                                                           1
Error: GNU Extension: Different type kinds at (1)

mgduda · 2026-04-23T22:51:39Z

When building with Make, after the physics have all been compiled, we symbolically link physics look-up tables into the top-level MPAS-Model directory (see https://github.com/MPAS-Dev/MPAS-Model/blob/v8.4.0/src/core_atmosphere/Makefile#L49-L54). Should we do this for the ccn_activate.bin file as well?

mgduda · 2026-04-23T23:09:25Z

@AndersJensen-NOAA From where should users obtain the file freeze_water_data_tempo_v3? This doesn't seem to be present in the TEMPO/tables directory.

Here's the runtime error I'm seeing without this file in my run directory:

ERROR STOP --- file "freeze_water_data_tempo_v3" needed for TEMPO microphysics was not found.

mgduda · 2026-04-23T23:24:20Z


             do k = kts,kte
             do i = its,ite
                rnimpten(k,i) = ni(k,i)


When running with the convection_permitting suite (no TEMPO microphysics enabled), debug builds point to an out-of-bounds array access on this line:

At line 870 of file mpas_atmphys_interface.F Fortran runtime error: Index '1' of dimension 2 of array 'ni' below lower bound of 22364884

This doesn't seem to occur with the v8.3.1 tag, and so the error seems to be specific to this PR branch.

Perhaps the new block of code beginning at line 705 is causing the code beginning at line 784 to no longer be executed?

@mgduda Ya, I likely messed something up with the case statements. I'll take a look.

I'm not a huge fan of the nested case-select statements.

I rearranged the logic to call case("mp_tempo") after the nested part of the code so that my case would not interfere with the nested logic.

I think some further fixes may be needed. When I attempt to run with the convection_permitting suite (and after compiling with DEBUG=true), I'm seeing the following runtime error:

#0 0x8173c7 in __mpas_atmphys_interface_MOD_microphysics_from_mpas at /glade/derecho/scratch/duda/pull/MPAS-Model/src/core_atmosphere/physics/mpas_atmphys_interface.F:716

I think the issue may be that the microp2_select case statement in allocate_microphysics in mpas_atmphys_driver_microphysics.F is contained within the mp_tempo case in the microp_select case statement further up in the routine.

AndersJensen-NOAA · 2026-04-23T23:27:40Z

@AndersJensen-NOAA From where should users obtain the file freeze_water_data_tempo_v3? This doesn't seem to be present in the TEMPO/tables directory.

Here's the runtime error I'm seeing without this file in my run directory:
ERROR STOP --- file "freeze_water_data_tempo_v3" needed for TEMPO microphysics was not found.

@mgduda you need three tables that are large-ish so they aren't stored on git at the moment.
I keep a copy of the table on noaa servers:
wget https://gsl.noaa.gov/thredds/fileServer/retro/jensen/qr_acr_qg_data_tempo_v3
wget https://gsl.noaa.gov/thredds/fileServer/retro/jensen/qr_acr_qs_data_tempo_v3
wget https://gsl.noaa.gov/thredds/fileServer/retro/jensen/freeze_water_data_tempo_v3

If you need to build the tables, you can compile/run the standalone build_tables program. If you are using gfortran to build the tables you will want to modify the default optimization or use MPI, otherwise the build will take a long time.
https://ncar.github.io/TEMPO/program/build_tables.html

I'm open to suggestions for better ways to deal the lookup tables. Maybe they can be automatically downoaded/linked?

AndersJensen-NOAA · 2026-04-23T23:32:12Z

When building with Make, after the physics have all been compiled, we symbolically link physics look-up tables into the top-level MPAS-Model directory (see https://github.com/MPAS-Dev/MPAS-Model/blob/v8.4.0/src/core_atmosphere/Makefile#L49-L54). Should we do this for the ccn_activate.bin file as well?

Yes.

mgduda · 2026-04-23T23:40:34Z

I'm open to suggestions for better ways to deal the lookup tables. Maybe they can be automatically downoaded/linked?

Would it be feasible to incorporate your stand-alone program for computing these tables into MPAS-A's existing src/core_atmosphere/utils directory? If the code is more or less static, we could just place the source file directly in the MPAS-Model repository; otherwise, we could fetch the code from a repository with manage_externals.

AndersJensen-NOAA · 2026-04-24T21:35:14Z

I'm open to suggestions for better ways to deal the lookup tables. Maybe they can be automatically downoaded/linked?

Would it be feasible to incorporate your stand-alone program for computing these tables into MPAS-A's existing src/core_atmosphere/utils directory? If the code is more or less static, we could just place the source file directly in the MPAS-Model repository; otherwise, we could fetch the code from a repository with manage_externals.

The lookup tables are now the same for WRF/MPAS/CCPP, and I image that 99% of users won't want to change or rebuild the tables. Even though the build code is mostly static at this point, I'd like to keep the executable in the TEMPO repository so I don't have manage the program outside of TEMPO. I think the best path forward is to to either pull the lookup tables from NOAA servers or store them as git artifacts or in git LFS.

AndersJensen-NOAA · 2026-04-25T17:32:01Z

When building with Make using the gnu build target, there are a couple of compilation errors (perhaps because we include the -std=f2008 flag):

src/module_mp_tempo_diags.F90:119:28:

  119 |       dbz(k) = max(-35._wp, 10._wp*log10((ze_rain(k)+ze_snow(k)+ze_graupel(k))*1.e18_dp))
      |                            1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_diags.F90:53:59:

   53 |         re_qs(k) = max(5.01e-6_wp, min(0.5_wp*(smoc/smob), 999.e-6_wp))
      |                                                           1
Error: GNU Extension: Different type kinds at (1)

This commit should fix the issue:
NCAR/TEMPO@8e30fc0

mgduda · 2026-05-04T19:57:34Z

The changes in NCAR/TEMPO@8e30fc0 seem to fix the original compilation issues I was seeing (with -std=f2008), though I'm now getting a different set of errors:

src/module_mp_tempo_main.F90:3085:63:

 3085 |             melt_f = max(0.05_wp, min(tend%prr_gml(k)*dt/rg(k),1._wp))
      |                                                               1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:2418:53:

 2418 |               snow_dens_frac = min(1._wp, max(0._wp, rs(k)*odt / &
      |                                                     1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:1092:10:

 1092 |           min(cig(1)*oig2*qi1d(k)/am_i*lami**bm_i, max_ni/rho(k)))
      |          1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:945:64:

  945 |             min(ccg(1,nu_c)*ocg2(nu_c)*qc1d(k)/am_r*lamc**bm_r, nt_c_max/rho(k)))
      |                                                                1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:956:66:

  956 |         mvd_c(k) = max(min((3.0_wp + nu_c + 0.672_wp) * ilamc(k), d0r), d0c)
      |                                                                  1
Error: GNU Extension: Different type kinds at (1)

mgduda · 2026-05-04T20:01:35Z

I'm open to suggestions for better ways to deal the lookup tables. Maybe they can be automatically downoaded/linked?

Would it be feasible to incorporate your stand-alone program for computing these tables into MPAS-A's existing src/core_atmosphere/utils directory? If the code is more or less static, we could just place the source file directly in the MPAS-Model repository; otherwise, we could fetch the code from a repository with manage_externals.

The lookup tables are now the same for WRF/MPAS/CCPP, and I image that 99% of users won't want to change or rebuild the tables. Even though the build code is mostly static at this point, I'd like to keep the executable in the TEMPO repository so I don't have manage the program outside of TEMPO. I think the best path forward is to to either pull the lookup tables from NOAA servers or store them as git artifacts or in git LFS.

I can help with changes to download the tables. However, I think we might want to consider how to version these. What happens, for example, if the tables on the NOAA server are updated to support a newer version of TEMPO, but a user is still running an older release of MPAS-Atmosphere (with an older version of TEMPO)?

AndersJensen-NOAA · 2026-05-05T18:27:40Z

The changes in NCAR/TEMPO@8e30fc0 seem to fix the original compilation issues I was seeing (with -std=f2008), though I'm now getting a different set of errors:

src/module_mp_tempo_main.F90:3085:63:

 3085 |             melt_f = max(0.05_wp, min(tend%prr_gml(k)*dt/rg(k),1._wp))
      |                                                               1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:2418:53:

 2418 |               snow_dens_frac = min(1._wp, max(0._wp, rs(k)*odt / &
      |                                                     1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:1092:10:

 1092 |           min(cig(1)*oig2*qi1d(k)/am_i*lami**bm_i, max_ni/rho(k)))
      |          1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:945:64:

  945 |             min(ccg(1,nu_c)*ocg2(nu_c)*qc1d(k)/am_r*lamc**bm_r, nt_c_max/rho(k)))
      |                                                                1
Error: GNU Extension: Different type kinds at (1)
src/module_mp_tempo_main.F90:956:66:

  956 |         mvd_c(k) = max(min((3.0_wp + nu_c + 0.672_wp) * ilamc(k), d0r), d0c)
      |                                                                  1
Error: GNU Extension: Different type kinds at (1)

@mgduda I'm working out final issues with gnu debug, and came upon this issue when opening lookup tables to read:

src/module_mp_tempo_driver.F90:624:43:

624 | action='read', iostat=istat, convert='big_endian')
| 1
Error: GNU Extension: CONVERT tag at (1)

It seems like the convert option in the open statement is not supported by f2008 (but otherwise okay). Our computers are down today, but I'll confirm later this week that this is in fact the case. Do you have any thoughts on how to get around this? I think that convert is only needed for the ccpp since WRF and MPAS force big_endian at compile time.

mgduda · 2026-05-05T19:03:41Z

@mgduda I'm working out final issues with gnu debug, and came upon this issue when opening lookup tables to read:

src/module_mp_tempo_driver.F90:624:43:

624 | action='read', iostat=istat, convert='big_endian') | 1 Error: GNU Extension: CONVERT tag at (1)

It seems like the convert option in the open statement is not supported by f2008 (but otherwise okay). Our computers are down today, but I'll confirm later this week that this is in fact the case. Do you have any thoughts on how to get around this? I think that convert is only needed for the ccpp since WRF and MPAS force big_endian at compile time.

I don't think the Fortran standard provides a way to force I/O to assume a particular byte order, and so this is something that must be handled in a compiler-specific way.

There are probably better ways of going about this, but one option might be to add the convert='big_endian' keyword argument conditionally through pre-processing, e.g.,

    open(unit=mp_unit, file=filename, form='unformatted', status='old', &
         action='read', iostat=istat &
#ifdef TEMPO_USE_CONVERT_ARGUMENT
         , convert='big_endian' &
#endif
         )

For host models whose build systems don't provide compiler-specific flags to assume big-endian I/O, you could define the TEMPO_USE_CONVERT_ARGUMENT macro during compilation (recognizing that this would be incompatible with strict standards compliance).

AndersJensen-NOAA added 2 commits January 9, 2026 00:34

initial connection to TEMPO microphysics

34921a8

update tempo tag in externals

894e86a

AndersJensen-NOAA mentioned this pull request Jan 9, 2026

TEMPO microphysics for WRF wrf-model/WRF#2270

Merged

- updates TEMPO tag

97f8af7

- adds TEMPO registry - adds include flags and module use statements to connect tempo to microphysics driver

AndersJensen-NOAA mentioned this pull request Jan 16, 2026

Updates to TEMPO microphysics (v3) ufs-community/ccpp-physics#348

Open

AndersJensen-NOAA added 12 commits January 20, 2026 23:35

- adds tempo microphysics to list of available microphysics options

3835c65

- adds substepping to tempo microphysics when dt > 90s - adds tempo and aerosolaware options to interface

- adds aerosol initialization for tempo

9c08bb3

- adds initialization routines for tempo with aerosolaware option

-adds tempo and supported diagnostics to microphysics driver

634d4c0

Update TEMPO tag

3a2dded

adds tempo packages and tempo variables to registries

099bb79

adds support for tempo initial conditions of nwfa and nifa

7162adf

move tempo pointer to NCAR/TEMPO

860bf34

adds tempo to lw and sw radiation drivers

d8ef1f6

connects tempo aerosolaware variables to mynn mixing

556bc5c

Added hailaware feature

7e38e78

cleaned up interface, added comments, and added 3d reflectivity

07ff1f0

add missing comma

91f0699

AndersJensen-NOAA marked this pull request as ready for review February 5, 2026 21:01

AndersJensen-NOAA added 4 commits February 13, 2026 19:10

Update to tempo v3.0.1 and add mp_tempo case to precipitation output

28e0284

update tempo to version 3.0.2

f6a45ea

update to tempo v3.0.3

62f07cd

update to tempo version 3.0.4

b0bbb8b

mgduda requested review from jihyeonjang and mgduda April 23, 2026 19:17

mgduda added the Atmosphere label Apr 23, 2026

mgduda changed the base branch from master to develop April 23, 2026 19:19

mgduda reviewed Apr 23, 2026

View reviewed changes

AndersJensen-NOAA added 2 commits April 25, 2026 17:14

Modify TEMPO pointer to development version of 3.0.6

8350c5e

Attempt to fix nested case statement logic in the interface

0953fce

Conversation

AndersJensen-NOAA commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mgduda commented Apr 23, 2026

Uh oh!

mgduda commented Apr 23, 2026

Uh oh!

mgduda commented Apr 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mgduda May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndersJensen-NOAA commented Apr 23, 2026

Uh oh!

AndersJensen-NOAA commented Apr 23, 2026

Uh oh!

mgduda commented Apr 23, 2026

Uh oh!

AndersJensen-NOAA commented Apr 24, 2026

Uh oh!

AndersJensen-NOAA commented Apr 25, 2026

Uh oh!

mgduda commented May 4, 2026

Uh oh!

mgduda commented May 4, 2026

Uh oh!

AndersJensen-NOAA commented May 5, 2026

Uh oh!

mgduda commented May 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

AndersJensen-NOAA commented Jan 9, 2026 •

edited

Loading

mgduda May 4, 2026 •

edited

Loading