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

[James Orr]

The IPSL and CNRM cimate models that participated in CMIP5 both used the NEMO 
model (ORCA2 and ORCA1 configurations) with tripolar grids.  Both provided 
output the was CF compliant.


James

On Thu, 30 Mar 2017, Karl Taylor wrote:


Hi Sebastien,

More than one group stored output on a tripolar grid in CMIP5.  I'm pretty 
sure they did it in a CF-conforming way.  I know at least some of the GFDL 
model output was reported on a tripolar grid, as described at 
http://nomads.gfdl.noaa.gov/CM2.X/oceangrid.html (or search on "tripolar 
grid" for additional links).  You could look to their example, and see if you 
think it is done correctly.


I don't think extensions or modifications to CF are needed for tripolar 
grids.


best regards,
Karl

On 3/30/17 9:42 AM, Jim Biard wrote:


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 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


--
CICS-NC  Visit us on
Facebook  *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC 
North Carolina State University 
NOAA National Centers for Environmental Information 
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org 
o: +1 828 271 4900

/Connect with us on Facebook for climate 
 and ocean and geophysics 
 information, and follow us 

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" 
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 add to my netcdf file a way to better describe axes:

double y(y) ;
y:units = "1" ;
y:long_name 

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

[Jim Biard]

Karl,

I think Sébastien raises some valid questions regarding appropriate 
standard names and best form for specifying that the coordinate system 
is a tripolar grid.


The projection_x_coordinate and projection_y_coordinate definitions 
state " The relationship between the projection coordinates andlatitude 
andlongitude 
is described by thegrid_mapping 
." If you can't specify a 
grid_mapping, then these standard names don't really apply, do they? And 
perhaps, if there's no way to construct a CRS for a tripolar grid, these 
standard names shouldn't be used.


I agree that you can specify all the parts (2D lat and lon grids, 1D i 
and j "coordinates") without using a standard name on the 1D coordinate 
variables and without ever specifying a grid_mapping, and that such an 
arrangement is CF-compliant. But the connection of the 1D coordinate 
variables with the lat and lon grids is then left to information 
provided in comment attributes or non-standard attributes created by the 
authors. To put this grid on the same footing as, say, a Lambert 
Conformal Conic CRS, don't you need to have a grid_mapping or some other 
equivalent standard mechanism?


Grace and peace,

Jim

On 3/30/17 4:27 PM, Karl Taylor wrote:

Hi Sebastien,

More than one group stored output on a tripolar grid in CMIP5. I'm 
pretty sure they did it in a CF-conforming way.  I know at least some 
of the GFDL model output was reported on a tripolar grid, as described 
at http://nomads.gfdl.noaa.gov/CM2.X/oceangrid.html (or search on 
"tripolar grid" for additional links).  You could look to their 
example, and see if you think it is done correctly.


I don't think extensions or modifications to CF are needed for 
tripolar grids.


best regards,
Karl

On 3/30/17 9:42 AM, Jim Biard wrote:


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 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 

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

[Karl Taylor]

Hi Sebastien,

More than one group stored output on a tripolar grid in CMIP5.  I'm 
pretty sure they did it in a CF-conforming way.  I know at least some of 
the GFDL model output was reported on a tripolar grid, as described at 
http://nomads.gfdl.noaa.gov/CM2.X/oceangrid.html (or search on "tripolar 
grid" for additional links).  You could look to their example, and see 
if you think it is done correctly.


I don't think extensions or modifications to CF are needed for tripolar 
grids.


best regards,
Karl

On 3/30/17 9:42 AM, Jim Biard wrote:


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 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


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


/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org 
o: +1 828 271 4900

/Connect with us on Facebook for climate 
 and ocean and geophysics 
 information, and follow us 
on Twitter at @NOAANCEIclimate  
and @NOAANCEIocngeo . /





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

[CF-metadata] Standard Names Representing Measurements not due to some process

[Andrew Barna]

Hello,

I was having a discussion regarding rosette mounted transmissometers, 
specifically the Wetlabs C-Star.

The most obvious standard name for the measurement appears to be:
volume_beam_attenuation_coefficient_of_radiative_flux_in_sea_water

However, because of the way the instrument is calibrated, the attenuation due 
to the (pure) water itself is not a constituent of the reported attenuation 
coefficient.
The resulting modification would appear to be:
volume_beam_attenuation_coefficient_of_radiative_flux_in_sea_water_not_due_to_water
 (or some variant, _not_due_to_pure_water)

Is there a better way to account for reporting parameters which are the result 
of all processes except for some known process?

Thanks,
-Barna
___
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

[Jim Biard]

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 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


--
CICS-NC  Visit us on
Facebook  *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC 
North Carolina State University 
NOAA National Centers for Environmental Information 
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org 
o: +1 828 271 4900

/Connect with us on Facebook for climate 
 and ocean and geophysics 
 information, and follow us 
on Twitter at @NOAANCEIclimate  and 
@NOAANCEIocngeo . /



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

[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] WG: proposal for two new standard_names and an additional chemical species

[Lowry, Roy K.]

Hi Alison,


The 'in equilibrium' in pCO2 definition refers to the air in the analytical 
equipment and so has nothing to do with air-sea interface equilibrium. pCO2 is 
measured by using something like a shower-head or a column full of marbles to 
equilibrate the water sample with a stream of air that is then passed into a 
gas analyser. Consequently, the Standard Name makes no statement about the 
depth from which the water was taken. The same would apply to methane.


Whilst it is usual to measure pCO2 in surface waters, I have come across 
measurements on water bottle samples collected at depth.


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 
hours a week and can only guarantee e-mail response on Wednesdays, my day in 
the office. All vocabulary queries should be sent to enquir...@bodc.ac.uk. 
Please also use this e-mail if your requirement is urgent.



From: CF-metadata  on behalf of 
alison.pamm...@stfc.ac.uk 
Sent: 29 March 2017 12:34
To: beate.ge...@hzg.de; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] WG: proposal for two new standard_names and an 
additional chemical species

Dear Beate,

Thank you for your proposals.

As you have pointed out, we have an existing name 
'surface_partial_pressure_of_carbon_dioxide_in_sea_water'. I completely agree 
that we should remove the sentence
' "Water" means water in all phases, including frozen i.e. ice and snow' from 
the definition as it really isn't necessary for this name. I will make that 
change in the April update to the standard name table.

The definition of the existing name includes the sentence 'The partial pressure 
of a dissolved gas in sea water is the partial pressure in air with which it 
would be in equilibrium' so clearly this is talking about equilibrium of 
partial pressures across the air-sea interface, i.e. at the surface. For the 
proposed name partial_pressure_of_carbon_dioxide_in_sea_water do you mean 
partial pressures at some arbitrary depth below the sea surface, even if these 
are not actually in physical contact with the surface itself? If so, then I 
agree we do need a new name.

For the methane name I would ask the same question. Certainly we can introduce 
a methane partial pressure name, but I'd like to understand whether it's at the 
surface or at some arbitrary depth.

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.


From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
beate.ge...@hzg.de
Sent: 20 February 2017 08:30
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] WG: proposal for two new standard_names and an 
additional chemical species

Dear all and especially the cf-metadata crew,

My colleagues and I apply for an expansion of the table of chemical species 
(http://cfconventions.org/Data/cf-standard-names/docs/guidelines.html#id2799094):
 methane.

We apply to include partial_pressure_of_methane_in_sea_water (units: Pa)
with following description:
The partial pressure of a dissolved gas in sea water is the partial pressure in 
air with which it would be in equilibrium. The partial pressure of a gaseous 
constituent of air is the pressure which it alone would exert with unchanged 
temperature and number of moles per unit volume.

The description of 'surface_partial_pressure_of_carbon_dioxide_in_sea_water' 
includes the sentence
"Water" means water in all phases, including frozen i.e. ice and snow.
which does not fit in this context – perhaps is an update possible here.

We apply to include the additional standard_name 
partial_pressure_of_carbon_dioxide_in_sea_water (units: Pa)
with the description
The partial pressure of a dissolved gas in sea water is the partial pressure in 
air with which it would be in equilibrium. The partial pressure of a gaseous 
constituent of air is the pressure which it alone would exert with unchanged 
temperature and number of moles per unit volume.

The reason for this applications is the conversion of our measurement data to 
cf-conform netCDF.

Thanks in advance for your help,
Beate Geyer

Institut für Küstenforschung

Dr. Beate Geyer
Regionale Atmosphären Modellierung

Telefon :   +49 4152 87-1871
Telefax :   +49 4152 87-41871

Helmholtz-Zentrum Geesthacht
Zentrum für Material- und Küstenforschung GmbH
Max-Planck-Straße 1 I 21502 Geesthacht I Deutschland/Germany

Geschäftsführer/Board of Management: Prof. Dr. Wolfgang Kaysser, Dipl.-Ing. 
Michael Ganß
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: 
Ministerialdirigent Dr. Herbert Zeisel
Amtsgericht Lübeck HRB 285 GE (Register Court)
Internet: 

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

[alison.pamment]

Dear Sebastien,

I have been discussing these names again off-list with the proposer Kevin Marsh 
over the last few days. I think we are making good progress and I am doing some 
more work on the definitions of the names. I will post a summary of progress on 
all these names within the next day or so. Thanks for looking at the names 
again.

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: 30 March 2017 09:08
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard names for NEMO ocean model output
> 
> 
> 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_exp
> ressed_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.
> 
> 

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: