Bug fixes to 3D diagnostic tendencies; add more tendencies #15

SamuelTrahanNOAA · 2020-03-06T18:58:05Z

This is the ufs-weather-model pull request for NOAA-GSL/ccpp-physics#18

Bug fixes are added so the 3D diagnostic tendency output works properly. There is a new qdiag3d flag to turn on 3D tracer tendencies. Also, there are now tendencies for the model, ccpp, and total. The later two are for debugging the tendency calculations. The timestep_init and timestep_final stages of CCPP are implemented.

Fully tested with gfs v16 beta test suite.

This is still a draft pull request because:

The GSD v0 and GFS v15p2 tendencies are not yet validated.
The other suites need timestep_init and timestep_final sections added or the build process will fail when they're selected.
There is an unresolved question of how to handle the problem of precision.

The Precision Problem

I can say definitively that double precision floating point is not enough to accumulate tendencies across the orders of magnitude typically found in the atmosphere. This was determined by adding a fourth tendency, now disabled in the code. Every time the ccpp or model tendencies were accumulated, that fourth tendency was accumulated by the same amount. In that case, the tendencies of: temperature had a precision of about 0.1 degrees, water vapor mixing ratio of 1e-5, and wind of .1 meters per second. Those are per-3-hour tendencies from a C768 global model. A higher-resolution run would have much larger imprecision due to the larger number of timesteps.

Those can be viewed as the best possible tendency errors.

Right now, the error in the tendencies of CCPP are about 2.5 times the best possible. It is hard to tell whether it is due to further precision issues (eight times as many additions per timestep) or incorrect tendency logic.

The precision issue could be dealt with using quadruple precision (128 bit) floating-point. That is a part of the Fortran 2008 standard, and it is an optional part of the MPI standard. It may be feasible to implement it, but that could cause portability issues.

…e should calculate the 3D diagnostic tendencies.

… and physics/moninedmf.f

…s, implement model/ccpp/total tendencies.

…dded model and cppp tendency variables

…model tendencies add up to total change in 3 hours for the gfs v16 beta suite

… tendencies for gvsv15p2

DomHeinzeller · 2020-03-19T21:15:13Z

@llpcarson @grantfirl - for your information, the latest version of the 3D tendencies PR for NOAA-GSD/fv3atm.

llpcarson · 2020-04-06T14:22:46Z

ccpp/config/ccpp_prebuild_config.py

@@ -184,7 +187,10 @@
    'FV3/ccpp/physics/physics/gcm_shoc.F90'                      : [ 'slow_physics' ],
    'FV3/ccpp/physics/physics/get_prs_fv3.F90'                   : [ 'slow_physics' ],
    'FV3/ccpp/physics/physics/gfdl_cloud_microphys.F90'          : [ 'slow_physics' ],
-    'FV3/ccpp/physics/physics/gfdl_fv_sat_adj.F90'               : [ 'fast_physics' ],
+    'FV3/ccpp/physics/physics/gfdl_fv_sat_adj.F90'               : [ 'slow_physics' ],


is this correct? gfdl_fv_sat_adj.F90 should remain in "fast_physics", right?

Yes, I will revert this.

llpcarson · 2020-04-06T14:23:33Z

ccpp/suites/suite_FV3_CPT_v0.xml

      <scheme>get_phi_fv3</scheme>
      <scheme>GFS_suite_interstitial_3</scheme>
+      <scheme>GFS_DCNV_generic_pre</scheme>


Is this related to the diagnostics output? or an unrelated change?

That change is not my doing. It must have been merged from another branch.

llpcarson · 2020-04-06T14:28:01Z

All of the SDFs will need the timestep_init and timestep_final (as noted) before merging. This may also break alot of user-workflow-configs, so needs to be merged with plenty of communication!

SamuelTrahanNOAA · 2020-04-06T20:20:44Z

All of the SDFs will need the timestep_init and timestep_final (as noted) before merging. This may also break alot of user-workflow-configs, so needs to be merged with plenty of communication!

It would be simpler to update the CCPP framework to allow timestep_init and timestep_final to not be declared in the XML file.

SamuelTrahanNOAA · 2020-04-06T20:21:34Z

I'm trying to test changes to this one by one, but Hera is being very slow, and /scratch2 is freezing up frequently. It may take another day for me to make any meaningful progress on this.

climbfuji · 2020-04-06T20:41:21Z

All of the SDFs will need the timestep_init and timestep_final (as noted) before merging. This may also break alot of user-workflow-configs, so needs to be merged with plenty of communication!

It would be simpler to update the CCPP framework to allow timestep_init and timestep_final to not be declared in the XML file.

This is not going to work and not intended. These two additional routines will be required when we move to cap_gen.py anyway, there is no harm adding them now.

…L#27) * add fh00 post control file, add restart output at specified forecast hours, ugwd bug fixes * fv3atm NOAA-GSL#15:Add support for GEFS-Aerosols restart capability * remove comment prints * fix RunDuration in atmos fcst side * update post_gfs with new post changes * comment out print line * point fv3 dycore to the latest NOAA-EMC dev/emc branch

DomHeinzeller · 2020-04-16T16:37:09Z

@llpcarson @grantfirl I would like to ask you for your opinion on the standard names for the new variables

    logical              :: flag_for_gwd_generic_tend!< true if GFS_GWD_generic should calculate tendencies
    logical              :: flag_for_pbl_generic_tend!< true if GFS_PBL_generic should calculate tendencies
    logical              :: flag_for_scnv_generic_tend!< true if GFS_DCNV_generic should calculate tendencies
    logical              :: flag_for_dcnv_generic_tend!< true if GFS_DCNV_generic should calculate tendencies

in GFS_typdefs.{F90,meta}. I think that all our flags have standard names starting with flag_for or something similar. I can make those changes in the PRs that I need to create anyway. Thank you!

DomHeinzeller · 2020-04-16T16:38:15Z

@llpcarson @grantfirl I would like to ask you for your opinion on the standard names for the new variables

    logical              :: flag_for_gwd_generic_tend!< true if GFS_GWD_generic should calculate tendencies
    logical              :: flag_for_pbl_generic_tend!< true if GFS_PBL_generic should calculate tendencies
    logical              :: flag_for_scnv_generic_tend!< true if GFS_DCNV_generic should calculate tendencies
    logical              :: flag_for_dcnv_generic_tend!< true if GFS_DCNV_generic should calculate tendencies

in GFS_typdefs.{F90,meta}. I think that all our flags have standard names starting with flag_for or something similar. I can make those changes in the PRs that I need to create anyway. Thank you!

grantfirl · 2020-04-16T16:44:38Z

How about: flag_for_generic_gravity_wave_drag_tendency flag_for_generic_planetary_boundary_layer_tendency flag_for_generic_shallow_convection_tendency flag_for_generic_deep_convection_tendency

…

On Thu, Apr 16, 2020 at 10:37 AM DomHeinzeller ***@***.***> wrote: @llpcarson <https://github.com/llpcarson> @grantfirl <https://github.com/grantfirl> I would like to ask you for your opinion on the standard names for the new variables logical :: flag_for_gwd_generic_tend!< true if GFS_GWD_generic should calculate tendencies logical :: flag_for_pbl_generic_tend!< true if GFS_PBL_generic should calculate tendencies logical :: flag_for_scnv_generic_tend!< true if GFS_DCNV_generic should calculate tendencies logical :: flag_for_dcnv_generic_tend!< true if GFS_DCNV_generic should calculate tendencies in GFS_typdefs.{F90,meta}. I think that all our flags have standard names starting with flag_for or something similar. I can make those changes in the PRs that I need to create anyway. Thank you! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCO5UBK5X2EPGE6UIZZ67DRM4X4JANCNFSM4LDF56DQ> .

-- *Grant J. Firl* Project Scientist I Joint Numerical Testbed Research Applications Laboratory National Center for Atmospheric Research FL3-1016: (303) 497-2872

