[Rivet] hopefully quick Rivet assertion question

[Caterina Doglioni]

Hi Andy,

thanks for noticing the out-of-bounds problem, that was silly of me (at 
least I put a disclaimer about sending this to the Rivet list...)!

I have now fixed the issue, and the code goes through happily. I suspect 
the deltaPhi function was getting garbage values as input that caused 
the assertion to fail (not sure how, I can do more digging if you'd 
like). Thanks for this!

Caterina

On 01/08/2014 02:00 PM, Andy Buckley wrote:
> 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
>>>
>>
>
>