Update on low-order-byte corruption  ( summary ,  more details ) --  Vern Sandberg and Ben Johnson

• Vern and Ben summarized recent findings on the low-order-byte corruption first noticed during the S3 run. Technical details can be found in their detector elog entry ( plain text version ) and plots found on a web page .
• In brief, the corruption was tracked down to an inadequately designed VME decoder chip on Brandywine clock cards used widely in the DAQ system (Vern will check with GEO people to see if they use the same clock card; Albert believes they do.) The bad decoder chip frequently tries to drive the lowest 8 bits of the VME data lines when it's supposed to be idle. This occurs in synchronization with the 16 Hz "heartbeat" used in DAQ buffer transfers.
• It is possible but not yet demonstrated that the corruptions are the source of long-term inter-ifo correlations seen by the stochastic group as a 16-Hz comb of significant coherence. Peter Fritschel mentioned that one can see 16-Hz features in single-IFO dark noise and suggested checking whether those go away when the clock card is disabled.
• The possiblity of GPS-synchronized "glitches" in all three IFO's may also prove problematic in the burst analysis (and perhaps in the pulsar analysis). Nominally, the effect on AS_Q is small, since the last byte affects only 1 part in 65K of the AS_Q value, but one worries that high frequency behavior is disproportionately affected in the highly colored raw AS_Q spectrum.
• There is strong evidence that the corruption has been occurring since the E8 engineering run (preceding S1). Vern and Ben are writing up a more detailed document on their conclusions. They are still looking for clues that could help pin down these occurrences in offline analyses. Except for special channels with restricted allowed values, it's hard to know whether any given data sample has been affected by the malfunctioning clock card. John Zweizig suggested that for the future, systematic software tests be carried out online to look for such corruptions. Vern thinks that injecting a variety of bit patterns and checking readout should be feasible.
• John mentioned that he remains stymied in trying to simulate the front-end LSC code offline with the LSCMon DMT monitor in order to find times when AS_Q and DARM_CTRL appear inconsistent as a marker for corruption. A recent attempt to ramp data smoothly to avoid start-up transients didn't pan out. KR suggested talking with Rolf Bork (author of front-end code) to see if a hidden parameter is somehow missing from the simulation.

• Brian spoke briefly about a new detchar subgroup on Interferometer Performance Analysis (IPA) being formed to better bridge the gap between commissioning and detector modelling. He and Erika want to provide a forum for modellers to come together to confront the data with their simulations. They are asking for volunteers and will be organizing regular telecons. They have begun to collect links to various software. Ken Ganezer suggested they take a look at the home page of the Advanced Interferometer Configurations group, which has many simulation links. Ken volunteered to participate in the new subgroup.

• Status of DMT infrastructure:
  
  
• John Zweizig: Version updates, etc
• John's recent infrastructure work has been partly bug fixing in the DMTGen simulation package, prompted by problems found by Natalia Zotov who has been using it to exercise PTMon. A new test program is under development to allow a customizable suite of tests with error codes to be executed for key parts of the DMT infrastructure. The tests would be run with each new DMT release or patch.
• A new primitive frequency-domain filter class has been installed to support Patrick Sutton's new calibration code (see below).
• Problems Natalia reported with the Foton filter class and the decimation-by-two filter haven't yet been sorted out. Natalia has been asked for more info to help reproduce the problem she sees.
• DMT trend directories at the sites have changed (which required restarting the process manager). Instead of the old /export/DMTtrends/XxxMon directories, there will now be directories subdivided according to GPS time in million-second intervals, e.g., /dmt/XxxMon/H-M-765/ indicating the first three digits of the GPS time. In each case, there is also a link /dmt/XxxMon/current that points to the present GPS subdirectory.
• John would like to overhaul the database trigger definitions used by DMT monitors. He will circulate a proposal to the DMT-discuss soon and ask for feedback. After a consensus is reached on a definition change, it will be proposed to the DASWG group. 
  
  
• Patrick Sutton: Calibration infrastructure

Details of the planned new SenseMon-extracted calibration code were given at the March LSC meeting. The coding is well underway, with one class intended for most users: EasyCal, which will take care of nearly all the details of getting a calibrated strain spectra. One remaining issue is how to store the calibration reference info in a standard way. It's attractive to put everything in a single file that the calibration team would be responsible for updating periodically. Brian suggested Patrick speak with Xavier Siemens or Martin Hewittson, since they are devising a standard calibration frame file relevant to the future time-domain h(t) calibration.
 

• Status of DMT monitors under substantial development / revamping / debugging:

 
• Tim Bodiya / Keith Riles: SpecMon

KR reported that Tim's most recent code has much improved speed and stability w.r.t. clicks of the GUI buttons, thanks to a revamped socket interface, but that the program crashes frequently after about an hour of running. Tim is working on the problem.
 
• Ken Ganezer: seis_blrms

No recent work, but Ken will be looking hard in the next week at known glitches suspected to be due to data dropouts.
 
• Sergey Klimenko: BurstMon

Sergey has begun work on a stripped-down, single-channel version of WaveMon that will allow multiple injections of waveforms to determine roughly every minute the 50% efficiency point for h_rss for a variety of burst waveform types. A figure of merit plot would be the h_rss_50 value vs time. Another possibility is range to see BH-BH mergers, using the same injection technique. Sergey envisions roughly 200 injections per minute per waveform type and worries about having adequate computing time online. He expects to have a working prototype in 1-2 weeks.

• Tim Olson: SpectrumArchiver

Work is progressing well on a version with config-file-specified channel inputs. Tim will try to arrange to spend some time soon at LHO when Daniel Sigg is there, in order to work out a scheme for a new DTT version that allows rapid retrieval of archived spectra. (The present retrieval is quite cumbersome via the standard DTT import command.) He will also send the source code to John and become familiar with using cvs for future updates.
 
• Steve Penn: BicoMon and BicoViewer

Steve is discussing with Albert Lazzarini a mode of running BicoViewer for the stochastic group analysis in which the user could request 1/4 Hz binning over a 512 Hz band, producing a plot of roughly 4 million pixels. How to display and store that much data is under study. John suggested using root histograms for storage, for efficiency. Steve has also fixed a bug in the decimation process and is working on 2-D smoothing of the plots.
 
• Giovanni Santostasi: PulsarMon
  Giovanni wasn't able to make the call because of a technical glitch, but reported by e-mail that he has started work on the pulsar figure of merit monitor. 
  
  
• Brian Stubbs: SuspensionMon

Brian is debugging the new trend-writing code re-installed recently and continues trying to understand code bottlenecks that make the monitor slower than expected. He expects to have a new version for release in mid-May.
 
• Julien Sylvestre: TFCMon(?)
  No report.
  
  
• Martin McHugh: StochMon
  Martin reported that Jennifer Barre' who has been working on a stochastic analysis figure of merit monitor will be leaving the group at the start of the summer. There are two candidate students to suceed her this summer, and she will work with one of them to transfer knowledge before she leaves.
  
  
• Natalia Zotov: PTMon

Natalia was unable to make the meeting, but reported by e-mail that she has focussed PTMon efforts recently on using the new DMTGen package to evaluate and tune performance. She has uncovered a number of bugs in DMTGen itself, which John has addressed (see above).
 
• John Zweizig: LSCMon

John is still having trouble getting the LSC  emulation working in order to determine better the degree of byte corruption in AS_Q (see above). 

A.O.B.

• Brian O'Reilly reported that the final S2 calibration document, including errors, should be in the DCC in the next few days.
  
  
• Mike Landry mentioned that a preliminary revisit of the issue of the overall sign of detector response for the three IFO's seems to indicate no changes since the post-S1 checks, but a more careful check will be made in the next day or so and the results incorporated into the final S2 calibration document. (Some members of the burst group have been worrying about this issue lately.)
  
  
• Mike Ashley reported that he now has complete sets of LineAmp calibration line amplitude and phase plots for the S2 and S3 runs.
  
  
• KR mentioned that S3 version 1 data quality segments would be released later in the day, with S2 version 4 segments planned for next week.
  
  
• The next detchar telecon will be in two weeks: Friday April 23 at 1:30 EDT. The main subject will be S2 and S3 investigations.