USER REQUEST: density variable has two meanings the GDAC

[Acolohan]

From: 'Travis Miles' Date: Thu, Jun 22, 2023 at 4:47 PM Subject: density variable has two meanings the Glider DAC To: _NOS Glider DAC Support@noaa.gov [glider.dac.support@noaa.gov](mailto:glider.dac.support@noaa.gov)

We came across a data variable issue in the glider DAC that seems ubiquitous at a first glance. We noticed that all the SeaGliders have the variable “density” with “Sea water potential density” in the metadata, while Slocum and Spray gliders seem to have the “density” variable with “Sea Water Density” in metadata, which actually represent “in-situ density”

So in the DAC the variable “density” is being used for both “potential” and “in-situ” density. I think “potential” density should be a separate variable just like we have “potential_temperature” as a separate variable from “temperature.”

I don’t think it matters for any model data assimilation issues as temperature/salinity are assimilated not density, but for people using the data for validation/inter-comparison or science we probably need to be consistent across platforms. I believe the issue is that default data out of the SeaGlider base station is potential density, while Slocum and Spray are doing in situ density post-processing.

Thanks, happy to discuss further.

Travis Miles, Ph.D.

[kerfoot]

In my opinion, this is a data provider issue, not a DAC issue. It's also is a great example of why the application of correct metadata standards are fundamentally important to the exchange of data across platforms. Here's why:

• By design, the DAC NetCDF specification is extremely flexible. Other than few CF metadata standards, the format was designed to be approachable in order to attract as many data providers as possible. Aside from the variables listed below, the DAC specification intentionally does not enforce any variable naming convention via a controlled vocabulary, such as the OceanGliders Parameter Usage Vocabulary. This decision was made to provide the maximum amount of flexibility for our data providers.

• The DAC NetCDF specification only requires 7 variables to be included. The inclusion of these variables is required as they are fundamental to the proper serving of the data set by ERDDAP. The following variables are required to be included in submitted files:

  1. trajectory
  2. profile_time
  3. profile_lat
  4. profile_lon
  5. time
  6. lat
  7. lon

  Theoretically, a data provider could submit files containing only the variables listed above and the files would be considered valid with respect to serving via ERDDAP.

• A fundamental service of the DAC is to provide T/S measurements that are ultimately released to the GTS, making them available for model assimilation. As such, we would strongly recommend that the following variables are also included, however they are not required:

  1. pressure
  2. depth
  3. temperature
  4. conductivity
  5. salinity
  6. density

  Descriptions of the variables are provided through the use of a variety of controlled vocabularies, primarily CF standard names and UDUNITS2. The use of community accepted controlled vocabularies allows computer programs to properly interpret variable descriptions and convert from one set of units to another.

• CF conventions are a minimal set of NetCDF conventions that define a few attributes that must be included in order for a NetCDF files to be considered compliant. The creator of the NetCDF files is allowed the freedom to add any additional attribute to the file or a variables as they see fit. But it's entirely up to the user and these additional attributes are not used by a computer to determine what quantity a variable actually holds. For the purposes of this ticket, the 2 attributes that we are concerned with are:

  1. standard_name
  2. units

Assuming we agree on the above, let's take the density variable as an example:

1. The cf standard name database provides 3 possible standard names for a variable containing density measured in sea water. The following are the standard names and the definitions provided by the CF manual:

   • sea_water_density: Sea water density is the in-situ density (not the potential density). If 1000 kg m-3 is subtracted, the standard name sea_water_sigma_t should be chosen instead.
   • sea_water_neutral_density: Neutral density is a variable designed so that a surface of constant neutral density everywhere has a local slope that is close to the local slope of the neutral tangent plane. At the sea surface in the equatorial Pacific neutral density is very close to the potential density anomaly. At other locations, this is not the case. For example, along a neutral density surface there is a difference of up to 0.14 kg/m^3 in the potential density anomaly at the outcrops in the Southern and Northern hemispheres.
   • sea_water_potential_density: sea water potential density is the density a parcel of sea water would have if moved adiabatically to a reference pressure, by default assumed to be sea level pressure. To specify the reference pressure to which the quantity applies, provide a scalar coordinate variable with standard name reference_pressure. The density of a substance is its mass per unit volume. For sea water potential density, if 1000 kg m-3 is subtracted, the standard name sea_water_sigma_theta should be chosen instead.

   For the purposes of this discussion, we are only concerned with sea_water_density and sea_water_potential_density.

2. Regardless of which standard name is chosen, the canonical units of density are kg m-3, however there may be other units that are allowed as long as they are accepted values in the UDUNITS2 database.

3. The equation for calculating density can be found in the well known and widely used Gibbs Sea-Water Oceanographic Toolbox and is called gsw_rho. The difference between calculating sea_water_density and sea_water_potential_density is to pass the reference pressure (p_ref) in order to calculate sea_water_potential_density. They are fundamentally 2 different parameters.

So, regardless of whether these 2 parameters are included as 2 different variables (i.e.: density and potential_density) or only one of the parameters is included as the density variable, it is incumbent upon the data provider to include the correct standard name as a user of this data set has no other way to determine which parameter is actually calculated:

density:standard_name  = "sea_water_density"
density:units = "kg m-3"

or:

density:standard_name = "sea_water_potential_density"
density:reference_pressure = "REFERENCE PRESSURE"
density:units = "kg m-3"

or:

density:standard_name  = "sea_water_density"
density:units = "kg m-3"
...
potential_density:standard_name = "sea_water_potential_density"
potential_density:reference_pressure = "REFERENCE PRESSURE"
potential_density:units = "kg m-3"

The only way the DAC would be able to address this issue on a system level would be:

1. Determine whether the necessary measured precursor parameters are available in each file submitted by the data provider.
2. Calculate the intermediate inputs for gsw_rho
3. Write (potentially clobbering existing data provider file variables) to the file.

Since the seaglider data sets in question (example) have included:

density:comment = "Sea water potential density"
density:standard_name = "sea_water_density"

I am assuming the calculated parameter is actually potential density, not density. So the standard_name is incorrect. We (@kerfoot ) can contact the data providers and ask them to include the correct standard name of sea_water_potential_density.

Definitely open to discussing this further, but my inclination is to have this discussion with Dr. Miles, contact the seaglider data providers, and then close as #wontfix.

[Acolohan]

@kerfoot Go for it!

[kerfoot]

Per personal conversation with Dr. Travis Miles:

Thanks, I think I agree with your post and strategy of notifying users. Do we have a sense of whether this is all Seaglider users, 
or just some data providers? Not sure where/who has the most impact to communicate the error in names to or where/what 
group would be the best to market the information to. Happy to discuss, maybe Dan Hayes is worth notifying or just putting it 
out as a bulletin in the UG2 Slack? Happy to help however I can.

The take home message is that this is a metadata issue that should be addressed by the data providers and/or glider operators.

I will follow up with Dan Hayes at CyprusSubsea to inquire about proper standard names.

closing.