LAPACK/ScaLAPACK Development

When I compile LAPACK 3.0, last release, everything goes fine until I get to the testing phase.
The diagnostic message is shown belw:

make[2]: Leaving directory `/apps/home/mbibby/svd/LAPACK/TESTING/LIN'
Testing REAL LAPACK linear equation routines
./xlintsts < stest.in > stest.out 2>&1
make[1]: *** [stest.out] Error 134
make[1]: Leaving directory `/apps/home/mbibby/svd/LAPACK/TESTING'
make: *** [testing] Error 2

Can someone suggest what I need to do to get through this phase>

Thank you.

Malcolm M Bibby

Does someone got any hints or make.inc for LAPACK Testing on a ALPHA EV6 or EV67 with the fortran compaq compiler 2.96?

Code: Select all

 #Make.inc
FORTRAN  = fort
OPTS     = -f77 -fpe3
DRVOPTS  = $(OPTS)
LOADER   = fort
LOADOPTS =


gives

Code: Select all

 forrtl: error (65): floating invalid

for cec.out, csvd.out, sec.out, sed.out, ssvd,out and zec.out.

Any help appreciated
Thanks
Julie

For anyone interested this problem has now been partially resolved. With a suggestion from Ed Anderson, I set ILAEV=0 for ISPEC = 10 & 11 in the ilaenv.f routines. Then set the fortran compiler option to -fpe0. The code now compiles fine and passes all of the TESTING suite.
It passes all of the TIMING suites in single and double but fails in complex and complex16.

If anyone has encountered similar failures please let know.

Malcolm

Using a tip provided by Ed Anderson, I set "ILAENV = 0" for ISPEC = 10 and 11, in each of the five copies of ilaenv.f. I also used -fpe0 with the compiler. Now , everything compiles and passes all TESTING.

However, it only passes single and double in TIMING.

In complex it fails with xlintimc < ctime.in > ctime.out 2>&1. The error occurs, I think in slasda.f, which is at the bottom of a long series of calls starting in ctimls or ctimlq, procedding then to cgelsd, cgebrd, cunmbr, clalsd and slasda.

In complex16 the failure appears to be in dlasdq, starting with a call to zgesdd, zgebrd, dbdsdc, dlasd0 and then dlasdq. Here it fails because one of the members of arry D is less than the safe minimum. I believe a similar problem was reported by anothere problem earlier.

If more information is needed to resolve these two issues, I will be happy to oblige - including access to my machine.

Malcolm

I believe the problem with dlasdq when timing using the zsvdtim.in input file is due to a bug in TIMING/EIG/ztimee.f. In the call to ZTIM26, IWORK is passed as an actual argument instead of the much larger IWORK2, which is used in the ZTIM21 and ZTIM22 calls, and used in the call to DTIM26 in dtimee.f. IWORK is too small for the requirements in ZTIM26. With this corrected, it worked OK on our Alpha system.

ctimee.f has the same bug, but didn't actually fail. Also, I didn't have any problems with ctime.in.

This was tested on an EV6 with source code BLAS, and using Compaq Fortran compiler V5.4A, using flags f90 -O3 -fpe0 to compile.

Hope this helps,
Ed

We tried your modifications on our Alpha machine and the TIMING went through without any problem.

Code: Select all

Processor:
   The alpha EV6.8CB (21264C) processor operates at 1000 MHz
Compiler:
   Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650)
   Compiler Driver V6.5-302 (dtk) cc Driver
Flags:
   -O4 -fpe1

Thank you very much Ed.
Julie

Ed, thanks for the input. I made the changes to ctimee.f and ztimee.f and now the whole package passes all testing and timing.

For others who might use this plarform combo, my OPTS were:

OPTS = -arch host -tune host -align all -O1.

I have found with this compiler that moving to a higher level of optimization does not improve performance much. However, on my setup, I find that optimization levels higher than O1 will not permit my Fortran programs to execute with large dimension statements.

Thanks for the input Ed, and the confirmation Julie - nice machine you've got there!

Malcolm.

Ed, thanks for the input. I made the changes to ctimee.f and ztimee.f and now the whole package passes all testing and timing.

For others who might use this plarform combo, my OPTS were:

OPTS = -arch host -tune host -align all -O1.

I have found that with this compiler that moving to a higher level of optimization does not improve performance much. However, on my setup, I find that optimization levels higher than O1 will not permit my Fortran programs to execute with large dimension statements.

Thanks for the input Ed, and the confirmation Julie - nice machine you've got there!

Malcolm.