Re: [CF-metadata] use of integral_wrt_depth_of_sea_water_practical_salinity

[Sebastien Villaume]

Dear Alison,

sorry for the late reply, I have been very busy with other activities.

 > If we take this approach then Sebastien could use the existing
> integral_wrt_depth_of_sea_water_practical_salinity name and it would cover all
> use cases. Do others agree? If so, then I will modify the definitions of all
> 387 existing integral names in the next update. This will create some
> housekeeping work for the standard name table, but it avoids the need to 
> modify
> the conventions which would be necessary for some of the other ideas that have
> been discussed in this thread.

I am happy with this simple and straightforward approach although I would have 
favoured a more clear and generic way to specify these bounds.

If everyone else is happy with this and if all the integral_wrt_X_of_Y standard 
names are updated accordingly, I will then encode my "surface to sea floor" 
bounds by not specifying the bounds! 

thanks a lot!

/Sébastien

- Original Message -
> From: "Alison Pamment - UKRI STFC" <alison.pamm...@stfc.ac.uk>
> To: cf-metadata@cgd.ucar.edu, "Sebastien Villaume 
> (sebastien.villa...@ecmwf.int)" <sebastien.villa...@ecmwf.int>
> Sent: Friday, 27 April, 2018 08:14:04
> Subject: RE: [CF-metadata] use of 
> integral_wrt_depth_of_sea_water_practical_salinity

> Dear Sebastien, All,
> 
> I have just been reading through this thread and it raises some interesting
> points.
> 
> When I made my original comments back in 2016 (that
> ocean_integral_wrt_depth_of_sea_water_practical_salinity (i.e. integral over
> the whole depth from sea floor to surface) is a special case of
> integral_wrt_depth_of_sea_water_practical_salinity) I don't think I had fully
> thought through how one would go about specifying the limits for the full 
> depth
> case.  I see now that we don't really have an agreed mechanism for doing this,
> although a number of ideas have been put forward. I agree with Martin's 
> comment
> that one would expect to look at the coordinates and coordinate bounds for the
> limits of an integral - certainly that's what we do for cases where the limits
> define a layer and I think it's preferable  to treat the full depth case
> similarly.
> 
> Jonathan suggested making the existing in_atmosphere_layer/in_ocean_layer 
> names
> aliases of the full depth atmosphere/ocean names and stating in the definition
> that if coordinate bounds are not specified it means the entire vertical 
> extent
> of the atmosphere/ocean. The question that Sebastien has raised is concerned
> specifically with how to state the limits on the integral_wrt_Y_of_X names and
> I do think we can solve the problem by modifying the definitions along the
> lines Jonathan suggests. Currently the definitions all say 'The phrase
> "integral_wrt_X_of_Y" means int Y dX. The data variable should have an axis 
> for
> X specifying the limits of the integral as bounds.' We could modify this to
> read 'The phrase "integral_wrt_X_of_Y" means int Y dX. To specify the limits 
> of
> the integral the data variable should have an axis for X and associated
> coordinate bounds. If no axis for X is associated with the data variable, or 
> no
> coordinate bounds are specified, it is assumed that the integral is calculated
> over the entire vertical extent of the medium, e.g, if the medium is air the
> integral is assumed to be calculated over the full depth of the atmosphere.'
> 
> If we take this approach then Sebastien could use the existing
> integral_wrt_depth_of_sea_water_practical_salinity name and it would cover all
> use cases. Do others agree? If so, then I will modify the definitions of all
> 387 existing integral names in the next update. This will create some
> housekeeping work for the standard name table, but it avoids the need to 
> modify
> the conventions which would be necessary for some of the other ideas that have
> been discussed in this thread.
> 
> As to whether we should make layer names into aliases, e.g.
> mass_content_of_cloud_ice_in_atmosphere_layer becoming an alias of
> atmosphere_mass_content_of_cloud_ice, we could certainly do this by taking a
> similar approach regarding  bounds in the definitions, but strictly speaking,
> it's not necessary to do this to address Sebastien's question. Also, if we are
> trying to be completely consistent about integrals and layers, it raises the
> question of whether atmosphere_mass_content, atmosphere_mole_content, etc,
> names should all be changed to integral names. For example, should both the
> existing mass_content_of_cloud_ice names be turned into aliases of a new name
> integral_wrt_height_of_mass_of_cloud_ice_in_air? Personally, I don't feel it
> would make the names any clearer so I'm no

Re: [CF-metadata] use of integral_wrt_depth_of_sea_water_practical_salinity

[Sebastien Villaume]

Hi Martin,

This is interesting because it makes me realize that I am not the only one 
facing these issues with "special" bounds that are function of other 
variables...

I like the idea of "pseudo-controlled" cell_method construction but in my case 
I would require something like:

cell_method = "depth: integral from X to Y (where Z)" 

with X being "surface" and Y being "sea_floor" with eventually a "where" clause 
with Z being "sea".


I think that this kind of issues should not be solved on a case-by-case basis 
but addressed in a general context because the case-by-case approach always 
leads to specific solutions...


/Sébastien

- Original Message -
> From: "Martin Juckes - UKRI STFC" <martin.juc...@stfc.ac.uk>
> To: "Karl Taylor" <taylo...@llnl.gov>, "Sebastien Villaume" 
> <sebastien.villa...@ecmwf.int>
> Cc: cf-metadata@cgd.ucar.edu, "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
> Sent: Monday, 16 April, 2018 10:02:28
> Subject: Re: use of integral_wrt_depth_of_sea_water_practical_salinity

> Hello Karl, Sebastien,
> 
> 
> I'm not sure that I've understood the whole thread, but to me it looks as 
> though
> the coordinate bounds would be the natural place to deal with this, though it
> would require a modification to the convention.
> 
> 
> There was a related, inconclusive, discussion in 2016 on the encoding of
> histogram bin ranges in the case where some bins are not defined by the
> numerical ranges that the current convention permits for coordinate bounds
> (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/059037.html ). The 
> idea
> of using flag_values and flag_meanings came up. For the current example you
> could set the lower value of the depth coordinate bounds of the vertical
> integral to -5 [m] and then have flag_values=-5,
> flag_meanings="ocean_floor".
> 
> 
> Alternatively, there appears to be agreement in
> https://cf-trac.llnl.gov/trac/ticket/152 that the cell_methods construction
> "mean where X" does not need to me restricted to horizontal spatial means. 
> That
> ticket discusses using it for temporal means, but it could also be used for
> depth means, as in:
> 
> "cell_methods = mean: depth where sea".  The idea that the CF area type "sea"
> can be depth dependant was accepted in a discussion of usage in CMIP6, where 
> we
> have many variables which require the surface sea extent, and others which
> require the total sea extent, including the small but significant portion
> extending under floating ice shelves. This would make the flag_values/meanings
> construction redundant.
> 
> 
> Incidentally, the cell_methods string can be parsed by David Hassell's  cf
> python library (https://pypi.python.org/pypi/cf-python ). This doesn't 
> entirely
> solve the problem because of the variable quality of the information that has
> been encoded in the cell_methods string in the past ... but it does give us a
> tool to use in our efforts to improve the situation.
> 
> 
> regards,
> 
> Martin
> 
> 
> 
> 
> From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Sebastien
> Villaume <sebastien.villa...@ecmwf.int>
> Sent: 13 April 2018 17:30
> To: Karl Taylor
> Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
> Subject: Re: [CF-metadata] use of
> integral_wrt_depth_of_sea_water_practical_salinity
> 
> Hi Karl,
> 
> I tend to agree that this solution is far from ideal.
> 
> The core issue is that there is no clear separation between a parameter
> (diagnostic quantities, observables, coordinates etc.) and what you do with it
> in CF: everything is squeezed in the standard name and in the cell_method (in 
> a
> non-consistent way).
> 
> In an ideal world, the standard names should only describe bare parameters and
> everything related to processing should go into something else. But many
> standard names make reference to time, space, post-processing, extra useful
> informations, etc.
> The cell_method attribute is in principle there to represent any
> (post-)processing but it is not always the case, sometimes the informations 
> are
> in the standard name directly or sometimes the cell_method is too limited to
> describe what needs to be described. like in my case here...
> To maintain a strict separation, the "integral_wrt_X_of_Y" should be one of 
> the
> cell_method from the beginning I also never understood why "difference" is
> not a valid method in the table E.1 of appendix E since "sum" is there.
> 
> I noticed few months ago 

Re: [CF-metadata] use of integral_wrt_depth_of_sea_water_practical_salinity

[Sebastien Villaume]

Hi Karl,

I tend to agree that this solution is far from ideal.

The core issue is that there is no clear separation between a parameter 
(diagnostic quantities, observables, coordinates etc.) and what you do with it 
in CF: everything is squeezed in the standard name and in the cell_method (in a 
non-consistent way).

In an ideal world, the standard names should only describe bare parameters and 
everything related to processing should go into something else. But many 
standard names make reference to time, space, post-processing, extra useful 
informations, etc.   
The cell_method attribute is in principle there to represent any 
(post-)processing but it is not always the case, sometimes the informations are 
in the standard name directly or sometimes the cell_method is too limited to 
describe what needs to be described. like in my case here... 
To maintain a strict separation, the "integral_wrt_X_of_Y" should be one of the 
cell_method from the beginning I also never understood why "difference" is 
not a valid method in the table E.1 of appendix E since "sum" is there.

I noticed few months ago a thread discussing ontologies in connection with the 
proposal of standard names for isotopes. Hundreds of new standard names were 
added. To me this was all wrong: only few standard names should have been 
added: mass_concentration, density, optical_depth, whatever physical property 
you like. Each variable holding one of these standard name should point to a 
scalar through a controlled attribute. The scalar should  name the isotope or 
the type of particle or the chemical constituent, etc. 
I can already see coming hundreds of new standard names each time a new useful 
property for isotopes or molecules is required.

You will not prevent explosion of standard names if you don't limit them to the 
"what". The "when" should go in the time variable(s), the "where" in the 
spatial variables, and finally the "how" either in the cell_method with clear 
controlled vocabulary or using a new controlled mechanism yet to define.   

/Sébastien

- Original Message -----
> From: "Karl Taylor" <taylo...@llnl.gov>
> To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>, "Lowry, Roy K." 
> <r...@bodc.ac.uk>, "Jonathan Gregory"
> <j.m.greg...@reading.ac.uk>
> Cc: cf-metadata@cgd.ucar.edu
> Sent: Friday, 13 April, 2018 16:32:39
> Subject: Re: [CF-metadata] use of 
> integral_wrt_depth_of_sea_water_practical_salinity

> Dear all,
> 
> I am wary of a "slippery slope" if every calculation performed on a
> quantity results in a new standard name for that quantity.  We have
> tried to avoid that in most cases by use of the cell methods, bounds,
> and climatology attributes.  Isn't there some way to accommodate this in
> a more general way?  I agree that use of non-controlled vocabulary is
> not ideal, but I would be interested in the kind of use case you
> envision where you would have to parse it? How does definition of a new
> standard name satisfy your use case of machine interpretation?
> 
> best regards,
> Karl
> 
> 
> On 4/13/18 8:22 AM, Sebastien Villaume wrote:
>> Dear Jonathan, Roy and Karl,
>>
>> thank you for your valuable inputs.
>>
>> I am not very fond of the cell_method solution: I am already very reluctant
>> using it because it is not controlled vocabulary and it is a nightmare to 
>> parse
>> to extract valuable metadata automatically. Now that I am discovering that 
>> one
>> can use a standard_name with no attached bounds instead of a proper variable
>> name with associated bounds makes me even more reluctant to use it!
>>
>> But I am not in a favour of encoding huge values of depth either...
>>
>> ... which leaves me being in favour of proposing new standard names by 
>> prefixing
>> existing standard names with "ocean_" !
>>
>>
>> /Sébastien
>>
>> - Original Message -
>>> From: "Karl Taylor" <taylo...@llnl.gov>
>>> To: cf-metadata@cgd.ucar.edu
>>> Sent: Wednesday, 11 April, 2018 18:45:07
>>> Subject: Re: [CF-metadata] use of
>>> integral_wrt_depth_of_sea_water_practical_salinity
>>> Dear Sebastien,
>>>
>>> One option would be to include in cell_methods the following:
>>>
>>> cell_methods = "depth: mean (from surface to sea floor)"
>>>
>>> where depth is the standard name for the vertical coordinate, as
>>> provided for  in
>>> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#cell-methods-no-coordinates
>>> , and the information in par

Re: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

[Sebastien Villaume]

Dear list,

any more comments? can we move forward and agree on these new standard names?

thanks
/Sébastien

- Original Message -
> From: "Jonathan Gregory" <jonathan.greg...@ncas.ac.uk>
> To: cf-metadata@cgd.ucar.edu
> Sent: Wednesday, 11 April, 2018 18:32:30
> Subject: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

> Dear Sebastien
> 
> I would favour your alternative
>> Alternatively, we could move the last sentence of each description to the
>> respective "ocean_mixed_layer_thickness_defined_by_*" standard names to make
>> that specific usage more explicit. We then keep a more general description 
>> for
>> the new "*_difference" standard names.
> for the reason you give, which appeals to me.
> 
> Also, instead of "auxiliary coordinate" I would say "coordinate variable or
> scalar coordinate variable". A scalar coord var is formally like a size-one
> auxiliary coord var. However the threshold variable could in principle be
> multi-valued; then you'd have a dimension for it, and it wouldn't be an aux
> coord var.
> 
> Best wishes
> 
> Jonathan
> 
> 
> ----- Forwarded message from Sebastien Villaume <sebastien.villa...@ecmwf.int>
> -
> 
>> Date: Tue, 10 Apr 2018 10:36:21 + (GMT-00:00)
>> From: Sebastien Villaume <sebastien.villa...@ecmwf.int>
>> To: cf-metadata@cgd.ucar.edu
>> Cc: "Lowry, Roy K." <r...@bodc.ac.uk>, Jonathan Gregory
>>  <j.m.greg...@reading.ac.uk>
>> Subject: Re: [CF-metadata] how touse
>>  ocean_mixed_layer_thickness_defined_by_*
>> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF52 (Linux)/8.6.0_GA_1200)
>> 
>> 
>> Dear CF list,
>> 
>> I took a bit longer to write down the proposed definitions of these 3 
>> standard
>> names.
>> 
>> 
>> standard name: sea_water_temperature_difference
>> units: K
>> description:
>> Sea water temperature is the in situ temperature of the sea water. The 
>> standard
>> name "sea_water_temperature_difference" can be used (as an auxiliary
>> coordinate) together with the standard name
>> "ocean_mixed_layer_thickness_defined_by_temperature" to define its 
>> temperature
>> criterion.
>> 
>> 
>> standard name: sea_water_sigma_theta_difference
>> units: kg/m3
>> description:
>> Sigma-theta of sea water is the potential density (i.e. the density when 
>> moved
>> adiabatically to a reference pressure) of water having the same temperature 
>> and
>> salinity, minus 1000 kg m-3. The standard name
>> "sea_water_sigma_theta_difference" can be used (as an auxiliary coordinate)
>> together with the standard name
>> "ocean_mixed_layer_thickness_defined_by_sigma_theta" to define its 
>> sigma_theta
>> criterion.
>> 
>> standard name: sea_water_sigma_t_difference
>> units: kg/m3
>> description:
>> Sigma-t of sea water is the density of water at atmospheric pressure (i.e. 
>> the
>> surface) having the same temperature and salinity, minus 1000 kg m-3. The
>> standard name "sea_water_sigma_t_difference" can be used (as an auxiliary
>> coordinate) together with the standard name
>> "ocean_mixed_layer_thickness_defined_by_sigma_t" to define its sigma_t
>> criterion.
>> 
>> 
>> Alternatively, we could move the last sentence of each description to the
>> respective "ocean_mixed_layer_thickness_defined_by_*" standard names to make
>> that specific usage more explicit. We then keep a more general description 
>> for
>> the new "*_difference" standard names.
>> 
>> /Sébastien
>> 
>> - Original Message -
>> > From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
>> > To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
>> > Cc: cf-metadata@cgd.ucar.edu, "Lowry, Roy K." <r...@bodc.ac.uk>
>> > Sent: Friday, 6 April, 2018 14:24:18
>> > Subject: Re: [CF-metadata] how to  use 
>> > ocean_mixed_layer_thickness_defined_by_*
>> 
>> > Dear Sebastien and Roy
>> > 
>> > Thanks. I agree that it's a good idea to include sea_water_.
>> > 
>> > Best wishes
>> > 
>> > Jonathan
>> > 
>> > On Thu, Apr 05, 2018 at 07:04:26PM +, Sebastien Villaume wrote:
>> >> Date: Thu, 5 Apr 2018 19:04:26 + (GMT-00:00)
>> >> From: Sebastien Villaume <sebastien.villa.

