Fortran interfaces

[chrisa]

Hi,

Are there any plans to update the Fortran interfaces to plasma, for example making use of the Fortran 2003 C interoperability features in order to avoid having do declare integer*4 arrays of length 2 to hold pointers, bind(c) interfaces rather than underscores, and using a modue instead of the current plasmaf.h incude file?

Thanks,
Chris.

[admin]

It is always a good idea to have newer interfaces.
It can always be done if the demand justifies it.
You are the firs persona asking about it.
How much demand is there at NAG?

[chrisa]

Hi,

Thanks for the reply...

We're currently exploring the challenges of calling PLASMA (and MAGMA) within some of our library routines and evaluating performance as part of an internal research project, and we would need to call the C interfaces portably from Fortran.

Writing wrappers for MAGMA appears to be relatively simple because routine interfaces are the same as LAPACK (as far as I understand), but with PLASMA there are some differences in the interfaces due to the use of tiled algorithms, and that somewhat complicates things. For example, I have looked at calling PLASMA_dgetrf. This routine has an extra argument L, which is not such a problem, but IPIV has a different format. Currently in the PLASMA examples both of these arguments are handled in Fortran as non-portable pointers types (2-element, 4-byte integer arrays), but that could easily be made portable if the F2003 c_ptr kind was used instead. That's not a big problem; the main problem I'm having with this routine is that we use the values of IPIV in testing DGETRF, but I don't know how to get the IPIV that's returned from PLASMA_dgetrf into the format returned by a LAPACK DGETRF call (or if that's even meaningful anymore with a tiled approach?) in Fortran. I haven't seen any PLASMA utility functions to do this?

Thanks for your time,
Chris.

[admin]

Chris,
It's been some time since we looked into Fortran interoperability.
It's probably about time we look into it again.
Your suggestion is definitely helpful.

About pivots in LU, they are not equivalent.
PLASMA's tile LU returns a different set of pivots and there is no translation to LAPACK.
PLASMA's tile LU simply does pivoting differently.
But it should solve your system correctly.

That being said, we also have a LAPACK-compliant LU, which is going to be included in the next release (a couple of weeks).
What is going to happen is that PLASMA_dgetrf() will be the LAPACK-compliant LU and the tile LU will be renamed to something else.
Jakub

[mateo70]

Chris,

About the fortran interface for MAGMA: it will be included in the last RC that will probably be released today.

Mathieu

[chrisa]

Hi Guys,

Thanks for the information, that all sounds very interesting. I'll keep my eye out for those new releases.

Jakub, I'm interested in the LAPACK-compliant LU fact... how will that work in PLASMA - will it still use a tiled algorithm underneath, and if so how do you return the LAPACK-compliant version of IPIV if, as you said, the tiled LU simply does pivoting differently? Or will it be a traditional LAPACK-style blocked algorithm underneath?

Thanks for your time,
Chris.

[mateo70]

Hi Chris,

It will be the exact same result than LAPACK. We will just do the panel by another way than it s done actually, and we uses tile algorithm to do the update to create more parallelism.

Mathieu

[chrisa]

Hi Mathieu,

OK, thanks. I look forward to trying that one out.

Chris.

[Houndie]

Hey, I don't mean to be necromancing an old post here, but was there ever a LAPACK-compliant LU algorithm released? I would be extremely interested in this...I have the same problem as Chris, in that I need to access the values of IPIV in a LAPACK routine in Fortran. Any help would be appreciated

[mateo70]

Hi,

it will be released in the next version of PLASMA replacing the actual algorithm using incremental/pairwise pivoting.

Mathieu