Hi, Matt.

I don't think we're really that close to being able to use lcsim reconstruction on the raw data....

We still need a good set of ECAL calibrations in the conditions database (pedestals/noise).  I'm hoping we have this by the end of the week.  Code exists to generate these automatically in lcsim.  There will be more discussion about this at tomorrow's software meeting.  We need this for pedestal subtraction on the ADC data for raw mode and integral hits.

We do not have gain calibrations per channel for the <gain * ADC> conversion to energy from the raw hits in lcsim.  I think there has been some work on this in EVIO based C code and scripts, but there isn't any code for generating the gain calibrations in lcsim.  I hope we put this into Java at some point in a Driver.  Tim and I are working on a cosmic analysis which I hope will help with this calibration. 

The mode 7 data is not being converted correctly, or at least not in a form that makes sense for LCIO persistency.  Sho is working with Andrea on this problem.  The other two modes (integral and window) should be convertible to LCIO at the moment.  

I have been able to convert from the raw mode (window) data to RawTrackerHit and then CalorimeterHit collections.  Then I am running a specialized cosmic clusterer.  So there is part of a working recon chain for the cosmic runs already in Java.  I'm going to clean this up and check it into a standard package today from my user area.

For the new physics data, I think we should try to do some simple topological hit clustering once the conversion to CalorimeterHits is working in a reasonable way.  The existing clusterer has an internal energy calibration, and since I think essentially the CalorimeterHit objects you get out are not going to have energies that make much sense (until we write a Driver to properly perform this conversion or modify an existing one), it might be best to just use a simple clustering algorithm that doesn't use the energy in a complex way.  Or you could throw the "real" clusterer at the data and see what happens.  

So with all these issues, tagging HPS Java does not make any sense right now, because it is under heavy development.  And the tag would be immediately obsolete.  You should just work from snapshots.

Maybe others more closely involved with ECAL operations have additional points or clarification to add here?

And, yes, I hope to talk about a number of issues related to conditions/calibrations tomorrow at the software meeting.

--Jeremy

-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Graham, Mathew Thomas
Sent: Wednesday, December 10, 2014 11:18 AM
To: hps-software
Subject: hps-java release for first data

Hi Folks, 

We will hopefully get our first beam on target very soon and it would be good to have some standard recon (ECAL only of course) to run on it.  It would be good if we could get a tagged release to do this...possible?  What's the status of ECAL reconstruction?  Calibration?  I guess we're going to talk about this tomorrow...

Thanks, Matt

ps...Jeremy peer pressured me into posting this to the list...
########################################################################
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

########################################################################
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