|
[Rivet] agile memory useAndy Buckley andy.buckley at ed.ac.ukMon Jan 31 15:53:33 GMT 2011
I'll look into this... thanks for finding and reporting it. I don't know of anywhere that we are e.g. allocating an array proportional to NUM_EVENTS, but that's what it looks like. We also don't pass the AGILe maximum event number to the Fortran common blocks, AFAIK, so the problem is indeed likely to be in the steering and generator independent. Hopefully it'll be obvious :) Cheers, Andy On 31/01/11 13:42, Gavin Hesketh wrote: > Hello, > Noticed this after seeing lots of batch job crashes. Sometimes I run > agile with a large number of events (mostly because of the setup I have > for alpgen). When this number gets very large, agile grabs a huge block > of virtual memory before generating any events. > eg: > agile-runmc Pythia6:424 -n 10000000 > grabs 170 MB > > agile-runmc Pythia6:424 -n 100000000 > grabs 1.5 GB, and tends to be killed by the batch queue I use. > > x10 higher N won't initialise. > > ok, 100M is a lot of events, and I've figured out a work-around for this > in the way I run alpgen. But it seems strange that agile should be > requesting so much memory when events are in the end fed to a pipe for > rivet to read one by one. Is this expected? Seems to be independent of > the generator I use. > > thanks, > Gavin > _______________________________________________ > Rivet mailing list > Rivet at projects.hepforge.org > http://www.hepforge.org/lists/listinfo/rivet > -- Dr Andy Buckley SUPA Advanced Research Fellow Particle Physics Experiment Group, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
More information about the Rivet mailing list |