Field Modelling Tools in G4MICE MICE VC Chris Rogers 1st Feb 2006

Overview Simulation plays an important role in MICE –Use for design and analysis –Also verification/optimisation of simulation is a goal of MICE –Important that software is upgradable and maintainable Simulation has five main components –DetModel builds the model for detectors –EngModel builds the model for the cooling channel –Interface/Persistency handles file I/O and user inputs –BeamTools builds the model for the fields (and some engineering) –Simulation ties them all together and interfaces it all with G4 I’m going to describe recent work to redesign the BeamTools library –Move away from an ICOOL-style set of generic beam elements –Clean up and rewrite large amounts of code –Eventually EngModel will handle all physical engineering of the cooling channel

Motivation BeamTools previously consisted of a set of generic beam elements placed by EngModel –This means we can’t include an arbritrary level of detail in the cooling channel Elements had awkward interface –E.g. every time the user built a solenoid, first need to define each current sheet BeamTools code was clunky and over-complex –Lots of duplication of work (cutting and pasting) –Difficult to maintain and upgrade I want Analysis and Optics libraries to see the fields but not GEANT4 –Access to large libraries like G4 slows down Analysis even if they are not used –Engineering description is not useful for Analysis

Old BeamTools Architecture BTMagFieldMapBTSolenoidBTPillBoxQ35 BTGlobalMagField BTSheet BTGlobalEMField BTAccelDevice BTLinacCellPhaseInfo BTMagFieldMapPlacement

New BeamTools Architecture BTField BTMagFieldMapBTSolenoidBTPillBoxQuad (not yet) BTFieldGroup BTSheet BTFieldConstructor BTPhaser MICEMagFieldMICEEMField

Features BTField is a generic object (virtual) –Means I can write an interface to a generic field –A given function doesn’t need to know the type of field it is talking to –E.g. I can ask a field what the field value is without knowing what sort of field (solenoid, rf cavity, etc) it is –Something similar existed before but in GEANT4, so we could not control it BTFieldGroup is a generic container for BTFields –Handles placement of fields –Generic interface of BTField means I can place any BTField –E.g. build a BTFieldGroup for each module Implementing MICE stages becomes extremely easy –RF cavities can now be rotated

Features (cont.) BTFieldConstructor reads geometry and builds the fields –It is a special BTFieldGroup –Builds each module as a BTFieldGroup BTPhaser sets the phase by a call to BTFieldConstructor whenever the reference particle steps –BTFieldGroup hands the call down to all the other fields –Write special code in the BTPillBox function to set the phase –Can do this in any new field class without knowing anything about BTPhaser, BTFieldGroup –BTPhaser methods can be called from any function Lots of things need to know whether the phase needs to be set MICEMag/EMField communicate with GEANT4 –Don’t do anything except provide an interface with G4 ~50% less code for much more functionality –64.1 Kb vs 93.8 Kb –Easier to maintain –Easier to extend

Sample MICE Channel BTFieldConstructor MICE FieldGroup RFCC0 FieldGroup AFC1FieldGroup AFC0 FieldGroup Tracker0FieldGroup Tracker1 FieldGroup RFCC1 FieldGroup Linac1FieldGroup Linac0 Example of some of the objects in a MICE Stage VI FieldGroup FieldGroup AFC BTSolenoid Focus1 BTSolenoid Focus0

On axis B z On axis Bz looks ok Compare G4MICE with ICOOL (right hand plot) –Different by ~ 1% Slightly different algorithms –I think ICOOL generates the grid and writes directly to disk –G4MICE generates a grid and then interpolates Only five sheets [Bz(ICOOL) - Bz(G4MICE)]

Off axis B z Off-axis looks okay –Something interesting going on in the coils –ICOOL and G4MICE placing the coils in slightly different places? I need to check –Introduces significant differences but only inside material [Bz(ICOOL) - Bz(G4MICE)]

Off axis B r Again a few significant differences –Again quite far out from the beamline –Worst near AFC At least the beam is quite tightly focused there –Perhaps better/more accurate with more sheets [Br(ICOOL) - Br(G4MICE)]

RF Model Standard PillBox model –E-field given by Bessel(r/r0)*sin(  t) where r0 is some factor of the cavity radius –B-field also calculated (faint plot is B  * 100 [T]) –Cavity radius according to the frequency of the cavity Phase using reference particle –Reference particle should see only mean dE/dz and no MSc –Bug means it also gets a small amount of MSc (bug 77) I think a problem with GEANT4 to do with knock-on electrons R = 2.405c/ 

Beam Transport Beta function looks reasonable –Beams have 0 energy spread initially –Black has no material or RF –Red has LH2 and RF, no rf windows or detectors –TRD magnets Angular Momentum also nice –Canonical angular momentum is ~conserved (reassuring!) L can L kin

Cooling Energy looks good –Cavities phase to ~ 100 ps precision –Would be nice to do better but hampered by Ref Particle bug Cooling nicely (~ 13% cooling) –Worried by the emittance spike in the third absorber –Why here (and e.g. not in the other absorbers)? –Probably Virtual Planes algorithm

Amplitude Momentum Correlation Amplitude momentum correlation –Initially non-zero as I use E, t as my longitudinal phase space variables Worried about the spike

Processing Speed First attempt at profiling time spent in each G4MICE func BeamTools accounts for ~ 5% of G4MICE processor time –Less (as a %) if simulating detectors –Significant enough to be worth keeping an eye on New code is a fair bit slower –New BT slower at transforming between local and global coords –Transforms twice, once to the module FieldGroup and once to the global field group –May be possible to improve performance New BT/sOld BT/s BeamTools Setup (Building field maps etc)30.5 Interpolation between bfield map grid nodes Calculating solenoid field after interpolation3453 Transforming from global coordinate system13327 Total time in G4MICE libraries665368

To do Still need to implement –Quads –RF field map –Electrostatic cavity? –Iron Would like to start moving engineering model to EngModel –E.g. use same window class for absorbers and rf –Needs to happen before I can commit the code May be some optimisation to do ito speed –Is it better to have fast code or working code?