Hi Olivier:
Thanks for the reply. I'm Happy to go with the sea_[type]_temperature
semantics for CF as you suggest and we will define the long_names according
to GHRSST-PP definitions. So we have:
1) SSTint (GHRSST-PP) ?? surface_temperature (CF) ?? Please can you remind
me of the long name and definition for this?
2) SSTskin (GHRSST-PP) ?? sea_skin_temperature (CF) ??
skin_layer_sea_surface_temperature (CF_long)
3) SSTsubskin (GHRSST-PP) ?? sea_subskin_temperature (CF) ??
subskin_layer_sea_surface_temperature (CF_long)
4) SSTdepth (GHRSST-PP) ?? sea_water_temperature (CF) with depth attribute
But we also need to agree what to do with the SSTfoundation. This is a term
that is gathering momentum in the community and is used widely today. I
understand Jonathans concerns but those concerns apply equally to the other
definitions measurements vs analysis). For a time T and location [x,y]
there will be one temperature at the base of the diurnal layer [defined as a
significant gradient] in the same way we define mixed layer depths and that
is the SSTfnd. This is the 'important' temperature and depth for most
applications concerned with data assimilation and diurnal variability
modelling. There may be multiple methods to determine this temperature but
they should return the same value for location [x,y] and time T. so, at the
risk of becoming unpopular... can I suggest the following:
5) SSTfnd (GHRSST-PP) ?? sea_foundation_temperature (CF) ??
sea_surface_temperature_at_diurnal_thermocline_base
(CF_long)
The GHRSST-PP has a Science Team meeting coming up in June this year and I'd
really like to report full acceptance of the modified proposals I put to the
CF group for GHRSST-PP data sets. IF we can agree on the SST foundation
clarifications I provided above can we move forward?
Does this now mean we are OK and have reached consensus? What happens next?
Take care and best regards
Craig
Jonathan Gregory <j.m.gregory at reading.ac.uk>
hide details 14 Feb
to cf-metadata at cgd.ucar.edu
date
14 Feb 2008 16:40
subject
[CF-metadata] CF-1.0 registration of new names for SST
mailed-by
cgd.ucar.edu Dear Craig
I would find sea_[sub]skin_temperature more obvious than
[sub]skin_sea_surface_temperature because it feels like "surface" and
"[sub]skin layer" are conflicting concepts.
No problem with the surface or the temperature with a depth coord. I don't
think CF can mandate the depth coord but obviously you can in your
applications of CF.
I am worried about the foundation temperature. I understand your wish to
abolish the rather vague SST bulk temperature, but "foundation" seems vague
to me in its own right. Alison's options
> measured/modelled at the base of the thermocline so that the values are
> intrinsically free of diurnal variation
and
> or is the diurnal variation statistically removed from the data
strike me as different things, which should not have the same name.
Statistically removing the variation could mean just calculating the daily
mean, which is indicated by cell_methods, not the standard name, or it could
mean filtering the data, which could be indicated in some other way to be
devised. You write
> Only in situ contact thermometry is able to measure SSTfnd ...
> SSTfnd will be similar to a night time minimum or pre-dawn value at
> depths of ~1-5 m, but some differences could exist. Note that SSTfnd
> does not imply a constant depth mixed layer, but rather a surface
> layer of variable depth depending on the balance between
> stratification and turbulent energy and is expected to change slowly
> over the course of a day.
That sounds rather ill-defined to me. Could you not have different names for
the results of different methods for evaluating it?
best wishes
Jonathan
Discussion:
Summary of proposal so Far (from Oliveier Laurent mail)
> *SSTint (GHRSST-PP): surface_temperature (CF)
OK as we do not use this in operations but clarification on the
interface may still be useful in a description.
> *SSTskin (GHRSST-PP):
> - sea_surface_temperature_in_skin_layer
> - skin_sea_surface_temperature
> - sea_skin_temperature?
> - sea_water_temperature with a depth attribute ?
We still propose skin_layer_sea_surface_temperature as in the
GHRSST-PP proposal.
> *SSTsubskin (GHRSST-PP):
> - sea_surface_temperature_in_subskin_layer?
> - subskin_sea_surface_temperature?
> - sea_subskin_temperature?
> - sea_water_temperature with a depth attribute ?
> (same comments as for SSTskin)
I accept subskin_sea_surface_temperature
> *SSTdepth (GHRSST-PP): sea_water_temperature (CF)
I'm happy with Alison and Nan suggestions regarding the use of
sea_water_temperature followed by a depth attribute. Without the
depth attribute the data are only of marginal use in data assimilation
systems and for blending. Many of the problems we have in the
satellite SST community today stem from the fact that depth was not
included as an essential component of the measurement. Now that some
satellite radiometers are providing more accurate and consistent
measurements of SST than can be obtained in situ (O'Carroll et al
JTECH, 2007) depth is essential!!) So to answer Alisons question
"We already have the standard name sea_water_temperature which is
defined as follows: "For the temperature of sea water at a particular
depth or layer, a data variable of sea_water_temperature with a
vertical coordinate axis should be used." Would this meet your
needs?" The answer is YES it does and we will work on this within
GHRSST-PP. but The need for the depth information needs to be
mandatory can this be done? without depth it is somewhat
meaningless...
>
> *SSTfnd (GHRSST-PP):
> - sea_surface_temperature_at_diurnal_thermocline_base
This is not correct. The main purpose of SSTfnd is to remove from the
vocabulary of
scientists the totally confusing and lazy term bulk SST which is
meaningless in the context of modern measurements, for data
assimilation and simply perpetuates confusion and erroneous
assumptions (Bit harsh, I know, but essentially true!)). To answer
Alison's question:
"Does this mean that the foundation temperature is measured/modelled
at the base of the thermocline so that the values are intrinsically
free of diurnal variation [YES], or is the diurnal variation
statistically removed from the data [it could be - especially when
blending data for statistical analyses]?" The answer is yes in both
cases. I hope that a new 'surface' and associated name can be
introduced to represent this quantity which is the quantity that most
global SST analysis systems produce today. There is a nice figure
showing what SSTfnd is at
https://www.ghrsst-pp.org/SST-Definitions.html
So I would argue for foundation_sea_surface_temperature
On 15/02/2008, olivier lauret <olauret at cls.fr> wrote:
>
> Dear Craig and all,
>
> Thanks for getting back on this topic. I have the feeling that everybody
> is agree to follow GHRSST definitions but there are only a few details to
> deal with..
> About introducing
> 1) SSTint (GHRSST-PP) ?? surface_temperature (CF)
> 2) SSTskin (GHRSST-PP) ?? skin_layer_sea_surface_temperature (CF)
> 3) SSTsubskin (GHRSST-PP) ?? subskin_sea_surface_temperature (CF)
> 4) SSTdepth (GHRSST-PP) ?? sea_water_temperature (CF)
>
> I guess everybody is OK on this. There remain only doubts on the semantics
> on 2) and 3), as Jonathan suggested to use "sea_[sub]skin_temperature". I'd
> personally prefer "sea_[sub]skin_temperature" too: CF currently proposes
> "sea_surface_temperature" and "sea_water_temperature", following this logic
> it is quite natural to introduce the quantities "sea_subskin_temperature"
> and "sea_skin_temperature", isn't it? Anyway for you Craig there is still
> the possibility to freely define "skin_layer_sea_surface_temperature" and
> "subskin_sea_surface_temperature " as the long_name attributes.
>
> 5) SSTfnd (GHRSST-PP)?? foundation_sea_surface_temperature
> I am not sure Craig received Jonathan's answer on this (hereafter, it was
> a "reply" instead of a "reply all" and maybe Craig's gmail address is not
> registered on CF mailing list)?
>
> And about John's suggestion for MMI, it's a good idea. I personally did
> not heard about an initiative going in this sense, it would be a good thing
> to have an ontology based on GHRSST definitions.
>
> Regards
>
> Olivier.
>
> -----Message d'origine-----
> De : cf-metadata-bounces at cgd.ucar.edu [mailto:
> cf-metadata-bounces at cgd.ucar.edu] De la part de Jonathan Gregory
> Envoy? : jeudi 14 f?vrier 2008 17:41
> ? : cf-metadata at cgd.ucar.edu
> Objet : [CF-metadata] CF-1.0 registration of new names for SST
>
>
> Dear Craig
>
> I would find sea_[sub]skin_temperature more obvious than
> [sub]skin_sea_surface_temperature because it feels like "surface" and
> "[sub]skin layer" are conflicting concepts.
>
> No problem with the surface or the temperature with a depth coord. I don't
> think CF can mandate the depth coord but obviously you can in your
> applications of CF.
>
> I am worried about the foundation temperature. I understand your wish to
> abolish the rather vague SST bulk temperature, but "foundation" seems
> vague
> to me in its own right. Alison's options
> > measured/modelled at the base of the thermocline so that the values are
> > intrinsically free of diurnal variation
> and
> > or is the diurnal variation statistically removed from the data
> strike me as different things, which should not have the same name.
> Statistically removing the variation could mean just calculating the daily
> mean, which is indicated by cell_methods, not the standard name, or it
> could
> mean filtering the data, which could be indicated in some other way to be
> devised. You write
>
> > Only in situ contact thermometry is able to measure SSTfnd ...
> > SSTfnd will be similar to a night time minimum or pre-dawn value at
> > depths of ~1-5 m, but some differences could exist. Note that SSTfnd
> > does not imply a constant depth mixed layer, but rather a surface
> > layer of variable depth depending on the balance between
> > stratification and turbulent energy and is expected to change slowly
> > over the course of a day.
>
> That sounds rather ill-defined to me. Could you not have different names
> for
> the results of different methods for evaluating it?
>
> best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
> Cliquez sur l'url suivante
>
> https://www.mailcontrol.com/sr/ZudirdYlLneOuXrcyueCVQNGJwLdzJ8rOTCYSKtb45a3O3rK49roLfvNm6oPMvN32OFUGSoM99IThPoQ6aD81V0qkTt+JcoTJNUvM0QkojxH7M0eqCY+E919AxwQHSBZRWmk1SFbkAmc95+ya0u9jiMDSYs8zQkesnDMLue4BYNa9Bn+fSKJ15rRacCAubaIgQNZ7JN26NwuMH54Jp0O1E9xutjQbw11
> si ce message est ind?sirable (pourriel).
>
--
Dr Craig Donlon
Director of the International GODAE SST Pilot Project Office
Met Office Hadley Centre,
Fitzroy Road, Exeter, EX1 3PB United Kingdom
Tel: +44 (0)1392 886622 Mob:07920 235750
Fax:+44 (0)1392 885681
Skype ID:crazit
SkypeIn: +44 0141 416 0882
E-mail: craig.donlon at gmail.com
http://www.ghrsst-pp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080319/5d185dc7/attachment-0002.html>
Received on Wed Mar 19 2008 - 10:21:38 GMT
