-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DSTs instead of nTuples #7
Comments
👍 |
Yes, that would be interesting. There are two options, you make a simple filter on tour stripping line and write out all events. This is quite easy to configure. The second option is to write out a micro DST which contains only your candidate. This has a much lower event size. I always wanted to learn how to do that but never got around it. However, this is what is done in the stripping as well, so one can probably learn from that. |
Yes, we could use that to teach This reminds me of the classic Ruf presentation: On Thu, Nov 26, 2015 at 11:08 AM, Sascha Stahl [email protected]
Dr. Albert Puig Navarro |
The Ruf classic is what made me push so hard for the interactive DST exploring lesson. I think doing your actual analysis on a DST is still a bit tedious though as it doesn't load fast enough. Dumping stuff into a So conclusion is we include this in this set of lessons? Let's decide that first before going off into dreamland of what could be. |
I'm not sure, honestly... As you say, it's more cumbersome than On Thu, Nov 26, 2015 at 12:49 PM, Tim Head [email protected] wrote:
Dr. Albert Puig Navarro |
Yeah, I think it is a bit "smarter" than dumping everything into a tree and cutting this down. |
I recently started playing around with this. I made a µDST with the output of two Turbo lines, and then ran a For a few thousand events that contained my signal, the input µDST from the bookkeeping was 4.6 GB and the output µDST was 70 MB. The filtering step was straight-forward for my use case, though I suspect adding things like raw banks (for flavour tagging and stuff) takes a little more care. |
my 2 grumpy cents: i'd be sad to let ntuples go, as TTree:Draw is extremely powerful once you exploit that both, the variable you draw and the weight (NB: the second argument is not a cut string, it returns a float!) support bool, int and float operations: |
Reading the initial post, I would say that this is meant less as "DSTs instead of nTuples" and more as "DSTs in addition to nTuples". |
@ibab is right, the (µ)DST step is meant as an intermediary to making ntuples as one would normally. The primary use case, at least for me, is rerunning my ntuple creation when I realise I'm missing some variables, or am asked to investigate things I hadn't foreseen (e.g. running |
ack. which reminds me, i think christian (rostock) once told me he'd use µDST as OO ntuple. maybe one can ask for longterm experience. also realised another advantage: if you use µDST anyhow as ntuple, you don't have code which only works in DaVinci and code which only works on ntuples. (and then you have to translate your ntuple code once you need its output as stripping variable or relatedinfo on µDST). |
However, working with µDST (which I like in principle) makes things more I like having only ROOT because I can work on the Mac or offline, but if BTW: this would be a DREAM come true. |
so (back to topic): and then add a lesson "cool stuff you can do with a µDST instead of writing an ntuple" |
Agreed! 👍 |
👍 |
Not even sure we'd want to have "replace your nTuple with a uDST". Maybe On Fri, Dec 18, 2015 at 10:17 AM Alex Pearce [email protected]
|
Agreed, the title should be different. Paul summarized very well what I had in mind. |
This could be an interesting topic to cover.
Lucio pointed out during the computing workshop in Paris (Nov 2015) that you could simply write a DST instead of a DecayTreeTuple from your grid jobs. The average size per event should be comparable but you can access "all the information". Once you have your DST you can then remake your nTuple as many times as you wish, potentially even locally without the grid.
I think this is a nice idea to reduce the pain of having huge nTuples with all the branches, re-running things on the grid missing some events, etc.
The text was updated successfully, but these errors were encountered: