===============
Updated on May 13
===============
I did some test on the BFC chain options to determine switch-on or off for each detector subsystems. Here are some test results.
A) Check the SVT/SSD options
/star/u/dongx/lbl/hft/Run14/Sti_Test/Sti_05092014/Test_SSDSVT/test*.log
1)
default HFT complete chain: test_default.log
"P2014a,btof,BEmcChkStat,Corr4,OSpaceZ2,OGridLeak3D,-hitfilt"
Output are:
1 - activesst = 1
2 - usesst = 1
3 - activeist = 1
4 - useist = 1
5 - activepixel = 1
6 - usepixel = 1
7 - alignment = 0
8 - usevertexfinder = 1
9 - usetracker = 1
10 - useeventfiller = 1
11 - usessd = 1
12 - usesvt = 1
13 - activetpc = 1
14 - usetpc = 1
StiMaker::Init() -I- Adding detector group:Sst (ssd)
StiDetectorBuilder::StiDetectorBuilder() - INFO - Instantiating builder named:Ssd
StiDefaultToolkit::add() -I- Adding hit loader for detector group:SSD
StiDefaultToolkit::add() -I- Adding builder for detector group:SSD
StiMaker::Init() -I- Adding detector group:PIXEL
StiDetectorBuilder::StiDetectorBuilder() - INFO - Instantiating builder named:Pixel
StiDefaultToolkit::add() -I- Adding hit loader for detector group:Pixel
StiDefaultToolkit::add() -I- Adding builder for detector group:Pixel
StiMaker::Init() -I- Adding detector group:Ist
StiDetectorBuilder::StiDetectorBuilder() - INFO - Instantiating builder named:Ist
StiDefaultToolkit::add() -I- Adding hit loader for detector group:Ist
StiDefaultToolkit::add() -I- Adding builder for detector group:Ist
Comment:
i) The chain does what it should do. One confusion part is "usessd=1, usesvt=1" are set by default in StiMaker. SVT is not initialized as there is no SvtDbMaker in the chain.
ii) The P2014a contains the default tracking chain: StiHftC = "StiLibsHft -SvtIT -SsdIT PxlIT pxlDb IstIT istDb SstIT ssdDb"
"-SvtIT" and "-SsdIT" are intended to disable the Svt and Ssd in Sti, but since the "usessd" and "usesvt" are set by default in Sti, thus create some confusions.
I would suggest:
a) use "NoSvtIT" and "NoSsdIT" instead of "-SvtIT", "-SsdIT", they will do all the job to switch off the SvtIt and SsdIT. In addition, in the BFChain.cxx, they can be recognized and set "usesvt" to 0. The "usessd" is a bit tricky, see line 435 in StBFChain.cxx.
b) Probably a good way is not to set the "usesvt" and "usessd" in StiMaker by default in the constructor. They should be enabled with chain options.
A simple test in /star/u/dongx/lbl/hft/Run14/Sti_Test/Sti_05092014/Test_SSDSVT/Modified_StiMaker/ with the default chain shows it enables the same detector groups. See test_default.log in this directory.
2) Another reason I suggest to make the change is for the test when one wants to switch off the Ssd/Svt geometry.
A quick test with the following chain
"P2014a,btof,BEmcChkStat,Corr4,OSpaceZ2,OGridLeak3D,-hitfilt,-SstIT"
will not do the job since the "usessd" is set to TRUE by default then. The log file is test_NoSst.log. You can see the output
1 - activeist = 1
2 - useist = 1
3 - activepixel = 1
4 - usepixel = 1
5 - alignment = 0
6 - usevertexfinder = 1
7 - usetracker = 1
8 - useeventfiller = 1
9 - usessd = 1
10 - usesvt = 1
11 - activetpc = 1
12 - usetpc = 1
And then Sti output
StiMaker::Init() -I- Adding detector group:Ssd
StiDetectorBuilder::StiDetectorBuilder() - INFO - Instantiating builder named:Ssd
StiDefaultToolkit::add() -I- Not adding hit loader for detector group:SSD
StiDefaultToolkit::add() -I- Adding builder for detector group:SSD
StiMaker::Init() -I- Adding detector group:PIXEL
StiDetectorBuilder::StiDetectorBuilder() - INFO - Instantiating builder named:Pixel
StiDefaultToolkit::add() -I- Adding hit loader for detector group:Pixel
StiDefaultToolkit::add() -I- Adding builder for detector group:Pixel
StiMaker::Init() -I- Adding detector group:Ist
StiDetectorBuilder::StiDetectorBuilder() - INFO - Instantiating builder named:Ist
StiDefaultToolkit::add() -I- Adding hit loader for detector group:Ist
StiDefaultToolkit::add() -I- Adding builder for detector group:Ist
The SSD detector is still loaded with the name now "SSD" (not SST).
With the modified StiMaker (don't set the usessd and usesvt by default in constructor) with the same chain shows it does the job. See the job file
/star/u/dongx/lbl/hft/Run14/Sti_Test/Sti_05092014/Test_SSDSVT/Modified_StiMaker/test_NoSst.log
3) With the current chain, to disable the SSD geometry, in addition to "-SstIT", one has to add "NoSsdIT". But the Sti Attr parameters seem a bit confusing too.
I have two test log files
a) /star/u/dongx/lbl/hft/Run14/Sti_Test/Sti_05092014/Test_SSDSVT/test_NoSsdSvt.log
"P2014a,btof,BEmcChkStat,Corr4,OSpaceZ2,OGridLeak3D,-hitfilt,NoSsdIt,NoSvtIt"
1 - activesst = 1
2 - usesst = 1
3 - activeist = 1
4 - useist = 1
5 - activepixel = 1
6 - usepixel = 1
7 - usesvt = 0
8 - alignment = 0
9 - usevertexfinder = 1
10 - usetracker = 1
11 - useeventfiller = 1
12 - usessd = 1
13 - usesvt = 1
14 - activetpc = 1
15 - usetpc = 1
I don't understand line 13. Seems to reset the usesvt again with some default setting.
The Sti detector loader shows SSD detector is still loaded.
b) /star/u/dongx/lbl/hft/Run14/Sti_Test/Sti_05092014/Test_SSDSVT/test_NoSsdSvt_NoSst.log
"P2014a,btof,BEmcChkStat,Corr4,OSpaceZ2,OGridLeak3D,-hitfilt,NoSsdIt,NoSvtIt,-SstIT"
Similarly I don't understand
1 - activeist = 1
2 - useist = 1
3 - activepixel = 1
4 - usepixel = 1
5 - usessd = 0
6 - usesvt = 0
7 - alignment = 0
8 - usevertexfinder = 1
9 - usetracker = 1
10 - useeventfiller = 1
11 - usessd = 1
12 - usesvt = 1
13 - activetpc = 1
14 - usetpc = 1
line 11 and 12 with conflict to line 5 and 6. But later when I check Sti detector loader, no SSD or SST named detector is created.
===============
Created on March 28
===============
Dmitri Smirnov has nicely kept all the latest updates in terms of the HFT software development while they are being reviewed and committed in the following area
$CVSROOT/offline/hft/
The README.md file in that directory instructs you how to setup the full running environment with HFT software.
Out of these software, one of them is the Sti tracking related code. The original source codes were long being built in the area $CVSROOT/StRoot/StiRnD and it has been used extensively for the HFT proposal and CDR simulations. Dmitri has taken out these codes out of the "R&D"-like area and move to production directories, namely, $CVSROOT/StRoot/StiPxl, StiIst. One more key development is to complete all the geometry definitions in these tracking software.
One modification Dmitri made to the StiPixelDetectorBuilder is to define active detectors for each sensor separately, while in the old approach, we grouped the whole ladder into one single volume (StiIst still inheritates from the old approach using the single ladder as one volume). By testing with some simulation data, I observe some issues with the new StiPxl.
| Simu. event display with StiPxl/StiIst |
Simu. event display with StiRnD |
 |
 |
The lines show the reconstructed tracks. While dots are the measured PXL/IST hits, while yellow dots indicate whether the hits are picked up by the track in Sti or not. They are the same as the white ones if got picked up, but I slightly shift the positions for visibility.
One clearly sees in the left figure with the StiPxl, almost no track can pick up any PXL hits. While in the right figure with the StiRnD/Hft, the PXL hits are nicely picked up by the tracking.
To reproduce this, please find the source codes here (these were also built from the $CVSROOT/offline/hft)
With StiPxl/StiIst
/star/u/dongx/lbl/hft/Run14/Simu/runBFC.sh
and with StiRnD
/star/u/dongx/lbl/hft/Run14/Simu/old_StiRnD/runBFC.sh
One suspicous after looking into a bit the Sti code is that Sti use a hit-vector map to make the correspondences between hits and detectors, while the detectors are identified based on the refAngle and radius (both are in the x-y plan). Thus in the new StiPxl approach which separates all individual sensors (same x-y position, but different in z), I am not sure how the system can recognize which are the hits belong to a certain sensor. Need experts' comments and find a fix to this.
