The current implementation of AgML requires 647 separate ROOT dictionary entries in order to support the STAR geometry model.  This includes entries for each geometry module (e.g. one for the EcalGeo.xml, one for the EcalGeo6.xml, one for the TpceGeo1.xml, etc...).  And it includes entries for every data structure declared within each geometry module.  This has an impact on  compilation time which we would like to reduce.

Why do we need so many dictionary entries?  Two reasons:

1. We use the ROOT dictionary as a factory in order to instantiate the modules and blocks which build detectors and volumes:

       AgModule *module = (AgModule *)TClass::GetClass("EcalGeo6") -> New(); 
       AgBlock *block = (AgBlock *)TClass::GetClass("ECAL") -> New();

2. We use the ROOT dictionary to manipulate the data structures declared in the modules from the master steering routine

        AgStructure::AgDetpNew('ECAL');
        AgStructure::AgDetpAdd('Emcg_t', 'version', 1.0f ); // Set Emcg_t emcg; emcg.version = 1.0f;
        module -> Construct( block );

Very type sensitive ... calling with a double or an int in the above code would silently fail. Many accesses to ROOT dictionary to find the address of a data member, and then set the value of that data member. Just not a good design.

So we would like to remove the dependence on the ROOT dictionary to the greatest extent possible. To that end, we implement our own dictionary scheme in AgML. Since we know at parsing time (i.e. when xml --> .cxx) pretty much everything we need to know about a data structure, we can write our own dictionary class.  

---

05/12/2016

First attempt brings the dictionary entries down from 647 to 140.  The 140 dictionary entries correspond to classes used to describe a configuration state for the geometry modules. 

Code is able to reproduce the y2012 -- y2015 geoemtry tags.

Issue exists with FTPC and its supports.  Old Geometry.cxx model tied the FtpcGeo.xml and SupoGeo.xml modules together, creating them in the same routine, triggered by a single detector state.  The new scheme creates one detector module per detector state.  Need to work around this by either (a) creating new SUPOxx detector states, or extending FTPCxx states to create the support geometry as well.