Caltech: Blackburn, Lazzarini, Shawhan, Zweizig
     Dublin: Ottewill
     Hanford: Landry, Schofield
     Michigan: Gustafson, Riles
     MIT: Sylvestre

Introduction (KR):

• KR briefly went over the agenda and remarked that attendance would be low at this meeting because of the Marcel Grossman (MG9) meeting in Rome this week and because an ASIS group teleconference is scheduled at nearly the same time. The ASIS group meeting coordinator was unaware that DC teleconferences are normally held the first Friday of each month, but has now been informed of it.

• John is getting ready for the next release of the DMT which he plans for Bastille Day (Friday July 14). He will be at Hanford the following week to help smooth out any problems that might arise in making this major revision the production version.
• The new release has been delayed by headaches associated with a new major release (V 2.25) of CERN's ROOT package. The new package is backward incompatible with old ROOT versions. John is making the new DMT compatible with the new ROOT and hopes (but does not guarantee) that it will be backward compatible with old ROOT versions which users may have at their home institutes. One example of a backward incompatibility is that ROOT histogram axes are now specified with double precision floats (which is good for using GPS time for a horizontal axis).
• The release has also been delayed by incorporation of contributed code from LSC members:
• Multi-taper spectral analysis of lines - Adrian Ottewill
• Operational state condition classes - KR
• Time/frequency classes - Soumya Mohanty
• Other contributed or soon-to-be-contributed code which has not yet been incorporated:
• IIR filter routines - Teviet Creighton
• Inter-channel correlation analysis - Adrian Ottewill
• Wavelet tool class and line tracker - Sergey Klimenko
• Since the last teleconference John has filled in a number of missing pieces of the display monitor client/server. Daniel Sigg's Diagnostic Test Tool (DTT) libraries will be used for graphical control and display of background monitors. The essential infrastructure of calling up a plot from a background process has been verified to work. John was urged to include a template example in the next DMT release to give guidance to software writers who want to exploit this new infrastructure early on.
• The monitor client/server supports a handful of data object types for transfer. The number of types is expected to increase with time, as needs arise. It hasn't yet been decided how to handle transfer of time/frequency plots. Software writers wanting support for new object types should talk with John. although one can use strings for the time being to transfer non-standard data.
• John hasn't yet written a formal software requirements document for contributed DMT software, but has the following comments and suggestions:
• DMT software falls into four rough categories: Infrastructure; Signal processing classes; background monitors, and foreground monitors.
• For greatest usefulness, he suggests that monitor writers first create tools that fall under the category of signal processing classes and then to write a monitor that uses those tools. Most of the monitors he has been given or he knows about under development are foreground monitors that require further development before they could be run as background processes. Software writers should keep in mind that most useful monitors will need to be run in background eventually.
• More documentation on contributed code is needed, in general.
• Peter strongly seconded John's suggestion to divide tool classes from monitors, pointing out that soon we will make the transition from writing mostly generic algorithms to writing monitors focussed on specific detector systems. Having an array of tools to draw upon that aren't inextricably tied to particular monitors would be highly desirable.
• Another new DMT feature is the ability to set EPICS alarms to notify control room operators of urgent triggers. The infrastructure for giving authorization to processes for setting such alarms (or writing to the meta-database) has not yet been implemented, though.
• Persons writing code to generate triggers for the meta-database are encouraged to let John know if they want to participate in a rerun over the April engineering run data (see last month's teleconference minutes).
• John brought up the issue of DMT compatibility with the LAL library. The IIR filter code provided by Teviet from a LAL version is not as modular as John had thought at the last teleconference, and a decision must be made soon on whether downloading the DMT package at home institutes should also require downloading the LAL package. KR was reluctant to tie the DMT too closely to the full LAL package. John suggested that the LAL code could be divided between a core library and the rest, with the core downloadable separately, if desired, to reduce  exposure to compilation troubles with newer LAL routines. John, KR, Stuart Anderson and others will discuss this further offline.
• John will be at Hanford June 16-21 and generally available then at 509-372-8300 (x195).

• Line noise:

 
• B. Allen, A. Ottewill (Adrian reporting)

The line tracking code was sent to John in April (see above and minutes of May teleconference). Adrian plans to revisit this code and create one or more signal processing classes as per John's proposal above. He will also keep in mind that the same code should be runnable in the LDAS data conditioning API. He hopes to make progress on this by the August LSC meeting.


• S. Klimenko (John Zweizig reporting)
  Sergey will meet John at Hanford in just over a week to install wavelet tools and a wavelet-based line tracker in the DMT environment.  
  
  
• A. Sintes

Alicia is attending MG9 but reported by e-mail that no progress has been made since the last teleconference. Her next task is code documentation. She too has written LAL code, and how it is incorporated will depend on  how the DMT/LAL interface is handled (see above).



• Characterizing seismic noise:

 
• E. Daw (not present - attending MG9)

 
• Inter-channel correlations:

• B. Allen, A. Ottewill (Adrian reporting)

The correlation code has been given to John for DMT incorporation. As for Adrian's line tracking code, it will be revisited with an eye to making generally useful signal processing classes and to incorporation into the data conditioning API.


• Bilinear cross-couplings

 
• S. Penn
  Steve could not join the meeting, but reported by e-mail that he has the C code for the cumulants up to 4th order done.  The bispectrum, trispectrum, etc are just the 2D (3D,...) FFT of these cumulants. He wondered if the FFT code in DMT has routines for 2D FFTs, etc. John says it does not, but he plans to convert over to the FFTW package in the future. He believes that it does support at least 2D FFT's. Steve reported that the bi-, tri- coherences and the cross-coherences are not yet done and that he has been working so far on stand-alone C code with test arrays. He still needs to get this working in the DMT and hopes to do so by the August LSC meeting.

 
• Operational state:

 
• R. Gustafson, K. Riles (KR reporting)

The operational state condition classes were delivered to John last month and will be in the next DMT release (see above). Some improvements (more condition types and more flexible configuration file format) were introduced since the last teleconference. This initial package is complete and documented (see ~keithr/osc directory on sand at LHO for preview), but users are encouraged to try it out and suggest further improvements.

• Bandlimited RMS

 
• E. Daw  (not present - attending MG9)

 
• Time / Frequency plots
  
  
• (see Mohanty and Sylvestre reports below)

 
• Non-Gaussian noise

 
• S. Finn, S. Siddiqui

Sam is attending MG9 but reported the following by e-mail:

Gaby, Michael Hsu (an undergraduate REU student) and I have had great success in applying wavelet-based methods for automatically characterizing and identifying transients of different kinds in the 40M and the April 2Km engineering data run.

In the 40M these techniques automatically find several of the transients that have been found through "listening" to the IFO_DMRO channel, and have correlated these with activity in some of the other channels (e.g., the seismometers, the PSL). We have found a definite case of a strong non-linear upconversion from a low frequency (on order 2 Hz) oscillation in the seismometer channel to a pair of closely-spaced broadband bursts at about 100 Hz in DMRO. This pattern is repeated several times throughout the data. I can't post a figure from here but will try to do so on my return. We (Gaby and I) would like to talk about this method of analysis and some of our experiences with it as applied to the 2Km data at the next LSC meeting.

We are in the midst of applying these methods to the engineering data. We have found trong evidence for what looks to be discrete jumps in light intensity, lasting exactly 1/16 s (1024 samples) randomly interspersed in the data. These discrete jumps show up in the H2:LSC-AS-Q_TEMP channel, and have cognates in the PSL-FSS_FAST_F channel. (KR note: this may be the same problem reported by John at the May teleconference.)  A second set of artifacts involve a discrete jump in H2:LSC-AS-Q_TEMP, followed by a brief, high
frequency ringing in the channel. These appear to be strongly correlated with clearly identifiable artifacts in the H2:IOO-MC_I channel as well as the PSL-FSS_FAST_F channel. They look very much like some features that Rick Savage just showed at the MG9 Meeting which are associated with laser frequency noise.

There are two other category of events, represented by one or two examples each. These are, in the first case, high frequency bursts that last for on order 1/8 s, and a low frequency burst that lasts for about 1 or 2 cycles at about 2 Hz.

The principal value that I see for these techniques at the moment are
1) an automatic way of identifying artifacts that are not at all visible to
the eye or by study of a single channel;
2) as a way of diagnosing the instrument by identifying anomalies that have
similar characteristics (i.e., this technique can classify anomalies).
Light-weight filters that are very effective at looking for events like
these can then be designed and run on-line in the DMT or in LDAS.
3) Identified events can either be removed via a targeted regression or the
data can be vetoed during some period involving the artifact.

We're continuing our investigations and will have more to report at a later
time. We intend to develop an engine for doing this in the context of the
DMT. I can't give a time scale for that yet - I've not yet talked with the
student I have in mind for it - but it may be as early as Thanksgiving.

• Power spectral transients:

 
• S. Mohanty, S. Siddiqui

Soumya could not join the meeting but reported by e-mail. As discussed at previous teleconferences, this task has been broken into two stages: 1) providing a general-purpose tool for monitoring & displaying power deviations from the average in frequency bands vs time and 2) using pattern recognition to detect and record statistically significant transients. DMT classes have been given to John for the first stage and will be incorporated into the next DMT release (see above). This code provides a foreground monitor for running in ROOT and is documented at the following link. DMT code for the second stage should be ready by the end of the month.


• Servo instability:

 
R. Gustafson, K. Riles (KR reporting)
Nothing new to report since the last teleconference. KR is shooting for the end of the month for completion, but may try replacing the simple spectral power measures with ones based on Soumya's more sophisticated classes, if those appear to be appropriate.
 
• Event catalog:

 
• J. Sylvestre, R. Weiss (Julien reporting)

Julien installed stand-alone DMT processes at Hanford last month that monitor and display information on time frequency behavior for specified channels. There is a background process doing the computations and a GUI interface process for setting parameters and displaying results, including time/frequency plots. These processes run on real-time data on sand, stone and blue at Hanford, but can also be used to look at archived data on fortress by changing environment variables. Julien gave operators at Hanford a tutorial on using these TID (transient identification) programs in June. The code now consists mostly of C functions. KR encouraged Julien to follow John's proposal to define generally useful signal processing classes and to work with John on creating a background process able to write triggers to the meta-database and set EPICS alarms. In addition to flagging transients according to excess power in time-frequency plots, a revised version of the code will include a time-domain filter bank. An MIT undergraduate is working with Julien to create a filter for identifying overhead aircraft. Other filters will be added in the future. John worried a bit that the filter bank might grow large enough to swamp the available DMT CPU time. This issue will be revisited later when we have more experience.

• Flickering optical modes:

 
No volunteer!!!


• Transient detection using adaptive denoising methods

 
• E. Chassande-Mottin (not present)

 
• Impulse recognition:

 
• Although no one has volunteered for this task, it has much in common with the matched filtering technique used in the event catalog (see Sylvestre report above). Determining the appropriate filters to use to recognize impulses needs work. Julien volunteered to look into this by talking with Rai Weiss and Fred Raab to understand better what is involved. He may agree to take on this task.

 
• Magnetic field transients

 
• E. Mauceli (not present)

• (See minutes of last teleconference for background information)
• Sam Finn has agreed to lead a followup to this summer's first LDAS Mock Data Challenge (MDC) to test the data conditioning API.
• The followup MDC is tentatively scheduled for February 2001 to test line tracking & removal, regression corrections, and time interval vetoes. Volunteers from the DC group who will help in this effort include Adrian, Sergey and Evan.
• Sam plans to hold a first organizational meeting of participants at the August LSC meeting and to follow up with regular teleconferences. KR will also sit in on these, and Sam will report on the group's progress at the monthly DC teleconferences to ensure a tight coupling of the MDC to the larger DC effort.

• An e-mail will be sent out to the group soon soliciting talk requests for the DC sessions at the August LSC meeting.
• At the last LSC meeting we successfully avoided overlapping sessions of the DC and ASIS groups which seemed to work well in better integrating the two groups. But many persons in the advanced detector R&D groups were still left out. This was unfortunate, since they not only had a strong interest in detector characterization presentations, but also could have brought valuable experience and expertise to DC discussions.
• It's not feasible to completely avoid overlap of DC sessions with ASIS and all advanced detector sessions in a 3-day meeting, but by grouping DC talks by topic and by coordinating with the other groups, it may be possible to eliminate the most egregious overlaps.
• The required complexity of coordination does mean, however, that time and session allotments will likely be less flexible than at previous meetings. Interested speakers are strongly encouraged to request talks early.

A.O.B.

• Peter reported that he and John have begun investigating offline analysis packages that would allow more flexible detector characterization of time intervals flagged upstream as interesting by DMT monitors or astrophysics template banks. 
  The ideal for them would be a GUI package like Matlab's simulink or GEO's Triana program that allows on-the-fly selection of DMT-like signal processing functions by assembly of modular components, but a package written in C++ and easily modified (Matlab is proprietary and Triana written in java). 
  They have looked at half  a dozen packages and have tentatively settled upon one called SKIRUN, a free program written at the University of Utah written in C++ and TCL/TK. Although written originally for biomedical imaging and the solution of boundary value problems. its architecture may be adaptable to LIGO needs. Peter and John plan to try it out and report back. It's not yet clear how feasible it would be to incorporate DMT classes and signal processing directly into SKIRUN.
  They have not excluded the possibility of using Matlab instead. KR urged them to talk with the Penn State group and with Warren Johnson who have extensive experience with Matlab analysis.
• Next teleconference: Friday August 4 at 11:00 a.m. EDT (8:00 PDT).