-
Notifications
You must be signed in to change notification settings - Fork 78
Changes for more resonable partitioning: #813
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -286,7 +286,7 @@ void setDefaultZoltanParameters(Zoltan_Struct* zz) { | |
| Zoltan_Set_Param(zz, "CHECK_GRAPH", "2"); | ||
| Zoltan_Set_Param(zz,"EDGE_WEIGHT_DIM","0"); | ||
| Zoltan_Set_Param(zz, "OBJ_WEIGHT_DIM", "0"); | ||
| Zoltan_Set_Param(zz, "PHG_EDGE_SIZE_THRESHOLD", ".35"); /* 0-remove all, 1-remove none */ | ||
| Zoltan_Set_Param(zz, "PHG_EDGE_SIZE_THRESHOLD", "1"); /* 0-remove all, 1-remove none */ | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What are the observations that favor this change? Have you observed problems with too many of the graph edges being cut? I must admit I do not know how to interpret the threshold: will 0.35 cut 35% of the edges?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the effect of setting this to 1 is that no (hyper-)edges will be omitted from the graph, even if the number of vertices on the edge is a large amount of the total amount of vertices in the graph (used to be 35%). I believe this is intended to detect all-to-all-ish connections that would be a problem for the partitioning algorithm, since all partitions would be penalized for this cut.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem on small cases or "dead ends" i.e 1D is that every second cell is on different partitions.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are we really optimizing for those cases? Are there performance penalties for other more relevant cases due to this? |
||
| } | ||
|
|
||
|
|
||
|
|
||
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.
Why is this not needed? Should it not be symmetrical?
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 do not understand this fully, but this will be done for all processes so this will be added when the other partition is processed 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.
If one already have added overlap one will add a copy to an other partitions potential on a cell which already is owner, which make an error. The Overlap code is probably has bed used and tested to little. In some tests parallel indexsets seems to have a problem.
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.
What do you mean by this?
If I recall correctly: If a cell was added as owner than all additional occurrences as copy will be neglected.
If I am wrong then please add a failing test case demonstrating this first.
The idea of the index sets used is that if we have an index then we now where that index is present in addition. We might be breaking this guarantee here...