[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20050404: Poe problem with netcdf

Unidata Support <address@hidden> writes:

> ------- Forwarded Message
>
>>To: address@hidden
>>From: "Wright, Dan" <address@hidden>
>>Subject: Poe problem with netcdf
>>Organization: UCAR/Unidata
>>Keywords: 200504041159.j34BxTv2027743
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_000_01C5390D.B68980F0
> Content-Type: multipart/alternative;
>       boundary="----_=_NextPart_001_01C5390D.B68980F0"
>
>
> ------_=_NextPart_001_01C5390D.B68980F0
> Content-Type: text/plain
>
> Hi and Help!:
>
> I've been struggling with installing OPA on an IBM SP machine for the past
> week -- a long week.  For a long time my problems were associated with
> just getting OPA to compile on the SP, but now I've reached the point where
> the opa executable is about to be linked to netcdf.  At this point, I get
> the message "Undefined initfini symbol: poe_remote_main".

Sorry, I'm not familiar with OPA, but poe_remote_main is not a part of
netCDF.

>
> I've gone back to NETCDF and recompiled it (many times) and I've reached
> the point that I think I have successfully compiled in real*8 (real*8 
> is required for the OPA code) but when I type "make test" I eventually get 
> the same undefined initfini message as I get when OPA tries to link to
> NETCDF.
> I don't know if both problems are related to netcdf or if they are both
> caused 
> by some poe error that I'm making, but I figure I'd better get it working in
>
> netcdf before going to the next stage.

The problem seems to be with the F90 interface. Do you need the F90
interface?

>
> In the hope that you can help me with this problem, I've
> attached some files to provide information on what I've done.
>
> I'm using version 3.6.0-p1 of netcdf so I think I'm up to date.  As you'll
> see 
>>From the log file I'm on an SP machine running AIX.
>
> out_configure is the standard output produced when I  type ./configure 1>
> out_configure in the src directory.
> config.log is the log file produced during the same step.
> out_make_test_src and err_make_testsrc are the standard output and standard
> errors produced when I type 'make test 1> out_make_test_src 2>
> err_make_test_src'.
>
> In addition to the poe problem (which I hope is just that I need to set some
> environment variable or something like that) I am also troubled by the
> requirement for real*8.  For a test without parallel processing, I used
> xlf_r rather than mpxlf_r, and similarly for the other compilers.  I then
> compiled using the option -qautodbl = dbl4, but when I tried 'make test' I
> got error messages related to oversized objects.  When I recompiled with
> -qautodbl = dbl, these errors were eliminated.  Can you tell me if the code
> obtained with -qautodbl = dbl4 is bad or if this is a problem with the test
> program. (I would send the files for this test case, but I'm afraid it would
> just confuse things -- and I'm confused enough.)
>
> I hope you can help. 
>

I don't know if netCDF will even work with real*8. Sorry, but I've
never tried it. However, if you can get the tests to pass, that would
be a good sign.

Since I don't know where the poe function resides, I don't think I can
help you much there.

Sorry,

Ed
-- 
Ed Hartnett  -- address@hidden