Non periodic partitioning
The graph of cells that we currently use assumes that the space wraps at the boundaries. This is not true for non-periodic volumes and we have no work across those boundaries. These updates allow for that.
They also allow for vertex weights of zero, as non-periodic spaces can have many empty cells, which should not be considered to carry any work. This latter point is important as this allows empty cells to be gathered to a single node (more frequently anyway, having uniform weights seems not to disallow this effect), which reduces the area of the regions, reducing the number of proxies required (important for spaces with 256x256x256 cells, with a small number of active cells).
Fixes #540 (closed).
Merge request reports
Activity
added 350 commits
-
6659c423...8c324037 - 349 commits from branch
master
- f363b0e6 - Merge remote-tracking branch 'origin/master' into non-periodic-repart
-
6659c423...8c324037 - 349 commits from branch
added 198 commits
-
f363b0e6...5d48d7f7 - 196 commits from branch
master
- c6641656 - Merge remote-tracking branch 'origin/master' into non-periodic-repart
- f554eebc - Create timers for the limiter tasks in order for the code to compile again.
-
f363b0e6...5d48d7f7 - 196 commits from branch
I was looking at reducing the time spent in partitioning by compressing the graph. Since we have large expanses which are just empty cells, I thought it might be reasonable to replace parts of it with symbolic cells, using a technique like edge contraction.
Sadly that turned out to be a lot of work (in both senses, since each contraction looks like it requires a complete relabelling of the graph). So I scaled down my attempt to just reducing the number of edges, surely we don't need 26 per vertex to support the geometry of the grid, maybe just the 6 face edges would be sufficient in cells surrounded by other empty cells... But that hasn't worked yet and I haven't gotten back to looking at it in sometime.
If I abandon that for the moment, this looks good to go, if as you say needing a merge from master.
added 652 commits
-
6ea23de7...d5866e97 - 651 commits from branch
master
- f7f75384 - Merge remote-tracking branch 'origin/master' into non-periodic-repart
-
6ea23de7...d5866e97 - 651 commits from branch
assigned to @matthieu
I'm currently running fine on the
non-periodic-repart-update
branch where I did the same master merge, so should be fine.But if the
engine_max_parts_per_ghost
fix I'm currently testing is what fixes things, I assume I should make that a .yml parameter or something. So we can wait on the merge until that. Or just merge again after.mentioned in commit 58ad1106