 |
 |
Hi Tim, > > Sorry... I didn't mean to ding you for not googling first, ;) no harm done. > > I think all of your questions are good ones that we don't have answers to yet, and are the types of things we are grappling with in these discussions. I guess I propose we figure out the boundary conditions resource-wise that we're dealing with first, and then figure out what kind of event content we can afford. The question of ROOT vs LCIO here is probably separate. ROOT is pretty good at packing the data, but then again I guess LCIO is as well, so size-wize this should not matter, correct? And if I can write a C++ program that reads in a file and writes out a root tree, this is just my analysis job. I.e. even in CMS, where all data, even RAW, are root files, I make another root tree for my own analyses purposes, and I actually see advantages in having LCIO microDSTs. An Ntuplizer that has TClonesArrays of some simple classes is pretty straightforward to write once we know the content, so I do not see how this is worth an argument at this point... How do I get Omar's code? I'd like to see if we can start using C++ to read in lcio files that we generate here at Rutgers. -y > > Tim > > On Mar 7, 2013, at 5:23 PM, Yuri Gershtein <[log in to unmask]> wrote: > >> Hi Tim, >> >> thanks, and apologies for not googling things before asking. >> >>> Yes, certainly, it is practical. LCIO was long ago settled on as the EDM for HPS and the LCIO output will be the raw output format of the experiment. Like any persistency framework, we can decide exactly what parts of the events we can afford to output to tape. That content has not yet been settled. There are some things that for whatever reason haven't been persisted as LCIO objects in the past (but should be) and there are other things we have been writing to the events that won't be feasible to keep when we have large volumes of data. >> >> Should we have this discussion with some concrete numbers for what the event sizes are going to be then and what computing / storage resources >> are going to be available at which sites? >> >>> One could make an LCIO micro-DST also, but it seems the desire is to convert to ROOT at the point of slimming the data for analysis. >> >> Oh, I'm all for it, but there is also value in being able to run the same or similar code on DST or micro-DST… >> It's also would be great to define what is meant by "analysis" here - >> is alignment analysis? ECAL calibration? Development of electron ID? >> Do you foresee that it is all done in DST, or you have a separate calibration stream? >> >> Again, sorry, I'm just trying to come up to speed with the computing model, >> may be I can google those kind of questions as well… >> >> thanks, >> -y >> >> -------------------------- >> Prof. Yuri Gershtein >> [log in to unmask] >> http://physics.rutgers.edu/~gershtein >> (732)445-5500 x1794 >> W316 Serin Building >> Department of Physics and Astronomy >> 136 Frelinghuysen Rd >> Rutgers University >> Piscataway, NJ 08854 >> > > -------------------------- Prof. Yuri Gershtein [log in to unmask] http://physics.rutgers.edu/~gershtein (732)445-5500 x1794 W316 Serin Building Department of Physics and Astronomy 136 Frelinghuysen Rd Rutgers University Piscataway, NJ 08854 ######################################################################## 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