[MITgcm-support] problem running verification

[Jaime Palter]

Ed,

Thanks so much for your comments.  I have the answers to some of the
questions you pose, which could clarify what the problem may be.  I have
interspersed them with our other messages (*in between asterics* for
clarity)

>> However, when I tried to run exp1, which is configured to run for 4 time
>> steps, the output seemed all wrong.  The first ambiguous output is that
>> at the end of the run, ncdump shows all ITERS = [0,10] and all T = [0,
>> 1200], when I thought there should be 4 iterations.  In addition all the
>> variables seem to have "blown up," for the second recorded time step.
>> The velocity and sea surface (etc.) height are infinity or negative
>> infinity at all grid points.
>
> This is just a guess (would need to get more info to confirm), but it
> sounds like a byte-swapping (endian-ness) problem.  By convention,
> MITgcm stores and reads all its non-NetCDF binary files in big-endian
> format.  So, on a big-endian system no byte-swapping is needed and on a
> little-endian system we need to byte-swap the information when its read
> and before its written.
*****************
Yes, this is why we rebuilt the windx.sin_y file (and topog.box file) just
in case the binaries weren't compatible. However, they still didn't work.
Indeed, since we are a sun sparc, it seems we shouldn't need to regenerate
these in any case. Are there other input files (perhaps not in the
input directory) that the experiment is using that might not be
compatible?
*******************

> So, what sort of Sun do you have?  Suns with Sparc chips are big-endian
> and need no byte-swapping.  The new Suns with AMD Opteron chips are
> little-endian (same as Intel) and need byte-swapping.

***********
Everything else I see is an ascii file and is thus ok.
***********

>   http://mitgcm.org/testing.html
***********
I checked out this site, but couldn't find an answer to this problem
***********

> currently includes examples of both Suns with Sparc chips ("sun4u") and
> (non-Sun but doesn't really matter) AMD64 machines.
>
> Ed
>
> --
> Edward H. Hill III, PhD
> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
>              Cambridge, MA 02139-4307
> emails:  eh3 at mit.edu                ed at eh3.com
> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> phone:   617-253-0098
> fax:     617-253-4464
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support



--------
Mark S.C. Reed
Research Scientist
UNC-Ch ITS/Research Computing
Renaissance Computing Institute (RENCI)
919-843-5113
markreed at unc.edu