J. Oberling, P. King
PMC Alignment
After the last week's temperature spike the transmitted power through the PMC had dropped (see alogs 20490 and 20504), today's goal was to fix it. First Peter attempted to adjust the temperature of the PMC, as it had not settled back to its original temperature from before the temp spike. See Peter's alog here for full details, but the short version is that temperature is such a slow actuator and we are so limited on time that we decided to go in and adjust the beam alignment into the PMC.
With the ISS off we tweaked mirrors M06 and M07. Pitching M06 down slightly gained us the lost PMC transmission. Walking the beam slightly up and down in pitch and left and right in yaw did not improve the transmitted power, so after re-locking the adjustment screws we had:
We checked the centering on the PMC_TRANS PD and after a very slight adjustment to mirror M36 the transmitted power increased slightly to 25.29 W. We measured the visibility of the PMC:
With the ISS on:
We then measured the transmitted PMC power and the power after the ISC EOM with a power meter.
The power out of the ISC EOM is displayed on the IMC Overview MEDM screen, in the lower left corner. On the PSL table this is IO_AB_PD3. It read 25.81 W, so this needs recalibration. We blocked the PD and saw 0.175 W on the MEDM screen, so there is some offset we need to remove as well.
O1 Prep
We turned off all the computers inside the enclosure and removed the 1 cordless phone (it is currently sitting on the desk on the west side of the H1 PSL enclosure next to the PSL electronics rack). We shut off the DBB electronics in prep for O1; these will need to be turned back on if we want to run DBB scans during Tuesday maintenance. Once done in the LVEA we asked Richard to turn off power to the clean room phone located in the PSL enclosure. All HEPA fans for the enclosure are off, as well as both air conditioners. The make-up air is set to 20%, and this was confirmed by listening to the fan (it is located in the old chiller closet on the east side of the H1 PSL enclosure).
IO_AB_PD3 Recalibration
J. Oberling, P. King, C. Vorvick
We recalibrated IO_AB_PD3. To remove the measured 0.175 W of offset we set the offset value on the filter screen to -77.0 (440 counts/W with a gain of 1). We then set the gain to 0.916 to get the MEDM window to match our power measurement. If we want more power from the PSL our only course now is to increase the front end diode currents.
just when we thought we had fixed the monit autostart of the daqd process on h1dc0 it again failed to start up after a DAQ restart this morning (following model changes). Using the monit web page, I was able to stop and start the daqd process manually. I verified there were no duplicate processes running and the PID file was correct. There is a DAQ frame gap due to this problem from 09:13 to 09:51 PDT (between GPS times 1123949568 - 1123951808).
Charge measurements was done on both ETMs. It is early enough to discuss the new tendencies, nevertheless it seems like ETMY change the sign of charging after changing the bias sign on ETMY (see 20387) while ETMX charging is the same (as well as the bias sign). Now (since Aug,10) both ETMX and ETMY Biases are -9.5V, Plots are in attachment.
After the QUAD front end restarts, we found that some of the DARM DAMP MODE loops were blasting the suspension. In these cases, the FE was restoring non-zero gains as per the safe.snap settings file. Since Jenne confirmed that the GUARDIAN sets these gains and turns these loops on, I have written all of the gains to be ZERO in the safe.snaps for future restarts.
as part of the SR3 investigation, we restarted the h1iopsush56 model to re-calibrate the 18bit DACs. The procedure was: stop user models, stop IOP model, start IOP model, check the status of the 18bit DAC autocal, clear the SWWD DACKILLs to stop the SEI SWWD countdown, start the user models one at a time.
Looking at the AUTOCAL history, this restart and the previous 3 restarts since the last reboot have all successfully calibrated all 5 DAC cards in the correct amount of time.
following the h1susetm[x,y] model changes this morning to remove the cpu intensive violin mode calculations from the models, the models are now running faster. Looking at second trends over the past few hours, the CPU max ranges before and after the change are shown below
sus | before | after |
ETMX | 57-64uS | 53-58uS |
ETMY | 57-62uS | 54-57uS |
the improvement is in the range of 3uS to 4uS. The TIM bit of the STATE_WORD triggers above 62uS, so we would not expect any more TIM errors on the CDS overview screen.
ER8 day 1
no restarts reported.
Filiberto, Richard, Elli
A filter was added to the HWS power supply. The idea is that the filter module will cut out the current spikes from the HWS that were showing up in the PEM channels. We will test this today.
The filter is in a box labeled "HWS filter for power supply" and is located inside the HWS table by HAM 4, on top on the HWS corner breakout box. The filter connects between the HWS Corner Breakout Box (refer to D1200934 and E1100892).
I can't find any evidence of 1Hz lines or glitches when the ITM HWS cameras are on. The filter module appears to be doing its job.
There is no 1Hz glitxhes in the ITMX GS13 when the HWS is on. These glitches were bothering detchar during ER7 (alog 18548). The attached spectrogram can be compared with that in alog 18548. Left spectrogram is HWS off, right plot is with HWS on.
There is also no increase in the 1Hz line in the corner station magnetometer spectrum when the HWS cameras are switched on. (Spectrum attached. "Live" spectra were taken with camera off, reference spectra were taken with camera off.)
This morning after we restarted the ITM and ETM SUS models, the guardians failed when attempting to bring these SUSes back up. It failed on all 4 QUAD SUS guardians at the same place when requesting to go from SAFE to ALIGNED:
2015-08-18T15:47:25.63598 SUS_ETMX [ENABLE_ALL.main] ezca: H1:SUS-ETMX_L2_TEST_L => ON: OUTPUT
2015-08-18T15:47:25.88943 SUS_ETMX [ENABLE_ALL.main] ezca: H1:SUS-ETMX_L2_TEST_P => ON: OUTPUT
2015-08-18T15:47:26.14962 SUS_ETMX [ENABLE_ALL.main] ezca: H1:SUS-ETMX_L2_TEST_Y => ON: OUTPUT
2015-08-18T15:47:26.40621 SUS_ETMX [ENABLE_ALL.main] ezca: H1:SUS-ETMX_L3_TEST_L => ON: OUTPUT
2015-08-18T15:47:26.65966 SUS_ETMX [ENABLE_ALL.main] ezca: H1:SUS-ETMX_L3_TEST_P => ON: OUTPUT
2015-08-18T15:47:26.91415 SUS_ETMX [ENABLE_ALL.main] ezca: H1:SUS-ETMX_L3_TEST_Y => ON: OUTPUT
2015-08-18T15:47:27.16605 SUS_ETMX [ENABLE_ALL.main] ezca: H1:SUS-ETMX_L3_TEST_BIAS => ON: OUTPUT
2015-08-18T15:47:27.16619 SUS_ETMX [ENABLE_ALL.main] Turning on OL damping outputs
2015-08-18T15:47:27.18074 SUS_ETMX W: Traceback (most recent call last):
2015-08-18T15:47:27.18076 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/worker.py", line 459, in run
2015-08-18T15:47:27.18077 retval = statefunc()
2015-08-18T15:47:27.18077 File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/state.py", line 240, in __call__
2015-08-18T15:47:27.18078 main_return = self.func.__call__(state_obj, *args, **kwargs)
2015-08-18T15:47:27.18078 File "/opt/rtcds/userapps/release/sus/h1/guardian/SUS.py", line 456, in main
2015-08-18T15:47:27.18079 sus.olDampOutputSwitchWrite('ON')
2015-08-18T15:47:27.18079 NameError: global name 'sus' is not defined
2015-08-18T15:47:27.18080
2015-08-18T15:47:27.18762 SUS_ETMX ERROR in state ENABLE_ALL: see log for more info (LOAD to reset)
Reloading the GRD didn't work. In order to get around this we Put the GRD to MANUAL and enabled the output switches by hand, then selected ALIGNING, anmd ALIGNED.
This is now fixed.
An object called "susobj" is defined early in the guardian, which contains the name of the optic. In the new state ENABLE_ALL, the optical lever turn-on was mistakenly calling this object "sus" rather than "susobj". 3 extra characters, one click of the Load button, and ITMX went nicely from DAMPED to ALIGNED.
I have loaded the guardian code on ITMY as well, but *not* on the ETMs, since charge measurements are in progress.
UPDATE: ETMX and ETMY guardians were loaded, after charge measurements were complete.
After the model restarts from this morning, we attempted to perform a DAQ restart which failed and is unresponsive to a login. Waiting for CDS...
HAM5, ITMX, and BS had 1214, 44, 253 accumulated saturations respectively. They have been cleared.
[Dave B, Nutsinee, Duncan M]
I have added an IPC receiver to the h1odcmaster model to connect the TCS-ODC from h1tcscs to ODC-MASTER. This model has been rebuild and restarted, but this work should not be considered complete until after a restart of the DAQ.
This change, along with associated updates to the SDF/safe.snap were recorded as r11318.
LVEA: Laser Hazard IFO: UnLocked Observation Bit: Commissioning All Times in UTC 07:00 Take over from Corey G. 07:00 IFO unlocked – Commissioners looking into problem going to high power 07:14 Locked at DC_READOUT 08:36 Go to INCREASE_POWER 08:39 Lockloss – Commissioners working on going to high power problem 09:19 Trying to relock at DC_READOUT – No lock at LOCK_DRMI_1F 11:50 Running initial alignment due to DRMI and bad looking spot on AS AIR 12:00 LLO starting maintenance at or around 12:00UTC 12:12 Peter – Starting PMC adjustments 14:17 Christina & Karen – Moving stuff into the High-Bay & OSB Receiving 14:50 Christina & Karen – Finished moving stuff around the OSB 14:52 Christina & Karen – Going to End-Y for cleaning 15:00 Turn over to Travis
A quick entry to capture things as they are. A more detailed entry will follow. The Quest was to try and bring back the alignment of the pre-modecleaner by adjusting the temperature of the body. In short, it didn't work. The longer story is that the jury is still out (I'd say). The body temperature of the pre-modecleaner was ~304.5K when the alignment was notionally good. The elevated temperature of the pre-modecleaner was ~305K. Increasing the voltage on the PZT, by increasing the HVREF signal, results in the temperature of the pre-modecleaner decreasing. As expected. Not surprisingly this takes quite some time. The fastest way to bring the temperature down was to turn off the temperature loop. Set the HVREF to a low value, req-acquire lock for the PMC and the increase the HVREF to its maximum value and then turn the heater loop on with the HEATER OFFSET set to zero. Attached is a plot of the pitch of a pre-modecleaner transmitted beam as monitored by the quadrant photodiode in the ISS photodiode box. Clearly both pitch and yaw are affected by the temperature change. Previously it wasn't so obvious that yaw was affected but that might be due to the time scale of the temperature changes. Also attached are plots of the transmitted and reflected output of the pre-modecleaner, and the output power of the laser during the same time. There is a slight increase in the transmitted power but nothing to write home about. In short it's undoubtedly faster to go in and re-align.
As per LIGO-M1500250, H1 has now been put into "OBSERVATION MODE". This means:
The ODC-OPERATOR_OBSERVATION_READY bit, which is set to "Undisturbed" by the operator on the GUARD_OVERVIEW screen, will now be automatically unset by the Guardian IFO top node if any of the monitored guardian nodes drop from OK==True.
The most likely ways that this can happen are:
Operators must be aware that the INTENT bit must be manually reset after any of these changes.
The list of Guardian nodes being monitored is stored in:
USERAPPS/sys/h1/guardian/IFO_NODE_LIST.py
The current monitored node list is:
ALIGN_IFO ALS_COMM ALS_DIFF ALS_XARM ALS_YARM HPI_BS HPI_ETMX HPI_ETMY HPI_HAM1 HPI_HAM2 HPI_HAM3 HPI_HAM4 HPI_HAM5 HPI_HAM6 HPI_ITMX HPI_ITMY IMC_LOCK ISC_DRMI ISC_LOCK ISI_BS_ST1 ISI_BS_ST2 ISI_ETMX_ST1 ISI_ETMX_ST2 ISI_ETMY_ST1 ISI_ETMY_ST2 ISI_HAM2 ISI_HAM3 ISI_HAM4 ISI_HAM5 ISI_HAM6 ISI_ITMX_ST1 ISI_ITMX_ST2 ISI_ITMY_ST1 ISI_ITMY_ST2 OMC_LOCK SEI_BS SEI_ETMX SEI_ETMY SEI_HAM2 SEI_HAM3 SEI_HAM4 SEI_HAM5 SEI_HAM6 SEI_ITMX SEI_ITMY SR3_CAGE_SERVO SUS_BS SUS_ETMX SUS_ETMY SUS_IM1 SUS_IM2 SUS_IM3 SUS_IM4 SUS_ITMX SUS_ITMY SUS_MC1 SUS_MC2 SUS_MC3 SUS_OM1 SUS_OM2 SUS_OM3 SUS_OMC SUS_PR2 SUS_PR3 SUS_PRM SUS_RM1 SUS_RM2 SUS_SR2 SUS_SR3 SUS_SRM SUS_TMSX SUS_TMSY TCS_ITMX
Note to Operators: ODC-OPERATOR_OBSERVATION_READY bit, which is controlled by the button labeled "undisturbed" on the GUARD_OVERVIEW.adl screen, is distinct and different from the H1:ODC-OBSERVATORY_MODE channel, which is set from the OPS_OBSERVATORY_MODE.adl screen. The ODC-OBSERVATORY_MODE describes the activity (wind, preventative maintenance, commissioning, etc.) and is used to generate our time spent pies. These are summarized in the DetChar summary pages at:
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150817/lock/operating_mode/
The Operators' priority is to the GUARD_OVERVIEW undisturbed button, which signals the readiness for scientifically valid observing. The selection of the LHO operating mode to "OBSERVING" (in the OPS-OBSERVATORY_MODE.adl screen) can be done after the pressing of the "undisturbed" button. After a lock loss, the operator should select the appropriate LHO operating mode activity.
Sheila, Kiwamu
We newly put an elliptic low pass in ETMY_L3 in order to reduce the number of saturation events.
Today, we noticed that ETMY frequently saturated at the bottom stage. Looking at the spectra and time series, we found that high frequency components above 1 kHz was a culprit. This is related to the activity that Evan et al worked on last night (alog 20585) trying to get a better phase margin. We decided to install a roll off in order to mitigate the issue. We put an elliptic whose cut off is at 950 Hz with a 20 dB rejection in the stop band and 3 dB ripple in the pass band. Since the filter banks in ETMY_L3_LOCK was full, we put it in DRIVEALIGN instead. It is now in FM7 and the ISC_LOCK turns it on in the ETMY_TRANSITION state. This costed a 2.6 deg phase loss at 40 Hz which should be OK according to Evan's open loop measurement.
As a result, it reduced the DAC counts in RMS by a factor of between 2 and 3. This seemed to help reducing the saturation events so far. See the attached. We could have lower the cut off frequency more, but since it is going to be limited by frequency components below a couple of Hz anyway, we leave it as it is.
We did some more DARM filter cleanup:
Craig, Jenne, Kiwamu,
We did a VCO calibration for the ALS diff vco in the last Friday when the interferometer was suffering from high wind. The new result suggests that the VCO calibration stays the same as the one for ER7 by 0.6%.
The new coefficient is 0.11847 +/- 9.3e-05 [cnts @ DIFF_PLL_CTRL_INMON / Hz @ DIFF VCO frequency read by the timing comparator ].
The attached below shows the fitting result:
The measurement method is the same as the previous one which is described in this alog (alog 18711). One difference is that we used the INMON as opposed to OUTPUT because we did not want to rely on the filter shape of the chain which contains the zpk([[40], [1.6]) which is supposed to cancel the low noise VCO circuit. The sweep was as slow as 255 [Hz/ sec]. The fitting uses a frequency region where the linearity was found to be good (as indicated in the plot as yellow shaded region).
The analysis code, data and figure are saved in SVN as follows:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/ALSDiff/vco_calibration_fitting.py
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/ALSDiff/2015-08-14_vco_sweep_v2.txt
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Results/ALSDiff/2015-08-14_VCO_calibration_v2.pdf
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Results/ALSDiff/2015-08-14_VCO_calibration_v2.png
I made another measurement which is an improved version of the last measurement.
The improvements are:
The fitted coefficient this time is lower that the last measurement by 0.4 %, presumably because of the improvements which should get rid of systematic biases.
Coefficient = 0.11802 +/- 4.92e-05 (0.042 %) in [cnts / Hz]
Here is a plot showing the data along with the fitting line:
Looking at the residuals, there seem to be two components -- majorities are on the wavy trend while there are scattered points which tend to have high values. I believe that the ones having high values are due to the impulse response of the VCO and comparator which deviated every time when I made a discrete steps. As shown, they tend to pull up the interception while they don't seem to affect the slop so much. Since the quantity we care is the slope of the fitting line, I think the data is good enough.
As usual, the data, script and figures are checked in to the SVN. They can be found at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/ALSDiff/2015-08-18_vco_steps.dat
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/ALSDiff/2015-08-18_vco_calibration_fitting.py
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Results/ALSDiff/2015-08-18_VCO_calibration.pdf
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Results/ALSDiff/2015-08-18_VCO_calibration.png