|
META TOPICPARENT |
name="BDsimDevelopment" |
BDSIM Code Week August 2014
|
|
< < | Main Tasks |
> > |
- Tasks are numbered only for identification purposes and not for order of completion or priority.
|
| |
|
< < |
- These are numbered only for identification purposes and not for order of completion or priority.
|
> > | |
| |
|
< < |
- Complete bunch interfacing (placet etc)
- Factorise tracking
- Make tracking only option
- Make tracking + collimator geant world
- Multiple mains for different run types
- Complete different general geometry libraries
- Rename BDSMultipole to BDSMagnet?
- Class hierarchy for section of accelerator
- Removal of Beam Loss Monitor throughout everything
- Factorisation / cleanup of detector construction
- Tidy up Drift in BDSComponentFactory
Task Notes
Task 1 Notes |
> > | Task 1 - Complete bunch interfacing (placet etc) |
| |
|
> > |
- Stewart already on this - details from him
|
| |
|
< < | Task 7 Notes - Rename BDSMultipole to BDSMagnet |
> > | Task 2 - Factorise Tracking
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 |
|
- Currently called BDSMultipole, but used as a generic beam line segment / section.
- Drift is a multipole just now - perhaps not true.
|
|
- 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 |
> > | Task 8 - 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. |
|
- existing bdsim main class hierarchy:
|
|
< < | Task 9 Notes - Removal of Beam Loss Monitor throughout everything |
> > |
- 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 |
|
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 |
> > | Task 10 - 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. |
|
- iterate over the original beamline list from the parser and delete each object
- return the world with everything in it
|
|
< < | |
> > | |
|
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. |
|
> > |
- 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
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!). |
|
-- LaurieNevay - 21 Jul 2014 |
|
-- LaurieNevay - 21 Jul 2014 |
|
> > | |
|
META FILEATTACHMENT |
attachment="Screen_Shot_2014-07-23_at_14.07.36.png" attr="" comment="existing bdsim main class hierarchy" date="1406121114" name="Screen_Shot_2014-07-23_at_14.07.36.png" path="Screen_Shot_2014-07-23_at_14.07.36.png" size="279061" user="uxap005" version="1" |
|
|
> > |
META FILEATTACHMENT |
attachment="2014_07_17_bdsim_plans_thoughts.pdf" attr="" comment="" date="1406286421" name="2014_07_17_bdsim_plans_thoughts.pdf" path="2014_07_17_bdsim_plans_thoughts.pdf" size="2274935" user="uxap005" version="1" |
META FILEATTACHMENT |
attachment="2014_07_17_bdsim_plans_thoughts.pptx" attr="" comment="" date="1406286435" name="2014_07_17_bdsim_plans_thoughts.pptx" path="2014_07_17_bdsim_plans_thoughts.pptx" size="1212553" user="uxap005" version="1" |
|