Make
checksum of all files used as input to a test before and after the test
is run to ensure nothing has changed during the test
Record
number of times test was paused in the test report
Need to be able to correlate test data
with environmental house keeping not collected by the instrument.Implies having to synchronize clocks.
Test and schema/configuration files
are not tightly bound
Make a report class
Determine a test suite name
convention, e.g.:
ped.xxx.py
gain.xxx.py
Output files labeled with the form pjjjyyhhmssq.ext,
as above
Logging of session activity
Session: offline building of
schema/configuration, online running of tests
Security
Should test operators log in to Run
Control?
Run log should contain operator name
Must handle situation in which
multiple copies of Run Control are started
Dealt with by inability to share a
socket?
We decided that looping over a test is
a property of the test, not of Run Control
Do we need the ability to log all
commands sent to the embedded system?
Consensus is no.Likely to be useful only for debugging.
Electronic log book discussion
Post workshop: Eduardo requires the
ability to determine whether a run was flawed from the electronic
logbook.Flawed runs will
normally not be analyzed offline.
The flawed flag is determined from
coarse metrics from subsystems, e.g. is HV on for all components for
which it should be
Do we need to be able to drill down
into the flawed flag to find out why the run is flawed or is it
sufficient to say that if you’re really interested in a flawed run, go
ahead and analyze it?Consensus
is no need to drill.
Need to make the criteria that go
into the flawed flag not too stringent so that all runs don’t become
marked flawed
Curt and Selim chaired a discussion the
lower levels of command and event network packets
Scripts will need to be able to ensure
that the event pipeline is empty
This is done with the marker field of
a trigger message.A trigger
message is issued with a unique marker value.The script then looks at the marker field of events that
come back from the embedded system.If it sees the special value, the pipe is empty.
Selim demoed the creation of a GUI with
Qt Designer on the fly.
Scripts that care should have a
GUI-enabled flag so that they can interact with a GUI or the command
line interface depending on whether they’re invoked interactively or in
batch mode
Friday
Performance discussion
Selim measures command rates at ~1200
commands/second
Selim measures event rates at 2000
events/second without parsing, 200-700 events/second with parsing, depending
on size
Byron measures event rates at ~1200
events/second using SciPy/numeric to parse CAL data
Byron raised his concern about FSW
recoding subsystem scripts
Adds risk
Processing Calorimeter data onboard
is excessive – this should be done on the ground
JJ indicated that the amount of data
involved is too large to ship to the ground
JJ described FSW plans:
Need to handle case where calibration
fails on orbit
Calibrations are FSW’s best tool for
determining the health of the system
Need to decide where to draw line
between ground based and on orbit functions
FSW will have statistics tools (means
and standard deviations, etc.)
For onboard pedestal calibrations,
results can be fed back into FSW
Rather not include ground in this
loop
Byron plans to design his scripts to
separate data collection from analysis
FSW is not planning to import code
from non-FSW groups
Byron: algorithms are given to FSW for
implementation in FSW environment
JJ indicates a constraint on the
algorithms is that it must be a single pass over the data since the SSR
is a write-only device
Slight modification on this is that
some amount of data can buffered and analyzed before writing to the SSR
FSW may implement algorithms by
distributing events to multiple CPUs and processing them in parallel
Can treat multiple “channels” of data
in parallel, if crosstalk and suchlike aren’t a problem
TKR data size is large so no
possibility of involving the ground, depending on compressibility
Threshold sweep could maybe be done
from the ground if compressibility allows since it won’t be done very
often
Byron asked whether pedestal
normalization data will be stored on board
JJ thinks FSW will have to, yes
JJ requests some cheap (CPU time,
memory) instrument integrity tests
JJ expects calibrations to typically
take less than a minute apiece
How to handle bad calibrations?
Mark corresponding dataset bad (can’t
recall it from SSR)
Try again
FSW is not planning to do several
different subsystem calibrations simultaneously
CPU, memory, bandwidth limits lead to
partitioning of what portion of the detector is calibrated when
Definitions:
Calibration: actions incompatible
with regular (physics) data taking
Monitoring: actions compatible with
regular data taking, e.g. dead strip list accumulation
Certain things can be done on the
ground better than on board
On board’s advantage is statistics –
only a small fraction of the data is sent to the ground
Can’t do photon pointing on board –
too hard
JJ requests subsystems submit
monitoring ideas requiring high statistics to FSW
JJ expects to get pedestal data from
CAL during regular data taking periodically to monitor performance
around the orbit
Action items: JJ requests from subsystems:
Information on cross talk effects
What order to go through calibrations
How to march through the DAC curve
Any information on funny effects in
the real system
How should calibrations be taken,
processed and presented