Possible Tasks - in no particular order or level of priority - just for referencing.

<--
 Settings just to customise this page 
 

 Set ALLOWTOPICVIEW = TWikiGuest, JohnAdamsInstituteGroup
 
-->

LHC Simulation Priorities (in order of first to do)

1. Complete Teleporter / Terminator & Test
2. Create appropriate input distributions (not currently possible)
3. Optimise each stepper - as few things as possible - most called functions (easy and quick)
4. Significantly optimise geometry lookup to reduce simulation time (only ~1% tracking routines)
5. Factorise tracking (allow set of symplectic routines to be used for example)
6. Create tracker + geant4 collimator world to significantly speedup run time (over order of magnitude)

• Tasks are numbered only for identification purposes and not for order of completion or priority.

Task 1 - Complete bunch interfacing (placet etc)

• Stewart already on this - details from him

Task 2 - Factorise Tracking

• For tasks 2 - 5, some recent slides. See discussion in task 8 about sectional volume caveats.
• 2014_07_17_bdsim_plans_thoughts.pdf: 2014_07_17_bdsim_plans_thoughts.pdf
• 2014_07_17_bdsim_plans_thoughts.pptx: 2014_07_17_bdsim_plans_thoughts.pptx

Idea is to separate tracking routines (perhaps into subfolder) so we can switch between sets of them or have multiple sets - ie normal bdsim, symplectic, mixture. We can then easily add code that builds the accelerator out of only these tracking routines. This also lays the foundation for tasks 3 - 5.

Task 3 - Make tracking only option

Create a main function that builds accelerator lattice out of tracking routines only - geant4 not used. Can use openmp / parallelism. No geant4 at all.

Task 4 - Make tracking + collimator geant world

Create a main function that works similar to tracking only, but instead adds new special collimator routine. For each collimator a mini geant4 runmanager is created with a collimator in it. This is setup at the beginning (overhead) and when the particles are passed to this collimator, they are shot off as primaries in the single collimator mini geant4 world. Afterwards passed back.

This gives the soft scattering for halo particles that may remain in a ring for a long time.

Preliminary tests on a normal laptop allowed primaries through a simple geometry at near kiloHertz repetition rates. There are around 100 collimator elements in the LHC lattice.

Task 5 - Multiple mains for different run types

Task 6 - Complete different general geometry libraries

Task 7 - Rename BDSMultipole to BDSMagnet

Task 8 - Class Hierarchy for section of accelerator

• NOTE - the problem with creating a general volume (currently called marker volume) for each segment is the possible geometry overlap when you use the ggmad / BDSelement / lcdd / sql geometry formats.

If you build the beamline consisting of only the cylindrical magnets (or normal magnets) then the geometry is very 'flat' and has a lot of items at the same level of hierarchy - 2 -5 x compare to if a container volume is used. However, if you want to describe some custom object and place it next to the magnet, but your object would protrude from the segment (marker) volume, then a geometry error would occur. You could make the segment volume wide enough to encompass things easily, but you definitely have to be clever / check when you have a bend. Making a really wide segment volume would mean that even for low angles, the edges would touch -> geometry error.

I think having a segment volume is definitely a good way to go though as it makes things clearer. The segment volume could have a vector of the logical volumes it has in the order of their hierarchy. This is basically nothing new, but perhaps just renaming and modification of BDSAccleratorComponent. The ideas are all there, but the naming perhaps can just be a little clearer and formalised.

I don't yet know enough about how the general geometry works, but in the end it should generate a geant4 logical volume and do a geant 4 placement on it. It would make sense that this object generated from the geometry drivers would have introspective methods that would tell us its extend, in which case these could be used to check that they won't protrude from that section - or the section volume can be enlarged to accommodate it. The only problem with this is if the geometry driver object goes outside that segment longitudinally.

Task 9 - Removal of Beam Loss Monitor throughout everything

Task 10 - Factorisation / cleanup of detector construction

Task 11 - Tidy up Drift in BDSComponentFactory

• Should the code that checks and prepares input parameters be here or in a helper function on a class by class basis?
• Class arguments should be relatively uniform and pure

Task 12 - BDSIMHOME removal

• BDSGlobalConstants::Instance()->GetBDSIMHOME

This environmental variable was the way to get files relative to the input file previously and not the best way (although pragmatic) way. I've now fixed the parser so it'll follow relative paths correctly in the input file. The only thing is if this piece of code the parser is used to register input geometry files. If it is, then we should have a list / vector / map somewhere that stores the geometry files (ggmad, sql, lcdd) to be constructed later.

For now, there is only a get method in BDSGlobalConstants and no Set method. It's a private member variable so can't be set anywhere. It's not initialised either and I can't find "BDSIMHOME" anywhere in bdsim apart from in this file - is it used?

BDSElement - various geometry formats - presumably modelled on the ggmad example - use this to build up a path in the geometry building code (shouldn't be here!).

• These are numbered only for identification purposes and not for order of completion or priority.

1. Rename BDSMultipole to BDSMagnet?
2. Class hierarchy for section of accelerator
3. Removal of Beam Loss Monitor throughout everything
4. Factorisation / cleanup of detector construction
5. Tidy up Drift in BDSComponentFactory

Task 7 Notes - Rename BDSMultipole to BDSMagnet

• Currently called BDSMultipole, but used as a generic beam line segment / section.
• Drift is a multipole just now - perhaps not true.
• Drift also has an innerIronRadius…
• Also links to Task 8
• Drift inherits BDSMultipole, where as I think it should probably inherit BDSAccelerator Component

Task 8 Notes - Class Hierarchy for section of accelerator

The model of the accelerator is generally built up of segments of beam line based on a lattice description. It is also possible to attached extra placed objects within each segment - for example beam loss monitors, your custom detector class. These individual components for example don't need their own tunnel specification or things that a general segment of beamline needs.

• BDSAcceleratorComponent.hh has accessor functions for K strengths - perhaps this belongs in BDSMultipole - used for surveying the accelerator at construction - survey can be factorised out to not require these functions here.

• Perhaps BDSAcceleratorComponent -> (becomes) BDSAcceleratorSegment
• BDSMultipole -> BDSMagnet
• BDSAcceleratorComponent is used for generic component like a beam loss monitor, laserwire, detector placement

• Why does BDSAcceleratorComponent have 6 VisualAttributes?

• existing bdsim main class hierarchy:
  

Task 9 Notes - Removal of Beam Loss Monitor throughout everything

Beam loss monitor parameters, variables etc are spread throughout much of the code and get passed through many constructors through a slightly awkward inheritance. With Task 8 proposed hierarchy, you can stick in any (new task 8 type) BDSAcceleratorComponent. New BDSBeamLossMonitor inherits BDSAcceleratorComponent. BDSAcceleratorSection can contain any number of BDSAcceleratorComponents - ie a std::map <name,BDSAcceleratorComponent> in BDSAcceleratorSection. Geometry check after construction prevents overlapping with generic components a la the input specifications (boxsize, magnet type, etc).

Task 10 Notes - Factorisation / cleanup of detector construction

BDSDetectorConstruction is (by necessity) quite a big and detailed bit of code. However, there are a few simple steps that could make it simpler and clearer - even more so if we fiddle the hierarchy a little.

The first section of it deals with constructing all the materials and registering them. This section could easily be put into a function and put into BDSMaterials. It can then be called at the beginning of the detector construction. This code relies on an instance of BDSMaterials already existing (I think) so it would be an unbound method but contained in BDSMaterials.cc.

• Note there's slight confusion with the word "element" here. At the beginning it's used to mean a chemical element, but generally, it's a beam line segment that you can paste your own geometry etc into from external sources. It's also referred to as a general segment of beamline.

Below are the rough sequence of events that happen in detector construction as it currently stands (work in progress):

1. Define Materials / Elements / Atoms (what's the difference between elements an atoms here?) / Molecules / General Materials
2. Create component factory
3. iterate over beamline and create components
4. Define k values for 'beamline instance'
5. Put terminator on end if circular
6. iterate over the beamline and work out coordinates in preparation for defining the world
7. determine world size and build solids, logical volumes, field etc
8. create precision region and set production cuts for it
9. place the world
10. create sensitive detector manager
11. iterate over beamline and make list of marker logical volumes
12. iterate over the beamline
    • • Set up sensitive volumes
      • create shower models for multiple sensitive volumes
      • Work out their coordinates of where they should be placed
      • Place items in the world
13. iterate over the beamline
    • • build tunnel
      • build ggmad (geometry gmad) stuff and place it
14. iterate over the original beamline list from the parser and delete each object
15. return the world with everything in it

Task 11 Notes - Tidy up Drift in BDSComponentFactory

In BDSComponentFactory, there is a different approach for many items. For example for Drift there is a lot of precalculation and checking in the component factory code with debug output. This should clearly be included in the BDSDrift class. Relatively easy to tidy up.

BDSIM Code Week August 2014

Main Tasks

1. Complete bunch interfacing (placet etc)
2. Factorise tracking
3. Make tracking only option
4. Make tracking + collimator geant world
5. Multiple mains for different run types
6. Complete different general geometry libraries

Task Notes

Task 1 Notes

• blah blah blah

-- Public.LaurieNevay - 21 Jul 2014