Fortran - "make test" error wehn compiling NetCFD with Intel 8.1

Author

"make test" error wehn compiling NetCFD with Intel 8.1

Andry William

2004-09-20, 4:02 pm

Dear experts:

I have to compile the NetCDF libraries with Intel fortran 8.1 because the
main source code I have will need it. I have read all the installation
documentation given in the NetCDF web site. I have also managed to compile
the libraries with:
make

However, my problem comes when I need to verify the libraries using
make test

Everything seems OK besides the test on nf_****_real. I mean, the errors
are:

*** Testing nf_strerror ...
......
*** Testing nf_put_var1_real ...
Var value read not that expected
### 4 FAILURES TESTING nf_put_var1_real! ###
......
*** Testing nf_put_var_real ...
Numeric conversion not representable
Var value read not that expected
### 7 FAILURES TESTING nf_put_var_real! ###
......
*** Testing nf_put_vara_real ...
Numeric conversion not representable
### 7 FAILURES TESTING nf_put_vara_real! ###
.......
*** Testing nf_put_varm_real ...
Numeric conversion not representable
Var value read not that expected
### 7 FAILURES TESTING nf_put_varm_real! ###
.......
*** Testing nf_put_att_real ...
Numeric conversion not representable

att. value read not that expected
att. value read not that expected

### 3 FAILURES TESTING nf_put_att_real! ###
Total number of failures: 35
make[2]: *** [test] Error 1

Can somebody help and tell me what is wrong? How can I verify that
my libraries are OK?

Thanks in advance,

Andry

Paul Van Delst

2004-09-20, 4:02 pm

Andry William wrote:
> Dear experts:
>
> I have to compile the NetCDF libraries with Intel fortran 8.1 because the
> main source code I have will need it. I have read all the installation
> documentation given in the NetCDF web site. I have also managed to compile
> the libraries with:
> make
>
> However, my problem comes when I need to verify the libraries using
> make test

Hello,

<assumption>
I'm not familiar with the version number cross-talk between Windows and linux intel
compilers, so I'll assume you're compiling on a linux system. Mine is RH WSE 3.0.
</assumption>

I've compiled, tested, and used (a lot!) the netCDF library compiled with Intel v8.0 (not
8.1 yet). The settings I used were:

export FC=/opt/intel_fc_80/bin/ifort
export F90=/opt/intel_fc_80/bin/ifort
export FFLAGS="-O -mp -static-libcxa"
export F90FLAGS="-O -mp -static-libcxa"
export CPPFLAGS="-DNDEBUG -DpgiFortran"
export CC=gcc

The "-mp" flag is used to "maintain floating point precision (disables some
optimizations)" and the -static is (was?) necessary since the default behaviour was to
use/load/whatever the libcxa library dynamically which just didn't work (the details
escape me). It may be the -mp flag will do the trick (depending on how different the real
numbers are in the netcdf test suite comparisons), but that would sorta worry me since I
don't typically use the -mp flag in my own code.

The -DpgiFortran tag in CPPFLAGS is used simply because there is no officaly intel listing
in the cfortran.h file (although users have supplid updated cfortran.h files for download)
and, apparently, the calling convention/name mangling is (was?) serendipitously performed
the same way by both compilers.

If the above settings for a netCDF compile don't work on your system with the v8.1
compiler, it *may* be a good data point if you download the v8.0 compiler and try that to
help eliminate any system/OS issues.

Good luck and let us know what happens.

cheers,

paulv

Andry William

2004-09-21, 3:58 pm

Paul Van Delst <....> wrote in message news:

> so I'll assume you're compiling on a linux system. Mine is RH WSE 3.0.
> ...
Hi,
Sorry, I forgot to mention that I am using linux SUSE 9.0 with gcc 3.3.1
and intel fortran 8.1.

> export FC=/opt/intel_fc_80/bin/ifort
> export F90=/opt/intel_fc_80/bin/ifort
> export FFLAGS="-O -mp -static-libcxa"
> export F90FLAGS="-O -mp -static-libcxa"
> export CPPFLAGS="-DNDEBUG -DpgiFortran"
> export CC=gcc

Thank's for this information. My early problem came from the fact that
I did not set the FC nor the FFLAGS environment. In fact I thought the
configuration will use the g77 but it seems like it is necessary to set
it equal to the Fortran 90 compiler.
>
> Good luck and let us know what happens.

So for the follow up, I just say that I could compile and test the
NetCDF 3.5.1 without problem on a SUSE linux 9.0 with gcc 3.3.1 and
intel fortran 8.1. You really need to set the above environment variables
(all of them).

Now I have another question on compiling the NetCDF with REAL*8 set.
>
> I've compiled, tested, and used (a lot!) the netCDF library compiled
> with Intel v8.0 (not 8.1 yet).

I managed to compile the libraries with the following options for the
FLAGS environments
setenv FFLAGS "-O -mp -r8 -static-libcxa"
setenv F90FLAGS "-O -mp -r8 -static-libcxa"

