By David Boersma (UW-Madison)

(1) what

The DOM response service, as I understand it, is an icetray service which 
can transform a series of PDF values describing the expected distribution 
of PE times (for some given track hypothesis and a given DOM) into a 
corresponding expected ATWD or FADC waveform.

In a sense it's the inverse of a feature extractor, but not exactly. An 
important difference with a DOMsimulator is that it takes a PDF for input 
instead of a series of SPE hits.

(2) why

We need a response service for the waveform-based likelihood 
reconstruction, because photonics and other PDFs only give a sort of 
Platonic Idea of the shadow trace which we measure in the DOM cave (sorry, 
Berkeley guys). The distribution of the photon hit times will be smeared 
by the PMT and suffer from saturation on all sorts of levels. And besides, 
the measured waveforms are not always long enough to hold the full signal.

Therefore we should compare the measured signals not directly to the 
Platonic PDF. At least, not in EHE events, where many signals suffer from 
saturation and too short waveforms. For example, the WF-likelihood should 
not give a large penalty for WF bins with only a tenth the expected number 
of PE is registered, if that WF bin is at its saturation value.

In short, by using the DOM response service the WF-likelihood can do a 
so-called apples-to-apples comparison of hypothesis and measurement.

(3) how

The PDF-to-DOM-response transformation is made into a service so that it 
is separated from the WF calculation, both for the developers and for 
users.