| Work Permit | Date | Description | alog | 
| 6174.html | 2016-09-20 17:00 | Activity: Bug fix to Time Dependence calculations; must pick off SIN/COS output of oscillators for excitation injected just upstream of DARM filter banks (which determines the actuation strength of the ETMY's). Change to h1calcs front-end model alone. Requires a DAQ restart. | 20853, 29852 | 
| 6173.html | 2016-09-20 10:52 | Activity: h1fw2 has the rcg3.2 daqd code with additional EPICS diagnostics channels. These need to be added to the DAQ (H1EDCU_DAQ.ini). DAQ restart needed. | 29852 | 
| 6172.html | 2016-09-20 10:31 | Activity: Remove old second loop ISS; rename outerloop to secondloop. Copy over QPD & REF. | 29854, 29852 | 
| 6171.html | 2016-09-20 09:52 | Activity: clone h1fw1, run h1fw0 with the cloned disk to make the two frame writers identical. Will require NDS restarts as we swap between frame file systems. | 29852 | 
| 6170.html | 2016-09-19 16:21 | Activity: Investigate clipping of PCal beams. This will require an aligned ETMx and the end station will be transitioned to Laser Hazard. | |
| 6169.html | 2016-09-19 14:46 | Activity: Install interlock to prevent pump from restarting after power outage. This is to mitigate a problem with the pump running backwards after brief power glitch. | |
| 6168.html | 2016-09-19 10:46 | Activity: reuse two spare filermodules for PWR-EOM data. install additional PWR filters. DAQ change to replace in commissioning frame the 2 spare with 3 pwr_eom at 2kHz. DAQ restart required. | 29797 | 
| 6167.html | 2016-09-19 10:08 | Activity: Lower flow through the PSL HPO in an attempt to mitigate increased pointing noise (especially around 1kHz). | |
| 6166.html | 2016-09-19 09:38 | Activity: Update h0vaclx to remove PT140 gauge pair. This has been replaced by a BPG402 gauge. Requires DAQ restart. Will trip ITMX and HAM6 HV supply. | 29794, 29835, 29839, 29852 | 
| 6165.html | 2016-09-16 14:47 | Activity: Replace a generic interface box (D1002932) with a whitened version of the generic interface box in order to improve the signal-to-noise ratio for the intensity monitors. The box sits under the PSL table, and therefore the person needs to enter the PSL booth. | |
| 6164.html | 2016-09-16 08:59 | Activity: Set h1brsex and h1brsey to autostart the Beckhoff PLCs, C# code and EPICS IOC. Test through restarts. | 29832 | 
| 6163.html | 2016-09-16 08:32 | Activity: Host tour for vacuum/NEG pump vendor visitor to either EX or EY, which ever is less intrusive. Start around 9:45am and should last no longer than 15-20 min. | |
| 6162.html | 2016-09-15 17:20 | Activity: upgrade h1hwsex computer from U10.04 to U14.04 | |
| 6161.html | 2016-09-15 15:52 | Activity: Continue development on the MEDM to html converter. This is to improve the current screens and prepare more for presenting it at the EPICS meeting next week. This will likely involve minor outages of the screens that are reflected in realtime over lhocds (not the remote medm commands) which are used by the vacuum and facilities group. This will require remote access to CDS. | |
| 6160.html | 2016-09-15 14:45 | Activity: Edit h1susprocpi to save 64 channels to science frames at 2048 (32 BP_IN1 and DAMP_32 OUT). Edit PI_MASTER > IWAVE_PLL_BY_MODE to add EpicsIn 'State'. The latter will allow user input to set a state for each mode that guardian can then read to determine if mode should be handled by guardian or not. | 29739 | 
| 6159.html | 2016-09-15 08:50 | Activity: Swap ion pump controllers. Remove ion pump controller from x-end and install at x-mid. Install removed controller from x-mid at x-end. | 29729 | 
| 6158.html | 2016-09-14 14:17 | Activity: Fix the ISS arm power scaling for the third loop. Requires updated LSC and ISS front-end models. | 29701, 29732 | 
| 6151.html | 2016-09-12 11:54 | Activity: GC core router will be rebooted and have transceivers swapped to upgrade from 1Gb to 10Gb connection with ESnet. Wireless and Internet connectivity will be disrupted during the short outage. CDS and LDAS internal networks will be unaffected, along with the phone system. | 29829 | 
| 6105.html | 2016-08-19 14:44 | Activity: Pull EtherCAT End Station Chassis 3 at EY and EX. Will inspect cabling for the Demod readbacks for the green WFS. Fault Report 6024 | 29848 | 
I've stepped all four ring heaters consecutively tonight by 4 W each to identify which test mass belongs to the new 17783 Hz/47.7 kHz PI mode (alogs 29820 and 29838). The shift in frequencies of the test masses is dominated by a change in the Young's modulus which we can alter via the ring heater power; by stepping each ring heater and finding which causes a larger relative frequency shift of the mode in question, we can identify which test mass the mode is from. See T1600080 and LLO alog 18002 for more info. All power changes below were applied to both top and bottom ring heater. All times UTC.
ETMX: 0.75 --> 2.75 @ 9:29 --> 0.75 @ 9:48
ETMY: 0 --> 2 @ 9:49 --> 0 @ 10:08
ITMX: 0.25 --> 2.25 @ 10:08 --> 0.25 @ 10:29
ITMY: 1.25 --> 3.25 @ 10:31 --> 1.25 @ 10:41
Note we just lost lock around 10:42, probably due to these ITM steps.
Driving the ITM ESDs to saturation in a single quadrant raises peaks in DARM.
We've only briefly (and at first accidentally) investigated. I drove ITMY and ITMX ESD UL to saturation at 17783 Hz and we see a broad peak in DARM over an order of magniture above noise floor at 81.9 Hz for each. Also drove ITMX same quadrant at 15006 Hz and saw several peaks in DARM, most notably at 55 Hz and 110 Hz. We'll do proper injections next.
Kiwamu, Terra, Lisa We had a hard time dealing with bounce and roll modes tonight and that slowed us down. After keeping them under control, we followed directions from Daniel and we engaged the ISS boost (gain increase from 5dB to 7dB, boost 1 on -- we believe this is supposed to give us a factor of 2 suppression at 2 kHz, with higher gain at 100 Hz). The higher suppression of intensity noise around 100 Hz exposed a suspicious shape in the noise curve, so we decided to triple-check the calibration by making complete calibration measurements (see Kiwamu's entry). With the new calibration filters, the suspicious shape at 100 Hz disappeared, and we got back a more familiar curve...and some Mpc, SensMon is around 60 Mpc. The "jitter/intensity/(frequency?)" noise coupling to DARM stabilizes in a bad place after a while at 50W (yellow is O1 reference, all the other colors are curves taken at different times during the lock in low noise), making DARM worse between 500 Hz and 1 kHz, and even more clearly above 3 kHz. So there is more work to do to figure out how to keep the coupling low. We leave the IFO to Terra for PI tests. Some details: - bounce and roll modes are becoming a problem, they required constant attention during lock acquisition; - we had an error message once complaining that the ISS third loop was not engaged, and we couldn't move on in the locking sequence; Kiwamu bypassed the problem by forcing power increase (we also had some problem closing the ISS second loop from the medm screen (?)) - there have been (at least) a couple of ISS instabilities that prevented us from staying locked in DRMI; we "fixed" them by increasing the diffraction power, that happened at least twice today - we reversed the change to the DARM gain, now it is back to 1400
Lisa, Kiwamu,
We think that the calibration has been wrong and therefore it lifted up the noise floor below 300 Hz. We need another set of eyes tomorrow to doublecheck our theory (we are currently too sleepy to do systematic investigation).
In short, we believe that the sign of ETMY L3 stage in CALCS (or somewhere else similar to it) is wrong which is exactly the same situation as what happened in this past July (28396).
Because I knew that our DARM open loop model is accurate and consistent with the recent measurement (29748), I made a calibration filter for DARM_IN1 which converts DARM_IN1 to DARM displacement as opposed to the use of both DARM_IN1 and DARM_OUT. Here is a comparison of the CALCS spectrum against the spectrum derived from DARM_IN1.
As shown in the plot, the CAL CS spectrum overestimates the noise floor below 300 Hz or so. This is exactly the same behavior as what we have experienced in this past July. In addition, we have noticed that the noise floor of CALCS changed as a function of the DARM control gain which should not happen in the calibration scheme used in CAL CS. Also, when we flipped the sign of the EY L3 stage in CAL CS, the leve of the noise floor became identical to the one derived by DARM_IN1 and also became insensitive to the control gain. This increased our confidence that the L3 sign was wrong in CALCS.
We are leaving the L3 stage gain flipped (DRIVEALIGN_GAIN -30 --> +30) for the night. If our theory is correct, we regain the binary range back to ~60 Mpc with this change.
Also, we took a DARM open loop and PCAL sweep measurement within the same lock stretch. We did not analyze them yet, but they are available at:
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/PCAL/2016-09-21_H1_PCAL2DARMTF_4to1200Hz.xml
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/DARMOLGTFs/2016-09-21_H1_DARM_OLGTF_4to1200Hz.xml
Also, my code which generated the calibration filter for DARM_IN1, as well as, the generated filter are available at:
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/CalibrateH1DARM_IN1.m
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/DARM_IN1_calib.txt
I don't know what was decided this morning, but somehow we ended up with the wrong actuator sign in the front-end calibration again. So I reinstated the sign flip in the drivealign calibration filter.
After we fixed the sign flip on the night, the Pcal to CAL-CS transfer function looked indeed correct. See the attatched screenshot below.
The transfer function from Pcal to CAL-CS is almost unity in magnitude and zero in phase which double-confirms that the sign flip was the right action. The dtt template was updated with the latest DELTAL_EXTERNAL whitening filter, known delays.
The dtt file can be found at:
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/PCAL/2016-09-21_H1_PCAL2DARMTF_4to1200Hz.xml
The matlab script which produced the calibration filter can be found at:
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/H1_pcal2darm_correction.m
Finally the calibration filter in ascii formt is available at:
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/pcal2darm_calib.txt
By the way, in the script, I needed to add an additional minus sign in order to get the resulting phase close to zero rather than close to 180 deg. I feel like this is one of theose things we had found during O1, but I can't recall what introduced a minus sign. In addition, the calibration filter currently does not include the effect of the supernyquist poles of OMC DCPDs which introduces a phase delay at high frequencies.
The open loop transfer function(s) can be now analyzed by a copy of Evan G's code,
	/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/DARMOLGTFs/compareDARMOLGTFs.m
The attached are the resulting figures from the code. I have not adjusted kappas or examined each piece of the DARM loop yet, but the model showed a good agreement with the measurement-- no crazy bug so far in the model.
Cheryl, Kiwamu,
Related to 29808, 29793, WP6165
[Modified generic interface box is now installed]
We have replaced the generatic interface box with a modified box (S1103802) in the PSL booth today. The box was the one for reading out the EOM pick off (IMC-PWR_EOM) and the periscope power (IMC-PWR_IN). Their associated AC channels are now with a gain of 200 at high frequencies above 4 Hz as described in Daniel's log (29808).
[PDA55 is installed for monitoring the light before EOM]
In addition, we have newly installed a PDA55 in order to monitor intensity noise before the EOM. See the attached for the setup.
As shown in the picture, the PDA55 recieves light leaking to the first steering mirror after the PMC. According to a handheld power meter, the power level of thie light was about 1 mW. The PDA55 with the lowest gain setting gave us a DC voltage of 4 volts.
Currently IMC-PWR_EOM_AC and IMC-PWR_EOM_DC are connected to this new PDA55 and not to the actual EOM pick off.
[Some cleaning up]
There was an undumped reflection back form a lens (IO-MB_L2). We put a beam dump by the Faraday isolator of the ALS.
Also, some pictures are available in ResourseSpace https://ligoimages.mit.edu/?c=1712
Title: 09/20/2016, Evening Shift 23:00 – 07:00 (16:00 - 00:00) All times in UTC (PT) State of H1: IFO is down due to a problem with the Guardian. CDS is working on the resolution. Commissioning: Outgoing Operator: Ed Activity Log: All Times in UTC (PT) 23:00 (16:00) Start of shift 23:35 (16:35) Rick & Travis – Back from End-X 23:37 (16:37) Ben – Going into LVEA to look for tools 23:42 (16:42) Ben – Out of the LVEA 00:05 (17:05) Kiwamu & Nutsinee – Out of LVEA 00:07 (17:07) Dave – DAQ restart (WP #6174) Title: 09/20/2006, Evening Shift 23:00 – 07:00 (16:00 – 00:00) All times in UTC (PT) Support: Jenne, Sheila, Lisa, Kiwamu Incoming Operator: N/A Shift Detail Summary: Ran initial alignment after Guardian fixed and people out of LVEA and End-X. Commissioning and relocking took up the bulk of the shift. Environmental conditions of light winds and low seismic activity all shift. The End-X BRS was rung up all shift. Using ISI_CUST_CHAMBER_GND_BRS.adl to monitor. No change in signals during the shift, so per Jim W. did not make any adjustments or changes.
Jeff K, Dave B, Darkhan T,
Overview
Coherence calculation settings were updated today's after a minor bug fix in CAL-CS.
We discovered that some of the reference EPICS records that are used for calculation of kappas in the front-end were not set (or lost after a DAQ restart). The records were populated with values calculated from the DARM model for ER9.
Details
Similarly, SUS_LINE1 synched oscillator SINGAIN and COSGAIN values must be set to be $(IFO):SUS-ETMY_L3_CAL_LINE_CLKGAIN multiplied by DAQ downsampling TF magnitude at this frequency (35.9 Hz at LHO). Synched OSC phase must be set to the DAQ downsampling TF phase at the line frequency (not sure if we need to put positive or negative phase). Previously SUS_LINE1 synched OSC parameters were not set properly and the coherence was not calculated (see attachment 4, coherences calculated during last 4 days).
	Both DARM_LINE1 and SUS_LINE1 oscillator parameters were updated, the changes were accepted in SDF_OVERVIEW.
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_(REAL|IMAG) and H1:CAL-CS_TDEP_CAVITY_POLE_PCAL_FREQ:
	Old : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_REAL 0
	New : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_REAL -1.73852e-19
	
	Old : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_IMAG 0
	New : H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_IMAG -1.03541e-19
cds_user_apps repo, r14297.J. Kissel, S. Dwyer, L. Barsotti At the advice of DetChar (LHO aLOG 29828) we've balanced the DCPDs, which indeed hasn't been done since the new breadboard and PDs were installed (LHO aLOG 28862). Unlike the previous pair of DCPDs which were out-of-the-box perfectly balanced (see LHO aLOG 17650), the current pair has an imbalance of 2.1106%. This value has been entered into H1:OMC-DCPD_BALANCE, and accepted into the SDF "down" state for the h1omc model. Method: For the DCPD sum, we take an average of the two: A/2 + B/2. The h1omc front-end infrastructure is built such that the percentage imbalance, e, is applied to both equally: A*(1 + e)/2 + B(1 - e)/2 So, the transfer function measurement of DCPD A/B is (1+e)/(1-e) ~ 1 + 2e. Since the transfer function magnitude is 0.957788, then the imbalance we enter will be e = ((A/B) - 1) / 2 = 0.021106 = -2.1106%. We also found this value gradually (because we weren't sure how the infrastructure worked), by confirming the imbalance that minimized the DCPD NULL stream (and the coherence drops to zero). Overshooting the imbalance (e.g. by entering in -4.2%) shows a clear sign flip from the reference trace where there is 0% imbalance compensation.
This is not relevant anymore, since the OMC model has been changed to a more transparent matrix, but there was no divide by 2 in the old scheme. The sum was just a plain sum of the balanced values. (Trying to incorporate that non-existent factor of 2 just caused a lockloss while trying to implement the new matrix, which is the only reason I mention it).
Ben Keita Daniel
We updated the ISS box:
We made the following model updates:
D. Tuyenbayev, J. Kissel
Darkhan had noticed that we are demodulating the ETMY SUS calibration line (which determines the test mass (L3) stage actuation strength change, kappa_{TST}) differently than that which is injected just after the DARM bank from the CAL-CS model (which determines the PUM+UIM (L1+L2) stage actuation strength change, kappa_{PU}), after we upgraded the font-end DARM loop parameter time-dependence calculations (see e.g. LHO aLOGs 29231, 29740, and 29744). In short, for the DARM line, he discovered we're not able tune the phase of the oscillator for this new time dependent analysis. If we keep this, then we'd have to maintain two sets of DARM loop model EPICs records to calculate these actuation strength changes, because offline construction of kappas must include the phase destortion of DAQ downsampling filters at the calibration line frequency, where any front-end calculation does not. Also, it seems unnecessarily confusing to demodulate various lines differently.
As such, for the DARM_LINE_MONITOR block in the 
/opt/rtcds/userapps/release/cal/common/models/CAL_LINE_MONITOR_MASTER.mdl
library, we've broken the DARM_LINE_DEMOD tee-off of the CLK output of the oscillator, and replaced it with the I phase output of a phase rotation block, which picks up the SIN and COS outputs of the oscillator.
These changes have been committed to the userapps repo.
			
			
		
		new h1calcs model WP6174
Jeff, Darkhan, Dave:
new h1calcs model installed. DAQ restart combined this and the last h1psliss changes.
h1psliss model WP6172
Daniel, Keita, Ben, Dave:
h1psliss was restarted several time, first to primarily replace OUTERLOOP with SECONDLOOP naming. Subsequent restart for minor name tweaks. Several DAQ restarts
Clone h1fw1 WP6171
Carlos, Dave
NDS were switch to using h1fw0's frames. h1fw1 was shutdown and its boot disk is being cloned. Due to its size (1TB) this will take overnight.
Reboot h1guardian0
TJ, Dave
We did a reboot of h1guardian0, later attemps to lock the mode cleaner showed connection errors for Beckhoff channels. Running caget on h1guardian0 did get the data, but showned two paths (direct and via epics-gateway). Stop-start of the node did not force the connection. We turned off the gateway (h1slow-h1fe) and rebooted guardian. Some nodes still showed connection errors, again caget connected. Finally we started the gateway and all the connections completed. Need further investigation with Jamie.
h1guardian0 was updated prior to the reboot, we think this may have broken INJ_TRANS node.
TCS CO2 chiler tests
Dave, Nutsinee:
Confirmed that pulling the chiller cable in preparation for a power cycle of h1oaf0 IOChassis trips the CO2 lasers and should not be done.
Remove old PT140 channels from Vacuum Controls WP6166
Patrick, Dave:
After Patrick had made the Beckhoff changes, I imported his latest h0vaclx.ini file into H0EDCU_VAC.ini This went in on later DAQ restart
Add h1fw2's new diag epics channels to DAQ WP6173
Dave:
h1fw2 is running Jonathan's RCG3.2 daqd with improved diagnostics. These additional channels were added to H1EDCU_DAQ.ini and went in on a DAQ restart.
h1susprocpi model
Terra, Dave:
Terra added epics input channels for state definition. Model was changed and DAQ was restarted. Small number of slow channels were added to DAQ.
DAQ restarts
Dave:
Several DAQ restarts during the day to support the above activities. Most went cleanly, two had minor issues
On one I needed to restart the mxstream from both h1pemmx and h1pemmy
On another I need to restart the mxstream on h1sush56
An idea was proposed to eliminate the possibility that charge build up on optics could be due to UV photons from new hot ion gauges installed at end stations. We (Jeff K., Betsy W., and I) may pursue this during O2 break by turning off IGs for extended periods of time while measuring charge rate. Attached is a schematic showing the location of the two new hot ion gauges (IG) at each end station (and one 250 meters down on each arm) AND now we have a updated VE GUI on MEDM, thanks to Gerardo, showing these gauges (names have changed): X4,Y4 are attached to the top of the very end BSC. X5,Y5 are right next to NEG pump, which is at about head level, also bolted to the very end BSC. X4 and Y4 are interlocked with high voltage, so if we turn them off, we need to immediately turn HV back on manually. We can leave the gauges off for a week or more; however, we lose HV safety interlocks. X5,Y5 next to NEGs can be turned off for as long as we need. X6,Y6 are 250 meters down from end stations next to the ion pumps (IP) that were installed to compensate for the valved out large IP at end station. Those IPs and IGs should be far enough away to avoid charging issues, but they are on valves and we could valve the pump out for a day if we absolutely need to (we will see a pressure rise but it will recover when we turn pump back on).
Re-plumbed exhaust flow meter on CP4 incorporating a "trap" to protect flow meter from LN2. Only the finest flex tube and zip ties were used.
Continued troubleshooting the Demodulator readback signals for the green WFS at the end stations. Traced issues to faulty Beckhoff analog input terminals - EL3104.
EY - EL3104 Terminals 6 and 9 were replaced
EX - EL3104 Terminals 6, 7, 8 , and 9 were replaced. I don't expect all four units to be bad, but was easier to replace all four at once.
Units removed will be tested to see if we can reproduce/diagnose the problem.
One thing to note is that the RF Mon channels at EY were not as stable as EX. The LO mon signals at EY (15dB) had a 3dB difference than EX (18dB). Not sure if this is an issue or just the state of each end station at the time of testing.
Maintenance Day
15:03 Ben Abbott out to LVEA to pull out ISS chassis
15:04 Patrick executing WP#6166
15:07 Joe into LVEA for weekly inspections of batteries, etc.
15:09 Cleaning crew dispersing to End Stations
15:17 Ben out of LVEA
15:21 Kyle outo EX
15:30 Fil to EY to troubleshoot WFS readbacks
15:40 BRS at both ends turned off
15:51 Kiwamu to squezer bay
16:00 Kiwamu out
16:06 Jim to EY to check on ion pump for BRS
16:07 Christina leaving EX
16:11 Gerardo out to LVEA to power up PT140
16:14 LASER tripped
16:29 Jim back
16:33 Karen leaving EY
16:35 Kyle and Fil back
16:37 Travis back from EY
16:38 Jason starting to bring the LASER back up
16:39 LN2 Delivery arrived
16:55 Karen into LVEA
17:01 Alfredo into Biergarten to install 24V junction boxes on top of racks.
17:16 Jason into LVEA to reset Noise Eater
17:19 Hugh and Chris out to EY mechanical room with the big truck
17:21 Mike L into LVEA for a quick tour
17:28 Richard out to reset theHV interlock that tripped during vaccuum system reboot
17:29 Kiwamu and Nutsinee into optics lab
17:39 Richard out
17:48 Nutsinee doing TCS work
17:52 Joe into LVEA for his usual weekly checks
17:54 Ben returning the ISS chassis to the LVEA
17:54 Travis, Rick and co. to EX for Pcal work
17:55 EX transitioning o LASER HAZARD
17:57 Betsy out
17:59 Gerardo out of LVEA.
18:01 Nutsi out to LVEA (TCS)
18:24 Cheryl ad Kiwamu into PSL enclosure for WP#6165
18:37 Chandra going for a jog along the X-arm
19:35 Fil to EX
19:40 Chandra back
20:02 Kyle to EX
20:17 Richard into CER to install reset buttons on HV interlock boxes
20:21 Richard back
20:39 DAQ restart ( 3 times)
20:45 DAQ is back (3 times)
21:02 DOH onsite for John W
21:07 John and DOH into LVEA
21:32 Rick and Travis headed back to EX
22:47 Fil back from EX
22:57 Handing of to Jeff B
Today, Carlos P. fixed the LAN setup IP address issue for me and I was able to connect to the X-end RGA electronics using the dedicated laptop. This allowed me to confirm that the RGA still functioned following its removal and re-installation the other day (prerequisite to performing the bake operation). I then wrapped the whole assembly in aluminum foil (it's an art - performed by artists). At the next opportunity, I will wrap the assembly in heat tapes (also and art - performed by artists!) followed by the final layer of aluminum foil. At that point, it will sit idle awaiting the next 5-day window of IFO down time to perform the actual bake.
A reminder that we are in the testing phase of operator control of remote access to LHO CDS. This is a soft roll-out, it is only in effect while an operator is on duty and it does not kill any running sessions.
Here is part of an email which was sent to remote access users on 8/30
Dear All,
this email is being sent to everyone who has logged remotely into LHO CDS in the past calendar year. Starting today we are testing an enhanced security system which requires remote users to call the control room operator before remote access is permitted. During this testing phase the additional restrictions will only be in place when an operator is on shift, 8am to 4pm Pacific Local Time Monday through Friday. Outside of these times, access will be unrestricted. Open sessions which span these time boundaries are unaffected.
Note that this applies to secure copy (scp) as well as secure shell (ssh) sessions.
The operator’s phone number is (509) 372 8202
Dave, Nutsinee
Today we did a little test to confirm that there's no way to aviod CO2 laser tripping when oaf computer and IO chasis are bering restarted by unplugging the chillers from the front end which we thought might have worked at one point. Turned out as soon as the chillers were unplugged from the cables the CO2 controller box tripped immediately and the drawn currents went down to 0.7 A for TCSX and 0.8 A for TCSY (from their nominal at ~22A). Funny thing is when I went back to restart the controller boxes after plugging the chillers back in there're no red lights indicating that they had been tripped. They simply stopped lasing. The laser status looks like it's never tripped. So if somebody unplug the chillers and the lasers don't work, there's currently no obvious way to know from the control room that the chiller(s) have been unplugged (except that TCS laser locking guardian might throw fist and unreasonable DAC outputs).
Before I went out to the mezzanine I paused TCS guardian so that they won't try to talk to the chillers when they're disconnected. As soon as the chillers were disconnected (10:52 AM local) DAC output 1(ITMX pzt), 4(ITMX chiller), 9(ITMY pzt), 12(ITMY chiller) freaked out and dropped/jumped far from nominal. They didn't come back to their nominal values until I restarted the TCS laser locking guardian nodes after bringing everything back to normal.
We need Alastair's magic box to prevent TCS from tripping everytime oaf/dac is powered down.
TCS CO2 system layout can be fround here
If by magic box you mean the summing chassis, that wont stop the lasers from shutting off when the OAF computer goes down. That is installed at LLO and it still goes down. The summing chassis was for a different problem
Also on the CO2 control boxes in the LVEA after the laser goes down, red lights dont show. It should be that not all the green lights are displaying. That is your warning something is wrong. Its not until you rehit the red "gate" button that all the lights will come back on illuminating green (my memory could be wrong though).
Also you can see if the laser is ON by looking at the TCS screens and seeing the power coming out of the laser. Or you can look at the flow of the chillers, etc on the main TCS MEDM screens to see if the chillers are working
J. Kissel Now that we're approaching ER10, and the noise is getting back to O1 levels, we need to start tracking the time dependence of the SRCL detuning in the DARM response. As such, with only intuition to guide, I've added a new calibration line at 7.83 Hz, driven by PCALY at a requested amplitude of 20000 [ct] (corresponds to a DAC [ct/rtHz] of 28909, and 8.8e-13 [m/rtHz] of DARM displacement). For a 10 [sec] FFT, with the current sensitivity, this has about an SNR of 10. We can explore driving the line harder, but let's see what we get out of this -- we're already close to the limit of the PCAL AOM, and that's what I used to tune the excitation amplitude. Also note that, although we often use a 10 [sec] FFT as our SNR metric, in practice, we often use 60 or 120 [sec] FFTs (i.e. the time scale on which we expect optical plant parameters to vary), so we'll win there. I've checked to make sure that this new line - Does not saturate the PCALY DAC - Does not saturate the PCALY OFS - Does not saturate the DARM actuator when trying to control this line (ETMY SUS) - Does not generate any substantial harmonics or other non-linear noise in DARM And I've also accepted the settings for this new line in the safe and OBSERVE snaps for PCALY. Let's get this line into SLM tool and start analyzing to see if the SRC detuning moves! P.S. We expect fisher-matrix back-up that this is roughly the "optimal" location for the SRCL line, given that we suspect the optical spring frequency to be around 9.8 [Hz]. Of course, we cannot put the line right on 9.8 [Hz], since that's exactly the frequency of the QUAD's highest vertical mode (a.k.a. "bounce" mode). I've compared 7.93 [Hz] against all of the "do not put a line here" criteria used for the original calibration lines (see LLO aLOG 15870), and this frequency does indeed satisfy those criteria especially since the line is below the astrophysical analysis band.
Ring heater tests indicate that the new 17783 Hz (aliased from 47753 Hz) belongs to ITMY, in agreement with Slawek's prediction.
Below shows the relative frequency shifting of one mode per test mass and mystery 17783 Hz mode ('o') during the ITM ring heater steps. ITMX was stepped up first then stepped down at the same time ITMY was stepped up. As expected, the 15518 Hz mode on ITMY rises slightly with the ITMY ring heater increase. At the same time, we see a drop in 17783 Hz; since 17783 Hz is the aliased-down frequency, we see it decrease as the 47.7 kHz mode shifts upwards.
I've set up damping settings for 17783 Hz on MODE 7. I tried many times to drive it up but got little response; as seen in Slawek's mechanical mode shape simulations, there is poor overlap with ESD actuation. Recently we were unable to damp 18041 Hz (aliased down from 47.5 kHz); ultimately we had to change ring heater power to avoid.