Oh ok, I just thought we need to interpolate the

`\delta \tau_i^t(\tau)`

(they are from the orbit file so they are given at the sampling rate of the orbits right?) in order to match the desired sampling rate of MOC time correlations. I agree, a live discussion might be a good idea :)

Hi @j2b.bayle, I totally agree with your expansion, I confused something in my calculation, sorry for the confusion...

Regarding your second set of simplifications: I actually do not see how this would simplify the computational effort because the

`\delta \tau_i^t(\tau)`

have to be interpolated to the MOC time correlation sampling rate anyway because they still appear in the equation in the first term of the 1st order approximated coefficient.

I recall some discussions from the last months, in which it was favored to increase the MOC time correlation accuracy from 1ms to 0.1ms. From that perspective I would be in favor of not performing your second set of simplifications, but with the rest I agree except for the 1st order approximated coefficient where I get:

`\delta \tau_i^t(\tau) \cdot \left(1 + y_{0,i} + y_{1,i} \tau + y_{2,i} \tau^2 \right)`

i.e. without division by 2 and 3 in the second and third term, respectively (but this of course only matters when we decide to not use your second approximation).

Hi @j2b.bayle ,

I compared the two methods in general:

THE-dev-wrt-TCB via interpolation vs THE-dev-wrt-TCB via approximation (expansion)

The plots show the residuals for the different expansion orders, i.e. they show the accumulated error of the expansion (if I computed the interpolation correctly)

Hi all,

I computed now the_wrt_tcb using an interpolation of the_wrt_tps via InterpolatedUnivariateSpline order=5 (is this the way you would interpolate this?) and compared the result to the different expansion orders shown above:

If I did not do a mistake, the deviation between the two approaches is higher than the contribution of the higher order terms. I guess then the discussion would not about which expansion terms we include but rather about should we do an expansion at all or better go with the interpolation?

Hi all,

for the case we decide to implement the expansion I tried to evaluate the contributions of the different orders:

Short description:

Upper left: TPS deviation wrt TCB simulated with LISA Orbits using an ESA orbit file

Upper right: THE deviation wrt TPS neglecting stochastic clock noise (did not want to simulate that for 9 years), i.e.

`\delta \hat{\tau}^{\tau}(\tau) = y_0 \cdot \tau + \frac{y_1}{2} \cdot \tau^2 + \frac{y_2}{3} \cdot \tau^3,`

using y_0 = 1e-7, y_1 = 1e-14 s-1, y_2 = 1e-23 s-2.

Center left: THE deviation wrt TCB 0'th order expansion

`\delta \hat{\tau}^{t}(\tau) \approx \delta \tau^{t}(\tau) + \delta \hat{\tau}^{\tau}(\tau)`

Center right: 1'st order correction

`y_{0} \cdot \delta \tau^{t}(\tau)`

Lower left: 2'nd order correction

`\frac{y_{1}}{2} \cdot (\delta \tau^{t}(\tau))^2`

Lower right: 3'rd order correction

`\frac{y_{2}}{3} \cdot (\delta \tau^{t}(\tau))^3`

I guess what still needs to be evaluated is the error we are making when using the expansion instead of the interpolation.

Hi all,

thanks @j2b.bayle for spotting this! The tps_proper_time_deviations should definitely be included, I have the feeling I accidentally dropped them when I tried to implement #88 (closed), sorry...

I remember, that when we first implemented the tcb_timer_deviations we had exactly this discussion if we can approximate

`\delta \hat{\tau}^{\tau_i}_i(\tau + \delta \tau^t(\tau)) = \delta \hat{\tau}^{\tau_i}_i(\tau),`

and we concluded that it is fine due to the small contribution that Olaf pointed out (~1e-7s).

However, now I agree, that we should simulate the tcb_timer_deviations as accurate as possible (in particular if it is computationally not expensive and also considering, that we do a lot of effort to get the exact noise characteristics of these measurements from ESOC). Moreover, in INReP we want to fit a clock model to these measurements, and in INReP topology 3 when we try to disentangle the pseudo-ranges we are not only interested in the desynchronization but also in the clock drifts, so it makes sense t be as accurate as possible here.

@j2b.bayle Regarding your equation: I almost agree, I just do not understand why we need to square the tps_proper_time_deviations in the second term. Couldn't we just consider the USO frequency offsets as linear drifts and then write

`\delta \hat{\tau}^{t}_i(\tau) \approx \delta \tau^{t}_i(\tau) + \delta \hat{\tau}^{\tau_i}_i(\tau) + y_{0,\:i} \cdot \delta \tau^{t}_i(\tau)`

Regarding the naming: I agree with @j2b.bayle , tps_proper_time_deviations is misleading. Maybe proper_time_tcb_deviation would describe it better? For tcb_timer_deviations we could use moc_time_correlations as this is (I guess) the way ESOC refers to it.

**Jan Niklas Reinhardt**
(db1012b8)
*
at
04 Oct 14:21
*

Closes #105

**Jan Niklas Reinhardt**
(3e753acc)
*
at
04 Oct 10:58
*

Correct the default ASD of the TCB timer synchronization error

Hi @j2b.bayle, @ohartwig

Do you think the following is reasonable:

`\text{tcb sync rms} \stackrel{!}{=} 1\text{ms} = \text{ASD} \cdot \sqrt{\text{Hz}} \cdot \sqrt{f_s / (2 \text{Hz})}`

`\text{ASD} = 1\text{ms} / \sqrt{\text{Hz}} \cdot \sqrt{2 \text{Hz} / f_s} `

so default:

`\text{ASD} = 0.42 \text{s} / \sqrt{\text{Hz}}`

Or shouldn't we define this noise as ASD and just add normally distributed random numbers with standard deviation 1ms?

We set sync_asds = 1ms/sqrt(Hz). However, the sampling time of these measurements is in the order of days, default dt = 1day. Hence, considering that we still use white noise(because we do not have further information), we get for the rms value

tcb_sync_rms = 1ms * sqrt(fs/2 / Hz) = 1ms / sqrt(2 * 86400) ~ 2.4e-6s,

which is far too small.

The pyplnoise distribution has been withdrawn. For that reason the installation of LISA Instrument as specified in the README does not work.