face to sea floor"
bounds by not specifying the bounds!
thanks a lot!
/Sébastien
- Original Message -
> From: "Alison Pamment - UKRI STFC"
> To: cf-metadata@cgd.ucar.edu, "Sebastien Villaume
> (sebastien.villa...@ecmwf.int)"
> Sent: F
ddressed in a general context because the case-by-case approach always
leads to specific solutions...
/Sébastien
- Original Message -
> From: "Martin Juckes - UKRI STFC"
> To: "Karl Taylor" , "Sebastien Villaume"
>
>
controlled mechanism yet to define.
/Sébastien
----- Original Message -
> From: "Karl Taylor"
> To: "Sebastien Villaume" , "Lowry, Roy K."
> , "Jonathan Gregory"
>
> Cc: cf-metadata@cgd.ucar.edu
> Sent: Friday, 13 April, 201
urpose. Otherwise you could set a very large lower
>> depth boundary with the understanding that integrating below the sea floor
>> added nothing, but that's a bit ugly.
>>
>> Best wishes
>>
>> Jonathan
>>
>> - Forwarded message from Sebastien Vi
; 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
>
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: i
ove 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: "Jona
cate 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_w
wrt_sea_surface
sigma_t_difference_wrt_sea_surface
any quick suggestions are very welcome!
thanks
/Sébastien
- Original Message -
> From: "Sebastien Villaume"
> To: "CF Metadata"
> Sent: Wednesday, 4 April, 2018 14:04:42
> Subject: [CF-metadata] how to u
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 d
es. 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
Jo
me 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
-
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 ;
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_per
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"
To: "sebastien villaume"
Cc: "Jonath
> 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,
> >
uot;. I assume it was intended that way but
"_height" got somehow truncated.
Best wishes,
Sébastien
- Original Message -
From: "alison pamment"
To: "sebastien villaume"
Cc: cf-metadata@cgd.ucar.edu, "Jonathan Gregory"
Sent: Thursday, 8 June, 201
these standard names in the coming weeks.
thanks,
/Sébastien
- Original Message -
From: "Sebastien Villaume"
To: "Lowry, Roy K."
Cc: cf-metadata@cgd.ucar.edu, "Jonathan Gregory"
Sent: Tuesday, 30 May, 2017 09:42:54
Subject: Re: [CF-metadata] New standard nam
e can using them.
thanks,
/Sébastien
- Original Message -
From: "Lowry, Roy K."
To: "Jonathan Gregory" , "Sebastien Villaume"
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,
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
ways 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
-
> Date: Tue, 18
titude: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 variable
n "obvious" concept, but there is an
ambiguity
about whether it corresponds to a dimension of a data variable, or a
physical
variable (not necessarily spatiotemporal) which could be an independent
variable on which the data depends. Latitude might be an axis in the second
sense even if
ge_in_sea_surface_height" and
"thermosteric_change_in_sea_surface_height" are enough.
Best wishes,
/Sébastien
- Original Message -
From: "alison pamment"
To: "sebastien villaume" ,
cf-metadata@cgd.ucar.edu
Sent: Thursday, 13 April, 2017 17:41:38
Subjec
nk 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"
To: "Sebastien Villaume"
Cc: "CF Metadata" , "Jonathan Gregory"
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 paramet
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
reates 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 na
ers to be recorded.
Best wishes
Jonathan
- Forwarded message from Sebastien Villaume
-
> Date: Wed, 5 Apr 2017 08:47:57 +0000
> From: Sebastien Villaume
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
> X-Mailer: Zimb
inate 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
-
e 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
- Or
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 lon
se 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 le
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
de.
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 map
. 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
>>
ents
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 NEM
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
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 (plea
39 matches
Mail list logo
