SBend apparently not closed

[Stewart Boogert]

Based on

• bdsim : 692c05f (boogertDev)
• robdsim : aa84d2f (master)

in test/TrackingTestFiles/Bend/

• Simple single (drift, sbend, drift) system

d1: drift, l=0.5;
q : sbend, angle=0.05, l=0.5;
d2: drift, l=0.5;
m : marker;

l : line = (d1,q,d2,m);

use, period=l;

sample, range=d1;
sample, range=q;
sample, range=d2;
sample, range=m;

• 1 GeV e- beam

bdsim --file=Bend.gmad --batch --output=root 

In [1]: import robdsim
In [2]: r = robdsim.robdsimOutput("./output_0.root")
In [3]: r.GetOrbit(0)
robdsimOutput::GetOrbit> name,s,x,y,xp,yp : primaries 0 0 0 0 0
robdsimOutput::GetOrbit> name,s,x,y,xp,yp : Sampler_1_d1_phys_1 0.00100004 0 0 0 0
robdsimOutput::GetOrbit> name,s,x,y,xp,yp : Sampler_2_q_phys_1 0.501 0 0 0 0
robdsimOutput::GetOrbit> name,s,x,y,xp,yp : Sampler_3_d2_phys_1 1.00105 1.30042 0 5.20275e-06 0
robdsimOutput::GetOrbit> name,s,x,y,xp,yp : Sampler_4_m_phys_1 1.50105 3.90179 0 5.20275e-06 0

So after a simple bend (angle=0.05) in local (reference orbit) coordinates there appears to be a 1.50105 um shift.

The following plot is the ATF2 x and y orbit for a reference particle on axis, clearly as the beta functions get large the initial problem is amplified until there is an 8 mm oscillation towards the end of the line.

[Laurie Nevay]

I've addressed this with the sbendmarkvol branch. Previously, the sbend and rbend required an angled input and output face for their marker volume. This was achieved using a rhomboid. However, this primitive in Geant4 (G4Trd - 'trapezoid') is defined by its z length and then half widths in x and y at each end. Normally, in BDSIM we build along z with x and y transversely in both our beam coordinates and in general primitive coordinates (makes life easy). In this case though, z was used vertically - normal 'y' and then the volume rotated. In the end this meant that the length and the reference particle path length (due to placement) was dependent on many calculated sizes and not a parameter directly. Ie the 'length' of the sbend along the beam was determined by the midpoint on the angled side defined by the edges, which were calculated. This led to inevitable inaccuracy in placements and length definition.

In the end, of all the possible sizes of a component, we must be particularly precise about its length and therefore must construct the geometry using the best primitives so we don't have to calculate (or with as little calculation as possible) the length.

The use of this primitive also required multiple rotations - therefore of both the contents inside the marker volume and the marker volume during placement. The geometry interface that reads out rotation angles also read out this 90 degree rotation wrongly as well. Throughout detector construction and BDSBeamline and BDSBeamlineNavigator, there were string compares looking for the special cases of 'rbends' and 'sbends'. Making it quite messy and interlinked. Indeed when fixing the sbends, all the rbends were then incorrectly placed and rotated.

To fix this I've changed a reasonable amount.

Sbends - I now use a G4CutTubs primitive for the marker volume. Therefore, we only need to calculate the chordlength from the arclength. The defined length and therefore component placement are now better. This primitive defines a cylinder with angled faces. The angled faces are specified by normal vectors that are calculated from the half angle of the sbend. This choice of primitive avoids all the rotation back and forth (phew!) making the code simpler and also avoids lots of boolean solids for the magnet body volumes - making the LHC lattice for example 10 - 20% faster than before (even with each sbend split into 5!).

The closure of sbends is also better. Below is test data from Stewart's test above showing not perfect closure, but within 0.3nm. For the LHC lattice with sbends typically split into 5 sbends, the closure is <0.1um (note this is hard to judge as the LHC lattice uses h and v kickers). Compared to 1.5um (presuming these units from above output...) it's significantly better.

PDGID  E[GeV]          X[mum]          Y[mum]          Z[mum]          S[m]             
11     1.0000000000    0.0000000000    0.0000000000    0.0200000000
11     1.0000000000    0.0000000000    0.0000000000    0.0200000000
11     1.0000000000    0.0002498923    0.0000000000    0.0199999999
11     1.0000000000    0.0002498923    0.0000000000    0.0200000002

