-
Notifications
You must be signed in to change notification settings - Fork 91
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
ginkgo own ILU and IC #1684
ginkgo own ILU and IC #1684
Conversation
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.
I have some questions and comments, but overall I am excited about this! Thanks @yhmtsai
core/factorization/ilu.cpp
Outdated
local_system_matrix->get_const_row_ptrs()))); | ||
ilu = | ||
gko::experimental::factorization::Lu<ValueType, IndexType>::build() | ||
.with_checked_lookup(true) |
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.
Same here, would prefer with_safe_lookup
or something like that, personally.
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.
IMO this should rather be a new type, LU and ILU(...) have very different use cases. That would also allow us to build a new, improved ILU preconditioner interface based on the Factorization
type instead of the slightly hacky Composition
-like type ILU is currently.
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.
Thanks Mike, I'm happy to see how simple this was to extend to ILU. Some design and naming suggestions I'd like to see discussed, and maybe we should build a roadmap for the future ILU preconditioner interface.
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.
A few more minor comments, but most of my questions/issues have been addressed.
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.
Looking good, but I have some more minor comments.
include/ginkgo/core/factorization/incompleted_factorization.hpp
Outdated
Show resolved
Hide resolved
include/ginkgo/core/factorization/incompleted_factorization.hpp
Outdated
Show resolved
Hide resolved
990a6ce
to
31f0966
Compare
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.
I'm not 100% convinced it's a good choice to put both ILU and LU into the same gko::kernels::... function (It's fine if they use the same kernel, just the function itself), since the interface to LU will probably change significantly in the future. Otherwise only the suggestion of using if constexpr
where it makes sense
I don't get the meaning about putting into |
instead of adding a new parameter to factorize, forcing me to split that function later on when I implement more LU-specific preprocessing and optimizations, split it into |
dismissing, as it referred to earlier interface issues
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.
I'll likely have to split up the factorize
function into two different kernels without full_fillin
very soon, but I won't hold up the PR any further. Thanks for the updates
@upsj Yes, that makes sense if these kernels can not share most of part |
- bitmap: lead wrong answer or segfault - hashmap: infinite loop
…pposite behavior). Co-authored-by: Tobias Ribizel <[email protected]> Co-authored-by: Natalie Beams <[email protected]>
…rategy" to avoid new strategy input
Co-authored-by: Tobias Ribizel <[email protected]>
Co-authored-by: Natalie Beams <[email protected]>
Co-authored-by: Marcel Koch <[email protected]>
Co-authored-by: Tobias Ribizel <[email protected]>
Quality Gate failedFailed conditions |
This PR adds ginkgo own impelementation for ILU and IC. It is controlled by `incomplete_algorithm::sync_free`. Related PR: ginkgo-project#1684
This pr enables the ginkgo's implementation ILU through the current LU implementation.
To enable that, we need to allow LU can ignore the missing fill-in entries.
It is controlled by checked_lookup parameter, and user needs to pass the same sparsityCsr as the original one as the symbolic factor to get ILU.
Moreover, this pr also adds a parameter for algorithm selection. It will forward the information to LU and unpack them directly to return the same structure as the original sparselib.
Note. LU by default gives combined matrix but ILU gives the composition.
The first commit shows that the hashmap lookup leads the hang issue and bitmap lookup leads illegal memory access (incorrect result with -1 index return).
The second commit shows the results are wrong if we do not ignore missing fill-in entries update after fixing infinite loop of hashmap lookup
After this pr, we provide another way to factorize ILU without relying on the sparse library.
TODO