[MITgcm-devel] NetCDF is cool
Martin Losch
mlosch at awi-bremerhaven.de
Tue Sep 28 06:16:59 EDT 2004
Hi Ed,
you wanted it that way, I'll keep sending you comments:
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
...
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:
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
XG=sNx
YC=sNy
YG=sNy
ZC=Nr
ZG=Nr
variables:
(coordinate variables)
float XC(XC)
float XG(XG)
float YC(YC)
float YG(YG)
float ZC(ZC)
float ZG(ZG)
(record variables)
double U(T,ZC,YC,XG)
double V(T,ZC,YG,XC)
double W(T,ZG,YC,XC)
double S(T,ZC,YC,XC)
etc.
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.
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.
That's all for now.
Martin
On Sep 27, 2004, at 8:01 PM, Ed Hill wrote:
> On Mon, 2004-09-27 at 04:41, Martin Losch wrote:
>>
>> I finally found some time to have a look at the MNC package. I am
>> really impressed. Works nice for me. I still have to learn how to add
>> output, but for a dumb user (like me) it's great.
>
> Hi Martin,
>
> Thank you for giving it a try!!!
>
> And please see:
>
> http://mitgcm.org/pelican/online_documents/node236.html
>
> for an up-to-date description of the namelist variables for turning
> on/off the various kinds of output.
>
>
>> May I make a suggestion regarding coordinate variables. You have
>> probably thought about this long ago, and I may not put forward
>> anything new. If that's so, tell me and I'll shut up.
>
> Your comments are appreciated!
>
> Please let us know about these things since we're still trying to sort
> out the best way to support the various NetCDF "conventions". Its not
> at all clear to me what is the best way of formatting the output for
> the
> various NetCDF plotting packages:
>
> eg.: INGRID, Ocean Data View, MatLAB, ferret
>
> that people want to use.
>
>
>> You probably know about this coordinate and record variable stuff so I
>> might be carrying coal to Newcastle, forgive me: A netcdf-variable is
>> called a coordinate variable, when it has the same name as the
>> corresponding dimension, e.g. if you call your netcdf-dimension 'X',
>> you can call a variable X(of length X) and this is then a coordinate
>> variable (I get my infromation from the NetCDF 3.3 or 3.5 user manual,
>> I forget). The cool thing about this is that tools such as ncview (
>> http://meteora.ucsd.edu:80/~pierce/ncview_home_page.html ), usually
>> recognize these coordinate variables and 1. do not display them and 2.
>> use the information to display other non-coordinate variables. For
>> example:
>> netcdf-dimension x,y,time (time being a record dimension)
>> coordinate-variables x(x), y(y), time(time)
>> record-variable theta(time,y,x)
>> will then be displayed automatically with the correct coordinates by
>> ncview, ncbrowse, ferret and whatever tools there are. At the same
>> time
>> a variabe time(time,y,x) would be (and is) treated as a coordinate
>> variable, and not displayed. This happens with variabe T and dimension
>> T in the state.*.nc file. I realize that you cannot use coordinate
>> variables properly because of the general orthogonal horizontal
>> coordinates that should also take into account the cube-sphere case,
>> but giving the record-dimension andthe temperature variable the same
>> name T is a bit unfortunate for the above reasons.
>> What do you think?
>
> OK, I just checked in a fix for "T" ==> "Temp".
>
> And I think that the all the names and conventions we use ought to be
> reviewed. Please critically review whats there! ;-)
>
> Also, virtually all plotting packages expect the grids to be aligned
> with the coordinate system and, in the general case, our grids just
> aren't. The only truly general solution that I see to this problem is
> to use a tool such as NCO:
>
> http://nco.sourceforge.net/
>
> to post-process the output so that it fits within the conventions used
> by each plotting program. I know thats not convenient, but is it
> really
> possible to come up with a sufficiently generic/general set of names
> and
> attributes that will satisfy even a majority of the popular plotting
> packages for all of our model/grid geometries...?
>
> If you can think of better solutions (or even more small improvements
> as
> with the "T"==>"Temp" case), then that would be very helpful and I'll
> do
> everything I can to implement them.
>
> thanks again,
> Ed
>
> --
> Edward H. Hill III, PhD
> office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
> Cambridge, MA 02139-4307
> emails: eh3 at mit.edu ed at eh3.com
> URLs: http://web.mit.edu/eh3/ http://eh3.com/
> phone: 617-253-0098
> fax: 617-253-4464
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list