Need upwind advection test -> Test coverage and Options Implementation

[apcraig]

In the test matrix,

https://docs.google.com/spreadsheets/d/1dMzOC2GAsGqXJvs7xHybCQkPRneeUm78Ah1OXp34bAQ

alt04 is supposed to test the upwind advection scheme but this causes the model to fail so remap is being used temporarily. We need to add or modify one of the tests to cover upwind.

[apcraig]

I am going to add a couple other issues here for the time being.

The alt01 test has bathymetry turned on but kdyn=0 (dynamics off). We should again review our tests and test coverage.

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.

1. 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.

2. 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.

3. 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.

[eclare108213]

I will move the discussion about how to handle options to a separate issue, and close this one.