oceanS on SGI

[yildirim]

Hi,

I have compiled ROMS on SGI recently, I have encountred several erros in three files because of AINT(......,r8) mathematical function. I have removed KIND option "r8" inside ANINT(*,r8) lines in these files, it worked nicely, and get executable file "oceanS",

then I just typed the following command

./oceanS < ocean_upw_in > & ocean_upw.out& at unix command line,

it gave me the following error:

Segmentation fault ./oceanS < ocean_upw.in >& ocean_upw.out (core dumped)

does anybody have some idea what it might be the cause?

how can I be sure that my installation are succesfully done,

thanks,

[ce107]

A very basic question: Have you tried resetting the stack limit to unlimited?

For the Bourne shell family:
ulimit -s unlimited
For the C-shell family:
unlimit stacksize

In many cases this solves the problem.

Constantinos

[yildirim]

Hi,

I tried "unlimit stacksize", and problem is still in there,

do you have any suggestion?

thanks,

[yildirim]

Hi,

I thought that I have set "stacksize" as unlimited, but it seems that I could not, do anyone have idea that this size " stacksize" might have problems ,

% limit

cputime unlimited
filesize unlimited
datasize unlimited
stacksize 524288 kbytes
coredumpsize unlimited
memoryuse 2173424 kbytes
vmemoryuse unlimited
descriptors 2500

% unlimit stacksize

% limit

cputime unlimited
filesize unlimited
datasize unlimited
stacksize 524288 kbytes
coredumpsize unlimited
memoryuse 2173424 kbytes
vmemoryuse unlimited
descriptors 2500

thanks,

[kate]

I can't imagine that UPWELLING is big enough for you to need a larger stacksize. It must be something else - I will try it on an SGI.

Edit: I tried it on:
IRIX64 video2 6.5 10070055 IP27

and could not reproduce the problem. I did run into linker troubles from mp_numthreads and another similar function from mp_routines:

#elif defined SGI
integer :: mp_numthreads

my_numthreads=mp_numthreads()
#else
my_numthreads=1
#endif

I just commented out the whole SGI section, letting it take the #else.

[ce107]

I can't imagine that UPWELLING is big enough for you to need a larger stacksize. It must be something else - I will try it on an SGI.

Edit: I tried it on:
IRIX64 video2 6.5 10070055 IP27

and could not reproduce the problem. I did run into linker troubles from mp_numthreads and another similar function from mp_routines:

#elif defined SGI
integer :: mp_numthreads

my_numthreads=mp_numthreads()
#else
my_numthreads=1
#endif

I just commented out the whole SGI section, letting it take the #else.

We just had a one-on-one debugging session with Gazi on this and it appears to be an issue with MIPSPro 7.3.1.2m runtime as the problem will not appear on more modern versions I have access to on other systems. Essentially the call to flush(6) for the stdout causes a seg fault!

On the issue hinted to above, ROMS as currently distributed will not link successfuly on an SGI unless "-mp" is used as a link-time flag as -DSGI causes calls to mp_*() SGI threaded library routines even for serial code.

Moreover, if one sets LARGE=on, the inclusion of empty libraries for the adjoint etc. causes further failures as these empty libraries are generated by default as n32(bit) objects while everything else is a 64bit object. Since "ar" doesn't have a flag to enforce a 64bit library generation, a trick needs to be used to omit these empty libraries from the link line.