Home » Groups » STAR Protected

dev14 : SSD geometry

Updated on Tue, 2012-09-04 08:22. Originally created by bouchet on 2012-08-25 12:30.

 for dev14, SSD ladders should be rotated by 9 degrees around phi to have the edge of ladder 1 starting at 12:00 

Compared to the old configuration where the ladders weren't tilted

ISSUE : half of the hits are removed in the FastSimulator because the transformation global-->local coordinates is wrong

quick simulation :

  • 100 pions, flat Pt, with the old configuration

QA :INFO  - # TPC hits:          4961:  Bad ones (! flag):     342:     Used in Fit:      4502

QA :INFO  - # SSD hits:          94:    Bad ones(flag>3): 0:    Used in Fit:      75

QA :INFO  - # Hft hits:         228:    Bad ones: 0:    Used in Fit:      181

QA :INFO  - # Ist hits:         121:    Bad ones: 0:    Used in Fit:      91

--> ratio of hits used/ALL = 75/95 ~ 0.8

 

  • 100 pions, flat Pt, with the new configuration

QA :INFO  - # TPC hits:          5688:  Bad ones (! flag):     599:     Used in Fit:      4710

QA :INFO  - # SSD hits:          65:    Bad ones(flag>3): 0:    Used in Fit:      36

QA :INFO  - # Hft hits:         239:    Bad ones: 0:    Used in Fit:      193

QA :INFO  - # Ist hits:         114:    Bad ones: 0:    Used in Fit:      86

--> ratio of hits used/ALL = 36/65 ~ 0.55

 

09/01 : the issue with the SSD hits is explained here  

The SSD code ( reconstuction, tracking) is using geometry tables to calculate the rotation matrices ( global<--> local)  for each wafers.

These tables are :

 

  • SsdLaddersOnSectors.dev14.C  
  • SsdOnGlobal.dev14.C        
  • SsdWafersOnLadders.dev14.C
  • SsdSectorsOnGlobal.dev14.C
They are used as explained below
 
The issue was that when using the new geometry for the SSD, the rotation matrices were different from the method using the GEANT path access.
Therfore hits positions in reconstruction were different that wafer positions from where they belong, thus Sti Tracking always found a differnece too big between the Sti volume and the Sti hit.
 
A temporary solution was the GEANT path method ( as for StiPixel and StiIst ) in the SSD code.
For StiSsd, one has to define the list of materials.
My first attempt was to use only SLSD volume ( active silicon )
 
 <Block name="SFSL" comment="is the Silicon of the strip detector"  >
            <Material name="Silicon" />
            <Attribute for="SFSL" seen="2" colo="1" />
            <Shape type="BOX" dz="SFJP_SFSL_Dz" dx="SFJP_SFSL_Dx" dy="SFJP_SFSL_Dy" />

            <Create block="SFSD" />
            <Placement block="SFSD"  >
            </Placement>

Then I have included all the inactive areas for a given wafer :

 

Geometry description (from $STAR/StarVMC/Geometry/SisdGeo/SisdGeo7.xml):

  • SFSL  : <Block name="SFSL" comment="is the Silicon of the strip detector" >
  • SFAA : <Block name="SFAA" comment="is the A128C chip" >
  • SFPI   : <Block name="SFPI" comment="are the pions" >
  • SFFX  : <Block name="SFFX" comment="is the flex" >
  • SFRS  : <Block name="SFRS" comment="two supports of the hybrid stiffneer (piece of it)" >
  • SFRA  : <Block name="SFRA" comment="is the hybrid stiffneer" >

 

The result of simulation ( single tracks per event ) is below :

We see that when including the inactive areas, the number of hits reconstructed is the same but the number of hits used in tracking is lower.

Groups: