The automated noise injections on Friday 26th worked as intended: there were two minutes of noise injection on each longitudinal DoFs (Figs.1-5).
The coherence with Hrec is unsatisfying though (Figs.6-10). A finer tuning of the amplitudes of the noise injections might be necessary.
Figure 1. The CARM noise injection caused SR to move by ~0.5urad, because it made the B1 photodiodes saturate. It needs to be understood how the CARM noise injection shape needs to be changed so it doesn't cause B1 saturations which will spoil the measurement.
Figure 2. Normal daily hrec calibration measurements (between 16:00 UTC and 16:10 UTC) are no longer kicking the SR alignment.
given that the past injections performed on CARM SLOW loop through the automatic script in /virgoDev/Automation/scripts/LSC/inject_lsc.py were not sufficiently accurate (fig.1), today we increased of a factor 5 the noise amplitude. If this noise amplitude is not enough, we could increase it even further, there should be margin, see fig.2 and 3.
Today, first of all, we made a test moving the lock from ITMs marionettes to ETMs marionettes. It worked as expected (a better balancing would be required), but it unlocked with the usual 1.8 Hz oscillation when the old filters for MIR/MAR splitting were engaged. Since this fact exclude that the oscillation depends on some strange coupling with DRMI dofs, we checked again other possibilities ad we found an oscillation of CARM SLOW (fig 1). We had excluded this possibility because the first time the problem was observed, CARM SLOW appeared stable. Probably we were wrong since the beginning and the right thing to do was to work on CARM SLOW loop. Anyway, it is not clear at all why a change of actuators - supposed to be transparent in terms of loop gain - should make CARM SLOW unstable. We decided to postpone an activity on that loop, because we need more time to understand better this issue and because we should also have a look on its noise projection.
For the moment, we improved the current reallocation strategy implementing a new High-Pass filter, which is a bit more efficient everywhere and shows no issue at 1.8 Hz (fig 2). We also validated the direct transition to LN2, gaining a factor of 2 in distance from saturation during the lock acquisition. This transition is currently used by default.
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.
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.
For debugging purposes, the channels Audio and DC related to the B1_PD3 and B1s_PD1 photodiodes acquired at 100KHz are now stored with the "_FS" suffix and available in the RAW_FULL stream .
Below the list of the channels, acquired by the SDB2_DBOX_RightDown - SDB2_MezzPD2 mezzanines at 100KHz and stored with the "_FS" suffix:
V1:SDB2_B1_PD3_Audio_raw_FS nData= 100000 min= -6.11e+03 mean=-4.89e+03 max=-3.56e+03 rate= 100000Hz
V1:SDB2_B1_PD3_DC_raw_FS nData= 100000 min= -3.55e+03 mean=-3.31e+03 max=-3.07e+03 rate= 100000Hz
V1:SDB2_B1sP_PD1_Audio_raw_FS nData= 100000 min= -2.69e+05 mean=-2.67e+05 max=-2.65e+05 rate= 100000Hz
V1:SDB2_B1sP_PD1_DC_raw_FS nData= 100000 min= -3.62e+03 mean=-3.38e+03 max=-3.14e+03 rate= 100000Hz
V1:SDB2_B1s_PD1_Audio_raw_FS nData= 100000 min= 6.12e+04 mean= 6.2e+04 max= 6.28e+04 rate= 100000Hz
V1:SDB2_B1s_PD1_DC_raw_FS nData= 100000 min= 1.54e+04 mean= 1.57e+04 max= 1.6e+04 rate= 100000Hz
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).
The following plots shows a 300s FFTTime of the SDB2_B1p_PD1_Audio, SDB2_B1_PD3_Audio and the SDB2_B1s_PD1_Audio channels during the OMC lock acquisition where the purple rectangle highlights the periods with the presence of unexpected lines
Here we report a few more observations concerning the excess noise causing problems to reach DC readout.
The excess noise is visible on the audio channels of several photodiodes (Fig.1 and Fig.2): B1s, B1sP and B1_PD3 (which are on the same service mezzanine) as well as on the B1p_PD1 audio channel (however in this later case, only lines are present, while for B1s and B1_PD3 there is a clear impact on the noise floor).
As reported already by Diego, an extra noise is also present on the SDB1_LC_TX_err and SDB1_LC_TY_err signals at the same time as the noise is present on the photodiodes. This SDB1_LC_TX/TY_err signals are constructed from the SDB1 B5 QD2 H and V signals, which also see the extra noise. This observation concerning the SDB1 local control was already true yesterday (Fig.3)
Both the spectrum of the B1_PD1 audio channel, and those of SDB1_B5_QD2_H/V signals are clean when we are in CARM_NULL_1F (Fig.4).
The extra lines on B1p_PD1 and the extra noise on the B5 QD2 signals show up as soon as the OMC shutter is open (Fig.5). The lines showing up on B1_PD1 are at the same frequency as the lines seen on B1s (Fig.6), although the B1s noise floor changes when the lock of the OMC is acquired.
The first lock at 16h00-UTC was luky as the OMC lock noise disappeared just after the OMC lock with B1_PD3_Audio (plot) but not the others ones (ie 21h50m-UTC one)
Figure 1. Another channel that sees the noise is SDB1_B5_QD1_H (and all the other channels of the quadrants on SDB1). It sees the noise start when the slow shutter on SDB1 starts opening 15:59:16, then the noise level is constant, and the it stops. On B1 PD3 the noise level stops when it stops on B5 QD1, and it is present only when there is light on B1 PD3, so that is the reason why the level of noise on B1 PD3 varies in time during these 5 minutes.
This is most likely due to the slow shutter of the OMC which is mounted on an Agilis translation stage with electronic end of range stops. The stops are failing and the piezo-motor of the shutter keeps trying to push it further even though the translation stage arrived at the end of its range.
Figure 2. Shows that the OMC thermistor sees a line at ~1721 Hz when the slow shutter is in motion. This is likely the electrical cross-coupling of the voltage sent to the slow shutter showing up on the voltage readout used for the temperature measurement. In blue is when the shutter moves and in purple when the shutter doesn't move. Unfortunately dataDisplay can't seem to handle the dynamic, and making an FFTtime plot of this channel doesn't seem to work.
FIgure 3. When the shutter is closing after an unlock there is also a 1721Hz line preens in OMC1 T1, but it is 10 times smaller.
Figure 4. OMC T1 also sees the 1721Hz when opening the OMC shutter in single bounce. The line stays on for about 30 minutes, before stopping by itself. The shutter is closed 20 minutes after the line stops by itself according to the shutter log file.
Action items to debug this further and mitigate it:
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.
A new pair of reallocation filters for Arm control has been implemented, in order to get rid of the 1.8 Hz oscillation.
The 1.8 Hz oscillation appears as soon as the transition to LN1 is done and leads to the unlock a few seconds. The first time it appeared, last Saturday, it took much more time to increase up to the unlock. The transition to LN1 implies that the mirror branch of the control is moved from ITMs to ETMs, but also that the splitting filters changes from low-crossing / first order HP to high-crossing / second order HP. The second strategy is mandatory in order to reduce the correction on the mirrors and allow the transition to LN2 (very small range on mirror actuation). As we can see in fig 1, using a modified strategy for the high crossing frequency the 1.8 Hz does not apper.
The new splitting filters are shown in fig 3 and can be compared to the old ones, shown in fig 2: the new high pass is a first order and it is much less efficent. At 1.8 Hz, the marionette branch is suppressed a lot. Fig 4 and fig 5 include the respective plants and give the information about the actual impact of each branch on DARM displacement.
From what we know about this control, there is no reason to imagine a problem at 1.8 Hz, both for the old and the new strategy. Moreover, new measurements of plant for NI marionette (fig 6) and NE mirror (fig 7) has been performed, showing that no change occurred after years from the previous measurements (the measurements give no information about the response at 1.8 Hz, but the models say that nothig special should be there).
The problem of the new strategy is that it produces a quite large correction to the mirrors in LN2 (fig 8, fig 9), even if not reaching the saturation. Worse weather condition could change this conclusion, so we should be ready to implement a backup solution in that case. We need also to take into account that the transition to LN2 requires to stay locked just by a pair of coils for a few seconds, while the relays switch is performed on the other pair. In that moment the correction is doubled and the saturation is possible.
Today around 16:30:00 the ITF unlocked due to a PR trip, andthe successive three lock acquisitions failed due to bad CARM_SLOW engagements. We attempted to correct the problem by tuning the gain, but only the fourth attempt (with gain=16) was successful.
A new filter for this loop, as per 63896, is under developement
After the intervention of last Monday, the DIFFp_TX_SET servo was trying to build a signal with a line that did not exist anymore.
We changed the frequency of the demodulation to 3.3 Hz in ASC_pre and the frequency of the high-pass cut-off in DIFFp_alignment to 3.3 Hz as well. We also tuned the demodulation phase of DIFFp_TX_B1p to -1.8.
After that the offset manually added during debugging (63916) was removed and the servo changed it back to a value that minimizes B1p, as it is supposed to.
We reloaded the filters in ASC_pre to make this solution permanent. The new value of the demodulation phase is saved in ASC_pre but the config file has not been reloaded to avoid the risk of an unlock. Since Metatron does not change it, the value we set online should remain until there is a chance of reloading ASC_pre safely.
It should work as intended now (the servo brings the setpoint to a value that corresponds to the minimum of the "ball" that appear on the istogram with SDB2_B1p_DC and ASC_DIFFp_TX_INPUT, Figs.1,2), but we will keep monitoring it over the next few days.
The DIFFp_TX_SET servo is indeed not working.
For the moment, we disengaged the servo and set a better sepoint by hand, since the servo was slowly but constantly drifting away from the minimum of the fringe.
The state of the ITF was changed to ADJUSTING for this intervention and it's now back to SCIENCE.
Lately, some of the unlocks at CARM null 1f were occurring during the engagement of the first control filter of CARM slow loop (RFC 6 MHz error signal). Systematically, the engagement is characterized by an oscillation at 430 mHz (see Fig.1), which sometimes leads to the unlocks.
By looking at the model this could be explained by a loop instability due to low loop gain, in which the open loop has a 0dB crossing in a region where there is no phase margin left, which causes the arise of the aforementioned oscillation (see Fig.2, blue plot).
The issue has been easily cured by increasing the loop gain (addittionally the filter has been slightly modified by adding a missing integrator). However, in the sequence of the used filter, we switch from a very robust filter (CARM slow syn, blue fig.2) to a less robust filter with much roll-off (CARM slow test2, red fig.2) with completely different shape. This doesn't make much sense, so the situation can be improved and made less critical by changing the first filter with one with shape similar to the final one, but with less boost, in order to have less kicks during the engagement.
During the recovery of last Saturday, one of the unlocks was caused by DIFFp_TX's gain becoming too low overtime. The coherence of the UGF monitor line was too low and the servo was not functional. As a patch, the ISC crew increased considerably the lines' amplitude.
As a result, the lines became dominating on B1_PD1/2_Audio rms (63876) and caused them to occasionally saturate introducing loud glitches in the sensitivity. The issue concerns DIFFp_TX line.
Today we tried to find an amplitude that allowed the UGF servo to work while avoiding the saturation on B1 audio channels, but we observed that there was no possible amplitude that satified both conditions.
Instead, we elected to move the line at lower frequency (4.8 -> 3.3 Hz) and recalibrate the target UGF (2.7 -> 3.6). The result is positive: audio channels remain within 0.025 mW instead of
0.04 mW and the line coherence is good (Fig.1).
Moving the UGF servo line allowed Michal to lower SDB1's dithering line as well, since it is no longer "competing" with DIFFp's line.
During our tests, we noticed that the noise floor on the audio channels spike when the filters of MICH and SRCL are swapped between LN2 and LN3. We tested a lock acquisition without this filter swap (we changed the UGF servos' target as well to remain consistent with the control filters), and then introduced the new filters manually one at a time. The noise level on B1 audio channels did not increase as a result, what we observed must have been due to something else.
After this test, we leave the ITF in the final state.
We prepared and tested the SSFS noise injections:
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.
Today we had an unlock (15.45 UTC) very similar to the ones of Monday (1st of april) evening, We asked Paolo to take a look and he noticed that the signal sent to the suspensions (ASC_PR_TX/TY_CORR) got to 0 just before the unlock. We didn't see it because the signal ASC_PR_TX/TY didn't go to 0, so this cleearly pointed towards the safety TRIGGER of the loop, based on the sum of B1p QD2 quadrant. We relaxed it a bit (from 11 to 15).
After the few tests on several LSC loops that I've done (which are not worthed to be mentioned here), after the unlock of 15.18 UTC, other interventions on the machine have been made.
The only modification in the lock acquisition that I've left is the amplitude of the DIFFp TY line increased of a factor 2 (CARM null 3F step in ITF_LOCK.ini). This was done to improve the coherence of the line for the gain servo: for a couple of attempts today we experienced a loss of gain of the diffp TY , and so I had to increase the loop gain of almost a factor 2 (from 8 to 14, but only online), to compensate a slow frequency oscillation (0.4 Hz).
The angular noise injections perfomed a few days ago highlighted an excess coupling of DIFFp_TY on Hrec. In fig 1 a TF in meter per Volts of DIFFp TY correction is compared to a model: an off-centering of the beam by about 2 mm is required to roughly fit the measurement at 30 Hz. According to the angular dither lines below 10 Hz, the centering should be 10 or 20 times more accurate.
As Michal suggested, the problem is correlated to SR TY working point. By the way, an impact of SR alignment on dither signals reliability has been observed since the beginning of O4 commissoning.
We performed a measurement with SR alignment, obtaining a much lower coupling, but still a bit too high. Then we started to play with the position of the beam on the TMs, adding offsets on X dither signals. Moving the beam on WE, with a noise injection on WE TY CORR, we obtained a reduction of coupling going in positive direction. A minimum was reached, than the coupling increased again. The best point was found at 0.5, roughly calbrated in mm. From an injection on DIFFp in this position, the coupling appeared to be lower just by a factor of 2, or a bit more. Keeping this position on WE, the beam was moved on WI. A minimum coupling was found at -0.5. This time, the injection on DIFFp highlighted a stronger reduction, compatible to an off-centering similar to the expected one. The summary of the measurements is shown in fig 2.
We stayed a bit in the new position, observing a range above 50 Mpc: if something in the optical tuning was changed, it was not immediate to see. Finally we removed the offsets and went back in the standard alignment.
Angular injections performed yesterday march 18th and last march 14th have been preliminary analyzed. A noise budget wrt HREC has been produced.
In order:
For the results of Fig.s 1 and 2, DIFFp TY looks the one more limiting (to be investigated). Concerning the projections of Fig.3, results of BS both TX and TY are not reliable due to a lack of coherence with Hrec, probably due to the shape of the noise filter (bandpass centered at 5 Hz and 3.5 Hz respectively). Such measurements need to be taken again.
This morning the scope was to re-commission the scripts that inject noise on the LSC / ASC / SSFS loops. The LSC script was already ready, so we just run it to check that it was working properly. All the injections showed coherence with Hrec (SRCL wsa slighlty worse than the others, on Wednesday we would like to try a nosie injection at slightly lower frequencies 5-50Hz). The script can be found and launched at: /virgoDev/Automation/scripts/LSC/inject_lsc.py. Today's injections GPS can be found at /virgoData/NoiseInjections/LSC/LSC_injection-1394783415. Notice that during these injections the Galvo of B4 QD1 opened. To be checked if it was a coincidence or if this happens consistently.
Next activity was to inject noise in the angular loops closed on QPD error signals (Commp, DIFFp and PR) in order to adjust the amplitudes of the noise injected. Note that BR TX loop is also measurable but we mispelled the DOF name in the function to perform the injection (to be repeated on Wednesday)
Clean data: Same for the LSC noise injections.
ASC noise shape = Butterworth bandpass between 5 and 50 Hz.
GPS time stamps of the injections:
- 8.21.15 UTC + 120 sec, DIFFp TX inj ampl 8e-6.
- 8.32.10 UTC + 120 sec, DIFFp TX inj ampl 1e-4.
- 8.55.00 UTC + 120 sec, PR TX inj ampl 1e-4.
- 9.06.15 UTC + 120 sec, PR TY inj ampl 2e-4.
- 9.22.30 UTC + 120 sec, COMMp TX inj ampl 9e-4.
- 9.33.40 UTC + 120 sec, COMMp TY inj ampl 1e-3.
We also wrote a symmetric code in order to inject noise in these loops, and we tested it. It can be found at: /virgoDev/Automation/scripts/ASC/inject_asc_test.py. The .txt file with the measurements is stored in the folder 'virgoData/NoiseInjection/ASC/ASC_injection-*GPS*.txt'. We would like to finish with the BS TX on Wednesday, and then inject noise through the driving to the remaining angualr DOFs (SR and softs).
As side activity we performed an OLTF measurement of the BS TY loop through the DSP (HF brench, optical lever sensing), in order to have a response of the roll-off of the loop tf.
Noise shape: bandpass 'bpass.flt' centered at 3.5 Hz.
- 9.54.30 + 120 sec, BS TY inj ampl 5e.3
We tested again the control filter for BS TX tested last thursday. This time, it was possible to appreciate the effect of the filter (gain more at 200 mHz). GPS of the test:
- 10.36.00 + 120 sec, clean data with standard filter.
- 10.39.30 + 120 sec, test with new filter (txCorrAA2.flt).
We left the new filter as default. In Fig.s 1 is reported the measurement of the HF brench of the open loop of the BS TY, while in Fig.2 is plotted the spectra with the response of the new control filter for BS TX (red) with respect the current one (blue).
FInally, we tried to inject noise to the SSFS. The first thing we did was to comment the "define SSFS_FLT_NOISE" in order to be able to change the filters online, and then we restarted SSFS_phi, SSFS_noise and SSFS_Ctrl. We relocked and we started to try to make nosie injections. After some trials, we managed to inject noise around the UGF, and we already created a dedicated script that can be found: /virgoDev/Atomation/scripts/LSC/inject_ssfs.py. On Wednesday we would like to add two more dedicated noise injections at lower frequencies.
We will work on the script to produce the noise budget online.
Angular injections performed yesterday march 18th and last march 14th have been preliminary analyzed. A noise budget wrt HREC has been produced.
In order:
For the results of Fig.s 1 and 2, DIFFp TY looks the one more limiting (to be investigated). Concerning the projections of Fig.3, results of BS both TX and TY are not reliable due to a lack of coherence with Hrec, probably due to the shape of the noise filter (bandpass centered at 5 Hz and 3.5 Hz respectively). Such measurements need to be taken again.
given that the past injections performed on CARM SLOW loop through the automatic script in /virgoDev/Automation/scripts/LSC/inject_lsc.py were not sufficiently accurate (fig.1), today we increased of a factor 5 the noise amplitude. If this noise amplitude is not enough, we could increase it even further, there should be margin, see fig.2 and 3.
Today there has been at least one unlock in LOW_NOISE_3 due to a ~ 9 Hz oscillation on SRCL, which is its high gain limit (17:38:57 UTC). Looking into it, we found that once in LOW_NOISE_3 the SRCL (and, less badly, MICH) line coherence drops a lot, despite the line being as high as in LOW_NOISE_2, making the UGF servo not working. Also, there is hint of the (measured) UGF increasing a bit during the SR_TY misalignment.
For this reasons we increased of more of a factor 2 the SRCL line in LOW_NOISE_3 (and 25% also the MICH one), and we also decreased a bit for safety the SRCL UGF setpoint in LOW_NOISE_2, in order to start already with a lower UGF (~5.5 Hz, 2,8 in fake units), which is still safe for the LOW_NOISE_2 controller. To be monitored over the weekend.
The current lock is with the SRCL gain reduced by hand from 0.28 to 0.2; we took a series of LSC noise injections starting at 19:13:55 UTC to verify this hypothesis and for the usual purposes; GPSs are stored in /virgoData/NoiseInjections/LSC/LSC_injection-1394565253.txt. Preliminar DARM noise budget is attached. The contributions to DARM look relatively fine, but the DARM shape itself is very strange.
After some analysis it turned out that the CLEAN data during the injection suffered a "25 min glitch"; I will try to get around it or repeat the measurement.
While checking the very basic channels and not finding anything, I found instead the unexpected shape in Sc_NI_noise, which I don't even know from which card it comes from. No other Sc_*_NOISE is different from zero, except a line injected on IB which I remember being legit.
Also, a minor issue in the new SRCL_SET calibration commands was impacting the last stage of LOW_NOISE_3, with the only effect of not updating the servo calibration for the last stage. So, the correct behaviour of SRCL_SET should be checked from the current lock onwards.
Figure 1 the noise on Sc_NI_NOISE is mostly fluctuations at a few hundred mHz. And then at 1/f^3 or 1/f^4 roll-off. That doesn't answer the question of why it is there and what it is for.
Sometimes I use the probe 'Sc_**_noise' to see a signal not present in the data, which I am interested in. I add the signal just before the probe, so that the variable used for noise injections does not contain actually anything. The DSP can send a limited number of probes to the DAQ, and the limit has been reached, therefore this is the only way I have to do debugging activity without removing standard probes. In the case on NI, I forgot to remove this signal after the check.
Anyway, having some 'true' noise channel not at zero doesn't mean that the noise is actively injected somewhere: there is always a second switch that needs to be activated in order to send the noise around. And it is also true that having the noise channels at zero doesn't exclude that some noise injection is going on by mistake: there are for sure places in the DSP code where one can add noise without generating any 'noise' signal in the probes.
After restricting the CLEAN data to its first 80 s (txt file updated accordingly), a correct projection can be computed, and it is attached.
Entry of march 14th afternoon shift.
After the end of the INJ activity with injection standalone, we started (quite late) the activity.
The aim of the shift was to work on the ASC loops, in terms of calibration of the error signal and control filters in order to assest the loops situation.
To do so we performed several measurements of the open loops transfer functions (BS and PR loops). Based on the outcome we evaluated if there was the necessity of improving the shape of the control filters in order to improve either the accuracy or the noise reintroductions of the different loops.
Here the GPS of the main injections:
In Fig.s 1, 2 and 3 are reported the calibrated results of the measurement (red) superposed with the open-loop models (blue), of the injection performed on PR TX, PR TY and BS TX respectively.
The adjustment of the model allowed to compute the correct calibration factors to obtain the error signal in actual u-radians.
The calibration factor are respectively:
Based on the spectra of the BS TX loop, a new control filter has been designed and tested, to gain a little bit more (since margin is quite available), especially in the 200 mHz region. In Fig.4, the comparison of the model (OL, sensitivity and CL) between the current filter (red) and the new one (blue) is reported.
The test with the new controller has been done at 22.16.10 UTC. In Fig.5 are reported the comparison of the error signal spectra before and after the test. Unfortunately, good outcome and results cannot be totally appreciated, since during the test we were still experiencing the effect of an earthquake.
The activity will continue. Actions to be done:
Noise budget on Hrec based on the performed measurement will be posted asap in a dedicated entry.
Even if we tought we reverted the nominal control filter for PR TX, this morning we found that the new one was still running.
At a first sight, by checking the data, it looks like it worked fine for the whole acquisition. Maybe it should be good to check the right gain values for the different steps.
We left the new TX controller as default.
Today's activity was delayed by the presence of high wind activity up untill around 16.00 UTC.
Over the shift we experienced several unlocks: a couple at CARM null 1f due to a low gain of DIFFp TY loop, which was affected by a low frequency oscillation (0.4 Hz) during the transition from CARM null 3f to 1f (Diffp drift control -> full bandwidth). Almost doubling the loop gain cured the issue.
A couple of other unlocks occurred in the steady state at LowNoise 3 after few minutes of lock, right after the glitch, with the arise of a 1.1 Hz oscillation, which we think it may be related to the PR TX loop.
-----
Regarding the activity of the shift we performed several test by restoring former damper loops of the MIR roll and vertical modes of the four test masses: 9.8 Hz (TZ roll) and 7 Hz (Y vertical).
Better details will be posted in an other entry. Here we reported the GPS time stamps of the tests:
initial test with roll damper:
- 16.37.20 UTC TZ damper of NI switched on in LN2.
We encountered some issue with the reload of some old version of the configuration file ITF_LOCK.ini. After we restored the correct locking parameters we were able to reach LowNoise 3 but we unlocked shortly after.
test with vertical damper:
- 21.23 UTC: reference data with BNS range stable higher than 53 Mpc in LN3.
- 21.26.30 UTC: we reduced the dither lines on WI, NI, WE, NE by a factor 5, from 0.005 to 0.001.
- 21.32.20 UTC: switched on the NI WI NE WE 7 Hz vertical damper. The effect on DARM spectra was immediatly visible as the 7 Hz resonance decreased in amplitude.
test with roll damper:
- 21.42.30 UTC: we switched only the loops on WI and NI, since in a previous test the WE test caused an unlock.
- 21.55.45 UTC we switched on the NE damper loop, but shortly after we opened all three loops, since the mode was somehow excited.
In order to understand if the NE damper is somehow affected or can lead to some instability we tried to engage the loop alone with all the other 3 open.
- 22.07 UTC: test with NE standalone, which worked quite fine and it didn't seem to be unstable.
- 22-11.50 UTC: same test with the WE loop: we didn't unlock but the loop was not behaving well since an increase of lf correction was noticed.
----
PR TX control test:
as a last test, at 22.13.45 UTC we engaged the PR TX control filter, which was tested once some time ago. This filter is aimed to improve of almost a factor 2 the rms of the loop, and to reduce the amplitude of the sbs on several peaks on Hrec due to non linear couplings. The filter behaved well and it doesn't seem to suffer low gain instability at around 1.1 Hz.
In the future it seems worthed to evaluate the stability of the loop at every step of the acquisition in order to leave this one as default.
At 22.37 UTC we reverted the control filter to the standard one.
We left the ITF locked in LN3, with autorelock engaged and with all the damper loops OPEN, but with the amplitude of the dither lines reduced of a factor 5.
Even if we tought we reverted the nominal control filter for PR TX, this morning we found that the new one was still running.
At a first sight, by checking the data, it looks like it worked fine for the whole acquisition. Maybe it should be good to check the right gain values for the different steps.
We left the new TX controller as default.
This morning's shift was devoted to three different topics; the first part of the shift was unfortunately impacted a lot by the bad weather, with several unlocks of CARM2MC and WARM.
Topic #1: DRMI DoFs diagonalization
The goal of the shift was to move the diagonalisation of the DRMI degrees of freedom from the sensing to the driving. This should reduce the error signals of the DoFs at the correction level and thus help to (potentially marginally) reduce the contribution of the DRMI degrees of freedom to Hrec.
We had three locks in CARM Null 1f in which we wanted to test the diagonalisation on the driving (having the diagonalisation of the sensing off) at the following times:
- 11:05:30 UTC
- 12:22:30 UTC
- 13:12:00 UTC
All three attempts failed due to the weights being too high, which in particular seems to be the case for the PRCL2MICH and PRCL2SRCL values. This is rather puzzling since the algorithm that estimates the coupling is identical for the diagonalisation on the sensing and driving, so switching to the driving should have only been a matter of some signal bookkeeping.
The most likely cause thus seems to be a bug in the code. We will analyse the data and determine if there is an obvious cause.
The process which uses the new algorithm (PyDiagTest) is in the VirgoOnlineTest VPM instance, and it is decoupled from the ITF (it only reads from FbmMain and does not send cm commands); it will be used offline to debug the code, while the usual process is operational as usual. The non-diagonal driving matrix elements have been added to the re-initialization in DOWN.
Topic #2: new SRCL control filter and tuning of UGF servos in LOW_NOISE_*
Today we tested a new optimized SRCL filter SRCL_ctrl5b, with an increased roll-off; it has been tested in nominal LOW_NOISE_3, starting from 16.21.45 UTC; the results are shown in Figures 1 and 2 on the ITF and the model respectively; the two match well and the structures correspond to the expectation.
For some time it has been noticed that in LN3 the DRMI loops gain too much wrt the target UGF. This was due to two main reason: one (already mentioned in some entry in the past) was the roll-off structures of the control filters which are in the injected UGF lines region. This causes a misreading of the unity gain frequencies of the loops causing an increase of gains up to the instability regions. The second reason was partially due to the the misalignment of the SR TY in LN3.
Today profiting of the bad weather in the early part of the shift, we partially fixed this issue by adjusting the setpoint of the loops considering the roll-off structures, in order to have the correct gains in all the high power steps (LN1, LN2 and LN3).
For future reference here are reported the fake UGF set point and the real UGF of the three loops:
| DRMI loop | Fake UGF setpoint [a.u.] | Real UGF [Hz] |
|---|---|---|
| MICH LN1/LN2 | 6 | 8 |
| MICH LN3 | 3.5 | 7-8 |
| PRCL LN2/LN3 | 15 | 25 |
| SRCL LN3 | 1 | 5.5 |
| SRCL LN3 new | 0.2 | 4.5 |
In the pictures 3 to 5 are reported the DRMI OLTF with the corresponding 1/f interpolation to obtain the 'fake' UGF setpoints.
After taking 10 minutes of clean data with the new SRCL filter, we launched the LSC noise injection script to compute the new DARM noise budget; GPSs are stored in /virgoData/NoiseInjections/LSC/LSC_injection-1392741356.txt, and the new noise budget is shown in Figure 6.
The new SRCL filter has been added to the automation in LOW_NOISE_3 in place of the old one; in case this needs to be reverted both srcl_filter and srcl_ugf_set must be changed (old ones left, commented).
Topic #3: Automation changes in LOW_NOISE_3
Given that we cannot perform the lock acquisition with SR already misaligned but we are forced to keep the current scheme, we modified how the LOW_NOISE_3 state behaves: now it keeps the DRMI lines on, and the UGF servos as well, while the SR is getting misaligned. Once it detects that SR_TY is within a certain range with respect to the desired setpoint (currently 170 +- 5 Hz) it disengages the DRMI UGF servos and turns off the relevant lines. The GUI will show the process via notifications.
The current scheme is good enough for the commissioning; in view of the Run we may either want to keep this (but flagging with a to-be-created DQ channel when the process is really over) or move everything to ACQUIRE_LOW_NOISE_3, which may have the opposite drawback to keep from Science mode until SR has finished moving. The former solution is a little more confusing and needs a double check (state index and DQ channel) but the latter will reduce the LOW_NOISE_3 duty cycle. This will be discussed during the Run preparation.
Leftovers to be done:
The task of the shift was to make the whole lock acqusition with the SR ty close to the final position (~200Hz of DCP) in order to avoid the transient at LN3 which will detune the optimal tuning for the controllers.
We observed that this could not be done if the SR ty initial position is in the wrong side of the "Parabola". If this case happens the servo will bring the SR ty further away. Then for sure we have to start from the aligned position.
The automation has been restored in the normal configuration.
In any case other ideas to have the science mode with the optimal tuning are present and will be implemented next week.
This morning we continued and completed the recovery of the ITF lock up to Low Noise 3.
Low noise 3 reached a first time at 08h27 utc.
We use these data from 08h27 to 08h29 to check the blending of the B1s photodiode (see Fig.1 and Fig.2). The blending seems OK.
We had some data with stable BNS range around 52-53 Mpc from 09h00 up to ~09h35 utc (Figure 3).
During the previous lock acquisition we realized that we had forgotten to restore the B5 QD2 offsets used for dark fringe. This was done at next unlock, at 10h36 utc.
FbsDet: Remove SMS SDB2_dbox_bench, reload Config at 10h42 utc to recover SMS data produced by this process.
With Michal we changed some logic in DET_MAIN node in order to fix the issue with DET_MAIN node getting stuck in the state "SHUTTER_READY_FOR_CLOSING" when B1s safety is triggered (https://logbook.virgo-gw.eu/virgo/?r=63361):
The DET_MAIN node has been loaded without issue.
ITF unlocked during lock acquisition from step 115 (transition of the DARM hand-off to B1_PD3) at 10h55m48 utc. Figure 4 shows that DET_MAIN wend to DOWN at the time of the unlock and then worked properly, renabling the B1s photodiode when passing through SHUTTER_CHECKED_CLOSED.
Opening and Closing of OMC shutter tested successfully with ITF in DOWN around 10h59 utc.
With ITF in DC readout: we adjusted the B1 demodulation phase for the OMC lock: changed from -0.64 to -0.40 rad at 12h11 utc.
Low Noise 3 reached at 12h18 utc (Figure 5), and interrupted manually at 12h43 utc to allow an activity on the automation.
Figure 6 shows what happened when the lock was interrupted: DET_MAIN passed correctly from the state "SHUTTER_CLOSED" to the state "SHUTTER_CLOSING", before going to DOWN. B1s safety was triggered when DET_MAIN was in SHUTTER_CLOSING, but the photodiode was reactivated in SHUTTER_CHECKED_CLOSED and DET_MAIN eventually made it to SHUTTER CLOSED.
the attached figure shows the successful test of DET_MAIN (cycle of SHUTTER OPEN / SHUTTER CLOSED) with ITF in DOWN.
The task of the shift was to make the whole lock acqusition with the SR ty close to the final position (~200Hz of DCP) in order to avoid the transient at LN3 which will detune the optimal tuning for the controllers.
We observed that this could not be done if the SR ty initial position is in the wrong side of the "Parabola". If this case happens the servo will bring the SR ty further away. Then for sure we have to start from the aligned position.
The automation has been restored in the normal configuration.
In any case other ideas to have the science mode with the optimal tuning are present and will be implemented next week.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png){kind=link}
.png){kind=link}
.png){kind=link}
.png){kind=link}
.png){kind=link}
.png){kind=link}
.png){kind=link}
.png){kind=link}
.png){kind=link}
