Dear Dan
You posted this on 29 Jan but no-one's responded, I believe.
I agree that there can be an issue with the space required for this, but that
does depend on how the data is organised. With a single 3D field in a file,
the space required is doubled, but larger datasets usually have many times in
a file (making them 4D) or many variables in a file (for a given time), or
both, so the overhead is less proportionately. I tend to think we would do
better to agree a convention for how groups of files are to be treated as a
single dataset, so that metrics like these can be shared among files without
duplication, than to adopt alternative conventions for saving space within
each file. The issue of aggregating files has come up many times.
Best wishes
Jonathan
----- Forwarded message from dan.bernie at metoffice.gov.uk -----
> Hi,
>
> I am an occasional reader of this list and have a query/proposal about
> the CF description of partial cells in (ocean) models with z-
> coordinates.
>
> As it stands in the CF convention (as I understand it), when using
> partial cells the different volume of cells is accounted for by
> including a 3-D array of the size of the full grid to describe the
> volume of each cell as well as a cell measure attribute in the variable:
>
> dimensions:
> deptht = 301 ;
> y = 149 ;
> x = 182 ;
> variables:
> float deptht(deptht) ;
> deptht: long_name = ?depth? ;
> deptht: units = ?m? ;
> float lon(x,y) ;
> lon: long_name = ?longitude? ;
> lon: units = ?degrees_east? ;
> float lat(x,y) ;
> lat: long_name = ?latitude? ;
> lat: units = ?degrees_north? ;
> double volumet(y, x) ;
> volumet :units = "m3" ;
> volumet :long_name = "volume of grid cell" ;
> volumet :standard_name = "cell_volume?;
> float votemper(deptht, y, x) ;
> votemper:units = "degC" ;
> votemper:long_name = "Temperature" ;
> votemper:coordinates = "deptht lat lon" ;
> votemper:cell_measures = "volume: volumet" ;
> votemper:standard_name = "sea_water_potential_temperature" ;
>
>
> My query/suggestion is about the need for a 3-D array for the thickness
> of the partial cell. The information on the thickness of the partial
> cell is essentially 2-D and the "volumet" array in the example above is
> almost doubling the size of the file. It would be entirely possible to
> fully define grid cell volumes using level thickness, grid cell area and
> information on the level and thickness of the partial cell. In the below
> example the "deptht_bounds" is used to find level thickness while the
> grid cell area is given in the 2-D array "areat". These two can be used
> for volume of every cell except the partial cells. To deal with the
> volume of the partial cells a new cell_measure of
> "partial_cell_thickness" could be used. In such a case the thickness and
> level of the partial cell can be specifed in a single number. For
> example of if the 24th level was the partial cell and it was 0.4 of the
> original thickness a "partial_cell_thickness" of 23.4 would specify the
> levels and thickness, i.e 23 full levels and 0.4 of the 24th. The
> thickness of the partial cell being 0.4 of the thickness determined from
> the 24th levels of "deptht_bounds" which would act as a refference. This
> in combination with the "areat" array would describe the cell volumes.
>
> e.g.
>
> dimensions:
> deptht = 301 ;
> y = 149 ;
> x = 182 ;
> ndepth_bounds = 2 ;
> variables:
> float deptht(deptht) ;
> deptht: long_name = ?depth? ;
> deptht: units = ?m? ;
> deptht: bounds = ?deptht_bounds" ;
> float lon(x,y) ;
> lon: long_name = ?longitude? ;
> lon: units = ?degrees_east? ;
> float lat(x,y) ;
> lat: long_name = ?latitude? ;
> lat: units = ?degrees_north? ;
> double deptht_bounds(deptht, ndepth_bounds) ;
> deptht_bounds:units = "m" ;
> deptht_bounds:long_name = "depth boundaries of cells" ;
> double areat(y, x) ;
> areat:units = "m2" ;
> areat:long_name = "area of grid cell" ;
>
>
> I'm aware that this would require some extra processing to calculate a
> 3-D array of cell volumes whereas keeping the 3-D volume array is
> foolproof, but the calculation is simple and it would greatly reduce the
> over head if many files were stored at higher vertical resolutions as in
> the above example.
>
> I'd be keen to hear people opinions on this or possible alternatives if
> I've missed something about possible ways to deal with this that are
> already used.
>
> Regards
>
>
> --
> Dan Bernie
> HadGEM Physical Processes and Coupling Scientist
> Met Office Hadley Centre, FitzRoy Road, Exeter, EX1 3PB
> Tel: +44 (0)1392 884862 Fax: +44 (0)1392 885681
> E-mail: dan.bernie at metoffice.gov.uk http://www.metoffice.gov.uk
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Sun Mar 09 2008 - 10:32:48 GMT
