Skip to content
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

Merged
merged 17 commits into from
Nov 29, 2024
Merged

ginkgo own ILU and IC #1684

merged 17 commits into from
Nov 29, 2024

Conversation

yhmtsai
Copy link
Member

@yhmtsai yhmtsai commented Sep 26, 2024

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

  • cholesky (in this pr, too)

@yhmtsai yhmtsai added the 1:ST:ready-for-review This PR is ready for review label Sep 26, 2024
@yhmtsai yhmtsai requested review from nbeams, upsj and a team September 26, 2024 09:22
@yhmtsai yhmtsai self-assigned this Sep 26, 2024
@ginkgo-bot ginkgo-bot added reg:build This is related to the build system. reg:testing This is related to testing. type:matrix-format This is related to the Matrix formats type:factorization This is related to the Factorizations mod:all This touches all Ginkgo modules. labels Sep 26, 2024
@yhmtsai yhmtsai marked this pull request as ready for review September 26, 2024 09:23
Copy link
Collaborator

@nbeams nbeams left a 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

common/cuda_hip/factorization/lu_kernels.cpp Outdated Show resolved Hide resolved
local_system_matrix->get_const_row_ptrs())));
ilu =
gko::experimental::factorization::Lu<ValueType, IndexType>::build()
.with_checked_lookup(true)
Copy link
Collaborator

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.

Copy link
Member

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.

core/factorization/ilu.cpp Outdated Show resolved Hide resolved
core/factorization/ilu.cpp Outdated Show resolved Hide resolved
include/ginkgo/core/factorization/ilu.hpp Outdated Show resolved Hide resolved
include/ginkgo/core/factorization/lu.hpp Outdated Show resolved Hide resolved
core/matrix/csr_lookup.hpp Show resolved Hide resolved
upsj
upsj previously requested changes Sep 26, 2024
Copy link
Member

@upsj upsj left a 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.

Copy link
Collaborator

@nbeams nbeams left a 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.

include/ginkgo/core/factorization/lu.hpp Outdated Show resolved Hide resolved
core/factorization/lu.cpp Outdated Show resolved Hide resolved
include/ginkgo/core/factorization/cholesky.hpp Outdated Show resolved Hide resolved
include/ginkgo/core/factorization/lu.hpp Outdated Show resolved Hide resolved
@yhmtsai yhmtsai changed the title ginkgo ILU ginkgo own ILU and IC Nov 7, 2024
@yhmtsai yhmtsai requested review from upsj and nbeams November 12, 2024 18:49
Copy link
Collaborator

@nbeams nbeams left a 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/lu.hpp Outdated Show resolved Hide resolved
core/factorization/ic.cpp Outdated Show resolved Hide resolved
core/factorization/ic.cpp Show resolved Hide resolved
core/factorization/ilu.cpp Outdated Show resolved Hide resolved
core/factorization/ilu.cpp Outdated Show resolved Hide resolved
reference/test/factorization/lu_kernels.cpp Outdated Show resolved Hide resolved
reference/test/factorization/lu_kernels.cpp Outdated Show resolved Hide resolved
test/factorization/lu_kernels.cpp Outdated Show resolved Hide resolved
@yhmtsai yhmtsai force-pushed the gko_ilu branch 2 times, most recently from 990a6ce to 31f0966 Compare November 20, 2024 17:02
Copy link
Member

@upsj upsj left a 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

common/cuda_hip/factorization/cholesky_kernels.cpp Outdated Show resolved Hide resolved
common/cuda_hip/factorization/lu_kernels.cpp Outdated Show resolved Hide resolved
omp/factorization/cholesky_kernels.cpp Outdated Show resolved Hide resolved
reference/factorization/cholesky_kernels.cpp Outdated Show resolved Hide resolved
reference/factorization/lu_kernels.cpp Outdated Show resolved Hide resolved
@yhmtsai
Copy link
Member Author

yhmtsai commented Nov 27, 2024

I don't get the meaning about putting into gko::kernels, I think all kernel functions are in the namespace.
Could you elaborate it more?
I do not think this change give any changes to LU. It only touches ILU interface now.
Also, LU in experimental, although it is not good, we can still change the LU interface.
I would also like to reduce thought on unclear future to stop this pr. There are a few pr hang by that comment, but they are resolved in long time more than one year.

@upsj
Copy link
Member

upsj commented Nov 27, 2024

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 factorize and incomplete_factorize. For now they use the same kernel (and the full_fillin template parameter is fine, since this is limited only to a single file), in the future they will likely not.

@upsj upsj dismissed their stale review November 27, 2024 21:44

dismissing, as it referred to earlier interface issues

Copy link
Member

@upsj upsj left a 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

@yhmtsai
Copy link
Member Author

yhmtsai commented Nov 28, 2024

@upsj Yes, that makes sense if these kernels can not share most of part

yhmtsai and others added 17 commits November 29, 2024 09:54
- 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]>
@yhmtsai yhmtsai merged commit e848148 into develop Nov 29, 2024
10 of 11 checks passed
@yhmtsai yhmtsai deleted the gko_ilu branch November 29, 2024 12:48
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
23.2% Duplication on New Code (required ≤ 20%)

See analysis details on SonarQube Cloud

MarcelKoch pushed a commit to MarcelKoch/ginkgo that referenced this pull request Dec 2, 2024
This PR adds ginkgo own impelementation for ILU and IC. It is controlled by `incomplete_algorithm::sync_free`.

Related PR: ginkgo-project#1684
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1:ST:ready-to-merge This PR is ready to merge. mod:all This touches all Ginkgo modules. reg:build This is related to the build system. reg:testing This is related to testing. type:factorization This is related to the Factorizations type:matrix-format This is related to the Matrix formats
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants