Presentation is loading. Please wait.

Presentation is loading. Please wait.

Status of TFluka: geometry and validation Andrei Gheata ALICE Off-line week, 21 Feb. 2005.

Similar presentations


Presentation on theme: "Status of TFluka: geometry and validation Andrei Gheata ALICE Off-line week, 21 Feb. 2005."— Presentation transcript:

1 Status of TFluka: geometry and validation Andrei Gheata ALICE Off-line week, 21 Feb. 2005

2 Outline Geometry in TFluka TGeo developments related to TFluka Validation: TFluka vs. FLUKA Conclusions

3 Geometry FLUKA native geometry cannot represent a G3-like description at ALICE scale FLUGG: an interface to GEANT4 geometry – dropped due to instability TGeo interface –creating/working with the same geometry used with GEANT3 Geometry building interface implementing VMC methods: Material, Mixture, Medium, Gsvolu, Gspos, Gsposp, Gsdvn, … Using common interface TGeoMCGeometry in most cases Methods with FLUKA-specific implementation in TFlukaMCGeometry Navigation interface implemented via specific wrapper functions No documentation -> “interface discovery” done by looking into FLUGG Implementation much simplified compared to FLUGG Needed building specific features directly in TGeo

4 Geometry in VMC VMC TGeant3 TGeant4 TFluka G3 geom G3 geom. ROOT geom. G4 geom. GEANT3transport GEANT4transport FLUKAtransport USERCODE VGM Flugg g3tog4 ROOT geom. VGM g2root Not yet

5 Additional geometry tasks in TFluka Creation of FLUKA materials corresponding to GEANT3 ones Not obvious – FLUKA does not support materials defined by effective Z Currently a patch is substituting some “averaged” materials with “close-to-real” accepted ones Considerable effort made by several people to do this – should be properly handled at detector level Assigning materials to FLUKA regions Handling low-energy neutron x-sec related indices Automatic PEMF file generation

6 TGeo developments related to TFluka Physical node ID management Equivalent to FLUKA “lattice” concept Int_t TGeoManager::GetCurrentNodeId() Void TGeoManager::CdNode(Int_t node_id) Avoids managing geometry states as objects (new/delete at each step) Adds just ~6 MB data in memory for full ALICE Boundary-tolerant distance computation algorithms Avoids potential numerical problems when crossing boundaries Leads to visible improvements – see next

7 Boundary tolerance The particle position (x,y,z) and the current physical volume supposed to contain this may become numerically inconsistent after crossing a boundary Symptoms depending on transport engine G3 transport careful not to “step” on boundaries. Even if something gets wrong (geometry error), “non- destructive” step recovery methods are built-in FLUKA transport systematically stepping on boundaries – numerically the new particle position may be as well in or out the new lattice; recovery methods are poor Hard to observe and debug – the systematic ranges from 1/10000 to 1/million with unpredictable effects

8 Boundary tolerance in TGeo Few strategies implemented in TFluka geometry interface to solve this “Push” strategy: the current point is pushed forward (~1e-10) to put it in the right geometry container 1e-10: quite empirical value – cannot work 100% Final solution implemented: boundary tolerance at geometrical shape level May the location assumption be wrong, give the transportation what it expects…

9 Boundary tolerance in TGeo (2) “I am inside – how long still ?” Red line “I am outside – how far next boundary ?” 0.0 !!! Implemented for all shapes used in ALICE ~1e-10 cm

10 Validation: TFluka vs. FLUKA Long way to current TFluka status Considerable effort – starting to pay-off Validation tests within AliRoot for TFluka vs. GEANT3 and ITS test beam (see talk from A.Morsch) Validation test against FLUKA native examples (geometry validation) – see next Geometry tests for simple examples Does the new geometry reproduce the boundary crossing sequence/positions ? - YES Do we get the same physics results in identical initial conditions ? – YES Can we reproduce the final random seeds with the 2 geometries – NOT YET, but working on understanding why

11 Setup 1: HCal Al+Pb with scintillators Compact (~5x10x5 cm) but complex geometry Boolean compositions for each layer (>100 components) 1 GeV protons in strong field (60 T !) Test case 1: Vacuum everywhere (no physics) Comparison of boundary crossings (w. or w.o. field) Test case 2: Materials on, physics on, same Input/pemf file Looking at Edep distribution

12 Setup 2: Al-Au-Al thin layers, low energy electron transport Trivial geometry, EM-cascade physics No field 1 MeV electrons along Z, all energy lost in material Comparison of shower profiles Identical run conditions Longitudinal and radial Edep distributions Z R

13 Results (1) Boundary crossings matching (no phys) Matching ratio: 100% with or w.o. field Difference between matched crossings at machine precision level No biasing observed

14 Results (2) Physics on 5000 protons 1GeV/c in 60T x-oriented field

15 Results (3) EM-cascade profiles (Ekin=1MeV) Low energy electron transport, 10000 primary electrons Problem when crossing boundaries observed – now fixed by FLUKA team

16 Conclusions Improvements in TFluka geometry interface Boundary tolerance implemented in TGeo Related fixes/adjustments in FLUKA/TFluka FLUKA VMC under extensive testing New geometry does not change/bias boundary sequence nor physics results Random seed reproducibility – next item to be followed Just preliminary not conclusive performance tests so far. We may expect however a non-negligible time penalty with respect to G3 simulation, depending on several factors


Download ppt "Status of TFluka: geometry and validation Andrei Gheata ALICE Off-line week, 21 Feb. 2005."

Similar presentations


Ads by Google