Home » PANDA » PandaRoot » Bugs, Fixes, Releases » PndSttHitProducerRealFast() depends on event type?
| PndSttHitProducerRealFast() depends on event type? [message #8228] |
Wed, 15 April 2009 16:23  |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *kph.uni-mainz.de
|
|
Dear all,
During the debugging of my code, I found that Stt part was problem in my code.
When I try to use hit provider for STT detector, following class is called to digitize
PndSttHitProducerRealFast* sttHitProducer = new PndSttHitProducerRealFast();
fRun->AddTask(sttHitProducer);
But run is stopped with below message at certain event.
If I don't use this class, I can go to the end.
---------------------------------------------
DIGI EXECUTION *********************
Hit array contains 79 hits
*** Break *** floating point exception
---------------------------------------------
And one more strange thing is that some event can passing through without error.
Here is the output before crashing
---------------------------------------------
DIGI EXECUTION *********************
Hit array contains 107 hits
Event Number 0
caution: wrong drift time
caution: wrong drift time
caution: wrong drift time
caution: wrong drift time
Nr of Points: 4
-I- PndMvdHybridHitProducer: 4 PndMvdMCPoints, 3 Digi created. 3 (event 0)
-I- PndMvdNoiseProducer: Noise produced 0xStripRect 0xStripTrap 0xPixels
Ideal Hit Producer -Point-: 0xb5d5f50
-I- PndTofHitProducerIdeal: 1 TofPoints, 1 Hits created.
-I- PndTofHitProducerIdeal: 0 SciFTofPoints, 0 sciF Hits created.
---------------------------------------------
So, I assume that STT hit producer give up some calculation. I don't know how they decide it. Could anybody explain how STT class works?
Thank you!
|
|
|
|
| Re: PndSttHitProducerRealFast() depends on event type? [message #8230 is a reply to message #8228] |
Wed, 15 April 2009 18:52  |
|
Anonymous Poster
|
|
From: *pool.einsundeins.de
|
|
Hi,
the floating point exception that happens should be easy to find. Dont you have more output when this crash happens? Usually the ROOT signal handler gives you a stack trace for such situations. If this is not the case by default, just run it in the debugger, i.e.:
gdb root.exe
Simply using root doesnt work, it needs to be root.exe
then inside gdb do (whatever options you usually use for your root call, e.g.)
run -b -q myMacro.C
Then when the crash happened, type
where
and then look more exactly at the frame where it happens (the one before 'signal handler' for example if it where 5) type
fr 5
what do you get? Probably some division be zero.
Cheers, Christian
|
|
|
|
|
|
|
|
|
|
|
|
| Re: PndSttHitProducerRealFast() depends on event type? [message #8237 is a reply to message #8234] |
Thu, 16 April 2009 12:30 |
|
Anonymous Poster
|
|
From: *natpool.mwn.de
|
|
Hi,
I dont find it strange that Lia and Stefano had no problems, but someone using different generators has them. This is to my mind a division by zero problem or similar, and there can be a million reasons, why certain event topologies trigger this problem while others dont.
I think we should try to be a bit more careful in general with numerics. If you write any new code at least, try to avoid divisions by zero.
Cheers, Christian
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: PndSttHitProducerRealFast() depends on event type? [message #8255 is a reply to message #8254] |
Thu, 16 April 2009 23:39 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Lia and all pandaroot experts,
There is no improvement of my understanding, now I'm still confusing for all situation.
Let's considering only in the simulation level.
I prepare two output display in attached file.
I used two different *.geo cases with TOF.
Tof->SetGeometryFileName("tofSciF.geo");
Tof->SetGeometryFileName("tofbarrel.geo");
I didn't touch any other lines.
In 10th event, the run is stuck with tofbarrel.geo.
To see what here is happen, all messages are printed with gdb mode in the case of using tofbarrel.geo.
One more strange thing is...
If I try to use DIRC detector or dipole field, which is suggested
in the tutorial run_sim_tpccombi_pgun.C,
at the second or fouth event run was also broken.
I doubt whether I have recent pandaroot version, and pandaroot is working
in my laptop with ubuntu operation.
Or probably, christian hoeppner already pointed out, there is related on the event topology. Such case, other person must report same problem. But it's not until now.
Best regards,
Donghee Kang
[Updated on: Fri, 17 April 2009 00:22] Report message to a moderator |
|
|
|
|
|
|
|
| Re: PndSttHitProducerRealFast() depends on event type? [message #8622 is a reply to message #8228] |
Sat, 23 May 2009 16:41 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear all,
I would like to conclude my problem for STT class in pandaroot.
If you have some idea and suggestion, it would be very helpful.
I want to change TPC to STT mode, since the STT is planned to install as default detector system for central tracking.
Now, I explain again what my problem is for STT study.
In order to use STT detector I have introduced below line with correct geo metry in my Simulation "run" code, which you can also find in attached file, the name is test_run.C, To simply no interesting part took out, only STT part is used.
| Quote: |
FairDetector *Stt= new PndStt("STT", kTRUE);
Stt->SetGeometryFileName("straws_skewed_blocks_35cm_pipe.geo");
fRun->AddModule(Stt);
|
Then, I'm going to digi tasks with following line
| Quote: |
// ----- STT analysis tasks --------------------------------------------
PndSttHitProducerRealFast* sttHitProducer = new PndSttHitProducerRealFast();
fRun->AddTask(sttHitProducer);
// trackfinding ....
PndSttTrackFinderIdeal* sttTrackFinder = new PndSttTrackFinderIdeal(1);
PndSttFindTracks* sttFindTracks = new PndSttFindTracks("Track Finder", "FairTask", sttTrackFinder, 1);
sttFindTracks->AddHitCollectionName("STTHit", "STTPoint");
fRun->AddTask(sttFindTracks);
|
In this stage, the stt track finder cannot perform the tracking from porduced hit.
If you try to run test_digi.C, you can clearly see why the digitization is stopped.
This is not correlated geometry, because I exclude all other detector component to make a debug.
The problem is purely trackfinding of STT for my special event.
If I use this code with box generator, all process including run and digi can pass through at the end.
If I use TPC, the event can be reconstructed with TPC detectors.
Few event give some reasonable return values, for example,
| Quote: |
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 53
MCTracks: total 5, accepted 2, reconstructable: 2
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
-I- PndSttHitProducerIdeal: 5 SttPoints, 5 Hits created.
|
You can also check this number from test_digi.C file at first and second event.
I want to know that if PndSttTrackFinderIdeal.cxx code check hit threshold or true MC information, or if they don't find some expected number, do they return stop signal?
Also, I assume that STT class return the floating exception, when there are not enough hits, thus they give up some kind of difficult tracking.
STT expert can give more infomation, when they can fail to calucalte in the PndSttTrackFinderIdeal.cxx code.
I'm so sorry for inconvenient discussion.
This is my working environment.
Pandaroot v5476
Event : exclusive compton scattering with three outgoing particle (electron, photon, proton)
-
Attachment: test_digi.C
(Size: 2.88KB, Downloaded 268 times)
-
Attachment: test_run.C
(Size: 2.80KB, Downloaded 277 times)
-
Attachment: test_3.txt
(Size: 62.50KB, Downloaded 314 times)
|
|
|
|
|
|
|
|
| Re: PndSttHitProducerRealFast() depends on event type? [message #8675 is a reply to message #8622] |
Tue, 26 May 2009 17:03 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *47-151.net24.it
|
|
Hi,
I ran your macros: they both run to the end without problems.
Did you see also some crash of the code or is it just a matter of the results?
Concerning the ouput, here is what I get:
Event Number 0
-I- PndSttTrackFinderIdeal: STTTrack 0 created from MCTrack 3 (3 STTPoints)
-I- PndSttTrackFinderIdeal: STTTrack 1 created from MCTrack 4 (3 STTPoints)
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 53
MCTracks: total 5, accepted 2, reconstructable: 2
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 1
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 5
MCTracks: total 6, accepted 0, reconstructable: 0
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 2
-I- PndSttTrackFinderIdeal: STTTrack 0 created from MCTrack 0 (3 STTPoints)
-I- PndSttTrackFinderIdeal: STTTrack 1 created from MCTrack 3 (3 STTPoints)
-I- PndSttTrackFinderIdeal: STTTrack 2 created from MCTrack 4 (3 STTPoints)
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 56
MCTracks: total 5, accepted 3, reconstructable: 3
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 3
-I- PndSttTrackFinderIdeal: STTTrack 0 created from MCTrack 0 (3 STTPoints)
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 26
MCTracks: total 3, accepted 1, reconstructable: 1
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 4
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 7
MCTracks: total 8, accepted 0, reconstructable: 0
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 5
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 1
MCTracks: total 3, accepted 0, reconstructable: 0
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 6
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 0
MCTracks: total 3, accepted 0, reconstructable: 0
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 7
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 0
MCTracks: total 3, accepted 0, reconstructable: 0
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 8
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 5
MCTracks: total 5, accepted 0, reconstructable: 0
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
-------------------------------------------------------
Event Number 9
-------------------------------------------------------
-I- Ideal STT track finding -I-
Hits: 1
MCTracks: total 3, accepted 0, reconstructable: 0
SttHits not found : 0
SttPoints not found : 0
MCTracks not found : 0
SttTracks not found : 0
So basically I see it can reconstruct: 2 tracks in evt 0, 3 tracks in evt 2 and 1 track in evt 3.
I checked the number of hits per track in the simulation stage and what I get is:
evt 0 track 4 hits 27
evt 0 track 3 hits 26
evt 1 track 0 hits 3
evt 1 track 5 hits 2
evt 2 track 4 hits 27
evt 2 track 3 hits 25
evt 2 track 0 hits 4
evt 3 track 0 hits 26
evt 4 track 7 hits 7
evt 5 track 0 hits 1
evt 8 track 4 hits 3
evt 8 track 3 hits 2
evt 9 track 0 hits 1
I looked into the PndSttTrackFinderIdeal and I found that there is actually a cut for tracks with less than 3 hits, so we expect the finder to reconstruct only the blue colored lines in the above list, which correspond to the events and number of tracks the track finder was actually able to reconstruct, except for the event number 4 (I have to understand it, because I see several hits in the same tube and this is strange, since we register an hit each time the particles leaves the volume, so a track should leave only one hit in each tube, with an entrance and en exit position... I will investigate this).
The problem I see is that there are too few hits in the stt to construct a track (even if we throw away the cut on the number of hits, the helix construction will fail) and I think this is due to the particular kind of events (this would also explain why everything runs fine with the box generator).
Can you try to generate particles only in the transverse plane for example, in such a way that they enter the stt and leave more hits? In this case everything should run fine.
Please let me know if there are still problems or if I didn' t answer properly to your questions.
Best regards,
Lia.
-
Attachment: numhits.C
(Size: 1.47KB, Downloaded 246 times)
|
|
|
|
Goto Forum:
Current Time: Fri Sep 13 11:03:19 CEST 2024
Total time taken to generate the page: 0.00965 seconds
|
GSI Forum
Search
Help
Members
Login
Home
