- General information
- Data readiness
- Grid and Cloud
- Infrastructure
- Machine Learning
- Offline Software
- Production
- Test tree
Adding a New Detector to STAR
Updated on Thu, 2013-12-19 09:47 by jwebb. Originally created by potekhin on 2006-10-12 17:18.
Under:
When hits are built up into clusters, the clustering algorithm should set the idtruth value for the cluster based on the dominant contributor of the hits which make up the cluster.
When clusters are associated into space points, the point finding algorithm should set the idtruth value for the point. In the event that two clusters are combined with two different idTruth values, you should set idTruth = 0.
The STAR Geometry Model
The STAR Geometry is implented in geant 3, which provides the geometry description to STAR's Monte Carlo application, starsim. The geant3 model is
implemented using the Advanced Geometry Interface for GSTAR language. AGI provides a flexible and robust framework in which detector
geometries can be quickly implemented. STAR is currently migrating from the AGI language to a related framework called AgML. AgML stands for
"Another Geometry Modelling Language." It is based on XML, and is the preferred language in which new geomtries should be implemented. AgML
provides backwards compatability with the AGI language, in order to continue supporting the starsim application as we transition to a new STAR virtual
Monte Carlo application.
Geometry Definition
Geometry Definition
Users wishing to develop and integrate new detector models into the STAR framework will be intersted in the following links:
- The STAR AgML reference guide.
- The STAR AgML example shapes.
- List of Default AgML Materials
- The AgML Tutorials is a good place to get started with AgML development.
- An annotated example, the AgML Example: The Beam Beam Counters, is also available.
- Another example, the FGT geometry
Tracking Interface (Stv)
Exporting detector hits
- Implement a hit class based on StEvent/StHit
- Implement a hit collection
- Implement an iterator over your hit collection based on StEventUtilities/StHitIter
- Add your hit iterator to the StEventUtitlies/StEventHitIter
Implementing a custom seed finder
ID Truth
ID truth is an ID which enables us to determine which simulated particle was principally responsible for the creation of a hit in a detector, and eventually the physics objects (clusters, points, tracks) which are formed from them. The StHit class has a member function which takes two arguements:
- idTru -- the primary key of the simulated particle, i.e. "track_p" in the g2t hit structure
- qaTru -- the quality of the truth value, defined as the dominant contributor to the hit, cluster, point or track.
When hits are built up into clusters, the clustering algorithm should set the idtruth value for the cluster based on the dominant contributor of the hits which make up the cluster.
When clusters are associated into space points, the point finding algorithm should set the idtruth value for the point. In the event that two clusters are combined with two different idTruth values, you should set idTruth = 0.
Interface to Starsim
The interface between starsim and reconstruction is briefly outlined here
- You do not have access to view this node
Information about geometries used in production and which geometries to use in simulations may be found in the following links:
- Existing Geometry Tags used in Production
- The STAR Geometry in simulation & reconstruction contains useful information on the detector configurations associated with a unique geometry tag. Production geometry tags state the year for which the tag is valid, and a letter indicating the revision level of the geometry. For example, "y2009c" indicates the third revision of the 2009 configuration of the STAR detector. Users wishing to run starsim in their private areas are encouraged to use the most recent revision for the year in which they want to compare to data.
Comparisons between the original AgSTAR model and the new AgML model of the detector may be found here:
- Comparisons between AgML vs AgSTAR Comparison demonstrate the level of equivalence between AgML and the original AgSTAR geometries.
- Comparisons between You do not have access to view this node HITS, for simple simulations run in starsim.
- Comparisons between AgML vs AgSTAR tracking comparison
AgML Project Overview and Readiness for 2012
HOWTO Use Geometries defined in AgML in STARSIM
AgML geometries are available for use in simulation using the "eval" libraries.
$ starver eval
The geometries themselves are available in a special library, which is setup for backwards compatability with starsim. To use the geometries you load the "xgeometry.so" library in a starsim session, either interactively or in a macro:
starsim> detp geom y2012
starsim> gexe $STAR_LIB/xgeometry.so
starsim> gclos all
HOWTO Use Geometries defined in AgML in the Big Full Chain
AgML geometries may also be used in reconstruction. To access them, the "agml" flag should be provided in the chain being run:
e.g
root [0] .L bfc.C
root [1] bfc(nevents,"y2012 agml ...", inputFile);
Geometry in Preparation: y2012Major changes: 1. Support cone, ftpc, ssd, pmd removed.
2. Inner Detector Support Module (IDSM) added
3. Forward GEM Tracker (FGTD) added
Use of AgML geometries within starsim:
$ starver eval
$ starsim
starsim> detp geom y2012
starsim> gexe $STAR_LIB/xgeometry.so
starsim> gclos all
Use of AgML geometries within the big full chain:
$ root4star
root [0] .L bfc.C
root [1] bfc(0,"y2012 agml ...",inputFile);
|
Current (10/24/2011) configuration of the IDSM with FGT inside -- |
Page maintained by Jason Webb <jwebb@bnl.gov>
»
- Printer-friendly version
- Login or register to post comments