[Go-essp-tech] CMOR and cell_measures issues

[V. Balaji]

Phil, I'm very impressed that Had will have gridspec files, is this
a done deal? I've been so pessimistic about this that I was wondering
if even we should do one ourselves.

You know of course that gridspec says you can supply

> 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

as one single supergrid...

But if you're doing gridspec at all, I will concede this point:-). Let's
both do these separate gridspecs for now.

Bentley, Philip writes:

> 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
>
>
>
>
>

-- 

V. Balaji                               Office:  +1-609-452-6516
Head, Modeling Systems Group, GFDL      Home:    +1-212-253-6662
Princeton University                    Email: v.balaji at noaa.gov