Changes in STEER: * If the number of detectors is set to 0 (zero) in AliFMDMap, it will assume that the data contained is 51,200 entries - corresponding exactly to the number of channels in the FMD. This is the default mode of operation for most maps - in particular the multiplicity map of AliESDFMD. Before, one would specify 3 detectors, 2 rings, 40 sectors, and 512 strips, resulting in 3*2*40*512=122880 entries - or 71680 entries that would never be used. This change will effectively more than half the amount of memory used by AliESDFMD. * Implemented the member function AliFMDMap::CalcCoords to go from array index to detector coordinates (detector,ring,sector,strip). * Implemented *=, /=, +=, and -= between AliFMDMap objects, and *, /, +, and - operators that return an AliFMDFloatMap object. The implementation will access the contained arrays sequentially for optimal speed (unrolled nested loops). This would allow us to the ADC->Energy conversion like energy = (adc - pedestal) * gain where energy, adc, pedestal, and gain are all AliFMDFloatMap objects. Special care is taken if the maps do not have the same dimensions. * Implemented AliFMDMap::ForEach that takes an object of a sub-class of AliFMDMap::ForOne and applies the relevant functional operator to each element. The internal array is accessed sequentially for optimal speed (unrolled nested loops). * Define AliESDFMD::ForEach that will loop over all entries and apply the functional operator of the supplied object of a sub-class of AliESDFMD::ForOne to each element in turn. The loop is unrolled. Changes in FMD: * AliFMD***Map now defaults to construct with exactly 51200 entries. Maps with fewer entries can still be made (like before) by explicit use of constructor arguments. * Calibration and digitizer code constructs AliFMD***Map with minimal sizes needed. These changes committed by Peter HRISTOV on behalf of Christian Holm Christensen.
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?
Fixed some coding style violations. Added track lenght through medum to AliFMDHit. Also added flag fStop for stopped tracks (IsTrackStop || IsTrackDisappeared). Updated DrawHits, DrawXsection. Added GetMedia.C to track where tracks corresponding to hits come from. Useful for background studies. Added DrawHitsDigits, to compare the energy loss from hits to the ADC counts from digitisation. Updated Config.C to properly deal with TFluka.
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.
Got rid of class template AliFMD<Type> on request of Federico, who thinks they are evil (sigh!). Added a lot of (duplicate) code to cover what was previously done by that class template. New structure to the reconstruction algorithms. In essence, the details of the algorithms areput into separate classes. Clean-up of some code. Removed header guards in implementation files _only_ - Peter thinks they are evil (sigh!). They are still present in the declaration files as I believe that is definitely the Right Thing (tm) to do cf. Fons. The code is in a pretty unstable state, but I had to commit as Federico and Peter wanted the class template out ASAP. Apparently there's a problem on Optreon/Itianium machines where either R__ACCESS_IN_SYMBOL or R__USE_SHADOW_CLASS is defined, and an assert fails: Assert(sizeof(AliFMDMap<float>) == sizeof(::ROOT::Shadow::BlaBla)) This seems to be a problem in (ROOT)CINT - not with templates as such.