Migrated to a geometry implemented via AliFMDGeometry (derives from

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.