Physics channel analysis for tracking TDR [message #11721] |
Wed, 27 April 2011 18:24 |
Dima Melnychuk
Messages: 213 Registered: April 2004 Location: National Centre for Nucle...
|
first-grade participant |
From: *fuw.edu.pl
|
|
Dear colleagues,
I have several technical questions related to physics channel analysis for tracking TDR which I would like to discuss.
1.Macros for physics channels simulation.
Stefano proposed the location for tracking TDR macros /macro/run/tdrct, where at the moment there are macro of simulation of DPM background for both CT options. I suppose macros for generation of physics channels should be placed here, but should it be one macro for all channels with generated particle and .dec file for EvtGen as input parameters or separate macro for each channel? I prefer second option, but it will increase the number of additional files from 2 to 8 (assuming 4 physics channels).
2. Number of generated events.
I do not know if it was decided how many events for each physics channel should be simulated. And here I would like to touch the question of time needed for pattern recognition for fully mixed event in TPC. As Felix mentioned pattern recognition for one fully mixed event, i.e 1 physics event + 1000 background event is about half an hour. With 10000 physics event for one channel it will take around 200 day/CPU. With average number of running jobs from DC4 equal 110 (http://panda-wiki.gsi.de/cgi-bin/view/Computing/DataChallenge4) it will take 2 days per physics channel, which I find reasonable. But in this case it will require 10M DPM events for each physics channel, if DPM events are not reused.
For STT case with this number of physics event the number of required DPM events is much lower.
In my opinion this number of physics events should be sufficient if there will not be significant drop of efficiency due to missing forward tracker. So usage of the fast tracking for the forward tracker proposed by Ralf is favourable from this point of view.
3. Background for physics channels.
As it was discussed on the last collaboration meeting, due to missing PID code it does not make sense to study suppression of dedicated background channels, where PID is essential. However, since generic DPM background will be available anyway, I think it make sense to study suppression of this background with simple selection criteria as number of tracks, mass windows and probably 4C-fit probability. But for such a background the reconstruction with event mixing is too CPU consuming, so I suppose the simplified reconstruction chain without event mixing should be used. But if this idea is supported it's up to sub-detector experts to provide two separate reconstruction macros with/without event mixing.
So any opinions?
Dima
|
|
|
Re: Physics channel analysis for tracking TDR [message #11722 is a reply to message #11721] |
Thu, 28 April 2011 12:31 |
StefanoSpataro
Messages: 2736 Registered: June 2005 Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
Hi DIma,
I try to answer you somehow.
Dima Melnychuk wrote on Wed, 27 April 2011 18:24 |
1.Macros for physics channels simulation.
Stefano proposed the location for tracking TDR macros /macro/run/tdrct, where at the moment there are macro of simulation of DPM background for both CT options. I suppose macros for generation of physics channels should be placed here, but should it be one macro for all channels with generated particle and .dec file for EvtGen as input parameters or separate macro for each channel? I prefer second option, but it will increase the number of additional files from 2 to 8 (assuming 4 physics channels).
|
That folder was a starting point. I suppose the best way would be to create 4 separate folders, one for each analysis channel, and put the correlated macros there, including also the analysis code.
Quote: |
2. Number of generated events.
I do not know if it was decided how many events for each physics channel should be simulated. And here I would like to touch the question of time needed for pattern recognition for fully mixed event in TPC. As Felix mentioned pattern recognition for one fully mixed event, i.e 1 physics event + 1000 background event is about half an hour. With 10000 physics event for one channel it will take around 200 day/CPU. With average number of running jobs from DC4 equal 110 (http://panda-wiki.gsi.de/cgi-bin/view/Computing/DataChallenge4) it will take 2 days per physics channel, which I find reasonable. But in this case it will require 10M DPM events for each physics channel, if DPM events are not reused.
For STT case with this number of physics event the number of required DPM events is much lower.
|
You are right. Unfortunately I do not have yet the TPC reconstruction code at all (the macros in the tdrct folder have only lhe), therefore I do not have a felling on the disk space required and on the data size.
For sure, half an hour to reconstruct one single event is not affordable on the mid-long run, I supposed the code should be changed, if not we will never be able to analyze the flux of real data.
Quote: |
In my opinion this number of physics events should be sufficient if there will not be significant drop of efficiency due to missing forward tracker. So usage of the fast tracking for the forward tracker proposed by Ralf is favourable from this point of view.
|
Reconstruction will run only after the tracking developers will fix the code. In the meantime we can try to use Ralf code to see if it could help or not. I will add it into the macros.
Quote: |
3. Background for physics channels.
As it was discussed on the last collaboration meeting, due to missing PID code it does not make sense to study suppression of dedicated background channels, where PID is essential. However, since generic DPM background will be available anyway, I think it make sense to study suppression of this background with simple selection criteria as number of tracks, mass windows and probably 4C-fit probability. But for such a background the reconstruction with event mixing is too CPU consuming, so I suppose the simplified reconstruction chain without event mixing should be used. But if this idea is supported it's up to sub-detector experts to provide two separate reconstruction macros with/without event mixing.
|
I think this can be an interesting and important point. I would suggest to rise it during the tracking meeting of this afternoon.
|
|
|