Shouldn't need to list all grid combinations explicitly in config_grids.xml

[esmci]

Shouldn't need to list all grid combinations explicitly in config_grids.xml

[billsacks]

I'm not sure what the solution is to this problem. I'm hoping others will have some insightful ideas....

[billsacks]

I realized that part of the problem here is that there are bits of information that should be orthogonal, but for which there is currently no way to express this information orthogonally. A useful way to think of this is in terms of the separate ATM_GRID, LND_GRID, etc. xml variables. For most xml variables, we have a way to specify valid values and defaults for just that xml variable, but there is currently no way to do this (that I am aware of) for these component grids.

Some examples of this are:

• Translations between grid long name, short name and alias. For example, I'd like a way to simply list out the allowed glc grids, with their short name and alias -- e.g., g%gland20 has shortname gland20 and alias gl20. Currently, these translations need to be repeated for every grid combination, which is both tedious and error-prone. Even better: phase out support for these three different names for each grid, reducing this to a single name for a grid (personally, I'd choose the "alias", with the long name relegated to embedded documentation).
• Default grid for a given component if none is specified. For example, I'd like a way to say: For any atmosphere, land, ocean (etc.) grids, the default CISM grid is gland5UM if using CISM1 and gland4 if using CISM2.

I'd argue that all information about individual components' grids should be specified orthogonally like that.

There is also the issue of compset dependence - e.g., you can only use a non-null glc grid if running with CISM (or MPAS-LI in ACME). Again, this would be easier to specify if things were broken up orthogonally. Also, we could consider distributing this information in the components as we do for lots of other information (so CISM would define its allowable grids, MPAS-LI would define its allowable grids, etc.) -- although I'm on the fence about whether this makes sense in this case (the main stumbling block I see is what to do about the non-active components).

The next step is specifying which grids are allowed together. The way I see it (maybe incorrectly), this information is essentially already specified by what mapping files are listed in config_grids.xml. So I'd say that you should not have to list allowable grid combinations: instead, the user specifies a set of grids to run with, and then the driver's build-namelist determines if this is an allowable combination based on whether it can find all of the needed mapping files.

A trickier piece is the user interface. According to my suggestions, there would no longer be any capability to define aliases like f19_g16_gl20. In my mind, that's a good thing, both for we developers (avoiding the combinatorial maintenance problem) and for users. Why for users? We are getting so many components in the system that I can't imagine how users can keep straight which components' grids need to be specified in the alias and which can be omitted, and for those that need to be specified, the order in which they need to be specified (quick: does the glc grid come before or after the rof grid?)

So, I would propose that we move away from allowing a specification of a single grid string, instead having separate arguments to create_newcase (-grid_atm, -grid_lnd, -grid_glc, etc. – or maybe -atm_grid, -lnd_grid, -glc_grid). In most cases, reasonable defaults could be chosen if a given component's grid isn't specified, so that users don't need to know what glc grid or wavewatch grid they should choose. (It seems like, in most cases, the atm grid is the only one for which there isn't an obvious default.) These defaults could perhaps depend on the other grids that have been specified: I'm imagining something like the namelist_defaults mechanism, allowing (e.g.) the default ocn_grid to depend on the specified atm_grid. (The idea here is: don't make the user know that you always use a gx3v7 ocean grid when using a T31 atm grid: that kind of expert knowledge can easily be encoded.)

The final(?) piece is how to specify the grid in testnames. Here we do need to smush everything together into one string, I think. For this purpose, I could see using something like a hybrid between the current long name and alias: a%f09_oi%g16, etc. However, this could also make use of the defaults noted above, so that it would also be reasonable to just have grid a%f09 in the test name.

[billsacks]

Much of this was addressed by #814 . There are still some ideas here that were not addressed, but I think this is good enough that I can close it. (IIRC, some of those other ideas were felt to be bad ideas by others.)