GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » [FIXED] MC matching
[FIXED] MC matching [message #18903] Tue, 19 January 2016 08:46 Go to next message
Alexander Zinchenko is currently offline  Alexander Zinchenko
Messages: 8
Registered: January 2016
occasional visitor
From: *jinr.ru
Hello.
I was looking at some decays involving \pi0s. When trying to reconstruct them from 2 photons
and check MC truth I get no correct combinations at all - all gamma-gamma go to wrong
combination case (see the attached plots).
I am using January 2016 release.
  • Attachment: ftm.png
    (Size: 7.38KB, Downloaded 291 times)
  • Attachment: nm.png
    (Size: 9.96KB, Downloaded 344 times)

[Updated on: Thu, 11 February 2016 23:57] by Moderator

Report message to a moderator

Re: MC matching [message #18904 is a reply to message #18903] Tue, 19 January 2016 08:59 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 91.252.21*
Can you attach the analysis macro you wrote?
Re: MC matching [message #18905 is a reply to message #18903] Tue, 19 January 2016 09:04 Go to previous messageGo to next message
Alexander Zinchenko is currently offline  Alexander Zinchenko
Messages: 8
Registered: January 2016
occasional visitor
From: *jinr.ru
It is the same as I used for my previous checks last year - attached.
Re: MC matching [message #18972 is a reply to message #18903] Wed, 03 February 2016 13:47 Go to previous messageGo to next message
Dominik Steinschaden is currently offline  Dominik Steinschaden
Messages: 28
Registered: April 2015
continuous participant
From: *smi.oeaw.ac.at
Is this problem already solved?

Because some time ago I was not able to use the stored Fairlinks after the digitization stage anymore, due to a bug in the recent Fairroot version as far as I remember.

Maybe this is caused by the same bug.

Dominik
Re: MC matching [message #18973 is a reply to message #18903] Wed, 03 February 2016 14:03 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
From: *ikp.kfa-juelich.de
What macros did you use for the complete simulation/digitization/reconstruction chain?

Cheers,

Tobias
Re: MC matching [message #18978 is a reply to message #18903] Thu, 04 February 2016 08:36 Go to previous messageGo to next message
Alexander Zinchenko is currently offline  Alexander Zinchenko
Messages: 8
Registered: January 2016
occasional visitor
From: *jinr.ru
I used the set of macros from tutorials/rho directory which are run from the script
tut_runall.sh except the simulation macro that was slightly modified (attached).
Regards.
Alexander
  • Attachment: tut_sim.C
    (Size: 7.71KB, Downloaded 252 times)
Re: MC matching [message #18980 is a reply to message #18978] Thu, 04 February 2016 10:58 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 106.2.197*
Hi,
I think tutorial macros are not yet updated to use FairLinks, while the ones in macro/run should be good.
I suggest the following: you need to add the code line:

fRun->SetUseFairLinks(kTRUE);


before

FairRuntimeDb *rtdb=fRun->GetRuntimeDb();


In all the macros sim digi reco and pid. This should solve the problem.

The way to solve the problem of misaligned macros is in the repository since few versions, I will report maybe next SeeVogh.
Re: MC matching [message #18989 is a reply to message #18980] Fri, 05 February 2016 12:04 Go to previous messageGo to next message
Alexander Zinchenko is currently offline  Alexander Zinchenko
Messages: 8
Registered: January 2016
occasional visitor
From: *jinr.ru
Hi,
the proposed remedy seems to solve the problem, but only partially - see attachments. There are still signal combinations in the "no match" sample.
Any other suggestions?
Alexander
  • Attachment: ftm.png
    (Size: 10.82KB, Downloaded 268 times)
  • Attachment: nm.png
    (Size: 11.89KB, Downloaded 261 times)
Re: MC matching [message #18990 is a reply to message #18989] Fri, 05 February 2016 13:37 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 106.2.197*
I have not well understood, which are the problems of the no-match plot?
Re: MC matching [message #18991 is a reply to message #18990] Fri, 05 February 2016 14:17 Go to previous messageGo to next message
Alexander Zinchenko is currently offline  Alexander Zinchenko
Messages: 8
Registered: January 2016
occasional visitor
From: *jinr.ru
Naively I was expecting it to be looking completely "background-like", i.e. without a peak at \pi0-mass value.
And, indeed, it was really like that about 1.5 years ago or so (see attachment).
Re: MC matching [message #18992 is a reply to message #18989] Fri, 05 February 2016 14:22 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
From: *ikp.kfa-juelich.de
Dear Alexander,

I think the problem is, that you have photon conversion before the calorimeter is hit. In this case the neutral candidate is not treated as the original photon but as the converter electron in the MC matching. You could check this if you ask the particles in your nm plot what the PID of their mother particle is.

Cheers,

Tobias
Re: MC matching [message #19017 is a reply to message #18903] Wed, 10 February 2016 19:37 Go to previous messageGo to next message
Alexander Zinchenko is currently offline  Alexander Zinchenko
Messages: 8
Registered: January 2016
occasional visitor
From: 185.48.36*
Hello.
I tried to do what was suggested (at least as think I did what was suggested), i.e. for pi0-candidates which were classified as "no-matched with MC" I checked PDG codes of both daughters and they are 22 (photons).

Another strange thing (for me - maybe somehow related to this): if I do
PndAnalysis* theAnalysis = new PndAnalysis();

theAnalysis->FillList(mclist, "McTruth");

// Get number of pi0 decaying into gam gam
for (int jmc = 0; jmc < mclist.GetLength(); ++jmc) {
if (mclist[jmc]->PdgCode() != 111) continue; // select only pi0
hpi0_mult->Fill(mclist[jmc]->NDaughters());
}
I get quite a few cases with only one daughter. Is it a normal behavior?

Re: MC matching [message #19018 is a reply to message #19017] Wed, 10 February 2016 19:52 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
If one of the photons is going in a direction without leaving a signal in the detector this can happen, the daugher is not stored in the MCTrack. This is a setting in the g3Config.C:

 st->SetMinPoints(1);


If you do:

 st->SetMinPoints(0);


then you will see also the particles w/o leaving hits in the detectors, but your MC data size will be much larger.
Re: MC matching [message #19032 is a reply to message #18903] Thu, 11 February 2016 20:22 Go to previous message
Alexander Zinchenko is currently offline  Alexander Zinchenko
Messages: 8
Registered: January 2016
occasional visitor
From: 185.48.36*
Hello.
I have managed to check the proposed explanation of the origin of the "non-matched" pi0's. They are indeed due to early interactions of decay photons. So, I suppose the case can be closed. Thanks for cooperation.
Alexander
Previous Topic: Compilation errors in trunk release 28886
Next Topic: [FIXED] pandaroot install problem
Goto Forum:
  


Current Time: Sat Nov 23 10:19:24 CET 2024

Total time taken to generate the page: 0.00644 seconds