<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Thanks Martin, that definitely makes sense for the per-tile output. My confusion came with the glued output, and I think I've now figured it out. </p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">The gluemnc script (utils/scripts/gluemnc) produces glued files where Xp1 and Yp1 are the same size as X and Y respectively. The gluemncbig script (utils/python/MITgcmutils/scripts/gluemncbig) produces glued files where
Xp1 and Yp1 are one larger than X and Y. </p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">I'm not sure which is more "correct" for glued files covering the entire domain, but it does explain why an old NetCDF grid file I was given (generated using MNC and gluemnc) had different Xp1 and Yp1 dimensions to the
one I generated myself using gluemncbig.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Many thanks again,</p>
<p style="margin-top:0;margin-bottom:0">Kaitlin</p>
<p style="margin-top:0;margin-bottom:0"></p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> MITgcm-support <mitgcm-support-bounces@mitgcm.org> on behalf of Martin Losch <Martin.Losch@awi.de><br>
<b>Sent:</b> 23 May 2018 15:58:01<br>
<b>To:</b> MITgcm Support<br>
<b>Subject:</b> Re: [MITgcm-support] Inconsistent sizes between MNC and binary output</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">That’s not a bug, that’s a feature. I don’t think that you can turn it off.<br>
<br>
The point at nx+1 is the same as point 1 either on the adjacent tile or (if you have only one tile) on the current tile. It help computing velocities or their gradients at cell centres. In more complicated topologies (cubed sphere) it is convenient because
you don’t have to sort out the connectivity between tiles for these computations. MDS output does not have this feature.<br>
<br>
Martin<br>
<br>
> On 23. May 2018, at 15:20, Naughten, Kaitlin A. <kaight@bas.ac.uk> wrote:<br>
> <br>
> Hi everyone,<br>
> <br>
> I've noticed something strange when running MITgcm using binary output vs MNC output. MNC includes the easternmost and northernmost points of the Xp1 and Yp1 axes, so they are one longer than the X and Y axes. Binary output lops these points off, so Xp1 is
the same size as X, and Yp1 is the same size as Y. The same is true for all variables on the u, v, or psi grids. So even though it's a C-grid, all the output arrays are the same size.<br>
> <br>
> Is there some namelist flag I am missing so that the two output methods agree on the dimensions? I would like to be able to switch between MNC and binary, and still use the same plotting scripts.<br>
> <br>
> Many thanks,<br>
> Kaitlin Naughten<br>
> This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material
supplied to NERC may be stored in an electronic records management system.<br>
> _______________________________________________<br>
> MITgcm-support mailing list<br>
> MITgcm-support@mitgcm.org<br>
> <a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
<br>
_______________________________________________<br>
MITgcm-support mailing list<br>
MITgcm-support@mitgcm.org<br>
<a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
</div>
</span></font></div>
</div>
<hr>
<small>This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material
supplied to NERC may be stored in an electronic records management system</small>.
<hr>
</body>
</html>