Allow nlevgrnd less than nlevurb

[ekluzek]

Brief summary of bug

There are some bits of code that address the nlevurb level of arrays that are dimensioned by nlevgrnd. Thus an implicit assumption that nlevgrnd >= nlevurb.

@olyson @barlage

General bug information

CTSM version you are using: ctsm1.0.dev031

Does this bug cause significantly incorrect results in the model's science? No
Configurations affected:
Non-standard configurations where you set nlevgrnd to be less than nlevurb.
We want to use this for the NWP configuration where we want to use 4 levels
with nlevurb being 5.

Details of bug

This dependence is especially true of the older simple building temperature. And we likely won't fix that. We should make sure the code aborts for that case though.

For newer cases, I think we can remove this dependence.

[billsacks]

@ekluzek I just reworded the title to make it sound more like an enhancement.

[billsacks]

From a quick look through the code, I think it will take some care to ensure that we find and fix all relevant places. For example, consider this loop:

https://github.com/ESCOMP/ctsm/blob/e96cce8cbfc2e00175e224849ea174145313cf01/src/biogeophys/SoilFluxesMod.F90#L375-L389

This loop seems to implicitly assume that nlevurb <= nlevgrnd (if nlevurb > nlevgrnd, not all urban layers would be handled currently). We'll need to be vigilant to find and fix any similar looping structures.

[billsacks]

@olyson can you please take this on at some point?

[olyson]

Ok. Start by branching off of master?

[ekluzek]

Yes, we want this to go onto master. So starting with latest master would be good.

[olyson]

I've gone through the code and made appropriate changes to remove this assumption (I think). I'm still getting bfb for a test case (with nlevgrnd>nlevurb; ERP_Ld3.f09_g17.I1850Clm50BgcCropCru.cheyenne_intel.clm-ciso).
I'd like to try running with nlevgrnd<nlevurb to see if I've found all of the assumption instances.
Is that possible with the code base that I'm using (ctsm1.0.dev035)? Can I just set nlevgrnd to, e.g., 4, somewhere, or is there an NWP configuration that I need to use?

[billsacks]

Thank you @olyson !

It's possible that you could just set nlevgrnd to 4, but the easiest thing to do may be to start with the NWP configuration and tweak that. The NWP configuration is supported starting with ctsm1.0.dev038, so you'd need to merge your branch up to that (hopefully fairly easy since it's just a few tags ahead of your starting point). Then you could use a compset like I2000Ctsm50NwpSpGswpGs (with any grid). Note that this is an SP case: in that version of the code, I believe NWP and BGC are incompatible. Then search the code for 5SL_3m and change it to actually use nlevgrnd = 4 rather than 5 (changes are needed in clm_varpar.F90 and initVerticalMod.F90).

Actually, probably it's a good idea to first reproduce that you get an error with this configuration from this code version without your changes, before verifying that your code changes make this problem go away. (Because I'm not sure exactly what configuration generated the error before.)

If any of this is unclear, I'm happy to help.

[olyson]

Thanks, that all makes sense, I'll give it a try.

[olyson]

I tried compset I2000Ctsm50NwpSpGswpGs with a 1deg global grid with ctsm1.0.dev038. This ran for 5 days. I then tried changing nlevsoi and nlevgrnd to 4 in clm_varpar.F90, and removed dzsoi(5)=1.0_r8 in initVerticalMod.F90. This simulation crashed right away with a bunch of large snow balance errors (mostly associated with glacier columns but some with vegetated landunits).
I tried this with my merged code and got the same types of errors.
I think I will investigate these large snow balance errors first in ctsm1.0.dev038 to see what the cause is.