Minutes of DAQ/Online Calibration Meeting 03/31/00
Attending:
J. Cranshaw
A. Kotwal
K. Lannon
B. Orejudos
J. Patrick
V. Papadimitriou
K. Pitts
R. St Denis
R. Vidal
Follow up points from previous meetings Rick St. Denis
---------------------------------------
Rick St. Denis asked Jim Patrick about the status of scripting. Steve
Nahn pointed out that this is one item but in fact there are two
concepts. First there is the ability for Run Control to issue a
sequence of commands from a script. Second there is the more limited
need for Run Control to take events, issue a command for a number to be
modified, take more events and so on. Jim Patrick confirmed that this
was the case. He then pointed out that the DDG calibration in the TDC's
needs this and since Bill Orejudos has a crate, then he would like to
meet with him, Eliot (for the state machine) and Bill Badgett to
brainstorm how best to do the calibration. A time was set for next
week Thursday. Jim feels this is concrete and a simpler case than the
SVX. It is therefore a good place to start. Steve Nahn agreed with
this.
Bill Orejudos asked what the end result is. There are two things. One
is to be able to run a calibration from run control where a single run
contains various steps in a parameter and some series of events and that
it is possible to get the information on the change in the condition.
The second is to be able to get run control to fire off the consumer as
well as run the results. This is something that is needed and will be
done as a second step.
Summary of Database meetings from this week Rick St. Denis/
as they impact the Online Calibrations Jack Cranshaw
Rick and Jack summarized the meetings this week:
MDC vs RDC
----------
Mock Data Challenge 2 and the real data challenge -- or cosmic running
will be able to avoid conflict because it is planned to divide level 3
into two pieces, offering a hardwire partitioning. The only potential
interference would come if there are high rate tests being done in the
MDC2 and it is necessary to stop doing DAQ at that point. It is
envisioned that there will be a week of high rate testing. Jim Patrick
feels it is too early to predict the impact.
Remote Database Access, Export and Freeware
-------------------------------------------
The plan is forming to export the entire online calibration database to
all institutes on a nightly update basis. We would propose to
administer this centrally from fermilab in a way that is analogous to
that for the code distribution. In fact only the online database tables
would be left out of this distribution of databases: trigger, offline
calibration and the run file catalog would be done. A group is being
form to test this out based on oracle and on freeware databases.
Integration, Development, Production
------------------------------------
The machine B0DAU35 is currently a production and integration machine.
This summer it will become only the production machine and a request for
a smaller machine for development and integration has been sent to the
online project leader from the database coordinator. The activity
currently on B0DAU30 would move to B0DAU35 and the new machine during
June. It is considered essential to establish the final configuration
before the commissioning run to be able to run under the same conditions
as run 2. It is not considered wise to use the time between the end of the
commisioning run and the start of run 2 for modifications of the
database hardware.
Valid Sets
----------
A discussion of what calibration to use when and how this is determined
resulted in a document that will be circulated in the next week on how
this is done. This includes a definition of how a set of calibrations
is formed, how calibrations can be declared good by hand and
automatically.
DB Manager Connections
----------------------
Next Monday (see separate email) the DB manager will be modified to
allow for selective timeouts of the database connections. The
documentation for how this works will be available by next Monday. This
is necessary in order to satisfy license restrictions on active
connections to the database. The new software is scheduled for release
next Monday.
Class Template and Inheritance
------------------------------
The scheme in place for the Silicon D bank consumers using templated C++
classes was examined by Jim Kowalkowski and he considers it to be the
correct solution. He will work next week with Mary Bishai on the SVX
code and Jack Cranshaw on the Calorimeter code in order to finish the
templating. The end result is that to enter calibrations one need only
get the bank defined and then write a class that does the actual work to
fill the calibration information into a bank as well as to provide a
class that maps the channel id in the raw data to the channel id in the
calibration. This can also be used to fill histograms for monitoring of
single banks.
Further development to define the class on the database would free the
user from writing any C++ code.
Database Interconnections was held after this meeting.
Round Table (5 minutes each)
-----------
Database: Rick Vidal
======================================
On April 1, all work on Oracle will be scrapped and we will move to
Objectivity. Rick will personally issue the rm -rf / command.
Banks and Templates Jack Cranshaw
========================================
See remarks above on the Class Templates and Inheritance
SVX: Steve Nahn
=====================================
There is still a problem with getting the X bank calibrations done
because of the limits of the size of the CPU. This is also holding up
the bank definitions. The work is to get FISION on a 2604 just now.
There is concern at how long this will take.
The ISL hardware locations are defined! Bill Badgett will enter this
into the hardware database when he is back next week. David Stuart is
looking into the L00 locations.
The software event builder works and can be used for module readout at
SiDet as well as running at B0 =-- thereby removing the need for
hardware event builder and level 3 in testing. It runs at about 50Hz.
COT: Bill Orejudos/Ashutosh Kotwal
========================================================
Much on the COT was reported in the DAQ meeting yesterday and centered
on the work Bill has done in getting calibrations to run in the crate
that was mentioned above. A real crate will come on the time scale of
April 14.
Muon Kevin Lannon/Trevor Vickey
=====================================================
Kevin and Trevor introduced themselves as working on the muons. They
want to work with a D bank consumer and don't think that they need the x
mode. Jim Patrick asked if this might take too long and Bill Orjudos
said 1000 events takes about 2 minutes. Rick St. Denis asked why they
don't want to have x mode in case it is deemed that it does run too long
and so that they can monitor the card performance. Jim Patrick thought
this would be wise. This means that Bill Orejudos has to rename some of
his code so that it can be copied to be used by muons. He agreed to do
this. It also means that the banks have to be defined. Rick St.D
suggested this be done at low priority and put at the bottom of David
Daggenhart's list. This was agreed. Rick also pointed out that that
Trevor and Kevin should keep in close contact with Jack so that they can
benefit from the templating work being done. This saves an enormous
amount of code writing and especially of code maintenance.
CLC: Alexei Safonov
==========================================
No report
Consumer: Kaori Maeshima
=========================================
No report
Calorimeter/DBana: Vaia Papadimitriou
=============================================
Vaia has been running with the full central detector but is never sure
what crates she will be allowed to use. She also pointed out two rather
disturbing problems.
1. When writing the same data to the database twice, differing only in
version, DBANA did not show a spike at 0! This needs to be traced and
Rick Vidal offered to lend a hand if it seems to be coming from the
database. Jack and Vaia are pursuing this problem.
2. She failed to write to the database a couple of times because of
running out of space in a segment. It is not clear how this should be
handled and what the constraints on segment size vs performance exist.
It all gets tied up in the OEM (Oracle Enterprise Manager) discussion
becuase the OEM software allows one to query the usage in the database
and expand as needed. This will be pursued by Jack with the dba's.
ShowerMax: Steve Kuhlmann
==========================================
no report
Discussion
----------
Next meetings
in two weeks.