Skip to content
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

Open
wachsylon opened this issue Apr 3, 2019 · 10 comments
Open

branch_time_in_child #465

wachsylon opened this issue Apr 3, 2019 · 10 comments
Milestone

Comments

@wachsylon
Copy link
Collaborator

Hi,
I have two questions related to attribute branch_time_in_child.

  1. First, I thought I can get the 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?
  2. 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.

Best regards,
Fabi

@ashao
Copy link

ashao commented Apr 10, 2019

Just sharing what we're doing at CCCma since I happened upon this issue. Your understanding of what branch_time_in_child is exactly ours as well. For example, the pre-industrial control experiment using CanESM5 starts in 5201. Say we launched a historical experiment (which begins in 1850) off of year 5250 of the PI control. The resulting labels for that historical experiment would be:

  • branch_time_in_child would be 1850-01-01
  • branch_time_in_parent would be 5250-01-01

@taylor13
Copy link
Collaborator

@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:
parent_time_units = "days since 5201-01-01"
branch_time_in_parent = 1.7885D04 # =49 years*365 days/year after the beginning of the run
branch_time_in_child = 0.0D00
and the time "units" attribute = "days since 1850-01-01"
and a calendar attribute (attached to the time coordinate) = "noleap"

Please let me know if somehow we could make these terms clearer.

@taylor13
Copy link
Collaborator

One further clarification concerning the "base time" (i.e., time units). It is stated in goo.gl/neswPr under point 14 that

d. For simulations not tied to a particular date, the ‘base time’ is arbitrary, but it should 
correspond to the beginning of the run.  Thus, in these simulations, ‘base time’ is 
whatever time one decides to assign to the beginning of the run.

e. All values of the time coordinate should be positive and monotonically increasing, 
which will be ensured by observing the above rules.

Please see that document for further guidance.

@ashao
Copy link

ashao commented Apr 11, 2019

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

parent_time_units = "days since 1850-01-01 0:0:0.0"
branch_time_in_child = 0.
branch_time_in_parent = 1223115.

@taylor13
Copy link
Collaborator

Thanks. Seems o.k.

@taylor13
Copy link
Collaborator

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?

@durack1 durack1 added this to the 4.0/Future milestone May 14, 2019
@durack1
Copy link
Contributor

durack1 commented May 14, 2019

@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

@doutriaux1
Copy link
Collaborator

@taylor13 what about cases where you spin off some run from a control run and start say an amip run? The control run time probably doesn't matter and could be off no?

@taylor13
Copy link
Collaborator

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.

@durack1
Copy link
Contributor

durack1 commented Nov 4, 2021

@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 branch_method, branch_time_in_child and branch_time_in_parent with notes at the end of the doc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants