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