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-2030
2041: 2031-2040
2051: 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