Advice wanted: DATM variables needed to force all other components about cesm HOT 18 CLOSED

@kdraeder If I understand this correctly, I think that this list of variables would be similar to the list needed to force the J1850G compset. That compset has a datm but all active surface components. It was set up for the sake of spinning up CISM, by going back and forth between (a) a B compset that produces cpl hist output from atm to cpl, and (b) this J compset that cycles over this cpl hist output in datm, running all surface components.

@lofverstrom or @JeremyFyke - I forget what output you get from the coupler for this (i.e., what namelist flags you turn on). Can you please let us know?

from cesm.

These namelist flags are turned on in the the cpl namelist (in a B compset) to produce the atm forcing data for the JG simulation.

cat >> user_nl_cpl <<EOF
histaux_a2x3hr = .true.
histaux_a2x24hr = .true.
histaux_a2x1hri = .true.
histaux_a2x1hr = .true.
EOF

from cesm.

@billsacks @lofverstrom
This looks like just what I need to know!
If we can't afford the hourly output, can the components
make due with the 3 hourly and daily?
Thanks!

from cesm.

@kdraeder these are the six hourly fields:

  character(CL) :: hist_a2x1hri_flds = &
       'Faxa_swndr:Faxa_swvdr:Faxa_swndf:Faxa_swvdf'

  character(CL) :: hist_a2x1hr_flds  = &
       'Sa_u:Sa_v'

If I remember correctly, POP folks are the ones who suggest using those rather than 3-hourly. You may want to talk to @klindsay28 about this if you haven't already.

from cesm.

I talked with @klindsay28 and this is the user_nl_cpl that was used to generate the most recent CPLHIST data:

histaux_a2x24hr = .true.
histaux_a2x3hr = .true.
histaux_a2x1hri= .true.
histaux_a2x1hr = .true.
histaux_r2x = .true.

That list is the same as @lofverstrom above, with the exception that it also includes histaux_r2x, which would be needed if you want to force a POP/CICE configuration, but NOT for CLM standalone.

from cesm.

from cesm.

I think the answer to the question "What forcings should I generate" depends on the use cases for the forcings.

I came up with the settings mentioned by @lofverstrom and @ekluzek. The use case for the forcings that led to those choices was ocean and land BGC spinup. For the ocean BGC spinup, I wanted the ocean circulation in the forced run to be very close to the circulation of the coupled model. Based on some experimentation, I have found that having some forcings at a higher temporal frequency reduces the mismatch between the forced run using this forcing and the coupled run generating the forcing. For instance, lower frequency winds (more temporal smoothing) tends to clip the high winds. This reduces energy going into the ocean, and leads to shallower mixed layers, which impacts BGC. So I opted to generate bottom winds more frequently than 3-hourly.

I suspect that the use case(s) for the forcing you are generating is different.
So it might not make sense to use the same settings that I developed.
It might be the case that 3-hourly averages are reasonable.
I'll point out that this is the frequency of all forcings used in our ocean/ice hindcast forcing.
But I am not clear on the use cases you have in mind.

from cesm.

@klindsay28
Those are excellent points, which clarify why I'm trying to be inclusive
when choosing which forcing variables and frequencies to save,
while minimizing the data volume. I'm in the position of not knowing
all of the use cases for which I'd like this data set to be useful.
But your use case and the CLM spinup are a great place to start, and may be sufficient.
Am I right in thinking that the BGC spinup is probably one of the more demanding
use cases?
Are you aware of other, equally demanding use cases that required
different high frequency variables?

The data volume of the cpl history files, even including the hourly forcing,
looks manageable. I need to figure out whether the variables at different
frequencies is redundant: does a2x1h_Sa_u essentially contain
all of the information that's in a2x3h_Sa_u?
Are any components unable to use hourly data,
so the redundant 3-hourly should be included?

Thanks again for the advice!

from cesm.

I've run into one other wrinkle, which I need to understand better,
and maybe fix. When I use histaux_r2x = .true. I get the
cpl .hr2x. files only at hour 00, even though my forecasts
end at hours 06, 12, 18, and 00.
Am I missing a way to write the hr2x files from every forecast?

This river forcing is described as instantaneous, but the time
that's associated with the data in that file is half way between
hour 18 and 00. If it had been a day-long forecast, the time
would have been hour 12 (half way between hours 00 of
the initial and final dates). In both cases the file name has
...00000.nc in it, so it looks like the data is for the day boundary,
but comes from(?) different times of day.
Do I need to worry about this?

from cesm.

Yes, I think that's a problem. According to this code block:

https://github.com/ESMCI/cime/blob/c4f02062ee6cd0fb1e671513c28eb07582f7d4ed/src/drivers/mct/main/cime_comp_mod.F90#L3054-L3063

it looks like histaux_r2x is hard-wired to just write output every 24 hours. Are you restarting the model every 6 hours? If so, an important point is that these histaux files do not restart properly - so I think what you'd get is r2x files written every 24 hours, but just with averages from the last 6 hours (i.e., since the last restart).

One possible fix would be to write these files every 6 hours rather than every 24 hours. I'm not sure what implications that would have.

from cesm.

Thanks @billsacks
Each forecast is a 'startup', and I don't anticipate
that these files will be needed in a 'restart' context.

The documentation of histaux_r2x says
(http://www.cesm.ucar.edu/models/cesm2/component_settings/drv_nml.html)
"turns on coupler history stream for instantaneous runoff to coupler fields."
If it actually is instantaneous data, then it seem like hour 21
(from my 6 hour forecast) would be just as valid as hour 12 (the default),
so my once-per-day data would be good enough.
But if the coupler or the ocean makes an assumption that it is hour 12 data,
that would introduce a bias that I probably don't want.

If it actually writes out averaged data, the 6 hour forecast forcing will
definitely be biased compared to the 24 hour forecast.

from cesm.

I'm pretty sure that documentation is wrong, and that histaux_r2x is actually 24-hour-average fields.

from cesm.

@klindsay28 confirmed that it writes average files from the forecast:
24-hour if the forecast is that long or longer, or only the length of the
forecast, if less than 24 hours. So I'll need/want some sort of fix
before using histaux_r2x in a data assimilation context.

If a file is written at the end of every forecast, I can average them once/day.
That looks much easier than making the restart of histaux_r2x files work
correctly (@billsacks thinks this is broken). The file names would need to
have SSSSS added to the date stamp YYYY-MM-DD.

from cesm.

@billsacks wrote

One possible fix would be to write these files every 6 hours rather than every 24 hours. I'm not sure what implications that would have.

I tested replacing
write_now=t24hr_alarm
with
write_now=t6hr_alarm
in the
src.drv/cime_comp_mod.F90 call to seq_hist_writeaux(...'r2x'...).
It wrote a file every 6 hours, as hoped.
I had to change the file names to include seconds.
So what seems to be needed here is a way to set
write_now = min(forecast_length,24_hours).
It might take me a lot of digging to figure out how to access
the forecast length in this module, so I'm hoping that someone
can at least point me to the right variable(s) and mechanism
for importing them.

I don't have permission to assign this issue to anyone,
or give it labels, so it would be great if someone would do that.

Should I open a new issue about the frequency of r2x history writes?

In CIME or ESCOMP?

Does this look possible by the CESM2_1 tag/release?

Thanks,
Kevin

from cesm.

@kdraeder what you're asking for feels like it warrants a CIME issue. I can't address whether this is feasible for CESM2.1, but maybe @mvertens or @jedwards4b could.

from cesm.

I opened CIME #2831 and provided a fix in CIME #2832.
The hr2x files are now written at time-of-day = 00000
and at the end of the forecast, no matter what time it is.
The averaging is over whatever time span is in each file;
1 day for all but the last (partial) day, and the partial day
for the last file (which could be 24 h).

from cesm.

Thanks, @kdraeder . I've lost track of what remains in this issue; can this escomp/cesm issue be closed now?

from cesm.

There's still inconsistency between the filetype of the
cpl.hr2x filenames and the contents, which are averaged.
But my understanding is that that will be resolved later
in a way that's least disruptive to users.
Other than that, the problems I ran into have been resolved.
Thanks for all the help!

from cesm.