Rbends - as already mentioned, fixing the sbends by changing the primitive and removing the rotation throughout placement broke the rotation during placement of rbends too. Note the placement rotation test tested on if the accelerator component had an angle whereas the placement position tested on 'rbend' and 'sbend' - inconsistent behaviour. I used the same primitive for the RBend too.

The previous Rbend uses a small drift, magnet, small drift to make sure the magnet body fits completely inside the marker volume for that section of beamline and doesn't protrude into the previous marker volumes. However, the calculation was slightly wrong and there were overlapping volumes - this causes particles (typically secondaries in the magnet bodies) to get stuck during tracking. The G4CutTubs primitive was used and the dimension calculation fixed.

NOTE - we should revise the rbend in future. Currently, a small drift is added and the field slightly upscaled - causing the same angle change in a reference particle, but not strictly accurate.

Detector Contruction - placement & rotation. This had to be fixed to remove the now unnecessary rotations and check the placement (for best closure). Note, even if the element length and field are described perfectly, the reference particle orbit may not close due to misplacement of the volumes where it can accrue tiny bits of extra drift space and therefore offsets.

World Size - after fixing the detector construction for the new rbends and sbends, the calculation of the world size was wrong - again dependent on string compares looking for rotations in rbends and sbends. This was fixed by using the information stored in BDSBeamlineNavigator inside BDSBeamline. When accelerator components are pushed back onto the beamline, the extend of the beamline is now calculated. Previously the coordinates were also calculated, but never used anywhere in the code.

Previously, there were several loops over the beamline in BDSDetectorConstruction that repeatedly calculated the extend of the machine. At least one of these loops has been removed as the you can query the BDSBeamline object to ask its extend and build the World Volume as needed now. This reduces the amount of code, makes it simpler and avoids possible errors. Changing the sbend construction really shouldn't have resulted in such extensive changes to the construction of the accelerator. Now, the construction is much more generic and the world construction process doesn't need to know anything about specific items.

World size - note the world has to be placed at (0,0,0). We make the world symmetric gives it's maximum extend in each dimension. this results in quite a lot of empty world. However, were we to offset the beamline in the world to fit it in a smaller box, we would have to subtract this offset whenever we get global coordinates throughout the code. Making a slightly smaller world has no advantage so there's no point in this. Adding this beamline offset throughout the code would be extensive and pointless also. So, if the world appears a little big, that's why.

Note, you can use the visualiser with the debug build. The marker volumes (containers for each magnet) are transparent green. In the scene tree, you can change the world edge colour to black so you can see the box. Attached are a few examples of very bendy machines that were used to test world calculation, placement and tracking closure for reference particles.

H & VKicks - these normally used the member variable "itsAngle" from BDSAcceleratorComponent. Now in placement, this is regarded as the angle the reference coordinates are changed by in curvilinear coordinates. So with H and V kicks, they don't change the reference coordinate system for building. To avoid this placement error, they now use a new internal member variable called "itsKickAngle" - akin to the angle of the dipolar field but not "itsAngle" so doesn't affect placement.

[Laurie Nevay]

Previous Rbend poking through sampler with strong angle. Normally, smaller angles are used, but this is indicative of a geometry mistake.

[Laurie Nevay]

Test lattice with strong sbend and rbend for an easily visible angle. Note here the particle leaves the rbend as it hits the narrow aperture for such a strong bend - it does work properly. Note the rbend geometry including a small drift on either side. For low angles these are very small.

[Laurie Nevay]

A very bendy machine indeed. Note this would've failed before but the one initial 3/4 (2pi) sbend is split into many many sbends. World volume accurately determined.

[Laurie Nevay]

World volume size calculated correctly. This image shows how the machine extent is used as a world box half size resulting in a good bit of empty space. This is ok.

[Laurie Nevay]

I tagged the develop branch as v0.63 before my changes. I've merged in all of my changes (potentially closing this issue) into develop. Please test yourselves (I don't have the best ATF2 model for example) and let me know of any problems.

[Laurie Nevay]

see all the previous comments for the fix