Abstract: I document the tasks which need to be completed before deployment of the AgML geometry markup language.
1. Implement shape parameters in the Create operator
The AgSTAR language provides three mechanisms for specifying the shape of a volume: (1) As part of the BLOCK definition, (2) passing in shape parameters when the BLOCK is positioned, and (3) passing in shape parameters when the BLOCK is created.  The first two mechanisms are documented in the AgSTAR manual, but the third was not.  Thus it has not yet been implemented, and rarely used in the STAR geometry.  (Only the tof and mutd make extensive use of it).
Adding this missing functionality to the Create operator will require:
(a) Changes to the AgML, AgROOT exporters
(b) Changes to the AgmlStacker class and the StarTGeoStacker class
This represents the last (known) functionality in AgSTAR which is missing in AgML.
2. Define and validate the y2009a geometry
Run on the original geometries to generate AGML files for every STAR detector.  May require some modification by hand (e.g. comment out EMCUTS macro).  Then run starbase and validate against the native AgSTAR geometry.

3. Implement a run-time geometry defintion

At present, different geometry versions (tags) are achieved by inserting code to alter data structues into the exported C++ classes.  This implies that every time we want to generate a new geometry, the AgML files will need to be parsed, code exported, and code compiled.  It would be better if geometries could be selected at run-time instead.

We will need to create a master geometry file (ala geometry.g).  This file will contain the definition of every geometry tag which we plan to support.  The sytax I envision will look like:

<Geometry tag="y2009a">        
   <Insert module="TpceGeo3a">              
   tpcg.variable = 3              
   <Exec module="TpceGeo3a" />        
   <Exec module="EcalGeo6" />        
The Insert commands will result in the creation of a functor, which will modify the specified data structures.  This functor will be added to a lookup table (STL map) in the specified module.  When the module is Exec'd, the geometry tag will be passed to the constructor of the Module, and the appropriate functor will be called.  This way the appropriate geometry version for every detector can be called, and the data structures can be configured for the given geometry.
We will need to write the master geometry file by hand (geometry.g is far to complicated to handle with a parser).
4. Once the master geometry file (MGF) is implemented, we can deploy at RCF.  Need pyparsing.
5. Once all geometries are implemented in the MGF and validated against AgSTAR originals, we can integrate with reconstruction.
6. Once we integrate with reconstruction, we should begin validating the AgML geometries in terms of Monte Carlo response in starsim.
7. (Possibly earlier in the list)... debug a crash on exit.  Probably there is a TGeo object which is getting deleted twice somewhere, or...
8. Implement CAVE as an AgML module.