[MITgcm-devel] towards better MatLAB post-processing

[Ed Hill]

On Wed, 2005-12-14 at 19:34 -0500, Jean-Michel Campin wrote:
> >   'compact'  ::
> > 
> >     this format is going to be specified by JMC and it is meant
> >     to be a compact vector of values that contains every value
> >     (inc. all corner points) without any redundancies and in a
> >     specified order (rank/shape)
> > 
> >     eg.  res = rdnctiles('state*','U',[36000], 'compact')
> >          size(res.U) --> order specified by JMC
> > 
> 
> Just to summarize what the "compact" form could be:
> 
> store any 2D variable in a long vector fld2d(Nb_of_H_gridpts,1)
> store any 3D variable in an array of the shape long-vector x Nr :
>                                        fld3d(Nb_of_H_gridpts,1,Nr)
>  (might be interesting to keep this 2nd dimension, even if it's
>   always 1, so that a 3D field is still stored in a 3.D array)
> where Nb_of_H_gridpts is the total number of grid-points in
> the horizontal grid.

OK, sounds good.

> The ordering (inside this long vector) that I was thinking is:
> a) grid-cell center (tracer point):
>  face(1),face(2), ... ,face(6) (if 6 faces)
> and for each face, dimension Fx x Fy:
>  ([1:Fx],1),([1:Fx],2), ... , ([1:Fx],Fy)
>  (this is just the usual ordering in fortran)

Yes, sounds good!


> b) grid-cell edges (vector on C-grid) : this is in fact not
> different, because the Western U & Southern V edge grid-point
> (that are shared by 2 faces) on one face will have to correspond
> to an Eastern or Northern edge (not necessary in this order) on the
> other face.
> In short, the same ordering as for tracers is fine.

I'm a little uncertain about the vector quantities.  Is it true that the
sN[xy]+1 points will always be owned by an adjacent tile?  For instance,
what happens to a domain with an open (and non-periodic) boundary?  Will
that boundary edge (which has no neighbor) be owned by no-one?

And, do we intend to limit ourselves to tile topologies were tiles must
be arranged in such a way that the UV "+1" points _have_ to be owned by
a neighbor?  It may not be a big deal to make such a choice.  In fact,
it may be a perfectly reasonable thing to do.  I just want to make the
point now so that we see the implications of our choices.


> c) grid-cell corner (vorticity point) :
> The more convenient way would be to start with the same ordering
> as for tracers, and to add, at the end, the corners that have not
> yet been counted (= "missing corners"), and list them in the same
> order as the face they belong to (= the first face where it
> appears).
> This would give, for a cubed-sphere grid (which has 2 additional
> corners c1,c2):
>  face(1),face(2),face(3),face(4),face(5),face(6),c1,c2
> 
> Alternatively we could choose:
>  face(1),c1,face(2),c2,face(3),face(4),face(5),face(6)

I like the latter because it keeps faces "together".  But it doesn't
really matter so long as we all agree on a convention, whatever it
is.  :-)


> This is inspired by my experience with cubed-sphere grids,
> but might not be the best solution for grids with less
> corner points than tracer points (case where more than 4 faces
> share 1 corner).

If you folks think the above is workable then I'll write a few MatLAB
routines that:

 1) add to rdnctiles() so that one can read mnc output and 
    return all variables in the above "compact" format

 2) a routine that will do the conversion:
      "compact" format  -->  "per-face" format

 3) a routine that will do the conversion:
      "per-face" format  -->  "compact" format

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