IDAMAX question

[xian-zhong_guous_cd-]

I am testing a MPI code MUMPS on 64 bit linux and link it with MKL. However, the code crashes on IDAMAX. Here is my link line:
gfortran -O -fPIC -I/tmp_mnt/u/seattle01/dev/dev_ccm+/mpi/platform/PMPI/8.0.1.0/linux64_2.6-x86-glibc_2.3.4/include -I. -I../include -c dsimpletest.F
gfortran -o dsimpletest -O -fPIC dsimpletest.o ../lib/libdmumps.a ../lib/libmumps_common.a -L../PORD/lib/ -lpord -L/u/xeons03/people/xian/intel/composerxe-2011.1.107/mkl/lib/intel64/ -lmkl_scalapack_lp64 -lmkl_gf_ilp64 -lmkl_blacs_intelmpi_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -L/u/xeons03/people/xian/intel/composerxe-2011.1.107/compiler/lib/intel64/ -liomp5 -lpthread -lm -L/tmp_mnt/u/seattle01/dev/dev_ccm+/mpi/platform/PMPI/8.0.1.0/linux64_2.6-x86-glibc_2.3.4/lib/linux_amd64/ -lmpi -lblas -lpthread
Is it possible of mismatching between 32 bit vs 64 bit?

[xian-zhong_guous_cd-]

One more detail: MUMPS written in fortran90.

[mecej4]

Is it possible of mismatching between 32 bit vs 64 bit?

The linker will not let you link 32-bit objects with 64-bit objects.

As to your first question: IDAMAX is a simple function, so it should be possible to isolate the problem. What are the values passed to IDAMAX?

[xian-zhong_guous_cd-]

The values passed to IDAMAX seem correct:
n= 1 x= 0.255216946324049 incx= 1
When I replace IDAMAX(n,x,incx) by IDAMAX(x), it does not crash any more. As I mentioned, the code I am testing is writted in FORTRAN90. I am wodnering whether I should use fortran95 interface. As matter of fact, now it complains other BLAS f77 function calls:
MKL ERROR: Parameter 2 was incorrect on entry to DGER
MKL ERROR: Parameter 6 was incorrect on entry to DTRSM
MKL ERROR: Parameter 4 was incorrect on entry to DGEMM

[TimP]

It looks like you should be including the USE or header files corresponding to the BLAS f77 or 95 usage you have chosen, to enable the compiler to complain about mistaken mixtures of the two.

[xian-zhong_guous_cd-]

Does that mean I need modify the source code? If yes, what happens if switching BLAS and LAPACK?

[mecej4]

To use the Fortran 9x interface to BLAS/LAPACK, in particular those routines that entail OPTIONAL arguments and ALLOCATABLE arguments, you must provide an explicit interface in the caller. If your code does not do this, that is an error that you are responsible for fixing.

If your code contains proper calls to the Fortran 9x interface names to BLAS/LAPACK, but the returned runtime error messages are in terms of the arguments to the F77 routines which support the Fortran 9X routines, I consider that a defect in the implementation.

If yes, what happens if switching BLAS and LAPACK?

I have no idea what you meant to ask. Do you mean switch from one implementation to another? If so, and both implementations follow the standard documented API, nothing should happen except with regard to those portions that are allowed to be vendor-dependent.

[TimP]

Quoting mecej4

If your code contains proper calls to the Fortran 9x interface names to BLAS/LAPACK, but the returned runtime error messages are in terms of the arguments to the F77 routines which support the Fortran 9X routines, I consider that a defect in the implementation.

The core functions don't change, and don't know whether they were called directly by the original f77 interface, or indirectly through f95 interface. If that's a "defect," it's inherent in the public BLAS95/LAPACK95 design, to which MKL is faithful. MKL replicates all behavior of the reference netlib code, even in the few cases where there is an obvious fixable bug.

[mecej4]

There was this thread a few weeks ago on the F77-F90 interface question. Another problem underlying the F95 interfaces is that Lapack95 has gone unrevised for many years and some parts, therefore, are dated w.r.t. their F77 counterparts.

Intel has deviated from the reference BLAS and LAPACK specifications in a few instances to allow the programmer to recover from a failed call using the returned INFO argument rather than having the program abort with an error message. In these instances, at least, there should be no obstacle to providing an interpretation of the error value in the INFO returned by the F77 routines into error messages in terms of the F9X arguments.

An extension along the same lines would enable one to shield the user of an F9X routine from the messages given by the F77 routine. The F9X wrapper routine would call the F77 routine with an input value of INFO that tells it not to print any error messages but to return a suitable INFO value. The wrapper routine would then interpret that value in terms of its own arguments. Such re-interpretations already exist in some BLAS95 and LAPACK95 routines, I think.

[Alexander_K_Intel3]

Hi,

There is mismatch of libraries integer types in the linking line, should be-lmkl_gf_lp64, not -lmkl_gf_ilp64.

W.B.R.,
Alexander

[xian-zhong_guous_cd-]

Alexander,
You are the hero. Yes, that mismathch was the cuase of my problem. Thank you very much. You guys at Intel are great.

Sam