Add accelerator lattice, starting with quadrupoles #3063
Conversation
…tor_lattice_quads
for more information, see https://pre-commit.ci
|
This pull request introduces 2 alerts when merging fa21501 into 8eb3163 - view on LGTM.com new alerts:
|
dpgrote
force-pushed
the
add_accelerator_lattice_quads
branch
from
615f933
to
93ad406
Compare
It is not clear why there was a change, but the difference is essentially round off in the E field. The important thing is that the particles are still correct.
| @@ -1384,6 +1390,54 @@ External fields | |||
| and :math:`E_z = 0`, and | |||
| :math:`B_x = \mathrm{strength} \cdot y`, :math:`B_y = -\mathrm{strength} \cdot x`, and :math:`B_z = 0`. | |||
|
|
|||
| Accelerator Lattice | |||
There was a problem hiding this comment.
@dpgrote @cemitch99 let us double check again if we can keep them as close as possible to ImpactX :)
https://impactx.readthedocs.io/en/latest/usage/parameters.html#lattice-elements
There was a problem hiding this comment.
Looks good on first view to me. See plasmalens -> ConstF below.
| * ``<element_name>.dBdx`` (``float``, in Tesla/meter) optional (default: 0.) the magnetic quadrupole field gradient | ||
| The field applied to the particles will be `Bx = dBdx*y` and `By = dBdx*x`. | ||
|
|
||
| * ``plasmalens`` for a field modeling a plasma lens |
There was a problem hiding this comment.
Checking how similar this is in ImpactX to ConstF element with @cemitch99
There was a problem hiding this comment.
Discussed on slack: ConstF is more general. We might want to replace plasmalens with the equivalent description of ConstF in a follow-up PR.
There was a problem hiding this comment.
Yes, using the more general ConstF would be good in a later PR. In this PR, I wanted to reproduce the existing capability.
| lattice.elements = lattice1 lattice2 | ||
|
|
||
| lattice1.type = lattice | ||
| lattice1.elements = drift1 quad1 | ||
|
|
||
| lattice2.type = lattice | ||
| lattice2.elements = drift2 quad2 | ||
|
|
||
| drift1.type = drift | ||
| drift1.ds = 0.2 | ||
|
|
||
| quad1.type = quad | ||
| quad1.ds = 0.2 | ||
| quad1.dEdx = 1.e4 |
There was a problem hiding this comment.
Clever recursive way to do segments 🤓
We could to the same in ImpactX @cemitch99 ?
There was a problem hiding this comment.
Will track here ECP-WarpX/impactx#284
There was a problem hiding this comment.
Implemented via ECP-WarpX/impactx#335
Add include statements Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
Add includes Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
for more information, see https://pre-commit.ci
| A list of names (one name per lattice element), in the order that they | ||
| appear in the lattice. | ||
|
|
||
| * ``<element_name>.type`` (``string``) |
There was a problem hiding this comment.
@dpgrote I just realized we forgot to document the lattice type here, for lines.
There was a problem hiding this comment.
Discussed offline: will add and rename to line
This PR is the initial implementation of an accelerator lattice, starting with hard edge quadrupoles. The implementation follows the scheme in Warp, where the lattice is laid out along the
zaxis. Each lattice element is specified by an extent inzand information about its field structure.To locate which element particles are in, a grid is laid out in
zand at each grid cell, the index of the nearest element is saved. Then for each particle, a look up is done from the table. This grid is updated as needed in a moving frame and with load balancing.For the GPU, host level and device level classes are defined. The data is read in and setup in the host level class and the needed data copied to the GPU. The device level class only holds pointers to the needed data. This hasn't been tested but does compile.
To do:
This PR assumes that elements within a type do not overlap each other. A future PR can be added to allow the overlapping.