coupler history file offset specification for DATM

[thoar]

I have a collection of coupler history files (from an assimilation with CAM) that I would like to use in an 'I" compset and specify DATM_MODE=CPLHIST

CESM2_1_80_3node.cpl.ha2x1hi.nc
CESM2_1_80_3node.cpl.ha2x1h.nc
CESM2_1_80_3node.cpl.ha2x3h.nc

The 'time' and 'time_bnds' variables are directly from the coupler

When I look at the default CASEROOT/CaseDocs/datm.streams.txt.CPLHISTForcing.* files, they have some pretty unusual values for the offset.

The stream text files that use each of these files have the following offsets:

CESM2_1_80_3node.cpl.ha2x1hi.nc <offset> 2700 </offset>
CESM2_1_80_3node.cpl.ha2x1h.nc <offset> 900 </offset>
CESM2_1_80_3node.cpl.ha2x3h.nc <offset> 900 </offset

I am a bit confused as to what I should specify for 'offset'. Section 3.5 of 3. Input Streams — CIME master documentation makes me think I want to have an offset of 0 ... since the time in the file seems to be the midpoint of the time_bnds values.


Any help? Clarification?

 

[thoar]

There seems to be a disconnect between the documentation and the default for release-clm5.0.27 using cime5.6.20 with regard to the interpolation method and subsequent offset specification for the DATM settings.

1.2.4.6. CPLHISTForcing mode and it’s DATM settings

indicates:

For solar taxmode is set to coszen so the offset is set to -10800 seconds so that the ending time-step is adjust by three hours to the beginning of the interval.

When I configure a case using the following compset

set COMPSET = 1850_DATM%CPLHIST_CLM50%BGC-CROP_SICE_SOCN_MOSART_SGLC_SWAV

The datm_in file results in a taxmode of 'cycle' and tintalgo of 'nearest':

  streams = "datm.streams.txt.CPLHISTForcing.Solar -999 -999 -999",
            "datm.streams.txt.CPLHISTForcing.nonSolarFlux -999 -999 -999",
            "datm.streams.txt.CPLHISTForcing.State3hr -999 -999 -999",
            "datm.streams.txt.CPLHISTForcing.State1hr -999 -999 -999",
            "datm.streams.txt.presaero.cplhist -999 -999 -999",
            "datm.streams.txt.topo.cplhist -999 -999 -999"
  taxmode = "cycle", "cycle", "cycle", "cycle", "cycle", "cycle"
  tintalgo = "nearest", "nearest", "linear", "linear", "nearest", "nearest"

The other thing that is interesting is that the datm.streams.txt.CPLHISTForcing.Solar file is set to use an 'ha2x1hi' file with an offset of 2700.

I am in the situation where I have 'ha2x1h' files from a CESM CAM6 run and would like to know if I should follow the documentation or the result of the default case configuration. Any help would be appreciated.

 

[thoar]

To be a bit more specific ... the documentation indicates:

The time-stamps for Coupler history files for CESM is at the end of the interval,

but when I dump the time variable and the time_bnds variable, this does not seem to be the case.

 

[thoar]

After a bit of email back-and-forth, the default values for the offset and interpolation method were verified to produce (nearly) identical results to a coupled run.
These values are not the values implied by the discussion in the documentation.

My methodology for confirming that the offsets are appropriate is as follows:
1) Run B1850 compset for 1 year, generating cpl histaux output needed for datm/drof cplhist modes. Do a separate run to generate a few days of nstep cpl hist output.
2) Postprocess the cpl histaux output to be compatible with datm/drof cplhist modes.
3) Run a G1850ECO_CPLHIST compset for a few days, generating nstep cpl hist output.

Compare the a2x and r2x fields in the cpl hist output from 1) and 2). Because of the time-averaging (e.g., 3-hourly for most a2x_Sa fields) in the cpl histaux output, these fields are not identical. However, if the offsets are chosen appropriately, certain time-filtered time-means of a2x and r2x fields 1) should be within roundoff of the corresponding time-means from 3). For example, 3-hourly means of a2x_Sa fields from 3) are the same as 3-hourly means of a2x_Sa fields from 1) with an additional time-filter applied. I have an ncl script that checks that these relationships hold. If the offsets are not just right, the test fails.

None of this explains why the given offsets work, it just confirms that they do. ...

The clarification needed here is that the 'Postprocess'ing in Step 2 is simply a concatenation to generate monthly files and to ensure they have the domain information. There is no time-averaging or filtering happenning in Step 2.