[Rivet] Fwd: Memory error

[Alan Kaptanoglu]

Thanks everybody, I figured it out.

Best wishes,
Alan

On Mon, Oct 24, 2016 at 3:33 PM, Andy Buckley <andy.buckley at cern.ch> wrote:

> Also, there's no need for a WITH_ROOT preprocessor variable if you're
> writing your own ROOT-using analysis. rivet-buildplugin doesn't provide any
> such variable, and we removed it from the Rivet core along with the move
> from AIDA -> YODA a few years ago.
>
> Andy
>
>
>
> On 24/10/16 13:29, David Bjergaard wrote:
>
>> Hi Alan,
>>
>> The AIDA framework was replaced with Yoda, so you may have to tweak some
>> of
>> those headers/remove them if you are using root to just dump the tree.
>>
>>     David
>>
>>
>> Alan Kaptanoglu <alank2 at alumni.stanford.edu> writes:
>>
>> ---------- 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(fastjet::active_area_explicit_ghost
>>> s,*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
>>>
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> https://www.hepforge.org/lists/listinfo/rivet
>>
>>
>
> --
> 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/dfc14214/attachment.html>