We have tinj running again at LHO. We are going to test scheduling injections again.
I think it's possible that we're closer to the Newtonian gravitational noise limit than I had thought. This is on the list of "things we knew were coming, but are perhaps here sooner than I thought they would be".
The punch line is that we may be limited by Newtonian noise between 16-20 Hz. Not a wide band, but reasonably consistent with the expectations from papers such as P1200017.
In the attached plot, the blue trace is the calibrated DARM spectrum (CAL-DELTAL_EXTERNAL_DQ) that we show on the wall, taken yesterday. The green trace is my estimate of the Newtonian noise.
For the Newtonian noise, I have taken the Z-axis STS-2 seismometer data from the sensors on the ground near each test mass. (There is one seismometer at each end station, and one in the vertex near the ITMs - I use the same seismometer data for each ITM). The seismometers are in velocity units (I believe Jim said it's nm/s), so I pwelch to get velocity/rtHz, then apply the calibration zpk([],0, 1.6e-10) to get to meters/rtHz. I then translate to acceleration due to Newtonian noise using eq 1 from T1100237. Finaly, I add the 4 acceleration contributions (one from each test mass) incoherently and get to displacement by dividing the spectrum by (2*pi*f)^2.
The Newtonian noise is touching the DARM spectrum between about 16 - 20 Hz. We're within about an order of magnitude in the band 10 - 30 Hz. Evan will shortly re-run his noise budget code using this "measured" Newtonian noise to see if it helps explain some of the discrepancy between the measured and expected DARM spectra (this spectra is higher than the GWINC curve that is currently used in the noise budget).
Notably, this estimate of seismically-induced Newtonian noise is somewhat larger than what we've quoted in P1200017 and T1100237. If I use only the ETMY spectrum as an estimate for all 4 test masses, I get an answer more consistent with our past estimates. However, using the actual seismic signals from each test mass, I'm getting this slightly higher estimate.
The script to generate this plot is attached, as is the exported-from-DTT text file of the calibrated DARM spectrum.
Adding SEI tag, so people see it.
Is the STS signal calibrated correctly above 30 Hz or are you just assuming its a flat velocity sensor?
If its really close, you should be able to add the seismic data streams with the right signs and then take the coherence between this pseudo-channel and DARM and see something more than we expect by just the seismic model estimates.
Hmmm, good point Rana. I should have thought of that - it looks like the STS calibration doesn't compensate for the roll-off, so I'll put that in, and redo the traces.
Jenne, The estimate you're getting in the 15-20 Hz region is an order of magnitude or more higher than the estimate made by Jan Harms for L1, found in T1500284.
Can you post the ground noise spectra you are using so we can compare with what Jan used for L1?
The originally posted NN estimate spectra is totally wrong. I forgot to take the sqrt of the seismic spectra after pwelching, before calibrating to meters.
This corrected plot is much more consistent with Jan's estimates from T1500284.
EDIT, 3:15pm: Calibration was missing a factor of 2*pi. Plot has been updated.
Great. I like consistent results. Another remark; seismic displacement measured at a test mass has vanishing correlation with its NN. This is true at least for seismic surface fields. So if you want to proceed with correlation measurements, then the pseudo-channel needs to be constructed from an array of seismometers, with non of these seismometers being located at the test mass.
Here I include a version of the Newtonian noise estimate plot, with the GWINC estimate of aLIGO's sensitivity, in addition to the current LHO sensitivity.
The trace "GWINC with NN term" is just the regular output of Gwinc, assuming no Newtonian noise cancellation. The trace "GWINC no NN term" is all terms in gwinc except for the Newtonian noise. In particular, recall that the Gwinc NN term is not identical to the NN estimate I plot here.
The point here is to show that, although at our current sensitivity we are not limited by Newtonian noise, if we can eliminate the LSC and ASC control noise terms from our latest noise budget (aLog 21162), we likely will be.
EDIT: a further version of this plot now includes the GWINC NN curve.
JeffreyK, SudarshanK, DarkhanT,
We compared DARM model for ER8, O1 with canonical DARM loop TF measurement and DARM loop measurement from Sep 23 (LHO alog 21868). The purpose of this analysis is to see if DARM OLG TF changed from Sep 10 (canonical parameter set for O1) till Sep 23, and to see how DARM time-varying parameters were estimated by kappa correction factors. The comparison show that the overall DARM OLG TF difference between two measurements is ~ 1% in magnitude and < 1 deg.
κtst and κC corrected O1 models* resulted in:
*kappas were informed by cal. lines within 2 hours from both of the TF measurements (Sep 10 and Sep 23)
On calibration telecon we discussed that we could possibly accout for systemtic phase discrepancy in O1 model by applying time advance in actuation and sensing functions.
Earlier, after resolving some of the O1 DARM model issues we did a similar analysis that did not include Sep 23 measurement results, for details on analysis see LHO alog 21827.
The script that compares the models was committed to calibration SVN:
CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/DARMOLGTFs/CompareDARMOLGTFs_O1.m (r1533)
TITLE: Sept 24, 15:00-23:00UTC, 8:00-16:00PT
STATE Of H1: Observe, Range = 77Mpc, locked 3 hours, Observe 1 hour
SUPPORT: Hugh, Sheila
SHIFT SUMMARY:
IFO locked as soon as ground motion decreased, however, another four earthquakes of magnitude 4+ arrived, and full lock in Low Noise took the first 4 hours of the shift.
Currently IFO is in Observe and injections are planned.
INCOMING OPERATOR: JimW
ACTIVITY LOG:
Earlier activity details logged in alogs 21900, 21894, 21893, and 21888.
15:00UTC - start of shift, IFO was aligned by Corey, locked with his alignment, only tweak I made was to ETMY TMS
15:47:12UTC - ground motion just coming down enough to relock, first DRMI lock since the earthquake in Canada
16:09:36UTC - IFO made it to Bounce Violin Mode Damping
16:19:37UTC - IFO unlocked
18:04:31UTC - IFO ready to lock, and this starts the locking sequence that resulted in the IFO going to Low Noise
18:55:04UTC - IFO in Low Noise
18:58:57UTC - IFO in Observe
19:26UTC - 12:26PT, truck at receiving
19:37:35UTC - Commissioning , Praxair on site, other activities
19:44UTC - Richard, Filiberto, Mid-Y
19:45:55UTC - engaged FM2 on DHARD_Y, Sheila's filter
21:43:53UTC - IFO back to Observe, lock has been continuous since 18:58:57UTC
23:00:00UTC - end of shift, plans being made for injections
CURRENT ToDo List, when not locked:
- reload Guardian on SR2. It is showing a filter change on it's Guardian, which does NOT prevent Observe mode, but indicates that Guardian needs to be reloaded, which should clear this up.
BTL logged some details about the Rogue Excitation Problem we suffer with HAM5 ISI. The solution to this problem is fixing the coil driver monitor or unwiring this signal from the model. We might get approve to fix this in one way or the other but until then... We have to recover.
If you look at the model image Brian includes, you can see or not and I'll tell you anyway, if the Masterswitch is opened or the WD is fully (state4) tripped for more than 3 seconds, the Rogue Exc alarm will go off (because of the perceived excess voltage.) This is why it always goes into Rogue alarm everytime the WD trips. Also why it is a problem when we have opened the master switch.
So to untrip the platform, you have to untrip the watchdog, and untrip the rogue trip within 3 seconds. If you manage to do this fast enough which isn't that bad, and the guardian wasn't the one to close the masterswitch, you could end up with an SPM diff showing on the guardian for HAM5 SEI. Not that this is a big deal as we aren't keying on SPM and yes we could unmonitor the SEI but I like the monitoring.
So if the ISI is tripped:
1) check that the MASTER SWITCH is closed,
2) On the Watchdog page Click RESET ALL Rogue Exc WD RESET, and RESET ALL again, all within a couple seconds.
If it trips again, check the MASTERSWITCH, if it is open, it may be the Guardian, make sure the Guardian is set to Isolated and try the RESETs again.
Until we do the main fixes in line one, if these steps don't work, call me anytime.
If you end up with SPM diffs, and you care, you may be in for a platform cycle to OFFLINE (includes HEPI) so that the GUARDIAN closes the MASTERSWITCH.
Once OFFLINE (MASTERSWITCHs open,) set the guardina to isolated and do the above RESET dance. I'm crossing my fingers so be patient.
A tour group was on site early this afternoon. Arrival time at LSB = ~12:30 PM. Departure time = ~3:00 PM. Group size = ~20 adults. Vehicles at the LSB = ~10 passenger cars. The group walked the site near the corner station and visited the control room between 1:30 and 3:00 PM.
Adam, Chris We are beginning to test coherent hardware injection with tinj. Will update this aLog with schedule as they happen.
1127167840 1 0.5 coherenttest1_1126257410 EDIT: Cancelled, do not have permission to upload to CBC group on GraceDB.
Cancelled the last scheduled injection. Cannot upload events to gracedb.
1127168901 1 0.5 coherenttest1_1126257410
The last injection did not go in at LHO. tinj had stopped eariler. At LLO the wrong schedule was updated. See ALog entry We are stopping with the tests.
Commissioning from 19:37:35UTC to 21:43:53UTC.
DHARD_Y FM2 turned off at the end of Commissioning.
During the commissioning period that just ended, there was:
- Praxair at EX
- light equipment moved from OSB receiving to MY (pickup truck)
- equipment moved from VPW receiving to MY (pickup truck)
- EX pcal switches changed, and backed out
- DHARD_Y FM2 engaged and disengaged
- ETMX Diag_Reset to clear another timing error that showed up today
19:26UTC - 12:26PT, truck at receiving
19:37:35UTC - Commissioning , Praxair on site
Praxair takes about 2.5 hours, so expect to be in Commissioning until about 22:15UTC.
There is a second Praxair truck expected today as well.
19:44UTC - Richard, Filiberto, Mid-Y
19:45:55UTC - engaged FM2 on DHARD_Y, Sheila's filter
- heard the rumbling of the truck in the CR, and saw the range drop to 55Mpc just before engaging the filter
- apparently the truck had to turn around and go to the Y arm, which is the rumbling I heard
TITLE: IFO returns to Observe after multiple large earthquakes over the last 4 hours.
ASSISTANCE: Hugh (HAM5 SEI clearing all Guardian issues), Sheila (bounce-roll mode damping)
TIMELINE:
15:00UTC - start of shift, high ground motion
- SYS_DIAG telling me ISS defracted power is too high - I reduce the slider. Defracted power was 12 and went to 9.
15:47:12UTC - ground motion just coming down enough to relock, first DRMI lock since the earthquake in Canada
16:09:36UTC - IFO made it to Bounce Violin Mode Damping
16:19:37UTC - IFO unlocked
- A couple more DRIM locks that didn't survive.
- Four more 5-6 magnitude earthquakes come in and prevent locking.
18:04:31UTC - IFO ready to lock, and this starts the locking sequence that resulted in the IFO going to Low Noise
- Longer than usual time from ready to Low Noise, and one reason was that the roll mode on ITMY was about 4, so with Sheila's help I started the damping of the roll mode manually, and waiting for it to improved = 20 minutes
18:55:04UTC - IFO in Low Noise
18:58:57UTC - IFO in Observe
All buildings are beginning to respond to the lower outdoor temperatures so Bubba and I have turned on heaters in both end stations and the LVEA.
One stage of HC5 is now on in the LVEA. This will impact the input chambers the most. The response appears to be ~0.5 F.
The End stations have variac control so these have been incremented from 4ma(off) up 8.5ma
Video0's striptools have been modified, and now they have a red background, due to the channels DHARD_Y and DHARD_P.
When making a change to a screen, it's important to test it in all situations. Maybe this addition worked quite well during our long lock, but right now with earthquakes and relocking, the change to the striptools have rendered them unusable.
FOM image attached.
This is a symptom of a rung up roll mode. Cheryl spent the last few minutes damping it (ITMY) and now these displays are back to looking normal.
J. Kissel I've taken new DARM open loop gain and PCALY to DARM transfer functions to validate the current calibration. During the PCALY to DARM transfer function, I take the transfer function from PCALY's RX PD (calibrated into [m] of ETMY motion) and the CAL-CS front-end's DELTAL_EXTERNAL (calibrated into DARM [m], which -- since we're driving ETMY -- is identical to [m] of ETMY motion). These two different methods agree to within 4% and 3 [deg] over the 15 [Hz] to 1.2 [kHz] band. The calibration discrepancy expands to a whopping 9% and 4 [deg] if we look a frequencies between 5 and 15 [Hz] ;-). I think we're in great shape, boys and girls. Details -------------- - CAL-CS does not correct for any slow time depedence (optical gain, test mass actuation strength, etc), so any agreement you see with the current interferometer is agreement with the reference model taken on Sep 10th 2015 (LHO aLOG 21385). - In the previous measurement, Kiwamu had to fudge the phase by ~90 [us] to get the phase to agree. Now that we've updated the cycle delay between sensing and actuation to 7 [16 kHz clock cycles] to better approximate the high-frequency frequency response of AA, AI, and the OMC DCPD signal chain, we no longer have to fudge the phase -- AND the phase between the two metrics agree. NICE. - I've made sure to turn OFF calibration lines *during both of these measurements, but there should be ample data just before and just after with calibration lines ON, such that we can compare our results against theirs to help refine our estimates of systematic error. - The measurements live in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/DARMOLGTFs/2015-09-23_H1_DARM_OLGTF_7to1200Hz.xml /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Measurements/PCAL$/2015-09-23_PCALY2DARMTF_7to1200Hz.xml and have been committed to the CalSVN. We'll process these results shortly, and perform a similar analysis as Darkhan has done in yesterday's aLOG 21827.
The parameter file for this measurement was committed to calibration SVN:
CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/DARMOLGTFs/H1DARMparams_1127083151.m
Attached plots show components of DARM loop TF and their residuals vs. DARM model for O1.
It looks better. Very nice.
By the way, I wanted to measure the open loop without the MICH or SRCL feedforward because I wanted to demonstrate that the unknown shape in the residual in magnitude is not due to these feedforward corrections. Though this may be a crazy thought. Anyway, it would be great if you can run an open-loop measurement without the feedforwards at some point, just once.
L1 went out of lock. At H1 we turned off the intent bit and injected some hardware injections. The hardware injections were the same waveform that was injected on September 21. For more information about those injections see aLog entry 21759 For information about the waveform see aLog entry 21774. tinj was not used to do the injections.The commands to do the injections were: awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 0.5 -d -d >> log2.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt ezcawrite H1:CAL-INJ_TINJ_TYPE 1 awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 H1-HWINJ_CBC-1126257410-12.txt 1.0 -d -d >> log2.txt To my chagrin the first two injections were labeled as burst injections. Taken from the awgstream log the corresponding times are approximates of the injection time: 1127074640.002463000 1127074773.002417000 1127075235.002141000 1127075742.002100000 The expected SNR of the injection is ~18 without any scaling factor. I've attached omegascans of the injections. There is no sign of the "pre-glitch" that was seen on September 21.
Attached stdout of command line.
Neat! looks good.
Hi Chris, It looks like there is a 1s offset between the times you report and the rough coalescence time of the signal. Do you know if it is exactly 1s difference?
Yes, as John said, all of the end times of the waveforms are just about 1 second later that what's in the original post. I ran a version my simple bandpass-filtered overlay script for these waveforms. Filtering both the model (strain waveform injected into the system) and the data from 70-260 Hz, it overlays them, and also does a crude (non-optimal) matched filter to estimate the relative amplitude and time offset. The four plots attached are for the four injected signals; note that the first one was injected with a scale factor of 0.5 and is not "reconstructed" by my code very accurately. The others actually look rather good, with reasonably consistent amplitudes and time delays. Note that the sign of the signal came out correctly!
I ran the daily BBH search with the injected template on the last two injections (1127075235 and 1127075742). For 1127075235; the recovered end time was 1127075235.986, the SNR was 20.42, the chi-squared was 29.17, and the newSNR was 19.19. For 1127075242; the recovered end time was 1127075242.986, the SNR was 20.04, the chi-squared was 35.07, and the newSNR was 19.19.
KW sees all the injections with the +1 sec delay, some of them in multiple frequency bands.
From
/gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074624-64.trg
/gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074752-64.trg
/gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075200-64.trg
/gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075712-64.trg
tcent fcent significance channel
1127074640.979948 146 26.34 H1_GDS-CALIB_STRAIN_32_2048
1127074774.015977 119 41.17 H1_GDS-CALIB_STRAIN_8_128
1127074773.978134 165 104.42 H1_GDS-CALIB_STRAIN_32_2048
1127075235.980545 199 136.82 H1_GDS-CALIB_STRAIN_32_2048
1127075743.018279 102 74.87 H1_GDS-CALIB_STRAIN_8_128
1127075742.982020 162 113.65 H1_GDS-CALIB_STRAIN_32_2048
Omicron also sees them with the same delay
From :
/home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074621-30.xml
/home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074771-30.xml
/home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075221-30.xml
/home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075731-30.xml
peak time fcent snr
1127074640.977539062 88.77163 6.3716
1127074773.983397960 648.78342 11.41002 <- surprisingly high fcent, could be due to clustering
1127075235.981445074 181.39816 13.09279
1127075742.983397960 181.39816 12.39437
LIB single-IFO jobs also found all the events. Post-proc pages can be found here:
https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074640.98-0/H1L1/H1/posplots.html
https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074773.98-1/H1L1/H1/posplots.html
https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075235.98-2/H1L1/H1/posplots.html
https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075742.98-3/H1L1/H1/posplots.html
all runs appear to have reasonable posteriors.
Here is how Omicron detects these injections: https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074641/ https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074774/ https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075236/ https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075743/ Here are the parameters measured by Omicron (loudest tile): 1127074640: t=1127074640.981, f=119.9 Hz, SNR=6.7 1127074773: t=1127074773.981, f=135.3 Hz, SNR=11.8 1127075235: t=1127075235.981, f=114.9 Hz, SNR=12.8 1127075742: t=1127075742.981, f=135.3 Hz, SNR=12.4
The BayesWave single IFO (glitch only) analysis recovers these injections with the following SNRs: 4640: 8.65535 4773: 19.2185 5253: 20.5258 5742: 20.1666 The results are posted here: https://ldas-jobs.ligo.caltech.edu/~meg.millhouse/O1/CBC_hwinj/
Elli and Stefan showed in aLOG 20827 that the signals measured by AS 36 WFS for SRM and BS alignment appeared to be strongly dependent on the power circulating in the interferometer. This was apparently not seen to be the case in L1. As a result, I've been looking at the AS 36 sensing with a Finesse model (L1300231), to see if this variability is reproducible in simulation, and also to see what other IFO variables can affect this variability.
In the past when looking for differences between L1 and H1 length sensing (for the SRC in particular), the mode matching of the SRC has come up as a likely candidate. This is mainly because of the relatively large uncertainties in the SR3 mirror RoC combined with the strong dependence of the SRC mode on the SR3 RoC. I thought this would therefore be a good place to start when looking at the alignment sensors at the AS port. I don't expect the SR3 RoC to be very dependent on IFO power, but having a larger SR3 RoC offset (or one in a particular direction) may increase the dependence of the AS WFS signals on the ITM thermal lenses (which are the main IFO variables we typically expect to change with IFO power). This might therefore explain why H1 sees a bigger change in the ASC signals than L1 as the IFOs heat up.
My first step was to observe the change in AS 36 WFS signals as a function of SR3 RoC. The results for the two DOFs shown in aLOG 20827 (MICH = BS, SRC2 = SRM) are shown in the attached plots. I did not spend much time adjusting Gouy phases or demod phases at the WFS in order to match the experiment, but I did make sure that the Gouy phase difference between WFSA and WFSB was 90deg at the nominal SR3 RoC. In the attached plots we can see that the AS 36 WFS signals are definitely changing with SR3 RoC, in some cases even changing sign (e.g. SRM Yaw to ASA36I/Q and SRM Pitch to ASA36I/Q). It's difficult at this stage to compare very closely with the experimental data shown in aLOG 20827, but at least we can say that from model it's not unexpected that these ASC sensing matrix elements are changing with some IFO mode mismatches. The same plots are available for all alignment DOFs, but that's 22 in total so I'm sparing you all the ones which weren't measured during IFO warm up.
The next step will be to look at the dependence of the same ASC matrix elements on common ITM thermal lens values, for a few different SR3 RoC offsets. This is where we might be able to see something that explains the difference between L1 and H1 in this respect. (Of course, there may be other effects which contribute here, such as differential ITM lensing, spot position offsets on the WFS, drifting of uncontrolled DOFs when the IFO heats up... but we have to start somewhere).
Can you add a plot of the amplitude and phase of 36MHz signal that is common to all four quadrants when there's no misalignment?
As requested, here are plots of the 36MHz signal that is common to all quadrants at the ASWFSA and ASWFSB locations in the simulation. I also checked whether the "sidebands on sidebands" from the series modulation at the EOM had any influence on the signal that shows up here: apparently it does not make a difference beyond the ~100ppm level.
At Daniel's suggestion, I adjusted the overall WFS phases so that the 36MHz bias signal shows up only in the I-phase channels. This was done just by adding the phase shown in the plots in the previous comment to both I and Q detectors in the simulation. I've attached the ASWFS sensing matrix elements for MICH (BS) and SRC2 (SRM) again here with the new demod phase basis.
**EDIT** When I reran the code to output the sensitivities to WFS spot position (see below) I also output the MICH (BS) and SRC2 (SRM) DOFs again, as well as all the other ASC DOFs. Motivated by some discussion with Keita about why PIT and YAW looked so different, I checked again how different they were. In the outputs from the re-run, PIT and YAW don't look so different now (see attached files with "phased" suffix, now also including SRC1 (SR2) actuation). The PIT plots are the same as previously, but the YAW plots are different to previous and now agree better with PIT plots.
I suspect that the reason for the earlier difference had something to do with the demod phases not having been adjusted from default for YAW signals, but I wasn't yet able to recreate the error. Another possibility is that I just uploaded old plots with the same names by mistake.
To clarify the point of adjusting the WFS demod phases like this, I also added four new alignment DOFs corresponding to spot position on WFSA and WFSB, in ptich and yaw directions. This was done by dithering a steering mirror in the path just before each WFS, and double demodulating at the 36MHz frequency (in I and Q) and then at the dither frequency. The attached plots show what you would expect to see: In each DOF the sensitivity to spot position is all in the I quadrature (first-order sensitivity to spot position due to the 36MHz bias). Naturally, WFSA spot position doesn't show up at WFSB and vice versa, and yaw position doesn't show up in the WFS pitch signal and vice versa.
For completeness, the yaxis is in units of W/rad tilt of the steering mirror that is being dithered. For WFSA the steering mirror is 0.1m from the WFSA location, and for WFSB the steering mirror is 0.2878m from the WFSB location. We can convert the axes to W/mm spot position or similar from this information, or into W/beam_radius using the fact that the beam spot sizes are at 567µm at WFSA and 146µm at WFSB.
As shown above the 36MHz WFS are sensitive in one quadrature to spot position, due to the constant presence of a 36MHz signal at the WFS. This fact, combined with the possibility of poor spot centering on the WFS due to the effects of "junk" carrier light, is a potential cause of badness in the 36MHz AS WFS loops. Daniel and Keita were interested to know if the spot centering could be improved by using some kind of RF QPD that balances either the 18MHz (or 90MHz) RF signals between quadrants to effectively center the 9MHz (or 45MHz) sideband field, instead of the time averaged sum of all fields (DC centering) that is sensitive to junk carrier light. In Daniel's words, you can think of this as kind of an "RF optical lever".
This brought up the question of which sideband field's spot postion at the WFS changes most when either the BS, SR2 or SRM are actuated.
To answer that question, I:
Some observations from the plots:
I looked again at some of the 2f WFS signals, this time with a linear sweep over alignment offsets rather than a dither transfer function. I attached the results here, with detectors being phased to have the constant signal always in I quadrature. As noted before by Daniel, AS18Q looks like a good signal for MICH sensing, as it is pretty insensitive to beam spot position on the WFS. Since I was looking at larger alignment offsets, I included higher-order modes up to order 6 in the calculation, and all length DOFs were locked. This was for zero SR3 RoC offset, so mode matching is optimal.
Folks have been complaining that the HAM5-ISI Rogue Excitation monitor is a pain. (see e.g. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=21474) It looks like the coil-voltage-readback monitor for the V2 coil is busted somewhere, and so the monitor is sitting around -500 counts all the time. Hugh gave me the GPS time for a recent earthquake, and in the attached plot you can see the watchdog trip from normal (state 1) to damp-down (state 2) at T+3 seconds. The coil voltages come down pretty quickly. Then the WD goes to state 4 (full trip) about 3 seconds later and the coil drive monitors (except V2) get quite small. The rogue excitation alarm goes off about 3 seconds after that, because the V2 monitor has not fallen to abs(Vmon) < +100 counts. The V2 monitor just sort of sits at ~-500 counts all the time. I'm pretty sure the V2 coil drive is working, otherwise the HAM5-ISI platform would act very poorly. I'm guessing the problem is somewhere in the readback chain. Note - the channels I use for this are all Epics channels, so the timing is a bit crude and the voltages are sort of jumpy. The channels are: H1:ISI-HAM5_ERRMON_ROGUE_EXC_ALARM H1:ISI-HAM5_CDMON_H1_V_INMON H1:ISI-HAM5_CDMON_H2_V_INMON H1:ISI-HAM5_CDMON_H3_V_INMON H1:ISI-HAM5_CDMON_V1_V_INMON H1:ISI-HAM5_CDMON_V2_V_INMON H1:ISI-HAM5_CDMON_V3_V_INMON H1:ISI-HAM5_WD_MON_STATE_INMON I've also attached screenshots of the "coil drive voltage too big" calculation and the "rogue excitation alarm generation" calculation from the HAM-ISI master model
I've added integration issue 1127 on this https://services.ligo-wa.caltech.edu/integrationissues/show_bug.cgi?id=1127
I think I've got all the colors sorted out and pretty sure it looks like H2 Monitor isn't working either. At first I thought it was just zero on the plot but I don't think so. At least it won't cause this problem and being H2 may help find the problem.