add ability to specify namelist requirements via xml

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2014-06-06 15:27:44 -0600
Bugzilla Id: 1989
Bugzilla CC: andre@ucar.edu, muszala@ucar.edu, mvertens@ucar.edu, rfisher@ucar.edu,

Erik and I were talking about how it would be nice to be able to specify namelist requirements via an xml file, in order to simplify the error-checking that we currently do in build_namelist.

We could see three possible ways to do this:

(1) Specify requirements (somehow) in the namelist definition xml file

(2) Have a file similar to namelist_defaults, but giving requirements rather than defaults

(3) If a lot of our error-checking is along the lines of:

If variable X=xxx, then variable Y should be yyy, which is its default value

• Then we could implement this by having something like an "unmodifiable" attribute in the namelist_defaults file.

e.g., rather than

yyy

instead, have:

yyy

If the unmodifiable attribute is set, that means that, not only is this its default value, but also it cannot be modified from this value by the user.

This could possibly be implemented in the add_default call.

[billsacks]

Bill Sacks < sacks@ucar.edu > - 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