[MITgcm-support] netcdf with curvilinear grid

[Ed Hill]

On Thu, 31 Jan 2008 08:34:30 +0100 Martin Losch wrote:
> 
> where in the jungle of mnc can I find a clue of what's happening,
> why for one tile/cpu, the j-ordering is one way and for the other
> it's reversed, what variables control that and where do they get
> their information from, so I can try to hunt this problem down.


Hi Martin,

Its 4am here.  I've already spent a long day coding and then looked
through MNC and MITgcm files just because you asked so *very*
politely.

I don't understand your problem.  Perhaps its lack of sleep.  But here
are some observations:

 0) The "gridfiles.tar" you sent is not a complete setup.  I 
    don't have the foggiest idea what topology (EXCH1 or EXCH2) 
    you are trying to use since you very helpfully omitted all 
    the input files or code that specify that information.

 1) When you think about the grids keep in mind that MNC does 
    not (anywhere!) "flip" or permute the grid quantities  
    during either reads or writes to the netcdf files.  The 
    netcdf files always have the same "orientation" in memory 
    within MITgcm as they do on disk -- just the addition 
    or removal of points around the halo regions.

    The only thing like "flipping" that MNC does is the storage 
    of the tile edge-edge coincidence information as provided by 
    either "EXCH1" or EXCH2.  You can use:

      cd pkg/mnc
      grep -i exch *.F

    to see where these occur within MNC.  And note that this 
    "flipping" does not permute anything *within* the per-tile 
    files.  It just specifies how the tiles are "sewn" together.

 2) Have you looked at the code in the following files:

      model/src/ini_curvilinear_grid.F
      pkg/exch2/w2_e2setup.F  (if using EXCH2)

    and convinced yourself that things have the same order within 
    the *.mitgrid files that the code expects?  Its a very good 
    place to start.


Ed

-- 
Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20080131/69739539/attachment.sig>