Reports 1-1 of 1 Clear search Modify search
AdV-DAQ (Calibration)
rolland, grimaud, masserot, verkindt - was, bersanetti - 0:10 Wednesday 02 April 2025 (66485) Print this report
April fool's day.... Hrec fooled by bad suspension flags

After the maintenance yesterday, around 18h LT Michal realized that there was something strange in the reconstructed h(t), in particular the cavity pole was around 260 Hz instead of 180 Hz. Also the optical gains were not as usual (see figures 1 and 2). On the contrary, the cavity pole estimated by ISC was still ok (see last figure).

After a lot of investigations, and some injections for measurements of the optical responses and for actuator responses,  we found that the issue comes from the fact that the channels SAT_*_LN_P1 were all at 0, instead of being at 1, for BS, NE and WE (see figure 3).

We understood that the suspensions were in fact properly switched in their correct modes (by Metatron), but that the monitoring channels giving their modes were not correct. Hence Hrec was using the actuator models in HP for BS and LN1 for NE and WE, instead of LN1 for BS and LN2 for NE and WE. The use of incorrect actuator models directly impacts the estimation of the optical responses.

Note that the processes CoilsSb* were restarted around noon (see gray bands in figure 4) and the logs of these processes show a lot of error messages (python errors and ModBus errors), , to be checked if this is the source of the issue, or something else in the DSPs.  We called Valerio Boschi around 23h30 LT about this issue, to be checked tomorrow morning.

Around 23h45 LT, we restarted Hrec by temporarily forcing the mode of the suspensions to their real mode, without using the SAT monitoring channels. The optical responses are now back to nominal values (see very last part of figure 5).

 

_____________________

Around 23h50 LT (21h50 UTC), we finally  started the injections planned  for this evening/night: injections of lines at high frequency (range 1 kHz to 8 kHz) with the NE and WE PCal, to re-estimate the mechanical response of the PCal due to excitation of mirror internal (drum) modes.     (but we have skipped the injections for check hrec).

--> Injections should run to around 9h LT tomorrow morning.

___________________

To trigger this issue quickly next time, a flag must be added in the DMS to check that the suspensions are in the correct mode depending on the lock state.

Images attached to this report
Comments to this report:
carbognani - 12:54 Wednesday 02 April 2025 (66490) Print this report

"Note that the processes CoilsSb* were restarted around noon (see gray bands in figure 4) and the logs of these processes show a lot of error messages (python errors and ModBus errors), , to be checked if this is the source of the issue"

If you check the log file in the past months you will see the same error, in spite of the reported error the actions requested to the relays are always completed correctly. This is a known problem for wich a dedicated merge request on PySb is pending:

https://git.ligo.org/virgo/virgoapp/PySb/-/merge_requests/3

The proper solution would be the update of the relay box firmware but we preferred not to do it during the run.

We have survived like this so far. We could decide to implement the merge request and proceed in silencing the error if becoming too misleading like in this case.

bersanetti - 14:55 Wednesday 02 April 2025 (66491) Print this report

As Franco explained, the CoilsSb* issue is long standing and I agree it can be misleading.

However, the actuation for NE/WE/BS was correct, as we have checked during the evening, so that means that the relays were set correctly.

The same can be said for the gain values inside the DSPs, as without them the actuation would have been wrong, and probably we would have unlocked given the quite big difference between the LN1 and LN2 actuators configurations (more than a factor 10 if I recall correcly).

I can infer then that the issue was that the values of the gains were correct, but the update was not sent to the DAQ, so maybe the hiccup was at the level of SusDAQBridge?

Looking into it, I can see loads of errors of the type

  • 2025-04-02 12h46m57 UTC Thread.__init__() not called

happening once every 10 seconds, so there may be a problem there.

masserot - 15:16 Wednesday 02 April 2025 (66493) Print this report

The Thread__init message appeared the first time at 2025-04-01-06h17m27-UTC, Below the details of the SusDAQBridge server

   2025-03-30-08h32m58-UTC>ERROR..-worker: Sa_MC - F0_DC_ENBL: Got NaN. Dsp #42103 status: EXIT_DSP_NOTCONNECTED
   2025-03-30-16h32m40-UTC>ERROR..-worker: Sa_WE - ACC1_Noise: Got NaN. Dsp #31013 status: EXIT_DSP_NOTCONNECTED
   2025-04-01-06h17m27-UTC>ERROR..-Thread.__init__() not called
   2025-04-01-06h17m37-UTC>ERROR..-Thread.__init__() not called
 

bersanetti, carbognani - 16:38 Wednesday 02 April 2025 (66495) Print this report

The SusDAQBridge process was restarted correctly (a reload was not enough) and we could check online that the SAT gains were being updated again both as INFO in the VPM and online through dataDisplay.

verkindt - 19:37 Thursday 03 April 2025 (66506) Print this report

I have a done a reprocessing of Hrec for the time period where the SAT flags were disturbing h(t) reconstruction (see also elog66486), between 1427543600 (April 1 11h53 UTC) and  1427578996 (April 1 21h43 UTC).

The reprocessed data are here:
/data/prod/hrec/O4/hrepro/20250225-20250401/v1online.ffl

and the corresponding trend data are here:
/data/prod/hrec/O4/hrepro/20250225-20250401/v1online_trend.ffl

Plot1 shows a comparison of BNS range in online data (blue) and in reprocessed data (orange)
Plot2 shows a comparison of hoft_raw sensitivity curve in online data (blue) and in reprocessed data (orange).

Those reprocessed data will be then integrated to the AR frames production for chunk 20250225-20250401.

 

Images attached to this comment
Search Help
×

Warning

×