Make Noah-MP-only static fields optional in the init_atmosphere core

[mgduda]

This PR introduces changes that make Noah-MP static fields optional in the init_atmosphere core.

Previously, the soilcomp and soilcl{1,2,3,4} fields needed only by the Noah-MP scheme were required in all static files read by the init_atmosphere core. In cases where the Noah-MP scheme will not be used when running the atmosphere core, it would be desirable to not require these Noah-MP-only fields.

Now, a new namelist option and package in the init_atmosphere core permit the generation and the use of static files that do not contain soilcomp and soilcl{1,2,3,4}.

1. The new config_noahmp_static namelist option in the &data_sources namelist group determines whether the Noah-MP-only static fields will be allocated, read, computed, and written in the init_atmosphere core. This namelist option defaults to true, yielding the default behavior of the init_atmosphere_model program prior to this commit.

2. The new noahmp package, which is active if and only if config_noahmp_static is true, controls the allocation, reading, and writing of the Noah-MP-only static fields.

3. In the init_atm_static routine, which is called when config_static_interp is true, the soilcomp and soilcl{1,2,3,4} fields are computed only if config_noahmp_static is true.

[ldfowler58]

The down point of adding the option config_noahmp_static is the need to recompute the static fields if we want to use the Noah-MP or Noah land surface schemes. What was the motivation for the PR? Thanks.

[mgduda]

@ldfowler58 There is at least one group that is using their own software (as I understand it) to produce static files, which they would then like to use with the init_atmosphere core to produce real-data ICs. Their software for producing static files doesn't handle the new Noah-MP fields, and since they aren't currently interested in using the Noah-MP scheme, this PR would allow them to avoid modifying their code.

We could make the new config_noahmp_static option hidden by default.

[abishekg7]

Tested this with the config_noahmp_static nml option set to true and false, and unset. Seems to work as intended. However, I have some further questions about noahmp package, which I will ask in person before approving.

[ldfowler58]

Thanks to abishek for testing the config_noahmp_static nml option. Can we rename the package noahmp to sf_noahmp_in for consistency with the package name in ./core_atmosphere/Registry.xml?

As Michael knows, I am in the midst of reviewing the implementation of the EPA PX land surface scheme which requires additional static fields which are not needed with Noah or Noah-MP. I was wondering if we could, fro the get go, have a more generic way to do this so that we do not multiply the config_*_static options? For instance, we could have something like

config_lsm_static = "sf_noahmp" or config_lsm_static = "sf_px" and move the relevant sourcecode using CASE(' ')? Would this make sense? Thanks.

[mgduda]

Thanks to abishek for testing the config_noahmp_static nml option. Can we rename the package noahmp to sf_noahmp_in for consistency with the package name in ./core_atmosphere/Registry.xml?

As Michael knows, I am in the midst of reviewing the implementation of the EPA PX land surface scheme which requires additional static fields which are not needed with Noah or Noah-MP. I was wondering if we could, fro the get go, have a more generic way to do this so that we do not multiply the config_*_static options? For instance, we could have something like

config_lsm_static = "sf_noahmp" or config_lsm_static = "sf_px" and move the relevant sourcecode using CASE(' ')? Would this make sense? Thanks.

For the sf_noahmp_in package, what is the _in suffix meant to signify? In my opinion, the sf_ prefix isn't necessary, as there is only one category of parameterization scheme with the name "noahmp".

Regarding the generalization of static field selection, how would we specify that we want both Noah-MP and PX static fields?

[ldfowler58]

The "sf_" prefix refers to all the parameterizations dealing with surface processes (land surface schemes, surface layer schemes). I was simply advocating for consistency in the name of packages between those used in core_init_atmosphere and core_atmosphere.

In response to "Regarding the generalization of static field selection, how would we specify that we want both Noah-MP and PX static fields?", and to date, the specific fields required to run Noah-MP (soilcomp, etc...) are not used in the PX-LSM. And vice versa, the specific fields required to run PX (soiltypef, lai12m, etc...) are not used in the Noah LSM.

Just suggestions, of course.