|
[Rivet] more fun with alpgenAndy Buckley andy.buckley at ed.ac.ukThu 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 |