GSI Forum: Analysis » Update Notes

Home » PANDA » PandaRoot » Analysis » Update Notes

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

Update Notes [message #14913]

Tue, 02 July 2013 16:08

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

first-grade participant

From: *gsi.de

Revision 20579:

Changed (hopefully all) the way the B field was retrieved. There should be no hardcoded 2 T anymore.

Ralf

Report message to a moderator

Re: Update Notes [message #14915 is a reply to message #14913]

Tue, 02 July 2013 16:51

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

first-grade participant

From: *gsi.de

Revision 20582:

Moved Truth matching to PndAnalysis. Removed the PndMcTruthMatch class to avoid confusion with the truthmatching before the Analysis stage.

Use it to match also composites and decay trees like:

PndAnalysis* theAnalysis = new PndAnalysis ();
RhoCandidate* cand;
RhoCandList list;
int matchlevel=2; //0-2, default 2
bool verbose=false; //default false
...

//Matching on candidate:
theAnalysis->McTruthMatch(cand);
// OR with more options
theAnalysis->McTruthMatch(cand, matchlevel, verbose);

//Matching a full list (same options as above possible):
theAnalysis->McTruthMatch(list);

Cheers
Ralf

Report message to a moderator

Re: Update Notes [message #14922 is a reply to message #14915]

Wed, 03 July 2013 23:09

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: 2.235.190*

Sorry but I have not well understood.
In order to find the mc match object, after the:

theAnalysis->McTruthMatch(cand);

what should one do? Just use RhoCandidate* GetMcTruth() or something different?

Report message to a moderator

Re: Update Notes [message #14924 is a reply to message #14913]

Thu, 04 July 2013 07:33

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

first-grade participant

From: *gsi.de

Hi Stefano.

Yes.

To explain it in more detail:
Upon the first FillList in one event the MC Truth tree is built and each final state particle (the measurtement) will get the McTruth object assigned.
The McTruthMatch checkes the properties of the Reconstructed particle and the McTruth. Furthermore the intermediate particles form the decay tree (built up with Combine()) are checked, too. The bool value being returned tells if the match was successful. Matching composites will then have a valid McTruth pointer as well.

Ralf

Report message to a moderator

Re: Update Notes [message #15021 is a reply to message #14913]

Thu, 25 July 2013 23:40

Simon Reiter
Messages: 44
Registered: May 2013

continuous participant

From: *dip0.t-ipconnect.de

Hi,

I'm trying to rewrite my macros to trunk and need some changes. But I got to a point I'm not sure about. I'm checking the mother candidate after using McTruthMatch(RhoCandidate). I'm checking for primary pions directly from pbarpsystem (McIdx=0 or PdgCode=88888). But I want to use the code for my dpm background too, so (since rel apr13) there is no pdgcode for the first particle(just the McIdx=-1). Therefore I used GetMcMotherIdx() and checked if it's lower than zero, like this:

int motherId = mctrk[piplus[ipiplus].GetMcIdx()].GetMcMotherIdx();
if(motherId<0 || mctrk[motherId].PdgCode()==88888) {

So my question is now: Is mother set or not for primary pions?

theAnalysis->FillList(mctrk, "McTruth");
theAnalysis->FillList(piplus, "PionLoosePlus",pidalgos);
...
for (Int_t ipiplus=0;ipiplus<piplus.GetLength();++ipiplus){
  if (theAnalysis->McTruthMatch(piplus[ipiplus])){
    pidpiplus.Add(piplus[ipiplus]);
    RhoCandidate *mother = piplus[ipiplus]->TheMother();
    if(!mother || mother->PdgCode()==88888) {     <------------
    truepiplus.Add(piplus[ipiplus]);
  } else {
    falsepiplus.Add(piplus[ipiplus]);
    }
  }
}

Simon

PS: decay is: pbarpsytem ->pi+ pi- ... -> ...

Report message to a moderator

Re: Update Notes [message #15026 is a reply to message #15021]

Fri, 26 July 2013 18:49

Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI

first-grade participant

From: *adsl.alicedsl.de

Hi Simon,

the mc truth of the mother is actually set, but you accessed it incorrect in your example. You should try it with something like the following:

  RhoCandidate *truth  = piplus[ipiplus]->GetMcTruth();  
  RhoCandidate *mother = 0;
  if (truth) mother = truth->TheMother();  // mother from truth object, not from reco candidate!
  if (!mother || mother->PdgCode()==88888) {...}

For the time being the McTruthMatch for decay trees has a bug in the code (after restructuring of rho), which I already identified. Before checking in the fix, I'd like to first talk to Ralf (who has been in vacations this week) on Monday whether it's consistent with his redesing.

Anyway, in your case it should work like shown above I guess.

Best,
Klaus

Report message to a moderator

Re: Update Notes [message #15131 is a reply to message #14913]

Wed, 07 August 2013 23:20

Simon Reiter
Messages: 44
Registered: May 2013

continuous participant

From: *dip0.t-ipconnect.de

Hi Klaus,

I tried it another time to rewrite. This time I didn't used theAnalysis->McTruthMatch(piplus[ipiplus]).
I followed your script part and wrote:

if (piplus[ipiplus]->GetMcTruth()){
 RhoCandidate* motherId = piplus[ipiplus]->GetMcTruth()->TheMother();
 if(motherId && motherId->PdgCode()==88888) { ... }
}

But I'm getting an error for TheMother:

#0  0x00007fa22815844e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fa2280de29e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007fa229031407 in TUnixSystem::StackTrace() () from /home/panda/fairsoft/sep12build/lib/root/libCore.so.5.34
#3  0x00007fa229033ce3 in TUnixSystem::DispatchSignals(ESignals) () from /home/panda/fairsoft/sep12build/lib/root/libCore.so.5.34
#4  <signal handler called>
#5  0x00007fa215bb0a60 in RhoCandidate::TheMother (this=0x8011) at /home/panda/pandaroot/trunk/rho/RhoBase/RhoCandidate.h:267
#6  0x00007fa215b5c808 in G__G__RhoDict_321_0_68 (result7=0x176e9a0, funcname=0x281 <Address 0x281 out of bounds>, libp=0x7fff6c89f730, hash=-85) at /home/panda/pandaroot/trunkbuild/rho/G__RhoDict.cxx:7519
#7  0x00007fa22730d9ab in Cint::G__ExceptionWrapper(int (*)(G__value*, char const*, G__param*, int), G__value*, char*, G__param*, int) () from /home/panda/fairsoft/sep12build/lib/root/libCint.so.5.34
#8  0x00007fa2273202de in G__exec_asm () from /home/panda/fairsoft/sep12build/lib/root/libCint.so.5.34
#9  0x00007fa2273ec4ff in G__exec_loop(char const*, char*, std::list<G__FastAllocString, std::allocator<G__FastAllocString> > const&) [clone .constprop.69] () from /home/panda/fairsoft/sep12build/lib/root/libCint.so.5.34
#10
....

Why can't PandaRoot get the mother candidate after it is checked, that the mctruth candidate is available?
This even happend not in the 1st event!

Best regards
Simon

Report message to a moderator

Re: Update Notes [message #15134 is a reply to message #15131]

Thu, 08 August 2013 11:52

Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI

first-grade participant

From: *gsi.de

Hi Simon,

I had also some similar problem of accessing PdgCode() after 11000 events, althought the pointer to the object was not 0x0. In your error dump the sequence

RhoCandidate::TheMother (this=0x8011)

looks suspicious for me, the pointer looks strange.

Up to now I was not able to identify the bug. Finally I explicitly compared that pointer with something like

RhoCandidate *truth = piplus[ipiplus]->GetMcTruth();
if (truth != (RhoCandidate*)0x8011) ...

as a work around solution. This is really dirty, but you can give it a try, whether it's just this single place, or you get more crashes like this.

Best,
Klaus

Report message to a moderator

Re: Update Notes [message #15161 is a reply to message #14913]

Fri, 09 August 2013 12:26

Simon Reiter
Messages: 44
Registered: May 2013

continuous participant

From: *dip0.t-ipconnect.de

Hi Klaus,

I tried this and got my next error after asking for TheMother():

#5  0x00007fe3db443a60 in RhoCandidate::TheMother (this=0x10011) at /home/panda/pandaroot/trunk/rho/RhoBase/RhoCandidate.h:267

I tried to avod this with the same workaround but it didn't help. I still get the error and can't exclude this pointer..

RhoCandidate* mother = piplus[ipiplus]->GetMcTruth()->TheMother();
if(mother && mother!=(RhoCandidate*)0x10011) {
    if(motherId->PdgCode()==88888) { ... }
}

I'm using 21005 for full simulation.

Best regards
Simon

Report message to a moderator

Re: Update Notes [message #15163 is a reply to message #15161]

Fri, 09 August 2013 13:47

Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI

first-grade participant

From: *gsi.de

Hi Simon,

would it be possible, that you attach your simulation and analysis macros, so that I can try to reproduce your error?

I guess your previous attachment was for apr13.

Best,
Klaus

Report message to a moderator

Re: Update Notes [message #15165 is a reply to message #14913]

Fri, 09 August 2013 14:49

Simon Reiter
Messages: 44
Registered: May 2013

continuous participant

From: *zeu.uni-giessen.de

Hi,

here they are for the trunk. I got this error nearly every job (2000 events). The simulation macros are not the newest from tutorials/rho, but the log files from sim to pid didn't call any errors.

Best regards
Simon

PS: Why is RhoCandidate* TheMother() two times implmented, one normal and one const?

Attachment: macros_trunk.tar.gz
(Size: 20.93KB, Downloaded 215 times)

[Updated on: Fri, 09 August 2013 14:52]

Report message to a moderator

Re: Update Notes [message #15172 is a reply to message #15165]

Fri, 09 August 2013 16:48

Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI

first-grade participant

From: *gsi.de

Hi Simon,

just as a fast feedback, I run your chain for 500 events, and after checking for one 'strange' pointer (0x10011) it was working properly. So it doesn't seem to be a very frequent bug. However I'll take a closer look to this nasty behaviour next week.

Simon Reiter wrote on Fri, 09 August 2013 14:49

PS: Why is RhoCandidate* TheMother() two times implmented, one normal and one const?

Good question, which I would redirect to Ralf. Sometimes you need const input as parameters for other methods, and maybe this const RhoCandidate* TheMother() is to avoid a const_cast inbetween. But that was just guessing...

Best,
Klaus

Report message to a moderator

Re: Update Notes [message #15173 is a reply to message #15172]

Fri, 09 August 2013 21:45

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: 2.235.190*

I have seen this crash after 1400 events... of course it has to be fixed somehow. Maybe some missing initialization in the constructor?

Report message to a moderator

Re: Update Notes [message #15176 is a reply to message #14913]

Sat, 10 August 2013 22:50

Simon Reiter
Messages: 44
Registered: May 2013

continuous participant

From: *dip0.t-ipconnect.de

I simulated now 200 events, 1000 events and 2000 events. In 200 and 1000 I got no errors, in 2000 events I got n error in 5 of 7, after 1400 events, after 1200 events after 1100 events, after 700 events and after 500 events.
Maybe it's because I'm not using the simulation macros out of the tutorial. I used some old ones, a bit modified. Maybe there is the problem.

Additionally I used the simulation macros of tutorials/rho and it worked for 2000 events in 10 of 10 times.

[Updated on: Sun, 11 August 2013 05:42]

Report message to a moderator

Re: Update Notes [message #15177 is a reply to message #14913]

Sat, 10 August 2013 23:07

Simon Reiter
Messages: 44
Registered: May 2013

continuous participant

From: *dip0.t-ipconnect.de

Searched for differences between to tutorial macros and my ones:

Sim-macro: Found fRun->SetStoreTraj(kTRUE); // uncomment that if you want to have points for plotting but that does not seems like the reason.

pid-macro and digi-macro i just found fRun->SetWriteRunInfoFile(kFALSE); but this seems false anyway.

[Updated on: Sat, 10 August 2013 23:08]

Report message to a moderator

Re: Update Notes [message #15179 is a reply to message #15176]

Mon, 12 August 2013 09:12

Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI

first-grade participant

From: *gsi.de

Hi Simon,

I think I found the bug with the broken truth pointer and fixed it. After updating PndTools/AnalysisTools you could again try a case where you got this crash and look, whether it's gone now.

Best,
Klaus

Report message to a moderator

Re: Update Notes [message #15183 is a reply to message #15179]

Mon, 12 August 2013 12:30

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: 2.235.190*

I have rerun the analysis of my 2000 events which were crashing, and now the analysis goes smoothly.
The only "strange" thing is coming from several error messages in the fitters, which are not crashing:

Error in <Inv5x5>: matrix is singular
PndVtxPRG: COVi Inversion failed, abort fit.
Error in <PndVtxPRG::PndVtxPRG::FitNode()>: Fit failed for composite 0x7fbad4384d60. Set chisquare to 172239904.

I hope they are fine.

Report message to a moderator

Re: Update Notes [message #15187 is a reply to message #14913]

Mon, 12 August 2013 20:48

Simon Reiter
Messages: 44
Registered: May 2013

continuous participant

From: *dip0.t-ipconnect.de

Hi,

yes, it seems working now.
These are just some Errors by the PndVtxPRG-Fitter. I just don't know why there always another chisquare for each simulation.

Thanks
Simon

Report message to a moderator

Previous Topic:	Documentation for Rho classes
Next Topic:	MVD Particle Identification in analyses

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Dec 01 11:44:08 CET 2024

Total time taken to generate the page: 0.00860 seconds