[MITgcm-support] problem running verification

[Ed Hill]

On Tue, 2006-01-24 at 15:20 -0500, Jaime Palter wrote:
> Hello all,
> 
> After downloading the MITgcm a few weeks ago from CVS, I have
> successfully compiled and  run verification exp0 on a Sun machine
> (single thread, single processor).
> 
> 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.
> 
> I am not getting any warnings or any errors and we have tried remaking
> windx.siny in genmake to no avail.  Does anyone have any advice?

Hi Jamie,

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.

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.

And, you might ask, how does one do this byte-swapping?  There are two
ways to do it in the optfiles.  One is to have your compiler do it by
asing the compiler to byte-swap all IO using a compiler-specific flag
such as:

  FFLAGS='-byteswapio'

and that requires support from the compiler (not all compilers have the
ability to do byte-swapping for you so you'll have to check).  And the
other is to let MITgcm do it by specifying the define:

  DEFINES='-D_BYTESWAPIO'

Please see all the optfiles in:

   MITgcm/tools/build_options

for examples of both.

Also, you should be able to get all of our verification suite working
with basically any sort of Sun machines.  Our routine testing:

  http://mitgcm.org/testing.html

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