[Rivet] hopefully quick Rivet assertion question

Andy Buckley andy.buckley at cern.ch
Wed Jan 8 13:00:39 GMT 2014


Hi Caterina,

Very strange! I realised after sending it that my code was testing the
domain normalising of the phi values themselves rather than their
deltas... did you test whether the phi[0]-phi[1], phi[1]-phi[3],
phi[2]-phi[3] combinations work in the test code?

Ah, I just noticed something odd about these indices: you're talking
about the phi values of *three* jets, but in the array notation you're
accessing leadjets[3], i.e. the *fourth* jet:

delta_phi[j12] = Rivet::deltaPhi(leadjets[0], leadjets[1]);
delta_phi[j13] = Rivet::deltaPhi(leadjets[1], leadjets[3]);
delta_phi[j23] = Rivet::deltaPhi(leadjets[2], leadjets[3]);

Are there errors in your array indices on the j13 and j23 lines here?

Maybe the problem is coming from cases where you access an object off
the end of the array, or similar. Although I'd expect it to crash in
that case, and the logic of the _mapAngleM2PITo2Pi function should
definitely, always map the given value into [-2pi, 2pi] -- hence the
assert rather than a more "user friendly" exception throw -- so I don't
know how it can be failing. If we can't understand this, I'll see if we
can put some more printout into the code, but a build with -NDEBUG in
the CPPFLAGS should disable the assert (note that this is orthogonal to
debug symbols.) I'm in two minds about whether to enable this by default
since David G pointed out that it can lead to violations of the C++ "one
definition rule".

Andy


On 08/01/14 13:46, Caterina Doglioni wrote:
> Hi Andy,
> 
> sorry for the (not-too) holiday-related delay, I'm back to this now.
> Turns out my previous values were those of the previous event
> (apologies!). So I've picked up a couple more:
> 
> phi j1:6.11223
> phi j2:2.50349
> phi j3:4.45546
> python:
> /afs/cern.ch/user/d/doglioni/Work/ThreeJet_Rivet2/local/include/Rivet/Math/MathUtils.hh:419:
> double Rivet::_mapAngleM2PITo2Pi(double): Assertion `rtn >= -TWOPI &&
> rtn <= TWOPI' failed.
> 
> then on another run:
> 
> phi j1:5.4923
> phi j2:1.73499
> phi j3:3.35263
> python:
> /afs/cern.ch/user/d/doglioni/Work/ThreeJet_Rivet2/local/include/Rivet/Math/MathUtils.hh:419:
> double Rivet::_mapAngleM2PITo2Pi(double): Assertion `rtn >= -TWOPI &&
> rtn <= TWOPI' failed.
> Aborted
> 
> None of the two give any problem when plugged into your small .cc code.
> 
> I have put the hepmc dump of the events containing the latter one in my
> lxplus public (I can probably find out how to add an event counter if
> that helps...):
> 
> ~doglioni/hepmc.events
> 
> I'll now try to recompile rivet without debug symbols (and cross-check
> the results with your implementation).
> 
> Thanks!
> Caterina
> 
> On 12/10/2013 11:46 AM, Andy Buckley wrote:
>> On 09/12/13 13:47, Caterina Doglioni wrote:
>>> Hi Andy,
>>>
>>> I have a possibly strange thing happening to a Rivet code that I'm using
>>> (Cigdem in cc) - if it's a bug I'll chase it up through the official
>>> channel, but if this is not the case and I'm doing something wrong,
>>> emailing just you will spare my silly error being exposed to a wider
>>> audience :). Some snippets:
>>>
>>> leadjets[0] and [1] are 4-momenta that I get from:
>>>
>>> const Jets jets = applyProjection<JetAlg>(event,
>>> "Jets").jetsByPt(100*GeV);
>>>
>>> out of a Pythia8+Sacrifice jetty final state. However, sometimes (e.g.
>>> after 300 events in one of the runs) one of the following lines:
>>>
>>> delta_phi[j12] = Rivet::deltaPhi(leadjets[0], leadjets[1]);
>>> delta_phi[j13] = Rivet::deltaPhi(leadjets[1], leadjets[3]);
>>> delta_phi[j23] = Rivet::deltaPhi(leadjets[2], leadjets[3]);
>>>
>>> crashes my entire code with:
>>>
>>> python:
>>> /afs/cern.ch/user/d/doglioni/Work/ThreeJet_Rivet2/local/include/Rivet/Math/MathUtils.hh:419:
>>>
>>> double Rivet::_mapAngleM2PITo2Pi(double): Assertion `rtn >= -TWOPI &&
>>> rtn <= TWOPI' failed.
>>> Aborted (core dumped)
>>>
>>> I've checked that leadjets[0] and [1] are sane, and that their phi value
>>> is from 0 to 2pi, but I haven't managed to track down where things go
>>> wrong because this is unfortunately not always happening at the same
>>> place! One instance of incriminated jets is here:
>>>
>>> phi j1:0.387629
>>> phi j2:3.61709
>>> phi j3:1.82318
>>> python:
>>> /afs/cern.ch/user/d/doglioni/Work/ThreeJet_Rivet2/local/include/Rivet/Math/MathUtils.hh:419:
>>>
>>> double Rivet::_mapAngleM2PITo2Pi(double): Assertion `rtn >= -TWOPI &&
>>> rtn <= TWOPI' failed.
>>>
>>> If you can spot the problem without effort from your side I'll be happy
>>> to hear it - but let me know if you prefer this to go into official
>>> channels.
>>
>> Hi Caterina, Cigdem... and I've CC'd the Rivet list,
>>
>> That is very strange. a) I thought that we had already knocked all the
>> wrinkles out of those deltaPhi asserts, and b) those phi values are
>> already within the -2pi..2pi range and so nothing should happen at all!
>> The relevant code is this:
>>
>> https://rivet.hepforge.org/trac/browser/include/Rivet/Math/MathUtils.hh#L412
>>
>>
>> and I implemented a tiny test program (attached) to run the same logic
>> and assert on the values you supplied (TWOPI = 2*M_PI in
>> https://rivet.hepforge.org/trac/browser/include/Rivet/Math/MathHeader.hh#L50).
>>
>> Unsurprisingly it's fine:
>>
>> andy at duality:~/tmp/testfmod$ g++ testfmod.cc -o testfmod
>> andy at duality:~/tmp/testfmod$ ./testfmod
>> 0.387629 -> 0.387629 = 0.123386*PI
>> 3.61709 -> 3.61709 = 1.15136*PI
>> 1.82318 -> 1.82318 = 0.580336*PI
>>
>> Does anyone else know what might be going on here? Do you know which
>> specific phi value is causing the trouble, Cate? If you could put the
>> analysis code and a HepMC dump of the events (300 events in ASCII is not
>> enormous) somewhere ~public, e.g. your AFS public dir then I can look in
>> more detail.
>>
>> A workaround for now is to add CPPFLAGS=-DNDEBUG to your configure or
>> make command line before building Rivet (you are using a private build,
>> yes?). This will disable the assert. I actually thought that the asserts
>> were only active when -g was used, but it turns out that that only
>> controls the debug symbols and that assert disabling requires the NDEBUG
>> #define, cf.
>> http://stackoverflow.com/questions/5354314/how-to-completely-disable-assertion
>>
>>
>> Cheers,
>> Andy
>>
> 


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN


More information about the Rivet mailing list