Print

Print



Hi Omar,

as I mentioned, I followed these instructions and they worked perfectly for me on my Mac.

Now my new student Andrew (Andrew meet the software experts, software experts meet Andrew)
Running Ubuntu 12.04 LTS 64 bit, the instructions break.
I.e. when he does make install he gets an error with the following disgnostics:

 56%] Building CXX object
lcio/CMakeFiles/lcioDict.dir/__/rootdict/UTIL.cxx.o
In file included from
/home/chill/Research/lcio/trunk/build/rootdict/UTIL.h:39:0,
                from
/home/chill/Research/lcio/trunk/build/rootdict/UTIL.cxx:17:
/home/chill/Research/lcio/trunk/src/cpp/include/UTIL/LCIterator.h: In
constructor ‘UTIL::LCIterator<T>::LCIterator(EVENT::LCEvent*, const
string&)’:
/home/chill/Research/lcio/trunk/src/cpp/include/UTIL/LCIterator.h:69:10:
error: ‘lcio’ has not been declared
/home/chill/Research/lcio/trunk/src/cpp/include/UTIL/LCIterator.h: In
constructor ‘UTIL::LCIterator<T>::LCIterator(EVENT::LCCollection*)’:
/home/chill/Research/lcio/trunk/src/cpp/include/UTIL/LCIterator.h:89:10:
error: ‘lcio’ has not been declared
make[2]: *** [lcio/CMakeFiles/lcioDict.dir/__/rootdict/UTIL.cxx.o] Error 1
make[1]: *** [lcio/CMakeFiles/lcioDict.dir/all] Error 2
make: *** [all] Error 2


We just went together through the instructions from scratch, and the error persists.
Did you see anything like that before?

Since we are uploading things from the trunk, is it possible that the version he just downloaded is a 
different one?

Thanks!
-y


On Mar 7, 2013, at 10:20 PM, Omar Moreno wrote:


Hello Yuri, 

On Thu, Mar 7, 2013 at 6:54 PM, Yuri Gershtein <gershtein@physics.rutgers.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: 

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 repo using 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                       0
EcalCalHits                   CalorimeterHit                   2
EcalClusters                  Cluster                          1
EcalReadoutHits               RawCalorimeterHit               12
FPGAData                      LCGenericObject                  7
HelicalTrackHitRelations      LCRelation                       0
HelicalTrackHits              TrackerHit                       0
HelicalTrackMCRelations       LCRelation                       0
MatchedTracks                 Track                            0
RotatedHelicalTrackHitRelationsLCRelation                       0
RotatedHelicalTrackHits       TrackerHit                       0
RotatedHelicalTrackMCRelationsLCRelation                       0
SVTFittedRawTrackerHits       LCRelation                      43
SVTRawTrackerHits             TrackerRawData                  43
SVTShapeFitParameters         LCGenericObject                 43
SeededMCParticles             MCParticle                       0
StripClusterer_SiTrackerHitStrip1DTrackerHit                       0
TriggerBank                   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
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