[Rivet] agile memory use

Andy Buckley andy.buckley at ed.ac.uk
Mon 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