[CF-metadata] use of integral_wrt_depth_of_sea_water_practical_salinity

[Sebastien Villaume]

Dear list,

In 2016/2017, a list of new standard names for NEMO output has been proposed 
and accepted : 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/058964.html

from that initial list of standard names and after many iterations, one of the 
accepted standard name was:

standard name: integral_wrt_depth_of_sea_water_practical_salinity
units: m

But the initial list of proposed standard names had actually 2 entries for this 
standard name: 

- one entry which is the one that eventually made it to the list (the standard 
name above)
- a second entry for the case where the depth is the total depth, from surface 
to sea floor: ocean_integral_wrt_depth_of_sea_water_practical_salinity

During the discussion:
 -  Alison argued that the 2 entries were actually identical, the second one 
being simply a special case of the first one, i.e. when the depth corresponds 
to the total depth. She proposed later on to simply dropped the second entry.
 -  Antonio Cofino argued that in this case the reference to Axis and to bounds 
should be removed from the description because in the case of the total depth, 
the bounds are not a constant (but function of lat and lon) 

In the published description the reference to an axis and to bounds is still 
there.



My immediate problem is that I want to produce a parameter that is the integral 
wrt the whole depth of the salinity and I don't know how to do this.

for a fixed depth of 500m for instance, the metadata for the parameter would be:

float salinity500(t, y, x) ;
salinity500:standard_name = 
"integral_wrt_depth_of_sea_water_practical_salinity" ;
salinity500:units = "m" ;
salinity500:coordinates = "time dpt500 latitude longitude" ;
float dpt500 ;
dpt500:standard_name = "depth_below_geoid" ;
dpt500:units = "m" ;
dpt500:axis = "Z" ;
dpt500:positive = "down" ;
dpt500:bounds = dpt500_bnds ;
float dpt500_bnds(bnds) ;

and in the dpt500_bnds array, I have : [0., 500.]

for the total depth, I can't use the same mechanism, because the second value 
of the bounds is not a constant, it is a function of lat and lon: [0., 
f(lat,lon)]


How can I solve this?

Is it possible to reconsider the standard name 
ocean_integral_wrt_depth_of_sea_water_practical_salinity (or a variation of it)?
Another approach could be to keep the existing standard name, add a new 
standard name that represents the total water column and use it as an auxiliary 
coordinate.

thanks,


Dr. Sébastien Villaume

M.A.R.S. Analyst
ECMWF Data Governance facilitator

ECMWF 
Shinfield Park,
Reading RG2 9AX, UK
+44 (0)118 949 9301
+44 (0)7825 521592
sebastien.villa...@ecmwf.int

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

Re: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

[Sebastien Villaume]

Dear CF list,

I took a bit longer to write down the proposed definitions of these 3 standard 
names.


standard name: sea_water_temperature_difference 
units: K
description:
Sea water temperature is the in situ temperature of the sea water. The standard 
name "sea_water_temperature_difference" can be used (as an auxiliary 
coordinate) together with the standard name 
"ocean_mixed_layer_thickness_defined_by_temperature" to define its temperature 
criterion.


standard name: sea_water_sigma_theta_difference
units: kg/m3
description:
Sigma-theta of sea water is the potential density (i.e. the density when moved 
adiabatically to a reference pressure) of water having the same temperature and 
salinity, minus 1000 kg m-3. The standard name 
"sea_water_sigma_theta_difference" can be used (as an auxiliary coordinate) 
together with the standard name 
"ocean_mixed_layer_thickness_defined_by_sigma_theta" to define its sigma_theta 
criterion.

standard name: sea_water_sigma_t_difference
units: kg/m3
description:
Sigma-t of sea water is the density of water at atmospheric pressure (i.e. the 
surface) having the same temperature and salinity, minus 1000 kg m-3. The 
standard name "sea_water_sigma_t_difference" can be used (as an auxiliary 
coordinate) together with the standard name  
"ocean_mixed_layer_thickness_defined_by_sigma_t" to define its sigma_t 
criterion.


Alternatively, we could move the last sentence of each description to the 
respective "ocean_mixed_layer_thickness_defined_by_*" standard names to make 
that specific usage more explicit. We then keep a more general description for 
the new "*_difference" standard names.

/Sébastien

- Original Message -
> From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
> To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
> Cc: cf-metadata@cgd.ucar.edu, "Lowry, Roy K." <r...@bodc.ac.uk>
> Sent: Friday, 6 April, 2018 14:24:18
> Subject: Re: [CF-metadata] how to use 
> ocean_mixed_layer_thickness_defined_by_*

> Dear Sebastien and Roy
> 
> Thanks. I agree that it's a good idea to include sea_water_.
> 
> Best wishes
> 
> Jonathan
> 
> On Thu, Apr 05, 2018 at 07:04:26PM +, Sebastien Villaume wrote:
>> Date: Thu, 5 Apr 2018 19:04:26 + (GMT-00:00)
>> From: Sebastien Villaume <sebastien.villa...@ecmwf.int>
>> To: cf-metadata@cgd.ucar.edu
>> Cc: Jonathan Gregory <j.m.greg...@reading.ac.uk>, "Lowry, Roy K."
>>  <r...@bodc.ac.uk>
>> Subject: Re: [CF-metadata] how touse
>>  ocean_mixed_layer_thickness_defined_by_*
>> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF59
>>  (Linux)/8.6.0_GA_1200)
>> 
>> Dear Jonathan and Roy,
>> 
>> thank you for your suggestions.
>> 
>> I am happy to go with a set of general standard names if it is fine with
>> everyone. I find it actually useful to make the standard names reusable by 
>> not
>> hard-coding one of the reference. It is pretty clear from the mixed layer
>> definition that it is a difference with respect to the sea surface.
>> 
>> I am also happy to prefix sigma_theta and sigma_t with sea_water:
>> 
>> sea_water_temperature_difference (K)
>> sea_water_sigma_theta_difference (kg/m3)
>> sea_water_sigma_t_difference (kg/m3)
>> 
>> I will draft some definitions for tomorrow.
>> 
>> thanks!
>> 
>> /Sébastien
>> 
>> - Original Message -
>> > From: "Lowry, Roy K." <r...@bodc.ac.uk>
>> > To: cf-metadata@cgd.ucar.edu, "Jonathan Gregory" 
>> > <j.m.greg...@reading.ac.uk>
>> > Sent: Thursday, 5 April, 2018 18:34:48
>> > Subject: Re: [CF-metadata] how to  use 
>> > ocean_mixed_layer_thickness_defined_by_*
>> 
>> > Dear Jonathan and Sebastien,
>> > 
>> > 
>> > 
>> > 
>> > I was initially thinking of not including ' _defining_mixed_layer' in my
>> > suggestion and am certainly happy with leaving it out. However, I still 
>> > think
>> > sigma_t and sigma_theta should be prefixed with 'sea_water'. This would 
>> > give:
>> > 
>> > 
>> > 
>> > 
>> > 
>> > sea_water_temperature_difference
>> > sea_water_sigma_theta_difference
>> > sea_water_sigma_t_difference
>> > 
>> > Cheers, Roy.
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > Please note that I partially retired on 01/11/2015. I am now only working 
>> > 7.5
>> > hours a week and can on

Re: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

[Sebastien Villaume]

Dear Jonathan and Roy,

thank you for your suggestions.

I am happy to go with a set of general standard names if it is fine with 
everyone. I find it actually useful to make the standard names reusable by not 
hard-coding one of the reference. It is pretty clear from the mixed layer 
definition that it is a difference with respect to the sea surface.

I am also happy to prefix sigma_theta and sigma_t with sea_water:

sea_water_temperature_difference (K)
sea_water_sigma_theta_difference (kg/m3)
sea_water_sigma_t_difference (kg/m3)

I will draft some definitions for tomorrow. 

thanks!

/Sébastien

- Original Message -
> From: "Lowry, Roy K." <r...@bodc.ac.uk>
> To: cf-metadata@cgd.ucar.edu, "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
> Sent: Thursday, 5 April, 2018 18:34:48
> Subject: Re: [CF-metadata] how to use 
> ocean_mixed_layer_thickness_defined_by_*

> Dear Jonathan and Sebastien,
> 
> 
> 
> 
> I was initially thinking of not including ' _defining_mixed_layer' in my
> suggestion and am certainly happy with leaving it out. However, I still think
> sigma_t and sigma_theta should be prefixed with 'sea_water'. This would give:
> 
> 
> 
> 
> 
> sea_water_temperature_difference
> sea_water_sigma_theta_difference
> sea_water_sigma_t_difference
> 
> 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 <j.m.greg...@reading.ac.uk>
> Sent: 05 April 2018 18:28
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*
> Dear Sebastien
> 
> It's interesting that this question hasn't been raised before. Thanks for 
> doing
> so now. I agree that new standard names would be appropriate. There are 
> already
> some standard names containing "difference" in various ways. I would suggest
> that for your purpose the names don't have to be so specific. You could use
> sea_water_temperature_difference
> sigma_theta_difference
> sigma_t_difference
> because in the context of your use of them it is obvious what difference you
> mean. That would make these names perhaps useful for other purposes too. This
> is like the rather generic name
> air_temperature_threshold
> which doesn't indicate what the threshold can be used for. I would also 
> suggest
> that the definitions of the three kinds of mixed layer depth should have a
> sentence added to say that the threshold should be stored in a coordinate var,
> e.g. like the sentence for 
> number_of_days_with_air_temperature_above_threshold.
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from Sebastien Villaume <sebastien.villa...@ecmwf.int>
> -
> 
>> Date: Thu, 5 Apr 2018 13:55:50 +
>> From: Sebastien Villaume <sebastien.villa...@ecmwf.int>
>> To: CF Metadata <cf-metadata@cgd.ucar.edu>
>> Subject: Re: [CF-metadata] how to use
>> ocean_mixed_layer_thickness_defined_by_*
>> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF52 (Linux)/8.6.0_GA_1200)
>> 
>> Hi all,
>> 
>> It seems that my question did not attract much response. :(
>> 
>> Is it because no one knows how to use these standard names and properly 
>> encode
>> the "quantity that differs from its surface value by a certain amount"?
>> 
>> Giving it more thoughts I feel that I need new standard names to describe 
>> this
>> properly.
>> 
>> Would it make sense to describe it this way:
>> 
>> float swtd ;
>> swtd:standard_name = "sea_water_temperature_difference_wrt_sea_surface" ;
>> swtd:units = "degC" ;
>> swtd:axis = "Z" ;
>> swtd:positive = "down" ;
>> swtd:long_name = "temperature difference wrt its surface value"
>> 
>> float omlt(t, j, i) ;
>> omlt:standard_name = "ocean_mixed_layer_thickness_defined_by_temperature" ;
>> omlt:units = "m" ;
>> omlt:coordinates = "time swtd1 latitude longitude" ;
>> omlt:long_name = "ocean mixed layer defined by difference of temperature from
>> surface"
>> 
>> and the scalar value swtd can be 0.5 degC, 1.0 degC, etc.
>> 
>> In this case, I need standard names working with temperature, s

Re: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

[Sebastien Villaume]

Hi all,

It seems that my question did not attract much response. :(

Is it because no one knows how to use these standard names and properly encode 
the "quantity that differs from its surface value by a certain amount"?

Giving it more thoughts I feel that I need new standard names to describe this 
properly.

Would it make sense to describe it this way:

float swtd ;
swtd:standard_name = "sea_water_temperature_difference_wrt_sea_surface" ;
swtd:units = "degC" ;
swtd:axis = "Z" ;
swtd:positive = "down" ;
swtd:long_name = "temperature difference wrt its surface value"

float omlt(t, j, i) ;
omlt:standard_name = "ocean_mixed_layer_thickness_defined_by_temperature" ;
omlt:units = "m" ;
omlt:coordinates = "time swtd1 latitude longitude" ;
omlt:long_name = "ocean mixed layer defined by difference of temperature 
from surface"

and the scalar value swtd can be 0.5 degC, 1.0 degC, etc.

In this case, I need standard names working with temperature, sigma_theta and 
sigma_t:

sea_water_temperature_difference_wrt_sea_surface
sigma_theta_difference_wrt_sea_surface
sigma_t_difference_wrt_sea_surface


any quick suggestions are very welcome!

thanks
/Sébastien

- Original Message -
> From: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
> To: "CF Metadata" <cf-metadata@cgd.ucar.edu>
> Sent: Wednesday, 4 April, 2018 14:04:42
> Subject: [CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

> Dear list,
> 
> I have a question regarding the use of the standard names of the form
> ocean_mixed_layer_thickness_defined_by_*
> 
> the definition from the official standard name table is:
> 
> "The ocean mixed layer is the upper part of the ocean, regarded as being
> well-mixed. The base of the mixed layer defined by temperature, sigma or
> sigma_theta is the level at which the quantity indicated differs from its
> surface value by a certain amount."
> 
> From what I understand, in the case of
> ocean_mixed_layer_thickness_defined_by_temperature, I should specify some
> quantity as a scalar (Z axis), but it is actually a temperature difference 
> that
> I need to encode, not a plain temperature : temp_surf - temp_base_level =
> temp_delta_defining_mixed_layer_thickness
> 
> if it was simply a temperature I would maybe use:
> 
> float swpt ;
>swpt:standard_name = "sea_water_potential_temperature" ;
>swpt:units = "degC" ;
>swpt:axis = "Z" ;
>swpt:positive = "down" ;
> 
> but what I really want to encode is a temperature difference. How can I 
> specify
> that? Is "sea_water_potential_temperature" the correct standard name to use?
> 
> 
> same question for ocean_mixed_layer_thickness_defined_by_sigma_theta, how do I
> encode a "difference" in sigma_theta?
> 
> thanks,
> 
> 
> 
> Dr. Sébastien Villaume
> 
> M.A.R.S. Analyst
> ECMWF Data Governance facilitator
> 
> ECMWF
> Shinfield Park,
> Reading RG2 9AX, UK
> +44 (0)118 949 9301
> +44 (0)7825 521592
> sebastien.villa...@ecmwf.int
> 
> ___
> 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

[CF-metadata] how to use ocean_mixed_layer_thickness_defined_by_*

[Sebastien Villaume]

Dear list,

I have a question regarding the use of the standard names of the form 
ocean_mixed_layer_thickness_defined_by_*

the definition from the official standard name table is:

"The ocean mixed layer is the upper part of the ocean, regarded as being 
well-mixed. The base of the mixed layer defined by temperature, sigma or 
sigma_theta is the level at which the quantity indicated differs from its 
surface value by a certain amount."

From what I understand, in the case of 
ocean_mixed_layer_thickness_defined_by_temperature, I should specify some 
quantity as a scalar (Z axis), but it is actually a temperature difference that 
I need to encode, not a plain temperature : temp_surf - temp_base_level = 
temp_delta_defining_mixed_layer_thickness

if it was simply a temperature I would maybe use:

float swpt ;
swpt:standard_name = "sea_water_potential_temperature" ;
swpt:units = "degC" ;
swpt:axis = "Z" ;
swpt:positive = "down" ;

but what I really want to encode is a temperature difference. How can I specify 
that? Is "sea_water_potential_temperature" the correct standard name to use?


same question for ocean_mixed_layer_thickness_defined_by_sigma_theta, how do I 
encode a "difference" in sigma_theta?

thanks,



Dr. Sébastien Villaume

M.A.R.S. Analyst
ECMWF Data Governance facilitator

ECMWF 
Shinfield Park,
Reading RG2 9AX, UK
+44 (0)118 949 9301
+44 (0)7825 521592
sebastien.villa...@ecmwf.int

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

Re: [CF-metadata] various "time" in CF

[Sebastien Villaume]

Dear Jonathan, Chris and other,

@Chris, thanks for your contribution to the discussion. very interesting

I don't agree with your comment regarding 3D data variable with 4 coordinates 
being wrong. I have 3 physical axes and 4 coordinates, yes, but leadtime is a 
coordinates associated to the same time axis than the forecast_reference_time 
coordinate.
In other words, I have 2 coordinates sharing the same physical axis. I don't 
have multiple Time, I have multiple descriptions/partitioning of Time.

I am doing this because I want to associate 2 informations for each time: the 
reference time and the elapsed time since that reference time (instead of only 
providing the valid time which is simply the composite of the two with a loss 
of information). As Jonathan pointed it out, this is discussed in detail in 
trac ticket 117 and on this mailing list. I have also looked at the discussions 
from the early 90's on the unidata netCDF mailing list. It took a while to go 
through, it seems to be a recurrent problem and nobody really solved it so far.

@Jonathan,

I started this thread precisely to revive the discussion from trac ticket 117 
(btw, I can log in on the trac site but sadly not add any comments to existing 
tickets(!))

We have a fundamental disagreement: I don't see this as a "multiple time axes" 
problem, I see it as a "single time axis with multiple time coordinates defined 
on it" problem. Our preferred solution (so far) is in fact to use all three 
standard names (time, forecast_reference_time and forecast_period) in the same 
file but only "time" has the attribute "axis = T". One can see the two other 
coordinates as "auxiliary coordinates" of the same physical axis. It means 
having redundant informations (only 2 are needed, the 3rd one can be derived 
from these 2) but it makes the data files compatible with more tools.

I see two options to move forward:
1) expand the available list of standard names to be able to describe 
accurately any type of forecasts, analysis, hindcast, etc.

2) recognise that time and processes are decoupled information, deprecates 
"forecast_reference_time" and "forecast_period" for something more generic like 
"reference_time" and "time_interval", and finally design a mechanism to 
describe forecast, hindcast, analysis, etc. 


 
cheers,
/Sébastien

- Original Message -
From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 25 October, 2017 13:50:53
Subject: Re: [CF-metadata] various "time" in CF

Dear Sebastien and Chris

The various ways to handle forecast times, analysis times and forecast
periods with multiple time axes have been discussed several times before. Since
there are plenty of use-cases, and it's complicated, it would be good if we
could agree on recommended ways to do it, which could be added to the CF
standard document as examples. The last time this was attempted was over two
years ago, in cf-trac.llnl.gov/trac/ticket/117. Perhaps you could have a look
at that and comment if appropriate, and maybe also my earlier summary, over a
decade ago (!), in mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html.

Best wishes

Jonathan

- Forwarded message from Chris Barker <chris.bar...@noaa.gov> -

> Date: Tue, 24 Oct 2017 14:12:33 -0700
> From: Chris Barker <chris.bar...@noaa.gov>
> To: Sebastien Villaume <sebastien.villa...@ecmwf.int>
> CC: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu>
> Subject: Re: [CF-metadata] various "time" in CF
> 
> My thoughts:
> 
> Example 1:
> >
> > ...
>  variables:
> 
> >
> > double time(t) ;
> > time:units = "hours since 2010-01-01 00:00:00" ;
> > time:standard_name = "time" ;
> > time:calendar = "gregorian" ;
> > time:axis = "T" ;
> >
> >  lat/long  here 
> >
> > float data(t, j, i) ;
> > ...
> > data:standard_name = "temperature" ;
> > data:coordinates = "time lat lon" ;
> > ...
> > What is this? Is this an analysis? an observation? or something else?
> >
> 
> That should be specified one way or another in the attributes of the data
> variable -- what type of data it is has nothing to do with what time it is
> associated with.
> 
> the coordinates attribute specifies that the time axis is described by the
> "time" variable, and the time attributes specify that it is representing
> time, and what units an calendar -- a particular datetime is exactly the
> same regardless of whether it's an analysis or observation, etc.
> 
> Indeed, one very might have an an

Re: [CF-metadata] various "time" in CF

[Sebastien Villaume]

Hi Antonio,

if I understand you correctly the only thing that distinguishes an analysis 
from the initial forecast step is the use or not of forecast_period with value 
0? Is it a common practice and are all netCDF users familiar and confortable 
with that subtle difference? 
How can I include in the same file the analysis and the entire forecast?

I fully agree with you that "forecast", "hindcast", "analysis", "reanalysis", 
etc. do not relate to the time coordinate. But this is violated by the use of 
"forecast_reference_time" and "forecast_period" instead of simply 
"reference_time" and "period"? Do you agree?

I never thought of using realization as a way to describe all these concepts. I 
always thought that realization was specifically designed for probability 
related stuff and that the standard_name comes from the definition of a 
"realization" in probability/statistic theory.
I would define the various concepts as various "processes" rather than 
"realizations".

In the case of a set of hindcasts, how would you write the metadata? 

cheers,
/Sébastien

- Original Message -
From: "Antonio S. Cofiño" <antonio.cof...@unican.es>
To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
Cc: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 18 October, 2017 22:24:54
Subject: Re: [CF-metadata] various "time" in CF

Hi Sebastiien

On 18/10/17 18:19, Sebastien Villaume wrote:
> Hi Antonio,
>
> thank you for your detailed answer. You answered some of my questions but 
> completely misses one crucial point, i.e. how do I distinguish 2 very 
> different usage of the same generic standard name ?
I understand that you don't mean to have 2 coordinates with 
forecast_period as value for the attribute standard_name right?

My point it's to avoid the usage of standard_time="time" unless it's 
been used for the valid time concept (for example, observations).
>
> I give you few concrete examples.
>
> Example 1:
>
> dimensions:
>  i = 360 ;
>  j = 180 ;
>  t = 1 ;
>
> variables:
>
>  double time(t) ;
>  time:units = "hours since 2010-01-01 00:00:00" ;
>  time:standard_name = "time" ;
>  time:calendar = "gregorian" ;
>  time:axis = "T" ;
>
>   lat/long  here 
>
>  float data(t, j, i) ;
>  ...
>  data:standard_name = "temperature" ;
>  data:coordinates = "time lat lon" ;
>  ...
>
> data:
>
>  time = [ 00 ]
>  ...
>
>
> What is this? Is this an analysis? an observation? or something else?
Because the usage of "time" as standard_name for the time coordinate I'm 
not able to say if it's an analysis or a forecast. What I'm able to say 
is that the variable "data" are temperatures with valid time at 
2010-01-01 00:00:00 (instantaneous)
>
> ith
> Example 2:
>
> dimensions:
>  i = 360 ;
>  j = 180 ;
>  t = 5 ;
>
> variables:
>  double forecast_reference_time(t) ;
>  forecast_reference_time:units = "hours since 2010-01-01 00:00:00" ;
>  forecast_reference_time:standard_name = "forecast_reference_time" ;
>   
>  double leadtime(t) ;
>  leadtime:units="hours" ;
>  leadtime:standard_name="forecast_period" ;
>   
>
>   lat/long 
>
>  float data(t, j, i) ;
>  ...
>  data:standard_name = "temperature" ;
>  data:coordinates = "leadtime forecast_reference_time lat lon" ;
>  ...
>
> data:
>
>  forecast_reference_time = [  00,  00,  00,  00,  00 ]
>
>  leadtime = [ 00, 06, 12, 18, 24 ]
>  ...
>
> What is this? is it the forecast done back on the 1st January 2010? or is it 
> a hindcast done years later to test the model of today? or is it a forecast 
> from a reanalysis dataset, for instance ERA5? or something else?
It's a forecast with analysis time on the 2010-01-01 00:00:00 and time 
steps of 00, 06, 12, 18 and 24 which are valid at 2010-01-01 00:00:00, 
2010-01-01 06:00:00, 2010-01-01 12:00:00, 2010-01-01 18:00:00 and 
2010-01-02 00:00:00 (respectively). IMO a hindcast or reanalysis are 
different concepts that doesn't relates to time coordinates directly but 
they relate to different "realization" or "source" auxiliary coordinates 
or as global attributes.



>
> extra question for example 2: lets assume it is a hindcast. how will I be 
> able to distinguish this hindcast done today from the hindcast I am going to 
> do in 5 years time to test the model then? or fro

Re: [CF-metadata] various "time" in CF

[Sebastien Villaume]

Hi Antonio,

thank you for your detailed answer. You answered some of my questions but 
completely misses one crucial point, i.e. how do I distinguish 2 very different 
usage of the same generic standard name ?

I give you few concrete examples.

Example 1:

dimensions:
i = 360 ;
j = 180 ;
t = 1 ; 

variables:

double time(t) ;
time:units = "hours since 2010-01-01 00:00:00" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
time:axis = "T" ;

 lat/long  here 

float data(t, j, i) ;
...
data:standard_name = "temperature" ;
data:coordinates = "time lat lon" ;
...

data:

time = [ 00 ]
...


What is this? Is this an analysis? an observation? or something else? 



Example 2:

dimensions:
i = 360 ;
j = 180 ;
t = 5 ;

variables:
double forecast_reference_time(t) ;
forecast_reference_time:units = "hours since 2010-01-01 00:00:00" ;
forecast_reference_time:standard_name = "forecast_reference_time" ;
 
double leadtime(t) ;
leadtime:units="hours" ;
leadtime:standard_name="forecast_period" ;
 

 lat/long 

float data(t, j, i) ;
...
data:standard_name = "temperature" ;
data:coordinates = "leadtime forecast_reference_time lat lon" ;
...

data:

forecast_reference_time = [  00,  00,  00,  00,  00 ]

leadtime = [ 00, 06, 12, 18, 24 ]
...

What is this? is it the forecast done back on the 1st January 2010? or is it a 
hindcast done years later to test the model of today? or is it a forecast from 
a reanalysis dataset, for instance ERA5? or something else?

extra question for example 2: lets assume it is a hindcast. how will I be able 
to distinguish this hindcast done today from the hindcast I am going to do in 5 
years time to test the model then? or from the hindcast I did 2 years ago for 
that date?


It is to clarify this sort of things that I would like to have extra standard 
name, something less generic than the 3 available standard names. 
If I change the standard name in example 1 for "analysis_time", isn't it more 
clear what it is? 
If I use hindcast_reference_time and hindcast_period in example 2 AND I include 
a mechanism to encode when the hindcast has been computed, isn't it clearer as 
well? 


more comments are very welcome! :)

cheers,
/Sébastien

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

[CF-metadata] various "time" in CF

[Sebastien Villaume]

Hi all,

I am trying to find a consistent way to describe Time in CF-netCDF, so far 
without success. :(

The main reason is that there are only 3 standard names to describe Time 
(unless I missed something in the official CF standard name list):

 - time
 - forecast_reference_time
 - forecast_period


I would like to describe properly (and without relying at all on the file 
names):
 - a forecast
 - several forecasts in the same file
 - an analysis
 - several analyses in the same file
 - a reforecast/hindcast
 - several reforecasts/hindcasts in the same file
 - observations
 - data assimilation/acquisition 
 - distinguish if the data variable is associated with an analysis time or a 
forecast reference time (some data variables do differ between analysis and 
forecast step 0!)
 - etc.

of course, I could use the generic "time" standard name and put all the 
required informations in the "long_name" attribute but I don't want to do that: 
long_name is a free text attribute, I need controlled vocabulary which is 
exactly the purpose of the standard_name attribute. 

I also need to be able to reference these "kinds" of time coordinates in the 
cell_method attribute of my data variables to describe statistical processing 
like sums/accumulations, min/max, means, standard deviations, etc. 

The simplest solution that comes to my mind would be to add new standard names 
for these kinds of time coordinates but it seems to be such a common issue that 
I can't believe nobody proposed before. Hence, I am wondering if I am missing 
something here or if someone tried and it was not very well 
received/rejected...  

Is it worth spending time drafting a proposal to define new standard names for 
time coordinates?

cheers,


Dr. Sébastien Villaume

M.A.R.S administrator
DATA Governance facilitator

ECMWF 
Shinfield Park,
Reading RG2 9AX, UK
+44 7825 521592
sebastien.villa...@ecmwf.int

___
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 NEMO ocean model output

[Sebastien Villaume]

Dear Alison,

thank you very much for your thorough search and the time spent on this!

We are happy with the names and definitions.

thanks again

Best wishes,
/Sébastien

- Original Message -
From: "alison pamment" <alison.pamm...@stfc.ac.uk>
To: "sebastien villaume" <sebastien.villa...@ecmwf.int>
Cc: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>, cf-metadata@cgd.ucar.edu
Sent: Tuesday, 13 June, 2017 14:03:31
Subject: RE: [CF-metadata] New standard names for NEMO ocean model output

Dear Sebastien and Jonathan,

Thank you for clarifying the definition of the 
steric_change_in_sea_surface_height names. The only question now is whether to 
use the word 'steric' to describe the concept.

I did a brief internet search which turned up lots of links to articles about 
global sea level change, so I then wondered if 'steric' is only used in 
oceanography to talk about global and/or long term changes which might mean we 
shouldn't use it for the NEMO names. However, I then found the following in the 
AMS glossary which I often turn to as a reference: "Specific-volume anomaly (or 
anomaly of specific volume; also called steric anomaly; symbol δ.) In 
oceanography, the excess of the actual specific volume of the seawater at any 
point in the ocean over the specific volume of seawater of salinity 35 psu and 
temperature 0°C at the same pressure." 
(http://glossary.ametsoc.org/wiki/Steric_anomaly) (N.B. "Specific" means per 
unit mass). This definition sounds exactly like that used in the NEMO 
quantities - it isn't only a global quantity and doesn't require mean sea level 
as a baseline.

Our existing 'steric' names use the term more loosely:
global_average_steric_sea_level_change
'Global average steric sea level change is caused by changes in sea water 
density due to changes in temperature (thermosteric) and salinity (halosteric). 
Zero sea level change is an arbitrary level.'
global_average_thermosteric_sea_level_change
'Global average thermosteric sea level change is the part caused by change in 
density due to change in temperature i.e. thermal expansion. Zero sea level 
change is an arbitrary level.'
I don't think this is inconsistent with the new names because of the sentence 
about an arbitrary zero for the global sea level change. Also, in these names 
we do say 'sea_level', so here we are definitely talking about the change in 
mean sea level.

So, for the NEMO names, I think we should stick with what we had previously 
agreed (with the typo in the first definition now fixed).
steric_change_in_sea_surface_height (m)
' "Sea surface height" is a time-varying quantity. The steric change in sea 
surface height is the change in height that a water column of standard 
temperature T=0°C and practical salinity S=35.0 would undergo when its 
temperature and salinity are changed to the observed values. The sum of the 
quantities with standard names thermosteric_change_in_sea_surface_height and 
halosteric_change_in_sea_surface_height is the total steric change in the water 
column height, which has the standard name of 
steric_change_in_sea_surface_height. The sum of the quantities with standard 
names sea_water_mass_per_unit_area_expressed_as_thickness and 
steric_change_in_sea_surface_height is the total thickness of the sea water 
column.'

halosteric_change_in_sea_surface_height (m)
' "Sea surface height" is a time-varying quantity. The halosteric change in sea 
surface height is the change in height that a water column of standard 
practical salinity S=35.0 would undergo when its salinity is changed to the 
observed value. The sum of the quantities with standard names 
thermosteric_change_in_sea_surface_height and 
halosteric_change_in_sea_surface_height is the total steric change in the water 
column height, which has the standard name of 
steric_change_in_sea_surface_height.'

thermosteric_change_in_sea_surface_height (m)
' "Sea surface height" is a time-varying quantity. The thermosteric change in 
sea surface height is the change in height that a water column of standard 
temperature T=0°C would undergo when its temperature is changed to the observed 
value. The sum of the quantities with standard names 
thermosteric_change_in_sea_surface_height and 
halosteric_change_in_sea_surface_height is the total steric change in the water 
column height, which has the standard name of 
steric_change_in_sea_surface_height.'

For the existing steric names, I think we should add our usual text about 
'sea_level' to the definitions:
global_average_steric_sea_level_change
'Global average steric sea level change is caused by changes in sea water 
density due to changes in temperature (thermosteric) and salinity (halosteric). 
Zero sea level change is an arbitrary level. "Sea level" means mean sea level.'
global_average_thermosteric_sea_level_change
'Global average thermosteric sea level change is the p

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Dear All,

after discussing with the dataset owner/expert (Eric), he has confirmed to me 
that all the quantities involved are instantaneous and that sea_surface_height 
is the correct reference. 

The definition given by Alison is correct:

> the sum of
> sea_water_mass_per_unit_area_expressed_as_thickness and
> steric_change_in_sea_surface were meant to give the total water column
> thickness in a given model time step. The steric change measures the
> contribution of sea water density to the thickness compared with what it would
> be if the same mass of water had standard temperature and salinity
 
Regarding the choice between verbosity/clarity vs domain expert preferred 
naming, we are still open but it seemed through the discussion that the domain 
expert naming was favoured. Our main concern is that we want to use these 
standard names as soon as possible and want them published in the next release 
of the table.


