Zeroed rad fields in instantaneous output

[merrelli@wisc_edu]

I'm doing a single day CESM1.0 model run, driving CAM5.0, with instantaneous output set for many of the radiation fields. Setting the instantaneous flag gives hourly output in the history file for the grid I chose (f19_f19). The user_nl_cam that I used is at the bottom, for reference. In the output history file h1, the radiation related fields (QRS, etc) are all zero for the second hour. The thermodynamic fields (T, Q, PS, TS) are not zeroed and contain full data at all time steps. Has anyone seen this happen before? Does this indicate just a data drop at the 2nd hour, or are the output values out of sync in some way?

Thanks in advance for any help.


user_nl_cam:

&camexp
mfilt = 24,24,24,24,24
nhtfrq = -6,-1,-1,-1,-1
fincl2 = 'T:I', 'Q:I', 'PS:I', 'TS:I', 'QRL:I', 'QRLC:I', 'QRS:I', 'QRSC:I',
'CLOUD:I', 'CLDTOT:I', 'CLDLOW:I', 'CLDMED:I', 'CLDHGH:I',
'FLDS:I', 'FLDSC:I', 'FLNS:I', 'FLNSC:I', 'FLNT:I', 'FLNTC:I', 'FLUT:I', 'FLUTC:I',
'FSDS:I', 'FSDSC:I', 'FSNS:I', 'FSNSC:I', 'FSNT:I', 'FSNTC:I', 'FSNTOA:I', 'FSNTOAC:I', 'FSUTOA:I'
/

 

[eaton]

This is kind of complicated and I can't explain exactly why things are done this way. But I can explain more or less how things are done and why you're seeing the behavior you are seeing. I've done a couple of runs using FV at 10x15 and am reporting average (over the 2D spatial field) values of the instantaneous (in time) FLDS field. For the first run the field was written every timestep (nhtfrq=1). Here are the results:

nstep  time(day)   FLDS avg (W/m2)
  0          0     2.857238561897947E+02
  1      .0208      0.0
  2      .0416      0.0
  3      .0625     2.848142196086415E+02
  4      .0833      0.0
  5      .1041     2.854824023330421E+02
  6      .1250      0.0
  7      .1458     2.849592890655785E+02
  8      .1666      0.0
  9      .1875     2.846109570118419E+02
 10      .2083      0.0
 11      .2291     2.846174894801358E+02
 12      .2500      0.0

So the first thing to notice is that the radiation calculations happen during the initialization (nstep=0), and after that just once per hour (the timestep is 1800 sec), but offset so that except for nstep=1 the results always appear at odd timesteps (or, in terms of time, on the half hour boundaries). The reason for the offset is that the radiation calculation requires information about albedos from the surface components and the time loop is set up so that the albedos are sent to the atm on the hour boundaries, and then are used by the atm to do a radiation calculation during the next timestep, the results of which are written to the output file with a time stamp of a half hour boundary.

The next run is identical except that the instantaneous field is only written once per hour (nhtfrq=2). Here are the results:

nstep  time(day)   FLDS avg (W/m2)
  0          0     2.857238561897947E+02
  2      .0416      0.0
  4      .0833     2.848142196086415E+02
  6      .1250     2.854824023330421E+02
  8      .1666     2.849592890655785E+02
 10      .2083     2.846109570118419E+02
 12      .2500     2.846174894801358E+02

This is the result you observed, i.e., that the field contains zero values at a time of 1 hour (not 2 hours). But comparing the two tables you'll see that the nstep=0 values match, and after that the values on the hour boundaries in the 2nd table match the values at the preceding half hour boundaries in the first table.

The reason this is happening is due to a subtle aspect of how the history mechanism works. All fields written to the history file are stored in a buffer. For instantaneous fields, each time the field is computed the new values are written to the buffer overwritting the previous values. Since the radiation fields are only computed every other timestep, the history buffers are only updated every other timestep. And so, for example, in the second run when the model writes the data in the buffers to disk on even timesteps (at hour boundaries), no radiation calculation was made on that timestep and the buffer was not updated, so what is being written to disk is the result from the previous timestep. That explains the half hour offset in the results produced by these two runs.

 

[merrelli@wisc_edu]

Thanks for the detailed reply. It matches what I see at my end. I'm still left with the following question:

Say I want to compare the value of FLDS at one time step with an offline radiative flux calculation that I am performing based on the values of (T,Q,albedo,etc). If I my understanding is correct, if I have a nhtfrq=1 history file, I would need to compare the value of FLDS at nstep=3, with my offline calc using (T,Q,Albedo,etc) from nstep=2.

If I have a nhtfrq=2 history file, I need to compare the value of FLDS at nstep=4 with my offline calc using (T,Q,etc) from nstep=2. In this case it would look like I need to shift the FLDS output back by one array element to get the data back "in-sync".

Is that correct? Or is albedo passed to the radiation differently from the other variables?

 

[eaton]

Most of the fields written to the history files represent a state of the model that occurs just after the convective adjustments and radiative heating tendencies have been applied. So if you have nhtfrq=1 output, probably the closest comparison will be obtained by comparing the radiative fluxes output at the half hour boundaries with the offline calculation done using the state information (T,Q,albedo,etc) also from the half hour boundaries. That state is only different from what the online radiation calculation saw due to being updated by the radiative heating before being written to the history file.

If you have nhtfrq=2 output the comparison can't be as close because the radiative fluxes output at hour boundaries were actually computed using the state near the half hour boundaries which isn't being output.

There is a new feature in the CESM1 release that allows writing the exact data to a history file that is input to the radiation code. This is enabled by setting the namelist variable rad_data_output=.true.. The history file that the data is written to is selected using the variable rad_data_histfile_num. And there is a variable rad_data_avgflag to set the averaging flag for this data.