Skip to content

Conversation

@ax3l
Copy link
Member

@ax3l ax3l commented Mar 19, 2025

Add 2D Space Charge in Particle Tracking. First part of #401

To Do

For this to compile, you need to set:
cmake --fresh -S . -B build -DImpactX_FFT=ON -DImpactX_ablastr_branch=a76eecf1553f5d0e72ec948c9a67db4111a1544f (WarpX commit of the merged PR BLAST-WarpX/warpx#6201 )

Follow-up

@ax3l ax3l added the component: space charge Space charge & potential solver label Mar 19, 2025
@ax3l ax3l added this to the Advanced Methods (SciDAC-5) milestone Mar 19, 2025
@ax3l ax3l requested a review from WeiqunZhang March 19, 2025 22:38
// push momentum
px += field_interp[0] * push_consts;
py += field_interp[1] * push_consts;
pz += field_interp[2] * push_consts; // TODO: is this always += 0.0?
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-zero, because we will model a variation of the current density along t.

Might in practice often be neglected. We can start without long. kick and add it later.

@ax3l ax3l force-pushed the topic-space-charge-particles-2D branch 2 times, most recently from de299e6 to 7b53d47 Compare July 15, 2025 18:53
@ax3l ax3l requested a review from cemitch99 July 15, 2025 18:56
@ax3l ax3l force-pushed the topic-space-charge-particles-2D branch from 7b53d47 to 79b5d1c Compare August 28, 2025 21:19
@ax3l ax3l changed the title [WIP] 2.5D Space Charge in Particle Tracking [WIP] 2D Space Charge in Particle Tracking Aug 28, 2025
@cemitch99 cemitch99 changed the title [WIP] 2D Space Charge in Particle Tracking 2D Space Charge in Particle Tracking Aug 28, 2025
@cemitch99
Copy link
Member

The test here currently fails with the simple error:

domain size in direction 2 is 1
blocking_factor is 8
amrex::Error::0::domain size not divisible by blocking_factor !!!

We should make this error conditional on the space charge solver. This solver requires a grid size of 1 in z.

Copy link
Member

@cemitch99 cemitch99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to touch base on the scale/normalization of the fields returned by the 2D solve, in order to correctly set the value of push_constants in GatherAndPush.cpp.

RemiLehe pushed a commit to BLAST-WarpX/warpx that referenced this pull request Sep 9, 2025
Enable interpolating fields to particles in 1D or 2D even when running a
3D simulation. Needed for 2D and 2.5D space charge in ImpactX:
BLAST-ImpactX/impactx#909
@cemitch99
Copy link
Member

cemitch99 commented Sep 12, 2025

Here is a more interesting observation. I ran with an axisymmetric KV beam, expanding in free space, with 2D space charge for an identical number of grid points in x and y, but the envelopes show significantly different evolution. This is evidence of x/y asymmetry in the underlying 2D Poisson solve. The push constants need to be updated, but they are identical in x and y.
Expanding_beam_2D_envelopes.pdf

# Particle Beam(s)
beam.npart = 100000  # outside tests, use 1e5 or more
beam.units = static
beam.kin_energy = 250.0
beam.current = 1.0e-3
beam.particle = proton
beam.distribution = kvdist
beam.lambdaX = 4.472135955e-4
beam.lambdaY = beam.lambdaX
beam.lambdaT = 9.12241869e-7
beam.lambdaPx = 0.0
beam.lambdaPy = 0.0 
beam.lambdaPt = 0.0

# Beamline: lattice elements and segments
lattice.elements = monitor drift1 monitor
lattice.nslice = 40

drift1.type = drift
drift1.ds = 6.0

monitor.type = beam_monitor
monitor.backend = h5

# Algorithms
algo.particle_shape = 2
algo.space_charge = 2D
algo.poisson_solver = "fft"

amr.n_cell = 16 16 1
amr.blocking_factor_x = 8
amr.blocking_factor_y = 8
amr.blocking_factor_z = 1

geometry.prob_relative = 1.01

@ax3l ax3l mentioned this pull request Sep 15, 2025
1 task
Comment on lines 110 to 111
px += field_interp[0] * push_consts * beta_gamma * dr[2] / (c0_SI);
py += field_interp[1] * push_consts * beta_gamma * dr[2] / (c0_SI); //this should be field_interp[1]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The constants appearing in px and py are currently in draft form only, and will continue to be updated.

ax3l and others added 5 commits September 23, 2025 15:28
Keep simple for now.
Phi is then blown up again to 3D with indentical values in z.

Co-authored-by: Weiqun Zhang <[email protected]>
)
add_impactx_test(expanding-fft-2d.py
examples/expanding_beam/run_expanding_fft_2D.py
OFF # ImpactX MPI-parallel
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want 100% the same AMReX blocks ("grids output"):

Suggested change
OFF # ImpactX MPI-parallel
ON # ImpactX MPI-parallel

@cemitch99
Copy link
Member

cemitch99 commented Oct 17, 2025

FYI: I had to relax the tolerance a great deal for the Python tests, especially the FODO test, while the C++/app tests passed with no problem. I'm still concerned that there may be something else going on specific to the Python test implementation or bindings.

* [pre-commit.ci] pre-commit autoupdate (BLAST-ImpactX#1161)

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.13.1 → v0.13.2](astral-sh/ruff-pre-commit@v0.13.1...v0.13.2)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* [pre-commit.ci] pre-commit autoupdate (BLAST-ImpactX#1165)

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)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Gauss 3D: Fix Push Constants (BLAST-ImpactX#1168)

This fixes the push constants for non-equal x,y,z and
adds an end-point correction for the integration. It
also changes the number of integration points by default
to 101 instead of 401.

Co-authored-by: Ji Qiang <[email protected]>

* [pre-commit.ci] pre-commit autoupdate (BLAST-ImpactX#1174)

updates:
- [github.com/astral-sh/ruff-pre-commit: v0.13.3 → v0.14.0](astral-sh/ruff-pre-commit@v0.13.3...v0.14.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Bump stefanzweifel/git-auto-commit-action from 6 to 7 (BLAST-ImpactX#1175)

Bumps [stefanzweifel/git-auto-commit-action](https://github.com/stefanzweifel/git-auto-commit-action) from 6 to 7.
- [Release notes](https://github.com/stefanzweifel/git-auto-commit-action/releases)
- [Changelog](https://github.com/stefanzweifel/git-auto-commit-action/blob/master/CHANGELOG.md)
- [Commits](stefanzweifel/git-auto-commit-action@v6...v7)

---
updated-dependencies:
- dependency-name: stefanzweifel/git-auto-commit-action
  dependency-version: '7'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Bump github/codeql-action from 3 to 4 (BLAST-ImpactX#1176)

Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3 to 4.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@v3...v4)

---
updated-dependencies:
- dependency-name: github/codeql-action
  dependency-version: '4'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Fix `BeamMonitor`: Delay Open (BLAST-ImpactX#1178)

`BeamMonitor` opens the openPMD series now on first output. This
simplifies usage dramatically, now allowing to:

* create the lattice (monitor elements) before the `sim` is even
  initialized
* creating a monitor element and not using it in a lattice

* CMake `pip_install`: Package Examples (BLAST-ImpactX#1179)

Ensure the `examples/` directory is part of the `pip` wheels
we build, e.g., on `cmake --build build -j 6 --target pip_install`

* Envelope: Silence Warning w/o Space-Charge (BLAST-ImpactX#1173)

Consistent with the other two tracking modes, we only
print options upfront and do not warn every simulation
step if space charge is not used.

* Release 25.10 (BLAST-ImpactX#1180)

* Update Stub Files

* AMReX/ABLASTR/WarpX: development (BLAST-ImpactX#1177)

* ABLASTR/WarpX: development

Update the ABLASTR dependency to the latest development branch.

* pyAMReX: `development`

* Python: Improve `KnownElementsList` (BLAST-ImpactX#1181)

Add per-element by-reference access for manipulation.

* Update Stub Files

* Element Selection Syntax (BLAST-ImpactX#1182)

* Implementation

5hr vibe pair coded in Cursor. Maybe should have just done it xD

* Doc

* Fix Type Hints

* `select`: Fix All-Selected Path

Avoid implicit return of `None`

* Cleanup

* Update Stub Files

* Fix Python import errors (BLAST-ImpactX#1186)

* Update Stub Files

* Fix RFCavity edge case (BLAST-ImpactX#1185)

* Fix RFCavity edge case.

* Remove extra semicolon.

* Fix el typing (BLAST-ImpactX#1190)

* Fix `KnownElementsList` Stubs

Avoid importing `typing` for type hints, because pybind11-stubgen
forgets the import when generating `pyi` files...

* Update Stubs

* Update PALS to 0.2.0 (BLAST-ImpactX#1184)

* Update PALS version

* Fix missing imports in KnownElementsList.pyi

* Fix FODO example script

* Revert changes to stub file

* fix some math issues in examle documentation (BLAST-ImpactX#1191)

* "Starting step" Print: Spaces (BLAST-ImpactX#1187)

- newline before new step
- no space before `++++ Starting step`

* Element Names: All, `None` (BLAST-ImpactX#1189)

It is easier for user-facing workflows if `.name` exists
for all elements, even `Empty`.

In Python, instead of throwing an exception we return the
`None` value for elements without a user-provided name,
which simplifies user-logic. In this case `.has_name` is
`False`.

* Update Stub Files

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Axel Huebl <[email protected]>
Co-authored-by: Ji Qiang <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: ax3l <[email protected]>
Co-authored-by: Edoardo Zoni <[email protected]>
Co-authored-by: Richard Pausch <[email protected]>
@cemitch99
Copy link
Member

Screenshot 2025-10-17 at 3 11 30 PM Note: Something is still not quite right.

@cemitch99
Copy link
Member

cemitch99 commented Oct 20, 2025

@WeiqunZhang and @ax3l The test mentioned earlier today for this PR is located in: examples/expanding_beam/

C++ input file: input_expanding_fft_2D.in
Python input file: run_expanding_fft_2D.py

I have added a script for plotting the x-y beam size evolution called plot_expanding_fft_2D.py.

If the test works, the beam size at the end (at the maximum value of $s$ shown in the plot) should be 1 mm.

To see the convergence issue, I suggest running the Python test with npart = 1M for a few values of sim.blocking_factor_x and sim.blocking_factor_y. You can see the effect this has on the beam moments by running the plot script in each case.

@cemitch99
Copy link
Member

@WeiqunZhang and @ax3l Note: I tried the same test using 3D space charge (using examples/expanding_beam/run_expanding_fft.py after turning off mesh refinement), and this issue does not occur.

@cemitch99
Copy link
Member

cemitch99 commented Oct 30, 2025

@WeiqunZhang and @ax3l Here is the latest update: If I run the app example "input_expanding_fft_2D.in", then I always see that 1 grid is used, independently of the choice of blocking factor ("1 grids 1024 cells"), and the results are consistent:
ExpandingBeam_app_input
However, if I run the corresponding Python example "run_expanding_fft_2D.py", then as I change the blocking factor, the number of grids varies (bf = 32, grids = 1; bf = 16, grids = 4; bf = 8, grids = 16; bf = 4, grids = 64; bf = 2, grids = 256). The results are consistent for bf >= 8, but disagree for smaller bf. Here, the number of cells is [32,32,1] in each case.
ExpandingBeam_py_input

This issue has now been fixed. Thanks @WeiqunZhang !

@cemitch99
Copy link
Member

For this PR, we need to resolve the following error resulting in failing tests:

amrex::Abort::1::Particle container needs to have at least one grid. !!!
SIGABRT

Grids Summary:
Level 0 1 grids 1024 cells 100 % of domain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component: space charge Space charge & potential solver tracking: particles

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants