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

Allow optional MPI communications for virtual boundary module #177

Closed
fankiat opened this issue Jan 27, 2023 · 0 comments · Fixed by #178
Closed

Allow optional MPI communications for virtual boundary module #177

fankiat opened this issue Jan 27, 2023 · 0 comments · Fixed by #178
Assignees
Labels
enhancement New feature or request prio:high High priority

Comments

@fankiat
Copy link
Owner

fankiat commented Jan 27, 2023

Currently, parts of the code are equipped with synchronization calls like eulerian grid ghosting and lagrangian grid scatter/gather. These communications are present to ensure correctness since they are executed every time the subfunction/submodule is called. This may not always be necessary, and definitely slows things down when many bodies are involved. For example, the velocity field does not need to be ghosted every time an interactor is called. Rather, the field only needs to be ghosted once (before calling interactors, perhaps via the simulator) for all the interactors to compute the forcing on its lagrangian grid. As a workaround, we could give users the option to turn off these excessive but safer synchronizations while providing a warning to remind users to be wary of their decision and to remember to ghost the velocity before looping over all the interactor calls. Similarly, for the lagrangian forcing grids, if the lagrangian grids in any one rank are guaranteed to be in and will remain within the same local rank as the eulerian grid throughout the simulation, there is no need for lagrangian grid gather and scatter, and Eulerian-Lagrangian interaction can happen directly without prior MPI communications. Default settings should of course be the configuration with excessive but correct communications, which is what the current code is doing.

@fankiat fankiat added enhancement New feature or request prio:high High priority labels Jan 27, 2023
@fankiat fankiat self-assigned this Jan 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request prio:high High priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant