Tempo version 3 by AndersJensen-NOAA · Pull Request #353 · ufs-community/ccpp-physics

AndersJensen-NOAA · 2026-02-04T18:15:53Z

Description of Changes:

Tempo version 3. See release notes and documentation in the TEMPO: repository https://github.com/NCAR/TEMPO

Tests Conducted:

Tempo Regression tests

Dependencies:

NOAA-EMC/ufsatm#1063
ufs-community/ufs-weather-model#3078

Documentation:

https://ncar.github.io/TEMPO/

Issue (optional):

Contributors (optional):

…m Thompson

…ply to convection

grantfirl · 2026-03-04T19:41:48Z

@AndersJensen-NOAA Could you please fill out the pull request template so that this PR can be reviewed?

AndersJensen-NOAA · 2026-05-28T15:36:42Z

@grantfirl @dustinswales

I need help getting these two regression tests to pass:
fail_compile_atm_mpas_dyn32_gnu
fail_compile_atm_mpas_dyn32_debug_gnu

I modified GFS_rrtmpg_pre for the TEMPO hookup, and now the two mpas tests fail. It appears that those tests are radiation only physics tests specific to MPAS. Since we aren't using MPAS yet in the UFS and since these aren't actually full physics tests, I think those tests should actually be turned off.

If not, can one of you fix the TEMPO hookup on the CCPP side?

Or better yet, address #361

Thanks.

grantfirl · 2026-05-28T17:09:58Z

@grantfirl @dustinswales

I need help getting these two regression tests to pass: fail_compile_atm_mpas_dyn32_gnu fail_compile_atm_mpas_dyn32_debug_gnu

I modified GFS_rrtmpg_pre for the TEMPO hookup, and now the two mpas tests fail. It appears that those tests are radiation only physics tests specific to MPAS. Since we aren't using MPAS yet in the UFS and since these aren't actually full physics tests, I think those tests should actually be turned off.

If not, can one of you fix the TEMPO hookup on the CCPP side?

Or better yet, address #361

Thanks.

We use those tests to keep the MPAS-in-UFS functionality working, so they need to stay.

It looks like your RTs were run with the wrong (old) version of TEMPO checked out. I addressed the comment in #353 (comment). Please try to pull down the latest commit of this PR branch with the .gitmodules fix and run git submodule update --init --recursive from the ccpp/physics directory. Then, make sure that https://github.com/NCAR/TEMPO/tree/b1ee10c4e53f5cb9b68ac1c4e770cbe126d1e24e is actually checked out in the TEMPO submodule.

Once that's done, please run those 2 failing mpas-based tests again. I'm guessing that it'll fix them.

AndersJensen-NOAA · 2026-05-28T17:49:35Z

@grantfirl @dustinswales
I need help getting these two regression tests to pass: fail_compile_atm_mpas_dyn32_gnu fail_compile_atm_mpas_dyn32_debug_gnu
I modified GFS_rrtmpg_pre for the TEMPO hookup, and now the two mpas tests fail. It appears that those tests are radiation only physics tests specific to MPAS. Since we aren't using MPAS yet in the UFS and since these aren't actually full physics tests, I think those tests should actually be turned off.
If not, can one of you fix the TEMPO hookup on the CCPP side?
Or better yet, address #361
Thanks.

We use those tests to keep the MPAS-in-UFS functionality working, so they need to stay.

It looks like your RTs were run with the wrong (old) version of TEMPO checked out. I addressed the comment in #353 (comment). Please try to pull down the latest commit of this PR branch with the .gitmodules fix and run git submodule update --init --recursive from the ccpp/physics directory. Then, make sure that https://github.com/NCAR/TEMPO/tree/b1ee10c4e53f5cb9b68ac1c4e770cbe126d1e24e is actually checked out in the TEMPO submodule.

Once that's done, please run those 2 failing mpas-based tests again. I'm guessing that it'll fix them.

Still failed:
/scratch4/BMC/wrfruc/Anders.Jensen/RT_RUNDIRS/Anders.Jensen/FV3_RT/rt_3613567/compile_atm_mpas_dyn32_debug_gnu/

