Started Famis Task to check all the CPSs weekly. This noise has not been seen since June3, aLog 27549. Will move FRS 5615 to pending and recommend closing. Maybe power outage 6 June helped.
100mL of water was added to the Xtal chiller to bring the sight-tube level to MAX. Xtal flow is 20.1 l/min. Diode chiller was not in alarm and flow rate showed 31.5 l/min. FIlters showed no discoloration to note.
The front end pump diode temperatures were adjusted to increase the laser power.
- D1 was 26.6 degC is now 26.4 degC
- D2 was 24.6 degC is now 24.4 degC
- D3 was 27.8 degC is now 27.5 degC
- D4 unchanged
The temperature changes increased the output power by ~300 mW.
Increased the diode currents for the front end laser to bring the power back to where it should be.
- D1/D2 was 45.5 A is now 46.0 A
- D3/D4 was 47.5 A is now 49.5 A
The net result is that the front end laser power increased by 1 W. That helps to preserve the
injection locking bandwidth a trifle.
The temperatures of the high power oscillator pump diodes was also adjusted. A 4 W increase
was obtained. The diode currents were not touched.
Observatory Mode taken from Unknown to Commissioning
Some recovery from Maintenance Thurs (Roll Modes and checks of violin modes). Rest of the evening consisted of Commissioning work (Jeff
Worked on damping out Roll Modes of ITMx (with Sheila's tutorial). Spent about ~30min (started at 4:58pm)
Received some Test Mass Coil WD Verbal Alarms (i.e. ETMX RMS ['LR'] WD has tripped). And this was a first for me. Kissel pointed me toward how to untrip these (Jeff said this WD is for the Test Mass penultimate masses (which is L2?). For L2, the WD Trips are located on the right side of the SUS screen (RMS WD RESET). To clear, put in a 1.0 for the UL & then take it back to 0.0. This seems to take care of it for all the coils! Kissel was concerned that these sort of WD trips could be a sign for violin modes ringing up.
SIDE NOTE: The operator electric table apparently couldn't take my weight & failed. Please do not use this table until it is repaired.
Please do not sit on the electric table at the operator's station. It is not intended to support your weight.
Bubba repaired the table this morning.
We had a couple locklosses when the ISS saturated, both with the third loop on and off. We just increased the ref signal to -1.52 V to move the diffracted power to around 4%. Was some setting incorect after a reboot this morning? SDF indicated that everythind is OK.
The 1st loop's reference offset voltage (H1:PSL-ISS_REFSIGNAL) is not monitored in the SDF system. During O1, because of the alignment drift in the PSL and or interactions with the 2nd loop, the operators would often adjust the diffracted power with this offset. I've now re-monitored the channel, for now, because we don't have any restriction of SDF difference to do science. Keita restarted the PSL ISS model again this morning, and we had begun relocking too quickly (!!) after that reboot, so we had to adjust the offset on the fly, when it was have too late. This resulted in a close, but not the same, value of -1.602. Also had to restore the "AOM Offset" H1:PSL-ISS_CTRL_OFFSET, which should be 3.85 (it had come up as 2.5). I've accepted both the -1.602 offset voltage and 3.85 AOM offset in the SDF's safe.snap and down.snap for the PSLISS front-end.
Note that the H1:PSL-ISS_CTRL_OFFSET used to be 2.5, but yesterday Keita and I changed it to 3.85. Thank you Jason & Jeff for pointing out that I forgot to write an alog.
We made this adjustment with the ISS first loop off, and set the offset such that the diffracted power was a little over 3%. Before doing this, the diffracted power was 1.7% with the first loop off, and we kept hitting the bottom rail, which would send the first loop into oscillation and cause it to unlock. We were able to close the 1st loop, and everything looked okay. So, 3.85 is the new best value.
With all that said, we've had a few times over the last 3 days of hitting the bottom rail of the ISS when we've got the IFO locked, and it changes the power injected into the vacuum and the IFO oscillates a bit although usually retains lock. We may need to consider increasing the first loop offset even more, so that we're a teeny bit farther away from that rail.
PT-140a (pirani) is off scale again, after more adjustments to pot this morning by Gerardo. It was working for a while today, reading in -4 Torr range and the CC was ON. I'm reopening FRS ticket 6061 so Richard et al can look at wiring. Noticed that when I turn CC on the pirani reading drops from 1e-3 Torr to 5e-4 Torr. Note that when we powered down PT-110a (on HAM6) we noticed a change in PT-140a.
I was perusing the lsc model and noticed that it looked terrible. The reason was that the lsc/common/models/lsc.mdl file has been saved with matlab-2015b and looks very bad when viewed with matlab-2012b (please see attached screen shots).
Currently CDS has standardized on matlab-2012b for all front end model files. I checked all the H1 files and found we have three model files which have been saved with 2015b (lsc,mdl, h1isietmx.mdl and h1isietmy.mdl). Having a file written by different versions of matlab also makes 'svn diff' essentially worthless due to the large number of format differences.
I'll convert the 2015 formatted files back to 2012 format. Perhaps adopting a later version of matlab for CDS is a topic for discussion with a larger audience.
The left plot is the 2015-format file viewed with 2015b, the right plot is the same file viewed with 2012b.
BTW, here is a one line (albeit a long line) command to list any source mdl files which have a matlab version other than 2012b. At this point I have reverted lsc.mdl, so only ISI models are left upgraded.
for i in $(grep -h mdl /opt/rtcds/lho/h1/target/*/src/src_locations.txt|sort -u);do which_matlab_version.py $i|grep -v 2012b;done
2010a /opt/rtcds/userapps/release/isi/common/models/Offset_DOF.mdl
2015b /opt/rtcds/userapps/release/isi/h1/models/h1isietmx.mdl
2015b /opt/rtcds/userapps/release/isi/h1/models/h1isietmy.mdl
all user files reverted to 2012b. I rebuilt the kernel object files and verified they only differ with the running files by the different build-date strings.
J. Kissel, C. Vorvick, S. Dwyer After this morning's reboot of the entire corner station (LHO aLOG 29302) we had a little bit of trouble re-locking the mode cleaner. We eventually realized, once again, that upon reboot the EUL2OSEM matrix values for the bottom stage of the HSTSs (i.e. M3 of MC1, MC2, and MC3) are restored, but they don't get loaded because the load button is a momentary. We have solved this before by requesting that all of these matrices be loaded in the ISC_LOCK guardian (see, e.g. LHO aLOG 25208), but we're often in a situation where we're trying to recover the IMC much earlier that we ever run the ISC_LOCK DOWN state. As such, I've copied the load matrix lines from the ISC_LOCK guardian's down state, and stuck them in the IMC_LOCK guardian's DOWN state. This way as soon as we begin to play with the IMC, these M3 EUL2OSEM values will be loaded. The new IMC_LOCK guardian code has been both loaded into the running system and committed to the userapss repo here, /opt/rtcds/userapps/release/ioo/common/guardian
Plot shows OSEM IN goes to zero, pitch goes to zero, but the COILOUT drive and voltmon remain essentially unchanged from before and after the event at 11:15UTC.
I cannot change OSEM values with alignment slider or by removing all drive from the coils.
Plot 2 shows all of the IMs and MC1 and MC3.
IM4 Trans oscillates after the event, then is quiet.
I have already mentioned the possibility of a broken wire, to explain this event.
Cheryl's last sentence is pretty scary, so I would like to emphasize that this is not a suspension wire breakage event.
Note that IM4_Trans, other than a quick glitch, remains totally constant in spot position before and after this "event". The IM2 glitch happens at the left side of these plots (IM2 readbacks are the top left plots in Cheryl's attachment 2). The IMC does not lose lock until much later, and we see the IM4 Trans pitch and yaw in the bottom corner of Cheryl's attachment 2 is nice and happy until the IMC loses lock.
Work is still in progress to diagnose exactly what happened, but I suspect that somehow the OSEM readback channels went dead, which (since we use them for local damping) caused a transient signal to go to the coils, which caused a brief alignment glitch. Now the damping is obviously bad since we don't have valid signal going in, but the overall alignment of the optic seems not to have moved.
So before we vent I went and looked at the signal chain. I replaced the Sat Amp S1100173with a new one S110091. This has signals returning to the system. Normal may be up to someone else.
Opened and Closed FRS Ticket 6098.
IM2 is damped and realigned to restore pointing on IM4 Trans.
Change in satelite box means the IM2 pointing was not restored with the old OSEM values.
I realigned IM2 to restore the IM4 Trans values, which puts the IM2 OSEM pitch and yaw readings at p = +611, and y = -195 (old values p = 603, y = -204).
IM4 Trans values were p = -0.525, y = 0.095, now restored (IM1, IM3, and IM4 were restored earlier today).
Jim B., Patrick T. WP 6118 The IOC code was updated to directly include the device support code in the build directory instead of linking to a separately built support library. The source code from libavl and c_string was also moved into the IOC build directory. The IOC database was updated to add the humidity channels listed here: https://dcc.ligo.org/LIGO-L1600108 I ran into some build issues stemming from the fact that h0epics2 is running Ubuntu 10.04.4 and the repositories for it have been taken down. I instead compiled and started it on h0epics (Ubuntu 12.04.5), after Jim B. installed libcurl4-openssl-dev, make, g++ and libreadline. I noticed that the H0:FMC-MILLIAMP_MAXVAL channel has not been set and has thus been defaulted to 0. This is used in the conversion from milliamps to percent for a number of records. As a result these records have had values of inf (divide by 0). I set H0:FMC-MILLIAMP_MAXVAL to 12.0. Perhaps this should be hardcoded in the database. The added humidity channels are: H0:FMC-CS_OSB_RM132_RH_PCT H0:FMC-CS_OSB_RM161_RH_PCT H0:FMC-CS_OSB_RM162_RH_PCT H0:FMC-CS_OSB_RM163_RH_PCT H0:FMC-CS_OSB_RM165_RH_PCT H0:FMC-EX_DIS_RH_PCT H0:FMC-EX_OSA_RH_PCT H0:FMC-EX_SPACE_RH_PCT H0:FMC-EY_DIS_RH_PCT H0:FMC-EY_OSA_RH_PCT H0:FMC-EY_SPACE_RH_PCT H0:FMC-LVEA_AHU1_DIS_RH_PCT H0:FMC-LVEA_AHU1_OSA_RH_PCT H0:FMC-LVEA_AHU1_SPACE_RH_PCT H0:FMC-LVEA_AHU2_DIS_RH_PCT H0:FMC-LVEA_AHU2_OSA_RH_PCT H0:FMC-LVEA_AHU2_SPACE_RH_PCT H0:FMC-MX_DIS_RH_PCT H0:FMC-MX_OSA_RH_PCT H0:FMC-MX_SPACE_RH_PCT H0:FMC-MY_DIS_RH_PCT H0:FMC-MY_OSA_RH_PCT H0:FMC-MY_SPACE_RH_PCT These channels are not yet in the DAQ. I burtrestored the IOC to earlier this morning to set the alarm levels.
I've added them to H0EDCU_FMCS.ini and they will go in on the next DAQ restart. I checked that the new channels exist.
Running a Worden experiment: -CP4 at 88% full -Set LLCV to nominal in manual mode (41% open) -Increase LLCV by 5% (43% open) and leave it at this value -Monitor increase in fill -Allow fill to exceed 100% and monitor exhaust flow meter (expect a sharp increase in flow when liquid starts to hit warm exhaust) -After this sharp increase, reduce LLCV by 10% to below nominal (<41%) -Hope that no LN2 reaches the flow meter this time (when flow approaches 100% I will monitor while sitting next to exhaust to be ready to open bypass exhaust valve and remove flow meter with LN2 gloves on) **THIS WILL GENERATE CP4 ALARM ON PUMP LEVEL**
Note: this is done with Dewar at 39.6% full
I increased LLCV to 45% (10% increase from nominal) to speed things up. 5% LLCV increase is about 1% fill increase every 40 min.
Taking too long to reach critical point (>100% full), so I'm terminating this experiment before alarms start (>98% full), and will restart early tomorrow at 90% full set point.