- bouchet's home page
- Posts
- 2016
- 2015
- December (1)
- November (3)
- October (2)
- September (2)
- August (2)
- June (2)
- April (5)
- March (2)
- February (3)
- January (2)
- 2014
- December (2)
- November (2)
- October (3)
- September (2)
- August (3)
- July (1)
- June (3)
- May (6)
- April (6)
- March (1)
- February (2)
- January (1)
- 2013
- December (2)
- November (3)
- October (3)
- September (4)
- August (1)
- July (1)
- May (4)
- April (6)
- March (4)
- February (3)
- 2012
- 2011
- December (2)
- November (2)
- October (4)
- September (1)
- August (2)
- July (6)
- June (2)
- May (3)
- April (3)
- March (2)
- 2010
- 2009
- December (2)
- November (1)
- October (3)
- September (1)
- August (1)
- July (1)
- June (2)
- April (1)
- March (2)
- February (2)
- January (1)
- 2008
- My blog
- Post new blog entry
- All blogs
BFC timing for pixel in AgML
reminder : GEANT tree for the pixel geometry in AgML (PixlGeo4.xml, not yet in CVS)
test : run the BFC chain and compare with a simplified pixel geoemtry (upgr15) the time to make an event
BFC chain is :
run 'bfc.C(1,10,"dev13,AgML,ITTF,Sti,tpcI,TpcRS,TpxRaw,TpxClu,pixFastSim,-ssdfast,VFMCE, McEvent,geant,IdTruth,fzin,StiRnd,PixelIT,-IstIT,NoSvtIt,NoSsdIt,StiPulls,analysis,tags, clearmem,evout,McEvOut,MiniMcMk,McAna,MakeEvent","test.fz") > log_gdb'
note : there may be useless option for a first test (mcana, minimcmk, root files out)
chain a : detailed pixel + new beam pipe (PipeGeov1.xml) + no SSD + no IST
chain b : simplified pixel + new beam pipe (PipeGeov1.xml) + no SSD + no IST
Both chains used the EVAL library and dev13 geometry
Some details:
- StPixelFastSimMaker, StMcEvent, StiPixelDetectorBuilder have been modified to find the new GEANT hits path
- path chain a : /HALL_1/CAVE_1/IDSM_1/PXMO_1/PXLA_4/LADR_1/PLAC_1
- path chain b : /HALL_1/CAVE_1/IDSM_1/PXMO_1/PXLA_1/PLMI_6/PLAC_1
- The simplified pixel wasn't in the IDSM in upgr15 ; for the comparsion, I have taken dev13 configuration (so it has the IDSM) and change the .xml file for the PIXEL
note for 3. : upgr15 has 2 layers (with 10 and 30 ladders respectively). The path for :
layer 1 : /HALL_1/CAVE_1/IDSM_1/PXMO_1/PXLA_1/PLMI_[1_10]/PLAC_1
layer 2 : /HALL_1/CAVE_1/IDSM_1/PXMO_1/PXL1_2/PLMI_[1_30]/PLAC_1
- the first event is always the one that takes the more time (CPU and REAL time)
- CPU time is sensibly the same for both chain : ~ 90s for the first event, then ~4s for the next events
- there is an increase in the REAL time for the chain using the detailed PXL (149s) vs. the chain using the simplified PXL (104s)
note : chain a and chain b use 2 different .fz files (but based on the same kumac) : the reason is because as the geometry changes, the hits distribution/GEANT path names will change too.
Another comparison : I've removed most of the printout, move to LOG_INFO so that there is no extra time.
Also the simplified pixel has the same material definition than the detailed :
Material_t map[] = { {"AIR", &_gasMat}, {"SILICON", &_siMat}, {"SILICON", &_hybridMat} };

➩ from this test, it seems that the difference seen for the 1st event between the simplified PXL and detailed PXL comes from the declaration of the additionnal passive silicon material
03/19 :
- Pixel hits Position through the BFC chain.
In the text file, I printed the positions of pixel hits (X,Y,Z) for 1 event containing 1 pion ( dev13 + detailed pixel)
Hits positions are correctly propagated through all the chain : 1) StPixelFastSimMaker (smearing) 2) StiPixelHitLoader 3) StAnalysisMaker
- another test : this time I filled the CPU and REAL time (from StChain.cxx ) in a TTree ; the sample used is 20 events, 10 pions per event. Comments are included in this plot
03/23 :
I tested StiPixelDetectorBuilder when :
- the list of materials is declared before the call of useVMCGeometry()
- the list of materials is declared after the call of useVMCGeometry()
- it was related to bug #2297
From the log files, I do not see any differences in hits position, hits numbers.
- bouchet's blog
- Login or register to post comments