Pursuant to a discussion on the PSL call this morning, I'm posting trends of the humidity and temperature in the Laser Room, Laser Diode Room, and Chiller Room over the past 365 days.
The humidity sensors are coupled with the temperature sensors. We have more temperature sensors, but we decided not to record their coupled humidity sensor signals.
Just for comparison's sake, a plot of the humidity sensor in the high power oscillator box is included.
See LLO alog, for comparable plots
Attached is a plot of the NPRO output power and the output power of the two pump diodes for the past 4 years. One can see that the diode current was increased around 8/16/2013 and 6/5/2014. The first increase in pump current was about 200 mA; the second about 50 mA. This NPRO is very close to its "maximum" diode current.
See LLO alog for comparison
O1 days 46,47
model restarts logged for Mon 02/Nov/2015 No restarts reported
	model restarts logged for Tue 03/Nov/2015
	2015_11_03 09:30 h1hpiitmy
	2015_11_03 09:30 h1iopseib1
	2015_11_03 09:30 h1isiitmy
	2015_11_03 10:16 h1isibs
	2015_11_03 10:18 h1isiitmx
	2015_11_03 10:26 h1isietmx
	2015_11_03 10:31 h1isietmy
Maintenance day. Power cycle of h1seib1, new BSC ISI models with reduced sensitivity to coil driver temp status bit when triggering watchdog.
Title:  11/04/2015, Day Shift 16:00 – 00:00 (08:00 – 16:00) All times in UTC (PT)
	
State of H1: 16:00 (08:00), The IFO is locked at NOMINAL_LOW_NOISE, in Observing mode 
Outgoing Operator: Jim
Quick Summary:  IFO locked in Observing for the past 9 hours. Winds are calm to light (0 – 3mph), seismic activity is quiet; microseism is centered around 0.3 um/s.   
     
A
			
			
		
		Apologizes for the late entry. Yesterday all site supply fans were lubricated per the quarterly schedule. We also took the maintenance period opportunity to change some extremely dirty air filters which are located in the supply fan areas.
