Home » PANDA » PandaRoot » Analysis » [CLOSED] Wrong particle in FillList
| [CLOSED] Wrong particle in FillList [message #15044] |
Tue, 30 July 2013 13:58  |
Lu Cao
Messages: 77
Registered: February 2013
|
continuous participant |
From: *ikp.kfa-juelich.de
|
|
Hi all,
In the analysis for the decay pbp->Ds-(KKpi) Ds+ (e+ nu_e eta(3pi)), I use the following PID algorithm to fill the candidates list as
theAnalysis->FillList(pipbase, "PionLossePlus");
theAnalysis->FillList(pimbase, "PionLosseMinus");
theAnalysis->FillList(kapbase, "KaonLossePlus");
theAnalysis->FillList(kambase, "KaonLosseMinus");
theAnalysis->FillList(rawgambase,"Neutral");
then, I check the PDG numbers of candidates in each list. In every event, some particles with wrong PDG are found.
Found wrong piplus in pipbase list: evt = 1 j = 1 PDGCode = -11
Found wrong piplus in pipbase list: evt = 1 j = 2 PDGCode = 11
Found wrong piplus in pipbase list: evt = 1 j = 3 PDGCode = 321
Found wrong piplus in pipbase list: evt = 1 j = 4 PDGCode = -11
---------------------------------------------------
Found wrong piminus in pimbase list: evt = 1 j = 1 PDGCode = -11
---------------------------------------------------
Found wrong gamma in gambase list: evt = 1 j = 1 PDGCode = 2112
Found wrong gamma in gambase list: evt = 1 j = 2 PDGCode = 2112
Found wrong gamma in gambase list: evt = 1 j = 3 PDGCode = -11
Found wrong gamma in gambase list: evt = 1 j = 6 PDGCode = -211
Found wrong gamma in gambase list: evt = 1 j = 7 PDGCode = 11
Found wrong gamma in gambase list: evt = 1 j = 10 PDGCode = 2112
Found wrong gamma in gambase list: evt = 1 j = 11 PDGCode = 2112
Found wrong gamma in gambase list: evt = 1 j = 12 PDGCode = -11
---------------------------------------------------
Found wrong kaminus in kambase list: evt = 1 j = 0 PDGCode = -211
Found wrong kaminus in kambase list: evt = 1 j = 1 PDGCode = -11
---------------------------------------------------
Found wrong kaplus in kapbase list: evt = 1 j = 0 PDGCode = 211
Found wrong kaplus in kapbase list: evt = 1 j = 1 PDGCode = -11
Found wrong kaplus in kapbase list: evt = 1 j = 2 PDGCode = 11
Found wrong kaplus in kapbase list: evt = 1 j = 4 PDGCode = -11
---------------------------------------------------
This seems not reasonable. I'm using the version #18621.
Best regards,
Lu
[Updated on: Fri, 23 August 2013 17:16] by Moderator Report message to a moderator |
|
|
|
|
|
| Re: Wrong particle in FillList [message #15049 is a reply to message #15044] |
Tue, 30 July 2013 15:43  |
Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI
|
first-grade participant |
From: *gsi.de
|
|
Hi Lu,
indeed, it looks strange, in particular, that you have charged particles in your gamma list. One issue with your code is, that the keywords are wrong; use 'PionLoosePlus' instead of 'PionLossePlus' etc. Your unknown keyword 'Losse' should lead to default 'All', meaning, that no PID cut is applied.
Maybe you could do an svn update on trunk/rho and trunk/PndTools/AnalysisTools and try again with the correct keywords.
In general, also with correct working PID algorithms, you always might have some wrong particles (from MC truth point of view) in the lists due to misidentification.
Best,
Klaus
|
|
|
|
|
|
| Re: Wrong particle in FillList [message #15059 is a reply to message #15049] |
Tue, 30 July 2013 22:27 |
Lu Cao
Messages: 77
Registered: February 2013
|
continuous participant |
From: *adsl.alicedsl.de
|
|
Hi Klaus,
First, sorry for mistyping~~
I have updated the whole framework to the latest version #20914, and found the FillList works quite well with "Loose" and even "All" PID algorithm in the charged particle cases, where almost no wrong filling.
However, for the gamma, the pdg code of all candidates are 0. I checked that in MC truth. They are correct in there.
In the analysis macro, I use
| Quote: |
PndAnalysis* theAnalysis = new PndAnalysis();
RhoCandList gamma;
theAnalysis->FillList(gamma, "PidAlgoIdealNeutral");
while (theAnalysis->GetEvent() && i++<nevts)
{for (j=0;j<gamma.GetLength();++j)
{cout << "gamma =" << gamma[j]->PdgCode() << endl;
}
}
|
Best regards,
Lu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Wrong particle in FillList [message #15075 is a reply to message #15044] |
Wed, 31 July 2013 19:35 |
Simon Reiter
Messages: 44
Registered: May 2013
|
continuous participant |
From: *zeu.uni-giessen.de
|
|
Hi,
I'm not sure if it is corrected in the trunk, but I found something weird. While using the release APR13 I searched for pions and checked their pdg.
theAnalysis->FillList(mctrk, "McTruth");
theAnalysis->FillList(pions, "PionLooseCharged");
for(Int_t i=0;i<pions.GetLength();i++) {
if (!mcm.MctMatch(pions[i], mctrk)){
...
}
}
At ... I printed the McIdx of "pions", the PdgCode of "pions" and the "PdgCode" of mctrk.
McIdx: 2311 pdg: 211
McPdg of 2311: -211
McIdx: 174 pdg: 211
McPdg of 174: 1000010020
.
.
.
While MctMatch is comparing the pdgcode of "pions[i]" and the one pointed to in mctrk, there shouldn't be any difference, if "McIdx" of "pions[i]" is set correctly. But there are plus-minus problems..
Additionally what is pdg 1000010020? This number is set by "McTruth"!!!
Is the default PID "PidAlgoIdealCharged" with MC information or not? And will this be corrected in the release?
Best regards,
Simon
[Updated on: Wed, 31 July 2013 19:43] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Wrong particle in FillList [message #15143 is a reply to message #15138] |
Thu, 08 August 2013 15:36 |
Jens Sören Lange
Messages: 193
Registered: June 2005
|
first-grade participant |
From: *wlan.uni-giessen.de
|
|
Hi Stefano,
1.) At first, please see your own meeting minutes
http://panda-wiki.gsi.de/cgi-bin/view/Computing/Minutes06May2013
"New pandaroot release APR13. The new pandaroot release has been created, based on sep12 external packages. It contains stable code for the analysis, and it is strongly suggested to use it."
We understand that now (with your email today) it seems you change the official recommendation (-> use trunk instead of release!), but please keep in mind that Simon must deliver his thesis in 4 weeks from you.
2.) A release is a release. Bug fixing should be supported (to some level). It is only 3 1/2 months that the release is out. If support is stopped after such a short time, we can never finish any reasonable results.
3.) It is not only Simon. We are preparing many results for the CHARM'13 (Y(4260), h_c', 3F4 state radiative decays, to be shown for the first time). It is completely out of question that 3 weeks before the conference we start re-writing everything for the trunk.
4.) Actually, Simon tried to switch to the trunk.
The discussion is here
https://forum.gsi.de/index.php?t=msg&th=3915&start=0&rid=206 7&S=257ebb8477b8bb15c64c915092466140
More problems. Again, that problem is the trunk.
The proposed solution from Klaus (see the final posting) is to change the pointer "by hand" event-by-event
"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) ..."
We think that this is not a reasonable option.
5.) trunk is trunk. There is no new rho release so far (at least we think there is not). Sure, development takes time and Ralf is on it, but even if somehow we manage to switch to the trunk and actually (-> wishful thinking!!) to have any working chain, it means that stuff is changing on a daily basis and maybe tomorrow the macros would not run anymore.
So, in order to keep deadlines (Simon's thesis and CHARM'13), we decide not to switch to the trunk right now.
greetings - Simon, Martin, Sören
|
|
|
|
| Re: Wrong particle in FillList [message #15144 is a reply to message #15143] |
Thu, 08 August 2013 16:05 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: 2.235.190*
|
|
Hi Soeren,
| Quote: |
We understand that now (with your email today) it seems you change the official recommendation (-> use trunk instead of release!), but please keep in mind that Simon must deliver his thesis in 4 weeks from you.
|
I am not changing the official recommendation, apr13 is still the suggested code. We have a list of bugs found after the creation of the release, and some of them are already fixed in the trunk. Maybe new bugs are also present in the trunk. I am just saying that this bug could be fixed. Could.
| Quote: |
2.) A release is a release. Bug fixing should be supported (to some level). It is only 3 1/2 months that the release is out. If support is stopped after such a short time, we can never finish any reasonable results.
|
The release is able to perform all the basic features, more or less. The McMatch could have problem, but there are other ways to do mc selections, i.e. using the MC index as done in the previous analyses and in the past.
Now we have two different analysis code. If Ralf or Klaus want to spend some time trying to debug the apr13 one, fine. But, again, the MC id can be performed in other ways before the bug is found.
I.e. you will fill a tcandlist with PionVeryLoose, you loop inside the tcandlist, retrieve the corresponding mc index, and create a new TCandList with only the particles you need.
Again, my proposal was to switch to the trunk to help Klaus and Ralf debugging, not to run analysis on the trunk. I believe the apr13 should be still fine for analysis. It depends on the features which are going to be used.
|
|
|
|
| Re: Wrong particle in FillList [message #15147 is a reply to message #15143] |
Thu, 08 August 2013 18:48 |
Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI
|
first-grade participant |
From: *adsl.alicedsl.de
|
|
Hi Sören,
I also like to give comments to some of your points.
I fully agree to 1) and 2), that there should be some stable and reliable environment, which is well defined. However, at the moment we had some significant restructuring fully absorbing the tiny manpower dedicated to analysis tools. Many bugs are showing up now, when people seriously start using the tools, which is very nice and welcome! But you cannot expect software to be bugfree, when only a small number of people try to use it at all, even if now it's suddenly very urgent that everything works flawless...
Concerning 4), you might have misunderstood my suggestion for a workaround. I reported, that I also encountered a strange error once in 20000 events. Thus when catching this one flawed pointer by hand it worked for the rest of the events. Therefore I suggested to try, whether it is just this one occasion but putting that 'dirty fix'. I of course agree, that we have to identify the bug and put a real fix.
What suprises me is, that you are aiming to show results for the first time in three weeks from now on a international workshop, which in principle have to be accepted by the publication committee and/or speakers board. According to our publication rules, a detailed analysis document has to be prepared and it has to be presented in a session open to all collaboration members, also for MC analyses. I know, that in the past things were handled quite relaxed, but with new results we really should be very careful. I hope you agree...
So, to summarize: We are working on the stuff to make it more stable, and surely some fixes will be done in apr13 until a new release is created with the restructured rho package. But it simply takes time, and we are just a few people.
Best regards,
Klaus
|
|
|
|
| Re: Wrong particle in FillList [message #15149 is a reply to message #15044] |
Thu, 08 August 2013 21:51 |
Jens Sören Lange
Messages: 193
Registered: June 2005
|
first-grade participant |
From: *unitymediagroup.de
|
|
Hi Klaus,
first of all, of course we know that you and Ralf are working hard on the rho update and that it takes time. But changing back and forth between release and trunk for us and our macros just brings too many problems. More problems than benefit.
About the talk, please don't worry. This is an official talk assigned by the speaker's board. Volker Metag is the assigned referee. We will have the rehearsal a few days before the talk and follow Volker's advice and decision what to show and what not.
The plan is the following.
1.) Any of the results in this talk will be attached with a personal name of the student (or me) who did the analysis.
And this is the only time that the results will be shown.
The results will not be open for more talks, so there is no danger that they would be shown by someone not being able to report exactly what has been done, and what not. This means that e.g. they will not be shown at PHIPSI'13, MENU'13 or HADRON'13.
2.) We will be only using the apr13 release, so it is (hopefully) safe. And only results which are consistent with resolution published before in the physics book will be shown. The momentum resolution is anyway much larger than other experiments because of the high fixed target boost, so the invariant mass resolution is maybe not the issue and safe to show.
3.) But I agree with you. If it is really the case that we can not evaluate any reconstruction efficiency (because MCTruth is not propagated into the rho TCandidates) then we cannot show. I would only show invariant mass resolutions then.
4.) I didn't know that talks have the requirements of additional analysis documents. There was no information so far from the speakers board. Can you maybe send around the analysis documents of the last few talks at conferences? I can of course provide a draft of an analysis document. 50% of the talk is results which anyway have been shown at Panda meetings before (X(3872) resonance scan or h_c' recoil mass results - now improved by Simon - in my talk December 2012). But an example of an analysis document would be nice.
cheers, Soeren
|
|
|
|
|
|
|
|
| Re: Wrong particle in FillList [message #15154 is a reply to message #15149] |
Fri, 09 August 2013 09:52 |
Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI
|
first-grade participant |
From: *gsi.de
|
|
Hi,
just wanted to report, that I just checked out release/apr13 (so, no 'svn update', but a real new check out), and all tutorial macros with all functionallity worked out of the box.
So, when somebody has problems, I just can tell, that everything seems to work properly in the unaltered release/apr13 version.
Best,
Klaus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Pages (2): [1 ] |
  |
Goto Forum:
Current Time: Thu Nov 28 13:44:18 CET 2024
Total time taken to generate the page: 0.00672 seconds
|
GSI Forum
Search
Help
Members
Login
Home
