1. STAR Simulation Overview Maxim Potekhin STAR Collaboration Meeting BNL February 28, 2003 February 28, 2003

2. Overview STAR simulation infrastructure components  Current projects  Development areas, or where we are and where we want to be 

3. 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

4. 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: Code examples: Do While (G2R_GET_HIT('emc').eq. 0) Do While (G2R_GET_HIT('emc').eq. 0) g2t_emc_hit(i).de = Elos g2t_emc_hit(i).de = Elos g2t_emc_hit(i).volume_id = volume g2t_emc_hit(i).volume_id = volume enddo enddo section = numbv(1+shift) ! ECVO section = numbv(1+shift) ! ECVO phi_30d = sector_hash(numbv(2+shift),ib) ! EMOD phi_30d = sector_hash(numbv(2+shift),ib) ! EMOD zsubsect = numbv(3+shift) ! ESEC (no readout) zsubsect = numbv(3+shift) ! ESEC (no readout) zsublayer = numbv(4+shift) ! EMGT (no readout) zsublayer = numbv(4+shift) ! EMGT (no readout) volume_id = 100000*rileft+1000*(5*(phi_30d-1)+phi)+10*eta+section volume_id = 100000*rileft+1000*(5*(phi_30d-1)+phi)+10*eta+section

5. 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.

6. 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

7. 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

8. 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)

9. Current projects Monte Carlo dataset production –Hijing 1.33 (done) –Hijing 1.382 (in progress) –produced at RCF and PDSF (Eric Hjort) –data RCF  PDSF 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)

10. STAF application support Maintenenance of codebase Keeping up with external libraries and compiler versions Documentation

11. 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)

12. 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.

13. Example: SVT study Using photon conversions to probe material density in the detector

14. 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? 

15. 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

16. 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