Re: [CF-metadata] proposed change to CF calendar
Hi, As Tony indicated, the ESMF Team also supports this proposal to make the CF default/standard Gregorian calendar proleptic. Like CCSM, our Gregorian calendar is proleptic, and, also like CCSM, we do not support a mixed Julian/Gregorian historical calendar, as we've had no such requirement to-date from our users. Regards, Earl Schwab ESMF Core Team Original Message Subject:proposed change to calendar definitions Date: Fri, 08 Oct 2010 11:00:57 -0700 From: Tony Craig To: cf-metadata@cgd.ucar.edu CC: Mariana Vertenstein , eschwab.e...@gmail.com The NCAR CCSM climate model tries to follow the CF standard as much as possible with regard to input and output datasets. However, we are finding it nearly impossible to adhere to the calendaring standard. We do not have access to time managers either internally or through external sources, such as ESMF, to support the default CF "gregorian/standard" calendar as documented here, http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#calendar And at the end of that section, the CF convention notes in particular the challenges associated with "the discontinuity" in the mixed gregorian/julian calendar. We have discussed calendaring issues with the ESMF developers, and they also have no immediate plans to support the mixed gregorian/julian calendar. ESMF is one of our primary tools for supporting infrastructure in climate models, especially time managers. As a result, in our implementation, we treat the calendar naming conventions differently. gregorian == proleptic_gregorian and mixed gregorian/julian is not supported. We would like to propose a change to the CF calendar conventions to reflect what we believe the community is already doing. We propose 1. continued support of the name proleptic_calendar for backwards compatability. 2. changing the definition of gregorian and standard to be the proleptic gregorian calendar instead of the mixed gregorian/julian. 3. make the proleptic gregorian the default calendar 4. add a new calendar name, such a gregorian_julian to provide the ability to define a mixed calendar in CF conventions. that would change the definition in the above CF standards document to the following gregorian or proleptic_gregorian or standard A gregorian calendar extended to dates before 1582... This is the default. gregorian_julian Mixed Gregorian/Julian calendar as defined by Udunits. We've had discussions about this with ESMF and they are supportive of this proposal. Their gregorian calendar is also proleptic and this proposed change would make both their and our implementation more closely aligned with the CF convention. If you have any questions, please feel free to contact me. thanks, tony.. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] point observation data in CF 1.4
Dear Steve et al. Yes, it is a choice about complexity vs efficiency of space. Using an indirection to point to t means that you don't have to make the trajectories all exist at all times. It takes very little more space: instead of the t(o) in the usual trajectory feature, you have tindex(o), and this can then be packed either in the start:stop contiguous representation or the indexed representation. Extra space is needed only because there is a t variable as well. But it is certainly more complex having this indirection. Does the saving of space through not padding the trajectories justify the complexity? I don't know. Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] point observation data in CF 1.4
P.S. I neglected the obvious further simplification: replace "t(o)"
with "t(t)". Time becomes a simple netCDF coordinate variable in the
synchronized representation of trajectories. Similar for synchronized
profiles and time series.
===
On 10/13/2010 10:39 AM, Steve hankin wrote:
Hi All,
2 cents: Since this is a new twist on previously discussed feature
types, the tires of alternative approaches probably deserve to be
kicked. What's special about this use case is that the trajectories
are all synchronized in time. (Though with differing start/stop
times.) Analogous cases exist in profiles -- for example the Levitus
ocean profile collection has all been interpolated to common depths.
Similarly, time series collections are commonly synchronized.
The synchronization of coordinates opens a potential door to great
simplicity of representation.
metadata(i)data(i,o) x(i,o) y(i,o) z(i,o) t(o)
where i is the instance (which of the trajectories), o is simply the
time index. The possible costs are proliferation in numbers of ways
to represent similar things and file size. The question that I'd be
inclined to ask of Ute and Rich would be a judgment call on the cost
in file size that would result from filling missing values at the
start/end of each individual trajectory. Optionally the metadata
could include
tstart_index(i) tend_index(i)
This representation seems _the simplest from the standpoint of
application code (reading)_. Synoptic view are simply projection at
fixed "o" index; the history of an individual trajectory is simply a
projection at a fixed "i" index.
-
For each of the three basic structure -- time series, profiles, and
trajectories -- discussed at
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions we
have three approaches: multi-dimensional, ragged contiguous, ragged
indexed. ("flattened" omitted here). Effectively what I am kicking
the tires on here is a 4th approach: a "synchronized representation",
which would be the simplest of all of them. If we replaced "t(o)"
with "t(i,o)" above the "synchronized representation" generalizes into
the "multi-dimensional representation" of trajectories.
By the way, it is quite likely that *none *of the above precisely
addresses the needs of the model that is producing the data. Does
that model know in advance what the maximum number of tracer particles
will be? If that number is known, then the "Ragged array (indexed)
representation" of trajectories is arguably _the simplest from the
standpoint of model (writing)._ (And already documented. ;-) )
- Steve
On 10/13/2010 5:49 AM, Jonathan Gregory wrote:
Dear Rich
With the approach you suggest, if you wanted to obtain all the
particle positions at a particular time step, would you need to read
all tindex for all particles? (I'm a little fuzzy on what the CDL
would look like...)
No, I don't think so. Either of John's proposed packing mechanisms would
allow you to get just the tindex (and x y z) that applied to a particular
particle without reading the others.
Cheers
Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] point observation data in CF 1.4
Hi All,
2 cents: Since this is a new twist on previously discussed feature
types, the tires of alternative approaches probably deserve to be
kicked. What's special about this use case is that the trajectories are
all synchronized in time. (Though with differing start/stop times.)
Analogous cases exist in profiles -- for example the Levitus ocean
profile collection has all been interpolated to common depths.
Similarly, time series collections are commonly synchronized.
The synchronization of coordinates opens a potential door to great
simplicity of representation.
metadata(i)data(i,o) x(i,o) y(i,o) z(i,o) t(o)
where i is the instance (which of the trajectories), o is simply the
time index. The possible costs are proliferation in numbers of ways to
represent similar things and file size. The question that I'd be
inclined to ask of Ute and Rich would be a judgment call on the cost in
file size that would result from filling missing values at the start/end
of each individual trajectory. Optionally the metadata could include
tstart_index(i) tend_index(i)
This representation seems _the simplest from the standpoint of
application code (reading)_. Synoptic view are simply projection at
fixed "o" index; the history of an individual trajectory is simply a
projection at a fixed "i" index.
-
For each of the three basic structure -- time series, profiles, and
trajectories -- discussed at
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions we have
three approaches: multi-dimensional, ragged contiguous, ragged indexed.
("flattened" omitted here). Effectively what I am kicking the tires on
here is a 4th approach: a "synchronized representation", which would be
the simplest of all of them. If we replaced "t(o)" with "t(i,o)" above
the "synchronized representation" generalizes into the
"multi-dimensional representation" of trajectories.
By the way, it is quite likely that *none *of the above precisely
addresses the needs of the model that is producing the data. Does that
model know in advance what the maximum number of tracer particles will
be? If that number is known, then the "Ragged array (indexed)
representation" of trajectories is arguably _the simplest from the
standpoint of model (writing)._ (And already documented. ;-) )
- Steve
On 10/13/2010 5:49 AM, Jonathan Gregory wrote:
Dear Rich
With the approach you suggest, if you wanted to obtain all the
particle positions at a particular time step, would you need to read
all tindex for all particles? (I'm a little fuzzy on what the CDL
would look like...)
No, I don't think so. Either of John's proposed packing mechanisms would
allow you to get just the tindex (and x y z) that applied to a particular
particle without reading the others.
Cheers
Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] point observation data in CF 1.4
Dear Rich > With the approach you suggest, if you wanted to obtain all the > particle positions at a particular time step, would you need to read > all tindex for all particles? (I'm a little fuzzy on what the CDL > would look like...) No, I don't think so. Either of John's proposed packing mechanisms would allow you to get just the tindex (and x y z) that applied to a particular particle without reading the others. Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] point observation data in CF 1.4
Jonathan, >> Typical producers of this kind of data are numerical particle tracking >> models. These codes step through time, following the (x,y,t) or >> (x,y,z,t) trajectories of individual particles. At each time step, >> more particles may be introduced to be tracked, while other particles >> stop being tracked because they leave the domain, hit the boundary, or >> whatever. > > This kind of data could be described by the trajectory feature type, but each > trajectory would be entirely independent, so they'd all have separate times, > whereas as you describe it the time coord is common to all trajectories (that > exist at a particular time). To arrange this, an indirection could be used on > the time dimension: > data(i,o) x(i,o) y(i,o) z(i,o) t(tindex(i,o)) > where i is the instance (which of the trajectories), o is the point along that > trajectory, t is the coordinate vector of common times, and tindex is an index > to t. For example, we might have these two trajectories (x,t) (omitting y and > z for simplicity) > (0,10) (1,11) (2,12) > (3,11) (2,12) (1,13) (0,14) > Then t would be [10,11,12,13,14] (all the times). For the first trajectory > x=[0,1,2] tindex=[0,1,2] > and for the second > x=[3,2,1,0] tindex=[1,2,3,4] > Is that right? Perhaps/probably there's a neater or more natural way to do it. Yes, that's exactly right. With the approach you suggest, if you wanted to obtain all the particle positions at a particular time step, would you need to read all tindex for all particles? (I'm a little fuzzy on what the CDL would look like...) Thanks, Rich -- Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] point observation data in CF 1.4
Dear Rich Thanks for this explanation: > Typical producers of this kind of data are numerical particle tracking > models. These codes step through time, following the (x,y,t) or > (x,y,z,t) trajectories of individual particles. At each time step, > more particles may be introduced to be tracked, while other particles > stop being tracked because they leave the domain, hit the boundary, or > whatever. This kind of data could be described by the trajectory feature type, but each trajectory would be entirely independent, so they'd all have separate times, whereas as you describe it the time coord is common to all trajectories (that exist at a particular time). To arrange this, an indirection could be used on the time dimension: data(i,o) x(i,o) y(i,o) z(i,o) t(tindex(i,o)) where i is the instance (which of the trajectories), o is the point along that trajectory, t is the coordinate vector of common times, and tindex is an index to t. For example, we might have these two trajectories (x,t) (omitting y and z for simplicity) (0,10) (1,11) (2,12) (3,11) (2,12) (1,13) (0,14) Then t would be [10,11,12,13,14] (all the times). For the first trajectory x=[0,1,2] tindex=[0,1,2] and for the second x=[3,2,1,0] tindex=[1,2,3,4] Is that right? Perhaps/probably there's a neater or more natural way to do it. Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] point observation data in CF 1.4
Hei folkens, Thanks for pointing that out for me. This is exactly what I need. Regards, Ute Ute Brönner www.sintef.com/marine_environment Consider the environment before printing -Original Message- From: rsign...@gmail.com [mailto:rsign...@gmail.com] On Behalf Of Rich Signell Sent: Mittwoch, 13. Oktober 2010 13:31 To: Ute Brönner Cc: John Caron; Jonathan Gregory; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] point observation data in CF 1.4 Folks, > 2. I think trajectory is when you follow a set of "things", boats, a person. > But at each time step they are identical, maybe not the same number because > of missing data. I could assume that I have a trajectory but actually I can't > be sure if my particles are the same as before. Therefore I chose not to take > that convention. Let me attempt to clarify what I think Ute is talking about. Typical producers of this kind of data are numerical particle tracking models. These codes step through time, following the (x,y,t) or (x,y,z,t) trajectories of individual particles. At each time step, more particles may be introduced to be tracked, while other particles stop being tracked because they leave the domain, hit the boundary, or whatever. Thus at each time step there are a known number of particle being tracked, but this varies as the run proceeds in time. So each particle trajectory may have different start and end times. There may be thousands or tens of thousands of particles, so it's not feasible to write each trajectory into a separate file. We want a featureType that will allow us to write the entire collection of particles at each time step into a single file, and that will allow us to extract all the particles at a single time step, as well as extract individual particle trajectories by their ID.It didn't seem like the existing pointFeature types work for this case. -Rich -- Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598 > I'll be happy to contribute to the discussion as well as good as I can! > > Best regards, > Ute > > Ute Brönner > www.sintef.com/marine_environment > > Consider the environment before printing > > -Original Message- > From: John Caron [mailto:ca...@unidata.ucar.edu] > Sent: Dienstag, 12. Oktober 2010 19:31 > To: Rich Signell > Cc: Ute Brönner; Jonathan Gregory; cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] point observation data in CF 1.4 > > Hi Ute: > > 1. im not sure what this means: " I now finally find out that the new > approaches of Netcdf 4 are not implemented in the Java API, yet." > > 2. I would have thought "3D particle tracking" would be a trajectory. > how is it different? > > John > > On 10/11/2010 4:24 AM, Rich Signell wrote: >> Ute, >> >> I was thinking that you could use the proposed convention in 9.3.2 as >> a workaround, with the "station" being each record. But I see now >> that the coordinate variables for lon, lat need to be a function of >> station, so as you say, that won't work. >> >> Clearly there is a need for another Point Convention type to handle >> the output from particle tracking models like this. I can think of at >> least four models that would benefit from this convention right now, >> including the NSF RAPID grant we are working on for 3D particle >> tracking using LTRANS for the Deepwater Horizon Spill. >> >> @Jonathan, Caron& Hankin: Can we revive your discussion? I'd be >> happy to participate. >> >> -Rich >> >> On Mon, Oct 11, 2010 at 4:05 AM, Ute Brönner wrote: >>> Hei Rich, >>> >>> I found that convention before, this was what I mentioned to Jonathan. >>> But first of all, this is not convention, yet, and secondly I have no >>> stations but a varying set of observations per timestep (neither stations >>> nor trajectories). I now write the data with redundant time as a limited >>> dimension, and records(time, latitude, longitude) and have >>> mass (record), radius(record) etc. >>> >>> Thanks anyway, >>> Ute >>> >>> Ute Brönner >>> www.sintef.com/marine_environment >>> >>> Consider the environment before printing >>> >>> -Original Message- >>> From: rsign...@gmail.com [mailto:rsign...@gmail.com] On Behalf Of Rich >>> Signell >>> Sent: Freitag, 8. Oktober 2010 13:59 >>> To: Ute Brönner >>> Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu; John Caron >>> Subject: Re: [CF-metadata] point observation data in CF 1.4 >>> >>> Ute, >>> >>> On this page: >>> https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions >>> >>> It appears that your case *might* be handled by: >>> >>> 9.3.2 Ragged array (contiguous) representation >>> >>> I'm pretty sure that this "ragged_row_count" feature *is* included in >>> NetCDF-Java, but John Caron (cc'd here) could confirm. >>> >>> Please report back to this group if you find success (or perhaps even >>> if you don't!) >>> >>> Thanks, >>> -Rich >>> >>> On Thu, Oct 7, 2010 at 3:15 AM, Ute Brönner wrote: Jonathan, thanks for your
Re: [CF-metadata] point observation data in CF 1.4
Folks, > 2. I think trajectory is when you follow a set of "things", boats, a person. > But at each time step they are identical, maybe not the same number because > of missing data. I could assume that I have a trajectory but actually I can't > be sure if my particles are the same as before. Therefore I chose not to take > that convention. Let me attempt to clarify what I think Ute is talking about. Typical producers of this kind of data are numerical particle tracking models. These codes step through time, following the (x,y,t) or (x,y,z,t) trajectories of individual particles. At each time step, more particles may be introduced to be tracked, while other particles stop being tracked because they leave the domain, hit the boundary, or whatever. Thus at each time step there are a known number of particle being tracked, but this varies as the run proceeds in time. So each particle trajectory may have different start and end times. There may be thousands or tens of thousands of particles, so it's not feasible to write each trajectory into a separate file. We want a featureType that will allow us to write the entire collection of particles at each time step into a single file, and that will allow us to extract all the particles at a single time step, as well as extract individual particle trajectories by their ID.It didn't seem like the existing pointFeature types work for this case. -Rich -- Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598 > I'll be happy to contribute to the discussion as well as good as I can! > > Best regards, > Ute > > Ute Brönner > www.sintef.com/marine_environment > > Consider the environment before printing > > -Original Message- > From: John Caron [mailto:ca...@unidata.ucar.edu] > Sent: Dienstag, 12. Oktober 2010 19:31 > To: Rich Signell > Cc: Ute Brönner; Jonathan Gregory; cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] point observation data in CF 1.4 > > Hi Ute: > > 1. im not sure what this means: " I now finally find out that the new > approaches of Netcdf 4 are not implemented in the Java API, yet." > > 2. I would have thought "3D particle tracking" would be a trajectory. > how is it different? > > John > > On 10/11/2010 4:24 AM, Rich Signell wrote: >> Ute, >> >> I was thinking that you could use the proposed convention in 9.3.2 as >> a workaround, with the "station" being each record. But I see now >> that the coordinate variables for lon, lat need to be a function of >> station, so as you say, that won't work. >> >> Clearly there is a need for another Point Convention type to handle >> the output from particle tracking models like this. I can think of at >> least four models that would benefit from this convention right now, >> including the NSF RAPID grant we are working on for 3D particle >> tracking using LTRANS for the Deepwater Horizon Spill. >> >> @Jonathan, Caron& Hankin: Can we revive your discussion? I'd be >> happy to participate. >> >> -Rich >> >> On Mon, Oct 11, 2010 at 4:05 AM, Ute Brönner wrote: >>> Hei Rich, >>> >>> I found that convention before, this was what I mentioned to Jonathan. >>> But first of all, this is not convention, yet, and secondly I have no >>> stations but a varying set of observations per timestep (neither stations >>> nor trajectories). I now write the data with redundant time as a limited >>> dimension, and records(time, latitude, longitude) and have >>> mass (record), radius(record) etc. >>> >>> Thanks anyway, >>> Ute >>> >>> Ute Brönner >>> www.sintef.com/marine_environment >>> >>> Consider the environment before printing >>> >>> -Original Message- >>> From: rsign...@gmail.com [mailto:rsign...@gmail.com] On Behalf Of Rich >>> Signell >>> Sent: Freitag, 8. Oktober 2010 13:59 >>> To: Ute Brönner >>> Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu; John Caron >>> Subject: Re: [CF-metadata] point observation data in CF 1.4 >>> >>> Ute, >>> >>> On this page: >>> https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions >>> >>> It appears that your case *might* be handled by: >>> >>> 9.3.2 Ragged array (contiguous) representation >>> >>> I'm pretty sure that this "ragged_row_count" feature *is* included in >>> NetCDF-Java, but John Caron (cc'd here) could confirm. >>> >>> Please report back to this group if you find success (or perhaps even >>> if you don't!) >>> >>> Thanks, >>> -Rich >>> >>> On Thu, Oct 7, 2010 at 3:15 AM, Ute Brönner wrote: Jonathan, thanks for your answer! My troubles were related to shape and dimensions. I now finally find out that the new approaches of Netcdf 4 are not implemented in the Java API, yet. I now use a record dimension which is unlimited and a limited time dimension. Hope that works, otherwise, I have your address now :-) Best regards, Ute Ute Brönner www.sintef.com/marine_environment Consider the environment before printing
[CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters
Dear Andrew > Yes, but depends on the community (list) accepting the idea of having a Good. I think we are agreed then to propose these new cell methods: root_mean_square mean_of_upper_decile and these new standard names: sea_surface_wave_height sea_surface_wave_mean_crest_period sea_surface_wave_significant_wave_period sea_surface_wave_period_at_second_largest_peak_of_variance_spectral_density sea_surface_wave_variance_spectral_density_zeroth_frequency_moment sea_surface_wave_root_mean_square_amplitude_from_variance_spectral_density I agree that the last will avoid confusion with the RMS of wave height. I agree also that this depends on users being comfortable with the concepts being split into two attributes, in accordance with the usual CF practice, but deciding on how to join them up as common_concepts will help. Comments from others would help. It is good that Roy supports this compromise. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters
Hello Andrew and Jonathan, First, I think this discussion is heading towards reasonable compromise avoiding my concerns of a massive proliferation in cell methods and the pitfall of concepts that are explainable in the context of their parameter, but meaningless in isolation (e.g. explaining moments without the concept of frequency). Now for my views on 'common concepts'. This was a very good idea that so far has drowned in a quagmire of over-commitment. Bad news is that it's nearly a year since I left Hamburg allaying Michael and Frank's frustrations with an enthusiasm to make progress that was instantly swamped by day job issues when I returned to the office. Good news is that I am now involved (with co-workers and support) in an EU FP7 project and discovered at the project meeting last week that is going to need precise semantic interoperability between CF and SeaDataNet. In other words an exact mapping between the BODC Parameter Usage Vocabulary (P011) and data channels in CF. A mapping between P011 and CF Standard Names isn't going to cut the mustard for all the reasons that 'common concepts' were mooted to address. So, if this project is to progress operational common concepts will have to be implemented by next summer at the latest. So, my view on common concepts has recently become much more positive and I am therefore comfortable with the latest proposal. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of andrew walsh Sent: 13 October 2010 01:00 To: Jonathan Gregory Cc: cf-metadata@cgd.ucar.edu; Mark Kulmar Subject: Re: [CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters Hi Jonathon and CF metadata list, My responses are in-line below. Andrew Walsh - Original Message - From: "Jonathan Gregory" To: "andrew walsh" Cc: "Patrick Gorringe" ; ; "Mark Kulmar" ; ; "Roger Proctor" Sent: Wednesday, October 13, 2010 03:09 Subject: [CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters > Dear Andrew > > Thanks - this is a fruitful discussion. I think we agree on proposing these > new names > > sea_surface_wave_height Yes, but depends on the community (list) accepting the idea of having a common concept of 'sea_surface_wave_height' modified by the cell methods to get particular meanings for 4 of the 9 proposed wave parameters as follows: CF std. name; "cell_method"; constructed meaning (name) First 2 parameters would use new cell methods: 1) sea_surface_wave_height; "time: root_mean_square"; sea_surface_wave_height_root_mean_square 2) sea_surface_wave_height; "time: mean_of_upper_decile";sea_surface_wave_height_mean_of_upper_decile These 2 parameters would use existing cell methods: 3) sea_surface_wave_height; "time: mean"; sea_surface_wave_height_mean 4) sea_surface_wave_height; "time: maximum"; sea_surface_wave_height_maximum List readers, I would appreciate any feedback on the idea of using common concept + cell_method? > sea_surface_wave_mean_crest_period > sea_surface_wave_significant_wave_period Yes, these 2 OK. > > You have proposed a new name > sea_surface_wave_period_at_second_largest_peak_of_the_energy_spectrum > (to replace an earlier proposal). Is this the "second" corresponding to this > existing name being the "first": > sea_surface_wave_period_at_variance_spectral_density_maximum > and if so, could your new quantity be > sea_surface_wave_period_at_second_largest_peak_of_variance_spectral_density > for consistency? Yes, I this would be more consistent. > > Thanks for your explanation of sea_surface_wave_zeroth_spectral_moment. That > leads me to ask whether it could be called > sea_surface_wave_variance_spectral_density_zeroth_frequency_moment > to correspond to the terminology used in the existing names > > sea_surface_wave_mean_period_from_variance_spectral_density_first|second_frequency_moment Yes it could be called that, again fits in with existing terminology. > > Finally, you have explained that > sea_surface_wave_root_mean_square_amplitude > is the square root of the zeroth moment. It is liable to be confused with the > root_mean_square sea_surface_wave_height. Would it be acceptable to call it, > rather clumsily, > > sea_surface_wave_amplitude_from_variance_spectral_density_zeroth_frequency_moment > which follows the pattern of the names of wave periods calculated from > moments? > If it is always called sea_surface_wave_root_mean_square_amplitude and that > doesn't cause any confusion in practice, we don't need to worry about it. But > you did point out "not be confused with", so I suppose it might be a problem! I think 'sea_surface_wave_amplitude_from_variance_spectral_density_zeroth_frequency_moment' is longer/more clumsy than it needs to be. How about just 'sea_surface_wave_root_mean_square_amplitude_from_variance_spectral_density' with a the 'description' in the CF XML
