[Rivet] Fwd: Memory error

Alan Kaptanoglu alank2 at alumni.stanford.edu
Mon Oct 24 10:07:31 BST 2016


---------- Forwarded message ----------
From: Alan Kaptanoglu <alank2 at alumni.stanford.edu>
Date: Mon, Oct 24, 2016 at 11:07 AM
Subject: Re: [Rivet] Memory error
To: andy.buckley at cern.ch


Thanks. Do I need some of the header files from the example file? I am
compiling with the --with-root flag but it is not accepting my #ifndef
HAVE_ROOT. Perhaps I need the AIDA namespace? I do not appear to have
RivetAIDA.hh in my include directory.

Best,
Alan

On Mon, Oct 24, 2016 at 10:55 AM, Andy Buckley <andy.buckley at cern.ch> wrote:

> Ok, thanks. Well, something like that old analysis should still be usable:
> just create a ROOT tree in the init(), fill in analyze(), and close/write
> in finalize().
>
> To do the linking against ROOT, you should be able to compile your plugin
> with something like rivet-buildplugin --with-root MY_ANALYSIS.cc
>
> Cheers,
> Andy
>
>
> On 24/10/16 09:35, Alan Kaptanoglu wrote:
>
>> Thanks for the replies. Exactly as David said. I would like to dump
>> trees from rivet and use a multivariate analysis tool like tvma. I found
>> an admittedly ancient rivet script that seems to do this but I am unsure
>> if something like this is still supported in the newer rivet versions (I
>> am running 2.5.1.).
>> https://rivet.hepforge.org/trac/attachment/ticket/95/ExampleTree.cc
>>
>> Let me know if there is something that can be done. Thanks again!
>>
>> Best,
>> Alan
>>
>> On Sat, Oct 22, 2016 at 1:29 AM, Andy Buckley <andy.buckley at cern.ch
>> <mailto:andy.buckley at cern.ch>> wrote:
>>
>>     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
>>         <mailto: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>
>>                 <mailto: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>
>>                 <mailto: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>
>>                 <mailto: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(fastje
>> t::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
>>
>>
>>
>
> --
> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20161024/c63cd1a7/attachment.html>


More information about the Rivet mailing list