ARPACK is broken in update 3

[Denis_Mamaluy]

After compiling ARPACK with the latest Fortran/MKL version (update 3), dsaupd/dseupd combination produces incorrect results. This problem disappears when reverted to the previous (update 2) version. Tested in Windows, don't want to mess up Linux, so keeping update 2 there.

[Noah_C_Intel]

Hey thanks for letting us know. This is definitely a regression and I will work to get this fixed. I will keep you updated on the status.

[Alexander_K_Intel3]

Hi Denis,

Thank you for reporting this! We were able to reproduce it. This seems to be a bug in MKL parallel version of DLACPY. Workaround is to use sequential MKL or link the dlacpy.f from NETLIB before MKL.

W.B.R.,

Alexander

[Zhang_Z_Intel]

A quick update on the root cause and how Intel MKL is going to do address this issue.

The problem lies in ARPACK's using the DLACPY routine to copy arrays where the source and destination overlap. It caused no problem when DLACPY was implemented as a serial operation. Intel MKL 11.0 Update 3 introduces a multithreaded implementation for DLACPY, which manifests the issue of copying overlapped arrays. Note that FORTRAN standard enforces that array arguments passed to a routine to be non-aliased. MKL's threaded DLACPY is taking advantages of this specification, and therefore it is a valid implementation. We have contacted the ARPACK developers and made them aware of this issue.

In order to continue to provide compatibility with the existing ARPACK implementation, we will fully resolve this problem in our next release (MKL 11.0 Update 4). For the time being, there are a few options:

• Users can choose to use the default DLACPY implementation included in the ARPACK source, while still using MKL 11.0 Update 3 for other LAPACK functions. This requires minor modifications to the ARPACK makefile to make the default DLACPY linked before MKL. This KB describes the steps.
• Users can also choose to modify the ARPACK source code to avoid using DLACPY on overlapped arrays. For example, replace the DLACPY with a loop copying element-by-element. This requires minor modifications to the ARPACK source. See the KB for instructions.
• We are working on a patch that can be applied to an MKL 11.0 Update 3 installation ahead of the Update 4 release. Let us know if you would like to receive this patch when ready.

Hopefully, this can help our users to move forward with using MKL 11.0 Update 3. Thanks.

[Zhang_Z_Intel]

Please see this KB for workaround before the issue is fully fixed in MKL 11.0 Update 4. Thanks.

[Denis_Mamaluy]

Thanks, that took care of the problem. I see now that this really was an ARPACK thing, hopefully they'll update it soon.

[AndrewC]

Here we go again. I am getting different results with ARPACK and MKL 11.0 Update 5 vs MKL 11.0 Update 4 , Update 2 etc on a particular case. Obviously I did not use Update 3.

[AndrewC]

Update 5 +ARPACK seems to produce different results for the rigid-body mode frequencies (eigen values) of a classic vibration problem . As these are essentially random around 0 hz this is not a bug, but just different to Update 4.

[Zhang_Z_Intel]

vasci_ wrote:

Update 5 +ARPACK seems to produce different results for the rigid-body mode frequencies (eigen values) of a classic vibration problem . As these are essentially random around 0 hz this is not a bug, but just different to Update 4.

vasci_,

Do you mean update 2, update 4, and update 5 all produce different resutls for the same problem, but all are legitimate results? If it is not a bug, then do you prefer seeing identical results using different update releases? My understanding is MKL does not support version-to-version reproducibility.