TBIOROOT Rework Status (Core Software Meeting - 03/21/2001)

After  trying a couple of different strategies I managed to find a partial solution that didn't require too much modification of the code.

How the dependence of CalRecon on TkrRecon was Removed

• Made a local copy detGeo called CalDetGeo in CalRecon thus removing calorimeterGeo's need for detGeo
• Added a new Class called Axis to GlastEvent who's only purpose in life is to contain the enum
  • enum axis { X,Y,PASSIVE}; (formerly in TkrAxis)
• Tracy paralleled this change by making detGeo into TkrDetGeo and removing all things associated with Cal.

How the dependence of TBIOROOT on CalRecon was Removed

• Moved the data classes used by both TBIOROOT and CalRecon into GlastEvent, which is a natural place for them.
• Changed CalRecon to take into account the move of the classes.
• Changed TBIOROOT to use the classes now in GlastEvent.
• The classes moved are: CalBase, CalLogID, CalADCLogs, CaRecLogs, CsIClusters.

How the dependence of TBIOROOT on TkrRecon was NOT removed

• After talking to Tracy it became clear that trying to parallel the moving of data classes done for CalRecon would result in the majority of the code in TkrRecon moving to GlastEvent.
• The idea of interfaces for the output side of the TkrRecon data classes was entertained, however we rejected the idea because it would result in a rather large and quite nasty interface.

Summary

At least the direct link between CalRecon and TkrRecon was broken, which is a small victory. Tracy is also proposing that he will modify TkrRecon to eat TkrDigis which will go part of the way to solving the TBIOROOT problem. I hate to declare defeat however fixing the TBIOROOT->TrkRecon dependence is probably more work then it's worth.

Ian Gable: 05/29/2001 08:29 PM