Avoiding conflicts in set_nml and set_env options

[eclare108213]

This was originally raised in #140.

There is also a question about how to handle the options (--sets). There is a question of precedent and some problems have arisen in usage. At this point, there are few constraints on what can be defined in the set_nml and set_env options. Users can mix and match multiple options and the changes will be implemented based on the option name alphabetically. This can create problems if conflicting settings are defined in different options files and a user chooses them. This probably needs to be fixed. There are a couple ways this could be fixed.

• We could carefully review the options files and split up any files that might be in conflict. That would mean we would probably add more options files and tests would need more options to be fully defined.
• We could create a hierarchy of changes such that each set_nml or set_env file would define a value for a unique variable or group of variables. Then a higher level set of files would aggregate those. For instance, we might have set_nml.kdyn0, set_nml.kdyn1, set_nml.kdyn2, set_nml.kdyn3, ... and then a separate like set_nml.alt02 that would define it's options from the lower level files. That would allow just about any test to be setup from the low level files cleanly (with lots of options) and for aggregated settings to be defined as well. The original implementation of the options did something like this.
• We could allow just a single option to be defined by the user on the --sets argument so any conflicts would be avoided. That would mean we would have to create enough high level groups of settings to be useful, and it would reduce some of the flexbility of the current capability.

There may be other ways to address this issue as well.

[apcraig]

#494 adds some new script warning messages when --set introduces conflicts in namelist or env variables. It continues to process as always, but this should provide information that might allow us to avoid these conflicts in the future.

[eclare108213]

It sounds like #494 addresses the issues here sufficiently. Are there still remaining issues that ought to be addressed, or can we close this one?

[apcraig]

It could certainly be improved or changed, but I think what we have is OK. I think we could close this.