[Go-essp-tech] CMOR and cell_measures issues
Charles Doutriaux
doutriaux1 at llnl.gov
Fri Oct 22 08:41:50 MDT 2010
Hi Phillip,
As far as the filen name goes, the same could be said for all "fixed"
field, they're likely to be the same across experiments
(sftlf/orog/etc...). But we're "trying" to get as close as possible from
the DRS....
C.
On 10/22/10 7:31 AM, Bentley, Philip wrote:
> Hi Karl,
>
> A somewhat belated follow-up question in connection with this proposal
> (and with some slight overlap with Jamie's email which crossed on the
> ether)...
>
> As things stand the files named in the 'associated_files' attribute
> appear thus (using our RCP 4.5 simulation as an example):
>
> "... gridspecFile: gridspec_fx_HadGEM2-ES_rcp45_r0i0p0.nc areacella:
> areacella_fx_HadGEM2-ES_rcp45_r0i0p0.nc"
>
> Are the <expt_id>_<rip> parts (i.e. 'rcp45_r0i0p0.nc' ) actually
> required? AFAIK, our gridspec/cellarea files will not change from one
> simulation to the next using the same model (HadGEM2-ES in this case).
>
> Since, like most centers, we will be running large numbers of
> simulations using the same model, it looks like we would need to
> create numerous duplicates of the gridspec/cellarea files - or lots of
> symlinks - in order to for these references to make sense. Unless you
> are planning to manage that on our behalf somehow...?
>
> I think our 4 gridspec files for the HadGEM2 atm grids are likely to
> be called something like...
>
> gridspec_fx_HadGEM2-ES_atm_pgrid.nc
> gridspec_fx_HadGEM2-ES_atm_ugrid.nc
> gridspec_fx_HadGEM2-ES_atm_vgrid.nc
> gridspec_fx_HadGEM2-ES_atm_uvgrid.nc
>
> So without any simulation-specific info. (There would also be files
> for the ocean grids)
>
> As it happens the gridspec files contain grid cell areas, so I'm now
> wondering if we'd even supply both?
>
> I'd be interested to hear your thoughts on this. I may be
> mis-understanding something/everything :-)
>
> Regards
> Phil
>
>
> ------------------------------------------------------------------------
> *From:* Karl Taylor [mailto:taylor13 at llnl.gov]
> *Sent:* 19 October 2010 18:36
> *To:* martin.juckes at stfc.ac.uk
> *Cc:* Bentley, Philip; Doutriaux, Charles; Kettleborough, Jamie;
> Bryan Lawrence; cmor at lists.llnl.gov; go-essp-tech at ucar.edu;
> Kyle.Olivo at noaa.gov
> *Subject:* CMOR and cell_measures issues
>
> Dear CMOR users,
>
> It has been brought to our attention that the CF checker (which is
> different from the CMOR checker) traps an error in CMOR-produced
> files indicating non-compliance with the CF conventions. The
> error is that the cell_measures attribute is defined, but the area
> and/or volume data is not contained in the file. [We have
> included a non-CF attribute called "associated_files" that points
> to the files containing area/volume.] Still, in order to not
> confuse CF-compliant software we plan to immediately release a new
> version of CMOR in which the "cell_measures" attribute is replaced
> by a non-CF attribute named "ext_cell_measures" (indicating that
> the area/volume data is externally available).
>
> Also, some groups have reported that not all their variables are
> carried on the same grid. (For example, sometimes the u and v
> fields are staggered relative to T.) In this case it would be
> necessary to have more than one set of areas associated with the
> model, and this is not currently possible since only areacella,
> areacello, and volcello are defined in the CMIP5 request for model
> output. We have therefore decided to include an option for CMOR
> users to suppress writing of the ext_cell_measures attribute when
> it would point to areacella or areacello incorrectly. The user
> would in effect be allowed one set of areas to be associated with
> the atmospheric model and one set of areas/volumes to be
> associated with the ocean models. The user would suppress the
> ext_cell_measures attribute (and areacella, areacello, volcello
> would not appear in the "associated_files" attribute) for any
> variables where these areas/volumes would be incorrect.
>
> We hope this is acceptable.
>
> Best regards,
> Karl and Charles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20101022/50034a2a/attachment-0001.html
More information about the GO-ESSP-TECH
mailing list