avoiding allocating extra MultiFab for boundary filling? #2147
-
|
Hi, It looks like in all of the example AMR codes an extra MultiFab is allocated and used solely for boundary filling with a FillPatch function. Is it possible to fill boundaries with AmrCore or AmrLevel without allocating an extra MultiFab, i.e. directly filling the ghost cells of an existing MultiFab without modifying the validbox region? Or is there a performance (or other) reason to favor allocating a new MultiFab and using FillPatch to copy both the validbox and the boundary data? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
In FillPatch, the destination MultiFab is allowed to be the same object as one of the source MultiFabs as long as the function arguments are consistent. Besides MultiFabs, FillPatch also takes times as argument, and each MultiFab is associated with a time. In the case there is aliasing in MultiFabs, the destination MulitiFab's time must agree with its alias MultiFab's time. As for performance, it's usually better when there is aliasing because there is less data involved. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, wow, that was simple. Thanks. |
Beta Was this translation helpful? Give feedback.
In FillPatch, the destination MultiFab is allowed to be the same object as one of the source MultiFabs as long as the function arguments are consistent. Besides MultiFabs, FillPatch also takes times as argument, and each MultiFab is associated with a time. In the case there is aliasing in MultiFabs, the destination MulitiFab's time must agree with its alias MultiFab's time. As for performance, it's usually better when there is aliasing because there is less data involved.