Re: [CF-metadata] Suggestion for standard names for bottom current and due to tides and Stokes drift

[Lowry, Roy K.]

Hi John,

I touched on this issue when the sea floor temperature and practical salinity 
names were set up.  My understanding is that it does have a meaning which is 
the portion of the water column influenced by the seabed, sometimes termed the 
'benthic boundary layer'. Oceanographers I've worked with certainly of a 
conceptual understanding of this, but what it means in terms of a quantitative 
definition varies depending upon whether one is working in shelf sea, deep 
ocean or other environments.

I think I suggested adding 'benthic boundary layer' to the CF sea_floor 
Standard Name definitions, but I don't recall any reaction.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of John Graybeal 

Sent: 12 November 2019 23:07
To: Marcelo Andrioni 
Cc: CF Metadata List 
Subject: Re: [CF-metadata] Suggestion for standard names for bottom current and 
due to tides and Stokes drift

I have a question about the definitions of the *_at_sea_floor standard names, 
which state "… is that adjacent to the ocean bottom, which would be the deepest 
grid cell in an ocean model."

I understand what this means for ocean models (but suspect it has quite 
different implications for models featuring cells of smaller thickness nearer 
the boundary).

Does it mean anything for observational data? (In which case, there should be a 
corresponding definition, yes?) Or by definition, are all of these variables 
not applicable to observational data?

This question is general and should not affect this particular request, so 
conceivably it should be a new topic if the answer is not straightforward.

John


On Nov 12, 2019, at 11:59 AM, Marcelo Andrioni 
mailto:marceloandri...@gmail.com>> wrote:

Dear Jonathan, my suggestion of sea_water_from_direction_at_sea_floor
was based on the "basic" standard name:
sea_water_from_direction
The phrase "from_direction" is used in the construction
X_from_direction and indicates the direction from which the velocity
vector of X is coming. The direction is a bearing in the usual
geographical sense, measured positive clockwise from due north.

so that the only difference would be to add the suffix _at_sea_floor
like it was done with:
sea_water_potential_temperature
sea_water_potential_temperature_at_sea_floor

Thank you.

Em ter., 12 de nov. de 2019 às 16:22,
mailto:cf-metadata-requ...@cgd.ucar.edu>> 
escreveu:

Send CF-metadata mailing list submissions to
   cf-metadata@cgd.ucar.edu

To subscribe or unsubscribe via the World Wide Web, visit
   http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
or, via email, send a message with subject or body 'help' to
   cf-metadata-requ...@cgd.ucar.edu

You can reach the person managing the list at
   cf-metadata-ow...@cgd.ucar.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CF-metadata digest..."


Today's Topics:

  1. Suggestion for standard names for bottom current and due to
 tides and Stokes drift (Jonathan Gregory)
  2. Re: Suggestion for standard names for bottom current and due
 to tides and Stokes drift (Marcelo Andrioni)


--

Message: 1
Date: Mon, 11 Nov 2019 18:00:27 +
From: Jonathan Gregory 
mailto:j.m.greg...@reading.ac.uk>>
To: "cf-metadata@cgd.ucar.edu" 
mailto:cf-metadata@cgd.ucar.edu>>
Subject: [CF-metadata] Suggestion for standard names for bottom
   current and due to tides and Stokes drift
Message-ID: 
<2019180025.ga8...@met.reading.ac.uk>
Content-Type: text/plain; charset="us-ascii"

Dear Francesca and Marcelo

I think that "velocity" ought to appear in this one:
sea_water_to_direction_at_sea_floor
It's the velocity which has a direction.

Best wishes

Jonathan

- Forwarded message from Francesca Eggleton - UKRI STFC 
mailto:francesca.eggle...@stfc.ac.uk>> -

Date: Mon, 11 Nov 2019 17:29:31 +
From: Francesca Eggleton - UKRI STFC 
mailto:francesca.eggle...@stfc.ac.uk>>
To: "cf-metadata@cgd.ucar.edu" 
mailto:cf-metadata@cgd.ucar.edu>>
Subject: [CF-metadata] Suggestion for standard names for bottom current and
 due to tides and Stokes drift

Dear Marcelo,



Thank you for your proposals and apologies for the delay in responding. As you 
may have seen in Alison's last email, I will be helping out with the 
maintenance of the standard names.



Thank you to Jonathan for comments on these proposals. They all look good and 
seem to match what already exists. The two phrases which were suggested as 
aliases, I believe to be new terms and have suggested a reason why so please 
comment if you agree/disagree. The 

Re: [CF-metadata] new variable name request

[Lowry, Roy K.]

Hi Alison,

Looks good to me.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 25 September 2019 17:09
To: CF-metadata (cf-metadata@cgd.ucar.edu) 
Subject: Re: [CF-metadata] new variable name request

Dear All,

The proposed name sea_water_temperature_at_sea_floor has been added to the 
latest version of the standard name table.

As discussed, we already have a standard name for 
sea_water_salinity_at_sea_floor.

There seems to be some support for also adding 
sea_water_practical_salinity_at_sea_floor (canonical units: 1) for use with 
observational datasets. Based on existing names the definition for this would 
be as follows:
'The salinity at the sea floor is that adjacent to the ocean bottom, which 
would be the deepest grid cell in an ocean model. Practical Salinity, S_P, is a 
determination of the salinity of sea water, based on its electrical 
conductance. The measured conductance, corrected for temperature and pressure, 
is compared to the conductance of a standard potassium chloride solution, 
producing a value on the Practical Salinity Scale of 1978 (PSS-78). This name 
should not be used to describe salinity observations made before 1978, or ones 
not based on conductance measurements. Conversion of Practical Salinity to 
other precisely defined salinity measures should use the appropriate formulas 
specified by TEOS-10. Other standard names for precisely defined salinity 
quantities are sea_water_absolute_salinity (S_A); sea_water_preformed_salinity 
(S_*), sea_water_reference_salinity (S_R); sea_water_cox_salinity (S_C), used 
for salinity observations between 1967 and 1977; and sea_water_knudsen_salinity 
(
 S_K), used for salinity observations between 1901 and 1966. Salinity 
quantities that do not match any of the precise definitions should be given the 
more general standard name of sea_water_salinity. Reference: 
www.teos-10.org<http://www.teos-10.org>; Lewis, 1980 
doi:10.1109/JOE.1980.1145448.'

Is this okay? If so, it can be added in the October standard names update.

Best wishes,
Alison

---
Alison Pamment   
Tel: +44 1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: 
mailto:alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 12 September 2019 19:59
To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: Re: [CF-metadata] new variable name request

PS I was already totally happy with adding sea_water_temperature_at_sea_floor

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of Nan Galbraith
Sent: 12 September 2019 17:13
To: mailto:cf-metadata@cgd.ucar.edu
Cc: OceanSITES Data Management Team
Subject: Re: [CF-metadata] new variable name request
Hi all -

I'd like to second (or third ... ) the request for new standard names for
sea_water_practical_salinity_at_sea_floor and
sea_water_temperature_at_sea_floor.

In the OceanSITES project, we deploy CTDs on mooring anchors, and it
would be good
to be able to find these records, among all the water temperature and
practical salinity
data sets on our servers. We supply a measurement depth, but it isn't
useful for this
search, since the water depth isn't mandatory in our format spec.

These records are not exactly on the sea floor, but within a few meters;
do we need to
apply some limit to the distance? I'm thinking about the various
sea_surface_temperature
variants, surface_skin and surface_subskin, but I'm assuming this isn't
needed for sea
floor measurements.

Thanks - Nan


On 9/10/19 1:59 PM, Lowry, Roy K. wrote:
> Hi again,
>
> I place great weight on the phrase 'where appropriate'. If a model
> works out electrical conductivity and then uses the PSS-78 algorithms
> to compute the salinity then using 'practical salinity' would be
> appropriate, but these are far from the norm!!! It's observational
> measurements where we really need to be careful about the types of
> salinity, but I've yet to see a measurements data set where bottom
> salinities are tagged differently from the salinities measured
> elsewhere in the water column. Consequently I don't see the need for
> the new name.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> 
> *From:* Andrew Barna
> *Sent:* 10 September 2019 18:47
> *Subject:* Re: [C

Re: [CF-metadata] new variable name request

[Lowry, Roy K.]

PS I was already totally happy with adding sea_water_temperature_at_sea_floor


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Nan Galbraith 

Sent: 12 September 2019 17:13
To: cf-metadata@cgd.ucar.edu 
Cc: OceanSITES Data Management Team 
Subject: Re: [CF-metadata] new variable name request

Hi all -

I'd like to second (or third ... ) the request for new standard names for
sea_water_practical_salinity_at_sea_floor and
sea_water_temperature_at_sea_floor.

In the OceanSITES project, we deploy CTDs on mooring anchors, and it
would be good
to be able to find these records, among all the water temperature and
practical salinity
data sets on our servers. We supply a measurement depth, but it isn't
useful for this
search, since the water depth isn't mandatory in our format spec.

These records are not exactly on the sea floor, but within a few meters;
do we need to
apply some limit to the distance? I'm thinking about the various
sea_surface_temperature
variants, surface_skin and surface_subskin, but I'm assuming this isn't
needed for sea
floor measurements.

Thanks - Nan


On 9/10/19 1:59 PM, Lowry, Roy K. wrote:
> Hi again,
>
> I place great weight on the phrase 'where appropriate'. If a model
> works out electrical conductivity and then uses the PSS-78 algorithms
> to compute the salinity then using 'practical salinity' would be
> appropriate, but these are far from the norm!!!  It's observational
> measurements where we really need to be careful about the types of
> salinity, but I've yet to see a measurements data set where bottom
> salinities are tagged differently from the salinities measured
> elsewhere in the water column. Consequently I don't see the need for
> the new name.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> 
> *From:* Andrew Barna 
> *Sent:* 10 September 2019 18:47
> *Subject:* Re: [CF-metadata] new variable name request
> Thanks Roy,
>
> All the existing “sea_water_salinity” names have the sentence "The
> more precise standard names should be used where appropriate for both
> modelled and observed salinities.” So it think it was worth the ask if
> they know.
>
> -Barna
>
> > On 2019-09-10, at 07:42, Lowry, Roy K.  wrote:
> >
> > Dear Barna,
> >
> > Perhaps the existing Standard Name would suffice for Cathy's needs
> as she is labelling model output and the models in my experience do
> not work to a specific measurement scale. This is because boundary
> condition and assimilation data sets can include measurements of more
> than one type in order to provide adequate coverage.
> >
> > Cheers, Roy.
> >
> >
> > From: CF-metadata  on behalf of
> Andrew Barna 
> > Sent: 10 September 2019 18:23
> > Subject: Re: [CF-metadata] new variable name request
> >
> > Hi Cathy,
> >
> > There is already the name `sea_water_salinity_at_sea_floor` in the
> CF standard name list. However, if you know the scale you are
> calculating, a new name should be added to indicate this:
> > sea_water_practical_salinity_at_sea_floor if using PSS-78
> > or
> > sea_water_absolute_salinity_at_sea_floor if using TEOS-10
> >
> > I can come up with some definitions if you would like to have either
> of these proposed to the list.
> > -Barna
> >
> >
> > > On 2019-09-10, at 07:04, Cathy Smith  wrote:
> > >
> > > Thanks. I will use that variable.
> > >
> > > I also calculated salinity of the ocean floor. Same question.
> > >
> > > Cathy
> > >
> > > On 9/9/19 3:44 PM, Andrew Barna wrote:
> > >> Hi Cathy,
> > >>
> > >> There is the name `sea_water_potential_temperature_at_sea_floor`
> with the following definition:
> > >> Potential temperature is the temperature a parcel of air or sea
> water would have if moved adiabatically to sea level pressure. The
> potential temperature at the sea floor is that adjacent to the ocean
> bottom, which would be the deepest grid cell in an ocean model.
> > >>
> > >> From what I can tell, there is no “in situ” sea water temperature
> name at the sea floor. I’d suggest the following name for this
> parameter with canonical units K:
> > >> `sea_water_temperature_at_sea_floor`
> > >>
> > >> Here is a possible definition basically modifying the above to
> remove the “potential” parts:
> > >>
> > >> Sea wat

Re: [CF-metadata] new variable name request

[Lowry, Roy K.]

Hi Karl,

I can't see precedents like 'sea_water_potential_temperature_at_sea_floor' 
(already in the Standard Names) being overridden by existing practice from 
atmospheric data.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Taylor, Karl 
E. 
Sent: 12 September 2019 17:56
To: cf-metadata@cgd.ucar.edu 
Subject: Re: [CF-metadata] new variable name request

Hi All,

For reference, a measurement usually referred to as surface air
temperature is a measurement taken at about 2 meters height above the
surface (of the earth or ocean).  It has a standard name
"air_temperature" (which also applies to temperatures higher up in the
atmosphere).  To precisely specify the height above the surface at which
the surface air temperature is measured, a scalar coordinate is defined
with standard_name "height", with the value set to the actual height of
measurement (usually 2 meters, as noted above).  Note that this
near-surface air temperature is different from "surface_temperature"
which is the temperature of the surface itself.

Something similar is done for surface wind speed measurements, but the
height is typically 10 meters, not 2 meters.

In both cases, no special standard name is defined for these
near-surface measurements.

best regards,
Karl

On 9/12/19 9:13 AM, Nan Galbraith wrote:
> Hi all -
>
> I'd like to second (or third ... ) the request for new standard names for
> sea_water_practical_salinity_at_sea_floor and
> sea_water_temperature_at_sea_floor.
>
> In the OceanSITES project, we deploy CTDs on mooring anchors, and it
> would be good
> to be able to find these records, among all the water temperature and
> practical salinity
> data sets on our servers. We supply a measurement depth, but it isn't
> useful for this
> search, since the water depth isn't mandatory in our format spec.
>
> These records are not exactly on the sea floor, but within a few
> meters; do we need to
> apply some limit to the distance? I'm thinking about the various
> sea_surface_temperature
> variants, surface_skin and surface_subskin, but I'm assuming this
> isn't needed for sea
> floor measurements.
>
> Thanks - Nan
>
>
> On 9/10/19 1:59 PM, Lowry, Roy K. wrote:
>> Hi again,
>>
>> I place great weight on the phrase 'where appropriate'. If a model
>> works out electrical conductivity and then uses the PSS-78 algorithms
>> to compute the salinity then using 'practical salinity' would be
>> appropriate, but these are far from the norm!!!  It's observational
>> measurements where we really need to be careful about the types of
>> salinity, but I've yet to see a measurements data set where bottom
>> salinities are tagged differently from the salinities measured
>> elsewhere in the water column. Consequently I don't see the need for
>> the new name.
>>
>> Cheers, Roy.
>>
>> I have now retired but will continue to be active through an Emeritus
>> Fellowship using this e-mail address.
>>
>>
>> 
>> *From:* Andrew Barna 
>> *Sent:* 10 September 2019 18:47
>> *Subject:* Re: [CF-metadata] new variable name request
>> Thanks Roy,
>>
>> All the existing “sea_water_salinity” names have the sentence "The
>> more precise standard names should be used where appropriate for both
>> modelled and observed salinities.” So it think it was worth the ask
>> if they know.
>>
>> -Barna
>>
>> > On 2019-09-10, at 07:42, Lowry, Roy K.  wrote:
>> >
>> > Dear Barna,
>> >
>> > Perhaps the existing Standard Name would suffice for Cathy's needs
>> as she is labelling model output and the models in my experience do
>> not work to a specific measurement scale. This is because boundary
>> condition and assimilation data sets can include measurements of more
>> than one type in order to provide adequate coverage.
>> >
>> > Cheers, Roy.
>> >
>> >
>> > From: CF-metadata  on behalf of
>> Andrew Barna 
>> > Sent: 10 September 2019 18:23
>> > Subject: Re: [CF-metadata] new variable name request
>> >
>> > Hi Cathy,
>> >
>> > There is already the name `sea_water_salinity_at_sea_floor` in the
>> CF standard name list. However, if you know the scale you are
>> calculating, a new name should be added to indicate this:
>> > sea_water_practical_salinity_at_sea_floor if using PSS-78
>> > or
>> > sea_water_absolute_salinity_at_sea_floor if using TEOS-10
>

Re: [CF-metadata] new variable name request

[Lowry, Roy K.]

Hi Nan,

That is a reasonably convincing use case for adding 
sea_water_practical_salinity_at_sea_floor. It's the first time I've encountered 
a desire to label near-bed observations differently from those elsewhere in the 
water column but can see what you're wanting to do . The strategy I used in the 
past involved loading data up into a relational database then using a filter 
algorithm based on measurement depth,water depth and benthic boundary layer 
thickness (which can vary from 2 m to 50 m depending upon the water column 
structure and the purpose for which the data are being used).

For model data, it's easy to define 'at sea floor' - it's the bottom cell in a 
full-depth profile. For measurements I agree with you that quantifying 'at sea 
floor' isn't a good idea based on my experiences described above. Would it be 
helpful for measurements to use the phrase 'within the benthic boundary layer'?

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Nan Galbraith 

Sent: 12 September 2019 17:13
To: cf-metadata@cgd.ucar.edu 
Cc: OceanSITES Data Management Team 
Subject: Re: [CF-metadata] new variable name request

Hi all -

I'd like to second (or third ... ) the request for new standard names for
sea_water_practical_salinity_at_sea_floor and
sea_water_temperature_at_sea_floor.

In the OceanSITES project, we deploy CTDs on mooring anchors, and it
would be good
to be able to find these records, among all the water temperature and
practical salinity
data sets on our servers. We supply a measurement depth, but it isn't
useful for this
search, since the water depth isn't mandatory in our format spec.

These records are not exactly on the sea floor, but within a few meters;
do we need to
apply some limit to the distance? I'm thinking about the various
sea_surface_temperature
variants, surface_skin and surface_subskin, but I'm assuming this isn't
needed for sea
floor measurements.

Thanks - Nan


On 9/10/19 1:59 PM, Lowry, Roy K. wrote:
> Hi again,
>
> I place great weight on the phrase 'where appropriate'. If a model
> works out electrical conductivity and then uses the PSS-78 algorithms
> to compute the salinity then using 'practical salinity' would be
> appropriate, but these are far from the norm!!!  It's observational
> measurements where we really need to be careful about the types of
> salinity, but I've yet to see a measurements data set where bottom
> salinities are tagged differently from the salinities measured
> elsewhere in the water column. Consequently I don't see the need for
> the new name.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> 
> *From:* Andrew Barna 
> *Sent:* 10 September 2019 18:47
> *Subject:* Re: [CF-metadata] new variable name request
> Thanks Roy,
>
> All the existing “sea_water_salinity” names have the sentence "The
> more precise standard names should be used where appropriate for both
> modelled and observed salinities.” So it think it was worth the ask if
> they know.
>
> -Barna
>
> > On 2019-09-10, at 07:42, Lowry, Roy K.  wrote:
> >
> > Dear Barna,
> >
> > Perhaps the existing Standard Name would suffice for Cathy's needs
> as she is labelling model output and the models in my experience do
> not work to a specific measurement scale. This is because boundary
> condition and assimilation data sets can include measurements of more
> than one type in order to provide adequate coverage.
> >
> > Cheers, Roy.
> >
> >
> > From: CF-metadata  on behalf of
> Andrew Barna 
> > Sent: 10 September 2019 18:23
> > Subject: Re: [CF-metadata] new variable name request
> >
> > Hi Cathy,
> >
> > There is already the name `sea_water_salinity_at_sea_floor` in the
> CF standard name list. However, if you know the scale you are
> calculating, a new name should be added to indicate this:
> > sea_water_practical_salinity_at_sea_floor if using PSS-78
> > or
> > sea_water_absolute_salinity_at_sea_floor if using TEOS-10
> >
> > I can come up with some definitions if you would like to have either
> of these proposed to the list.
> > -Barna
> >
> >
> > > On 2019-09-10, at 07:04, Cathy Smith  wrote:
> > >
> > > Thanks. I will use that variable.
> > >
> > > I also calculated salinity of the ocean floor. Same question.
> > >
> > > Cathy
> > >
> > > On 9/9/19 3:44 PM, Andrew Barna wrote:
> > >> Hi Cathy,
> > >>
> > >> There is t

Re: [CF-metadata] new variable name request

[Lowry, Roy K.]

Hi again,

I place great weight on the phrase 'where appropriate'. If a model works out 
electrical conductivity and then uses the PSS-78 algorithms to compute the 
salinity then using 'practical salinity' would be appropriate, but these are 
far from the norm!!!  It's observational measurements where we really need to 
be careful about the types of salinity, but I've yet to see a measurements data 
set where bottom salinities are tagged differently from the salinities measured 
elsewhere in the water column. Consequently I don't see the need for the new 
name.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: Andrew Barna 
Sent: 10 September 2019 18:47
To: Lowry, Roy K. 
Cc: Cathy Smith ; CF Metadata List 

Subject: Re: [CF-metadata] new variable name request

Thanks Roy,

All the existing “sea_water_salinity” names have the sentence "The more precise 
standard names should be used where appropriate for both modelled and observed 
salinities.” So it think it was worth the ask if they know.

-Barna

> On 2019-09-10, at 07:42, Lowry, Roy K.  wrote:
>
> Dear Barna,
>
> Perhaps the existing Standard Name would suffice for Cathy's needs as she is 
> labelling model output and the models in my experience do not work to a 
> specific measurement scale. This is because boundary condition and 
> assimilation data sets can include measurements of more than one type in 
> order to provide adequate coverage.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
> From: CF-metadata  on behalf of Andrew 
> Barna 
> Sent: 10 September 2019 18:23
> To: Cathy Smith 
> Cc: CF Metadata List 
> Subject: Re: [CF-metadata] new variable name request
>
> Hi Cathy,
>
> There is already the name `sea_water_salinity_at_sea_floor` in the CF 
> standard name list. However, if you know the scale you are calculating, a new 
> name should be added to indicate this:
> sea_water_practical_salinity_at_sea_floor if using PSS-78
> or
> sea_water_absolute_salinity_at_sea_floor if using TEOS-10
>
> I can come up with some definitions if you would like to have either of these 
> proposed to the list.
> -Barna
>
>
> > On 2019-09-10, at 07:04, Cathy Smith  wrote:
> >
> > Thanks. I will use that variable.
> >
> > I also calculated salinity of the ocean floor. Same question.
> >
> > Cathy
> >
> > On 9/9/19 3:44 PM, Andrew Barna wrote:
> >> Hi Cathy,
> >>
> >> There is the name `sea_water_potential_temperature_at_sea_floor` with the 
> >> following definition:
> >> Potential temperature is the temperature a parcel of air or sea water 
> >> would have if moved adiabatically to sea level pressure. The potential 
> >> temperature at the sea floor is that adjacent to the ocean bottom, which 
> >> would be the deepest grid cell in an ocean model.
> >>
> >> From what I can tell, there is no “in situ” sea water temperature name at 
> >> the sea floor. I’d suggest the following name for this parameter with 
> >> canonical units K:
> >> `sea_water_temperature_at_sea_floor`
> >>
> >> Here is a possible definition basically modifying the above to remove the 
> >> “potential” parts:
> >>
> >> Sea water temperature is the in situ temperature of the sea water. The 
> >> temperature at the sea floor is that adjacent to the ocean bottom, which 
> >> would be the deepest grid cell in an ocean model.
> >>
> >> There should probably also be a modification of the existing 
> >> sea_water_temperature definition to include this new name if it is 
> >> accepted:
> >>
> >> The sentence:
> >> "There are standard names for sea_surface_temperature, 
> >> sea_surface_skin_temperature, sea_surface_subskin_temperature and 
> >> sea_surface_foundation_temperature which can be used to describe data 
> >> located at the specified surfaces.”
> >>
> >> Should be changed to:
> >>
> >> "There are standard names for sea_surface_temperature, 
> >> sea_surface_skin_temperature, sea_surface_subskin_temperature,  
> >> sea_surface_foundation_temperature, and sea_water_temperature_at_sea_floor 
> >> which can be used to describe data located at the specified surfaces.”
> >>
> >> -Barna
> >>
> >>> On 2019-09-09, at 11:23, Cathy Smith  wrote:
> >>>
> >>> All
> >>>
> >>> I have a new variable request; bottom tempe

Re: [CF-metadata] new variable name request

[Lowry, Roy K.]

Hi again,

I have seen many examples of model output over the years where salinities have 
been tagged with the units of 'PSU' but I know for a fact that the source data 
used have been a mixture of PSS-78 and historical data that strictly speaking 
should be given units of ppt.

I would counsel against adding a new Standard Name for labelling model output.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Andrew Barna 

Sent: 10 September 2019 18:38
To: Cathy Smith 
Cc: CF Metadata List 
Subject: Re: [CF-metadata] new variable name request

Hi Cathy,

The “P” of PSU is “Practical” so it's almost certain to be PSS-78, it sounds 
like we should get “sea_water_practical_salinity_at_sea_floor” on the list. Let 
me know what the oceanographer says and we can get a name proposed.

-Barna


> On 2019-09-10, at 07:32, Cathy Smith  wrote:
>
> Thanks. I didn't think to look. It's a reanalysis dataset so not measured 
> directly. The units are PSU. I'm not sure either "methods" below apply. The 
> observed data for ORAS5 reanalysis is from here
>
> https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/2013JC009067
>
> I'll ask an oceanographer here if he has any idea about this.
>
> Cathy
>
> On 9/10/19 11:23 AM, Andrew Barna wrote:
>> Hi Cathy,
>>
>> There is already the name `sea_water_salinity_at_sea_floor` in the CF 
>> standard name list. However, if you know the scale you are calculating, a 
>> new name should be added to indicate this:
>> sea_water_practical_salinity_at_sea_floor if using PSS-78
>> or
>> sea_water_absolute_salinity_at_sea_floor if using TEOS-10
>>
>> I can come up with some definitions if you would like to have either of 
>> these proposed to the list.
>> -Barna
>>
>>
>>> On 2019-09-10, at 07:04, Cathy Smith  wrote:
>>>
>>> Thanks. I will use that variable.
>>>
>>> I also calculated salinity of the ocean floor. Same question.
>>>
>>> Cathy
>>>
>>> On 9/9/19 3:44 PM, Andrew Barna wrote:
 Hi Cathy,

 There is the name `sea_water_potential_temperature_at_sea_floor` with the 
 following definition:
 Potential temperature is the temperature a parcel of air or sea water 
 would have if moved adiabatically to sea level pressure. The potential 
 temperature at the sea floor is that adjacent to the ocean bottom, which 
 would be the deepest grid cell in an ocean model.

 From what I can tell, there is no “in situ” sea water temperature name at 
 the sea floor. I’d suggest the following name for this parameter with 
 canonical units K:
 `sea_water_temperature_at_sea_floor`

 Here is a possible definition basically modifying the above to remove the 
 “potential” parts:

 Sea water temperature is the in situ temperature of the sea water. The 
 temperature at the sea floor is that adjacent to the ocean bottom, which 
 would be the deepest grid cell in an ocean model.

 There should probably also be a modification of the existing 
 sea_water_temperature definition to include this new name if it is 
 accepted:

 The sentence:
 "There are standard names for sea_surface_temperature, 
 sea_surface_skin_temperature, sea_surface_subskin_temperature and 
 sea_surface_foundation_temperature which can be used to describe data 
 located at the specified surfaces.”

 Should be changed to:

 "There are standard names for sea_surface_temperature, 
 sea_surface_skin_temperature, sea_surface_subskin_temperature,  
 sea_surface_foundation_temperature, and sea_water_temperature_at_sea_floor 
 which can be used to describe data located at the specified surfaces.”

 -Barna

> On 2019-09-09, at 11:23, Cathy Smith  wrote:
>
> All
>
> I have a new variable request; bottom temperature. It is the temperature 
> of the ocean floor (or the last level of a multi level ocean dataset). I 
> searched and was unable to find it or a variable with "bottom" or synomyn 
> as a level. I welcome being pointed out where I missed it.
>
> It is an important variable for fish and aquatic populations near coasts 
> (or very shallow oceans).
>
> http://glossary.ametsoc.org/wiki/Bottom_temperature
>
> https://www.frontiersin.org/articles/10.3389/fmars.2019.00030/full
>
> Let me know if this request should go elsewhere.
>
> Thanks
>
> Cathy Smith
>
> --
> NOAA/ESRL PSD and CU CIRES
> 303-497-6263
> https://www.esrl.noaa.gov/psd/people/cathy.smith/
>
> Emails about data/webpages may get quicker responses from emailing
> esrl.psd.d...@noaa.gov
>
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> 

Re: [CF-metadata] new variable name request

[Lowry, Roy K.]

Dear Barna,

Perhaps the existing Standard Name would suffice for Cathy's needs as she is 
labelling model output and the models in my experience do not work to a 
specific measurement scale. This is because boundary condition and assimilation 
data sets can include measurements of more than one type in order to provide 
adequate coverage.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Andrew Barna 

Sent: 10 September 2019 18:23
To: Cathy Smith 
Cc: CF Metadata List 
Subject: Re: [CF-metadata] new variable name request

Hi Cathy,

There is already the name `sea_water_salinity_at_sea_floor` in the CF standard 
name list. However, if you know the scale you are calculating, a new name 
should be added to indicate this:
sea_water_practical_salinity_at_sea_floor if using PSS-78
or
sea_water_absolute_salinity_at_sea_floor if using TEOS-10

I can come up with some definitions if you would like to have either of these 
proposed to the list.
-Barna


> On 2019-09-10, at 07:04, Cathy Smith  wrote:
>
> Thanks. I will use that variable.
>
> I also calculated salinity of the ocean floor. Same question.
>
> Cathy
>
> On 9/9/19 3:44 PM, Andrew Barna wrote:
>> Hi Cathy,
>>
>> There is the name `sea_water_potential_temperature_at_sea_floor` with the 
>> following definition:
>> Potential temperature is the temperature a parcel of air or sea water would 
>> have if moved adiabatically to sea level pressure. The potential temperature 
>> at the sea floor is that adjacent to the ocean bottom, which would be the 
>> deepest grid cell in an ocean model.
>>
>> From what I can tell, there is no “in situ” sea water temperature name at 
>> the sea floor. I’d suggest the following name for this parameter with 
>> canonical units K:
>> `sea_water_temperature_at_sea_floor`
>>
>> Here is a possible definition basically modifying the above to remove the 
>> “potential” parts:
>>
>> Sea water temperature is the in situ temperature of the sea water. The 
>> temperature at the sea floor is that adjacent to the ocean bottom, which 
>> would be the deepest grid cell in an ocean model.
>>
>> There should probably also be a modification of the existing 
>> sea_water_temperature definition to include this new name if it is accepted:
>>
>> The sentence:
>> "There are standard names for sea_surface_temperature, 
>> sea_surface_skin_temperature, sea_surface_subskin_temperature and 
>> sea_surface_foundation_temperature which can be used to describe data 
>> located at the specified surfaces.”
>>
>> Should be changed to:
>>
>> "There are standard names for sea_surface_temperature, 
>> sea_surface_skin_temperature, sea_surface_subskin_temperature,  
>> sea_surface_foundation_temperature, and sea_water_temperature_at_sea_floor 
>> which can be used to describe data located at the specified surfaces.”
>>
>> -Barna
>>
>>> On 2019-09-09, at 11:23, Cathy Smith  wrote:
>>>
>>> All
>>>
>>> I have a new variable request; bottom temperature. It is the temperature of 
>>> the ocean floor (or the last level of a multi level ocean dataset). I 
>>> searched and was unable to find it or a variable with "bottom" or synomyn 
>>> as a level. I welcome being pointed out where I missed it.
>>>
>>> It is an important variable for fish and aquatic populations near coasts 
>>> (or very shallow oceans).
>>>
>>> http://glossary.ametsoc.org/wiki/Bottom_temperature
>>>
>>> https://www.frontiersin.org/articles/10.3389/fmars.2019.00030/full
>>>
>>> Let me know if this request should go elsewhere.
>>>
>>> Thanks
>>>
>>> Cathy Smith
>>>
>>> --
>>> NOAA/ESRL PSD and CU CIRES
>>> 303-497-6263
>>> https://www.esrl.noaa.gov/psd/people/cathy.smith/
>>>
>>> Emails about data/webpages may get quicker responses from emailing
>>> esrl.psd.d...@noaa.gov
>>>
>>> ___
>>> CF-metadata mailing list
>>> CF-metadata@cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --
> --
> NOAA/ESRL PSD and CU CIRES
> 303-497-6263
> https://www.esrl.noaa.gov/psd/people/cathy.smith/
>
> Emails about data/webpages may get quicker responses from emailing
> esrl.psd.d...@noaa.gov
>

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own 

Re: [CF-metadata] New standard_name of quality_flag for corresponding quality control variables

[Lowry, Roy K.]

Dear Ken,

Having been involved in the quite painful process of weaning out data quality 
information from the host of status flag (often misnamed quality flag) schemes 
in oceanographic legacy data I would be very disappointed were 'quality_flag' 
not to be accepted as a Standard Name. If nothing else it will provide 
best-practice guidance to maintain semantic purity in quality flag schemes.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Kehoe, 
Kenneth E. 
Sent: 26 July 2019 22:17
To: CF Metadata List 
Subject: Re: [CF-metadata] New standard_name of quality_flag for corresponding 
quality control variables

Barna,

I disagree. It is not possible to distinguish a quality variable by the 
existence of flag_meanings attribute alone. flag_meanings is an attribute used 
by any state variable. We need some method to distinguish a state of the 
instrument or some other general state variable from quality. I see not 
defining a quality variable explicitly will be more work for the user as they 
will be required to parse out every flag_meanings value to see if it applies.

I am proposing a standard name because that has a more likely adoption than 
adding a new attribute. I have tried adding new attributes to the CF convention 
in the past and I have gotten large push back. Most often I was told to put 
that information into standard name. For example positive direction on a 
variable (not a vertical coordinate), digital object identifier, orientation of 
platform variables, and indication of a variable as being uncertainty were all 
denied. I was told the standard name describes the variable, which is what I am 
proposing.

I don't see the use of multiple variables for describing quality as a problem. 
I would recommend only having one, but not forbidding multiple. I know the CF 
document proposes using flag_values with flag_masks to indicate which mask 
value to use. I find that logic quite confusing for the average user since the 
descriptions are all mix together in flag_meanings. If your concern is having 
multiple ancillary quality variables I suggest adding additional standard names 
or having the user look for a keyword in the long_name. For example we could 
propose a suite of new standard names: quality_flag, primary_quality_flag, 
secondary_quality_flag instrument_quality_flag, model_quality_flag, ...

Since CF does not have any specific examples or explanation on how to handle 
quality I think we need to start somewhere. The standard name table has many 
examples of a general term being introduced to work on solving a problem, and 
when that needs refinement we add a better term. Looking at platform 
names there are more general terms 
that do not indicate positive direction when first entered into the table. Then 
when there was an understanding that a need for knowing the positive direction 
was desired it was added later. I see the addition of quality_flag following 
the same logic. If a refined or set of refined standard names are needed in the 
future we can add them but right now starting simple with quality_flag seems 
most appropriate.

I have serious doubts I will get a new attribute name adopted by CF to indicate 
a variable is a quality variable. I could propose a new attribute like 
"quality_variable" but what do I set the attribute to. There is no CF boolean 
to say True/False. And if we have the attribute set to some value we will need 
a new ontology to mange. I'm looking for a simple solution to declare a 
variable as a quality indication variable.

Thanks and have a nice weekend,

Ken




On 2019-7-26 14:05, Andrew Barna wrote:
Hi Everyone,

I've been re reading all these emails and having some long conversations with 
colleagues about this proposal and still I can't seem to convince myself that 
it is a good idea.

The initial request seemed to be motivated by wanting to distinguish "quality" 
from "status" based on standard name alone. This distinction can currently be 
accomplished by using the "flag_meanings" attribute. This name is hardly unique 
in needing additional information, many of the radiation names need (often 
optional) wavelength coordinates. If you are doing any custom calendars or 
grids, all these need additional attributes or information to properly 
interpret the data in the variable.

Having multiple flag variables in a file shouldn't be a problem, WOCE did it 
for "originator" vs  "expert" QC. If you really don't want more than one flag 
variable, the flag_masks attribute allows for combining all these states 
together, combing that further with flag_meanings even allows you to define 
which combinations are valid. My group is considering having multiple flag 
schemes in the file (WOCE and ARGO), so you can just use the one that you like 
best.

My colleagues expressed concern 

Re: [CF-metadata] New standard_name of quality_flag for corresponding quality control variables

[Lowry, Roy K.]

Dear Barna,

I don't think legacy schemes that notoriously mix quality statements with other 
information are a problem. They would simply be labelled 'status_flag'. 
'quality_flag' would be reserved for schemes with cleaner semantics. My 
understanding of the proposal does not change the meaning of 'status_flag' to 
exclude flag schemes with some quality flags.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Andrew Barna 

Sent: 23 July 2019 20:33
To: Kehoe, Kenneth E. 
Cc: cf-metadata@cgd.ucar.edu 
Subject: Re: [CF-metadata] New standard_name of quality_flag for corresponding 
quality control variables

Ken,

Ok I see how this can be useful. Two more questions:
* How would you deal with "legacy" flag schemes which mix "status" and
"quality" already? I'm thinking of WOCE CTD as an example where "7"
means Despiked (a status) and "3" means Questionable measurement (a
quality). The way my seagoing group have dealt with both is by having
the "quality" override "status" if the quality is anything other than
"good", e.g. a questionable measurement which has been despiked gets
flag 3.

* Are there rules in CF regarding restricting an existing definition?
I imagine there are many datasets already using the "status_flag" name
as either a stand alone standard name or a standard name modifier.
This change seems to be "breaking" in that previously compliant
datasets would now have quality information in a purely status field.

Thanks
-Barna

On Tue, Jul 23, 2019 at 10:08 AM Kehoe, Kenneth E.  wrote:
>
> Martin,
>
> Thanks for your reply. I would prefer to keep the proposal simple. My example 
> of a weighted mean was just one I created off the top of my head. I don't see 
> it as something to actually look into implementing.
>
> I need a way to indicate a variable is a quality status field. The 
> distinction that the status field only contains quality information is the 
> important distinction. The variable indicated with quality_flag will need to 
> also use flag_meanings, same as status_flag. Hence my reason for choosing 
> quality_flag to follow a similar naming pattern.
>
> Barna,
>
> Without a distinction that the entire variable is a quality variable the user 
> is forced to parse the flag_meanings to see if the variable applies. This 
> would also encourage a data provider to mix quality with source or instrument 
> state or something else in the same variable. That would be very difficult to 
> understand.
>
> As Martin points out quality is more subjective than other status 
> information. A user may need to choose what parts of the quality variable to 
> apply. I would prefer we not conflate absolute information with subjective 
> information. But we need a way to distinguish the variable contains absolute 
> information vs a variable that contains more subjective information.
>
> To expand on Martin's example imagine a profiling instrument that has a 
> shutter to protect the laser from rain. The laser will always send out pulses 
> and the receiver will always be on receiving the return from laser pulse. To 
> know when the shutter is in the open state where the instrument is profiling 
> we would use a state variable with a simple flag_values method.
>
> short shutter (time)
>   shutter:long_name = "Shutter state"
>   shutter:units = '1'
>   shutter:flag_values = 0, 1
>   shutter:flag_meanings = "closed open"
>   shutter:standard_name = "status_flag"
>
> This variable is just indicating the position of the shutter. There is no 
> ambiguity with it's use. If a user wants to use the data for atmospheric 
> reasons they should filter to only use data where profiling. In fact we can 
> implement this variable into our code by only using data where shutter is set 
> to open.
>
> Here is an example of more subjective quality variable.
>
> short quality_variable (time)
>   quality_variable:long_name = "Quality variable for linked data variable"
>   quality_variable:units = '1'
>   quality_variable:flag_masks= 1, 2, 4, 8, 16, 32
>   quality_variable:flag_meanings = "Shutter_not_open
> Laser_below_80_percent_power
> Laser_below_60_percent_power
> Laser_below_40_percent_power
> Bird_poop_may_be_on_sensor
> Bird_poop_is_on_sensor"
>   quality_variable:flag_meanings = "Bad Suspect Suspect Bad Suspect Bad"
>   quality_variable:standard_name = "quality_flag"
>
> In this example there are three indications when the laser is less than 100%. 
> It would be up to the user to decide what percentage is the limit where they 
> do not want to use the data. This is more subjective and dependent on the 
> research techniques to determine if the issue a problem or not. It is also up 
> to the user to determine if the chance of bird poop on the sensor is an issue 
> or if they are OK with the risk of using the data. And to be nice to the user 
> we have also pulled 

Re: [CF-metadata] proposing two new standard names for H2S and N2 in sea water

[Lowry, Roy K.]

These look good to me.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Daniel 
Neumann 
Sent: 16 May 2019 10:29
To: CF Metadata Mail List
Subject: [CF-metadata] proposing two new standard names for H2S and N2 in sea 
water

Dear all,

I would like to propose two new standard names, which I need for naming
output variables of a biogeochemical ocean model:

(a) mole_concentration_of_dissolved_molecular_nitrogen_in_sea_water
(b) mole_concentration_of_hydrogen_sulfide_in_sea_water

A similar name than (a) already exists for O2:
mole_concentration_of_dissolved_molecular_oxygen_in_sea_water . I just
copied the units and description (and adapted it to N2).

One standard name containing `hydrogen_sulfide` exists for the
atmosphere but none exists for the water yet. I copied the description
of another `mole_concentration_of_..._in_sea_water` standard name and
replaced the chemical formula in it.


The full definition of the two standard names:

NAME:
mole_concentration_of_dissolved_molecular_nitrogen_in_sea_water

DESCRIPTION:
Mole concentration means number of moles per unit volume, also called
"molarity", and is used in the construction
mole_concentration_of_X_in_Y, where X is a material constituent of Y. A
chemical or biological species denoted by X may be described by a single
term such as "nitrogen" or a phrase such as "nox_expressed_as_nitrogen".
The chemical formula for molecular nitrogen is N2.

UNIT:
mol m-3


NAME:
mole_concentration_of_hydrogen_sulfide_in_sea_water

DESCRIPTION:
Mole concentration means number of moles per unit volume, also called
"molarity", and is used in the construction
mole_concentration_of_X_in_Y, where X is a material constituent of Y. A
chemical or biological species denoted by X may be described by a single
term such as "nitrogen" or a phrase such as "nox_expressed_as_nitrogen".
The chemical formula for molecular hydrogen sulfide is H2S.

UNIT:
mol m-3


Best Regards,
Daniel

--
Daniel Neumann

Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany

phone:  +49-381-5197-287
fax:+49-381-5197-114 or 440
e-mail: daniel.neum...@io-warnemuende.de




This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Question to usage of standard_name sea_water_practical_salinity

[Lowry, Roy K.]

Dear Daniel,

The value you should store is 35. There is much discussion in the CF archives 
on the various types of salinity and their units that is best not repeated. It 
may help your understanding to think of the reason practical salinity is 
dimensionless and has the canonical unit 1 as being because it is derived from 
a dimensionless electrical conductivity ratio.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Daniel 
Neumann 
Sent: 15 May 2019 11:58
To: CF Metadata Mail List
Subject: [CF-metadata] Question to usage of standard_name 
sea_water_practical_salinity

Dear list,

The standard name "sea_water_practical_salinity" has the unit "1". The
CF FAQ says that "1" is used instead of "psu" as unit
(http://cfconventions.org/faq.html#udunits_missing).

If we have "35 psu", does the variable "sea_water_practical_salinity"
has a value of 35 (just unit "psu" removed) or of 0.035 (35 psu approx.
35 g/kg = 0.035 g/g = 0.035)?

Best Regards,
Daniel

--
Daniel Neumann

Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany

phone:  +49-381-5197-287
fax:+49-381-5197-114 or 440
e-mail: daniel.neum...@io-warnemuende.de




This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Some standard name updates to improve consistency.

[Lowry, Roy K.]

Dear Martin,

>From what I can see, the productivity Standard Name descriptions use the 
>phrase '"Productivity" means production per unit area'. Looking at the 
>canonical units productivity is moles_or_mass/m2/s, whereas production is 
>moles_or_mass/m3/s. This means that productivity is in fact the depth integral 
>of production and not the rate of a state variable.

I would suggest that before doing any 'tidying up' that the canonical units are 
checked.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Martin Juckes 
- UKRI STFC 
Sent: 24 April 2019 13:41
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Some standard name updates to improve consistency.

Hello All,


The standard name table has a high degree of internal consistency across 
thousands of variables, but there are a few anomalies. I'd like to suggest a 
few changes below.  These are minor issues,


 1. Change "aerosol" to "aerosol_particles".

The overwhelming majority of aerosol terms refer to "aerosol_particles". There 
are two anomalies:


  *   
tendency_of_atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur_due_to_wet_deposition
  *   mercury_dry_aerosol

Should these be changed to "aerosol_particles"?

2. Primary production vs. primary productivity

There are 6 terms for 
net_primary_productivity_of_biomass_expressed_as_carbon..., and one for 
net_primary_production_of_biomass_expressed_as_carbon_per_unit_volume_in_sea_water.
 In addition, there are 6 terms using primary_production in the construction 
"due_to_net_primary_production".

Production and productivity are often used interchangeably, but some people 
draw a distinction. E.g. using "productivity" for a rate and "production" for 
an amount. The usage in the standard names could be interpreted as using 
"primary_production" in oceanic contexts and "primary_productivity" in land 
contexts, but net_primary_productivity_of_biomass_expressed_as_carbon is not 
explicitly defined as applying only to land. Should it be?

Can we either change these terms to consistently use "productivity" (or 
"production"), or, if that is not appropriate, provide some explanation of the 
use of two different terms for the same quantity?

3. aerodynamic_resistance

The definition of this term implies that it refers to the aerodynamic 
resistance of the boundary layer, rather than the more general concept of 
aerodynamic resistance as defined, for example, by AMS: 
http://glossary.ametsoc.org/wiki/Aerodynamic_resistance .

If the narrower term is intended, perhaps the name should be changed to 
aerodynamic_resistance_of_planetary_boundary_layer, so that it is clear that 
this is a boundary layer property.

4. Litter and Soil

To mean the combination of litter and soil, we have one use of 
"soil_and_litter", one of "litter_and_soil". There are multiple uses of 
"vegetation_litter_and_soil", so we can take this as the preferred order.

Can we change 
carbon_mass_flux_into_soil_and_litter_due_to_anthropogenic_land_use_or_land_cover_change
 to 
carbon_mass_flux_into_litter_and_soil_due_to_anthropogenic_land_use_or_land_cover_change
 for consistency?


5. Products


There are 7 terms which use the old name "omega", which is now aliassed to 
"lagrangian_tendency_of_air_pressure".  Two of these are redundant, because 
they are of the form "product_of_B_and_A" for terms already covered by 
"product_of_A_and_B".

 1. product_of_specific_humidity_and_omega
 2. product_of_omega_and_specific_humidity [redundant]
 3. product_of_eastward_wind_and_omega
 4. product_of_northward_wind_and_omega
 5. product_of_air_temperature_and_omega
 6. product_of_omega_and_air_temperature [redundant]
 7. product_of_geopotential_height_and_omega


Can we remove the two redundant terms, and replace "omega" with 
"lagrangian_tendency_of_air_pressure"?


6. Use of "net_downward" in aerosol indirect radiative effect terms


There are 5 aerosol direct radiative effect terms. These are analogous to cloud 
radiative effect terms (3)  and radiative forcing terms (12). For all the 
radiative forcing terms and the cloud radiative effect terms, the sign 
convention is assumed to be that positive forcing/radiative effect is 
equivalent to a downward radiative flux.  This is also true for the TOA direct 
radiative effect term. For 4 terms describing the aerosol direct radiative 
effect at the surface, there is an additional inclusion of "net_downward" in 
the term. This looks redundant to me, and I think it should be removed for 
consistency with other radiative effect and forcing terms.


* 
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect

* 
surface_net_downward_longwave_dust_ambient_aerosol_particles_direct_radiative_effect_assuming_clear_sky

* 
surface_net_downward_shortwave_dust_ambient_aerosol_particles_direct_radiative_effect

* 

Re: [CF-metadata] New halocarbon standard name requests

[Lowry, Roy K.]

Hi Alison,

I have never used PubChem - I tend to use ChEBI - but reading around it seems a 
highly respected standard and I can find no valid argument against its use.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 17 April 2019 17:31
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: Re: [CF-metadata] New halocarbon standard name requests

Dear Dan, Roy and Jonathan,

Apologies for the delay in getting back to this discussion. I agree completely 
that the IUPAC names need to be accurate to facilitate searching of names and 
definitions. I'm in favour of getting rid of superfluous hyphens as Roy 
suggests e.g., 1,1,1-trichloro-ethane becomes 1,1,1-trichloroethane.

I used PubChem (https://pubchem.ncbi.nlm.nih.gov/) to produce the following 
list of changes  to existing standard name definitions. Interestingly, this 
suggests we should remove hyphens but add brackets in some cases (hcfc22 for 
example) while others seem to include hyphens where we might not expect them, 
e.g. halon1211.
limonene: current definition '1-methyl-4-prop-1-en-2-yl-cyclohexene' will be 
corrected to '1-methyl-4-prop-1-en-2-ylcyclohexene'.
isoprene: current definition '2-methyl-buta-1,3-diene' will be corrected to 
'2-methylbuta-1,3-diene'.
hcfc22: current definition 'chloro-difluoro-methane' will be corrected to 
'chloro(difluoro)methane'.
hcc140a:  current definition '1,1,1-trichloro-ethane' will be corrected to 
'1,1,1-trichloroethane'.
halon2402:  current definition '1,2-dibromo-1,1,2,2-tetrafluoro-ethane' will be 
corrected to '1,2-dibromo-1,1,2,2-tetrafluoroethane'.
halon1301: current definition 'bromo-trifluoro-methane' will be corrected to 
'bromo(trifluoro)methane'.
halon1211: current definition 'bromo-chloro-difluoro-methane' will be corrected 
to 'bromo-chloro-difluoromethane'.
halon1202: current definition 'dibromo-difluoro-methane' will be corrected to 
'dibromo(difluoro)methane'.
cfc12: current definition 'dichloro-difluoro-methane' will be corrected to 
'dichloro(difluoro)methane'.
cfc115: current definition '1-chloro-1,1,2,2,2-pentafluoro-ethane' will be 
corrected to '1-chloro-1,1,2,2,2-pentafluoroethane'.
cfc114: current definition '1,2-dichloro-1,1,2,2-tetrafluoro-ethane' will be 
corrected to '1,2-dichloro-1,1,2,2-tetrafluoroethane'.
cfc113a: current definition '1,1,1-trichloro-2,2,2-trifluoro-ethane' will be 
corrected to '1,1,1-trichloro-2,2,2-trifluoroethane.'
cfc113: current definition '1,1,2-trichloro-1,2,2-trifluoro-ethane' will be 
corrected to '1,1,2-trichloro-1,2,2-trifluoroethane'.
cfc11: current definition 'trichloro-fluoro-methane' will be corrected to 
'trichloro(fluoro)methane'.

Do you agree with using PubChem as the reference source and are you happy to 
proceed with these changes?

Regarding the existing carbon tetrafluoride names, I will add pfc14 to the 
definitions as an alternative name. Similarly, methyl chloroform will be added 
to the definitions of existing hcc140a names as previously discussed. These 
changes will be added in the May standard names update.

Best wishes,
Alison

---
Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Jonathan 
Gregory
Sent: 09 April 2019 13:46
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New halocarbon standard name requests

Dear Roy

> You're right about hcc140a - I'd missed that because of the hyphen in the 
> IUPAC name trichloro-ethane. In my view the hyphen doesn't belong there (try 
> googling trichloro-ethane) if the IUPAC standard is strictly followed - 
> should be trichloroethane. If others agree maybe we should clean out the 
> hyphens from the definitions in a future update?

I agree that our chemical names in definitions should follow IUPAC.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing 

Re: [CF-metadata] New halocarbon standard name requests

[Lowry, Roy K.]

Just to be crystal clear there should be one hyphen in the full IUPAC name 
1,1,1-trichloroethane - it's the second hyphen between trichloro and ethane 
that's the issue.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Lowry, Roy K. 

Sent: 08 April 2019 20:56
To: Alison Pamment - UKRI STFC; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New halocarbon standard name requests

Hi Alison,

You're right about hcc140a - I'd missed that because of the hyphen in the IUPAC 
name trichloro-ethane. In my view the hyphen doesn't belong there (try googling 
trichloro-ethane) if the IUPAC standard is strictly followed - should be 
trichloroethane. If others agree maybe we should clean out the hyphens from the 
definitions in a future update?

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 08 April 2019 17:24
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New halocarbon standard name requests

Dear Dan and Roy,

Thank you Dan for proposing these six new names and to Roy for the careful 
checking.

Roy is correct that mole_fraction_of_carbon_tetrachloride_in_air already exists 
in the standard name table. In fact we have eight existing carbon_tetrachloride 
quantities but only one of them 
(tendency_of_atmosphere_moles_of_carbon_tetrachloride) mentions the IUPAC name, 
tetrachloromethane, in its definition. Although we don't need a new name, I 
will update the existing ones to add the IUPAC information to the definitions.

The proposed name mole_fraction_of_methyl_chloroform_in_air doesn't currently 
exist in the standard name table. However, we do have the name 
mole_fraction_of_hcc140a_in_air defined as :
' "Mole fraction" is used in the construction "mole_fraction_of_X_in_Y", where 
X is a material constituent of Y. A chemical or biological species denoted by X 
may be described by a single term such as "nitrogen" or a phrase such as 
"nox_expressed_as_nitrogen". The chemical formula for hcc140a is CH3CCl3. The 
IUPAC name for hcc140a is 1,1,1-trichloro-ethane.'
This appears to be the same chemical species so I don't think we need a new 
name for this one.  We have ten existing hcc140a names and if it is also 
commonly referred to as methyl chloroform I suggest we add that to the 
definitions as follows:
' "Mole fraction" is used in the construction "mole_fraction_of_X_in_Y", where 
X is a material constituent of Y. A chemical or biological species denoted by X 
may be described by a single term such as "nitrogen" or a phrase such as 
"nox_expressed_as_nitrogen". The chemical formula for hcc140a, also called 
methyl chloroform, is CH3CCl3. The IUPAC name for hcc140a is 
1,1,1-trichloro-ethane.'
Do others agree?

To summarize where we are with this set of proposals, the following are 
accepted for publication in the standard name table and will be included in 
this week's update:
'mole_fraction_of_dichloromethane_in_air (Canonical unit: 1)
Definition: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for dichloromethane 
is CH2Cl2. The IUPAC name is dichloromethane.'

mole_fraction_of_chloroform_in_air (Canonical unit: 1)
Definition: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for chloroform is 
CHCl3. The IUPAC name for chloroform is trichloromethane.'

mole_fraction_of_perchloroethene_in_air (Canonical unit: 1)
Definition: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for perchloroethene 
is CCl2CCl2. The IUPAC name for perchloroethene is tetrachloroethene.'

mole_fraction_of_pfc218_in_air (Canonical unit: 1)
Definition: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc218 is C3F8. 
The IUPAC name for pfc218

Re: [CF-metadata] New halocarbon standard name requests

[Lowry, Roy K.]

Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data Analysis    Email: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 02 April 2019 13:03
To: Dan Say ; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New halocarbon standard name requests

Hi again,

This request for PFC-318 is duplicated in your third e-mail (the one including 
carbon tetrafluoride).

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: Dan Say
Sent: 29 March 2019 14:33
To: Lowry, Roy K.; mailto:cf-metadata@cgd.ucar.edu
Subject: Re: New halocarbon standard name requests
Apologies, can I also add the following:

PFC-318
Standard name: mole_fraction_of_pfc318_in_air (Canonical unit: 1)
Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc318 is c-C4F8. 
The IUPAC name for pfc318 is octafluorocyclobutane.

Thanks,

Dan




Dr Daniel Say
Postdoctoral Research Associate
Atmospheric Chemistry Research Group
School of Chemistry
University of Bristol
Tel: (+44) 117 3317042

From: Lowry, Roy K.
Sent: 29 March 2019 13:39:25
To: Dan Say; mailto:cf-metadata@cgd.ucar.edu
Subject: Re: New halocarbon standard name requests
Thanks Dan,

Nicely put together and I can't see any issues.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata on behalf of Dan Say
Sent: 29 March 2019 13:11
To: mailto:cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New halocarbon standard name requests
Dear All,

I'd like to request an addition to the standard name list for atmospheric 
measurements of halocarbons dichloromethane, chloroform, perchloroethene, 
carbon tetrachloride, methyl chloroform and octafluoropropane. Here are the 
details of the proposed standard names.

Proposal for a new standard variable names:
Dichloromethane
Standard name: mole_fraction_of_dichloromethane_in_air (Canonical unit: 1)
Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for dichloromethane 
is CH2Cl2. The IUPAC name is dichloromethane.

Chloroform
Standard name: mole_fraction_of_chloroform_in_air (Canonical unit: 1)
Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for chloroform is 
CHCl3. The IUPAC name for chloroform is trichloromethane.

Perchloroethene
Standard name: mole_fraction_of_perchloroethene_in_air (Canonical unit: 1)
Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for perchloroethene 
is CCl2CCl2. The IUPAC name for perchloroethene is tetrachloroethene.

Carbon tetrachloride
Standard name: mole_fraction_of_carbon_tetrachloride_in_air (Canonical unit: 1)
Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for carbon 
tetrachloride is CCl4. The IUPAC name for carbon tetrachloride is 
tetrachloromethane.

Methyl chloroform
Standard name: mole_fraction_of_methyl_chloroform_in_air (Canonical unit: 1)
Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for methyl chloroform 
is CH3CCl3. The IUPAC name for methyl chloroform is 1,1,1-trichloroethane.

PFC-218
Stan

Re: [CF-metadata] New halocarbon standard name requests

[Lowry, Roy K.]

Hi again,

This request for PFC-318 is duplicated in your third e-mail (the one including 
carbon tetrafluoride).

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: Dan Say 
Sent: 29 March 2019 14:33
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: Re: New halocarbon standard name requests


Apologies, can I also add the following:


PFC-318

Standard name: mole_fraction_of_pfc318_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc318 is c-C4F8. 
The IUPAC name for pfc318 is octafluorocyclobutane.


Thanks,


Dan





Dr Daniel Say
Postdoctoral Research Associate
Atmospheric Chemistry Research Group
School of Chemistry
University of Bristol
Tel: (+44) 117 3317042
____________
From: Lowry, Roy K. 
Sent: 29 March 2019 13:39:25
To: Dan Say; cf-metadata@cgd.ucar.edu
Subject: Re: New halocarbon standard name requests

Thanks Dan,

Nicely put together and I can't see any issues.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Dan Say 

Sent: 29 March 2019 13:11
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New halocarbon standard name requests


Dear All,

I'd like to request an addition to the standard name list for atmospheric 
measurements of halocarbons dichloromethane, chloroform, perchloroethene, 
carbon tetrachloride, methyl chloroform and octafluoropropane. Here are the 
details of the proposed standard names.

Proposal for a new standard variable names:


Dichloromethane

Standard name: mole_fraction_of_dichloromethane_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for dichloromethane 
is CH2Cl2. The IUPAC name is dichloromethane.


Chloroform

Standard name: mole_fraction_of_chloroform_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for chloroform is 
CHCl3. The IUPAC name for chloroform is trichloromethane.



Perchloroethene

Standard name: mole_fraction_of_perchloroethene_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for perchloroethene 
is CCl2CCl2. The IUPAC name for perchloroethene is tetrachloroethene.



Carbon tetrachloride

Standard name: mole_fraction_of_carbon_tetrachloride_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for carbon 
tetrachloride is CCl4. The IUPAC name for carbon tetrachloride is 
tetrachloromethane.



Methyl chloroform

Standard name: mole_fraction_of_methyl_chloroform_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for methyl chloroform 
is CH3CCl3. The IUPAC name for methyl chloroform is 1,1,1-trichloroethane.



PFC-218

Standard name: mole_fraction_of_pfc218_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc218 is C3F8. 
The IUPAC name for pfc218 is octafluoropropane.



Thanks in advance,

Dan





Dr Dani

Re: [CF-metadata] New halocarbon standard name requests

[Lowry, Roy K.]

Hi again,

After bumping into one accidental duplicate, I thought I'd better check the 
first part of your submission more carefully and found 
'mole_fraction_of_carbon_tetrachloride_in_air' 
(http://vocab.nerc.ac.uk/collection/P07/current/CFV8N16/) already exists, which 
I missed first time around.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Dan Say 

Sent: 29 March 2019 13:11
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New halocarbon standard name requests


Dear All,

I'd like to request an addition to the standard name list for atmospheric 
measurements of halocarbons dichloromethane, chloroform, perchloroethene, 
carbon tetrachloride, methyl chloroform and octafluoropropane. Here are the 
details of the proposed standard names.

Proposal for a new standard variable names:


Dichloromethane

Standard name: mole_fraction_of_dichloromethane_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for dichloromethane 
is CH2Cl2. The IUPAC name is dichloromethane.


Chloroform

Standard name: mole_fraction_of_chloroform_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for chloroform is 
CHCl3. The IUPAC name for chloroform is trichloromethane.



Perchloroethene

Standard name: mole_fraction_of_perchloroethene_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for perchloroethene 
is CCl2CCl2. The IUPAC name for perchloroethene is tetrachloroethene.



Carbon tetrachloride

Standard name: mole_fraction_of_carbon_tetrachloride_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for carbon 
tetrachloride is CCl4. The IUPAC name for carbon tetrachloride is 
tetrachloromethane.



Methyl chloroform

Standard name: mole_fraction_of_methyl_chloroform_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for methyl chloroform 
is CH3CCl3. The IUPAC name for methyl chloroform is 1,1,1-trichloroethane.



PFC-218

Standard name: mole_fraction_of_pfc218_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc218 is C3F8. 
The IUPAC name for pfc218 is octafluoropropane.



Thanks in advance,

Dan





Dr Daniel Say
Postdoctoral Research Associate
Atmospheric Chemistry Research Group
School of Chemistry
University of Bristol
Tel: (+44) 117 3317042


This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu

Re: [CF-metadata] More trace gas standard names

[Lowry, Roy K.]

Hi Dan,

PFC-14 is already present as mole_fraction_of_carbon_tetrafluoride_in_air 
(http://vocab.nerc.ac.uk/collection/P07/current/GYGQPPOA/).

Otherwise look fine.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Dan Say 

Sent: 01 April 2019 14:40
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] More trace gas standard names


Hi All,


I'd like to propose the following standard names for trace halogenated 
compounds measured on our Medusa GCMS instrument:


PFC-14

Standard name: mole_fraction_of_pfc14_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc14 is CF4. The 
IUPAC name for pfc14 is tetrafluoromethane.



PFC-116

Standard name: mole_fraction_of_pfc116_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc116 is C2F6. 
The IUPAC name for pfc116 is hexafluoroethane.



PFC-318

Standard name: mole_fraction_of_pfc318_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc318 is c-C4F8. 
The IUPAC name for pfc318 is octafluorocyclobutane.



NF3

Standard name: mole_fraction_of_nitrogen_trifluoride_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for nitrogen 
trifluoride is NF3. Nitrogen trifluoride is the IUPAC name.



HFC-227ea

Standard name: mole_fraction_of_hfc227ea_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for hfc227ea is 
C3HF7. The IUPAC name for hfc227ea is 1,1,1,2,3,3,3-heptafluoropropane.



HFC-245fa

Standard name: mole_fraction_of_hfc245fa_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for hfc245fa is 
C3H3F5. The IUPAC name for hfc245fa is 1,1,1,3,3-pentafluoropropane.



HFC-4310mee

Standard name: mole_fraction_of_hfc4310mee_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for hfc4310mee is 
C5H2F10. The IUPAC name for hfc4310mee is 1,1,1,2,2,3,4,5,5,5-decafluoropentane.



HFC-365mfc

Standard name: mole_fraction_of_hfc365mfc_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for hfc365mfc is 
C4H5F5. The IUPAC name for hfc365mfc is 1,1,1,3,3-pentafluorobutane.



HFC-236fa

Standard name: mole_fraction_of_hfc236fa_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for hfc236fa is 
C3H2F6. The IUPAC name for hfc236fa is 1,1,1,3,3,3-hexafluoropropane.



HCFC-124

Standard name: mole_fraction_of_hcfc124_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as 

Re: [CF-metadata] New halocarbon standard name requests

[Lowry, Roy K.]

Thanks Dan,

Nicely put together and I can't see any issues.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Dan Say 

Sent: 29 March 2019 13:11
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New halocarbon standard name requests


Dear All,

I'd like to request an addition to the standard name list for atmospheric 
measurements of halocarbons dichloromethane, chloroform, perchloroethene, 
carbon tetrachloride, methyl chloroform and octafluoropropane. Here are the 
details of the proposed standard names.

Proposal for a new standard variable names:


Dichloromethane

Standard name: mole_fraction_of_dichloromethane_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for dichloromethane 
is CH2Cl2. The IUPAC name is dichloromethane.


Chloroform

Standard name: mole_fraction_of_chloroform_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for chloroform is 
CHCl3. The IUPAC name for chloroform is trichloromethane.



Perchloroethene

Standard name: mole_fraction_of_perchloroethene_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for perchloroethene 
is CCl2CCl2. The IUPAC name for perchloroethene is tetrachloroethene.



Carbon tetrachloride

Standard name: mole_fraction_of_carbon_tetrachloride_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for carbon 
tetrachloride is CCl4. The IUPAC name for carbon tetrachloride is 
tetrachloromethane.



Methyl chloroform

Standard name: mole_fraction_of_methyl_chloroform_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for methyl chloroform 
is CH3CCl3. The IUPAC name for methyl chloroform is 1,1,1-trichloroethane.



PFC-218

Standard name: mole_fraction_of_pfc218_in_air (Canonical unit: 1)

Long name: 'Mole fraction is used in the construction mole_fraction_of_X_in_Y, 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". The chemical formula for pfc218 is C3F8. 
The IUPAC name for pfc218 is octafluoropropane.



Thanks in advance,

Dan





Dr Daniel Say
Postdoctoral Research Associate
Atmospheric Chemistry Research Group
School of Chemistry
University of Bristol
Tel: (+44) 117 3317042


This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Addition of HFC standard names

[Lowry, Roy K.]

Hi David,

Wow. That does surprise me. I can't remember where I picked up that one or the 
other had to be present, but I do remember it was during a debate with a 
community about 10 years ago who were making statements that the standard_name 
attribute was mandatory for CF conformance. I'm impressed by your knowledge of 
the Conventions text!

I can understand the COARDS backwards compatibility argument, although this is 
something that is eroding as the Conventions evolve.  I would argue that 
'highly recommended' should be taken to mean 'mandatory' for data files 
currently being created!

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: David Hassell 
Sent: 13 March 2019 11:18
To: Lowry, Roy K.
Cc: Klaus Zimmermann; CF Metadata
Subject: Re: [CF-metadata] Addition of HFC standard names

Hello Roy,

The text at 
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#long-name
 doesn't include any mandatory circumstances, as I read it:

"For backwards compatibility with COARDS this attribute is optional. But it is 
highly recommended that either this or the standard_name attribute defined in 
the next section be provided to make the file self-describing. If a variable 
has no long_name attribute then an application may use, as a default, the 
standard_name if it exists, or the variable name itself."

What do you think?

All the best,
David


On Wed, 13 Mar 2019 at 10:29, Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:
Dear David,

My understanding is that the long_name attribute is mandatory, not just highly 
recommended, if there is no standard_name attribute.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of David Hassell 
mailto:david.hass...@ncas.ac.uk>>
Sent: 13 March 2019 09:53
To: Klaus Zimmermann
Cc: CF Metadata
Subject: Re: [CF-metadata] Addition of HFC standard names

Hello Klaus,

You are indeed correct - the CF "long_name" attribute contains a long 
descriptive name that is non-standardised. It is optional, though its use is 
highly recommended if there is no standard name.

Projects such as CMIP may, and do, insist on particular long names, but that is 
entirely outside of the CF conventions. The description of a standard name in 
the official table (e.g. "Mole fraction" is used in the construction 
"mole_fraction_of_X_in_Y", where X, .") provides the precise definition of 
the quantity, but is not intended to be used as a long name in netCDF datasets.

All the best,

David

On Wed, 13 Mar 2019 at 09:33, Klaus Zimmermann 
mailto:klaus.zimmerm...@smhi.se>> wrote:
Good morning,

just a technical clarification: long names are not standardized within
cf, correct?

Indeed, typical long names don't follow the snake_case convention, but
are rather more free-form and human readable/understandable. They are
chosen by the user, often giving information beyond the standard names.

Examples from CMIP6 (Omon table, variables tos and tosga):
tos:
- standard name: sea_surface_temperature
- long name: Sea Surface Temperature
tosga:
- standard name: sea_surface_temperature
- long name: Global Average Sea Surface Temperature

Cheers
Klaus


On 13/03/2019 10:11, Dan Say wrote:
> Good morning,
>
>
> I am happy to go with the IUPAC names if needs be however, hfc is
> standard nomenclature and I would have thought the most likely term to
> be searched. I also note that there are already standard names for
> several HCFCs and CFCs, for which the standard names are
> 'mole_fraction_of_cfc11_in_air' etc. Nevertheless, see below a list of
> the requested standard/long names and definitions, using both HFC and
> IUPAC nomenclature. I am happy for you to choose which ones we use,
> please advise.
>
>
> *HFC nomenclature:*
>
>
> Standard name: mole_fraction_of_hfc134a_in_air
>
> Long name: mole_fraction_of_hfc134a_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.  The
> IUPAC name for hfc134a is 1,1,1,2-tetrafluoroethane.
>
>
> Standard name: mole_fraction_of_hfc143a_in_air
>
> Long name: mole_fraction_of_hfc143a_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.  The
> IUPAC name for hfc143a is 1,1,1-trifluoroethane.
>
>
> Standard name: mole_fraction_of_hfc125_in_air
>
> Long name: mole_fraction_of_hfc125_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.  The
>

Re: [CF-metadata] Addition of HFC standard names

[Lowry, Roy K.]

e_fraction_of_trifluoromethane_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.
> Trifluoromethane is described by its common name, HFC-23.
>
>
>
> Cheers,
>
>
> Dan
>
>
>
> */
> /*
> */
> /*
> *Dr Daniel Say*
> Postdoctoral Research Associate
> Atmospheric Chemistry Research Group
> School of Chemistry
> University of Bristol
> Tel: (+44) 117 3317042
> 
> *From:* Lowry, Roy K. 
> *Sent:* 12 March 2019 17:17:12
> *To:* Dan Say; cf-metadata@cgd.ucar.edu
> *Subject:* Re: Addition of HFC standard names
>
> HI again,
>
> I'd prefer it to be somewhere in the Standard Name entry because that is
> searchable either through the XML document on the CF site or through the
> vocabulary servers handling Standard Names. That way your data gets
> discovered by other communities who might search for
> '1,1,1,2-tetrafluoroethane'.  I've dealt with quite a few oceanographic
> halocarbon data sets over the years, but had never come across the 'hfc'
> nomenclature before.
>
> To my knowledge the long name doesn't get scraped by data discovery
> systems. It is used more as usage metadata to help users better
> understand the measurements. By all means include the IUPAC name in the
> long name, but I would also keep the hfc synonym there.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> 
> *From:* Dan Say 
> *Sent:* 12 March 2019 16:59
> *To:* Lowry, Roy K.; cf-metadata@cgd.ucar.edu
> *Subject:* Re: Addition of HFC standard names
>
>
> Hi Roy,
>
>
> Would it make more sense to leave the standard name as suggested, but
> replace 'hfc134a' with '1,1,1,2-tetrafluoroethane' in the long name, for
> simplicity? This is my first venture into the CEDa archives so please
> advise, I am happy to change the long names if needs be.
>
>
> Cheers,
>
>
> Dan
>
>
> */
> /*
> */
> /*
> *Dr Daniel Say*
> Postdoctoral Research Associate
> Atmospheric Chemistry Research Group
> School of Chemistry
> University of Bristol
> Tel: (+44) 117 3317042
> 
> *From:* Lowry, Roy K. 
> *Sent:* 12 March 2019 16:56:17
> *To:* Dan Say; cf-metadata@cgd.ucar.edu
> *Subject:* Re: Addition of HFC standard names
>
> Dear Dan,
>
> I think it would be better to have the IUPAC names somewhere
> (e.g. 1,1,1,2-tetrafluoroethane for hfc134a if Wikipedia is correct) in
> the Standard Name entry. I'd be happy with it in the definition but
> would not object to it being in the Standard Name itself.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> 
> *From:* CF-metadata  on behalf of Dan
> Say 
> *Sent:* 12 March 2019 16:43
> *To:* cf-metadata@cgd.ucar.edu
> *Subject:* [CF-metadata] Addition of HFC standard names
>
>
> Dear All,
>
> I'd like to request an addition to the standard name list for
> atmospheric measurements of hydrofluorocarbons HFC-134a, HFC-143a,
> HFC-125, HFC-152a, HFC-32 and HFC-23. Here are the details of the
> proposed standard names.
>
> Proposal for a new standard variable names:
>
> Names:
> mole_fraction_of_hfc134a_in_air
> mole_fraction_of_hfc143a_in_air
> mole_fraction_of_hfc125_in_air
> mole_fraction_of_hfc152a_in_air
> mole_fraction_of_hfc32_in_air
> mole_fraction_of_hfc23_in_air
>
> Description: Atmospheric measurements of hydrofluorocarbons (HFC) are
> reported as mole fraction data in units of parts per trillion (ppt,
> 1E-12). The long name will remain the same as the standard name.
>
> Thanks in advance,
>
> Dan
>
> */
> /*
> */
> /*
> *Dr Daniel Say*
> Postdoctoral Research Associate
> Atmospheric Chemistry Research Group
> School of Chemistry
> University of Bristol
> Tel: (+44) 117 3317042
>
>
> This email and any attachments are intended solely for the use of the
> named recipients. If you are not the intended recipient you must not
> use, disclose, copy or distribute this email or any of its attachments
> and should notify the sender immediately and delete this email from your
> system.
> UK Research and Innovation has taken every reasonable precaution to

Re: [CF-metadata] Addition of HFC standard names

[Lowry, Roy K.]

common name, HFC-143a.
>
>
> Standard name: mole_fraction_of_1,1,1,2,2-pentafluoroethane_in_air
>
> Long name: mole_fraction_of_1,1,1,2,2-pentafluoroethane_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.
> 1,1,1,2,2-pentafluoroethane is described by its common name, HFC-125.
>
>
> Standard name: mole_fraction_of_1,1-difluoroethane_in_air
>
> Long name: mole_fraction_of_1,1-difluoroethane_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.
> 1,1-difluoroethane is described by its common name, HFC-152a.
>
>
> Standard name: mole_fraction_of_difluoromethane_in_air
>
> Long name: mole_fraction_of_difluoromethane_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.
> Difluoromethane is described by its common name, HFC-32.
>
>
> Standard name: mole_fraction_of_trifluoromethane_in_air
>
> Long name: mole_fraction_of_trifluoromethane_in_air
>
> Definition: Mole fraction is used in the construction
> mole_fraction_of_X_in_Y, where X is a material constituent of Y.
> Trifluoromethane is described by its common name, HFC-23.
>
>
>
> Cheers,
>
>
> Dan
>
>
>
> */
> /*
> */
> /*
> *Dr Daniel Say*
> Postdoctoral Research Associate
> Atmospheric Chemistry Research Group
> School of Chemistry
> University of Bristol
> Tel: (+44) 117 3317042
> 
> *From:* Lowry, Roy K. mailto:r...@bodc.ac.uk>>
> *Sent:* 12 March 2019 17:17:12
> *To:* Dan Say; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
> *Subject:* Re: Addition of HFC standard names
>
> HI again,
>
> I'd prefer it to be somewhere in the Standard Name entry because that is
> searchable either through the XML document on the CF site or through the
> vocabulary servers handling Standard Names. That way your data gets
> discovered by other communities who might search for
> '1,1,1,2-tetrafluoroethane'.  I've dealt with quite a few oceanographic
> halocarbon data sets over the years, but had never come across the 'hfc'
> nomenclature before.
>
> To my knowledge the long name doesn't get scraped by data discovery
> systems. It is used more as usage metadata to help users better
> understand the measurements. By all means include the IUPAC name in the
> long name, but I would also keep the hfc synonym there.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> 
> *From:* Dan Say mailto:dan@bristol.ac.uk>>
> *Sent:* 12 March 2019 16:59
> *To:* Lowry, Roy K.; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
> *Subject:* Re: Addition of HFC standard names
>
>
> Hi Roy,
>
>
> Would it make more sense to leave the standard name as suggested, but
> replace 'hfc134a' with '1,1,1,2-tetrafluoroethane' in the long name, for
> simplicity? This is my first venture into the CEDa archives so please
> advise, I am happy to change the long names if needs be.
>
>
> Cheers,
>
>
> Dan
>
>
> */
> /*
> */
> /*
> *Dr Daniel Say*
> Postdoctoral Research Associate
> Atmospheric Chemistry Research Group
> School of Chemistry
> University of Bristol
> Tel: (+44) 117 3317042
> 
> *From:* Lowry, Roy K. mailto:r...@bodc.ac.uk>>
> *Sent:* 12 March 2019 16:56:17
> *To:* Dan Say; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
> *Subject:* Re: Addition of HFC standard names
>
> Dear Dan,
>
> I think it would be better to have the IUPAC names somewhere
> (e.g. 1,1,1,2-tetrafluoroethane for hfc134a if Wikipedia is correct) in
> the Standard Name entry. I'd be happy with it in the definition but
> would not object to it being in the Standard Name itself.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
> 
> *From:* CF-metadata 
> mailto:cf-metadata-boun...@cgd.ucar.edu>> 
> on behalf of Dan
> Say mailto:dan@bristol.ac.uk>>
> *Sent:* 12 March 2019 16:43
> *To:* cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
> *Sub

Re: [CF-metadata] Addition of HFC standard names

[Lowry, Roy K.]

HI again,

I'd prefer it to be somewhere in the Standard Name entry because that is 
searchable either through the XML document on the CF site or through the 
vocabulary servers handling Standard Names. That way your data gets discovered 
by other communities who might search for '1,1,1,2-tetrafluoroethane'.  I've 
dealt with quite a few oceanographic halocarbon data sets over the years, but 
had never come across the 'hfc' nomenclature before.

To my knowledge the long name doesn't get scraped by data discovery systems. It 
is used more as usage metadata to help users better understand the 
measurements. By all means include the IUPAC name in the long name, but I would 
also keep the hfc synonym there.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: Dan Say 
Sent: 12 March 2019 16:59
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: Re: Addition of HFC standard names


Hi Roy,


Would it make more sense to leave the standard name as suggested, but replace 
'hfc134a' with '1,1,1,2-tetrafluoroethane' in the long name, for simplicity? 
This is my first venture into the CEDa archives so please advise, I am happy to 
change the long names if needs be.


Cheers,


Dan




Dr Daniel Say
Postdoctoral Research Associate
Atmospheric Chemistry Research Group
School of Chemistry
University of Bristol
Tel: (+44) 117 3317042

From: Lowry, Roy K. 
Sent: 12 March 2019 16:56:17
To: Dan Say; cf-metadata@cgd.ucar.edu
Subject: Re: Addition of HFC standard names

Dear Dan,

I think it would be better to have the IUPAC names somewhere (e.g. 
1,1,1,2-tetrafluoroethane for hfc134a if Wikipedia is correct) in the Standard 
Name entry. I'd be happy with it in the definition but would not object to it 
being in the Standard Name itself.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Dan Say 

Sent: 12 March 2019 16:43
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Addition of HFC standard names


Dear All,

I'd like to request an addition to the standard name list for atmospheric 
measurements of hydrofluorocarbons HFC-134a, HFC-143a, HFC-125, HFC-152a, 
HFC-32 and HFC-23. Here are the details of the proposed standard names.

Proposal for a new standard variable names:

Names:
mole_fraction_of_hfc134a_in_air
mole_fraction_of_hfc143a_in_air
mole_fraction_of_hfc125_in_air
mole_fraction_of_hfc152a_in_air
mole_fraction_of_hfc32_in_air
mole_fraction_of_hfc23_in_air

Description: Atmospheric measurements of hydrofluorocarbons (HFC) are reported 
as mole fraction data in units of parts per trillion (ppt, 1E-12). The long 
name will remain the same as the standard name.

Thanks in advance,

Dan



Dr Daniel Say
Postdoctoral Research Associate
Atmospheric Chemistry Research Group
School of Chemistry
University of Bristol
Tel: (+44) 117 3317042


This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.



This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation

Re: [CF-metadata] Addition of HFC standard names

[Lowry, Roy K.]

Dear Dan,

I think it would be better to have the IUPAC names somewhere (e.g. 
1,1,1,2-tetrafluoroethane for hfc134a if Wikipedia is correct) in the Standard 
Name entry. I'd be happy with it in the definition but would not object to it 
being in the Standard Name itself.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Dan Say 

Sent: 12 March 2019 16:43
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Addition of HFC standard names


Dear All,

I'd like to request an addition to the standard name list for atmospheric 
measurements of hydrofluorocarbons HFC-134a, HFC-143a, HFC-125, HFC-152a, 
HFC-32 and HFC-23. Here are the details of the proposed standard names.

Proposal for a new standard variable names:

Names:
mole_fraction_of_hfc134a_in_air
mole_fraction_of_hfc143a_in_air
mole_fraction_of_hfc125_in_air
mole_fraction_of_hfc152a_in_air
mole_fraction_of_hfc32_in_air
mole_fraction_of_hfc23_in_air

Description: Atmospheric measurements of hydrofluorocarbons (HFC) are reported 
as mole fraction data in units of parts per trillion (ppt, 1E-12). The long 
name will remain the same as the standard name.

Thanks in advance,

Dan



Dr Daniel Say
Postdoctoral Research Associate
Atmospheric Chemistry Research Group
School of Chemistry
University of Bristol
Tel: (+44) 117 3317042


This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Dear Alison,

I would suggest that if the reference standard isn't included in the Standard 
Name then I wouldn't put it into the definition. I don't like the idea of 
having narrower semantics in the definition compared to the name. How about 
putting a recommendation that the standard be specified in the long name into 
the definition?

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 20 February 2019 16:40
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Dear Katherine, Roy, Jonathan, Daniel,

Thank you all for the very clear and interesting discussion - I have learned a 
lot from reading all your comments and the various references. It seems that we 
are inching towards agreement on:
enrichment_of_14C_in_air_expressed_as_uppercase_delta_14C (Canonical unit: 
1e-3).

Certainly it is shorter and more readable if we don't include the reference 
standard in the name itself. I suggest that we include it in the definition for 
completeness, but leave it out of the name. In future, if someone were to 
propose a similar quantity based on a different standard we could add more 
detail into the names and turn the original one into an alias. However, the 
references I have looked at seem to indicate that the same international 
standard has been in use since the 1950s, so it isn't something that changes on 
a regular basis.

Based on Roy's suggested definition, other comments in the discussion, and text 
used in the definitions of existing standard names, we would have something 
like the following:
'Isotopic enrichment of 14C, often called d14C or delta14C (lower case delta), 
is used to calculate the fossil fuel contribution to atmospheric carbon dioxide 
using isotopic ratios of carbon. It is a parameterisation of the 14C/12C 
isotopic ratio in the sample with respect to the isotopic ratio in a reference 
standard, in this case the radiocarbon absolute reference standard, Oxalic Acid 
I. It is computed using the formula (((14C/12C)sample / (14C/12C)standard) - 1) 
* 1000. The quantity called D14C, or Delta14C (upper case delta) is d14C 
corrected for isotopic fractionation using the 13C/12C ratio as follows: D14C = 
d14C - 2(dC13 + 25)(1+d14C/1000). If the sample is enriched in 14C relative to 
the standard, then the data value is positive. Reference: Stuiver, M. and H.A. 
Polach, 1977, Discussion reporting of 14C data, Radiocarbon, Volume 19, No. 3, 
355-363, doi: 10.1017/S003382223672.'

Does that sound okay?

Best wishes,
Alison

---
Alison Pamment Tel: +44 
1235 778065
NCAS/Centre for Environmental Data AnalysisEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


Hi Jonathan and Roy,


I do not feel there is need to mention the reference material. Oxalic Acid has 
been agreed upon as the primary reference material and any other reference 
materials are all traceable to the primary standards for radiocarbon analysis.

Thanks,

Katherine

On 16/02/2019, 16:04, "CF-metadata on behalf of Jonathan Gregory" 
 wrote:

Dear Roy

I went for "big" because it's shorter and a bit more amusing. If we have
"uppercase" it would also be OK - no need for _ in the middle of it, I 
think.

Yes, it would be good to hear an authoritative view on whether there is more
than one standard in use.

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Fri, 15 Feb 2019 15:24:06 +
> From: "Lowry, Roy K." 
> To: Jonathan Gregory , 
"cf-metadata@cgd.ucar.edu"
> 
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> Dear Jonathan,
>
> I am almost happy with 'big_delta14C', but would prefer 
'upper_case_delta14C'.
>
> I still feel that unless explicitly told otherwise by a domain expert the 
reference standard needs to be there. As I mentioned in a previous posting 
there have been multiple 14C standards used over the past 40 years, although I 
cannot say for certain whether more than one is in current use.
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.
>
> 
> From: CF-metadata  on behalf of 
Jonathan Gregory 
> Sent: 15 February 2019 15:00
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> Dear all
>
> Thank you for the clarifica

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Thanks Jonathan,

I'm happy to go with 'uppercase'.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 16 February 2019 16:04
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Dear Roy

I went for "big" because it's shorter and a bit more amusing. If we have
"uppercase" it would also be OK - no need for _ in the middle of it, I think.

Yes, it would be good to hear an authoritative view on whether there is more
than one standard in use.

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Fri, 15 Feb 2019 15:24:06 +
> From: "Lowry, Roy K." 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> Dear Jonathan,
>
> I am almost happy with 'big_delta14C', but would prefer 'upper_case_delta14C'.
>
> I still feel that unless explicitly told otherwise by a domain expert the 
> reference standard needs to be there. As I mentioned in a previous posting 
> there have been multiple 14C standards used over the past 40 years, although 
> I cannot say for certain whether more than one is in current use.
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 15 February 2019 15:00
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> Dear all
>
> Thank you for the clarifications. Actually I still do not understand what the
> normalisation does, but evidently it's a well-defined procedure.
>
> I'm in favour of precision, of course, when there is a danger of ambiguity.
> Roy proposes
>
>   
> enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_14C_in_carbon_dioxide_in_air_expressed_as_D14C
>
> I would like to ask if we could make it
>
>   enrichment_of_14C_in_carbon_dioxide_in_air_expressed_as_big_delta14C
>
> That is: (a) Do we have to mention the reference standard? Katherine does not
> specify this. Is there more than one standard in use? If so, we do need to
> include it, I agree. (b) It seems clearer to me to spell out delta than to
> put just D. (c) I appreciate that the small-delta version is obsolete but we
> can't rule out it being needed sometime (or perhaps a similar distinction is
> in actual use with other isotopes?), and I think it would be unreliable to
> distinguish two standard names just because one had a small d where the other
> had a big D. If we ever need the small-delta version we can put small_delta.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from "Robert M. Key"  -
>
> > Date: Wed, 13 Feb 2019 14:31:58 +
> > From: "Robert M. Key" 
> > To: Katherine Pugsley 
> > CC: "Lowry, Roy K." , Jonathan Gregory
> >, "cf-metadata@cgd.ucar.edu"
> >
> > Subject: Re: [CF-metadata] New standard name for 14CO2
> >
> > What Katherine listed is correct.  I’m not going to try to use D/delta here 
> > because it so often changes from one computer to the next.
> >
> > Ever since Minze Stuiver’s paper came out, almost all ocean radiocarbon 
> > measurements have been reported as  D14C (o/oo). Oceanic 13C measurements 
> > on the other hand are reported in the standard d13C  ( eq. 2 in Katherine’s 
> > note with 13 instead of 14). In a few publications you do see D14C 
> > converted to atoms/KG, but that is only for inventories and similar because 
> > you can’t integrate permil units.
> >
> > Air measurements are, I think, not so consistent, but generally reported in 
> > the same way.
> > Minze Stuiver was a tree ring specialist, so I assume those data are also 
> > D14C (rather than d14C)
> >
> > In seawater the measurements are routinely made on dissolved inorganic 
> > carbon. These data are listed as the seawater D14C value without mention of 
> > inorganic component. This is equivalent to what Katherine listed in her 
> > first line.
> >
> > AMS techniques allow 14C measurements on the oceanic dissolved organic 
> > carbon (Ellen Druffel and a few others). These data are routinely listed as 
> > DO14C where here the D indicates dissolved rather than the previously used 
> > Delta (that is, Delta 14C on Dissolved Organic Carbon).
> >
> 

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Dear Daniel,

I just noticed the references in your e-mail and had a quick read through. The 
detailed methodology paper describes D14C (labelled using the upper case Greek 
letter) measurements with d13C corrections.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Wesloh, 
Daniel 
Sent: 15 February 2019 15:49
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Hello everyone,

   I feel I should mention that, while δ¹⁴C may be obsolete in the
field of carbon dating, it seems to still be used in measuring and
reporting current atmospheric isotopes, as done by NOAA once a month or
so at a collection of sites around the continent and in aircraft
campaigns such as ACT-America.  This would seem to indicate that
standard names for both δ¹⁴C and Δ¹⁴C are needed.

Regards,
Daniel

NOAA describes what measurements they make here:
https://www.esrl.noaa.gov/gmd/ccgg/aircraft/analysis.html
ACT-America describes available measurements here:
https://daac.ornl.gov/ACTAMERICA/guides/ACTAMERICA_Merge.html
The detailed description of the carbon-14 measurements would be in the
paper here:
https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2006JD008184

On 2/15/2019 10:00 AM, Jonathan Gregory wrote:
> Dear all
>
> Thank you for the clarifications. Actually I still do not understand what the
> normalisation does, but evidently it's a well-defined procedure.
>
> I'm in favour of precision, of course, when there is a danger of ambiguity.
> Roy proposes
>
>
> enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_14C_in_carbon_dioxide_in_air_expressed_as_D14C
>
> I would like to ask if we could make it
>
>enrichment_of_14C_in_carbon_dioxide_in_air_expressed_as_big_delta14C
>
> That is: (a) Do we have to mention the reference standard? Katherine does not
> specify this. Is there more than one standard in use? If so, we do need to
> include it, I agree. (b) It seems clearer to me to spell out delta than to
> put just D. (c) I appreciate that the small-delta version is obsolete but we
> can't rule out it being needed sometime (or perhaps a similar distinction is
> in actual use with other isotopes?), and I think it would be unreliable to
> distinguish two standard names just because one had a small d where the other
> had a big D. If we ever need the small-delta version we can put small_delta.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from "Robert M. Key"  -
>
>> Date: Wed, 13 Feb 2019 14:31:58 +
>> From: "Robert M. Key" 
>> To: Katherine Pugsley 
>> CC: "Lowry, Roy K." , Jonathan Gregory
>>   , "cf-metadata@cgd.ucar.edu"
>>   
>> Subject: Re: [CF-metadata] New standard name for 14CO2
>>
>> What Katherine listed is correct.  I’m not going to try to use D/delta here 
>> because it so often changes from one computer to the next.
>>
>> Ever since Minze Stuiver’s paper came out, almost all ocean radiocarbon 
>> measurements have been reported as  D14C (o/oo). Oceanic 13C measurements on 
>> the other hand are reported in the standard d13C  ( eq. 2 in Katherine’s 
>> note with 13 instead of 14). In a few publications you do see D14C converted 
>> to atoms/KG, but that is only for inventories and similar because you can’t 
>> integrate permil units.
>>
>> Air measurements are, I think, not so consistent, but generally reported in 
>> the same way.
>> Minze Stuiver was a tree ring specialist, so I assume those data are also 
>> D14C (rather than d14C)
>>
>> In seawater the measurements are routinely made on dissolved inorganic 
>> carbon. These data are listed as the seawater D14C value without mention of 
>> inorganic component. This is equivalent to what Katherine listed in her 
>> first line.
>>
>> AMS techniques allow 14C measurements on the oceanic dissolved organic 
>> carbon (Ellen Druffel and a few others). These data are routinely listed as 
>> DO14C where here the D indicates dissolved rather than the previously used 
>> Delta (that is, Delta 14C on Dissolved Organic Carbon).
>>
>> bob
>>
>> On Feb 13, 2019, at 5:30 AM, Katherine Pugsley 
>>  wrote:
>>
>> The measurements I would like to report are . Here is the 
>> complete definition of how we have calculated .
>>
>> The isotopic composition can be expressed in delta values, in units of per 
>> mil (‰). The small delta (δ) is the isotopic ratio R (heavy C / light C) of 
>> a sample relative to the isotope ratio of a standard substance (Equatio

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Dear Daniel,

Our usual policy with Standard Name development is to set them up on an 'on 
demand' rather than an 'in case they are needed' basis. We simply don't have 
the resources to create Standard Names to cover every known measurement.

Prior to your e-mail there had been no request to provide Standard Names for 
these data. Are these data being prepared in CF and therefore need to be 
covered by Standard Names?  If so, are the measurements with respect to a 
specific standard or even standards? If so, what?

I get the feeling from your e-mail that you think that the existence of a 
Standard Name makes a particular measurement 'correct'. This is definitely NOT 
the case. We would never attempt to control scientific activity in such a way.

Cheers, Roy.




I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Wesloh, 
Daniel 
Sent: 15 February 2019 15:49
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Hello everyone,

   I feel I should mention that, while δ¹⁴C may be obsolete in the
field of carbon dating, it seems to still be used in measuring and
reporting current atmospheric isotopes, as done by NOAA once a month or
so at a collection of sites around the continent and in aircraft
campaigns such as ACT-America.  This would seem to indicate that
standard names for both δ¹⁴C and Δ¹⁴C are needed.

Regards,
Daniel

NOAA describes what measurements they make here:
https://www.esrl.noaa.gov/gmd/ccgg/aircraft/analysis.html
ACT-America describes available measurements here:
https://daac.ornl.gov/ACTAMERICA/guides/ACTAMERICA_Merge.html
The detailed description of the carbon-14 measurements would be in the
paper here:
https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2006JD008184

On 2/15/2019 10:00 AM, Jonathan Gregory wrote:
> Dear all
>
> Thank you for the clarifications. Actually I still do not understand what the
> normalisation does, but evidently it's a well-defined procedure.
>
> I'm in favour of precision, of course, when there is a danger of ambiguity.
> Roy proposes
>
>
> enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_14C_in_carbon_dioxide_in_air_expressed_as_D14C
>
> I would like to ask if we could make it
>
>enrichment_of_14C_in_carbon_dioxide_in_air_expressed_as_big_delta14C
>
> That is: (a) Do we have to mention the reference standard? Katherine does not
> specify this. Is there more than one standard in use? If so, we do need to
> include it, I agree. (b) It seems clearer to me to spell out delta than to
> put just D. (c) I appreciate that the small-delta version is obsolete but we
> can't rule out it being needed sometime (or perhaps a similar distinction is
> in actual use with other isotopes?), and I think it would be unreliable to
> distinguish two standard names just because one had a small d where the other
> had a big D. If we ever need the small-delta version we can put small_delta.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from "Robert M. Key"  -
>
>> Date: Wed, 13 Feb 2019 14:31:58 +
>> From: "Robert M. Key" 
>> To: Katherine Pugsley 
>> CC: "Lowry, Roy K." , Jonathan Gregory
>>   , "cf-metadata@cgd.ucar.edu"
>>   
>> Subject: Re: [CF-metadata] New standard name for 14CO2
>>
>> What Katherine listed is correct.  I’m not going to try to use D/delta here 
>> because it so often changes from one computer to the next.
>>
>> Ever since Minze Stuiver’s paper came out, almost all ocean radiocarbon 
>> measurements have been reported as  D14C (o/oo). Oceanic 13C measurements on 
>> the other hand are reported in the standard d13C  ( eq. 2 in Katherine’s 
>> note with 13 instead of 14). In a few publications you do see D14C converted 
>> to atoms/KG, but that is only for inventories and similar because you can’t 
>> integrate permil units.
>>
>> Air measurements are, I think, not so consistent, but generally reported in 
>> the same way.
>> Minze Stuiver was a tree ring specialist, so I assume those data are also 
>> D14C (rather than d14C)
>>
>> In seawater the measurements are routinely made on dissolved inorganic 
>> carbon. These data are listed as the seawater D14C value without mention of 
>> inorganic component. This is equivalent to what Katherine listed in her 
>> first line.
>>
>> AMS techniques allow 14C measurements on the oceanic dissolved organic 
>> carbon (Ellen Druffel and a few others). These data are routinely listed as 
>> DO14C where here the D indicates dissolved rather than the previously used 
>> Delta (that i

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Dear Jonathan,

I am almost happy with 'big_delta14C', but would prefer 'upper_case_delta14C'.

I still feel that unless explicitly told otherwise by a domain expert the 
reference standard needs to be there. As I mentioned in a previous posting 
there have been multiple 14C standards used over the past 40 years, although I 
cannot say for certain whether more than one is in current use.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 15 February 2019 15:00
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Dear all

Thank you for the clarifications. Actually I still do not understand what the
normalisation does, but evidently it's a well-defined procedure.

I'm in favour of precision, of course, when there is a danger of ambiguity.
Roy proposes

  
enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_14C_in_carbon_dioxide_in_air_expressed_as_D14C

I would like to ask if we could make it

  enrichment_of_14C_in_carbon_dioxide_in_air_expressed_as_big_delta14C

That is: (a) Do we have to mention the reference standard? Katherine does not
specify this. Is there more than one standard in use? If so, we do need to
include it, I agree. (b) It seems clearer to me to spell out delta than to
put just D. (c) I appreciate that the small-delta version is obsolete but we
can't rule out it being needed sometime (or perhaps a similar distinction is
in actual use with other isotopes?), and I think it would be unreliable to
distinguish two standard names just because one had a small d where the other
had a big D. If we ever need the small-delta version we can put small_delta.

Best wishes

Jonathan

- Forwarded message from "Robert M. Key"  -

> Date: Wed, 13 Feb 2019 14:31:58 +
> From: "Robert M. Key" 
> To: Katherine Pugsley 
> CC: "Lowry, Roy K." , Jonathan Gregory
>, "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> What Katherine listed is correct.  I’m not going to try to use D/delta here 
> because it so often changes from one computer to the next.
>
> Ever since Minze Stuiver’s paper came out, almost all ocean radiocarbon 
> measurements have been reported as  D14C (o/oo). Oceanic 13C measurements on 
> the other hand are reported in the standard d13C  ( eq. 2 in Katherine’s note 
> with 13 instead of 14). In a few publications you do see D14C converted to 
> atoms/KG, but that is only for inventories and similar because you can’t 
> integrate permil units.
>
> Air measurements are, I think, not so consistent, but generally reported in 
> the same way.
> Minze Stuiver was a tree ring specialist, so I assume those data are also 
> D14C (rather than d14C)
>
> In seawater the measurements are routinely made on dissolved inorganic 
> carbon. These data are listed as the seawater D14C value without mention of 
> inorganic component. This is equivalent to what Katherine listed in her first 
> line.
>
> AMS techniques allow 14C measurements on the oceanic dissolved organic carbon 
> (Ellen Druffel and a few others). These data are routinely listed as DO14C 
> where here the D indicates dissolved rather than the previously used Delta 
> (that is, Delta 14C on Dissolved Organic Carbon).
>
> bob
>
> On Feb 13, 2019, at 5:30 AM, Katherine Pugsley 
>  wrote:
>
> The measurements I would like to report are . Here is the 
> complete definition of how we have calculated .
>
> The isotopic composition can be expressed in delta values, in units of per 
> mil (‰). The small delta (δ) is the isotopic ratio R (heavy C / light C) of a 
> sample relative to the isotope ratio of a standard substance (Equation 2, 
> Stuiver & Polach (1977)).
> 
> (2)
> Here, 14C sample is the 14C content of sample, C sample is the carbon content 
> of sample, 14C std is the 14C content of standard and C standard is the 
> carbon content of standard. δ14C is used to calculate Δ14C.
> 14C can also be expressed as capital delta Δ14C (Equation 3, (Stuiver and 
> Polach, 1977)). The Δ14C is normalized to a δ13C value of -25 ‰, this is done 
> to account for fractionation. Fractionation effects discriminate against 14C 
> twice as much as for 13C (Stuiver and Polach, 1977). Normalising 14C 
> measurements to a common δ13C should, therefore, remove reservoir specific 
> differences caused by fractionation,
> 
>  

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Hello again,

Bob Key contacted me off-list to point out that d14C and D14C are different, 
but didn't tell me how. Reading around (http://www.c14dating.com/agecalc.html) 
I find that D14C is d14c with the 13C correction applied using the equation 
D14C=d14C - 2(dC13 + 25)(1 + d14C/1000) per mille where d14C is what I'd 
described in the draft definition. Bob also made it clear that the carbon 
dating community regard d14C and D14C as significantly different measurements, 
with d14C consigned to history.

So, Katherine's measurements are D14C. I just need to be sure that the 
fractionation correction she has applied is as given above - Katherine?

Following Bob's intervention I feel the Standard Name and definition should be 
for D14C, not d14C such as:

enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_ 
14C_in_carbon_dioxide_in_air_expressed_as_D14C

Isotopic enrichment of 14C  (d14C or delta14C), is a parameterisation of the 
14C/12C isotopic ratio in the sample with respect to the isotopic ratio in a 
standard, in this case the radiocarbon absolute reference standard. It is 
computed using the formula (((14C/12C) sample / (14C/12C) standard) - 1) * 
1000.  D14C or Delta14C is d14C corrected for isotopic fractionation using the 
13C/12C ratio.  D14C = d14C - 2(dC13 + 25)(1 + d14C/1000). If the sample is 
enriched in 14C then the value is positive.

I know Jonathan won't be comfortable with this, but carbon chemistry is a 
discipline where precise measurement semantics is very important.

Cheers, Roy.
Radiocarbon Date calculation - 
c14dating.com<http://www.c14dating.com/agecalc.html>
Figure 1: Decay curve for C14 showing the activity at one half-life (t/2). The 
terms "%Modern", or "pmC" and D14C are shown related in this diagram along with 
the Radiocarbon age in years BP (Before 1950 AD).
www.c14dating.com





I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: Katherine Pugsley 
Sent: 13 February 2019 08:35
To: Lowry, Roy K.; Jonathan Gregory; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Hi Roy, Jonathan,

The normalisation mathematically corrects for the effects of isotopic 
fractionation, such that the processes which naturally fractionate during 
exchange have no impact on atmospheric Delta14C and thus, only disequilibrium 
terms need to be considered. For example, photosynthetic uptake of CO2.

Thanks,

Katherine


On 12/02/2019, 10:58, "CF-metadata on behalf of Lowry, Roy K." 
 wrote:

Dear Jonathan,

Whilst I initially favoured relegating the standard to the long name, after 
a bit of thought and reading around I changed my mind. Whilst multiple 
standards may not be in use today, a number have been favoured at different 
times over the past 50 years. See for example


https://www.researchgate.net/publication/222399840_Future_needs_and_requirements_for_AMS_14C_standards_and_reference_materials

Consequently, I feel inclusion of the name of the standard in the Standard 
name is prudent.

I think I understand what the 13C normalisation is about, but I'll leave it 
to Katherine to explain in case I haven't got it exactly right.

Cheers, Roy.

-Original Message-
From: CF-metadata  On Behalf Of Jonathan 
Gregory
Sent: 12 February 2019 10:13
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Dear Katherine and Roy

Thanks for the information. I think enrichment is fine. Unlike Roy, I would 
favour not mentioning the standard (and likewise I would not mention pee dee 
belemnite in d13O) unless there is more than one standard routinely in use, so 
that we need to distinguish. Are there any others in this case?

I am curious to know what this means:
> The sample ratio is normalised to – 25 per mil delta13C (to correct for 
isotopic fractionation).
(although I understand Roy's remark that it doesn't affect the definition).

Best wishes

Jonathan


    ----- Forwarded message from "Lowry, Roy K."  -

> Date: Mon, 11 Feb 2019 16:05:13 +
> From: "Lowry, Roy K." 
> To: Katherine Pugsley , Alison Pamment -
> UKRI STFC , "cf-metadata@cgd.ucar.edu"
> 
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> Thanks Katherine,
>
> That looks a complete set of information to me.  I think we're all happy 
using 'enrichment'. Next issue to resolve is whether two items of information - 
the standard used and the delta13C normalisation - are built into the Standard 
Name or consigned to the Long Name.  I would argue that the normalisation is an 
experimental detail and policy has been not to include these in Standard Names. 
However, to me the standard u

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Dear Jonathan,

Whilst I initially favoured relegating the standard to the long name, after a 
bit of thought and reading around I changed my mind. Whilst multiple standards 
may not be in use today, a number have been favoured at different times over 
the past 50 years. See for example

https://www.researchgate.net/publication/222399840_Future_needs_and_requirements_for_AMS_14C_standards_and_reference_materials

Consequently, I feel inclusion of the name of the standard in the Standard name 
is prudent.

I think I understand what the 13C normalisation is about, but I'll leave it to 
Katherine to explain in case I haven't got it exactly right.

Cheers, Roy.

-Original Message-
From: CF-metadata  On Behalf Of Jonathan 
Gregory
Sent: 12 February 2019 10:13
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Dear Katherine and Roy

Thanks for the information. I think enrichment is fine. Unlike Roy, I would 
favour not mentioning the standard (and likewise I would not mention pee dee 
belemnite in d13O) unless there is more than one standard routinely in use, so 
that we need to distinguish. Are there any others in this case?

I am curious to know what this means:
> The sample ratio is normalised to – 25 per mil delta13C (to correct for 
> isotopic fractionation).
(although I understand Roy's remark that it doesn't affect the definition).

Best wishes

Jonathan


- Forwarded message from "Lowry, Roy K."  -

> Date: Mon, 11 Feb 2019 16:05:13 +0000
> From: "Lowry, Roy K." 
> To: Katherine Pugsley , Alison Pamment -
> UKRI STFC , "cf-metadata@cgd.ucar.edu"
> 
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> Thanks Katherine,
>
> That looks a complete set of information to me.  I think we're all happy 
> using 'enrichment'. Next issue to resolve is whether two items of information 
> - the standard used and the delta13C normalisation - are built into the 
> Standard Name or consigned to the Long Name.  I would argue that the 
> normalisation is an experimental detail and policy has been not to include 
> these in Standard Names. However, to me the standard used is a fundamental 
> attribute of what has been measured so I would go for its inclusion giving us:
>
>
> enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_
> 14C_in_carbon_dioxide_in_air
>
> Her'e a straw man for a definition
>
> Isotopic enrichment of 14C, sometimes called Delta14C or delta14C, is a 
> parameterisation of the 14C/12C isotopic ratio in the sample with respect to 
> the isotopic ratio in a standard, in this case the radiocarbon absolute 
> reference standard. It is computed using the formula (((14C/12C) sample / 
> (14C/12C) standard) - 1) * 1000.  If the sample is enriched in 14C then the 
> value is positive.
>
> Cheers, Roy.
>
>
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
> 
> From: Katherine Pugsley 
> Sent: 11 February 2019 14:33
> To: Alison Pamment - UKRI STFC; Lowry, Roy K.;
> cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
>
> Hi All,
>
>
>
> Thank you, Roy, Jonathon and Alison, for your feedback on this new standard 
> name.
>
>
>
> Some more information on how the measurements are made and calculated.
>
>
>
> Measurements are made using Accelerator Mass Spectrometry.
>
> Roy is correct Delta14C is calculated similar to delta13C.
>
> Delta14C = (((14C/12C) sample / (14C/12C) standard) - 1) * 1000 per mil in 
> accordance to Stuiver and Polach (1977).
>
> The standard this is calculated in relation to is the radiocarbon absolute 
> reference standard, Oxalic Acid I. The sample ratio is normalised to – 25 per 
> mil delta13C (to correct for isotopic fractionation).
>
>
>
> Either of the names Roy suggests
> (enrichment_of_14C_in_carbon_dioxide_in_air or
> delta14C_in_carbon_dioxide_in_air
>
> ) could work.
>
>
>
> Thanks,
>
>
>
> Katherine
>
>
>
> From: CF-metadata  on behalf of
> Alison Pamment - UKRI STFC 
> Date: Monday, 11 February 2019 at 12:59
> To: "r...@bodc.ac.uk" , "cf-metadata@cgd.ucar.edu"
> 
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
>
>
> Hi Roy,
>
>
>
> Okay, thank you for spotting that!
>
>
>
> Best wishes,
>
> Alison
>
>
>
> --
>
> Alison Pamment Tel: +44 1235 778065
>
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
>
> STFC Rutherford Appleton Laboratory
>
> R25, 2.22
>
> Harwell Oxford, Did

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Thanks Katherine,

That looks a complete set of information to me.  I think we're all happy using 
'enrichment'. Next issue to resolve is whether two items of information - the 
standard used and the delta13C normalisation - are built into the Standard Name 
or consigned to the Long Name.  I would argue that the normalisation is an 
experimental detail and policy has been not to include these in Standard Names. 
However, to me the standard used is a fundamental attribute of what has been 
measured so I would go for its inclusion giving us:

 
enrichment_with_respect_to_radiocarbon_absolute_reference_standard_of_14C_in_carbon_dioxide_in_air

Her'e a straw man for a definition

Isotopic enrichment of 14C, sometimes called Delta14C or delta14C, is a 
parameterisation of the 14C/12C isotopic ratio in the sample with respect to 
the isotopic ratio in a standard, in this case the radiocarbon absolute 
reference standard. It is computed using the formula (((14C/12C) sample / 
(14C/12C) standard) - 1) * 1000.  If the sample is enriched in 14C then the 
value is positive.

Cheers, Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: Katherine Pugsley 
Sent: 11 February 2019 14:33
To: Alison Pamment - UKRI STFC; Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2


Hi All,



Thank you, Roy, Jonathon and Alison, for your feedback on this new standard 
name.



Some more information on how the measurements are made and calculated.



Measurements are made using Accelerator Mass Spectrometry.

Roy is correct Delta14C is calculated similar to delta13C.

Delta14C = (((14C/12C) sample / (14C/12C) standard) - 1) * 1000 per mil in 
accordance to Stuiver and Polach (1977).

The standard this is calculated in relation to is the radiocarbon absolute 
reference standard, Oxalic Acid I. The sample ratio is normalised to – 25 per 
mil delta13C (to correct for isotopic fractionation).



Either of the names Roy suggests (enrichment_of_14C_in_carbon_dioxide_in_air or 
delta14C_in_carbon_dioxide_in_air

) could work.



Thanks,



Katherine



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Date: Monday, 11 February 2019 at 12:59
To: "r...@bodc.ac.uk" , "cf-metadata@cgd.ucar.edu" 

Subject: Re: [CF-metadata] New standard name for 14CO2



Hi Roy,



Okay, thank you for spotting that!



Best wishes,

Alison



--

Alison Pamment Tel: +44 1235 778065

NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk

STFC Rutherford Appleton Laboratory

R25, 2.22

Harwell Oxford, Didcot, OX11 0QX, U.K.



From: Lowry, Roy K. 
Sent: 11 February 2019 12:55
To: Pamment, Alison (STFC,RAL,RALSP) ; 
cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2



Hi Alison,



One slight misunderstanding. 'per mil' means parts per thousand not parts per 
million so the units should be written as '1e-3' rather than '1e-6'.



 Cheers, Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Alison Pamment - UKRI STFC 
mailto:alison.pamm...@stfc.ac.uk>>
Sent: 11 February 2019 12:49
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] New standard name for 14CO2



Dear Katherine, All,

Katherine and I had briefly discussed this name before it was proposed to the 
mailing list - the suggestion of using mole_fraction was originally mine.  
Evidently I had misunderstood the quantity in question, and it's clear from the 
discussion so far that it wouldn't be appropriate to use mole_fraction in this 
case. Thank you to Roy and Jonathan for clarifying this (and my apologies to 
Katherine for misleading advice - I've not come across this quantity before).

It does seem that we will need to introduce some new terminology into standard 
names. Of Roy's two suggestions I prefer 
enrichment_of_14C_in_carbon_dioxide_in_air. From Roy's explanation, it looks 
like the quantity is in effect a ratio of ratios. While I appreciate that this 
may be referred to as a 'delta' in the chemistry community, 'delta' is often 
used as a mathematical symbol for calculating a difference or change, so I feel 
that it's best avoided in the standard name.

Regarding the units of 'per mil', the canonical unit in the standard name table 
would be written as '1e-6'.

Whichever terminology we choose, certainly we do need a clear definition - in 
particular if the quantity is being calculated with reference to a particular 
standard we should include that in the information. Katherine, please could you 
give us some more details about exactly how this quantity is being 
measured/calculated in your data?

Best

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

Hi Alison,

One slight misunderstanding. 'per mil' means parts per thousand not parts per 
million so the units should be written as '1e-3' rather than '1e-6'.

 Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 11 February 2019 12:49
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Dear Katherine, All,

Katherine and I had briefly discussed this name before it was proposed to the 
mailing list - the suggestion of using mole_fraction was originally mine.  
Evidently I had misunderstood the quantity in question, and it's clear from the 
discussion so far that it wouldn't be appropriate to use mole_fraction in this 
case. Thank you to Roy and Jonathan for clarifying this (and my apologies to 
Katherine for misleading advice - I've not come across this quantity before).

It does seem that we will need to introduce some new terminology into standard 
names. Of Roy's two suggestions I prefer 
enrichment_of_14C_in_carbon_dioxide_in_air. From Roy's explanation, it looks 
like the quantity is in effect a ratio of ratios. While I appreciate that this 
may be referred to as a 'delta' in the chemistry community, 'delta' is often 
used as a mathematical symbol for calculating a difference or change, so I feel 
that it's best avoided in the standard name.

Regarding the units of 'per mil', the canonical unit in the standard name table 
would be written as '1e-6'.

Whichever terminology we choose, certainly we do need a clear definition - in 
particular if the quantity is being calculated with reference to a particular 
standard we should include that in the information. Katherine, please could you 
give us some more details about exactly how this quantity is being 
measured/calculated in your data?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.


-Original Message-
From: CF-metadata  On Behalf Of Jonathan 
Gregory
Sent: 11 February 2019 04:57
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name for 14CO2

Dear all

I agree with Roy that delta-14C is not a mole fraction, but a way of expressing 
the deviation of an isotopic ratio in a sample from a standard isotopic ratio.
The definition Roy gives for delta-13C is shown in several websites. I think we 
need the precise definition of the quantity being proposed, because there 
appear to be variou quantities with big and small delta and D, and maybe they 
are all different, and would need distinct standard names. I think Roy is right 
that we have not given standard names to such quantities before.

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Fri, 8 Feb 2019 12:55:31 +0000
> From: "Lowry, Roy K." 
> To: Katherine Pugsley ,
>"cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] New standard name for 14CO2
>
> I think that delta-14CO2 is not the same thing as the mole fraction. Rather, 
> it is an expression of isotopic enrichment/depletion with respect to a 
> standard. Whilst I have no experience of atmospheric 14C, I have come across 
> delta notation a lot with other isotopes in geology and oceanography such as 
> 13C and 18O. There, delta is an expression of the ratio of the target isotope 
> to another isotope in the sample relative to some standard - ((sample 13C/12C 
> ratio / standard 13C/12C ratio) - 1) * 1000 to give a result scaled to per 
> mil. I presume that delta-14C is no different.
>
> I am unaware (i.e. I couldn't find) a precedent for delta values in CF 
> Standard Names. The issue of describing these things has been addressed at 
> length in the BODC parameter descriptions with almost 400 measurement 
> descriptions. A typical example is:
>
> Enrichment with respect to Vienna Pee Dee Belemnite (VPDB) of
> carbon-13 in carbonate in the sediment
>
> This particular example includes information on the specific standard used. 
> Many do not because the information is often unavailable for older data.
>
> A straw man alternative to Kate's proposal could be
>
> enrichment_of_14C_in_carbon_dioxide_in_air
>
> If information on the standard is available then that could be added as an 
> 'enrichment_with_respect_to_whatever' clause or the information could be 
> confined to the long name. The better solution depends upon the use case 
> (e.g. does it require inclusion of data where standard is unknown).
>
> Another approach could be to adopt community vocabulary such as:
>
> delta14C_in_carbon_dioxide_in_air
>
>

Re: [CF-metadata] New standard name for 14CO2

[Lowry, Roy K.]

I think that delta-14CO2 is not the same thing as the mole fraction. Rather, it 
is an expression of isotopic enrichment/depletion with respect to a standard. 
Whilst I have no experience of atmospheric 14C, I have come across delta 
notation a lot with other isotopes in geology and oceanography such as 13C and 
18O. There, delta is an expression of the ratio of the target isotope to 
another isotope in the sample relative to some standard - ((sample 13C/12C 
ratio / standard 13C/12C ratio) - 1) * 1000 to give a result scaled to per mil. 
I presume that delta-14C is no different.

I am unaware (i.e. I couldn't find) a precedent for delta values in CF Standard 
Names. The issue of describing these things has been addressed at length in the 
BODC parameter descriptions with almost 400 measurement descriptions. A typical 
example is:

Enrichment with respect to Vienna Pee Dee Belemnite (VPDB) of carbon-13 in 
carbonate in the sediment

This particular example includes information on the specific standard used. 
Many do not because the information is often unavailable for older data.

A straw man alternative to Kate's proposal could be

enrichment_of_14C_in_carbon_dioxide_in_air

If information on the standard is available then that could be added as an 
'enrichment_with_respect_to_whatever' clause or the information could be 
confined to the long name. The better solution depends upon the use case (e.g. 
does it require inclusion of data where standard is unknown).

Another approach could be to adopt community vocabulary such as:

delta14C_in_carbon_dioxide_in_air

Others may have alternative suggestions.

I went for 'enrichment of x' in the BODC dictionary because it provides a 
better fit to a normalised semantic model for mapping purposes. One only has to 
include one 'enrichment' rather than a long list of 'deltas' in the semantic 
element.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Katherine 
Pugsley 
Sent: 08 February 2019 10:46
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New standard name for 14CO2


Dear All,

I'd like to request an addition to the standard name list for atmospheric 14CO2 
measurements. Here are the details of the proposed standard name.

Proposal for a new standard variable name

Name: mole_fraction_of_14C_dioxide_in_air

Canonical Units: 1

Description: Atmospheric 14CO2 measurements are reported in Δ14C notation with 
units of per mil, the deviation from the absolute radiocarbon reference 
standard. Δ14C is used to calculate fossil fuel CO2 content. The long name will 
contain information that the variable is Δ14C.



Thanks,

Katherine




This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CMIP6 Confusion regarding carbon flux units

[Lowry, Roy K.]

Dear Chris,

The embedding of semantics in units of measure is something I have fought 
against for decades, largely because software agent AI algorithms are unlikely 
to look for them there. Your suggestion is also something that would never get 
past the guardians of UDUNITS.

However, I can understand your frustration with vital semantics being buried in 
the long name. Might a better solution be to include the necessary semantics in 
the Standard Name? This has been done previously. For example:

surface_upward_mass_flux_of_carbon_dioxide_expressed_as_carbon_due_to_anthropogenic_land_use_or_land_cover_change_excluding_forestry_and_agricultural_products

sinking_mole_flux_of_calcite_expressed_as_carbon_in_sea_water

All in all a search for '%flux%expressed_as_carbon%' turned up 39 hits. There 
are other examples that include phrases like 'expressed as 13C'.

If you are using Standard Names that do not include the 'expressed_as' clause 
and no suitable alternatives with the clause exist then I would suggest that 
you put in a new Standard Name request.

Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata  on behalf of Jones, Chris 
D 
Sent: 31 January 2019 09:38
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] CMIP6 Confusion regarding carbon flux units


Dear Martin, dear All,



it is emerging that groups are making errors in implementing the carbon cycle 
data requests - especially regarding the units of carbon fluxes.



The issue is confusion over whether to report kg of CARBON or kg of CO2.



The intended correct answer is buried deep within the long name, where fluxes 
are described as, “…. flux of CO2 expressed as carbon …”. But unless you know 
where to look this is rather hidden and is resulting in groups mixing units of 
carbon and CO2 across variables.



So this is a request - actually a plea - that we revisit the decision to 
include the quantity in the units definition. I have heard the arguments that 
“kg C” is not an SI unit and we just need to explain it in the long name - but 
this is really not working and is causing real confusion and errors.



So PLEASE, PLEASE, can we re-define the labels for carbon fluxes and stores in 
terms of “kgC m-2 s-1” etc. ?



There has been such a massive effort to both define and implement this data 
request it would be a huge shame if substantial errors came in at the last 
minute - this small change will prevent that.



thanks,

Chris







--
Dr Chris Jones
Head, Earth System and Mitigation Science Team
Met Office Hadley Centre, FitzRoy Road, Exeter, EX1 3PB, U.K.
Tel: +44 (0)1392 884514  Fax: +44 (0)1392 885681
E-mail: chris.d.jo...@metoffice.gov.uk  
http://www.metoffice.gov.uk




This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Fw: [CF Metadata] #160: Proposal to use GitHub instead of trac

[Lowry, Roy K.]

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Lowry, Roy K.
Sent: 13 December 2018 18:31
To: cf-metadata-ow...@lists.llnl.gov
Subject: Re: [CF Metadata] #160: Proposal to use GitHub instead of trac


FYI


As far as Standard Names are concerned, what I need is an alert by e-mail (i.e. 
without my having to log into something) each time a new proposal/thread is 
generated with the option to either follow or ignore

(currently achieved by deleting e-mails without opening on the basis of 
subject) that thread.


I have no interest at all how this is achieved technologically.


Cheers, Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF Metadata 
Sent: 13 December 2018 17:37
Subject: Re: [CF Metadata] #160: Proposal to use GitHub instead of trac

#160: Proposal to use GitHub instead of trac
-+--
  Reporter:  jonathan|  Owner:  cf-conventions@…
  Type:  task| Status:  new
  Priority:  medium  |  Milestone:
 Component:  cf-conventions  |Version:
Resolution:  |   Keywords:
-+--

Comment (by jonathan):

 For info: at the moment, positings to !GitHub issues are not being
 distributed by email, unlike trac postings. The conventions committee is
 discussing how to proceed with this. Jonathan

--
Ticket URL: <https://cf-trac.llnl.gov/trac/ticket/160#comment:28>
#160 (Proposal to use GitHub instead of trac) – CF 
Metadata<https://cf-trac.llnl.gov/trac/ticket/160#comment:28>
cf-trac.llnl.gov
I agree that github is a good option, although I'd like to keep the email list 
available for standard name proposals. For some people, having to use github 
might be enough of a challenge that they'd simply bypass the process altogether.



CF Metadata <http://cf-convention.github.io/>
CF Metadata


This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard names for Dissolved Inorganic Nitrogen and Particulate Organic Nitrogen

[Lowry, Roy K.]

Dear Alison,


Whilst your addition follows precedents and is reasonable (if a little model 
rather than measurement oriented) for dissolved inorganic nitrogen where there 
are only three species (nitrate, nitrite and ammonium), it doesn't make sense 
for PON observations, which can include hundreds of compounds from groups such 
as amines, proteins, amino acids etc. Furthermore, this list of species is 
unlikely to be known.


Consequently, I would replace:


"Particulate organic nitrogen" is the term used in standard names for all 
species belonging to the family that are represented within a given model. The 
list of individual species that are included in a quantity having a group 
chemical standard name can vary between models. Where possible, the data 
variable should be accompanied by a complete description of the species 
represented, for example, by using a comment attribute.'


by


"organic nitrogen" when measured always refers to all nitrogen incorporated in 
carbon compounds in the sample. Models may use the term to refer to nitrogen 
contained in specific groups of organic compounds in which case the data 
variable should be accompanied by a complete description of the species 
represented, for example, by using a comment attribute.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Alison Pamment - UKRI STFC 
Sent: 10 December 2018 16:19
To: Lowry, Roy K.; Daniel Neumann; cf-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] New standard names for Dissolved Inorganic Nitrogen 
and Particulate Organic Nitrogen

Dear Daniel and Roy,

Thank you, Daniel, for proposing two new standard names. I agree with Roy that 
they should be a straight forward addition to the table.

I have added text into the first definition based on our existing 
dissolved_inorganic_nitrogen names (which is consistent with the text in the 
proposal):

mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_water (mol m-3)
'Mole concentration means number of moles per unit volume, also called 
"molarity", and is used in the construction "mole_concentration_of_X_in_Y", 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". "Inorganic nitrogen" describes a family of 
chemical species which, in an ocean model, usually includes nitrite, nitrate 
and ammonium which act as nitrogen nutrients. "Inorganic nitrogen" is the term 
used in standard names for all species belonging to the family that are 
represented within a given model. The list of individual species that are 
included in a quantity having a group chemical standard name can vary between 
models. Where possible, the data variable should be accompanied by a complete 
description of the species represented, for example, by using a comment 
attribute.'

For the second name I have again added a couple of general sentences at the end 
of the definition:

mole_concentration_of_particulate_organic_nitrogen_in_sea_water (mol m-3)
'Mole concentration means number of moles per unit volume, also called 
"molarity", and is used in the construction "mole_concentration_of_X_in_Y", 
where X is a material constituent of Y. A chemical or biological species 
denoted by X may be described by a single term such as "nitrogen" or a phrase 
such as "nox_expressed_as_nitrogen". "Particulate organic nitrogen" means the 
sum of all organic nitrogen compounds that are solid, or bound to solid 
particles. "Particulate organic nitrogen" is the term used in standard names 
for all species belonging to the family that are represented within a given 
model. The list of individual species that are included in a quantity having a 
group chemical standard name can vary between models. Where possible, the data 
variable should be accompanied by a complete description of the species 
represented, for example, by using a comment attribute.'

If you are happy with these, then I think both names can be accepted and 
included in the next standard name table update.

We haven't previously had a definition for particulate_organic_nitrogen, so I 
will add it to the one existing name, 
sinking_mole_flux_of_particulate_organic_nitrogen_in_sea_water:
'In accordance with common usage in geophysical disciplines, "flux" implies per 
unit area, called "flux density" in physics. 'Sinking' is the gravitational 
settling of particulate matter suspended in a liquid. A sinking flux is 
positive downwards and is calculated relative to the movement of the 
surrounding fluid. "Particulate organic nitrogen" means the sum of all organic 
nitrogen compounds that are solid, or bound to solid particles. "Partic

Re: [CF-metadata] Sea water temperature anomaly standard name

[Lowry, Roy K.]

Dear Roy,


I would suggest that this is more in scope for GitHub than a Standard Name 
discussion as changes to the Conventions document could be required. Why not 
take it forward there and see if you can engage some interest?


I also feel that this could take some time and do not feel it would be fair to 
block Simon's request until it is resolved. There are a number of anomaly 
Standard Names and one more isn't going to make a great deal of difference.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Roy Mendelssohn - NOAA Federal 
Sent: 05 December 2018 14:35
To: cf-metadata@cgd.ucar.edu
Cc: Lowry, Roy K.
Subject: Re: [CF-metadata] Sea water temperature anomaly standard name

Interesting.  Look at the archive around April 4, 2016.  I was requesting a 
standard way to do anomalies, not just variable specific,  since anomalies are 
calculated all over the place, and it seems to me it makes little sense to have 
a new name for each specific anomaly,  rather than a generic method based on an 
existing name.  Let us just day it was not greeted with open arms.  Perhaps 
this is worth revisiting.

-Roy M.

> On Dec 5, 2018, at 6:20 AM, Lowry, Roy K.  wrote:
>
> Hello Simon,
>
> If you look at the definition for 
> ocean_mixed_layer_thickness_defined_by_temperature you will get a better 
> understanding about what sea_water_temperature_difference is about. It is an 
> auxiliary co-ordinate variable used to specify the temperature change that 
> defines the base of a mixed layer. Consequently, it has nothing to do with 
> your requirements.
>
> So, you need a new Standard Name. I would suggest:
>
> sea_water_temperature_anomaly
> Canonical Unit degrees Kelvin (note actual units in data files can be deg C)
> 'anomaly' means difference from climatology. Sea water temperature is the in 
> situ temperature within a water body.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
>
> From: CF-metadata  on behalf of Good, Simon 
> 
> Sent: 05 December 2018 13:12
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] Sea water temperature anomaly standard name
>
> Hello,
>
> I am generating some data that is the difference between a variable with 
> standard name sea_water_temperature and a climatology and I am not sure what 
> to use for the standard_name. There is an existing standard name 
> sea_water_temperature_difference but I am not sure if this is supposed to be 
> used to represent anomalies as the description of it is very brief. There are 
> a few other variables that have standard names defined for anomalies e.g. 
> air_temperature_anomaly, but there is currently no 
> sea_water_temperature_anomaly. I also checked the standard name modifiers as 
> I thought that anomaly might be included in those, but it is not currently. 
> Please could you advise on what I should use and if necessary request that it 
> be added to the list of standard names?
>
> Many thanks,
>
> Simon Good
>
>
>
>
> This email and any attachments are intended solely for the use of the named 
> recipients. If you are not the intended recipient you must not use, disclose, 
> copy or distribute this email or any of its attachments and should notify the 
> sender immediately and delete this email from your system.
> UK Research and Innovation has taken every reasonable precaution to minimise 
> risk of this email or any attachments containing viruses or malware but the 
> recipient should carry out its own virus and malware checks before opening 
> the attachments. UK Research and Innovation does not accept any liability for 
> any losses or damages which the recipient may sustain due to presence of any 
> viruses.
> Opinions, conclusions or other information in this message and attachments 
> that are not related directly to UK Research and Innovation business are 
> solely those of the author and do not represent the views of UK Research and 
> Innovation.
>
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."

Re: [CF-metadata] Sea water temperature anomaly standard name

[Lowry, Roy K.]

Hello Simon,


If you look at the definition for 
ocean_mixed_layer_thickness_defined_by_temperature you will get a better 
understanding about what sea_water_temperature_difference is about. It is an 
auxiliary co-ordinate variable used to specify the temperature change that 
defines the base of a mixed layer. Consequently, it has nothing to do with your 
requirements.


So, you need a new Standard Name. I would suggest:


sea_water_temperature_anomaly

Canonical Unit degrees Kelvin (note actual units in data files can be deg C)

'anomaly' means difference from climatology. Sea water temperature is the in 
situ temperature within a water body.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Good, Simon 

Sent: 05 December 2018 13:12
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] Sea water temperature anomaly standard name


Hello,



I am generating some data that is the difference between a variable with 
standard name sea_water_temperature and a climatology and I am not sure what to 
use for the standard_name. There is an existing standard name 
sea_water_temperature_difference but I am not sure if this is supposed to be 
used to represent anomalies as the description of it is very brief. There are a 
few other variables that have standard names defined for anomalies e.g. 
air_temperature_anomaly, but there is currently no 
sea_water_temperature_anomaly. I also checked the standard name modifiers as I 
thought that anomaly might be included in those, but it is not currently. 
Please could you advise on what I should use and if necessary request that it 
be added to the list of standard names?



Many thanks,



Simon Good






This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New standard names for Dissolved Inorganic Nitrogen and Particulate Organic Nitrogen

[Lowry, Roy K.]

Hi Daniel,


These look straightforward to me and would be a useful addition.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Daniel 
Neumann 
Sent: 22 November 2018 09:08
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New standard names for Dissolved Inorganic Nitrogen and 
Particulate Organic Nitrogen

Dear all,

I would like to propose two new standard names:

mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_water
mole_concentration_of_particulate_organic_nitrogen_in_sea_water

A similar standard name for "dissolved inorganic phosphorus" exists
already. Moreover, a few tendency/flux standard names exist for
"dissolved inorganic nitrogen" and "particulate organic nitrogen". The
descriptions and units are given below.

Regards,
Daniel


name:
mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_water

description:
Mole concentration means number of moles per unit volume, also called
"molarity", and is used in the construction
"mole_concentration_of_X_in_Y", where X is a material constituent of Y.
A chemical or biological species denoted by X may be described by a
single term such as "nitrogen" or a phrase such as
"nox_expressed_as_nitrogen". "Dissolved inorganic nitrogen" means the
sum of all inorganic nitrogen in solution (including nitrate, ammonia,
and nitrite).

unit:
mol m-3


name:
mole_concentration_of_particulate_organic_nitrogen_in_sea_water

description:
Mole concentration means number of moles per unit volume, also called
"molarity", and is used in the construction
"mole_concentration_of_X_in_Y", where X is a material constituent of Y.
A chemical or biological species denoted by X may be described by a
single term such as "nitrogen" or a phrase such as
"nox_expressed_as_nitrogen". "Particulate organic nitrogen" means the
sum of all organic nitrogen compounds, which are solid or which are
bound to solid particles.

unit:
mol m-3



--
Daniel Neumann

Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany

phone:  +49-381-5197-287
fax:+49-381-5197-114 or 440
e-mail: daniel.neum...@io-warnemuende.de




This email and any attachments are intended solely for the use of the named 
recipients. If you are not the intended recipient you must not use, disclose, 
copy or distribute this email or any of its attachments and should notify the 
sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise 
risk of this email or any attachments containing viruses or malware but the 
recipient should carry out its own virus and malware checks before opening the 
attachments. UK Research and Innovation does not accept any liability for any 
losses or damages which the recipient may sustain due to presence of any 
viruses.
Opinions, conclusions or other information in this message and attachments that 
are not related directly to UK Research and Innovation business are solely 
those of the author and do not represent the views of UK Research and 
Innovation.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 'years since' time units

[Lowry, Roy K.]

Dear Dave,


I see no problem with CF incorporating external standards such as UDUNITS 
providing that standard is adequately maintained (e.g. addition of new 
concepts) and supported by its governance through the provision of tools. In my 
opinion UDUNITS governance makes the grade. Indeed, it was a tool development 
query by UDUNITS that kicked off this thread and Martin's suggestion is to 
contact UDUNITS governance which I'm sure won't be ignored.


The alternative would be for CF to set up its own controlled vocabulary for 
units of measure. Even if the resources to do this could be secured I feel it 
would be a terrible waste.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of David 
Blodgett 
Sent: 26 October 2018 01:31
To: Martin Juckes - UKRI STFC
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] [CF-metadar ata] [EXTERNAL] 'months since' and 
'years since' time units

Dear Martin,

I'll leave it to others to argue the merits of various solutions. My aim was to 
point out that this problem is solved by prominent software which does 
basically what you describe. We could quibble about the concept of time and 
date being different, but given that this problem has a clear solution, I don't 
really care to. One way or another we will need to introduce the complexity of 
an additional way of discretizing a temporal axis that is based on cyclic 
calendar days/months/years rather than continuous seconds increments of time 
that add up to days months and years in nuanced ways depending on the time of 
year or leap-cycle.

Your suggested path -- work with the UDUNITS community to define this new type 
of timeline unit -- make very good sense.

I would like to clarify my point about UDUNITS being relied on. The parallel 
would be reliance on EPSG codes for projection parameters. A UDUNITS string is 
completely opaque to software that ONLY knows CF. By my understanding of CF, 
this breaks the rules by not fully describing the concept within the 
specification. I'm not complaining, I think it was the right decision to use an 
external source for units of measure -- I'm just pointing out the inconsistency 
relative to other aspects of the specification.

- Dave

> On Oct 25, 2018, at 7:37 AM, Martin Juckes - UKRI STFC 
>  wrote:
>
> Dear David, Lars,
>
>
> I'm afraid I do have a couple of reservations, though I understand the 
> motivation for trying to support this kind of information in the convention.
>
>
> My main concern is that "time" is a very important concept and it is distinct 
> from "date". Time has a very precise meaning which is recognised across 
> scientific domains. I recognise that it may be used interchangeably with 
> "date" in many contexts, but the CF convention is built on precisely defined 
> terms, so I feel it would be counter-productive to broaden our concept of 
> "time" to include "date". On the other hand, introducing a new CF name of 
> "date"  would make it possible to introduce the sort of information that you 
> are talking about.
>
>
> My 2nd concern is the suggestion that we should relax the current 
> specification of "units", which allows the comprehensive UDUNITS package to 
> be used when comparing variables without different units. I'm puzzled by your 
> suggestion the UDUNITS is opaque ... it looks like a pretty well maintained 
> library to me. Their definition of "year" as a "tropicalyear" agrees with the 
> GNU units library. I can't see why the information you want has to go in the 
> "units" attribute (I'm sorry if I have missed your explanation on this 
> point). There are two alternatives which I would prefer:
>
>
> (1) try to persuade UDUNITS to accept calendar_year and calendar_month as 
> units of "date", or perhaps "calendar_time". I don't think it would be worth 
> trying to persuade them to add these of units of "time", because, as Karl has 
> mentioned, they are not convertible in the same way other time units are. As 
> units of "calendar_time", however, they would fit perfectly well into the 
> UNIDATA and CF model.
>
>
> (2) place the information in a different attribute. This is clearly a new 
> concept for the convention, so it would be reasonably to add a new attribute.
>
>
> I think option (1) is worth trying, it would give a cleaner end result,
>
>
> regards,
>
> Martin
>
>
>
>
>
>
> 
> From: CF-metadata  on behalf of David 
> Blodgett 
> Sent: 21 October 2018 13:30
> To: Bärring Lars
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] [EXTERNAL] 'months since' and 'years since' time 
> units
>
> Dear Lars,
>
> Yes. I think we are in agreement. It seems odd to me that CF relies so 
> heavily on UDUNITS given the emphasis on non-opaque metadata in the spec 
> generally.
>
> So the relevant section is here:
> 

Re: [CF-metadata] 'months since' and 'years since' time units

[Lowry, Roy K.]

Dear Jeff,


I see a possibility for confusion here. Whilst the meaning of 'month' as 30 
days is well understood within the 360-day calendar community, others from 
outside that community could easily use 'months since' expecting it to mean 
365.242198781/12.  Would it be possible to use a more explicit label like '30 
day months since'?


I appreciate when suggesting this that I'm not aware of the history of 'months 
since' in UDUNITS and have no idea how deeply embedded it is out in the wild 
and therefore of its consequences.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Ryan 
Abernathey 
Sent: 17 October 2018 20:22
To: whitaker.jeff...@gmail.com
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] 'months since' and 'years since' time units

Hi everyone,

I am that user, and I'm new to this mailing list. Thank you all for your work 
on CF conventions. It's such a valuable effort!

I want to note that this was inspired by the proliferation of datasets in the 
wild that use "month" as their units. For example, nearly all of the IRI Data 
Library does this, in conjunction with a 3"60_day" calendar (example: 
https://iridl.ldeo.columbia.edu/SOURCES/.NOAA/.NCEP-NCAR/.CDAS-1/.MONTHLY/.Diagnostic/.surface/.temp/).
data: NOAA NCEP-NCAR CDAS-1 MONTHLY Diagnostic surface temp 

iridl.ldeo.columbia.edu
MONTHLY Diagnostic surface Temperature from NOAA NCEP-NCAR CDAS-1: Climate Data 
Assimilation System I; NCEP-NCAR Reanalysis Project. Resolution: 
1.875x1.904128; Longitude: global; Latitude: global; Time: [Jan 1949,Sep 2018]; 
monthly



My impression from talking to data providers is that no one is using "360_day" 
calendar and "months" as units, and then expecting "months" to be interpreted 
as 365.242198781/12 days. They all expect it to be interpreted as 30 days. 
While there are various workarounds that can be used at different levels of the 
software stack, the best solution, IMHO, is to explicitly allow in CF 
conventions what Jeff proposed: "months and years be interpreted as calendar 
months and years for those calendars where they have a fixed length". I don't 
think this will break existing applications.

Thanks,
Ryan

On Wed, Oct 17, 2018 at 3:06 PM Jeffrey Whitaker 
mailto:whitaker.jeff...@gmail.com>> wrote:
Hi:  I'm a developer of the 'cftime' python package 
(https://github.com/Unidata/cftime).  A user submitted a pull request 
(https://github.com/Unidata/cftime/pull/69) that implements support for a 
30-day calendar month time unit for the '360_day' CF calendar.  Although using 
a 'month' time unit is a tricky proposition in general, for this calendar it 
seems straightforward since every month has the same length.  However, in the 
discussion of the pull request it was pointed out that CF expects  that "the 
value of the units attribute is a string that can be recognized by UNIDATA’s 
Udunits package", and that UDUNITS defines a month as 365.242198781/12 days.
My question is this - is it reasonable for our python package to make an 
exception to this rule for the 360_day calendar?  More generally, can months 
and years be interpreted as calendar months and years for those calendars where 
they have a fixed length, or will this deviate from the existing CF conventions 
and break existing applications?

Regards, Jeff

--
Jeffrey S. Whitaker
NOAA/OAR/PSD  R/PSD1
325 Broadway, Boulder, CO, 80305-3328
Phone: (303)497-6313
FAX: (303)497-6449

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Alison,


I have read through the definitions and can see no errors.


As always when doing this, one sees possible 'improvements' but these are not 
critical and so are best kept to myself or we will never reach end game with 
this proposal.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 03 October 2018 18:10
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Platform Heave

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" instead of "may not" as I think the latter could sound like we are 
prohibiting the inclusion of changes to the "at rest" position, which I don't 
think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the 
link to check through the full list. N.B. You can refine the filters to view 
smaller subsets of names together, e.g., 'platform_sway'. If no objections or 
suggestions for further changes are received, the names will be accepted in 
their current form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New name: fugacity of CO2

[Lowry, Roy K.]

Dear All,


I'm happy with James's updated sentence. It says the same thing but is clearer. 
Once the fCO2 name has been added we could consider using it to upgrade other 
partial pressure definitions.


I think the last sentence is there to conform to a definition pattern that 
includes some less familiar substances. I'm equally happy with it or without it.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of James Orr 

Sent: 05 October 2018 14:26
To: Alison Pamment - UKRI STFC
Cc: 'Halloran, Paul'; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New name: fugacity of CO2

Hi Allison, Paul, Roy, et al.,

I would suggest to replace the 3rd sentence

"The partial pressure of a gaseous constituent of air is the pressure which it
alone would exert with unchanged temperature and number of moles per unit
volume."

with the following:

"The partial pressure of a gaseous constituent of air is the pressure that it
would exert if all other gaseous constituents were removed, assuming the volume,
the temperature, and its number of moles remain unchanged."

The description would then become as follows:

'The fugacity is the measured pressure (or partial pressure) of a real gas
corrected for the intermolecular forces of that gas, which allows that corrected
quantity to be treated like the pressure of an ideal gas in the ideal gas
equation PV = nRT. The partial pressure of a dissolved gas in sea water is the
partial pressure in air with which it would be in equilibrium. The partial
pressure of a gaseous constituent of air is the pressure that it would exert if
all other gaseous constituents were removed, assuming the volume, the
temperature, and its number of moles remain unchanged. The chemical formula for
carbon dioxide is CO2.'

In addition, is the last sentence useful given that it is common knowledge?

Thanks,

Jim

On Thu, 4 Oct 2018, Alison Pamment - UKRI STFC wrote:

> Dear Paul,
>
> Thank you for proposing this new standard name and thanks also to Roy, Jim 
> and Jonathan for their comments.
>
> I think the proposal as it now stands is:
> fugacity_of_carbon_dioxide_in_sea_water (Canonical units: Pa)
> 'The fugacity is the measured pressure (or partial pressure) of a real gas 
> corrected for the intermolecular forces of that gas, which allows that 
> corrected quantity to be treated like the pressure of an ideal gas in the 
> ideal gas equation PV = nRT. The partial pressure of a dissolved gas in sea 
> water is the partial pressure in air with which it would be in equilibrium. 
> The partial pressure of a gaseous constituent of air is the pressure which it 
> alone would exert with unchanged temperature and number of moles per unit 
> volume. The chemical formula for carbon dioxide is CO2.'
>
> Paul, please can you confirm if this is all okay? If so, I think the name can 
> be accepted and included in the next update to the table.
>
> Best wishes,
> Alison
>
> --
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
>
> -Original Message-
> From: CF-metadata  On Behalf Of Halloran, 
> Paul
> Sent: 26 September 2018 12:59
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New name: fugacity of CO2
>
> Thanks very much Jim.
>
> Just to clarify (in light of Jim’s second point), my argument around air-sea 
> CO2 flux which I put forward to support my suggestion that we include 
> fugacity is that an imprecise conversion from fugacity of CO2 to pCO2 to 
> allow one to submit data as a compliant netcdf (due to potentially not having 
> the the other required variables available at the correct frequency), while 
> likely to only result in small numerical errors could have bigger 
> implications if then used to calculate air-sea CO2 flux.
>
> Thanks,
> Paul
>
>> Hi Paul, Roy, et al.,
>>
>> A couple of points regarding fugacity.
>>
>> 1) In the proposed definition of fugacity, the first sentence could be
>> misunderstood.  I suggest changing it to the following:
>>
>> The fugacity is the measured pressure (or partial pressure) of a real
>> gas corrected for the intermolecular forces of that gas, which allows
>> that corrected quantity to be treated like the pressure of an ideal
>> gas in the ideal gas equation PV = nRT.
>>
>> 2) The air-sea flux of a gas does not depend on its fugacity, only its
>> partial pressure (i.e., in both the atmosphere and ocean).
>>
>> Cheers,
>>
>> Jim
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
CF-metadata Info Page - 
mailman.cgd.ucar.edu
mailman.cgd.ucar.edu

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jim,


Currents are measured by attaching one or more current meters along a rope 
suspended in the water body known as the mooring. Established practice is to 
call the current meters the instruments and the mooring the platform. As 
current meters have developed, some have been fitted with orientation sensors.  
Nan's concern, which  I share, was to be sure that orientation data from 
current meters (which everybody in oceanography I know thinks of as 
instruments) were covered by the new Standard Name definitions.


There are other examples I can think of where oceanographic equipment commonly 
regarded as instruments measure orientation and/or motion relative to a local 
CRS.


Cheers, Roy


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 03 October 2018 20:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Alison,

It all looks good to me. I must confess that I didn't give the definitions a 
super-careful reading.

I have a question, but I don't want it to derail anything. I'd just like to 
understand the thought.

We have included instrument as a type of platform per Nan's request, but in the 
areas I have worked in an instrument is always mounted on something, so I don't 
consider it to be an example of a platform. I'd consider the thing the 
instrument is mounted on as the platform. Is it common in other disciplines to 
think of instruments as free-standing (or floating or flying)?

Grace and peace,

Jim

On 10/3/18 1:10 PM, Alison Pamment - UKRI STFC wrote:

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" instead of "may not" as I think the latter could sound like we are 
prohibiting the inclusion of changes to the "at rest" position, which I don't 
think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the 
link to check through the full list. N.B. You can refine the filters to view 
smaller subsets of names together, e.g., 'platform_sway'. If no objections or 
suggestions for further changes are received, the names will be accepted in 
their current form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: 
alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
[CICS-NC]  Visit us on
Facebook    Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC 
North Carolina State University 
NOAA National Centers for Environmental Information 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Alison,


I'll give these a final careful read through early next week.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Alison 
Pamment - UKRI STFC 
Sent: 03 October 2018 18:10
To: CF-metadata (cf-metadata@cgd.ucar.edu)
Subject: [CF-metadata] Platform Heave

Dear Jim, Roy, Nan, Jonathan, et al.,

I have drawn together what I hope is the final list for the platform names.

We seem to be agreed on the need to have triplets of names to cope with 
opposite sign conventions and the case where the sign convention is unknown. 
I've followed Roy's comment 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020540.html regarding 
cross-referencing in the definitions, i.e. adding the statement to only choose 
the unsigned names if the convention is truly unknown. I plan to create aliases 
for some of the existing names as follows:
platform_yaw_angle -> platform_yaw
platform_pictch_angle -> platform_pitch
platform_roll_angle > platform_roll
to make them consistent with the new names. In addition to Jim's 12th September 
proposals (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html), 
new names for platform_sway, platform_sway_rate, platform_surge and 
platform_surge_rate are needed to provide complete triplets of names for all 
the quantities.

The definitions of the new quantities are all based on Jim's text, with the 
'platform' description moved to the end. 'Instrument' has been added to the 
list of platforms as I think this was requested by Nan earlier in the 
discussion. (I think we can regard an 'instrument' as a way to mount one or 
more 'sensors'). The definitions of all existing platform names will be updated 
for consistency.

On a grammatical point, I noticed that the definitions of yaw/pitch/roll/surge 
rate in Jim's message all said "Yaw/pitch/roll/surge rate *might not* include 
changes to the "at rest" position of the platform ..." whereas the definitions 
of sway/heave rate said "Sway/heave rate *may not* include changes to the "at 
rest" position of the platform ...". I have changed all the definitions to say 
"might not" instead of "may not" as I think the latter could sound like we are 
prohibiting the inclusion of changes to the "at rest" position, which I don't 
think is the intention. Please correct me if this is wrong!

I have added all the names into the standard names editor: 
http://cfeditor.ceda.ac.uk/proposals/1?status=active=platform=+and+display=Filter.
 To save copying and pasting all the text into this message, please use the 
link to check through the full list. N.B. You can refine the filters to view 
smaller subsets of names together, e.g., 'platform_sway'. If no objections or 
suggestions for further changes are received, the names will be accepted in 
their current form and published on 15th October.

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Spectral wave direction spread parameter

[Lowry, Roy K.]

Dear All,


I should have added that this proposal fills a clear gap in the set of wave 
Standard Names.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Lowry, Roy K. 

Sent: 28 September 2018 15:05
To: Jonathan Gregory; Rob Thomas
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Spectral wave direction spread parameter


Dear Jonathan,


I seem to remember the 'what is spread' discussion coming up last time we 
encountered wave directional spread Standard Names. The Standard Name 
sea_surface_wave_directional_spread has the definition:


Directional spread is the (one-sided) directional width within a given 
sub-domain of the wave directional spectrum, S(t,x,y,f,theta) where t is time, 
x and y are horizontal coordinates (such as longitude and latitude), f is 
frequency and theta is direction. For a given mean wave (beam) direction the 
quantity approximates half the root mean square width about the beam axis, as 
derived either directly from circular moments or via the Fourier components of 
the wave directional spectrum.


This seems to have been omitted from Rob's definition, which should I think 
read:


The quantity with the Standard  Name 
sea_surface_wave_directional_spread_at_variance_spectral_density_maximum is the 
directional spread of the most energetic waves. Directional spread is the 
(one-sided) directional width within a given sub-domain of the wave directional 
spectrum, S(t,x,y,f,theta) where t is time, x and y are horizontal coordinates 
(such as longitude and latitude), f is frequency and theta is direction. For a 
given mean wave (beam) direction the quantity approximates half the root mean 
square width about the beam axis, as derived either directly from circular 
moments or via the Fourier components of the wave directional spectrum.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 28 September 2018 13:26
To: Rob Thomas
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Spectral wave direction spread parameter

Dear Rob

>From the responses it's clear we need a name for this. I'm a bit nervous about
"spread", which sounds vague to me. Can you clarify it?

Best wishes and thanks

Jonathan

On Fri, Sep 28, 2018 at 07:47:51AM +, Rob Thomas wrote:
> Date: Fri, 28 Sep 2018 07:47:51 +
> From: Rob Thomas 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] Spectral wave direction spread parameter
>
> Hi,
>
>
>
> Please can I propose/request a new standard name for the list:
> "sea_surface_wave_directional_spread_at_variance_spectral_density_maximum"
>
>
>
> The rationale for this request is that in assessing our mappings of spectral 
> wave parameters to the CF standard names we have mapped "Peak Direction" 
> (described as "Dirp Direction for waves at peak of wave energy spectrum from 
> which the waves are coming") to 
> "sea_surface_wave_from_direction_at_variance_spectral_density_maximum" with 
> definition:
>
>
> The quantity with standard name 
> sea_surface_wave_from_direction_at_variance_spectral_density_maximum is the 
> direction from which the most energetic waves are coming. The spectral peak 
> is the most energetic wave in the total wave spectrum. The phrase 
> "from_direction" is used in the construction X_from_direction and indicates 
> the direction from which the velocity vector of X is coming. The direction is 
> a bearing in the usual geographical sense, measured positive clockwise from 
> due north. The wave directional spectrum can be written as a five dimensional 
> function S(t,x,y,f,theta) where t is time, x and y are horizontal coordinates 
> (such as longitude and latitude), f is frequency and theta is direction. S 
> has the standard name sea_surface_wave_directional_variance_spectral_density. 
> S can be integrated over direction to give S1= integral(S dtheta) and this 
> quantity has the standard name sea_surface_wave_variance_spectral_density.
>
>
>
> It does not appear there is an appropriate partner term for Peak Spread 
> (described as "Dsprp Directional spread of waves at peak of wave energy 
> spectrum") because the options currently available do not appear to tie in to 
> the peak wave energy spectrum/spectral peak information.
>
>
>
> Kind regards,
>
> Rob
>
>
>
> Dr. Rob Thomas
>
> Senior Data Analyst - European Data Management Projects Team Leader
>
>
>
> Marine Institute, Rinville, Oranmore, County Galway, H91 R673, Ireland
>
> Tel: (+)353

Re: [CF-metadata] Spectral wave direction spread parameter

[Lowry, Roy K.]

Dear Jonathan,


I seem to remember the 'what is spread' discussion coming up last time we 
encountered wave directional spread Standard Names. The Standard Name 
sea_surface_wave_directional_spread has the definition:


Directional spread is the (one-sided) directional width within a given 
sub-domain of the wave directional spectrum, S(t,x,y,f,theta) where t is time, 
x and y are horizontal coordinates (such as longitude and latitude), f is 
frequency and theta is direction. For a given mean wave (beam) direction the 
quantity approximates half the root mean square width about the beam axis, as 
derived either directly from circular moments or via the Fourier components of 
the wave directional spectrum.


This seems to have been omitted from Rob's definition, which should I think 
read:


The quantity with the Standard  Name 
sea_surface_wave_directional_spread_at_variance_spectral_density_maximum is the 
directional spread of the most energetic waves. Directional spread is the 
(one-sided) directional width within a given sub-domain of the wave directional 
spectrum, S(t,x,y,f,theta) where t is time, x and y are horizontal coordinates 
(such as longitude and latitude), f is frequency and theta is direction. For a 
given mean wave (beam) direction the quantity approximates half the root mean 
square width about the beam axis, as derived either directly from circular 
moments or via the Fourier components of the wave directional spectrum.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 28 September 2018 13:26
To: Rob Thomas
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Spectral wave direction spread parameter

Dear Rob

>From the responses it's clear we need a name for this. I'm a bit nervous about
"spread", which sounds vague to me. Can you clarify it?

Best wishes and thanks

Jonathan

On Fri, Sep 28, 2018 at 07:47:51AM +, Rob Thomas wrote:
> Date: Fri, 28 Sep 2018 07:47:51 +
> From: Rob Thomas 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: [CF-metadata] Spectral wave direction spread parameter
>
> Hi,
>
>
>
> Please can I propose/request a new standard name for the list:
> "sea_surface_wave_directional_spread_at_variance_spectral_density_maximum"
>
>
>
> The rationale for this request is that in assessing our mappings of spectral 
> wave parameters to the CF standard names we have mapped "Peak Direction" 
> (described as "Dirp Direction for waves at peak of wave energy spectrum from 
> which the waves are coming") to 
> "sea_surface_wave_from_direction_at_variance_spectral_density_maximum" with 
> definition:
>
>
> The quantity with standard name 
> sea_surface_wave_from_direction_at_variance_spectral_density_maximum is the 
> direction from which the most energetic waves are coming. The spectral peak 
> is the most energetic wave in the total wave spectrum. The phrase 
> "from_direction" is used in the construction X_from_direction and indicates 
> the direction from which the velocity vector of X is coming. The direction is 
> a bearing in the usual geographical sense, measured positive clockwise from 
> due north. The wave directional spectrum can be written as a five dimensional 
> function S(t,x,y,f,theta) where t is time, x and y are horizontal coordinates 
> (such as longitude and latitude), f is frequency and theta is direction. S 
> has the standard name sea_surface_wave_directional_variance_spectral_density. 
> S can be integrated over direction to give S1= integral(S dtheta) and this 
> quantity has the standard name sea_surface_wave_variance_spectral_density.
>
>
>
> It does not appear there is an appropriate partner term for Peak Spread 
> (described as "Dsprp Directional spread of waves at peak of wave energy 
> spectrum") because the options currently available do not appear to tie in to 
> the peak wave energy spectrum/spectral peak information.
>
>
>
> Kind regards,
>
> Rob
>
>
>
> Dr. Rob Thomas
>
> Senior Data Analyst - European Data Management Projects Team Leader
>
>
>
> Marine Institute, Rinville, Oranmore, County Galway, H91 R673, Ireland
>
> Tel: (+)353 (0)91 387 409
>
> Mob: (+)353 (0)87 952 3467
>
> Email: rob.tho...@marine.ie
>
> ORCID: -0001-6068-4924
>
> Web: http://data.marine.ie/
data.marine.ie - Marine Environment
data.marine.ie
Marine Environment The investigation of Marine environments, Open Ocean, 
deep-sea, estuarine, coastal and near-shore zones and mans’ impact on these 
areas.




> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] New name: fugacity of CO2

[Lowry, Roy K.]

Dear Paul,


I'm pretty sure the Canonical Unit should be Pascal, as with the existing 
partial pressure Standard Names. Note that this doesn't mean the data need to 
be in Pascals, it is just a way of expressing dimensionality in terms of SI. 
There is a field for the actual units of measure in the parameter attributes.


There are existing partial pressure Standard Names for CO2 and CH4, with 
partial pressure defined using the following text.


The partial pressure of a dissolved gas in sea water is the partial pressure in 
air with which it would be in equilibrium. The partial pressure of a gaseous 
constituent of air is the pressure which it alone would exert with unchanged 
temperature and number of moles per unit volume.


What is needed for fugacity is this with a description of the difference 
between partial pressure and fugacity.  What do you think of the following?


Fugacity is the equivalent for a real gas to partial pressure for an ideal gas. 
The partial pressure of a dissolved gas in sea water is the partial pressure in 
air with which it would be in equilibrium. The partial pressure of a gaseous 
constituent of air is the pressure which it alone would exert with unchanged 
temperature and number of moles per unit volume.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Halloran, 
Paul 
Sent: 20 September 2018 16:40
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] New name: fugacity of CO2

Dear mailing list,

I would like to propose a new standard name: 
‘fugacity_of_carbon_dioxide_in_sea_water’
Variable name: fCO2
Units: μatm
Definition: The fugacity of CO2 is its effective partial pressure.

Thanks for your consideration of this,
Paul
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
CF-metadata Info Page - 
mailman.cgd.ucar.edu
mailman.cgd.ucar.edu
This is an unmoderated list for discussions about interpretation, 
clarification, and proposals for extensions or change to the CF conventions.




This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jonathan,


I totally agree that creation of new unsigned datasets should be strongly 
discouraged, but disagree with the deprecation and creation of new Standard 
Names for two reasons.


First, the creation of the new names is more likely to encourage the new data 
sets without the sign convention - new names give the impression that they are 
acceptable. Adding the cross-referencing text to the existing Standard Name 
definitions, making it clear that their use is not best practice seems a much 
better strategy to me.


Secondly, it causes the pain of going through and editing existing file stock 
for very little gain. Remember the number of files affected could easily run 
into thousands and significant workload results from overheads such as version 
management.


Cheers, Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 20 September 2018 16:16
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear Alison

If it's necessary to have names for unsigned quantities because it's really
not known, then I agree we should, but I think we ought strongly to discourage
recording of data without a sign convention. Maybe we could introduce new
names (with the existing ones as aliases) that explicitly say "unknown sign"
in them, in some way, with definitions that say they shouldn't be used if the
sign is known.

Best wishes

Jonathan

- Forwarded message from Alison Pamment - UKRI STFC 
 -

> Date: Thu, 20 Sep 2018 14:59:51 +
> From: Alison Pamment - UKRI STFC 
> To: "r...@bodc.ac.uk" , "cf-metadata@cgd.ucar.edu"
>, "ngalbra...@whoi.edu"
>
> Subject: Re: [CF-metadata] Platform Heave
>
> Dear Nan and Roy,
>
> In fact I had neglected to consider the case when the sign is unknown or 
> unrecorded. I am used to thinking about model data, where the sign of a 
> quantity is always known, but I appreciate that things may be different in 
> the world of observations! Nan's suggestion of retaining the current names 
> and also adding the pairs of new signed names would cover all possibilities 
> and fits within the existing schema for the standard name table. (If we go 
> down this route then I think we should still create aliases for the existing 
> names to remove the word 'angle' for consistency with the new names).
>
> As you both point out, the definitions could be written to cross-reference 
> the signed and unsigned names so that CF users are directed to the most 
> appropriate name for their data. The appropriate NVS mappings could certainly 
> also be created.
>
> I agree with Roy that we should allow for signed (and unsigned) rates, again 
> with appropriate cross-references in the definitions.
>
> Do others support the idea of having triplets of names in this way?
>
> Best wishes,
> Alison
>
> --
> Alison Pamment Tel: +44 1235 778065
> NCAS/Centre for Environmental Data ArchivalEmail: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Oxford, Didcot, OX11 0QX, U.K.
>
> From: CF-metadata  On Behalf Of Lowry, Roy 
> K.
> Sent: 20 September 2018 15:38
> To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
> Subject: Re: [CF-metadata] Platform Heave
>
> Hi Nan,
>
> My understanding is that Alison was proposing leaving the existing 
> pitch/roll/yaw/heave in place, but with a note in the definitions that 
> direction isn't specified. New direction-specific names would then be added 
> and linked to the existing names as aliases (in the CF XML) or NarrowMatch 
> mappings (in NVS). This requires a change in the definition of 'alias' in the 
> CF Convention, which seems to have strong support.
>
> This is exactly what you want!
>
> Regarding the heave rates, I don't agree. In my view, if the quantities are 
> explicitly signed then names for explicitly signed quantity rate vectors 
> should also be available.
>
> Cheers, Roy.
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
> 
> From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
> Galbraith <mailto:ngalbra...@whoi.edu>
> Sent: 20 September 2018 15:11
> To: mailto:cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
>
> Thank you, Alison. This all looks good.
>
> With regards to your last point, about the existing names
> heave/yaw/pitch/roll  (and their rates),
> I'm not sure why we need to deprecate anything or even create these
> aliases. There may 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Thanks Alison,


I'd obviously misread/misunderstood your last message.  The 'triplet' method 
when narrowing the meaning of a Standard Name does help those of us who hold 
large file stocks of historical data, some of which has very poor metadata by 
present-day standards, but still has value.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Alison Pamment - UKRI STFC 
Sent: 20 September 2018 15:59
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: RE: [CF-metadata] Platform Heave

Dear Nan and Roy,

In fact I had neglected to consider the case when the sign is unknown or 
unrecorded. I am used to thinking about model data, where the sign of a 
quantity is always known, but I appreciate that things may be different in the 
world of observations! Nan's suggestion of retaining the current names and also 
adding the pairs of new signed names would cover all possibilities and fits 
within the existing schema for the standard name table. (If we go down this 
route then I think we should still create aliases for the existing names to 
remove the word 'angle' for consistency with the new names).

As you both point out, the definitions could be written to cross-reference the 
signed and unsigned names so that CF users are directed to the most appropriate 
name for their data. The appropriate NVS mappings could certainly also be 
created.

I agree with Roy that we should allow for signed (and unsigned) rates, again 
with appropriate cross-references in the definitions.

Do others support the idea of having triplets of names in this way?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 20 September 2018 15:38
To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Nan,

My understanding is that Alison was proposing leaving the existing 
pitch/roll/yaw/heave in place, but with a note in the definitions that 
direction isn't specified. New direction-specific names would then be added and 
linked to the existing names as aliases (in the CF XML) or NarrowMatch mappings 
(in NVS). This requires a change in the definition of 'alias' in the CF 
Convention, which seems to have strong support.

This is exactly what you want!

Regarding the heave rates, I don't agree. In my view, if the quantities are 
explicitly signed then names for explicitly signed quantity rate vectors should 
also be available.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
Galbraith <mailto:ngalbra...@whoi.edu>
Sent: 20 September 2018 15:11
To: mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thank you, Alison. This all looks good.

With regards to your last point, about the existing names
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even
need to be signed - or
can't be signed because the heave distance or rate is provided by an
instrument and the 'sense' of
the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a
sentence about using the
direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I
haven't looked at all of them
to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the
definitions. When using the
html search function and looking for the difference between say
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the
definition of the
quantity comes first. Not everyone uses the standard name table this
way, I know, but for
those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
>
> Dear Alison,
>
>
> Your proposal is a much better solution than deprecating the original
> Standard Name and so has full support of Gwen and I.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
>
> 
> *From:* Alison Pamment - UKRI STFC <mailto:alison.pamm...@stfc.ac.uk>
> 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Apologies Nan,


It was me who had misunderstood Alison's proposal!


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Alison Pamment - UKRI STFC 
Sent: 20 September 2018 15:59
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: RE: [CF-metadata] Platform Heave

Dear Nan and Roy,

In fact I had neglected to consider the case when the sign is unknown or 
unrecorded. I am used to thinking about model data, where the sign of a 
quantity is always known, but I appreciate that things may be different in the 
world of observations! Nan's suggestion of retaining the current names and also 
adding the pairs of new signed names would cover all possibilities and fits 
within the existing schema for the standard name table. (If we go down this 
route then I think we should still create aliases for the existing names to 
remove the word 'angle' for consistency with the new names).

As you both point out, the definitions could be written to cross-reference the 
signed and unsigned names so that CF users are directed to the most appropriate 
name for their data. The appropriate NVS mappings could certainly also be 
created.

I agree with Roy that we should allow for signed (and unsigned) rates, again 
with appropriate cross-references in the definitions.

Do others support the idea of having triplets of names in this way?

Best wishes,
Alison

--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.

From: CF-metadata  On Behalf Of Lowry, Roy K.
Sent: 20 September 2018 15:38
To: cf-metadata@cgd.ucar.edu; ngalbra...@whoi.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Nan,

My understanding is that Alison was proposing leaving the existing 
pitch/roll/yaw/heave in place, but with a note in the definitions that 
direction isn't specified. New direction-specific names would then be added and 
linked to the existing names as aliases (in the CF XML) or NarrowMatch mappings 
(in NVS). This requires a change in the definition of 'alias' in the CF 
Convention, which seems to have strong support.

This is exactly what you want!

Regarding the heave rates, I don't agree. In my view, if the quantities are 
explicitly signed then names for explicitly signed quantity rate vectors should 
also be available.

Cheers, Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata <mailto:cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan 
Galbraith <mailto:ngalbra...@whoi.edu>
Sent: 20 September 2018 15:11
To: mailto:cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thank you, Alison. This all looks good.

With regards to your last point, about the existing names
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even
need to be signed - or
can't be signed because the heave distance or rate is provided by an
instrument and the 'sense' of
the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a
sentence about using the
direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I
haven't looked at all of them
to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the
definitions. When using the
html search function and looking for the difference between say
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the
definition of the
quantity comes first. Not everyone uses the standard name table this
way, I know, but for
those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
>
> Dear Alison,
>
>
> Your proposal is a much better solution than deprecating the original
> Standard Name and so has full support of Gwen and I.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
>
> 
> *From:* Alison Pamment - UKRI STFC <mailto:alison.pamm...@stfc.ac.uk>
> *Sent:* 19 September 2018 19:04
> *To:* Lowry, Roy K.; Jim Biard; mailto:cf-metadata@cgd.ucar.edu
> *Subject:* RE: [CF-metadata] Platform Heave
> Dear Jim et al.,
>
> Thank you again for all the work on these n

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Nan,


My understanding is that Alison was proposing leaving the existing 
pitch/roll/yaw/heave in place, but with a note in the definitions that 
direction isn't specified. New direction-specific names would then be added and 
linked to the existing names as aliases (in the CF XML) or NarrowMatch mappings 
(in NVS). This requires a change in the definition of 'alias' in the CF 
Convention, which seems to have strong support.


This is exactly what you want!


Regarding the heave rates, I don't agree. In my view, if the quantities are 
explicitly signed then names for explicitly signed quantity rate vectors should 
also be available.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 20 September 2018 15:11
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thank you, Alison. This all looks good.

With regards to your last point, about the existing names
heave/yaw/pitch/roll  (and their rates),
I'm not sure why we need to deprecate anything or even create these
aliases. There may be cases
where the magnitude of e.g. heave is important, but doesn't really even
need to be signed - or
can't be signed because the heave distance or rate is provided by an
instrument and the 'sense' of
the heave is not included.

Can't we just leave the existing (unsigned) names as they are, adding a
sentence about using the
direction-specific names when direction is known?

Also, do we need both platform_heave_rate_up and
platform_heave_rate_down, or is heave_rate
sufficient? This also applies to most or all of the rates ... sorry I
haven't looked at all of them
to check how many pairs could be combined.

Last, thanks for clarifying the issue of order of terms in the
definitions. When using the
html search function and looking for the difference between say
platform_course and
platform_orientation, it is *much* easier (for a human, at least) if the
definition of the
quantity comes first. Not everyone uses the standard name table this
way, I know, but for
those who do this is really helpful.

Thanks for bringing this together!

- Nan



On 9/20/18 4:35 AM, Lowry, Roy K. wrote:
>
> Dear Alison,
>
>
> Your proposal is a much better solution than deprecating the original
> Standard Name and so has full support of Gwen and I.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus
> Fellowship using this e-mail address.
>
>
>
> 
> *From:* Alison Pamment - UKRI STFC 
> *Sent:* 19 September 2018 19:04
> *To:* Lowry, Roy K.; Jim Biard; cf-metadata@cgd.ucar.edu
> *Subject:* RE: [CF-metadata] Platform Heave
> Dear Jim et al.,
>
> Thank you again for all the work on these names and their definitions.
> I have now caught up with all the comments in the discussion and I
> think the names as written most recently by Jim in
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html are
> looking very good. All the recent comments seem to indicate unanimous
> support (with a couple of minor corrections to the yaw definition text).
>
> The definitions are great and using pairs of names is a neat solution
> to all the questions regarding reference frames and sign conventions.
> There has been some discussion of the order of the sentences in the
> definition, i.e. whether the quantity can be described first, followed
> by the general description of 'platform'. Jim pointed out that in many
> standard name definitions the sentences are ordered in the same way as
> the components of the name itself. Often I have constructed them that
> way because it gives some logical structure to the text, rather than
> just adding the sentences in some random order. However, there is no
> hard and fast rule and sometimes we do adjust the order of the
> sentences so that the text flows more naturally. For example, we
> recently added a lot of new names for sea surface wave spectra, such
> as sea_surface_primary_swell_wave_directional_spread, in which the
> first sentence of each definition summarizes the meaning of the
> quantity as a whole before going into further detail about the
> individual terms. I don't see any problem about reordering the
> platform definitions in the way Nan has suggested, e.g.
> platform_yaw_fore_starboard: Yaw is a rotation about the local
> vertical axis. Yaw is relative to the "at rest" rotation of the
> platform with respect to the axis of rotation. The "at rest" rotation
> of the platform may change over time. "Fore starboard" indicates that
> positive values of yaw represent the front of the platform moving to
> the right as viewed by 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Alison,


Your proposal is a much better solution than deprecating the original Standard 
Name and so has full support of Gwen and I.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Alison Pamment - UKRI STFC 
Sent: 19 September 2018 19:04
To: Lowry, Roy K.; Jim Biard; cf-metadata@cgd.ucar.edu
Subject: RE: [CF-metadata] Platform Heave

Dear Jim et al.,

Thank you again for all the work on these names and their definitions. I have 
now caught up with all the comments in the discussion and I think the names as 
written most recently by Jim in 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020513.html are looking 
very good. All the recent comments seem to indicate unanimous support (with a 
couple of minor corrections to the yaw definition text).

The definitions are great and using pairs of names is a neat solution to all 
the questions regarding reference frames and sign conventions. There has been 
some discussion of the order of the sentences in the definition, i.e. whether 
the quantity can be described first, followed by the general description of 
'platform'. Jim pointed out that in many standard name definitions the 
sentences are ordered in the same way as the components of the name itself. 
Often I have constructed them that way because it gives some logical structure 
to the text, rather than just adding the sentences in some random order. 
However, there is no hard and fast rule and sometimes we do adjust the order of 
the sentences so that the text flows more naturally. For example, we recently 
added a lot of new names for sea surface wave spectra, such as 
sea_surface_primary_swell_wave_directional_spread, in which the first sentence 
of each definition summarizes the meaning of the quantity as a whole before 
going into further detail about the individual terms. I don't see any problem 
about reordering the platform definitions in the way Nan has suggested, e.g.
platform_yaw_fore_starboard: Yaw is a rotation about the local vertical axis. 
Yaw is relative to the "at rest" rotation of the platform with respect to the 
axis of rotation. The "at rest" rotation of the platform may change over time. 
"Fore starboard" indicates that positive values of yaw represent the front of 
the platform moving to the right as viewed by an observer on top of the 
platform facing forward. Platform is a structure or vehicle that serves as a 
base for mounting sensors. Platforms include, but are not limited to, 
satellites, aeroplanes, ships, buoys, ground stations, and masts.
Unless anyone objects, I will write the definitions this way round when I add 
them to the standard name table.

There is another (technical) point that I need to raise before formally 
accepting these names. Some of the names are new, e.g. the surge and sway 
quantities, so there is no problem about adding pairs of these names straight 
into the table as new entries. During the discussion it was mentioned that 
'heave' would also be new. In fact, I added names platform_heave and 
platform_heave_rate to the standard name table in V58 on 7th August with 
definitions that I thought we had agreed at that point. (This was just before I 
went on leave and it didn't get announced on the list, so I'll post details of 
that update separately.) For the heave names and the existing yaw/pitch/roll 
names we now want to introduce pairs of names to allow for the possible use of 
opposing sign conventions and this raises a question about how to construct the 
aliases.

We had a similar case some years ago in which it was realised that the existing 
name surface_carbon_dioxide_mole_flux gave no indication of its sign 
convention. There was some discussion over whether existing data sets might 
treat the upward flux as positive and downwards as negative, or vice versa. 
There was no real way of answering this question, so to avoid invalidating any 
existing data, I added two new names 
surface_downward_mole_flux_of_carbon_dioxide and 
surface_downward_mole_flux_of_carbon_dioxide and listed 
surface_carbon_dioxide_mole_flux as the alias of both. The definitions of the 
new terms both contain the sentences 'The standard name 
surface_carbon_dioxide_mole_flux is deprecated because it does not specify in 
which direction the flux is positive. Any data having the standard name 
surface_carbon_dioxide_mole_flux should be examined carefully to determine 
which sign convention was used.' This seemed like a pragmatic approach to 
solving the problem of adding a pair of new names while not making any 
assumptions about the sign conventions already in use. I would argue that a 
similar approach would also make sense for the heave/yaw/pitch/roll names, 
e.g., platform_yaw_fore_starboard and platform_yaw_fore_port would both have an 
alias of platform_yaw_angle and an explanatory senten

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


Interesting article that answers some of my questions about what we've been 
defining here in terms of platform-local axes and 'real world' co-ordinate 
reference systems.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 13 September 2018 19:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


I only just located this wikipedia article. It describes the different axes 
conventions that are in common use and the differences between them.


https://en.wikipedia.org/wiki/Axes_conventions

[https://upload.wikimedia.org/wikipedia/commons/thumb/6/67/Plane.svg/1200px-Plane.svg.png]<https://en.wikipedia.org/wiki/Axes_conventions>

Axes conventions - Wikipedia<https://en.wikipedia.org/wiki/Axes_conventions>
en.wikipedia.org
In ballistics and flight dynamics, axes conventions are standardized ways of 
establishing the location and orientation of coordinate axes for use as a frame 
of reference.Mobile objects are normally tracked from an external frame 
considered fixed. Other frames can be defined on those mobile objects to deal 
with relative positions for other objects.




On 9/13/18 12:15 PM, Lowry, Roy K. wrote:

Hi John,


Your Q2 has been discussed at length. The local vertical axis is indeed local 
to the platform, as are the axes running front to back and left to right.


Your eagle eyes have indeed spotted something I missed in the yaw definition ' 
'Yaw is a rotation about the axis of rotation' should I think read 'Yaw is a 
rotation about the local vertical axis'.


I HATE 'smart' quotes and Microsoft's mission to make every quote smart through 
auto-correction!


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of John Graybeal 
<mailto:jbgrayb...@mindspring.com>
Sent: 13 September 2018 16:38
To: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

It’s a brilliant effort, if I may say. I’ve been following and appreciating it 
(wanted it for a long time!) and I think it is very close.

If I may say so, it deserves a bit of time for everyone to catch up, before 
enshrinement.  I have two questions I’d like to ask, and one editing nit.

Question 1: The last version I found is enclosed, but I can’t tell if it is the 
last version. (Please note the long tails of the emails make it extremely 
time-consuming to find the content when trying to catch up. Hence I have sent 
this without the long tail.)

This version does not seem to address Nan’s suggestion to put the platform 
description after the roll/pitch/etc description, which I also like. Still, I 
can see advantages both ways.

Question 2: The one concern I have, sorry if you dealt with it thoroughly, is 
about the expression in each definition that reads something like "Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform.”  I may be 
mis-remembering, but from my airplane navigation days my understanding is that 
the role is around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if the 
airplane is yawing to the right, the roll is around the actual direction, not 
the travel direction.  This is important at small scales when dealing with the 
spherical coordinate math necessary to point telescopes; it’s important at 
large scales if you imagine a fighter jet flying vertically up or down, and 
executing a roll (the roll axis is definitely not perpendicular to the local 
vertical axis in this case, unless you mean “platform local”, which I believe 
is how it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way also—once they 
define ‘front’, the measurements and calculations for roll are all around where 
front is, and similar patterns apply for pitch (measured relative to a line 
perpendicular to front-back axis directly through the wings) and yaw (measured 
around an axis vertical to the airplane local—note that the definitions for yaw 
include "Yaw is a rotation about the axis of rotation”, and appear to have lost 
the description of what the axis of rotation *is*.

I cite Wikipedia as my authority, not just because it matches my memory but 
also because it is footnoted, and refers to both airplanes and satellites using 
this reference frame.

Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the order of the 
day.

John



platform_roll_starboard_down: Platform is a structure or vehicle that serves as 
a ba

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi John,


Your Q2 has been discussed at length. The local vertical axis is indeed local 
to the platform, as are the axes running front to back and left to right.


Your eagle eyes have indeed spotted something I missed in the yaw definition ' 
'Yaw is a rotation about the axis of rotation' should I think read 'Yaw is a 
rotation about the local vertical axis'.


I HATE 'smart' quotes and Microsoft's mission to make every quote smart through 
auto-correction!


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of John Graybeal 

Sent: 13 September 2018 16:38
To: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

It’s a brilliant effort, if I may say. I’ve been following and appreciating it 
(wanted it for a long time!) and I think it is very close.

If I may say so, it deserves a bit of time for everyone to catch up, before 
enshrinement.  I have two questions I’d like to ask, and one editing nit.

Question 1: The last version I found is enclosed, but I can’t tell if it is the 
last version. (Please note the long tails of the emails make it extremely 
time-consuming to find the content when trying to catch up. Hence I have sent 
this without the long tail.)

This version does not seem to address Nan’s suggestion to put the platform 
description after the roll/pitch/etc description, which I also like. Still, I 
can see advantages both ways.

Question 2: The one concern I have, sorry if you dealt with it thoroughly, is 
about the expression in each definition that reads something like "Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform.”  I may be 
mis-remembering, but from my airplane navigation days my understanding is that 
the role is around the axis that points out the front of the airplane. If the 
airplane is pitched up, the roll is around the pitched-up vector; if the 
airplane is yawing to the right, the roll is around the actual direction, not 
the travel direction.  This is important at small scales when dealing with the 
spherical coordinate math necessary to point telescopes; it’s important at 
large scales if you imagine a fighter jet flying vertically up or down, and 
executing a roll (the roll axis is definitely not perpendicular to the local 
vertical axis in this case, unless you mean “platform local”, which I believe 
is how it is defined and I’m pretty sure is how it is measured by the 
accelerometers).  I believe that satellites work the same way also—once they 
define ‘front’, the measurements and calculations for roll are all around where 
front is, and similar patterns apply for pitch (measured relative to a line 
perpendicular to front-back axis directly through the wings) and yaw (measured 
around an axis vertical to the airplane local—note that the definitions for yaw 
include "Yaw is a rotation about the axis of rotation”, and appear to have lost 
the description of what the axis of rotation *is*.

I cite Wikipedia as my authority, not just because it matches my memory but 
also because it is footnoted, and refers to both airplanes and satellites using 
this reference frame.

Finally, my editing nit is that these definitions have replaced smart 
apostrophes with question marks, I assume dumb apostrophes are the order of the 
day.

John



platform_roll_starboard_down: Platform is a structure or vehicle that serves as 
a base for mounting sensors. Platforms include, but are not limited to, 
satellites, aeroplanes, ships, buoys, ground stations, and masts. Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform. Roll is 
relative to the ?at rest? rotation of the platform with respect to the axis of 
rotation. The ?at rest? rotation of the platform may change over time. 
"Starboard down" indicates that positive values of roll represent the right 
side of the platform falling as viewed by an observer on top of the platform 
facing forward.

platform_roll_starboard_up: Platform is a structure or vehicle that serves as a 
base for mounting sensors. Platforms include, but are not limited to, 
satellites, aeroplanes, ships, buoys, ground stations, and masts. Roll is a 
rotation about an axis that is perpendicular to the local vertical axis and is 
coplanar with the nominal forward motion direction of the platform. Roll is 
relative to the ?at rest? rotation of the platform with respect to the axis of 
rotation. The ?at rest? rotation of the platform may change over time. 
"Starboard up" indicates that positive values of roll represent the right side 
of the platform rising as viewed by an observer on top of the platform facing 
forward.

platform_roll_rate_starboard_down: Platform is a structure or vehicle that 
serves as a base for 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Nan and Jim,


It was me, on my own volition, who raised concerns about the use of nautical 
terms to try and make the concepts domain-independent. However, 'port' is such 
an elegant way of saying 'left when facing forward' that I don't think we 
should resist it. Saw a nice definition for port  - 'The side of a platform 
that is on the left when one is facing forward.'


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 11 September 2018 16:37
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Nan,

That was my concern. As I have thought about it, we can make it clear in the 
definition text. I'll generate those later this week.

Jim

On 9/11/18 10:53 AM, Nan Galbraith wrote:
I agree completely. Thanks to all for keeping at it with this topic.

 * platform_roll_starboard_down
 * platform_yaw_fore_starboard
 * platform_pitch_fore_up
 * platform_surge_fore
 * platform_sway _port
 * platform_heave_up

There was some concern expressed about using port and starboard, because
satellite folks don't normally use those terms. I was unable to figure out 
exactly
who raised this point, the thread is long and sometimes my mail client makes the
sender of each message a little obscure.

I'm assuming even satellites have a 'front' - ADCPs don't, really, except by 
some
obscure convention set by the vendors - so presumably people will be able to 
figure
out which side is which, and these terms will be OK.

- Nan


On 9/7/18 4:07 AM, Lowry, Roy K. wrote:

Good point,


So you'd prefer platform_roll_starboard_down and so on?


Cheers, Roy.



*From:* John Graybeal 
<mailto:jbgrayb...@mindspring.com>
*Sent:* 07 September 2018 03:29
*Subject:* Re: [CF-metadata] Platform Heave
Sorry if I missed a point, but joining the motion to platform_ will be much 
more findable. Platform roll for example is a really common expression.

John

On Sep 6, 2018, at 08:22, Lowry, Roy K. 
mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk>> wrote:

Dear Jim,


Looking good to me.


Cheers, Roy.



*From:* CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Jim Biard mailto:jbi...@cicsnc.org> 
<mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org>>
*Sent:* 05 September 2018 17:38
*Subject:* Re: [CF-metadata] Platform Heave

Roy, Jonathan,

I expect that surge, sway, and heave may well not have any "alternate 
direction" representations in the wild, but I recall that we found that the 
same is not true of pitch, roll, and yaw.

Should we define the "canonical" set in such a fashion that the sign convention 
is explicit and wait for people to request the others?

I guess that would be:

  * platform_starboard_down_roll
  * platform_fore_starboard_yaw
  * platform_fore_up_pitch
  * platform_fore_surge
  * platform_port_sway
  * platform_up_heave

Is that what we want?

Grace and peace,

Jim

On 9/5/18 12:10 PM, Jonathan Gregory wrote:

Dear Roy OK, yes. I agree with that too! We should not provide standard names 
for there is no use case yet. However, it's a good idea for foresee how this 
may be done, so that a neat solution is readily available when the day comes. 
Best wishes and thanks Jonathan On Wed, Sep 05, 2018 at 04:07:26PM +0000, 
Lowry, Roy K. wrote:

Date: Wed, 5 Sep 2018 16:07:26 + From: "Lowry, Roy K." 
<mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk> Subject: Re: [CF-metadata] 
Platform Heave Dear Jonathan, This isn't a desire to mandate, it's just an 
attempt to prevent the creation of six unnecessary Standard Names for sign 
conventions based on my knowledge and researches of oceanographic data that 
don't exist. Should anybody come up with a single example of the opposite sign 
convention in heave/sway/surge from any other domain then the additional 
Standard Names will obviously need setting up. Anybody know of any??? It also 
goes without saying the 'normal' conventions should leave the door open - for 
example 'upward heave' leaves the door open for a future 'downward heave'. This 
follows another principle of CF Standard Names which is that Standard Names 
should only set up when there is a demonstrable use case and not just in case a 
use case arises. Cheers, Roy. From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>
 on behalf of Jonathan Gregory 
<mailto:j.m.greg...@reading.ac.uk> 
<mailto:j.m.greg...@reading.ac.uk><mailto

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jim,


I think maybe you're doing more work than necessary. I see the work falling 
into three parts.


1) Revision of the definitions of heave/heave rate that are part of a new 
Standard Name that has yet to be accepted.


2) Creation of new Standard Names for Ken for sway/sway rate and surge/surge 
rate


3) Upgrade to the definitions of the existing Standard Names for pitch, roll 
and yaw.


How about hard-wiring direction conventions for cases (1) and (2) - heave 
positive up, surge positive forwards and sway to match Ken's data sets? As 
these are new Standard Names they cannot be out in the wild with the opposite 
direction convention.


We would then need to deprecate the three existing Standard Names and replace 
them with six new ones.


One other thought that is occupying my mind is whether the rate parameters are 
scalars or vectors? Any thoughts?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 04 September 2018 16:36
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Jonathan,

Two out of three of Nan's "most intuitive" rotations (pitch and yaw) are 
clockwise rather than anticlockwise if the unit vectors are X-fore, Y-port, and 
Z-up, which form a right-hand coordinate system. This is part of why you will 
see examples where the unit vectors are defined as X-fore, Y-starboard, and 
Z-down. This orientation of the unit vectors makes yaw to starboard, pitch up, 
and roll starboard down all anticlockwise rotations, but it points the Z unit 
vector down, which is, for most people, rather counter-intuitive. And this is 
why we are trying to define things in terms that don't require specification of 
unit vector directions.

I'm going to try to continue down that path and avoid calling out 
clockwise/anticlockwise.

Grace and peace,

Jim

On 9/4/18 10:18 AM, Jonathan Gregory wrote:

Dear Jim



If that's the general consensus, then we can go that general
direction. I'll prepare pairs of everything.


Thank you for your flexibility.



Regarding Nan's suggestions for names - I'm not a "ship person" so
starboard and port are unfamiliar terms that I have to constantly
check myself on. I dislike putting them in the names. I don't see
them in regular use in the satellite domain. The same goes for bow
as far as usage outside of the ship domain. Airplanes have noses.
Satellites have ... I don't know if there is even a name, as there
is no need for a leading edge. I'll struggle to find something, and
then we can wrangle over it.


I agree with you - it would be better to have something generic and self-
explanatory, even if it diverges from familiar terminology.



I think the "most intuitive" way to represent the angles - and most
consistent as well, in my view - is clockwise rotations around the
unit vectors. This makes positive yaw to starboard, positive pitch
nose up, and positive roll starboard up. But we are talking about
having both signs represented in names, so I guess that is moot.


I agree with this too. For describing polygonal bounds, we say that the
vertices should be traversed anticlockwise as seen from above. That is a
positive direction of rotation around the vertical axis, since longitude-
latitude-upward is a right-handed coordinate system. I suppose this is the
yaw rotation - but is that the opposite sign from yours?

Best wishes

Jonathan



On 9/3/18 12:51 PM, Jonathan Gregory wrote:


Dear Roy and Nan

I agree that if there are existing names whose sign convention is undefined
we can't retrospectively define it. I think those ones ought to be deprecated,
though, in favour of new ones with signs indicated.

Best wishes

Jonathan

- Forwarded message from Nan Galbraith 
<mailto:ngalbra...@whoi.edu> -



Date: Sun, 02 Sep 2018 11:57:33 -0400
From: Nan Galbraith <mailto:ngalbra...@whoi.edu>
To: "Lowry, Roy K." <mailto:r...@bodc.ac.uk>
Cc: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave
User-Agent: Internet Messaging Program (IMP) H4 (5.0.23)

I second Roy's suggestion; existing names have undefined directionality,
and new names have explicit directions. This seems like the only way to
move forward. If there's a difference of opinion on which direction
should be in the new name, we can easily create a pair for each term.

What would the explicit names be?  Some of the terms in the thread
below use 'right' and 'left' where 'port' and 'starboard' might be
more clear, since, as Roy points out, left and right can be taken
as 'looking forwards from the platform or looking at the front of
the platform.'

I also agree that these are the most intuitive way to represent these
angles/motions:


heave positive up
pitch positive bow up
yaw positive to starboard roll positive starboard side

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jonathan,


I appreciate that you haven't been following this debate so I thought I'd point 
out that the proposal is a mixture of new Standard Names and upgrades to 
definitions of existing Standard Names for pitch, roll and yaw.  To my thinking 
whatever is done shouldn't change the semantics of the existing names.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 31 August 2018 13:52
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Dear all

I haven't been following this discussion, so please excuse me if I've missed
the point. I think you are suggesting introducing a new attribute to indicate
the positive sense of various new quantities for platform orientation - is
that right? To do that would not be consistent with other standard names, which
(where relevant) all have the positive sense indicate in the standard name
itself. That's why there are many pairs of standard names for upward/downward,
in particular. The reason for doing this is to make it impossible to name the
quantity without indicating its sign convention, whereas a separate attribute
can be omitted, and probably sometimes will. It also opens new possibilities
for getting things wrong, by putting illegal values in it.

Therefore I would argue for the same approach here, both because I think it's
less error-prone, and for consistency with other CF standard names. I'm sure
the objection occurs to you that this means more standard names. That's true,
but it's only twice as many, I believe, since each of the quantities has only
two possible senses.

Best wishes

Jonathan

- Forwarded message from Kenneth Kehoe  -

> Date: Thu, 30 Aug 2018 12:05:44 -0600
> From: Kenneth Kehoe 
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
>Gecko/20100101 Thunderbird/60.0
>
> I think we should keep things simple as Ethan suggests below. But
> since the proposed attribute "direction" is defined as indicating
> the positive direction we don't need to include the word positive.
>
> The terms would then be:
> roll: "right_side_up" and "right_side_down"
> pitch: "nose_up" and "nose_down"
> yaw: "nose_right" and "nose_left"
> surge: "forward" and "backward"
> sway: "left" and "right"
> heave: "up" and "down"
>
> It would be nice to be more explicit in the netCDF file and require
> less on the standard_name definition so I would suggest we use the
> original proposed attribute name of "positive_direction" with the
> above allowed values.
>
> Or if we don't want to add a new attribute we could use the existing
> "positive" attribute and expand its allowed use. I've proposed this
> in the past and it was decided to not expand the definition. I think
> the concern for not expanding positive was the requirement of only
> using that attribute on coordinate variables. For the coordinate
> variable the only allowable values are up and down. But for this use
> those values would only be attached to a variable, not a coordinate
> variable.
>
> Since we are creating an attribute to define the positive direction
> I would like to add radial definition of "toward" and "away". But I
> think we can simplify this a bit further. If we define the point of
> reference that is moving in the standard name then we don't need to
> put the point of reference in the positive (or direction or
> positive_direction) attribute. For example the pitch standard_name
> would indicate the location of reference of the nose. This would
> then reduce the list of possible options to:
>
> roll: "up" and "down"
> pitch: "up" and "down"
> yaw: "right" and "left"
> surge: "forward" and "backward"
> sway: "left" and "right"
> heave: "up" and "down"
>
> If we could use the current attribute of "positive" that has up and
> down already defined then we only need to to add "right", "left",
> "forward", "backward", "toward", "away".
>
> Easy!
>
>
> Ken
>
>
>
> On 2018-8-29 13:54, Ethan Davis wrote:
> >Hey Jim,
> >
> >How about removing one layer of terminology by using your
> >definitions for the allowed values of "direction":
> >
> >roll: "positive_right_side_up" and "positive_right_side_down".
> >pitch: "positive_nose_up" and "positive_nose_down".
> >yaw: "positive_nose_right" and "positive_nose_left".
> >surge: "positive_forward" and "positive_backward".
> >sway: "positive_left" and "positive_right".
> >heave: "positive_up" and "positive_down".
> >
> >Cheers,
> >
> >Ethan
> >
> >On Wed, Aug 29, 2018 at 12:02 PM Jim Biard  >> wrote:
> >
> >John,
> >
> >There are a variety of conventions for defining roll, pitch, and
> >yaw out there. This is why we are avoiding a specific one. Others
> >have searched existing datasets that are using earlier versions of
> >these 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jim,


>From my researches into existing oceanographic data sets (SeaDataCloud 
>holdings plus EU glider data projects), covering heave, pitch, roll and yaw. I 
>haven't discovered a single deviation from the conventions:


heave positive up

Pitch positive bow/nose up

yaw positive to startboard

roll starboard side down


I have yet to find any data sets, other than those described by Ken in these 
discussions, in my searches containing surge or sway.


The only ambiguity I have found in the wider domain of Google is where the 
concept of 'positive clockwise' has been used without specifying whether the 
observer is looking forwards from the platform or looking at the front of the 
platform. This isn't helped by the multitude of bidirectional vectors (arrows 
at each end) in illustrative diagrams.


Might our lives be made easier if we adopted a set of conventions, state them 
explicitly in the Standard Names as Jonathan suggests leaving room in the 
unlikely - in my view at least - event of Standard Names for the opposite 
convention being required?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 31 August 2018 14:38
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Jonathan,

That's only part of the issue. Here are the issues as I see them.

  *   There is no single sign convention being followed in existing datasets 
"in the wild".
  *   There is a long-standing convention for vertical coordinates using the 
attribute positive rather than having pairs of standard names for 
height_positive_up, height_positive_down, etc. The suggested solution is 
corollary, and the positive attribute could be used instead of adding a new 
attribute named direction with a suitable expansion of possible valid values.
  *   In order to cover all bases, we'd need three versions for each standard 
name (e.g. - platform_roll, platform_roll_clockwise, 
platform_roll_anticlockwise - or similar names)
  *   Having three different versions of each standard name will lead to new 
possibilities for getting things wrong by picking the wrong version.
  *   Semantically, there is only one concept in each case. If I am searching 
for roll variables and I have multiple names that mean roll, I must expand my 
search to include all variants. This is a small example, but there are other 
examples of this problem that are definitely not trivial and defeat one of the 
goals for using standard names - being able to find like quantities across 
datasets, particularly using automated techniques rather than human eyes.

Grace and peace,

Jim

On 8/31/18 8:52 AM, Jonathan Gregory wrote:

Dear all

I haven't been following this discussion, so please excuse me if I've missed
the point. I think you are suggesting introducing a new attribute to indicate
the positive sense of various new quantities for platform orientation - is
that right? To do that would not be consistent with other standard names, which
(where relevant) all have the positive sense indicate in the standard name
itself. That's why there are many pairs of standard names for upward/downward,
in particular. The reason for doing this is to make it impossible to name the
quantity without indicating its sign convention, whereas a separate attribute
can be omitted, and probably sometimes will. It also opens new possibilities
for getting things wrong, by putting illegal values in it.

Therefore I would argue for the same approach here, both because I think it's
less error-prone, and for consistency with other CF standard names. I'm sure
the objection occurs to you that this means more standard names. That's true,
but it's only twice as many, I believe, since each of the quantities has only
two possible senses.

Best wishes

Jonathan

- Forwarded message from Kenneth Kehoe 
 -



Date: Thu, 30 Aug 2018 12:05:44 -0600
From: Kenneth Kehoe 
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
Gecko/20100101 Thunderbird/60.0

I think we should keep things simple as Ethan suggests below. But
since the proposed attribute "direction" is defined as indicating
the positive direction we don't need to include the word positive.

The terms would then be:
roll: "right_side_up" and "right_side_down"
pitch: "nose_up" and "nose_down"
yaw: "nose_right" and "nose_left"
surge: "forward" and "backward"
sway: "left" and "right"
heave: "up" and "down"

It would be nice to be more explicit in the netCDF file and require
less on the standard_name definition so I would suggest we use the
original proposed attribute name of "positive_direction" with the
above allowed values.

Or if we don't want to add a new attribute we could use the existing

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


One other thing to think on is the set of 'rate' Standard Names, or are you 
happy with my prefix from the yaw example added on to your definitions.


And finally are we intending to propose platform_sway and platform_surge as new 
Standard Names in addition to platform_heave which started this discussion even 
though nobody has specifically asked for them?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 06 August 2018 16:47
To: CF Metadata List; Jonathan Gregory
Subject: Re: [CF-metadata] Platform Heave

Hi.

There are other standard names that call for a separate attribute or variable 
that provides context. The attributes (at the moment) are all standard CF 
attributes (cell_methods, flag_meanings, comment, etc). I'd love to get 
feedback from the community about whether or not a directionality attribute 
would need to described as a "standard" CF attribute.

I'll be glad to rework the definitions to make them directionality-agnostic 
when I get back next week.

Grace and peace,

Jim

[CICS-NC]<http://www.cicsnc.org/>Visit us on
Facebook<http://www.facebook.com/cicsnc>Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocean and 
geophysics<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo<http://www.twitter.com/NOAANCEIocngeo>.




On Sat, Aug 4, 2018 at 3:45 AM Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear Nan,


So are we returning to the wording in Alison's original definitions (e.g. yaw 
normally clockwise facing front) before you with my support asked for the 
ambiguity be removed? Or do you want to go even further with no mention of sign 
convention at all?


I would also question whether a Standard Name definition is the place to 
specify the mechanism to be used for the description of a sign convention as it 
has wider implications than the parameters currently under discussion. Would it 
not be more appropriate for this to be considered an enhancement to CF and 
written into the Conventions document? If so, it should it not be the subject 
of a GitHub ticket?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu>> on 
behalf of Nan Galbraith mailto:ngalbra...@whoi.edu>>
Sent: 04 August 2018 02:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Thanks, Jim.

> change the definitions to avoid declaring which direction is
> positive, make the direction attribute optional, and say that users
> should be careful about assuming the directionality for variables
> lacking the attribute.

This is the approach I'd prefer as well.

- Nan


Quoting Jim Biard mailto:jbi...@cicsnc.org>>:

> Nan,
>
> I didn't go to the lengths of making new regularized definitions
> before I wrote that list. I was thinking in terms of making the
> clockwise/anticlockwise call based on the right hand rule and the
> unit vector for each axis. For roll, for example, if the X unit
> vector faces forward, the "right side down" roll is actually
> anticlockwise - that is, it is in the direction that your right hand
> fingers curl if you grab the unit vector in your hand with your
> thumb pointing in the same direction as the unit vector. That
> definition is independent of observer location and look direction.
> My definitions for all the direction values are following that same
> convention.
>
> Accurate knowledge of the sign of roll, pitch, and yaw is critical
> in the satellite and aircraft world. The look angles for remote
> sensors are affected by these values. I get it that not all systems
> care about the signed values, so that reason and for backward
> compatibility I suggested that we could change the definitions to
> avoid declaring which direction is positive, make the direction
> attribute optional, and say that users should be careful about
> assuming the directionality for variables lacking the attribute.
>
> Grace and peace,
>
> Jim
>>
>> On 8/3/18 2:03 PM, Nan Galbraith wrote:
>>

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Nan,


So are we returning to the wording in Alison's original definitions (e.g. yaw 
normally clockwise facing front) before you with my support asked for the 
ambiguity be removed? Or do you want to go even further with no mention of sign 
convention at all?


I would also question whether a Standard Name definition is the place to 
specify the mechanism to be used for the description of a sign convention as it 
has wider implications than the parameters currently under discussion. Would it 
not be more appropriate for this to be considered an enhancement to CF and 
written into the Conventions document? If so, it should it not be the subject 
of a GitHub ticket?


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 04 August 2018 02:18
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Thanks, Jim.

> change the definitions to avoid declaring which direction is
> positive, make the direction attribute optional, and say that users
> should be careful about assuming the directionality for variables
> lacking the attribute.

This is the approach I'd prefer as well.

- Nan


Quoting Jim Biard :

> Nan,
>
> I didn't go to the lengths of making new regularized definitions
> before I wrote that list. I was thinking in terms of making the
> clockwise/anticlockwise call based on the right hand rule and the
> unit vector for each axis. For roll, for example, if the X unit
> vector faces forward, the "right side down" roll is actually
> anticlockwise - that is, it is in the direction that your right hand
> fingers curl if you grab the unit vector in your hand with your
> thumb pointing in the same direction as the unit vector. That
> definition is independent of observer location and look direction.
> My definitions for all the direction values are following that same
> convention.
>
> Accurate knowledge of the sign of roll, pitch, and yaw is critical
> in the satellite and aircraft world. The look angles for remote
> sensors are affected by these values. I get it that not all systems
> care about the signed values, so that reason and for backward
> compatibility I suggested that we could change the definitions to
> avoid declaring which direction is positive, make the direction
> attribute optional, and say that users should be careful about
> assuming the directionality for variables lacking the attribute.
>
> Grace and peace,
>
> Jim
>>
>> On 8/3/18 2:03 PM, Nan Galbraith wrote:
>>> Hi Roy -
>>>
>>> Yes,  I've been looking at that page quite a bit lately, and I
>>> think it backs up
>>> what I'm saying.
>>>
>>> If you are standing on that fuselage (may we never), facing
>>> forward, the red roll
>>> arrow is showing a clockwise motion, with right side moving
>>> downward. If you
>>> were facing aft, the arrow would be anticlockwise, but the right side would
>>> be rising.
>>>
>>> So, 'roll: "clockwise" for positive right side up and
>>> "anticlockwise" for positive right
>>> side down'- is backwards in either case. I'm not disputing
>>> anything except
>>> the term 'clockwise'  in this phrase.
>>>
>>> Thanks - Nan
>>>
>>> On 8/3/18 1:43 PM, Lowry, Roy K. wrote:
>>>>
>>>> Hi Nan,
>>>>
>>>>
>>>> Whilst I appreciate the limitations of Wikipedia as an
>>>> authoritative source have a look at
>>>> https://en.wikipedia.org/wiki/Aircraft_principal_axes
[https://upload.wikimedia.org/wikipedia/commons/thumb/5/54/Flight_dynamics_with_text.png/1200px-Flight_dynamics_with_text.png]<https://en.wikipedia.org/wiki/Aircraft_principal_axes>

Aircraft principal axes - 
Wikipedia<https://en.wikipedia.org/wiki/Aircraft_principal_axes>
en.wikipedia.org
Normal axis, or yaw axis — an axis drawn from top to bottom, and perpendicular 
to the other two axes.Parallel to the fuselage station.; Transverse axis, 
lateral axis, or pitch axis — an axis running from the pilot's left to right in 
piloted aircraft, and parallel to the wings of a winged aircraft.



>>>>
>>>>
>>>> Cheers, Roy.
>>>>
>>>>
>>>> 
>>>> *From:* Nan Galbraith 
>>>> *Sent:* 03 August 2018 18:23
>>>> *To:* Jim Biard; Lowry, Roy K.; kke...@ou.edu
>>>> *Subject:* Re: [CF-metadata] Platform Heave (pitch, roll)
>>>> Hi Jim, Roy and Ken -
>>>>
>>>>

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

On second thoughts removing the underscores is more elegant correction than 
adding 'platform'.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Lowry, Roy K. 

Sent: 30 July 2018 18:49
To: Kenneth Kehoe
Cc: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave


Hi Ken,


You're absolutely right - should have been platform_yaw_angle. Getting the 
detail spot on in these things isn't easy, which is why we have discussion 
lists!


With the way I'm currently seeing things I don't agree that pitch and roll 
affect the definition of heave. They are only factors that come into account 
with the coupling of heave into the next level of the CRS hierarchy.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Kenneth Kehoe 

Sent: 30 July 2018 18:39
Cc: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

I agree with John the (keel to top of mast) statement is incorrect when the 
platform is tilted. I only inserted that to help describe the Z-axis. But I 
don't think it's helping. I think John is also right on point with this since I 
can't find a definition of heave that discusses the orientation of the platform 
and how it relates to the measurement of heave. That is why I'm suggesting we 
not try to tackle that issue. From an instrument perspective I don't think the 
organization writing the measurement to file actually know all the details of 
how the values are derived or the full reference frame. I tell people to not 
use the standard_name definitions unless they are positive it matches exactly, 
and without all the information I don't think people will be able to use a too 
specific definition. A less specific definition would allow the use now, and a 
more specific definition can be added later if needed.

I did like Roy's definition of platform_yaw_angle and platform_yaw_rate. My 
only suggestion is to remove the underscore in "yaw_angle" in the definition of 
platform_yaw_rate, or use the full term "platform_yaw_angle". Otherwise it 
appears like a reference to a different term.

Ken



On 2018-7-30 10:52, John Graybeal wrote:
1) Now that we have another platform_heave comment, could we please create a 
new thread for the discussion on pitch/roll/heading?  Maybe starting without 
all the historical points, at least the heave-related ones? Both are difficult 
conversations to follow in sequence.

2) I have a concern about the last two heave definitions.
  a) "Heave is the linear motion along the vertical Z-axis (e.g. keel to top of 
mast) with positive values representing upward motion.”

I like the thrust of this definition, it’s simple to understand. However I 
don’t think it’s measured in the direction of keel to top of mast of the 
current or recent vessel position, is it? I rather assume it is perpendicular 
to a nominally level service, possibly in the direction of the gravity vector. 
The dictionary definition "Heaving is the linear motion along the vertical 
Z-axis” with the positive values coda seems closer.

  b) "upwards vertical displacement of a platform over a measurement time 
interval”

I can’t tell how to parse ‘over’ here.  An upwards vertical displacement is 
relative to another position, and in this case I think that ‘original’ position 
is being measured (at least conceptually) during another time interval. It just 
needs a few words, something like “of a platform when compared to its average 
vertical position over a corresponding time interface”.

But I guess the fundamental issue is I can’t tell (and don’t actually know) 
what heave is determined with respect to. If my last 11 positions relative to 
average seas are 0, 1, 2, 2, 1, 4, 1, 2, 2, 1, 0 (think hilly!), I have no idea 
if the heave at the peak (‘4’) is 4 or something else — it just depends on when 
and how long the baseline measurement is, doesn’t it?  (Or to put it another 
way, is the heave at the 7th point a negative number, since the ship just went 
down 3 units?)  If someone can answer that then our best definition might be 
more obvious.

John

---
John Graybeal
jbgrayb...@mindspring.com<mailto:jbgrayb...@mindspring.com>

On Jul 29, 2018, at 04:29, Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear All,

Giving it some thought over the weekend I realise that where we lost the plot 
in this discussion was when we encountered 'direction of travel'. Jim 
succinctly described platform motion with the phrase 'nested co-ordinate 
systems'. What I failed to realise - and I'm guessing I'm not alone - is that 
the pitch, roll, heave etc. family of terms for platform motion refer SOLELY to 
the innermost co-ordinate reference in that nest and that 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hear Hear!!!


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 30 July 2018 19:22
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Point of order!

I'm in favor of less specific definitions; other attributes can be
used to describe methods and ... whatever else is needed.

On the other hand, planning to change a definition to something more
specific at some point in the future is not good for CF. If I label
something
as heave now, it should still be heave in 20 years.

Cheers - Nan

On 7/30/18 1:39 PM, Kenneth Kehoe wrote:
> A less specific definition would allow the use now, and a more
> specific definition can be added later if needed.
>

--
***
* Nan GalbraithInformation Systems Specialist *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543 (508) 289-2444 *
***


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
CF-metadata Info Page - 
mailman.cgd.ucar.edu
mailman.cgd.ucar.edu
This is an unmoderated list for discussions about interpretation, 
clarification, and proposals for extensions or change to the CF conventions.




This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Nan,


By platform at rest I mean a situation where pitch=0, roll=0, yaw=0, heave=0 
etc. I'm now seeing a tilted platform, such as an out of balance deck load, as 
a coupling to the next level of CRS, so your last statement is absolutely spot 
on.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Nan Galbraith 

Sent: 30 July 2018 18:12
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi all -

I like Ken K's definitions; simple and to the point;  And I agree that
we need to be explicit
about positive direction (which term, by the way, doesn't google well).

I'm not sure I agree with Roy that 'zero is platform at rest' - could
you please explain
that? By 'at rest' do we mean that no forces are operating on the
platform? Would  a buoy
have roll and heave angles if its deck load were out of balance?  If its
deck isn't level, what
term would describe that? I suppose you're building on the fact that
these rotations are
relative to the internal axes of the platform, with no relation to the
'real world'.

It does seem like we're converging ... maybe.

Cheers - Nan

-

On 7/29/18 7:29 AM, Lowry, Roy K. wrote:
>  > Dear All, > > > Giving it some thought over the weekend I realise
that where we lost > the plot in this discussion was when we encountered
'direction of > travel'. Jim succinctly described platform motion with
the phrase > 'nested co-ordinate systems'. What I failed to realise -
and I'm > guessing I'm not alone - is that the pitch, roll, heave etc.
family > of terms for platform motion refer SOLELY to the innermost >
co-ordinate reference in that nest and that the 'zero' for these >
measurements is 'platform at rest'. This innermost co-ordinate >
reference comprises three orthogonal axes that intersect at the >
platform's centre of gravity. Two of these are horizontal (Ken's >
longitudinal X-axis and transverse Y-axis) and the third vertical >
(Ken's vertical Z-axis). Others make no attempt to treat these >
parameters in the same way as zenith, and I now realise CF shouldn't >
be any different. > > > Having come to terms with this, Ken's definition
elements have a > beautiful simplicity that can be slotted into Alison's
compound > definitions. My only problem is the inclusion of nautical
terms like > 'bow' and 'stern', but these can easily be replaced by
generic > equivalents such as 'front' and 'back'. I would also make it
clearer > is that zero is platform at rest. > > > For example the
definition pair for yaw become: > > > platform_yaw_angle > > "yaw
_angle" is the amount of rotation from the rest position around > the
vertical Z-axis with positive values resulting in clockwise > motion
when viewed from above. The vertical Z axis, also known as the > "yaw
axis", is an imaginary line running vertically through the > platform's
centre of gravity. Standard names for "platform" describe > the motion
and orientation of the vehicle from which observations are > made.
Platforms include, but are not limited to, satellites, > aeroplanes,
ships, instruments and buoys. > > > platform_yaw_rate > >
"platform_yaw_rate" is the change per unit time of "yaw_angle". "yaw >
_angle" is the amount of rotation from the rest position around the >
vertical Z-axis with positive values resulting in clockwise motion >
when viewed from above. The vertical Z axis, also known as the "yaw >
axis", is an imaginary line running vertically through the platform's >
centre of gravity. Standard names for "platform" describe the motion >
and orientation of the vehicle from which observations are made. >
Platforms include, but are not limited to, satellites, aeroplanes, >
ships, instruments and buoys. > > > How does that work for people? > > >
Cheers, Roy. > > > -
> From: CF-metadata on behalf of Kenneth Kehoe   > Sent: 27 July 
> 2018 16:49 > Subject: Re: [CF-metadata] Platform Heave
 > > All, > > Sorry for joining this conversation late. This is an
important > discussion for my group and finding a resolution would be
very > helpful. For my purposes I only need a good definition, which
might > coincide with the nautical definitions. For example this
reference > <https://www.wartsila.com/encyclopedia/term/ship-motions>
[https://cdn.wartsila.com/images/default-source/marine-pictures/encyclopedia-download.jpg?sfvrsn=adbfdc45_41zB]<https://www.wartsila.com/encyclopedia/term/ship-motions>

Ship motions - Wärtsilä<https://www.wartsila.com/encyclopedia/term/ship-motions>
www.wartsila.com
Ship motions. A ship at sea moves in six de

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Ken,


You're absolutely right - should have been platform_yaw_angle. Getting the 
detail spot on in these things isn't easy, which is why we have discussion 
lists!


With the way I'm currently seeing things I don't agree that pitch and roll 
affect the definition of heave. They are only factors that come into account 
with the coupling of heave into the next level of the CRS hierarchy.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Kenneth Kehoe 

Sent: 30 July 2018 18:39
Cc: CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

I agree with John the (keel to top of mast) statement is incorrect when the 
platform is tilted. I only inserted that to help describe the Z-axis. But I 
don't think it's helping. I think John is also right on point with this since I 
can't find a definition of heave that discusses the orientation of the platform 
and how it relates to the measurement of heave. That is why I'm suggesting we 
not try to tackle that issue. From an instrument perspective I don't think the 
organization writing the measurement to file actually know all the details of 
how the values are derived or the full reference frame. I tell people to not 
use the standard_name definitions unless they are positive it matches exactly, 
and without all the information I don't think people will be able to use a too 
specific definition. A less specific definition would allow the use now, and a 
more specific definition can be added later if needed.

I did like Roy's definition of platform_yaw_angle and platform_yaw_rate. My 
only suggestion is to remove the underscore in "yaw_angle" in the definition of 
platform_yaw_rate, or use the full term "platform_yaw_angle". Otherwise it 
appears like a reference to a different term.

Ken



On 2018-7-30 10:52, John Graybeal wrote:
1) Now that we have another platform_heave comment, could we please create a 
new thread for the discussion on pitch/roll/heading?  Maybe starting without 
all the historical points, at least the heave-related ones? Both are difficult 
conversations to follow in sequence.

2) I have a concern about the last two heave definitions.
  a) "Heave is the linear motion along the vertical Z-axis (e.g. keel to top of 
mast) with positive values representing upward motion.”

I like the thrust of this definition, it’s simple to understand. However I 
don’t think it’s measured in the direction of keel to top of mast of the 
current or recent vessel position, is it? I rather assume it is perpendicular 
to a nominally level service, possibly in the direction of the gravity vector. 
The dictionary definition "Heaving is the linear motion along the vertical 
Z-axis” with the positive values coda seems closer.

  b) "upwards vertical displacement of a platform over a measurement time 
interval”

I can’t tell how to parse ‘over’ here.  An upwards vertical displacement is 
relative to another position, and in this case I think that ‘original’ position 
is being measured (at least conceptually) during another time interval. It just 
needs a few words, something like “of a platform when compared to its average 
vertical position over a corresponding time interface”.

But I guess the fundamental issue is I can’t tell (and don’t actually know) 
what heave is determined with respect to. If my last 11 positions relative to 
average seas are 0, 1, 2, 2, 1, 4, 1, 2, 2, 1, 0 (think hilly!), I have no idea 
if the heave at the peak (‘4’) is 4 or something else — it just depends on when 
and how long the baseline measurement is, doesn’t it?  (Or to put it another 
way, is the heave at the 7th point a negative number, since the ship just went 
down 3 units?)  If someone can answer that then our best definition might be 
more obvious.

John

---
John Graybeal
jbgrayb...@mindspring.com<mailto:jbgrayb...@mindspring.com>

On Jul 29, 2018, at 04:29, Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear All,

Giving it some thought over the weekend I realise that where we lost the plot 
in this discussion was when we encountered 'direction of travel'. Jim 
succinctly described platform motion with the phrase 'nested co-ordinate 
systems'. What I failed to realise - and I'm guessing I'm not alone - is that 
the pitch, roll, heave etc. family of terms for platform motion refer SOLELY to 
the innermost co-ordinate reference in that nest and that the 'zero' for these 
measurements is 'platform at rest'. This innermost co-ordinate reference 
comprises three orthogonal axes that intersect at the platform's centre of 
gravity. Two of these are horizontal (Ken's longitudinal X-axis and transverse 
Y-axis) and the third vertical (Ken's vertical Z-axis). Others make no attempt 
to treat these parameters in the same way as zenith, and I now realise CF 
sh

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi John,


Think about my last posting. Heave is only relevant to the internal platform 
CRS. How it couples to other CRS, such as a 3-D platform locations, may well 
differ for different types of platform, but that should not be a concern of the 
heave definition.


Heave has a lot in common with pitche, roll, heave etc. so I don't think it 
should be decoupled.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: John Graybeal 
Sent: 30 July 2018 17:52
To: Lowry, Roy K.
Cc: Kenneth Kehoe; CF Metadata List
Subject: Re: [CF-metadata] Platform Heave

1) Now that we have another platform_heave comment, could we please create a 
new thread for the discussion on pitch/roll/heading?  Maybe starting without 
all the historical points, at least the heave-related ones? Both are difficult 
conversations to follow in sequence.

2) I have a concern about the last two heave definitions.
  a) "Heave is the linear motion along the vertical Z-axis (e.g. keel to top of 
mast) with positive values representing upward motion.”

I like the thrust of this definition, it’s simple to understand. However I 
don’t think it’s measured in the direction of keel to top of mast of the 
current or recent vessel position, is it? I rather assume it is perpendicular 
to a nominally level service, possibly in the direction of the gravity vector. 
The dictionary definition "Heaving is the linear motion along the vertical 
Z-axis” with the positive values coda seems closer.

  b) "upwards vertical displacement of a platform over a measurement time 
interval”

I can’t tell how to parse ‘over’ here.  An upwards vertical displacement is 
relative to another position, and in this case I think that ‘original’ position 
is being measured (at least conceptually) during another time interval. It just 
needs a few words, something like “of a platform when compared to its average 
vertical position over a corresponding time interface”.

But I guess the fundamental issue is I can’t tell (and don’t actually know) 
what heave is determined with respect to. If my last 11 positions relative to 
average seas are 0, 1, 2, 2, 1, 4, 1, 2, 2, 1, 0 (think hilly!), I have no idea 
if the heave at the peak (‘4’) is 4 or something else — it just depends on when 
and how long the baseline measurement is, doesn’t it?  (Or to put it another 
way, is the heave at the 7th point a negative number, since the ship just went 
down 3 units?)  If someone can answer that then our best definition might be 
more obvious.

John

---
John Graybeal
jbgrayb...@mindspring.com<mailto:jbgrayb...@mindspring.com>

On Jul 29, 2018, at 04:29, Lowry, Roy K. 
mailto:r...@bodc.ac.uk>> wrote:

Dear All,

Giving it some thought over the weekend I realise that where we lost the plot 
in this discussion was when we encountered 'direction of travel'. Jim 
succinctly described platform motion with the phrase 'nested co-ordinate 
systems'. What I failed to realise - and I'm guessing I'm not alone - is that 
the pitch, roll, heave etc. family of terms for platform motion refer SOLELY to 
the innermost co-ordinate reference in that nest and that the 'zero' for these 
measurements is 'platform at rest'. This innermost co-ordinate reference 
comprises three orthogonal axes that intersect at the platform's centre of 
gravity. Two of these are horizontal (Ken's longitudinal X-axis and transverse 
Y-axis) and the third vertical (Ken's vertical Z-axis). Others make no attempt 
to treat these parameters in the same way as zenith, and I now realise CF 
shouldn't be any different.

Having come to terms with this, Ken's definition elements hve a beautiful 
simplicity that can be slotted into Alison's compound definitions. My only 
problem is the inclusion of nautical terms like 'bow' and 'stern', but these 
can easily be replaced by generic equivalents such as 'front' and 'back'. I 
would also make it clearer is that zero is platform at rest.

For example the definition pair for yaw become:

platform_yaw_angle
"yaw _angle" is the amount of rotation from the rest position around the 
vertical Z-axis with positive values resulting in clockwise motion when viewed 
from above. The vertical Z axis, also known as the "yaw axis", is an imaginary 
line running vertically through the platform's centre of gravity.  Standard 
names for "platform" describe the motion and orientation of the vehicle from 
which observations are made. Platforms include, but are not limited to, 
satellites, aeroplanes, ships, instruments and buoys.

platform_yaw_rate

"platform_yaw_rate" is the change per unit time of "yaw_angle".  "yaw _angle" 
is the amount of rotation from the rest position around the vertical Z-axis 
with positive values resulting in clockwise motion when viewed from above. The 
vertical

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

'
nature of the quantities, which gets back to defining the
'moving-mean' sea level reference point.) Grace and peace,

Jim


On 6/1/18 11:23 AM, Nan Galbraith wrote:
Hi all -

The latest version is confusing to me. The term 'a platform that is
nominally at rest' does not apply to many platforms for which heave is
calculated; the original version of that, 'a moving object above the
vertical level of that object when stationary' was maybe a little more clear... 
if also a little wordy.

And, the term  'vertical displacement determined by integrating
vertical accelerations' may also not apply - I've been looking at the
different ways heave is calculated, and there are a few: 'Heave can be
computed from GPS RTK height measurements and from vertical accelerations 
measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical
displacement?  Do we need to be more specific than that?

Thanks - Nan


From: Lowry, Roy K.
Sent: 30 May 2018 21:37

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:

platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.

Cheers. Roy.


--
--

From: Lowry, Roy K. 
mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk>
Sent: 30 May 2018 21:02

Thanks Jim,

That work for me.

Cheers, Roy.

----------
--

From: Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 30 May 2018 18:39

Roy,

So, heave is integrated vertical acceleration? How about

platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.

Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

 Hi Jim,

 Does

  "Heave" is a term used to describe the vertical displacement
 of a moving object above the vertical level of that object
 when stationary.

 help by getting rid of the semantically-loaded word 'height'?
 If not, what would?

 I think the confusion is because you are thinking of heave in
 terms of position within a reference frame. To think of it as the
 vertical displacement between a real platform and a massless
 platform is misleading- such considerations are part of the
 derivation of wave height from high frequency heave measurements,
 which isn't relevant to a discussion of the raw measurement. It's
 also worth bearing in mind that whilst the debate has focused on
 platforms floating on the sea surface, the concept of heave could
 in theory be applied to objects in the atmosphere.

 In practice, heave is measured by accelerometers that are usually
 combined with tilt sensors that give pitch, roll and yaw. Hence,
 it is totally decoupled from any reference outside the platform.

 To answer your last muse, to get heave from a high frequency
 height relative to datum time series the method would need to
 determine the height of the object when 'stationary'. In the case
 of objects on the sea, 'stationary' is considered to be a flat
 calm sea (i.e. no waves), which can be approximated by averaging
 the raw time series. So, heave could be approximated by
 differencing the raw and averaged data. However, I can't think why
 anybody would want to do that.

 Cheers, Roy.


--
--

 From:Jim Biard 
<mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org>
 Sent: 26 May 2018 23:18

 My biggest concern is that the standard name definition makes it
 clear in some fashion or other that this is a measure of
 deviations from some lower frequency (or low-pass filtered)
 measure of vertical position. (As are sway and surge in relation
 to their corresponding horizontal coordinates.) As was pointed
 out, heave is used in certain communities, so it's reasonable to
 provide a standard name, but it seems rather imprecise as it has
 been described so far.

 If I have understood the explanations correctly, a time series of
 platform height relative to a fixed datum that has sufficient
 precision and frequency would fully represent the heave along with
 the more slowly varying effects of tide, waves, etc. So is heave,
 as usually used, the first-order instantaneous difference between
 the height of an actual platform and the height of a massle

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

pointed to the helpful Wikipedia page for ship motion, 
https://en.wikipedia.org/wiki/Ship_motions<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Ship-5Fmotions=DwMDaQ=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk=Vm7o2ZGxPkkqRuPs8nVMVQ=fsDk1eg5rM-so0h_XCTK_Pl1w5MGnQK88vuvHcbhUUI=gxXkUfvVSqtWNEzxwyAeuKgEMzADzXWv2OOZtOBRAao=>.
 The suggestions below are merged from different sections of that page, and 
might be a little ... long, but I'd also like to append something like 
'Platforms include but are not limited to satellites, aeroplanes, ships, 
instruments, and buoys.'

Pitch
The up/down rotation of a platform about its transverse/Y axis. The 
transverse/Y axis, lateral or pitch axis is an imaginary line running 
horizontally across the platform and through its center of gravity. A pitch  
motion is an up-or-down movement of the bow and stern of the platform.

Roll
The tilting rotation of a platform about its longitudinal/X axis. The 
longitudinal/X axis, or roll axis, is an imaginary line running horizontally 
through the length of the platform, through its center of gravity, and parallel 
to the waterline. A roll motion is a side-to-side or port-starboard tilting 
motion of the superstructure around this axis.

Yaw
The turning rotation of a platform about its vertical/Z axis. The vertical/Z 
axis, or yaw axis, is an imaginary line running vertically through the platform 
and through its center of gravity.
A yaw motion is a side-to side movement of the bow and stern of the ship.

And we had something like this for heave:
platform_heave (m) = upwards vertical displacement

I suppose these could also be applied to platform_*_rates.

Regards -
Nan


On 7/4/18 4:47 AM, Alison Pamment - UKRI STFC wrote:



Dear Steve,  > > Thank you for your message and apologies for not
having processed


 > your proposals as yet. I have been working on the CMIP names, but > they are 
 > reaching a conclusion and I will shortly be looking through > the many other 
 > proposals that have been waiting for attention. > > A quick look through the 
 > discussion of your names shows they are > pretty much agreed. You need take 
 > no further action at this time - I > will check that the names and 
 > definitions are clear and consistent > with existing names and get back to 
 > you on the list with any final > comments or questions. Version 56 of the 
 > standard name table will be > published later today - I think we can 
 > probably finalise your names > in time for version 57. > > Best wishes, 
 > Alison



From: Hamilton, Steve <mailto:sj.hamil...@fugro.com>
Sent: 03 July 2018 09:12


Please can you advise if this standard name has now been accepted and
when it will be included in the CF Standard Names

If there is something else to do please let me know

Thanks

Steve



From: Jim Biard 
mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org>>
Sent: 01 June 2018 22:56


Nan,
Thanks for pulling things back in. I very much like the idea of keeping 
technology or specific methods out of the definition if at all possible, so I 
like your proposal. I expect we should include platform in the definition, as 
well as an indication that this is dynamic (over time). How about these 
definitions?
platform_heave (m) = upwards vertical displacement of a platform over
a measurement time interval platform_heave_rate (m s-1) = upwards rate
of change in vertical displacement of a platform over a measurement time 
interval They leave out some detail but capture the relative nature of the 
quantities.
(In my mind, the primary detail being left out is the 'net zero'
nature of the quantities, which gets back to defining the
'moving-mean' sea level reference point.) Grace and peace,

Jim


On 6/1/18 11:23 AM, Nan Galbraith wrote:
Hi all -

The latest version is confusing to me. The term 'a platform that is
nominally at rest' does not apply to many platforms for which heave is
calculated; the original version of that, 'a moving object above the
vertical level of that object when stationary' was maybe a little more clear... 
if also a little wordy.

And, the term  'vertical displacement determined by integrating
vertical accelerations' may also not apply - I've been looking at the
different ways heave is calculated, and there are a few: 'Heave can be
computed from GPS RTK height measurements and from vertical accelerations 
measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical
displacement?  Do we need to be more specific than that?

Thanks - Nan


From: Lowry, Roy K.
Sent: 30 May 2018 21:37

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:

platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that 

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


If you can make clear suggestions that make the existing Standard Names more 
widely applicable without the need to rework legacy data that have been 
labelled with these Standard Names then that is obviously beneficial.  However, 
please do this by quoting concrete alternative definitions so that we can all 
understand where you are proposing we go from where we currently are.


BTW if you look at my last reply to Nan then you'll see that the wisdom of 
coupling the platform_orientation Standard Name into the definition of yaw has 
already been questioned.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 26 July 2018 20:05
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Roy,


I'm just trying to lay out the scope of the challenge to see if we can avoid 
defining terms in ways that require us to have ship_yaw as a different term 
than satellite_yaw, for example. I appreciate that the marine community has a 
long history (longer than the aerospace communities) with these terms. All the 
same, it seems to me that we should be able to define basic terms such as 
pitch, roll, and yaw (and maybe surge, sway, and heave as well) in terms that 
are usable by all. As an example, using platform_orientation in the definition 
of platform_yaw renders the term quasi-meaningless for platforms that require 
more than one quantity to define the transform between the platform body 
reference system and its motion reference system. Using platform_course in 
these definitions has a similar limiting effect for platforms that require more 
and/or different terms to define their motion reference frames.


Maybe it's not possible to find a happy medium, but I'm hoping to do so. I'll 
suggest some standard name definitions of my own shortly.


Grace and peace,


Jim

On 7/26/18 2:46 PM, Lowry, Roy K. wrote:

Dear Jim,


I think the problem is that the 'platform' standard names have been developed 
by a community versed in the ship/aircraft/buoy and to a lesser extent 
submarine/glider use cases (i.e. those with which you are least familiar) and 
we're now talking as if they should be totally generic.


The one thing I understand in your e-mail (most of it is gobbledy-gook to me as 
an observational oceanographer) is that there are different kinds of platforms 
with different degrees of freedom and their own terminology. For example, 
pitch, roll and yaw are not (hopefully!) concepts applicable to a fixed oil rig.


These data streams have been returned by our primary platforms (research 
vessels) for decades - e.g. heading that CF decided to name 
platform_orientation - has been in every research vessel navigation file that 
I've handled from the late 1980s to around 2005. There is usually also speed 
through the water, latitiude, longitude, speed made good (speed over the 
seabed), course made good, velocity north over seabed and velocity east over 
seabed. Some also include pitch, roll and yaw. You cannot suddenly decide that 
the data of decades should be transformed into an idealised generic co-ordinate 
reference system for CF.


My view is that realistically an all-encompassing, totally generic solution 
should be confined to the 'too hard' basket and that we should define the 
standard names based on use cases of known data streams. Consideration then 
would then need to be given to data streams outside the original scope as to 
whether the existing Standard Names are appropriate or new Standard Names are 
required.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 26 July 2018 18:25
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave


Alison, Roy,

I don't mean to be difficult, but I think that for greatest generality the 
"motion and orientation" of a platform pretty much has to be relative to a 
reference frame that depends only on the translational motion (if any) of the 
platform. When I look more closely at the definitions we have now, I also see 
that platform_course and platform_orientation are insufficient for the 
satellite case, and don't quite cover the airborne case. The full set of 
elements needed to define a point on a platform in its internal frame in terms 
of an earth-based reference frame are:

  *   Oim = Vector that describes the baseline offset of the origin of the 
platform's internal reference frame relative to the platform's motion frame.
  *   Mim = Matrix that describes the baseline rotation of the platform's 
internal reference frame relative to the platform's motion frame.
  *   Mrpy = Matrix

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

s us a minimum 
of 10 dynamic terms (roll, pitch, yaw, surge, sway, heave, X, Y, altitude, 
course), and Mim may not be definable using a single platform_orientation angle.

Ships (& land vehicles (& drifters?)):

I have no experience with ships. Based on what I've read in here and read 
online: Ome is defined using X/Y/(sea level). Mme is defined as it is in the 
airplane case. This gives us a minimum of 9 dynamic terms (roll, pitch, yaw, 
surge, sway, heave, X, Y, platform_course), and Mim is defined using the single 
platform_orientation angle.

Buoys:

No experience here either. But it appears to be: Ome is defined using a fixed 
X/Y/(sea level). Mme is defined (I guess?) with East, North, and Up as its X, 
Y, and Z unit vectors. This gives us a minimum of 6 dynamic terms (roll, pitch, 
yaw, surge, sway, heave), and Mim is defined using the single 
platform_orientation angle. At least that's my guess.

All that to point out that different kinds of platforms use different terms and 
have different degrees of freedom. We need to cover all these cases if we want 
to be both precise and general.

Grace and peace,

Jim

On 7/25/18 12:34 PM, Alison Pamment - UKRI STFC wrote:

Dear Roy and Jim,


Thanks again both for your help.


Both your replies are saying that referring to direction of motion for 
measuring yaw is a bad idea, and in any case it doesn't apply to stationary 
platforms (which presumably have some means of determining their own 
orientation relative to concepts such as 'up', 'north', etc.)  You are both 
advising against saying 'mean orientation' and I agree that it's not really a 
well-defined concept.


I like Roy's suggested text which refers to the platform's own axis to define 
yaw. So the full definition of platform_yaw_angle would be:

'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments and buoys. "Yaw" means 
rotation of the platform in the horizontal plane about its vertical/Z axis. The 
vertical/Z axis, also known as the "yaw axis", is an imaginary line running 
vertically through the platform and through its center of gravity. In yaw 
motion, the platform rotates clockwise or counter clockwise in the horizontal, 
relative to its orientation, which has the standard name platform_orientation. 
Platform yaw angle is the angle at a given instant between the platform's 
longitudinal/X axis and the position of that axis with high frequency 
variations (e.g. the effect of surface waves on a ship) removed. Zero yaw angle 
means the longitudinal axis is aligned with the platform_orientation. The usual 
sign convention is that yaw angle is measured positive when the front or leading
 edge of the platform is rotated clockwise from the platform_orientation.'


Okay?


Like Roy, I had wondered whether 'platform_orientation' should really be an 
instantaneous quantity or something with high frequency variability removed. If 
it is the latter (which I think was probably the original intention of the 
standard name) then we should amend the definition as follows:

'Standard names for "platform" describe the motion and orientation of the 
vehicle from which observations are made. Platforms include, but are not 
limited to, satellites, aeroplanes, ships, instruments and buoys. The platform 
orientation is the direction in which the "front" or longitudinal axis of the 
platform is pointing with high frequency variations (e.g. the effect of surface 
waves on a ship) removed. (This is not necessarily the same as the direction in 
which the platform is travelling, called platform_course).'


Okay?


As an additional point, I note that besides the names already discussed in this 
thread, there are a further 11 existing platform names. I will include the new 
text for 'platform' in their definitions as part of the August standard names 
update.


Best wishes,

Alison


From: Lowry, Roy K. <mailto:r...@bodc.ac.uk>
Sent: 25 July 2018 16:35:27
To: Pamment, Alison (STFC,RAL,RALSP); 
cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave


Hi again,


This is an area where it is easy to get tied up in knots because there are 
multiple reference frames. If we talk ships then there is the 
platform_orientation (or heading) which is measured using a gyro-compass - a 
stabilised instrument that eliminates high-frequency variations in where the 
bow is actually pointing and provides the zero reference point for yaw.


The concept of 'travel' relates to another reference frame external to the 
platform - say a GPS CRS  - but yaw only has relevance to the platform's 
internal reference frame. So you are right that bringing 'direction of travel' 
into a definition of yaw is a bad thing even though it's re

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

like Roy's suggested text which refers to the platform's own axis to define 
> yaw. So the full definition of platform_yaw_angle would be:
>
> 'Standard names for "platform" describe the motion and orientation of the 
> vehicle from which observations are made. Platforms include, but are not 
> limited to, satellites, aeroplanes, ships, instruments and buoys. "Yaw" means 
> rotation of the platform in the horizontal plane about its vertical/Z axis. 
> The vertical/Z axis, also known as the "yaw axis", is an imaginary line 
> running vertically through the platform and through its center of gravity. In 
> yaw motion, the platform rotates clockwise or counter clockwise in the 
> horizontal, relative to its orientation, which has the standard name 
> platform_orientation. Platform yaw angle is the angle at a given instant 
> between the platform's longitudinal/X axis and the position of that axis with 
> high frequency variations (e.g. the effect of surface waves on a ship) 
> removed. Zero yaw angle means the longitudinal axis is aligned with the 
> platform_orientation. The usual sign convention is that yaw angle is measured 
> positive when the front or
>   leading
>   edge of the platform is rotated clockwise from the platform_orientation.'
>
>
> Okay?
>
>
> Like Roy, I had wondered whether 'platform_orientation' should really be an 
> instantaneous quantity or something with high frequency variability removed. 
> If it is the latter (which I think was probably the original intention of the 
> standard name) then we should amend the definition as follows:
>
> 'Standard names for "platform" describe the motion and orientation of the 
> vehicle from which observations are made. Platforms include, but are not 
> limited to, satellites, aeroplanes, ships, instruments and buoys. The 
> platform orientation is the direction in which the "front" or longitudinal 
> axis of the platform is pointing with high frequency variations (e.g. the 
> effect of surface waves on a ship) removed. (This is not necessarily the same 
> as the direction in which the platform is travelling, called 
> platform_course).'
>
>
> Okay?
>
>
> As an additional point, I note that besides the names already discussed in 
> this thread, there are a further 11 existing platform names. I will include 
> the new text for 'platform' in their definitions as part of the August 
> standard names update.
>
>
> Best wishes,
>
> Alison
>
> 
> From: Lowry, Roy K. 
> Sent: 25 July 2018 16:35:27
> To: Pamment, Alison (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Platform Heave
>
>
> Hi again,
>
>
> This is an area where it is easy to get tied up in knots because there are 
> multiple reference frames. If we talk ships then there is the 
> platform_orientation (or heading) which is measured using a gyro-compass - a 
> stabilised instrument that eliminates high-frequency variations in where the 
> bow is actually pointing and provides the zero reference point for yaw.
>
>
> The concept of 'travel' relates to another reference frame external to the 
> platform - say a GPS CRS  - but yaw only has relevance to the platform's 
> internal reference frame. So you are right that bringing 'direction of 
> travel' into a definition of yaw is a bad thing even though it's reasonably 
> common practice to do so.
>
>
> Mean orientation is also possibly best avoided as the platform_orientation 
> isn't necessarily determined by averaging instantaneous longitudinal axis 
> orientations.  It could be - and often is - measured by something that has 
> greater inertia than the platform.
>
>
> So how about using :
>
>
> Platform yaw angle is the angle at a given instant between the platform's 
> longitudinal/X axis and the position of that axis with high frequency 
> variations (e.g. the effect of surface waves on a ship) removed. Zero yaw 
> angle means the longitudinal axis is aligned with the platform_orientation. 
> The usual sign convention is that yaw angle is measured positive when the 
> front or leading edge of the platform is rotated clockwise from the 
> platform_orientation.
>
>
> This raises the question as to whether the platform_orientation definition 
> should have the clarification 'with high-frequency variability removed' 
> added. This would be an explicit statement of what - to me at least - is 
> commonly understood meaning of 'heading'.
>
>
> Does that help?
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
>
> 
>

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

erged 
from different sections of that page, and might be a little ... long, but I'd 
also like to append something like 'Platforms include but are not limited to 
satellites, aeroplanes, ships, instruments, and buoys.'

Pitch
The up/down rotation of a platform about its transverse/Y axis. The 
transverse/Y axis, lateral or pitch axis is an imaginary line running 
horizontally across the platform and through its center of gravity. A pitch  
motion is an up-or-down movement of the bow and stern of the platform.

Roll
The tilting rotation of a platform about its longitudinal/X axis. The 
longitudinal/X axis, or roll axis, is an imaginary line running horizontally 
through the length of the platform, through its center of gravity, and parallel 
to the waterline. A roll motion is a side-to-side or port-starboard tilting 
motion of the superstructure around this axis.

Yaw
The turning rotation of a platform about its vertical/Z axis. The vertical/Z 
axis, or yaw axis, is an imaginary line running vertically through the platform 
and through its center of gravity.
A yaw motion is a side-to side movement of the bow and stern of the ship.

And we had something like this for heave:
platform_heave (m) = upwards vertical displacement

I suppose these could also be applied to platform_*_rates.

Regards -
Nan


On 7/4/18 4:47 AM, Alison Pamment - UKRI STFC wrote:

> Dear Steve,  > > Thank you for your message and apologies for not
> having processed
 > your proposals as yet. I have been working on the CMIP names, but > they are 
 > reaching a conclusion and I will shortly be looking through > the many other 
 > proposals that have been waiting for attention. > > A quick look through the 
 > discussion of your names shows they are > pretty much agreed. You need take 
 > no further action at this time - I > will check that the names and 
 > definitions are clear and consistent > with existing names and get back to 
 > you on the list with any final > comments or questions. Version 56 of the 
 > standard name table will be > published later today - I think we can 
 > probably finalise your names > in time for version 57. > > Best wishes, 
 > Alison
> 
> From: Hamilton, Steve 
> Sent: 03 July 2018 09:12
>
>
> Please can you advise if this standard name has now been accepted and
> when it will be included in the CF Standard Names
>
> If there is something else to do please let me know
>
> Thanks
>
> Steve
>
>
> 
> From: Jim Biard mailto:jbi...@cicsnc.org>>
> Sent: 01 June 2018 22:56
>
>
> Nan,
> Thanks for pulling things back in. I very much like the idea of keeping 
> technology or specific methods out of the definition if at all possible, so I 
> like your proposal. I expect we should include platform in the definition, as 
> well as an indication that this is dynamic (over time). How about these 
> definitions?
> platform_heave (m) = upwards vertical displacement of a platform over
> a measurement time interval platform_heave_rate (m s-1) = upwards rate
> of change in vertical displacement of a platform over a measurement time 
> interval They leave out some detail but capture the relative nature of the 
> quantities.
> (In my mind, the primary detail being left out is the 'net zero'
> nature of the quantities, which gets back to defining the
> 'moving-mean' sea level reference point.) Grace and peace,
>
> Jim

> On 6/1/18 11:23 AM, Nan Galbraith wrote:
> Hi all -
>
> The latest version is confusing to me. The term 'a platform that is
> nominally at rest' does not apply to many platforms for which heave is
> calculated; the original version of that, 'a moving object above the
> vertical level of that object when stationary' was maybe a little more 
> clear... if also a little wordy.
>
> And, the term  'vertical displacement determined by integrating
> vertical accelerations' may also not apply - I've been looking at the
> different ways heave is calculated, and there are a few: 'Heave can be
> computed from GPS RTK height measurements and from vertical accelerations 
> measured by linear accelerometers'
>
> Why  not keep it simple: platform_heave (m) = upwards vertical
> displacement?  Do we need to be more specific than that?
>
> Thanks - Nan
>
>
> From: Lowry, Roy K.
> Sent: 30 May 2018 21:37
>
> An afterthought. Heave is conventionally positive upwards so to make this 
> clear I would add the word 'upwards' thus:
>
> platform_heave (m) = upwards vertical displacement determined by integrating 
> vertical accelerations of a platform that is nominally at rest.
>
> platform_heave_rate (m s-1) = upwards vertical velocity determined by 
> integrating vertical acceleration

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

uly 2018 17:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

Hi Alison, Steve, and all -

Since we have a little time to finalize this, could we also consider updating 
the definitions of platform_pitch_angle, platform_roll_angle and 
platform_yaw_angle?

Currently, these all say 'Standard names for platform describe the motion and 
orientation of the vehicle from which observations are made e.g. aeroplane, 
ship or satellite.'

John Helly pointed to the helpful Wikipedia page for ship motion, 
https://en.wikipedia.org/wiki/Ship_motions. The suggestions below are merged 
from different sections of that page, and might be a little ... long, but I'd 
also like to append something like 'Platforms include but are not limited to 
satellites, aeroplanes, ships, instruments, and buoys.'

Pitch
The up/down rotation of a platform about its transverse/Y axis. The 
transverse/Y axis, lateral or pitch axis is an imaginary line running 
horizontally across the platform and through its center of gravity. A pitch  
motion is an up-or-down movement of the bow and stern of the platform.

Roll
The tilting rotation of a platform about its longitudinal/X axis. The 
longitudinal/X axis, or roll axis, is an imaginary line running horizontally 
through the length of the platform, through its center of gravity, and parallel 
to the waterline. A roll motion is a side-to-side or port-starboard tilting 
motion of the superstructure around this axis.

Yaw
The turning rotation of a platform about its vertical/Z axis. The vertical/Z 
axis, or yaw axis, is an imaginary line running vertically through the platform 
and through its center of gravity.
A yaw motion is a side-to side movement of the bow and stern of the ship.

And we had something like this for heave:
platform_heave (m) = upwards vertical displacement

I suppose these could also be applied to platform_*_rates.

Regards -
Nan


On 7/4/18 4:47 AM, Alison Pamment - UKRI STFC wrote:

> Dear Steve,  > > Thank you for your message and apologies for not
> having processed
 > your proposals as yet. I have been working on the CMIP names, but > they are 
 > reaching a conclusion and I will shortly be looking through > the many other 
 > proposals that have been waiting for attention. > > A quick look through the 
 > discussion of your names shows they are > pretty much agreed. You need take 
 > no further action at this time - I > will check that the names and 
 > definitions are clear and consistent > with existing names and get back to 
 > you on the list with any final > comments or questions. Version 56 of the 
 > standard name table will be > published later today - I think we can 
 > probably finalise your names > in time for version 57. > > Best wishes, 
 > Alison
> 
> From: Hamilton, Steve 
> Sent: 03 July 2018 09:12
>
>
> Please can you advise if this standard name has now been accepted and
> when it will be included in the CF Standard Names
>
> If there is something else to do please let me know
>
> Thanks
>
> Steve
>
>
> 
> From: Jim Biard mailto:jbi...@cicsnc.org>>
> Sent: 01 June 2018 22:56
>
>
> Nan,
> Thanks for pulling things back in. I very much like the idea of keeping 
> technology or specific methods out of the definition if at all possible, so I 
> like your proposal. I expect we should include platform in the definition, as 
> well as an indication that this is dynamic (over time). How about these 
> definitions?
> platform_heave (m) = upwards vertical displacement of a platform over
> a measurement time interval platform_heave_rate (m s-1) = upwards rate
> of change in vertical displacement of a platform over a measurement time 
> interval They leave out some detail but capture the relative nature of the 
> quantities.
> (In my mind, the primary detail being left out is the 'net zero'
> nature of the quantities, which gets back to defining the
> 'moving-mean' sea level reference point.) Grace and peace,
>
> Jim

> On 6/1/18 11:23 AM, Nan Galbraith wrote:
> Hi all -
>
> The latest version is confusing to me. The term 'a platform that is
> nominally at rest' does not apply to many platforms for which heave is
> calculated; the original version of that, 'a moving object above the
> vertical level of that object when stationary' was maybe a little more 
> clear... if also a little wordy.
>
> And, the term  'vertical displacement determined by integrating
> vertical accelerations' may also not apply - I've been looking at the
> different ways heave is calculated, and there are a few: 'Heave can be
> computed from GPS RTK height measurements and from vertical accelerations 
> measured by linear accelerometers'
>
> Why  not keep it simple: platform_heave

Re: [CF-metadata] Standard Names to support Trac ticket 99

[Lowry, Roy K.]

Many thanks,


I'll have a look at Section 6 and get back to you if I've any further queries 
or issues. I wasn't sure how much had changed since 1.5 and consequently 
whether you're previous comments were still valid.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 12 July 2018 17:48
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99

Dear Roy

Ah, OK. Thanks. Having thought about that, I went to look at ticket 99, and
found that I'd said the same thing five years ago in comment 1. As you see,
I'm bit-reproducible.

I propose that we should tidy the CF document by promoting 6.1.1 on "Geographic
regions" to 6.3 (i.e. remove it from 6.1), and adding yours as 6.4. Then 6.1
and 6.2 will describe mechanisms in CF, and 6.3 and 6.4 applications of these
mechanisms.

Does that seem OK?

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Thu, 12 Jul 2018 16:04:07 +0000
> From: "Lowry, Roy K." 
> To: "cf-metadata@cgd.ucar.edu" ,
>"j.m.greg...@reading.ac.uk" 
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Jonathan,
>
>
> The extra text that I am preparing in the Trac ticket for addition to the CF 
> Conventions. I was hoping your familiarity with these could recommend a 
> suitable section for amendment.
>
>
> Cheers, Roy.
>
>
> I have now retired but will continue to be active through an Emeritus 
> Fellowship using this e-mail address.
>
>
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 12 July 2018 16:36
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Roy
>
> That's good news. Thanks for your patience. I like this new proposal, but I'm
> not sure what you're asking me. Which extra text?
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from "Lowry, Roy K."  -
>
> > Date: Thu, 12 Jul 2018 11:54:57 +
> > From: "Lowry, Roy K." 
> > To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
> >
> > Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
> >
> > Dear Jonathan,
> >
> >
> > Getting back to this now I've had some feedback. 'organisms_in_taxon' is 
> > fine and a remodelled proposal on this basis is given below. I'll try and 
> > get to your comments on the trac proposal in the coming week. To save me a 
> > lot of reading would you have a recommendation on where I should look to 
> > add the extra text?
> >
> >
> > Cheers, Roy.
> >
> > biological_taxon_name
> > biological_taxon_lsid
> > number_concentration_of_organisms_in_taxon_in_sea_water
> > mass_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> > mass_concentration_of_organisms_in_taxon_expressed_as_chlorophyll_in_sea_water
> > mass_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
> > mole_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> > mole_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
> >
> >
> > biological_taxon_name
> >
> > A plaintext human-readable label, usually a Latin binomial such as Calanus 
> > finmarchicus, applied to a biological taxon. Biological taxon is a name or 
> > other label identifying an organism or a group of organisms as belonging to 
> > a unit of classification in a hierarchical taxonomy.
> >
> > dimensionless
> >
> > biological_taxon_lsid
> >
> > The Life Science Identifier (LSID) is a standard URI for a biological 
> > taxon. Biological taxon is a name or other label identifying an organism or 
> > a group of organisms as belonging to a unit of classification in a 
> > hierarchical taxonomy. The LSID is a URN with the syntax 
> > ‘urn:lsid:::[:]’. For example, the 
> > copepod Calocalanus pavo may be represented by LSIDs 
> > ‘urn:lsid:marinespecies.org:taxname:104669’ (based on WoRMS) and 
> > urn:lsid:itis.gov:itis_tsn:85335’ (based on ITIS). These URNs may be 
> > converted to URLs delivering RDF by prefixing with 'http://lsid.tdwg.org/'.
> >
> > dimensionless
> >
> > number_concentration_of_organisms_in_taxon_in_sea_water
> >
> > Number concentration means the count of an entity per unit volume and is 
> > used in the construction ‘number_concentration_of_X_in_Y’, where X is a 
> > material cons

Re: [CF-metadata] Standard Names to support Trac ticket 99

[Lowry, Roy K.]

Dear Jonathan,


The extra text that I am preparing in the Trac ticket for addition to the CF 
Conventions. I was hoping your familiarity with these could recommend a 
suitable section for amendment.


Cheers, Roy.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 12 July 2018 16:36
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99

Dear Roy

That's good news. Thanks for your patience. I like this new proposal, but I'm
not sure what you're asking me. Which extra text?

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Thu, 12 Jul 2018 11:54:57 +0000
> From: "Lowry, Roy K." 
> To: Jonathan Gregory , "cf-metadata@cgd.ucar.edu"
>
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Jonathan,
>
>
> Getting back to this now I've had some feedback. 'organisms_in_taxon' is fine 
> and a remodelled proposal on this basis is given below. I'll try and get to 
> your comments on the trac proposal in the coming week. To save me a lot of 
> reading would you have a recommendation on where I should look to add the 
> extra text?
>
>
> Cheers, Roy.
>
> biological_taxon_name
> biological_taxon_lsid
> number_concentration_of_organisms_in_taxon_in_sea_water
> mass_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> mass_concentration_of_organisms_in_taxon_expressed_as_chlorophyll_in_sea_water
> mass_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
> mole_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
> mole_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water
>
>
> biological_taxon_name
>
> A plaintext human-readable label, usually a Latin binomial such as Calanus 
> finmarchicus, applied to a biological taxon. Biological taxon is a name or 
> other label identifying an organism or a group of organisms as belonging to a 
> unit of classification in a hierarchical taxonomy.
>
> dimensionless
>
> biological_taxon_lsid
>
> The Life Science Identifier (LSID) is a standard URI for a biological taxon. 
> Biological taxon is a name or other label identifying an organism or a group 
> of organisms as belonging to a unit of classification in a hierarchical 
> taxonomy. The LSID is a URN with the syntax 
> ‘urn:lsid:::[:]’. For example, the 
> copepod Calocalanus pavo may be represented by LSIDs 
> ‘urn:lsid:marinespecies.org:taxname:104669’ (based on WoRMS) and 
> urn:lsid:itis.gov:itis_tsn:85335’ (based on ITIS). These URNs may be 
> converted to URLs delivering RDF by prefixing with 'http://lsid.tdwg.org/'.
>
> dimensionless
>
> number_concentration_of_organisms_in_taxon_in_sea_water
>
> Number concentration means the count of an entity per unit volume and is used 
> in the construction ‘number_concentration_of_X_in_Y’, where X is a material 
> constituent of Y.. Biological taxon is a name or other label identifying an 
> organism or a group of organisms as belonging to a unit of classification in 
> a hierarchical taxonomy. Number concentration of biota is also referred to as 
> abundance.
>
> m-3
>
> mass_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water
>
> Mass concentration means mass per unit volume and is used in the construction 
> ‘mass_concentration_of_X_in_Y’, where X is a material constituent of Y. A 
> chemical species denoted by X may be described by a single term such as 
> 'nitrogen' or a phrase such as
> 'nox_expressed_as_nitrogen'. The phrase 'expressed_as' is used in the 
> construction ‘A_expressed_as_B’, where B is a chemical constituent of A. It 
> means that the quantity indicated by the standard name is calculated solely 
> with respect to the B contained in A, neglecting all other chemical 
> constituents of A. Mass concentration of biota expressed as carbon is also 
> referred to as carbon biomass. Biological taxon is a name or other label 
> identifying an organism or a group of organisms as belonging to a unit of 
> classification in a hierarchical taxonomy.
>
>  kg m-3
>
> mass_concentration_of_organisms_in_taxon_expressed_as_chlorophyll_in_sea_water
>
> Mass concentration means mass per unit volume and is used in the construction 
> ‘mass_concentration_of_X_in_Y’, where X is a material constituent of Y. A 
> chemical or biological species denoted by X may be described by a single term 
> such as 'nitrogen' or a phrase such as 'nox_expressed_as_nitrogen'. The 
> phrase 'expressed_as' is used in the
> construction ‘A_expressed_as_B’, where B is a chemica

Re: [CF-metadata] Standard Names to support Trac ticket 99

[Lowry, Roy K.]

mole_concentration_of_organisms_in_taxon_expressed_as_carbon_in_sea_water

Mole concentration means number of moles per unit volume, also called 
‘molarity’, and is used in the construction ‘mole_concentration_of_X_in_Y’, 
where X is a material constituent of Y. A chemical species denoted by X may be 
described by a single term such as 'nitrogen' or a phrase such as 
'nox_expressed_as_nitrogen'. The phrase 'expressed_as' is used in the 
construction ‘A_expressed_as_B’, where B is a chemical constituent of A. It 
means that the quantity indicated by the standard name is calculated solely 
with respect to the B contained in A, neglecting all other chemical 
constituents of A. Biological taxon is a name or other label identifying an 
organism or a group of organisms as belonging to a unit of classification in a 
hierarchical taxonomy.

mol m-3

mole_concentration_of_organisms_in_taxon_expressed_as_nitrogen_in_sea_water

Mole concentration means number of moles per unit volume, also called 
‘molarity’, and is used in the construction ‘mole_concentration_of_X_in_Y’, 
where X is a material constituent of Y. A chemical species denoted by X may be 
described by a single term such as 'nitrogen' or a phrase such as 
'nox_expressed_as_nitrogen'. The phrase 'expressed_as' is used in the 
construction ‘A_expressed_as_B’, where B is a chemical constituent of A. It 
means that the quantity indicated by the standard name is calculated solely 
with respect to the B contained in A, neglecting all other chemical 
constituents of A. Biological taxon is a name or other label identifying an 
organism or a group of organisms as belonging to a unit of classification in a 
hierarchical taxonomy.

mol m-3



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 21 May 2018 16:37
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99

Dear Roy and Martin

I think taxonomic_category might be a little better than taxon, but it still
seems obscure to me. Can you see something wrong with organisms_in_taxon (or
_from_ or _belonging_to_) for instance? It is the organisms we mean.

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K."  -

> Date: Mon, 21 May 2018 08:02:05 +0000
> From: "Lowry, Roy K." 
> To: Martin Juckes - UKRI STFC ,
>"cf-metadata@cgd.ucar.edu" ,
>"j.m.greg...@reading.ac.uk" 
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Jonathan,
>
>
> Getting back to Trac 99. I prefer Martin's suggestion here. Are you happy 
> with that?
>
>
> Cheers, Roy.
>
>
> I am retiring on 31/05/2018 but will continue to be active through an 
> Emeritus Fellowship using this e-mail address.
>
>
> 
> From: Martin Juckes - UKRI STFC 
> Sent: 02 May 2018 08:47
> To: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk; Lowry, Roy K.
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Roy, Jonathan,
>
>
> I understand the cause of Jonathan's concern: wikipedia suggests a broader 
> interpretation of "taxon" which would be consistent with using the word to 
> refer to the organisms from a biological taxon, but the Encyclopedia 
> Britannica has a narrower and perhaps more scientifically precise definition 
> in which "taxon" refers to the name, not the organisms matching the name 
> (https://www.britannica.com/science/taxon ). The article uses the phrase 
> "taxonomic category" which could be used as an alternative to Jonathan's 
> suggestion:
>
> mass_concentration_of_taxonomic_category_expressed_as_carbon_in_sea_water
>
>
> regards,
>
> Martin
>
>
> 
> From: CF-metadata  on behalf of Jonathan 
> Gregory 
> Sent: 01 May 2018 17:08
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Roy
>
> I agree that the confusion is unlikely. Maybe I shouldn't have given that
> example, because it's distracting. My discomfort is just that "taxon" doesn't
> mean "organisms" but "name of type of organisms" e.g. in
>   mass_concentration_of_biological_taxon_expressed_as_carbon_in_sea_water
> you can substitute your proposed definition of taxon, to get
>   
> mass_concentration_of_name_identifying_an_organism_as_belonging_to_a_unit_of_classification_expressed_as_carbon_in_sea_water
> I think you mean
>   
> mass_concentration_of_organisms_from_biological_taxon_expressed_as_carbon_in_sea_water
> That's a bit longer, but feels more comfortable to me.
>
> Best wishes
>
> Jonathan
>
>
> ---

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

I'm equally happy with this.


I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 01 June 2018 22:56
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Nan,

Thanks for pulling things back in. I very much like the idea of keeping 
technology or specific methods out of the definition if at all possible, so I 
like your proposal. I expect we should include platform in the definition, as 
well as an indication that this is dynamic (over time). How about these 
definitions?

platform_heave (m) = upwards vertical displacement of a platform over a 
measurement time interval

platform_heave_rate (m s-1) = upwards rate of change in vertical displacement 
of a platform over a measurement time interval

They leave out some detail but capture the relative nature of the quantities.

(In my mind, the primary detail being left out is the 'net zero' nature of the 
quantities, which gets back to defining the 'moving-mean' sea level reference 
point.)

Grace and peace,

Jim

On 6/1/18 11:23 AM, Nan Galbraith wrote:
Hi all -

The latest version is confusing to me. The term 'a platform that is nominally 
at rest' does
not apply to many platforms for which heave is calculated; the original version 
of that,
'a moving object above the vertical level of that object when stationary' was 
maybe a little
more clear... if also a little wordy.

And, the term  'vertical displacement determined by integrating vertical 
accelerations' may
also not apply - I've been looking at the different ways heave is calculated, 
and there
are a few: 'Heave can be computed from GPS RTK height measurements and from
vertical accelerations measured by linear accelerometers'

Why  not keep it simple: platform_heave (m) = upwards vertical displacement?  
Do we need
to be more specific than that?

Thanks - Nan

On 5/31/18 5:01 AM, Hamilton, Steve wrote:

Thanks for everyone’s input, the below seems acceptable for now

Regards

Steve

From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Lowry, Roy K.
Sent: 30 May 2018 21:37
To: Jim Biard <mailto:jbi...@cicsnc.org>; 
cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:

platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.

Cheers. Roy.

I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Lowry, Roy K. mailto:r...@bodc.ac.uk> 
<mailto:r...@bodc.ac.uk><mailto:r...@bodc.ac.uk>>
Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu> 
<mailto:cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Thanks Jim,

That work for me.

Cheers, Roy.



From: CF-metadata 
mailto:cf-metadata-boun...@cgd.ucar.edu> 
<mailto:cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu>>
 on behalf of Jim Biard mailto:jbi...@cicsnc.org> 
<mailto:jbi...@cicsnc.org><mailto:jbi...@cicsnc.org>>
Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu> 
<mailto:cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

Roy,

So, heave is integrated vertical acceleration? How about

platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.

Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,

Does

 "Heave" is a term used to describe the vertical displacement
of a moving object above the vertical level of that object
when stationary.

help by getting rid of the semantically-loaded word 'height'?
If not, what would?

I think the confusion is because you are thinking of heave in
terms of position within a reference frame. To think of it as the
vertical displacement between a real platform and a massless
platform is mislea

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

An afterthought. Heave is conventionally positive upwards so to make this clear 
I would add the word 'upwards' thus:


platform_heave (m) = upwards vertical displacement determined by integrating 
vertical accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = upwards vertical velocity determined by 
integrating vertical accelerations of a platform that is nominally at rest.


Cheers. Roy.



I have now retired but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Lowry, Roy K. 

Sent: 30 May 2018 21:02
To: Jim Biard; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Thanks Jim,


That work for me.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Roy,


So, heave is integrated vertical acceleration? How about


platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.


Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,


Does


 "Heave" is a term used to describe the vertical displacement of a moving 
object above the vertical level of that object when stationary.

help by getting rid of the semantically-loaded word 'height'? If not, what 
would?

I think the confusion is because you are thinking of heave in terms of position 
within a reference frame. To think of it as the vertical displacement between a 
real platform and a massless platform is misleading- such considerations are 
part of the derivation of wave height from high frequency heave measurements, 
which isn't relevant to a discussion of the raw measurement. It's also worth 
bearing in mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to objects in the 
atmosphere.

In practice, heave is measured by accelerometers that are usually combined with 
tilt sensors that give pitch, roll and yaw. Hence, it is totally decoupled from 
any reference outside the platform.

To answer your last muse, to get heave from a high frequency height relative to 
datum time series the method would need to determine the height of the object 
when 'stationary'. In the case of objects on the sea, 'stationary' is 
considered to be a flat calm sea (i.e. no waves), which can be approximated by 
averaging the raw time series. So, heave could be approximated by differencing 
the raw and averaged data. However, I can't think why anybody would want to do 
that.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it clear in some 
fashion or other that this is a measure of deviations from some lower frequency 
(or low-pass filtered) measure of vertical position. (As are sway and surge in 
relation to their corresponding horizontal coordinates.) As was pointed out, 
heave is used in certain communities, so it's reasonable to provide a standard 
name, but it seems rather imprecise as it has been described so far.

If I have understood the explanations correctly, a time series of platform 
height relative to a fixed datum that has sufficient precision and frequency 
would fully represent the heave along with the more slowly varying effects of 
tide, waves, etc. So is heave, as usually used, the first-order instantaneous 
difference between the height of an actual platform and the height of a 
massless ideal platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of instantaneous 
measures of height relative to a fixed datum be separated in practice into 
heave and "non-heave" height?

Getting back on track, it seems to me that the definition ought to somehow 
assist the reader in understanding how heave relates to other measures of 
height.

[CICS-NC]<http://www.cicsnc.org/>Visit us on
[https://ncics.org/wp-content/themes/ncics/img/NCICS_logo-560x292.png]<http://www.cicsnc.org/>

North Carolina Institute for Climate Studies<http://www.cicsnc.org/>
www.cicsnc.org<http://www.cicsnc.org>
The North Carolina Institute for Climate Stud

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Thanks Jim,


That work for me.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Jim Biard 

Sent: 30 May 2018 18:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Roy,


So, heave is integrated vertical acceleration? How about


platform_heave (m) = vertical displacement determined by integrating vertical 
accelerations of a platform that is nominally at rest.

platform_heave_rate (m s-1) = vertical velocity determined by integrating 
vertical accelerations of a platform that is nominally at rest.


Jim

On 5/27/18 5:38 AM, Lowry, Roy K. wrote:

Hi Jim,


Does


 "Heave" is a term used to describe the vertical displacement of a moving 
object above the vertical level of that object when stationary.

help by getting rid of the semantically-loaded word 'height'? If not, what 
would?

I think the confusion is because you are thinking of heave in terms of position 
within a reference frame. To think of it as the vertical displacement between a 
real platform and a massless platform is misleading- such considerations are 
part of the derivation of wave height from high frequency heave measurements, 
which isn't relevant to a discussion of the raw measurement. It's also worth 
bearing in mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to objects in the 
atmosphere.

In practice, heave is measured by accelerometers that are usually combined with 
tilt sensors that give pitch, roll and yaw. Hence, it is totally decoupled from 
any reference outside the platform.

To answer your last muse, to get heave from a high frequency height relative to 
datum time series the method would need to determine the height of the object 
when 'stationary'. In the case of objects on the sea, 'stationary' is 
considered to be a flat calm sea (i.e. no waves), which can be approximated by 
averaging the raw time series. So, heave could be approximated by differencing 
the raw and averaged data. However, I can't think why anybody would want to do 
that.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Jim Biard <mailto:jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it clear in some 
fashion or other that this is a measure of deviations from some lower frequency 
(or low-pass filtered) measure of vertical position. (As are sway and surge in 
relation to their corresponding horizontal coordinates.) As was pointed out, 
heave is used in certain communities, so it's reasonable to provide a standard 
name, but it seems rather imprecise as it has been described so far.

If I have understood the explanations correctly, a time series of platform 
height relative to a fixed datum that has sufficient precision and frequency 
would fully represent the heave along with the more slowly varying effects of 
tide, waves, etc. So is heave, as usually used, the first-order instantaneous 
difference between the height of an actual platform and the height of a 
massless ideal platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of instantaneous 
measures of height relative to a fixed datum be separated in practice into 
heave and "non-heave" height?

Getting back on track, it seems to me that the definition ought to somehow 
assist the reader in understanding how heave relates to other measures of 
height.

[CICS-NC]<http://www.cicsnc.org/>Visit us on
[https://ncics.org/wp-content/themes/ncics/img/NCICS_logo-560x292.png]<http://www.cicsnc.org/>

North Carolina Institute for Climate Studies<http://www.cicsnc.org/>
www.cicsnc.org<http://www.cicsnc.org>
The North Carolina Institute for Climate Studies is a unique center of 
excellence showcasing a partnership between universities, the private sector, 
non-profit organizations, community groups, and the federal government.



Facebook<http://www.facebook.com/cicsnc>Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocea

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Hi Jim,


Does


 "Heave" is a term used to describe the vertical displacement of a moving 
object above the vertical level of that object when stationary.

help by getting rid of the semantically-loaded word 'height'? If not, what 
would?

I think the confusion is because you are thinking of heave in terms of position 
within a reference frame. To think of it as the vertical displacement between a 
real platform and a massless platform is misleading- such considerations are 
part of the derivation of wave height from high frequency heave measurements, 
which isn't relevant to a discussion of the raw measurement. It's also worth 
bearing in mind that whilst the debate has focused on platforms floating on the 
sea surface, the concept of heave could in theory be applied to objects in the 
atmosphere.

In practice, heave is measured by accelerometers that are usually combined with 
tilt sensors that give pitch, roll and yaw. Hence, it is totally decoupled from 
any reference outside the platform.

To answer your last muse, to get heave from a high frequency height relative to 
datum time series the method would need to determine the height of the object 
when 'stationary'. In the case of objects on the sea, 'stationary' is 
considered to be a flat calm sea (i.e. no waves), which can be approximated by 
averaging the raw time series. So, heave could be approximated by differencing 
the raw and averaged data. However, I can't think why anybody would want to do 
that.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Jim Biard 
<jbi...@cicsnc.org>
Sent: 26 May 2018 23:18
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

My biggest concern is that the standard name definition makes it clear in some 
fashion or other that this is a measure of deviations from some lower frequency 
(or low-pass filtered) measure of vertical position. (As are sway and surge in 
relation to their corresponding horizontal coordinates.) As was pointed out, 
heave is used in certain communities, so it's reasonable to provide a standard 
name, but it seems rather imprecise as it has been described so far.

If I have understood the explanations correctly, a time series of platform 
height relative to a fixed datum that has sufficient precision and frequency 
would fully represent the heave along with the more slowly varying effects of 
tide, waves, etc. So is heave, as usually used, the first-order instantaneous 
difference between the height of an actual platform and the height of a 
massless ideal platform that would maintain a fixed offset relative to the sea 
surface? And, just out of curiosity, how would a time series of instantaneous 
measures of height relative to a fixed datum be separated in practice into 
heave and "non-heave" height?

Getting back on track, it seems to me that the definition ought to somehow 
assist the reader in understanding how heave relates to other measures of 
height.

[CICS-NC]<http://www.cicsnc.org/>Visit us on
[https://ncics.org/wp-content/themes/ncics/img/NCICS_logo-560x292.png]<http://www.cicsnc.org/>

North Carolina Institute for Climate Studies<http://www.cicsnc.org/>
www.cicsnc.org
The North Carolina Institute for Climate Studies is a unique center of 
excellence showcasing a partnership between universities, the private sector, 
non-profit organizations, community groups, and the federal government.



Facebook<http://www.facebook.com/cicsnc>Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocean and 
geophysics<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo<http://www.twitter.com/NOAANCEIocngeo>.



On Sat, May 26, 2018 at 3:11 AM, Lowry, Roy K. 
<r...@bodc.ac.uk<mailto:r...@bodc.ac.uk>> wrote:

Dear Jim and John,


Heave is indeed a height relative to a datum, that datum being the calm sea 
surface, which is a local short interval mean sea level that isn't linked into 
any global reference system.  Indeed the 'datum' moves relative to the rest of 
the world - but not the platform - as tide rises and falls so many would prefer 
to call it an 'instrument zero' rather than a 'datum'.


Heave is therefore a very different measurement to any sea l

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Jim and John,


Heave is indeed a height relative to a datum, that datum being the calm sea 
surface, which is a local short interval mean sea level that isn't linked into 
any global reference system.  Indeed the 'datum' moves relative to the rest of 
the world - but not the platform - as tide rises and falls so many would prefer 
to call it an 'instrument zero' rather than a 'datum'.


Heave is therefore a very different measurement to any sea level parameter and 
is the raw measurement recorded at high (Hz to kHz) frequency as a time series 
by floating wave instruments such as waveriders and shipborne wave recorders. 
It therefore cannot be sensibly described by the same or similar Standard Name 
as a measurement of height above a globally referenced datum like long-term 
mean sea level or geoid. Whilst the Standard Name could be 
'platform_height_above_calm_sea_surface'  or 
'platform_height_above_stationary_position' I would argue that 'heave' is a 
term from the same domain vocabulary as 'pitch', 'roll' and 'yaw' and therefore 
should be used.


John is right to point out that the heave measurement is affected by the nature 
of the platform with a 250,000 tonne supertanker moving up and down much less 
than a rowing boat in a given wave climate, especially a wind sea. That was 
what was behind the SBWR corrections based on platform dimensions set up by 
Laurie Draper and Tom Tucker back in the 1980s.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of John Helly 
<hel...@ucsd.edu>
Sent: 26 May 2018 04:48
To: Jim Biard; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


Can't let go of this yet.

If you think about the inverse problem of deriving the sea surface elevation 
from the heave you would have to account for the latency of ship motion 
relative to the sea-surface. A  wave passing under a ship induces motions that 
are not instantaneous either in attack or decay.

J.

On 5/25/18 20:42, John Helly wrote:

I believe it's a synonym within the oceanographic community for the vertical 
motion of an ocean-going platform.

https://en.wikipedia.org/wiki/Ship_motions

Ship motions - Wikipedia<https://en.wikipedia.org/wiki/Ship_motions>
en.wikipedia.org
Ship motions are defined by the six degrees of freedom that a ship, boat or any 
other craft can experience.



Could just be jargon but it strike me as more complex: nonetheless a vertical 
position relative to a datum, but the buoyancy, stability and momentum of the 
platform are implied as part of the dynamics.  It seems that the datum is not a 
geophysical one alone but confounded with the 'normal' waterline for a platform 
so it may be relative to the water level in which the platform is embedded.  
That's a tough one.  Two different platforms on the same sea surface would have 
different 'heave', for example.

J.

On 5/25/18 19:54, Jim Biard wrote:
Hi.

I get and endorse the need for pitch, roll, and yaw, but I remain perplexed 
about heave. How is a time series of 'heave' different from a time series of 
height relative to some vertical datum? I've yet to see a proposed definition 
that convinces me that this is a uniquely different quantity.

Grace and peace,

Jim

[CICS-NC]<http://www.cicsnc.org/>Visit us on
Facebook<http://www.facebook.com/cicsnc>Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900

Connect with us on Facebook for 
climate<http://www.facebook.com/NOAANCEIclimate> and ocean and 
geophysics<http://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate <http://www.twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo<http://www.twitter.com/NOAANCEIocngeo>.



On Fri, May 25, 2018 at 7:28 AM, Lowry, Roy K. 
<r...@bodc.ac.uk<mailto:r...@bodc.ac.uk>> wrote:

Dear All,


I agree with Nan that definitions of pitch roll and yaw would improve the 
existing Standard Name definitions. I also agree with using the existing 
orientation Standard Names for ADCPs and that the 'platform' definition wording 
could make this clearer. However, such an enhancements should be submitted as a 
separate proposal and not be considered as part of Steve's proposal.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu<mailto:cf

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear All,


I agree with Nan that definitions of pitch roll and yaw would improve the 
existing Standard Name definitions. I also agree with using the existing 
orientation Standard Names for ADCPs and that the 'platform' definition wording 
could make this clearer. However, such an enhancements should be submitted as a 
separate proposal and not be considered as part of Steve's proposal.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Nan Galbraith 
<ngalbra...@whoi.edu>
Sent: 25 May 2018 14:46
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave

I'd really like to see pitch, roll and yaw defined in the CF standard
name table; currently
the definitions only say 'Standard names for platform describe the
motion and orientation
of the vehicle from which observations are made e.g. aeroplane, ship or
satellite.'

Also, not to get too far into the weeds, but many of the platform terms
are important
for instruments like ADCPs, so I'd just like to confirm that these
definitions - and
the names themselves - can be used to describe instruments, not just
vehicles
'e.g.  aeroplane, ship or satellite'.   We already use pitch roll and
yaw for these
instruments on surface moorings, and I hope (and assume) this is legal.

Thanks - Nan Galbraith


On 5/25/18 8:53 AM, Lowry, Roy K. wrote:
>
>
> Dear Steve,
>
>
> One of the reasons I was interested in your definitions was your
> perspective on the datum (i.e. zero value) for heave. The datum
> 'mean_sea_level' is well used in CF, but with the definition 'time
> mean of sea surface elevation at a given location over an arbitrary
> period sufficient to eliminate the tidal signals.' This is obviously
> not appropriate for platform heave which doesn't take any account of
> the state of the tide and so I would exclude 'mean_sea_level' from the
> Standard Name.
>
>
> I think my preference would be to keep the term 'heave' as we already
> have 'pitch', 'yaw' and 'roll', giving:
>
>
> platform_heave (m)
>
>
> Standard names for platform describe the motion and orientation of the
> vehicle from which observations are made e.g. aeroplane, ship or
> satellite. "Heave" is a term used to describe the vertical
> displacement of the platform above its position when not moving.
>
>
> tendency_of_platform_heave (m s-1)
>
>
> Standard names for platform describe the motion and orientation of the
> vehicle from which observations are made e.g. aeroplane, ship or
> satellite. "Tendency_of_X" means derivative of X with respect to time.
> "Heave" is a term used to describe the vertical displacement of the
> platform above its position when not moving.
>
>
> What do you think?
>
>
> Cheers, Roy.
>
>
> I am retiring on 31/05/2018 but will continue to be active through an
> Emeritus Fellowship using this e-mail address.
>
>
>
> 
> *From:* CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of
> Hamilton, Steve <sj.hamil...@fugro.com>
> *Sent:* 25 May 2018 08:51
> *To:* cf-metadata@cgd.ucar.edu
> *Subject:* Re: [CF-metadata] Platform Heave
>
> All,
>
> Thanks for all the comments, I have tried to capture as below -
>
> *Parameter Name***
>
>
>
> *Standard Name*
>
>
>
> *Definition*
>
>
>
> *Canonical Units*
>
>  Platform Heave
>
>
>
> Platform_Height_above_mean_sea_Level
>
>
>
> Standard names for platform describe the motion and
> orientation of the vehicle from which observations are made e.g.
> aeroplane, ship or satellite.  Height above mean sea Level is the
> linear vertical (up/down) distance of the platform in respect to the
> mean sea level.
>
>
>
> m
>
>Platform Heave Rate
>
>
>
> Tendency_of_Platform_Height_above_mean_sea_Level
>
>
>
> Standard names for platform describe the motion and
> orientation of the vehicle from which observations are made e.g.
> aeroplane, ship or satellite. "tendency_of_X" means derivative of X
> with respect to time. Height above mean sea Level is the linear
> vertical (up/down) distance of the platform in respect to the mean sea
> level.
>
>
>
> m s-1
>
> Please let me know if you have further comments
>
> Thanks
>
> Steve
>
> *From:*Steven Emmerson <emmer...@ucar.edu>
> *Sent:* 21 May 2018 19:18
> *To:* Hamilton, Steve <sj.hamil...@fugro.com>
> *Cc:* cf-metadata@cgd.ucar.edu
> *Subject:* Re

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

Dear Steve,


One of the reasons I was interested in your definitions was your perspective on 
the datum (i.e. zero value) for heave. The datum 'mean_sea_level' is well used 
in CF, but with the definition 'time mean of sea surface elevation at a given 
location over an arbitrary period sufficient to eliminate the tidal signals.' 
This is obviously not appropriate for platform heave which doesn't take any 
account of the state of the tide and so I would exclude 'mean_sea_level' from 
the Standard Name.


I think my preference would be to keep the term 'heave' as we already have 
'pitch', 'yaw' and 'roll', giving:


platform_heave (m)


Standard names for platform describe the motion and orientation of the vehicle 
from which observations are made e.g. aeroplane, ship or satellite. "Heave" is 
a term used to describe the vertical displacement of the platform above its 
position when not moving.


tendency_of_platform_heave (m s-1)


Standard names for platform describe the motion and orientation of the vehicle 
from which observations are made e.g. aeroplane, ship or satellite. 
"Tendency_of_X" means derivative of X with respect to time. "Heave" is a term 
used to describe the vertical displacement of the platform above its position 
when not moving.


What do you think?


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Hamilton, 
Steve 
Sent: 25 May 2018 08:51
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave


All,



Thanks for all the comments, I have tried to capture as below -



  Parameter Name


   Standard Name


   Definition


Canonical Units


 Platform Heave


 Platform_Height_above_mean_sea_Level


Standard names for platform describe the motion and orientation of the 
vehicle from which observations are made e.g. aeroplane, ship or satellite.  
Height above mean sea Level is the linear vertical (up/down) distance of the 
platform in respect to the mean sea level.




m


   Platform Heave Rate


 Tendency_of_Platform_Height_above_mean_sea_Level


Standard names for platform describe the motion and orientation of the 
vehicle from which observations are made e.g. aeroplane, ship or satellite. 
"tendency_of_X" means derivative of X with respect to time. Height above mean 
sea Level is the linear vertical (up/down) distance of the platform in respect 
to the mean sea level.




m s-1




Please let me know if you have further comments



Thanks



Steve



From: Steven Emmerson 
Sent: 21 May 2018 19:18
To: Hamilton, Steve 
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Platform Heave



Whatever name you come up with, the canonical unit of the heave rate shouldn't 
be "ms-1", but rather one of the following:

m s-1

m/s

m.s-1



I favor "m/s".


Regards,

Steve Emmerson



On Mon, May 21, 2018 at 6:32 AM, Hamilton, Steve 
> wrote:

Hi



I am trying to find the CF name for heave of a vessel or platform.  
platform_roll_angle and platform_pitch_angle already exist but nothing on heave



Would be the following be acceptable



Platform_heave (m)

Platform_heave_rate (ms-1)



Standard names for platform describe the motion and orientation of the vehicle 
from which observations are made e.g. aeroplane, ship or satellite.



Kind Regards,



Steve



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Lowry, Roy K.]

DearSteve,


Would you care to provide definitions?


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Hamilton, 
Steve 
Sent: 21 May 2018 13:32
To: 'cf-metadata@cgd.ucar.edu'
Subject: [CF-metadata] Platform Heave


Hi



I am trying to find the CF name for heave of a vessel or platform.  
platform_roll_angle and platform_pitch_angle already exist but nothing on heave



Would be the following be acceptable



Platform_heave (m)

Platform_heave_rate (ms-1)



Standard names for platform describe the motion and orientation of the vehicle 
from which observations are made e.g. aeroplane, ship or satellite.



Kind Regards,



Steve




This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Standard Names to support Trac ticket 99

[Lowry, Roy K.]

Dear Jonathan,


I'll go back to the biological experts and see what they think. They were 
recommending 'biological entity', but I thought that might cause issues because 
it would bring into scope morphological classifications and bits of organisms 
such as 'cod liver' for which there is no (to my knowledge) governance in place 
like there is with taxon.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Jonathan 
Gregory <j.m.greg...@reading.ac.uk>
Sent: 21 May 2018 16:37
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99

Dear Roy and Martin

I think taxonomic_category might be a little better than taxon, but it still
seems obscure to me. Can you see something wrong with organisms_in_taxon (or
_from_ or _belonging_to_) for instance? It is the organisms we mean.

Best wishes

Jonathan

- Forwarded message from "Lowry, Roy K." <r...@bodc.ac.uk> -

> Date: Mon, 21 May 2018 08:02:05 +
> From: "Lowry, Roy K." <r...@bodc.ac.uk>
> To: Martin Juckes - UKRI STFC <martin.juc...@stfc.ac.uk>,
>"cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu>,
>"j.m.greg...@reading.ac.uk" <j.m.greg...@reading.ac.uk>
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Jonathan,
>
>
> Getting back to Trac 99. I prefer Martin's suggestion here. Are you happy 
> with that?
>
>
> Cheers, Roy.
>
>
> I am retiring on 31/05/2018 but will continue to be active through an 
> Emeritus Fellowship using this e-mail address.
>
>
> ____
> From: Martin Juckes - UKRI STFC <martin.juc...@stfc.ac.uk>
> Sent: 02 May 2018 08:47
> To: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk; Lowry, Roy K.
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Roy, Jonathan,
>
>
> I understand the cause of Jonathan's concern: wikipedia suggests a broader 
> interpretation of "taxon" which would be consistent with using the word to 
> refer to the organisms from a biological taxon, but the Encyclopedia 
> Britannica has a narrower and perhaps more scientifically precise definition 
> in which "taxon" refers to the name, not the organisms matching the name 
> (https://www.britannica.com/science/taxon ). The article uses the phrase 
> "taxonomic category" which could be used as an alternative to Jonathan's 
> suggestion:
>
> mass_concentration_of_taxonomic_category_expressed_as_carbon_in_sea_water
>
>
> regards,
>
> Martin
>
>
> 
> From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Jonathan 
> Gregory <j.m.greg...@reading.ac.uk>
> Sent: 01 May 2018 17:08
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Roy
>
> I agree that the confusion is unlikely. Maybe I shouldn't have given that
> example, because it's distracting. My discomfort is just that "taxon" doesn't
> mean "organisms" but "name of type of organisms" e.g. in
>   mass_concentration_of_biological_taxon_expressed_as_carbon_in_sea_water
> you can substitute your proposed definition of taxon, to get
>   
> mass_concentration_of_name_identifying_an_organism_as_belonging_to_a_unit_of_classification_expressed_as_carbon_in_sea_water
> I think you mean
>   
> mass_concentration_of_organisms_from_biological_taxon_expressed_as_carbon_in_sea_water
> That's a bit longer, but feels more comfortable to me.
>
> Best wishes
>
> Jonathan
>
>
> - Forwarded message from "Lowry, Roy K." <r...@bodc.ac.uk> -
>
> > Date: Fri, 27 Apr 2018 11:55:26 +
> > From: "Lowry, Roy K." <r...@bodc.ac.uk>
> > To: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu>,
> >"j.m.greg...@reading.ac.uk" <j.m.greg...@reading.ac.uk>
> > Subject: Re: [CF-metadata]  Standard Names to support Trac ticket 99
> >
> > Dear Jonathon,
> >
> >
> > I realised that I hadn't replied to this. Think we're all agreed on 
> > biological_taxon_lsid.
> >
> >
> > I can't think of an alternative to cover your second comment, but feel that 
> > 'number_concentration_of_biological_taxon' with 'concentration' and taxon 
> > in the singular is clearly different from 'number_of_biological_taxa', or 
> > more likely 'count_of_biological_taxa' and so feel th

Re: [CF-metadata] Standard Names to support Trac ticket 99

[Lowry, Roy K.]

Dear Jonathan,


Getting back to Trac 99. I prefer Martin's suggestion here. Are you happy with 
that?


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Martin Juckes - UKRI STFC <martin.juc...@stfc.ac.uk>
Sent: 02 May 2018 08:47
To: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk; Lowry, Roy K.
Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99

Dear Roy, Jonathan,


I understand the cause of Jonathan's concern: wikipedia suggests a broader 
interpretation of "taxon" which would be consistent with using the word to 
refer to the organisms from a biological taxon, but the Encyclopedia Britannica 
has a narrower and perhaps more scientifically precise definition in which 
"taxon" refers to the name, not the organisms matching the name 
(https://www.britannica.com/science/taxon ). The article uses the phrase 
"taxonomic category" which could be used as an alternative to Jonathan's 
suggestion:

mass_concentration_of_taxonomic_category_expressed_as_carbon_in_sea_water


regards,

Martin



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Jonathan 
Gregory <j.m.greg...@reading.ac.uk>
Sent: 01 May 2018 17:08
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Standard Names to support Trac ticket 99

Dear Roy

I agree that the confusion is unlikely. Maybe I shouldn't have given that
example, because it's distracting. My discomfort is just that "taxon" doesn't
mean "organisms" but "name of type of organisms" e.g. in
  mass_concentration_of_biological_taxon_expressed_as_carbon_in_sea_water
you can substitute your proposed definition of taxon, to get
  
mass_concentration_of_name_identifying_an_organism_as_belonging_to_a_unit_of_classification_expressed_as_carbon_in_sea_water
I think you mean
  
mass_concentration_of_organisms_from_biological_taxon_expressed_as_carbon_in_sea_water
That's a bit longer, but feels more comfortable to me.

Best wishes

Jonathan


- Forwarded message from "Lowry, Roy K." <r...@bodc.ac.uk> -

> Date: Fri, 27 Apr 2018 11:55:26 +
> From: "Lowry, Roy K." <r...@bodc.ac.uk>
> To: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu>,
>"j.m.greg...@reading.ac.uk" <j.m.greg...@reading.ac.uk>
> Subject: Re: [CF-metadata]  Standard Names to support Trac ticket 99
>
> Dear Jonathon,
>
>
> I realised that I hadn't replied to this. Think we're all agreed on 
> biological_taxon_lsid.
>
>
> I can't think of an alternative to cover your second comment, but feel that 
> 'number_concentration_of_biological_taxon' with 'concentration' and taxon in 
> the singular is clearly different from 'number_of_biological_taxa', or more 
> likely 'count_of_biological_taxa' and so feel that there is not a significant 
> risk of confusion.
>
>
> Cheers, Roy.
>
>
> Please note that I partially retired on 01/11/2015. I am now only working 7.5 
> hours a week and can only guarantee e-mail response on Wednesdays, my day in 
> the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
> Please also use this e-mail if your requirement is urgent.
>
>
> 
> From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Jonathan 
> Gregory <jonathan.greg...@ncas.ac.uk>
> Sent: 16 April 2018 19:19
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] Standard Names to support Trac ticket 99
>
> Dear Roy
>
> Thanks for this. It looks sensible and well-constructed to me. I have two
> comments.
>
> * In response to your question, I think biological_taxon_lsid is better, since
> you propose that's what we use. The more generic version would be suitable if
> we offered a choice about which sort of ID to use, but it would present a
> difficulty if you wanted to provide more than one kind of ID; this would need
> more than one coord var, and it would be helpful to give them different
> standard names.
>
> * In the concentration names, I think "biological taxon" means "organisms
> of biological taxon", doesn't it? I suggest it would be better to spell this
> out in some way in the standard name. For example,
>   number_concentration_of_biological_taxon_in_sea_water
> might (surprisingly) be interpreted as meaning how many species there are
> per unit volume.
>
> Best wishes
>
> Jonathan
>
>
> - Forwarded message from "Lowry, Roy K." <r...@bodc.ac.uk> -
>
> > Date: Fri, 13 Apr 2018 14:02:59 +
> > From: "Lowry, Roy K." <r...@bodc.ac.uk>
> >

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

Fine for me too.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Daniel 
Neumann <daniel.neum...@io-warnemuende.de>
Sent: 18 May 2018 13:39
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?

Dear Jonathan,

That's fine for me.

Daniel


On 18.05.2018 14:37, Jonathan Gregory wrote:
> Dear Daniel and Roy
>
> I sent an email yesterday which for some reason disappeared into the void.
> Please could I request sea_floor_sediment instead of seabed_sediment? That's
> because we already use sea_floor in several standard names, but not sedbed.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Daniel Neumann 
> <daniel.neum...@io-warnemuende.de> -
>
>> Date: Fri, 18 May 2018 13:31:04 +0200
>> From: Daniel Neumann <daniel.neum...@io-warnemuende.de>
>> To: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu>
>> Subject: Re: [CF-metadata] No standard names for element concentrations in
>>   sediment?
>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>>   Thunderbird/52.7.0
>>
>> Hi Roy,
>>
>>
>> OK, that's fine. Thanks.
>>
>>
>> Cheers,
>>
>> Daniel
>>
>>
>>
>> On 18.05.2018 13:25, Lowry, Roy K. wrote:
>>> Hi Daniel,
>>>
>>>
>>> Most of the solids in sediment are silicate minerals, quite often
>>> quartz (silicon dioxide), which would be included in
>>> 'moles_of_silicon'  So, I suggest:
>>>
>>>
>>> moles_of_dissolved_inorganic_plus_biogenic_silicon_per_unit_area_in_seabed_sediment
>>>
>>> unit: mol/m2
>>>
>>> description: moles_of_X_per_unit_area_in_Y describes the amount of
>>> X in a column with unity base area of material/compartment Y.
>>> 'Seabed sediment' means particulate matter bound at the sea floor
>>> including interstitial pore water. Information on the location of
>>> the interface between water column and sediment can be provided
>>> via the comment attribute. 'Dissolved inorganic silicon' means the
>>> sum of all inorganic silicon in solution (including silicic acid
>>> and its first dissociated anion SiO(OH)3-). 'Biogenic silicon' is
>>> any silicon compound, usually the mineral opal, produced by
>>> organisms (e.g. diatom skeletal remains) in solid or colloidal
>>> form.
>>>
>>> Cheers, Roy.
>>>
>>>
>>> I am retiring on 31/05/2018 but will continue to be active through
>>> an Emeritus Fellowship using this e-mail address.
>>>
>>>
>>>
>>> 
>>> *From:* CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf
>>> of Daniel Neumann <daniel.neum...@io-warnemuende.de>
>>> *Sent:* 18 May 2018 10:45
>>> *To:* cf-metadata@cgd.ucar.edu
>>> *Subject:* Re: [CF-metadata] No standard names for element
>>> concentrations in sediment?
>>> Hi,
>>>
>>> Thanks for correction. I realized that I need a standard name not
>>> only for silicate but for biogenic silica plus silicate. I updated
>>> the proposed name and description as follows:
>>>
>>> moles_of_silicon_per_unit_area_in_seabed_sediment
>>>
>>> unit: mol/m2
>>>
>>> description: moles_of_X_per_unit_area_in_Y describes the amount of
>>> X in a column with unity base area of material/compartment Y.
>>> 'Seabed sediment' means particulate matter bound at the sea floor
>>> including interstitial pore water. Information on the location of
>>> the interface between water column and sediment can be provided
>>> via the comment attribute. 'Silicon' summarizes 'dissolved
>>> inorganic silicon' and 'biogenic silica'. 'Dissolved inorganic
>>> silicon' means the sum of all inorganic silicon in solution
>>> (including silicic acid and its first dissociated anion
>>> SiO(OH)3-). 'Biogenic silica' are biogenic silicon minerals which
>>> originate from the siliceous skeletal material of dead diatoms and
>>> other silica-utilizing organisms.
>>>
>>>
>>> Daniel
>>>
>>>
>>> On 18.05.2018 09:47, Lowry, Roy K. wrote:
>>>> Hi (yet) again,
>

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

Hi Daniel,


Most of the solids in sediment are silicate minerals, quite often quartz 
(silicon dioxide), which would be included in 'moles_of_silicon'  So, I suggest:


moles_of_dissolved_inorganic_plus_biogenic_silicon_per_unit_area_in_seabed_sediment

unit: mol/m2

description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute. 'Dissolved inorganic silicon' means 
the sum of all inorganic silicon in solution (including silicic acid and its 
first dissociated anion SiO(OH)3-). 'Biogenic silicon' is any silicon compound, 
usually the mineral opal, produced by organisms (e.g. diatom skeletal remains) 
in solid or colloidal form.

Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Daniel 
Neumann <daniel.neum...@io-warnemuende.de>
Sent: 18 May 2018 10:45
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?

Hi,

Thanks for correction. I realized that I need a standard name not only for 
silicate but for biogenic silica plus silicate. I updated the proposed name and 
description as follows:

moles_of_silicon_per_unit_area_in_seabed_sediment

unit: mol/m2

description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute. 'Silicon' summarizes 'dissolved 
inorganic silicon' and 'biogenic silica'. 'Dissolved inorganic silicon' means 
the sum of all inorganic silicon in solution (including silicic acid and its 
first dissociated anion SiO(OH)3-). 'Biogenic silica' are biogenic silicon 
minerals which originate from the siliceous skeletal material of dead diatoms 
and other silica-utilizing organisms.


Daniel


On 18.05.2018 09:47, Lowry, Roy K. wrote:

Hi (yet) again,


Overnight I remembered a debate on CF about not using'dissolved inorganic 
silicon' rather than 'silicate' in new Standard Names. I also think it's worth 
some clarification in the definition to explain how things can be dissolved in 
something that many would think of as a solid.


So that will give us:


moles_of_nitrogen_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute.



moles_of_dissolved_inorganic_silicon_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute. 'Dissolved inorganic silicon' means 
the sum of all inorganic silicon in solution (including silicic acid and its 
first dissociated anion SiO(OH)3-).


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Daniel Neumann 
<daniel.neum...@io-warnemuende.de><mailto:daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 19:58
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?


Great :-) . Then I would like to propose the following two new standard names:



moles_of_nitrogen_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Sediment' means 
particulate matter bound at the sea floor. Information on the location of the 
interface between water column and sediment can be provided via the comment 
attribute.



and



moles_of_silicate_expressed_as_silicon_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

First sentence should read:


Overnight I remembered a debate on CF about using'dissolved inorganic silicon' 
rather than 'silicate'


Doh!


Apologies, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: Lowry, Roy K.
Sent: 18 May 2018 08:47
To: Daniel Neumann; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?


Hi (yet) again,


Overnight I remembered a debate on CF about not using'dissolved inorganic 
silicon' rather than 'silicate' in new Standard Names. I also think it's worth 
some clarification in the definition to explain how things can be dissolved in 
something that many would think of as a solid.


So that will give us:


moles_of_nitrogen_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute.



moles_of_dissolved_inorganic_silicon_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute. 'Dissolved inorganic silicon' means 
the sum of all inorganic silicon in solution (including silicic acid and its 
first dissociated anion SiO(OH)3-).


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Daniel 
Neumann <daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 19:58
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?


Great :-) . Then I would like to propose the following two new standard names:



moles_of_nitrogen_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Sediment' means 
particulate matter bound at the sea floor. Information on the location of the 
interface between water column and sediment can be provided via the comment 
attribute.



and



moles_of_silicate_expressed_as_silicon_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Sediment' means 
particulate matter bound at the sea floor. Information on the location of the 
interface between water column and sediment can be provided via the comment 
attribute.



Cheers,

Daniel


On 17.05.2018 16:00, Lowry, Roy K. wrote:

Hi Daniel,


That works for me.


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Daniel Neumann 
<daniel.neum...@io-warnemuende.de><mailto:daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 10:41
To: CF Metadata Mail List
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?

Dear Roy, Dear Jonathan,

Thank you for the feedback. I see  that sediment might be ambiguous. Would 
"seabed sediment" or "marine seabed sediment" be an acceptable alternative?

  moles_of_nitrogen_per_unit_area_in_seabed_sediment

This would clarify that the sea floor is meant as location of the sediment. It 
would also clarify that not bare rock is meant.

Cheers,
Daniel


On 16.05.2018 11:42, Lowry, Roy K. wrote:

Thanks Daniel,



Couple of additional thoughts that struck me. Is there possibility of confusion 
between seafloor sediment and suspended sediment? What if the seabed was bare 
rock?  So, might:



moles_of_nitrogen_per_unit_area_in_seabed



be better?



Let’s see if we get any other thoughts on the list.



Cheers, Roy.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Daniel Neumann
Sent: 16 May 2018 09:28
To: CF Metadata Mail List 
<cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?



Dear Roy,

> I think benthos chemistry is virgin territory for CF - not really 

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

Hi (yet) again,


Overnight I remembered a debate on CF about not using'dissolved inorganic 
silicon' rather than 'silicate' in new Standard Names. I also think it's worth 
some clarification in the definition to explain how things can be dissolved in 
something that many would think of as a solid.


So that will give us:


moles_of_nitrogen_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute.



moles_of_dissolved_inorganic_silicon_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Seabed sediment' means 
particulate matter bound at the sea floor including interstitial pore water. 
Information on the location of the interface between water column and sediment 
can be provided via the comment attribute. 'Dissolved inorganic silicon' means 
the sum of all inorganic silicon in solution (including silicic acid and its 
first dissociated anion SiO(OH)3-).


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Daniel 
Neumann <daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 19:58
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?


Great :-) . Then I would like to propose the following two new standard names:



moles_of_nitrogen_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Sediment' means 
particulate matter bound at the sea floor. Information on the location of the 
interface between water column and sediment can be provided via the comment 
attribute.



and



moles_of_silicate_expressed_as_silicon_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Sediment' means 
particulate matter bound at the sea floor. Information on the location of the 
interface between water column and sediment can be provided via the comment 
attribute.



Cheers,

Daniel


On 17.05.2018 16:00, Lowry, Roy K. wrote:

Hi Daniel,


That works for me.


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Daniel Neumann 
<daniel.neum...@io-warnemuende.de><mailto:daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 10:41
To: CF Metadata Mail List
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?

Dear Roy, Dear Jonathan,

Thank you for the feedback. I see  that sediment might be ambiguous. Would 
"seabed sediment" or "marine seabed sediment" be an acceptable alternative?

  moles_of_nitrogen_per_unit_area_in_seabed_sediment

This would clarify that the sea floor is meant as location of the sediment. It 
would also clarify that not bare rock is meant.

Cheers,
Daniel


On 16.05.2018 11:42, Lowry, Roy K. wrote:

Thanks Daniel,



Couple of additional thoughts that struck me. Is there possibility of confusion 
between seafloor sediment and suspended sediment? What if the seabed was bare 
rock?  So, might:



moles_of_nitrogen_per_unit_area_in_seabed



be better?



Let’s see if we get any other thoughts on the list.



Cheers, Roy.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Daniel Neumann
Sent: 16 May 2018 09:28
To: CF Metadata Mail List 
<cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?



Dear Roy,

> I think benthos chemistry is virgin territory for CF - not really surprising 
> for a standard that started in the atmosphere before dipping its toes in the 
> ocean.

:-)

> I'm presuming your coming from a modelling perspective,

Yes

In our current model setup (ecosystem model of the water column) we have a 
fairly simple sediment and write out the nitrogen amount per m2.

This name might be appropriate for this purpose:
moles_of_nitrogen_per_unit_area_in_sediment

unit:
mol/m2

description:
moles_of_X_per_unit_area_in_Y describes the amount of

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

Hi again,


I think all you need for the second Standard Name is:


moles_of_silicate_per_unit_area_in_seabed_sediment


as there is one atom of silicon per molecule of any of the species making up 
'silicate'. You only really need 'expressed_as_silicon' for 'mass_of_silicate'.


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Daniel 
Neumann <daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 19:58
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?


Great :-) . Then I would like to propose the following two new standard names:



moles_of_nitrogen_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Sediment' means 
particulate matter bound at the sea floor. Information on the location of the 
interface between water column and sediment can be provided via the comment 
attribute.



and



moles_of_silicate_expressed_as_silicon_per_unit_area_in_seabed_sediment


unit: mol/m2


description: moles_of_X_per_unit_area_in_Y describes the amount of X in a 
column with unity base area of material/compartment Y. 'Sediment' means 
particulate matter bound at the sea floor. Information on the location of the 
interface between water column and sediment can be provided via the comment 
attribute.



Cheers,

Daniel


On 17.05.2018 16:00, Lowry, Roy K. wrote:

Hi Daniel,


That works for me.


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Daniel Neumann 
<daniel.neum...@io-warnemuende.de><mailto:daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 10:41
To: CF Metadata Mail List
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?

Dear Roy, Dear Jonathan,

Thank you for the feedback. I see  that sediment might be ambiguous. Would 
"seabed sediment" or "marine seabed sediment" be an acceptable alternative?

  moles_of_nitrogen_per_unit_area_in_seabed_sediment

This would clarify that the sea floor is meant as location of the sediment. It 
would also clarify that not bare rock is meant.

Cheers,
Daniel


On 16.05.2018 11:42, Lowry, Roy K. wrote:

Thanks Daniel,



Couple of additional thoughts that struck me. Is there possibility of confusion 
between seafloor sediment and suspended sediment? What if the seabed was bare 
rock?  So, might:



moles_of_nitrogen_per_unit_area_in_seabed



be better?



Let’s see if we get any other thoughts on the list.



Cheers, Roy.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Daniel Neumann
Sent: 16 May 2018 09:28
To: CF Metadata Mail List 
<cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?



Dear Roy,

> I think benthos chemistry is virgin territory for CF - not really surprising 
> for a standard that started in the atmosphere before dipping its toes in the 
> ocean.

:-)

> I'm presuming your coming from a modelling perspective,

Yes

In our current model setup (ecosystem model of the water column) we have a 
fairly simple sediment and write out the nitrogen amount per m2.

This name might be appropriate for this purpose:
moles_of_nitrogen_per_unit_area_in_sediment

unit:
mol/m2

description:
moles_of_X_per_unit_area_in_Y describes the amount of X in a column with unity 
base area of material/compartment Y. 'Sediment' means particulate matter bound 
at the sea floor. Information on the location of the interface between water 
column and sediment can be provided via the comment attribute.


Cheers,
Daniel



On 15.05.2018 18:30, Lowry, Roy K. wrote:

Dear Daniel,



I think benthos chemistry is virgin territory for CF - not really surprising 
for a standard that started in the atmosphere before dipping its toes in the 
ocean.



Some thoughts based on my experience with observed sediment chemistry data. The 
data may be reported  per unit mass of wet or dry sediment or per unit volume 
of wet sediment. Also it is worth making clear that 'sediment' means sediment 
of all grain sizes (say a phrase like 'total_sediment') as samples are 
frequently sieved prior to analysis.



I'm presuming your coming from a modelling perspective, so I'm not totally 
clear about your needs, but would something like 
'mole_concentration_of_nitrogen_in_wet_total_sediment' be what you would be 
looking for?



Ch

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

Hi Daniel,


That works for me.


Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Daniel 
Neumann <daniel.neum...@io-warnemuende.de>
Sent: 17 May 2018 10:41
To: CF Metadata Mail List
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?

Dear Roy, Dear Jonathan,

Thank you for the feedback. I see  that sediment might be ambiguous. Would 
"seabed sediment" or "marine seabed sediment" be an acceptable alternative?

  moles_of_nitrogen_per_unit_area_in_seabed_sediment

This would clarify that the sea floor is meant as location of the sediment. It 
would also clarify that not bare rock is meant.

Cheers,
Daniel


On 16.05.2018 11:42, Lowry, Roy K. wrote:

Thanks Daniel,



Couple of additional thoughts that struck me. Is there possibility of confusion 
between seafloor sediment and suspended sediment? What if the seabed was bare 
rock?  So, might:



moles_of_nitrogen_per_unit_area_in_seabed



be better?



Let’s see if we get any other thoughts on the list.



Cheers, Roy.



From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> On 
Behalf Of Daniel Neumann
Sent: 16 May 2018 09:28
To: CF Metadata Mail List 
<cf-metadata@cgd.ucar.edu><mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?



Dear Roy,

> I think benthos chemistry is virgin territory for CF - not really surprising 
> for a standard that started in the atmosphere before dipping its toes in the 
> ocean.

:-)

> I'm presuming your coming from a modelling perspective,

Yes

In our current model setup (ecosystem model of the water column) we have a 
fairly simple sediment and write out the nitrogen amount per m2.

This name might be appropriate for this purpose:
moles_of_nitrogen_per_unit_area_in_sediment

unit:
mol/m2

description:
moles_of_X_per_unit_area_in_Y describes the amount of X in a column with unity 
base area of material/compartment Y. 'Sediment' means particulate matter bound 
at the sea floor. Information on the location of the interface between water 
column and sediment can be provided via the comment attribute.


Cheers,
Daniel



On 15.05.2018 18:30, Lowry, Roy K. wrote:

Dear Daniel,



I think benthos chemistry is virgin territory for CF - not really surprising 
for a standard that started in the atmosphere before dipping its toes in the 
ocean.



Some thoughts based on my experience with observed sediment chemistry data. The 
data may be reported  per unit mass of wet or dry sediment or per unit volume 
of wet sediment. Also it is worth making clear that 'sediment' means sediment 
of all grain sizes (say a phrase like 'total_sediment') as samples are 
frequently sieved prior to analysis.



I'm presuming your coming from a modelling perspective, so I'm not totally 
clear about your needs, but would something like 
'mole_concentration_of_nitrogen_in_wet_total_sediment' be what you would be 
looking for?



Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.





From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Daniel Neumann 
<daniel.neum...@io-warnemuende.de><mailto:daniel.neum...@io-warnemuende.de>
Sent: 15 May 2018 16:51
To: CF Metadata Mail List
Subject: [CF-metadata] No standard names for element concentrations in sediment?



Dear CF Mailing List,

I am looking for standard names to describe the mole concentration of
nitrogen in the sediment. The CF standard name table does not contain
any standard names regarding "mole_concentration" in "sediment". I was
wondering whether another term than "sediment" was used for such names.
I also tried "mud", "seabed", and "sea_bed". Or do no such standard
names exist at all?

Cheers,
Daniel

--
Daniel Neumann

Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany

phone:  +49-381-5197-287
fax:+49-381-5197-114 or 440
e-mail: 
daniel.neum...@io-warnemuende.de<mailto:daniel.neum...@io-warnemuende.de>

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

CF-metadata Info Page - 
mailman.cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>

mailman.cgd.ucar.edu

This is an unmoderated list for discussions about interpretation, 
clarification, and proposals for extensions or change to the C

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

Thanks Daniel,

Couple of additional thoughts that struck me. Is there possibility of confusion 
between seafloor sediment and suspended sediment? What if the seabed was bare 
rock?  So, might:

moles_of_nitrogen_per_unit_area_in_seabed

be better?

Let's see if we get any other thoughts on the list.

Cheers, Roy.

From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> On Behalf Of Daniel Neumann
Sent: 16 May 2018 09:28
To: CF Metadata Mail List <cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] No standard names for element concentrations in 
sediment?

Dear Roy,

> I think benthos chemistry is virgin territory for CF - not really surprising 
> for a standard that started in the atmosphere before dipping its toes in the 
> ocean.

:-)

> I'm presuming your coming from a modelling perspective,

Yes

In our current model setup (ecosystem model of the water column) we have a 
fairly simple sediment and write out the nitrogen amount per m2.

This name might be appropriate for this purpose:
moles_of_nitrogen_per_unit_area_in_sediment

unit:
mol/m2

description:
moles_of_X_per_unit_area_in_Y describes the amount of X in a column with unity 
base area of material/compartment Y. 'Sediment' means particulate matter bound 
at the sea floor. Information on the location of the interface between water 
column and sediment can be provided via the comment attribute.


Cheers,
Daniel


On 15.05.2018 18:30, Lowry, Roy K. wrote:

Dear Daniel,



I think benthos chemistry is virgin territory for CF - not really surprising 
for a standard that started in the atmosphere before dipping its toes in the 
ocean.



Some thoughts based on my experience with observed sediment chemistry data. The 
data may be reported  per unit mass of wet or dry sediment or per unit volume 
of wet sediment. Also it is worth making clear that 'sediment' means sediment 
of all grain sizes (say a phrase like 'total_sediment') as samples are 
frequently sieved prior to analysis.



I'm presuming your coming from a modelling perspective, so I'm not totally 
clear about your needs, but would something like 
'mole_concentration_of_nitrogen_in_wet_total_sediment' be what you would be 
looking for?



Cheers, Roy.



I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.


From: CF-metadata 
<cf-metadata-boun...@cgd.ucar.edu><mailto:cf-metadata-boun...@cgd.ucar.edu> on 
behalf of Daniel Neumann 
<daniel.neum...@io-warnemuende.de><mailto:daniel.neum...@io-warnemuende.de>
Sent: 15 May 2018 16:51
To: CF Metadata Mail List
Subject: [CF-metadata] No standard names for element concentrations in sediment?

Dear CF Mailing List,

I am looking for standard names to describe the mole concentration of
nitrogen in the sediment. The CF standard name table does not contain
any standard names regarding "mole_concentration" in "sediment". I was
wondering whether another term than "sediment" was used for such names.
I also tried "mud", "seabed", and "sea_bed". Or do no such standard
names exist at all?

Cheers,
Daniel

--
Daniel Neumann

Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany

phone:  +49-381-5197-287
fax:+49-381-5197-114 or 440
e-mail: 
daniel.neum...@io-warnemuende.de<mailto:daniel.neum...@io-warnemuende.de>

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
CF-metadata Info Page - 
mailman.cgd.ucar.edu<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
mailman.cgd.ucar.edu
This is an unmoderated list for discussions about interpretation, 
clarification, and proposals for extensions or change to the CF conventions.



This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.




--

Daniel Neumann



Leibniz Institute for Baltic Sea Research Warnemuende

Physical Oceanography and Instrumentation

Seestrasse 15

18119 Rostock

Germany



phone:  +49-381-5197-287

fax:+49-381-5197-114 or 440

e-mail: 
daniel.neum...@io-warnemuende.de<mailto:daniel.neum...@io-warnemuende.de>


This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unle

Re: [CF-metadata] No standard names for element concentrations in sediment?

[Lowry, Roy K.]

Dear Daniel,


I think benthos chemistry is virgin territory for CF - not really surprising 
for a standard that started in the atmosphere before dipping its toes in the 
ocean.


Some thoughts based on my experience with observed sediment chemistry data. The 
data may be reported  per unit mass of wet or dry sediment or per unit volume 
of wet sediment. Also it is worth making clear that 'sediment' means sediment 
of all grain sizes (say a phrase like 'total_sediment') as samples are 
frequently sieved prior to analysis.


I'm presuming your coming from a modelling perspective, so I'm not totally 
clear about your needs, but would something like 
'mole_concentration_of_nitrogen_in_wet_total_sediment' be what you would be 
looking for?


Cheers, Roy.


I am retiring on 31/05/2018 but will continue to be active through an Emeritus 
Fellowship using this e-mail address.



From: CF-metadata  on behalf of Daniel 
Neumann 
Sent: 15 May 2018 16:51
To: CF Metadata Mail List
Subject: [CF-metadata] No standard names for element concentrations in sediment?

Dear CF Mailing List,

I am looking for standard names to describe the mole concentration of
nitrogen in the sediment. The CF standard name table does not contain
any standard names regarding "mole_concentration" in "sediment". I was
wondering whether another term than "sediment" was used for such names.
I also tried "mud", "seabed", and "sea_bed". Or do no such standard
names exist at all?

Cheers,
Daniel

--
Daniel Neumann

Leibniz Institute for Baltic Sea Research Warnemuende
Physical Oceanography and Instrumentation
Seestrasse 15
18119 Rostock
Germany

phone:  +49-381-5197-287
fax:+49-381-5197-114 or 440
e-mail: daniel.neum...@io-warnemuende.de

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
CF-metadata Info Page - 
mailman.cgd.ucar.edu
mailman.cgd.ucar.edu
This is an unmoderated list for discussions about interpretation, 
clarification, and proposals for extensions or change to the CF conventions.




This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] proposed new standard name for storm surge residual

[Lowry, Roy K.]

Dear Andy,


I agree with Jonathan that specifically referencing LAT in the Standard Name 
would be better. In the UK sea level community there is a tendency to use the 
term 'chart datum' when what is really meant is 'Admiralty Chart Datum', which 
is defined as LAT.  Some other navies (e.g. Australia) use LAT as chart datum, 
but others do not. Therefore on a global scale 'chart datum' can have many 
meanings.


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
Please also use this e-mail if your requirement is urgent.



From: CF-metadata  on behalf of Jonathan 
Gregory 
Sent: 08 May 2018 15:34
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] proposed new standard name for storm surge residual

Dear Andy

Thanks for this, and to Roy for support. I agree, I think we've pretty much
worked out what we mean now.

Instead of chart_datum I would prefer that we had standard names mentioning
the specific datums you want e.g. lowest_astronomical_tide, because it is more
informative and reduces the need for other information. Or is there a need to
be vague about it?

We have a mechanism, viz grid_mapping, to identify datums more precisely. If
we can't do that currently for MSL we could extend the convention.

As well as steric changes, I think non-tidal includes ocean dynamics (on all
timescales). I think your definitions look right.

Best wishes

Jonathan

- Forwarded message from "Saulter, Andrew" 
 -

> Date: Tue, 8 May 2018 08:08:13 +
> From: "Saulter, Andrew" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] proposed new standard name for storm surge
>residual
>
> Dear Jonathon,
>
> Thanks for all the constructive inputs - this feels like we are getting 
> somewhere :-)
>
> I'd be very happy with "non_tidal_elevation_of_sea_surface_height"; elevation 
> references positive when SSH is increased but also acknowledges suppression 
> of SSH with high pressure/negative surge; non-tidal gives us the very useful 
> catchall that there are various processes at play.
>
> Regards the tidal SSH, you are absolutely right about assumptions. Normally 
> the tidal predictions we would be using (either directly or as boundary 
> inputs to a model) would be derived from a harmonic analysis of data covering 
> a given averaging period (varies, but anything from a month as a minimum that 
> captures a single spring-neap cycle, to 19-odd years to capture a full set of 
> sun-moon variations that cause the very largest tides). It is generally 
> assumed that the averaging will cancel out many of the other ocean effects - 
> any errors where this hasn't happened correctly will manifest themselves in 
> the non_tidal part (which is why I'm comfortable that this name makes more 
> sense than surge for observed values).
>
> Being the wild optimist that I am, I've taken the below and tried to flesh it 
> out a bit for the tide and non-tidal variables we would have in our use 
> cases. Please let me know what you reckon - the descriptions might still need 
> some work?
>
>  tidal_sea_surface_height_above_mean_sea_level
> Units: m
> "Sea surface height" is a time-varying quantity. "Height_above_X" means the 
> vertical distance above the named surface X. "Mean sea level" means the time 
> mean of sea surface elevation at a given location over an arbitrary period 
> sufficient to eliminate the tidal signals. The tidal component of sea surface 
> height describes the predicted variability of the sea surface due to 
> astronomic forcing (chiefly lunar and solar cycles) and shallow water 
> resonance of tidal components; for example as generated based on harmonic 
> analysis, or resulting from the application of harmonic tidal series as 
> boundary conditions to a numerical tidal model.
>
> tidal_sea_surface_height_above_chart_datum
> Units: m
> "Sea surface height" is a time-varying quantity. "Height_above_X" means the 
> vertical distance above the named surface X. "Chart datum" describes a local 
> vertical reference from which depths displayed on a nautical chart are 
> measured and which differs from mean sea level. For example, chart datum 
> based on "lowest astronomical tide" or "mean lower low water". The tidal 
> component of sea surface height describes the predicted variability of the 
> sea surface due to astronomic forcing (chiefly lunar and solar cycles) and 
> shallow water resonance of tidal components; for example as generated based 
> on harmonic analysis, or resulting from the application of harmonic tidal 
> series as boundary conditions to a numerical tidal model.
>
> 

Re: [CF-metadata] proposed additional names for sea_surface_wave parameters

[Lowry, Roy K.]

Hi Andy,


Finally managed to check the detail of this proposal and agree with Jonathan 
that all now looks good.


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
Please also use this e-mail if your requirement is urgent.



From: CF-metadata  on behalf of Saulter, 
Andrew 
Sent: 04 May 2018 16:17
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] proposed additional names for sea_surface_wave 
parameters

Jonathon, Roy, Steven,

Many thanks for your advice on these. Just to summarise, the proposed CF names, 
units and descriptors following our discussions are listed below.

Have a great weekend everyone
Andy


sea_surface_tertiary_swell_wave_from_direction
units: degree
The quantity with standard name sea_surface_tertiary_swell_wave_from_direction 
is the direction from which the third most energetic swell waves are coming. 
Swell waves are waves on the ocean surface and are the low frequency portion of 
a bimodal wave frequency spectrum. The tertiary swell wave is the third most 
energetic swell wave. The phrase "from_direction" is used in the construction 
X_from_direction and indicates the direction from which the velocity vector of 
X is coming. The direction is a bearing in the usual geographical sense, 
measured positive clockwise from due north.

sea_surface_tertiary_swell_wave_mean_period
units: s
The quantity with standard name sea_surface_tertiary_swell_wave_mean_period is 
the mean period of the third most energetic swell waves. Swell waves are waves 
on the ocean surface and are the low frequency portion of a bimodal wave 
frequency spectrum. The tertiary swell wave is the third most energetic wave in 
the low frequency portion of a bimodal wave frequency spectrum. A period is an 
interval of time, or the time-period of an oscillation. Wave period is the 
interval of time between repeated features on the waveform such as crests, 
troughs or upward passes through the mean level. Wave mean period is the mean 
period measured over the observation duration.

sea_surface_tertiary_swell_wave_significant_height
Swell waves are waves on the ocean surface and are the low frequency portion of 
a bimodal wave frequency spectrum. The tertiary swell wave is the third most 
energetic wave in the low frequency portion of a bimodal wave frequency 
spectrum. Significant wave height is a statistic computed from wave 
measurements and corresponds to the average height of the highest one third of 
the waves, where the height is defined as the vertical distance from a wave 
trough to the following wave crest.

sea_surface_wind_wave_period_at_variance_spectral_density_maximum
units: s
The quantity with standard name 
sea_surface_wind_wave_period_at_variance_spectral_density_maximum is the period 
of the most energetic waves within the wind wave component of a sea. Wind waves 
are waves on the ocean surface and are the high frequency portion of a bimodal 
wave frequency spectrum. A period is an interval of time, or the time-period of 
an oscillation. The phrase "wave_period_at_variance_spectral_density_maximum", 
sometimes called peak wave period, describes the period of the most energetic 
waves within a given sub-domain of the wave spectrum.

sea_surface_primary_swell_wave_period_at_variance_spectral_density_maximum
units: s
The quantity with standard name 
sea_surface_primary_swell_wave_period_at_variance_spectral_density_maximum is 
the period of the most energetic waves within the primary swell wave component 
of a sea. Swell waves are waves on the ocean surface and are the low frequency 
portion of a bimodal wave frequency spectrum. The primary swell wave is the 
most energetic wave component in the low frequency portion of a bimodal wave 
frequency spectrum. A period is an interval of time, or the time-period of an 
oscillation. The phrase "wave_period_at_variance_spectral_density_maximum", 
sometimes called peak wave period, describes the period of the most energetic 
waves within a given sub-domain of the wave spectrum.

sea_surface_secondary_swell_wave_period_at_variance_spectral_density_maximum
units: s
The quantity with standard name 
sea_surface_secondary_swell_wave_period_at_variance_spectral_density_maximum is 
the period of the most energetic waves within the secondary swell wave 
component of a sea. Swell waves are waves on the ocean surface and are the low 
frequency portion of a bimodal wave frequency spectrum. The secondary swell 
wave is the most energetic wave component in the low frequency portion of a 
bimodal wave frequency spectrum. A period is an interval of time, or the 
time-period of an oscillation. The phrase 
"wave_period_at_variance_spectral_density_maximum", sometimes called peak 

Re: [CF-metadata] proposed additional names for sea_surface_wave parameters

[Lowry, Roy K.]

Dear Jonathan,


I totally agree with Andy on this point.


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
Please also use this e-mail if your requirement is urgent.



From: CF-metadata  on behalf of Saulter, 
Andrew 
Sent: 03 May 2018 11:34
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] proposed additional names for sea_surface_wave 
parameters

Thanks Jonathon,

Re the directional_spread parameters in section 4, the "one-sided directional 
width" as its described in Holthuijsen's book (Waves in Oceanic and Coastal 
Waters) is perhaps more precisely defined by Tucker and Pitt (Waves in Ocean 
Engineering) as "half the beam-width as usually described: that is, it is from 
the beam axis to the root mean square width".

So in principle there is a statistical relationship between this value and a 
mean_wave_direction that is also computed from moments of the directional wave 
spectrum. However, there is a lot of detail here; first Tucker and Pitt note 
that this is an approximation. Rather more detail is given by Kuik et al. 
(1988, https://doi.org/10.1175/1520-0485(1988)018%3C1020:AMFTRA%3E2.0.CO;2 ) 
who explain potential differences in calculation of directional characteristics 
using linear or circular moments - the latter being necessary for wave 
measurements, where spreading is then estimated based on the Fourier components 
of the directional wave spectrum rather than a direct calculation of 
directional spectrum statistics.

So the parameter feels a bit more complex and nuanced than a cell_methods 
application to wave_direction would allow. I think giving it its own name is 
more appropriate in this case?

Cheers
Andy


-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
Jonathan Gregory
Sent: 02 May 2018 13:32
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] proposed additional names for sea_surface_wave parameters

Dear Andy

Your new proposals of sections 1-3 following existing patterns, as you say, and 
look fine to me.

For those of section 4, can you say precisely what "one-sided directional 
width" means? The way you describe it, I wonder whether it could be described 
as a processed version of the wave_direction theta. For example, if it was the 
standard deviation of theta, cell_methods could describe it.

Best wishes

Jonathan

- Forwarded message from "Saulter, Andrew" 
 -

> Date: Wed, 2 May 2018 07:28:05 +
> From: "Saulter, Andrew" 
> To: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] proposed additional names for sea_surface_wave
>parameters
>
> Adding a minor amendment to the units for the 
> 'wave_energy_at_variance_spectral_density_maximum' parameters. These should 
> be 'm2 s' rather than 'm2s' in order to be parsed by UDUNITS.
>
> Andy
>
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf
> Of Saulter, Andrew
> Sent: 01 May 2018 09:27
> To: cf-metadata@cgd.ucar.edu
> Subject: [CF-metadata] proposed additional names for sea_surface_wave
> parameters
>
> Hi all,
>
> Please find proposals for some additional sea_surface_wave parameters, which 
> will be provided as part of Met Office operational forecast products in the 
> near future. Hopefully nothing too contentious as mostly an extension of some 
> existing CF names.
>
>
> 1.   Addition of 'tertiary_swell' names for existing wave parameters 
> defined under 'wind_wave', 'primary_swell' and 'secondary_swell' categories. 
> So would add:
>
> sea_surface_tertiary_swell_wave_from_direction
> units: degree
> The quantity with standard name 
> sea_surface_tertiary_swell_wave_from_direction is the direction from which 
> the third most energetic swell waves are coming. Swell waves are waves on the 
> ocean surface and are the low frequency portion of a bimodal wave frequency 
> spectrum. The tertiary swell wave is the third most energetic swell wave. The 
> phrase "from_direction" is used in the construction X_from_direction and 
> indicates the direction from which the velocity vector of X is coming. The 
> direction is a bearing in the usual geographical sense, measured positive 
> clockwise from due north.
>
> sea_surface_tertiary_swell_wave_mean_period
> units: s
> The quantity with standard name sea_surface_tertiary_swell_wave_mean_period 
> is the mean period of the third most energetic swell waves. Swell waves are 
> waves on the ocean surface and are the low frequency portion of a bimodal 
> wave frequency spectrum. The tertiary swell wave is the third most energetic 
> wave in the low frequency portion of a bimodal wave frequency 

Re: [CF-metadata] proposed new standard name for storm surge residual

[Lowry, Roy K.]

Hi again,


Having read a bit more I see that 'surge'  is commonly used to cover the total 
forcing due to wind and pressure so ignore my previous comment!


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
Please also use this e-mail if your requirement is urgent.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Lowry, Roy K. 
<r...@bodc.ac.uk>
Sent: 03 May 2018 09:47
To: Saulter, Andrew; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] proposed new standard name for storm surge residual


Hi Andy,


A thought that struck me as I read through your e-mail is that surges aren't 
the only meteorological forcing. Whilst in a model the non-tide contributions 
can be easily differentiated in observational data they cannot.


Would 'sea_surface_height_due_to_meteorological_forcing'  be a better to make 
the Standard Name appropriate to observational data as well? Or do you wish to 
clearly identify the forcing? If so, would it be a good idea to clearly state 
in the definition that surge is a variation in sea surface elevation due to 
variations in atmospheric pressure?


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
Please also use this e-mail if your requirement is urgent.



From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Saulter, 
Andrew <andrew.saul...@metoffice.gov.uk>
Sent: 03 May 2018 09:28
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] proposed new standard name for storm surge residual

Apologies; there were issues with the way my email formatted the last message - 
I've sorted this out below...

-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
Saulter, Andrew
Sent: 03 May 2018 09:24
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] proposed new standard name for storm surge residual

Dear Jonathon,

Possibly, I have been over-thinking this! I went back to square one and looked 
at the family of 'sea_surface_height' variables again and read the phrasing as 
carefully as I could.

>From these:

'sea_surface_height' is a time-varying quantity - so implies a generic 
summation of components; in practise we determine what these are depending on 
our use and (should) reflect the choices underlying this in our metadata

'height_above_X' means the vertical distance above the named surface X - there 
are a whole set of these for 'sea_surface_height' ('above_geoid', 
'above_geopotential_datum', 'above_mean_sea_level') that set the vertical 
reference

Then, as I think we've all agreed, 'due_to_surge', 'due_to_tide' are simply 
relative quantities. In other words, a summation of these quantities should 
lead us to a 'sea_surface_height_above_X', but on their own they are generic.

Putting that lot together, what this should mean is that for my surge model, 
which is referenced to mean sea level and has a tide and surge part that I can 
decompose, I could generate variables with standard names:

1. sea_surface_height_above_mean_sea_level - the total

2.sea_surface_height_due_to_tide - the tide part

3. sea_surface_height_due_to_surge - the surge part

All good so far. The other example that I'm concerned about is a situation 
where the tide I'm using has been referenced to a datum which isn't necessarily 
the mean sea level or reference ellipsoid, e.g. Chart Datum or Lowest 
Astronomic Tide. In this case, I think the total water level and decomposition 
should comprise:

1. sea_surface_height_above_reference_datum (as per the existing 'water_height' 
example) - the total

2. sea_surface_height_due_to_tide - the tide part

3. sea_surface_height_due_to_surge - the surge part

These all work when it is clear that my 'due_to' components sum up to my 
'sea_surface_height_above' parameter, since that is where any datum reference 
gets applied. So, in an example where I've decided that the water level I'm 
predicting will be just fine if all I am doing is feeding in a tide prediction 
referenced to chart datum, then the CF name I use is 
'sea_surface_height_above_reference_datum' and not 
'sea_surface_height_due_to_tide' as it’s the overall level and not actually the 
components that I'm interested in. This was the source of my confusion...

The one addition to the above is that the reference_datum should a) be 
stipulated and b) have a way of being mapped to the reference_ellipsoid we 
would use for the coordinate system. A) would need a new descriptive variable, 
e.g. 'reference_datum_name'.