Inconsistent setting of nsplit, rsplit and qsplit

[sjsprecious]

Issue Type

Other (please describe below)

Issue Description

According to the DoE's documentation (https://e3sm.atlassian.net/wiki/spaces/DOC/pages/1044644202/EAM+s+HOMME+dycore), when the NH-SE dycores are used, we should set nsplit=-1, rsplit=-1 and qsplit=-1.

However, I added a print statement around https://github.com/NCAR/StormSPEED/blob/stormspeed/src/dynamics/senh/dyn_comp.F90#L914 and I saw the following output:

nsplit =            1 , rsplit =            1 , qsplit =            6

I can see that at least nsplit is set to -1 at https://github.com/NCAR/StormSPEED/blob/stormspeed/src/dynamics/senh/cam_mods/namelist_mod_cam.F90#L96. Thus I guess those values are either overwritten somewhere or not set correctly during initialization. Hopefully it is just a code cleanup issue.

Will this change answers?

I Don't Know

Will you be implementing this yourself?

No

[mt5555]

they should be set to -1 in the namelist, and then at initialization the correct values will be computed, based on dtime, se_tstep, dt_tracer_factor, dt_remap_factor

The values printed in the log are then these values computed by initialization.

The motivation behind this is to have all dycore timesteps relative to "se_tstep", and thus not change when the physics timestep dtime is changed.

[sjsprecious]

Thanks @mt5555 for your quick reply and clarification. Then the printed values in my log file did not necessarily mean the setup is wrong.

According to the following settings, these three variables should be set to -1 in the namelist as expected:

• nsplit: https://github.com/NCAR/StormSPEED/blob/stormspeed/bld/namelist_files/namelist_defaults_cam.xml#L3334
• rsplit: https://github.com/NCAR/StormSPEED/blob/stormspeed/bld/namelist_files/namelist_defaults_cam.xml#L3347
• qsplit: https://github.com/NCAR/StormSPEED/blob/stormspeed/bld/namelist_files/namelist_defaults_cam.xml#L3301

However, the se_nsplit value is overwritten to 2 after the namelist value is read (https://github.com/NCAR/StormSPEED/blob/stormspeed/src/dynamics/senh/dyn_comp.F90#L360) and then broadcast to all MPI ranks. I think this value is then reset to -1 again at https://github.com/NCAR/StormSPEED/blob/stormspeed/src/dynamics/senh/cam_mods/namelist_mod_cam.F90#L96. Thus probably we are using the correct values of those namelist variables eventually but some cleanup may be needed to avoid those confusing value changes (unless I misunderstood those changes again)?

[mt5555]

here's a conjectur on what might be happening:

se_nsplit has to be computed and set properly. It's used by the dp_coupling layer as the loop over dycore timesteps per physics timestep. Internally in the dycore, after initialization only "se_tstep" should be used, since the dycore doesn't need to know the physics timestep. The dycore variable nsplit might be a copy of se_nsplit, and the fact that the dycore changes this back to -1 is confusing, but probably harmless (and left over from the old timestep dycore interface where the user set nsplit instead of tstep).

[sjsprecious]

Thanks @mt5555 for your detailed explanation. That makes sense and hopefully John's code-cleanup work can resolve the confusion later.

[jtruesdal]

@mt5555 would there be a scenario where we would want to allow the user to override the defaults (-1) and ignore the internal computation of these variables. If not then I think they should be removed from the user modifiable namelist for the nonhydrostatic dycore.

[mt5555]

agreed. It would make sense to me if the STORMspeed namelist xml removed nsplit, rsplit and qsplit from allowable namelist variables, and only supports the new timestep interface.

We haven't done this in E3SM (but we should!) because we have a lot of regression tests from older configurations that still use the older timestepping interface.