H1:ISC-RF_C_SQZAOM200M_OUTPUTMON correlates with range drops even on sub-second time scales.
Attached are plots for GPS
1256913467 (same drop as in alog 52979)
1257226318 (today)
1257229296 (today)
Note that the sharp drop in 1256913467 corresponds down to the second with the range drop in alog 52979.
H1:ISC-RF_C_SQZAOM200M_OUTPUTMON used to monitor the RF power level of the RF amplifier that drives the first AOM in the CLF path. This AOM driver has been replaced by a new AM modulated AOM driver. H1:ISC-RF_C_SQZAOM200M_OUTPUTMON is still connected to old RF amp that is now powered off. What this channel senses is very unclear.
This channel was also the most correlated result in the re-run lasso in my last comment here https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=53091 and that entry lists other channels highly correlated with this channel.
H1:IMC-MC2_TRANS_NSUM_OUT channel is calibrated in Watts for the internal power buildup. In the attached plot, I don't see excessive acoustic peaks like the ones observed at LLO before increasing the beam size on IMC WFS (LLO alog 12426) and therefore don't see the need for the change at LHO.
BRSY seems to be close to it's range.
Ed, Camilla
16:47UTC The large equpiment bearing truck that is currently parked on the road beyond the gate will unload a backhoe/frontloader and slowly drive it to the water tower area. I'll note more accurate times as this takes place for DetChar.
16:56 started moving (from frount vehicle gate)
17:04 Parked next to X arm fire tank.
Ed and Camilla
TITLE: 11/08 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 108Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 1mph Gusts, 0mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.38 μm/s
QUICK SUMMARY:
Expecting some noise later in the day when a truck moves equipment down the arms for the wind fence.
TITLE: 11/08 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 111Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY:
A couple of earthquakes caused some action in the middle of this freezing fog shift. Have a couple of Hand-Off Notes for other shifts:
1) Restarting Cal Lines: Whenever H1 loses lock, please email Aaron V. and Maddie Wade so they can restart them.
2) Squeezer Tests: Not sure there's still a call for it, but it was mentioned to try some tests to address H1 range when it drops to 110Mpc or below (see Sheila's alog here).
LOG:
Lost lock to an earthquake (sent an email to Aaron V. to restart Cal Lines at Keita's request).
Currently locking H1 & at Increase Power step currently (after about 63min ffrom lockloss).
Crossing Fingers.
12:21 H1 back to OBSERVING w/ a range hovering around 110Mpc.
Topped off Crystal Chiller with 260 mL. Diode Chiller OK. Filters look fine (slight yellow tint of Crystal filter [known item]).
TITLE: 11/08 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 111Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 2mph Gusts, 1mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.25 μm/s
useism has been trending up the last 24hrs. (one note about that is Jim mentioned we might want to take the new SEI_DIFF guardian node from nominal FULL_DIFF_CPS to DOWN to get data when we have high useism, BUT not yet...he will need to fix SDF for this and get go ahead from Keita).
QUICK SUMMARY:
H1's been in observing 10.5hrs. Have seen H1's range take a few visible steps down in last 3-4hrs (Jim mentioned alogs about Squeezer by Sheila about this). Other than that, all is well thus far.
TITLE: 11/08 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 110Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Quiet shift
LOG:
Ed had an earthquake when I came in. Not much else has happened.
I remeasured the CARM pole as we did in April. CARM pole = 0.595 +- 0.007 Hz. The method was pretty much the same as before, I just looked at the Input RIN using H1:PSL-ISS_SECONDLOOP_RIN_OUTER_OUT_DQ rather than H1:IMC-IM4_TRANS_NSUM_OUT_DQ (but these have a TF of unity, so they witness the same thing). My B channel this time was H1:LSC-POP_A_RIN_OUT_DQ, this corresponded well with using the arm transmission as B channels as well. The coherence is marginal, I fit only to points between 13 and 29 Hz. Could bias this estimate.
S. Dwyer, S. Karki
We noticed yesterday that the ADS lines running at ETMY were showing up in ETMX and eventually into the DARM (attached plot- The dither lines are at : ETMX: P= 20.131, Y= 22.347 amd ETMY: P:20.789, Y=21.9 ). We thought we could reduce this coupling by notching these ADS lines in DHARD. We tested this today by applying the notch at both the DHARD pitch and yaw. After notching the lines and opening the ADS servo loops we tried to see if we can reduce these lines in the DARM by changing the A2L gain. We tried both pitch and yaw at ETMY and didnot see any significant difference.
I multiplied the FM10 "cal" filter in H1:LSC-REFL_A_RIN and H1:LSC-REFL_B_RIN by 2.616, bringing the gain from 0.1168 to 0.3055, at Nov 08 2019, 00:44:23 UTC.
I did this because during my last intensity injection, the REFL A/Input RIN and REFL B/Input RIN TFs were not unity, equaling ~ 0.382.
After a quick chat with Daniel, the RIN chan was calibrated using the IFO at 2W, before thermal changes and RF driver sliders were changed.
I recalibrated it such that REFL {A,B}/Input RIN = 1 at full IFO with 38.1 W requested, 33.5 W incident on the PRM.
The flow rate seems to be consistent following the chiller was swap back in September (alog52208). We have not had any lost observing time due to a relocking laser, but we have had a handful of laser relocks. Two of them happened during the SRC part of initial alignment, though perhaps this just very coincident. Overall, I would say things look healthy.
Following up on work by Beverly, I ran a short Lasso run on today's range drop. The run spans 2019-11-06 02:00-07:00. Clearly very highly correlated channels are as follows:
Channel "Pearson Coefficient" 0.9799929848627831 H1:SQZ-DCPD_SUM_RMS1_MON.mean 0.9725502574463882 H1:SQZ-DCPD_RATIO_1_MON.rms 0.9312747855964804 H1:SQZ-DCPD_SUM_RMS1_MON.rms
The full page output is at https://ldas-jobs.ligo-wa.caltech.edu/~jrsmith/detchar/O3b/lasso-Nov-6-2019-2/ (updated using the fancy new python 3 version)
Figures below show:
1) The range drop from the summary pages.
2) The range and scaled SQZ DCPD channel
3) A scatter plot of range vs SQZ values
4) The other channels that are duplicate of the SQZ winner
I think not much new from what Beverly reported so far. Happy to follow up with further inquiries.
@DetChar -- these channels contain DARM / DELTAL / h(t) in them. They're BLRMS monitor channels comparing the squeezer performance (SQZ; via the NULL stream [the "difference" between OMC DCPDA and B]) against the OMC's DCPD SUM (i.e. the gravitational wave detecting photodiodes, and the DARM loop error signal). The first band (i.e. what eventually forms H1:SQZ-DCPD_SUM_RMS1_MON, and then H1:SQZ-DCPD_RATIO_1_MON), is a tight band pass around 1640 Hz -- the frequency region simply chosen to be a region we believe to be "shot/quantum noise dominated with no features." There are 4 of these BLRMS data streams, and they should probably just be considered "unsafe" as copies of the gravitational wave channels. H1:SQZ-DCPD_NULL_BP_1_INMON (**and other associated EPICs records on similar name, but with the standard filter module suffixes; OUTMON, EXCMON, OFFSET, etc.) H1:SQZ-DCPD_NULL_BP_2_INMON ** H1:SQZ-DCPD_NULL_BP_3_INMON ** H1:SQZ-DCPD_NULL_BP_4_INMON ** H1:SQZ-DCPD_NULL_LP_1_INMON ** H1:SQZ-DCPD_NULL_LP_2_INMON ** H1:SQZ-DCPD_NULL_LP_3_INMON ** H1:SQZ-DCPD_NULL_LP_4_INMON ** H1:SQZ-DCPD_NULL_RMS1_MON H1:SQZ-DCPD_NULL_RMS2_MON H1:SQZ-DCPD_NULL_RMS3_MON H1:SQZ-DCPD_NULL_RMS4_MON H1:SQZ-DCPD_RATIO_1_DB_MON H1:SQZ-DCPD_RATIO_1_MON H1:SQZ-DCPD_RATIO_2_DB_MON H1:SQZ-DCPD_RATIO_2_MON H1:SQZ-DCPD_RATIO_3_DB_MON H1:SQZ-DCPD_RATIO_3_MON H1:SQZ-DCPD_RATIO_4_DB_MON H1:SQZ-DCPD_RATIO_4_MON H1:SQZ-DCPD_SUM_BP_1_INMON ** H1:SQZ-DCPD_SUM_BP_2_INMON ** H1:SQZ-DCPD_SUM_BP_3_INMON ** H1:SQZ-DCPD_SUM_BP_4_INMON ** H1:SQZ-DCPD_SUM_LP_1_INMON ** H1:SQZ-DCPD_SUM_LP_2_INMON ** H1:SQZ-DCPD_SUM_LP_3_INMON ** H1:SQZ-DCPD_SUM_LP_4_INMON ** H1:SQZ-DCPD_SUM_RMS1_MON H1:SQZ-DCPD_SUM_RMS2_MON H1:SQZ-DCPD_SUM_RMS3_MON H1:SQZ-DCPD_SUM_RMS4_MON
Thank you very much Jeff. We have taken steps to remove all {IFO}:SQZ-DCPD_ channels for future lasso runs. However, it also occured to me that lasso was updated to by default not consider channels that don't change in the first ten minutes of its run. This is not a good way to catch changes in the middle of a segment. So I generated a full channel list by hand using:
(ligo-summary-3.7) [joshua.smith@ldas-pcdev1 lasso-Nov-6-2019-4]$ gw_data_find -o H -t H1_T -u file -s 1257040818 -e 1257040918 -n | xargs FrChannels | egrep -v "OAF-RANGE|CDS-SENSEMON|CAL-CS_DARM|SQZ-DCPD_|SUS-*TM*MODE*" | egrep ".mean|.rms" | cut -d\ -f1 > chans.txt
and ran lasso on this much longer channel list.
(ligo-summary-3.7) [joshua.smith@ldas-pcdev1 lasso-Nov-6-2019-4]$ nohup gwdetchar-lasso-correlation -i H1 -f chans.txt -T minute -a 0.2 -O 2.5 -J 16 -j 16 1257040818 1257058818 &
The results are here: https://ldas-jobs.ligo-wa.caltech.edu/~jrsmith/detchar/O3b/lasso-Nov-6-2019-4/
Conclusion: This points to H1:ISC-RF_C_SQZAOM200M_OUTPUTMON as the most highly correlated. But also has a list of channels highly correlated to that one, which I've pasted below. I am posting this hastily, as I have to run, so I am sorry, again I have not investigated these channels as a follow up yet, but I thought it could be helpful for commissioners to see the updated list.
|
Channel |
Pearson Coefficient |
|
-0.9999996566205920 |
H1:ISC-RF_C_SQZAOM200M_OUTPUTMON.mean |
|
-0.9330572847583630 |
H1:OMC-LSC_I_OUT_DQ.rms |
|
0.8875620058071610 |
H1:ASC-OMCR_B_PIT_OUT_DQ.mean |
|
0.887557437214179 |
H1:ASC-OMCR_B_MTRX_P_OUTMON.mean |
|
0.8875548329386750 |
H1:ASC-OMCR_B_PIT_OUT16.mean |
|
0.8875269357613680 |
H1:ASC-OMCR_B_PIT_INMON.mean |
|
0.8875269357613680 |
H1:ASC-OMCR_B_PIT_OUTPUT.mean |
|
-0.8867419443426080 |
H1:OMC-ASC_Y2_X_SIN_OUT16.rms |
|
-0.8818601017037520 |
H1:SYS-TIMING_C_FO_A_PORT_5_SLAVE_VCXOCTRL.mean |
|
-0.8818600988445600 |
H1:SYS-TIMING_C_FO_A_PORT_5_SLAVE_VCXOCTRL.rms |
|
-0.8750126151025700 |
H1:OMC-ASC_P1_X_COS_OUT16.rms |
|
-0.8673301041530260 |
H1:OMC-ASC_P2_X_SIN_OUT16.rms |
|
-0.8642192268464130 |
H1:ISI-BS_ST2_BLND_RZ_GS13_CUR_IN1_DQ.rms |
|
-0.8627117825481380 |
H1:OMC-ASC_Y2_X_COS_OUT16.rms |
|
-0.861022683603709 |
H1:PEM-C_SUP_RACK1_TEMPERATURE.rms |
|
-0.8610220968306960 |
H1:PEM-C_SUP_RACK1_TEMPERATURE.mean |
|
0.858408671078947 |
H1:IOP-ASC0_ADC_DT_OUT16.mean |
|
0.8573914259079220 |
H1:IOP-ASC0_ADC_DT_OUT16.rms |
|
-0.8571425309954690 |
H1:HPI-ITMY_BLRMS_VP_30M.rms |
|
-0.8571423785897070 |
H1:HPI-ITMY_BLRMS_VP_30M.mean |
|
-0.856700860825061 |
H1:OMC-ASC_Y1_X_COS_OUT16.rms |
|
-0.856420367475446 |
H1:HPI-ITMY_BLRMS_LOG_VP_30M.rms |
|
-0.8564203318837560 |
H1:HPI-ITMY_BLRMS_LOG_VP_30M.mean |
|
-0.8527525850009830 |
H1:IMC-TRANS_IN1_DQ.mean |
|
-0.8527518540230320 |
H1:IMC-TRANS_OUT_DQ.mean |
|
-0.8527496025226880 |
H1:IMC-TRANS_OUT_DQ.rms |
|
-0.8527473701532360 |
H1:IMC-TRANS_OUT16.rms |
|
-0.8527470948451950 |
H1:IMC-TRANS_OUT16.mean |
|
-0.8527326142606620 |
H1:IMC-TRANS_IN1_DQ.rms |
|
-0.8523469401317910 |
H1:OMC-ASC_P1_X_SIN_OUT16.rms |
|
-0.850131863101939 |
H1:OMC-LSC_Q_OUTPUT.rms |
|
-0.850131863101939 |
H1:OMC-LSC_Q_INMON.rms |
Nutsinee, Daniel, Sheila
We have some requests for the operators to try some tests next time the range drops to around 110Mpc. We'd ask you to try each of these tests, which you can do by copying and pasting the lines below into a terminal. Waiting 10-15 minutes between each one would make sure we what happens. If any of these appear to fix the problem (or the range goes back to normal on its own) obviously you can stop the test.
Keita has OK'd staying in observe, so before starting this go into SDF and unmonitor these channels, and remonitor them when you are done. If there is a problem with this and we are out of observing momentarily that's sort of OK, although we would like to avoid it if possible. Also, please alog carefully and include times when you do this. Thank you.
1) increase SHG gain by 20dB
2)H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG move up and down by 10 degrees, wait 10-15 minutes between moves.
3)lower CLF ISS gain
Sheila/Keita: I'm catching up on emails/alogs. Couple questions regarding this:
1) Is there a preference for when we should run these tests with regards to the other detectors? Would we want to do it when L1 is out of Observing? Or does that matter?
2) I tried to get set up to UNMONITOR some channels, but I wasn't quite able to; here are notes on the channels:
H1:SQZ-SHG_SERVO_IN1GAIN: This does not come up when I Sort On Substring for it. So does that mean SDF already does not care about it?
H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG: This channel also does not come up. There is a H1:SQZ-CLF_REFL_RF6_PHASE_D (& _R) which comes up though.
H1:SQZ-CLF_ISS_GAIN: This also does not come up. There are channels for _CTRL_GAIN & _ERR_GAIN though.
Anyway, we have been at 110Mpc for the last 8hrs spanning two different locks. If L1, breaks lock, maybe I'll give it a go, but right now they are up.
H1:SQZ-SHG_SERVO_IN1GAIN, H1:SQZ-CLF_REFL_RF6_PHASE_PHASED, and H1:SQZ-CLF_ISS_GAIN are found under H1SYSECATC1PLC4 (CS_ECAT_PLC4 button on SDF overview screen). I didn't know that that was the case, but was able to find it once I saw that these things are all analog board settings.
Settings for analog boards (common mode boards, delay line phase shifters, whitening amplifiers etc.) are typically controlled using ethercat (there are exceptions e.g. SUS BIO and some of PSL boards) so you'll find those in one of ethercat SDFs.
14:43:10 Tried CLF_ISS_GAIN to 10dB
14:48:10 Back to 16dB
14:53:30 Tried CLF_SERVO_IN2GAIN to -15dB
15:00:00 Back to -9dB
15:27:30 CLF_ISS_SERVO off
15:34:00 CLF_ISS_SERVO on
15:40:16 CLF_ISS SERVO off
15:45:16 CLF_ISS_SERVO on
No change with any of the above attempts.
Nutsinee Daniel
CLF power change
We changed the CLF power from 120µW to 55µW and it correlated with the range!
| 120µW | 55µW | |
|---|---|---|
| H1:SQZ-CLF_ISS_SETPOINT | 1.01 | 0.51 |
| H1:SQZ-CLF_ISS_GAIN | 16 | 7 |
| H1:SQZ-CLF_SERVO_IN2GAIN | –9 | –4 |
Times:
We accpeted the new settings in SDF and leave it as the new nominal over the weekend.