You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This range calculation is not straight forward as we do not only specify the first and last year, and the step of the output, but we also specify the major_first_digit, so in which precise year we are storing a range. That means our first output file can have a different time range as the following ones. For example:
In the case above the following files labelled with the year key should cover the values time spans:
2031: 2023-20302041: 2031-20402051: 2041-2050
It does something similar if the stepping exceeds the last bound.
I am wondering... is this extra complicated logic really necessary? --> ask Christopher
Limitations:
The way it is coded limits us to year ranges, we cannot specify monthly ranges for the output files, which might be a problem for the future high resolution simulations (we should write it first for years, but do it in a way that is easier to generalise to months)
Calculates year ranges for the output (https://github.com/FESOM/seamore/blob/7725366f7b68ea3824ac6baa500ea49531722b72/lib/cmorizer.rb#L182-L195)
This range calculation is not straight forward as we do not only specify the
first
andlast
year, and thestep
of the output, but we also specify themajor_first_digit
, so in which precise year we are storing a range. That means our first output file can have a different time range as the following ones. For example:In the case above the following files labelled with the year key should cover the values time spans:
It does something similar if the stepping exceeds the
last
bound.I am wondering... is this extra complicated logic really necessary? --> ask Christopher
Limitations:
Called by:
Calls: range_years
The text was updated successfully, but these errors were encountered: