TITLE: 06/09 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: n/a
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 6mph Gusts, 3mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.23 μm/s
QUICK SUMMARY:
H1 was in the SDF Revert state (took to READY) overnight. Continue to be in the holding pattern of not going with more than 10W in power until approved.
IMAX crew continuing with set-up work.
There was a 6.2 earthquake down along the Pacific/Antartic Ridge about 5hrs ago.
TITLE: 06/09 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Commissioning
SHIFT SUMMARY:
Ten 10Watt locks tonight with no obvious spikes in pressure .
2024-06-08_22:58:05 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-08_23:53:25 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-09_00:40:40 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-09_01:22:46 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-09_02:42:00 ISC_LOCK POWER_10W -> LOCKLOSS
The above locklosses at 10Watts can be seen at alog 78320
Had to do an initial alignment inbetween the the first and last 5, that struggled to get past SRC, but I lowered the threshholds again.
2024-06-09_05:23:19 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-09_05:58:34 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-09_06:26:14 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-09_06:53:46 ISC_LOCK POWER_10W -> LOCKLOSS
2024-06-09_07:21:12 ISC_LOCK POWER_10W -> LOCKLOSS
On the last one I forgot to return H1:IMC-REFL_SERVO_IN1POL back to positive, and spent some time wondering why the IMC wasn't locking any longer lol.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
21:03 | SAF | HAZARD | LVEA | YES | LVEA is Laser HAZARD | 23:31 |
00:23 | Tour | Mike & IMAX | LVEA Xarm | YES | Giving Film Crew an IMAX tour & drone flying | 4:38 |
01:32 | Fire Watch | Dripta | LVEA Roof & EY | No | Looking for fire or smoke near Rt.240 round about | 02:02 |
We had 10 locklosses from 10W lock yesterday, and we see zero pressure spike. At this point I'd say this HAM6 alignment is safe. We can try locking OMC and going to high power.
The 1st attachment is the summary trends from yesterday, the same thing as Tony posted but just in a single plot. Y-axis scale is the same as the 2nd attachment, which is from Thursday when we got pressure spikes. Note that the first spike was from a 10-W lock loss on Thursday and that was clearly visible in all pirani gauges on the plot.
TITLE: 06/08 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 11mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.15 μm/s
QUICK SUMMARY:
H1 was able to get locked up to POWER_10W twice so far.
First 10W Lock Pressure ndscope
Second 10W Lock Pressure ndscope
Notes: this lock had many EX saturations.
Known Locklosses all caused by intentional H1:IMC-REFL_SERVO_IN1POL polarity change.
I've been sitting in power 10W for 15 minutes just to see if there is any warm up time or something.
Third 10Watt lock pressure ndscope 2024-06-09_00:40:40
Fourth 10WATT lock pressure ndscope 2024-06-09_01:22:46
5th 10WATT lock pressure ndscope 2024-06-09_02:42:00
A shot of the five 10Watt lock stretches with set scales I took from Keita's alog (78310) with UTC times for reference.
Thankfully I don't see any increases in pressures over the course of these 5 10Watt locks.
TITLE: 06/08 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY:
Operations NOTE: H1 -NOT- to be taken higher than 10Watts until commissioners give the OK (which will most likely be tomorrow). Jenne/Sheila/Keita on Teamspeak discussed plans for the rest of the weekend and the goal for tonight/tomorrow is to get (5) H1 locklosses from 10W (The hope is to NOT have any more pressure spikes coinciding with H1 locklosses.)
Next Steps? Once (5) 10W locklosses have been achieved, will reassess what to do next.
Whew! What a day! H1 continued to have issues locking DRMI today as it did yesterday. Keita & Sheila were helping remotely from 9am(local) to about 4pm (with Jenne joining at the end of the shift). PLUS, there were Saturday tours today, AND THEN a film crew showed up!
I wrote a running diary covering what activities we did for H1 (with the hopes of posting entries throughout the day, but it was too hectic of a day!).
The main point is that H1's DRMI-locking issues seem to be addressed (I was able to get the #1 10W lock before the end of my shift, and Tony just broke lock for the #2 10W lock. Only 3 more needed!)
Started today's shift by starting with a fresh alignment (reverted to the time when TJ & Sheila handed H1 over to me for an alignment at lunch time Friday afternoon). After that, I basically started "my diary," but since Sheila/Keita will have a better summary of what happened to get H1 back (I will post my locking notes for today as a text file---because they were basically chicken scratch with all the activity going on!)
Attached are screenshots of the SUS sliders (yesterday and what they were first thing this morning), Locking Notes, and the text file for the SUS slider revert.
LOG: (not much here, because the day was focused on H1 getting through DRMI!)
I replaced the temporary viewport covers with the permanent ones and I cleared the LVEA for observation mode.
Sheila, Keita, Corey
The ISC lock guardian wil lock the bright MICH if PRMI is taking a while to lock. Sometimes we do not want this, as today when we just manually aligned the BS in PRMI and don't want it adjusted.
I've added a flag to lscparams to stop this, called auto_MICH_fringes. I added a similar flag called auto_DRMI, which is also now set to False.
We will want to set these back to True when we are ready to go back to fully automated locking, for now operators can request PRMI or MICH fringes if they like.
Sat Jun 08 10:11:08 2024 INFO: Fill completed in 11min 5secs
TITLE: 06/08 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: n/a
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 12mph Gusts, 10mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.13 μm/s
QUICK SUMMARY:
H1 was in IDLE for the night after (also Tony had to deal with some alignment grief with H1). Will look at the alignment this morning and then chat with Sheila & Keita.
Saturday Tours Day & a film crew is also scheduled to be on-site this forecasted hotter afternoon.
TITLE: 06/08 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: OWL Shift Canceled.
SHIFT SUMMARY:
The Plan for tonight: Tony will power up on RF to avoid the difficulties we have with turning on a DARM offset. Stop at 10W, which is the smallest power at which we saw a pressure spike yesterday, and intentionally unlock (request down or flip sign on IMC servo). Check for a pressure spike. If there is no spike, repeat this until the end of Tony's shift when he will leave the IFO in DOWN. No owl operator. In the morning, @Keita Kawabe @Corey Gray and I will chat on zoom at 9 am, to discuss next steps, and what is needed for debugging the locking issues. @Jenne Driggers I think that today's locking situation is very similar to what you alogged on Wed, we were able to turn on the DARM offset once when I opened the SRC1 loops and aligned SRM by hand to reduce POP90.
What Actually happned:
Got stuck at locking DRMI for the entire night trying different alignments and troubleshooting tips.
I moved the BS and PRM around so much that I could no longer convince ISC_lock to go to AQUIRE_DRMI_1F any longer again.
So I went back to do an Initial Alignment. interestingly enough I ended up in the same spot as last time where I was stuck in AQUIRE_SRY, I touched up PRM by hand again as best I could while watching AS_AIR and ASC_AS_A_DC Sum again. once I got that as maxed As i could get it, I lowered the threshholds again.
H1:LSC-SRCL_TRIG_THRESH_ON from 0.006 -> 0.003
H1:LSC-SRCL_TRIG_THRESH_OFF and 0.004 -> 0.002
Allowed Initial_alignment to complete again.
And once ISC_LOCK got back to locking DRMI I was greeted with another instance of the beam splitter or PRM being off in YAW by a lot.
I then held ISC_LOCK in AQUIRE_DRMI_1F & set the slider values for PRM and BS to the value that they were at during the last lock with DRMI. This did not work either.
I tired this a few more times using different places along the locking process.
Rolling ALL sliders back to GPS Time 1401839323 (the IDLE time before the last time we had a locked DRMI.)
I was hesitant to revert ALL sliders back because I was under the impression that there was some significat work done on that particular alignment.
All sliders restored to GPS time: 1401762164 (Tail end of Initial alignment before a good lock)
The Alignment is off somewhere, And I'm not sure where.
I stayed a little late to try one more thing:
I restored back to a know good alignment, then ran another initial alignment on top of that! but I did't move SRM in the SRC ALIGN IFO stage. instead I just quit the Alignment.
This resulted in an alignment that got DRMI locked but SRM saturations were constant and I got stuck in DRMI_LOCKED_CHECK_ASC because the SRC channeles were not converging.
I tried this again and tripped the SRM SUS WatchDog. I have now taken ISC_LOCK to Down for the night.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
21:03 | SAF | HAZARD | LVEA | YES | LVEA is Laser HAZARD | 23:31 |
15:24 | isc | commissioners | cr | - | OFI pointing | 00:21 |
17:10 | SHG | terry.KarMeng | OpticsLab | YES | SHG green/ir laser work | 23:54 |
23:22 | PEM | Robert | LVEA input arm | YES | Taking temp View Port Covers *OFF* to look inside! | 01:22 |
01:36 | PEM | Robert | LVEA | YES | Putting Temproary ViewPorts on | 01:40 |
TITLE: 06/08 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 8mph Gusts, 6mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.14 μm/s
QUICK SUMMARY:
While trying to LOCK DRMI
I touched up BS and SRM but I still couldn't get DRMI locked. (likely pecause there was activitiy on the HAMS)
I then started an initial alignment.
I got into SRC align and could not find SR2. I pushed around SR2 to try and find it by hand, but I realized that there was still activity on and near the HAMS duirng the first stages of IA, and I had also potentially caused problems with the IA by requesting the laser stay at 2 watts in the middle of a movement. So I re-requested initial alignment and allowed SRC to do it's thing without intervention.
SR2 sliders are currently -8.6 for P and 2058.8 for Yaw
Reverting SR2 Sliders ONLY to 1401741295 (Last initial Alignment before a lock)
Which were -631.6 in P 282.6 in Yaw
Ended up moving SR2 sliders back, and moving SRM sliders to get better fringes while align IFO was in SRC align.
Jenne Driggers helped me out by pointing me in the right direction with SRM and showing me which thresholds to lower
H1:LSC-SRCL_TRIG_THRESH_ON from 0.006 -> 0.003
H1:LSC-SRCL_TRIG_THRESH_OFF and 0.004 -> 0.002
Once I started to lock and got back up to DRMI the Beam splitter was very off in pitch, which is wild since I just did an initial alignment. While touchingup the beamsplitter alignment, there was a lockloss from DRMI, maybe from my BS movement.
X arm had the PDH issue again which eventually resolved itself.
Currently trying to lock DRMI again.
Since Tuesday some of our sucsesfull locks have required manual intervention with the alignment of SRC to be able to turn on the DARM offset.
We would like to have Tony lock the IFO to 10W tonight and intentionally unlock it to see that we do not have any pressure spikes when this happens in this alignment.
I've edited the guardian, setting the flag in lscparams so that we power up on RF, and adding a check of this flag in DARM_OFFSET so that we don't engage the DARM offset if the flag is True.
Keita, Sheila,Robert, TJ, Jennie, Corey, Tony
Dave and Gerardo alerted us that there have been vacuum spikes after locklosses in HAM6 yesterday. We are looking at what circulating powers were and what the lockloss transient was at the time of locklosses that caused and didn't cause a vacuum spike in HAM6. Here is a comparison table:
time | AS_C peak | POP A LF | which alignment | spike? |
6/7 1:12:35 | 0.938*10 = 9.378 | 5505 | bad | 3.6e-8 |
6/7 3:04:08 | 1.35*60 = 81 | 26739 | bad | 4.28e-8 |
6/7 03:51:29 | 1.05*60 = 63 | 27032 | bad | 1.5e-7 |
6/7 23:15:54 UTC | 0.342*2 =0.684 | 1109 | good | no |
6/7 20:54 UTC | 1.58*2= 3.16 | 651 | good, PRG was tanking | no |
In the bad alignment, the beam was clipped on it's way to AS_C, so that diode wasn't catching all the power it would have in the good alignment. AS_A and AS_B saturate at the time of locklosses.
The spike in vacuum pressure was higher with each successive lockloss, although the power on AS_C was largest in the second one.
One of the three pressure spikes from yesterday was the lock loss from 10W, others were from 60W.
1st plot shows the worst one in terms of the pressure spike (the last one at 6/7 1:12:35 UTC, 60W).
This doesn't tell us the cause of the pressure spike, that requires different investigations.
Anyway, the 2nd plot shows the lockloss from today after Sheila, Jennie and TJ moved to a better alignment.
SR2 doesn't move much over the power range from 2W to 25W, and ASC-AS_C_NSUM doesn't show the sign of clipping. Everything looks saner and thus better.
The only concern is if this "better" alignment will still burn things in HAM6. We haven't observed pressure spikes from 2W lock losses with this alignment today but that only happened twice.
To clarify, "bad" alignment that produced pressure spikes was only for Thursday, and the "better" alignment today is supposed to be the same as or at least quite similar to pre-Thursday. Since we haven't had any pressure spikes with pre-Thur. alignment, I doubt that we'll see any pressure spikes with this alignment either.
However, picos had to be moved by large amount to go from pre-Thur. to Thur. and then to Fri. alignment. Even though Fri. alignment should be clouse to pre-Thur., we expect some not-so-large difference in the WFS sled centering, thus in the HAM6 alignment.
Out of caution, we'd like to see that losing lock at 10W won't cause pressure spikes before proceeding further. We chose 10W, because a pressure spike was observed at that power with a loss of lock with a bad (Thu.) alignment. If we don't see any spike for many lock losses with current (Fri.) alignment it would be safe to proceed.
Since automated DC lock won't work for this "good" alignment yet (that problem existed before Thursday and it seems to persist today), Sheila and I asked Tony to lock the IFO, bring it to 10W with RF, kill lock and observe pressure. If there's a spike he will stop, otherwise he will repeat.
We'll reconvene tomorrow.
Attached is an annotated HAM6 picture.
Also, plots with more piranis showing all three pressure spikes was posted in alog 78327.
Since FS seems to have worked, potential point that could have made pressure spikes are:
TITLE: 06/07 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 7mph Gusts, 5mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.14 μm/s
QUICK SUMMARY:
IFO has been seeing vacuum pressure spikes during locklosses potentially coming from HAM6.
Currently Holding in OFFLOAD_DRMI_ASC. and will be touching up alignment by hand.
A plan is being made to determine the corrective action for the Pressure spike issue which MIGHT be due to a beam heating up something that should not be heated up.
Lockloss, getting bck to OFFLOAD _DRMI_ASC to manually align.
TITLE: 06/07 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY:
Continuing OFI pointing work: Undid the pointing from last night and returned to a different pointing.
Other big item was toward the end of the shift when Dave & Gerardo contacted the Control Room regarding pressure glitches seen last night which corresponded with (3) higher power locklosses last night. (We are no longer at this pointing as noted above though, but this took all the focus of the last hour or so.)
LOG:
Sheila D, Jennie W, Corey G, TJ S
Yesterday we tried a new SR2&3 alignment combination for hopes of better OFI throughput, but after a hrad fought alignment battle, this alignment proved to not work out (alog78290). This morning we started the process to move back to our SR positions that we have been running for the last month or so.
The process was the same that we have been running: walk SR2 and SR3 in a single dof while trying to not fall off AS_C, AS_B, or AS_A, then correct with picos when unable to stay on the QPDs. Repeat with the another dof. This got us back to our target SR positions, but OM3 and OMC were either saturating or getting close to it. Based on part of Keita's recommendation for how to do this move (alog78297), we moved the OMs and some picos enough to engage the OMC ASC, which controls OM1&3 to steer into the OMC QPDs, then moved OM2 to relieve some of the strain on OM3&C. This required a DOF2TT matrix change as in Keita's alog. Eventually we were able to get all QPDS (AS_{A,B,C} & OMC_{A,B}) to be centered with fairly low drive output on the suspensions.
Corey ran a manual initial alignment and brought SRM back to near where it has been. When relocking we first ran into the DARM offset issue that we have been seeing lately (see alog78273), and I didn't catch it in time. The next time around Sheila put the SCR1 Y offset of in and changed the DARM offset and that was enough for us to lock the OMC and move onto DC readout. We've now heard of some other issues, so we are holding here and not advancing over 2W yet.
Gabriele, Sheila
Between the locks on June 3rd and June 4th, our LSC feedforward became mistuned (more dramatically than before). This might explain most of our range drop this week. We don't know why this happened, there aren't any known changes that occured, other than a stretch of windy days with poor locking.
This morning we were briefly locked in our "post April 24th alignment", and Gabriele walked me though doing the iterative feedforward measurements.
I've updated the README.txt in userapps/lsc/h1/scripts/feedforward with instructions for the iterative measurement:
go to NLN_CAL_MEAS
To turn off FF: SRCLFF1 (or MICHFF) to DARM: turn SRCLFF1 (or MICHFF) gain to zero, turn off the FF filter but leave the high pass on, turn off the input to SRCLFF1, set gain to 1. Run excitation with the SRCLFF template
SRCL to DARM: nominal configuration with MICH and SRCL FF on, in NLS_CAL_MEAS. Run the template for SRCL excitation
When you measure MICH to DARM you leave everything in nominal condition
When you measure SRCL to DARM you leave everything in nominal condition
When you measure SRCLFF to DARM you leave MICHFF in nominal condition, turn off SRCLFF as aboves
When you measure MICHFF to DARM you leave SRCLFF in nominal condition, turn off MICHFF as above
The measurements are checked in at userapps/lsc/h1/scripts/feedforward
SRCLFF_excitation_ETMYpum_2024_06_06.xml
NoLP_MICHFF_excitation_ETMYpum_June62024.xml
MICH_excitation_June62024.xml
SRCL_excitation_June62024.xml
Here are two fits that should improve MICH and SRCL FF
SRCL
zpk([-7.169784531472987+i*46.80222713776738;-7.169784531472987-i*46.80222713776738;-50.91705199165386+i*64.16016193457278;-50.91705199165386-i*64.16016193457278;-42.15501976438775-i*1098.232422972419;-42.15501976438775+i*1098.232422972419;-145.0093557348077-i*1089.461704122895;-145.0093557348077+i*1089.461704122895;-245.0829862689482+i*1107.79921936364;-245.0829862689482-i*1107.79921936364;-141.5739067943562;-144.9209247430132;-826.3641092498208;-852.1997030446448],[-2.881922149238943+i*32.00142415651089;-2.881922149238943-i*32.00142415651089;-39.6556740022373+i*916.0295759541193;-39.6556740022373-i*916.0295759541193;-230.3431403668346+i*2309.933027270674;-230.3431403668346-i*2309.933027270674;-39.76964022276446;-39.8605595541308;-39.89837525205524;-39.91157191605507;-40.46668526791298;-2581.144039450426;-2671.009338936645;-2738.495590062898],0.4767541992000439)
MICH
zpk([-0.1470884781758559+i*48.42475784167187;-0.1470884781758559-i*48.42475784167187;-24.82947443442181+i*50.41982768133377;-24.82947443442181-i*50.41982768133377;-1.195340221327271+i*60.10254083145923;-1.195340221327271-i*60.10254083145923;-0.8119687656946064+i*112.301511110354;-0.8119687656946064-i*112.301511110354;-94.78274149473425+i*118.9486474187639;-94.78274149473425-i*118.9486474187639;-307.5544495976067+i*199.6473319209523;-307.5544495976067-i*199.6473319209523;-365.1498461668634+i*797.5973180592285;-365.1498461668634-i*797.5973180592285;-264.514660945466+i*941.2100034065085;-264.514660945466-i*941.2100034065085;49.35448274331864;-185.3386536745414],[-1.619706160754901+i*48.82075959570737;-1.619706160754901-i*48.82075959570737;-1.342047624329135+i*59.97321034526349;-1.342047624329135-i*59.97321034526349;-0.7898795886248342+i*112.7249598047579;-0.7898795886248342-i*112.7249598047579;-310.8951954733114+i*592.1396997441478;-310.8951954733114-i*592.1396997441478;-167.320180125188+i*927.5461319412049;-167.320180125188-i*927.5461319412049;-33.94826038138513;-33.98691038181345;-34.44985837050922;-35.1231562638948;-189.8775386189932;-309.2218677305598;-375.827056617601;-1502.151637570457],-8.520785430534616)
Jenne D, Jennie W
Jenne noticed that our AS_A_YAW offset was on in the current state (PREP_FOR_LOCKING). We don't want this offset on currently as we are moving to a different spot on the OFI for which we need the picomotors, therefore we my need to rethink AS_A and B alignment offsets.
We turned this offset and the other AS_A and AS_B oiffsets off.
This is the only one I could find set in the ISC_LOCK guardian so I commented this line out.
elif self.counter==9 and self.timer['LoopShapeRamp']:
#ezca['ASC-AS_A_DC_YAW_OFFSET'] = -0.15 J Wright commented this out on 6th June 2024.
ezca.switch('ASC-AS_A_DC_YAW', 'OFFSET', 'ON')
I reloaded the ISC_LOCK guardian.