Custom Query (124 matches)


Show under each result:

Results (46 - 48 of 124)

Ticket Resolution Summary Owner Reporter
#61 fixed 2 new cell methods cf-conventions@… awalsh

1. Title

2 new cell methods

2. Moderator

Moderator - Alison Pammet Proposer - Andrew Walsh. Contributors and discussion - Jonathon Gregory, Roy Lowry, Mark Kulmar

3. Requirement

Extend the cell methods table with 2 new cell methods.

4. Initial Statement of Technical Proposal

As a result of discussion around the adding 9 new sea surface wave data

parameters to the CF standard names list it was decided to reduce this proposal to 6 new standard names thereby reducing the proliferation of new names. This reduction was achieved by introducing a 'common concept' name called 'sea_surface_wave_height' qualified by one of 4 cell methods i.e.

mean maximum root_mean_square mean_of_upper_decile

which will describe 4 of the statistical wave height variables:

sea_surface_mean_wave_height sea_surface_maximum_wave_height sea_surface_root_mean_square_wave_height sea_surface_wave_mean_of_highest_one_tenth_waves


'mean' and 'maximum' are existing cell methods. 'root_mean_square' and 'mean_of_upper_decile' are the 2 new cell methods proposed.

The other 5 new standard names proposed were:

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

5. Benefits

This proposal would benefit the netCDF user community as it reduces the proliferation of new names by using a common concept standard name qualified by cell methods. These 2 new cell methods may also find useful application with

other data parameters wherever statistical methods of 'root_mean_square' or 'mean_of_upper_decile' were applied.

6. Status Quo

Status quo would be to use non-standard long_names for these sea surface wave data variables with the disadvantage of poor interoperability.

#62 fixed scalar auxiliary coordinate clarifications cf-conventions@… taylor13

This proposal is to clear up some apparent inconsistencies in the description of allowable attributes for auxiliary coordinate variables.

At the beginning of section 6.2 of the conventions, it states:

"In some situations a dimension may have alternative sets of coordinates values. Since there can only be one coordinate variable for the dimension (the variable with the same name as the dimension), any alternative sets of values have to be stored in auxiliary coordinate variables. For such alternative coordinate variables, there are no mandatory attributes, but they may have any of the attributes allowed for coordinate variables."

But in paragraph 4 of Chapter 5 it states:

"The axis attribute is not allowed for auxiliary coordinate variables."

in contradiction to the statement in section 6.2.

Furthermore, according to the definition of a scalar coordinate variable (section 1.2), it is supposed to be "functionally equivalent to either a size one coordinate variable or a size one auxiliary coordinate variable." The only way for this to be possible is for both types of scalar coordinates to include the same attributes. Currently the CF document forbids use of the axis attribute in conjunction with auxiliary coordinate variables, but allows its use for coordinate variables. To make the two consistent, the following change to paragraph 4 of Chapter 5 is proposed:

Replace "The axis attribute is not allowed for auxiliary coordinate variables. Auxiliary coordinate variables ..." by "If an axis attribute is attached to an auxiliary coordinate variable, it can be used by applications in the same way the axis attribute is used in conjunction with coordinate variables. Note that if this attribute is missing, it may still be possible to determine if a particular dimension should be associated with the auxiliary coordinate variable. For example, auxiliary coordinate variables ..."

Note that in Example 5.2, the axis attribute "X" is associated with xc, and if the above change were adopted, the axis attribute could also appear in conjunction with the auxiliary coordinate variable "lon". Would this cause problems?

Also, some folks might misinterpret the paragraph at the end of section 2.4, which states that "The advantage of using a coordinate variable is that all its attributes can be used to describe the single-valued quantity, including boundaries." to mean that this is an "advantage over a a size one auxiliary coordinate variable", when in fact it means an "advantage over *omitting* the scalar variable". I therefore propose rewriting this sentence to read:

"The use of a scalar coordinate variable is encouraged, when appropriate, because the coordinate attributes (including axis attribute and the cell bounds) can be defined to more fully describe the quantity of interest."

#63 fixed GRIDSPEC: aggregation of block-structured and time dependent data cf-conventions@… pletzer

1. Title

GRIDSPEC to aggregate block-structured and time dependent data

2. Moderator

Balaji (v.balaji@…)

3. Requirement

Current conventions support logical rectangular data stored in a single file. The proposed extension will allow users to aggregate data stored in multiple files, whether the data represent different time slices or are associated with different logically rectangular grids as in the case of the cubed sphere mosaic for instance.

4. Initial Statement of Technical Proposal

GRIDSPEC comprises of two parts: M-SPEC for representing the grid connectivity in mosaics and F-SPEC for time and mosaic data aggregation.

For M-SPEC, a mosaic file contains the list of files where grid information can be extracted with inter-tile connectivity information provided as a map between the set of indices on one tile to indices on the neighbouring tile. This covers both surfacial and volumetric coupling. The former arises for instance when two three-dimensional grids share a surface while the latter arises when the grids are overlapping.

The F-SPEC describes the format of the host file, which acts as a single entry point to the aggregation. Variable data scattered among many files appear as one logical entity when viewed through the host file. Brittleness, in other words the fragility of the aggregation resulting from inadvertent file corruption, file movement and other file operations, is minimized by consolidating all the file names in the host file, which can be straightforwardly re-generated by scanning directories and inspecting the global attributes of the files residing therein.

5. Benefits

Data producers will be able to store data in multiple files while allowing data consumers to access the data as if all the data were stored in a single file.

A number of codes are moving away from longitude-latitude grids because of the singularity of such grids at the pole, which can cause severe limitations in the maximum time steps than models can take. M-SPEC will allow atmospheric and ocean models to store data on their native grids, without having to incur inaccuracies due to lon-lat regridding.

6. Detailed Proposal

Because of the length of this proposal, a separate web page was created to explain in more details our proposed enhancements. The web page contains many examples and is supported by illustrations.

Note: See TracQuery for help on using queries.