climbfuji · 2020-04-16T16:46:01Z

How about: flag_for_generic_gravity_wave_drag_tendency flag_for_generic_planetary_boundary_layer_tendency flag_for_generic_shallow_convection_tendency flag_for_generic_deep_convection_tendency
…

This sounds good to me, thanks very much. Unless I hear any objections from @llpcarson or @SamuelTrahanNOAA, I will make this change.

llpcarson · 2020-04-16T16:49:04Z

No objections from me, thanks!

…

On Thu, Apr 16, 2020 at 10:46 AM Dom Heinzeller ***@***.***> wrote: How about: flag_for_generic_gravity_wave_drag_tendency flag_for_generic_planetary_boundary_layer_tendency flag_for_generic_shallow_convection_tendency flag_for_generic_deep_convection_tendency … <#m_6412760015156109833_> This sounds good to me, thanks very much. Unless I hear any objections from @llpcarson <https://github.com/llpcarson> or @SamuelTrahanNOAA <https://github.com/SamuelTrahanNOAA>, I will make this change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2OWIT4NIPYCSWSOVDRQUDRM4Y5VANCNFSM4LDF56DQ> .

SamuelTrahanNOAA · 2020-04-16T17:04:01Z

Don't go to far with those long variable names or you'll hit line length or name length limits.

grantfirl · 2020-04-16T17:22:54Z

Just to be clear, I was not commenting on actual variable names, only their CCPP standard names.

…

On Thu, Apr 16, 2020 at 11:04 AM Samuel Trahan (NOAA contractor) < ***@***.***> wrote: Don't go to far with those long variable names or you'll hit line length or name length limits. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCO5UFY6C6IY4DG6IFPQXDRM43BDANCNFSM4LDF56DQ> .

-- *Grant J. Firl* Project Scientist I Joint Numerical Testbed Research Applications Laboratory National Center for Atmospheric Research FL3-1016: (303) 497-2872

SamuelTrahanNOAA · 2020-04-16T17:33:29Z

Just to be clear, I was not commenting on actual variable names, only their CCPP standard names.

I'm unaware of any string length limits in Python, so you should be able to use the collected works of Shakespeare as the standard name.

Just make sure you have reasonable Fortran variable name lengths.

