Annotation of /MITgcm_contrib/gael/profilesMatlabProcessing/netcdf_ecco_GenericgridNOTEONOVERLAPCORNERS

In general: the overlap corners are perillious for any field located on tracer points.
       They are never actively used in the model computation so the values there
       can be meaningless in forward mode or in adjoint mode -- only the exchange
       can make a difference there.
       Using a regular lat/lon grid and exch "1", you find the expected value
       (corner of another tile) but this cannot be expected in general.
       In the Cube Sphere topology for example, the overlap corner values simply
       do not correspond to a model grid point!!! The exch2 routines then put a
       default value there or copy a neighboring value. This is true for XC and
       YC after they have been exchanged for example.
=> we are never going to use the values that are found in the overlap corners,
either for XC/YC or for T/S
1	gforget	1.1	In general: the overlap corners are perillious for any field located on tracer points.
2			They are never actively used in the model computation so the values there
3			can be meaningless in forward mode or in adjoint mode -- only the exchange
4			can make a difference there.
5			Using a regular lat/lon grid and exch "1", you find the expected value
6			(corner of another tile) but this cannot be expected in general.
7			In the Cube Sphere topology for example, the overlap corner values simply
8			do not correspond to a model grid point!!! The exch2 routines then put a
9			default value there or copy a neighboring value. This is true for XC and
10			YC after they have been exchanged for example.
11			=> we are never going to use the values that are found in the overlap corners,
12			either for XC/YC or for T/S