Dear Jonathan,
> 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?
I just had a look. There is a set of existing names which were proposed
for CFMIP by Tomoo Ogura, some of which used the terms condensation and
evaporation (see below). The third set referring to the condensed water
budget indicate to me that Tomoo was taking an approach consistent with
the other standard names that you are advocating - ie that deposition
and sublimation are examples of condensation and evaporation.
Where condensation and evaporation appear in the cloud liquid water
budget it is implicit that it's referring to the liquid phase only.
[1] Cloud liquid water budget
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_homogeneous_nucleation
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_heterogeneous_nucleation
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_riming
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_accretion_to_rain
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_accretion_to_snow
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_melting_from_cloud_ice
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_autoconversion
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_advection
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_longwave_heating
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_shortwave_heating
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_boundary_layer_mixing
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_convection
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_turbulence
tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_pressure_change
[2] Cloud ice budget
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_homogeneous_nucleation
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heterogeneous_nucleation_from_cloud_liquid
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heterogeneous_nucleation_from_water_vapor
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_from_cloud_liquid
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_from_rain
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_deposition_and_sublimation
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_aggregation
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_accretion_to_snow
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_evaporation_of_melting_ice
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_to_rain
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_to_cloud_liquid
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_icefall
tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_advection
[3] Cloud condensed water budget
tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_condensation_and_evaporation
tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_autoconversion_to_rain
tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_autoconversion_to_snow
tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_icefall
tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_advection
> 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.
Yes. Tomoo seems to have solved that problem by explicitly referring to
liquid water when referring to condensation and evaporation between vapour
and 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.
Thanks for pointing me to that definition. I hadn't come across it. I
accept your point that it is important to be self consistent in CF even
if the common usage of 'condensation' and 'condensed' and 'condensate'
are inconsistently used in meteorology. I will think about how
to redefine my new variables to be consistent with the CF convention's
current approach, perhaps adding a new term like
condensation_and_evaporation_conversion_to_liquid_water where the liquid
phase only is concerned.
Thanks for your help.
Best wishes,
Mark
>
> ----- 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
> ********************************************
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Webb Climate Scientist
Met Office Hadley Centre
FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884515 Fax: +44 (0)1392 885681
E-mail:mark.webb at metoffice.gov.uk http://www.metoffice.gov.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received on Fri Jul 24 2015 - 09:04:19 BST
