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

Add option for runtime element distribution #5641

Merged
merged 1 commit into from
Dec 1, 2023

Conversation

knelli2
Copy link
Contributor

@knelli2 knelli2 commented Nov 27, 2023

Proposed changes

Now we can choose how we distribute elements at runtime so you can experiment with what is best for your runs. Currently all the options are different weights for a space-filling curve except for a round-robin distribution. The distributions I added to each of the input files is exactly what it was before, so in practice the distribution should be the same as before.

Upgrade instructions

Evolution and elliptic executables must now have a new option in the input file called

Parallelization:
  ElementDistribution: NumGridPoints

An exception to this are the *CharacteristicExtract executables. They do not need this new option.

Code review checklist

  • The code is documented and the documentation renders correctly. Run
    make doc to generate the documentation locally into BUILD_DIR/docs/html.
    Then open index.html.
  • The code follows the stylistic and code quality guidelines listed in the
    code review guide.
  • The PR lists upgrade instructions and is labeled bugfix or
    new feature if appropriate.

Further comments

@knelli2 knelli2 force-pushed the runtime_element_dist branch 2 times, most recently from d9e16ad to f44f2de Compare November 28, 2023 04:18
Copy link
Member

@nilsdeppe nilsdeppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, a few small suggestions for comments and clarifications. Please squash any changes immediately

grid_points_per_core[target_proc] += grid_points_per_element;
grid_points_per_node[target_node] += grid_points_per_element;
if (element_weight.has_value()) {
for (const auto& element_id : element_ids) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a comment here and in the else to the effect of // Distribute by estimated cost of the element. E.g., a weighted space-filling curve. and then // Do a round-robin distribution of the elements?

const domain::BlockZCurveProcDistribution<volume_dim> element_distribution{
element_costs, num_of_procs_to_use, blocks, initial_refinement_levels,
initial_extents, procs_to_ignore};
// Only need this if the element weight has a value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this -> element_distribution (so that when someone accidentally moves the comment or code, at least we have some hope of putting them back together :D )

Maybe expand comment ... since then we have to distribute the elements in a more complicated way than just round robin?

element_array(element_id)
.insert(global_cache, initialization_items, target_proc);
if (element_weight.has_value()) {
const std::unordered_map<ElementId<Dim>, double> element_costs =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add same comments here that you do to the other file

namespace OptionTags {
/// \ingroup OptionTagsGroup
/// \ingroup ComputationalDomainGroup
struct ElementDistribution {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this go into the ResourceInfo group? I can't decide whether or not I like that. I don't love having a bunch of lowest-level options if possible :Shrug:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ResourceInfo isn't actually an options group, it's just a struct. That being said, I can put it into the struct and just add a member function for accessing it if you think that's better. The ResourceInfo is available in the initialization items, so I don't have strong opinions where we place the option

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay. Hmm, yea, if it's easy to do maybe it's worth doing? My only hesitation is then if we have an executable that uses ResourceInfo but no elements things will be confusing. In a sense we probably want something like a Parallelization group, but that seems beyond the scope of this PR and should probably have input from the other core devs 🤷 So I will let you make a decision on what you think is best and we'll just go with that :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh actually, this is true for the CCE executable. It doesn't have a DgElementArray, so with the current setup you never specify an element distribution. But if it was in the ResourceInfo, then you'd have to, but it'd be a useless option.

I like the idea of a Parallelization group. I'll put the element distribution in there, and we can add to it later with whatever else we come up with.

I guess we could technically put the ResourceInfo into Parallelization, but I think that's out of the scope of this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like a good plan to me!

Copy link
Member

@nilsdeppe nilsdeppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, please squash!

@knelli2
Copy link
Contributor Author

knelli2 commented Nov 30, 2023

@nilsdeppe Squashed. @nilsvu could you take a look at the elliptic parts that I edited? I had to change more things than expected so I'd like your sign off

Copy link
Member

@nilsvu nilsvu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍 Thanks for adding this.

@nilsdeppe nilsdeppe merged commit b479ee1 into sxs-collaboration:develop Dec 1, 2023
21 of 22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants