Hi, Tancredi!
> 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
That's great! I think he should follow the steps I outlined in that
solution then (I mentioned there scaler, epics, trigger also) - this saves
me some work and I can spend that time on analysis.
Anyway, some elogbook information will be part of the RUN table in the
"BLAST_physics" database (Chris already made some changes to that table,
preparing it for this, I think).
Chris, this also answers your email: it is not enough to keep the
e-map (or any other) file up to date, we need to keep a history of files
used for every run (as I understood from Doug), so we record the e-map
file name (which will include a timestamp) for every run in the database.
We could use all the information straight from the database, but as you
said, that would be too much work (to change codes) and it probably is not
worth it.
The solution I sent takes care, in my opinion, of all the "logistics"
details related to CODA runs, e-map, trigger settings etc., without
requiring a whole lot of work. But we just need to have a clear and broad
picture of how we are going to integrate the whole thing, and I think this
solution takes care of that.
I hope we were thinking about the same problem when speaking about a
solution.
Cheers!
Adrian
> -- 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