I believe if you load the DST library before issuing the command it works.
Worth a shot ...
On Tue, Jan 23, 2018 at 11:16 AM, Nathan Baltzell <[log in to unmask]> wrote:
> I thought the TRefArrays prevented from even being able to … maybe there’s
> a way?
>
>
> > On Jan 23, 2018, at 14:03, Graham, Mathew Thomas <
> [log in to unmask]> wrote:
> >
> >
> > Yeah, that’s the advantage of a flat ntuple…it’s tough to use a deep
> ntuple at the ROOT command line. That’s what macros are for.
> >
> >> On Jan 23, 2018, at 10:05 AM, Sebouh Paul <[log in to unmask]>
> wrote:
> >>
> >> One advantage of the ntuples is that it is easier to write code to make
> plots, since the names of variables tend to be shorter. Secondly, there's
> the issue with TRefArray in the DSTs.
> >>
> >> For instance, plotting the mass spectrum of mollers would be in ntuples:
> >>
> >> ntuple->Draw("tarM>>h(300, 0.03, 0.07)", "abs(topTrkT-botTrkT)<3 &&
> topTrkChisq < 30 && botTrkChisq < 30 && botP < 1.75 && topP < 1.75")
> >>
> >> (these correspond to track time difference of 3 ns, both tracks have
> chi^2 < 30, and an FEE cut on both tracks at 1.75 GeV)
> >>
> >> Whereas in the DSTs, you could try the equivalent, which would be like
> >>
> >> HPS_Event->Draw("tc_moller_candidates.mass>>h(300, 0.03, 0.07)",
> "abs(tc_moller_candidates.svt_tracks[0].track_time[0]-tc_
> moller_candidates.svt_tracks[1].track_time)<3 && tc_moller_candidates.svt_tracks[0].chi_squared
> < 30 && tc_moller_candidates.svt_tracks[1].chi_squared < 30 &&
> tc_moller_candidates.particles[0].pz < 1.75 && tc_moller_candidates.particles[1].pz<
> 1.75")
> >>
> >> However, not only is this cumbersome code, it also fails to run, since
> it complains about not being able to find the classes for things:
> >>
> >> Is there some library that I am supposed to load before running
> this? Or is this bad syntax? If there is a way to do what I am trying to
> do, I stand corrected, and please let me know how to do it.
> >>
> >>
> >> On Mon, Jan 22, 2018 at 10:44 AM, Graham, Mathew Thomas <
> [log in to unmask]> wrote:
> >>
> >> I haven’t used “the" ntuple (though I have used the ntuplemaker for
> some stuff where I had to re-run the reconstruction myself, and I think
> it’s very useful).
> >>
> >> I really like the DSTs because it contains (almost) all of the data for
> an event so, besides just making your selection and looking at your e+e-
> candidate, you can look at what else is going on in the event. I know that
> the ntuple had added a lot of the information in a “flat” way, but adding
> new info requires remaking the ntuple instead of just re-running a root
> macro.
> >>
> >> Now, maybe there are some calculations done in the making of the flat
> ntuple that can’t be done in the DST? Like something that requires the
> geometry?
> >>
> >>
> >>> I would like to see if the time is here to really get going on a
> discussion about our data summary output. From what I observe, there is a
> quick hack that started with Sho and that grew organically into what is now
> the Tuple Maker. There is a lot to be said for this system, including that
> it is used by quite a few of you, but I don’t think I could argue this is
> the ideal situation. The recent effort to re-factor it and document it was
> excellent. Was that enough? Can this system be considered production ready
> now?
> >>> We also have a DST maker, which Omar produced and maintains, which had
> some thought go into the design, but it seems does not fit people’s needs,
> else there would be no need for a tuple maker. What would make the DST
> maker universal?
> >>>
> >>> So, now that we have some experience with all this, I would like to
> start a discussion on what it is that we actually want for a DST output,
> and how would we get there. I would like this to be a discussion at our
> next software meeting, but if that is too soon, we can also discuss it in
> the next one.
> >>>
> >>> Can someone present the pro side of the tuple maker? Holly? Miriam?
> >>> Can someone present the pro side of the DST maker? Omar?
> >>> What are the limitations in either of the implementations?
> >>>
> >>> To get you thinking about the topic, let me make some controversial
> statements:
> >>>
> >>> • Is the underlying reason for the Tuple maker, and the clunky
> Java to text file to ROOT mechanism, that LCIO is simply a horrible data
> format?
> >>> • So should we get rid of LCIO then, which seems to have
> hampered our ability to write the data we want to write on many occasions?
> >>> • If not, why the text file?
> >>> • Is there an issue with how we use, and understand, the ROOT file
> format, and the various ways in which you can use it to access structured
> data?
> >>> • Do we want the data structured, or do we prefer a simple
> tuple because it is easier?
> >>> • We risk making mistakes in the analysis because we do not know
> exactly what went into our output. We also risk wasting people’s time if
> they started out with the “wrong” dst and then have to switch to the other
> one. How do we avoid these pitfalls?
> >>> • Is this not really a concern? Nothing to see here, carry
> on….
> >>>
> >>> I hope we can find our way out of what appears to me is our current
> not so great situation.
> >>>
> >>> Best regards,
> >>> Maurik
> >>>
> >>>
> >>> Use REPLY-ALL to reply to list
> >>>
> >>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
> >>>
> >>
> >>
> >> Use REPLY-ALL to reply to list
> >>
> >> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
> >>
> >>
> >
> >
> > Use REPLY-ALL to reply to list
> >
> > To unsubscribe from the HPS-SOFTWARE list, click the following link:
> > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
> >
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
