add ability to specify namelist requirements via xml

[escomp]

add ability to specify namelist requirements via xml

[billsacks]

Bill Sacks < [email protected] > - 2016-09-21 15:02:58 -0600

Mariana is working on a cime feature that accomplishes most or all of what we wanted here: You can add an element in namelist_definition like this:

<unmodifiable_via_user_nl>ERROR TEXT</unmodifiable_via_user_nl>

Then if the given variable appears in the user_nl file, build_namelist will die with an error (printing the given ERROR TEXT).

This relies on the python version of the namelist utilities - so we'll be able to use it in CLM once CLM's build namelist is rewritten in python.

If I understand the original comment correctly, this mechanism wouldn't handle case (3) - which I think is dealing with the possibility that a given variable might be modifiable via the user_nl file in some circumstances but not in others. But I don't know how many (if any) cases we have of this... if it turns out we have a lot, I imagine we could extend the new code somehow to handle that case.

[billsacks]

One thing we do a lot is have error-checking code saying something like "foo should only be specified if bar = X", or maybe "having foo = Y is only possible if bar = X". I could imagine encoding this in the xml if we allow arbitrary python code in the xml. For example, we could have elements like <can_only_be_specified_if> (in the above case, that would have the value "bar == X") and/or <value_requirements> (off-hand, I'm not sure what the python code would look like for that, but I imagine we could come up with something).

[billsacks]

One thing we do a lot is have error-checking code saying something like "foo should only be specified if bar = X", or maybe "having foo = Y is only possible if bar = X". I could imagine encoding this in the xml if we allow arbitrary python code in the xml. For example, we could have elements like <can_only_be_specified_if> (in the above case, that would have the value "bar == X") and/or <value_requirements> (off-hand, I'm not sure what the python code would look like for that, but I imagine we could come up with something).

For this to work, together with the more data-driven capabilities that I think are possible in python - where we don't need explicit add_default calls: I think we'd need a way to specify that one namelist group be handled before another. For example, we could put the high-level control logic (selecting which parameterizations we use, etc.) in the main clm_inparm. Then we'd want to ensure that is dealt with first, before trying to do any error checking on namelist variables in other groups (for example: nothing should be specified in user_nl_clm from group 'foo', unless variable 'bar' in clm_inparm has value 'baz').

[ekluzek]

This is something that can likely happen now with ParamGen which is in cime now, and has a syntax that should work for these type of things.

[ekluzek]

This goes in the context of #585