LISA Instrument issueshttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues2023-12-08T10:54:31+01:00https://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/139Cannot call `write()` twice on the same `Instrument` instance2023-12-08T10:54:31+01:00Jean-Baptiste Baylej2b.bayle@gmail.comCannot call `write()` twice on the same `Instrument` instanceIn the current implementation, some quantities (such as resampled GW signals, or glitches) are computed when the `Instrument` instance is initialized, i.e., inside `__init__()`. They are immediately added to the cache. When `write()` is ...In the current implementation, some quantities (such as resampled GW signals, or glitches) are computed when the `Instrument` instance is initialized, i.e., inside `__init__()`. They are immediately added to the cache. When `write()` is called, these quantities are used to compute other quantities, and as soon as they are not needed anymore they are discarded (flushed from memory and written to disk, if requested) such that they don't clutter the RAM.
This means that when the user calls `write()` a second time on the same instance, we are trying to access these quantities again in the cache but they don't exist anymore, and an `AttributeError` is thrown.
We should better handle this case by either
* Making sure that all quantities are computed in `write()`, and that the cache only lives there. That would mean that these quantities are recomputed if `write()` is called multiple times -- which is safe because users might have changed some simulation parameter in the meantime. If they have not, this is a bit suboptimal.
* Forbidding users to call `write()` a second time, by checking whether `self.simulated` is true or not.
* By not flushing, in `write()`, quantities that are computed in `__init__()`. That is a bit more efficient in terms of computation, but takes up memory (that might be an issue). Also, if the user changes simulation parameters between calls to `write()`, this will lead to some nasty inconsistencies.v1.7Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/133Fix fluctuations in distant beams2023-10-12T11:03:20+02:00Martin StaabFix fluctuations in distant beamsI think I found a bug in the calculation of the distant fluctuations in both carrier and sideband beams. As I read it, at the moment, the GW signal and TTl couples to the local offsets. Shouldn't they couple to the propagated distant one...I think I found a bug in the calculation of the distant fluctuations in both carrier and sideband beams. As I read it, at the moment, the GW signal and TTl couples to the local offsets. Shouldn't they couple to the propagated distant ones as indicated also in the "Unified model document" (see $`\nu_{21}^o`$ below)?
![image](/uploads/b5629bd9b721b974f6f814e6859947ce/image.png)
In my opinion
```Python
self.distant_carrier_fluctuations = \
propagated_carrier_fluctuations \
- (self.central_freq + self.local_carrier_offsets) * self.gws \
- (self.central_freq + self.local_carrier_offsets) * self.local_ttls / c
```
should really read
```Python
self.distant_carrier_fluctuations = \
propagated_carrier_fluctuations \
- (self.central_freq + self.distant_carrier_offsets) * self.gws \
- (self.central_freq + self.distant_carrier_offsets) * self.local_ttls / c
```
or am I missing something?v1.6Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/128Wrong units for clock drifts in the documentation2023-02-27T20:53:51+01:00HEES AurélienWrong units for clock drifts in the documentationI think `clock_freqoffsets: dictionary of clock frequency offsets [s^-1], or 'default'` should be expressed in s/s (at least such as it is used right now). Same remark for the higher order terms. If true, this is only a problem in the doc.I think `clock_freqoffsets: dictionary of clock frequency offsets [s^-1], or 'default'` should be expressed in s/s (at least such as it is used right now). Same remark for the higher order terms. If true, this is only a problem in the doc.v1.4Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/127Fix a bug in report job2023-02-28T11:02:15+01:00Jean-Baptiste Baylej2b.bayle@gmail.comFix a bug in report jobOur report job plots the MOC time couples with respect to measurement time instead of telemetry times. Matplotlib cannot broadcast the arrays and throw an error that makes the job fail.Our report job plots the MOC time couples with respect to measurement time instead of telemetry times. Matplotlib cannot broadcast the arrays and throw an error that makes the job fail.v1.4Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/126Error in definition of `telemetry_t0`2023-02-26T00:24:07+01:00Jean-Baptiste Baylej2b.bayle@gmail.comError in definition of `telemetry_t0`We currently define
```python
self.telemetry_t0 = self.t0 - self.initial_telemetry_size * self.telemetry_dt
```
where it should really be
```python
self.telemetry_t0 = self.t0 - (self.initial_telemetry_size - 1) * self.telemetry_dt
```We currently define
```python
self.telemetry_t0 = self.t0 - self.initial_telemetry_size * self.telemetry_dt
```
where it should really be
```python
self.telemetry_t0 = self.t0 - (self.initial_telemetry_size - 1) * self.telemetry_dt
```v1.4Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/125Missing `telemetry_dt` attribute in measurement files2023-02-23T15:08:59+01:00Jean-Baptiste Baylej2b.bayle@gmail.comMissing `telemetry_dt` attribute in measurement filesWe should add the telemetry sampling time `telemetry_dt` as attribute when writing measurement files.We should add the telemetry sampling time `telemetry_dt` as attribute when writing measurement files.v1.4Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/123Error when using an non zero initial_telemetry_size2023-02-21T15:47:50+01:00HEES AurélienError when using an non zero initial_telemetry_sizeWhen `initial_telemetry_size` is non zero and when using an orbit file from LISAOrbit2.X, an error is produced. I think line 685 from the code, i.e. `self.tps_wrt_tcb = ForEachSC(lambda sc: interpolate(dataset[:, sc_index[sc]], self.phys...When `initial_telemetry_size` is non zero and when using an orbit file from LISAOrbit2.X, an error is produced. I think line 685 from the code, i.e. `self.tps_wrt_tcb = ForEachSC(lambda sc: interpolate(dataset[:, sc_index[sc]], self.physics_t))` should be similar to line 656, i.e. `self.physics_t` should be `self.physics_t_withinitial`
On top of that, I think the MOC time correlation should be written by default on the output file (and not when `keep_all=True`)v1.4HEES AurélienHEES Aurélienhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/122Clock jitter noise should saturate below around 1E- 4 Hz2023-02-28T11:09:02+01:00Jean-Baptiste Baylej2b.bayle@gmail.comClock jitter noise should saturate below around 1E- 4 HzWe model the clock using deterministic drifts (for low frequency behavior), and an in-band pink jitter noise. The currently implementation for this jitter noise does not saturate below 1E-4 Hz (we use 1/simulation_size); therefore we "do...We model the clock using deterministic drifts (for low frequency behavior), and an in-band pink jitter noise. The currently implementation for this jitter noise does not saturate below 1E-4 Hz (we use 1/simulation_size); therefore we "double count" the low frequency behavior.
We should change this to saturate the jitter noise around 1E-4 or 1E-5 Hz.v1.4Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/120Report job raises an error2023-02-15T18:44:37+01:00Jean-Baptiste Baylej2b.bayle@gmail.comReport job raises an errorWe renamed `tcb_timer_deviations` to `moc_time_correlation` in https://gitlab.in2p3.fr/lisa-simulation/instrument/-/merge_requests/141, and forgot to update the report CI job. Now the latter throws an error.
See https://gitlab.in2p3.fr/...We renamed `tcb_timer_deviations` to `moc_time_correlation` in https://gitlab.in2p3.fr/lisa-simulation/instrument/-/merge_requests/141, and forgot to update the report CI job. Now the latter throws an error.
See https://gitlab.in2p3.fr/lisa-simulation/instrument/-/jobs/624384#L483.
```
Traceback (most recent call last):
File "/usr/local/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
self.run()
File "/usr/local/lib/python3.8/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File "report.py", line 85, in no_noise
plot_measurements(instru, pdf)
File "report.py", line 748, in plot_measurements
plot_tseries(instru.t, instru.tcb_timer_deviations[sc], skip=0, label=sc)
AttributeError: 'Instrument' object has no attribute 'tcb_timer_deviations'
```v1.4Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/118'dist' Ci job fails2023-01-21T23:37:20+01:00Jean-Baptiste Baylej2b.bayle@gmail.com'dist' Ci job failshttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/pipelines/218469 failed.
It seems that the package `build` is not listed in requirements.txt.https://gitlab.in2p3.fr/lisa-simulation/instrument/-/pipelines/218469 failed.
It seems that the package `build` is not listed in requirements.txt.v1.3Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/115Bug when computing THE with respect to TCB2023-01-04T15:03:19+01:00Jean-Baptiste Baylej2b.bayle@gmail.comBug when computing THE with respect to TCBhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/merge_requests/141 seems to have introduced a weird bug affecting performance when computing THE with respect to TCB.
This happens around line 916 of "instrument.py".https://gitlab.in2p3.fr/lisa-simulation/instrument/-/merge_requests/141 seems to have introduced a weird bug affecting performance when computing THE with respect to TCB.
This happens around line 916 of "instrument.py".v1.2Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/114Make `pprs` and `d_pprs` consistent2022-12-22T18:32:11+01:00Martin StaabMake `pprs` and `d_pprs` consistentAt the moment, both PPRs and their derivatives are read from file and interpolating using an individual instance of `InterpolatedUnivariantSpline`. This is a problem as the two datasets might be inconsistent in the sense that the two spl...At the moment, both PPRs and their derivatives are read from file and interpolating using an individual instance of `InterpolatedUnivariantSpline`. This is a problem as the two datasets might be inconsistent in the sense that the two splines just approximate the respective data set, hence `ppr_spline.derivative(1)(t)` could in general be different to `dppr_spline(t)`.
We suggest to use a single spline to interpolate the PPRs and then use `ppr_spline.derivative()` to express the PPRs derivatives.v1.2Martin StaabMartin Staabhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/113Missing TPS deviations from TPS in the TCB timer deviations2022-12-14T16:25:51+01:00Jean-Baptiste Baylej2b.bayle@gmail.comMissing TPS deviations from TPS in the TCB timer deviationsThe TCB timer deviations represent the deviations of the onboard clock time with respect to the TCB. They should contain the deviations of the clock with respect to the spacecraft proper time (clock offset, noise and drifts), in addition...The TCB timer deviations represent the deviations of the onboard clock time with respect to the TCB. They should contain the deviations of the clock with respect to the spacecraft proper time (clock offset, noise and drifts), in addition to the deviation of the TPS with respect to the TPS (relativistic effect).
TCB timer deviations have been initially implemented in https://gitlab.in2p3.fr/lisa-simulation/instrument/-/merge_requests/81 as
```python
self.tcb_timer_deviations = \
self.clock_offsets + \
self.clock_freqoffsets * self.telemetry_t + \
self.clock_freqlindrifts * self.telemetry_t**2 / 2 + \
self.clock_freqquaddrifts * self.telemetry_t**3 / 3 + \
self.tps_proper_time_deviations + \
self.tcb_sync_noises
```
and missed clock noise (integrated to get a time). This was fixed in https://gitlab.in2p3.fr/lisa-simulation/instrument/-/merge_requests/108. Issues with sampling of the TCB timer deviations were addressed in https://gitlab.in2p3.fr/lisa-simulation/instrument/-/merge_requests/110, but it seems that it resulted in the `tps_proper_time_deviations` not being included (they are still read from orbit files).
This is a bug that we need to fix.
Also, we might reconsider the naming of these quantities (TCB timer deviations, TPS proper time deviations, etc.) as they are complicated to remember, not super consistent nor explicit.v1.2Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/111Fix automatic versioning and latest tagging2022-10-27T11:15:57+02:00Jean-Baptiste Baylej2b.bayle@gmail.comFix automatic versioning and latest taggingIt seems that on Gitlab runners, automatic versioning always report a dirty repository.
According to https://forum.gitlab.com/t/gitlab-runner-clones-a-dirty-version-when-using-lfs/21874, this is due to Gitlab not using Git LFS, but down...It seems that on Gitlab runners, automatic versioning always report a dirty repository.
According to https://forum.gitlab.com/t/gitlab-runner-clones-a-dirty-version-when-using-lfs/21874, this is due to Gitlab not using Git LFS, but downloading LFS files with a custom script. Therefore, git thinks these files are not committed and therefore report a dirty repo.
Also, the current 'tag-latest' job seems to fail.v1.2https://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/108Fix starting time when interpolating frequency plan files2022-10-20T16:58:06+02:00Olaf HartwigFix starting time when interpolating frequency plan filesThe frequency plan files are currently always interpolated assuming they start at the `t0` of the simulation. This means we will only use the 'correct' frequency plan if the simulation start time coincides with the start time of the orbi...The frequency plan files are currently always interpolated assuming they start at the `t0` of the simulation. This means we will only use the 'correct' frequency plan if the simulation start time coincides with the start time of the orbits used to compute the frequency plan.
We should instead interpolate using the `t0` saved in the frequency plan file. Note that this is currently not possible since the frequency planning files are defined with a different time reference. This has to be corrected before solving this issue.v1.2Olaf HartwigOlaf Hartwighttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/105Correct the ASD or the TCB-timer synchronization2022-10-04T14:21:02+02:00Jan Niklas ReinhardtCorrect the ASD or the TCB-timer synchronizationWe 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 rm...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.v1.2Jan Niklas ReinhardtJan Niklas Reinhardthttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/103Bug when writing a measurement file with no GW file input2022-09-05T13:35:46+02:00Jean-Baptiste Baylej2b.bayle@gmail.comBug when writing a measurement file with no GW file inputPlaying around with LISAInstrument, I am thrown an error when running a simulation without GW inputs.
```
AttributeError: 'Instrument' object has no attribute 'gw_group'
```Playing around with LISAInstrument, I am thrown an error when running a simulation without GW inputs.
```
AttributeError: 'Instrument' object has no attribute 'gw_group'
```v1.2Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/99Dependency pyplnoise is no longer available2022-07-20T11:43:35+02:00Jan Niklas ReinhardtDependency pyplnoise is no longer availableThe pyplnoise distribution has been withdrawn. For that reason the installation of LISA Instrument as specified in the README does not work.The pyplnoise distribution has been withdrawn. For that reason the installation of LISA Instrument as specified in the README does not work.v1.1Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.comhttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/88Correct the sampling of the TCB timer deviations2022-11-01T10:02:56+01:00Jan Niklas ReinhardtCorrect the sampling of the TCB timer deviationsWhen creating `tcb_timer_deviations`, the `local_timer_deviations` and the `tps_proper_time_deviations` need to be resampled to match the `tcb_sync_noises` (they are sampled according to the telemetry contacts).When creating `tcb_timer_deviations`, the `local_timer_deviations` and the `tps_proper_time_deviations` need to be resampled to match the `tcb_sync_noises` (they are sampled according to the telemetry contacts).v1.1Jan Niklas ReinhardtJan Niklas Reinhardthttps://gitlab.in2p3.fr/lisa-simulation/instrument/-/issues/87Clock noise is not included in `tcb_timer_deviations`2022-05-16T23:13:51+02:00Jean-Baptiste Baylej2b.bayle@gmail.comClock noise is not included in `tcb_timer_deviations`TCB timer deviations should represent the difference between the clock time and the equivalent TCB time.
It is the sum of
* the relativistic effects (given by the orbits as `tps_proper_time_deviations`)
* the instrumental clock errors (...TCB timer deviations should represent the difference between the clock time and the equivalent TCB time.
It is the sum of
* the relativistic effects (given by the orbits as `tps_proper_time_deviations`)
* the instrumental clock errors (given by `local_timer_deviations`, the sum of clock jitter noise, timer offsets and frequency drifts)
* TCB synchronization errors (given by `tcb_sync_noises`)
We currently don't include the clock jitter noise, and that's a bug.v1.1Jean-Baptiste Baylej2b.bayle@gmail.comJean-Baptiste Baylej2b.bayle@gmail.com