beamsize effect #3
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Automated via .github/workflows/weekly_update.yml. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Edoardo Zoni <[email protected]>
<!--pre-commit.ci start--> updates: - [github.com/pre-commit/mirrors-clang-format: v21.1.1 → v21.1.2](pre-commit/mirrors-clang-format@v21.1.1...v21.1.2) - [github.com/astral-sh/ruff-pre-commit: v0.13.1 → v0.13.2](astral-sh/ruff-pre-commit@v0.13.1...v0.13.2) <!--pre-commit.ci end--> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
This adds the option to rotate in space a species initialized as a Gaussian beam. The rotation is performed around a user-defined axis by a user-defined angle. --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Remi Lehe <[email protected]>
…ST-WarpX#6192) This replaces the O(N^2) differential luminosity calculation with an O(N) Monte-Carlo algorithm like the one used in the Binary Collision module. It performs pair-wise collisions between interacting particles using a random permutation of the particles in each species. Todo: - [x] Performance test. @aeriforme will send: the input script and the submission script. - [x] Refactor to reduce duplication These are the performance results I got on Perlmutter using the input script @aeriforme gave me. On development: ``` TinyProfiler total time across processes [min...avg...max]: 4386 ... 4386 ... 4386 ----------------------------------------------------------------------------------------------------------- Name NCalls Excl. Min Excl. Avg Excl. Max Max % ----------------------------------------------------------------------------------------------------------- DifferentialLuminosity::ComputeDiags 4617 2.729 197.5 552.5 12.60% DifferentialLuminosity2D::ComputeDiags 4617 2.552 190.6 535.8 12.21% ``` On this branch: ``` TinyProfiler total time across processes [min...avg...max]: 3319 ... 3319 ... 3319 ------------------------------------------------------------------------------------------------------------- Name NCalls Excl. Min Excl. Avg Excl. Max Max % ------------------------------------------------------------------------------------------------------------- DifferentialLuminosity::ComputeDiags 4617 3.389 6.694 11.06 0.33% DifferentialLuminosity2D::ComputeDiags 4617 3.288 5.895 9.201 0.28% ``` Results on lepton version of the differential luminosity diagnostic test: <img width="640" height="480" alt="theory_compare_1d" src="https://github.com/user-attachments/assets/16f46c24-5113-4c0e-a015-c087d70a08c9" /> and for the 2D diagnostic: <img width="640" height="480" alt="2d_sim" src="https://github.com/user-attachments/assets/d23f81bb-2f50-4191-ae3b-7ead34d8f0ab" /> --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Remi Lehe <[email protected]>
…-WarpX#6232) This PR implements the following changes: - The WarpXParticleContainer's member variable is named `m_mass`. - Any local copy for device lambda capture is named `mass` (rather than `m`, `ms`, `mass_local`, etc.).
This PR is a follow-up to PR BLAST-WarpX#5969 where the ability to use particle suborbits in the implicit schemes was introduced. Currently, an approximation is used to compute the contribution of suborbit particles to the mass matrices that ignores terms that arise owing to coupling between suborbits. This approximation is not always a good one and has been observed to lead to an increase in total Newton iterations when being used for the Jacobian calculation, thereby increasing the wall time. This PR refactors the suborbit implementation to do a direct particle-based calculation of J for suborbit particles during the linear stage of JFNK when the mass matrices are being used, mimicking the behavior in PICNIC. However, unlike PICNIC, the suborbit particles are still included in the preconditioner, where the approximation discussed above is sufficient.
I noticed in BLAST-WarpX#6231 that the input file of the test `test_3d_photon_pusher` was setting up photons with electron charge and electron mass 👀. This PR fixes the input file replacing the charge and mass inputs with the species type.
BLAST-WarpX#6234) I think that `min3` and `max3` helper functions can be removed from `HancockUtils.H` . Indeed, `std::max` and `std::min` can already accept more than 2 values to compare, e.g. : ``` std::max({1,2,3}); ``` The generated assembly seems to have zero overhead : https://godbolt.org/z/f68To3a36
…ST-WarpX#6236) Excitation and forward scattering is not yet supported in DSMC but currently these processes do not result in sensible error messages. Addresses BLAST-WarpX#6229. Signed-off-by: roelof-groenewald <[email protected]>
The `bool WarpX::getPMLRZ()` method is not really necessary, since it is a simple single-line function used only once from within the WarpX class (in `WarpXMovingWindow.cpp` ). I think that we can remove it to simplify the WarpX class.
…ce in WarpXMovingWindow.cpp (BLAST-WarpX#6238) `UpdateInjectionPosition` is used only once inside `WarpXMovingWindow.cpp` . I propose to move it to `WarpXMovingWindow.cpp` in order to simplify the interface of the WarpX class.
### Background While investigating a failure in the test `test_3d_linear_compton_bunch_laser` in BLAST-WarpX#5955, we realized that the position update implemented in `UpdatePosition` was not correct for massless particles like photons. This was called from `PhysicalParticleContainer::AddPlasmaFlux` for the flux injection of photons. @RemiLehe suggested that we correct the implementation in `UpdatePosition` and remove the photon counterpart `UpdatePositionPhoton`, which was only called from `PhotonParticleContainer::PushPX`. ### Changes Take into account the mass of the particle in the position update equation: - For massive particles: $\Delta x = \frac{u_x}{\gamma} \Delta t$. - For massless particles: $\Delta x = c \frac{u_x}{|u|} \Delta t$. Note that for now I kept the equations as they were. Alternatively, we could also write the equations as $\Delta x = c^2 \frac{p_x}{E} \Delta t$, with $E^2 = p^2 c^2 + m^2 c^4$, with $m=0$ but $p$ computed using the electron mass for photons. ### Validation This is a snapshot of one photon species in the (x,z) plane from the test `test_3d_linear_compton_bunch_laser`, `development` branch on the left vs. this branch on the right: <p align="center"> <img src="https://github.com/user-attachments/assets/a53e46a6-b11d-4b73-9591-ae213420a51a" width="350"> <img src="https://github.com/user-attachments/assets/2754bc75-466c-4edd-a713-e83c3c60cc6b" width="350"> </p> ### To-do - [x] Merge BLAST-WarpX#6232 and rebase this branch. - [x] Merge BLAST-WarpX#6235 and rebase this branch.
…_plotfile_headerversion (BLAST-WarpX#6244) `plotfile_headerversion` and `slice_plotfile_headerversion` seem to be unused. This PR removes them from the WarpX class. This allows us to move `#include <AMReX_VisMF.H>` from `WarpX.H` to `WarpX.cpp` .
…ntation of some methods from the header to the cpp file (BLAST-WarpX#6226) This PR moves the implementation of some methods of `SpectralFieldData`, `SpectralFieldDataRZ`, and `SpectralSolver` from the header file to the cpp file. This makes the header files smaller and more readable.
…BLAST-WarpX#6213) I was compiling WarpX on Frontier in all geometries and ran into a build error with the RCYLINDER and RSPHERE geometries. This PR skips the shared deposition routines when building in these geometries for now.
Automated via .github/workflows/monthly_release.yml. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Edoardo Zoni <[email protected]>
<!--pre-commit.ci start--> updates: - [github.com/astral-sh/ruff-pre-commit: v0.13.2 → v0.13.3](astral-sh/ruff-pre-commit@v0.13.2...v0.13.3) <!--pre-commit.ci end--> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
This PR adds a print of the maximum relative error when checksums fail, which I think is quite useful when they fail for many "keys" and/or many tests (e.g., BLAST-WarpX#5955, BLAST-WarpX#6248) - the maximum relative error gives a glimpse of how good or bad things are. This is an example of the new output, with the extra line printing the maximum relative error: ``` ... ERROR: Benchmark and output file checksum have different value for key [lev=0,Ex] Benchmark: [lev=0,Ex] 9.408402900367834e+05 Test file: [lev=0,Ex] 9.409402900367834e+05 Absolute error: 1.00e+02 Relative error: 1.06e-04 ERROR: Benchmark and output file checksum have different value for key [lev=0,Ez] Benchmark: [lev=0,Ez] 6.654423300420902e+05 Test file: [lev=0,Ez] 6.754423300420902e+05 Absolute error: 1.00e+04 Relative error: 1.50e-02 ERROR: Benchmark and output file checksum have different value for key [lev=0,jx] Benchmark: [lev=0,jx] 9.956269465957083e+03 Test file: [lev=0,jx] 9.956269365957083e+03 Absolute error: 1.00e-04 Relative error: 1.00e-08 Maximum relative error: 1.50e-02 New checksums file test_2d_larmor.json: ... ``` Feel free to close the PR without merging if you think this is not useful.
Automated via .github/workflows/weekly_update.yml. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Edoardo Zoni <[email protected]>
WarpX's constructor may build objects that call WarpX::getInstance, which in turn build WarpX again if `m_instance` is nullptr. So we should assign `this` to `m_instance` at the beginning of the constructor to avoid the recursion.
Some parts of the documentation on checksums are obsolete, in the sense that they document modules that are not really used in practice, since we migrated to CTest last year.
Co-authored-by: Edoardo Zoni <[email protected]>
This PR fixes a bug in the nonlinear Newton solver. The convergence based on the absolute tolerance was using the relative tolerance instead of the absolute tolerance.
While updating BLAST-WarpX#5637 for review, I reached a `maybe uninitialized` error in the CI tests This PR updates the `FieldGather.H` file to initialize the affected variables (and the other similar ones just in case)
…LAST-WarpX#6260) This makes a significant performance difference on a problem setup @aeriforme gave me. In this simulation, many particles leave the domain and we need to store them all for analysis. On development: ``` TinyProfiler total time across processes [min...avg...max]: 4246 ... 4246 ... 4246 ------------------------------------------------------------------------------------------------------------- Name NCalls Excl. Min Excl. Avg Excl. Max Max % ------------------------------------------------------------------------------------------------------------- ParticleBoundaryBuffer::gatherParticles::resize 8772 3843 3843 3843 90.49% WarpXOpenPMDPlot::SeriesFlush()() 96 89.46 89.46 89.46 2.11% ParticleBoundaryBuffer::gatherParticles 256 58.11 58.11 58.11 1.37% ParticleContainer::addParticles 48 53.54 53.54 53.54 1.26% ParticleBoundaryBuffer::gatherParticles::filterAndTransform 8772 27.26 27.26 27.26 0.64% ``` This PR: ``` TinyProfiler total time across processes [min...avg...max]: 494.6 ... 494.6 ... 494.6 ------------------------------------------------------------------------------------------------------------- Name NCalls Excl. Min Excl. Avg Excl. Max Max % ------------------------------------------------------------------------------------------------------------- ParticleBoundaryBuffer::gatherParticles::resize 8754 126.3 126.3 126.3 25.53% WarpXOpenPMDPlot::SeriesFlush()() 96 90.3 90.3 90.3 18.26% ParticleContainer::addParticles 48 59.01 59.01 59.01 11.93% FFT::R2C::forward(in) 1934 27.05 27.05 27.05 5.47% ParticleBoundaryBuffer::gatherParticles::filterAndTransform 8754 26.8 26.8 26.8 5.42% ```
…LAST-WarpX#6225) To my understanding, the `SpectralFieldData` constructor is called only at the beginning of the simulation (and most likely after regrid operations) to prepare the FFT plans. Therefore, if I am not mistaken, we should not track the time spent in the constructor for load balancing, since this routine won't be called again before redistributing the boxes. Note that after removing cost tracking from the `SpectralFieldData` constructor, `lev` becomes an unused parameter.
Automated via .github/workflows/weekly_update.yml. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Edoardo Zoni <[email protected]>
While reviewing some of our documentation PRs, I noticed that we use the `:alt:` (alternate text) syntax in a way that might be neither optimal nor consistent with the `reStructuredText` [figure examples](https://docutils.sourceforge.io/docs/ref/rst/directives.html#figure): ```rst .. figure:: picture.png :scale: 50 % :alt: map to buried treasure This is the caption of the figure (a simple paragraph). ``` As a reminder, the `reStructuredText` [image docs](https://docutils.sourceforge.io/docs/ref/rst/directives.html#image) describes alternate text as > Alternate text: a short description of the image, displayed by applications that cannot display images, or spoken by applications for visually impaired users _Before_ this PR, this is the output when an image is displayed:  _Before_ this PR, this is the output when an image is _not_ displayed (e.g., due to a typo in the docs):  _After_ this PR, I would propose to have this output when an image is _not_ displayed (e.g., due to a typo in the docs):  I think this is a better output for both users that read the docs (avoid reading the caption twice) and visually impaired users (avoid hearing the caption twice - the real caption is spoken too). Note that in some cases we do not yet provide a caption. I believe we should add a caption to all figures, but I left this out of this PR.
This updates the overview of the theory page, to make it less specific to plasma-based accelerators: <img width="767" height="811" alt="Screenshot 2025-11-04 at 6 14 11 AM" src="https://github.com/user-attachments/assets/566d02f5-0a4b-4031-bf90-df20165b33ee" />
…rpX#6342) Since the hybrid PIC model is documented as a field solver, I think it makes sense to explicitly mention the field equation that it solves in the title.
Fixes some indentation warnings and errors by replacing the more extensive code block with indentations in the docstring with a sentence that explains the same content.
Move from `MultiFabWrapper` to `MultiFab`. Will automatically be forwarded still to the `MultiFabWrapper`.
…n using single/double precision (BLAST-WarpX#5828) With this PR the constants in ablastr are first defined using variable templates and then specialized for `amrex::Real`, e.g., for mathematical constants: ```C++ /** Mathematical constants */ namespace math { //! ratio of a circle's circumference to its diameter (variable template) template<typename T> constexpr auto pi_v = static_cast<T>(3.14159265358979323846); //! https://tauday.com/tau-manifesto (variable template) template<typename T> constexpr auto tau_v = static_cast<T>(2.0 * pi_v<double>); //! ratio of a circle's circumference to its diameter constexpr auto pi = pi_v<amrex::Real>; //! https://tauday.com/tau-manifesto constexpr auto tau = tau_v<amrex::Real>; } // namespace math ``` This is done with the intent of allowing the use of `double` precision constants even if the code is compiled in single precision (or vice versa if you really want it !), e.g. : ```C++ const auto a = 2_rt * math::pi; // a is an amrex::Real const auto b = 2 * math::pi_v<double>; // b is a double ! const auto c = 2 * math::pi_v<float>; // c is a float ! ``` I will need this feature to import the QED module from PICSAR into WarpX. I've started migrating the code in BLAST-WarpX#5677 ,but the PR is becoming too big, so I decided to split it into smaller chunks. The new feature is now used in the template function `Algorithms::KineticEnergy` . This function is conceived to be able to force double precision in some cases regardless of how WarpX has been compiled. Therefore, using `c` in double precision in these cases is coherent with its goal. Note that I've changed the variables from `static constexpr` to `constexpr` because, to my understanding, `static` does not make any difference in this context. ## Previous discussions With this PR the constants in ablastr are first defined using variable templates and then specialized for `amrex::Real`, e.g., for mathematical constants: ```C++ namespace math { namespace variable_templates { template<typename T> constexpr auto pi = static_cast<T>(3.14159265358979323846); template<typename T> constexpr auto tau = static_cast<T>(2.0 * pi<double>); } constexpr auto pi = variable_templates::pi<amrex::Real>; constexpr auto tau = variable_templates::tau<amrex::Real>; } // namespace math ``` This is done with the intent of allowing the use of `double` precision constants even if the code is compiled in single precision (or vice versa if you really want it !), e.g. : ```C++ using namespace ablastr; namespace math_vt = math::variable_templates; const auto a = 2_rt * math::pi; // a is an amrex::Real const auto b = 2 * math_vt::pi<double>; // b is a double ! ``` I will need this feature to import the QED module from PICSAR into WarpX. I've started migrating the code in BLAST-WarpX#5677 ,but the PR is becoming too big, so I decided to split it into smaller chunks. The new feature is now used in the template function `Algorithms::KineticEnergy` . This function is conceived to be able to force double precision in some cases regardless of how WarpX has been compiled. Therefore, using `c` in double precision in these cases is coherent with its goal. In case you don't like the long namespace name `variable_template`, an alternative would be to call it `vt`. Note that I've changed the variables from `static constexpr` to `constexpr` because, to my understanding, `static` does not make any difference in this context. ### Updates - Following @dpgrote 's suggestion, I've changed `variable_templates` to `const_templates` - Following @aeriforme 's suggestion, I've added `c2`, `invc` and `inv_c2` constants, and I have tested them by modifying a couple of source files. - Following @WeiqunZhang 's suggestion, I am now using `_v` suffix to indicate variable templates, as done in C++20 https://en.cppreference.com/w/cpp/numeric/constants.html
Move from wrapper to fundamental class.
Follow up to BLAST-WarpX#5386. @ax3l pointed out that the :alt: text should always provide a concise description of the image for digital accessibility, even if the caption is also always accessible.
This PR simplifies the field access and removes the use of the Python fields class wrapper. This reduces the complexity of having multiple ways of accessing MultiFab objects. Now, the MultiFabs should only be accessed via the MultiFab registry. Changes: - [x] Add sim.fields for the multifab_registry - [x] Update Physics_applications/capacitive_discharge/inputs_test_2d_background_mcc_picmi.py as first test - [x] Update input files to use sim.fields instead of warpx.multifab_register() - [x] Update input files that do not use mesh - [x] Update input files that use mesh - [x] Update python_extend.rst - [x] warn on usage of the old wrapper classes --------- Signed-off-by: roelof-groenewald <[email protected]> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Roelof Groenewald <[email protected]> Co-authored-by: Marco Garten <[email protected]> Co-authored-by: Remi Lehe <[email protected]> Co-authored-by: Marco Garten <[email protected]> Co-authored-by: Edoardo Zoni <[email protected]> Co-authored-by: Axel Huebl <[email protected]>
ARTEMIS is a different code than WarpX. Therefore listing ARTEMIS references/examples is not directly relevant, and might be confusing to users (for the same reaons, we do not list HiPACE++ or ImpactX references/examples ; these connections could be made on the BLAST website instead: https://blast.lbl.gov/)
…6345) I replaced the section on field solvers by a more generic section on "Models and Algorithms". As part of this, I created a folder `models_algorithms` and moved some of the files there. Some screenshots of the new documentation: <img width="389" height="596" alt="Screenshot 2025-11-05 at 9 44 38 AM" src="https://github.com/user-attachments/assets/af7c9b81-4755-457c-9807-e7f1c497d6d9" /> <img width="527" height="559" alt="Screenshot 2025-11-05 at 9 44 50 AM" src="https://github.com/user-attachments/assets/d68e930b-fcbe-420b-ba49-890f0c3210be" /> This will need some follow-up PRs: - The implicit PIC section is currently empty - We will need to also add the semi-implicit PIC section --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Signed-off-by: roelof-groenewald <[email protected]> Co-authored-by: Remi Lehe <[email protected]>
Rearranges the order of the content in INSTALL, USAGE and DATA ANALYSIS sections of the documentation. It also improves the titles of the sections. --------- Co-authored-by: Edoardo Zoni <[email protected]> Co-authored-by: Axel Huebl <[email protected]>
Super small change here, maybe not relevant. I'd like to propose to limit the sorting verbosity in case the warpx output verbosity is limited. At the moment, if I run with ``` warpx.verbose = 1 warpx.limit_verbose_step = 1 ``` the stdout looks something like this ``` STEP 1100 ends. TIME = 7.87731526e-14 DT = 7.161195691e-17 Evolve time = 44.17611283 s; This step = 0.031813776 s; Avg. per step = 0.04016010257 s --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles --- INFO : re-sorting particles STEP 1200 starts ... --- INFO : re-sorting particles STEP 1200 ends. TIME = 8.593434829e-14 DT = 7.161195691e-17 Evolve time = 47.03899439 s; This step = 0.037334873 s; Avg. per step = 0.03919916199 s ``` I don't know if there's any reason to keep the sorting information active with a limited verbosity, but without any step information associated I don't find it very informative and kind of clutters the output. Let me know if this makes sense.
Add top section description of the actual equations solved in the hybrid-PIC scheme: <img width="715" height="516" alt="image" src="https://github.com/user-attachments/assets/e53d1990-c340-4833-9f94-a9b54aeb40e2" /> --------- Signed-off-by: roelof-groenewald <[email protected]>
- Added FAQ: BTD link to /Inputs file/Diagnostics and Output/BTD - Added FAQ: boosted frame link to Overall simulation parameters section --------- Co-authored-by: Remi Lehe <[email protected]>
…iew section (BLAST-WarpX#6360) Add an overview section that motivates the Python extensions: <img width="748" height="626" alt="Screenshot 2025-11-05 at 3 39 07 PM" src="https://github.com/user-attachments/assets/afb848a1-4c05-41e5-b1dd-e41bdcfa6e8b" />
Cleaning up `Example/Uniform plasma` subsection. --------- Co-authored-by: Remi Lehe <[email protected]>
… how to run (BLAST-WarpX#6364) This improves the next section of the page: <img width="614" height="701" alt="Screenshot 2025-11-05 at 5 04 41 PM" src="https://github.com/user-attachments/assets/97aece76-e473-4069-8b92-f0406fd28cfb" />
This adds the alias warp.step to be consistent with Simulation.step. This is to avoid confusion since in various examples warpx and Simulation are used interchangeably - the method for running the simulation should be the same. Should the warpx.evolve just be removed (i.e. renamed "step")?
<!--pre-commit.ci start--> updates: - [github.com/astral-sh/ruff-pre-commit: v0.14.2 → v0.14.3](astral-sh/ruff-pre-commit@v0.14.2...v0.14.3) <!--pre-commit.ci end--> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
This incorporates feedback from the rest of the WarpX team
Modernize examples to use the new `sim.particles` access to `MultiParticleContainer` directly.
Rework the WarpX recommended citation as discussed in the Tue, Aug 19 developer meeting. [Preview here.](https://warpx--6102.org.readthedocs.build/en/6102/acknowledge_us.html) - [x] Zenodo: add new co-authors to - [x] Zenodo: remove "contributors" (not co-authors) that had minimal contributions - [x] finalize more in the style of https://openpmd-api.readthedocs.io/en/0.16.1/citation.html#openpmd-api w/ link to homepage. two sections, each with a tab "copy bibtex" and a tab "copy plain text": - [x] One that is "how to credit generally WarpX (2018)" via the general Zenodo link - [x] One that is "how to reproducibly cite a specific version of WarpX (2025) via the version-specific Zenodo link --------- Co-authored-by: Remi Lehe <[email protected]> Co-authored-by: Alexander Sinn <[email protected]>
We want to keep the `MultiFab` pointers the same during load balancing (`WarpX::RemakeLevel`). In interactive usage, users might store a reference/handle to our `MultiFab` classes directly between simulation steps. We want to make sure these references stay valid. Using `std::swap` and `std::move` helps us to move the new data underneath the existing pointer to `MultiFab` instead of replacing it with a new pointer altogether during load balancing, where we recreate `MultiFab` instances. This fixes the load balancing of EB fields to stay stable, too. With this fix (and the already working handles handed out by `MutliFabRegister` for most of our fields), we can avoid our high level field wrapper and transparently forward all AMReX methods and properties to users, without another level of indirection. --------- Co-authored-by: Weiqun Zhang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added beamsize effect.