Array Format (Native / Original)
This document describes some of the native data formats present in AMOC datasets provided by different observing arrays.
In the logic of amocarray, we will first convert to an OceanSITES compatible format. Documentation is outlined in the OceanSITES format.
Note: This is a work in progress and not all arrays are fully described. The goal is to provide a summary of the data formats and how they could be transformed into a common format. The common format is not yet defined but will ideally be able to capture most if not all of the original data.
Table of Contents
OSNAP Original Data Format
The OSNAP array provides multiple observational data products including time series of overturning and heat/freshwater transport, streamfunctions in density space, and gridded fields of velocity, temperature, and salinity.
At OSNAP, we have variables like MOC_ALL, MOC_EAST and MOC_WEST which are time series (TIME
), but these could be represented as MOC (N_PROF
, TIME
) where instead of the three different variables, N_PROF=3. This would be somewhat more difficult to communicate to the user, since LATITUDE and LONGITUDE are not single points per N_PROF but instead may represent end points of a section.
Variables MOC_ALL_ERR are also provided, which could be translated to MOC_ERR (N_PROF
, TIME
) with LATITUDE (N_PROF
) or LATITUDE_BOUND (N_PROF
, 2).
Heat fluxes also exist, as MHT_ALL, MHT_EAST and MHT_WEST, so these could be MHT (N_PROF
, TIME
).
OSNAP_MOC_MHT_MFT_TimeSeries_201408_202006_2023.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(71,) |
datetime |
|
|
|
(71,) |
Sv |
|
|
|
(71,) |
Sv |
|
|
|
(71,) |
Sv |
|
|
|
(71,) |
PW |
|
|
|
(71,) |
Sv |
|
OSNAP_Streamfunction_201408_202006_2023.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(71,) |
datetime |
|
|
|
(481,) |
kg m-3 |
|
|
|
(481, 71) |
Sv |
|
|
|
(481, 71) |
Sv |
|
|
|
(481, 71) |
Sv |
|
OSNAP_Gridded_201408_202006_2023.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(71,) |
datetime |
|
|
|
(256,) |
degrees_north |
|
|
|
(256,) |
degrees_east |
|
|
|
(199,) |
m |
|
|
|
(71, 199, 256) |
m s-1 |
|
|
|
(71, 199, 256) |
degC |
|
|
|
(71, 199, 256) |
psu |
|
RAPID Original Data Format
The RAPID array at 26°N produces a range of observational and derived products:
1D time series of AMOC transport
Time series profiles of temperature, salinity, and velocity at specific locations (moorings)
Gridded sections of hydrographic and velocity fields
Layer transport estimates based on defined vertical boundaries
Streamfunction evaluations in depth or density space
moc_vertical.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(307,) |
m |
Vertical coordinate in meters |
|
|
(13779,) |
datetime |
Time coordinate, 12-hour intervals |
|
|
(307, 13779) |
Sv |
Overturning streamfunction at 26°N |
ts_gridded.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(242,) |
dbar |
Pressure coordinate |
|
|
(13779,) |
datetime |
Time coordinate, 12-hour intervals |
|
|
(242, 13779) |
°C |
Temperature west 26.52N/76.74W |
|
|
(242, 13779) |
psu |
Salinity WB3 26.50N/76.6W |
|
|
(242, 13779) |
°C |
Temperature MAR west 24.52N/50.57W |
|
|
(242, 13779) |
°C |
Temperature MAR east 24.52N/41.21W |
|
|
(242, 13779) |
°C |
Temperature east 26.99N/16.23W |
|
|
(242, 13779) |
1 |
Data quality flag for |
moc_transports.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(13779,) |
datetime |
Time coordinate, 12-hour intervals |
|
|
(13779,) |
Sv |
Thermocline recirculation 0–800 m |
|
|
(13779,) |
Sv |
Intermediate water 800–1100 m |
|
|
(13779,) |
Sv |
Upper NADW 1100–3000 m |
|
|
(13779,) |
Sv |
Lower NADW 3000–5000 m |
|
|
(13779,) |
Sv |
AABW >5000 m |
|
|
(13779,) |
Sv |
Florida Straits transport |
|
|
(13779,) |
Sv |
Ekman transport |
|
|
(13779,) |
Sv |
Upper Mid-Ocean transport |
|
|
(13779,) |
Sv |
Overturning transport MOC index |
2d_gridded.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(689,) |
datetime |
Time (10-day intervals) |
|
|
(254,) |
degrees_east |
Longitude coordinate |
|
|
(307,) |
m |
Depth coordinate |
|
|
(689, 254, 307) |
°C |
Conservative Temperature (ITS-90) |
|
|
(689, 254, 307) |
g/kg |
Absolute Salinity |
|
|
(689, 254, 307) |
m/s |
Meridional velocity |
|
|
(689, 254, 307) |
m/s |
Ekman velocity |
|
|
(689,) |
m/s |
Depth-integrated meridional velocity |
meridional_transports.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(689,) |
datetime |
Time (10-day intervals) |
|
|
(307,) |
m |
Depth coordinate |
|
|
(489,) |
kg/m³ – 1000 |
Potential density anomaly (σ₀) |
|
|
(689,) |
Sv |
Maximum overturning from depth-streamfunction |
|
|
(689,) |
Sv |
Maximum overturning from density-streamfunction |
|
|
(689,) |
PW |
Northward heat transport |
|
|
(689,) |
Sv |
Northward freshwater transport |
|
|
(307,) |
dbar |
Pressure coordinate |
|
|
(689, 307) |
Sv |
Overturning streamfunction in depth space |
|
|
(689, 489?) |
Sv |
Overturning streamfunction in density space |
MOVE Original Data Format
MOVE provides the TRANSPORT_TOTAL which corresponds to the MOC, but also things like transport_component_internal (TIME
,), transport_component_internal_offset (TIME
,), and transport_component_boundary (TIME
,). This would be similar to RAPID’s version of “interior transport” and “western boundary wedge”, but it’s not so clear how to make these similarly named.
OS_MOVE_TRANSPORTS.nc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(6756,) |
datetime |
|
|
|
(6756,) |
Sverdrup |
|
|
|
(6756,) |
Sverdrup |
|
|
|
(6756,) |
Sverdrup |
|
|
|
(6756,) |
Sverdrup |
|
SAMBA Original Data Format
Note that the longer datasets (e.g., MOC_TotalAnomaly_and_constituents.asc) is from Meinen et al. (2018) and the shorter dataset (e.g., Upper_Abyssal_Transport_Anomalies.txt) is from Kersalé et al. (2020).
Upper_Abyssal_Transport_Anomalies.txt
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(1404,) |
datetime |
|
|
|
(1404,) |
Sv |
|
|
|
(1404,) |
Sv |
|
MOC_TotalAnomaly_and_constituents.asc
Name |
Dimensions |
Shape |
Units |
Description |
---|---|---|---|---|
|
|
(2964,) |
datetime |
|
|
|
(2964,) |
Sv |
|
|
|
(2964,) |
Sv |
|
|
|
(2964,) |
Sv |
|
|
|
(2964,) |
Sv |
|
|
|
(2964,) |
Sv |
|
|
|
(2964,) |
Sv |
|
|
|
(2964,) |
Sv |
|
|
|
(2964,) |
Sv |
|
FW2015
This is a different beast but similar to RAPID in that it has components which represent transport for different segments of the array (like Gulf Stream, Ekman and upper-mid-ocean) where these sum to produce MOC. This is vaguely like OSNAP east and OSNAP west, except I don’t think those sum to produce the total overturning. And Ekman could be part of a layer transport but here is has no depth reference. Gulf Stream has longitude bounds and a single latitude (LATITUDE
, LONGITUDE_BOUND
) and limits over which the depths are represented (DEPTH_BOUND
?) but no N_LEVELS. It doesn’t quite make sense to call the dimension N_PROF since these aren’t profiles. Maybe N_COMPONENT?
Summary of FW2015 files:
~~~~~~~~~~~~~~~~~~~~~~~~~~`
- MOCproxy_for_figshare_v1.mat
TIME
: dimensionTIME
(264,), type datetime
MOC_PROXY
: dimensionTIME
, units Sv
EK
: dimensionTIME
, units Sv
GS
: dimensionTIME
, units Sv
UMO_PROXY
: dimensionTIME
, units Sv
Potential reformats: ~~~~~~~~~~~~~~~~~~~~~~~~~~`
Overturning:
MOC
: time series (dimension:TIME
)
Component transports:
Dimensions:
TIME
,N_COMPONENT
(1404, 7)Coordinates:
LATITUDE
,LONGITUDE_BOUNDS
(scalar, x2),TIME
in datetime.N_COMPONENT
for the number of components.Variables:
TRANSPORT
(TIME
,N_COMPONENT
) - This would also haveTRANSPORT_NAME
(N_COMPONENT
, string) to indicate what the component is (e.g. EK, GS, LNADW, MOC, MOC_PROXY, UMO_GRID, UMO_PROXY, UNADW_GRID, etc). Note that some of these were just copies of what the RAPID time series was at the time.
MOCHA
Summary of MOCHA files:
The heat transports at RAPID-MOCHA are provided with N_LEVELS, TIME, and variables:
Q_eddy
Q_ek
Q_fc
Q_gyre
Q_int.
Again, we have a situation where N_PROF isn’t really appropriate. Maybe N_COMPONENT? WE should double check that things called N_COMPONENT then somehow sum to produce a total? Then we would have something like MHT_COMPONENTS (N_COMPONENT
, TIME
) and MHT (TIME
)
But we also have things like:
T_basin (
TIME
,N_LEVELS
)T_basin_mean (
N_LEVELS
)T_fc_fwt (
TIME
)V_basin (
TIME
,N_LEVELS
) –> is this identical to new RAPID velo sxn?V_basin_mean (
N_LEVELS
)V_fc (
TIME
,N_LEVELS
)
Potential reformats:
So this might be suggested as a TEMPERATURE (TIME
, N_LEVELS
) but unclear how to indicate that this is a zonal mean temperature as compared to the ones which are TEMPERATURE (N_PROF
, TIME
, N_LEVELS
) for the full sections.
Heat Transport Components:
Q_eddy, Q_ek, Q_fc, Q_gyre, Q_int → suggest
MHT_COMPONENT
(N_COMPONENT
,TIME
)Total:
MHT
(TIME
)
Additional Variables:
T_basin, V_basin, T_fc_fwt, etc.
These suggest basin-mean properties:
TEMPERATURE
(TIME
,N_LEVELS
)
Note:
N_COMPONENT
should indicate summable components if applicable