Welcome to the new DiscussCESM forum!
We are still working on the website migration, so you may experience downtime during this process.

Existing users, please reset your password before logging in here: https://xenforo.cgd.ucar.edu/cesm/index.php?lost-password/

time offset using CPLHIST for offline CLM5

Why there are time offset when using CPLHIST to drive offline CLM5?
In CLM5 code, when the model takes cpl files, time line will be offset by 2700 seconds for solar hourly input files and 900 seconds for others.

clm5.0.30/cime/src/components/data_comps/datm/cime_config/namelist_definition_datm.xml

<entry id="strm_offset">
<type>integer</type>
<category>streams</category>
<group>streams_file</group>
<desc>Stream offset.</desc>
<values>
<value>0</value>
<value stream="CORE_IAF_JRA.*.GISS.SWDN">-5400</value>
<value stream="CPLHISTForcing.Solar">2700</value>
<value stream="CPLHISTForcing.nonSolarFlux">900</value>
<value stream="CPLHISTForcing.State3hr">900</value>
<value stream="CPLHISTForcing.State1hr">900</value>
<value stream="presaero.cplhist">0</value>
<value stream="topo.cplhist">0</value>
</values>
</entry>
 

erik

Erik Kluzek
CSEG and Liaisons
Staff member
This is a good question that needs some clarification. I thought we had some documentation on this, but I'm not finding it right now.

But, the shift has to do with four things, how the time-stamp is given in CPLHIST output,
how different time interpolation methods use the time-stamp, the averaging period of the data, and finally matching the forcing of CPLHIST cases to the originating case that generated the data. That last point is the most important one, we want a case running with CPLHIST data to match the forcing from the originating case as close as possible (because of averaging and interpolation it wont match exactly, but you want it to be as close as possible).

Now, going through each point.
- How the time-stamp is given in CPLHIST output
- How different time interpolation methods use the time-stamp
- Averaging period of the data
- Matching the forcing of CPLHIST cases to the originating case that generated the data

# How the time-stamp is given in CPLHIST output

Note in all cases the time-step that given in CPLHIST output is at the end of the interval that it represents, regardless of the type of averaging it represents. For example for daily average data that starts on midnight Jan/1st and runs to midnight Jan/2nd, the time-stamp will be for midnight of Jan/2nd. So the time-stamp is always the end of the averaging period.

# How different time interpolation methods use the time-stamp

The solar data uses a cosine of the solar zenith angle scaling in an attempt to get the solar to follow the pattern of the cosine of the solar zenith angle. In this case the time-stamp needs to be the beginning of the averaging period.

The non Solar flux data are things like precipitation that use the average over the whole period, so it wants the middle of the period. The state data for 3hr or 1hr are 3-hourly or 1-hourly state data that use a linear interpolation so wants the middle of the period.

# Averaging period of the data

The sensitivity to the details of the interval is more impactful for faster changing data on a shorter time interval. Some of the data types from above are monthly or yearly averages, and hence it doesn't matter as much the details of the time-stamp. Hence, these fields use a time offset of zero.

# Matching the forcing of CPLHIST cases to the originating case that generated the data

This is the most important part of this. What was done is that simulations were done to find the optimal values for the time offsets so that the CPLHIST simulation would match the original simulation as close as possible.

A writeup on this is in this post:

 
Top