-
Notifications
You must be signed in to change notification settings - Fork 19
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
Implement multifab wrapper functionality from WarpX #370
Implement multifab wrapper functionality from WarpX #370
Conversation
for more information, see https://pre-commit.ci
Hi @dpgrote, That is fantastic, thanks a lot for porting this! I think in symmetry with AMReX functions like We could even add default arguments to |
@dpgrote This is awesome. To add CI and show usage examples, can you please add a few new examples in This then makes it very easy to add add a new
|
How about this, add the method Note that there is a subtlety in |
src/amrex/extensions/MultiFab.py
Outdated
from .Iterator import next | ||
|
||
try: |
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.
We need to put this into a function that has access to amr
, so we only attempt an import if:
if amr.Config.have_mpi:
Otherwise, this can cause issues in scenarios, e.g., running serially on Cray machines.
src/amrex/extensions/MultiFab.py
Outdated
try: | ||
from mpi4py import MPI as mpi | ||
|
||
comm_world = mpi.COMM_WORLD |
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.
While we have access to amr
, we can replace mpi.COMM_WORLD
with amr.ParallelDescriptor.Communicator()
later on.
I did not expose that element yet, but we already created an mpi4py compatible MPI_Communicator
for the MPMD logic in pyAMReX. This can be a follow-up PR.
for more information, see https://pre-commit.ci
The more I think about this (and work on implementing something), the more I like the idea of using imaginary numbers for the guard cells. The idea of using negative numbers for the lower ghost cells breaks the standard python usage, since for every sequence type, negative indices are always relative to the end of the sequence. It is asymmetric since there then no nice way of referring to the upper ghost cells. The imaginary indices are a very concise and unambiguous way is specifying the ghosts, both lower and upper. I'll implement this and provide examples to show what it's like. |
So to get a plane with ghost cells, something like this? :) mf[-2j:+2j, 0, 0] # include 2 ghost cells in the first plane of the global domain or is that mf[-2j:-1+3j, 0, 0] # include 2 ghost cells in the first plane of the global domain |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
It would be
The If you want all of the cells, the valid cells plus the two guard cells on each side, then it would be
One thing that is missing is a clean way to specify and open ended range on one side including the ghost cells. |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
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.
This is awesome and impressive, thank you! 🚀 ✨
This fixes some comments from PR #370
This adds the code from the WarpX fields.py that allows global indexing of MultiFabs. This is done by adding
__getitem__
and__setitem__
methods for the MultiFab object.Note that this incorporates the changes from WarpX PR #4370 that had not been merged in.
This currently only does the get/set without including the ghost cells. What is needed is a way of specifying inclusion of the ghost cells. Perhaps this?
Maybe this, using imaginary numbers to refer to ghost cells?
I prefer this method.