Best Wishes,
/Sébastien

- Original Message -
From: "alison pamment" <alison.pamm...@stfc.ac.uk>
To: "alison pamment" <alison.pamm...@stfc.ac.uk>, "Jonathan Gregory" 
<j.m.greg...@reading.ac.uk>, cf-metadata@cgd.ucar.edu
Sent: Tuesday, 13 June, 2017 11:03:50
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear Jonathan and Sebastien,

Following on from my last post and looking at the names again, I understand the 
steric names to mean the contribution of temperature and salinity to the 
(instantaneous) sea_surface_height. Is that right? If so, then I still don't 
think we should be referring to mean sea level. In the discussion we did 
consider the possibility of writing the names as:
change_in_sea_surface_height_due_to_change_in_sea_water_density
change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinity
change_in_sea_surface_height_due_to_change_in_sea_water_temperature
but rejected them as being rather verbose. But are they in fact clearer? The 
main thing in the end is to avoid ambiguity and possible misinterpretation. 
What do you think?

Best wishes,
Alison

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



> -Original Message-
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
> alison.pamm...@stfc.ac.uk
> Sent: 13 June 2017 10:46
> To: j.m.greg...@reading.ac.uk; cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard names for NEMO ocean model output
> 
> Dear Jonathan and Sebastien,
> 
> Thank you both for your replies. Jonathan is correct that sea_surface_height
> means the instantaneous sea level and that's what I thought was meant by
> these names. I thought that the sum of
> sea_water_mass_per_unit_area_expressed_as_thickness and
> steric_change_in_sea_surface were meant to give the total water column
> thickness in a given model time step. The steric change measures the
> contribution of sea water density to the thickness compared with what it would
> be if the same mass of water had standard temperature and salinity doesn't it?
> I hadn't understood the names to mean a comparison to mean sea level, but if
> that is the intention then we should change the names as Jonathan suggests.
> Sebastien, please can you clarify?
> 
> Best wishes,
> Alison
> 
> --
> Alison Pamment   Tel: +44 
> 1235 778065
> Centre for Environmental Data Analysis Email: 
> alison.pamm...@stfc.ac.uk
> STFC Rutherford Appleton Laboratory
> R25, 2.22
> Harwell Campus, Didcot, OX11 0QX, U.K.
> 
> 
> > -Original Message-
> > From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
> > Jonathan Gregory
> > Sent: 09 June 2017 14:20
> > To: cf-metadata@cgd.ucar.edu
> > Subject: Re: [CF-metadata] New standard names for NEMO ocean model
> output
> >
> > Dear Sebastien and Alison
> >
> > Sorry to come back to this late, but in view of a more recent discussion, 
> > it's
> > occurred to me that we should put mean_sea_level rather than
> > sea_surface_height
> > in these three names. By sea_surface_height we mean its instantaneous
> level,
> > but when we speak of steric SL change we're referring to mean sea level.
> > Would
> > you agree?
> >
> > Best wishes
> >
> > Jonathan
> >
> > - Forwarded message from Sebastien Villaume
> > <sebastien.villa...@ecmwf.int> -
> >
> > > Date: Fri, 9 Jun 2017 07:43:19 +
> > > From: Sebastien Villaume <sebastien.vill

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Thank you Alison!

We (Kevin Marsh and myself) are happy with the amended definitions you 
proposed. 

only one minor tweak in the last sentence of the 
"steric_change_in_sea_surface_height" definition: I would add "_height" at the 
end of "steric_change_in_sea_surface". I assume it was intended that way but 
"_height" got somehow truncated.

Best wishes,
Sébastien

- Original Message -
From: "alison pamment" <alison.pamm...@stfc.ac.uk>
To: "sebastien villaume" <sebastien.villa...@ecmwf.int>
Cc: cf-metadata@cgd.ucar.edu, "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
Sent: Thursday, 8 June, 2017 15:28:25
Subject: RE: New standard names for NEMO ocean model output

Dear Sebastien,

Thank you for once again bringing this back to the list. I agree that the 
discussion seems to have settled on the "steric" names rather than the longer 
versions. We need to have definitions, so I've modified the text I suggested 
previously.

We now have:
steric_change_in_sea_surface_height (m)
' "Sea surface height" is a time-varying quantity. The steric change in sea 
surface height is the change in height that a water column of standard 
temperature T=0°C and practical salinity S=35.0 would undergo when its 
temperature and salinity are changed to the observed values. The sum of the 
quantities with standard names thermosteric_change_in_sea_surface_height and 
halosteric_change_in_sea_surface_height is the total steric change in the water 
column height, which has the standard name of 
steric_change_in_sea_surface_height. The sum of the quantities with standard 
names sea_water_mass_per_unit_area_expressed_as_thickness and 
steric_change_in_sea_surface is the total thickness of the sea water column.'

halosteric_change_in_sea_surface_height (m)
' "Sea surface height" is a time-varying quantity. The halosteric change in sea 
surface height is the change in height that a water column of standard 
practical salinity S=35.0 would undergo when its salinity is changed to the 
observed value. The sum of the quantities with standard names 
thermosteric_change_in_sea_surface_height and 
halosteric_change_in_sea_surface_height is the total steric change in the water 
column height, which has the standard name of 
steric_change_in_sea_surface_height.'

thermosteric_change_in_sea_surface_height (m)
' "Sea surface height" is a time-varying quantity. The thermosteric change in 
sea surface height is the change in height that a water column of standard 
temperature T=0°C would undergo when its temperature is changed to the observed 
value. The sum of the quantities with standard names 
thermosteric_change_in_sea_surface_height and 
halosteric_change_in_sea_surface_height is the total steric change in the water 
column height, which has the standard name of 
steric_change_in_sea_surface_height.'

If you are happy with these then the names can be accepted and added at the 
next update of the standard name table on 26th June.

Best wishes,
Alison

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



> -Original Message-
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of
> Sebastien Villaume
> Sent: 08 June 2017 13:09
> To: Sebastien Villaume
> Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
> Subject: Re: [CF-metadata] New standard names for NEMO ocean model output
> 
> Dear all,
> 
> since nobody is raising any more issues or showing strong feelings in the
> choice of final standard names, I propose to adopt
> 
> steric_change_in_sea_surface_height
> halosteric_change_in_sea_surface_height
> thermosteric_change_in_sea_surface_height
> 
> 
> We will start producing variables with these standard names in the coming
> weeks.
> 
> thanks,
> /Sébastien
> 
> - Original Message -
> From: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
> To: "Lowry, Roy K." <r...@bodc.ac.uk>
> Cc: cf-metadata@cgd.ucar.edu, "Jonathan Gregory"
> <j.m.greg...@reading.ac.uk>
> Sent: Tuesday, 30 May, 2017 09:42:54
> Subject: Re: [CF-metadata] New standard names for NEMO ocean model output
> 
> Dear all,
> 
> we would like to start using the remaining 3 standard names for NEMO output.
> We only need to reach a consensus on the standard names we would like to
> have:
> 
> change_in_sea_surface_height_due_to_change_in_sea_water_density
> change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinit
> y
> change_in_sea_surface_height_due_to_change_in_sea_water_temperature
> 
> or
> 
> ster

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Dear all,

since nobody is raising any more issues or showing strong feelings in the 
choice of final standard names, I propose to adopt

steric_change_in_sea_surface_height
halosteric_change_in_sea_surface_height
thermosteric_change_in_sea_surface_height


We will start producing variables with these standard names in the coming weeks.

thanks,
/Sébastien

- Original Message -
From: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
To: "Lowry, Roy K." <r...@bodc.ac.uk>
Cc: cf-metadata@cgd.ucar.edu, "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
Sent: Tuesday, 30 May, 2017 09:42:54
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear all,

we would like to start using the remaining 3 standard names for NEMO output. We 
only need to reach a consensus on the standard names we would like to have:

change_in_sea_surface_height_due_to_change_in_sea_water_density
change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinity
change_in_sea_surface_height_due_to_change_in_sea_water_temperature

or 

steric_change_in_sea_surface_height
halosteric_change_in_sea_surface_height
thermosteric_change_in_sea_surface_height

as I mentioned before, I don't have a strong preference, I only need a decision 
so that we can using them. 

thanks,
/Sébastien

- Original Message -
From: "Lowry, Roy K." <r...@bodc.ac.uk>
To: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>, "Sebastien Villaume" 
<sebastien.villa...@ecmwf.int>
Cc: cf-metadata@cgd.ucar.edu
Sent: Thursday, 27 April, 2017 09:48:42
Subject: Re: New standard names for NEMO ocean model output

Dear All,


My preference (but not insistence) would be for the more compact versions 
providing steric, halosteric and thermosteric are clearly described in the 
definitions. This is cleaner, less confusing, consistent with past practice, 
more likely to be discovered and readily understandable by those who are likely 
to need to use the Standard Names.


If this is unacceptable to anybody then I'm in total agreement with Jonathan 
that we need to be consistent with existing Standard Names incorporating 
'sterics', which means including both forms and aliasing them.


Note that established practice over the past decade has caused 'alias' to come 
to mean 'deprecated and replaced by' rather than 'synonym'. Consequently, if 
going for the option of adding both forms and replacing the existing 'sterics' 
then the 'sterics' need to be the 'deprecates' and the 'due-tos' need to be the 
replacements in all cases.


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 Sebastien 
Villaume <sebastien.villa...@ecmwf.int>
Sent: 27 April 2017 09:16
To: Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear all,

I am not a domain expert, I can't really grasp which set of names is more 
suitable. As a non expert, I would favour the first set because it is more 
explicit.

That said, I will follow what the domain experts and/or the standard names 
experts would recommend. Please let us know so we can agree and start using 
these names.


Best wishes,
/Sébastien

- Original Message -
From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 26 April, 2017 22:36:14
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear Sebastien

> @Jonathan: what would be the standard names if we were using 
> "_due_to_change_in_" ? Since it is a "change" of height due to a "change" of 
> a physical property, we end up with:
>
> change_in_sea_surface_height_due_to_change_in_sea_water_density
> change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinity
> change_in_sea_surface_height_due_to_change_in_sea_water_temperature

Yes, I agree, that would be right.

> It is fine for me but I understand it could look awkward to some 
> users/experts. It is however nicely verbose to help understand what those 
> parameters are.
>
> If we were removing "_above_sea_floor" from the names proposed by Alison:
>
> steric_change_in_sea_surface_height
> halosteric_change_in_sea_surface_height
> thermosteric_change_in_sea_surface_height
>
> it is more compact and elegant but it could be a bit cryptic to non-experts.

Yes, I agree with this too. As I mentioned, thermosteric and steric do appear
in existing names (one each), so we should eithe

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Dear all,

we would like to start using the remaining 3 standard names for NEMO output. We 
only need to reach a consensus on the standard names we would like to have:

change_in_sea_surface_height_due_to_change_in_sea_water_density
change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinity
change_in_sea_surface_height_due_to_change_in_sea_water_temperature

or 

steric_change_in_sea_surface_height
halosteric_change_in_sea_surface_height
thermosteric_change_in_sea_surface_height

as I mentioned before, I don't have a strong preference, I only need a decision 
so that we can using them. 

thanks,
/Sébastien

- Original Message -
From: "Lowry, Roy K." <r...@bodc.ac.uk>
To: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>, "Sebastien Villaume" 
<sebastien.villa...@ecmwf.int>
Cc: cf-metadata@cgd.ucar.edu
Sent: Thursday, 27 April, 2017 09:48:42
Subject: Re: New standard names for NEMO ocean model output

Dear All,


My preference (but not insistence) would be for the more compact versions 
providing steric, halosteric and thermosteric are clearly described in the 
definitions. This is cleaner, less confusing, consistent with past practice, 
more likely to be discovered and readily understandable by those who are likely 
to need to use the Standard Names.


If this is unacceptable to anybody then I'm in total agreement with Jonathan 
that we need to be consistent with existing Standard Names incorporating 
'sterics', which means including both forms and aliasing them.


Note that established practice over the past decade has caused 'alias' to come 
to mean 'deprecated and replaced by' rather than 'synonym'. Consequently, if 
going for the option of adding both forms and replacing the existing 'sterics' 
then the 'sterics' need to be the 'deprecates' and the 'due-tos' need to be the 
replacements in all cases.


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 Sebastien 
Villaume <sebastien.villa...@ecmwf.int>
Sent: 27 April 2017 09:16
To: Jonathan Gregory
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear all,

I am not a domain expert, I can't really grasp which set of names is more 
suitable. As a non expert, I would favour the first set because it is more 
explicit.

That said, I will follow what the domain experts and/or the standard names 
experts would recommend. Please let us know so we can agree and start using 
these names.


Best wishes,
/Sébastien

- Original Message -
From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 26 April, 2017 22:36:14
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear Sebastien

> @Jonathan: what would be the standard names if we were using 
> "_due_to_change_in_" ? Since it is a "change" of height due to a "change" of 
> a physical property, we end up with:
>
> change_in_sea_surface_height_due_to_change_in_sea_water_density
> change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinity
> change_in_sea_surface_height_due_to_change_in_sea_water_temperature

Yes, I agree, that would be right.

> It is fine for me but I understand it could look awkward to some 
> users/experts. It is however nicely verbose to help understand what those 
> parameters are.
>
> If we were removing "_above_sea_floor" from the names proposed by Alison:
>
> steric_change_in_sea_surface_height
> halosteric_change_in_sea_surface_height
> thermosteric_change_in_sea_surface_height
>
> it is more compact and elegant but it could be a bit cryptic to non-experts.

Yes, I agree with this too. As I mentioned, thermosteric and steric do appear
in existing names (one each), so we should either rename those with due_to, or
use the steric terms here, for consistency.

> I am fine with both formulations and I agree with Kevin, we could keep both 
> versions and make aliases.

I am fine too with either of them, but not with aliases for this purpose. We
use aliases to preserve backwards-compatibility when we change our minds, not
to provide synonyms in the first place.

Best wishes

Jonathan
___
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<http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata>
mailman.cgd.ucar.edu
This is an unmoderated list for discussi

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Dear all,

I am not a domain expert, I can't really grasp which set of names is more 
suitable. As a non expert, I would favour the first set because it is more 
explicit. 

That said, I will follow what the domain experts and/or the standard names 
experts would recommend. Please let us know so we can agree and start using 
these names.


Best wishes,
/Sébastien

- Original Message -
From: "Jonathan Gregory" 
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 26 April, 2017 22:36:14
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear Sebastien

> @Jonathan: what would be the standard names if we were using 
> "_due_to_change_in_" ? Since it is a "change" of height due to a "change" of 
> a physical property, we end up with:
> 
> change_in_sea_surface_height_due_to_change_in_sea_water_density
> change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinity
> change_in_sea_surface_height_due_to_change_in_sea_water_temperature

Yes, I agree, that would be right.

> It is fine for me but I understand it could look awkward to some 
> users/experts. It is however nicely verbose to help understand what those 
> parameters are.
> 
> If we were removing "_above_sea_floor" from the names proposed by Alison:
> 
> steric_change_in_sea_surface_height
> halosteric_change_in_sea_surface_height
> thermosteric_change_in_sea_surface_height
> 
> it is more compact and elegant but it could be a bit cryptic to non-experts.

Yes, I agree with this too. As I mentioned, thermosteric and steric do appear
in existing names (one each), so we should either rename those with due_to, or
use the steric terms here, for consistency.

> I am fine with both formulations and I agree with Kevin, we could keep both 
> versions and make aliases. 

I am fine too with either of them, but not with aliases for this purpose. We
use aliases to preserve backwards-compatibility when we change our minds, not
to provide synonyms in the first place.

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

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Dear Alison and Jonathan,

thank you for your comments.

@Jonathan: what would be the standard names if we were using 
"_due_to_change_in_" ? Since it is a "change" of height due to a "change" of a 
physical property, we end up with:

change_in_sea_surface_height_due_to_change_in_sea_water_density
change_in_sea_surface_height_due_to_change_in_sea_water_practical_salinity
change_in_sea_surface_height_due_to_change_in_sea_water_temperature

It is fine for me but I understand it could look awkward to some users/experts. 
It is however nicely verbose to help understand what those parameters are.

If we were removing "_above_sea_floor" from the names proposed by Alison:

steric_change_in_sea_surface_height
halosteric_change_in_sea_surface_height
thermosteric_change_in_sea_surface_height

it is more compact and elegant but it could be a bit cryptic to non-experts.

I am fine with both formulations and I agree with Kevin, we could keep both 
versions and make aliases. 

Best wishes,
/Sébastien


- Original Message -
From: "j m gregory" <j.m.greg...@reading.ac.uk>
To: cf-metadata@cgd.ucar.edu
Sent: Friday, 21 April, 2017 10:25:30
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear Alison and Sebastien

Thanks for your summary, Alison. I agree with Sebastien that we do not need
above_SURFACE in the sea-level change names, because they are changes, so the
reference level cancels out. Picking up Sebastien's other point, I agree that
instead of [thermo/halo]steric, we could say
due_to_change_in_sea_water_temperature/salinity/density.
If I was not an "expert" in this area, indeed I might argue against using the
usual words, for the sake of easy understanding by others! These quantities
are pretty much always called [thermo/halo]steric, and we already use "steric"
in a couple of standard names. However, it would be fine to rename these ones
as well if we prefer to avoid more opaque terminology.

Best wishes

Jonathan

- Forwarded message from Sebastien Villaume <sebastien.villa...@ecmwf.int> 
-

> Date: Tue, 18 Apr 2017 08:20:21 +
> From: Sebastien Villaume <sebastien.villa...@ecmwf.int>
> To: alison pamment <alison.pamm...@stfc.ac.uk>
> CC: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard names for NEMO ocean model output
> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
> 
> Dear Alison,
> 
> The new standard names you are suggesting for (3), (4) and (5) are 
> interesting. 
> 
> I have few comments:
> 
> when I searched "sea_surface_height" in the latest standard name table, I 
> noticed standard names with "sea_surface_height_amplitude_due_to", 
> "sea_surface_height_bias_due_to", and "sea_surface_height_correction_due_to". 
> would it make sense to use "sea_surface_height_change_due_to" or "due_to" is 
> only reserved for certain cases (like external physical processes)?
> 
> I am also wondering if the reference "above_X" for the height is needed: the 
> change in height will be the same whatever the origin chosen (sea floor, 
> geoid, etc.) because it is the difference between 2 heights sharing the same 
> reference. In that sense it feels that "steric_change_in_sea_surface_height", 
> "halosteric_change_in_sea_surface_height" and 
> "thermosteric_change_in_sea_surface_height" are enough.
> 
> Best wishes,
> /Sébastien
> 
> - Original Message -
> From: "alison pamment" <alison.pamm...@stfc.ac.uk>
> To: "sebastien villaume" <sebastien.villa...@ecmwf.int>, 
> cf-metadata@cgd.ucar.edu
> Sent: Thursday, 13 April, 2017 17:41:38
> Subject: RE: New standard names for NEMO ocean model output
> 
> Dear Jonathan and Sebastien,
> 
> Thank you both for your comments. I think we are now agreed on the following 
> names (with definitions as given in my previous email 
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059392.html):
> 
> 1. sea_water_mass_per_unit_area_expressed_as_thickness (m)
> 2. 
> ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity_threshold 
> (m)
> 2a. The existing name 
> ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity will 
> become an alias of 
> ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity_deficit 
> (m).
> 6. ratio_of_sea_water_potential_temperature_anomaly_to_relaxation_timescale 
> (K s-1)
> 7. ratio_of_sea_water_practical_salinity_anomaly_to_relaxation_timescale (s-1)
> 8. integral_of_sea_water_practical_salinity_wrt_depth (m)
> 
> These names are accepted for publication in the standard name table and will 
> be added at the next updat

Re: [CF-metadata] axis attribute

[Sebastien Villaume]

Hi David,

I am still missing an attribute attached to "latitude" and "longitude" to bind 
them with their respective axis/spatial dimension.
The "link" is still implicit if nothing else than what you wrote is added. I 
also feel that the dimension and axis attributes are somehow redundant.

I also find your long_name attribute misleading because all the values in 
latitude(j,i) goes on the Y axis and all the values in longitude(j,i) goes on 
the X axis! i and j are only the indices of the horizontal grid. Your long_name 
suggests something else.

Is it ok if I add in your example an "axis_mapping" attribute to lat and lon:

dimensions:
i = 100 ;
j = 200 ;
variables:
char x:
x:dimension = "i" ;
x:axis = "X" ;
x:standard_name = "???" ;
char y: 
y:dimension = "j" ;
y:axis = "Y" ;
y:standard_name = "???" ;
double longitude(j, i) ;
longitude:units = "degrees_east" ;
longitude:axis_mapping = x ;
double latitude(j, i) ;
latitude:units = "degrees_north" ;
latitude:axis_mapping = y  ;
double tas(j, i) ;
tas:standard_name = "air_temperature" ;
tas:units = "K" ;
tas:coordinates = "longitude latitude" ;
tas:axes = "x y" ;  // new data variable attribute which points to 
dimension variables



/Sébastien

- Original Message -
From: "David Hassell" <david.hass...@ncas.ac.uk>
To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
Cc: "Jim Biard" <jbi...@cicsnc.org>, "CF Metadata" <cf-metadata@cgd.ucar.edu>
Sent: Tuesday, 18 April, 2017 13:09:18
Subject: Re: [CF-metadata] axis attribute

Hello Sébastien,

If we were to go down a route like this (and I'm not sure myself about it),
I think a new generic "add metadata to a dimension" mechanism might be
better. This could be used to provide plotting hints, regridding hints (a
more compelling use case than plotting, for me) or anything else about a
dimension. The idea being that we have a place to store information
relating to a dimension which does not directly describe the other
variables which span that dimension.

A new "dimension variable" would have to say which dimension it relates to,
and may optionally have "axis", "long_name" and "comment" to describe the
dimension (any other attributes being considered non-standard). The
dimension variables would be referenced by data variables, rather than
coordinate variables:

dimensions:
i = 100 ;
j = 200 ;
variables:
char x: // dimension metadata variable (of
arbitrary type becuase it has no data)
x.dimension = "i" ; // mandatory dimension property which
says which dimension is being described
x:axis = "X" ;  // optional
x.long_name = "provide plotting/regridding hint that i should go on
X axis" ;// optional
char y: // dimension metadata variable (of
arbitrary type)
y.dimension = "j" ;
y:axis = "Y" ;
y.long_name = "provide plotting/regridding hint that j should go on
Y axis" ;
double longitude(j, i) ;
longitude:units = "degrees_east" ;
double latitude(j, i) ;
    latitude:units = "degrees_north" ;
double temperature(j, i) ;
tas:standard_name = "air_temperature" ;
tas:units = "K" ;
tas:coordinates = "longitude latitide" ;
tas:axes = "x y" ;  // new data variable attribute which points to
dimension variables


Thanks, David


On 18 April 2017 at 11:08, Sebastien Villaume <sebastien.villa...@ecmwf.int>
wrote:

> Dear Jonathan and Jim,
>
> thank you for your further comments.
>
> @Jonathan: I don't want to define an axis without coordinates or put the
> "axis" attribute on more than one object, I only propose to decouple the
> axis definition from the coordinate definition. I don't see why I can't
> define a dummy object, it is exactly what is done to define a crs: a
> variable without dimension, without data, only attributes:
>
>   int crs ;
> crs:grid_mapping_name = "latitude_longitude" ;
> crs:semi_major_axis = 6371000.0 ;
> crs:inverse_flattening = 0 ;
>
>
> following the same principle, I could define:
>
>   int axis_x ;
> axis_x:axis = X;
> axis_x:standard_name = "axis" ;
> axis_x:long_name = "axis for the longitude coordinate"
> axis_x:units = "1" ;
>
> and then have my longitude:
>
> float longitude(j,i);
> longitude:standard_name = &qu

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Dear Alison,

The new standard names you are suggesting for (3), (4) and (5) are interesting. 

I have few comments:

when I searched "sea_surface_height" in the latest standard name table, I 
noticed standard names with "sea_surface_height_amplitude_due_to", 
"sea_surface_height_bias_due_to", and "sea_surface_height_correction_due_to". 
would it make sense to use "sea_surface_height_change_due_to" or "due_to" is 
only reserved for certain cases (like external physical processes)?

I am also wondering if the reference "above_X" for the height is needed: the 
change in height will be the same whatever the origin chosen (sea floor, geoid, 
etc.) because it is the difference between 2 heights sharing the same 
reference. In that sense it feels that "steric_change_in_sea_surface_height", 
"halosteric_change_in_sea_surface_height" and 
"thermosteric_change_in_sea_surface_height" are enough.

Best wishes,
/Sébastien

----- Original Message -
From: "alison pamment" <alison.pamm...@stfc.ac.uk>
To: "sebastien villaume" <sebastien.villa...@ecmwf.int>, 
cf-metadata@cgd.ucar.edu
Sent: Thursday, 13 April, 2017 17:41:38
Subject: RE: New standard names for NEMO ocean model output

Dear Jonathan and Sebastien,

Thank you both for your comments. I think we are now agreed on the following 
names (with definitions as given in my previous email 
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059392.html):

1. sea_water_mass_per_unit_area_expressed_as_thickness (m)
2. ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity_threshold 
(m)
2a. The existing name 
ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity will become 
an alias of 
ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity_deficit (m).
6. ratio_of_sea_water_potential_temperature_anomaly_to_relaxation_timescale (K 
s-1)
7. ratio_of_sea_water_practical_salinity_anomaly_to_relaxation_timescale (s-1)
8. integral_of_sea_water_practical_salinity_wrt_depth (m)

These names are accepted for publication in the standard name table and will be 
added at the next update, scheduled for 24th April.

I think we have also agreed to drop proposal (9) 
integral_of_sea_water_practical_salinity_wrt_total_depth (m) because it is the 
same quantity as (8).

For the 'steric' names, Jonathan feels these should indicate that the term 
relates to a change in local sea level, rather than simply water column 
thickness, and Sebastien is keen that we adopt a common approach for all three 
names. We have a number of "sea_surface_height_above_X" names where X is 
variously "geoid", "reference_ellipsoid", etc. Based on this syntax I would 
then suggest the following names:

3. steric_change_in_sea_surface_height_above_sea_floor (m)
' "Sea surface height" is a time-varying quantity. The steric change in sea 
surface height is the change in height a water column of standard temperature 
T=0°C and practical salinity S=35.0 would undergo when its temperature and 
salinity are changed to the observed values. The sum of the quantities with 
standard names thermosteric_change_in_sea_surface_height_above_sea_floor and 
halosteric_change_in_sea_surface_height_above_sea_floor is the total steric 
change in the water column height, which has the standard name of 
steric_change_in_sea_surface_height_above_sea_floor. The sum of the quantities 
with standard names sea_water_mass_per_unit_area_expressed_as_thickness and 
steric_change_in_sea_surface_height_above_sea_floor is the total thickness of 
the sea water column.'

4. halosteric_change_in_sea_surface_height_above_sea_floor (m)
' "Sea surface height" is a time-varying quantity. The halosteric change in sea 
surface height is the change in height a water column of standard practical 
salinity S=35.0 would undergo when its salinity is changed to the observed 
value. The sum of the quantities with standard names 
thermosteric_change_in_sea_surface_height_above_sea_floor and 
halosteric_change_in_sea_surface_height_above_sea_floor is the total steric 
change in the water column height, which has the standard name of 
steric_change_in_sea_surface_height_above_sea_floor.'

5. thermosteric_change_in_sea_surface_height_above_sea_floor (m)
' "Sea surface height" is a time-varying quantity. The thermosteric change in 
sea surface height is the change in height a water column of standard 
temperature T=0°C would undergo when its temperature is changed to the observed 
value. The sum of the quantities with standard names 
thermosteric_change_in_sea_surface_height_above_sea_floor and 
halosteric_change_in_sea_surface_height_above_sea_floor is the total steric 
change in the water column height, which has the standard name of 
steric_change_in_sea_surface_height_above_sea_floor.'

Are these better?

Best wishes,
Alison

-

Re: [CF-metadata] axis attribute

[Sebastien Villaume]

Dear David,

I see your point and you are probably right that a plotting routine will 
probably sort this out.

However this is not what I am after, I am more interested in metadata discovery 
and indexing. 
I need to discover what I have in a file without plotting it, without having a 
human looking at it to confirm what it is and that it has been plotted 
correctly. 
I also would like to use these metadata informations to perform actions like 
merging netCDF files, slicing, cropping, aggregating, interpolating, comparing 
data in different grids and representations, etc.

I understand that implicit is fine and that explicit is not required for some 
applications. I have no issue with this. 
My personal point of view is that explicit is better than implicit: I tend to 
prefer "mandatory" over "optional".

Being implicit means that the assumptions made need to be valid 100% of the 
time to avoid accidents or corner cases.
I would like to be explicit so I need all the proper mechanisms (variables, 
semantics, etc.) in place so I can use them.
Right now it feels that I am missing some functionality.

Let me copy below few bits of the terminology section in the CF 1.7 draft 
document (very similar to 1.6). Please read it keeping in mind what is really 
an axis, a coordinate, a spatio-temporal dimension and an an array dimension. 
Each time you read "coordinate2, "dimension" or "dimensional", ask yourself 
what is implied and if it is not ambiguous:


variables

auxiliary coordinate variable
Any netCDF variable that contains coordinate data, but is not a coordinate 
variable (in the sense of that term defined by the NUG and used by this 
standard - see below). Unlike coordinate variables, there is no relationship 
between the name of an auxiliary coordinate variable and the name(s) of its 
dimension(s).

coordinate variable
We use this term precisely as it is defined in section 2.3.1 of the NUG . 
It is a one-dimensional variable with the same name as its dimension [e.g., 
time(time) ], and it is defined as a numeric data type with values that are 
ordered monotonically. Missing values are not allowed in coordinate variables.

grid mapping variable
A variable used as a container for attributes that define a specific grid 
mapping. The type of the variable is arbitrary since it contains no data.

multidimensional coordinate variable
An auxiliary coordinate variable that is multidimensional.

scalar coordinate variable
A scalar variable (i.e. one with no dimensions) that contains coordinate 
data. Depending on context, it may be functionally equivalent either to a 
size-one coordinate variable (Section 5.7, "Scalar Coordinate Variables") or to 
a size-one auxiliary coordinate variable (Section 6.1, "Labels" and Section 
9.2, "Collections, instances, and elements").


dimensions

latitude dimension
A dimension of a netCDF variable that has an associated latitude coordinate 
variable.

longitude dimension
A dimension of a netCDF variable that has an associated longitude 
coordinate variable.

spatiotemporal dimension
A dimension of a netCDF variable that is used to identify a location in 
time and/or space.

time dimension
A dimension of a netCDF variable that has an associated time coordinate 
variable.

vertical dimension
A dimension of a netCDF variable that has an associated vertical coordinate 
variable.


So according to this terminology, I have in my file, 2 auxiliary coordinates 
variables, but no "real" coordinates variables (according to the NUG) so my 
auxiliary coordinates are auxiliary to what?
What is a "multidimensional coordinate"? if dimension means spatio-temporal 
dimension it is a non sense because a coordinate can only reference 1 
spatio-temporal dimension, if it is meant to be array-dimensions it is not 
clear...
What are my 2D array latitude and longitude then? are they latitude and 
longitude dimension defined in the terminology? not really because there 
are no such things as latitude and longitude dimension: you can define latitude 
and longitude coordinates, associated with 2 axis that themselves define 2 
spatial dimensions... but the coordinates can be defined in whatever n-D array.
I like the definition of "grid mapping variable", I could use a similar 
variable to be a container for attributes for my "axis variable" with no data!

I know that in the day-to-day life and discussions we don't make the effort to 
be precise (I don't) and that it is easy to overload the meaning of things but 
I think that the CF document needs to be very precise, non ambiguous and can 
not mix axes, coordinates, spatio-temporal and array dimensions.

/Sébastien

- Original Message -
From: "David Hassell" &

Re: [CF-metadata] CF compliant tripolar grid representation

[Sebastien Villaume]

t;
> To: "Hedley, Mark" <mark.hed...@metoffice.gov.uk>, "cf-metadata@cgd.ucar.edu"
>   <cf-metadata@cgd.ucar.edu>
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> Hi Mark,
> 
> I support your concerns. There is a difference between stating which 
> geographic and/or projected CRS is being used and defining which specific 
> points are included in the data set. The issue of describing a tripolar grid 
> seems to relate to the latter not the former.
> 
> From a quick glance at Appendix F I would say that the odd one out is the 
> rotated pole. Describing a grid as 'rotated pole' is surely just convenient 
> shorthand for describing which points in a lat-long CRS you are using. It is 
> certainly not a CRS and, arguably, not a grid mapping. Is it possible, for 
> example, to declare that a grid is 'rotated pole' _and_ that the CRS is WGS84?
> 
> Perhaps tripolar grids and rotated pole grids are two parts of the same 
> problem.
> 
> Regards,
> 
> Dan
> 
> 
> -Original Message-
> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf 
> Of Hedley, Mark
> Sent: 06 April 2017 09:28
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> I would like to restate my concern about describing the tri-polar grid as a 
> coordinate reference system, using the 'grid mapping' defined in approach in 
> 5.6. Horizontal Coordinate Reference Systems, Grid Mappings, and Projections 
> and Appendix F Grid Mappings.
> 
> I do not think that the tri-polar grid is a Coordinate Reference System, 
> unlike all other entities defined in Appendix F.  I think that adding a 
> tri-polar definition here fundamentally alters the interpretation of 'grid 
> mapping' and has potentially significant implications for software providing 
> capabilities to work with grid mapping entities.
> This would represent a significant change of scope for these aspects of the 
> Conventions document.
> 
> Currently all entries in Appendix F are either a Geographic Coordinate 
> Reference System or a Projected Coordinate Reference System.
> The tri-polar grid is neither of these.
> The mechanics of looking up the required longitude and latitude values 
> for a given x/i and y/j coordinate index are not mathematically 
> similar to the calculations for geographic or projected space
> 
> I think the CF community would do well to consider where else information 
> defining a tri-polar grid may be encoded in a file, and to keep the scope of 
> the Grid Mapping section constrained.
> 
> I saw Appendix D: Parametric Vertical Coordinates mentioned as well, all be 
> it in passing.  The tri-polar grid does not seem like a case of parametric 
> coordinates either, to me, even if the 'vertical' was relaxed.
> 
> I realise I am raising objections but not proposing solutions, I do not have 
> an easy answer here, I am afraid.
> 
> all the best
> mark
> 
> 
> 
> From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of 
> Sebastien Villaume [sebastien.villa...@ecmwf.int]
> Sent: 05 April 2017 19:20
> To: Gregory, Jonathan
> Cc: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> Dear Jonathan,
> 
> I will try to look at Appendix F and come back with a proposal. I have a 
> rough idea of what I need but I have no clue what would be the proper terms 
> for those: extra attributes to describe north pole 1 and north pole 2, 
> latitude separating the "regular" from the irregular region, etc.
> 
> 
> 
> Dr. Sébastien Villaume
> Analyst
> ECMWF
> Shinfield Park,
> Reading RG2 9AX, UK
> +44 7825 521592
> sebastien.villa...@ecmwf.int
> 
> 
> - Original Message -
> From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
> To: cf-metadata@cgd.ucar.edu
> Sent: Wednesday, 5 April, 2017 16:15:55
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> Dear Sebastien
> 
> Apologies. I meant Appendix F (grid mappings) not D. Could you describe your 
> species of tripolar grid as one of these? Maybe there aren't any parameters 
> to be recorded.
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from Sebastien Villaume 
> <sebastien.villa...@ecmwf.int> -
> 
> > Date: Wed, 5 Apr 2017 08:47:57 +
> > From: Sebastien Villaume <sebastien.villa...@ecmwf.int>
> > To: cf-metadata@cgd.ucar.edu
> > Subject: Re: [CF-metadata] CF compliant tripolar grid representa

Re: [CF-metadata] axis attribute

[Sebastien Villaume]

Dear Mark and Jonathan,

thank you for your comments.

@Mark:
the short answer: you can put in principle whatever you want in that variable 
because in this case it is a dummy variable only there to hold the axis 
attribute. But please read the long explanation!

the long, boring explanation:
As I understand it, the CF convention does not recognize axis as a valid object 
on its own like for "dimensions" and the various type of "variables" and the 
convention seems to make it mandatory to attach to it a variable that becomes a 
"coordinate" variable. Note that I say that it is the coordinate variable that 
is attached to the axis and not the opposite.

From a mathematical point of view, it is perfectly possible to define an axis 
without a coordinate on it (arguably it is not that useful). The common case is 
that a 1-D array defines positions on that axis (the coordinate). Then your 1-D 
data points are positioned with the help of the coordinate, itself attached to 
the axis. 

If you have one more axis, you can define a new coordinate on it. This creates 
a 2-D space. Now you have the choice on how you represent your 2-D data points:
if the dataset is totally irregular you will have a 1-D array of "n" data 
points associated with a 1-D array of "n" positions for the first dimension and 
a 1-D array of "n" positions for the second dimension. It works, it is still a 
2-D dataset stored in a long one dimensional vector.

Imagine that you realize that your dataset is not as irregular as you thought, 
it is in fact a regular grid! you identify that you only have i possible values 
of the first coordinate and j possible values for the second coordinate, you 
also notice that i*j=n. Great you can now represent your dataset with 2 
coordinates of length i and j respectively, each of them associated with 2 axes 
x and y and your data is now a 2-D array of size (i,j). you can position your 
data using the coordinates, it is mapped using the indices within each 
coordinate array. Now you have a 2-D spatial dataset sored in a 2-D array with 
2 supporting 1-D spatial coordinates stored in one dimensional vectors.

Lets say now that you take this regular grid and you distort it... your regular 
grid is gone you can no longer use i and j for partitioning! really? well no, 
nobody says that you can not slice your "n" long vectors into i*j arrays! you 
could choose whatever you want for i and j as long as i*j=n. Of course if you 
choose (2)*(n/2) or (n/2)*(2), it is a bit useless, but you can also choose 
meaningful i and j because even if your grid became irregular, it is not random 
points, it is still a grid of size i*j . This is exactly my use case! And in 
that situation your coordinates can be arranged in arrays of size i*j. What I 
need is 2 axes and 2 coordinates of dimension 2 with lengths i and j. The catch 
here is that I have 2-D arrays to store one "spatial" dimension! It is another 
case of overlapped concepts, dimension is used transparently for the dimension 
of arrays, dimension of the geometrical space, and sometimes for the size of 
one of the dimensions of an array!!

Anyway, I should be able to define my axes like this:

int x;
x:axis = "X";
x:standard_name = "x_axis" ; // no standard name exists...
x:units = "1" ; // no units, it will come with the coordinate
int y;
y:axis = "Y";
y:standard_name = "y_axis" ; // no standard name exists...
y:units = "1" ; // no units, it will come with the coordinate
float longitude(j,i);
longitude:standard_name = "longitude" ;
longitude:units = "degrees" ;
longitude:positive = "east" ;
longitude:long_name = "longitude" ;
longitude:axis_mapping = "X" ;
float latitude(j,i);
latitude:standard_name = "latitude" ;
latitude:units = "degrees" ;
latitude:positive = "north" ;
latitude:long_name = "latitude" ;
latitude:axis_mapping = "Y" ;
float sit(j, i) ;
sit:units = "m" ;
sit:standard_name = "sea_ice_thickness" ;
sit:long_name = "Ice thickness" ;
sit:coordinates = "latitude longitude" ;

several comments:
notice how one could tell on which axis the coordinate should go using for 
instance a "axis_mapping" attribute. Not a "coordinate" attribute, this one 
should be used to tell the coordinates of my data variable!
I find this approach clearer and more flexible as it can probably cater for any 
situation of axes, coordinates, etc.

But because in CF one cannot create bare axis, I follow the rules and creates:

double x(i);
x:axis = "X";
x:standard_name = "..." ; // not an axis anymore, give me a standard name
x:units = "1" ;
y:long_name = "i-index of mesh grid" ;
double y(j);
y:axis = "Y";
y:standard_name = "..." ; // not an axis anymore, give me a standard name
y:units = "1" ;
y:long_name = "j-index of mesh grid" ;

and I have the choice of what I put in those arrays since it is somehow 
artificial.

I could populate the "primary" coordinates with 1 to i and 1 to 

Re: [CF-metadata] axis attribute

[Sebastien Villaume]

Dear Jim et al,

after reading the Trac tickets and Jim's last comment I realized something: 
people are mixing and overlapping 2 different concepts, i.e. the coordinates 
system and the plotting space!!!

Very often the coordinates axes can be used as plotting axes so one tends to 
forget that they can be different. 

When both coordinates and plotting space are defined using orthogonal axes it 
is easy to map straight away lat/lon/depth with a x/y/z (provided that one map 
the units of the coordinates on the x/y/z plotting axes)!

People, like me, that understands "axis" as "coordinate axis" will always want 
to have it on something that has the following properties: 1-D, an origin, some 
units and a direction.
Others, that understands "axis" as "plotting axis", will not see a problem 
putting that attribute on a 2-D variable because what they mean is "use the 
values contained in that 2-D field to position the data variable on that 
plotting axis". It is not wrong but it is misleading!

if I take the example of my specific case, and if I carefully make the 
distinction between the coordinates system and the plotting space I would then 
have:

dimensions:
y = 292 ;
x = 362 ;
variables:
double y(y) ;
y:axis = "Y" ;
y:units = "1" ;
y:long_name = "j-index of mesh grid" ;
double x(x) ;
x:axis = "X" ;
x:units = "1" ;
x:long_name = "i-index of mesh grid" ;
float longitude(y, x) ;
longitude:standard_name = "longitude" ;
longitude:units = "degrees_east" ;
longitude:long_name = "longitude" ;
longitude:plotting_axis = "X";
float latitude(y, x) ;
latitude:standard_name = "latitude" ;
latitude:units = "degrees_north" ;
latitude:long_name = "latitude" ;
latitude:plotting_axis = "Y";
float sit(y, x) ;
sit:units = "m" ;
sit:standard_name = "sea_ice_thickness" ;
sit:long_name = "Ice thickness" ;

Here I use "axis" to label the "coordinate axes" and "plotting_axis" to tell 
what is used to space-position the content of the data variable. What the 
plotting_axis attribute tells is:

"use the content of the 2-D longitude variable to position the grid points of 
my data variable on the X plot axis"
"use the content of the 2-D latitude variable to position the grid points of my 
data variable on the Y plot axis"

Note that if it creates backward incompatibilities one could keep "axis" for 
"plotting_axis" and have a new attribute for "coordinates axis" named 
"coord_axis" (and make it optional if the plotting and coordinates axes are 
identical).

and then I still need 2 new standard names for my 1-D coordinate variables! :D

 

Dr. Sébastien Villaume 
Analyst 
ECMWF 
Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 5 April, 2017 19:10:40
Subject: Re: [CF-metadata] axis attribute

Dear Jonathan et al,

I think that the coordinates terminology widely used in the CF community is 
very misleading (at least to me, but maybe it is because I am quite new in the 
CF business and/or I see all this with fresh new eyes). 

If I define a "x" and a "y" in addition of the 2-D lat and lon, it is not x and 
y that are auxiliary coordinates, it is in fact exactly the opposite from a 
mathematical point of view: x and y will be the primary coordinates and lat and 
lon are only 2 quantities (that happens to be coordinates in a different 
coordinates system) expressed in my coordinates system. This is why coordinates 
(or "primary coordinates" if we consider that auxiliary coordinates are 
reserved for coordinates of a different coordinates system expressed in the 
primary one) have to be 1-D and anything that is 2-D or 3-D or n-D can in 
principle be expressed in terms of the primary coordinates. 

I can make an analogy with 2 coordinates systems again:  Cartesian (x,y,z) and 
spherical (r, theta and phi). In the Cartesian system, r theta and phi are 
function of x,y,z and vice versa in spherical system x, y and z are function of 
r, theta, phi.

I also find the units of latitude and longitude confusing: it looks like it was 
a way to squeeze the direction of the coordinate inside the units. I have the 
same observation for the time coordinate that has its origin in the units!
It was done correctly for z coordinate using "units" and "positive", probably 
because there are 

Re: [CF-metadata] CF compliant tripolar grid representation

[Sebastien Villaume]

Dear Jonathan,

I will try to look at Appendix F and come back with a proposal. I have a rough 
idea of what I need but I have no clue what would be the proper terms for 
those: extra attributes to describe north pole 1 and north pole 2, latitude 
separating the "regular" from the irregular region, etc.

 

Dr. Sébastien Villaume 
Analyst 
ECMWF 
Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 5 April, 2017 16:15:55
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Dear Sebastien

Apologies. I meant Appendix F (grid mappings) not D. Could you describe
your species of tripolar grid as one of these? Maybe there aren't any
parameters to be recorded.

Best wishes

Jonathan

----- Forwarded message from Sebastien Villaume <sebastien.villa...@ecmwf.int> 
-

> Date: Wed, 5 Apr 2017 08:47:57 +
> From: Sebastien Villaume <sebastien.villa...@ecmwf.int>
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
> 
> Hi all,
> 
> I could try to draft an new entry in grid_mapping or a new entry in Appendix 
> D (it will not be a dimensionless "vertical" coordinate but a dimensionless 
> "horizontal" coordinate) 
> 
> Could we agree first on what I need to define? I don't want to invest too 
> much time in defining something before everyone agree on the way forward.
> 
> thanks 
> 
>  
> 
> Dr. Sébastien Villaume 
> Analyst 
> ECMWF Shinfield Park, 
> Reading RG2 9AX, UK 
> +44 7825 521592 
> sebastien.villa...@ecmwf.int 
> 
> 
> - Original Message -
> From: "Jim Biard" <jbi...@cicsnc.org>
> To: cf-metadata@cgd.ucar.edu
> Sent: Tuesday, 4 April, 2017 21:47:36
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> 
> Hi. 
> 
> I tend to agree with Jonathan about the use of the grid_mapping variable, 
> although it would probably be necessary to provide a clear distinction 
> between this sort of information about mapping grid indices to lats and lons 
> and providing information about mapping projected coordinate axis values to 
> lats and lons. This new use is probably more appropriate for the name of the 
> variable ( grid _mapping). Having said that, the potential for confusion and 
> complication makes me wonder if a new construct isn't needed. 
> 
> The problem that I see with x/y_coordinate_index is that the indices are very 
> likely indices to lat/lon coordinates, not x/y coordinates. They function as 
> a sort of unitless, non-geographic x and y, but I think it would better to 
> avoid overloading concepts. It's also possible that these indices could be 
> indices to x and y coordinates, so it seems to me that 
> lat/lon_coordinate_index would be no better. This is what led me to the names 
> in my list that didn't use x, y, lat, or lon. They could be useful in other 
> scenarios, such as satellite swath imagery, which have axes of scan and 
> sample, so I didn't want to constrain the terms too closely to the mesh grid 
> scenario that this discussion started with. 
> 
> Grace and peace, 
> 
> Jim 
> 
> On 4/4/17 4:25 PM, Jonathan Gregory wrote: 
> 
> 
> 
> Dear Sébastien et al.
> 
> From what you say I understand that the translation of indices to coordinate
> values is rather ad-hoc, rather than being done by the same formulae for all
> sorts of tripolar grid. You could identify the grid construction, if that 
> would
> be useful, in a non-standard way in some attribute such as "comment". To
> provide a standardised description, I still think grid_mapping would be the
> right place, but evidently "tripolar" would not be a sufficient definition.
> Instead you would need different entries in Appendix D for the different sorts
> of tripolar grid in use. In these entries you could certainly give URLs to
> documentation, I think, as well as a description. The aim of putting it in
> Appendix D would be to provide a source of information about how the indices
> are related to coordinate values.
> 
> I suggested [xy]_coordinate_index because these phrases are already used in
> standard names (one of each). If we don't like them now, we ought to change 
> the
> existing names, since we should be consistent. I think the phrase "coordinate
> index" means "the index to a coordinate value&qu

Re: [CF-metadata] axis attribute

[Sebastien Villaume]

Dear Jonathan et al,

I think that the coordinates terminology widely used in the CF community is 
very misleading (at least to me, but maybe it is because I am quite new in the 
CF business and/or I see all this with fresh new eyes). 

If I define a "x" and a "y" in addition of the 2-D lat and lon, it is not x and 
y that are auxiliary coordinates, it is in fact exactly the opposite from a 
mathematical point of view: x and y will be the primary coordinates and lat and 
lon are only 2 quantities (that happens to be coordinates in a different 
coordinates system) expressed in my coordinates system. This is why coordinates 
(or "primary coordinates" if we consider that auxiliary coordinates are 
reserved for coordinates of a different coordinates system expressed in the 
primary one) have to be 1-D and anything that is 2-D or 3-D or n-D can in 
principle be expressed in terms of the primary coordinates. 

I can make an analogy with 2 coordinates systems again:  Cartesian (x,y,z) and 
spherical (r, theta and phi). In the Cartesian system, r theta and phi are 
function of x,y,z and vice versa in spherical system x, y and z are function of 
r, theta, phi.

I also find the units of latitude and longitude confusing: it looks like it was 
a way to squeeze the direction of the coordinate inside the units. I have the 
same observation for the time coordinate that has its origin in the units!
It was done correctly for z coordinate using "units" and "positive", probably 
because there are many types of z coordinates with various origin and 
directions, and no real consensus. I note however that often the origin is not 
always clearly defined.
I would have kept "units=degrees" for both latitude and longitude and then 
attached a "positive=north" for latitude and "positive=east" for longitude... 
Then the origins are usually always standard (Greenwich meridian and equator) 
so I can understand that those can be omitted. For Time, I also understand that 
the direction of the time can also be omitted, the time flowing in the other 
direction is not directly useful... well, it is useful in relativistic quantum 
theory: https://en.wikipedia.org/wiki/T-symmetry


 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jonathan Gregory" <j.m.greg...@reading.ac.uk>
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 5 April, 2017 17:12:09
Subject: Re: [CF-metadata] axis attribute

Dear Karl, Sebastien, Jim

In ticket 8 I proposed explicitly to disallow the axis attribute for auxiliary
coordinate variables, restricting it to 1D coordinate variables. This was
agreed and implemented in an early version of CF. However in ticket 62 this
decision was revised. That ticket was begun by Karl, who was initially
concerned with scalar coordinate variables. However in the end the majority
agreed to allow the attribute for all aux coord vars.

We could change it back, of course, in CF 1.7, if a new proposal was made and
agreed quickly. Please could you have a look at ticket 62 to review the
earlier decision?

Best wishes

Jonathan

- Forwarded message from Sebastien Villaume <sebastien.villa...@ecmwf.int> 
-

> Date: Wed, 5 Apr 2017 08:36:29 +
> From: Sebastien Villaume <sebastien.villa...@ecmwf.int>
> To: Jim Biard <jbi...@cicsnc.org>
> CC: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] axis attribute
> X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
> 
> Hi,
> 
> I am also against assigning an "axis" attribute to a 2-D variables. 
> 
> From a mathematical point of view an axis is one dimension, has an origin, a 
> reference unit and a direction. For instance a 3D Cartesian coordinates 
> system has three dimensions defined by 3 axes, each axis is defined by a unit 
> vector (reference unit and direction) and an origin (it happens that they all 
> share the same origin but it is not a requirement in principle). A spherical 
> coordinate system has also 3 dimensions, defined by 1 axis and 2 angles, the 
> axis is defined like in Cartesian coordinates, the 2 angles are defined by an 
> origin (0deg), a reference unit (1/360 of a circle) and a direction ( 
> increasing degrees is anti clockwise).
> 
> Clearly 2-D latitude and longitude do not fulfil this. In my case both are 
> simply variables in a 2D space that needs to be defined somehow. This is 
> exactly why I am trying to define 2 "supporting" 1-D variables with the clear 
> intention to put an axis attribute on them. I could name this 2 supporting 
> variables x and y , or i and j or whatever. 
> 
> Is it acceptable to put an "axis = x/y" 

Re: [CF-metadata] CF compliant tripolar grid representation

[Sebastien Villaume]

Hi David,

yes the purpose of having index coordinates variables is purely to identify 
spatial dimensions in this case.

My actual lat and lon are both 2-D, with dimensions (291,360). It could have 
been described as one long 1-D vector of dimension 291*360=104760. 

But why it has not been done this way?
first of all because you will confuse many software if you have in your files:  

dimensions :
 d = 104760 ;
variables :
float lat(d);
   ...

float lon(d);
   ...

float sea_surface_temp(d);
   ...

secondly, these two dimensions have a meaning! does 360 for the "x" dimension 
sounds familiar? yep, the grid is a 1deg longitude grid but this is only true 
for the part of the tripolar grid that follows the regular lat/lon. The 
"irregular" part will not follow this but it will still have the same number of 
i points for a given index of the other dimension. This can be seen on this 
projection:

http://sosie.sourceforge.net/sosie_files/fig_irregular.png

but keep in mind that if I was projecting the same grid but taking the north 
pole as origin, the previously "irregular" part would look like "regular" and 
vice versa (actually not exactly regular because the two extra poles and the 
traditional north pole are not aligned which creates small distortions).

Anyway, I don't see a major issue having index coordinates defined to support 
the dimensions? Is it because the units for those are in fact "1"? Is it 
because those are not really what we usually call an "axis"? 

Maybe something else is more appropriate than "axis", maybe the attribute that 
we use to label a dimension should be extended : not only "axis" but also 
"angle", "index", etc. The CF requirement would be that you have no more than 3 
spatial dimensions to describe a parameter: nr axes + nr angles + nr indices <= 
3 

cartesian, curvilinear, etc.: 3 axes (x, y, z)
spherical : 1 axis (r) + 2 angles (theta, phi)
my case : 2 indices (i, j) + 1 axis (z or why not k)

if you think about it, some of the popular z axes are not really z axes and 
could be classified as "index k" (pressure levels, isotherms, etc...): these 
are simply a different way (than traditional axis with distance units) to 
define an origin (0 Pa, 0Kelvin, etc.), some units (Pa, K, et.) and direction 
(positive/negative) for a specific dimension... Geopotential height is 
equivalent to height but with a different choice of origin and the same units 
(meters).

what is making these "z" axis acceptable but not indices?

Regarding sub-regions, you would not extract the sub-regions based on the 
indices directly but using the lat and lon built on top.


 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 
____

- Original Message -
From: "David Hassell" <david.hass...@ncas.ac.uk>
To: "Sebastien Villaume" <sebastien.villa...@ecmwf.int>
Cc: "CF Metadata" <cf-metadata@cgd.ucar.edu>
Sent: Wednesday, 5 April, 2017 11:52:49
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Hello,

I may not be grasping everything here, but it seems to me that the purpose
of having two index coordinate variables is purely to be able to identify
the *dimensions* as X and Y - is that right?

If so, storing a coordinate variable with integer positions seems
unsatisfactory - what do the contained integer numbers actually mean? What
happens when you extract a sub-region (as Mark pointed out)? I think the
parallel with the magnitude_of_derivative_of_position_wrt_x_coordinate_index
standard name could be a bit misleading, as this is a derivative, so the
absolute values of any x-indices is not important.

Thanks for you patience!

David

On 5 April 2017 at 09:47, Sebastien Villaume <sebastien.villa...@ecmwf.int>
wrote:

> Hi all,
>
> I could try to draft an new entry in grid_mapping or a new entry in
> Appendix D (it will not be a dimensionless "vertical" coordinate but a
> dimensionless "horizontal" coordinate)
>
> Could we agree first on what I need to define? I don't want to invest too
> much time in defining something before everyone agree on the way forward.
>
> thanks
>
> 
>
> Dr. Sébastien Villaume
> Analyst
> ECMWF Shinfield Park,
> Reading RG2 9AX, UK
> +44 7825 521592
> sebastien.villa...@ecmwf.int
> 
>
> - Original Message -
> From: "Jim Biard" <jbi...@cicsnc.org>
> To: cf-metadata@cgd.ucar.edu
> Sent: Tuesday, 4 April, 2017 21:47:36
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>
> Hi.
>
> I tend 

Re: [CF-metadata] New standard names for NEMO ocean model output

[Sebastien Villaume]

Dear Alison et al,

we are happy with your suggestions/modifications. 

I also understand from your comments to 
integral_of_sea_water_practical_salinity_wrt_depth that my proposal to rename 
integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat_content 
for consistency is no longer required.


Regarding Jonathan comments, I think we (Eric, Kevin, myself) are fine with 
"thickness", "thickness_change", "height" or "height_change" for the steric, 
halosteric and thermosteric contributions as long as it is consistent for the 
three standard names and other related names.

In the future, we may want to produce the steric, halosteric and thermosteric 
contributions of each water cell of the column, not only for the whole water 
column. The definitions of the present standard names and the possibility to 
derive new standard names for this future situation need to be taken into 
account.

one more question: what is the standard name corresponding to 
sea_water_mass_per_unit_area_expressed_as_thickness (at 0degC, 35psu) + 
ocean_steric_thickness? i.e the total thickness of the water column? it is not 
clear to me if it exists or if we should use 
sea_water_mass_per_unit_area_expressed_as_thickness and point to an auxiliary 
variable sea_water_density at XdegC and Ypsu...

thanks, 
Sebastien

 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jonathan Gregory" 
To: cf-metadata@cgd.ucar.edu
Sent: Tuesday, 4 April, 2017 21:13:08
Subject: Re: [CF-metadata] New standard names for NEMO ocean model output

Dear Alison

Thank you for your careful and sensible analysis, as always. I agree with all
your proposals except that I'm sorry to say I'm not happy about the steric
height yet. I don't seek to insist on what I suggested before, but I don't
think the proposal so far matches scientific terminology as far as I'm aware.

> 3. ocean_steric_thickness (m)
> 4. ocean_halosteric_thickness (m)
> 5. ocean_thermosteric_thickness (m)

I understand these to mean the *change* in the thickness of the water column
caused by change to sea water density, due to change in T and S. That's what
your definitions indicate. If it's a change in thickness, it's confusing to
call it a thickness, I would say. People often refer to quantities of "steric/
halosteric/thermosteric sea level change", which I think are the same as what
we're talking about here. The change in thickness of the water column (the
vertical distance from the sea floor to the sea surface) is of course the same
thing as local sea level change.

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

Re: [CF-metadata] CF compliant tripolar grid representation

[Sebastien Villaume]

Hi all,

I could try to draft an new entry in grid_mapping or a new entry in Appendix D 
(it will not be a dimensionless "vertical" coordinate but a dimensionless 
"horizontal" coordinate) 

Could we agree first on what I need to define? I don't want to invest too much 
time in defining something before everyone agree on the way forward.

thanks 

 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jim Biard" <jbi...@cicsnc.org>
To: cf-metadata@cgd.ucar.edu
Sent: Tuesday, 4 April, 2017 21:47:36
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Hi. 

I tend to agree with Jonathan about the use of the grid_mapping variable, 
although it would probably be necessary to provide a clear distinction between 
this sort of information about mapping grid indices to lats and lons and 
providing information about mapping projected coordinate axis values to lats 
and lons. This new use is probably more appropriate for the name of the 
variable ( grid _mapping). Having said that, the potential for confusion and 
complication makes me wonder if a new construct isn't needed. 

The problem that I see with x/y_coordinate_index is that the indices are very 
likely indices to lat/lon coordinates, not x/y coordinates. They function as a 
sort of unitless, non-geographic x and y, but I think it would better to avoid 
overloading concepts. It's also possible that these indices could be indices to 
x and y coordinates, so it seems to me that lat/lon_coordinate_index would be 
no better. This is what led me to the names in my list that didn't use x, y, 
lat, or lon. They could be useful in other scenarios, such as satellite swath 
imagery, which have axes of scan and sample, so I didn't want to constrain the 
terms too closely to the mesh grid scenario that this discussion started with. 

Grace and peace, 

Jim 

On 4/4/17 4:25 PM, Jonathan Gregory wrote: 



Dear Sébastien et al.

>From what you say I understand that the translation of indices to coordinate
values is rather ad-hoc, rather than being done by the same formulae for all
sorts of tripolar grid. You could identify the grid construction, if that would
be useful, in a non-standard way in some attribute such as "comment". To
provide a standardised description, I still think grid_mapping would be the
right place, but evidently "tripolar" would not be a sufficient definition.
Instead you would need different entries in Appendix D for the different sorts
of tripolar grid in use. In these entries you could certainly give URLs to
documentation, I think, as well as a description. The aim of putting it in
Appendix D would be to provide a source of information about how the indices
are related to coordinate values.

I suggested [xy]_coordinate_index because these phrases are already used in
standard names (one of each). If we don't like them now, we ought to change the
existing names, since we should be consistent. I think the phrase "coordinate
index" means "the index to a coordinate value". Just "index" would be less
informative, I feel.

Best wishes

Jonathan


- Forwarded message from Sebastien Villaume <sebastien.villa...@ecmwf.int> 
- 



Date: Mon, 3 Apr 2017 13:56:40 +
From: Sebastien Villaume <sebastien.villa...@ecmwf.int> To: 
cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF compliant tripolar grid 
representation
X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)


Hi Mark,

I agree that we need to find the best way to describe these grids (with the 
appropriate controlled metadata) and not necessarily use an existing concept 
(crs, grid_mapping) if it does not fit the purpose and generates confusion. 

These tripolar grids are tricky and I guess this is why there is no standard 
systematic way to describe them.

Reading more on it, I realized that some of them are not always "regular grids" 
(by regular I mean monotonic increase of lat and lon when increasing i and j 
indices): it seems that some NEMO configurations reuse some of the i and j 
indices that are over land (large parts of Asia and Africa) and relocate them 
over specific water regions to locally increase the grid resolution! 

This can be seen here: 
http://www.nemo-ocean.eu/content/download/7538/40914/file/meshmask_grid.pdf 
Some of these grids do not have a simple analytical description since it is a 
composite of several local descriptions. How can I then properly 
reference/identify them? using an attribute like "model_grid_mapping" or 
"model_mesh_mapping" or simply "mesh_mapping" instead of "grid_mapping" and 
points to an URN/URI?

AMy main issue is that I can not derive directly from the metadata th

Re: [CF-metadata] axis attribute

[Sebastien Villaume]

Hi,

I am also against assigning an "axis" attribute to a 2-D variables. 

>From a mathematical point of view an axis is one dimension, has an origin, a 
>reference unit and a direction. For instance a 3D Cartesian coordinates system 
>has three dimensions defined by 3 axes, each axis is defined by a unit vector 
>(reference unit and direction) and an origin (it happens that they all share 
>the same origin but it is not a requirement in principle). A spherical 
>coordinate system has also 3 dimensions, defined by 1 axis and 2 angles, the 
>axis is defined like in Cartesian coordinates, the 2 angles are defined by an 
>origin (0deg), a reference unit (1/360 of a circle) and a direction ( 
>increasing degrees is anti clockwise).

Clearly 2-D latitude and longitude do not fulfil this. In my case both are 
simply variables in a 2D space that needs to be defined somehow. This is 
exactly why I am trying to define 2 "supporting" 1-D variables with the clear 
intention to put an axis attribute on them. I could name this 2 supporting 
variables x and y , or i and j or whatever. 

Is it acceptable to put an "axis = x/y" on variables with standard names 
containing i/j? would it be acceptable to put axis = i/j instead? 

More generally when you have a dataset in a different coordinates system, i.e. 
spherical coordinates, do you put axis x/y/z on r, theta, phi? if you have a 
dataset in a grid point space: i/j/k? of in a lattice space (admittedly with 
limited usage for earth science)?  Would it be more logical to have different 
type of variable attributes for different type of dimensions? like "axis", 
"angle", etc.

This is a more general discussion for the CF convention experts, what I only 
need is two standard names to describe my lat/lon supporting axes!

 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jim Biard" 
To: cf-metadata@cgd.ucar.edu
Sent: Tuesday, 4 April, 2017 23:43:58
Subject: Re: [CF-metadata] axis attribute

Karl, 

Don't allow the attribute on 2D variables. :) I feel like it's a pretty far 
stretch to get to your 2D example. 


Jim 

On 4/4/17 6:41 PM, Karl Taylor wrote: 


Hi all, 
I don't think the issue of 2-d auxiliary coordinates entered the discussion 
leading to their allowance by CF 1.6 (but I only quickly reviewed the 
discussion). I think that allowing the axis attribute to be attached to an 
auxiliary coordinate that is 1-d can be useful (e.g., when a balloon records 
temperature as a function of time and we want to record its lat and lon 
positions as a function of time; one could conceivably want to plot the 
temperature as a function of latitude and/or longitude, with one or the other 
of them providing the positions along a coordinate axis). 

I agree that saying lat(x,y) is a "y axis" seems rather odd, but if you 
consider each x,y pair to define an index, then it might be tolerable to say 
they each could be regarded as parametric axes defined as a function of an 
index. 

In both cases, of course, the axis values may not be monotonic, so they 
wouldn't be considered coordinates axes themselves. 

It's really not a pretty situation. Not sure what can be done about it. 

best regards, 
Karl 


On 4/4/17 1:49 PM, Jim Biard wrote: 




Jonathan, 

But was the axis attribute intended for use on 2D auxiliary coordinate 
variables? Perhaps that was before my time, but I don't recall seeing any 
discussion where that use was advocated. 

Jim 

On 4/4/17 4:30 PM, Jonathan Gregory wrote: 



Dear David and Jim

Before CF 1.6, the axis attribute was allowed only for (Unidata) coordinate
variables (i.e. the 1D ones whose name equals their dimension name). In CF 1.6
it was generalised to be allowed for auxiliary coordinate variables, as
described in the preamble of sect 5. I wasn't really in favour of this change,
but the majority was.

Best wishes

Jonathan

- Forwarded message from Jim Biard  - 



Date: Fri, 31 Mar 2017 12:44:11 -0400
From: Jim Biard  CC: CF Metadata  
Subject: Re: [CF-metadata] CF compliant tripolar grid representation
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
Gecko/20100101 Thunderbird/45.8.0

David,

Yes. I think the wording could stand to be clearer. What I wonder is
what use is there for identifying a 2D grid of latitude values as
being an axis? I do a lot of satellite swath imagery and have worked
with polar stereographic data, and latitude is not an axis of my
measurement variable grid in either case.

I think part of the confusion arises from a somewhat unclear
definition of coordinate. I tend to use the phrase "true coordinate"
for one that is1-D, has a variable name equal to its dimension name,
is monotonic, has no fill values, etc, versus "auxiliary 

Re: [CF-metadata] CF compliant tripolar grid representation

[Sebastien Villaume]

l don't like mixing these terms) and 
projection coordinates or geographic coordinates 

Sebastien states: 
I have checked both IPSL and CNRM CMIP5 datasets. It is indeed NEMO datasets 
and it is probably a 
ORCA tripolar grid in both cases. I write "probably" because it is not clear 
and conclusive 
without plotting the datasets: lat and lon are 2D fields, the datasets define 2 
extra 1D coordinates "i" and "j" 
to be used as mesh indices (but without a proper standard name). 
The datasets also have bounds for lat and lon, defined as "lat_vertices" and 
"lon_vertices" which I think 
is one solution to describe the tripolar grid. I would prefer something more 
standardized and documented so 
that one can quickly identify from the metadata that it is a tripolar grid 
(defining the resolution, 
where are the poles, how it is derived, etc.) 

I appreciate the desire to have a standardised approach to defining such a 
model grid. I would not advocate trying to use grid mapping variables 
and relationships for this, I think this could do more harm than good. 
I don't have a better suggestion to hand, I'm sad to say. 

I am not raising principled objections to this conversation or the direction of 
travel; I am raising waryness and caution about introducing further confusion 
or implying stronger relationships than can be provided. 

all the best 
mark 


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org] 
Sent: 31 March 2017 23:26 
To: cf-metadata@cgd.ucar.edu 
Subject: Re: [CF-metadata] CF compliant tripolar grid representation 



Hi. 

I like the more generic x/y_coordinate_index name, but I'm wondering if x and y 
have too strong an association to projected coordinate systems. I also like 
u/v, but that may be too strongly associated for some people with vector 
components (wind, for example). What do the rest of you think? Here are some 
names that come to mind. Feel free to suggest something better! 


* mesh_grid_i_index, mesh_grid_j_index 
* grid_i_index, grid_j_index 
* grid_i_coordinate, grid_j_coordinate 
* x_coordinate_index, y_coordinate_index 
* index_x_coordinate, index_y_coordinate (this ordering matches the 
projection_x/y_coordinate naming) 
* u_coordinate, v_coordinate 
* i_coordinate, j_coordinate 
* grid_row_coordinate, grid_column_coordinate 
* row_coordinate, column_coordinate 


The more I look at these, the more I like the last two. 


As for a definitions, how about something like this variation on the ones for 
the projection_x/y_coordinate? 




column_coordinate: "column" indicates the fastest-changing dimension of a 
two-dimensional grid, when this is not associated with a spatial coordinate 
dimension such as longitude or projected X, positive with increasing column. 
The column coordinate, possibly in conjunction with the row coordinate, serves 
as a parametric driver mapping abstract grid positions to spatial coordinates 
such as latitude and longitude. 


row_coordinate: "row" indicates the the slowest-changing dimension of a 
2-dimensional grid, when this is not associated with a spatial coordinate 
dimension such as latitude or projected Y, positive with increasing row. The 
row and column coordinates serve as a parametric driver mapping abstract grid 
positions to spatial coordinates such as latitude and longitude. Grace and 
peace, 

Jim 

On 3/31/17 5:37 PM, Sebastien Villaume wrote: 



Hi all,

I have checked both IPSL and CNRM CMIP5 datasets. It is indeed NEMO datasets 
and it is probably a ORCA tripolar grid in both cases. I write "probably" 
because it is not clear and conclusive without plotting the datasets: lat and 
lon are 2D fields, the datasets define 2 extra 1D coordinates "i" and "j" to be 
used as mesh indices (but without a proper standard name). The datasets also 
have bounds for lat and lon, defined as "lat_vertices" and "lon_vertices" which 
I think is one solution to describe the tripolar grid. I would prefer something 
more standardized and documented so that one can quickly identify from the 
metadata that it is a tripolar grid (defining the resolution, where are the 
poles, how it is derived, etc.)

I would like to propose for addition standard names to support the mesh 
indices/coordinates: 

"mesh_grid_i/j_index" suggested by Jim 
or
"x/y_coordinate_index" suggested by Jonathan

I let the experts in standard names decide which pair suits best the present 
case.

Regarding tripolar grids characteristics, I did some research and came to the 
conclusion that "Murray tripolar grids" are not identical to "ORCA/NEMO 
tripolar grids". This is true even without considering characteristics like the 
grid resolution, the location of the poles or where the latitude boundary is 
placed between the modified a

Re: [CF-metadata] CF compliant tripolar grid representation

[Sebastien Villaume]

Dear Jim and Karl,

thank you for your quick answers.

Karl, it seems that the tripolar grid mentioned in the link you sent is defined 
in this paper:

Murray, R. J., 1996: Explicit generation of orthogonal grids for ocean models. 
Journal of Computational Physics, 126, 251-273

which is cited by the paper from the NEMO group (Madec et al) that I mentioned 
in my original question. I need to check carefully if the definition is really 
identical or if they simply got inspired by the "Murray tripolar grid" and 
derived something similar but not exactly identical. In that case, it means 
there are several types of tripolar grids... 
One first difference I can directly identify is that the separation between the 
regular lat-lon and the modified part is not at the same latitude: 65N for 
Murray tripolar grid and 40N for the NEMO one.
In any case, if someone already defined tripolar grids in a CF compliant way, I 
can definitely start from there.

Regarding X and Y, I thought that "projection_[x|y]_coordinate" were used in 
the case of a projection on an Euclidian plane since the units of both standard 
names are "meters". 
What I am really after is more what you are suggesting later in your answer, 
i.e. mesh_grid_[i|j]_index. It feels weird to have a 2-D lat and lon as 
coordinates axis Y/X, this is why I need I would like to add those 1-D 
coordinate variables.  I also noticed the grid_latitude and grid_longitude in 
the standard_name table but it is explicitly for rotated grids.

Would it be possible to request mesh_grid_i_index and mesh_grid_j_index? 
(regardless of the feasibility of defining a proper tripolar crs)

 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 


- Original Message -
From: "Jim Biard" <jbi...@cicsnc.org>
To: cf-metadata@cgd.ucar.edu
Sent: Thursday, 30 March, 2017 17:42:01
Subject: Re: [CF-metadata] CF compliant tripolar grid representation

Sébastien, 

If I'm not mistaken, we would need to propose a new grid_mapping to be added to 
the Conventions that would define a Tripolar Coordinate Reference System, along 
with any attributes that don't currently exist that are needed to complete the 
definition. I did a search for a standard tripolar CRS in proj4 or epsg, and 
was unable to find one. Is it possible to make such a definition? 


Regarding the standard names for your X and Y coordinate variables, I think you 
could use "projection_x/y_coordinate" once a grid_mapping has been defined. Of 
course you could always leave the attribute off, since a standard_name 
attribute is not a requirement. 
If making a new grid_mapping is not feasible, you could request standard names 
along the lines of mesh_grid_i_index and mesh_grid_j_index. These standard 
names would (on reading their definitions) make it clear that the measurements 
are on a mesh grid for which there is no CRS. At least that's what comes to 
mind at the moment. 

Grace and peace, 

Jim 

On 3/30/17 11:52 AM, Sebastien Villaume wrote: 



Hello all,

I am looking for the best approach to describe in a CF compliant way the 
tripolar grids usually used in NEMO configurations.

Basically, the difference with a usual bipolar grid (north pole-south pole) is 
that the north pole is split into 2 poles moved over Canada and Russia (to have 
distortions/singularities not over the ocean). A good visual representation can 
be found here: 
http://www.geomar.de/typo3temp/pics/globe_grid2_14_b8edb639ae.png everything 
south of the green line (40degN) is identical to a regular grid, but everything 
north of it is computed using a technique described here: 

Madec, G. and M. Imbard, 1996 : A global ocean mesh to overcome the north pole 
singularity. Clim. Dyn., 12, 381–388.


The usual NEMO output of the grid looks like this:

float longitude(y, x) ;
longitude:standard_name = "longitude" ;
longitude:units = "degrees_east" ;
longitude:long_name = "longitude" ;
float latitude(y, x) ;
latitude:standard_name = "latitude" ;
latitude:units = "degrees_north" ;
latitude:long_name = "latitude" ;


Basically both latitudes and longitudes need to be specified for each grid 
point, hence lat and lon are 2D arrays. This is not a problem itself but I 
would like to give more information through maybe grid_mapping or crs so it is 
clear that the grid is tripolar. This is useful information if one want to 
project/interpolate this back to a more regular representation.

Looking at the CF conventions, I can see that grids can be fairly nicely 
documented but nothing for tripolar grids. 

Is there some documentation/guidelines on how to derive a proper 
grid_mapping/crs with valid attributes for tripolar grids? 

I would also like to

[CF-metadata] CF compliant tripolar grid representation

[Sebastien Villaume]

Hello all,

I am looking for the best approach to describe in a CF compliant way the 
tripolar grids usually used in NEMO configurations.

Basically, the difference with a usual bipolar grid (north pole-south pole) is 
that the north pole is split into 2 poles moved over Canada and Russia (to have 
distortions/singularities not over the ocean). A good visual representation can 
be found here:

http://www.geomar.de/typo3temp/pics/globe_grid2_14_b8edb639ae.png 

everything south of the green line (40degN) is identical to a regular grid, but 
everything north of it is computed using a technique described here: 

Madec, G. and M. Imbard, 1996 : A global ocean mesh to overcome the north pole 
singularity. Clim. Dyn., 12, 381–388.


The usual NEMO output of the grid looks like this:

float longitude(y, x) ;
longitude:standard_name = "longitude" ;
longitude:units = "degrees_east" ;
longitude:long_name = "longitude" ;
float latitude(y, x) ;
latitude:standard_name = "latitude" ;
latitude:units = "degrees_north" ;
latitude:long_name = "latitude" ;


Basically both latitudes and longitudes need to be specified for each grid 
point, hence lat and lon are 2D arrays. This is not a problem itself but I 
would like to give more information through maybe grid_mapping or crs so it is 
clear that the grid is tripolar. This is useful information if one want to 
project/interpolate this back to a more regular representation.

Looking at the CF conventions, I can see that grids can be fairly nicely 
documented but nothing for tripolar grids. 

Is there some documentation/guidelines on how to derive a proper 
grid_mapping/crs with valid attributes for tripolar grids? 

I would also like to add to my netcdf file a way to better describe axes:

double y(y) ;
y:units = "1" ;
y:long_name = "j-index of mesh grid" ;
y:standard_name = ??? ;
double x(x) ;
x:units = "1" ;
x:long_name = "i-index of mesh grid" ;
x:standard_name = ??? ;

what would be the standard name of these?

Thanks,

 

Dr. Sébastien Villaume 
Analyst 
ECMWF Shinfield Park, 
Reading RG2 9AX, UK 
+44 7825 521592 
sebastien.villa...@ecmwf.int 

___
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 NEMO ocean model output

[Sebastien Villaume]

Hi all,

I would like to reactivate this specific thread in order to reach an agreement 
and get these standard names accepted and published in the next version of the 
table.

I went through the whole thread and updated each proposed standard name 
according to the comments/suggestions made (please see below). 

I have also added two new standard names: one to deprecate an existing standard 
name that is not following the usual naming convention 
(integral_of_sea_water_potential_temperature_wrt_depth_in_ocean_layer_expressed_as_heat_content)
 and one derived from it to cover the whole sea water column case. It is the 
last two of the list below.

Since I am not an ocean model expert and in particular not a NEMO expert/user, 
I am welcoming any relevant comments/suggestions, especially from the NEMO 
community.

thanks


NEMO variable: 
somixhgt
standard name: 
ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity_threshold
(originally proposed as ocean_turbocline_depth)
units: 
m 

description: 
The mixed layer thickness is estimated using the depth at which the vertical 
eddy diffusivity coefficient (resulting from the vertical physics alone) fall 
below a given value defined locally. A coordinate variable or scalar coordinate 
variable with standard name ocean_vertical_diffusivity can be specified to 
indicate the value of the coefficient that was used to calculate the mixed 
layer thickness.

other action to take (suggested by Jonathan Gregory): 
rename the existing the standard name  
ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity which refers 
to the level at which the diffusivity differs from its surface value by a 
certain amount, as 
ocean_mixed_layer_thickness_defined_by_vertical_tracer_diffusivity_deficit



NEMO variable:
sobpheig
standard name: 
sea_water_mass_per_unit_area_expressed_as_thickness
(originally proposed as bottom_pressure_equivalent_height)
units:
m 

description: 
This is the mass of the water column expressed as a thickness using a given 
reference density:

sea_water_mass_per_unit_area_expressed_as_thickness = ( 
sea_water_mass_per_unit_area / sea_water_density )

The thickness is the extent of a vertical column or layer. The sea water 
density used to do the conversion is assumed to be the density of water of 
standard temperature T=0°C and practical salinity S=35.0. Otherwise it should 
be provided as an auxiliary scalar using the standard name sea_water_density.



NEMO variable:
sostheig
standard name:
ocean_steric_thickness
(originally proposed as ocean_steric_height)
units:
m 

description: 
The ocean steric thickness measures the height by which a column of water with 
standard temperature T=0°C and salinity S=35.0 expands if its temperature and 
salinity are changed to the observed values.



NEMO variable:
vosthsal
standard name: 
ocean_halosteric_thickness
(originally proposed as ocean_steric_thickness_due_to_salinity)
units:
m 

description: 
The quantity with standard name ocean_halosteric_thickness is a measure of the 
change in thickness that would be undergone by a column of water of standard 
temperature T=0°C and practical salinity S=35.0 if its salinity were changed to 
the locally observed value. Thickness is the extent of a vertical column or 
layer.


NEMO variable:
vosthtem
standard name: 
ocean_thermosteric_thickness
(originally proposed as ocean_steric_thickness_due_to_temperature)
units:
m 

description: 
The quantity with standard name ocean_thermosteric_thickness is a measure of 
the change in thickness that would be undergone by a column of water of 
standard temperature T=0°C and practical salinity S=35.0 if its temperature 
were changed to the locally observed value. Thickness is the extent of a 
vertical column or layer.


NEMO variable:
vottrdmp
standard name: 
ratio_of_sea_water_potential_temperature_anomaly_to_relaxation_timescale
(originally proposed as temperature_profile_anomaly_correction)
units:
K s-1

description: 
This term is estimated as the deviation of the local sea water potential 
temperature from an ocean model with respect to an observation-based 
climatology (eg World Ocean Database) weighted by a user-specified relaxation 
coefficient in s-1 (1/(relaxation timescale)).


NEMO variable:
vostrdmp
standard name: 
ratio_of_sea_water_practical_salinity_anomaly_to_relaxation_timescale
(originally proposed as practical_salinity_profile_anomaly_correction)
units:
s-1

description: 
This term is estimated as the deviation of the local sea water practical 
salinity from an ocean model with respect to an observation-based climatology 
(eg World Ocean Database) weighted by a user-specified relaxation coefficient 
in s-1 (1/(relaxation timescale)).


NEMO variables:
sosal300, sosal700
standard name: