Hello Karl,
In your email of 17th July you ask the "use case" for providing the spatial coordinates of data. I was under the impression that this was an accepted objective: the proposal here was to close a gap whereby there is a small collection of CMIP5 and CMIP6 variables, namely those on corresponding to fluxes through transects and basin data, for which the CF Convention provides no means of detailed geo-referencing (though we could just use a scalar coordinate variable to specify the mid-point of the transect/basin). The use case is, as stated in my initial email, geo-referencing the data,
regards,
Martin
________________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of cf-metadata-request at cgd.ucar.edu [cf-metadata-request at cgd.ucar.edu]
Sent: 17 July 2015 17:03
To: cf-metadata at cgd.ucar.edu
Subject: CF-metadata Digest, Vol 147, Issue 22
Send CF-metadata mailing list submissions to
cf-metadata at cgd.ucar.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
or, via email, send a message with subject or body 'help' to
cf-metadata-request at cgd.ucar.edu
You can reach the person managing the list at
cf-metadata-owner at cgd.ucar.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CF-metadata digest..."
Today's Topics:
1. proposal for new standard names for some cloud quantities
(Jonathan Gregory)
2. How to define time coordinate in GPS? (Jonathan Gregory)
3. Re: Specifying latitude and longitude of transects and
regions (Hedley, Mark)
4. Re: Specifying latitude and longitude of transects and
regions (Karl Taylor)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Jul 2015 14:49:41 +0100
From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] proposal for new standard names for some cloud
quantities
Message-ID: <20150717134941.GA7003 at met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii
Dear Mark
I can't remember whether I found any existing inconsistency. Are there any
names among those which were previously added for CFMIP that have the same
definitions of evaporation and condensation as you used? Thank you for
modifying your definitions and removing problems so that for the moment we
will not be introducing an inconsistency. Using the wider definitions of
evaporation and condensation means that it's simpler to name and discuss
phase transitions gas <-> liquid or solid, while sublimation and deposition
refer to gas <-> solid, but as you imply, we would need to find other words or
phrases to refer to gas <-> liquid. In support of the general definition,
I would note that vapour means gas, and condensed means not gas (as in
https://en.wikipedia.org/wiki/Condensed_matter_physics), so these words are
quite logical - but I would definitely not argue that languages are or should
be always logical! For CF consistency is a very important principle. We could
adopt your preferred definitions, if we renamed quite a few of the existing
standard names.
Best wishes
Jonathan
----- Forwarded message from Mark Webb <mark.webb at metoffice.gov.uk> -----
> Date: Wed, 15 Jul 2015 18:36:55 +0100
> From: Mark Webb <mark.webb at metoffice.gov.uk>
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> CC: Mark Webb <mark.webb at metoffice.gov.uk>, cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] proposal for new standard names for some cloud
> quantities
> User-Agent: Mutt/1.5.20 (2009-12-10)
>
> Dear Jonathan,
>
> Thanks for your comments.
>
> > Thanks very much. Having the definitions detail the processes helps a lot.
> > I do have a remaining concern about terminology, though, which probably should
> > have been noticed earlier. In the guidelines, "condensed water" means liquid
> > or solid (ice), for instance in mass_fraction_of_cloud_condensed_water_in_air,
> > which says this explicitly in its definition.
>
> > For consistency, "condensation" should mean gas -> liquid or solid. The
> > A Met Soc glossary says "in general" that's what condensation means, but
> > in meteorology it means gas -> liquid.
> > http://glossary.ametsoc.org/wiki/Condensation
> > It's unfortunate that it's ambiguous! I think the general definition is
> > more satisfactory.
>
> > The same entry says "evaporation" means liquid or solid -> gas i.e. the reverse
> > of condensation. That is the sense in which we use it in some other standard
> > names e.g. water_evaporation_flux. However the AMS entry for evaporation gives
> > this as its first sense, but remarks that it's "usually" liquid->gas. Again, an
> > unsatisfactory ambiguity, and I would prefer the broader definition. With the
> > broader definitions, deposition (gas -> solid) is a subset of condensation,
> > and sublimation (solid -> gas) a subset of evaporation.
> >
> > It looks like we may have some existing inconsistency between the meanings of
> > condensation and perhaps evaporation in standard names. Do you agree? If so we
> > should try to sort it out. An advantage of the broader definitions is you would
> > not have to say condensation_and_deposition, since it's all condensation.
>
> I've given this quite a bit of thought and I'm afraid that I'm unsure
> about the best way to proceed. Personally I prefer the definition
> in common usage in meterology which restricts condensation and
> evaporation to vapour/liquid transitions and uses deposition/
> sublimation as well. I see this as more precise because it allows
> for the future possibility of supporting variables which separate
> condensation and deposition for example. But I also very much take
> your point that this is potentially inconsistent with other terms
> already defined in the standard names such as water_evaporation_flux
> /condensed_water. (I think that the current standard names are
> consistent in this sense - but I may have missed something. Was
> there a particular inconsistency that you had spotted?)
>
> For the moment I have modified my proposal to remove references
> to condensation/evaporation - hopefully the definitions below
> are now unambigous. This has required removing a couple of
> variables. I will think about the best way to propose these
> at a future date. I'll have to decide whether to adopt
> your suggestion or whether to propose more wide ranging changes
> to the standard names to make them consistent with my preferred
> definition for condensation/evaporation.
>
> Here is my updated proposal. Please let me know if you have any
> concerns with it is it now stands.
>
> Thanks!
> Mark
------------------------------
Message: 2
Date: Fri, 17 Jul 2015 14:53:20 +0100
From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] How to define time coordinate in GPS?
Message-ID: <20150717135320.GB7003 at met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii
Dear Karl
I agree with your summary of the situation, thank you. This whole discussion
began (as the title reminds us) because of a use-case of specifying that GPS
time had been used, and not UTC time, so I expect there will be use of these
new calendars, but that most data will continue be written with gregorian,
which we will define more precisely when we make this change.
Best wishes
Jonathan
----- Forwarded message from Karl Taylor <taylor13 at llnl.gov> -----
> Date: Wed, 15 Jul 2015 13:30:52 -0700
> From: Karl Taylor <taylor13 at llnl.gov>
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] How to define time coordinate in GPS?
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0)
> Gecko/20100101 Thunderbird/31.7.0
>
> Hi Jonathan and Jim,
>
> Thanks for bearing with me as I educate myself and think about this
> stuff. I rethought further about what I said yesterday and
> realized that maybe we were still making this too complicated.
> Jonathan's discussion helped me to come up with the following:
>
> Starting with the following claims:
>
> 1) All model data stored under CF has been generated by models with
> strict 86400 second mean sidereal days (and no leap seconds are
> necessary)
>
> 2) Up to now, the vast majority of all observational data stored
> under CF has had reference times that can be associated with the UTC
> calendar (or its predecessor GMT) and the elapsed times have been
> recorded omitting leap seconds.
>
> I make the second claim because, for example, folks doing daily
> measurements or even 3-hourly measurements collected for synoptic
> weather prediction record that data at certain times of day as
> dictated by clocks that follow UTC. For example a measurement might
> be done every day at 0Z and the person performing the measurement is
> probably not even aware that every once in a while he had to wait 1
> second longer than usual because a leap second was inserted. When
> these measurements are recorded as time series, I'd be surprised if
> anyone has inserted a leap second in computing elapsed time.
>
> This "sloppiness" in recording elapsed time actually is a blessing
> to those of us comparing climate model output to observations. If
> we want to compare monthly means, for example, we can specify
> exactly the same time bounds for both observed data and model output
> and we will extract the data of interest. If instead leap seconds
> had been accounted for in calculating elapsed time under the UTC
> system, then the time bounds would be different from models,
> certainly giving us headaches and likely leading to mistakes.
>
> I would therefore advocate to interpret "gregorian" as follows:
>
> This calendar is based on the assumption that the length of the mean
> solar day is exactly 86400 seconds. For observations, the
> assumption is not in fact exactly correct. To facilitate
> comparisons between model results and climate and weather
> observations, an adjustment in the true elapsed time is required
> when calendar="gregorian". The reference time should be specified
> according to the UTC time system, but leap seconds should be omitted
> in converting from wall-clock time to elapsed time. This means that
> elapsed time values will only be approximately correct, but this is
> generally desirable because: 1) simple algorithms can be used to
> convert from wall-clock time to elapsed time, 2) the mismatch
> between the model's mean solar day and the actual mean solar day
> (about .002 seconds) can be ignored in comparing models and
> observations; observed elapsed times are effectively modified to
> yield a time series that stays synced with the diurnal cycle we
> would find if the earth's day were exactly 86400 seconds long. Note
> that although elapsed times stored in the CF-conforming file will be
> only approximate, they will differ by less than 17 seconds (as of
> July 2015) from the true elapsed time.
>
> I think this definition means that there is no need for gregorian_utc_nls.
>
> Although I can see why the two new calendars (gregorian_utc and
> gregorian_gps) could be used for special cases, I would hope most
> providers of climate and weather data will continue to use a
> "gregorian" calendar as defined above. This will make it much
> easier for modelers to compare their output to observations.
>
> best regards,
> Karl
>
>
> On 7/15/15 1:34 AM, Jonathan Gregory wrote:
> >PS. First, to repeat myself:
> >
> >So my conclusion (at present - but I suspect I haven't understood something
> >you have said) is that gregorian is fine and sufficient (with the addition of
> >gregorian_utc and gregorian_gps for the well-defined real-world systems) if
> >we define it to mean that 86400-seconds are assumed to be used for conversion
> >from clock time to elapsed time and elapsed time to clock time, that it is not
> >defined whether the reference time and clock times are GPS and UTC, and that
> >the elapsed times may not be exactly correct for the real world (due to the
> >neglect of leap seconds).
> >
> >I also said, "This is then the same as gregorian_utc_nls, so we would not need
> >that either, which was your final conclusion in your previous post." Actually
> >it's not quite the same as gregorian_utc_nls, which asserts that clock times,
> >if real-world, are UTC. Otherwise it's the same. If my conclusion above is
> >correct, then I don't mind whether we introduce gregorian_utc_nls or not. No-
> >one has definitely asked for it, as far as I remember; we discussed it because
> >of anticipating the need, I believe. We could therefore follow the usual CF
> >principle of omitting it until it's asked for.
> >
> >Cheers
> >
> >Jonathan
> >
> >----- Forwarded message from Jonathan Gregory <j.m.gregory at reading.ac.uk-----
> >
> >Date: Wed, 15 Jul 2015 08:01:04 +0100
> >From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> >To: cf-metadata at cgd.ucar.edu
> >Subject: [CF-metadata] How to define time coordinate in GPS?
> >User-Agent: Mutt/1.5.21 (2010-09-15)
> >
> >Dear Karl
> >
> >I think the meaning of "gregorian" up to CF 1.6 is actually not clear, because
> >we had not thought about these distinctions earlier. If we change the calendar
> >definitions, it does not affect the interpretation of any existing data written
> >with previous versions. However I agree that it would be inconvenient for data-
> >users if they had to process "gregorian" times differently according to the
> >setting of the Conventions version.
> >
> >I thought that the current proposal was that gregorian would be vague in
> >future, like you wrote in your second option:
> >
> >1) might or might not account for leap seconds, 2) might or might not assume
> >the length of the solar day is exactly 86400 seconds long, and 3) might express
> >the reference time according to either UTC or GPS
> >
> >and that is exactly the reason why, after agreeing with Jim last week, I
> >changed my mind to argue that we needed gregorian_nls for model data, to
> >preserve the exactness for times which really are always 86400-second days.
> >You agree we would need gregorian_nls in that case. I agree that it means that
> >models would use gregorian_nls in future, not gregorian.
> >
> >However in your first option you don't think this is necessary:
> >
> >Under the "gregorian" calendar the length of the solar day can be assumed to be
> >exactly 86400 seconds long (i.e., there are no leap seconds). This means that
> >for models where this assumption almost invariably is valid, conversion from
> >elapsed time to clock time is straight-forward and exact, whereas for
> >observations, conversion to clock time may introduce errors as large as 16
> >seconds because it is unknown whether the UTC or GPS time system has been used
> >in specifying the reference times (appearing in the time units attribute), and
> >it is also unknown whether leap seconds have been properly accounted for in
> >converting UTC clock times to elapsed time.
> >
> >I'm sorry, but I can't see what is the difference. In both cases you say it
> >is unknown whether leap seconds have been included in converting from clock
> >time to elapsed time. Is the crucial difference about the length of the day?
> >Does "assume the solar day to be exactly 86400 seconds" mean "assume all days
> >are 86400 seconds in converting elapsed time to clock time"?
> >
> >If that's what you mean, I think your first and preferred option is fine, and
> >then I agree we do not need gregorian_nls. To spell it out, I think this is
> >acceptable if "gregorian" means that you will recover the clock times (time-
> >stamps) exactly by using an algorithm that assumes constant 86400-second days
> >(i.e. with no leap seconds). If these clock times refer to the real world, it
> >is undefined whether the reference time is GPS or UTC, and consequently it is
> >undefined whether the decoded clock times are GPS or UTC.
> >
> >But my statement "you will recover the clock times (time-stamps) exactly by
> >using an algorithm that assumes constant 86400-second days" is inconsistent
> >with your statement "conversion to clock time may introduce errors ... because
> >it is unknown whether ... leap seconds have been properly accounted for in
> >converting UTC clock times to elapsed time". According to my statement,
> >gregorian means that leap seconds were ignored when converting clock times to
> >elapsed times i.e. 86400-second days were used. If that's not the case, you
> >can't decode accurately. Thus the elapsed times may not be quite right for the
> >real world. This is then the same as gregorian_utc_nls, so we would not need
> >that either, which was your final conclusion in your previous post.
> >
> >So my conclusion (at present - but I suspect I haven't understood something
> >you have said) is that gregorian is fine and sufficient (with the addition of
> >gregorian_utc and gregorian_gps for the well-defined real-world systems) if
> >we define it to mean that 86400-seconds are assumed to be used for conversion
> >from clock time to elapsed time and elapsed time to clock time, that it is not
> >defined whether the reference time and clock times are GPS and UTC, and that
> >the elapsed times may not be exactly correct for the real world (due to the
> >neglect of leap seconds).
> >
> >Best wishes
> >
> >Jonathan
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata at cgd.ucar.edu
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
------------------------------
Message: 3
Date: Fri, 17 Jul 2015 15:21:10 +0000
From: "Hedley, Mark" <mark.hedley at metoffice.gov.uk>
To: Karl Taylor <taylor13 at llnl.gov>, "cf-metadata at cgd.ucar.edu"
<cf-metadata at cgd.ucar.edu>
Subject: Re: [CF-metadata] Specifying latitude and longitude of
transects and regions
Message-ID:
<7819C496F4E10E47BCEFBE74551AAC96346FBAB3 at EXXCMPD1DAG3.cmpd1.metoffice.gov.uk>
Content-Type: text/plain; charset="us-ascii"
Hello Karl
I thought that Martin had presented a use case from CMIP5 which was expected to be repeated in CMIP6
Thus, I thought it likely that specifying data variables related to transects and regions would be done quite widely in CMIP6
You seem to think this is not the case, please may you elaborate a little on why for us?
thank you
mark
________________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Karl Taylor [taylor13 at llnl.gov]
Sent: 08 July 2015 01:26
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Specifying latitude and longitude of transects and regions
Hi Martin, Mark, and all,
I can see that theoretically one might want to define a transect, but do
we have any compelling use case to do this at the moment? I don't think
CMIP6 is such a case.
cheers,
Karl
On 7/1/15 6:33 AM, Hedley, Mark wrote:
> Hello Martin,
>
>> If the two end points can be specified with bounds within the existing convention, it might be simpler to use that. Can you explain to me how this is done? The only reference to bounds which I could find in the convention was in connection with cell boundaries.
> I don't think it can be done. I agree with your analysis, the only reference to bounds is with regard to cell boundaries. It think it is sensible to keep it this way and provide a separate mechanism for your transect use case. I think overloading the current bounds mechanism is likely to lead to problems.
>
>> The flow direction does need to be defined .. I suppose that would involve a clarification of the standard_name ocean_volume_transport_across_line. As you say, this should not be too complicated once we have a definition of the line to refer to.
> It would be good to consider if this could be defined for the transect, so that standard_name descriptions can remain unchanged. I'll think on this some more.
>
>> The approach I was thinking of could easily accommodate multiple points on a line, though I don't have a use for it at present. e.g.
> excellent.
>
> I'll follow up on this soon
> mark
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
------------------------------
Message: 4
Date: Fri, 17 Jul 2015 09:03:24 -0700
From: Karl Taylor <taylor13 at llnl.gov>
To: "Hedley, Mark" <mark.hedley at metoffice.gov.uk>,
"cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
Subject: Re: [CF-metadata] Specifying latitude and longitude of
transects and regions
Message-ID: <55A9274C.20500 at llnl.gov>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Mark,
Yes, in CMIP5 we asked for a single monthly-mean variable (mfo)
involving a "transect" be reported. This was the
sea water transport through (or associated with) the following straits,
openings, channels, passages, etc.: barents_opening, bering_strait,
canadian_archipelago, denmark_strait, drake_passage, english_channel,
pacific_equatorial_undercurrent, faroe_scotland_channel,
florida_bahamas_strait, fram_strait, iceland_faroe_channel,
indonesian_throughflow, mozambique_channel, taiwan_luzon_straits, and
windward_passage. For definitions see the following WGOMD document:
http://www.clivar.org/sites/default/files/documents/137_WGOMD_ModelOutput.pdf
Section 4.4 of that document explains how "transects" are defined
(approximately). The point of reporting this variable was that modelers
were supposed to be given some leeway in defining exactly what transect
should be used to compare their model with observations. Given the
large uncertainty in observations and the approximate nature of model
topology, I don't think anyone using the data will be particularly
interested in exactly how the transects were defined. I'm not saying
that the data would be completely useless (after all you would need this
information to redo the calculation of sea water transport), but we
decided that for a single variable it wasn't worth complicating CMOR
further to record the details. The approximate end-points are given in
the WGOMD document.
Perhaps Martin knows of someone who wants this information saved for
CMIP6 and why. [I don't recall if he gave examples.]
best regards,
Karl
)
On 7/17/15 8:21 AM, Hedley, Mark wrote:
> Hello Karl
>
> I thought that Martin had presented a use case from CMIP5 which was expected to be repeated in CMIP6
>
> Thus, I thought it likely that specifying data variables related to transects and regions would be done quite widely in CMIP6
>
> You seem to think this is not the case, please may you elaborate a little on why for us?
>
> thank you
> mark
>
> ________________________________________
> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Karl Taylor [taylor13 at llnl.gov]
> Sent: 08 July 2015 01:26
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Specifying latitude and longitude of transects and regions
>
> Hi Martin, Mark, and all,
>
> I can see that theoretically one might want to define a transect, but do
> we have any compelling use case to do this at the moment? I don't think
> CMIP6 is such a case.
>
> cheers,
> Karl
>
> On 7/1/15 6:33 AM, Hedley, Mark wrote:
>> Hello Martin,
>>
>>> If the two end points can be specified with bounds within the existing convention, it might be simpler to use that. Can you explain to me how this is done? The only reference to bounds which I could find in the convention was in connection with cell boundaries.
>> I don't think it can be done. I agree with your analysis, the only reference to bounds is with regard to cell boundaries. It think it is sensible to keep it this way and provide a separate mechanism for your transect use case. I think overloading the current bounds mechanism is likely to lead to problems.
>>
>>> The flow direction does need to be defined .. I suppose that would involve a clarification of the standard_name ocean_volume_transport_across_line. As you say, this should not be too complicated once we have a definition of the line to refer to.
>> It would be good to consider if this could be defined for the transect, so that standard_name descriptions can remain unchanged. I'll think on this some more.
>>
>>> The approach I was thinking of could easily accommodate multiple points on a line, though I don't have a use for it at present. e.g.
>> excellent.
>>
>> I'll follow up on this soon
>> mark
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150717/32d36d9f/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
------------------------------
End of CF-metadata Digest, Vol 147, Issue 22
********************************************
Received on Wed Jul 29 2015 - 01:54:02 BST
