[MITgcm-devel] NetCDF is cool

[chris hill]

Martin/Ed,

 Here is a quick summary of what is the plan on the naming thing:

 Our default for naming things in netCDF output should be to use the CF
convention metadata labels discussed here:

http://www.cgd.ucar.edu/cms/eaton/cf-metadata/index.html

and described in detail here

http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/standard_name.html

 Where these rules break Ferret/ingrid or are dumb and stupid etc.... we
will need to harass Eaton, Gregory, Hankin etc... at

http://echorock.cgd.ucar.edu/pipermail/cf-metadata/

and make a decision. We also are coordinating with ESMF and PRISM groups
on this topic.


Chris

On Tue, 2004-09-28 at 07:05, Ed Hill wrote:
> On Tue, 2004-09-28 at 06:16, Martin Losch wrote:
> > Hi Ed,
> > you wanted it that way, I'll keep sending you comments:
> 
> Yes, please keep the comments coming!  ;-)
> 
> 
> > 1. When I run an executable for the second time (without removing old  
> > files), I get this:
> > > MNC ERROR: variable 'XC_max' is already defined in file  
> > > 'monitor_grid.000001.nc' but using a different grid shape
> > > ABNORMAL END: S/R MNC_VAR_INIT_ANY
> > Now, it may be a good practice to remove all old output files, before  
> > you start a new run, so this may be intentional. But in case it isn't  
> > ...
> 
> Yes, its a safety feature.  And one elegant way to "fix it" is to use
> the "mnc_use_outdir" option described at:
> 
>   http://mitgcm.org/pelican/online_documents/node236.html
> 
> which will create a new and sequentially named directory containing all
> mnc output files each time you run the model.
> 
> 
> > 2. I think that it is a bit confusion to have different field sizes for  
> > Temp, U, V, but that's only my opinion. Since NetCDF is self  
> > explanatory, that's okay (o:
> 
> This feature was requested from the very beginning by Alistair and
> others.  The idea is that it would help reduce the number of "exchange
> type" operations needed during post-processing because you would have
> the n+1 velocities for the C-grid on each tile.
> 
> 
> > 3. As far as the coordinate variables are concerned: the only solution  
> > I see, is that in the case of aligned coordinates-grid (cartesian and  
> > spherical coordinates), there is one set of coordinate variables  
> > (XC,XG,YC,YG, ZC, ZG, all 1D vectors with dimension XC,YC,XG,YG,ZC,ZG),  
> > and in the case of a general orthogonal grid do it the way it's done  
> > now. It's probably a lot of work. Otherwise I agree, there is no  
> > general solution to this.
> > So for cartesian and spherical grids it could look like
> > dimension:
> > XC=sNx
> 
> [...snip...]
> 
> > As far as I know the smalles common denominator in terms of conventions  
> > is that coorindate variables (1D-vectors) and the corresponding  
> > dimensions have the same name.
> 
> Yes, I suppose it wouldn't be too hard to collapse the X[CG] and Y[CG]
> variables to vectors when the coordinate systems are aligned.  I'll add
> this to my to-do list!
> 
> 
> > 4. There is a list of attribute conventions in Section 8.1 of the  
> > netcdf manual:
> > http://my.unidata.ucar.edu/content/software/netcdf/guidef/guidef
> > -13.html#HEADING13-12
> > Not all of them are used by all tools, but I think, long_name, units,  
> > and missing_value are used by most in my experience. At least those are  
> > the ones that I always set, when I write netcdf output.
> 
> This (the setting of attributes) certainly *does* need work.  During our
> next documentation session (mid-October) it would be really helpful if
> the group could decide upon (even a preliminary) a set of variable names
> and attributes.
> 
> 
> > That's all for now.
> 
> Thanks again!  Feedback *is* helpful and appreciated!
> 
> Ed