Figure 1 shows the scan of the OMC performed from 17h05 utc to 17h30 utc, after waiting for 1 hour in CARM_NULL_1F.

Figure 2 shows a zoom of this scan around a Free Spectral Range.

In this FSR, assuming a calibration factor of about 4800 for B1_PD3, we have: ~48 mW on the first order mode, ~24 mW on the second order mode, ~125 mW on the third order modes, ~170 mW on the fourth order mode, around ~40 mW on each of the 5th and 6th order modes, ... Overall, all high order modes are reduced compared to the measurement performed one week ago ( https://logbook.virgo-gw.eu/virgo/?r=64206 ).

Focusing on the 2nd order mode which appears 4 times during the scan, its power is ranging between 24 and 40 mW which is quite similar to the range of values found last week.

Tonight I found the ViolinModes DMS flag red, with the subflag related to the first harmonics (~860-900 Hz) being the one over threshold. Looking into it (Figure) it looks like the SSFS noise injections induce an excitation of the modes.

As planned, this morning at 5.50 UTC, the ETM RH powers have been changed with the iTF in 'adjusting'.

The old and new values are summarized below:

The goal of the shift was to characterize the ITF working point with the following RH powers:

The actions performed during the shift are listed below:

13.08 UTC: ITF relocked in LN3

14.18 UTC: ITF manually unlocked to perform input beam mode matching measurement with the free swinging technique and green laser scan (performed by Suzanne, Camilla and Matthieu).

                    See detailes in 64204

15.03 UTC: ITF relocked in CARM NULL 1F

16.08 UTC: OMC scan started (performed by Romain and Andrea)

16.30 UTC: OMC scan ended 

16.52 UTC: ITF relocked in LN2

After 1.5 hr in LN2, at 18.20 UTC, Andrea will proceed with the lock acquisition.

The main ITF signals during this afternoon are shown in figure 1.

Today at 13:00 LT we could see an airplane flying over the main building, probably just departed from the lane nearby; one minute later it can be spotted in the CEB microphone signals, but it did not have an impact on Hrec; some 25 minutes later it probably came back along the same route, luckily causing no effect again on the sensitivity.

The activity of today was two-fold, with the focus being on understanding the relationship between the MIR/MAR reallocation issue (and the consequent 1.8 Hz oscillation) and the CARM loop gain. The underlying idea was that the CARM loop was marginal at the higher end of its phase bubble, and even the small change in gain induced by the change in the reallocation strategy between the HighPower and the LowNoise configurations could induce the crossing of CARM in the instability region.

The first test we did was in the (currently) standard configuration during science mode, with the splitting filters misbalanced towards the MIR correction:

• 16:00:00 UTC: clean data, 240 s;
• 16:04:30 UTC: CARM loop gain increased by 5% (16 -> 16.8), 500 s;
• 16:14:30 UTC: CARM loop gain increased up to +7.5% (16.8 -> 17.2), 500 s;
• 16:25:40 UTC: CARM loop gain decreased down to ~-20% (17.2 -> 13), 600 s.

The test is reported in Figure 1, where the four traces are respectively the purple, red, black and blue ones: the structures around 1.8 Hz, already present in the standard configuration, got progressively worse with the gain increased, and completely disappeared with the low gain.

We did then a test to restore the MIR/MAR reallocation filters in the low-gain condition, but this still caused the oscillation to rise and kill the lock (Figure 2).

At this point, remembering that the current CARM gain is much higher (factor ~2) than the old one, and this was mainly due to issues in the CARM loop engagement (which happens with a different filter at the end of LOCKING_CARM_NULL_1F), we wanted to test the old configuration for the lock acquisition:

• we left the old reallocation filters we used in the past and the test in Figure 2 ;
• we reduced the CARM gain from 16 to 9 (the one we used back in the day); in order to avoid getting back the engagement issues, we added the CARM gain reduction at the beginning of ACQUIRE_LOW_NOISE_1.

Indeed the test was successful, and we left this configuration.

Then we did some noise injections on CARM, to understand better the limits with respect to B1 saturations; we used the standars LSC_noise_MICHband filter, with different amplitudes (Figure 3):

• 18:37:30 UTC: amplitude 5e-5, 120 s;
• 18:40:30 UTC: amplitude 8e-5, 200 s; here we observed 1 glitch in DARM (following a 'canonical' 25min glitch);
• 18:45:25 UTC: amplitude 1e-4, 180 s; several glitches were observed;
• 18:48:30 UTC: amplitude 2e-4; glitches were now appearing consistently, also impacting SR alignment; the injection was quickly stopped.

We need to understand how to reduce such glitchyness without losing effectiveness in the noise injection, which is not that great to begin with; the shape of the filter is already at high frequency, relatively speaking, and moving it towards lower frequencies is tricky; also, much of the B1_DC r.m.s. is gained at 5.2 Hz (DIFFp_TY line) and at low frequency in general. Given the saturation level being around +-0.06, we are never away more than a factor of 2-3.

The other topic of today was confined in the very last part of the shift, given the importance of the first one; we just made manually a noise injection on BS_TY OpLev in order to verify the shape of the filter and the overall noise: the shape looks fine, and a noise injection of 10x the sensing noise level had no visible effect (18:55:30 UTC, 300 s, Figure4, in purple noise is generated but not injected).

More analysis on both topics may follow.

Today the lock acquisition was very troublesome due an excess of noise on the West Green beam. We tried to check the coupling of the fibers on the DAQ room, but it didn't solve the problem. Then we went to the end building and tried to improve the fiber coupling by moving the fibers in the rack. We found a position where the noise was reduced. Still there is some green power missing, so tomorrow some more systematic alignment work will be done, in order to better align the green in the SHG box. After this action the lock acquisition worked properly.

A few of today's unlocks, after the wind settled down, have been caused by low gain oscillation for PR_TX (Fig.1).

Increasing the gain in CARM_NULL_1F caused an unlock soon after the transition, so we introduced a gain change in ACQUIRE_LOW_NOISE_1 (line 5232 and 5275 in ITF_LOCK.py).

The modifications can easily be reverted or made transparent (by simply setting this gain to the same value in CARM_NULL_1F and LOW_NOISE_1) if need be.

Yesterday an helicopter was seen flying close to the Virgo buildings. This was in the late morning but the ITF was not locked. And again in the afternoo (14:30 to 15:30) when the ITF was locked.

Some indication of the passages are in the first plot, showing the RMS of some microphones in the band around 50Hz.

Helicopther noise is seen also at NEB and WEB. The sound signal is visible the band up to 200Hz, louder around 30 Hz (this can bee seen in Figure 2).

To a first look no evident glitch is seen in Hrec.

Yet, the unlock (around 15:20) is associated to scattered light arches in hrec and in B8 photodiode. At that time, judgeing from the sound level in microphones, the helicopter was close to WEB.

A correlation of the two events is possible (Figure 3).

But I would advise a better look with more accurate tools.

Today we had another event of the noise suddenly disappearing, and this happened before the lock of the OMC, at 16:02:59 UTC (Figure 1); the lock of OMC and DC Readout went through fine (Figure 2).

The error signal SDB1_LC_TY_err also shows a similar behaviour to B1_PD3 regarding the 1722 Hz line, but a much more broadband effect as well (Figure 1 and spectra in Figures 3 and 4).

Unfortunately the excess noise came back already at the following lock acquisition, with the same features (Fig. 1, purple, red and blue are noise, no noise, and noise again respectively).

Looking at the B1_PD3_DC spectrum we can see many big lines (and sidebands) (Fig. 2); the most offending in terms of SNR is the one at ~6885 Hz (Fig. 3), but what is striking at a first glance is that all of them are separated by ~1722 Hz, although the lowest one is not the strongest one, so maybe also some aliasing is involved.

As part of the today's commissioning work on the MIR/MAR reallocation between IMs and EMs, the logic of the two LowNoise configurations has been changed: a new parameter, bypass_ln1, is defined as boolean in the [ITF_LOCK] section of the ITF_LOCK.ini file.

When this parameter is set to True, during the LOW_NOISE_1 transition we will keep using the Input Mirrors to actuate. And obviously nothing will be done on the relays. Also, we will prepare the End Mirrors to use directly their LowNoise configuration, i.e. LowNoise2.

During the LOW_NOISE_2 transition, we will jump directly from HighPower to LowNoise2. The only caveat here is whether we can survive acting on the IM relays when already in LOW_NOISE_2 (we usually do that in LOW_NOISE_1). The other caveat is that with the very high useism we have now, the standard lock acquisition would probably not work anyway given our current problems.

More information on the changes at the level of the actuators are reported in the aforementioned entry.

After the (unfortunately temporary) fix of DC Readout we managed to test the new logic described here; unfortunately, as feared, acting on the IM relays while already in LowNoise2 made the ITF to unlock, at least in the single test that we could make (unlock at 23:19:51 UTC); this is apparently strange, as this kind of action was done in the past for the charge measurements, but it could be that the full switch on both IMs at the same time is too much. We could think of acting on them in series on one IM at a time, to be studied.

After this test, and seeing that the useism is going down (still far from being low, though), we reverted to the standard strategy, which needs a check anyway since it is embedded in the same new logic. Unfortunately we started to have issues again in the OMC/DC Readout phase, so this is still ongoing at the time of writing.

While investigating the problem with the lock in DC readout, we noticed that the B1_PD3 audio channel was much noisier than usual for all frequencies above 100 Hz, and also the OMC PZT correction spectrum was much noisier. We also noticed that the power on the carrier TEM00 was lower than expected for a DARM offset of -0.20.

Then, without doing anything, we observed a sudden transient at 21h40 utc that made this excess noise disappear and the B1_PD3_DC power getting back to normal.

The attached figures are comparing the B1_PD3 and OMC corrections spectrum with the excess noise (in purple) and the situation right after the noise disappeared (blue).

It was then possible to relock in DC readout while keeping the same parameters as usual for the transition to DC readout.

This strange excess noise will be further investigated tomorrow.

Last night a big worsening of the weather condition  arrived (fig 1) and produced the feared increase of correction on NE / WE mirrors, touching some time 10 V (fig 2). There was no need to wait for the strong wind of today, because the microseismic region, between 0.5 and 1 Hz, was enough to create problems (fig. 3).

Today we had in mind to test a filter for the windy condition, so we proceeded like that. In fig 4 we see that a result was achieved for the low frequency (200 mHz and < 100 mHz): a worsening of the sismic signal (first plot) did not produce an equivalent worsening of the correction. Unfortunately, we were again close to the instability at 1.8 Hz.

The next planned test was to move the marionette correction from ITMs to ETMs and see the effect on the 1,8 Hz instability. We started moving the north arm and the 1.8 Hz became quickly unstable, unlocking the ITF (fig 5, fig 6). Probably the right way to do the test would have been to move both the arms at the same time, but we had no opportunity to try.

We developed a new filter, which is supposed to gain less at low frequency, improve a bit between 0.5 and 1 Hz, and behave at 1.8 Hz about like the one which worked well the past days. We are waiting for a successful lock to know if it works.

In order to achieve LN2 in the current weather condition, a change of transition strategy was required, because normally we need to pass through a locking done by only a pair of mirror coils instead of all the four. If the mirror correction often exceeds 5 V like now, very likely it will saturate when 2 coils are used with the double gain. It happened like that the time we tried the normal transition. The new strategy consists in skipping the transition to LN1: setting directly the LN2 state for ETMs actuation and moving form ITMs to ETMs in this condition, we can continue using the four coils. The strategy worked, but it was not totally tested: the final step of disabling the ITMs high power state through the relays was not tested yet. The usual glitch caused by this action could be too large for LN2. The glitch could be eventually reduced because it is due to a DC value present on the high power actuation, which can be better subtracted digitally.

To highlight the Automation code running at the beginning of the Run a dedicated O4b tag has been created into the SVN archive here:

https://apps-online.virgo-gw.eu/svn-online/listing.php?repname=advconf&path=%2FAutomation%2Fuserapps%2Ftags%2FO4b%2F&#a09ad58fb8e800bdd380464476e4a3825\

After solving the issue of the marionetta of the NI, the ITF started unlocking at acquire LN3. We noticed very fast unlocks, due to the fast shutter closing very soon. No clear loop seemed guilty, but we noticed that the DIFFp TX UGF servo was not working because its line didn't have coherence. However the DIFFp TY gain was increasing quite strongly during the transition. So we increased the gain of the loop to keep the UGF stable, and it seemed to work. We also noticed that the UGF servos were off once in science, even if the lines were ON, so we commented the commands that turn them off.

We left the ITFlocked  in LN3.

The locking troubles were due to an instability at 1.8 Hz of NI marionette reallocation. The problem appears when the correction on the mirror is moved from NI to NE, and at the same time the splitting filters with higher crossover are engaged. Such a problem has never been observed before, but in principle an instability in that region cannot be excluded. There are resonances of the two suspensions which can have slightly different frequency and can create unstable crossing points. Why this problem should appear now, after years of correct work, I don't know. Some measurement is required in order to see if the problem can be explained by a loop model, and a more robust strategy can be found. For the moment, the gain on the filter on MA branch has been changed from the nominal one (0.416) to 0.38. The instability is no more there, but clearly is not very far. Changing more the gain could create different problems, so let's leave the things like that untill a good model will be available.

We prepared and tested the SSFS noise injections:

• 700 Hz - 1000 Hz (ampl: 40)
• 400 Hz - 700 Hz (ampl: 4.8)
• 200 Hz - 400 Hz (ampl: 2.56e-2)
• 100 Hz - 200 Hz (ampl: 1.28e-4)
• 1 kHz - 10 kHz (ampl:10)

The corresponding butterworth flters have been saved in CAL_noise and the process has been restarted. After re-locking the ITF, we tested the inject_SSFS.py script in virgoDev/Automation/scripts/LSC. The test was successful up to SSFS_2, during this injection the ITF unlocked. SSFS_2 and SSFS_3 still need to be tested successfully, the noise injection amplitude is probably too large.

We tested a noise injection on SRCL using the 'SRCL_noise_butter' filter. The filter was not present in ACL_noise filter bank, we introduced it before restarting the process for SSFS. We tested the noise injection with amplitude 6.4e-3 and found good coherence. We saved these parameters in the inject_lsc.py script.

After the unlock at 21:36:06 UTC I was called because the interferometer was stuck in DOWN, with the SQZ PLLs apparently not locking.

In reality the issue was caused by DET_MAIN stuck in SHUTTER_CHECK_CLOSED, possibly because of some PD not engaged during the check. A manual cycle through INIT solved the issue and the slow shutter could be closed.

When in DOWN, ITF_LOCK asks SQZ_MAIN to go to DOWN, where the PLLs are/can stay unlocked; only after every node is back to idle, just before resuming the lock acquisition, ITF_LOCK asks SQZ_MAIN to lock the PLLs. In any case, SQZ_MAIN is managed in a looser way with respect to the other nodes and it is not blocking for the lock acquisition until the very last stages, when we want the SQZ to actually be ready for injection.

Today we put in operation a new node, ITF_CONDITIONS, and we updated the already existing ITF_STATUS one. The underlying process is described in gitlab issue #19, and the main goal is to decouple what we call ITF Modes (Commissioning, Calibration, Maintenance, etc.) to ITF Conditions (Not Locked, Locking, Locked) as conditions are something the machine is doing whatever it is we want to do with it. The Conditions are:

Conditions are automatically generated by the ITF_CONDITIONS node, which only has a few states selectable; the main is DOWN, which is basically the default state, then the node will transition automatically to the three main conditions, dependently of the status of the interferometer itself, by tracking the index of the main ITF_LOCK node. The only other functionality ITF_CONDITIONS has is the Autorelock Failsafe one, which has been migrated from ITF_STATUS. This is working exactly as before, by selecting the state of the same name. The STOP state will exit from this.

Being stripped of such functionality and old unnecessary O3 code, now ITF_STATUS only deals with the modes, that have to be set manually by people, and which describe what the machine is targeted to do (or what is preventing the same thing); the modes are changed with respect to the past, and we have a few additions; each corresponds to a given node state as usual. The complete list is in the following table, and the number represents the value of the DQ_META_ITF_Mode channel (the new modes are listed in bold):

About the new modes: Earthquake and BadWeather are to be set when the machine is in some kind of trouble in locking, because we have the effects of one of the two, the second one (BadWeather) referring mostly to high wind and/or high microseismic activity.

PrepareScience is the default mode when none of the others is actually happening: this means thatif  we are locking only to reach the nominal state and then take data, this is the mode. As usual, the transition to Science can be done from any state, and the node itself will take care of checking whether this is legit or not, based on the ITF_LOCK index as usual; the transition will be not even started in the case, avoiding going in and out even for a second. If for any reason we exit from Science (unlock, transition between LOW_NOISE_3 to LOW_NOISE_3_SQZ, etc), the node will automatically fall to PREPARE_SCIENCE, losing memory of the previous state, which we think is the right thing to do. After that, the mode will stay PREPARE_SCIENCE waiting for a manual operation.

To recap: Modes and Conditions are decoupled, independent information. The information Not Locked, Locking and Locked now are the (only) Conditions, and whatever was looking at them based on the DQ_META_ITF_Mode value should move to check the ITF_CONDITIONS_index instead.

The Modes are instead almost identical to the previous behaviour, and we just have three new modes.

The node graphs of the two nodes are attached.

EDIT: we temporarily reverted to the old ways, as there is some unforeseen and currently unexplained bug impacting the production of h(t), which should only look at META_ITF_LOCK_index, which wasn't affected by the aforementioned changes.

After the maintenance, we have had mainly two types of unlocks: some at CARM_MC_IR, which we didn't pay much attention since the seismic and wind activity are high. However, every time that we rach CARM NULL 1f we would unlock. We could see many "oscillations" on all the longitudinal loops, the PR angular loops and then saturation of B2 photodiode.

It took some time to understand the reason for these unlocks, but since they were all of them at the same moment Diego remembered that it was the moment when we enagge the CARM slow loop. Indeed it looked like it was oscillating at veyr low frequency, so we increased its gain and it worked (1/1 times, we need to see if this works in the long time). Figure 1 shows the clearest example.

WHile debugging I profited to tune the demodulation phase of MICH and SRCL on DRMI 3F, which was off by 0.2 only, then I checked it at STEP 3, and CARM NULL 3f and it looked well tuned. I also fine tuned the DARM phase in STEP3, which ws off by 0.3.

This doesn't explain the unlocks of yesteday on STEP 2 and STEP 3. We keep on investigating.

The cleanup has been completed for ITF_LOCK, and also the following nodes have been checked but basically they needed no big cleanup: NARM_LOCK, WARM_LOCK, SUS, TCS_MAIN.

A full lock acquisition has been tested already to verify that no mistakes have been done in ITF_LOCK.

We have re-enabled in the automation the SR ty line with the usual amplitude 1.8 at LN3