160 likes | 167 Views
STAR Simulation Overview. Maxim Potekhin STAR Collaboration Meeting BNL February 28, 2003. Overview. STAR simulation infrastructure components [ Current projects [ Development areas, or where we are and where we want to be [. Simulation infrastructure components.
E N D
STARSimulation Overview Maxim Potekhin STAR Collaboration Meeting BNL February 28, 2003
Overview • STAR simulation infrastructure components [ • Current projects [ • Development areas, or where we are and where we want to be [
Simulation infrastructure components • Main simulation tool: STAF/GSTAR • based on PAW and GEANT 3.21 • dynamic loading of user libraries on demand • high degree of interactivity, with full scripting capability • output in ZEBRA format • persistent data, such as geometry, in the output • dataset management currently done via entries in the catalog file • Translation layer: g2t* [ • Detector Geometry Description [ • Event Generators [ • Simulation Data [ • Documentation • web pages being updated
Translation layer: g2t* • provides mapping of the native GEANT structures and variables to those used in reconstruction. Maintenance requires expert knowledge of GEANT. Code examples: Do While (G2R_GET_HIT('emc') .eq. 0) g2t_emc_hit(i).de = Elos g2t_emc_hit(i).volume_id = volume enddo section = numbv(1+shift) ! ECVO phi_30d = sector_hash(numbv(2+shift),ib) ! EMOD zsubsect = numbv(3+shift) ! ESEC (no readout) zsublayer = numbv(4+shift) ! EMGT (no readout) volume_id = 100000*rileft+1000*(5*(phi_30d-1)+phi)+10*eta+section
Detector Geometry Description • Number of detector subsystems: 18 • Custom macro “geometry language” (*.g files) • based on the obscure Fortran preprocessor called Mortran • ideally suited for application-specific Fortran code structuring • in many cases, helps circumvent limitations of Fortran • can be of help with the GEANT learning curve • has been successfully used in a number of projects • 11,000 lines of geometry code, largely user maintained • As previously mentioned, volume maps (not part of the geometry per se) are maintained separately in “g2t” files. • May or may not be user maintainable.
Detector Geometry Description • Code example: Block SVTT is the mother of all SVT volumes * Material Air Attribute SVTT seen=0 colo=1 Shape TUBE Rmin=svtg_RsizeMin, Rmax=svtg_RsizeMax, dz=svtg_ZsizeMax * End rings to support the ladders: * Create SIRP " inner end ring polygon piece " Position SIRP Z=serg_EndRngZm+serg_EndRngTh/2 AlphaZ=22.5
Event generators • Option to either generate events “on the fly”, or feed the GEANT simulator from a pre-fabricated event file. • Currently used • Hijing, moving from 1.33 to the newer 1.382 • expertise provided by Ron Longacre • Pythia 6.203 • Experimenting with Nexus: Ron Longacre and Gael Renault
Simulation data • Simulation output: ZEBRA files • can be re-opened and inspected with STAF (geometry, hits, etc) • serve as input for the reconstruction chain • large dedicated holding area for simulation files • HPSS population: • approx. 180 datasets, 18000 files • catalog (maintained by Lidia)
Current projects • Monte Carlo dataset production • Hijing 1.33 (done) • Hijing 1.382 (in progress) • produced at RCF and PDSF (Eric Hjort) • data RCFfgPDSF transfer scheme (HRM based) is being worked on (Eric) • STAF/GSTAR application support [ • Ongoing STAR geometry support [ • Event generator support (new versions etc) • New geometry description? [ • Documentation (Olga Barannikova)
STAF application support • Maintenenance of codebase • Keeping up with external libraries and compiler versions • Documentation
STAR geometry support • STAR is an experiment undergoing constant upgrades. This requires timely updates of the geometry definition files and other related configuration data (g2t). • Endcap EMC (Jan Balewski) • TOF trays (Frank Geurts) • Correcting geometry inaccuracies. Recently: • FTPC (extraneous structure elements) • Endcap EMC volume Id’s (Jan) • material distrribution in SVT (Ian) [ • BBC volume hierarchy (Joanna, Akio)
Example: SVT study • Based on an observation by Ian Johnson, about mismatch of the number of photon conversions in the detector, in the experimental data vs MC. • extra material in localized areas of SVT, unaccounted for in the geometry model • Complex design of the SVT feeds and support structures makes geometry modeling hard, despite high level of detail already implemented in the model.
Example: SVT study Using photon conversions to probe material density in the detector
STAR simulations development areas • Documentation (something that can always be improved) • Dataset cataloging • Further productization of STAF. Platforms other than Linux/gcc. • New tools for geometry description? [
New tools for geometry description? • Current geometry macro language • Works extremely well for GEANT 3.21 target language • Is based on the technology with scarce knowledge base • Hard (or impossible) to extend to other applications • SVT Tracking software? Reco? G4? Event display? • Current lack of unitary geometry description for both Monte Carlo and reconstruction software is a liability • significant complexity of both • difficulty of reconciliation, no handshake
New tools for geometry description? • XML technology studied in R&D projects for ATLAS and ALICE (and some other experiments) • Qualified success • Detailed DTD worked out • Parameter blocks implemented • Difficulties encountered in the implementation of programmatic constructs (such as loops and formulas) in geometry description • XML pro • Well understood technology with vast knowledge base • Integration with databases etc • Variety of well documented and supported tools, Java classes in particular • Platform neutral, i.e. not tied to a particular target language • XML contra • lack of demonstrable success (commissioned production app) in any collaboration so far