Minutes of DAQ/Online Calibration Meeting 01/07/00
Agenda:
=======
Friday, January 21, 9:00 am, B0 Theater
Minutes of last meeting Jack/Cranshaw/Rick St. Denis 5
(see below for corrections so far)
Follow up from last meeting
News
Round Table (5 minutes each) - names not confirmed.
-----------
COT/Muon: Ashutosh Kotwal
SVX: Steve Nahn
Database: Jack Cranshaw
Calorimeter/DBana: Vaia Papadimitriou
CLC: Alexei Safonov
Consumer: Kaori Maeshima
Access Methods: Rick Vidal
ShowerMax: Steve Kuhlmann
Presentations
-------------
Dennis Box Streaming to the database 20
Templates update Jack Cranshaw 10
Joblists update Rick St. Denis 5
Discussion
----------
Next meetings
Milestones
AOB
Minutes of the DAQ/Online Calibration Meeting on Jan 21, 2000
Minutes of last meeting Rick St. Denis 5
Follow up from last meeting
News
o The question was raised last time by Steve Nahn if histogram code
could be used in ROOT. Vaia says this has in fact been done.
o Access to views required some debugging of code. Dennis Box has
completed this.
o On the issue of scripting needed for charge injection, led and other
calibrations that need to take points under various conditions,
Jim investigated a framework that seems to have some desirable features,
and given a generic example of how it might be used. He has not had
time to figure out exactly where it would fit into the current run
control code.
o On the question of consumer communcation back to run control,
involving startup and sending commands, the "dbs" package developed by
the computing division for fixed target does this in a somewhat analagous
way to what we used to do. Basically you can start up processes on
local or remote systems and send text strings to their standard input.
This is the only way AC++ takes input. It does not address the issue
of consumers sending something back to run control in a manner it can
act on. It is conceivable that interfacing our online message reporter
(Merlin) with the offline error logger interface may be sufficient, but
this work is not done. These are current thoughts and there is the
caveat that what actually gets done is something different, and with
no promises as to the time scale.
o Rick St. Denis said his milestones are hung up in a wincenter/pc
interaction bug that blacks out the fields each time he tries to click
on them.
Round Table (5 minutes each)
-----------
COT/Muon: Bill Orejudos by email
Ashutosh Kotwal
=================================================
Here is the content of Bill's Email:
As I will be away from the lab for a week, I thought I could give
you a (very) quick summary by e-mail of my progress.
1) I have managed to send a CTTC event from the front end, to the
Software EVB, to the Consumer Server, to my server, and into the
database. I would consider this a milestone of sorts.
2) I have a dbana module working, so I can actually analyze the
entries I make to the COTCTT table in oracle.
Ashutosh added:
o electronics fro the COT are ready
o All cables are there
o They need to measure delays in the cable system so they need to
store 1200 numbers. It is needed in level3 and offline. The
numbers are of order 10ns. The implication is that it will be used
in stage0 as well. Rick suggested that Ashutosh contact Kevin
Burkett to be sure that he is aware of how these are applied.
The situation with the 1200 numbers has been summarized in later email
exchanges as follows:
The 1260 numbers go to the database in any case.
Then, either:
a. Bill Orejudos applies the nubmers to each calibration and puts the result
on the database
b. Bill Orejudos does not apply the numbers, but the L3 and offline
take Bill's values and the (relatively static) 1260 numbers.
Ashutosh has chosen option a.
As long as it is clearly spelled out and all players are clear on what
the numbers mean, then either option is fine; however, since it
is easier to ensure that offline, L3 and Stage 0 (potentially, at least
3 people) look at one table, option a is a better choice.
This choice needs to be confirmed with Bill.
SVX: Steve Nahn/Rick St.Denis
===================================================
The milestone of loading constants to the database from a consumer
receiving events from the consumer server logger, fetching them back
with the broker to the VME crate and loading them into the FIB was
achieved. The subtracted pedestals were verified (ie. 0) as expected
and in a second load, the process reversed.
Next steps:
o Get real info into the Hardware database. Steve is meeting with
Bill Badgett the week of Jan 24.
o Get fibs into B0 with the correct firmware
Steve asked about DBANA and there is a need for someone to program this
so we can look at the database.
Rick St. Denis has pointed out that the database code is not being
handled correctly on platforms other than linux and this needs to be
investigated. This bug was picked up automatically by the validation
procedures he described last time and he received a friendly email from
Andy Beretvas pointing out that there were some code testing failures.
Rick encouraged everyone to take advantage of this validation, even
if/especialy since it means constant mails from Andy until your code
works properly.
Database: Jack Cranshaw
=========================================
o Views were created
o there are 3 detectors in the database: COT,CALorimeter and SVX
o Tony Vaiciulis asked when Silicon and COT would get into stable running
with constants being downloaded to the database. For silicon, Steve
said there was no point in this since the DEM data were the same every
day. He said that it would make sense when barrel 4 was being read in
from its location at SiDet and there were plans afoot to do this.
For COT, Ashutosh said there is no point just yet. They want to
commission the TDC and then get COT endwal crates commissioned. One
will be done this week. The remainder depend on cabling and Peter
Wilson must be asked concerning this. TDC's are coming at 10/week and
will need to come at 20/week. In the latter case, it takes 10-12
weeks to get all tdc's. Presently there are a few TDC's being studied
in a crate too look at long term effects. In one month, there will be
3 endwall crates and at that point it will make sense to do daily
running and track the TDC performance. There are 8 crates needed.
o Calorimetry has 200 runs with 4-6 components per run. If 1/2 were
lost, it would not matter. There are 3 crates being studied right now.
Calorimeter/DBana: Vaia Papadimitriou
=============================================
o There are three crates running since two days: two central, and one
plug. The are trying to stabilize operation. (Things like buffer sizes
being too small and such are bugs that need to be worked out.)
o They still do QIE running only and the data quality is being checked.
CHA had one case where the error in slope went from 25 to 35%.
o Commissioning the hardware database is the next task.
o Still concerned with the run number, but the hardware event builder usage
should help. Level 3 is not expected to be stable for one month so for
now an event builder and level 3 expert are needed. Rick pointed out
that Ilya and Jeff have been quite helpful in the silicon testing.
o There are still no pedestals being taken, no RMS.
CLC: Alexei Safonov
=========================================
No Report
Consumer: -
============================
No report
Access Methods: Rick Vidal
=====================================
Rick said there was nothing new. Rick St. Denis asked when we needed to
answer the question about demands on the development database and Rick
Vidal responded that it will be April or May before a big machine is
purcased so this summer is when we need to know the answer.
ShowerMax: Steve Kuhlmann (Email)
--------------------------------------------------
No Report
Presentations
-------------
Dennis Box Streaming to the database 20
=======================================================
In his
presentation Dennis contrasted the present effort needed to
access Oracle in C++ and described a better way using the
Oracle Template Library developed by Sergei Kuchin. The central
concept is the Class::otl_stream which behaves much like any other
stream in C++. This means that effectively, in order to access the
database, one need specify it as the input and use the << operator.
The code looks like:
//-------------------------------------------
// 1. OPEN A CONNECTION WITH OTL_CONNECT_CLASS
//--------------------------------------------
otl_connect::otl_initialize(); // initialize OCI environment
db.rlogon("myUserID/myPassword@myDatabaseID"); // connect to Oracle
//-------------------------------------------
// 2. OPEN AN OTL STREAM
//--------------------------------------------
otl_stream io(1,"select name,age from stooges",db);
//-------------------------------------------
// 3. PERFORM IO WITH >> OPERATOR
//--------------------------------------------
int age;
char name[30];
while(!io.eof())
{
io >> name;
io >> age;
std::cout << "stooge name: " << name << " age: " << age << endl;
}
This is relatively simple.
This is being used for the File Catalogue. The main disadvantage is
that Sergei is modifying the code often. The source code is public and
available and there is always a risk that the product suddenly is no
longer supported. However, in Dennis' opinion, the ease of usage
introduced by this code outweighs any future loss in time needed to
support the code should the situation develope that Sergei no longer
supports it.
Templates Jack Cranshaw 10
============================================
Jack reminded us of the previous proposal and asked if anyone was in
dire need -- the template was not ready.
Rick asked if the consumer from which to inherit exists and Jack said
that one can inherit an AC++ class (ie. module) that is designed for
the calibration consumer. It currently has nothing different from the
generic AC++ class. Rick asked him to review the usage in various
consumers and see what could be migrated into the online calibration
consumer class.
Joblists update Rick St. Denis 5
============================================
No changes
Discussion
----------
Next meetings -- Feb 4 at 9am, theater
AOB
===
Tony Vaiciulis asked how many events are needed for calibration. For X
mode, there is one event, and for slope determination or charge
injection in D mode there will be some handful of events. The reason he
asked was that in running 1000 events, only about 200 are actually
making it to consumers who are busy with computing things. There is
some concern then that the source scans with the plug could run into trouble.