AndersJensen-NOAA · 2026-05-29T17:41:52Z

Any other ideas, @grantfirl

grantfirl · 2026-06-01T17:48:47Z

https://github.com/NCAR/TEMPO

@AndersJensen-NOAA

This line is why it won't compile:

https://github.com/NCAR/TEMPO/blob/b1ee10c4e53f5cb9b68ac1c4e770cbe126d1e24e/src/module_mp_tempo_main.F90#L18

grantfirl · 2026-06-01T17:55:06Z

@AndersJensen-NOAA The FV3 preprocessor flag isn't defined when running with MPAS. Can you remove this #ifdef? Or maybe add the one for MPAS? I'm not sure if it's just MPAS or what. @dustinswales Can you remember when running MPAS in UFS, FV3 isn't defined, but should Anders be putting in a check for #ifdef MPAS or something similar? @AndersJensen-NOAA Why is this guard needed in the first place?

AndersJensen-NOAA · 2026-06-01T17:59:32Z

@AndersJensen-NOAA The FV3 preprocessor flag isn't defined when running with MPAS. Can you remove this #ifdef? Or maybe add the one for MPAS? I'm not sure if it's just MPAS or what. @dustinswales Can you remember when running MPAS in UFS, FV3 isn't defined, but should Anders be putting in a check for #ifdef MPAS or something similar? @AndersJensen-NOAA Why is this guard needed in the first place?

God find, @grantfirl, thank you.
The flag is used to expose cloud, ice, and snow properties to the radiation code, so that the effective radii can be calculated. Otherwise, those procedures don't need to be public.

AndersJensen-NOAA · 2026-06-02T16:06:30Z

@grantfirl @dustinswales
I'm sure there is some sort of UFS_IN_MPAS flag that I can track down and add.

AndersJensen-NOAA · 2026-06-02T16:09:57Z

Actually, @grantfirl and @dustinswales, the check should go in the radiation code because when using the MPAS dycore, the effective radius values should be passed through from the microphysics. They only need to be calculated when using FV3.

dustinswales · 2026-06-02T22:59:02Z

FV3 is not defined when running MPAS in the UFS.
@AndersJensen-NOAA Do you need the FV3 macro? Is there any harm in these routines being public?

As for the radiation coupling...
How different are these new routines compared to what is done here?
That is, are these new routines analogous to make_IceNumber, make_DropletNumber, and make_RainNumber in Thompson MP?

dustinswales · 2026-06-03T17:24:19Z

                                           make_DropletNumber_thompson => make_DropletNumber, &
                                           make_RainNumber_thompson    => make_RainNumber

+#ifdef FV3


@AndersJensen-NOAA Can you revert these changes?

@dustinswales it works, the mpas tests now pass, and it is probably better than unnecessarily exposing internal tempo procedures to mpas when they aren't needed.

Sure it works, but it's not great to add macros we don't need. There are physics variables you could use to make dycore specific selections in the physics (e.g. here). No need to macros.

But, can you please answer my questions above about changes to TEMPO compared to Thompson?
Previously, with Thompson, all of these routines were made public and referenced in GFS_rrtmg_pre.F90. Why are they now private with TEMPO? (Seems like an MPAS-A specific decision that is having ramifications in the UFS....)

The Thompson functions , like make_DropletNumber, serve a different purpose. They simply calculate number concentrations if mass mixing ratios exist but number concentrations are too low. They are basically a check on low values. These functions in Thompson have several hard-coded parameter values, and there is no guarantee (given the way the are currently coded) that they will remain physically consistent with Thompson code itself.

My functions are used internally by TEMPO main. They are general procedures for bound checking and updating mass and number concentrations. They are called before diagnostics are output by tempo (reflectivity, effective radius, etc), so they are needed in GFS_rrtmg_pre, but only when effective radii are being calculated, which should not be the case for MPAS.

The Thompson functions , like make_DropletNumber, serve a different purpose. They simply calculate number concentrations if mass mixing ratios exist but number concentrations are too low. They are basically a check on low values. These functions in Thompson have several hard-coded parameter values, and there is no guarantee (given the way the are currently coded) that they will remain physically consistent with Thompson code itself.

My functions are used internally by TEMPO main. They are general procedures for bound checking and updating mass and number concentrations. They are called before diagnostics are output by tempo (reflectivity, effective radius, etc), so they are needed in GFS_rrtmg_pre, but only when effective radii are being calculated, which should not be the case for MPAS.

My point is that "general" routines in Thompson were public and used by the host models, but this is not true with TEMPO.

Your decision to wall off routines potentially needed by different host models, with coupling different needs, is the issue.

Making these public would avoid the need for macros in two repositories (ccpp and tempo) and have zero consequences within MPAS-A

WRF and MPAS do things one way, and the UFS/CCPP do things differently. I think we can agree on that. Any so yes, WRF and MPAS specific decisions can have ramifications in the UFS. That is just the way things work. I don't see it as a problem, given that WRF has been around for longer than the UFS and CCPP.

The "general" routines in Thompson are actually in a separate fortran module called module_mp_thompson_make_number_concentrations.F90. They are not in the main Thompson code. So, I could create another module with public routines exposed to the radiation code in a similar way. I don't think I want to add code thought, so I"ll probably just get rid of the FV3 macros.

But, now I need to know how the radiation code will work with MPAS in the UFS? Will there be code added to pass effective radius values to GFS_rrtmg_pre and skip the calculations?

But, now I need to know how the radiation code will work with MPAS in the UFS? Will there be code added to pass effective radius values to GFS_rrtmg_pre and skip the calculations?

@grantfirl is doing this piece, so you don't need to worry about doing it. You just need TEMPO to work with FV3.

@AndersJensen-NOAA @grantfirl See #361

…physics into tempo_v3

grantfirl · 2026-06-15T15:29:48Z

@AndersJensen-NOAA Does this PR need to go back into draft mode? I had approved and had run the UFS RTs for what I thought was the last time before getting this in the UFS merge queue, and then more commits have appeared. Perhaps this is my fault for not commenting that I was doing so. Please let us know when this is ready to go in final form. Also, I noticed that the TEMPO submodule is now pointing to a different branch (main) where the TEMPO submodule commit hash (c237eae42e0dcc8f8b775f114df5c7017e68b84c) doesn't exist. This needs to be updated to the actual commit from the branch that you're pointing to in .gitmodules at this point.

In the future, there needs to be a PR in the TEMPO submodule that corresponds to the ccpp-physics PR so this process can be cleaner and we can have an actually static codebase to use for testing. Every time the codebase changes, we need to rerun UFS RTs, which is expensive, and the resources used for RTs are all too finite.

AndersJensen-NOAA · 2026-06-15T15:40:39Z

@grantfirl sorry for the miscommunication on this. This is now done, and the ccpp should point to the main branch here: https://github.com/NCAR/TEMPO, which is tagged version 3.1.0.

… into tempo_v3

gspetro-NOAA · 2026-07-17T01:46:52Z

Testing completed successfully on ufs-community/ufs-weather-model#3078. This PR is ready to merge.

AndersJensen-NOAA added 10 commits February 4, 2026 18:14

initial connection of tempo version 3

214c182

Add comments to radiation for tempo MP and to differentiate tempo fro…

07b895c

…m Thompson

Connects TEMPO to GFS PBL generic

13c04f6

fix type and add tempo to aerosol index procedure

fc03db5

simplify tempo driver and add condensation routine

e29c7fa

radiation to use tempo v2 for now

d8171f0

adds diagnostics and optional arguments to tempo

391e7b3

add aerosol surface emissions to tempo and aerosol and hail aware flags

af6f852

couple tempo to MYNN in ccpp

d6e6ed6

update pointer to tempo and fix missing qv variable

425e3f0

AndersJensen-NOAA mentioned this pull request Feb 17, 2026

Optional arguments #355

Closed

AndersJensen-NOAA linked an issue Feb 17, 2026 that may be closed by this pull request

Optional arguments #355

Closed

AndersJensen-NOAA added 5 commits February 18, 2026 16:36

update GFS_rrtmg_pre for tempo v3, clean up condensation

25bdd3a

update to authoritative repo

2fe1529

clean-up code and add checks for tempo

4bc4a12

clean up radiation coupling to tempo v3

a5b3fab

update GFS_rad_pre, bugfixes to mp_temp, and update to tempo v3.0.3

ee031b7

AndersJensen-NOAA marked this pull request as ready for review February 19, 2026 22:12

AndersJensen-NOAA requested review from Qingfu-Liu, dustinswales, grantfirl, joeolson42, mzhangw and rhaesung as code owners February 19, 2026 22:12

AndersJensen-NOAA added 2 commits February 20, 2026 19:29

use thompson functions in interstial 4 for now as tendencies there ap…

0e14599

…ply to convection

Work to fix interstitial 4

8192851

AndersJensen-NOAA mentioned this pull request Feb 26, 2026

Tempo version 3 ufs-community/ufs-weather-model#3078

Merged

32 tasks

joeolson42 approved these changes Feb 26, 2026

View reviewed changes

grantfirl reviewed Mar 4, 2026

View reviewed changes

Comment thread .gitmodules

fixes for RTs

a19da35

update .gitmodules

733fff3

fix for ufs-mpas

75b1d5f

dustinswales reviewed Jun 3, 2026

View reviewed changes

AndersJensen-NOAA and others added 3 commits June 3, 2026 19:30

revert

ece309d

update tempo

97c8dd2

Merge branch 'ufs/dev' into tempo_v3

08e1bcf

grantfirl approved these changes Jun 12, 2026

View reviewed changes

AndersJensen-NOAA added 3 commits June 12, 2026 22:51

update tempo to v3.1.0

db5a369

Merge branch 'tempo_v3' of https://github.com/AndersJensen-NOAA/ccpp-…

2b5603e

…physics into tempo_v3

remove old version of TEMPO that was added back

52d5cdb

point tempo_v3 submodule to latest top-of-main commit

fb004f9

Qingfu-Liu approved these changes Jun 22, 2026

View reviewed changes

Merge branch 'ufs/dev' of https://github.com/ufs-community/ccpp-physics…

46e997c

… into tempo_v3

grantfirl merged commit b5addad into ufs-community:ufs/dev Jul 17, 2026
3 checks passed

This was referenced Jul 29, 2026

ufs-dev PR#353 tempo version 3 and ufs-dev PR#369 main sync NCAR/ccpp-scm#711

Draft

ufs-dev PR#353 tempo version 3 NCAR/ccpp-physics#1231

Open

Uh oh!

Conversation

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

Uh oh!

Description of Changes:

Tests Conducted:

Dependencies:

Documentation:

Issue (optional):

Contributors (optional):

Uh oh!

grantfirl commented Mar 4, 2026

Uh oh!

Uh oh!

AndersJensen-NOAA commented May 28, 2026

Uh oh!

grantfirl commented May 28, 2026

Uh oh!

AndersJensen-NOAA commented May 28, 2026

Uh oh!

AndersJensen-NOAA commented May 29, 2026

Uh oh!

grantfirl commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

grantfirl commented Jun 1, 2026

Uh oh!

AndersJensen-NOAA commented Jun 1, 2026

Uh oh!

AndersJensen-NOAA commented Jun 2, 2026

Uh oh!

AndersJensen-NOAA commented Jun 2, 2026

Uh oh!

dustinswales commented Jun 2, 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!

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!

grantfirl commented Jun 15, 2026

Uh oh!

AndersJensen-NOAA commented Jun 15, 2026

Uh oh!

gspetro-NOAA commented Jul 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

AndersJensen-NOAA commented Feb 4, 2026 •

edited

Loading

grantfirl commented Jun 1, 2026 •

edited

Loading