This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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