Particle trajectory reverses at end of gantry.

Issue #241 resolved
William Shields created an issue

Particle trajectory 'reverses' and travels backwards at the end of the final dipole in an example medical machine when using transform3d to rotate the gantry. It appears only when using the bdsimtwo integrator set, and when the dipole has a negative angle exit poleface rotation.

Tilting the elements instead of using a transform3d does not produce the bug. It occurs irrespective of fringe field inclusion. It does not occur in single component tests of the machine elements when also using transform3d.

Two files are attached, one with the machine using transform3d, the other using tilt.

The bug occurs in both the develop and master branches. Using G4 v 4.10.4.p02.

Comments (6)

  1. Laurie Nevay

    Confirmed. And only for +ve e2 on the outgoing pole face. The navigation shows it's not leaving the beam pipe correctly.

    Unfortunately, tilt is not correct for what we want to do.

    791   0.323    3.14e+03 7.72e+03 250       0        5.31e-07 1.05e+04  World       CoupledTransportation
    792   0.323    3.14e+03 7.72e+03 250       0        3.19e-06 1.05e+04  BM12_mod_0_14_0_pv CoupledTransportation
    793   0.323    3.14e+03 7.72e+03 250       0        5.34e-07 1.05e+04  BM12_mod_0_14_beampipe_pv CoupledTransportation
    794   0.323    3.14e+03 7.72e+03 250       0        2.15e-06 1.05e+04  BM12_mod_0_14_vacuum_pv CoupledTransportation
    795   0.323    3.19e+03 7.72e+03 250       0        53.1     1.06e+04  BM12_mod_0_14_beampipe_pv CoupledTransportation
    796   0.323    3.19e+03 7.72e+03 250       0        2.2e-06  1.06e+04  BM12_mod_0_14_0_pv CoupledTransportation
    797   0.323    3.19e+03 7.72e+03 250       0        5.45e-07 1.06e+04  World       CoupledTransportation
    798   0.323    3.19e+03 7.72e+03 250       0        3.28e-06 1.06e+04  BM12_mod_0_13_0_pv CoupledTransportation
    799   0.323    3.19e+03 7.72e+03 250       0        5.47e-07 1.06e+04  BM12_mod_0_13_beampipe_pv CoupledTransportation
    800   0.323    3.19e+03 7.72e+03 250       0        2.21e-06 1.06e+04  BM12_mod_0_13_vacuum_pv CoupledTransportation
    801   0.323    3.2e+03  7.72e+03 250       0        10.9     1.06e+04  BM12_mod_0_13_beampipe_pv CoupledTransportation
    802   0.323    3.2e+03  7.72e+03 250       0        3.05e-06 1.06e+04  BM12_mod_0_13_beampipe_pv CoupledTransportation
    803   0.323    3.22e+03 7.73e+03 250       0        15.8     1.06e+04  BM12_mod_0_13_beampipe_pv CoupledTransportation
    804   0.323    3.22e+03 7.73e+03 250       0        0.00311  1.06e+04  BM12_mod_0_13_0_pv CoupledTransportation
    805   0.323    3.24e+03 7.73e+03 250       0        28.1     1.06e+04  World       CoupledTransportation
    806   0.323    3.24e+03 7.73e+03 250       0        3.34e-06 1.06e+04  BM12_mod_0_12_0_pv CoupledTransportation
    807   0.323    3.3e+03  7.74e+03 250       0        56       1.07e+04  World       CoupledTransportation
    808   0.323    3.3e+03  7.74e+03 250       0        3.39e-06 1.07e+04  BM12_mod_0_11_0_pv CoupledTransportation
    809   0.323    3.3e+03  7.74e+03 250       0        0.962    1.07e+04  World       CoupledTransportation
    810   0.323    1.02e+04 8.78e+03 250       0        6.93e+03 1.76e+04  OutOfWorld  CoupledTransportation
    

    whereas we should expect:

    766   0.323    2.99e+03 7.71e+03 250       0        3e-06    1.03e+04  BM12_mod_0_18_0_pv CoupledTransportation
    767   0.323    2.99e+03 7.71e+03 250       0        5.01e-07 1.03e+04  BM12_mod_0_18_beampipe_pv CoupledTransportation
    768   0.323    2.99e+03 7.71e+03 250       0        2e-06    1.03e+04  BM12_mod_0_18_vacuum_pv CoupledTransportation
    769   0.323    2.94e+03 7.71e+03 250       0        48.6     1.03e+04  BM12_mod_0_18_beampipe_pv CoupledTransportation
    770   0.323    2.94e+03 7.71e+03 250       0        1.99e-06 1.03e+04  BM12_mod_0_18_0_pv CoupledTransportation
    771   0.323    2.94e+03 7.71e+03 250       0        4.98e-07 1.03e+04  World       CoupledTransportation
    772   0.323    2.94e+03 7.71e+03 250       0        4.5e-06  1.03e+04  BM12_mod_0_e2_fringe_0_pv CoupledTransportation
    773   0.323    2.94e+03 7.71e+03 250       0        9.9e-05  1.03e+04  World       CoupledTransportation
    774   0.323    2.94e+03 7.71e+03 250       0        4.5e-06  1.03e+04  DR64_mod_0_0_pv CoupledTransportation
    775   0.323    2.94e+03 7.71e+03 250       0        2e-06    1.03e+04  DR64_mod_0_vacuum_pv CoupledTransportation
    776   0.323    2.94e+03 7.71e+03 250       0        0.0212   1.03e+04  DR64_mod_0_vacuum_pv SamplerWorld_main
    777   0.323    2.94e+03 7.71e+03 250       0        1e-06    1.03e+04  DR64_mod_0_vacuum_pv SamplerWorld_main
    778   0.369    1.44e+03 7.71e+03 250       0        1.5e+03  1.18e+04  DR64_mod_0_0_pv CoupledTransportation
    779   0.369    1.44e+03 7.71e+03 250       0        2e-06    1.18e+04  World       CoupledTransportation
    780   0.369    1.44e+03 7.71e+03 250       0        1.5e-06  1.18e+04  World       SamplerWorld_main
    781   0.369    1.44e+03 7.71e+03 250       0        1e-06    1.18e+04  World       SamplerWorld_main
    782   0.727    -1.02e+04 7.71e+03 250       0        1.16e+04 2.34e+04  OutOfWorld  CoupledTransportation
    

    This likely means the tolerance is insufficient between the vacuum and beam pipe container volume. We should see this elsewhere but it could be because of the strong angle and compounded transforms.

  2. Laurie Nevay

    I also see this with the geant4 integrator set.

    I've tried with different beam pipe shapes and shrunk the beam pipe inside the magnet by another length safety but nothing had any impact.

    Given it happens with geant4 and bdsimtwo integrator sets and it also doesn't hit the fringe field, it must be a problem with geometry navigation or the field supplied (which will include transforms to the CL frame).

    Printing out the supplied global field, we see some weird behaviour:

    (-0.0015918288388358,9.7471404613534e-20,0)
    (-0.0015918288388358,9.7471404613534e-20,0)
    (-0.0015918288388358,9.7471404613534e-20,0)
    532   0.323    2.94e+03 7.71e+03 250       0        48.6     1.03e+04  BM12_mod_0_18_vacuum_pv SamplerWorld_main
    (0,0.001591828838835767,0)
    (0,0.001591828838835767,0)
    533   0.323    2.94e+03 7.71e+03 250       0        0        1.03e+04  BM12_mod_0_18_vacuum_pv SamplerWorld_main
    (0,0.001591828838835767,0)
    (0,0.001591828838835767,0)
    (0,0.001591828838835767,0)
    (0,0.001591828838835767,0)
    534   0.323    2.99e+03 7.71e+03 250       0        48.8     1.03e+04  BM12_mod_0_18_0_pv CoupledTransportation
    (-0.001591828838835767,9.747140461353352e-20,0)
    (-0.001591828838835767,9.747140461353352e-20,0)
    (-0.001591828838835767,9.747140461353352e-20,0)
    (-0.001591828838835767,9.747140461353352e-20,0)
    

    Note the field flipping to +ve Y. I'm not sure this should reflect the particle, but it's clear, there's mis-navigation with the parallel sampler world. Turning the samplers off fixes the problem. With such a lattice the reference orbit may be offset. With a different sign of e2, this explains why we see different behaviour. Also, the samplers aren't rotated to match the pole face - now nominally, Geant4 says overlapping volumes shouldn't be a problem but we've generally found them to always be a problem.

    We can have a look at the sampler placement given the rotated beam line (possible placement transform issue) and we can also think about the padding for samplers between elements, or we can consider not placing samplers at a pole face - this of course won't match optics anyway as it intercepts particles in and outside the dipole. It'd be very hard to represent particles in a sampler the way a tracking program does.

  3. William Shields reporter

    I ran the lattice with the bdsimmatrix set and that shows there is a horizontal offset of ~ -100 nm (CL co-ordinates) after the final dipole. Assuming bdsimtwo would exhibit the same small offset, this would place the particle still in the magnet when being sampled, and as you rightly said, flipping the poleface sign removes the problem. Could this problem be due to the fact that the particle would be in both the sampler, and magnet (with field) at the same time?

    We could unintentionally solve this with the proposed changes to permit angled poleface geometry with thin element tracking as the beam pipe faces would be perpendicular to the reference trajectory, so the sampler world and the beampipe part of the physical world should never overlap. This would also give us the benefit that the optics would be correct too.

    This obviously wouldn't solve this issue in the long term as this behaviour may happen elsewhere in the future, but should prevent us seeing it in this particular scenario.

  4. Laurie Nevay

    Yes, I think you're right - we would just avoid it with the behaviour of bdsimmatrix integrator set. However, I don't want to abandon the bdsimtwo one as I'll at least continue to use that for my studies. Also, we planned to put the pole face rotations back (at least for the beam pipe) so we may reintroduce it / make it visible again.

    How about for every integrator set other than bdsimmatrix (currently) if there is a finite pole face angle, we set the sampler to no sampler for that element (and the beam pipe beforehand).

    Note, the bdsimtwo integrator set would give a different local horizontal position vs bdsimmatrix for strong angle bends. The problem definitely exists, but we're just unlucky hitting the extremely small overlap with the sampler.

    I think this could always be a problem and there's no technical way around it so best remove the possibility.

  5. William Shields reporter

    Ok, makes sense. When I get the update working I'll only make it available for the bdsimmatrix set then. It could be rolled out to the other sets too in time, but obviously we'd have to do a large set of dipole tracking comparisons as all dipoles would be constructed differently, but that's for the future if we decide to do it.

    I agree with you, exclude dipoles with finite polefaces and the immediately previous element from sample, all. An option to override that may be useful though.

    I know that the different integrator sets will give different positions, particularly for strong bends, but I imagine at least the sign of the offset will be the same for both sets. Mainly because the sign of the dipole angle will have a big influence on it purely from the way the dipoles are constructed. As you say, we were unlucky with this example but lucky that we found it at all really.

  6. William Shields reporter

    BDSIM has been updated so samplers will no longer be placed directly before or after elements which have angled faces. This behaviour will occur for the bdsimtwo, geant4, and geant4dp integrator sets. Changes have been merged into develop.

  7. Log in to comment