|
[Rivet] more fun with alpgenGavin Hesketh hesketh at cern.chThu Dec 16 18:33:24 GMT 2010
...if you are interested in reproducing it exactly, this is the output from agile-runmc: http://www-clued0.fnal.gov/~ghesketh/hepmc-crash.txt then just: > rivet hepmc-crash.txt should do it. I suspect it's a HepMC IO problem, as the last event (for which there was no input) has no P or V, so probably the "END_EVENT_LISTING" is not parsed correctly. cheers, Gavin On 16/12/10 17:04, Andy Buckley wrote: > 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 >
More information about the Rivet mailing list |