cms-analysis / HiggsAnalysis-KITHiggsToTauTau

http://cms-analysis.github.io/HiggsAnalysis-KITHiggsToTauTau/
6 stars 18 forks source link

Artus Runtime Erro #34

Closed rfriese closed 8 years ago

rfriese commented 8 years ago

Hi all,

with the current master I just tried to run HiggsToTauTauAnalysis.py @HiggsAnalysis/KITHiggsToTauTau/data/ArtusWrapperConfigs/Run2Analysis.cfg -i /pnfs/desy.de/cms/tier2/store/user/rfriese/higgs-kit/skimming/80X_2016-08-04/GluGluHToTauTau_M120_13TeV_powheg_pythia8/crab_GluGluHToTauTauM120_RunIISpring16MiniAODv2reHLT_PUSpring16RAWAODSIM_13TeV_MINIAOD_powheg-pythia8/160804_130622/0000/kappa_GluGluHToTauTauM120_RunIISpring16MiniAODv2reHLT_PUSpring16RAWAODSIM_13TeV_MINIAOD_powheg-pythia8_1.root

That crashes with the following erro `` Warning in TClass::TClass: no dictionary for class CrystalBallEfficiency is available [#1] INFO:ObjectHandling -- RooWorkspace::CodeRepo::compileClasses() reusing code export directory .wscode.14d10e16-5982-31e6-9717-f3edb5cb0f6e.w to extract coded embedded in workspace [#1] INFO:ObjectHandling -- RooWorkspace::CodeRepo::compileClasses() Compiling code unit CrystalBallEfficiency to define class CrystalBallEfficiency Info in TUnixSystem::ACLiC: creating shared library /afs/desy.de/user/r/rfriese/xxl/analysis/CMSSW_7_1_5/src/.wscode.14d10e16-5982-31e6-9717-f3edb5cb0f6e.w/CrystalBallEfficiency_cxx.so /cvmfs/cms.cern.ch/slc6_amd64_gcc481/external/gcc/4.8.1/bin/../lib/gcc/x86_64-redhat-linux-gnu/4.8.1/../../../../x86_64-redhat-linux-gnu/bin/ld: cannot find libtbb.so.2 collect2: error: ld returned 1 exit status Error in : Compilation failed! [#0] ERROR:ObjectHandling -- RooWorkspace::CodeRepo::compileClasses() ERROR compiling class CrystalBallEfficiency, to fix this you can do the following: 1) Fix extracted source code files in directory .wscode.14d10e16-5982-31e6-9717-f3edb5cb0f6e.w/ 2) In clean ROOT session compiled fixed classes by hand using '.x .wscode.14d10e16-5982-31e6-9717-f3edb5cb0f6e.w/ClassName.cxx+' 3) Reopen file with RooWorkspace with broken source code in UPDATE mode. Access RooWorkspace to force loading of class Broken instances in workspace will not be compiled, instead precompiled fixed instances will be used. 4) Reimport fixed code in workspace using 'RooWorkspace::importClassCode("*",kTRUE)' method, Write() updated workspace to file and close file 5) Reopen file in clean ROOT session to confirm that problems are fixed Error in TBufferFile::ReadObject: trying to read an emulated class (CrystalBallEfficiency) to store in a compiled pointer (TObject)

* Break * segmentation violation ``

I pulled and tried a scram b clean... did I miss something one should have been doing?

Cheers

anehrkor commented 8 years ago

Hi Raphael,

sorry, I forgot to mention this earlier but you error might be related to the RooWorkspaceWeightProducer. If you use CMSSW_7_4_7 (and checkout v6.2.1 of combine!) it should work - at least it does in my case. We might want to think about switching to 7_4_7 altogether.

Best, Alex

rcaspart commented 8 years ago

Hi Raphael, Alex,

just as Alex said this is due to the workspace used in the RooWorkspaceWeightProducer. Basically the workspace checks if the class CrystalBallEfficiency is already in the root-dictionary and if not tries to build it on the fly. For me this worked fine on the login nodes but unfortunately did not seem to work reliably on all workernodes of the naf batch system (on some of them it failed with an error similar to your error). As Alex already mentioned the way to mitigate this is to have the CrystalBallEfficiency already available in your root-dictionary. This can for instance be done within libKappa [*]. However this does not seem to work for CMSSW_7_1_5 (most likely due to a different include structure; building libKappa works fine but compiling the rest with the changes for libKappa in place fails), but for example in CMSSW_7_4_7 it works fine.

[*] https://github.com/rcaspart/Kappa/tree/crystalball

anehrkor commented 8 years ago

Is there a reason against switching to CMSSW_7_4_7 altogether? If not, we could adjust the checkout recipe and everyone can switch to the newer version.

thomas-mueller commented 8 years ago

Before we switch to this version, we should check, that all our tools still work, especially since this would also mean to switch from ROOT 5 to 6.

Alex told me that for combine this should not be a problem. The remaining question then is just, if all our own tools (and TMVA) works with ROOT 6. I remember, that Stefan did some checks months ago. What is the status there? Rene, did you run everything (Artus, HP) with ROOT 6 already and can convince us, that it works?

rfriese commented 8 years ago

Hi all,

I would even say we should change to the the something on 80X (e.g. 8_0_14 like in Kappa) because it has gcc530 which comes with many advantages....

Cheers, Raphael

On 13.08.2016 16:54, anehrkor wrote:

Is there a reason against switching to CMSSW_7_4_7 altogether? If not, we could adjust the checkout recipe and everyone can switch to the newer version.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cms-analysis/HiggsAnalysis-KITHiggsToTauTau/issues/34#issuecomment-239624760, or mute the thread https://github.com/notifications/unsubscribe-auth/AE4HjujQ0lT8yVuRPrt9rRG3U22z50Dvks5qfdqYgaJpZM4Jjgfx.

Raphael Friese

Karlsruhe Institute of Technology (KIT) Kaiserstraße 12 Building 30.23 / R 8-22 76131 Karlsruhe, Germany Phone: +49 721 608-47243

CERN Building 32-4 B06 Phone: +41 22 76-78267

Email: Raphael.Friese@cern.ch

anehrkor commented 8 years ago

The problem is that there is no recommended 80X release for combine, yet. So this is unfortunately not an option at the moment.