startDate non-inclusive?

[rgieseke]

Is startDate non-inclusive?

It seems output streams start at 1746 only

ag 1745 sample_outputstream_rcp26.csv.csv
sample_outputstream_rcp26.csv
38650:1781,rcp26,0,temperature,Tgaveq,-0.0174588,degC
45669:1832,rcp26,0,ocean,OmegaAr_HL,2.17454,(unitless)
47483:1845,rcp26,0,ocean,pH_LL,8.17458,pH
47622:1846,rcp26,0,ocean,pH_LL,8.17452,pH
55317:1901,rcp26,0,forcing,FO3,0.1745,W/m2
72830:2020,rcp26,0,CH4,CH4,1745.82,ppbv CH4
90921:2146,rcp26,0,ocean,pH_HL,8.11745,pH
103956:2237,rcp26,0,simpleNbox,soil_c,1745.67,Pg C
104099:2238,rcp26,0,simpleNbox,soil_c,1745.06,Pg C

even though the ini files list the startDate as 1745:

startDate=1745

[bpbond]

This is misleading, I agree. The outputstream code writes the end date of the current timestep; e.g., when we're running 1 January 1745 - 31 December 1745, what actually gets written is (as you note) "1746".

What should be written is either "1745" (the year) or "1745.5" (the mathematical midpoint).

[bpbond]

I think this is significant enough to mark it as a "bug" and put it in our next major release milestone. Thoughts @cahartin and others?

...at the very least the documentation has to make this clear. See #169

[rgieseke]

Thanks for the explanation!
So currently the temperature value for 1746 is the average value for 1745, correct?

[bpbond]

@rgieseke right. No - see comment below. It's the model state at 1/1/1746.

[rgieseke]

Does this affect all output variables or are they any that only have yearly resolution? (Happy to add a note the Output Files wiki page).

[bpbond]

This should affect everything.

[rgieseke]

Added a note there based on your comment.

[bpbond]

Thanks @rgieseke

[rplzzz]

@bpbond How do we figure that the output temperature is the average value for the preceding year? The total forcing used to calculate the temperature appears to be the "current" value, which should be the value at the end of the current time step. We do have a windowed average for the CO₂ forcing, but my understanding is that that is meant to represent a real lag between forcing and temperature, not an adjustment for the discrete output step. The size of the window is 10 years in any case, which seems to large to be a reasonable discreteness adjustment.

So, unless I'm missing something (entirely possible), the output values are the state of the ODE system at runToDate, and they are output with a time coordinate of runToDate, which to my thinking makes the current behavior correct, if a little counterintuitive.

[bpbond]

Yup, no, you're right @rplzzz - sorry, that shows the perils of trying to think about something while on an unrelated conference call...

I agree: the current behavior is correct. "1746" in the output stream denotes the model state at 1/1/1746, not (as I said above) the midpoint of the previous year. Sorry about that @rgieseke .

To my mind then two things need to change: the documentation must be clear about this, and it would be good to print out the 1745 state, i.e. post-spinup, pre-run. This could happen by an extra call to the visitors I think.

[rgieseke]

Ok, then the comment on https://github.com/JGCRI/hector/wiki/OutputFiles needs to be updated. Can you do that?

Then, which value do you use to compare with historical data, e.g. HadCRUT?

[bpbond]

Yes, I'll change that.

What do you mean about historical data? HadCRUT is included in the repo (input/constraints/tgav_historical.csv) as a potential temperature constraint, but that's a convenience. The model doesn't require it.

[rgieseke]

The HadCRUT file has yearly averages. When you compare them with the "point" value of Hector output do you change/average (mid-point) the Hector output in any way? Or is it just Hector[1746] compared with HadCRUT[1746]? (edited)

[rplzzz]

We don't do any time averaging of the outputs.

[rgieseke]

For what it's worth, the paper states:

2.4 Time step, spinup, and constraints
The model’s fundamental time step is 1 year, although the
carbon cycle can operate on a finer resolution when neces-
sary (Sect. 3.1). When the model is on an integer date (e.g.,
1997.0) it is considered to be the midpoint of that particular
calendar year, in accordance with Representative Concentra-
tion Pathway (RCP) data (Meinshausen et al., 2011b).

I might not use the right terms, but I can't find references to the "dates" in the RCPs in http://dx.doi.org/10.1007/s10584-011-0156-z

In any case, this would mean that the startDate is non-inclusive?

[rplzzz]

startDate is the initial value of the simulation time coordinate t. Currently the initial state of the simulation isn't printed into the output (though you can technically find it in the final spin-up time step), but it probably should be, as that would be an easy fix.

[bpbond]

This has obviously been a source of confusion for some time. I think the cleanest solution what we discussed above: have the model output the initial state (as 1745, e.g.); treat the time value as a coordinate, per @rplzzz 's comment; and make this clear in the documentation.