Andrei Gheata ALICE off-line week, March 4, 2003

1. Status of geometrical modeler Andrei Gheata ALICE off-line week, March 4, 2003

2. Topics • Final goal reminder • Navigation features : status & performance • New features on visualization, I/O, user interface • Geometry checking interactive utility • Status of VMC integration • Next steps

3. Simulation program Geant3-based Geant4-based Fluka-based Monitoring Geometry package C++ classes Reconstruction program ... MySQL Visualisation Why a new modeler ? • The geometrical package is intended as a toolkit to provide the geometrical description of an experiment, tracking-related functionality + additional tools to ease-up building, checking and debugging a geometry. In particular, it will allow us to run different simulations and reconstruction through the same interface.Bonuses :increased speed and performance, full decoupling of user code from external simulation engines.

4. Requirements • Tracking-related functionality - (''Where am I?'', ''Which next and how far?'', ...) • Backward compatibility - to be able to reuse Geant3 geometries • Scalability - LHC geometries are big, we have to be able to represent them • Performance - it should be faster than existing modelers • Interactivity - users should be able to access easily all relevant geometry information + checking tools, builder interface, ...

5. Navigation features - status • These make the difference between a geometrical modeler and a transient store providing geometrical input for other applications. • Long way from implementing to validating/optimizing/ tuning these features => took most of the time • Luckily we had a gold mine of G3 geometries to test upon. • ''Where am I ?'' => done and happy with • Computing the distance to next boundary => done and working, some optimization for the most simple topologies needed • Safety => globaly computed when needed, seem to work • Normals to crossed surfaces => on demand (ongoing)

6. Root > .x mygeom.C Zebra memory Data structure JVOLUM JMATE,etc void gexam1() {TGeoMaterial *mat; TGeoMixture *mix; TGeoManager *gexam1 = new TGeoManager("gexam1","gexam1.C"); //-----------List of Materials and Mixtures-------------- mat = new TGeoMaterial("mat9","ALUMINIUM",26.98,13,2.7); mix = new TGeoMixture("mix10","IRON(COMPOUND)",3); mix->DefineElement(0,55.847,26,0.703964); mix->DefineElement(1,58.71,28,0.9900000E-01); mix->DefineElement(2,51.998,24,0.197); mat = new TGeoMaterial("mat11","COPPER",63.54,29,8.96); Geant > RZ/File 21 mygeom.geom on Zebra RZ mygeom.geom g2root mygeom.geom mygeom.C Automatic conversion from Geant3 Mygeom.c

7. Use one million points generated by Geant3 with full physics switched on Validation procedure

8. Validation procedure (2) • Using points generated by Geant3 applications • grecord.f --> mygeom.geom, mygeom.hbook • Play-back these points in Geant3 using only the Geant3 geometry package. Compute g3path, snext, safety in myresults.hbook • h2root myresults.hbook myresults.root • Same operation with TGeo classes. Compare g3path with tgeopath, same for snext, safety • Some discrepancies with Geant3 : • Due to precision problems in Geant3 (single precision geometries collected), points recorded at the volume boundaries may be found on the other side by TGeo. • When volumes declared MANY in Geant3 overlap and have sub-volumes also MANY, Geant3 is not always reporting the right answer. In general it does not matter, sometimes it does • In this exercise, we also found original errors in the detector description, e.g. wrong paramers

9. ROOT modeler benchmarks vs. GEANT3 • 1 mil. Points extracted from G3 simulation (full physics) • Point re-injected both in G3 and ROOT modeler, timings/track [microseconds] presented in the table.

10. ''Where am I ?'' - physics

11. ''Where am I ?'' - random

12. ''Distance to next ?'' - physics

13. ''Distance to next ?'' - random

14. New features • Visualization • Perspective view in ROOT pad • Volume focusing on double-click • HLR/HSR algorithms to be implemented • Simple tests for all navigation features (random points, raytracing, safety visualized, lego plots for radiation length) • User interface • Added methods for compatibility with the virtual MC • Most user actions for building geometry are now protected against errors

15. Detector weight • Volume/detector weight estimation • Based on randomly sampling current material (“where am I?”) • Desired accuracy as input (default 1%) • Weight of gases ignored (can be significant due to virtual containers) • Some values : • TPC : 7553 +/- 70 [kg] • ITSD : 39.657 +/- 0.356 [kg] • ABSM : 36634 +/- 146 [kg] • DDIP : 814161 +/- 5073 [kg] • PHOS : 18201 +/- 113 [kg] • B076 : 4396 +/- 41 [kg]

16. Number RZ file text file(.C) root file nodes (kBytes) (kBytes) (kBytes) Alicenew 3080198 ->mem 2714 3070 Atlas 29046966 9863 5872 3554 Brahms 2649 688 149 101 CDF 24422 2412 1350 1252 CMS 1166310 13296 1930 1284 LHCb 1533488 2121 1053 1215 I/O - file size • The size of the .root file and time to read are very important when developing a geometry. • .root files includes full voxelization

17. Geometry checker • It has to be able to checks for illegal extrusions/overlaps in the geometry definition. • Few possible approaches : • Primitive to primitive (shapes) intersection algorithms (136 combinations in our case ...) • Mesh to mesh intersection => polygon to polygon, not fully accurate, but at least feasible, since all shapes have already meshes used by visualization • Vertices approach : similar to mesh approach, but using only vertices information and the Contains(point) methods of shapes.

18. Extrusions • A given positioned volume should not extrude its container. (unless declared MANY • Verticesapproach necessary conditions : • All vertices of a volume have to be contained by its container • None of the container vertices should be contained by any daughter • For better results, the number of segments approximating tubes,cones,..., was set to 80. Detected Not detected

19. Overlaps • A given volume should not intersect any brother volume (if none of the two is MANY) • Verticesapproach necessary conditions : • All vertices of a volume have to be outside all its brothers • N(N-1) combinations to check if a volume has N daughters Detected Not detected

20. Checking ALICE geometry • The vertices approach is definitely unable to find all overlaps in a geometry, but : • It finds the most frequent ones (more than 90%) • It is very fast : ~20 seconds for full ALICE • Is able to estimate how big the overlap/extrusion is • Implementation : graphical interface producing a sorted list of overlaps per volume/geometry; the overlaps are drawable objects giving the full information about the overlap topology. • Full ALICE : ~160 overlaps/extrusions bigger than 1 mm found, ~200 bigger than 100 microns

21. G3 G3 transport User Code VMC G4 G4 transport FLUKA FLUKA transport Reconstruction Virtual Geometrical Modeller Visualisation Geometrical Modeller The Virtual MC • Allows running several MC's starting from the same code and having the same geometry for simulation, reconstruction and event display. Geant3.tar.gz includes an upgraded Geant3 with a C++ interface Geant4_mc.tar.gz includes the TVirtualMC <--> Geant4 interface classes Generators

22. TGeo integration to VMC • Started early this year by Rene -> new TGeant3 • Required few modifications in the API + implementation of a new class TGeoMedium • Methods to ease-up geometry building implemented in the manager class: Material(), Medium(), Matrix(), Volume(), Node(), Division() following as close as possible prototypes in VMC • Functionality of navigation methods adapted to match VMC requirements

23. TGeant3 • Can be compiled/run in 3 ways : • G3 standalone (default) • G3 + TGeo, G3 navigator : for debugging and validation purposes • TGeo as main navigator : not fully working yet • Can fully build ROOT geometry in AliRoot • Is able to compute geometry steps through TGeo • Several checks during parralel step computation validates TGeo algorithms.

24. TFluka • Work started two weeks ago : the idea is to be able to replace Flugg (G4) with TGeo at some point. • Now able to build ROOT geometry in parralel with G4 one • Navigation : main issue. The wrapper-based mechanisms in Flugg providing to FLUKA the G4 navigation need to be understood. • Many other details, like providing to FLUKA material ''cards'' based on TGeo materials instead of G4.

25. Next steps • Main focus on TGeo ''adoption'' by TGeant3 and TFluka • Work on optimizing computation of distances on some particular cases • Computation of normal directions to the crossed surface has to work soon. • Documentation has to be eventually written