Partitioning strategies: skip refined #359
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Looks good, thank you! I'll work on implementing this on the forestclaw/clawpatch side of things. We'll see how difficult it is. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a skip_refined flag as described in #335 to the domain_persist_t.
The flag defaults to 0 and can be set with
fclaw2d_domain_set_partitioning.If true, the patch data of patches that were refined during the most recent call to
fclaw3d_domain_adaptis only packed for the sibling with child id 0. Additionally, when a newly refined family is split between multiple processes in the new partition, the patch data will be packed for the first patch sent to each of these processes. Infclaw2d_domain_iterate_unpackevery sibling of the newly refined family will be supplied with the data packed by the sibling with child id 0. This option allows to delay the computation/allocation of the siblings' patch data until after the partitioning in memory-intensive runs.The partitioning demo is adapted to the new option. It now contains a workflow that allocates the siblings' patch data only after partitioning. Furthermore, we add a more sophisticated patch data structure and compute checksums of the local patch data to compare and verify the different partitioning strategies.