Kentaro, Lee, Daniel, Nutsinee

While tackling noise on high CLF power antisqueeze trace we found the source of mysterious CLF 'scatter shelves' to be the high SHG gain.

One might remember the weird looking shelves on the CLF error signal at 4kHz and 20kHz (alog46679 and alog47222).

Plot attached was taken today at 40uW transmitted CLF power, with high SHG gain being 30-31dB (~2kHz SHG transfer function UGF, see attached GIF file) and low SHG gain being 7dB (~200Hz SHG UGF). The 4kHz shelf isn't prominent here compared to the past alogs that's likely because the data was taken with relatively low CLF power, the 20kHz shelf however, is now gone. The broad peak at 5.5kHz is likely due to gain peaking as we were operating at higher CLF UGF than usual (that was not intentional, better CLF data is coming). We looked at the same comparison on Sunday with higher CLF power and saw that 4kHz shelf was eliminated (data was saved, but unretrievable).

At high SHG gain we had 35 deg phase margin on the SHG loop. We suspect the shelves were caused by SHG mechanical noise. Since then we have been operating at 7dB common gain where we no longer observe this coupling in CLF. This sadly put SHG UGF at 200Hz.  

Note that this still doesn't solve the problem with worsen squeezing at high CLF power. 

Jenne, Chiara.

As a firts test, in preparation for future simulations and measuments with PRCL during ISI differential control, we plotted traces for M1, M2, M3 and open loop gains (in attachment). This is useful to understand if/where flters need to be modified.

The second figure shows the loop diagram we think should work when insertng controbution from PRCL (red part). Two different ways are considered to connect PRCL to ISI, shown in blue and black, and not considered yet in the previous model.

While we were down for the earthquake and 50 mph winds I tweaked up the alignment of the end-y Hartmann.

I followed Aidan's handy instructions, mostly adjusting HWS M1A, and got a return beam as shown in the first attachment. There are two sets of diagonal fringes to the left and right of the beam. Previously (see second attachment for a screenshot from the instruction manual) the fringes were on the center and left of the beam, so perhaps it is still a bit miscentered in yaw? I'm not sure why, but the beam is dimmer now than it was previously.

Some notes:

• The intensity of the HWS source is so low after HWS-L1 that I needed the lights off in the VEA to view it on the card. I adjusted the angle of HWS-pol by a couple of degrees to make it a little brighter. If this is an ok thing to do maybe TJ can increase the power further during maintenance tomorrow?
• Streaming the camera image from the Hartmann computer using stream_image_HWSY didn't work for me, the image flickers in and out and is mostly blank, I don't know if this is related to the error message the camera is currently giving, which now says "ERROR: local variable \'stlist\' referen", I used the HWS live gui to take pictures, but they only update every 30 seconds which was tedious.

[Chiara, Jenne]

It's pretty windy and earthquake-y, so we took some time to measure the HAM3 to MC2 transfer function (so we don't have to do this in the morning during maintenance).

We drove at the error point of the isolation loop in X, since that is where our MC2 length offloading will inject.  We monitored MC2 both at the M1_LOCK_L_OUT and at the the M3_ISCINF_IN1 (although I should have probably taken the output of the ISCINF filter). 

We did bandpassed white noise injections, in 3 different bands, to see some coherence.  In the attached screenshot, the left plot is with the M1 stage as the monitor point, while the right is M3.  The red is coherent up to about 0.1 Hz, the green traces are coherent between about 0.2 Hz - 2 Hz, and the blue traces are coherent from about 0.5 Hz to 8 Hz.  We'll need to extract the data and stitch these together to make one single nice measurement, but then we can use this to help design our suspension length offloading.  The measurement in the left plots looks very similar to the LLO version of the measurement, reported in LLO alog 49151 (blue trace in 1st fig).
 

[Sheila, Craig, Timesh]

Cal SVN root: /ligo/svncommon/CalSVN/aligocalibration/trunk

This morning, Sheila took the usual sweep of measurements for calibration at around 15:56:49 UTC. When looking at the results from the processing sensing script, we see an antispring at f_s = 4 Hz. Attached to this alog is the raw data, the MCMC model with the measurement, the reference model with all the measurements and MCMC corner plot of this measurement.

We tried to re-measure the the Open Loop Gain (OLG) at around 01:10:13 UTC during which, the PCAL measurement ran successfully however the OLG measurement failed due to an earthquake. Before re-running the measurement we set H1:LSC-SRCL1_OFFSET from 100.0 counts to 0.0 counts. The steps in offset was to make sure that there was not a large loss of power in the arms and have the ability to quickly restore the IFO if required. The motivation for changing the offset was that in O3a, a value of 100.0 counts was used to compensate for a pro-spring (for example, see LHO alog 51440 and comment therein) and since we are measuring an anti-spring with the same counts offset, we may have been driving an anti-spring. The hypothesis is that by removing the offset, the spring would tend towards zero.

We were able to collect OLG data from 1083.7Hz down to 10.334Hz before the lockloss. This is not sufficient for re-measuring the spring/anti-spring of the IFO thus, we will attempt to repeat the OLG measurement once the IFO is back into nominal low noise (NLN) and has thermally equilibrated. The dtt files and processing scripts that were used are given below for the original measurements and the re-run measurements (svn revision given in brackets):

Measurements

Sensing:
^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml    (r8632)
^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28_H1_PCALY2DARMTF_LF_SS_5t1100Hz_10min.xml    (r8632)

^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28a_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml    (r8632)
^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28a_H1_PCALY2DARMTF_LF_SS_5t1100Hz_10min.xml    (r8632)

