[MITgcm-devel] mnc and "global" files

[Ed Hill]

On Thu, 2005-09-08 at 10:34 -0400, Jean-Michel Campin wrote:
> Hi Baylor, Ed, and others,
> 
> > So, you can have four processors
> > per tile which requires an additional indexing...which I recommend
> > denoting with a p.
> 
> No. You can have several tiles per processor, but not more than
> 1 processor per tile.
> 
> And regarding the sync. of pickup/state/tave, I am not sure that I fully
> understand the point, and right now, I don't see it as an improvement.
> And suppose we have the possibility to decide when to cut and create
> a new state.*.nc file (=as Ed proposed), you can always set this
> frequency = to (a multiple of) the pickup frequency, and this will do
> what you want. Does this make sense or did I miss something ?
> 
> Ed, I have 2 remarks/questions:

Hi Jean-Michel (& Chris who we'd like a vote from below),

OK, just to summarize our discussion today:

> 1) What do we do when there is only 1 face (90 % of the MITgcm users
>  don't run a "cube" like set-up, and don't use exch2):
>    a) do we drop the face ".f000001." piece ?
> or b) do we keep it whatever the set-up is ?

Yes, no problem.  We can easily drop the face index when there is only
one face.

> 2) I don't recommend to use 6 digits for the face number, and
> I think 3 is enough (i.e. .f001. , .f002. ...):
> - this is specially relevant if we choose to always have this face
>   number (solution b of question 1) in the file name.
> - this will make things more clear: global file / face =
>   larger file but fewer of them, and with shorter name, as opposed
>   to local files per tile.

OK, in C syntax it all boils down to:

  I prefer:    for TILES: ".t%06d."  for FACES: ".f%06d."
  You prefer:  for TILES: ".t%03d."  for FACES: ".f%06d."

so, as we discussed, lets ask Chris to cast the deciding vote.  Really,
its not a big deal either way.  So what do you want, Chris?

> 3) my recent experience with fields that don't fit into the
> Nx x Ny array structure (like vorticity on the cube), is that
> it's much more convenient to use a compressed form (nc*nc*6+2,Nr)
> than a faced structure (nc+1,nc+1,Nr,6) (<- especially the face
> after the k index is a pain). One of the advantages of the
> compressed form is that it can also be used for unstructure grids.
> This comes more as a post-processing / matlab issue.
> But regarding the choice of global file / face, I just want to be
> sure that we are aware of the alternative (= toward unstructure
> grids: Nb of horizontal grid points x Nb of levels), and that we
> don't change your mind before finishing the implementation of
> the 1rst choice.

OK, this item (#3) is now a discussion of how we handle the data layout
inside MatLAB.  So its orthogonal to our discussion of how we format the
MNC/netCDF files.  I just want to point that out.

And I'm fine with your above preference for a vector-oriented way of
handling things within MatLAB.  It is compact and it is very general.
And as long as we drag along enough metadata (using MatLAB cells or
structs or whatever), then we can readily convert (read or write) from
this layout to our netCDF files.  So I'm fine with it.

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