LAPACK outdated Fortran Function

[proud2bhaole]

Background information:
*******************************
We have an 10-year old program that utilizes Visual C++ as well as Fortran.

We are trying to migrate this from this environment:
> 1. Visual C++ 6
> 2. Compaq Visual Fortran 6
> 3. MS Fortran PowerStation 4.0

To this environment:
> 1. Visual Studio 2008
> 2. Intel Visual Fortran 11

Unfortunately, there is ONE Fortran function in a LAPACK library that was compiled using the older environment (PowerStation 4.0).

And I cannot find this function DPOSVM in any of the updated LAPACK source code. (although DPOSV exists)

Any help on this is greatly appreciated.

LAPACK: DPOSVM & DPOSV ISSUE
=================================

0. Problem: There exists a function DPOSVM that does not exist in the newer LAPACK versions.
There is, however a function called DPOSV that does exist.
Newest LAPACK Source code has been compiled and DPOSV is able to be called from the
latest LAPACK library (using this newest source code)

1. Function call for dposvm (ADSAP.C)
DPOSVM(&nopt,&nrhs,H,&nopt,E,&nopt,&error);

2. Function call for dposv (ADSAP.C)
DPOSV(&uplo,&nopt,&nrhs,H,&nopt,E,&nopt,&error);

3. The following comments were made within the code in the file ADSAP.C:

/* Solve system. Cholesky decomposition. LAPACK routine */
/* if error, H is not positive definite or bad input */
/* Solution is Newton step, returned in E */


/*DPOSV(&uplo,&nopt,&nrhs,H,&nopt,E,&nopt,&error);

We call function dposvm instead of dposv, because we can not pass
uplo character fro "c" file " to "fortran" file.*/

DPOSVM(&nopt,&nrhs,H,&nopt,E,&nopt,&error);

4. Apparently, DPOSVM was used instead of DPOSV due to incompatibility with C and Fortran.

5. COmmenting out DPOSVM and taking the commenting markers off of DPOSV results in a workable
executable. I.E., re-establish DPOSV as the primary function

6. The effects on the executable, however, are UNKNOWN. Further testing is required.

7. Questions:
a. Why was DPOSVM used?
b. Was it part of the original LAPACK.lib (this is assumed but needs to be verified)?
c. What is uplo character?
d. Perhaps with Visual Studio 2008 and Intel Fortran Visual Studio the shortcomings
of DPOSV have been resolved and DPOSVM is no longer needed?

8. Possible Solutions:
a. Use DPOSV instead of DPOSVM (if no adverse effects on program)
b. Find updated DPOSVM source code

[TimP]

uplo is documented in the public dposv http://www.netlib.org/lapack/double/dposv.f
It looks like someone made a copy where they set 'U' or 'L' inside and removed that argument from the call. The comment seems to indicate they didn't care to learn how a short character string was passed from MSVC to their Fortran compilation.
You should be able to use the DPOSV which comes with ifort mkl, if you find out which choice was made for uplo, and pass it in accordance with the mkl C++ include file.

[proud2bhaole]

Hi Tim

Thanks a lot!

Is there a particular 'uplo' setting that's sorta like a default (L or U)? I.e., mathematically which one would make more sense to set it to?

THanks
Kevin


Quoting - tim18

uplo is documented in the public dposv http://www.netlib.org/lapack/double/dposv.f
It looks like someone made a copy where they set 'U' or 'L' inside and removed that argument from the call. The comment seems to indicate they didn't care to learn how a short character string was passed from MSVC to their Fortran compilation.
You should be able to use the DPOSV which comes with ifort mkl, if you find out which choice was made for uplo, and pass it in accordance with the mkl C++ include file.

[TimP]

If any of the forums is suitable for discussion of BLAS, it would be the MKL forum. As far as I can see, the 'L' or the 'U' form are equally likely choices, so you would have to dig into your application to see which is in use.