 |
 |
Hello Yuri, Thanks for your interest. We could better provide you with more detailed responses and examples on how to get started if we knew a little more what your analysis domain was. Do you have a particular area of interest? Active, engaged analysts are what will drive this endeavor much more effectively than speculative discussions, so we welcome your participation. DSTs are envisioned for "physics" analyses. I.e. the files would contain things like ReconstructedParticle objects (including reconstructed Vertex objects) with which you would perform your bump hunts. These would be provided in LCIO, and some corresponding root file. See Stepan's proposal for what would constitute the root DST. Event reconstruction-type analyses should be done on LCIO files. We do not plan to replicate the event data model in root, so when accessing lower-level objects you will need to become conversant with the LCIO API. You have your choice of C++, Java, python and yes, even FORTRAN. The LCIO distribution comes with a root dictionary, so you can fire off a root session, load the dictionary, open an LCIO file and start looking at the data. Please let us know how we can best assist you. Norman ________________________________ From: Yuri Gershtein [[log in to unmask]] Sent: Thursday, March 07, 2013 5:23 PM To: Nelson, Timothy Knight Cc: McCormick, Jeremy I.; Neal, Homer A.; Jaros, John A.; Graham, Mathew Thomas; Graf, Norman A.; Moreno, Omar; Maurik Holtrop; hps-software Subject: Re: DSTs and work on slcio files using C++ 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]<mailto:[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