AEI-Potsdam: Chassande-Mottin, Sintes
     Caltech: Shawhan, Whitcomb, Zweizig
     Florida: Klimenko
     Michigan: Riles
     Penn State: Mohanty
     Syracuse: Penn

Data Monitor Tool Status (John Zweizig):

• John released version 1.2 of the DMT on July 14. A complete list of changes since version 1.1 can be found in /export/home/dmt/rev_1.2/Changes on the Hanford sand or stone computers.
• The new version is compatible with the latest root and framecpp versions, which means there is a little bit of backward incompatibility. Specifically, some old dmt macros for running in the root library now must specify floating point arguments explicitly instead of assuming integers will be automatically converted to floats where appropriate. Also, old framecpp software cannot read frames produced by the new software (version 4). The new software can read old frames, however, and the present DAQ at Hanford still produces version 3 frames.
• Users who call the fillData method directly should be aware that return code definitions have changed. In particular, a new non-fatal error code indicating an interruption from a monitor request corresponds to what used to be a fatal error.
• A number of bugs in the new release have appeared and will be fixed in a revised version (1.2.1) next week. The FSeries class is being revised to handle negative-frequency FFT coefficients differently. A trend accumulation class is also being developed.
• A new perl script (dmtstatus) has been written to provide status monitoring of data flow to the DMT and will be available in the next DMT release.
• Sergey Klimenko's wavelet line removal code (see below) was also added to the last DMT release.
• John is now working on allowing communication between background monitor processes and foreground root processes to facilitate GUI display and control. This feature should be useful to experts wanting more real-time control and data manipulation than will be available in the standard display monitor. It should also be useful for special-purpose GUI interfaces for particular subsystems. This infrastructure will be developed first for use with the PSL (working with Rick Savage).
• John will be attending the LSC meeting at Hanford and plans to stay on site until Wednesday August 23.

• Line noise:

 
• B. Allen, A. Ottewill (not present)

 
• S. Klimenko (presentation)

Sergey has delivered a line tracking & removal package to John for the DMT. It allows specification of lines and harmonics to be monitored, returning total energy and amplitudes of all requested harmonics (up to the Nyquist frequency, if desired). Two filtering options are supported now, and others can be added (see Sintes talk below). The class can be used by background processes or within root.
Sergey would like to create a background monitor using the line tracking class, one that reads a config file, monitors the requested lines, periodically writes summaries of the monitoring information to a trend frame, and displays information upon request. He asked whether a template exists for such a monitor design. Some discussion ensued on what different types of monitors are needed. At least three types can be identified:
• Performance characterization where a small amount of data is written to trend frames periodically (line monitoring, for example). In developing the trend accumulation class, John will provide a template for Sergey and others to follow.
• Performance characterization where a large amount of related data is stored periodically (power spectra of key channels, for example). Peter pointed out that trend frames are scalar, meaning that an 8k power spectrum would require 8k trend channels. It is not yet clear how best to handle this information. If the data volume is not too large, one could store these in the meta-database. Otherwise, a separate disk or tape archive may be appropriate.
• Transient analysis where a small amount of data is written to the meta-database non-periodically and where EPICS alarms may be set. An appropriate template exists for this, called DaqSlice.
All three types of monitor should be able to serve requested data to the display manager when full support for the manager becomes available.
 
• A. Sintes (documentation)

Alicia has sent John her coherent-line-removal code, which has been written according to the LAL specification (procedural C code). The algorithm exploits the coherence among a line source and its higher harmonics. The code is compatible with the next official LAL release, but not with the current version.
Following up on a discussion at our last teleconference, John has proposed to Jolien Creighton (LAL librarian) a scheme in which part  of the LAL code would be targeted for being linked with the DMT, while excluding those routines needed only for astrophysical searches. The separation would allow a compact version of LAL to be used and would insulate the DMT from parts of the library that might be unstable. Jolien was unhappy with John's initial proposal, however, and John plans to revisit the issue. He believes that in the current LAL, incorporating Alicia's code would mean (in practice) linking to the entire LAL. John says that linking to the entire LAL may be inevitable.
Alicia and Sergey were encouraged to get together at the Hanford meeting to see if integrating the coherent-line-removal code into Sergey's line tracking class is feasible.

• Characterizing seismic noise:

• E. Daw (KR reporting based on e-mail)

Most of the code for the seismic and band-limited rms (below) monitors is ready and should be delivered to John by the time of the LSC meeting.
• Inter-channel correlations:

• B. Allen, A. Ottewill (not present)

 
• Bilinear cross-couplings

 
• S. Penn

Code for 2nd- through 4th-order cumulants is complete, but creation of higher-order spectra requires the fftw package which is not yet supported in the DMT. John plans to write a generic wrapper to allow substitution of fftw for the presently used fftpack routines and any new and better fft packages that might emerge in the future. KR encouraged Steve to link directly to the fftw package for the time being to allow further code development, but John said it would be highly desirable to ensure that Steve's code uses standardized multispectral routines, since they are likely to be useful for other DMT processes in the future. He suggested that he and Steve work together on incorporating fftw into the DMT to which Steve was agreeable.
• Operational state:

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

The operational state condition classes were installed by John in the latest DMT release. A sample program (background monitor), makefile and documentation can be found in the DMT directory containing the class source code (OperStateCond.cc). The supported conditions have now been greatly expanded in a private development version to allow for detection of servo instabilities (see below).

• Bandlimited RMS

 
• E. Daw  (not present - see above)

 
• Time / Frequency plots

 
• S. Mohanty

No change in status from last teleconference (but see transient report below).
 
 
• J. Sylvestre (not present)

 
• Non-Gaussian noise

 
• S. Finn, S. Siddiqui (not present - first LDAS mock data challenge underway!)

• Power spectral transients:

 
• S. Mohanty, S. Siddiqui (Soumya reporting)

As reported 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.  DMT code for the second stage is about 70% complete (more would have been accomplished if not for the recent arrival of a baby daughter - Congratulations, Soma and Soumya!). Soumya still needs some C++ code for implementing trees, but has not found a package (John suggested checking the Standard Template Library) and has begun to write his own. He believes the complete package will be delivered to John before the end of August, when he leaves for Potsdam.
• Servo instability:

 
R. Gustafson, K. Riles (KR reporting)
The operational state condition class (see above) has been expanded to include conditions to detect servo instabilities. The expanded class is complete and ready for installation into the DMT, pending a few requested changes in John's FSpectrum and Sine classes (KR is using private, modified versions for now). What remains to make the package truly useful are 1) a stand-alone background monitor using the expanded class to generate EPICS alarms and meta-database entries; and 2) a set of configuration files tuned for the key servos in the 2-km IFO at Hanford. The monitor code should be ready by the end of August, perhaps by the LSC meeting. Useful config files should be ready by the end of September ("toy" sample config files of limited usefulness will be delivered with the initial code.) KR will work with Dick Gustafson (who is stationed at Hanford) on tuning the config files. In the longer term, when full support of the display manager is available, the servo instability monitor will be enhanced to serve spectra and history information to the display manager upon request and to change controlling parameters upon request.
• Event catalog:

 
• J. Sylvestre, R. Weiss (excerpt of e-mail from Julien)

My tid software package is now in the following stage:
i) core program completed (except frame writer; likely to be a bug in DMT). Running at LHO and LLO. Includes a match filter algorithm, and a high-contrast (thresholded) time-frequency representation.
ii) control and viewer GUIs completed (viewer needs upgrade to work with ROOT 2.25).
iii) There is a filter bank for airplanes (~1000 filters) at Hanford that seems to work well (>90% detection efficiency). The bank runs in real time on a Sun 450, but more work needs to be done to trim it down a little. My guess is that a couple hundreds filters should be plenty.
iv) Filter banks are very easy to generate, e.g. in Matlab. I have matlab m files for that.

Note that tid is still in an integrated environment form; I don't have definite plans to porting it to a c++ class, although it shouldn't be hard to do so. In case of urgent need, I can probably provide a c++ 'wrapper'.

At this point, I don't know if tid will be the ultimate 'event catalog' tool. It's good for exploration, but I think it's an open research question what an optimal event catalog should be. But at this point, the code to generate event lists based on a match-filter approach is completed. tid is mature, what remains is the construction of the filters. The airplane filter bank is almost done, but other types of bursts (including impulses) need a basis for the match filter. I have a student working on E1 data to characterize transients shapes. From her results, I expect to construct a few more filter banks for different types of events.

I consider that the construction of the filter banks is a rather difficult task; I provided a tool to apply such filters that is relatively user-friendly. I also provided (or will provide) a few examples of filter banks; I think that the generation of a full basis is a task that should be done by more than one person.

So, to answer your questions about due dates:
i) all programs are done
ii) mature filter bank for airplanes before the end of August
iii) more general filter bank for seismic bursts before the end of October

I will talk to John about including tid in the official DMT release.
 

• Flickering optical modes:

 
No volunteer!!!
• Transient detection using adaptive denoising methods

 
• E. Chassande-Mottin (Eric reporting)

A paper is in preparation with Sanjeev Dhurandar describing the method. Coding for the DMT will begin in August. The package should be ready by October 1.
• Impulse recognition:

 
• No volunteer!!! (This task could be carried out as a filter bank creation in the event catalog. Although Julien does not have time to tackle this, he would be happy to help someone wishing to use the tid code).

 
• Magnetic field transients

 
• E. Mauceli (KR reporting, based on e-mail)

The code is nearly complete (after an object-oriented rewrite) and will be delivered to John at or shortly after the LSC meeting. Other environmental transient monitors are easy to incorporate using the same class structure.

• A preliminary agenda of the DC sessions at the Hanford meeting has been posted. Time allotments are still tentative, but will be finalized by the middle of next week. Other persons wishing to speak should contact KR soon(!).

 
• The posted agenda includes two round-table discussions:
• LSC activity at the sites - A proposal will be presented on the first day for increasing the on-site presence of LSC members. The details of the proposal are being fleshed out among Stan, Daniel, and KR, but an important part concerns the manning of scientific monitoring shifts to be run in parallel with operator shifts. These shifts would include monitoring of the data quality and ongoing detector characterization. It's not yet clear what will be needed, but it's likely that sometime next year we will want to run at least daily 8-hour shifts, perhaps two or even three shifts per day for periods of 24/7 operation of the interferometers.

 

 

This fall it is planned to hold a 1-2 week data acquisition and data monitoring shakedown at Hanford in a 24/7 operation mode. Part of that shakedown (tentative time frame: October-November) would include a 1-2 day engineering run with a locked 2-km interferometer, like the 24-hour run in April. It is hoped, however, that this time the interferometer would be a two-armed Michelson with recycling. Later in the fall or early winter a 1-2 day engineering run is also planned for the 4-km interferometer at Livingston. These two organized data-taking periods serves as warmups for next year, and LSC participation is important.

The round-table discussion will focus on the manpower groups can contribute to these upcoming efforts and in the longer term to on-site detector characterization, including the regular manning of scientific monitoring shifts.
 

• Off-site detector characterization analysis - The second round-table discussion will focus on off-site detector characterization analysis. Issues to discuss include computing hardware and software needs at LSC institutes and whether we need dedicated computing facilities with access to the CACR archive (more general-purpose computing than offered by the Beowulf systems). Daniel will lead this discussion.
• Although an effort was made for this meeting to minimize overlap between DC sessions and those of the advanced detector groups, while also staggering the DC and ASIS sessions, success was limited. The result is the following:
• DC and ASIS will meet simultaneously on Tuesday afternoon, but will have staggered sessions thereafter (unless both groups need the overflow session on Thursday afternoon).
• The DC session on Thursday morning (10:45-12:00) will contain talks (thought to be) of greatest direct interest to persons in the advanced detector groups, and at least one of those groups (SWG) will not meet at that time.
This limited time for a joint gathering of DC and advanced detector physicists is unfortunate. KR plans at Hanford to raise once more the issue of optimal length/frequency/scope of LSC meetings.

• Next teleconference: Friday September 1 at 11:00 a.m. EDT (8:00 PDT).