Hi, Gabriel.  

I'm going to share my response to these questions with the software list as I believe others could benefit from this information...

Q: From what you said, if I understand right, I basically need to rewrite: /recon/ecal/EcalConditions.java to load the different conditions using the code here org.hps.conditions.ecal, that already provides classes to read the database, right ?

A: This is one approach I had thought about to rewrite that class, but I think a cleaner (but more time consuming ) approach would be to scrap that class and instead replace the calls to its static methods throughout the code with ones that use the new conditions system.  In the new way, the geometric objects themselves, e.g. the DetectorElements, contain the conditions data, so you can "go to" a crystal in the geometry and get its information.  The hits themselves have a direct connection to their DetectorElements.  This approach is probably better and should not be difficult to implement.  One would definitely want to perform tests and checks that the information between the text-based and database conditions is the same though, so running them side by side initially would be required.  (There's a way to do this involving setup of the database system which I can cover at some point.)

Q: A similar file should already exists for the SVT, but I didn't find it, could you tell me which one it is please ?

That is in trunk/hps-java at src/main/java/org/lcsim/hps/recon/tracking/SvtUtils.java and we are planning to replace that too (Omar will be working on this).

Q: Also just to be sure, what is in the database, is exactly what is in the txt files used so far for the conditions ?

The default conditions database at SLAC contains Test Run 2012 conditions for SVT and ECAL, which were converted (loaded) from the text files in hps-java containing this data.  The idea was to make a direct translation from the text files to the conditions database so that detailed cross checks between them were possible.

Q: Last, the development of an temporary Ecal database is to see how and what to write in it and so on ?It's a second step then, right ?

The idea would be that the ECAL group has its own MySQL instance with admin rights so that dropping databases and creating new tables is easy to do within the group.  Experimentation could be done on this database with new calibration procedures.  You would essentially have your own database.  Then we would merge the relavant tables into a primary database at JLab when the time comes. 

Or we can work off a central development database, but my admin rights on the one at SLAC are limited.  I also am not allowed to create and delete databases here at SLAC on machines other than my own.  So I am thinking of simply running some databases on my Linux machine (which I always leave on) and then making them world accessible.  This will work for the development phase.  Long term, the primary conditions databases will be located at JLab where it is easily accessible (hopefully?!) by the batch farm and control room software like monitoring etc.

It might be beneficial to start simply and create a Driver that reads some test run data and applies the existing conditions to it from the database in order to reconstruct the crystal energies.  This would be a good step in that it will show how to use the conditions system in a simple and straighforward way.  Then maybe we can move on to the (really pretty messy) job of replacing the old system with calls to the new API.

--Jeremy

-----Original Message-----
From: Gabriel CHARLES [mailto:[log in to unmask]] 
Sent: Tuesday, March 25, 2014 3:54 AM
To: McCormick, Jeremy I.
Subject: RE: SQL for ECal

Hi Jeremy,

   Thank you for all the details. I had a look at the conditions and I understand what is done there, not exactly but I can follow most of the code.

   From what you said, if I understand right, I basically need to
rewrite: /recon/ecal/EcalConditions.java to load the different conditions using the code here org.hps.conditions.ecal, that already provides classes to read the database, right ? A similar file should already exists for the SVT, but I didn't find it, could you tell me which one it is please ?

   Also just to be sure, what is in the database, is exactly what is in the txt files used so far for the conditions ?

   Last, the development of an temporary Ecal database is to see how and what to write in it and so on ?It's a second step then, right ?

Best,
---
Gabriel CHARLES
Institut de Physique Nucléaire d'Orsay

On Sat, 22 Mar 2014 11:44:17 -0700, McCormick, Jeremy I. wrote:
> Hi,
>
> Or even better, take a look at the ECAL conditions API here:
>
> 
> http://lcsim.org/sites/hps/apidocs/org/hps/conditions/ecal/package-sum
> mary.html
>
> We will need to add the timing.  I don't think this is there yet.
> Can you tell me what this value will represent?
> There is a data class we would then add to represent it and a backing 
> data table.
>
> For the database itself, I think you and your group should setup a 
> MySQL database to use for ECAL development.
> This is not too hard on most Linux distributions.  Then you would 
> execute one of the existing SQL scripts to load the table structures.
>
> As far as loading data from calibrations, I have some ideas for this 
> too...
> ________________________________________
> From: Gabriel CHARLES [[log in to unmask]]
> Sent: Saturday, March 22, 2014 3:06 AM
> To: McCormick, Jeremy I.
> Subject: SQL for ECal
>
> Hi Jeremy,
>
>    I would like to take care of the transcription of the txt files 
> used for the ECal in the database. I need to learn how to create 
> tables and access them first, but I need two things for this.
>    1) The txt files that should be translated
>    2) I see how to create a table but I don't understand if an address 
> or something like this is needed and also where I should execute it.
> For
> example, I have
> CREATE TABLE ECalCrysProp
> (
> CrysNumber int,
> CrysPosX int,
> CrysPosY int,
> Gain int,
> Time int
> );
>
> What do I do with it ?I understand that it is not that easy and it 
> should be included in what already exists but for the moment I don't 
> where it should be included.
>
> Thanks,
>   Gabriel

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