[ Jennie, Siva, Mayank]
Laser: Axcel ,Model Designation: BF-A64-0130-PP

We removed the Lens(f= 250 mm) in front of M2 meter and we placed a lens (1 m focal length) roughly 1 m away from the m2 meter.
The lens was adjusted so that the beam spot falls roughly at the center of traveling range of the stage.

We measured the M2 of the beam which gave the following result
M²x = 1.09 and M²y= 1.10.
Beam Waist Diameter X =702 µm
Beam Waist Diameter Y =703 µm
Beam Waist Position X =132 mm
Beam Waist Position Y =121 mm
Rayleigh Length X = 332 mm
Rayleigh Length Y =331 mm

The m2 value was better compared to the measurement done with the 250mm lens. However the Beam spot location of X and Y direction were off by 10 mm.
This astigmatism could be because of mismatch between beam and the optics axis of the lens.
We tried manually adjusting the lens but this was the minimum we could get by hand.
we can try tomorrow by placing the lens on a vertical x y stage to get fine movement.   

TITLE: 02/03 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 20mph Gusts, 14mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.34 μm/s
QUICK SUMMARY: H1 has been locked for almost 5 hours.

• Wind moderately low, microseism falling below 95th percentile

Sheila, Camilla, Matt Todd

Sheila, Ibrahim, Tony and Ryan S had lots of SQZ issues over the weekend: 82588, 82599, 82597, 82585, 82581

Changed made to avoid these:

• To avoid mis-clicks changing alignment:
  • Sheila commented out any PSAMS changes from SQZ_MANAGER
• To stop SQZ angle servo oscillating with a ~15 minute range, see attached plot  (note we also saw it oscillate when OPO temp was wrong in 82249):
  • In SQZ_ANG_ADJUST, Sheila reduced the servo gain from 0.5 to 0.1
  • In SQZ_ANG_ADJUST, Sheila removed the checker that only changed the SQZ phase if it was >3deg off.
• SHG power has been low this weekend:
  • We think this was due to the Zone 4 LVEA temp dropping ~0.4degF, see attached plot. Shiela/Ibrahim then adjusted the temperature while the LVEA was colder to improve the SHG green power, but  once it warmed up this was not the correct temperature. I've added to the SQZ wiki to help troubleshoot this in the future.
• RESET_SQZ_ASC had incorrect gains hardcoded into it and resets only ZM4 and ZM5 when we are using ZM4 and ZM6:
  • Matt edited this save the sus lock gains for ZM4,5,6, reset them and then turn them back to their previous values.
  • We tested this by taking SQZ_MANAGER to NO_SQUEEZING and then OFFLOAD_SQZ_ASC, put back in SQZ and then went to RESET_SQZ_ASC_FDS (which clears all ASC)
  • This now works well and can be used if SQZ angle/ ASC runs away. I reduced the limits for when the SQZ angle is reset form 100-250 to now if outside 150-250deg.
• After the OMC alignment was changed, the SQZ looked a lot better. We ran SQZ_SQZANG_FDS to check the best sqz angle plot here, then adjusted adf deg 1deg, sdf.

I'm also updating SQZ troubleshooting wiki, to hopefully be more clear and allow the operator team to more easily solve future SQZ issues.

During commisioning this morning, we added the final part of the ESD glitch limiting, by adding the actual limit part to ISC_LOCK. I added a limit value of 524188 to ETMX_L3_ESD_UR/UL/LL/LR filter banks, which are the upstream part of the 28 bit dac configuration for SUS ETMX. These limits are engaged in LOWNOISE_ESD_ETMX, but turned off again in PREP_FOR_LOCKING.

In LOWNOISE_ESD_ETMX I added:

            log('turning on esd limits to reduce ETMX glitches')
            for limits in ['UL','UR','LL','LR']:
                ezca.get_LIGOFilter('SUS-ETMX_L3_ESD_%s'%limits).switch_on('LIMIT')

So if we start losing lock at this step, these lines could be commented out. The limit turn-off in PREP_FOR_LOCKING is probably benign.

Diffs have been accepted in sdf.

I think the only way to tell if this is working is to wait and see if we have fewer ETMX glitch locklosses, or if we start riding through glitches that has caused locklosses in the past.

Mon Feb 03 10:07:31 2025 INFO: Fill completed in 7min 28secs

TCmins [-89C, -87C] OAT (1C, 34F) DeltaTempTime 10:07:40

Low range coherence check due to the low range we've been having in our last lock. Attached below.

Shown is worse range for 10Hz to 55Hz compared to Dec 15 '24.

Closes FAMIS 26355, Last checked in alog 82451

Laser Status:
    NPRO output power is 1.845W
    AMP1 output power is 70.07W
    AMP2 output power is 135.9W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 5 days, 21 hr 55 minutes
    Reflected power = 27.05W
    Transmitted power = 101.4W
    PowerSum = 128.4W

FSS:
    It has been locked for 0 days 0 hr and 49 min
    TPD[V] = 0.7664V

ISS:
    The diffracted power is around 3.2%
    Last saturation event was 0 days 0 hours and 49 minutes ago

Possible Issues:
    PMC reflected power is high

TITLE: 02/03 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.36 μm/s
QUICK SUMMARY:

IFO is LOCKING at ACQUIRE_PRMI

IFO was locking when I came in having lost lock only 30 mins ago (14:57 UTC).

TITLE: 02/03 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Mostly quiet shift with a drop from observing due to SQZ and a lockloss near the end of the shift. H1 just finished an initial alignment and has started relocking.