TITLE: 11/03 Owl: 8:00-16:00 UTC STATE Of H1: Observing @ ~75 MPc. SHIFT SUMMARY: SUPPORT: ACTIVITY LOG: H1 was locked when I arrived, RF45 was acting up occasionally, though. Otherwise quiet shift. 15:00 UTC Started receiving CS temp notifications, Bubba notified/working on it.
This morning about 15:00 UTC, I got a couple notifications that temps were low in the LVEA. I let Bubba know, but he was already working on it. I haven't heard any notifications since, Bubba said he will keep an eye on it.
TITLE: 11/03 [EVE Shift]: 00:00-08:00 UTC (16:00-00:00 PDT), all times posted in UTC STATE Of H1: Observing @ ~75 MPc. SHIFT SUMMARY: Initial lock impeded by bounce and roll modes. Lost lock during earthquake in East Timor. Seismic stayed abnormally high for almost 2 hours. Recovered and back to observing. SUPPORT: Evan, Jenne INCOMING OPERATOR: Jim ACTIVITY LOG: 00:13 UTC Kyle and Gerardo back from X28 (near end X) 01:25 UTC Towing truck through gate 04:36 UTC Nutsinee leaving, driving up bridge before heading out 04:40 UTC Jenne driving to end stations to turn card readers on 04:49 UTC Turned power off to speaker in control room 05:06 UTC Jenne back 05:45 UTC Restarted video2, Ops overview frozen
Seismic took about 2 hours to ring down to the point that we could relock. The 0.03 - 0.1 Hz seismic band is between ~ .02 and .1 um/s. The microseism is between ~ .1 and .2 um/s. The winds are around 10 mph. Violin mode damping for ITMX and ITMY is off. ISI blends are at Quite_90. Jenne turned the card readers on at end X, end Y and the LVEA. Range is around 78 MPc.
[Jenne, Miquel, Patrick]
The card readers providing access to the VEAs were turned off during maintenence today. Since we're unlocked due to an earthquake anyway, they have now been turned back on (EX, EY and vertex).
SUS I_T_M_Y saturating (Nov 4 04:14:41 UTC) DRMI Unlocked (Nov 4 04:14:41 UTC) Intention Bit: Commissioning (Nov 4 04:14:41 UTC) ISC_LOCK state: DOWN (Nov 4 04:14:48 UTC) From USGS: 6.3 77km WNW of Dili, East Timor 2015-11-04 03:44:15 UTC 14.3 km deep Spike to ~ .3 um/s in 0.03 - 0.1 Hz seismic band
Have remained in observing. No changes to report.
I have turned off the violin mode damping filters for IX and IY by zeroing their gains. Patrick accepted these into SDF so that we can go to observing.
This is meant to be temporary, i.e., for this one lock only.
The next time the interferometer comes into lock, the Guardian will turn on the normal violin mode damping settings. These settings will appear as SDF diffs (two on IX, and six on IY). These should be accepted into SDF.
We do not expect these modes to ring up during the course of the lock. However, if the mode height on the control room DARM spectrum around 500 Hz rises above 10−16 m/rtHz, the damping should be turned back on:
A screenshot of the nominal IY damping settings is attached (I didn't take one for IX).
ITMX:
ITMY
Thanks to Jeff, Patrick, and Jim for babysitting this.
The second lock (after the earthquake) lasted about 10 hours. Strangely, the ITM first harmonics (which range from 500 to 505 Hz) do not all seem to ring down.
An analysis of this data to measure Q of the fundamental modes for ITMX and ITMY violin modes is reported in 23331. The few modes that show an actual ringdown have a Q of about 0.3e9.
An analysis of this data to measure Q of the 2nd harmonics for ITMX and ITMY violin modes is reported in 23383.
There was some suspicion that the whitening gain for some of the ACB PDs became bad, but I have confirmed on the floor that the gain setting on the MEDM screen is reflected correctly in the diode amplifier box (D1301017) over the entire gain range for all baffle PDs for IX, IY, EX and EY.
I've followed the test procedure E1400003.
TITLE: 11/03 [EVE Shift]: 00:00-08:00 UTC (16:00-00:00 PDT), all times posted in UTC STATE Of H1: Lock acquisition OUTGOING OPERATOR: Jeff QUICK SUMMARY: Lights appear off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell from the camera if they are off at mid Y. Winds are less than 10 mph. Appear to be increasing. ISI blends are at Quite_90. Earthquake seismic band is between 0.01 and 0.02 um/s. Microseism is between 0.1 and 0.3 um/s. Jeff has been having trouble with ITMY bounce and roll modes. Has been stopping at REDUCE_CARM_OFFSET_MORE to allow Jenne and Evan to investigate.
The roll modes have been conquered. When they were too high, the DHARD loops become unstable and we lose lock. We stopped at REDUCE_CARM_OFFSET_MORE, which was the highest state that we could sit at without losing the lock.
ITMY's roll mode was the worst offender according to the monitor screen, so we only worked on damping that mode. We used the usual filter settings (which are always left in the correct state) and the usual negative sign for the gain. The usual gain that guardian leaves the ITMY roll mode damping is -40, but I was using larger gains to get the mode to go down faster. Once the roll modes were all around the "okay" level on the monitor screen, we let guardian continue the locking sequence.
We were concerned at one point that guardian had frozen on us, but it turns out that we were just being fooled. It looked like guardian was not finishing the DC_READOUT.main state, and not even starting the DC_READOUT.run state. However, it was all fine. I think I have been fooled by this before, but as a reminder (to myself especially), if an EPICS value is not going to change, guardian will not log that it tried to write the value. So, the last few steps of the main sequence were to write some gain values that were not going to change, which is why it looked like it was just stuck. Also, there was nothing in the run part of the state that was going to cause any log messages, so it didn't look like anything had happened, even though we were already getting the "return true" at the end of the state. In the end, we just requested a higher state, and guardian moved on as usual.
I have spent about an hour today checking some basic behavior of the ISS 2nd loop servo circuits. I did the following two measurements.
No crazy thing was found in today's test. Our plan is that whenever we have issues with the ISS 2nd loop in some future, we will repeat the same type of measurements with an aim to identify what is changing.
Offset measurement
I checked how the reference signal propagates to the servo signal output by changing the reference signal. The measurement was done with the IMC intentionally unlocked. Therefore there was no light incident on the ISS PD array in HAM2. The result is shown in the first attachment. An important quantity to note here is the signal output value when zero reference voltage was requested. It was 2.76 V. Also note that zero output signal can be obtained when the reference signal is requested to be between 5 and 10 mV. This does not sound crazy to me. According to the resultant plot, the linearity seems also fine. Additionally I checked the reference monitor as well which also showed a good linearity. Later, I did a coarse version of the same test with the full power incident on IMC (~22 W). Even though the actual RIN was too high to make a precise measurement, the linear coefficient between the reference and output signals seemed consistent with what I have measurement with no light. I also attach the raw data in txt format.
Operating point measurement
Then I locked the IMC and changed the input power step by step with a step size of about 2 [W]. In each step, I manually moved the reference signal such that the output signal stays around zero [V]. This tells us how the operating point evolves as a function of the input power. I did this test from 2 [W] to 22 [W]. The result is shown in the second attachment. As you can see in the plot, the operating point evolves linearly against the input power as expected. Additionally, I recorded IM4_TRANS_SUM as well in order to check the linearity of the output power of the IMC. IM4_TRANS seems to be also linear. The data in txt format is attached as well.
Note that all the tests were done with PD1-4 as an intensity sensor. PD5-8 was not checked during the tests.
There are two things that don't make sense.
1. DC gain mismatch between the drawing/traveller and the measurement.
When Second Loop boost, integrator and additional gain are all off and the variable gain slider is set to 0dB, the gain from REF signal monitor to Second Loop Output should be -220, taking into account the modification for the second loop electronics on the floor (D1300439, https://dcc.ligo.org/S1400214): -1 for the REF summation, -10dB (or 1/3.2) instead of 0dB for the variable gain amplifier, -100 for the last stage of "whitening" path (U34), and -7 for the daughter board.
D1300439 DC gain = -1/3.2*-100*-7=-220.
From Kiwamu's plots, the measured DC gain is about -12.5V/0.04V~ -310.
2. Mystery factor of two in REFSIG DAC output.
"REFSIG" slider has a mystery factor of 2 in the filter for the DAC output. As a result, when the slider is set to -0.577V, the output of the filter reads -1889 counts instead of -0.577V/40Vpp * 2^16ctspp = -945counts.
However, REF signal monitor, which I think is a read back of the offset voltage coming out of REFSIG DAC channel, reads -940 counts and 0.574V.
Per JimW's request (alog 23032), I edited the ISC_LOCK guardian such that it throws notification messages when the ISS 2nd loop fails in the engagement. I have reloaded ISC_LOCK and checked the code into the SVN.
The notification messages will be displayed (1) if the IMC_LOCK guardian falls back to the LOCKED state (which is the programmed failure sequence) and/or (2) if the engagement process takes more than 4 minutes. The below are the new version of the ENGAGE_ISS_2ND_LOOP state. The red lines are the ones I newly added.
* * * * * * in ENGAGE_ISS_2ND_LOOP * * * * * *
	    def main(self):
	        nodes['IMC_LOCK'] = 'ISS_ON'
	        self.wait_iss_minutes = 4.0 # in [min]
	        self.timer['ISSwait'] = self.wait_iss_minutes*60 # in [sec]
	
	    @get_watchdog_IMC_check_decorator(nodes)
	    @nodes.checker()
	    def run(self):
	        # notify when the ISS fails. 2015-Nov-3, KI
	        if nodes['IMC_LOCK'] == 'LOCKED' or nodes['IMC_LOCK'] == 'OPEN_ISS':
	            notify('!! 2nd loop engagement failed !!')    
	        # notify when the ISS is taking too many minutes. 2015-Nov-3, KI
	        if self.timer['ISSwait']:
	            notify('ISS spent more than %d minutes. Check ISS'%(self.wait_iss_minutes))
	        # if IMC arrives at the requested state, move on.
	        return nodes['IMC_LOCK'].arrived
Later today, we confirmed that the ISC_LOCK guardian behaved as intended -- it displayed the messages when the ISS failed in the engagement. Also there were a few minor typos which are now fixed. The guardian code is checked into the SVN.
The DTT template for showing the MICH spectrum on the control room wall is suffering from leakage, preventing us from seeing some features in the 8 to 11 Hz range. The current parameters and window are:
Window: Hanning
Start/end frequencies: 0/74444Hz
BW: 0.1Hz
Overlap: 70%
Avarages: 3
Resulting BW: 0.18Hz
After playing with the available windows (but keeping all other parameters fixed so it will refresh with the same latency), I have found that Flat-Top reduces the resulting BW to 0.24Hz but also reduces the leakage problem. This would allow us to see features over the problematic range. The first two attached figures correspond to 2015-10-28 14:48:24 ; they show how the Hanning window suffers from a real leakage problem while Flat-top maintains it’s performance. The feature over 8Hz corresponds to a problem solved by Bubba on log (22939).
I rather prefere to change the whitening filter, instead of chaging the windowing method.
Jeff and Miquel changed the DTT template displaying MICH, the new parameters and window are:
Window: Flat-Top
Start/end frequencies: 0/74444Hz
BW: 0.08Hz
Overlap: 70%
Avarages: 3
Resulting BW: 0.235628Hz
We believe that changing the whitening filter will not solve this leakege problem. The Hanning window resolves the frequency location better i.e smaller *BW but it's error in amplitude is up to 16%, whereas the FlatTop window measures better amplitude there for in this case reduses the leakege problem.
We have a few piece of evidence that suggest that anthropegenic noise (probably trucks going to ERDF) couples to DARM through scattered light which is most likely hitting something that is attached to the ground in the corner station.
On monday, Evan and I went to ISCT6 and listened to DARM and watched a spectrum while tapping and knocking on various things. We couldn't get a response in DARM by tapping around ISCT6. We tried knocking fairly hard on the table, the enclosure, tapping aggresively on all the periscope top mirrors, and several mounts on the table and nothing showed up. We did see something in DARM at around 100 Hz when I tapped loudly on the light pipe, but this seemed like an excitation that is much louder than anything that would normaly happen. Lastly we tried knocking on the chamber walls on the side of HAM6 near ISCT6, and this did make some low frequency noise in DARM. Evan has the times of our tapping.
It might be worth revisiting the fringe wrapping measurements we made in April by driving the ISI, the OMC sus, and the OMs. It may also be worth looking at some of the things done at LLO to look accoustic coupling through the HAM5 bellow (19450 and
14:31: tapping on HAM6 table
14:39: tapping on HAM6 chamber (ISCT6 side), in the region underneath AS port viewport
14:40: tapping on HAM6 chamber (ISCT6 side), near OMC REFL light pipe
14:44: with AS beam diverter open, tapping on HAM6 chamber (ISCT6 side)
14:45: with OMC REFL beam diverter open, tapping on HAM6 chamber (ISCT6 side)
14:47: beam diverters closed again, tapping on HAM6 chamber (ISCT6 side)
All times 2015-10-19 local
I've made some plots based on the tap time Evan recorded (the recorded time seems off by half a minute or so compare to what really shows up in the accelerometer and DARM). Not all taps created signals in DARM but every signal that showed up in DARM has the same feature in a spectrogram (visible at ~0-300Hz, 900Hz, 2000Hz, 3000Hz, and 5000Hz. See attachment2). Timeseries also reveal that whether or not the tap would show up in DARM does not seems to depend on the overall amplitude of the tap (seen in HAM6 accelerometer, see attachment 3). PEM spectrum during different taps times doesn't seem to give any clue why one tap shows up in DARM more than the other (attachment 4,5). Apology for the wrong conclusion I drew earlier based on the spectrum I plotted using wrong GPS time (those plots have been deleted).
I zoomed in a little closer at higher frequency and realized this pattern is similiar to the unsolved n*505 glitches. Could this be a clue to figuring out the mechanism that caused the n*505?