diff options
| author |  Weiqun Zhang <WeiqunZhang@lbl.gov>
| 2023-01-02 03:37:39 -0800 |
|---|---|---|
| committer |  GitHub <noreply@github.com>
| 2023-01-02 12:37:39 +0100 |
| commit | 1aa0eecc060d1f7752c9edf1498b0692c5f168d6 (patch) | |
| tree | 16c03475c92daeb69e7a0b9f9a9094c59085c475 /Python/pywarpx/timestepper.py | |
| parent | def83e6e157ad1fb7fbb7580e11a096f7eb7b24e (diff) | |
| download | WarpX-1aa0eecc060d1f7752c9edf1498b0692c5f168d6.tar.gz WarpX-1aa0eecc060d1f7752c9edf1498b0692c5f168d6.tar.zst WarpX-1aa0eecc060d1f7752c9edf1498b0692c5f168d6.zip | |
Fix a Bug in 1D ES (#3597)
After the tri-diagonal solve, the data in the special single-box MultiFab
need to be copied back to the normal MultiFab. However, when there was a
bug for periodic boundary. The issue is the special MultiFab is really
special. It has a nodal Box that grows the original nodal Box by 1 node in
the lower boundary and 2 (why 2?) nodes in the upper boundary and these
grown nodes are considered valid nodes, even though they do not have valid
data. Therefore amrex::ParallelCopy with periodicity does not work in this
case. For example, for a domain with 96 cells, the data at nodes 1 and 2 of
the normal MultiFab could be written with the invalid data at nodes 97 and
98 of the special MultiFab. This bug is fixed by replacing it with a
ParallelCopy without periodicity followed by a FillBoundary.
Diffstat (limited to 'Python/pywarpx/timestepper.py')
0 files changed, 0 insertions, 0 deletions