[Rivet] Memory error

[Andy Buckley]

I know... not asking about whether ROOT in general has uses (!), but 
what Alan specifically wanted it for. It's possible that we have 
something built-in but not well-advertised...

Andy


On 21/10/16 23:02, David Bjergaard wrote:
> 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
>>>
>>>
>>>
>>>


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