Introducing the fixes needed in order to read the old RCU firmware format (v<3) with the new altro decoder. The fixes are done in a way so that it would be easy to remove this addition whenever the backward compatibility will not be needed anymore. Removal of some obsolete code related to the dummy altro trailer. It is not used by the detectors for long time as they implemented their real hardware mapping.
Check-in to fix a few problems: * New pre-processor macro 'AliFMDDebug' which only ever evaluates it's argument if the debug level is high enough. This is to remove 'expensive' calls to 'Form' even if _NDEBUG isn't set. This could be used generally if the core team chooses to do so. * Fix 'policy' violations. * Issue an AliFatal if calibrations are not found. Previously it issued an AliWarning and continued using hard-coded calibrations. * Add support for looping over kinematics tracks and getting associated hits in AliFMDInput. This is to support background studies. * Fixed problem in AliFMDRawWriter that meant that FMD1 data was never written to disk. I assume this bug was introduced when cleaning up compiler warnings.
New detector numbering scheme (common for DAQ/HLT/Offline). All the subdetectors shall use the AliDAQ class for the sim and rec of the raw data. The AliDAQ and raw reader classes now provide all the necessary interfaces to write and select the detector specific raw-data payload. Look into the AliDAQ.h and AliRawReader.h for more details.
Added documentation of each file. Re-enabled RAW I/O using AliAltroBuffer and AliAltroRawStream. Re-implemented AliFMDRawStream for better use with AliAltroRawStream. Added strip range to calibration parameters. Perhaps I also need a calibration that says how many pre-samples the ALTRO makes. Currrently with the hardware we have now, it seems that the ALTRO makes 4 pre-samples, regardless of the oversampling rate. However, we've only varied the VA1 shift clock (between 5 and 1.25MHz), relative to 10MHZ for the ALTRO sample clock. It may be that the number of pre-samples is a constant time, which means it depends on the actual sample clock frequency. If that's the case, then this parameter should be stored with the sampling rate parameter. If not, then it should probably be stored independently. I'm seriously considering making a base class, AliFMDIndex, like struct AliFMDIndex { UShort_t fDetector; Char_t fRing; UShort_t fSector; UShort_t fStrip; }; and have the `per-strip' classes derive from that, like class AliFMDHit : public AliHit, public AliFMDIndex { ... } class AliFMDDigit : public TObject, public AliFMDIndex { ... } What does the experts think about that?
New RAW I/O. I rolled my own, because I wasn't happy with the old implementation, and things were missing. The new implementation can actually be used in any setting, and is much more flexible. Some other fixes for various small things, and new macros to make fake alignment data, etc.
Migrated to a geometry implemented via AliFMDGeometry (derives from AliGeometry) and support classes AliFMDRing, AliFMDDetector. The geometry classes holds parameters only, and does some calculations based on these. Simulation code is moved into a seperate abstract class AliFMDSimulator with 2 concrete implementations. AliFMDGeoSimulator and AliFMDg3Simulator. The AliFMDSimulator classes sets up the geometry and handles hits in the detector elements. AliFMD simply forwards calls to the AliFMDSimulator object. AliFMDGeoSimulator implements the geometry via the ROOT TGeo classes. That means that we can implement the shape of the silicon sensors via a divided TUBS volume put inside a ONLY XTRU volume. AliFMDG3Simulator implements the geometry via messages to TVirtualMC. Which concrete AliFMDSimulator is instantized is decided at run-time by checking TVirtualMC::IsRootGeometrySupported. If it returns true, then the AliFMDGeoSimulator is used. Otherwise, the AliFMDG3Simulator is used. The new singleton class AliFMDParameters acts as a simple DB of some parameters which is shared amoung the various piecies of the code, and which does not belong to the geometry. TODO: Implement the AliGeometry member functions Impact and ToGlobal. The latter is seriously limited by the fact that AliRecoPoint only has 3 indicies to identify a detector, while the FMD uses 4 (detector, ring, sector, strip). Implement the DrawDetector member function in AliFMDSimulator (one way od the other). In AliFMDG3Detector, we should check if the hit is inside the real shape of the silicon sensor. Things to consider: TGeoManager says it finds the `illegal' extrussions: * extrusion ov058/FIMO_x_0: vol=FIMO node=FIAC_0 extr=1.16823 * extrusion ov061/FOMO_x_0: vol=FOMO node=FOAC_0 extr=0.737969 and overlaps * overlap ov190/FMD3_o_7_8: vol=FMD3 <F3SL_6<->F3SL_7> ovlp=0.148996 * overlap ov191/FMD3_o_5_6: vol=FMD3 <F3SL_4<->F3SL_5> ovlp=0.148996 * overlap ov192/FMD3_o_6_7: vol=FMD3 <F3SL_5<->F3SL_6> ovlp=0.148996 * overlap ov193/FMD3_o_1_2: vol=FMD3 <F3SL_0<->F3SL_1> ovlp=0.148996 * overlap ov194/FMD3_o_1_8: vol=FMD3 <F3SL_0<->F3SL_7> ovlp=0.148996 * overlap ov195/FMD3_o_2_3: vol=FMD3 <F3SL_1<->F3SL_2> ovlp=0.148996 * overlap ov196/FMD3_o_3_4: vol=FMD3 <F3SL_2<->F3SL_3> ovlp=0.148996 * overlap ov197/FMD3_o_4_5: vol=FMD3 <F3SL_3<->F3SL_4> ovlp=0.148996 The first comes from the MANY TUBS volume inside the ONLY XTRU volume, and that should be OK. The latter comes from the some overlaps between the 8 support beams in the FMD3 cone. I've made these MANY volumes (I think), but TGeoManager still complains (I don't know why - it shouldn't). Christian Holm <cholm@nbi.dk> Thursday, 30th of December, 2004.
Various style issues dealt with, like inclussion of header files, etc. Honeycomb material changed to Aluminum - which is what want. New split of reconstruction classes. We have one `manager' class: `AliFMDReconstructor' that contains a list of algorithms derived from AliFMDMultAlgorithm. Currently implemented are `AliFMDMultNaiive' and `AliFMDMultPoisson'. New data structure `AliFMDMult' encodes common multiplicity information. `AliFMDMultRegion' hold multiplicity information gather from sevaral strips, like when using the Poisson method. This class should be extended to give information on the average eta, phi value. `AliFMDMultStrip' hold information on multiplicity from a single strip, as is the case when using the naiive approach to reconstruction. Some old and obsolete files are removed. AliFMDMap is moved into libFMDbase as per request of Thomas Kuhr. New subdirectory `scripts' will hold various scripts for testing, and so on.