The routine chirp_filters() computes
If the so called ``restricted'' post
-Newtonian polarizations
[leading order in the amplitude, but post
-Newtonian phase corrections]
are desired, they can be easily assembled from
and
.
The ``
'' (plus) polarization is given by
| (6.6.38) |
| (6.6.39) |
The restricted post
-Newtonian strain amplitude
impinging on the detector can also be calculated from the
output of chirp_filters() by
| (6.6.40) |
In the remainder of this section we will clarify some technical issues
involving the orbital phase.
First, in computing
in phase_frequency() we have arbitrarily
set the constant
in Eq.(
)
such that
at the beginning of the chirp.
The astrophysical convention for defining the
orbital phase angle
given in [8]
measures
in the plane of the orbit from the ascending node.
[The ascending node of the orbit is where body-1 passes through the plane
of the sky going away from the observer.]
Choosing
in this way we have assumed that
body-1 is passing through the ascending node of the orbit
at the instant we start our chirp.
Detailed information about the overall phase
is not needed for many purposes (i.e. matched filters),
therefore our choice is of little consequence.
If this information needs to be included for some application,
chirp_filters() can be modified to do so;
thus one can leave the computational engine phase_frequency()
untouched.
The second issue involving the phase is a bit more delicate.
We have used the true orbital phase
to
compute oscillatory part of the chirp in
Eqs.(
) and (
).
But should we use the logarithmically modulated phase variable
The advantage of neglecting the logarithm is that it speeds up the calculation of the chirps: we don't have to compute a logarithm at each time step. However, this may be at expense of accurately tracking the signal phase of a strongly relativistic source. After all much research has gone into computing the gravitational wave phase from these sources and we shouldn't willy-nilly discard these phase corrections. Is it difficult to modify our code to include this term? Not at all. In fact, the inclusion of the logarithmic correction to the gravitational wave phase would not affect phase_frequency(), at all. The fact that this logarithmic propagation effect only enters the chirp_filters() routine and not the phase_frequency() routine may seem like a computational quirk, but this actually has a physical origin: The routine phase_frequency() computes the local orbital phase of the binary; whereas, the physical origin of the logarithmic term is a propagation effect and has nothing to do with the orbital phase,
This is not say that no log terms will ever be needed in
phase_frequency().
Note that at post
-Newtonian
order there are log terms which do affect the local instantaneous
orbital motion of the binary,
so if phase_frequency() is ever modified to
incorporate that order, then log terms will appear there also.
Another issue involving the log term in the phase is the presence of
the ``arbitrary'' scale factor
entering the definition of
in Eq.(
).
The net effect of adjusting this constant is to change the value of
another arbitrary constant in our phase and frequency equations;
it shifts the value of
in Eq.(
).
In order to to facilitate swift computation,
we choose
to be the minimum frequency of the
requested chirp.
This insures that the ratio in the logarithm is of order unity during
the chirp computation.