<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Mark and Dmitry,<br>
<br>
Below is an attempt to specify requirements for the conditions
database. Please get back to me if you need additional
information...we can iterate as required.<br>
<br>
Thanks,<br>
<br>
Elliott<br>
<br>
<br>
<b><br>
<br>
<br>
<u>Requirements for Hall D Conditions Database</u></b><br>
<br>
<div align="left">Elliott Wolin<br>
11-Nov-2011<br>
</div>
<br>
<br>
<br>
<u>General Remarks</u><br>
<br>
The Hall D conditions database needs to store a wide variety of
types of data relevant to configuring and running the apparatus and
taking data. The information in the conditions database will be
used by the offline reconstruction and analysis effort, and might
further be used for debugging of online problems. Further, it is
important that this data be easily accessible from the analysis
programs from both on- and off-site. The data must be tagged
appropriately, and the schema shown by Mark at the April 2011 Online
meeting seems like it should work.<br>
<br>
Note that the conditions database need not duplicate the function of
the EPICS archiver, which records a vast quantity of fine-grained
data from a large number of sensors. Most of this data is not
needed by the offline effort, but it is difficult to predict in
advance which data will or will not be needed. It does make sense,
however, to record selected EPICS data in the conditions database
that surely will be used by the offline, for example the solenoid
setpoint current at the beginning of each run.<br>
<br>
<br>
<u>Input Requirements</u><br>
<u><br>
</u>Data will be input to the conditions database in a variety of
ways during experiment operations. These include input from C++ and
Java programs and from Python and shell (and perhaps Perl) scripts.
Some input will come from long-running programs or scripts, some
from short-lived programs or scripts launched as part of a run
control transition, and some from CRON jobs.<br>
<br>
Entry size will vary from single numbers or short strings to long
strings containing many thousands of characters.<br>
<br>
Entry frequency varies widely, with flurries of activity expected at
the beginning and end of data taking runs, with relatively few
entries during steady-state data taking. <br>
<br>
Entry rates will peak within about 20 seconds after the start of a
new run, with something like 10-20 processes making about 100-200
entries with a maximum aggregate size of less than 1 MB. Note that
how long these entries take is not critical as they will be made by
programs and scripts running in the background.<br>
<u><br>
</u>API requirements are not particularly strict, as only a few
experienced members of the online group will be involved in making
entries into the conditions database. <br>
<br>
<u><br>
<br>
Retrieval Requirements</u><br>
<br>
These are largely driven by offline requirements, and are almost
identical to those of the calibration database. It is highly
desirable that the API and access mechanisms for the conditions and
calibration databases be as similar as possible. <br>
<br>
An important consideration concerns export of the conditions
database to other sites. Some of the data entered will only be
useful to the online group, although it is never clear whether any
particular data type will be needed by the offline. A mechanism
needs to be provided that allows selective export of the database
contents, e.g. by run range and data type.<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Sincerely,
Elliott
================================================================================
Those raised in a morally relative or neutral environment will hold
no truths to be self-evident.
Elliott Wolin
Staff Physicist, Jefferson Lab
12000 Jefferson Ave
Suite 8 MS 12A1
Newport News, VA 23606
757-269-7365
================================================================================
</pre>
<br>
</body>
</html>