- yuxip's home page
- Posts
- 2015
- 2014
- December (2)
- November (1)
- October (2)
- September (6)
- August (2)
- July (1)
- June (3)
- May (4)
- April (1)
- March (2)
- 2013
- December (1)
- November (1)
- October (3)
- September (3)
- August (2)
- July (1)
- June (2)
- May (1)
- April (3)
- March (1)
- February (1)
- January (1)
- 2012
- 2011
- My blog
- Post new blog entry
- All blogs
FMS analysis tools in StRoot
To my knowledge there are 3 versions of analysis code currently that performs FMS-related analysis within StRoot framework. Although these code have
different interfaces and layouts, at the core of the reconstruction they all rely on the existing cluster finder(Yiqun class) in the PSU standalone package.
Here I'll try to describe what each of these code does based on my understanding, and especially focus on the version that I am working with.
1). StFmsAnalysisMaker from Jim Drachenberg/Xuan Li/Mriganka Mondal
This maker basically does a full-blown reconstruction from fms ADCs (retrieved from StMuDst::event()->triggerData()) to photons. The actual cluster finder
Yiqun class is also nested in this maker. One can quickly learn how to get FMS raw data and reconstrcted photons/cluster by looking at the first few steps of
this maker. But this particular maker is mostly intended for a very specific analysis the writer was interested in (FMS-FTPC correlations, jet finding on FMS,etc).
It does not serve as a baseline maker which provides well-defined transient/persistent container classes(of photons/clusters) for downstream analyses that focus
on any other particular topics.
2). BuildRunFMS_NMSP_7_5_2012.tgz from Steven H.
This is the package Steven has posted here. It largely keeps the structures of the standalone analysis packge unchanged and moves everything into StRoot
under a common namespace PSUGlobals. Users have the option to select either local calibration files or the ones from database (more of an experts' job). The
current code is not doing a very good job at hidding details of the reconstruction to users or downstream analyses. The only persistent class it serves is StMuFmsCluster
which stores the reconstructed clusters as well as photons derived from each of the cluster. Because the way the reconstruction code was set up any user/downstream
analysis has to explicity loop over each cluster in order to get a list of photons. This may confuse a non-expert user who's only interested in getting photons. But this code
is a good starting point for converging all the current analysis code and come up with an 'official' version.
3). StFms*Makers from Yuxi Pan
This is a group of makers that I am currently working with in my FMS-FMS/midrapidity correlation analysis. They're located at ~yuxip/FMS/StRoot on rcas node
When I wrote these makers I was trying to isolate FMS reconstruction itself from any further analysis/QAs that uses the reconstrcuted objects. So people who are interested
in the actual reconstruction procedure could be looking at only a certain part of the code while users who only want to get the results of the reconstruction don't have to worry
anything about setting up the reconstruction workflow. The layout of these makers are as follows,
a). StFmsHitMaker
This maker is almost the same as the one lives in $STAR/StRoot except that it adds the option of selecting local calibration files or read from database. It also provides
time-dependent gain calibrations (by reading another local file RunDep.root) in the same way as the standalone PSU code. The result of this maker is 4 energy matrices
(one for each NSTB module) which will be presented to the point maker.
b). StFmsPointMaker
This is where the actual cluster/photon reconstruction happens. StFmsPointMaker receives the 4 energy matrices from StFmsHitMaker, and the FindPoint() method is
the place that Yiqun class was called. Notice that it is easy to plug in a different cluster finder into FindPoint(). At the end of this function the reconstructed clusters and photons
will be stored in their own containers (StFmsPoint/StFmsPointCollection, StFmsCluster/StFmsClusterCollection). Also from each cluster one can easily get the associated
photons and towers because they're already a member of the cluster. But from each photon (StFmsPoint) one has to use the event-wise cluster id to trace back the cluster that
produced this photon. At the end of the reconstruction, the list of clusters and points(currently disabled) are added to TDataSet which can then be retrieved by downstream analysis.
c). StFmsAnalysisMaker
This is actually an example of how a user could play with FMS reconstruction results together with information from other detectors. Specifically from line 362 of StFmsAnalysisMaker
the code begin to read fms results. Here it gets StFmsClusterCollection from TDataSet and loops over clusters to retrieve photons. Note that if StFmsPointCollection was also
uploaded to TDataSet one can get photon list directly. Here for my analysis I've defined the persistent class StFmsDiPhoton in order to save photon pairs but it may not be really
relevant for others. In this maker I also have information from EMC and jet finder, etc.
Since my version still relies on the cluster finder in PSU package. I have to tell cons to include the PSU source files, for example by doing
cons EXTRA_CXXFLAGS='-I/star/u/yuxip/fmssim/FpdRoot -I/opt/star/sl53_gcc432/include'
- yuxip's blog
- Login or register to post comments