salinity "unit" is listed as `1e-3` in utils.py

[richardsc]

pyglider/pyglider/utils.py

Line 350 in c1218ac

('units', '1e-3'),

I know salinity units are a touchy subject, but working with some files processed through our pyglider pipeline recently I noticed that the units attribute for the sea_water_practical_salinity field is hard coded in utils.py to be "1e-3", which isn't correct.

As for what to change it to, I'd suggest either blank (i.e. '' or ' '), or something else to indicate a unitless quantity. Looking at the OG1.0 vocabulary they seem to recommend using "Dimensionless".

[jklymak]

Yeah im not sure where that came from. I think VOTO?

I liked psu in the olden days because it is clear where it came from and should be clear what the limitations are. I think we should see what the standard is here for teos10 and how to indicate that the salinity has been calculated without the location correction (which is the case here if I understand the code correctly)

[richardsc]

The TEOS10 standard for Practical Salinity (SP) is that it is unitless, though I don't know that there's an agreed-upon way to indicate that in a units field. See:

https://www.teos-10.org/pubs/gsw/html/gsw_SP_from_C.html

where the Matlab code uses "[ unitless ]" to indicate it.

As for the lack of location correction, that is implied by the fact that the field name is practical salinity (rather than "absolute salinity" or SA). Note that SP is the variable that should be archived, as SA is derived from it (and could be different depending on which version of GSW/TEOS10 is used).

[jklymak]

OK, agreed this is practical salinity - I should have looked more closely at the code.

I'm a little unclear if we should be serving "reference" salinity or "practical".

CF conventions want "1" here. I actually think this should be "PSU", but I guess I wasn't invited to that meeting.

[jklymak]

Hmm, even more fun, we then calculate absolute salinity using the location correction, but do not serve it, and then calculate potential density referenced to the surface from SA. That seems inconsistent. I wonder if we ask @lauryntalbot to take a look and see how different SA is from SP and if the potential density calc ends up very different?

[lauryntalbot]

We've been calculating potential density using AS with the location correction - I took the code from utils. Once the thermal lag correction is applied, we've also been adding "potential_denisty_adjusted"

[jklymak]

I think we have decided that this is the right things to serve:

salinity: is practical salinity with units of "1", which I sort of dislike, but...
Temperature: is in-situ temperature
potential_density: which is calculated from absolute salinity and conservative temperature, where absolute salinity has the geographic correction.

@lauryntalbot checked and potential density calculated this way is very close to the EOS-80 potential density. It seems a bit funny to me to calculate potential density from a salinity we do not serve, but users can easily calculate absolute salinity and conservative temperature from the variables given, and the potential density is very close to the historic.

I think we should update the attributes to make it clear what we are doing here though.

[richardsc]

I agree it does seem weird to serve a potential density that was calculated using fields that aren't actually stored in the object, but as you point out its easy to calculate both SA and CT, or alternatively to calculate the EOS-80 version of potential density using SP and in-situ T.

Googling about CF names I found this:

Units are not required for dimensionless quantities. A variable with no units attribute is assumed to be dimensionless. However, a units attribute specifying a dimensionless unit may optionally be included. The Udunits package defines a few dimensionless units, such as percent, but is lacking commonly used units such as ppm (parts per million). This convention does not support the addition of new dimensionless units that are not udunits compatible. The conforming unit for quantities that represent fractions, or parts of a whole, is "1". The conforming unit for parts per million is "1e-6". Descriptive information about dimensionless quantities, such as sea-ice concentration, cloud fraction, probability, etc., should be given in the long_name or standard_name attributes (see below) rather than the units.

though I disagree that practical salinity represents a fraction so "1" maybe isn't appropriate either. Based on the above, I can see where the original 1e-3 came from, because salinity has in the past been defined as ppt (which is not actually equivalent to practical salinity). Seems like the recommendation is to either leave it blank or just not include a units attribute.

I wonder what other glider DACs have decided?

[jklymak]

Argo:

	float psal(n_prof, n_levels) ;
		psal:long_name = "Practical salinity" ;
		psal:standard_name = "sea_water_salinity" ;
		psal:units = "psu" ;
		psal:valid_min = 2.f ;
		psal:valid_max = 41.f ;
		psal:C_format = "%10.4f" ;
		psal:FORTRAN_format = "F10.4" ;
		psal:resolution = 0.0002f ;
		psal:_FillValue = 99999.f ;

IOOS GDAC:

Float32 salinity {
UInt32 _ChunkSizes 48; loat32 _FillValue 9.96921e+36;
Float32 actual_range 31.4059, 33.20824;
String ancillary_variables "instrument_ctd qartod_salinity_flat_line_flag qartod_salinity_gross_range_flag qartod_salinity_rate_of_change_flag qartod_salinity_spike_flag qartod_salinity_primary_flag";
Float64 colorBarMaximum 37.0;
Float64 colorBarMinimum 30.0;
String instrument "instrument_ctd";
String ioos_category "Salinity";
String long_name "Sea Water Practical Salinity";
String observation_type "calculated";
Int32 processing_level 2;
String standard_name "sea_water_practical_salinity";
String units "1";
Float32 valia_max 0.0;
Float32 valia_min 40.0;
}

OG 2.0 format examples here: https://github.com/OceanGlidersCommunity/OG-format-user-manual/tree/main/og_format_examples_files use everything: "1", "psu", and "1e-3". So I'm not sure what use that is!

So it's the Wild West for this. I'd personally prefer we followed Argo and used "psu". If I'm publishing this I'd put S (psu) in the label. However, I appreciate some feel that is very wrong.