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 [[email protected]] on behalf of [email protected] [[email protected]] Sent: 17 July 2015 17:03 To: [email protected] Subject: CF-metadata Digest, Vol 147, Issue 22 Send CF-metadata mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: [email protected] Subject: [CF-metadata] proposal for new standard names for some cloud quantities Message-ID: <[email protected]> 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 <[email protected]> ----- > Date: Wed, 15 Jul 2015 18:36:55 +0100 > From: Mark Webb <[email protected]> > To: Jonathan Gregory <[email protected]> > CC: Mark Webb <[email protected]>, [email protected] > 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 <[email protected]> To: [email protected] Subject: [CF-metadata] How to define time coordinate in GPS? Message-ID: <[email protected]> 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 <[email protected]> ----- > Date: Wed, 15 Jul 2015 13:30:52 -0700 > From: Karl Taylor <[email protected]> > To: [email protected] > 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 <[email protected] > > > >Date: Wed, 15 Jul 2015 08:01:04 +0100 > >From: Jonathan Gregory <[email protected]> > >To: [email protected] > >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 > >[email protected] > >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ > CF-metadata mailing list > [email protected] > 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" <[email protected]> To: Karl Taylor <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [CF-metadata] Specifying latitude and longitude of transects and regions Message-ID: <7819c496f4e10e47bcefbe74551aac96346fb...@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 [[email protected]] on behalf of Karl Taylor [[email protected]] Sent: 08 July 2015 01:26 To: [email protected] 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 > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ------------------------------ Message: 4 Date: Fri, 17 Jul 2015 09:03:24 -0700 From: Karl Taylor <[email protected]> To: "Hedley, Mark" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [CF-metadata] Specifying latitude and longitude of transects and regions Message-ID: <[email protected]> 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 [[email protected]] on behalf of Karl Taylor > [[email protected]] > Sent: 08 July 2015 01:26 > To: [email protected] > 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 >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > 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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ------------------------------ End of CF-metadata Digest, Vol 147, Issue 22 ******************************************** _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
