Hi, Stuart.

Sorry to hear you’re under the weather!

Gabriel wants to update the DAQ map for the 2014 run, which is a text file.  This can be done in place without too much issue, which Sho agreed to do.  I suppose this works short term.

> Is mixing and matching a problem?

I think that yes, it is a problem to have some of your conditions in the database and others in text files, and certainly if they are the same type of conditions, then obviously it would be a mess.  It should really be one or the other.  Someone needs to begin work, basically immediately, to start making everything in the ECal codebase database compatible, specifically the readout simulation which has its own text-based system for conditions.  You can imagine creating a bunch of procedures now based upon using text files and then deciding to port everything later is going to create a big hassle and extra amount of work.  This is a task that needs to be done now, as a critical/blocker task, rather than done later.  I know that the ECal group is all working on “critical tasks” but I would put this one at the top of the queue, as everything else needs to use it.  If everyone writes their code now based on text-based conditions, it will at sometime need to be ported anyways, so by not doing this now, you would create extra work later.  Developers in the ECal group at any rate need to be become familiar with the database API, anyways.

> Is it an all-or-nothing task?

I am not sure exactly what you mean by “all-or-nothing” here, but it could be split between multiple people.  There’s no real technical reason it couldn’t.  However, it is probably more efficient for one person to take charge of this task with others helping them (such as me and/or Sho).

My inclination is creating a new ecal-recon package in the SVN which would be a fork of the existing ECal readout simulation code that uses the text based conditions.  Then someone could work on it and leave the old code with the text files completely untouched.  

The other alternative would be creating a branch of hps-java on which to do this work.  But this would imply we merge it back in and completely clobber the code using the text file conditions.  I’m tending to shy away from this, because I think for some time the text based system should still be available concurrently with the database system as a cross check.  

I would be willing to do this small part of making the new package, but I simply don’t have time to do the actual porting to the database API.

I hope that makes things clearer...

—Jeremy

On Mar 4, 2014, at 12:00 PM, Stuart Fegan <[log in to unmask]> wrote:

> I'm a bit flu-addled, in addition to behind on emails after getting 
> caught behind the winter storm on my way to JLab, so I'm not entirely 
> clear what the original question is here.  Is Gabriel trying to use the 
> new conditions API in some code development?  Is mixing and matching 
> (for development purposes) a problem, aside from the obvious issue of 
> maintaining both an up-to-date database and text file?
> 
> As for porting, is it an all-or-nothing task?  Can it be split between 
> more than one person, given the fact most ECal software people are 
> pretty close (or over) their available committed time?
> 
> Cheers,
> Stuart
> 
> On 04/03/14 17:11, McCormick, Jeremy I. wrote:
>> Hi,
>> 
>> The ECal readout simulation does not currently use the database.  It reads from flat text files.  As far as I know, the DAQ map is hard-coded to read from a location that points to a resource embedded in the jar (e.g. the text file).  If you just wanted to get started, you could modify your local copy of this file, but I don’t recommend it.
>> 
>> Someone from the ECal group needs to take responsibility for porting the existing code so that it can read from the database using the new conditions API.  As far as I know, no one has been assigned to this task.
>> 
>> —Jeremy
>> 
>> On Mar 4, 2014, at 5:22 AM, Gabriel CHARLES <[log in to unmask]> wrote:
>> 
>>> Hi Sho and Jeremy,
>>> 
>>>   This email may concern both of you, as I understood Jeremy you are
>>> the gourou of the database (among other things) while Sho you are the
>>> expert for the ECal software.
>>> 
>>>   The gain and noise values accessed when calling
>>> EcalConditions.physicalToNoise(hit.getCellID()) and
>>> EcalConditions.physicalToGain(hit.getCellID()) should be changed, or
>>> maybe a new table in the database created such that analysis on the test
>>> run remains possible. For now, the gain should be 1 for all crystals
>>> while the noise should corresponds to 10 MeV, which is a signal of 5.25
>>> mV or 10 ADC counts.
>>> 
>>>   Would it be possible to add this new table or something equivalent
>>> ?Will it introduce a new option in the steering file ?Please, let me
>>> know if you need more informations.
>>> 
>>> -- 
>>> Gabriel CHARLES
>>> Institut de Physique Nucléaire d'Orsay
>>> 
>> ########################################################################
>> 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
> 
> 
> -- 
> Dr Stuart Fegan
> Postdoctoral Researcher
> INFN-Genova
> Via Dodecaneso, 33 - 16146, Genova
> Italia
> 
> E-mail: [log in to unmask]
> 

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