A recent issue was found related to one ssd table in db.

For details : 

 http://www.star.bnl.gov/HyperNews-star/protected/get/dbdevel/72.html

The result of this corrupted db connection affected one table of the SSD : ssdNoise table that stored the values of the noise and pedestal.

In some case, when the first connection is done to db04, this table is not found.

This may affect a certain percentage (60%) of the current data already processed.

But apparenty, when the first connection is done with others than db04, the correct tables are picked.

It affects only files/sequences of data processed when the first connection (first event) is done with db04.

 That means we don't take the related noise and pedestal value for a given physics run, then the default values are set.

They are :

1. noise      = 3 adc
2. pedestal = 120 adc

This will affect the hit reconstruction because :

1. the clusterMaker used a cut on the noise value for each strip : during loops over fired strips for each wafer, we keep only strips above a threshhold (signal/noise>3)
2. now, if the noise that is taken by default (3 adc) is lower than the real noise that should have been used, more strips will fullfill this condition
3. the consequence is we will have more clusters that could be match to form a hit

So to reproduce this issue, I run the bfc chain with :

• the correct noise and pedestal values
• the default noise and pedestal values

The bfc chain used is :

DbV20080418,B2007g,ITTF,IAna,KeepSvtHit,hitfilt,VFMinuit3,l3onl,emcDY2,fpd,ftpc,trgd,ZDCVtx,SvtIt,SsdIt,Corr5,pmdReco,-dstout

the file used :

/star/data03/daq/2007/120/8120052/st_physics_8120052_raw_1040001.daq (AuAu200)

The next histograms are :

• open symbols : default values
• plain symbols : correct values

Fig 1 : Size (= number of strips) of all reconstructed clusters on p-side

 

• number of clusters on p-side (correct values) : 442721
• number of clusters on p-side (default values) : 994624

Fig 2 : Size (= number of strips) of all reconstructed clusters on n-side

 

• number of clusters on n-side (correct values) : 519628
• number of clusters on n-side (default values) : 902831

Fig 3 : Size (= number of strips) of all matched clusters on p-side

 

Fig 4 : Size (= number of strips) of all matched clusters on n-side 

 

We see clearly that the size of clusters (both p and n sides) are bigger with the default values.

I make a difference between all reconstructed clusters and matched clusters : the matched clusters are those effectively used to form hits, and their mean position in a given wafer (calculated as the COG) is used to determine the local hit position.

So having a cluster with anomalous size will degrade the position of the hit.

Fig 5 : kind of packages (hits) reconstructed

 

The kind of packages determines how many clusters on p-side  are associated with clusters on n-side.

From this plot , we see :

1. number of hits is higher with the default values than with the correct
2. more hits are coming from association on more than only one cluster per side
3. number of hits (correct values) : 169232 ; number of hits (default values) : 226521 (+30% hits)

For comparison, the same for CuCu :

 

In CuCu, we have ~ 90 % of hits coming from assocation of 1 clusters on p-side and one on n-side (noted here case 0 : 1p-1n).

The increase of other cases when we compare to AuAu is expected since it is a higher environment of particles so I expected these results.

However, the percentage of case 0 for :

1. correct values : 75 % 
2. default values : 63 %

 

Impact on the tracking

I looked at the MuDst files produced when I ran these 2 configurations.

The cuts for the tracks selection are :

• |ZVertex| < 30
• pt>0.1
• NTpc>15
• |eta|<1.3

Next are the phi and eta distribution of primary tracks with only SSD hits (in blue with the default noise values, in red with the correct)

Fig 6 : phi of selected tracks

 

Fig 7 : eta of selected tracks

 

We see an increase of the number of tracks for :

• phi ~ -2.5
• phi ~ -1.4
• phi ~ 1

 Now I compared the number of hits reconstructed in SSD 

 Fig 8 : number of hits (y-axis) reconstructed per ladder (x-axis)

 

Here we also see an increase of the number of reconstructed hits for :

• ladder 2
• ladder 3
• ladder 10
• ladder 14

That means that the increase of the number of tracks due to the default values of noise and pedestal in SSD is directly due to the increase of the number of hits 

You can look at the relation ladder_Id vs phi that shows that :

• ladder 2,3 : phi ~1
• ladder 10 : phi ~ -1.5
• ladder 14 : phi ~ -2.5

Investigation of cuts :

1. cut on number of silicon hits

The goal is to see if taking tracks with more than 1 SSD hits give the same distribution for the correct and default values. The idea may be

that adding svt hits could remove tracks where a wrong ssd hit is taken first.

The next panel show the phi distribution of tracks with no silicon hits (uper left), 1 ssd hits (uper right) then +1,2,3 SVT hits.

The dash-line is the default values and the plain line is the correct values

Fig 9 : phi distribution of tracks with 0,1,2,3,4 Silicon hits (the last panel is for tracks with SSD only)

 

1. the second cut I looked is the chi^{2} of the tracks vs phi to see if a higher chi^{2} is obtained for the phi region where the wrong hits sit.

There is no clear dependance 

Fig 10 : chi^{2} vs phi for tracks with SSD only (correct values)

 

 Fig 11 : chi^{2} vs phi for tracks with SSD only (default values)