Should we use the same initial conditions for CIME and standalone tests?

[brhillman]

This came up in updating some initialization of greenhouse gas variables, and the need to change some initial condition files. Right now, we are maintaining two sets of IC files: one set for CIME runs (what we'd use in a REAL simulation, meaning all components), and one set for standalone tests (what we'd use for running just a subset of components at a time). But, ideally maybe we'd like to be able to use the same IC files that we would use for the full config in our individual tests, so we do not have to maintain two sets of ICs every time you make a change to something, and so that the tests are operating on the same format of file we would use in a full run. For example, our initial conditions for full simulations do not include p_int, because p_int is initialized by dynamics, but for standalone tests that do not use dynamics we need to include p_int in the initial condition files since dynamics are not run.

[bartgol]

Note: this would require to implement some routines/classes that compute a given field (or a surrogate good enough for unit testing) from its inputs.

I don't have any good idea now, so we'll stick with the current framework. Despite being not great to have to maintain two sets of IC files, it is also important to not make the AD deseign (even more) confusing, just for the sake of accommodating a limited set of unit tests.

[PeterCaldwell]

this would require to implement some routines/classes that compute a given field (or a surrogate good enough for unit testing) from its inputs

I think Ben was suggesting that instead of having our unit tests magically derive any variable they need which isn't needed by CIME simulations, to instead cram all variables that any unit test might need into our CIME IC files. This would be a lot more doable than bloating the unit tests with code to generate variables they need but don't get externally. However, I think having slimmed down CIME ICs is really critical for being able to share them and upload/download them from the inputdata server at high res. So I'm dubious Ben's wish will ever come true.

[brhillman]

@PeterCaldwell actually, I think I was suggesting exactly the opposite of your interpretation, but this was quickly copied from a slack convo that Luca and Aaron and I had. I am 100% on board with slimmed down ICs. The problem is that then we need to do something special to handle the standalone tests. I do not think the answer is to bloat IC files to include the things we need for any combination of components. Right now though, we maintain a SEPARATE IC file for standalone tests that is exactly that: a bloated IC file with every field any process could possibly need, regardless of what else is running. Luca and I were lamenting about this, and thought it might be nice to have the standalone tests be able to use the production IC files.

[PeterCaldwell]

Oh, that's funny I got it totally backwards. I suspect that some unit tests could easily use the CIME IC and others will be more of a struggle. Maybe the rational thing to do would be to use CIME IC for as many as we easily can, and to construct special ICs for the tests that aren't amenable to the default IC?

[bartgol]

I think there are up and down sides with both approaches:

• Approach 1: create 2+ (sets of) input files. On the bright side, no extra code needed, but every time one makes a change to an IC file, we have to remember to change the other ones too. If we're lucky, without the mods we get a crash, and know to fix the IC file. If we're not lucky, we never find out one test is running with bad ICs.
• Approach 2: use only CIME IC files. On the bright side, only one (set of) IC file(s) to maintain. However, we need to provide a mini-lib of some sort, which provides the missing data (with some bare minimum requirement, along the line of p decreasing going up). This mini lib is linked in to standalone tests that need this extra help, but not to libatm when building via CIME.

My preference will prob keep going back/forth between one and the other, so no real preference (for now).

[AaronDonahue]

I think this has been addressed right? We currently have screami initial condition files for our CIME runs and two "unit tests" initial condition files for 72 and 128 levels respectively. Can we close this? @brhillman ? @PeterCaldwell ?

[bartgol]

I think that's the point of Ben: we are not using the same IC file for CIME and standalone runs. So whenever something changes in a phys pkg that needs an IC file update, on top of CIME IC files, we need to update also the screami_unit_tests files.

Can you remind me what these files have that the CIME IC files do not have? Is it just some surface fluxes, or is there more?