Actuation:
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L1_iEXC2DARM_10min.xml    (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L1_PCAL2DARM_8min.xml    (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L2_iEXC2DARM_12min.xml    (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L2_PCAL2DARM_6min.xml    (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L3_iEXC2DARM_12min.xml    (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L3_PCAL2DARM_6min.xml    (r8632)

Processing

Sensing:
Reference model: modelparams_H1_20190909
^/Runs/O3/H1/Scripts/FullIFOSensingTFs/process_sensingmeas_20191028.py    (r8636)

Actuation:
Reference model: modelparams_H1_20190416
^/Runs/O3/H1/Scripts/FullIFOSensingTFs/process_actuationmeas_20191028.py    (r8637)

I made an adjustment at the end of the day (bad idea!) which may result in PT199 drifting above the alarm threshold of 100 psi.  If so, please ignore any resulting alarm.  I am monitoring and will tweek tomorrow if required.

There are some changes to the beams on Calcite Wedge 1, seen on the analog camera.  Images attached show that the stray beam on the right side of the image was round on 30 Sept. 2019, and now has a tapered side.  Under the beam there are now vertical lines of IR light, where none were before.

The HAM2 East Door analog camera is looking at the steering mirror for the ISS Second Loop, and the back of AOE1 baffle.

In the past I've alogged that the ISS 2nd Loop steering mirror has multiple beams, alog 48801, images 6 and 8 from the left.

The first attachment show two images of the the ISS 2nd Loop steering mirror, AROM RH2, and the back of AOE1, one image with the illuminator on, so this image has both visible light and IR light (bottom), and one image with IR only (top), and in both images one can see multiple beams on the 2" steering mirror and the frame of AOE1.

The next two images show the approximate view of AROM RH2 and AOE1 from the East side of HAM2, at a much higher viewing angle than is possible with the current camera setup.

The last image shows AOE2.

AOE1 and AOE2 were originally inteded to have SiC baffle plates on both sides of the frame, however, at the time of install only 2 SiC plates were available, so the descision was to install the first plate for AOE1 and AOE2.

Created FRS 13760, and have added it to WHAM2 Issue Tracker FRS 5117.

Sheila, Patrick

Attached is a list of alignment values and their differences for Sep 27 2019 20:59:42 UTC (1253653200) and Oct 28 2019 20:39:42 UTC (1256330400). Both of these times are at NLN. The values are taken from minute trend means.

The IO Faraday Isolator Forward Rejected Beam is missing it's steering mirror, and dumping a beam on the front of AOE2 and on the frint of the IO beam dump.

In the first image, the top image is the camera view with no IR light, showing the AOE2 baffle, ROM RH11, the steering mirror for the IO faraday forward rejected beam (IO FI FRB), and the beam dump for the IO FI FRB. The bottom image is from today, H1 in NLN at 37W, showing a halo around the AOE2 aperture and a bright beam, which is part of the IO FI FRB.  Part of the IO FI FRB is hitting ROM RH11, and landing on the front of the beam dump, this means that part of the beam is also scattering from the barrel of ROM RH11.

The additional images show these components on HAM2 with IR light, and visible light, and include a diagram of where the IO FI FRB is intended to go.

There is a chance that this could be resolved with changing the alignment of IM3, however, it's equally likely that the angle of the main beam through the IO Faraday is contributing to this issue, and a combination of IM2 and IM3 may be needed to steer the FRB back into the beam dump.  It's also possible that IM1, IM2 and IM3 will need to be adjusted to steer the beam back into the beam dump and also restore the pointing of the main beam into the interferometor, as much as possible.

TITLE: 10/28 Day Shift 15:00 – 23:00 (08:00-16:00), all times posted in UTC

STATE of H1: Planned Engineering

INCOMING OPERATOR: None

SHIFT SUMMARY: Locked shortly after shift start, lost lock around 10:30. Had trouble re-locking, Sheila aligned IM3 and PR3 to increase COMM beatnote. Lost lock again about 2.5 hours later, likely due to PEM injections. Re-locking, currently at ACQUIRE_DRMI_1F.

LOG:

15:06 (08:06) Tyler driving forklift outside corner station

15:11 (08:11) Tyler finished

15:42 (08:42) Vlad to Optics Lab

16:53 (09:53) Robert, Phillipe to LVEA

16:54 (09:54) Jeff to mechanical room - check TCS chillers

16:58 (09:58) Patrick to H2 -- IO chassis testing

17:03 (10:03) Hugh to Optics Lab -- open fume hood for evaluation

17:04 (10:04) Jeff back from mechanical room

17:30 (10:30) Lockloss from NLN

17:55 (10:55) Timesh, Gavin to EX -- pick up NCAL equipment

18:04 (11:04) Richard to MX, MY -- find cable

18:24 (11:24) Timesh, Gavin back from EX

18:25 (11:25) Timesh, Gavin to Optics Lab -- drop off equipment

18:27 (11:27) Richard back from mid-stations

18:29 (11:29) Timesh, Gavin back from Optics Lab

18:56 (11:56) Patrick back from H2 building

19:17 (12:17) Robert, Dan to LVEA -- look at ISCT1

19:26 (12:26) Robert, Dan out of LVEA

19:29 (12:29) Jeff, Charles to Optics Lab -- look at chemicals

19:30 (12:30) Patrick to H2 building -- continue testing

19:46 (12:46) Patrick back from H2

19:48 (12:48) Hugh, Jeff out of Optics Lab

21:44 (14:44) Sheila, Lee to LVEA -- look for GPIB adapter near PSL racks

22:03 (15:03) Betsy to Optics Lab

22:35 (15:35) Sheila to LVEA -- clear out troublemakers

22:40 (15:40) Sheila out of LVEA

• Added 20dB of gain to the MICH ASC loops in PRMI.
• Since Jenne reported trouble with the CARM offset reduction yesterday, I tried to do the sequence the way it was before we modified it for the low recycling gain (REDUCE_CARM_OFFSET sets TR_CARM to -40, and then use the CARM 5 picometers state to calculate an offset st which we make the switch to REFL. This worked once so I've set the guardian to do it next time. 
• Injecting squeezing broke the IFO lock, this is the first time I've seen this since we switched away from the OPO reference squeezer control scheme. This lockloss is 1256308786, the attached screenshot shows that the LO loop seems to break lock and saturate in the seconds before the lockloss.  (Yesterday the squeezer fiber distribution AOM drive was changed to a fixed frequency  52728, which requires us to update the guardian so that the code no longer tried to adjust the squeezer VCO frequency before attempting to close the LO loop.  Since this hadn't been loaded this morning, the squeezer laser was probably very far off in frequency when we injected it and as the LO loop tried to lock we might have crossed a frequency that disturbed the IFO.)
• In the next lock Robert and I did a few measurements with the POP beam diverter. The pop beam diverter was closed from 15:39:03 UTC to 15:46:01 UTC.
• I ran some calibration sweeps during and just after the morning meeting.  We got the sensing function, L3 and L2 sweeps, and we nearly got the L1 sweep but the interferometer lost lock for unknown reasons part way through this.  Timesh has offered to start processing these sweeps.
• We weren't able to relock because the COMM beatnote was low, so Niko and TJ started an initial alignment. I moved the IM3 yaw slider back to 4870, the value it was at before the vent. 
• Spent some time thinking about the X arm/PR3 alignment, here is a summary of the story:
  • Looking back at the last locks of O3a (second attachment), the comm beatnote was around -4dBm.  In those locks the ITMX alignment changes by 3 to 4 microrad when the spots get centered, meaning that our inital alignment references at the end of O3a weren't actually set well for centering the beam on the optics.  We came into lock in September with the reccling gain monitor reading around 46 before any ASC was engaged. 
  • We believe that we lost the ITMX green camera reference durring the vent. 
  • We reset this once when we had partially recovered good recycling gain, but not yet been able to center the spots on the optics.  After that reset of the camera and green QPD references, we had a good COMM beatnote.  52692
  • After we pico'd AS_C we were able to close SRC ASC, and that allowed us to close the ADS and center the spots on the optics, we then reset the green camera and QPD offsets for this alignment. 52700  Wit these alignment settings we have been coming into resonance with a good recycling gain, around 47 according to our monitor.  This change also resulted in a lower comm beatnote, which caused some difficulty with locking for Jenne and Varun yesterday (52725), they moved PR3 to get that back.
  • We thought that PR3 had not been moved during the vent, but now that I am looking at the trend I see that it was actually moved a few microradians, so I've reverted both PR3 sliders to where they were in September. Bringing PR3 back to its September slider values restored the COMM beatnote to -5 to -6dBm, which is good enough for us to relock.
  • Patrick is writing a script that can compare our witness sensors now to O3a for different states. 

Richard, Patrick

Command run around 19:12 UTC. Pressure plot attached.

    Laser Status:
    Front End Power is 32.22W (should be around 30 W)
    70W Output Power is 70.23W
    Front End Watch is GREEN
    70W Watch is GREEN

    PMC:
    It has been locked 10 days, 19 hr 18 minutes (should be days/weeks)
    Reflected power = 11.46Watts
    Transmitted power = 53.39Watts
    PowerSum = 64.85Watts.

    FSS:
    It has been locked for 0 days 0 hr and 17 min (should be days/weeks)
    TPD[V] = 4.846V (min 0.9V)

    ISS:
    The diffracted power is around 1.5%
    Last saturation event was 0 days 0 hours and 17 minutes ago (should be days/weeks)

    Possible Issues:

SudarshanK, DriptaB, JoeB, ShivarajK, RickS

We updated the ETMX and ETMY parameters file to include the updated O3 masses as outlined in the LHO alog 49398.

svn/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/h1etmx.m

svn/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/h1etmy.m

These files have been committed to the svn and the updated values are shown below:

For ETMX:

ear_mass_total = 0.044;                           % sum of both ears, from Betsy
ear_distance   = 0.164;                           % D080658
amd_mass = .00205;                                 % New AMD masses added to the test mass; Updated by S. Karki LHO alog # 49398 
pend.m3 = 39.611+ear_mass_total+amd_mass;         % 39.657 = 39.603 + ear_mass_total+amd_mass; Updated on 25 Oct 2019 by S. Karki, LHO alog # 49398

For ETMY:

ear_mass_total = 0.044;                           % sum of both ears, from Betsy
ear_distance   = 0.164;                           % D080658
amd_mass = 0.00205;                                  % amd mass added by S.Karki as per LHO alog 49398
pend.m3  = 39.538 + ear_mass_total+amd_mass;      % 39.584 = 39.538 + ear_mass_total+amd_mass; Updated on 25th october 2019 by S. Karki as per the LHO alog # 49398

   TCS-X chiller was full so added no water. TCS-Y was down 0.5 from 10.0 to 9.5. I added 50ml water to TCS-Y. Observed nothing out of the norm on both chillers. Closing FAMIS #11515.  

HAM5_CP_SINF_V2 is showing a fairly large spike in the 600 Hz area. Beside that the spectra look fairly similar to one another.

There are frequently times when the build ups and ASC signals in DRMI become verry noisy about 1 minute after it locks.  The guardian does several things at the same time here, engages the DRMI ASC and waits for it to converge before offloading, requests BS stage 2 isolation, and changes DRMI from 1F to 3F locking.  Today we went through these steps slowly to try to understand which of these steps causes the big kick, and it seems that the BS ST2 isolation loops are the problem.  The attached screenshot shows that the problem happened durring the BS ST2 transition (there was not anything else going on at the time) although nothing seems to show up in the GS13 signals. 

We are often able to ride this out, but we sometimes loose lock due to this. Looking at the lockloss tool summary plot that Niko posted in the second attachment to 52514, this is probably responsible for the cluster of locklosses between the states 105 (TURN_ON_BS_ST2) and 111 (offload DRMI ASC) which is about 100 locklosses in O3a.

Edit:  In another locking attempt we waited again for the BS isolation loops, saw the big glitch but survived, then lostlock during the ASC offload, so there might be multiple problems in these states.  For now I've set ISC_LOCK to wait for the BS to finish isolating ST2 before it moves on to the other DRMI things, so that it will be easier to tell why we are loosing lock.

Also, watching the isolation loops, the glitch seems to happen at the time when FM1 is switched off and FM8 is switched on for the horizontal loops. (second attached screenshot.)