-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AztecOO: Fix #4006 (suboptimal LWORK for DGEEV triggers MKL bug) #4007
Conversation
@trilinos/aztecoo
Status Flag 'Pre-Test Inspection' - Auto Inspected - Inspection Is Not Necessary for this Pull Request. |
Status Flag 'Pull Request AutoTester' - Testing Jenkins Projects: Pull Request Auto Testing STARTING (click to expand)Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3_SERIAL
Jenkins Parameters
Using Repos:
Pull Request Author: mhoemmen |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhoemmen this looks reasonable as long as 4*n
is not a good upper bound for the work
array size?
Otherwise is it faster to first compute a more accurate bound and then run the DGEEV
?
@lucbv See DGEEV documentation:
The problem is that MKL's implementation of DGEEV has a bug. DGEEV has a branch somewhere inside that decides on what algorithm to use, based on whether LWORK is big enough for a nice blocked algorithm, or just big enough for a non-blocked algorithm. The latter branch of MKL appears to be broken. The work-around is never to reach that branch of MKL, by always picking LWORK optimally. This is what you're supposed to do anyway :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok
Status Flag 'Pull Request AutoTester' - Jenkins Testing: all Jobs PASSED Pull Request Auto Testing has PASSED (click to expand)Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3_SERIAL
Jenkins Parameters
|
Status Flag 'Pre-Merge Inspection' - SUCCESS: The last commit to this Pull Request has been INSPECTED AND APPROVED by [ bartlettroscoe lucbv ]! |
Status Flag 'Pull Request AutoTester' - Pull Request will be Automerged |
Merge on Pull Request# 4007: IS A SUCCESS - Pull Request successfully merged |
@trilinos/aztecoo
MKL has a bug: If you give DGEEV a suboptimal but still correct LWORK, it corrupts memory. This commit adds a work-around to AztecOO that does an LWORK query to allocate the optimal amount of memory. This may affect performance of GMRES condition number estimation a little bit. (It could speed up or slow down; not sure, and depends on the restart length.)
Related Issues