[MITgcm-support] MNC grid boundaries with curvilinear coordinates

[David Huard]

Hi Martin,

It seems to me that the grid definition and the conditions imposed at the
boundaries are two separate issues. That is, I can impose periodic BC
without having cyclical coordinates.

My point is that the current setup breaks the expectation that (XC[i,j],
YC[i,j]) is within the polygon formed by [(XG[i,j], YG[i,j] ), (XG[i+1, j],
YG[i+1, j]), (XG[i+1,j+1], YG[i+1, j+1]), XG[i,j+1],YG[i,j+1])]. I'm not
going to argue further since I understand changing this would break
backward compatibility for many users. One way out would be to define new
variables in the CF spirit: X_bnds, Y_bnds (see
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch07.html).

Cheers,

David







On Mon, Feb 25, 2013 at 4:09 AM, Martin Losch <Martin.Losch at awi.de> wrote:

> David,
>
> it's great to see python output in this matlab-dominated community (o:
>
> It's not a bug, it's a feature: the default boundary conditions for the
> MITgcm are double periodic so that the point at i=nx+1 is identical to the
> point at i=1, and the same for the j-direction. In the mnc-package, the
> output for variable on u and v-points of each tile is augmented by the
> first column/row of the neighboring tile, as a service (o: The last tile in
> x get's the first column of the first tile in x, and the coordinate it
> necessarily XG(1) = XG(end) - Lx.
>
> If your domain it periodic, that's what you want, right? If not, you can
> just ignore the last column. In fact, the standard mds output (the
> *.data/meta files) do not have these extra columns for any of the
> variables, neither for XG/YG.
>
> Martin
>
> On Feb 22, 2013, at 5:21 PM, David Huard <david.huard at gmail.com> wrote:
>
> > Hi all,
> >
> > I'm using the MITgcm on the Arctic domain and I noticed an issue with
> the netcdf output grid variables XG and YG.
> >
> > The last row and column of XG and YG are just copies the first row and
> column, as if it was a pac-man domain. Here is an example:
> >
> > array([[  31.97116089,   32.10241318,   32.23471451, ...,  146.66885376,
> >          146.80964661,   31.97116089],
> >        [ 31.77091026,   31.90175247,   32.033638  , ...,  146.87324524,
> >          147.01361084,   31.77091026],
> >        [ 31.57006645,   31.70048714,   31.83195305, ...,  147.07829285,
> >          147.21824646,   31.57006645],
> >        ...,
> >        [ -48.62563324,  -48.77060318,  -48.91656113, ..., -129.88247681,
> >         -130.03565979,  -48.62563324],
> >        [ -48.7310524 ,  -48.87626648,  -49.02246475, ..., -129.77496338,
> >         -129.92831421,  -48.7310524 ],
> >        [  31.97116089,   32.10241318,   32.23471451, ...,  146.66885376,
> >          146.80964661,   31.97116089]])
> >
> >
> > The consequence is that the last row and column of the tracer
> coordinates (XC, YC) do not lie in between the surrounding grid
> coordinates, which is what I would be expecting.
> >
> > Note that I generated the full grid using the python gluemncbig script.
> >
> > Cheers,
> >
> > David Huard
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20130225/5fb2f2c2/attachment.htm>