Benchmarking DAS History.rc in isolation

[bena-nasa]

An idea:

One long-standing issue with ensuring the ADAS model configuration has acceptable performance, is that testing the DAS history is only practical by running the das. The reason for this is that the History.rc files are templatedand are only un-templated when the DAS machinery is run as the code that does this is deep inside one of the DAS scripts.
Also one important distinction between running from gcm_setup and running from the ADA, since the untemplating of the
ADAS History templates depends on the date, this can't be done at setup.

The History.rc for each of the 4 synoptic times each day is slightly different. So to get a working History.rc and run with it, the ADAS scripting one way or another must be executed. If you want to save this History.rc you have to grab it from the work directory as the untemplated rc files are here and it gets removed one the temporary work directory is deleted. (Certainly if the .rc files for History were saved that would be a help).

More useful would be useful if the un-templating functionality could be extricated as something that could be run on it's own script so that producing a working History.rc file could be done in any script or just stand alone as issues arise.

The templates are in version control (I think those are the HISTORY_FP.rc.XXz.tmpl files) and the code that does this is in the scripting so it seems like extracting this would be doable. And something like this could be used by gcm_setup as well.

A script/function etc ... that takes a date and whatever other arguments are needed given an input template. So if we are doing development and want to know how it would impact the DAS or MERRA2-RC, or any other existing template file, one could setup an experiment of the appropriate resolution. Then given a template file, just in it through the untemplating script and bam, we have a valid History.rc that can just be used in any run situation.

This would make

• proactive testing of the ADAS or any non-gcm_setup History configuration and timings much simpler
• allow us to catch issues during development
• make troubleshooting easier
• provide setting recommendations ahead of time.

[bena-nasa]

@rtodling @mathomp4 @sdrabenh

Just following up on this based on mail traffic today, myself and Matt are probably the only one who care about this issue but... It really would make an awful lot of sense if there was ONE script (preferably written in Python) that untemplated the History.rc templates that everyone gcm_setup/where every buried deep in the das scripting it occurs/XXX_setup used.
Looking at the various History.rc templates all it would need the following to untemplate all permutations we currently have:

• A date and time (since the DAS needs this)
• A suffix for the file names (used by DAS)
• An atmosphere and model resolution (used by AGCM where where the output resolution depends on the model resolutions)

With those things you could take any template and bam get a file with no chevrons, not have to run a full DAS run (since fv_setup doesn't untemplate anything, that done at the runtime), run gcm_setup, or xxx_setup.

Heck you could template even more, make the bit shaving, make the deflate level for example arguments to the script and template those, then changing these would be so easy...

This would make workflows cleaner and testing possible especially when doing development on History. I would even volunteer to do this but it is probably outside my task.

[bena-nasa]

@rtodling @tclune @sdrabenh
Just pinging this issue again I don't want it to get lost, this would be very, very, very, very useful, it would make development and testing of History much easier.
Once again I'd be very happy to do this...

[bena-nasa]

Ping

[rtodling]

Hi Ben,

Sorry that I have not noticed this before - I was just searching for some info on bit-shaving and ran into this.

I don't see why we could not converge on some type of script to handle the HISTORY file(s) adequately.

As you identified, there are two levels of templating in HISTORY.rc: those marked with the "at" character, as in @something; and those marked as >>>SOMETHING<<<. I had agreed w/ Larry T. many years ago the the @something would be handled at setup time, and those >>SOMETHING<<< would be run-time variables. I have to say the GCM setup's has at times mixed these up - since not everybody making changes to the setups understand/knows-about the agreement.

In any case, I don't oppose to working on a unified script that can handle the setup part. We can also have a live discussion about this and decide on a path forward - as you can tell, I am not good at following discussions via email (those within git hub are even worse) - so meeting and talking about it will be more effective.