-
Notifications
You must be signed in to change notification settings - Fork 31
2D Space Charge in Particle Tracking #909
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
2D Space Charge in Particle Tracking #909
Conversation
| // 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? |
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.
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.
de299e6 to
7b53d47
Compare
7b53d47 to
79b5d1c
Compare
|
The test here currently fails with the simple error: We should make this error conditional on the space charge solver. This solver requires a grid size of 1 in z. |
cemitch99
left a comment
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.
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.
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
|
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. # 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 |
| 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] |
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.
The constants appearing in px and py are currently in draft form only, and will continue to be updated.
Keep simple for now.
Phi is then blown up again to 3D with indentical values in z. Co-authored-by: Weiqun Zhang <[email protected]>
|
@WeiqunZhang and @ax3l The test mentioned earlier today for this PR is located in: C++ input file: I have added a script for plotting the x-y beam size evolution called If the test works, the beam size at the end (at the maximum value of To see the convergence issue, I suggest running the Python test with npart = 1M for a few values of |
|
@WeiqunZhang and @ax3l Note: I tried the same test using 3D space charge (using |
|
@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: This issue has now been fixed. Thanks @WeiqunZhang ! |
Co-authored-by: Axel Huebl <[email protected]>
|
For this PR, we need to resolve the following error resulting in failing tests:
|
|
Fixed. |
…charge-particles-2D
|
@WeiqunZhang can you confirm what the last AMReX patch is that we need? Are there any newer than AMReX 25.11? |
|
Slack:
|
| amrex::IntVect num_guards_phi{num_guards_rho + 1}; // todo: I think this just depends on max(MLMG, force calc) | ||
| amrex::BoxArray phi_ba = cba; | ||
| if (space_charge == SpaceChargeAlgo::True_2D) { | ||
| num_guards_phi[2] = 0; | ||
| amrex::BoxList bl(amrex::IndexType{rho_nodal_flag}); | ||
| bl.reserve(cba.size()); | ||
| for (int i = 0, N = cba.size(); i < N; ++i) { | ||
| amrex::Box b = cba[i]; | ||
| b.convert(rho_nodal_flag).setRange(2,0); // Flatten box in z-direction |
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.
I am not particularly proud of the logic here and in PoissonSolve on how and when we allocate 2D fields. But I am ok to go ahead for now and clean it up in another go.



Add 2D Space Charge in Particle Tracking. First part of #401
To Do
ReduceToPlaneMFAMReX-Codes/amrex#4566For 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