Hello Yuri,
On Thu, Mar 7, 2013 at 6:54 PM, Yuri Gershtein <[log in to unmask]
edu> wrote:
> 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.
>
If you simple want to read LCIO files using the C++ API, I would start
here:
https://confluence.slac.stanford.edu/display/hpsg/Loading+LCIO
+Files+into+ROOT
Here you will find all the instructions needed to install the LCIO library
and will find a couple of examples.
If you want access to my code it is in a github. You can clone the
repousing the following command:
git clone https://github.com/omar-moreno/hps_dst/
The repo will contain the converter and the API used to access the
event information. In order to build the binaries, simply use the
Make command. Note that you need to make sure that the environmental
variables described in the first link have been set correctly in order
for the make command to work.
Once the binaries are made you can get usage information as follows:
./bin/write_hps_event -h
If you look at the converter code, it should give you an idea of how
to loop over an LCIO event, access collections and so on. Also, if
you run the following command
./bin/write_hps_event -i <lcio file> -d
If will dump a printout of the collections available in the lcio file.
Something like this
---------------------------------------------------------------------------
COLLECTION NAME COLLECTION TYPE NUMBER OF ELEMENTS
===========================================================================ConfirmedMCParticles
MCParticle 0EcalCalHits
CalorimeterHit 2EcalClusters
Cluster 1EcalReadoutHits
RawCalorimeterHit 12FPGAData
LCGenericObject 7HelicalTrackHitRelations
LCRelation 0HelicalTrackHits
TrackerHit 0HelicalTrackMCRelations
LCRelation 0MatchedTracks Track
0RotatedHelicalTrackHitRelationsLCRelation
0RotatedHelicalTrackHits TrackerHit
0RotatedHelicalTrackMCRelationsLCRelation
0SVTFittedRawTrackerHits LCRelation
43SVTRawTrackerHits TrackerRawData
43SVTShapeFitParameters LCGenericObject
43SeededMCParticles MCParticle
0StripClusterer_SiTrackerHitStrip1DTrackerHit
0TriggerBank LCGenericObject 1
---------------------------------------------------------------------------
This will give you the collection names you can access using the LCIO C++ API.
I must note that there are a lot of changes that I haven't pushed yet.
I hoping to do that sometime this weekend once I have sometime I am
happy with.
Let me know if you have any questions or issues running it.
--Omar Moreno
>
> -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
