Dave, Darkhan, Jeff:
A code bug in the file cds/common/src/BUFFER_AND_AVERAGE.c was fixed and h1calcs was restarted. No DAQ restart was required. This is the only model which uses this file.
Dan, Jim W, Sebastien, Dave:
While Sebastien was visiting LHO during the past week, we performed a test install of the MIT (Sebastien and Michael C.) earthquake arrival predictor code (seismon). Here is a summary of the install work so far:
We are using the spare CW injection computer, Dan M. upgraded this system from SL6.7 to SL7.2 last week.
The software install is in two parts: the USGS client system which periodically downloads seismic data from USGS, and the python code which analyses this data and issues local alters.
The USGS client code (based on java) was installed last Friday and have been running continuously since then. The connection between CDS and USGS is initiated internally for security reasons.
Today we got the seismon_traveltimes python code running, which for earthquakes with magnitude > 5.0 provides predicted arrival times (for each of; p-wave, s-wave, 3XRayleigh waves), predicted maximum velocity and surface distance from eq-source to LHO.
I'm working on scripts to run this continuously with a time resolution of about a minute, and to export these data as EPICS channels.
After a period of testing, we will decide how this system will be installed permanently on site (e.g. dedicated computer, integrated EPICS IOC)
John, Chandra Overfilled CP4 today while monitoring exhaust pressure and flow (from control room). -Manually set LLCV to 66% open (double nominal value) -Took 17 min. to fill to 100% (started at 90%) -Took another 60 min. to see a drastic change in flow and pressure beyond 100% full (i.e. cooling exhaust line) *constant 66% open -When exhaust pressure spiked to ~6 psi (flow meter spiked to ~480 slpm) we terminated the experiment and lowered LLCV to 20%, then 10% -Kyle reported the new plastic flex line froze and all exhaust pipe was cold to the touch. Flow meter read -5decC. -John and I measured uninsulated exhaust line temp afterward: -8degF where pipe exits building (lots of frost build up) and ~26degF several feet downstream We will repeat experiment tomorrow morning after exhaust line warms up but this time run until LN2 flows out end of exhaust line. We will install one or a few thermocouples along exhaust line.
SudarshanK, TravisS, RickS
Yesterday, we went to Xend to assess and optimize the Pcal beam locations on the ETM surface.
Since O1, we have known that the beams were clipping somewhere on the receiving side.
Unsing an updated method of assessing the beam locations that is based on the work that Miranda Chen (REU student from UTRGV) did this summer (basically using the ESD electrode pattern rather than the edge of the ETM) we found that the Pcal beams were quite far from their optimum locaitons (see first image attached below). The offests from the optimal locations (111.6 mm above and below the center of the face of the optic) were U [ 1.71, 12.27], L[10.02, -7.27] where U and L denote the upper and lower Pcal beams and the coordinates are [x offset, y offset] in millimeters with the usual conventions, positive x to the right, positive y up. Because we use 2" diameter optics in the Pcal periscope structure and because the receiveing-side mirrors are twice the distantance from the ETM, an offset of 12 mm at the ETM would correspond to an offset of ~24 mm at the periscope, likely the cause of the clipping we have observed. The reflected power measured by the power sensor in the receiver module increased by about 50% from about 4 V to 6.2 V.
We adjusted the beam locations using the steering mirrors in the Pcal transmitter module and ended up with positions that are within a mm of the optimal locations (see second image attached below): U [ 0.15, 0.43], L[-0.18, 0.05].
The third image below shows the Pcal spots on the ETM surface (inside green circles), visible when the chamber illuminator is off.
We are in the process of modeling the expected calibration errors resulting from bulk elastic deformation induced by the Pcal forces being so far from the optimal locations, but we expect errors as large as 20-40% at frequencies above 4 kHz for offsets as large as what we had before correcting the positions yesterday.
Attached is a plot that shows the expected calibration error at higher frequencies due to the effect of bulk elastic deformation of the test mass. The estimated error is calculated using the COMSOL modeling (worked on by Nicola and Shivaraj this summer) for the pcal beam configuration prior to moving the beam (LHOX_ER9). This is the same configuration in which we were running the the high frequency calibration lines during ER9 and even during O1 (there is no reason to believe the beam positions have changed appreciably since O1). The measurement data plotted alongside are the high frequency calibration lines run during the end of O1 and described in LHO alog 26275. The data is normalized to the model at 1 KHz and agrees closely to the model at frequencies above it. The beams are now moved to their optimal position as described above. The model shows smaller error (plotted in cyan) due to bulk elastic deformation for this optimal configuration (LHOX_ER10). Similar measurement will be done during and before ER10 in order to confirm the model.
Note that the movement of the beam on the ETM, per quarter turn on the adjustment knobs of the mirror mounts in the tramsmitter module, is about 10 mm (judging by what we experienced yesterday).
If one works out the numbers using the 100 TPI actuators in the mount and the 1.5" between the actuator and the pivot point, the result is about 12 mm per quarter turn, assuming the mirror is about 7 m from the mount. It might be closer to 8 meters given the distance from the mirror mount to the periscope and the path in the periscope (larter for the lower - outside - beam).
11am local 28 sec. to overfill CP3 with 1/2 turn open on bypass LLCV (bypass exhaust valve remains open) Next fill due Fri.
It looks like the code restarts yesterday made BRSX upset. Right now, the DRIFTMON channel is swinging about 10k counts, p2p. Krishna suggests "several thousand" is too high for the damper to be useable. It sounds like I'll need to re-center the table, after the BRS has settled down some. We'll keep monitoring, but for now the SEI_CONF manager needs to be left in a state that doesn't use BRSX, currently in WINDY_NOBRSX, though VERY_WINDY and some of the earthquake states will work as well. TJ has confirmed that with the BRSX_STAT node in error, SEI_CONF will not complete a transition to a state that uses the BRSX, but a code restart or INITing SEI_CONF could get around that.
Attached trend shows that trouble started around 18:30 UTC yesterday, which I think is about the time we did several restarts of the BRSX Beckhoff.
Attached is the OLTF in two configurations with 7dB VGA gain.
50W (actually 48W), AC coupling OFF, and boost ON (solid line)
50W (actually 48W), AC coupling ON, boost OFF (dashed).
UGF is about 9kHz with phase margin of 40 deg or so (boost ON) or 50 (boost OFF).
Boost buys us about 9dB more gain at 1kHz.
I asked Kiwamu to do an analog measurement up to higher frequency on the floor.
Here is a transfer fucntion with SR785 to check the high frequency portion.
Also, the attached zip contains the data, plot script, and figure.
Taking this data I looked at modifications to the ISS board to increase its bandwidth. The attached plot shows:
Adding the 20kHz zero is a no brainer, since it only requires to limit the dominant pole in the circuit. It improves the phase margin over the measured curve and allows the ugf up to move to 20kHz. This will increase the ISS gain by 2 at 1kHz. The increased ugf and phase margin will in turn allow us to move the knee of the boost higher with the option to add a second boost. The later two solutions will add another gain of 2 at 1kHz.
We engage the ISS boost twice today in low noise, and did not see any impact on the DARM noise. We expected an improvement at 1 kHz at least. Attached are before and after spectra of the in and out of loop diodes (at least that's what I think the new cahnnel names mean). If it is correct that INNER means in loop and outer means out of loop, we are sensor noise limited at 100 Hz with the boost on.
J. Kissel, K. Izumi Kiwamu and I sat down again this morning to review the suspected sign error in the L3 / TST / ESD path in the calibrated output (see LHO aLOG 29860). He's convinced me -- just like what had happened in July (LHO aLOG 28396) -- after the most recent flip of the ETMY L3 ESD bias sign (LHO aLOG 29397), although I had accounted for all of the digital changes in the L3 path, I did not change the replica of the actual to reflect the real actuation strength sign flip. Several decisions have been made so as to prevent this problem in the future: (1) We've decided against changing anything in the CAL-CS front-end calibration for future ESD bias sign flips. In the real ETMY L3 path, when the ESD bias sign is flipped, it changes the sign of the real-world ESD actuation. As such we compensate that change by changing the sign of the gain in the L3_DRIVEALIGN_L filter bank. In doing so, that means there's no change in the overall LSC super-actuator transfer function. Because there is no change in the overall transfer function, we therefore do not need to change the replica of the path in CAL-CS. In the past, we've changed the CAL-CS replica to save our sanity aesthetically -- such that, for example, we can look at the DRIVEALIGN matrix gain in both the actual ETMY SUS and in CAL-CS and they match. But if one does so, one MUST change the sign of the real ESD (H1:CAL-CS_DARM_ANALOG_ETMY_L3_GAIN). This is what was not done in July, nor was it done in late August, because there's no digital equivalent in the control system to remind me. In light of us (well, me) failing to keep this replica path correct, forgetting to code up a setting change here or there every time, we find the cons of keeping things aesthetically the same out-weighing the pros. We will no longer touch the CAL-CS calibration settings when we flip the bias sign in the future. (2) We've removed all CAL-CS changes from the ISC_LOCK guardian. While assessment and control system compensation for the bias flip still live in the ISC_LOCK and SUS_PI guardians, we've removed all modification to CAL-CS settings from the ISC_LOCK guardian. We've remove execution of these steps by commenting out the relevant lines in the ISC_LOCK guardian: # Check for BIAS flip on ETMY # Note that SUS_PI guardian also is affected by ETMX Bias Flipping. # There are checks and appropriate actions in there too. -Kissel, Hardwick 08/31/2016 if ezca['SUS-ETMY_L3_LOCK_INBIAS'] < 0: # ezca['SUS-ETMY_L3_ESDOUTF_UL_GAIN'] = +1 # Commented out after finding that compensating for the # ezca['SUS-ETMY_L3_ESDOUTF_LL_GAIN'] = +1 # Bias flip down stream of the linearization just does # ezca['SUS-ETMY_L3_ESDOUTF_UR_GAIN'] = +1 # not work. # ezca['SUS-ETMY_L3_ESDOUTF_LR_GAIN'] = +1 ezca['SUS-ETMY_L3_DRIVEALIGN_L2L_GAIN'] = -30.0 ezca['SUS-ETMY_L3_ESDOUTF_LIN_FORCE_COEFF'] = -124518.4 # ezca['CAL-CS_DARM_FE_ETMY_L3_DRIVEALIGN_L2L_GAIN'] = -30.0 # Commented out after second occurrence # ezca['CAL-CS_DARM_FE_ETMY_L3_ESDOUTF_UL_GAIN'] = +1 # of overall sign error in L3 path of # ezca['CAL-CS_DARM_FE_ETMY_L3_ESDOUTF_LIN_FORCE_COEFF'] = -124518.4 # CAL-CS. LHO aLOG 29868. # ezca['CAL-CS_DARM_ANALOG_ETMY_L3_GAIN']= -1 else: # flip everything. # ezca['SUS-ETMY_L3_ESDOUTF_UL_GAIN'] = +1 # Commented out after finding that compensating for the # ezca['SUS-ETMY_L3_ESDOUTF_LL_GAIN'] = +1 # Bias flip down stream of the linearization just does # ezca['SUS-ETMY_L3_ESDOUTF_UR_GAIN'] = +1 # not work. LHO aLOG 29397. # ezca['SUS-ETMY_L3_ESDOUTF_LR_GAIN'] = +1 ezca['SUS-ETMY_L3_DRIVEALIGN_L2L_GAIN'] = +30.0 ezca['SUS-ETMY_L3_ESDOUTF_LIN_FORCE_COEFF'] = +124518.4 # ezca['CAL-CS_DARM_FE_ETMY_L3_DRIVEALIGN_L2L_GAIN'] = +30.0 # Commented out after second occurrence # ezca['CAL-CS_DARM_FE_ETMY_L3_ESDOUTF_UL_GAIN'] = +1 # of overall sign error in L3 path of # ezca['CAL-CS_DARM_FE_ETMY_L3_ESDOUTF_LIN_FORCE_COEFF'] = +124518.4 # CAL-CS. LHO aLOG 29868. # ezca['CAL-CS_DARM_ANALOG_ETMY_L3_GAIN']= +1 ezca['SUS-ETMY_L3_LOCK_BIAS_GAIN'] = 1 Attached is a screen shot of the relevant MEDM screens to aide discussion.
SEI - BRSX is severly rung up since last night. Team is working on it.
SUS - Nothing to report
CDS ELT - Everything seems ok
VAC - only 1 PT140 now. CP4 exhaust flow measurements being done today. New vacuum gui
PSL - Nothing to report
FAC - FRS maintenance
COMMISH - intensity stabilization is working as intended
Also, IMC guardian is in ISS_ON.
| 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.
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.
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 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.
Modified COSGAIN to match SINGAIN.
