Allow CTSM to output history files interpolated to a regular grid (for example from SE unstructured grids to a FV grid)

[ekluzek]

It would be helpful to add the capability to interpolate output history files from an unstructured grid to a regular grid that can be visualized more readily. This capability has been put into CAM and could be ported over to CTSM. Since the "standard" grid for running with CAM in CESM is now the SE ne30np4.pg3 grid this capability would allow us to more easily visualize output from coupled simulations as well as to run standalone "I compsets" at ne30np4.pg3 and be able to interpret the output.

This came up in the context of this issue:

https://github.com/ESCOMP/CTSM/issues/2274#issuecomment-1837447524

[ekluzek]

In this comment I give the namelist options for CAM

https://github.com/ESCOMP/CTSM/issues/2274#issuecomment-1837583757

In CTSM from looking at the current namelist items I suggest the following might be how it would look like. Currently the history namelist items are jammed in the main clm_inparm namelist, and I'd prefer they would be in their own namelist, but for starting from where we are at this is what it would like. Some of the language is clearer with CAM, but below is more consistent with current CTSM history settings.

<entry id="hist_interp_output" type="logical(10)" category="history"
    group="clm_inparm" valid_values="">
Interpolate given history file to a lat/lon grid before output. One setting per history tape series.
Default: .false.
</entry>

<entry id="hist_interp_nlat" type="integer(10)" category="history"
    group="clm_inparm" valid_values="">
Size of latitude dimension of grid for interpolated output.
If hist_interp_nlat and hist_interp_nlon are zero, reasonable values
will be chosen based on the run resolution. Only used if
hist_interp_output is .true. for that history tape series. One setting per history tape series.
Need to set both hist_interp_nlat and hist_interp_nlon.
Default: 0
</entry>

<entry id="hist_interp_nlon" type="integer(10)" category="history"
    group="clm_inparm" valid_values="">
Size of longitude dimension of grid for interpolated output.
If hist_interp_nlat and hist_interp_nlon are zero, reasonable values
will be chosen based on the run resolution. One setting per history tape series.
Default: 0
</entry>

<entry id="hist_interp_gridtype" type="integer(10)" category="history"
    group="clm_inparm" valid_values="1,2,3">
Selects output grid type for lat/lon interpolated output.
1: Equally spaced, including poles (FV scalars output grid).
2: Gauss grid (Eulerian).
3: Equally spaced, no poles (FV3 staggered velocity).
Only used if hist_interp_output is .true. for that history tape series. One setting per history tape series.
Default: 1
</entry>

CAM also has interpolate_type, which it seems to suggests it allows you to use interpolation methods from the dycore, which we of course would not have, so as such I'm thinking we wouldn't have it.

The above is just my first pass of what the interface would look like, and I'd like everyone to weigh in on how they think this should go. It's also dependent on what the implementer @mvertens can reasonably do. So there could be changes to the above based on that. Also some features could be added in time rather than at the initial implementation.

[billsacks]

I was just reading through this and the related discussion in #2274 , and wanted to also bring @mnlevy1981 into the loop. He and I were talking recently about a desire to have an ESMF-based workflow for regridding output to a lat-lon grid incorporated into the postprocessing via the ESDS initiative. If I remember our discussion correctly, even though CAM has the option to interpolate output to a lat-lon grid at runtime, they have requested an option to do this in the post-processing as well, because a user might produce native output on the unstructured grid and then decide after the fact that they want to regrid to a particular lat-lon grid.

I think it makes sense to add a runtime option in CTSM similar to what's in CAM, but wanted to note that the current thinking seems to be that there would be a post-processing option as well.