Home » PANDA » PandaRoot » Bugs, Fixes, Releases » TPC digitization blocks everything for too many cluster events
 TPC digitization blocks everything for too many cluster events [message #10769] |
Thu, 03 June 2010 22:04  |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *54-82-r.retail.telecomitalia.it
|
|
Dear all,
I have noticed, producing many events with different momentum values, that sometimes the digi macro persists on some well defined events even for tenth of minutes!
In particular, the detector which is "blocking" the digitization is the TPC.
This is a sample of "blocking" event, produced when I was trying to simulate one single pion events from 0.5 to 4 GeV/c:
PndTpcClusterizer:: 20278 clusters created
41409 electrons arriving at readout
Aggregating drifted electrons into avalanches finished.
41409 Avalanches created
0 aggregations done.
77354 Signals created
PndTpcElectronicsTask::Exec
Building up padmap ...finished. 317 pads hit
........
After 20 minutes it is still blocked at the same event. This happens also many times... in this particular case 20278 clusters created, 41409 avalanches.
I copy a "normal" TPC event:
PndTpcClusterizer:: 674 clusters created
1214 electrons arriving at readout
Aggregating drifted electrons into avalanches finished.
1214 Avalanches created
0 aggregations done.
2260 Signals created
PndTpcElectronicsTask::Exec
Building up padmap ...finished. 287 pads hit
...........
166 Digis created
In this case "only" 674 clusters. Digitization time... less than 1 second.
I can understand that for large events the required digitization time is high, but 20 minutes are really too much, I think. I am not sure if, at the end, we will be able to analyse them or they will be simply too much noisy. In the latter case, maybe a rejection of events with a too high number of clusters/avalanche in tpc could help making the digitization a bit faster, without losing too much signal. Or maybe sometimes the code enters inside a too alrge loop that could be optimized, I don't now.
I would call for comments from the TPC experts.
|
|
|
|
|
|
|
|
| Re: TPC digitization blocks everything for too many cluster events [message #10778 is a reply to message #10776] |
Mon, 07 June 2010 16:05  |
Malgorzata Gumberidze
Messages: 98
Registered: June 2005
|
continuous participant |
From: *in2p3.fr
|
|
I have the same problem as Stefano.
I'm using pandaroot revision 8473 for my simulation.
What i do is to simulate with pgun electrons with the
momenta 0-5GeV/c. I'm running 10k events. Simulations get block
at the event 1201, and it take a lot of time, till it pass
problematic event. I'm already waiting 20 minutes.
this is a last print out which i get:
***************** PndEmcMakeBump, event: 1201 **************
Digi at (66, 68) was a local max. Energy = 1.46065
EMC header: fired crystals= 26, digi= 15, Total energy= 1.66663 [GeV],
Reconstructed clusters= 3, Total energy in clusters= 1.65603 [GeV]
-I- PndTofHitProducerIdeal: 2 TofPoints, 2 Hits created.
-I- PndTofHitProducerIdeal: 0 SciFTofPoints, 0 sciF Hits created.
PndTpcClusterizer:: 26737 clusters created
51323 electrons arriving at readout
Aggregating drifted electrons into avalanches finished.
51323 Avalanches created
0 aggregations done.
103810 Signals created
PndTpcElectronicsTask::Exec
Building up padmap ...finished. 397 pads hit
Few months ago i was doing the same kind of simulations with the older version of the revision, and i didn't have this kind of problem.
gosia
|
|
|
|
| Re: TPC digitization blocks everything for too many cluster events [message #10782 is a reply to message #10769] |
Tue, 08 June 2010 08:49 |
Jens Sören Lange
Messages: 193
Registered: June 2005
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Hi all,
yes, the same happens not only for pgun, but sometimes for EvtGen generated events, which are "normal" input events (i.e. there is a priori no low momentum particle in the generated event). It means: if these are spiraling tacks, they must originate from Geant.
However, it is not blocked. It is true that it takes a lot of time, but it continues. I had events which needed ~2 hours (same as Gosia, ~30000 clusters or more), but they are always finished. One can also see in the CPU comsumption ("top") that it continues to run.
cheers, Soeren
|
|
|
|
|
|
| Re: TPC digitization blocks everything for too many cluster events [message #10786 is a reply to message #10783] |
Wed, 09 June 2010 08:03 |
Sebastian Neubert
Messages: 282
Registered: March 2006
Location: Munich
|
first-grade participant |
From: *natpool.mwn.de
|
|
Dear colleagues,
there have been a few modifications in the ElectronicsTask (or more correctly in the components it uses) that have been introduced while we were studying the real data from our test-chamber. If the problem has appeared after these modifications then one should look into the PulseShapeAnalysis or the ClusterFinder.
Obviously there are several options to circumvent the problem but I would strongly suggest to cut out "bad" events (with a lot of primary clusters from a spiraling particle) since in fact they will be reconstructable most of the time. So this is only an option if you need a fast simulation and do not plan to study any efficiencies!
I will look into the digitization if I find a bug there but it might take some time. In the meantime it would be helpful if you could turn on all digitization output for the tpc (SetPersistence for all tasks, plus SetSamplePersistence for the ElectronicsTask) and plot the Signal amplitudes, Sample amplitudes and Digi amplitudes (A few events are enough) Maybe we can tune some cuts there.
Cheers! Sebastian.
Sebastian Neubert
Technische Universität München
Department Physik E18
sneubert@e18.physik.tu-muenchen.de
tel: +49-8928912592
[Updated on: Wed, 09 June 2010 08:03] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: TPC digitization blocks everything for too many cluster events [message #10815 is a reply to message #10789] |
Tue, 22 June 2010 19:08 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
Dear all,
I think I have found the guilty guy. Which is not tpc digitization, not exactly.
Putting some thousands of cout in PndTpcElectronicTask::Exec, I have found that the code stucks at the following line:
dig->SetLinks(FairMultiLinkedData(kTpcSignal, sigIdMap[padIt->first]));
Now we have understood why the problem was not appearing before: becuase it is related to the new fairlink propagation! If I comment out this line, the code is slow for the "heavy" events, but it is processed in a "reasonable" amount if time...
I have taken my wonderful 5533 event, it took 24 hours with FairLink line, 1 minute without....
I suppose there is something bad in the linking procedure for tpc, for large events, maybe because the too many objects to handle.
Another slow line, but two orders of magnitude faster than the link line, is the following:
PndTpcDigitizationPolicy().Digitize(sv,&samplelist,ffrontend,fpulseshape);
The code is stucked there for the guilty event, but just for 10 seconds per iteration of the padmap. I am not sure if this is a "feature" or if this could be optimized somehow, I leave the word to digitization experts.
About the SetLinks, I would suggest for the moment to comment out the line, in order to make the digit faster. If somebody wants to check the guilty event, just send me a mail and I could give him the path at GSI where to get a root file with... many problems.
Regards
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: TPC digitization blocks everything for too many cluster events [message #10829 is a reply to message #10828] |
Thu, 24 June 2010 13:06 |
Tobias Stockmanns
Messages: 489
Registered: May 2007
|
first-grade participant |
From: *ikp.kfa-juelich.de
|
|
Dear colleagues,
I have studied the FairLink problem in more detail. The problem is the enormous amount of data created for the TPC. For one special event it has: 19281 PrimäriClusters, 42958 Drifted Electrons, 42958 Avalanches, 80300 Signals and 1,674,929 Digis.
All this objects have links to the previous one. I could speed up the linking by a factor of 2 by using std::set instead of std::vector. Nevertheless this one event takes 500 s on my PC. I think that for the TPC one should bypass the linking and only connect the TpcClusters with the MC points and only for dedicated studies one switches on linking.
Cheers,
Tobias
|
|
|
|
Goto Forum:
Current Time: Tue Nov 26 00:27:20 CET 2024
Total time taken to generate the page: 0.00707 seconds
|
GSI Forum
Search
Help
Members
Login
Home
