Geometry and GEANT4
There appear to be a number of options to make geometry happen in GEANT4:
- Program it in directly.
- Use an interface that converts to GEANT4 geometry, see below.
- Interface through a CAD program, see CAD and GEANT4. The bad news is that many of the projects listed here are mostly dead. The good news is that as of 2010, there is some new life in this area, including commercial interest. Here's what I found.
There is a lot of "stuff" available in terms of GEANT4 geometry. This is clearly a very important issue, and there are clearly many different and diverging attempts to solve it. So far I see no clear winner. There are a number of dead ends, which once more emphasizes that the geometry definition is not a trivial meatter.
What we want:
- We want to use a package that allows us to use ONE geometry definition for all the various bits of software that will require geometry input.
- The format has to be clearly described and have a useful hirarchy.
- The software used must be non-proprietary.
- The software and standards used can not be a moving target.
- The software has to be stable and functional.
- More motherhood and apple pie.
- So far, there are no clear winners to me yet. I find the STAR detectors web page interesting. Note that since most web pages are not dated, it is hard to tell which projects were abandoned.
- Note that for most detectors, "someone else" provides the geometry in a machine readable hiarchical format. Now, how is this going to happen for CLAS12?
- For our initial efforst, all these fancy geometries may not be useful. If we write our code properly modular, we should be able to "plug in" a different geometry (which of course in actuality will take a lot of work.)
GEANT4 aware geometry converters.
- VMC (virtual Monte Carlo), Converts ROOT geometries to GEANT4, GEANT3 or FLUKA. That is the theory. The "big detector" using this is Alice at the LHC. According to their website (Alice GEANT4 Simulation) the VMC is based on GEANT3, and there are problems using it with GEANT4. These include no support for "MANY" geometries in the GEANT4 version. Since this is "bad" anyway, we can program around these limitations.
- Linear Collider Simulation Software. Geometry in a MySQL database: MOKKA , it has since changed to LCDD, a GDML derivative.
- LCSC: LCDG4 - The actual simulation that LCSC uses is based on XML geometry descriptions.
GEANT4 Geometry to other format converters
- There is an XML converter as part of GEANT4: GEANT4 XML . This includes GraXML for visualization. It converts the geometries to AGDD or GDML (see below.)
Various Geometry Descriptions
- GDML (Geant Detector XML) HOWTO use GDML in GEANT4
- LCDD (Linear Collider Detector Description) Extends GDML so that it is actually usefull for the whole geometry. Used in SLIC. See: Linear Collider Software
- AGDD (Atlas Geometry)
- HDDS (GlueX ) Used for Hall-D detector, written by Richard Jones.
- DDD (Detector Description CMS detector) They use COBRA (Coherent Object oriented Base for Reconstruction, Analysis and simulation - a software framework.) Seems complete and well documented.
- Alice , Alice GEANT4 Simulation
- STAR, STAR Simulation Page This is a very rich place to visit, I still need to read more. Seems that they use the VMC with a geometry in XML (seems they use the GDML definition). They used Alice as a case study. They also looked into the CMS DDD, and found they could not use it. There is info on storing the geometry in a MySQL database.