1) there is no need to add the constants defined in StSsdUtil/StSstConst.h
Constants for the SSD are already defined in ssdDimensions tables :

http://www.star.bnl.gov/Browser/STAR/browse-Geometry-ssd-ssdDimensions.html

struct ssdDimensions {
  long    wafersPerLadder;    /* 16         */
  long    a128PerSide;        /* 6          */
  long    stripPerSide;       /* 768        */
  double stripPitch;         /* 0.0095 cm  */
  double stereoAngle;        /* 0.0175 rad */
  double waferHalfLength;    /* 3.75 cm    */  
  double waferHalfWidth;     /* 2.1  cm    */
  double waferHalfThickness; /* 0.015 cm   */
  double waferHalfActLength; /* 3.65 cm    */
  double waferHalfActWidth;  /* 2. cm       */

The number of ladders is also defined in the table :

http://www.star.bnl.gov/Browser/STAR/browse-Geometry-ssd-ssdConfiguration.html

We used a DB entry for historical reason , meaning the # of ladders was not the same every year.

- run 3 --> 1 ladder prototype (but not sure if there was even data with this ladder)
- run 4 --> 10 ladders
- run 5,7 --> 20 ladders

These tables are initialized in StSstDbMaker.

2) Right now the main issue I see is that StiSst will always use the TGeo geometry, which is the result of the GEANT model.
That means even for real data it will use "ideal" geometry.
In StiPxl and StiIst you have defined an "idealGeometry" which is not present in StiSst.

In the old code (StiSst), the switch between real (survey) and ideal geometry is done by using the ssdWaferPosition table.
This table is built in StSstDbMaker and has the TGeoHMatrix definition for the 320 wafers. As this maker calls the Db, it will use either survey tables or geometry tables.

As a result of this maker, the object StSsdBarrel is built. That's the reason of the part :

 gMessMgr->Info() << "StiSstDetectorBuilder::buildDetectors() - I - Started " << endm;
   //StSsdBarrel *mySsd = StSsdBarrel::Instance();
   mySsd = StSsdBarrel::Instance();

   if (! mySsd) {// no active SSD
      gMessMgr->Info() << "StiSstDetectorBuilder::buildDetectors() - I - there is no SSD barrel - take whatever exist in GEANT" << endm;
      StiVMCToolKit::GetVMC();
      return;

   }

If no Barrel is found , meaning no placement of ladders, we use the ideal geometry.

For now, I would prefer to keep the use of this table (ssdWaferPosition) since it is also used in the offline hits reconstruction to calculate the local/global positions. It's better to be consistent between the positions of the hits and the placement of active sensor

3) The placement along Z is also done using a geometry table SsdSensorsOnLadders and differ from real data to ideal geometry

For real data (survey), ladder 1 as an example :

  {7101, 1,0,-0.000320, 0,1,0,  0.000320,0,1,  0.0178, -0.1998, -32.6230, .002, .1, .002,.1,.1,.1,"Survey Jim2013"}, //Lad01 Location=1
    {7201, 1,0,-0.000126, 0,1,0,  0.000126,0,1,  0.0212, -0.2013, -28.2740, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {7301, 1,0,-0.000714, 0,1,0,  0.000714,0,1,  0.0210, -0.2019, -23.9212, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {7401, 1,0,-0.000190, 0,1,0,  0.000190,0,1,  0.0237, -0.2029, -19.5748, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {7501, 1,0,-0.000015, 0,1,0,  0.000015,0,1,  0.0230, -0.2034, -15.2229, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {7601, 1,0,-0.000115, 0,1,0,  0.000115,0,1,  0.0255, -0.2048, -10.8725, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {7701, 1,0, 0.000041, 0,1,0, -0.000041,0,1,  0.0258, -0.2043, -6.5220, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {7801, 1,0,-0.000203, 0,1,0,  0.000203,0,1,  0.0257, -0.2048, -2.1693, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {7901, 1,0,-0.000257, 0,1,0,  0.000257,0,1,  0.0256, -0.2061,  2.1724, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {8001, 1,0,-0.000324, 0,1,0,  0.000324,0,1,  0.0267, -0.2049,  6.5273, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {8101, 1,0, 0.000003, 0,1,0, -0.000003,0,1,  0.0295, -0.2050,  10.8767, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {8201, 1,0, 0.000003, 0,1,0, -0.000003,0,1,  0.0270, -0.2026,  15.2300, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {8301, 1,0,-0.000261, 0,1,0,  0.000261,0,1,  0.0281, -0.2016,  19.5833, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {8401, 1,0, 0.000249, 0,1,0, -0.000249,0,1,  0.0299, -0.2003,  23.9453, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {8501, 1,0,-0.000059, 0,1,0,  0.000059,0,1,  0.0259, -0.1998,  28.2925, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},
    {8601, 1,0,-0.000417, 0,1,0,  0.000417,0,1,  0.0297, -0.1788,  32.6226, .002, .1, .002,.1,.1,.1,"Survey Jim2013"},

For ideal geometry, the position of sensor is "regular" along Z :

 row.t2 = -32.625  + 4.35*(wafer-1);

the following line :

 double sensorLength = kSstNumSensorsPerLadder * (sensorBBox->GetDZ() + 0.02); // halfDepth + 0.02 ~= (dead edge + sensor gap)/2

can also use the ssdDimension table values :

  double waferHalfLength;    /* 3.75 cm    */  
  double waferHalfWidth;     /* 2.1  cm    */
  double waferHalfThickness; /* 0.015 cm   */
  double waferHalfActLength; /* 3.65 cm    */
  double waferHalfActWidth;  /* 2. cm       */

in particular the active length (along Z) of the sensor is 2*2 cm but its total length 2*2.1 cm ; there are no gaps between sensors in the ideal geometry.


4) I think, if you want to use the TGeoHMatrix for the Z placement, you can access each sensor TGeoHMatrix with the old way :

  THashList        *ssdRot = gStSstDbMaker->GetRotations(); 
 // do Projections first SSD 
      for (Int_t i_ladder = 0; i_ladder < 20; i_ladder++) { 
        for (Int_t i_sensor = 0; i_sensor < 16; i_sensor++) { 
          UInt_t id = 7000 + 100*(i_sensor+1) + (i_ladder+1); 
          TGeoHMatrix *comb = (TGeoHMatrix *)ssdRot->FindObject(Form("R%04i", id)); 
          //std::cout <<" id : "<< id << std::endl; 
          //comb->Print(); 
          Double_t *rot = comb->GetRotationMatrix(); 
          Double_t *tra = comb->GetTranslation();