[MITgcm-support] Curvilinear grid file formats

[Jean-Michel Campin]

Hi Jeff,

I think the old thread you found is pointing to the main justification for extended grid-file 
size (i.e., Nx+1 x Ny+1), since cubed-sphere grid contain 2 "missing corners" that are missing
from the standard input file Nx x Ny.

Regarding grid-angles, they have been added after the new GRID_IO was added, so we found that 
there was not enough interest to add them in the OLD_GRID_IO section.

Regarding the "too many" grid files that the "new" GRID_IO code requires when using default exch1,
I think it's more like a bug than a feature: 
1) For simple topology domain (single facet, not cubed-sphere like) like yours, if you just compile 
  pkg/exch2 (and no need to use a "data.exch2" since default will work), then you will need only 
  1 single grid-file.
2) without pkg/exch2 (i.e., using default exch1), the "new" GRID_IO code has been written to accomodate
 a 6 tile, 6 facet cubed-sphere domain. But if we don't use "useCubedSphereExchange=T" this does not
 make much sense, I agree. Will submit a PR to fix this.

Cheers,
Jean-Michel

On Tue, Aug 04, 2020 at 09:05:47PM +0000, Jeffery R Scott wrote:
> Hi all,
> 
> Was trying to convert an existing curvilinear setup which used  #define OLD_GRID_IO to the ???new" compact format. This is a single domain of 210x192. EXCH2 is not activated.
> Initially setting up for a single proc/tile.
> 
> I found an old thread (http://mailman.mitgcm.org/pipermail/mitgcm-support/2013-July/008420.html) which addressed my first problem,
> namely that the new compact format requires fields (Nx+1,Ny+1) whereas old is (Nx,Ny). FWIW I did not get any difference (in mach prec)
> when I filled in the Nx+1 and Ny+1 fields for XG and YG (which was unclear in thread discussion). A bit curious that the new way requires angleCS and angleSN
> but not required in the old way.
> 
> However when I went to 80 procs/mpi the code wanted 80 grid files with extensions face001.bin, face002.bin etc. rather than accepting a global file
> (I specify horizGridFile). I did not see a way to get around this in the code, is there?
> 
> As an aside, most things in MITgcm with a switch named as *OLD* indicate something obsolete (often inferior) and kept for backward compatibility.
> In this instance, it seems OLD_GRID_IO might actually be the easiest way to set up this grid, and perhaps a more appropriate name should
> be chosen for this CPP option?
> 
> Jeff

> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support