The TCS shift is ongoing. We started the acquisition with HWS-INJ and HWS-HR WI at 8.50 LT.
The WI RH will be turned on at 11.00 LT (P=15 W) and it will be turned off this night (a new entry will follow).
Thank you to Giulio, Stefano and Giuseppe that fixed the connection bug on the HWS pc.
13:00 UTC ITF found unlocked. Before the beginning of the activty commissioners tried to relock ITF up to Low_Noise_1 without success.
17:00 UTC started the planned activity on OMC lock optimization carried out by M. Was (from remote). In order to allow the activity W arm and NE has been misaligned.
20:38 UTC OMC activity concluded.
20:40 UTC ITF realigned and left unlocked for the TCS planned activity of tomorrow following the instructions of D. Bersanetti.
20:43 UTC Stop Commissioning Mode.
Injection
SL_TempController grey flag on DMS. No connection with Tango Server (Server works fine). A failure occurred at Slave laser crystal #1 PID module.
15:00 UITC TempControllers manually restarted in EERoom (Laser OFF/ON with Genin). Problem not solved.
No temperatures monitoring of Diodes and Cristals. On Operator workstation the EERoom camera is oriented showing the controller displays.
| Actual values | 27.0 | 28.0 | 25.0 | 25.1 |
| Set point | 27.0 | 28.0 | 25.0 | 25.1 |
ACS - WE
Climatization out of service at West End Terminal hall
DMS - ACS_WE
Flags shelved till Monday under request of the expert:
INF..WEB_HALL_TE
HVAC..WEB_COLD_TE_ERR
HVAC..WEB_HOT_TE_ERR
INF..WEB_CHILLER_PRES_IN
INF__WEB_CHILLER_TE_OUT
INF..WEB_HEATER_PRES_OUT
DMS - Injection - LaserAmpli
Thresholds changed under request of the expert.
PSL..AMP_DIODE_1_TEMP
PSL..AMP_DIODE_2_TEMP
PSL..AMP_DIODE_3_TEMP
* confirmed that there is an offset in the OMC1 lock point, it seems stable compared to last week
* unclear whether the slow oscillation is a cross-over issue or some real signal
As the dark fringe couldn't be reach stably, the work was done on a single bounce beam from NI.
Continued work on understanding the OMC lock RMS started last week
Turned Faraday rotator to send most of the beam toward the squeezing bench: Channel 1 axis 2, -46150 lowered to -10150
Figure 1, OMC1 offset at 5e-5 is still a good way to lower the 119Hz line coupling.
Figure 2, this offset is also lowers the coupling of a broad-band noise injection (1e-4 V/rtHz from 0 to 5kHz)
17:54:30 (1min) injecting 3e-5 V/rtHz up to 50kHz with 0 offset
17:56 (1min) injecting 3e-5 V/rtHz up to 50kHz with 5e-5 offset
Figure 3, the lowered coupling is up to ~10kHz, above that there isn't much difference
Exploring further an offset of 5.5e-5 is even better. Figure 4, a factor 100 better than without offset as shown on figure 1.
For OMC2 I have tried to optimize the offset, but kept going in circles, it seems the slow oscillation is dominant.
Unlocked OMC2, and look at the offset to minimize the coupling of the 119Hz line, it changed to 4e-5. The slow oscillation of +/- 0.2 V in the PZT correction is still present (and it corresponds to an oscillation in 119Hz line coupling factor, with the coupling large when the PZT correction changes quickly). So the oscillation is real, and is not due to some OMC1/OMC2 cross-talk.
18:48-19:09 injection into OMC1 PZT, shaped (amplitude 3.0, pole at 10mHz, zero at 100mHz, butterworth at 0.5Hz)
changed PZT feedback filter replaced Q=1 pole-zero pair at 0.1-0.3Hz, with simple pole-zero at same frequency
19:23-19:33 repeating same injection into OMC1 PZT, the cross over moved from 15mHz to 250mHz (see figure 5)
relocked OMC2 in this asymmetric configuration (with OMC1 cross-over much higher than OMC2)
19:40-19:46 stable data
changed OMC2 PZT feedback to filter the same way as OMC1
19:47-19:52 stable data in this configuration, it doesn't seem like anything changed in the lock (figure 6).
Could try to boost the control filter and suppress this signal (but first I need to learn how to do that without large transients)
putting back usual PZT filter and unlocking OMC2
19:55 injection into OMC1_err (length loop)
20:01-20:11 increased amplitude from 1e-5 to 3e-5
20:15-20:24 injection with additional shaping to increase low frequency
more analysis on the loop measurements and steady state data will follow
Put Faraday rotator back to maximum throughput, seems to be a very different place -37650, maybe went down too fast and some commands where not actually executed by the rotator?
About the IMC: the IMC is lock-cycled on purpose during FmodErr if the PZT correction is outside thresholds; if it does that very often, that could point to an issue between the PZT and the IMC length driving. Maybe it has a common cause with the fact that the IMC unlocks frequently while scanning for the RFC resonance, as "big" movements of the cavity length are done in the process.
About Lock Acquisition: all the phases should be restored, we can relock to LOW_NOISE_1 but the PR loop (in DF) should be re-checked, as it was not working properly; I removed the 150 Hz notch as it often killed the lock in DF; PRCL_GAIN for dark fringe is strangely lower than usual. To be checked.
At the moment, the ITF is unlocked, the PR mirror is misaligned (as usual), the BS and NI mirrors are aligned (as usual), but the NE/WI/WE are misaligned, to allow the Friday afternoon shift. Here are the Automation instructions for the following activities: keep an eye on the DMS just in case.
What to do after the Friday afternoon shift: realign the arm cavities, and relock tthe arm cavities: all Metatron nodes but the following should be ignored;
- leave ITF_LOCK in PAUSE; because of this, you can ignore the managed/unmanaged status of every other node you are going to drive;
- leave INJ_MAIN as it is: the Injection system is standalone, no FmodErr tuning will be performed (it is disabled), it will recover itself in case of unlock of the IMC;
- CARM_DARM_LOCK: now it is in the MISALIGNED_ALL_BUT_NI state; bring it to DOWN, then ask for LOCKED_ARMS; when the arms are locked, wait for a few minutes until the arm cavity powers are stable (B7_DC ~ 0.38 mW, B8_DC ~ 0.35 mW); after this, ask again for the DOWN state;
- if you cannot see flashes on B7 and B8 DC (>= 0.1 mW), make sure that the shutters of B7_PD1 and B8_PD1 are opened from the VPM (they should); in case they are not, click on the "gear" near the SNEB_dbox_bench and SWEB_dbox_bench processes titles, then click the "gear" on the MezzPD section, Rearm, then Open);
- if you still cannot see the flashes, give up and go to DOWN; alignment will not be perfect on Monday, but the Saturday shift will be unaffected; however, please check (just from the VPM) that all the Automation Suspension Nodes are "ALIGNED" except SUS_PR, which should be "MISALIGNED";
What to do after the Saturday morning shift:
- leave ITF_LOCK in PAUSE;
- leave INJ_MAIN as it is;
- CARM_DARM_LOCK: now it is in the DOWN state, ask for LOCKED_ARMS; everything else from the previous section still applies, but the TCS activity may have 'spoiled' the West Arm power; if it locks and the situation is similar to the last TCS activity, any steady power around ~ 0.1 mW should be enough; if the arms seems reasonably stable, leave them locked;
- if you still cannot see the flashes, give up and go to DOWN;
This morning, one of the 4 PIDs used to control the temperature of the slave laser had a failure.
The module has been substituted and seems to work properly but now the server acquiring the temperature of the slave laser pumping diodes and crystals is not working properly.
We tried to adjust the settings without success. We will try to fix it next monday.
The new pump will arrive on Tuesday but tomorrow morning an attempt will be made with a similar reserve pump, which however needs a small adaptation.
Even if I tried to mitigate the effect by acting on the relative Eurotherm controller, Hall temperature may not be stable as usual.
- PSL work and acoustic injection inside laser lab.
- complete the software freezing on rtpc2, rtpc6 and rtpc12; SSFS_Ctrl software test.
at around 11:45utc we started to relock/recovery, in progress...
-inj
from around 10:40utc we started to have missing data from SL_TempController I tried to stop/restart the SL_TempController and also the related tango server but this didn't solve the problem.
This morning during the ISYS shift, we installed the speakers (ENV_NOISE_CEB_EEroom ) and the microphone (ENV_LLR_MIC) in the atrium of the laser lab in order to perform acoustic noise injections.
We then injected noise, making some trials to set the desired type and amplitude. In the attached plot we injected colored noise around 2 kHz (with 1 kHz bandwidth) with amplitude 0.005.
We will make further injections during next monday morning shift, while trying to reduce the noise coupled into the ML fiber by changing the input polarization.
We noticed a decrease of the intensity measured by the WI HWS. We optimized the waveplates in order to bring back the intensity around 3500 counts (see the attached figure). This has allowed to decrease she SLED current from 194 to 34 mA.
we mesure the power at LB_M9 (neoVAN output), at LB_M11 (AOM output) with and witout the block "L/2 - Brewster polar - L/2" right before the AOM).
we deduce:
Tuesday 17/04/18 we check that the dust we have seen on the pump fiber of the neoVAN (PSL-FOPT-1703-03) did not change, increase and could be responsible for our trouble wrt the neoVAN beam profile. This dust has been seen for the first time during the moving of the neoVAN diode from the laser lab to the eeroom; we had to disconnect the fiber from the head and then we saw the burnt "dust".
we see no change wrt the data from the 15/01/18
on 17th Apr 2018 we check the beam profile at the PMC output to check whether there could be some diffracted light connected with the PMC intra cavity loss.
we use a camera at the focus of a 0.5 m focal length lens
-> difficult to conclude, there is a small pedestal but hard to say to what this is connected
@ ~9:00-10:00 LT we swap the LB_DB_AMP_L1 lens from F=0.4m to F=0.5m. we keep the same position for the lens (~ 0.655 m from neoVAN).
the beam waist should be 829 um at 2,1 m from LB_DB_AMP_L1
this means a beam size at DB_AMP_QD_FF = Dvg*(F=0,813 m) = 332 um
this means the same beam size at the DB_AMP_PD_3mm, the PD with monitor the AMPL power (3mm diam)
The beam size at DB_AMP_QD_NF = 1047 um (located 0.465 m from LB_DB_AMP_L1)
We install a UVFS plate with 1 side AR coated after the LB_DB_AMP_L1 to feed a camera and monitor the neoVAN beam profile in the far field
of this lens (F=0.5 m). The AOI is to be confirmed together with the distance to the lens.
The beam is left miscentered on the camera waiting for the configuration of the latter
NOtice that by the end of the shift we disabled the FmodErr after every unlock, in case there was a problem on the logic. However, the scan of the RFC would bring the IMC very far from the good working point of the sidebands (~ 1mm). And also on the process the Thermal corrections of the laser would go to 1.3. I reseted them manually and that seemed to fix the problem for a while.
ALso while doing the FmodErr by hand I noticed that the IMC would unlock even for slow/small movements of the z, so maybe that can explain why while scanning the RFC it goes so far, if it unlocks often on the process. To be followed!
This night/morning we have put in operation large part of the software associated to the VCS-10.0 release. This release is dedicated to the CentOS7 upgrade wrap-up and to the (hopefully coming) Engineering Run at the end of April.
Further below is the provisional list of involved packages all installed in /virgoApp. The baseline of Basic/Core packages is the following (please use it for any not yet aligned software):
- use VirgoPolicy v2r6 (/virgoApp)
- use Fr v8r32p1 (/virgoApp)
- use Frv v4r28p4 (/virgoApp)
- use CSet v2r16 (/virgoApp)
- use Cm v8r12p5 (/virgoApp)
- use Cbf v4r13 (/virgoApp)
- use Cfg v8r06p2 (/virgoApp)
- use Fd v8r20p4 (/virgoApp)
For what concern the Python bindings the new versions now in use wrapping Cm v8r12p5 and Fd v8r20p4 are correspondingly PyCm v5r2 and PyFd v2r2.
PythonVirgoTools version has remained unchanged (v2r0)
Considering Virgo Online subdivisions in VPM, this is the situation in terms of process stop/restart from frozen versions:
Completed
- ADC7674
- Minitowers
- ISC
- Squeezer
- Injection
- TCS
- Suspension
- Data Collection
- Storage - Stol01
- Storage - Stol02
- Storage - Stol03
- Automation
- SMS host
Partially done
- Detector Environment Monitoring
- Vacuum
- Data Access
Not done
- Detector Monitoring
- Control Room
- DetChar
- Calibration-Reconstruction
Hopefully, the remaining processes (which stop/restart is supposed to be less invasive over Commissioning activities) will be dealt in the coming days once aligned versions will be made available.
Updated information over VCS-10.0 Release can be found online at:
https://wiki.virgo-gw.eu/Software_Management/VCS-10-0
-------------------------------------------------------------------------------------------------------------
Provisional VCS-10.0 software baseline
use CanAPI v3r10 (/virgoApp)
use libmodbus v3r1p40 (/virgoApp)
use libusb v0r3 (/virgoApp)
use VISA v0r2 (/virgoApp)
use PackageBuild v0r14 (/virgoApp)
use Glib v2r48p22 (/virgoApp)
use Cairo v1r14p82 (/virgoApp)
use GStreamer v1r10p22 (/virgoApp)
use Aravis v0r4p14 (/virgoApp)
use Comedi v0r8p10 (/virgoApp)
use FFTW v3r3p30 (/virgoApp)
use root v5r34p050 (/virgoApp
use VirgoPolicy v2r6 (/virgoApp)
use Fsm-AdV v1r0 Sa (/virgoApp)
use Filter-AdV v0p1 Sa (/virgoApp)
use Digfilt-AdV v1r6 Sa (/virgoApp)
use Fr v8r32p1 (/virgoApp)
use Frv v4r28p4 (/virgoApp)
use CSet v2r16 (/virgoApp)
use Cm v8r12p5 (/virgoApp)
use Cbf v4r13 (/virgoApp)
use Cll v1r20 (/virgoApp)
use Log v2r8 (/virgoApp)
use Cfg v8r06p2 (/virgoApp)
use AdvancedCommunication v5r10p1 (/virgoApp)
use Bc v5r6p1 (/virgoApp)
use Sb v2r4p1 (/virgoApp)
use ActuatorDrv v5r4 ISYS (/virgoApp)
use ActuatorSrv v4r3 ISYS (/virgoApp)
use ActuatorApp v5r1p1 ISYS (/virgoApp)
use Fm v4r07p1 (/virgoApp)
use Fd v8r20p4 (/virgoApp)
use PythonVirgoTools v2r0 (/virgoApp)
use Rtai v6r8 (/virgoApp)
use TolmDictionary v1r4 (/virgoApp)
use TolmUtilsForSa v1r3 Sa (/virgoApp)
use Damping-AdV v4r3p5 Sa (/virgoApp)
use GxNew v2r15 (/virgoApp)
use TolmBase v13r0 (/virgoStaging)
use Fbs v8r14p13 (/virgoApp)
use TolmFrameBuilder v4r7p13 (/virgoApp)
use DaqBox v13r0 (/virgoApp)
use TolmProcessor v13r0 (/virgoApp)
use Acl v0r52p13 (/virgoApp)
use Imaging v13r0 (/virgoApp)
use TolmComedi v13r0 (/virgoApp)
#Python
use PyCm v5r2 (/virgoApp)
use PyFd v2r2 (/virgoApp)
use PythonVirgoTools v2r0 (/virgoApp)
use TangoDAQSmsBridge v5r2 (/virgoApp)
use PyALP v2r0 (/virgoApp)
use PyRingHeater v1r2 (/virgoApp)
use PyPlc v0r0 (/virgoApp)
use PySbModi v3r1 (/virgoApp)
use PySb v1r1 (/virgoApp)
use PartCount v2r0 (/virgoApp)
use PyArtic v1r1 (/virgoApp)
#SAT Tango
use DspServer v2r8 Sa (/virgoApp)
use MchServer v4r2 Sa (/virgoApp)
use LcuServer v2r4 Sa (/virgoApp)
use PduServer v1r4 Sa (/virgoApp)
use SatServer v1r3 Sa (/virgoApp)
use TangoSrvMtr v5r0 Sa (/virgoApp)
#INJ Tango
use sdt2011 v7r0 (/virgoApp)
use Lnfs100 v7r1 (/virgoApp)
use SL_TempController v7r0 (/virgoApp)
This afternoon we worked on several topics.
- Alignment: We explored different working points, both for the PR @ MICH offset 0.1 and BS @ DF. In the case of the PR we tweaked the offsets in order to reach the DF better aligned, so that the AA in DF needs to move less the mirror. For the BS we opened the loop and we tried to optimized the powers at all the ports. We found a particular working point that seemed to make the dark fringe darker and the sidebands recycling slightly higher at the same time (see Figure 1). We left the new offsets saved on the ini file for what concerns the BS. About this latter loop, there is still some improvement to do adjusting the gains of the TX loop.
- OMC: we made a trial of locking the IMC without success, Michal took a look to it and adjusted one parameter, however we did not have time to re-try.
- 10 kHz:the SSFS signal was affected by a strong line at 10 kHz. Alain found and fixed the problem, related with the change of the frequency of the sidebands at the LNFS. More details will be posted by him.
- We have added a line in Metatron which fixes the value of the crossing point between both loops of the SSFS. The parameter can be found on the CARM_DARM_LOCK.ini, and is called "carm_mc_cross_gain"
NOTA: After the work of Alain, the demodulation phases changed. We have adjusted only the ones allowing us to reach LOCKED_SSFS. Tomorrow, the rest have to be checked!
NOtice that by the end of the shift we disabled the FmodErr after every unlock, in case there was a problem on the logic. However, the scan of the RFC would bring the IMC very far from the good working point of the sidebands (~ 1mm). And also on the process the Thermal corrections of the laser would go to 1.3. I reseted them manually and that seemed to fix the problem for a while.
ALso while doing the FmodErr by hand I noticed that the IMC would unlock even for slow/small movements of the z, so maybe that can explain why while scanning the RFC it goes so far, if it unlocks often on the process. To be followed!
About the IMC: the IMC is lock-cycled on purpose during FmodErr if the PZT correction is outside thresholds; if it does that very often, that could point to an issue between the PZT and the IMC length driving. Maybe it has a common cause with the fact that the IMC unlocks frequently while scanning for the RFC resonance, as "big" movements of the cavity length are done in the process.
About Lock Acquisition: all the phases should be restored, we can relock to LOW_NOISE_1 but the PR loop (in DF) should be re-checked, as it was not working properly; I removed the 150 Hz notch as it often killed the lock in DF; PRCL_GAIN for dark fringe is strangely lower than usual. To be checked.
One potential source for the 10 kHz comb might be the SSFS_Ctrl process, where some signals are up-sampled from 10 kHz to 500 kHz.
The shift has been dedicated to the ITF recovery and to the fine tuning of the ASC loops with MS.
Infrastructure / ACS_WE - At about 19:00 UTC the DMS showed an increasing of "mean_HVAC__WEB_COLD_TE_ERR", the expert came onsite in order to understand the problem. After a check D. Soldani communicated us that the WE refrigeration unit is blocked and it will be need an intervention of the external firm (tomorrow morning...), however we don't expect an increasing of the temperature for the night.
21:00 UTC - ITF left in Commissioning Mode due to the night shift scheduled (~in progress).
Figure 1, shows the comb, which is at exactly 10kHz (or less than 100mHz away from it), so it is likely to be some digital issue.
Figure 2, there is also a line at 229.22kHz which is a factor few high higher than the 10kHz and is dominating the RMS, so the 10kHz comb is not visible when looking at the data time series.
Too look more closely I have notched 8 of the high lines above 100kHz, and also reconstructed the signal using the amplitude and phase at all the multiples of 10kHz
Figure 3, shows the spectra of the two construction and the original data, the 10kHz comb follows roughly 1/f, which could be explained by a sawtooth signal
Figure 4, shows the time series, after notching the 10kHz wave is somewhat visible with a fast rise and slow decay, and in the pure comb signal the decay looks more like a sine-wave, the rise time is not exactly at the second, but 23us behind.
Summary of the morning shift:
- for the first half of the shift, we saw increased frequency noise as in the past days, so we had to try and overcome it by changing the SSFS crossing frequency and the SSFS gain during lock acquisition; when we managed to get to LOW_NOISE_1, things got better thanks to the SSFS, but the noise is still there; the shape of the loops did not change changing the crossing frequency, as opposed to the previous trials (Fig. 1, PRITF @ 0.7 Fringe);
- when using the base filter for SSFS a huge line, with structures and bump around it, shows up at 10 kHz; it immediately disappears once we switch to the boost filter; the issue was already there a few days ago;
- what is strange is the overall noise level increase, even in the range of the sensing noise floor and after the cut-off of the PD electronics/acquisition chain; see Figure 2, step LOW_NOISE_1, compared to a good lock of three days ago;
- in the second half of the shift the noise level decreased and we got good locks as at similar times in the last days; the 150 Hz-ish line is occasionally present in DARM but not at all times, and it can show up or disappear in lock; DARM is most affected by it, with a little cross-talk to MICH/PRCL; it does not show up in the SSFS signals;
- what killed most of the locks, which are quite stable and repeatable if not for the following, is a sudden oscillation/glitch at 24 Hz, clearly visible in DARM; it looks like a quick loop oscillation, but it happens also when MICH has a quite low UGF.
These three issues (24 Hz, "150" Hz and 10 kHz) are currently the focus of our investigations.
Figure 1, shows the comb, which is at exactly 10kHz (or less than 100mHz away from it), so it is likely to be some digital issue.
Figure 2, there is also a line at 229.22kHz which is a factor few high higher than the 10kHz and is dominating the RMS, so the 10kHz comb is not visible when looking at the data time series.
Too look more closely I have notched 8 of the high lines above 100kHz, and also reconstructed the signal using the amplitude and phase at all the multiples of 10kHz
Figure 3, shows the spectra of the two construction and the original data, the 10kHz comb follows roughly 1/f, which could be explained by a sawtooth signal
Figure 4, shows the time series, after notching the 10kHz wave is somewhat visible with a fast rise and slow decay, and in the pure comb signal the decay looks more like a sine-wave, the rise time is not exactly at the second, but 23us behind.
One potential source for the 10 kHz comb might be the SSFS_Ctrl process, where some signals are up-sampled from 10 kHz to 500 kHz.
Erratum!
The lock losses are not "Defined as a Metatron node making a transition from a higher state to down or init" but rather as a Metatron node transitioning from a nominal state of ITF_LOCK (META_ITF_LOCK_index) to DOWN or INIT. Indeed, they are basically defined according to flag channels DQ_META_LOCK_LOSS_{DoF}, which are themselves defined as explained.
it seems is not the third harmonic of the 50Hz mains.
I made a mistake. It was M8 mirror.