Bug fixes to 3D diagnostic tendencies (based on #15)

SamuelTrahanNOAA added 17 commits December 19, 2019 20:31

add qdiag3d support

df0e6ea

add qdiag3d support

c7ad1a3

Further bug fixes to tendency accumulation

dc10a75

fix several bugs mentioned in code review

2200678

Merge branch 'merge-me' into gsd/develop

0d60589

add a pbl_generic_tend flag to tell whether the GFS_PBL_generic modul…

538a1d8

…e should calculate the 3D diagnostic tendencies.

Move PBL tendencies into the PBL run subroutine.

fbc1826

add ldiag3d and qdiag3d support to physics/module_MYNNPBL_wrapper.F90…

ff725de

… and physics/moninedmf.f

Point to sam's repo

7b299c5

add model and ccpp tendency calculations

e95f8ab

physics-level changes for tendencies

5275fb9

Correct tendency flag names, implement some more diagnostic tendencie…

cf3d933

…s, implement model/ccpp/total tendencies.

remove model_tend_pre&post from fast physics, add to stochastic

dd8f27e

merge latest gsd/develop

9ca064c

All gfs v15p2 and v16beta 3d diagnostic tendencies look reasonable; a…

f4fecfd

…dded model and cppp tendency variables

Add timestep_init and timestep_final actions to CCPP. Update code so …

7d4d569

…model tendencies add up to total change in 3 hours for the gfs v16 beta suite

Remove debug prints and commented-out code.

d46ebe8

SamuelTrahanNOAA changed the title ~~Feature/gsd phys diag3d~~ Bug fixes to 3D diagnostic tendencies; add more tendencies Mar 6, 2020

SamuelTrahanNOAA added 2 commits March 12, 2020 17:20

Add total tendency calculations for gfsv15p2 and gsdv0. Calculate pbl…

9f8b18f

… tendencies for gvsv15p2

Add some #ifdef CCPP to avoid breaking non-CCPP runs

cd2583d

SamuelTrahanNOAA marked this pull request as ready for review March 17, 2020 17:19

SamuelTrahanNOAA requested a review from DomHeinzeller as a code owner March 17, 2020 17:19

SamuelTrahanNOAA added 4 commits April 3, 2020 20:23

merge gsd/develop

2dd765a

merge gsd/develop submodule ccpp/framework

19fb05e

Correction: Diag%hpbl => Tbd%hpbl

e09316a

Correction: Diag%hpbl => Tbd%hpbl

fcc27ec

llpcarson reviewed Apr 6, 2020

View reviewed changes

SamuelTrahanNOAA mentioned this pull request Apr 6, 2020

Bug fixes to 3D diagnostic tendencies; add more tendencies NOAA-GSL/ufs-weather-model#12

Merged

climbfuji mentioned this pull request Apr 17, 2020

Bug fixes to 3D diagnostic tendencies (based on #15) #19

Merged

DomHeinzeller added the do not merge Something is wrong, do not merge label Apr 20, 2020

DomHeinzeller added a commit that referenced this pull request Apr 22, 2020

Merge pull request #19 from climbfuji/tendencies_sam_with_dom_mods

537df51

Bug fixes to 3D diagnostic tendencies (based on #15)

DomHeinzeller merged commit fcc27ec into NOAA-GSL:gsd/develop Apr 22, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bug fixes to 3D diagnostic tendencies; add more tendencies #15

Bug fixes to 3D diagnostic tendencies; add more tendencies #15

SamuelTrahanNOAA commented Mar 6, 2020 •

edited

Loading

DomHeinzeller commented Mar 19, 2020

llpcarson Apr 6, 2020

DomHeinzeller Apr 16, 2020

llpcarson Apr 6, 2020

SamuelTrahanNOAA Apr 6, 2020

llpcarson commented Apr 6, 2020

SamuelTrahanNOAA commented Apr 6, 2020

SamuelTrahanNOAA commented Apr 6, 2020

climbfuji commented Apr 6, 2020

DomHeinzeller commented Apr 16, 2020

DomHeinzeller commented Apr 16, 2020

grantfirl commented Apr 16, 2020 via email

climbfuji commented Apr 16, 2020

llpcarson commented Apr 16, 2020 via email

SamuelTrahanNOAA commented Apr 16, 2020

grantfirl commented Apr 16, 2020 via email

SamuelTrahanNOAA commented Apr 16, 2020

Bug fixes to 3D diagnostic tendencies; add more tendencies #15

Bug fixes to 3D diagnostic tendencies; add more tendencies #15

Conversation

SamuelTrahanNOAA commented Mar 6, 2020 • edited Loading

The Precision Problem

DomHeinzeller commented Mar 19, 2020

llpcarson Apr 6, 2020

Choose a reason for hiding this comment

DomHeinzeller Apr 16, 2020

Choose a reason for hiding this comment

llpcarson Apr 6, 2020

Choose a reason for hiding this comment

SamuelTrahanNOAA Apr 6, 2020

Choose a reason for hiding this comment

llpcarson commented Apr 6, 2020

SamuelTrahanNOAA commented Apr 6, 2020

SamuelTrahanNOAA commented Apr 6, 2020

climbfuji commented Apr 6, 2020

DomHeinzeller commented Apr 16, 2020

DomHeinzeller commented Apr 16, 2020

grantfirl commented Apr 16, 2020 via email

climbfuji commented Apr 16, 2020

llpcarson commented Apr 16, 2020 via email

SamuelTrahanNOAA commented Apr 16, 2020

grantfirl commented Apr 16, 2020 via email

SamuelTrahanNOAA commented Apr 16, 2020

SamuelTrahanNOAA commented Mar 6, 2020 •

edited

Loading