Compiling the OA package in a linux box

Discussion on computers, ROMS installation and compiling

Moderators: arango, robertson

Post Reply

Compiling the OA package in a linux box

#1 Post by RubenDiez-Lazaro » 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 <
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 ... f-f77.html
the function "NF_PUT_ATT_TEXT" is defined by this way:

Code: Select all

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:

Code: Select all

-at line 314:

Code: Select all

-at line 359:

Code: Select all

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

Code: Select all

     &                         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:

Code: Select all

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

Code: Select all

-at line 595:

Code: Select all

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...

User avatar
Posts: 3683
Joined: Wed Jul 02, 2003 5:29 pm
Location: IMS/UAF, USA

#2 Post by kate » Thu Jun 22, 2006 9:55 pm

oa <
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).


#3 Post by RubenDiez-Lazaro » 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:

Code: Select all

 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...



Post Reply