[Rivet] more fun with alpgen

Andy Buckley andy.buckley at ed.ac.uk
Thu Dec 16 17:04:31 GMT 2010


On 16/12/10 16:39, Gavin Hesketh wrote:
> Hello,
> hopefully a simple one.
> 
> I'm running alpgen+pythia using agile, piping into a fifo being read by
> rivet. I  specify the number of events: agile-runmc -n 1000.
> 
> The problem is pythia is reading from an external file (from the alpgen
> matrix element generator), which might not contain 1000 events. Then,
> pythia calls UPVETO, to veto events based on parton-particle jet
> matching. So, even if the external file contains 1000 events, they might
> not all get processed through pythia to make it to the fifo.
> 
> The result being that rivet does not get 1000 events, and just hangs
> once the fifo is not being filled. I have to kill it by hand, which
> means no .aida file, and no way to run this on the batch queue...
> 
> Now, I have no way of knowing in advance exactly how many events will be
> in the external file read by pythia, or how many of those will fail
> UPVETO. So I want to tell agile to run over as many as possible (it
> seems to cleanly stop once the external file is exhausted, even if this
> is less than the "n" I specify). But is there a way to make rivet wrap
> up cleanly once the fifo is not receiving any more events (or when agile
> is no longer running)?

Hi Gavin,

Are you telling rivet to expect exactly 1000 events? In that case I
think it will wait even when AGILe has died. It should exit cleanly,
with an output file, if Ctrl-C'd. And if you don't specify a number of
events to Rivet, it should run until the end of the HepMC stream, which
is written by AGILe shutting down correctly. Maybe the AGILe AlpGen
interface *doesn't* exit smoothly enough to write that terminating run
footer.

Without having time right now to look into it, I think that Rivet is
doing the right thing, and heuristics to guess when the fifo is not
receiving more events would probably have their own edge cases and
problems. I've put a 1 hour timeout on the first event into the SVN
version of Rivet, to catch a never-amusing batch farm gotcha where jobs
appear to be running for days but are actually doing nothing at all, but
even if I were to extend that to the event loop it wouldn't have the
sort of responsive behaviour that you want.

So the problem is probably either that agile-runmc is *not* exiting as
smoothly as required when the external file is exhausted, or that you
are explicitly telling rivet to wait for a fixed number of events which
never arrive. Which is it? If the former, we should fix that before
making the next AGILe release (pretty soon, I hope)

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh


More information about the Rivet mailing list