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
author = {Russell, Rew and Hartnett, Edward and Caron, John},
12
-
year = {2006},
13
-
month = {01},
14
-
organization = {Conference: 22nd International Conference on Interactive Information Processing Systems for Meteorology, Oceanography, and Hydrology},
15
-
title = {NetCDF-4: Software Implementing an Enhanced Data Model for the Geosciences}
16
-
}
17
-
18
-
@article{Rew90,
19
-
author={Rew, R. and Davis, G.},
20
-
journal={IEEE Computer Graphics and Applications},
21
-
title={NetCDF: an interface for scientific data access},
22
-
year={1990},
23
-
volume={10},
24
-
number={4},
25
-
pages={76-82},
26
-
doi={10.1109/38.56302}
27
-
}
28
-
29
1
@manual{OGC_Zarr,
30
2
organization = "Open Geospatial Consortium",
31
3
title = "Zarr Storage Specification 2.0 Community Standard",
@@ -35,7 +7,6 @@ @manual{OGC_Zarr
35
7
url = "http://www.opengis.net/doc/CS/zarr/2.0"
36
8
}
37
9
38
-
39
10
@article{Barth2022,
40
11
author = {A. Barth and A. Alvera-Azc{\'{a}}rate and C. Troupin and J.-M. Beckers},
41
12
title = {{DINCAE} 2.0: multivariate convolutional neural network with error estimates to reconstruct sea surface temperature satellite and altimetry observations},
@@ -45,29 +16,6 @@ @article{Barth2022
45
16
doi = {10.5194/gmd-2021-353},
46
17
}
47
18
48
-
@article{Doglioni2023,
49
-
AUTHOR = {Doglioni, F. and Ricker, R. and Rabe, B. and Barth, A. and Troupin, C. and Kanzow, T.},
50
-
TITLE = {Sea surface height anomaly and geostrophic current velocity from altimetry measurements over the Arctic Ocean (2011--2020)},
51
-
JOURNAL = {Earth System Science Data},
52
-
VOLUME = {15},
53
-
YEAR = {2023},
54
-
NUMBER = {1},
55
-
PAGES = {225--263},
56
-
DOI = {10.5194/essd-15-225-2023}
57
-
}
58
-
59
-
@article{Belgacem21,
60
-
AUTHOR = {Belgacem, M. and Schroeder, K. and Barth, A. and Troupin, C. and Pavoni, B. and Raimbault, P. and Garcia, N. and Borghini, M. and Chiggiato, J.},
61
-
TITLE = {Climatological distribution of dissolved inorganic nutrients in the western Mediterranean Sea (1981--2017)},
author = {Ali Ramadhan and Gregory LeClaire Wagner and Chris Hill and Jean-Michel Campin and Valentin Churavy and Tim Besard and Andre Souza and Alan Edelman and Raffaele Ferrari and John Marshall},
73
21
title = {{Oceananigans.jl: Fast and friendly geophysical fluid dynamics on GPUs}},
@@ -81,18 +29,6 @@ @article{OceananigansJOSS
81
29
url = {https://doi.org/10.21105/joss.02018}
82
30
}
83
31
84
-
@ARTICLE{Shahzadi21,
85
-
AUTHOR={Shahzadi, K. and Pinardi, N. and Barth, A. and Troupin, C. and Lyubartsev, V. and Simoncelli, S.},
author = {Brian Eaton and Jonathan Gregory and Bob Drach and Karl Taylor and Steve Hankin and Jon Blower and John Caron and Rich Signell and Phil Bentley and Greg Rappa and Heinke Höck and Alison Pamment and Martin Juckes and Martin Raspaud and Randy Horne and Timothy Whiteaker and David Blodgett and Charlie Zender and Daniel Lee and David Hassell and Alan D. Snow and Tobias Kölling and Dave Allured and Aleksandar Jelenak and Anders Meier Soerensen and Lucile Gaultier and Sylvain Herlédan and Fernando Manzano and Lars Bärring and Christopher Barker and Sadie Bartholomew},
109
-
title = {{NetCDF Climate and Forecast (CF) Metadata Conventions v1.11}},
AUTHOR = {Hassell, D. and Gregory, J. and Blower, J. and Lawrence, B. N. and Taylor, K. E.},
@@ -153,14 +120,13 @@ @article{Hassell2017
153
120
154
121
155
122
@techreport{SeaDataNet_format,
156
-
title = "SeaDataNet. Datafile formats. ODV, MEDATLAS, NETCDF",
157
-
type = "Report",
158
-
url = "https://doi.org/10.13155/56547",
159
-
doi = "10.13155/56547",
160
-
author = "Lowry, Roy AND Fichaut, Michele AND Schlitzer, Reiner AND Maudire, Gilbert AND Bregent, Sophie AND Gatti, Julie",
161
-
year = "2024",
162
-
editor = "SeaDataNet",
163
-
abstract = "This document specify the data file format in used for data exchange in SeaDataNet. ODV (Ocean Data View) and NetCDF format are mandatory, whereas MEDATLAS is optional. This document describes the following versions of the SeaDataNet formats SeaDataNet ODV import format 0.4 SeaDataNet MEDATLAS format 2.0 SeaDataNet CFPOINT (CF NetCDF)1.0"
123
+
title = "SeaDataNet. Datafile formats. ODV, MEDATLAS, NETCDF",
124
+
type = "Report",
125
+
url = "https://doi.org/10.13155/56547",
126
+
doi = "10.13155/56547",
127
+
author = "Lowry, Roy AND Fichaut, Michele AND Schlitzer, Reiner AND Maudire, Gilbert AND Bregent, Sophie AND Gatti, Julie",
AUTHOR = {van Verseveld, W. J. and Weerts, A. H. and Visser, M. and Buitink, J. and Imhoff, R. O. and Boisgontier, H. and Bouaziz, L. and Eilander, D. and Hegnauer, M. and ten Velden, C. and Russell, B.},
179
-
TITLE = {Wflow\_sbm v0.7.3, a spatially distributed hydrological model: from global data to local applications},
AUTHOR = {van Verseveld, W. J. and Weerts, A. H. and Visser, M. and Buitink, J. and Imhoff, R. O. and Boisgontier, H. and Bouaziz, L. and Eilander, D. and Hegnauer, M. and ten Velden, C. and Russell, B.},
145
+
TITLE = {Wflow\_sbm v0.7.3, a spatially distributed hydrological model: from global data to local applications},
Copy file name to clipboardExpand all lines: paper/paper.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,7 +22,7 @@ bibliography: paper.bib
22
22
# Summary
23
23
24
24
25
-
Climate and Forecasting (CF) conventions are a metadata standard for earth data [@Eaton2023] and are mainly used in oceanography and meteorology.
25
+
Climate and Forecasting (CF) conventions are a metadata standard for earth data [@Eaton2024] and are mainly used in oceanography and meteorology.
26
26
It aims to be equally applicable to model data, remote-sensing data and in-situ data, despite the high heterogeneity of the different data types.
27
27
The CF conventions were originally proposed for the NetCDF storage format, but they are also increasingly used with other formats like Zarr [@OGC_Zarr] and grib ([GRIBDatasets](https://github.com/JuliaGeo/GRIBDatasets.jl)).
28
28
@@ -67,11 +67,11 @@ Different calendars have been defined in the context of the CF conventions:
67
67
|`360_day`|`DateTime360Day`| calendar assuming that all months have 30 days |
68
68
69
69
70
-
The Gregorian calendar has been introduced to account for the fact that a solar year is not exactly 365.25 days, but more closely approximating 365.2422 days. In the standard calendar, the day Thursday, 4 October 1582 (the last day of the Julian calendar) is followed by the first day of the Gregorian calendar, Friday, 15 October 1582 (the date of introduction of the Gregorian calendar).
70
+
The Gregorian calendar has been introduced to account for the fact that a solar year is not exactly 365.25 days, but more closely approximating 365.2422 days. In the standard calendar, the day Thursday, 4 October 1582 (the last day of the Julian calendar) is followed by the first day of the Gregorian calendar, Friday, 15 October 1582 (the date of introduction of the Gregorian calendar).
71
71
72
72
CFTime is based on the Meeus' algorithm [@Meeus98] for the Gregorian and Julian calendars, with two adaptations:
73
73
74
-
* The original algorithm is based on floating-point arithmetic. The algorithm in CFTime is implemented using integer arithmetics, which is more efficient. Also, underflows and overflows are easier to reason about in integer arithmetic.
74
+
* The original algorithm is based on floating-point arithmetic. The algorithm in CFTime is implemented using integer arithmetics, which is more efficient. Also, underflows and overflows are easier to reason about in integer arithmetic.
75
75
* The Meeus' algorithm has been extended to dates prior to 100 BC.
76
76
77
77
The Meeus' algorithm is very compact, efficient, requires only very few branches, and does not need large tables of constants. For verification purposes, the
@@ -80,8 +80,8 @@ algorithm used in the cftime python package [@Whitaker2024] was ported to Julia,
80
80
The following is a list of the main features of CFTime:
81
81
82
82
* Basic arithmetic such as computing the duration between two time instances by subtracting them, or adding a duration to a time instance
83
-
* Supporting a wide range of the time resolutions, from days down to attoseconds. Even if the use of attoseconds is quite unlikely in the context of earth science data, it has been added for feature parity with NumPy's date time type [@numpy].
84
-
* Supporting arbitrary time origins. Since the time origin for NumPy's date time type is fixed to be 1 January 1970 at 00:00, the usefulness of some time units is limited. As an extreme example, with attoseconds, all NumPy's date times can only express a time span of +/- 9.2 s around the time origin since a 64-bit integer is used internally. For CFTime.jl the time origin is arbitrary and part of the parametric type definition and not an additional field of the time data structure. As a consequence, a large array of date times with common time origin only need to store the time counter (also a 64-bit integer per default) for every element, which makes this case as memory efficient as NumPy's or Julia's default date time for this common use case.
83
+
* Supporting a wide range of the time resolutions, from days down to attoseconds. Even if the use of attoseconds is quite unlikely in the context of earth science data, it has been added for feature parity with NumPy's date time type [@harris2020array; @numpy].
84
+
* Supporting arbitrary time origins. Since the time origin for NumPy's date time type is fixed to be 1 January 1970 at 00:00, the usefulness of some time units is limited. As an extreme example, with attoseconds, all NumPy's date times can only express a time span of +/- 9.2 s around the time origin since a 64-bit integer is used internally. For CFTime.jl the time origin is arbitrary and part of the parametric type definition and not an additional field of the time data structure. As a consequence, a large array of date times with common time origin only need to store the time counter (also a 64-bit integer per default) for every element, which makes this case as memory efficient as NumPy's or Julia's default date time for this common use case.
85
85
86
86
* Per default, the time counter is a 64-bit integer, but other integers types (such as 32-bit, 128-bit or Julia's arbitrary-sized integer `BigInt`) or floating-point types can be used. Using an integer to encode a time instance should be preferred for most applications, as it is easier to reason about the time resolution in this case. Julia's compiler specializes all functions and methods for the employed types for optimal run-time performance.
87
87
* Conversion function between types and Julia's `DateTime`.
0 commit comments