Looking at the trend data on the web pages looks like the IMC unlocked as well, which is suspicious.
However, the IMC relocked immediately afterward, while it seems that there were some problems in relocking the ITF.
What happened?
seem to be correlated with large motions of the WI IP wich saturate the
correction on the WE. They triggered the change in the feedback strategy
of the WI and NI IP‘s reported later by Paolo.
Sorry for the confusion.
Adalberto arrives to support the commissioning crew..science mode recovered!
The lock has never been so stable, the dark fringe has never been so dark!
Hard to imagine what could destroy this happy state..
He is checking the detector monitoring flags..they are all green (more or less..)!
The run can start!!
The first plot shows the trend of signals during the 6 hour long lock of yesterday.
In particular, the Alp signal SIG_B2, which monitors the B2 Q/P ratio @ 62 Hz (PRCL line), before stabilized around 0, (corresponding to the optimal decoupling), where now it is around -1.3 (corresponding to a mistuning of ~52dg).
SIG_PRCL, which monitors B2_3f Q/P @ 62Hz, is instead stable over time, and the mistuning is smaller (around 30dg).
The other plots show the amplitude of the lines at the beginning and at the end of the lock.
The B2_3f phase which allows a stable lock of the ITF, gives a P/Q~2 .
The B2 phase is tuned so to have a flat TF between B2_3f_ACp and B2_ACp. The B2 P/Q coupling is more or less the same as B2_3f, ~ 2.
At the end of the lock the decoupling for B2_3f is more or less the same, where for B2 is more like 0.7.
The last plot shows the superposition of the two previous plots:
during the lock, the amplitude of the line decreases in B2_3f (both P and Q), where in B2 the decreases in P, but increases in Q.
The TF B2_ACp vs B2_3f_ACp remains in fact constant (both amplitude and phase).
Unfortunately I don‘t have a message... :-(
We had to stop and restart the locking process to recover..but we forgot to check the Gc elapsed time, which increased during this operation and the ITF unlocked again at step 10, during the NEO transition.
After that, the elapsed time seemed reasonable in await (64000), but at step 8 was too big, so we manually unlocked and we stopped and restarted the locking process a few times until the starting value was lower, around 62000.
After that we could reach science mode again.
As already reported, Matt added a protection in Alp, so that the locking sequence stops if the elapsed time is too high.
Of course it doesn‘t solve the problem, but at least reduces the wasted time,
which for us was at least 3 hours tonight...Nemo was not happy.
The alignment has been really stable for all the lock, except a short period of transparent tests..
---------------------
The transition to B2_mix caused the unlock of the ITF twice today.
I increased the B2_mix gain to -0.0014, not clear if this helps.
(only 1 success after that (first plot)..ITF still locked.). To be checked.
Stability
----------
This night we tested some long term stability of the ITF.
The ITF remained locked for at least four hours twice (see second plot), and all the unlocks were due to "technical" problems.
Sensitivity
------------
The sensitivity is now worse than before below 70 Hz (third plot).
Looking at B1, the sensitivity was good on 16th May,
13h50 UTC, at the end of a lock, and bad at 17h31 UTC, after relocking at step 12 (fourth plot):
16/5 11:27 13:27 863350068 Science Mode 12 12 -
16/5 13:51 15:51 863358674 Adjusting Mode 12 12 -
16/5 14:14 16:14 863360074 Unlock! 12 12 173
16/5 15:56 17:56 863366203 Manual unlock 1 1 0
16/5 16:08 18:08 863366923 Manual unlock 1 1 0
16/5 16:16 18:16 863367413 Manual unlock 1 1 0
16/5 17:03 19:03 863370250 Unsuccessful locking attempt 12 11
16/5 17:30 19:30 863371842 Locked! 12 12
The noise budget shows that the noise goes through MICH (fifth plot).
Since we were sleeping at that time, we are quite confident not to be guilty :-)
The only operation reported in the log at that time is Calibration automation .
We checked if the alpha filtered was changed in between, but it doesn‘t look like it was. We don‘t find anything else to blame... but since this didn‘t change, what did?
16/5 4:57 6:57 863326639 Locked! 12 12
/virgoData/CaRT/Calibration/PhotonCalibrator/CaliOptic_NI.car
at: May16,07-07:03:41 -> GPS: 863327035.
In the B1 spectrum I didn‘t see any of the lines which were supposed to be there..
to be checked...
B2_3f phase = -110
B2 phase = -25 (measured, gain = -0.00125)
B5 phase = -127
B2_3f starting offset = 300
Can we check the alpha tuning?
16/5 2:59 4:59 863319563 Locked! 12 12
16/5 4:19 6:19 863324403 Unlock! 12 12 79
It would be nice to avoid this kind of transparent tests in the near future, so to have a chance to check the long term stability of the ITF at some point...
We moved the poles in the NEO filter from 25Hz to 50Hz (old filter from entry 15798 still in NEO2). This gives much better margins (see third plot). With this filter we were able to reach step 12. The ITF appeared much more stable, but just to be sure we also set the MICH UGF to 15Hz.
In this state we measure the curve and the longitudinal noise prjection (see forth and fifth plots). As expected, MICH contributes more below 40Hz than before, but not much. This should have NO impact on the horizon, and seems a very small price to pay for a stable ITF.
This was supposed to be a quick test to exclude completely any possible contribution from control noises to the excess of noise visible in B1_ACp around that frequency.
Unfortunately, after recovering from a Gc crash, which happened as soon as we performed the transition (reboot of rios, re-closing of NE and WE LC, realigning of the ITF), we found that the linear alignment on PR engaged at step 4 systematically misaligned the mirror by some urad in tx, causing the unlock of the ITF.
The ITF was locking tonight, though there were a few unexplained lock losses, typtically with at 12Hz oscillation. Looking at the last of these (4:38 UTC), it seems that the change in the B2_3f offset (used to balance the SBs) changes the B2 phase (see Alp_Lock_SIG_B2). We checked the B2/B2_3f TF and it was not effected by this drift, so it is not clear how this causes problems or what to do about it.
We noted that, for no reason we are aware of, Beta was about half of the value seen in recent days (Gc_Driving_PRCL_NE-WE = 7e-4 instead of 15e-4).
On the noise-hunting front, we put notches in MICH and PRCL (NEO instead of NEO2) to be sure that the 241 Hz noise was not entering through those loops. These notches did not help, as we expected from the noise budget, but now we can be sure. Steps.cfg currently uses the filter with the notches, which I think is fine, but to go back simply change the filtering algo number back to 6 and reset the target algo in the following wait to 161. I would not suggest switching while locked, as this caused a Gc crash which cost about 1 hour to recover.
We also investigated the effect of the Pstab loop. We did 2 on/off test, the better of the these was: locked with Pstab ON, then OFF at 863234479, then back ON at 648. There was some noise added with Pstab off around 300Hz, and much coherence with TraRC and TraMC which goes away when it is on, so the servo seems to be helping there. Around 700Hz, there is some coherence with Sc_IB_TraRC which does not vanish with Pstab on, which might be a hint as to the source of one of the bumps seen in this region.
In particular, switching OFF the SR pump brings a further reduction of structures between 100 and 200 Hz (plots in next entry).