<div>Thanks Jon,</div><br><div>Frank's thoughts are on the right track -- I would not have expected this comparison to be a problem because the two types are different, and the projection compare() methods (which look up things like contained projections) should only be called if the concrete types exactly match. It'll require a bit of detailed debugging... which I can do given a bit of time.</div><br><div>By the way, thanks for committing directly, but for bugfixes like this please do it on the release branch, which is currently release-2-6-x: you can checkout with a "-b release-2-6-x" flag, or switch to it within a checkout with "hg up release-2-6-x". It seems picky, but the direction of flow should be from the current release into the default branch (which will become 2.7.0, if there is one) and other "big development" branches. Pulling the other way is harder, because there are things in there which can't/shouldn't be incorporated into the 2.6.x series.</div><br><div>Andy</div><br><div><signature id="initial"><div><table cellpadding="0" cellspacing="0"><tbody><tr><td colspan="2"><div style="padding-bottom:15px;"><div><strong>Dr Andy Buckley, Lecturer / Royal Society University Research Fellow</strong></div><div>Particle Physics Experiment Group, University of Glasgow</div></div></td></tr><tr><td style="vertical-align:top;"></td><td><div style="font-size:0.9em;white-space:nowrap;border-left:2px solid gray;margin-left:20px;padding-left:20px;"><div><div></div><div></div></div></div></td></tr></tbody></table></div></signature></div><div class="gmail_quote_attribution">On Jan 30 2018, at 10:39 am, Frank Siegert <frank.siegert@cern.ch> wrote:</div><blockquote><br><div><div>Hi Jon,</div><br><div>good point, this looks correct to me after your fix, but I'm also not</div><div>the projection handling expert.</div><br><div>Just to add, because I was wondering at first: the projection mapping</div><div>is fine here, since the ZFinders will not compare equal due to the ee</div><div>and mumu input. But the name they are registered under seems to clash</div><div>because both analyses are derived from the same base class and</div><div>apparently the projection registering code only takes that into</div><div>account and not the derived class? Andy or David will probably know</div><div>better whether that's expected behaviour.</div><br><div>Best,</div><div>Frank</div><br><br><div>On 27 January 2018 at 17:30, Jonathan Butterworth</div><div><J.Butterworth@ucl.ac.uk> wrote:</div><blockquote><div>Hi all,</div><br><div>About 24k events into a rivet run (using the tip of the default branch), it</div><div>terminated with the following message:</div><br><div>Duplicate name 'ZFinder' in parent 'ATLAS_2015_I1408516_MU'</div><br><div>which comes from the projection handler.</div><br><div>I looked into the code, and I think the issue is that the _MU and _EL</div><div>versions of this analysis (it's the ZpT one) use the same projection name.</div><div>I'm running some exotic events which have no Zs, but do have loads of muons</div><div>and occasional electrons. My guess is the problem occurs when there is a</div><div>pair of muons and a pair of electrons in the same event, each consistent</div><div>with a Z - not something you'd get in the SM processes this analysis was</div><div>aimed at, but not something that should crash it.</div><br><div>I have just committed some changes which I think sensibly address the</div><div>problem - certainly they stop the exit mid run and the plots look right as</div><div>far as I can tell.</div><br><div>I noticed at least one other analysis (which I am not using) with the same</div><div>problem. If you agree with my fixes, I will apply them to the other</div><div>routines, but I'd appreciate someone else having a quick look, as I am on</div><div>the edge of my c++ knowledge and there might be a better way.</div><br><div>Also I'm guessing it would be better if projection handler trapped this at</div><div>initialisation, not runtime? But I don't know how to do that (or if it's</div><div>even possible).</div><br><div>Cheers,</div><div>Jon</div><br><div>--</div><div>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><div>Prof. Jonathan Butterworth, http://www.hep.ucl.ac.uk/~jmb/</div><div>Head, Physics and Astronomy Department Tel: +44 20 7679 3444</div><div>University College London Gower St, London WC1E 6BT, UK</div><div>ATLAS, CERN Tel: +41 22 76 72340</div><div>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></blockquote><div>_______________________________________________</div><div>Rivet mailing list</div><div>Rivet@projects.hepforge.org</div><div>https://www.hepforge.org/lists/listinfo/rivet</div></div></blockquote>