Dear Steve,
If this coordinate information is to be stored as auxiliary coordinate
variable, one option is to do something similar to what we've done in
CMIP5. Like others, I'm not advocating this as the best solution for
CF, but it seems useful until a convention for doing this is accepted.
In CMIP5 we point to gridspec files and also files containing
cell_measures, so that this information doesn't have to be encoded in
each of the netCDF files. In your case for a variable, which I've named
"irradiance", the information might look like:
float irradiance(time, i, j)
irradiance: coordinates = "lat lon"
irradiance: associated_files = "baseURL:
http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation lat: latitude.nc lon:
longitude.nc"
The lat and lon variables would not be found in the file containing
irradiance, but lat(time, i, j) would be found in latitude.nc and lon
would be found in longitude.nc (or they both could be in a single file
if you want with the obvious modification of associated_files -- e.g.,
lat: coord.nc lon: coord.nc). The files would be found at a location
pointed to by baseURL.
I've also provided an example of CMIP5 output below with the
cell_measures reliance on associated_files.
Best regards,
Karl
Example 1: Usual Treatment of a 2-D Field
(surface latent heat flux; a function of longitude, latitude, month)
netcdf hfls_Amon_GICCM1_abrupt4xCO2_r1i1p1_198001-198002 {
dimensions:
time = UNLIMITED ; // (2 currently)
lat = 3 ;
lon = 4 ;
bnds = 2 ;
variables:
double time(time) ;
time:bounds = "time_bnds" ;
time:units = "days since 1980" ;
time:calendar = "standard" ;
time:axis = "T" ;
time:long_name = "time" ;
time:standard_name = "time" ;
double time_bnds(time, bnds) ;
double lat(lat) ;
lat:bounds = "lat_bnds" ;
lat:units = "degrees_north" ;
lat:axis = "Y" ;
lat:long_name = "latitude" ;
lat:standard_name = "latitude" ;
double lat_bnds(lat, bnds) ;
double lon(lon) ;
lon:bounds = "lon_bnds" ;
lon:units = "degrees_east" ;
lon:axis = "X" ;
lon:long_name = "longitude" ;
lon:standard_name = "longitude" ;
double lon_bnds(lon, bnds) ;
float hfls(time, lat, lon) ;
hfls:standard_name = "surface_upward_latent_heat_flux" ;
hfls:long_name = "Surface Upward Latent Heat Flux" ;
hfls:comment = "comment from CMIP5 table: includes both evaporation and
sublimation" ;
hfls:units = "W m-2" ;
hfls:original_name = "LATENT" ;
hfls:history = "2010-04-21T21:05:23Z altered by CMOR: Changed sign.
Inverted axis: lat." ;
hfls:cell_methods = "time: mean" ;
hfls:cell_measures = "area: areacella" ;
hfls:associated_files = "baseURL:
http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile:
gridspec_fx_GICCM1_abrupt4xCO2_r0i0p0.nc areacella:
areacella_fx_GICCM1_abrupt4xCO2_r0i0p0.nc" ;
hfls:_FillValue = 1.e+20f ;
hfls:missing_value = 1.e+20f ;
// global attributes:
:institution = "GICC (Generic International Climate Center, Geneva,
Switzerland)" ;
:institute_id = "GICC" ;
:experiment_id = "abrupt4xCO2" ;
:source = "GICCM1 (2002): atmosphere: GICAM3 (gicam_0_brnchT_itea_2,
T63L32); ocean: MOM (mom3_ver_3.5.2, 2x3L15); sea ice: GISIM4; land:
GILSM2.5" ;
:model_id = "GICCM1" ;
:forcing = "GHG (CO2 only)" ;
:parent_experiment_id = "piControl" ;
:branch_time = 365. ;
:contact = "Rusty Koder (ko...@middle_earth.net)" ;
:history = "Output from archive/giccm_03_std_2xCO2_2256.
2010-04-21T21:05:23Z CMOR rewrote data to comply with CF standards and
CMIP5 requirements." ;
:references = "Model described by Koder and Tolkien (J. Geophys. Res.,
2001, 576-591). Also see http://www.GICC.su/giccm/doc/index.html 2XCO2
simulation described in Dorkey et al. \'(Clim. Dyn., 2003, 323-357.)" ;
:initialization_method = 1 ;
:physics_version = 1 ;
:tracking_id = "c35a58c3-8978-4628-9103-9a7d61002e07" ;
:product = "output" ;
:experiment = "abrupt 4XCO2" ;
:frequency = "mon" ;
:creation_date = "2010-04-21T21:05:23Z" ;
:Conventions = "CF-1.4" ;
:project_id = "CMIP5" ;
:table_id = "Table Amon (02 April 2010)" ;
:title = "GICCM1 model output prepared for CMIP5 abrupt 4XCO2" ;
:modeling_realm = "atmos" ;
:realization = 1 ;
data:
time = 15.5, 45.5 ;
time_bnds =
0, 31,
31, 60 ;
lat = 10, 20, 30 ;
lat_bnds =
5, 15,
15, 25,
25, 35 ;
lon = 0, 90, 180, 270 ;
lon_bnds =
-45, 45,
45, 135,
135, 225,
225, 315 ;
hfls =
120, 116, 112, 108,
104, 100, 96, 92,
88, 84, 80, 76,
119, 115, 111, 107,
103, 99, 95, 91,
87, 83, 79, 75 ;
}
On 28-Apr-10 7:14 AM, Stephen Emsley wrote:
We have multiple satellite geophysical data products which share the
same set of geo-location and timing co-ordinates. To avoid product
bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering
the possibility of having a single file storing the co-ordinates but
we think that this conflicts with our desire to be CF Convention
conformant. Is that correct?
Many thanks
Steve
--
Dr Stephen Emsley *::* ARGANS Limited *::* www.*argans.co.uk
T: +44 1752 764289 *|* M: +44 7912 515418 *|* [email protected]
/ /
This message is to be treated as private and confidential, and the
information in it may not be used or disclosed except for the purpose
for which it has been sent. ARGANS is a limited company registered in
England & Wales. Registered number: 6313966. Registered address:
Thatchers, Russells Water, Henley on Thames, Oxon, RG9 6EU
_______________________________________________
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
