[Rivet] bug

[Andy Buckley]

On 11/08/14 21:06, Frank Krauss wrote:
> On 11/08/14 16:53, Andy Buckley wrote:
>> Hi Frank,
>>
>> I've been in touch with Holger about the problem -- last I heard your
>> problems came from running events with massless stable partons into
>> Rivet and filling NaN values into histograms. That's not something we
>> can test for, and I think YODA was/is right to abort when it gets a
>> crazy fill value that invalidates the histogram.
> 
> Well, actually, let me disagree there.  If you ever wanted to evaluate
> hadronization corrections or so with Rivet, you would have to deal with
> this.  That's why I believe this is exactly the kind of exception you
> want to catch, before filling it in ....

Hmm, so probably the check needs to go into the analysis then. For
flexibility I think it would be a good idea to get rid of all the
user-triggerable asserts from YODA, since there is no way to recover
from them, and replace them with exception throws which can at least be
handled if the calling code is careful.

I'm happy for people to go through the Rivet analysis code adding
checking for NaN and inf histo fills, and other issues that can arise
from parton-level running. But it's not surprising that the analyses we
get sent by experiments aren't so careful, and I don't see how we could
automate the checking by putting it inside YODA itself because the
analysis code would need to make sure that e.g. weight counters don't
get updated if a histo fill() fails...

>> This error looks different but is hard to read -- it looks like
>> something goes wrong inside a Boost shared pointer header. I don't see a
>> "px != 0" assert anywhere in that analysis code, so is this a private
>> version of it? Unless that assert is in the Boost code and it's just a
>> coincidence that they used a physicsy variable name like px...
> 
> Well, no idea what it is, but it certainly is annoying like hell. And,
> no, I don't do private versions of analyses, especially not by CMS.

Ok :-)  Just guessing from what it looked like, and that I know Holger
was trying some private hacks! Maybe the suggestion from Holger about
using make_shared has some merit, but he can't reproduce this problem on
the trunk anyway.

>> Duplicate analysis warnings are entirely intentional, and if you are
>> getting those it suggests that you are using a hacked copy of a standard
>> analysis and the system is warning that there is another one of the same
>> name later in the search path. Is that possible?
> 
> No, actually, I get lots of warnings, next time I copy and send them to
> you.  it's nothing serious, though.

Ok, let me know. If you're getting those warnings, maybe you have a
second Rivet installation somewhere and its analysis plugin libs are
getting found by virtue of being listed in your $RIVET_ANALYSIS_PATH?

>> I ran this analysis happily a few days ago when discussing with Holger,
>> and it worked fine. I'm on the Rivet trunk of course, but I don't think
>> there should be any significant changes w.r.t. 2.1.2  (not 2.0.0,
>> right?)  Certainly no changes in how histogram pointers are handled :-S
> 
> Hmm, rivet --version claimed 2.0.0 ....

Interesting. Can you send us your copy of the bootstrap script so we can
check what version is being downloaded? The way listed on the
GettingStarted wiki should be up to date with the download path for the
2.1.2 bootstrap.

Andy


>> On 11/08/14 16:31, Frank Krauss wrote:
>>> Dear All,
>>> as Holger already knows, there are more and more bugs cropping up in
>>> Rivet + Yoda.
>>> They manifest themselves as
>>>
>>>
>>> Sherpa:
>>> /home/krauss/rivetinstall/local/include/boost/smart_ptr/shared_ptr.hpp:653:
>>>
>>> typename boost::detail::sp_member_access<T>::type
>>> boost::shared_ptr<T>::operator->() const [with T = YODA::Histo1D,
>>> typename boost::detail::sp_member_access<T>::type = YODA::Histo1D*]:
>>> Assertion `px != 0' failed.
>>>
>>> Exception_Handler::SignalHandler: Signal (6) caught.
>>>     Cannot continue.
>>> Exception_Handler::GenerateStackTrace(..): Generating stack trace
>>> {
>>>    0x7fb8d9ec54f5  in 'gsignal' (raise.c:64)
>>>    0x7fb8d9ec8c5b  in 'abort' (abort.c:93)
>>>    0x7fb8d680fe61  in 'Rivet::CMS_2010_S8547297::analyze(Rivet::Event
>>> const&)'
>>>    0x7fb8d8af09d0  in 'Rivet::AnalysisHandler::analyze(HepMC::GenEvent
>>> const&)'
>>>    0x7fb8d8dacb1c  in 'Rivet_Interface::Run(ATOOLS::Blob_List*)'
>>> (basic_string.h:288)
>>>    0x7fb8dc031bef  in 'SHERPA::Analysis_Phase::Treat(ATOOLS::Blob_List*,
>>> double&)' (Analysis_Phase.C:66)
>>>    0x7fb8dc00d2c3  in 'SHERPA::Event_Handler::AnalyseEvent(double&)'
>>> (Event_Handler.C:145)
>>>    0x7fb8dc011b57  in
>>> 'SHERPA::Event_Handler::GenerateMinimumBiasEvent(SHERPA::eventtype::code&)'
>>>
>>> (Event_Handler.C:329)
>>>    0x7fb8dc012bf5  in
>>> 'SHERPA::Event_Handler::GenerateEvent(SHERPA::eventtype::code)'
>>> (Event_Handler.C:127)
>>>    0x7fb8e67dfc7b  in 'SHERPA::Sherpa::GenerateOneEvent(bool)'
>>> (Sherpa.C:197)
>>>    0x402177        in 'main' (Main.C:37)
>>> }
>>>
>>>
>>> So, apparently, your ** new ** ** default ** 2.0.0 which I accessed
>>> through the bootstrap script by now has some interesting behaviour.
>>> Before that, there have already been little nuisances, like double
>>> analyses warnings etc., but no outright crashes.  I seriously suggest
>>> you try to fix this and do some minor testing next time, before rolling
>>> out new versions.
>>>
>>> Best wishes
>>>     Frank
>>>
>>
> 
> 


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