[Rivet] bug

[Frank Krauss]

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 ....

> 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.

> 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.

> 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 ....

> 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
>>
>


-- 
======================
Professor Frank Krauss
IPPP
Durham University

+44 191 33 43751
======================