[Rivet] Rivet 2.6.0 integration problems in CMS sosftware

[Andy Buckley]

Thanks David. At runtime you can also set the RIVET_ANALYSIS_PATH to only find a subset of plugins: if you terminate the path variable with a double-colon (::) then it will *not* fall back to searching the $prefix/lib directory for Rivet*.so files.

Andy
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Experiment Group, University of Glasgow

On Jan 11 2018, at 4:04 pm, David Grellscheid <david.grellscheid at durham.ac.uk> wrote:
> Hi Xavier,
>
> you can rename some of the folders in "analyses/". If the name does not
> start with "plugin", the compile will be skipped.
>
> Are you compiling Rivet in a threaded environment with explicit TLS
> choices?
>
> Thanks,
>
> David
>
>
> On 11/01/18 15:41, Janssen Xavier wrote:
> >
> > Hi Andy,
> >
> > Is there a way I can compile only a few plugins for a quick test to be
> > sure this is a limit problem ?
> >
> > Cheers, Xavier,
> >
> >
> > > On 11 Jan 2018, at 16:34, Andy Buckley <andy.buckley at cern.ch
> > > <mailto:andy.buckley at cern.ch>> wrote:
> > >
> > > Hi Xavier,
> > >
> > > *Very* strange. The analysis loading has not changed at all, but the
> > > analysis compilation now uses the rivet-buildplugin script for all the
> > > built-in analyses as well as any external ones. I wouldn't expect that
> > > to change anything, and it's worked fine on my machine and others...
> > > but it is a change.
> > >
> > > I'm no expert on this static TLS thing -- a quick Google suggests that
> > > the system is running out of memory due to loading plugins each with
> > > their own static memory requirements. Maybe we just crossed some
> > > threshold? My recollection is that we load all the lightweight
> > > analysis *loader* objects into memory, but only instantiate the actual
> > > analysis classes which are requested by the user. Any experts on the
> > > list who can suggest diagnostics?
> > >
> > > Andy
> > >
> > > *Dr Andy Buckley, Lecturer / Royal Society University Research Fellow*
> > > Particle Physics Experiment Group, University of Glasgow
> > >
> > >
> > >
> > > On Jan 11 2018, at 3:16 pm, Janssen Xavier
> > > <xavier.janssen at uantwerpen.be <mailto:xavier.janssen at uantwerpen.be>>
> > > wrote:
> > >
> > >
> > > Hi,
> > >
> > > I was testing the integration of the latest release in our CMS
> > > software. The installation and compilation is working well.
> > > However trying to run Rivet to produce some MC events for 1 test
> > > analysis I use for validation is failing with the following error:
> > >
> > > unable to load
> > > /afs/cern.ch/work/x/xjanssen/cms/Rivet/10X_gcc630_Rivet260/CMSSW_10_0_0_pre3/lib/slc6_amd64_gcc630/pluginGeneratorInterfaceRivetInterface_plugins.so
> > > <http://cern.ch/work/x/xjanssen/cms/Rivet/10X_gcc630_Rivet260/CMSSW_10_0_0_pre3/lib/slc6_amd64_gcc630/pluginGeneratorInterfaceRivetInterface_plugins.so>
> > > because dlopen: cannot load any more object with static TLS
> > >
> > > where pluginGeneratorInterfaceRivetInterface_plugins.so is our
> > > standard interface to Rivet. Just to be sure I tested back Rivet
> > > 2.5.4 in the same CMS software release and I don’t get any such
> > > problem. Not sure exactly what is happening but what did you
> > > exactly changed in the compilation/loading of analysis in the
> > > latest release ?
> > >
> > > Cheers, Xavier.
> > > _______________________________________________
> > > Rivet mailing list
> > > Rivet at projects.hepforge.org <mailto:Rivet at projects.hepforge.org>
> > > https://www.hepforge.org/lists/listinfo/rivet
> >
> >
> >
> > _______________________________________________
> > Rivet mailing list
> > Rivet at projects.hepforge.org
> > https://www.hepforge.org/lists/listinfo/rivet
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20180111/1dd23616/attachment.html>