May 26, 2006
Bug report send by Desheng Wang from Caltech on scalapack@cs.utk.edu, Mon, 1 May 2006
The error in the first computation is that it misinterpret the statement in
PxLAPIV: The formula for the integer worskpace calculation in PxLAPIV is
LDW = LOCc( M_P + MOD(IP-1, MB_P) ) +
MB_P * CEIL( CEIL(LOCr(M_P)/MB_P) / (LCM/NPROW) )
where M_P is the local size of the IPIV. But the IPIV is slighlty bigger than A,
the global size of IPIV is:
MP = DESCA( M_ ) + DESCA( MB_ ) * NPROW
(and not DESCA(M_)).
and this gives the new formula to compute the integer workspace.
we have increased the size of the integer
workspace in the rectangular case.
We now report the new integer block size
calculation in the tester.
So that the LIWORK given by the tester to the
PxGETRI is big enough ...
13 files modified:
pdsygvx.f,
pcheevx.f,
pchegvx.f,
pdsyevx.f,
pdsygvx.f,
pssyevx.f,
pssygvx.f,
pzheevx.f,
pzhegvx.f,
pclahqr.f,
pzlahqr.f,
pslahqr.f,
pdlahqr.fMarch 22, 2006
Bug report from Yasuhiro Nakahara (Canon inc.) on 03/13/2006:
Description: pzlahqr routine was aborted due to a segmentation fault.
I found an invalid memory access at the line 525 in pzlahqr.f.
In the DO-loop, with II=1, S1(1, 0) was accessed.
Patch from Greg Henry (Intel) and Mark Fahey (ORNL)
Greg said:
> There is an easy fix for this- the idea of exceptional shifts is
> to just try something outside the norm based on the size of the diagonal
> elements. The offending part can be removed from the code without a
> loss of generality. I think I may be able to come with an alternate
> solution.
Note that this part of the code is not exercized by the testing.
(So the bug was hard to find.)
Modify typo in comment + description of workspace
When RANGE='V', work need to be of dimension 3
Correction of a Typo mistake in the work comment.
In SRC/pdsyevx.f, change WROK by WORK.
February 1st, 2006
[Jan 2006] Bug Fix for the p[s/d]lahqr
Although the Schur form returned by p[s/d]lahqr was correct (as tested by the testing routine),
the returned eigenvalues were not computed correctely. This bug was reported by Interactive
Supercompting (Thanks!).
[Jan 2006] Bug Fix for the SVD
Correct a bug in the workspace utilisation of p_gesvd. In the case
jobU='V' and jobVT='V', the routine has good pointers, otherwise the pointers in
the workspace where shifted as if matrices U and VT existed which
implied out of bound reference for the value stored at the end of the
workspace.
There was also a few problems at the end of the code with some sizes in the case of
rectangular matrices.
modify the workspace size of xBDSQR to follow the revision 184 of LAPACK
the workspace size of xBDSQR has moved from
* WDBDSQR = MAX(1, 4*SIZE )
to
* WDBDSQR = MAX(1, 2*SIZE + (2*SIZE - 4)*MAX(WANTU, WANTVT))
and is now back to
* WDBDSQR = MAX(1, 4*SIZE )
so SVD of ScaLAPACK is following (at least let us take the max of both until
LAPACK is fixed on its workspace size)
[Jan 2006] Add Complex SVD driver
Add the complex version of the SVD driver:
pcgesvd.f and
pzgesvd.f.
Modify the Makefile in the SRC directory to add these two new drivers.
[Jan 2006] Miscellaneous corections
SRC/p[s,d,c,z]gesv.f
[Documentation correction]
correction in the description of the parameter NRHS
(it's the number of columns of B not A)
SRC/p[s,d]lared1d.f
SRC/p[s,d]lared2d.f
[Documentation correction]
The comments in the routines p[s,d]lared2d (where the initial vectors are stored by row)
were wrong (basically replace BYCOL by BYROW)
Some homogenization among the 4 routines as well