1 / 45

Lhlay 3

Lhlay 3. Fast Detector Simulation Using Lelaps. Overview. Introduction What does it do and what is it? The CEPack tool kit Geometry and Materials Tracking, Multiple Scattering and dE/dx Electromagnetic and Hadronic Shower Parameterization Decays and Gamma Conversions

korbin
Download Presentation

Lhlay 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lhlay 3 Fast Detector Simulation Using Lelaps

  2. Overview • Introduction • What does it do and what is it? • The CEPack tool kit • Geometry and Materials • Tracking, Multiple Scattering and dE/dx • Electromagnetic and Hadronic Shower Parameterization • Decays and Gamma Conversions • Using CEPack inside Geant4 • Standalone CEPack: Lelaps • Performance • Future W.G.J. Langeveld - SLAC

  3. Introduction: What does it do? • It swims particles through detectors, taking into account magnetic fields, multiple scattering and dE/dx energy loss. • It produces parameterized showers in EM and hadronic calorimeters. • It converts gammas. • It supports decays of certain short-lived particles (“V” decays). • It does all this very fast. W.G.J. Langeveld - SLAC

  4. Introduction: What is it? • Lelaps consists of a set of C++ class libraries and a main program, which itself is called lelaps. • The main library is called CEPack, which contains the actual simulation toolkit. It uses only one utility library, “vec”. • Other utility libraries include: lStdHep, vlutil, plotpp, pl3. • Main programs (“lelapses”) have been written for BaBar and for LCD (LDMar01, SDJan03 and SDMar04 are implemented). • CEPack can also be used in conjunction with Geant4 parameterized volumes. In this way it is integrated in BaBar’s Geant4-based simulation. • The standalone version for LCD reads StdHep generator files and produces SIO or LCIO output files that can be read by JAS and LCDWired. W.G.J. Langeveld - SLAC

  5. Geometry in CEPack • Geometries are constructed using CENodes (which may contain a list of subnodes). • A number of common CENodes are predefined • cylinders, cones, boxes, spheres etc. • Transformations may be applied to CENodes in order to position and orient them. Arbitrary transformations are allowed. • CENodes need to provide methods for tracks entering and exiting, and for determining whether points are inside them or not. • CENodes may be assigned a numeric id and subid. • CENodes may implement a method to compute a subid from a location. • May be used to compute calorimeter segmentation. • CENodes do not have to be 3D objects. • Several predefined CENodes consist of one or more 2D surfaces. W.G.J. Langeveld - SLAC

  6. Geometry in CEPack: LD • Most objects in the LD are cylinders. • There are some conical masks (not drawn). • TPC and barrel muon detector each contain a CENode with a set of concentric cylinder surfaces. • Muon endcaps use a CENode with a set of cylindrical slices. • Calorimeters use subid calculation for their segmentation. W.G.J. Langeveld - SLAC

  7. Materials in CEPack • All elements built in with default pressure/temperature/density. • Any compound can be specified by chemical formula and density or (for gasses) temperature and pressure. • Mixtures can be created by mixing elements and compounds (by volume or by weight). • All needed quantities are calculated automatically • Constants needed for multiple scattering and energy loss • Radiation lengths (Tsai, PDG) • Interaction lengths (from a fit to element data) • Other constants needed for shower parametrization W.G.J. Langeveld - SLAC

  8. Matprop • Lelaps distribution comes with a little program called matprop: • matprop U # for elements (gasses at NTP) • matprop SiO2/2.32 # for solids (and liquids) specify # density (g/cc) • matprop CO2/1/298.15 # for gasses specify pressure (atm) # and temperature (K) • matprop O2/STP # for gasses at STP (0 C, 1 atm) • matprop Ar/NTP # for gasses at NTP (25 C, 1 atm) • matprop H2// # for gasses at NTP • For a mixture (e.g. Air at 20 C) use (-g to indicate gas): • matprop -g O2/1/293.15 20.946 N2/1/293.15 78.084 Ar/1/293.15 0.934 • Just type matprop to get a list of options • Prints out lots of material properties • Matprop is available onnline: http://www.slac.stanford.edu/comp/physics/matprop.html W.G.J. Langeveld - SLAC

  9. Tracking in CEPack • Tracking is performed by taking steps along a linear trajectory with endpoints on a helix, such that the sagitta stays below a certain (settable) maximum. • CENodes have bounding spheres (or bounding cylinders). • When computing distances to CENodes, only “relevant” CENodes are considered. • After each step, the amount of material traversed is checked: if enough material was traversed, multiple scattering and energy loss is performed and track parameters and list of relevant CENodes are recalculated. • When an intersection occurs within a step, the fractional step is executed, the CENode is entered, and the remaining fraction of the step follows. W.G.J. Langeveld - SLAC

  10. Multiple Scattering and dE/dx • Multiple scattering is performed using the algorithm of Lynch and Dahl. • Gerald R. Lynch and Orin I. Dahl, Nucl. Instr. And Meth. B58 (1991) 6. • Material is “saved up” along the track until there is enough. • dE/dx is calculated using the methods by Sternheimer and Peierls. • R.M. Sternheimer and R.F. Peierls, Phys. Rev. B3 (1971) 3681. • All constants precalculated by the material classes. W.G.J. Langeveld - SLAC

  11. Electromagnetic Shower Parameterization • Electromagnetic showers are parameterized using the algorithms of Grindhammer and Peters. • G. Grindhammer and S. Peters, arXiv:hep-ex/0001020v1 (2000) (Paper is a 1993 conference contribution, submitted by request to the archive in 2000). • Calorimeters are treated as homegeneous media, with longitudinal shower profile given by a gamma distribution (t in radiation lengths): • Coefficients α and β depend on the material (Z) and energy. • The profiles are fluctuated, and correlations between α and β are taken into account. W.G.J. Langeveld - SLAC

  12. EM Shower Parameterization: Radial Profile • For each step of one radiation length, a radial profile is computed of the form: with RC the median radius (in units of Molière radius) of core component of the shower, RT the median radius of tail component and p the fraction of “core” in the shower. • RC, RT and p are functions of Z, shower depth t and E. • Energy dE(t) is divided into spots (another gamma distribution with parameters depending on t). Spots are thrown in r according to the profile above, uniformly in φ and also uniformly between t and t+1. • Roughly, about 400 spots are generated per GeV of shower energy. • Spots are reported as “hits”. W.G.J. Langeveld - SLAC

  13. EM Shower Parameterization: BaBar CsI CEPack simulation of BaBar EM calorimeter in Moose (courtesy of Dominique Mangeol). See also the BaBar web site (computing – simulation – fast simulation). W.G.J. Langeveld - SLAC

  14. Hadronic Shower Parameterization • Hadronic showers are parameterized using code that is similar to the code for electromagnetic showers, with some modifications: • The location where the shower starts is simulated using an exponential law with attenuation given by the interaction length. • The longitudunal profile uses the Bock parameterization. • R.K. Bock, T. Hansl-Kozanecka and T.P. Shah, Nucl. Instr. And Meth. 186 (1981) 533. • A combination of two gamma distributions, one using radiation lengths and the other interaction lengths, is used. • Bock parameterization does not specify radial profiles. For the moment we use a radial profile similar to Grindhammer & Peters (for EM showers) but with radiation lengths replaced by interaction lengths and faster spread with depth. The parameters still need to be fine-tuned. W.G.J. Langeveld - SLAC

  15. Shower Parameterization Compared to Geant4 • Parameterized shower simulation was compared to Geant4. • “Parameterized Shower Simulation in Lelaps: A Comparison with GEANT4”, Daniel Birt, Amy Nicholson, Willy Langeveld, Dennis Wright, SLAC-TN-03-005, Aug 2003. • In general pretty good agreement for EM showers. Hadronic showers agree pretty well longitudinally, but not as well radially. • Hadronic shower parameterization has been tweaked since then. W.G.J. Langeveld - SLAC

  16. EM Shower Parameterization and Geant4 Comparison of CEPack longitudinal profile (green) of a 10 GeV electron in an EM calorimeter with Geant4 (orange). W.G.J. Langeveld - SLAC

  17. Decays and Gamma Conversions • Decays of unstable particles and gamma conversions are performed as follows: • Lelaps loops over the particles in a list, turns them into CETracks and swims them through the geometry • Tracks of decaying particles and converting gammas stop at the decay/conversion point • For supported unstable particles, a CEPack utility function picks decay mode or conversion and adds products to the list • Lelaps continues to loop over the particles in the list until there are none left • Supported unstable particles are pi0, K0-short (K0-long treated as stable), Lambda, Sigma+/-/0, Xi-,0 and Omega- . Only decay modes > 2% supported (“V” decays) W.G.J. Langeveld - SLAC

  18. History: Lelaps and CEPack 3.x Wired picture of the decay chain: Ω-→ Ξ0π- Ξ0 → Λπ0 Λ → p π- π0 → γ γas simulated by Lelaps for the LCD LD model. W.G.J. Langeveld - SLAC

  19. History: Lelaps and CEPack 3.x Wired picture of a gamma conversion as simulated by Lelaps for the LCD LD model. W.G.J. Langeveld - SLAC

  20. Using CEPack inside Geant4 • To use CEPack inside Geant4, create a Geant4 parameterized model, e.g.: class BgsSvtParamModel : public G4VFastSimulationModel • In its setup(), create the CENode corresponding to the CEPack simulation with all its subnodes. • In Doit(), convert from G4FastTrack track to CETrack, and call track.swim() • By subclassing CETrack, all hits are reported using CETRack report_hit() method. Convert hits to your favorite format. • Update Geant4’s notion of the track using G4FastStep (or call KillPrimaryTrack()) W.G.J. Langeveld - SLAC

  21. CEPack and Lelaps • Lelaps for LCD is a standalone program which uses CEPack. • It sets up the CEPack geometry (supports LDMar01, SDJan03 and SDMar04). • It uses lStdHep (“StdHep light” – included in the distribution): a class library to to read generator event files in StdHep format. StdHep particles are converted to SIO or LCIO particles. • Loops over events, creating CETracks. When hits are reported, they are added to SIO/LCIO hit lists. For calorimeter hits, the “spots” are first accumulated and turned into energy depositions in individual calorimeter cells and then added. • Finally, the SIO or LCIO event structure is written out. W.G.J. Langeveld - SLAC

  22. Lelaps (LDMar01) W.G.J. Langeveld - SLAC

  23. Lelaps (SDJan03) W.G.J. Langeveld - SLAC

  24. Lelaps: Usage • Most common usage: • lelaps –o foo.sio –E bar1.stdhep bar2.stdhep … reads one or more StdHep files and produces SIO output file. • Defaults to SDJan03. Use –L LDMar04 for LD, etc. • Also has built-in simple particle “gun”: • lelaps –o foo.slcio –i 11 –m 10 –n 4 –N 1000 generates 1000 events with 4 electrons/event with 10 GeV each random in 4π and produces LCIO output file. • Options for generation in x,y plane (2π) or along x, y, z directions • Options for turning off energy loss, multiple scattering and/or showering in calorimeters • Options for turning off decays and/or conversions and tracking their secondaries W.G.J. Langeveld - SLAC

  25. Performance (LDMar01) • 100 eeZZ events* at 500 GeV c.m. energy in the LD on a 1.4 GHz Pentium 4 running Linux (Noric03) gives the following performance (all numbers converted to 1 GHz processor speed): * panpy-ZZ-500-001001-gen-1.stdhep (5973 tracks) W.G.J. Langeveld - SLAC

  26. Performance (SDMar03) • 100 eeZZ events* at 500 GeV c.m. energy in the SD on a 1.4 GHz Pentium 4 running Linux (Noric03) gives the following performance (all numbers converted to 1 GHz processor speed): * panpy-ZZ-500-001001-gen-1.stdhep (5973 tracks) W.G.J. Langeveld - SLAC

  27. Performance: Analysis • Tracking alone: 3 - 4 events/s (at 1 GHz) for LD, 2 events/s for SD. • Adding parameterized showering costs 15% (SD) to 30% (LD). • Adding decays and conversions adds 20%. • LCIO output file (14 MB, compressed) adds another 40%. • SIO output takes much longer (factor 2 to 4 depending heavily on calorimeter segmentation). Could be optimized. • Platform/machine dependent. Tracking only, time per event: • Noric03 (1.4 GHz, gcc 2.95.3) 0.281 sec at 1 GHz • Tersk09 (0.44 GHz, Solaris with WS 7) 0.154 sec at 1 GHz • Windows (2 GHz, cygwin with gcc 3.2) 0.384 sec at 1 GHz W.G.J. Langeveld - SLAC

  28. Future • Lelaps and CEPack interfaces are not yet frozen! • New features planned for CEPack • Combinatorial geometry • Shower continuation into next volume • New features planned for Lelaps: • Read in geometry from some “standard” file format • Old features need to be tested more thoroughly • More tuning of hadronic showers • Review of code, improvements in consistency • Revisit optimization W.G.J. Langeveld - SLAC

  29. About the name Lelaps Lelaps (“storm wind”) was a dog with such speed that, once set upon a chase, he could not fail to catch his prey. Having forged him from bronze, Hephaestus gave him to Zeus, who in turn gave him to Athena, the goddess of the hunt. Athena gave Lelaps as a wedding present to Procris, daughter of Thespius, and the new bride of famous hunter Cephalus. A time came when a fox created havoc for the shepherds in Thebes. The fox had the divine property that its speed was so great that it could not be caught. Procris sent Lelaps to catch the fox. But because both were divine creatures, a stalemate ensued, upon which Zeus turned both into stone. Feeling remorse, Zeus elevated Lelaps to the skies, where he now shines as the constellation Canis Major, with Sirius as the main star. W.G.J. Langeveld - SLAC

  30. Introduction: Lelaps …but clearly, Lelaps (the program) is not a dog! W.G.J. Langeveld - SLAC

  31. The End W.G.J. Langeveld - SLAC

  32. Geometry File Format …and related issues

  33. Overview • Introduction • Religious wars, languages and file formats • Requirements • or at least “would be nice”s • A work in progress • The current plan • A note about XML W.G.J. Langeveld - SLAC

  34. Introduction • Talking about file formats is like talking about languages or standards--no matter what it is, at least 70% of the audience will be against it: • “Why not use an existing language/format, such as <fill in my favorite language/format>?” • “It’s not <fill in favorite standard> so it’s no good!” • “Don’t we already have enough standards?” • Content vs. Form • In the following I will give an example of what could be done. • That doesn’t mean the final product will be the same as the example. • XML is a specification of form, not content. • The example will not look like XML, though perhaps the final version could be in that form. W.G.J. Langeveld - SLAC

  35. Requirements • A Geometry file format ideally should satisfy the following: • Should allow avoiding duplication of related numbers • Should know about dimensions and enforce consistency • Should know about simple mathematics • cos, sin, sqrt, … • Should know about levels of detail • One wants to simulate different things in fast and full simulations • Should allow combinatorial geometry • Simple things should be simple, difficult things should be possible • Should be supported by Geant4, Lelaps, JAS. • should be easily supportable by any software that would like to • Should be self-descriptive • E.g. should contain the algorithm to derive cell ids from x, y, z, rho, theta, phi • Should allow hierarchies of volumes inside volumes • In the following I will not even address all of the above. W.G.J. Langeveld - SLAC

  36. A Work In Progress • Materials • Elements, compounds, mixtures • Units and variables • Volumes and Placements • Control structures and “arrays” • Levels of detail • Combinatorial geometry W.G.J. Langeveld - SLAC

  37. Units and Variables • Variables are used to hold just about anything. This includes units. Units are declared as follows, using the built-in unit() function: # # Comments are allowed, of course # atm = unit("atm"); cm = unit("cm"); m = 100.0 * cm; T = unit("T"); W.G.J. Langeveld - SLAC

  38. Materials • Materials are declared using the element, material or mixture tags (use the @ operator to pass by reference): Si = element("Si"); vacuum = material("vacuum"); O2 = material(formula("O2"), pressure(1.0 atm), temperature(293.15 K)); Tyvek = material(name("Tyvek"), formula("CH2CH2"), density(0.935 gcc)); Air = mixture(part(@O2, 20.946), part(@N2, 78.084), part(@Ar, 0.934), by("volume")); W.G.J. Langeveld - SLAC

  39. Volumes and Placements • First define a World Volume: World = cylinder(radius(700.0 cm), length(14.0 m), @vacuum); • Define another volume: em_ec_irad = 21.0 cm; em_ec_orad = 125.0 cm; em_b_irad = em_ec_orad + 2.0 cm; em_thickness = 15 cm; em_b_orad = em_b_irad + em_thickness; em_nlayers = 30; em_sampfrac = 0.02664; em_b_length = 368.0 cm; EM_Barrel = cylinder(name("EM Barrel"), innerRadius(em_b_irad), outerRadius(em_b_orad), length(em_b_length), @SiW, type("emcal"), nLayers(em_nlayers), samplingFraction(em_sampfrac)); • Add to World using placement: World += placement(@EM_Barrel, translate(0, 0, 0)); W.G.J. Langeveld - SLAC

  40. Control Structures and “Arrays” • Use loops to do repetitive tasks and if statements for conditionals: Vertex_Barrel = cylinder(name("Vertex Barrel"), innerRadius(v_irad), outerRadius(v_orad), length(v_lenmax)); for (i = 1; i <= v_nlayers; i += 1) { vlen = v_leninner; if (i > 1) vlen = v_lenmax; Vertex_Barrel.i = cylinder(name("Vertex Barrel " + i), innerRadius(v_spacing * i), outerRadius(v_spacing * i + v_thickness), length(vlen), @Si, type("tracker")); Vertex_Barrel += placement(@Vertex_Barrel.i); # Notice hierarchy } World += placement(@Vertex_Barrel); W.G.J. Langeveld - SLAC

  41. Levels of Detail • Specify levels of detail with “level” tag: Had_Endcap = cylinder(name("Had Endcap"), level(1), innerRadius(had_ec_irad), outerRadius(had_ec_orad), length(had_thickness), @StainlessPoly, type("hadcal"), nslices(had_nlayers), samplingFraction(had_sampfrac)); Had_Endcap += placement(@something, …, level(2), …); Had_Endcap += placement(@something_else, …, level(3), …); World += placement(@Had_Endcap, translate(0, 0, 0.5 * (had_b_length – had_thickness))); World += placement(@Had_Endcap, rotate_around_z(180 degrees), translate(0, 0, -0.5 * (had_b_length – had_thickness))); W.G.J. Langeveld - SLAC

  42. Combinatorial Geometry • Currently envisioned to be done using union() and intersection() constructs and not(): Lum_Endcap = cone(name("Lum Endcap"), innerTopRadius(l_e_itoprad), outerTopRadius(l_e_otoprad), innerBottomRadius(l_e_ibotrad), outerBottomRadius(l_e_obotrad), length(l_e_length), @WSiG10Air); Beampipe1 = cylinder(name("Beampipe 1"), radius(1.0 cm), length(lb_length)); Beampipe2 = cylinder(…, radius(2.0 cm), …); Lum_Cal = intersection(placement(Lum_Endcap), placement(not(Beampipe1), …)), placement(not(Beampipe2), …)); World += placement(@Lum_Cal, translate(0, 0, l_e_zoff)); World += placement(@Lum_Cal, rotate_around_x(180 degrees), translate(0, 0, -l_e_zoff)); W.G.J. Langeveld - SLAC

  43. The Plan • Parser/evaluator is mostly done • 3700 lines C++, half of which came from previous projects. • It runs and turns sample SDMar04 file into a list of volumes. • Left to do (not necessarily in this order): • Finish up some stuff in the evaluator (such as enforcing units) • Finalize concepts of level of detail and combinatorial geometry • Add API layer to access the volume list • Add simple geometry visualizer probably using Wired and HepReps • Write implementations for Geant4 and Lelaps • Translate parser/API into Java, add to JAS, Wired • Time scale depends on how fancy we want (need?) to get. Hopefully before Christmas. W.G.J. Langeveld - SLAC

  44. A Note about XML • Whether a file format is XML based or not is a matter of form, not content • Most important, however, is content. • One should worry about content first, and decide upon a file format last. • That file format could be XML, but that decision should be made after the content has been defined. <climbs on soapbox> • Commonly believed myths about XML: • Now that we’ve decided on XML, we’re almost done. • Wrong! Need to define content, write .dtd. • XML guarantees correct content. • Wrong! Only guarantees correct syntax. • XML is human-readable. • Wrong! Just look at it sometime. • When you use XML you don’t need to write a parser. • Wrong! You still have to write a parser, albeit at a higher level. <climbs down from soap box> W.G.J. Langeveld - SLAC

  45. The End W.G.J. Langeveld - SLAC

More Related