-
Notifications
You must be signed in to change notification settings - Fork 556
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
Epetra: throw error instead of segfault when using more than MAX_INT local indices #10249
Comments
This is part of the explorations in dealii/dealii#13428 where we're tracking down what happens if one tries to allocate sparsity patterns with more than 2B entries on one process :-( |
This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. |
Hi @jpthiele, sorry for the delay in action. This seems like a reasonable fix. Have you personally tested this? If not, I can look into this and submit a PR. |
@GrahamBenHarper I only briefly looked into it quite a while ago, so it would be perfect if you can look into it. @ccober6 I knew that it is out of active development in terms of new features, but I did not know of the specific date yet. That is certainly good to know. At the time this issue seemed like an easy-ish fix that could nicely be cherry-picked even when installing an older version of Trilinos. I also know that some people looked into writing wrappers for Tpetra in deal.II but I don't know the specific reasons why certain initiatives stopped. For me personally it is currently an issue of time as multiple other things have a higher priority at the moment. |
@jpthiele will do! |
@jpthiele Yeah, I just wanted to make sure it was on your radar. We should continue to make bug fixes until we are closer to the archival date, but obviously major changes/fixes we would need to assess the cost/benefit. :) |
Enhancement
@trilinos/epetra
When using more than MAX_INT local entries in Epetra_CrsGraph the code runs into a segfault
when calling OptimizeStorage() as this results in negative local indices.
There are two places in MakeLocalIndices 1 and 2
in which the resulting local index is checked for an error in Epetra_BlockMap::LID(gid)
by comparing the result with -1.
Couldn't (result < 0) be checked instead to catch this error as well?
The text was updated successfully, but these errors were encountered: