Detector Characterization Robot Progress Since January 2001

1
Detector Characterization Robot(Progress Since
January 2001)
Two Main Areas of Development Now

• Design (Already exists)
• Algorithmic and Statistical studies (In progress)
• Algorithm development and fast prototyping in
  MATLAB
• Soumya Mohanty, Soma Mukherjee

• Computational Implementaion issues (C)
• Software Environment (Standalone)
• Hardware requirements
• Soumya Mohanty, B.Sathyaprakash,
• R.Balasubramanian, D.Churches

2
What are the Robots Functions?

• Detect Changes in the Multi-channel data produced
  by an interferometric detector.
• Change in each channel by itself,
• In the inter-dependence of channels.
• Each change point is of potential interest.
• For Data analysts Need to adjust GW search
  algorithm parameters/thresholds,
• For Experimentalists Change in behaviour of
  detector components or the detectors
  environment.
• Perform with known reliability and sensitivity.

3
History (January 2001 Present)

• MATLAB v6.0 acquired (May 2001)
• Enhanced external interfaces (MEX), enhanced
  Signal Processing/Statistics Toolboxes and more.
• Started developing better Matlab to Frame
  interface frmake.c (MEX file) and frgui (GUI for
  browsing and executing FrDump).
• Changes made to line removal algorithm (MBLT)
  code.
• Eliminated resizing of matrices inside for loops,
  Ways to make the code faster identified.
• Present code is completely unoptimised and very
  slow.
• Investigation of alternatives to MBLT
  (Continuing).
• Coding almost complete (Kernel Density Estimates,
  LOWESS).
• Time series modeling functionality of Matlab
  investigated.
• Severely lacking compared to advanced statistical
  software such as SAS but sufficient to start
  with.
• PBURG produces a fixed offset (30dB) in PSD
  irrespective of model order.
• Discussions started on Computational aspects.
  Several telecons held.
• Identified data set for experimentation 40m Nov
  1994 run.
• Started generating data cleaned of lines using
  MBLT.

4
Thinking on Computational Front

• Preliminary accounting shows DCR to be
  computationally expensive.
• Mainly due to the line removing algorithm being
  used in the first stage.
• The first stage line removal will be applied to
  several channels so one needs a model
  independent, transient resistant method.
• However, much improvement is possible.
• Converging to a C Digital Signal Processing
  library (very focussed in the beginning).
• C so that it can be merged, if required, with
  TRIANA, DMT, LDAS.
• Want to make a portable, well-structured library
  (data structures based on the Standard Template
  Library and not custom built).
• Will be useful when iterating over several DCR
  designs and for rapid prototyping.
• Extensive search over the web for free software
  turned up only one such project (with only one
  author) without much development.
• But bits and pieces exist Especially DSP
  appropriate data structures based on STL.
• Explored other options such as MATLAB C Math
  library or OCTAVEs (free Matlab clone) library.
  MATLAB is very restrictive as far as sharing
  concerned. OCTAVE being explored by Stas Babak in
  a different context (?).
• Looking at Class hierarchy designs. (Book on C
  DSP algorithms found not freely distributable
  software/more for teaching)
• Scoping for manpower and hardware requirements
  started.

5
Plans on the design front

• Immediate plan is to manually execute the DCR on
  0.5 hours of 40m data (locked section).
• Writing a monolithic Matlab script not useful
  since algorithms are being updated and are being
  investigated individually. At least not yet.
• Manual execution strictly follows the DCR
  implementation. There should be no hidden human
  help.
• Continue coding and development of alternative
  tools at every stage.
• Exploring line removal alternatives.
• noise floor PSD tracking alternatives
• Median filtered PSD (New),
• Time-Frequency distributions.
• Refine algorithms and remove performance
  bottlenecks.
• Example In MBLT, Upsampling proving to be the
  main bottleneck in Matlab though it shouldnt be.
  May have to write own MEX file.
• Apply DCR to several auxiliary channels also.
• Note simple problems take up time. Getting to
  know the channel names in old 40m data FrDump of
  the old FrameLib version does not produce a list
  of channel names.

6
Line Removal (Median Based Line Tracker)
-
D A T A
7
(No Transcript)
8
One-time Database of frequencies, filterband
limits, block sizes required
f_info30.718 29.9 31.5
29.0 32.0 800 39.6 39.0
40.2 39.0 40.2 1000
41.1 40.9 41.5 40.9
41.5 1000 58.8 58.0
59.6 57.0 61.0 800 70.0
64.0 76.0 64.0 76.0
800 79.5 78.0 81.0
78.0 81.0 850 109.4
108.0 111.0 106.0 113.0 800
120.0 119.4 120.6 117
123.0 800 131.9 131.4
132.4 131.5 132.5 1000
47 E n t r i e s
9
Histograms Original versus Residual data
10
Time Series
11
Autocorrelation Function
12
Tracking PSD variation Time Series modeling

• Time series modeling Estimate a filter function
  such that the observed time series is
  statistically (upto second moments) similar to
  white noise passed through this filter.
• In general a zero-pole, stable, filter can be
  found.
• Anything can be fit with a sufficiently large
  order Therefore some penalty on model order
  needed (AIC,BIC,MLD,).
• Parametric model of PSD obtained as a side
  benefit. Frequency resolution is not tied to data
  duration.
• Time evolution of Model coefficients should
  indicate non-stationarity (both short and long
  term).
• AR models (all pole) can model spectra with sharp
  spikes.
• AR models only a special cases of more general
  models ARMA (AR and Moving Average).
• Restricted to AR right now because Matlab has
  only AR modeling.
• System Identification Toolbox arrived yesterday!
  (Also Neural Net, Wavelet and Database).

New
13
Order of fitted model Necessity of line removal
14
(No Transcript)
15
Comparision with Spectrogram
16
(No Transcript)
17
(No Transcript)