Ocean Modeling Discussion


Search for:
It is currently Fri Jul 19, 2019 1:50 am

Post new topic Reply to topic  [ 3 posts ] 

All times are UTC

Author Message
PostPosted: Wed Jun 21, 2006 2:50 pm 
I compile the code from de OA package on a linux box (debian sarge) with
the g77 compiler version 3.3.5 using the command
make -f Makefile.Gnu

When I try execute the program with
oa <oa.in
the system returns:

Then, i decided to investigate some extrange messages i watch at compiling
time. Here is that i found:

According to the unidata manual for the f77 version of the netcdf library at
the function "NF_PUT_ATT_TEXT" is defined by this way:

look that the function has 5 arguments.

Despite, in the file "def_oa.F" there are some calls to this function that
don't follows this prototipe:
-at line 240:

-at line 314:

-at line 359:
     &                       'lon_rho, scalar',rcode)

-at line 418:
     &                         text(1:lstr),rcode)

now, the function is called with 6 arguments, and some of them don't match
the type...

what's the way to correct this mismatch?

In same file ("def_oa.F") is used a macro, "nf_put_var1_FTYPE", defined in
the file "cppdefs.h" that in my case is expanded to "nf_put_var1_double".
According to the unidata manual for the f77 version of the netcdf library,
this function is defined like:

In the file "def_oa.F" this function is used, among others,:
-at line 593:

-at line 595:

when "nord" and "nfrq" are integers defined at the "inppar.h" file

Can we make a cast using the "dble()" function in order to transtale the
integers to doubles?
Perhaps we must use the "nf_put_var1_int" function instead?
Thanks for your time...

Reply with quote  
 Post subject:
PostPosted: Thu Jun 22, 2006 9:55 pm 
User avatar

Joined: Wed Jul 02, 2003 5:29 pm
Posts: 3633
Location: IMS/UAF, USA
oa <oa.in
the system returns:

I don't think the netcdf oddities have anything to do with it being killed. I would bet it has a lot more to do with running out of memory somehow. First of all, g77 doesn't support going over 2 GB in memory since it uses 32-bit addressing. Do you have that much memory or more? How much of it you can actually use might be set by the limits in your environment. Depending, the command to check this is either "limit" or "ulimit -a":

iceberg1 1% ulimit -a
time(seconds) 7200
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) unlimited
memory(kbytes) 1048576
coredump(blocks) 20000
nofiles(descriptors) 2000
iceberg1 2% limit
cputime 2:00:00
filesize unlimited
datasize unlimited
stacksize unlimited
coredumpsize 10000 kbytes
memoryuse 1048576 kbytes
descriptors 2000

I'm being limited to 1 GB by the operating system, even though I know there is more memory. If I need more, I have to run in a batch queue instead of interactively. You might try increasing the limits in case the default is less than the system maximum.

Another option is to see how big the arrays used by OA are. Is there a scratch space you can reduce? Or as a last resort I once divided up my domain using ncks and processed each chunk separately (with matlab, but it has the same kind of memory limits).

Reply with quote  
 Post subject:
PostPosted: Mon Jun 26, 2006 4:26 pm 
I think I get it working. Some considerations before explain
my (posible) solution:

1) Seems that the message returned by the system (KILLED) is
not caused by the inconsistency of types in functions
"nf_put_att_text" and "nf_put_var1_double".

2) I verified the ulimit configuration before writing the post:
Kate, pardon not to say it...

3) The KILLED condition seems be caused by the expansion of the
"BIGREAL" macro at file "oagrid.h" (in my system, expanded
to "real*8") ...
My solution consists in modify the "cppdefs.h" file of the OA
package in this way:
 1   !
 2      !======================================
 3   !  Copyright (c) 1996 Rutgers University
 4      !======================================
 5   !  Include file "cppdefs.h".
 6      !======================================
 7   !
 8   !  Choose appropriate C-preprocessing options by using command #define
 9   !  to activate option or #undef to deactivate option.
10   !
11   !  Define precision for numerics: size of floating-point variables.
12   !
13   #define DBLEPREC
14   !
15   !some definitions that seems work on my system (RDLazaro, USC)
16   !
17   #if defined linux
18   #undef DBLEPREC
19   #define DBLEPREC2
20   #endif
21   !
22   !  Undefine double precision flag for default 64-bit computers.
23   !
24   #if defined cray || defined CM2
25   # undef DBLEPREC
26   #endif
27   !
28   !  Set double/single precision for real type variables and associated
29   !  intrinsic functions.
30   !
31   #ifdef DBLEPREC
32   # define BIGREAL real*8
33   # define FLoaT dfloat
34   # define SQRT dsqrt
35   !
36   #elif def DBLEPREC2
37   # define BIGREAL double precision
38   # define FLoaT dble
39   # define SQRT dsqrt
40   !
41   #else
42   # define BIGREAL real
43   # define FLoaT float
44   # define SQRT sqrt
45   #endif
46   !
47   !  Set type of floating-point NetCDF functions.
48   ! 
49   #if defined DBLEPREC || defined DBLEPREC2
50   # define NF_FTYPE nf_double
51   # define nf_get_att_FTYPE nf_get_att_double
52   # define nf_put_att_FTYPE nf_put_att_double
53   # define nf_get_var1_FTYPE nf_get_var1_double
54   # define nf_put_var1_FTYPE nf_put_var1_double
55   # define nf_get_vara_FTYPE nf_get_vara_double
56   # define nf_put_vara_FTYPE nf_put_vara_double
57   #else
58   # define NF_FTYPE nf_real
59   # define nf_get_att_FTYPE nf_get_att_real
60   # define nf_put_att_FTYPE nf_put_att_real
61   # define nf_get_var1_FTYPE nf_get_var1_real
62   # define nf_put_var1_FTYPE nf_put_var1_real
63   # define nf_get_vara_FTYPE nf_get_vara_real
64   # define nf_put_vara_FTYPE nf_put_vara_real
65   #endif

I will comment the news lines:
- lines 16 to 20:
I define a new macro called "DBLEPREC2" in order to handle the
code on a linux box...
- lines 35 to 40:
I use "double precision" type instead "real*8", and the "dble"
function instead "dfloat"...
- line 49:
I modify this line in order to use the correct functions from
the netcdf library, also in the "DBLEPREC2" scheme...

I hope by useful for people in same problem. Also I would like
hear any commentaries to improve this (posible) solution...



Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group