[Rivet] Sherpa+Rivet: m_io->fill_next_event fails

[Eike von Seggern]

On Wed, Dec 09, 2009 at 15:42 +0000, Andy Buckley wrote:
> Frank Siegert wrote:
> > Frank Siegert, Thursday 26 November 2009:
> >> Eike von Seggern, Thursday 26 November 2009:
> >>> I'm trying to run Sherpa with the BaBar setup and analyse the events
> >>> with Rivet. However, Rivet stops after processing a few events. I
> >>> tracked it down to that the m_io->fill_next_event call in
> >>> Run::processEvent fails. But no other error message is printed by
> >>>  HepMC. Sherpa and Rivet are both built against HepMC 2.05 .
> >>>
> >>> I attach the Sherpa run card. The Rivet command is:
> >>>
> >>> rivet -l Rivet=DEBUG -a PDG_HADRON_MULTIPLICITIES babar.hepmc2g
> >>>
> >>> Has anyone an idea what's going wrong.
> >> I don't have a solution, but it might be interesting to know whether it
> >> works through Sherpa's internal Rivet interface (in 1.2.0). Our manual
> >> describes how you can use that... could you give that a try?
> > 
> > Actually, I've just tested it, and it doesn't stall, but the analysis 
> > isn't going to work for Babar events, since it looks at 2*"mean beam 
> > momentum" instead of sqrt(s). This isn't the same for asymmetric beams.
> 
> Eike/Frank, does this now work with the updated analysis? If so, then I 
> guess this *is* a problem with HepMC I/O. Why asymmetric beams would 
> lead to a HepMC read fail I have no idea... but it's possible, and looks 
> increasingly probable.

Yepp, I still get this with the current Rivet HEAD. So I think this is
either Sherpa's fault or HepMC itself. But most likely HepMC, because
writing out something without an error or anything strange and then not
being able to read in the data afterwards looks to me that way.

I'll try this now with example code to check that it's not Rivet's
fault.

BTW: Is there a nice write-up of the file format?

Cheers
    eike