Home » Groups » STAR Protected

IST/SSD residuals corrected

Updated on Mon, 2012-12-10 15:32. Originally created by bouchet on 2012-10-21 13:15.
see plots here

The residuals (<u-uP> and <v-vP>) for the IST were shifted (~50 microns).
The reason was because of wrong IstLaddersOnSectors and IstWafersOnLadders tables : these 2 tables are used to position all IST wafers/ladders.
The comparison btw the rotation matrices using the geometry tables and the root geometry is below:

root geometry :

StPixelFastSimMaker:DEBUG -  path: /HALL_1/CAVE_1/IBMO_1/IBAM_1/IBLM_4/IBSS_1 

matrix global_5 - tr=1  rot=1  refl=0  scl=0 

  0.965926    0.258819    0.000000    Tx =   1.822235 

 -0.258819    0.965926    0.000000    Ty =  13.881249 

  0.000000    0.000000    1.000000    Tz = -10.100000


geometry tables :
 

Idcur : 3401 

matrix R3401 - tr=1  rot=1  refl=0  scl=0 

  0.965926    0.258819   -0.000000    Tx =   1.832590 

 -0.258819    0.965926    0.000000    Ty =  13.919890 

  0.000000    0.000000    1.000000    Tz = -10.000000
To get the values used in the geometry tables, I loop over the Geant volumes. The mistake was to use the IST ladder volume ( IBAM ) instead of the active silicon volume ( IBSS )
The residual plot for both directions are now centred at 0


  • Matrix multiplication
To go from global to local, the following matrices are multiplied :

  WG = Tpc2Global * GL * SG * LS * WLL; 
 
with 
 Tpc2Global matrix Tpc2Glob - tr=1  rot=1  refl=0  scl=0
  1.000000   -0.000000    0.000000    Tx =   0.000000
  0.000000    1.000000    0.000000    Ty =   0.000000
  0.000000   -0.000000    1.000000    Tz =   0.000000

GL   :  St_Survey *IstOnGlobal = (St_Survey *) GetDataBase("Geometry/ist/IstOnGlobal");
SG   :  Survey_st *SectorsOnGlobal  = IstSectorsOnGlobal->GetTable();  // sectors in the IST barrel coordinate system 
LS    :  St_Survey *IstLaddersOnSectors = (St_Survey *) GetDataBase("Geometry/ist/IstLaddersOnSectors");// ladders in the IST sector coordinate systems 
WLL :  St_Survey *IstWafersOnLadders = (St_Survey *) GetDataBase("Geometry/ist/IstWafersOnLadders");  // wafers in the IST ladder coordinate systems 

note : Tpc2Global is correctly placed at the center of STAR

  • some tests
There was a question of how ideal are the parameters set in the table. For example :

TDataSet *CreateTable() {

  if (!gROOT->GetClass("St_Survey")) return 0;

  Survey_st row = {0, 1,0,0, 0,1,0, 0,0,1, 0,0,0,.1,.1,.1,.1,.1,.1,"ideal position"};

  St_Survey *tableSet = new St_Survey("SsdOnGlobal",1);

  tableSet->AddAt(&row.Id, 0);

  return (TDataSet *)tableSet;

}

I put all zeros in the tables :  SsdWafersOnLadders.dev14.C, SsdSectorsOnGlobal.dev14.C , SsdWafersOnLadder.dev14.C
No changes is observed.
  • test
In SsdWafersOnLadders, I have shifted the position of the Z placement :

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

residuals <u-uP>



residuals <v-vP>


While the residuals in u are centred at 0 ( and minus the gaps ), a positive shift in Z (as tested) moves every residuals by this value.
It could suggest that the shift we've seen for the SSD is a misplacement of Z wafers :
  1. wafers with Z<0 placement should be shifted towards Z->0 and vice versa
  • test 
       if(wafer<9)

        {

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

        }

        else

        {

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

For wafers with Z<0, I shift the Z position by 100 microns. For wafers with Z>0, the shift is in the opposite direction
 
Result : no shift

Result : shift



 UPDATE (12/1)
SSD hits position from StEvent :
************************************************************************************
*    Row   *         x *         y *         z *        xl *        yl *        zl *
************************************************************************************
*        0 * -6.275085 * 22.172990 * 2.7764999 * -2.790498 * 0.6014999 * 0.0014993 *
*        1 * -5.044036 * 22.103467 * 26.770500 * -1.557498 * -1.504499 * -0.003500 *
*        2 * -5.046247 * 22.118604 * 26.788499 * -1.560498 * -1.486500 * 0.0115001 *
*        3 * 0.7703861 * 23.185161 * -19.88649 * -3.258496 * -0.311499 * 0.0004962 *
*        4 * 15.069697 * -16.17649 * 29.589500 * 1.0365052 * 1.3145004 * 0.0004962 *
*        5 * 7.5190558 * -20.55773 * 5.7924995 * 2.8084950 * -0.732500 * 0.0004950 *
*        6 * 0.0566745 * -21.84609 * -11.80950 * 3.4364988 * -0.934500 * 0.0004993 *
*        7 * -19.47356 * -11.68815 * -21.04849 * -1.689494 * -1.473498 * 0.0005006 *
*        8 * -22.04654 * -3.881427 * -15.68849 * -0.393502 * -0.463499 * 0.0004975 *
************************************************************************************

SSD hits in before track matching for alignment :
StSsdDbMaker:INFO  - *** StSsdDbMaker::Make() == StOK(0) ***
No RND HitT Collections
 SSD :ladder/wafer : 1/9
 i : 0 x/y/z/localPos_0/localPos_1/kId : -6.2751/22.173/2.7765/-2.7905/0.6015/8
 SSD :ladder/wafer : 1/15
 i : 0 x/y/z/localPos_0/localPos_1/kId : -5.044/22.103/26.771/-1.5575/-1.5045/8
 SSD :ladder/wafer : 1/15
 i : 0 x/y/z/localPos_0/localPos_1/kId : -5.0462/22.119/26.788/-1.5605/-1.4865/8
 SSD :ladder/wafer : 2/4
 i : 1 x/y/z/localPos_0/localPos_1/kId : 0.77039/23.185/-19.886/-3.2585/-0.3115/8
 SSD :ladder/wafer : 9/15
 i : 8 x/y/z/localPos_0/localPos_1/kId : 15.07/-16.176/29.59/1.0365/1.3145/8
 SSD :ladder/wafer : 10/10
 i : 9 x/y/z/localPos_0/localPos_1/kId : 7.5191/-20.558/5.7925/2.8085/-0.7325/8
 SSD :ladder/wafer : 11/6
 i : 10 x/y/z/localPos_0/localPos_1/kId : 0.056675/-21.846/-11.81/3.4365/-0.9345/8
 SSD :ladder/wafer : 15/4
 i : 14 x/y/z/localPos_0/localPos_1/kId : -19.474/-11.688/-21.048/-1.6895/-1.4735/8
 SSD :ladder/wafer : 16/5
 i : 15 x/y/z/localPos_0/localPos_1/kId : -22.047/-3.8814/-15.688/-0.3935/-0.4635/8
I'm not sure if the last digits loss (-6.275085 --> -6.2751) has really an importance here : it's just an approximation of 0.85 microns to 1 micron.

SSD hits saved after track matching :
***********************************************************************************
*    Row   * Instance *  fHits.xG *  fHits.yG *  fHits.zG *   fHits.u *   fHits.v *
***********************************************************************************
*        0 *        1 * 0.7702019 *   23.1847 * -19.88649 * -3.258496 * -0.311499 *
*        0 *        6 * -22.04604 * -3.881453 * -15.68849 * -0.393502 * -0.463499 *
*        0 *        8 * -19.47308 * -11.68802 * -21.04849 * -1.689494 * -1.473498 *
*        0 *       11 * 0.0567007 * -21.84559 * -11.80950 * 3.4364988 * -0.934500 *
*        0 *       13 * 7.5189251 * -20.55725 * 5.7924995 * 2.8084950 * -0.732500 *
*        0 *       15 * 15.069422 * -16.17608 * 29.589500 * 1.0365052 * 1.3145004 *
***********************************************************************************
 
The alignment code re-uses the geometry tables for Global<-->Local transformation. As the positions of SSD hits saved after alignment are the same as before the code starts, it looks the geometry tables are not responsible for additional shifts.
--> investigation towards the track projection

Comparison of detector placement : geometry tables vs. StiSsd

StiSsd :

StiSsdDetectorBuilder::buildMaterials() - I - Done 
StiDetectorBuilder::add(0,0) detector Ssd/Layer_0/Ladder_0/Wafers
Det Id = 7101 cv :-3.4885 22.025 0 phi: 1.7279 r: 22.3 z: 0
Det Id = 7102 cv :3.7957 21.975 0 phi: 1.3998 r: 22.3 z: 0
Det Id = 7103 cv :10.332 19.762 0 phi: 1.0891 r: 22.3 z: 0
Det Id = 7104 cv :15.878 15.658 0 phi: 0.77842 r: 22.3 z: 0
Det Id = 7105 cv :19.905 10.055 0 phi: 0.46775 r: 22.3 z: 0
Det Id = 7106 cv :22.025 3.4885 0 phi: 0.15708 r: 22.3 z: 0
Det Id = 7107 cv :22.037 -3.4116 0 phi: -0.15359 r: 22.3 z: 0
Det Id = 7108 cv :19.94 -9.985 0 phi: -0.46426 r: 22.3 z: 0
Det Id = 7109 cv :15.933 -15.602 0 phi: -0.77493 r: 22.3 z: 0
Det Id = 7110 cv :10.228 -19.816 0 phi: -1.0943 r: 22.3 z: 0
Det Id = 7111 cv :3.4885 -22.025 0 phi: -1.4137 r: 22.3 z: 0
Det Id = 7112 cv :-3.6038 -22.007 0 phi: -1.7331 r: 22.3 z: 0
Det Id = 7113 cv :-10.332 -19.762 0 phi: -2.0525 r: 22.3 z: 0
Det Id = 7114 cv :-15.878 -15.658 0 phi: -2.3632 r: 22.3 z: 0
Det Id = 7115 cv :-19.905 -10.055 0 phi: -2.6738 r: 22.3 z: 0
Det Id = 7116 cv :-22.025 -3.4885 0 phi: -2.9845 r: 22.3 z: 0
Det Id = 7117 cv :-22.037 3.4116 0 phi: 2.988 r: 22.3 z: 0
Det Id = 7118 cv :-19.94 9.985 0 phi: 2.6773 r: 22.3 z: 0
Det Id = 7119 cv :-15.933 15.602 0 phi: 2.3667 r: 22.3 z: 0
Det Id = 7120 cv :-10.228 19.816 0 phi: 2.0473 r: 22.3 z: 0

 
Geometry tables ( ladder 1 and 20 for comparison)

 { 101,   0.9986295,-0.0523360, 0.0000000,   0.0523360, 0.9986295,-0.0000000,   0.0000000, 0.0000000, 1.0000000,    -3.48849,  22.02545,   0.00000,      0.10000,   0.10000,   0.10000,   0.10000,   0.10000,   0.10000},// SFMO_1/SFLM_1/SFDM_1/SFSW_1/SF
L_1/SFSD_1
      { 120,   0.9645574, 0.2638730, 0.0000000,  -0.2638730, 0.9645574,-0.0000000,   0.0000000, 0.0000000, 1.0000000,   -10.22788,  19.81617,   0.00000,      0.10000,   0.10000,   0.10000,   0.10000,   0.10000,   0.10000},// SFMO_1/SFLM_20/SFDM_1/SFSW_1/S
SL_1/SFSD_1

There is again a good agreement between the position of detector volumes which means that Sti ( tracking) is using/placing the correct geometry.
 
UPDATE (12/7)
Another test was to run with the drift velocity set to 0 in StiTpcHitLoader (related to the correction for TOF)
default :


set to 0 :
Groups: