Home » Blogs » ckimstar's blog

FMS points' z (comments from meeting at Aug. 7)

Updated on Tue, 2017-08-08 12:49. Originally created by ckimstar on 2017-08-07 16:10.

- Used single segment of RUN15 pp200trans: st_fms_16066033_raw_0000005.MuDst.root
- ~7,800 events

- Applied cuts:
   a. Points multiplicity cut (https://drupal.star.bnl.gov/STAR/system/files/CKim_170731.pdf)
   b. Excluded bad looking FMS channels
   c. FMS points E > 5 (GeV)

- Getting FMS z position (part of analysis code):

mFmsColl = event->fmsCollection();
StSPtrVecFmsPoint& points = mFmsColl->points();
...
const int detId = points[a]->detectorId();
const float z = points[a]->XYZ().z();

  then separated it by detId (north/south, large/small)

- Results:
 
 

- Checking the database:

a. DB -> Geometry -> Geometry_fms -> fmsDetectorPosition -> zoffset
b. dump file (dumpFmsDetectorPosition.txt)
   1) zoffset of small cells: 734.1
   2) zoffset of large cells: 729.7
   3) No south/north difference
 

- Conclusion: the z position of points I use are NOT the one in DB (surface of FMS cells).
   Why two distinct peaks exist for detId = 10 (south small)?
   In addition two different type of cells (detId 9 and 11: South large/small) got similar points z. Why?
   Is this coming from clusterization or point reco?

-----------------------------------------------------------------------------------------

- Update: Akio's explanation (quote from mail exchange)

...
To get STAR coordinate (xyz) from FMS local coordinate (x,y) to fill StFmsPoint, we use StFmsDbMaker::getStarXYZ().
Before run15 (with PositionModel=0), it uses x,y,z offsets from DetectorPosition DB and it asssumes perfect/regular matrix.

For run15 and beyond (with PositionModel>0 in DB), it uses codes provided by Stephen and Chris, called
  $CVSROOT/StRoot/StFmsDbMaker/getCellPosition<year><beam>.*
which provide STAR xyz for a given cell based on survey and konwledges of spacer locations added by re-stacking of cells before run15.
This gives none-perfect/irregular matrix in XY, and also there are small difference in z.

Following are front surface z [cm] from getCellPosition2015pp.cxx:
  nstb=1 (large north) 7208
  nstb=2 (large south) 7188
  nstb=3 (small north row>16) 7208
  nstb=3 (small north row<16) 7204
  nstb=4 (large north) 7188 <- small south? (Chong)

In addition, StFmsDbMaker::getStarXYZ() adds depth of shower max,
which is currently hardcoded as 15.0cm regardless if its small or large cells.
This should depends on small/large cell (and angle),
or we should move to Zauwen's code which gives xy in a certain reference Z he specifies.

- Update: Zhanwen's method for retrieving z position

...
find out in StFmsDbMaker, is this what model you are using. Looks like two more method is available for Run15(which I usually don't care).
So if mode==0 , it should be fine.
  "if(mPositionModel==0){ //simple uniform model with xyz offsets and widthes from DB"

»