[Go-essp-tech] CMOR and cell_measures issues

[Charles Doutriaux]

 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