<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18975"></HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV dir=ltr align=left><SPAN class=558304916-01112010><FONT color=#0000ff
size=2 face=Arial>Hello Karl,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=558304916-01112010><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=558304916-01112010><FONT color=#0000ff
size=2 face=Arial>thanks for this reply. Putting aside the issue of
whether this is really ext_cell_measures or cell_measures then I think, given
the resources we have locally, we have to make a choice of correctness vs
completeness. The reason we are tempted to turn off ext_cell_measures is
it is the least effort way we can see of submitting data that is correct.
I think you are suggesting going for completness - even if we risk submitting
some data with ext_cell_measures that is incorrect. Obviously this is *my*
interpretation of what you are saying. Yes we can go for both correctness
and completeness, but this will take us some effort - we need an exta component
in our system that can recognise which cell areas to assign to
which variables (with minimum error) - and we (like everyone) have lots of
demands on our effort at the moment - and we have to make judgements about where
to prioritise. (This isn't supposed to be a sob story - just trying to
explain why we are tempted...)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=558304916-01112010><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=558304916-01112010><FONT color=#0000ff
size=2 face=Arial>Would you recommend 'completeness' over 'correctness' - have I
interpreted you correctly? What are the options for correcting incorrect
meta-data once data is ingested into ESG?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=558304916-01112010><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=558304916-01112010><FONT color=#0000ff
size=2 face=Arial>Jamie</FONT></SPAN></DIV>
<DIV><SPAN class=558304916-01112010><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><BR></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Karl Taylor [mailto:taylor13@llnl.gov]
<BR><B>Sent:</B> 29 October 2010 21:36<BR><B>To:</B> Kettleborough,
Jamie<BR><B>Cc:</B> Bentley, Philip; V. Balaji; martin.juckes@stfc.ac.uk;
go-essp-tech@ucar.edu; cmor@lists.llnl.gov; Kyle.Olivo@noaa.gov; Doutriaux,
Charles<BR><B>Subject:</B> Re: [Go-essp-tech] CMOR and cell_measures
issues<BR></FONT><BR></DIV>
<DIV></DIV>Dear Jamie and Charles (a couple of questions for you),<BR>
<BLOCKQUOTE
cite=mid:E51EDFEBF10BE44BB4BDAF5FC2F024B90250C2FB@EXXMAIL02.desktop.frd.metoffice.com
type="cite">
<META name=GENERATOR content="MSHTML 8.00.6001.18939">
<DIV dir=ltr align=left><SPAN class=994545009-29102010><FONT color=#0000ff
size=2 face=Arial>Hello Karl,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=994545009-29102010></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=994545009-29102010><FONT color=#0000ff
size=2 face=Arial>I think the recommended way to 'turn off'
ext_cell_measures is to make a call to cmor.set_variable_attribute(varid,
'ext_cell_measures', ''). Is that right? We are very tempted to
do this for all variables - so basically overriding the MIP tables.
How big a problem do you think this will be for data users - our grid is
pretty straight forward and users can calculate cell_areas from the
latitudes.</FONT></SPAN></DIV></BLOCKQUOTE><BR>Yes, if the cell areas stored
in areacella are not appropriate for a particular field, and the requested
output tables say that ext_cell_measure includes areacella, then you should
call the set attribute function to reset ext_cell_measures="". Isn't
that right Charles?<BR><BR>Why are you tempted to turn off the
ext_cell_measures for all variables? Then your output won't conform to
the CMIP5 requirements.<BR><BR>In the latest CMOR tables, I have removed
ext_cell_measures from all the variables that we don't expect always to be on
the standard mesh (i.e., on the grid for which areacella is correct).
This includes velocities and transports and closely related fields, which are
sometimes staggered relative to areacella. I would still be interested
in hearing a clear explanation for why there are additional fields carried on
a completely different grid. <BR><BR>If users must compute the cell areas for
only your grid, and for all others they simply read the areacella field in,
then you are creating a special case that is completely unnecessary.<BR>
<BLOCKQUOTE
cite=mid:E51EDFEBF10BE44BB4BDAF5FC2F024B90250C2FB@EXXMAIL02.desktop.frd.metoffice.com
type="cite">
<DIV dir=ltr align=left><SPAN class=994545009-29102010></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=994545009-29102010><FONT color=#0000ff
size=2 face=Arial>That aside, doesn't the approach of providing
alternative grid areas need more discussion?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=994545009-29102010></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=994545009-29102010><FONT color=#0000ff
size=2 face=Arial> 1. how should we produce these. The most
natural approach I can think of is to modify the fx MIP tables to add in
areacellb (or whatever we choose to call it) and then output through CMOR -
this will maximise the chance of consistency between different grid area
files for any one model. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=994545009-29102010></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=994545009-29102010><FONT color=#0000ff
size=2 face=Arial> 2. how should we reference these additional
areas from a variable.? I could call cmor.set_variable_attribute(varid,
'ext_cell_measures', 'areacellb') - but in the tests I've done on CMOR 2.4
this only does half the job: it puts the appropriate ext_call_measures
attribute into the file, but does nothing with
associatedFiles.</FONT></SPAN></DIV></BLOCKQUOTE>I don't think it is a high
priority to standardize this immediately. We will want CMOR to place the
fields in the subdirectory fx, so I need to check with Charles whether this
requires the variable to appear in table fx. If not, I would probably
build an entirely new table similar to fx, but with only the additional
variables. This way you won't have to modify your table if a new fx
table comes out. As for referencing these additional area variables, I
think if you include area: <area_name> in the ext_cell_measures
attribute, then if CMOR isn't already doing this, Charles can modify
construction of associated_files to include something following the template
"<area_name>:
<area_name>_fx_IPSL-CM5_historical_r0i0p0.nc" What do you
think, Charles?<BR>
<BLOCKQUOTE
cite=mid:E51EDFEBF10BE44BB4BDAF5FC2F024B90250C2FB@EXXMAIL02.desktop.frd.metoffice.com
type="cite">
<DIV><SPAN class=994545009-29102010></SPAN> </DIV>
<DIV><SPAN class=994545009-29102010><FONT color=#0000ff size=2
face=Arial>Clearly these may have been things you were going to cover - but
ran out of time to, in which case sorry.</FONT></SPAN></DIV>
<DIV><SPAN class=994545009-29102010></SPAN> </DIV>
<DIV><SPAN class=994545009-29102010><FONT color=#0000ff size=2 face=Arial>I
think another scenario that still needs some thought is one where a data
provider has submitted data and published it in ESG. They then realise
they made a mistake - they should have turned ext_cell_measures off, but
didn't (or visa-versa). What happens in this case? (We have kind of
done this in that we have send data with incorrect cell_measures to the
BADC - but have caught the issue before ingestion into ESG - I
don't believe we will always be this lucky). You'll
probably see through why I'm asking this question about meta-data updates
again now, so I may as well be explicit... If we choose to turn off
ext_cell_measures for all our diagnostics on this initial submission - what
are our options for recovering from this if we later found the decision
to submit without ext_cell_measures was making our data hard to
use?</FONT></SPAN></DIV></BLOCKQUOTE><BR>Please don't turn off
ext_cell_measures (in general). I think you could easily write a
script to remove the cell_measures attribute using netCDF tools, but adding it
would require rewriting the entire file.<BR><BR>Best regards,<BR>Karl<BR>
<BLOCKQUOTE
cite=mid:E51EDFEBF10BE44BB4BDAF5FC2F024B90250C2FB@EXXMAIL02.desktop.frd.metoffice.com
type="cite">
<DIV><SPAN class=994545009-29102010></SPAN> </DIV>
<DIV><SPAN class=994545009-29102010></SPAN><FONT face=Arial><FONT
color=#0000ff><FONT size=2>J<SPAN
class=994545009-29102010>amie</SPAN></FONT></FONT></FONT><BR></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(0,0,255) 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Karl Taylor [<A
class=moz-txt-link-freetext
href="mailto:taylor13@llnl.gov">mailto:taylor13@llnl.gov</A>]
<BR><B>Sent:</B> 29 October 2010 02:15<BR><B>To:</B> Bentley,
Philip<BR><B>Cc:</B> V. Balaji; <A class=moz-txt-link-abbreviated
href="mailto:martin.juckes@stfc.ac.uk">martin.juckes@stfc.ac.uk</A>; <A
class=moz-txt-link-abbreviated
href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</A>; <A
class=moz-txt-link-abbreviated
href="mailto:cmor@lists.llnl.gov">cmor@lists.llnl.gov</A>; <A
class=moz-txt-link-abbreviated
href="mailto:Kyle.Olivo@noaa.gov">Kyle.Olivo@noaa.gov</A>; Doutriaux,
Charles; Kettleborough, Jamie<BR><B>Subject:</B> Re: [Go-essp-tech] CMOR
and cell_measures issues<BR></FONT><BR></DIV><FONT
face="Times New Roman">Dear all,<BR><BR>I meant to try to address all the
stuff in this discussion, but won't have time today. This email is
just to say that I think we should insist that the cell_area files
(areacella and areacello) be placed in the archive, even if there are also
gridspec files. The ext_cell_measures attribute should also be
included for fields that are on the "standard" grid (i.e., the one with
the cell areas stored in areacella or areacello). If there are other
fields for which the standard areas are inappropriate and where your
scientists think it is important to provide cell areas, then I recommend
that you create specially named variables and place them in the "fx"
subdirectories. For variables not on the "standard" grid
(i.e., the grid of areacella or areacello), you should "turn off" the
ext_cell_measures attribute.<BR><BR>I don't expect most groups to produce
gridspec files, so most analysts will be looking for areas in the
areacella and areacello variables, not the gridspec files. This is
why you should write the areacella and areacello files even if you also
write the gridspec files.<BR><BR>Also, could you please explain why you
prefer not to duplicate the "fx" fields in each experiment's directory
tree. <BR><BR>Best regards,<BR>Karl<BR></FONT><BR>On 10/25/10 7:12 AM,
Bentley, Philip wrote:
<BLOCKQUOTE
cite=mid:E51EDFEBF10BE44BB4BDAF5FC2F024B9036364A5@EXXMAIL02.desktop.frd.metoffice.com
type="cite"><PRE wrap="">Hi Balaji,
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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.
</PRE></BLOCKQUOTE><PRE wrap="">Nope, not a done deal yet :-(
In line with the CMIP5 expt design doc, we don't really need to provide
gridspec files since all our model output is on either regular or
uniform grids (i.e. simple cartesian product of lat & long).
However, this whole cell_measures business prompted me to revisit the
gridspec tools and output, which reminded me that the gridspec netcdf
files include a cell area variable. Which in turn means we wouldn't need
to provide a separate file (or files) for cell areas. Hence we could
drop the ext_cell_measures attribute from our CMIP5 output files.
Using the gridspec tools may be a quick and easy way for us to provide
cell area info if we need to.
Caveat: from a quick glance it looks like the netcdf files produced by
the gridspec tools are not CF compliant. Is this is an issue? Presumably
it is if we want all the data in the CMIP5 archive to be CF compliant.
(NB: it could be I'm not running with the very latest version of the
tools - but I couldn't see a more recent version on the gfdl web site).
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">You know of course that gridspec says you can supply
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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
</PRE></BLOCKQUOTE><PRE wrap="">as one single supergrid...
</PRE></BLOCKQUOTE><PRE wrap="">If I could figure out how to output all 7 or 8 atm/ocn (sub-)grids to a
single netcdf file I would, but the available documentation (e.g. for
make_hgrid) isn't clear on this point. Sorry, that's probably just me
being dumb! But if there is updated documentation then please point me
to it. If necessary I could concatenate variables afterwards using NCO
tools.
Right now I'm trying to figure out how to create a gridspec file for our
HadGEM2 ocean model, which uses a stretched (i.e. tartan/plaid) grid:
longitudes are evenly spaced, latitudes vary from 1 deg to 1/3 deg.
(Looks like I need to use the --my_grid_file option to supply the
lat/long coords).
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">But if you're doing gridspec at all, I will concede this
point:-). Let's both do these separate gridspecs for now.
</PRE></BLOCKQUOTE><PRE wrap="">Works for me.
I think we're suffering from 'early-adopter syndrome' :-/
Cheers,
Phil
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Bentley, Philip writes:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Hi Karl,
A somewhat belated follow-up question in connection with
</PRE></BLOCKQUOTE><PRE wrap="">this proposal
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">(and with some slight overlap with Jamie's email which
</PRE></BLOCKQUOTE><PRE wrap="">crossed on the
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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
</PRE></BLOCKQUOTE><PRE wrap="">change from one
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">simulation to the next using the same model (HadGEM2-ES in
</PRE></BLOCKQUOTE><PRE wrap="">this case).
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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 -
</PRE></BLOCKQUOTE><PRE wrap="">or lots of
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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
</PRE></BLOCKQUOTE><PRE wrap="">likely to
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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,
</PRE></BLOCKQUOTE><PRE wrap="">so I'm now
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap="">
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>