However, I got some error (another type of error) when testing the output.
Have you tried to compile the libraries with the REAL*8 set? This is the
error I get:

..... EVERYTHING COMES OK UNTIL THE FOLLOWING LINES:.....
............
../netcdf_test
example_good.cdl example.cdl differ: byte 239, line 11
*** Failure ***
*** example_good.cdl 2000-04-05 17:03:14.000000000 -0230
--- example.cdl 2004-09-21 12:47:43.000000000 -0230
***************
*** 8,15 ****
float P(frtime, lat, lon) ;
P:long_name = "pressure at maximum wind" ;
P:units = "hectopascals" ;
! P:valid_range = 0.f, 1500.f ;
! P:_FillValue = -9999.f ;
float lat(lat) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
--- 8,15 ----
float P(frtime, lat, lon) ;
P:long_name = "pressure at maximum wind" ;
P:units = "hectopascals" ;
! P:valid_range = 1.298651e+23f, 0.f ;
! P:_FillValue = 0.f ;
float lat(lat) ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
make[2]: *** [test] Error 1
make[2]: Leaving directory `/home/andry/Softwares/netcdf-3.5.1/src/f90'
make[1]: *** [subdir_target] Error 1
make[1]: Leaving directory `/home/andry/Softwares/netcdf-3.5.1/src'
make: *** [f90/test] Error 2

--------------------- END OF ERROR MESSAGE -------------------

I will appreciate any input on how to verify the libraries are OK?

Thanks again for the help,

Andry

Jan Vorbrüggen

2004-09-22, 9:09 am

The -r8 switch turns every definition of a floating point variable into
a double-precision one. The lines you show have the C notation of explicitly
single-precision values. It seems likely that a blanket application of -r8
will destroy some of the interfaces to the C parts of netCDF with the effects
you have seen.

Why would you want to compile the library with -r8? I can see no reason to
do that.

Jan

Paul Van Delst

2004-09-22, 4:01 pm

Andry William wrote:
> Now I have another question on compiling the NetCDF with REAL*8 set.
>
>
>
> I managed to compile the libraries with the following options for the
> FLAGS environments
> setenv FFLAGS "-O -mp -r8 -static-libcxa"
> setenv F90FLAGS "-O -mp -r8 -static-libcxa"
>

I have to repeat Jan Vorbrüggen's question: Why would you want to compile the netCDF
library with -r8?

Using -r8 will promote all declared REAL (single precision) variables to double precision.
The netCDF library already contains an interface for double precision real variables.
NetCDF supports the following data types (referred to as "external" data types):

char - 8-bit characters intended for representing text.
byte - 8-bit signed or unsigned integers (see discussion below).
short - 16-bit signed integers.
int - 32-bit signed integers.
float or real - 32-bit IEEE floating-point.
double - 64-bit IEEE floating-point.

I use every one of these interfaces (except for byte) without needing to do anything
special. In fact, the library even handles conversion between most types (although the
result may or may not be what you want.)

cheers,

paulv

Andry William

2004-09-23, 3:58 pm

Paul Van Delst <paul.vandelst@noaa.gov>
>
> I have to repeat Jan Vorbrüggen's question: Why would you want to compile
> the netCDF library with -r8?

Hi all,
Well, the only reason is that I am trying to compile the library with -r8
because in the manual of the main source code where I need to use the NetCDF
library, it said that something like it needs

"the NETCDF package compiled in REAL*8"

> Using -r8 will promote all declared REAL (single precision) variables to
> double precision.
> The netCDF library already contains an interface for double precision real
> variables. NetCDF supports the following data types (referred to as
> "external" data types):
>
> char - 8-bit characters intended for representing text.
> byte - 8-bit signed or unsigned integers (see discussion below).
> short - 16-bit signed integers.
> int - 32-bit signed integers.
> float or real - 32-bit IEEE floating-point.
> double - 64-bit IEEE floating-point.

I think you got the point, however, I am not sure I know how to do that
with the above statement on compiling the library. In case, I have the
library as it is (without the -r8 option for compiling), could you explain
how I can do that?

(I have to say that I just recently moved to fortran 90 although I am
very willing to read any manual if I need to, could you just point me
where I can start).

Thanks,

Andry

Paul Van Delst

2004-09-23, 3:58 pm

Andry William wrote:
> Paul Van Delst <paul.vandelst@noaa.gov>
>
>
>
> Hi all,
> Well, the only reason is that I am trying to compile the library with -r8
> because in the manual of the main source code where I need to use the NetCDF
> library, it said that something like it needs
>
> "the NETCDF package compiled in REAL*8"

Hmm. No offense to whoever wrote the manual, but that statement really doesn't mean
anything (to me at least :o). At best it's ambiguous.

>
>
> I think you got the point, however, I am not sure I know how to do that
> with the above statement on compiling the library. In case, I have the
> library as it is (without the -r8 option for compiling), could you explain
> how I can do that?
>
> (I have to say that I just recently moved to fortran 90 although I am
> very willing to read any manual if I need to, could you just point me
> where I can start).

If you are using the Fortran90 API to the netCDF library (v3.5.0 and up), then you
shouldn't need to do anything (in a perfect world at least) - you just call the netCDF
generic function and the specific function for the particular data type you are writing or
reading, e.g. integer, single precision real, double precision real, will be invoked.

I can imagine there are more details wrt your problem. What happens when you attempt to
use the "regular" netCDF library (compiled without the -r8 flag) with the source code you
are trying to use? Do you get netCDF library link errors with your source code or run time
errors?

cheers,

paulv

p.s. Apologies if the font on this message is too small. I just got Mozilla patched and
all my fonts seem to have decreased in size by about 50%! <squint squint>

Richard E Maine

2004-09-27, 4:01 pm

Paul Van Delst <paul.vandelst@noaa.gov> writes:

>
> Hmm. No offense to whoever wrote the manual, but that statement really
> doesn't mean anything (to me at least :o).

If you ever figure it out, let me know. :-)

> p.s. Apologies if the font on this message is too small. I just got
> Mozilla patched and all my fonts seem to have decreased in size by
> about 50%! <squint squint>

I don't see any evidence of font specification at all in what you are
sending out (though I suppose I could have overlooked it). Looks like
just plain text...which, of course, is what one would hope for.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

beliavsky@aol.com

2004-09-27, 4:01 pm

Richard E Maine <nospam@see.signature> wrote:
>Paul Van Delst <paul.vandelst@noaa.gov> writes:
>
>
>If you ever figure it out, let me know. :-)

I'm not familiar with NETCDF, but "compiled with REAL*8" to me means that
variables are just declared REAL (or possibly REAL*4) in the code and that
a compiler option such as /real_size:64 for Compaq Visual Fortran or -dbl
for Lahey/Fujitsu Fortran 95 should be used to effectively convert these
declarations to DOUBLE PRECISION. I'm not advocating this way of writing
code, just trying to interpret the statement.

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Richard E Maine

2004-09-27, 4:01 pm

"beliavsky@aol.com" <beliavsky@127.0.0.1:7501> writes:

> I'm not familiar with NETCDF, but "compiled with REAL*8" to me means that
> variables are just declared REAL (or possibly REAL*4) in the code and that
> a compiler option such as /real_size:64 for Compaq Visual Fortran or -dbl
> for Lahey/Fujitsu Fortran 95 should be used to effectively convert these
> declarations to DOUBLE PRECISION. I'm not advocating this way of writing
> code, just trying to interpret the statement.

Well, that's 2 of the possible interpretations. :-)

I say 2 because, although I didn't check those particular options on
those particular compilers, I would normally expect an option named
something like -dbl to do things differently from one named /real_size:64.
In particular, I'd expect their treatment of integers to be different.
Yes, it matters, at least if you expect to call the procedures in question
and have them actually work - getting integer sizes wrong will pretty
royally screw you up in many cases (seen that).

I've also seen people use phrases like "compiled with REAL*8" to mean
just that they changed the source code to have REAL*8 declarations and
then compiled it.

For the particular case of NETCDF, I presume that someone (not me - at least
not right now) can eventually find what was meant. But the purpose of (that
part of) my post was to mosty emphatically agree with Paul that this is a
sloppy and imprecise way to document something. Good documentation shouldn't
require that people discuss what their interpretation of it is.

(And yes, I would also agree that a good language standard also shouldn't
require that people discuss what their interpretation of it is. Maybe
someday there will be a language standard that meets the criterion. :-))

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

beliavsky@aol.com

2004-09-27, 4:01 pm

Richard E Maine <nospam@see.signature> wrote:
>"beliavsky@aol.com" <beliavsky@127.0.0.1:7501> writes:
>
that[color=darkred]
>
>Well, that's 2 of the possible interpretations. :-)
>
>I say 2 because, although I didn't check those particular options on
>those particular compilers, I would normally expect an option named
>something like -dbl to do things differently from one named /real_size:64.
>In particular, I'd expect their treatment of integers to be different.
>Yes, it matters, at least if you expect to call the procedures in question
>and have them actually work - getting integer sizes wrong will pretty
>royally screw you up in many cases (seen that).

The command line documentation of Lahey options lists the options

-dbl extend single precision reals to double precision

-long extend integer*4 to integer*8

and CVF has

/real_size:size Specifies the size of REAL and COMPLEX declarations, constants,
functions, and intrinsics.
Size is 32, 64.

/integer_size:size Specifies the default size of integer and logical
variables. Valid sizes are: 16, 32, 64.

Since each compiler has a separate option for specifying the default integer
size, I think -dbl and /real_size:64 have the same effect (leaving int's
unchanged from the default), although I have not tested this.

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Sponsored Links