dependance of some namelist default on the number of vertical levels (lev)?

[cecilehannay]

What is the feature/what would you like to discuss?

This issue should probably remove all nlev references in places where "lt" and "mt" can be used instead of nlev.

In namelist_defaults_cam.xml, there are parameters that are connected to the number of levels. While it makes sense for ncdata to be connected to nlev, it doesn't make sense for other parameters. Instead these parameters should connected to the lt or mt configuration. This is to avoid getting the wrong parameters when changing nlev.

For instance, we have in namelist_defaults_cam.xml

<gw_apply_tndmax                        >.true. </gw_apply_tndmax><gw_apply_tndmax chem="ghg_mam4" nlev="93">.false.</gw_apply_tndmax>
<gw_apply_tndmax chem="ghg_mam4" nlev="58">.false.</gw_apply_tndmax>

But if we are doing a LT run with a different number of levels than L58, we get gw_apply_tndmax=.true.

I've just experienced this with a LT and L32. I changed it manually in user_nl_cam but it would be best if it would automatically come out the same for all LT runs.

They are other parameters dependent of nlev=58 or 93

Is there anyone in particular you want to be part of this conversation?

@JulioTBacmeister, @cacraigucar

Will this change (regression test) answers?

Yes

Will you be implementing this enhancement yourself?

Any CAM SE can do this

[cacraigucar]

Adding @fvitt and @brian-eaton to the discussion

[brian-eaton]

The setting of gw_apply_tndmax for 32 level cam6 configurations is true. Changing gw_apply_tndmax to false for the new cam_dev, LT/MT compsets indicates that this is not strictly a model top issue. I would argue that the best solution is to add this setting to the use case file. That was done initially for hist_cam_{lt,mt}.xml, but for some reason was reverted in cam6_3_111. If this setting is made in the LT use case files then the correct value will be put in the namelist file regardless of nlev.

[cacraigucar]

@fvitt - Since you were the person who felt that some of the LT/MT variables should be in namelist_defaults, and made the change to move them, could you explain your reasoning. Based on @cecilehannay's request in this issue, do you have any problem with us moving them back to the use_cases?

[fvitt]

@fvitt - Since you were the person who felt that some of the LT/MT variables should be in namelist_defaults, and made the change to move them, could you explain your reasoning. Based on @cecilehannay's request in this issue, do you have any problem with us moving them back to the use_cases?

I thought it would be better to have these namelist parameters set in one place rather than multiple use case files. Setting them in one place is easier to maintain. My thinking is that the use case files are for setting exceptions to the defaults.

[brian-eaton]

In a sense gw_apply_tndmax is requiring an exception to the default which was .true. for the cam6 low top model. Clearly using nlev as an attribute is not appropriate. Perhaps at the end of the cam7 development we'll use phys = cam7 as the best way to set the value. But until the dust settles it seems like the use case is the best way to go.

[fvitt]

Another solution may be add a configure attribute (or option) such as "model_top" which can have valid values of "LT", "MT", "HT", and "XT". This attribute can be used in namelist_defaults_cam.xml for the settings as model_top="MT", etc. As mentioned before, there is no perfect way the for setting the namelist options for all our supported configurations.

[cacraigucar]

@fvitt and @brian-eaton - @nusbaume and I had a meeting this morning to brainstorm this issue, and after discussing several scenarios, we independently came up with the identical solution of introducing a configure option which we also named "model_top"! We propose introducing valid values of "LT" and "MT" and bringing this into #820. The "HT" and "XT" valid values can be brought in at a later time and we can open a separate issue for them.

[adamrher]

A cursory look and I only see an nlev / namelists_defaults dependence for effgw_beres_dp and effgw_oro, and a there is nlev=60 logic in build-namelist. So it shouldn't be that much work to resolve this issue.