Re: [BLAST_ANAWARE] electronics map

From: Adrian T Sindile (asindile@cisunix.unh.edu)
Date: Thu Jul 03 2003 - 20:38:47 EDT


Hi, Doug!
I think this is taken care of by elog? I had an idea about how to
do something like this, but I was told it was already taken care of (see
below - more about this on BLAST_Talk, May 27th 2003).
Thanks!

Adrian
----------------------------------------------------------------

>Hi adrian,
>I think sam hariton (our new urop) will take care of this as this is
>part of the elogbook. The same functionality is actually needed for
>scaler and epics maps and of course the configuration.

>Of course we only save the filename not the whole map
-- t
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Tue, 27 May 2003, Adrian T Sindile wrote:

> Hi, Doug, Chris!
> I thought about this (on my way home from shift) and I think one
solution
> would be the following:
> - I can write a ROOT macro and whenever we change a TDC, ADC cable
> position (crate, slot, channel) we could use that macro to update the
> current electronics information in the database;
> - the macro updates the database and then saves the electronics info in
a
> file formatted like the current electronics.map. In the name of the file
> we could have timestamp information (like Chris did for the trigger
> settings);
> - when we start a CODA run, a script (started by the Prestart button)
> looks for the most recent electronics.map file and writes that file's
name
> to the RUN table, for future reference, so we know what electronics map
> was used for each run.
>
> I think this solution achieves the following:
> - we only update information once, with the ROOT macro, in the MySQL
> database (we do not manually modify any files - we should NOT have to do
> that, as the database is meant to help eliminate such redundancies);
> - we always have the current information in the database and we do not
> have to modify anything there, as this was the original design of the
> database;
> - we have a history of files used for each run, and we do not have to
> modify all the reconstruction code, which will still be using files, not
> the database (that could require a lot of work and the reconstruction
> people probably have other issues to work on right now).
> - we could use the same aproach for epics map, trigger settings, scaler
> map.
>
> Please let me know what you think about this (if anyone else thinks he
has
> a good ideea, please speak up).
>
> Adrian

-------------------------------
Adrian Sindile
Research Assistant
Nuclear Physics Group
University of New Hampshire
phone: (603)862-1691
FAX: (603)862-2998
email: asindile@alberti.unh.edu
http://einstein.unh.edu/~adrian/



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST