GSI Forum: Bugs, Fixes, Releases » Reconstruction macro crush - PndMCTrackAssociator

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » Reconstruction macro crush - PndMCTrackAssociator

Show: Today's Messages :: Polls :: Message Navigator

Reconstruction macro crush - PndMCTrackAssociator [message #11873]

Tue, 24 May 2011 12:18

Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...

first-grade participant

From: *fuw.edu.pl

Dear colleagues,

Running reconstruction macro for eta_c analysis with STT I observe the crush from PndMCTrackAssociator.

I run macros from /macro/run/tdrct/eta_c

run_sim_stt_evt.C(2000,seed)
run_digi_stt_evt.C
run_reco_stt_evt.C

The last macro depending on the seed in 60% of cases produce the crush.

For example with seed=101

This macro for eta_c reconstruction with STT is based on the corresponding macro in npipi directory and probably this task (PndMCTrackAssociator) is not necessary here (at least I do not use its results at the moment).

But the may be somebody have an idea how to remove this crush.

Dima

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11874 is a reply to message #11873]

Tue, 24 May 2011 19:04

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

Hi,
I was able to reproduce some error, I am not sure if this was yours. However it seems there was a small bug in mvd code that now is fixed (thanks to Ralf).
Could you please update and try again?

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11895 is a reply to message #11873]

Thu, 26 May 2011 12:24

Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...

first-grade participant

From: *fuw.edu.pl

Hi,

After update by Ralf the problem with PndMCTrackAssociator is improved but not disappeared completely.

As I have written in my first post, I run the following macros
from /macro/run/tdrct/eta_c

run_sim_stt_evt.C(2000,seed)
run_digi_stt_evt.C
run_reco_stt_evt.C

Initially I run with 10 different seeds 101-110. In 6 out of 10 cases PndMCTrackAssociator crashed.

After update the crash appears in 2 out of 10 runs. In one case (seed=109) at the same events but with slightly different log message from MVD.

So at the beginning it was

And after update:

And for the seed=106 reconstruction crashed at different event

Dima

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11902 is a reply to message #11895]

Thu, 26 May 2011 15:56

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

Hi Dima,
there is something that I do not understand.
In your log you have:

mvd hit 0 12 does not exist

do you have such messages in other parts of the code?
I have run again the procedure but for me it does not crash, and I cannot see such messages.

If I have understood well, the problem comes from some wrong MVD index inside the PndTrackCand, filled by the STT tracking tasks. I supposed the MVD fix would have solved them, but this is not the case.
Do you have updated everything from the trunk, and launched the simulation from scratch? I do not want that using some parts of the previous files you are falling again in an error already fixed.

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11903 is a reply to message #11873]

Thu, 26 May 2011 16:22

Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...

first-grade participant

From: *fuw.edu.pl

Hi Stefano,

such messages

Quote:

mvd hit 0 12 does not exist

appear only before the crash.

And I have updated everything from the trunk, but rerun not from the simulation but from the digitization level.
I expected it's sufficient but will try once again from scratch and let you know about results.

By the way I run my macros on GSI batch farm and I would expect that running the code there with the same seeds crush should be reproducible.

Dima

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11905 is a reply to message #11903]

Thu, 26 May 2011 17:20

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

hi,
this is what I am trying to do, on a lenny64 machine.
However, I think it is a problem of the SttMvd tracking, or maybe of the mvdriemann itself.

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11907 is a reply to message #11873]

Thu, 26 May 2011 17:44

Ralf Kliemt
Messages: 507
Registered: May 2007
Location: GSI, Darmstadt

first-grade participant

From: *pool.mediaWays.net

Hi guys.

The issue "mvd hit 0 12 does not exist" occurs in the PndSttMvdGemTracking.
I digged a bit in my own code and found a serious issue. The "Detector ID".
What is it now?

Any suiting Number from that PndDetectorList.h, like kMVD?
Any suiting Number from that PndDetectorList.h, like kMVDDigiStrip?
The Branch Id from FairRootManager::Instance()->GetBranchId()?

When clear, I'll apply all Mvd related detID entries to that thing. Right now There is a mismatch between the meaning in the mvd code and the tracking.

Kind Regards.
Ralf

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11908 is a reply to message #11907]

Thu, 26 May 2011 17:49

Tobias Stockmanns
Messages: 489
Registered: May 2007

first-grade participant

From: *ikp.kfa-juelich.de

Dear pandaRooters,

I strongly suggest to use the BranchID from FairRootManager.

Cheers,

Tobias

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11909 is a reply to message #11907]

Thu, 26 May 2011 17:54

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

The answer is:

c: The Branch Id from FairRootManager::Instance()->GetBranchId()

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11910 is a reply to message #11909]

Thu, 26 May 2011 18:41

Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino

first-grade participant

From: *pv.infn.it

Hi all,
I know the line "mvd hit 0 12 does not exist" comes from PndSttMvdGemTracking, but in that occasion it just reads the list of hits collected in the SttMvdTrackCand and checks whether each hit is an mvd or stt hit.
I confirm it makes the check via detId = FairRootManager::Instance()->GetBranchId() and I know that also in PndSttMvdTracking the detId is assigned that way.
So, could it be that one specific hit is not assigned properly to the SttMvdTrackCand?
I did not have the time to check it yet, but I think the quickest thing to do is a macro which loops over the SttMvdTrackCand and from each of them takes the hits and checks whether they exist in their own TCA.

I have a question, did anyone try to apply the MCTrackAssociator directly to the MvdTracks or to the SttMvdTracks? This should clarify which task creates the problem...

Cheers,
Lia.

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11911 is a reply to message #11910]

Thu, 26 May 2011 19:14

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

Hi,
unfortunately only Dima has such problem. have you tried in an interactive machine?
I have tried with a lenny64, seed # 109, but I cannot reproduce this crash... I have no idea.
Maybe Dima can try as suggested by Lia, but my fear (again) is that some trackcandhit is messed.

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11913 is a reply to message #11873]

Fri, 27 May 2011 10:13

Ralf Kliemt
Messages: 507
Registered: May 2007
Location: GSI, Darmstadt

first-grade participant

From: *cb.uni-bonn.de

Hi Dima,

I was looking inside the code and did not find a cause for your problem.
So I ask you to check carefully your pandaroot installation (svn diff, revert changes you have except your own development, removing the build files and recompile from scratch). I expect you did that anyway x times while searching for a fix.

Another thing: When I switch the detID to be the TClonesArray's ID It will should be the removal of all kMVD... things in the data type list. There is some code still using it, so I'll have to go into some trouble getting it right there, too.
Opinions?

Ralf.

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11914 is a reply to message #11913]

Fri, 27 May 2011 10:35

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

Hi,
we are starting right now the digitization procedure. If at present the digi code gives problems, then the fix should be done as soon as possible. If it is just a matter of restyling, i would propose to postpone it.

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11919 is a reply to message #11873]

Fri, 27 May 2011 12:37

Ralf Kliemt
Messages: 507
Registered: May 2007
Location: GSI, Darmstadt

first-grade participant

From: *cb.uni-bonn.de

Hi.
Just a comment. When we store that Branch ID and use it later we have to take care that all files are loaded again. Furthermore, I think we even have to take care to load the branches in the same order again. So when registering a TCA, but not putting it to a file will make problems here.

Ralf

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11920 is a reply to message #11911]

Fri, 27 May 2011 12:42

Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino

first-grade participant

From: *pv.infn.it

Hi,
I prepared a macro (attached to this message) to test the PR as I said before, so that we can understand if (and where) there is a wrong hitid in a track candidate.

Please, Dima, can you run the macro on your files (changing the file names accordingly to yours) and on the different TCAs of PndTrack which come out from the various pattern recognitions?
At the moment it is set to work for evt_***_stt.root files (digi/reco) and for SttMvdTrack.

I hope this can help finding the problem,
Lia.

Attachment: checkPR.C
(Size: 2.93KB, Downloaded 331 times)

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11921 is a reply to message #11919]

Fri, 27 May 2011 12:45

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

According to Mohammad and Tobias we should not have such problems.
I ask for confirmation.

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11924 is a reply to message #11921]

Fri, 27 May 2011 13:40

Tobias Stockmanns
Messages: 489
Registered: May 2007

first-grade participant

From: *eduroam.ruhr-uni-bochum.de

Hi pandaRooters,

the Branch Id does not depend on the order of file loading or if the file is loaded at all. This Id is stored in each file header containing the Id's of all branches generated before.

Cheers,

Tobias

Report message to a moderator

Re: Reconstruction macro crush - PndMCTrackAssociator [message #11937 is a reply to message #11873]

Sun, 29 May 2011 08:52

Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...

first-grade participant

From: *play-internet.pl

Dear colleagues,

After updating to svn rev. 12110 and running again 10 runs by 2000 events I cannot reproduce this crash anymore.

So the problem disappeared, however I do not understand at which step exactly.

However, thanks to everybody participating in debugging.

Dima

Report message to a moderator

Previous Topic:	TPC digitization for more than 1000 events
Next Topic:	Question about geometryversion for EMC

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

PDF

]

Current Time: Sun Dec 01 02:05:29 CET 2024

Total time taken to generate the page: 0.00762 seconds