[Go-essp-tech] CMOR and cell_measures issues
V. Balaji
V.Balaji at noaa.gov
Mon Oct 25 07:08:39 MDT 2010
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
More information about the GO-ESSP-TECH
mailing list