[Rivet] Memory error

[David Bjergaard]

Hi Andy,

Not to hijack the thread, but using ROOT to dump a tree of events from a rivet
analysis is useful when you're doing exploratory analyses and want to see how
things are correlated at the generator level.


    David

Andy Buckley <andy.buckley at cern.ch> writes:

> Exactly what it says: Rivet's configure doesn't have an --enable-root
> option. Maybe you're thinking of YODA?
>
> You can pass linker flags for ROOT to the rivet-buildplugin script if
> you want, but we don't have any "official" support for it.
>
> Out of interest, what ROOT features do you require?
>
> Andy
>
>
> On 21/10/16 17:28, Alan Kaptanoglu wrote:
>> I have tried just --enable-root as well.
>>
>> On Fri, Oct 21, 2016 at 6:28 PM, Alan Kaptanoglu
>> <alank2 at alumni.stanford.edu <mailto:alank2 at alumni.stanford.edu>> wrote:
>>
>>     Another question, this time regarding linking rivet with ROOT. I
>>     have tried adding the line --enable-root to my configure file and
>>     re-installing but it complains:
>>     configure: WARNING: unrecognized options: --enable-root, --with-root
>>     and I am unsure how to proceed.
>>
>>     Best,
>>     Alan
>>
>>     On Mon, Oct 17, 2016 at 5:38 PM, Alan Kaptanoglu
>>     <alank2 at alumni.stanford.edu <mailto:alank2 at alumni.stanford.edu>> wrote:
>>
>>         Thank you very much! I read that in useJetArea() but was not
>>         sure how to get around it. Your line "  fj.useJetArea(new
>>         fastjet::AreaDefinition(fastjet::VoronoiAreaSpec()));" works
>>         perfectly. Passing it by value was a typo!
>>
>>         Cheers,
>>         Alan
>>
>>         On Mon, Oct 17, 2016 at 4:47 PM, Andy Buckley
>>         <andy.buckley at cern.ch <mailto:andy.buckley at cern.ch>> wrote:
>>
>>             On 17/10/16 15:29, Alan Kaptanoglu wrote:
>>
>>                 Hello,
>>
>>                 I am trying to declare jets with area in the
>>                 initialization section of
>>                 my Rivet Analysis. I originally tried:
>>
>>                       fastjet::GhostedAreaSpec areaspec(2.5,1,0.01);
>>                       fastjet::AreaDefinition
>>                 area_def(fastjet::active_area_explicit_ghosts,areaspec);
>>                       FastJets jets(vfs, FastJets::ANTIKT, Rsmall);
>>                       jets.useJetArea(area_def);
>>                       jets.useInvisibles(JetAlg::ALL_INVISIBLES);
>>                       jets.useMuons(JetAlg::DECAY_MUONS);
>>                       declare(jets, "jets");
>>
>>                 but this definition goes out of scope so when I ask for
>>                 jet areas in my
>>                 "analysis" section of my code, it complains the jets
>>                 have no valid jet
>>                 area associated with them. I next tried several versions of:
>>
>>                       areaspec = new fastjet::GhostedAreaSpec(2.5,1,0.01);
>>                       area_def = new
>>                 fastjet::AreaDefinition(fastjet::active_area_explicit_ghosts,*areaspec);
>>                       FastJets jets(vfs, FastJets::ANTIKT, Rsmall);
>>                       jets.useJetArea(area_def);
>>                       jets.useInvisibles(JetAlg::ALL_INVISIBLES);
>>                       jets.useMuons(JetAlg::DECAY_MUONS);
>>                       declare(jets, "jets");
>>
>>                 where areaspec and area_def are private members of my
>>                 Analysis class. I
>>                 also tried initializing these variables in my
>>                 constructor using
>>                 initialization lists, as well as declaring them global
>>                 variables (and
>>                 yes, to my knowledge, I am also deleting them correctly
>>                 if I use "new").
>>                 In all these cases, the code runs correctly but
>>                 complains at the end of
>>                 a memory error, which is attached in a text file. Any
>>                 idea why this is
>>                 happening or how to fix?
>>
>>
>>             Hi Alan,
>>
>>             The AreaDefinition provided to FastJets must be a
>>             heap-allocated pointer whose ownership is then taken over by
>>             the FastJets object: it will delete the pointer at the end
>>             of the run so you shouldn't try to do that yourself. (This
>>             is documented on the useJetArea() function)
>>
>>             To this end I usually make sure that I don't have a variable
>>             of my own pointing at that area def objects, e.g.
>>              fj.useJetArea(new
>>             fastjet::AreaDefinition(fastjet::VoronoiAreaSpec()));
>>
>>             As you noticed, if you pass in a locally allocated object,
>>             it goes out of scope and you get a crash. Although I'm not
>>             sure how you're able to pass it in by value rather than by
>>             pointer!
>>
>>             I would like, if possible, to avoid this pointer ownership
>>             stuff in the FastJets interface... I'm sure it's possible,
>>             just needs a bit of care and thought about backward
>>             compatibility. Pointers were used historically because we
>>             need the option of a null AreaDefinition, and there's no
>>             such thing as a null reference in C++.
>>
>>             Hope that helps,
>>             Andy
>>
>>             --
>>             Dr Andy Buckley, Lecturer / Royal Society University
>>             Research Fellow
>>             Particle Physics Expt Group, University of Glasgow
>>
>>
>>
>>