-
Notifications
You must be signed in to change notification settings - Fork 32
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
branch_time_in_child #465
Comments
Just sharing what we're doing at CCCma since I happened upon this issue. Your understanding of what
|
@ashao The global attributes are defined in https://goo.gl/v1drZl . branch_time_in_parent and branch_time_in_child are both double precision scalars (not text strings like "1850-01-01"). They must be interpreted using parent_time_units and the units attribute attached to the time coordinate in the file (which applies to the "child"), and the "calendar" attribute. Assuming that your time units are defined to be the first time-sample of a run (which is not a requirement) and assuming your calendar is "no-leap" (for simplicity here), you should have: Please let me know if somehow we could make these terms clearer. |
One further clarification concerning the "base time" (i.e., time units). It is stated in goo.gl/neswPr under point 14 that
Please see that document for further guidance. |
Sorry I was going off of memory since I wasn't on the CCCma network at the time. As you clarified this is exactly how are doing it at CCCma where our base unit is always referenced to 1850-01-01 for all experiments. Here's a snippet from our netCDF metadata
|
Thanks. Seems o.k. |
The suggestion above is: An idea for the future could be that CMOR checks whether the first time value of the variable is lower than branch_time_in_child. This should be impossible and raise an error according to 1. Not sure when this will become high enough priority to actually implement. Maybe we shouldn't bother? |
@taylor13 these could be labelled with an aspirational future release, say 4.0/Future just so they are not lost, however are not prioritized for immediate action. I just created such a milestone (see https://github.com/PCMDI/cmor/milestones?with_issues=no) and have labelled this issue under this milestone |
@taylor13 what about cases where you spin off some run from a control run and start say an |
The time in the control run is "branch_time_in_parent". What we're talking about here is "branch_time_in_child" which should be the beginning of the run and precede every time sample produced by the run. |
@jimchenyang just correct guidance can be provided, can you actually articulate a question for the #465 (comment). I would also direct you to look at the descriptive guidance contained in the google doc CMIP6 Global Attributes, DRS, Filenames, Directory Structure, and CV’s the second page lists descriptions for |
Hi,
I have two questions related to attribute
branch_time_in_child
.branch_time_in_child
by taking the branch time from the parent and converting it with the time units from the child. That is not correct, is it?branch_time_in_child
is actually the first time value of the child's simulation, isn't it?branch_time_in_child
. This should be impossible and raise an error according to 1.Best regards,
Fabi
The text was updated successfully, but these errors were encountered: