In continuation of bug #1255 (see previous blog entry) for ssd geometry tables used in simulation/real data, it has been decided to not use the 

ssdWafersPosition table for simulation (.C file in $STAR/Geometry/ssd) but instead to recalculate the wafers position (as in real data) using tables in DB, and then to produce a ssdWafersPosition_st structure.

For this, we will then load 4 tables : 

• SsdOnGlobal
• SsdSectorsOnGlobal
• SsdLaddersOnSectors
• SsdWafersOnLadders

When running the simulation, the tables are explicitely set to sim (in StSsdDbMaker::Init()) in order to get the corresponding flag

 if( m_Mode == 1) {

    LOG_INFO << "Init setting WafersPositions to simulation" << endm;  

    SetFlavor("sim","SsdOnGlobal");

    SetFlavor("sim","SsdSectorsOnGlobal");

    SetFlavor("sim","SsdLaddersOnSectors");

    SetFlavor("sim","SsdWafersOnLadders");

  }

In addition, in order to access only one time the tables in Db (and not to re-access in another maker), we introduce getter function to access the entries of the ssdWafersPositions produced :

  virtual St_ssdWafersPosition *GetssdWafersPos(){return m_positions;}

  virtual St_ssdDimensions     *GetssdDimensions(){return m_dimensions;}

Then in the simulation maker, one retrieves the positions of wafers with :

(in St_sls_Maker.cxx)

 m_positions  = 0;

  m_positions  = gStSsdDbMaker->GetssdWafersPos();

  if ((!m_dimensions)||(!m_positions)) {

    LOG_ERROR << "No  access to geometry parameters" << endm;

    return kStFatal;

  }

  if(m_positions){

    LOG_DEBUG << " m_positions found " << endl;

    positions = m_positions->GetTable(); 

    N = m_positions->GetNRows();

    LOG_DEBUG << " size is : " <<N  << endl;

  }

where   ssdWafersPosition_st *positions;

• check 1 : I checked with real data (same event of the same file) that I get same results as here (see check2)

The log is here

So we see that we have the same number of hits, with the same globals positions.

It means that the tables for real data (here m_Mode==0) are picked.

• check2 : simulation data (most important for this change)

I do have a difference without the change.

The point is that when we calculate the ssdWafersPosition table using sim tables and when we used the VMC geometry in StiSsdDetectorBuilder, there are slight differences.

This log shows what we expect : the wafer coordinates (here for wafer 7101 anf 7115) are the same for ssdWafersPositions and using VMC geometry.

Then when I plot the residuals, it is centred (for all hits) at 0.

I also checked that tables from simulations are picked (see this log)

 I check in this also which tables are taken since the SSD is positionning with respect to SVT and that SVT is positionning with respect to TPC (Yuri)

What I have instead are slight differences when re-creating ssdWafersPosition and VMC geeometry (see the log)

 --> it seems there is a difference between t2 and center[2]

 

 Update : 08/12 : after several tests, it appears that the difference is due to tables with flag *.y2005e.C and *.upgr01.C and *.C

Tables with *.y2005e.C gives the correct positions of hits.

In fact, there is only one table different : SsdSectorsOnGlobal

It can be show here (default tables)

and *.y2005e.C tables

Yuri made the change in .DEV2 for the table SsdSectorsOnGlobal : he disabled the old entry and we add the new ideal table :

 

mysql> select beginTime,t0,t1,t2,flavor,deactive from SsdSectorsOnGlobal where flavor='sim';

+---------------------+---------------+--------------+---------------+--------+------------+

| beginTime           | t0            | t1           | t2            | flavor | deactive   |

+---------------------+---------------+--------------+---------------+--------+------------+

| 2004-10-30 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-10-30 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-10-30 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-10-30 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-12-01 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-12-01 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-12-01 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-12-01 00:00:00 | -0.3993000000 | 0.0217000000 | -0.0900000000 | sim    | 1218572464 |

| 2004-10-30 00:00:00 |  0.0000000000 | 0.0000000000 |  0.0000000000 | sim    |          0 |

| 2004-10-30 00:00:00 |  0.0000000000 | 0.0000000000 |  0.0000000000 | sim    |          0 |

| 2004-10-30 00:00:00 |  0.0000000000 | 0.0000000000 |  0.0000000000 | sim    |          0 |

| 2004-10-30 00:00:00 |  0.0000000000 | 0.0000000000 |  0.0000000000 | sim    |          0 |

+---------------------+---------------+--------------+---------------+--------+------------+

 

Update : 08/15 : the change done in .DEV2 is available in DEV

check 1 : I ran, prior this commit, over 1 event.

The log of SSD hits is here.

The plot for the residuals in X (x_MC - x_reco) is here

check 2 : now I ran in DEV after the commit :

log of ssd hits : here

plot for residuals in X : here 

conclusions : before and after the commit, we have the same number of hits from GEANT and reconstructed hits (with the same positions) 

from GEANT : 1845 hits

reco HITS : 1316 hits

The only slight difference is when I plot the residuals, I have 2 more entries with the recent commit