-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
startDate non-inclusive? #177
Comments
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). |
Thanks for the explanation! |
@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). |
This should affect everything. |
Added a note there based on your comment. |
Thanks @rgieseke |
@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 CO2 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 |
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. |
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? |
Yes, I'll change that. What do you mean about historical data? HadCRUT is included in the repo ( |
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) |
Hector 1.x reports years in outputs as end of simulation year. 1745-12-31 = 1746.0 See JGCRI/hector#177
We don't do any time averaging of the outputs. |
For what it's worth, the paper states:
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? |
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. |
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. |
Is
startDate
non-inclusive?It seems output streams start at 1746 only
even though the ini files list the
startDate
as 1745:The text was updated successfully, but these errors were encountered: