Out of core Scalapack

[fletchjp]

What is the status of out-of-core Scalapack?

I have a copy of the prototype file and would like to link it with Scalapack version 2.

Has it been updated at all?

Thanks

John

[fletchjp]

I have made some progress with this problem. I fixed some instances of int to size_t in function definitions in the C code routines and have built the examples e.g. testddriver.f which runs.

In the application I want to adapt to use this I use LU decomposition and I have the routines for this and can inspect the example in testddriver.f.

I also use PDGEMR2D to set up the matrix before the decomposition. I have found a routine in the outofcore routines called FPDGEMR2D which looks like the outofcore equivalent. Comparing the argument lists they are similar, but FPDGEMR2D lacks the final argument giving an overall context:

SUBROUTINE FPDGEMR2D( M, N, AMAT, IA, JA, DESCA, BMAT, IB, JB, DESCB )

SUBROUTINE PDGEMR2D( M, N,
$ A, IA, JA, ADESC,
$ B, IB, JB, BDESC,
$ CTXT)

Also FPDGEMR2D contains a call to a routine called PDGEMR2DO which also lacks the final argument.

CALL PDGEMR2DO( M, N, AMAT, IA, JA, DESCA, BMAT, IB, JB,
$ DESCB )

I have not been able to find this routine.

The code for PDGEMR2D contains this notice.

Code: Select all

    Important notice
    ================
     The parameters of the routine have changed in April 1996
     There is a new last argument. It must be a context englobing
     all processors involved in the initial and final distribution.

     Be aware that all processors  included in this
      context must call the redistribution routine.


The date of FPDGEMR2D from the outofcore distribution is in 1999, and for PDGEMR2D is 2006.

I have not found a working example of code using FPDGEMR2D. I am wondering if it should be updated to include the extra argument for compatibility with Scalapack 2.0.0 and later.

Any help with this will be very much appreciated.

John

[fletchjp]

Test results for the out of core method are puzzling.

The test programs as set up give results for random matrices on LLt, LU and QR transforms.

The LLt results give errors per row of the correct order for the machine precision (10-14 for double, 10-6 for single precision).

The LU results are several orders of magnitude worse, and the QR results somewhere in between.

Is this poor performance to be expected? Would this be expected to be worse than ScaLAPACK or Lapack on the same problems?

I wondered if the double precision failure was somehow due to a single precision constant somewhere, but the single precision calculations show the same effect, where that reason is not possible.

Does anyone know the history of these codes, which are described as prototypes and therefore may not be fit to be used for serious calculations?

I hope someone will reply to this thread.

Thank you in advance

John

[fletchjp]

I have been comparing the test driver for the out of core ScaLAPACK with the corresponding routine for ScaLAPACK itself.

I find that the ScaLAPACK testing of the LU decomposition incorporates iterative refinement before looking at the errors.

I cannot find the corresponding calculation in the out of core version.

There is a routine in ScaLAPACK to do this called PDGERFS. The equivalent PFDGERFS is not in the prototype software.

Does it or its equivalent already exist?

Thanks

John

[efdazedo0]

Dear John,

I am the developer for the out of core scalapack prototype code.

You can contact me at dazevedoef@ornl.gov for further discussion on this software.

Ed D'Azevedo