IFO broke lock at 16:16 (08:16). Cause at this time is unknown. During relocking could not move past DRMI_1F. Consulted with Kiwamu and decided to run an initial alignment. IFO was relocked at NLN at 17:47 (09:47). Ran A2L script. There were SDF notifications for both ETMs and ITMs. Could not find a SUS person, so took screenshots and accepted all. Set intent bit to Observing at 18:25. Spoke with Hugh about the BSC ST2 Guardian notifications.
Jeff - you've done the correct thing to accept these SDFs, so good. As Evan says in his 23085 alog, the violin damping buttons were all switched back ON (via gain) this time up in the Guardian. Also, everytime you run the A2L script we should eye-ball that the values are not crazy different and then accept them in SDF. Thanks!
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.
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.
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?
Now that we've cleaned up all of our systematics from the DARM model and released the O1 version (see LHO aLOG 22056, I've updated the diagram that explains how the actuation path clock cycle delay is derived, and also shows that the current value of 7 [clock cycles] or 427.3 [us] that was recently installed at both sites (LHO aLOG 21788) still does a fine job at approximating the total delay between the inverse sensing and actuation chains.
A good diagram on the timing of a hardware injection through the DARM path: LLO aLOG 22361