• 01:02 - Dropped observing from SHG; alog82599
• 01:13 - Observing
• 05:36 - Lockloss; alog82600
  • Loaded SQZ_MANAGER
  • Went into initial alignment and again did not see ALS issues

Lockloss @ 05:36 UTC - link to lockloss tool

No obvious cause, and I don't really see evidence of an ETM glitch this time.

At 01:02 UTC, H1 dropped from observing due to the SHG dropping out, and it would not come back on its own. I brought SQZ_MANAGER to 'DOWN' and raised the SHG temperature (H1:SQZ-SHG_TEC_SETTEMP) from 34.6 to 35.2 to raise the OPO ISS control signal and SHG green power back up to around 2.8 and 120mW, respectively. After that, I requested SQZ_MANAGER back to 'FREQ_DEP_SQZ' and everything came back without issue. Once I accepted the new SHG temperature in SDF, H1 returned to observing at 01:13 UTC.

TITLE: 02/02 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 143Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 20:31 UTC

Many, many issues today all SQZ related. In short, our range is terrible and we know it is SQZ related.

Most of the story can be found in alog 82588 (and comments) but to summarize:

• SQZ phase adjustment guardian was oscillating all over the place so Sheila and I turned it off. SQZ was well locked and we went into observing with good range knowing that this will degrade slowly as we thermalize. The plan was to edit the phase once thermalized
  • Edited line 52 statment from true to false in sqzparams.py
  • Then edited SQZ_ANG_ADJUST guardiuan's nominal state to be "DOWN" in order to allow SQZ_MANAGER to talk let us OBSERVE
• Once thermalized, I attempted to optimize the range and the opo temp but neither of these worked. I noticed that the SHG power had plummeted significantly since we locked and so I did what Sheila and I did yesterday and this morning and adjusted the SHG temp to give it more power, which worked but as with last few days, power just plummets and settles (screenshot 1). SDF also attached (screenshot 2).
• The main issue right now is the low frequency squeezing is quite bad, with the trace a bit above the FDS reference line, which was the opposite issue from yesterday, which I do not know how to fix but have tried looking at the wiki, and optimizing via the controls I am able to reliably alter to maximize range.
• For a full story, check out the following alogs in addition to the one linked above: Tony's alog 82585 and alog 82581

Otherwise, Dave did a vacstat restart due to a glitch - alog 82595

LOG:

TITLE: 02/02 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 22mph Gusts, 18mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.41 μm/s
QUICK SUMMARY: H1 has been locked for 3.5 hours. Ibrahim is bringing me up to speed on the SQZ issues of the morning.

• Wind moderately low, microseism still steady around 95th percentile

VACSTAT detected a single BSC3 sensor glitch at 13:34 this afternoon. Last glitch was 20 days ago. I restarted vacstat_ioc.service on cdsioc0 at 13:46 and disabled HAM6's gauge.

Unknown cause Lockloss. Sheila and I were troubleshooting a host of SQZ mysteries when this happened (not actually touching anything just discussing). It's tempting to say SQZ related since all our issues this weekend have been but yet unknown.

SQZ Morning Troubles

After reading Tony's alog, I had the suspicion that this was the SHG power being too low, causing lock issues. I trended Sheila's SHG Power while adjusting the SHG temp to maximize. This worked to lock SQZ almost immediately - screenshot below.

However, despite SQZ locking, it looked like in trying to lock for hours the SQZ_ANG_ASC had gone awry and as the wiki put it, "ran away" I requested the reset SQZ_ANG guardian but this didn't work. Then, I saw another SQZ Angle reset guardian, called "Reset_SQZ_ANG_FDS", which immediately broke guardian. The node was in error and a bunch of settings in ZM4 abd ZM5 got changed. I reloaded the SQZ guardian and successfully got back to FREQ_DEP_SQZ. I saw there were some SDF changes that had occured so I undid them, successfully making guardian complain less and less. Then, there were 2 TCS SDF OFFSETs that were ZM4/5 M2 SAMS OFFSET and they were off by 100V, sitting at their max 200V. I recalled that when SQZ would drop out, it would notify something along the lines of "is this thing on?". I then made the assumption that because this slider was at its max, all I'd need to do was revert this change, whic happened over 3hrs ago. I did that and then we lost lock immediately.

What I think happened in order:

1. We get to NLN, SQZ FC can't lock due to low SHG power. It had degraded from Sheila and I's set point of 2.2 to a further 1.45.
2. Guardian maxes out its ability to attempt locking by using ZMs and SQZ Ang ASC (if those aren't the same thing) and sits there, not having FC locked and not being able to move any more.
3. Tony gets called and realizes the issue and can only get to a certain level before LOCK_LO_FDS rails, I assumer due to the above change. This means that even if we readjust the power, the ZM sliders would have to be adjusted.
4. I get to site, change the temp to maximize SHG power and SQZ locks but at this weird state where ZM5 and ZM4 have saturated M2 SAMS OFFSETS. I readjust but the slider difference is so violent, it causes a lockloss.

Now, I'm relocking, having reverted the M2 SAM OFFSETs that guardian made and having maximized the SHG Temp power (which interestingly had to go down contrary to yesterday). I've also attached as screenshot of the SDF change related to the AWC-SM4_M2_SAMS_OFFSET because I'm about to rever the change on the assumption it is erroneous.

What I find interesting is that lowering the SHG temp increases the SHG power first linearly, then after some arbitrary value, exponentially but only for one big and final jump (kind of like a temperature resonance if you can excuse my science fiction). You can see this in the SHG DC POWERMON trend that shows a huge final jump.