TCS switch-of timetable

TCS switch-off timetable

26th July 2017: the timetable is referred to the local time

10.11: Opening TCS ROOM main door
10.19: Opening lower part of WI acoustic enclosure
11.06: Switch-off sinusoidal signal at 1kHz => switch-off lasers
11.07: Power down of the Agilent generator related at 1kHz signal
11.07: Switch-off of the 2 TTL signals at 40MHz => switch-off RF electronics
11.08: Power down of the 2 Agilent generators related at 40MHz signals
11.08: Switch-off temperature controller and power down PLC of the controller => switch-off RF drivers and related power suppliers
11.12: Switch-off WI chiller
11.14: Switch-off NI chiller
11.17: Power down of both chillers
11.19: Switch-off pump of the service cooling system
11.20: Switch-off piezo controller
11.21: Switch-off pico-motors controller
11.24: Switch-off fun coil in TCS CHILLER ROOM
11.25: Switch-off bilge pump in TCS CHILLER ROOM (the pump was in stand-by mode)
11.50: Starting of new operations by Maddalena

Comment to Operator Report - Evening Shift 25 July (Click here to view original report: 38836)

Unless I misremember previously the DMS detected when a signal went flat and set the DMS flag to grey?

New server to follow drum mode frequency

Now that we have a reasonable sensitivity, it becomes interesting to study the performance of the interferometer as a function of the etalon effect. As a thermometer, we were using the frequency of mirror modes. To track the frequency of the drum mode over time, I implemented a new server called PySpectral, which is similar to an old one that was implemented using Matlab.

Algorithm to calculate the frequency:
-take data of B1_PD2_Audio at 20 kHz, multiply with a complex sine at 7810 Hz and decimate to 20 Hz.
-collect 100 seconds of down-sampled data and take an FFT, zeropadded by a factor 4.
-calculate the averaged PSD using 5 half-overlapping windows.
-find the maximum for every peak in a predefined region, and estimate the exact peak location using using quadratic interpolation. This works well for the large peaks, but not necessarily for the smaller ones.
These parameters might have to be tuned a bit. With some more averaging, we can hopefully measure the peak positions with milli-Hertz resolution. Given a calibration of 0.77 Hz per Kelvin for the drum-mode and 0.3 Kelvin per fringe, this should yield a resolution of slightly better than 1/100 of an etalon fringe.
-the height of the peak is calculated as the BRMS in the region of interest

Fig 1 compares the spectrum calculated by the server (which is available as a debug channel that is not stored to disk) and the real spectrum of B1_PD1. These should be equal within the pass-band of the decimation filter. The peaks at 7808 and especially the one at 7810 Hz do get excited a bit during a lock acquisition, so they are likely mirror modes. The one at 7812 Hz has been identified as belonging to the WE. The two remaining peaks at 7811 and 7813 Hz seem to have a bit lower Q. These might indicated the unexpected splitting of the modes of a single mirror, which we have seen before. It would be good to switch on the ring heaters of the NE/NI/WI mirrors for a short period as soon as possible, so that we know who is who during the science run.

Fig 2 shows the frequency and amplitude of the peaks during a few locks of last night. Note that the frequency of the lines is stored as an offset to the demodulation frequency of 7810 Hz, to not lose any information by rounding to single-precision floats.

Fig 3 shows the ringdown of the strong line at 7810 Hz. Using Q = pi * tau * f, a Q of 1.7e7 is obtained.

Configuration PCAL

The conversion factors for the calibration of PD1 and PD2 on the PCAL have been changed at 8h29 UTC and the control loop has been enabled.

Comment to 29.2 Hz and 92Hz Noise Elimination (Click here to view original report: 38814)

It has been confirmed the 29.2Hz line is gone from Hrec (figure 1). The 92 Hz bump was previously confirmed to have disappeared (38738) we just turned on the fan yesterday and observed the change in enviromental sensors to verify the source then it was switched back off. So, there is not a recent lock with the fan on for comparison, but none the less the 92Hz region is flat. Yesterday the operator recieved a flag for the ENV_WE_CT_ACC_Z being out of it's thrshold. The top right of figure 2 shows the significant reduction in the overall noise when the scroll pump was switched off, which resulted in the flag.

Most glitches between at 10-20Hz seems coming from MICH loop

I have look at the low frequency glitches that are coming and going on the several hours times scale in h(t) figure 3.

Yesterday I had noticed that beside SDB2 scattered light many glitches are seen in coincidence with B4 DC and the MICH error signal. To confirm that I have retrieve omicron triggers for Hrec_hoft and LSC_MICH between 4:00 UTC and 5:00 UTC this morning (July 26), that have an SNR>10 and a peak frequency below 50Hz. And looked for coincidence between them within a 100ms window.

Figure 1, shows the hoft SNR as a function of frequency. Blue pluses are all the hoft glitches selected, and circled in red are the ones which are coincident with MICH glitches. The glitches peaking between 14Hz and 17Hz are clearly coincident.

Figure 2, shows the hoft SNR vs the MICH SNR for the coincident glitches. And clearly the glitch has a larger SNR in MICH than in hoft (the blue line is a guide for the eye for equal SNR).

This is not surprising as below 25Hz the hoft noise is dominated by the MICH noise coupling to DARM. These MICH glitches might be gain peaking in the MICH loop that comes with fluctuations in optical gain or it could be something else.

A more systematic study would be needed to fully characterize this, but it would nice to create a veto or flag based on the MICH glitches below 50Hz. So that we can class this kind of glitches in a category even though data below 20Hz probably won't be used for any searches.

Packages installation in /virgoApp

To proceed with the O2 Code Freeze the following pakage versions have been installed in /virgoApp:

• use BRMSMoni v1r6
• use SpectroMoni v1r6
• use NonStatMoni v3r5
• use QPDmoni v0r00
• use Fbs v8r11p11
• use TolmBase v11r0
• use TolmDictionary v1r3
• use Rtai v6r8
• use Cfg v8r04
• use Frv v4r27p2
• use Fm v4r05
• use PicoControl v0r16p3
• use Glib v2r48p20
• use PackageBuild v0r9
• use Pr v10r26p60
• use TolmProcessor v6r0
• use TolmBase v6r0
• use TolmDictionary v1r1
• use Rtai v6r7
• use Acl v0r42p11
• use TolmProcessor v11r0
• use TolmFrameBuilder v4r6p11
• use DaqBox v11r2
• use DaqBox v11r2p1
• use Imaging v11r0p1
• use Aravis v0r4p11
• use GStreamer v1r10p20
• use Cairo v1r14p80
• use GxNew v2r13
• use Hameg v1r8
• use DemodMoni v0r01
• use Telescreen v3r31
• use LibSoup v2r48p10
• use Glib v2r42p20
• use GStreamer v1r4p54
• use Cairo v1r14p20
• use Moni v2r8p13
• use Hrec v2r27
• use Fd v8r12
• use Fd v8r16
• use Fd v8r17p3
• use Fd v8r17p4
• use Fd v8r17p7
• use Fd v8r17p8
• use Fd v8r18
   

Comment to Operator Report - Evening Shift 25 July (Click here to view original report: 38836)

The grey flags were denoting missing channels from the LaserAmp processes.

Following the procedure in WikiOperators, I found that the relevant servers (ServerMbAdsMB on Olwin and LaserAmp/EER on Astor) were both off.  So at around 00:40 LT I started these servers and then performed a reload of FbsAlp collect process.  After these actions the channels were again available and the DMS flags back to green (see attached plot).

As can be noted from the plot, it is worth to mention that before the period of data missing (stared around 18:30LT), the data were flat starting from around 10:00 LT.  This is even worse, because it is misleading for the DMS: indeed they remained flat at a value within the DMS tresholds, that therefore remained green till the above said  event of data missing.

Operator Report - Evening Shift 25 July

The shift has been dedicated mainly to the loop characterization update ( entry #38833 ).

Minitowers - SDB1

16:25 - 16:59 LT- B5 beam drift control disabled via VPM in order to allow a work on the beam dump.

INJ

since this afternoon at about 16:30 UTC we have gray flags on DMS for "LaserAmpli", "LaserChiller" and "InjectionAli" (expert informed).

 

23:00 LT - ITF locked in LOW_NOISE_3 with Hrec ~ 18Mpc

Loop characterization update

In preparation for ER12 I checked the OLTF for DARM, MICH and PRCL in the LOW_NOISE_2 state; while I did not expect big changes for DARM and PRCL, the change of error signal for MICH triggered the need for this update:

• the DARM loop has the usual UGF around 70 Hz, nothing has changed (Figure 1);
• MICH's UGF seemed a bit high, around 16.3 Hz (Figure 2); I changed the sensing matrix element for the last signal (in order to keep the usual gain valid for any signal) and reduced it to bring the UGF to ~ 12 Hz (Figure 3); the nominal UGF should be 10 Hz, but given the usual loss of phase margin on the lower end of this loop, for the time being I left it at 12 Hz;
• PRCL's UGF is very slightly higher than usual, but it shouldn't be a problem (Figure 4);

I took the chance, while still in LOW_NOISE_2, to de-normalize the error signal for PRCL from B2_8MHz/(B1p+B4) to plain B2_8MHz, then measure the OLTF again to fine tune the sensing weight in order to have the same UGF, should we decide to switch to this signal; I tuned this sensing weight to have the UGF at 40 Hz, and both this and the new sensing element for MICH are already saved in ITF_LOCK.ini.

 

At the end, I went to LOW_NOISE_3 in order to make a set of measurements there; after a couple of unlocks immediately after reaching such state, I reduced the gains of the DIFFp alignment loop from 1.0 to 0.4, and then i could perform the measurements; with the same (DARM aside) gain/sensing elements as the fine-tuned LOW_NOISE_2 configuration, the results were:

• I decided to use DARM_SET = 0.003 (B1_DC = 9.375 mW) to avoid the risk of other unlocks or adjustments; the gain was already roughly adjusted for this purpose during the last tests we did with this configuration, as DARM_GAIN = 4.25;
• DARM has its UGF at 73 Hz with this configuration, which seems perfectly fine;
• MICH has its UGF at 12.44 Hz, which is a very little deviation from LOW_NOISE_2;
• PRCL has its UGF unaltered at 40 Hz.

Some GPSs (all injections lasted 180 s each):

• LOW_NOISE_2:
  • CLEAN = 1185040483;
  • DARM = 1185040680 (UGF = 69.6 Hz);
  • MICH = 1185043339 (UGF = 12 Hz);
  • PRCL = 1185041081 (normalized, UGF = 43 Hz);
  • PRCL = 1185044962 (de-normalized, UGF = 40 Hz);
• LOW_NOISE_3:
  • CLEAN = 1185047602;
  • DARM = 1185047799 (UGF = 73 Hz);
  • MICH = 1185048000 (UGF = 12.44 Hz);
  • PRCL = 1185048200 (UGF = 40 Hz).

In principle all these measurements could be used for tuning the Alpha and Beta subtractions, but I'm not sure about the outcome since the ITF is not in its standard condition. Anyway I will look into those offline.

Now the LOW_NOISE_3 state takes into account the gain change for the DIFFp alignment loop and nothing has to be done manually.

 

While doing all this, I noticed that the excess noise we found yesterday has been quite rapidly fading away over the last couple of hours, with only a bump in the 10-20 Hz region but still the peaks (although smaller) at 84 and 160 Hz still showing up. For all these measurements I kept the DARM UGF line 5x higher in amplitude, as the 84 Hz peak was pretty much covering it; this is saved in ITF_LOCK.ini, but probably tomorrow morning we can restore the usual line amplitude.

Comment to Some low frequency glitches last night were SDB2 scattered light arches (Click here to view original report: 38815)

Triggered by Excavator data (https://scientists.virgo-gw.eu/DataAnalysis/Excavator/logbook/2017-07-25_useism/) we searched for a correlation between Hrec_hoft channel vs NI_MIR_Z_50Hz channel (plot 1) and Hrec_hoft vs SDB2_LC_Z_err_ground_corrected_50Hz channel (plot 2) using a matlab-code produced by Bas: the two results are complementary. As noted by Paolo, the NI local control sensor does not see a movement of the mirror, but a movement of the ground: the scattered light path is not yet understood.

In order to match better the spectrogram, we multiplied NI_MIR channel for a factor 2 and SDB2 for a factor 1.5

Reducing SDB2 B5 QD2 galvo loop bandwidth

Reduced the gain of the SDB2 B5 QD2 galvo loop from 0.5 to 0.001.
The 0.5 gain should correspond to a UGF of a few Hz.
Given that below 10Hz the filter is just a simple integrator, reducing the gain by a factor 500, should reduce the bandwidth by 500 down to ~10mHz, so that the galvo loop can be closed but also the DC signal be used for ITF control. While reloading the SDB2 quadrant configuration I broke the lock, as I forgot that many parameters are set by Metatron via cm commands for quadrant processes.

Figure 1, the loop closes properly (here in recombined at half fringe) and the integration time constant is indeed of the order of 100 seconds (corresponding to 10mHz).

MultiSAS SDB2 actuator offloading and step motor drivers config file reloading

This morning we have re-balanced the SDB2 inverted pendulum and Filter-0 by using the step motors. All the step motor power supplies have been restarted and the configuration file reloaded in all boards.
The DMS thresholds on the SBE_Sxxx_act0,1,2 have been changed to +/- 4Volts.

Realignment of the beam on the BPC quadrants

This morning we realigned the beam in order to reduce the corrections of the BPC and have a larger margin. We did it remotely from the IERoom, by moving the mirrors with the picomotors .

As shown in the plot, the corrections are now reduced.

Operator report - morning shift 25 July

ITF unlocked in the night 6:25 LT because of FbmFE crash.
After that the ITF had some difficulties to stay locked.
At 8:00 Lt started the planned maintenance:
- vacuum activities;
- grass cutting;
- test on IMC rampeauto ;
- fan coil installation in TCS room;
- suspensions work;
- 29.2 Hz and 92Hz Noise Elimination

At ~12:30 LT all the maintenance activities were concluded and we started to recover the ITF standard working condition; the ITF was relocked at 13:08 LT with Horizon at ~10Mpc.
Commissioning team are working to improve the sensitivity.

TCS
Check of water level of the TCS chillers.

ENV
Particle counters of CEB, NEB, WEB switched on and process restarted.

SBE
Together with Bertolini we centered SDB2 and we adjusted some thresholds for SBE in DMS.

DAQ
- FbmMain restarted at 15:05 LT after a crash occurred at 15:03 LT; the crash caused missing channels.
- PicoAppEIB restarted after a crash at 15:20 LT.

Comment to Regular spikes in LSC_Acl elapsed time (Click here to view original report: 38077)

Plot1 shows an example of glitches due to the spikes in LSC_ACl_elapsed_time.
The glitch is well visible in the spectrogram of LSC_DARM but not in the spectrogram of Hrec_hoft_20000Hz.
We can see many other glitches in the spectrogram of Hrec_hoft_20000Hz, which are typical low SNR glitches (SNR<8) visible by Omicron with a glitch rate
of about 1 per second. Elapsed_time glitches are a priori less annoying in h(t) than those low SNR glitches.
So, even if such glitches should be investigated and removed, they are not a problem for data analysis.

Flag to tag manual unlocks

The flag V1:DQ_META_MANUAL_UNLOCK has been added to the DAQ. It should be active for 1 second when an unlock of the interfermoter is triggered by hand, by pressing the down button on the ITF_LOCK node GUI.

Comment to FbsVac - SenO2 data collection removed du to duplicated channels: NE_O2_COMMAND_ELEC_ST ,WE_O2_COMMAND_ELEC_ST (Click here to view original report: 38818)

Problem solved, SenO2 put back in operation

Particle counters turned on

The dust particle counters of the CB, NE and WE have been turned on. The relative DMS processes have been restarted.

Comment to All SA motors are now connected to the smart PDUs (Click here to view original report: 38674)

NE and NI IP centering tool has been successfully tested. A few problems on the coil data sent to the DAQ have been fixed.

Comment to Data from Sa_WE partially missing since July 6th (Click here to view original report: 38812)

There is a two Tolm paths available to send the data to the rtpc4:

• Sa_WE_lk0 -- MxDxSN02_lk6 -- MxDxSN16_lk5--rtpc4_lk0 : ROUTING = 0xf94c0000 : The one currently used
• Sa_WE_lk0 -- MxDxSN02_lk7 -- MxDxSN07_lk5--rtpc4_lk1 : ROUTING = 0xf94e0000 : spare

FbsVac - SenO2 data collection removed du to duplicated channels: NE_O2_COMMAND_ELEC_ST ,WE_O2_COMMAND_ELEC_ST

Comment to Spare IMC rampeauto test failure. (Click here to view original report: 38807)

This morning, we try again to test the IMC rampeauto spare

after inspection by the electronic group.The +/- 24V

cable was identified as potentially faulty.

After a fast try, we were unable to lock even in 1/f.

Some low frequency glitches last night were SDB2 scattered light arches

I have looked at last nights data that had lots of low frequency glitches (figure 1) that Nicolas mentioned today to be due to high microseismic.

Figure 2, if I look at random time some of the glitches are due to large motion of SDB2 wrt to SDB1 (black line projection). But there are also some other glitches in the same minute due to something else (I checked it is not ACL elapsed time glitches). These glitches are coincident with the same glitches on B4_DC (figure 4), so maybe these glitches come from MICH, but they don't seem to be scattered light on SPRB.

Figure 3, if I look at time with a large SDB2 position fluctuation there is clearly a large glitch at the same time.

Looking in the trend data, the SDB2 vs SDB1 translation control loop was not enabled last night. It would have been a good time to test that loop...
I have turned it on this morning during the maintenance, and added checks in DMS for SNEB, SWEB and SDB2 that the loop is closed so that it doesn't get forgotten in the future.

Figure 5, looking in time domain at the glitches that are not due to SDB2 scattered light. They seem clearly to have their origin on B4. It could be either scattered light (but doesn't correlate well with SPRB motion) or MICH loop gain peaking (but the frequency is not always the same) as the oscillation also shows up in the MICH error signal not only in the B4_DC/Audio light.

Comment to Big transient glitch in BNS range (Click here to view original report: 38797)

Here is the omicron scan: https://wwwcascina.virgo.infn.it/DataAnalysis/Omicron/narnaud/scans/1184818117_std. There is nothing striking in it.