[Rivet] Rivet on afs

[Dmitri Konstantinov]

Hello Andy, Hello Katrhin,

I would propose to use our GENSER environment scripts provided for each 
package.

source 
/afs/cern.ch/sw/lcg/external/MCGenerators_lcgcmt67c/rivet/2.2.0/x86_64-slc6-gcc47-opt/rivetenv-genser.sh 


I think Kathrin doesn't have properly defined gcc environment for given 
gcc versions - gcc47, while default(system) lxplus compiler is gcc 4.4

Cheers,
      Dima



On 11/17/14 3:13 PM, Andy Buckley wrote:
> Hi Kathrin,
>
> I have copied this to the Rivet developer mailing list -- please send
> queries there rather than to me.
>
> I'm not sure about this issue -- it looks to me like the Genser build of
> Rivet/YODA was made using a different build of GCC than the one
> available via setupATLAS. We do not use libquadmath at all, so it is
> something that has been linked in by default.
>
> I suspect that finding a copy of libquadmath on AFS and putting its
> containing directory into your LD_LIBRARY_PATH variable would solve the
> problem, but there should be a standard environment setup for using LCG
> builds without having to do manual tweaks like that. I've copied in the
> LCG application area manager and Generator Services team, who I hope can
> provide an answer. I would also like to know, so I can provide easy
> instructions to use Genser's Rivet build, for non-ATLAS users.
>
> Best wishes,
> Andy
>
>
> On 17/11/14 10:52, Kathrin Becker wrote:
>> Dear Andy,
>>
>> I'm sorry to bother you again. I tried today to switch away from the
>> experimental version of rivet to the other one in afs.
>> I followed your instructions in the email.
>> But if I now do rivet-cmphistos I get the following error.
>> [becker at pplxint9 valplots_WW]$ rivet-cmphistos
>> mc12_8TeV.181416.PowhegPythia8_AU2CT10_HJ_MINLO_ggH125_WW2lep_EF_15_5.evgen.EVNT.e2177_tid01320008_00.yoda
>> mc12_8TeV.161224.PowhegPythia8_AU2CT10_ggH125_WW2lep.evgen.EVNT.e2363_tid01352492_00.yoda
>> 181999.HJ_MINLO_CT10nnlo_8TeV.yoda
>> 181997.H_NNLO_22_11_CT10nnlo_8TeV.yoda less standaloneSetupRivet.sh
>> Traceback (most recent call last):
>>    File
>> "/afs/cern.ch/sw/lcg/external/MCGenerators_lcgcmt67c/rivet/2.2.0/x86_64-slc6-gcc47-opt/bin/rivet-cmphistos",
>> line 13, in <module>
>>      import rivet, yoda, sys, os
>>    File
>> "/afs/cern.ch/sw/lcg/external/MCGenerators_lcgcmt67c/rivet/2.2.0/x86_64-slc6-gcc47-opt/lib/python2.7/site-packages/rivet/__init__.py",
>> line 12, in <module>
>>      from rivet.core import *
>> ImportError: libquadmath.so.0: cannot open shared object file: No such
>> file or directory
>>
>> Do you have an idea what I'm doing wrong?
>> Thank you for your help!
>> Cheers,
>> Kathrin
>>
>>
>>
>> On 11/12/2014 06:55 PM, Andy Buckley wrote:
>>> On 12/11/14 16:42, Kathrin Becker wrote:
>>>> Dear Andy,
>>>>
>>>> maybe you have already gotten tons of messages about this... But just in
>>>> case you haven't:
>>> Actually I didn't get lots of emails about this... you're the first.
>>> Yes, I was surprised too!
>>>
>>>> Is there a reason why the rivet on afs has been move from
>>>> /afs/cern.ch/sw/lcg/experimental/rivet/ to
>>>> /afs/cern.ch/sw/lcg/experimental/rivet/bak/ ?
>>>> Thus, all setup scripts don't work anymore.
>>>> Should we use a different rivet, that is located somewhere else?
>>> Yes, that's right! That area was never meant for production use -- the
>>> hint is in the "experimental" bit of the path! The version in there was
>>> a pre-release version from about 2 years ago; and was subject to change
>>> at any time (I'll use it again if I ever need to make a slightly public
>>> pre-release copy available for testing.)
>>>
>>> I just added a README file to that directory explaining how to set up a
>>> reliable existing AFS Rivet build, but here's the short version:
>>>
>>> setupATLAS
>>> localSetupPython 2.7.3-x86_64-slc6-gcc47
>>> source
>>> /afs/cern.ch/sw/lcg/external/MCGenerators_lcgcmt67c/rivet/2.2.0/x86_64-slc6-gcc47-opt/rivetenv.sh
>>>
>>>
>>>> PS: I only use rivet outside of Athena to do make-plots, as this
>>>> sometimes doesn't work when athena is setup.
>>> Hmm, that's odd. How does it go wrong, and with what release(s)?
>>>
>>> Andy
>>>
>