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

Tpetra::Map should check for duplicate GIDs on a calling process #157

Closed
mhoemmen opened this issue Feb 26, 2016 · 6 comments
Closed

Tpetra::Map should check for duplicate GIDs on a calling process #157

mhoemmen opened this issue Feb 26, 2016 · 6 comments
Labels
CLOSED_DUE_TO_INACTIVITY Issue or PR has been closed by the GitHub Actions bot due to inactivity. MARKED_FOR_CLOSURE Issue or PR is marked for auto-closure by the GitHub Actions bot. pkg: Tpetra type: enhancement Issue is an enhancement, not a bug

Comments

@mhoemmen
Copy link
Contributor

See spdomin/Nalu@b11ced4

mhoemmen referenced this issue in spdomin/Nalu Feb 26, 2016
Periodic boundary conditions in Nalu are implemented by a "pseudo-node"
approach: each slave node knows the global identifier of its' master, and
only master (and regular) nodes contribute rows to the system matrix.
When assembling the right-hand-side or matrix, contributions to slave nodes
are redirected to the rows/columns associated with their master nodes.
When there is more than one slave node referencing a master node, the code
was introducing a new local ID for each slave node.  This change checks if
the master node has already been visited and re-uses the existing local ID
(previously, multiple global ID/local ID pairs were sent to Tpetra which
could cause a failure).  The new code is a bit simpler in that it directly
sorts the global ID vectors instead of the vector of nodes, from which the
global ID vectors were then extracted.

* add TGV IC for more detailed testing of periodic bcs
@mhoemmen
Copy link
Contributor Author

We've debated this back and forth. I've even heard arguments that Tpetra::Map should support duplicate GIDs on a single process, because that would make some kinds of code (e.g., periodic boundaries) the same no matter how GIDs are divided among processes. In any case, if we're building a hash table anyway, it's not hard to check for duplicates.

@mhoemmen
Copy link
Contributor Author

@trilinos/tpetra

@mhoemmen mhoemmen added type: enhancement Issue is an enhancement, not a bug type: help wanted labels Mar 6, 2016
@mhoemmen
Copy link
Contributor Author

mhoemmen commented Mar 8, 2016

Please refer also to discussion of the original issue in Bugzilla (Bug 6475):

https://software.sandia.gov/bugzilla/show_bug.cgi?id=6475

I've closed that Bug; further discussion should take place here. Thanks Stefan!

@mhoemmen
Copy link
Contributor Author

mhoemmen commented Mar 8, 2016

I'm subsuming Bugzilla Bug 6365 ("Multiple (duplicate, repeat, repeated) local indices per global index on a process don't work") into this issue.

https://software.sandia.gov/bugzilla/show_bug.cgi?id=6365

@mhoemmen mhoemmen added this to the Tpetra-backlog milestone Nov 2, 2016
@github-actions
Copy link

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.
If you would like to keep this issue open please add a comment and remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.

@github-actions github-actions bot added the MARKED_FOR_CLOSURE Issue or PR is marked for auto-closure by the GitHub Actions bot. label Dec 15, 2020
@github-actions
Copy link

This issue was closed due to inactivity for 395 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLOSED_DUE_TO_INACTIVITY Issue or PR has been closed by the GitHub Actions bot due to inactivity. MARKED_FOR_CLOSURE Issue or PR is marked for auto-closure by the GitHub Actions bot. pkg: Tpetra type: enhancement Issue is an enhancement, not a bug
Projects
Status: Done
Development

No branches or pull requests

1 participant