- genevb's home page
- Posts
- 2024
- 2023
- 2022
- September (1)
- 2021
- 2020
- 2019
- 2018
- 2017
- December (1)
- October (3)
- September (1)
- August (1)
- July (2)
- June (2)
- April (2)
- March (2)
- February (1)
- 2016
- November (2)
- September (1)
- August (2)
- July (1)
- June (2)
- May (2)
- April (1)
- March (5)
- February (2)
- January (1)
- 2015
- December (1)
- October (1)
- September (2)
- June (1)
- May (2)
- April (2)
- March (3)
- February (1)
- January (3)
- 2014
- 2013
- 2012
- 2011
- January (3)
- 2010
- February (4)
- 2009
- 2008
- 2005
- October (1)
- My blog
- Post new blog entry
- All blogs
New TPC alignment impact on reconstruction speed
Updated on Wed, 2024-10-30 09:58. Originally created by genevb on 2024-10-29 23:46.
The new TPC alignment, as provided in PR#702, needs two items:
As part of a study for modifying vertex-finding for FXT data, I first processed some data in DEV, then I was asked to process it with the new alignment. This I only partly did at first, using the new code library but old BFC chain. After realizing this mistake, I processed again using the new code library with the new BFC chain option. This allowed me to compare the reconstruction speed difference due to the two items separately. My findings, using over 40k events from the production_4p59GeV_fixedTarget_2019 dataset are evident in the following plots:
Smaller sets of events were tried more than once to ensure reproducibility, and all direct comparisons were run on the same node at the same time to ensure comparability.
Looking at the end of the log files where time spent in individual makers in the BFC chain is presented, it is clear that the increased time for the new alignment is predominantly from the tracking ("Sti"), nearly doubling from 32777 CPU-seconds (47.5% of the full chain) in SL24y with the old chain to 63015 CPU-seconds (62.6% of the full chain) in SL24y with the new chain. At this time, it is not obvious to me why the new alignment affects tracking speed so significantly.
I believe this impact on reconstruction speed was a contributing factor to why the new TPC alignment test production conducting in a TFG library this past summer saw jobs take longer than the 3-day queue limit at SDCC. The 3-day queue limit never affected prior official BES-II data productions, but a closer look will be needed for any production with this new TPC alignment.
An important question is whether other iTPC era datasets than FXT may be impacted. I processed 200 Run 22 pp500 events to study this and obtained the following results, which show behavior consistent with the above FXT findings: the new library is a few percent slower, and the new alignment is roughly x1.5 slower. Also, the slow-down is again predominantly a near-doubling of the time spent in tracking ("Sti").
Importantly, this slow-down will have a big impact on my earlier Run 22 pp500 production estimates - more streams.
-Gene
- A new code library, built currently as SL24y
- A new BFC chain option, "CorrZ"
As part of a study for modifying vertex-finding for FXT data, I first processed some data in DEV, then I was asked to process it with the new alignment. This I only partly did at first, using the new code library but old BFC chain. After realizing this mistake, I processed again using the new code library with the new BFC chain option. This allowed me to compare the reconstruction speed difference due to the two items separately. My findings, using over 40k events from the production_4p59GeV_fixedTarget_2019 dataset are evident in the following plots:
- Left: using the old BFC chain, time per event [seconds] in SL24y vs. DEV (black points are individual events [excluding the first], and red points are a profile)
- Middle: using SL24y, time per event [seconds] with the new alignment BFC chain option vs. the old chain
- Right: profiles of the previous two plots (library comparison in blue, alignment comparison in red) with linear fits, giving slopes of 1.027 and 1.500 respectively
Smaller sets of events were tried more than once to ensure reproducibility, and all direct comparisons were run on the same node at the same time to ensure comparability.
Looking at the end of the log files where time spent in individual makers in the BFC chain is presented, it is clear that the increased time for the new alignment is predominantly from the tracking ("Sti"), nearly doubling from 32777 CPU-seconds (47.5% of the full chain) in SL24y with the old chain to 63015 CPU-seconds (62.6% of the full chain) in SL24y with the new chain. At this time, it is not obvious to me why the new alignment affects tracking speed so significantly.
I believe this impact on reconstruction speed was a contributing factor to why the new TPC alignment test production conducting in a TFG library this past summer saw jobs take longer than the 3-day queue limit at SDCC. The 3-day queue limit never affected prior official BES-II data productions, but a closer look will be needed for any production with this new TPC alignment.
An important question is whether other iTPC era datasets than FXT may be impacted. I processed 200 Run 22 pp500 events to study this and obtained the following results, which show behavior consistent with the above FXT findings: the new library is a few percent slower, and the new alignment is roughly x1.5 slower. Also, the slow-down is again predominantly a near-doubling of the time spent in tracking ("Sti").
Importantly, this slow-down will have a big impact on my earlier Run 22 pp500 production estimates - more streams.
-Gene
»
- genevb's blog
- Login or register to post comments