Wed May 29 10:15:30 2024 INFO: Fill completed in 15min 25secs

Gerardo confirmed a good fill curbside.

FAMIS 28354, last checked in alog77843

Late alog for the in-lock charge measurement taken last Tuesday before maintenance (May 21st). There was no measurement taken this week (IFO was unlocked before maintenance this Tuesday).

J. Kissel 

Remeasured the same remote, DAC-driven measurement of the whole OMC DCPD sensing chain -- the transimpedance amplifier, the whitening chassis, and the front-end compensation for the frequency response of those -- as yesterday, now 24-ish hours after the DCPD transimpedance amplifiers were powered on. 

Finally -- some good news!

As suspected, after the giant inductors thermalized, the low frequency response has restored to the same post-2024-vent ~0.3% magnitude drop below 25 Hz. 
Yesterday, I'd only waited 20 minutes after turning them on when I took the data from LHO:78095.
So -- clearly the thermal time constant for the inductors is longer than 20 minutes!

As I logged in this morning, the  SQZ ASC and FC ASC offload and graceful clear history scripts that I  ran and left open yesterday (whoops) reran. 15:16UTC. Before I could save sdf diffs, we went though DOWN SDF revert. There was nothing in SQZ ASC, but FC ASC got cleared. As squeezing hasn't been in a good alignment over the last 12 hours, this doesn't really matter. But if  we were in observing it would have knocked us out.

Reminder to close scripts once used. CDS is there a way we can disable this from happening?

TITLE: 05/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 142Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.08 μm/s 
QUICK SUMMARY:

IFO just lost lock 14:47 UTC and now relocking

Dust monitors also have a few warnings:

*H1:PEM-CS_DUST_LVEA6      WARNING: dust counts did not change, please investigate
  *H1:PEM-CS_DUST_LVEA10     WARNING: dust counts did not change, please investigate
  *H1:PEM-CS_DUST_PSL101     WARNING: dust counts did not change, please investigate
   *H1:PEM-CS_DUST_PSL102     WARNING: dust counts did not change, please investigate

 
 

TITLE: 05/29 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

A bit of a wind storm at the beginning of the shift but luckily strongest winds only lasted about an hour and allowed for locking shortly thereafter.  Had about 4-5hrs of observing during this shift (with another lockloss minutes before the end of the shift).
LOG:

• 0010 Winds drop below ~30mph!
• 0100 NLN
• 0105 nuc30
• 0113 Took SQZ Manager to FDS
  • 0115 Ran SCAN_ALIGNMENT_FDS and then SQZ Angle
  • 0140 Naoki joined me in teamspeak to look at alignment (& camilla also joined).  ZM4 was adjusted in alignment slightly again.
  • H1 range is hovering around 130-140Mpc.
  • 0411 LOCKLOSS (
• Locking notes:
  • ALSx arm took some time to lock as it had trouble staying locked (but eventually made it)
  • PRMI looked off in yaw, and I was not able to get it better by hand.  Ran a Manual Alignmnet of just the PRC.  Unfortunately, DRMI still had issues locking (even with SRM tweaks, so a full Initial Alignment was run).  After this H1 made it to NLN with no problem.
  • 0616 Back to Observing with a range around 150Mpc.
• 0752  Sadly as I typed this summary H1 had another lockloss (this was with calm winds)

After the early evening winds dropped below 30mph, returned to locking and H1 made it back ton NLN.  Had to turn on Squeezing and then ran requested SQZ states (Scan_Alignment_FDS & Scan_SQZAng).  Naoki also looked at alignment for the squeezer to address squeezer noise as well.  

Finally returned to Observing with H1 and it's different/new SR2/SR3 pointing (from today's commissioning work earlier).  Range is hovering around 145Mpc.

FranciscoL, [Remote: RickS]

After one week of moving the inner beam to the center of the Rx (alog 77967), on May 28, we moved the beam down. This completes a cycle in which we characterize the XY comparison value to both directions of the pcal beam movement - one side right, one side down.

Attachment 'BothBeamsBefore' shows the beams before making any changes. Attachment 'AlignedTarget' shows the alignment with the beam height gauge. The pdf 'EndStationLog.pdf' lists the voltage values after each significant step of procedure T2400163. The steps represent writing down a voltage value after a particular change of the system. Some steps were recorded multiple times after minor changes.

• 'Initial' - Nothing has changed, reading voltmeter after plugging it to "Rx PD Mon".
• (1) Alignment of the target.
• (2) Only inner beam at Rx detector. (see image 'InnerBeamBefore')
  • The beam voltage was maximized by moving both axis. The first value is before attempting to move anything. The second value comes from attempting to maximize by making a horizontal move The third value resulted from moving the beam counter-clock wise from the vertical axis, an equivalent to moving the beam up.
• (3) Finalized beam movement. (see image'InnerBeamAfter')
  • The first value was from an accidental move up. The second value was after moving the beam down. The third value is from attempting to maximize the signal by moving the horizontal axis.
• (4) Both beams at Rx detector, target still on (see image 'BothBeamsAfter')
• (8) Target off. The measurement was recorded after placing the pcal enclosures.

The voltage ranged by ± 0.01 V during the measurement, mostly noticed when the target is placed on the integrating shpere. We might need to look closer at the seismic isolation configuration to reduce the noise during this - and potentially also end station - measurement procedure.

The 'Initial' measurement is *equal* to the last voltage measurement from the previous movement, done on May 21 (alog 77967). The initial and final voltage measuremed during todays procedure did not change.

With the movement made today, we expect that the X/Y comparison will change by +21.15 HOPs.

Today Dripta and I went to EY and did what would have previously call a standard ES measurement with PS4.

And We also employed the new End Station procedure.

Details and analysis ccoming in a comment to this alog.

TITLE: 05/28 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 24mph Gusts, 16mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

The site is currently being hammered by high winds gusts have recently started approaching 40mph (H1 just had a lockloss during these high winds...and green arms have been having troubles, so I am taking H1 to IDLE and Observatory Mode to WINDY on an hr by hr basis....hoping winds cooperate after sundown.

When H1 is able to return to NLN, Camilla requested for SQZ that scan_alignment_fds & scan_sqzang be run.

Terry, Kar Meng

The second SHG seems to have the appropriate finesse (~60) at 1064 nm. Next steps remove high reflector from temporary mount and place it in the SHG housing, then recover modes then look for green light.

TITLE: 05/28 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

IFO is in LOCKING at LOCKING_ARMS_GREEN.

We acquired NLN earlier but lost lock while some last min SQZ maintenance was being done. We lost lock from LOWNOISE_COIL_DRIVERS at 23:23 UTC and the wind is really picking up now (40mph gusts).

LOG:

I made two minor changes that I tested out during relocking today.

LOCKING_ARMS_GREEN state will not run increase flashes if the SEI state is not nominal in the respective arm. This is to stop increase flashes aligning to while an ISI is tripped and aligning to a bad spot. It will notify "Arm SEI not nominal, no I.F. until resolved", but I couldn't get it to stay up for long before other notifications would get in the way. Regardless, it wont run I.F. and will work for unattended times.

In ALS_DIFF  the find IR used to step the offset and then do an instantaneous check to see if there was any resonance with a low threshold. We've gotten unlucky a few times where it dipped just below the threshold during the check. To remove luck from this, I have it now grab data every step and look at the max. The downside to this is that if there is an nds issue, it will fail. I also increased the fine tune IR step size from 3 ->5 and it seemed to work well.

Sheila, Camilla, Jenne, Naoki

While Ibrahim was doing initial alignment during maintence today, I moved SR3 (using sliders) and SR2 using the osem, to the positions in the second column of 77719 (-P move of SR3, May 7 10:39 pacific). 

Alena has been working with the zeemax model of what happened when our OFI was damaged, and she believes that this location is more centered in the OFI, and this data may be useful to her modeling.  We haven't recovered the range or all of the optical gain that we thought was possible before the OFI was damaged (our OMC alignment wasn't optimized when this happened), so we are hoping that a different spot may help.

When we relocked after this the range was low (~145 Mpc), the attached screenshot shows that we have more LSC coherence now.  We should be able to adjust LSC feedforward during tomorow's commissioning time to address that. 

J. Kissel
EDIT :: False Alarm -- see comment below!

Since I'm at the "what does it all mean?" stage of madness with the OMC DCPD Transimpedance Amplifier (TIA), I decided to make it worse -- I remeasured the original transfer function that triggered me worrying about the TIA response in after the OMC swap (see LHO:75986). I did this to try to corroborate whether there is a change in the DCPDA response above 1 kHz as mentioned in LHO:78090. 

This transfer function is the remote, DAC-driven measurement of the whole DCPD sensing chain -- the transimpedance amplifier, the whitening chassis, and the front-end compensation for the frequency response of those -- this has been described most recently in LHO:71225. 

I *don't* see a difference above 1 kHz, but I *do* see more difference in response below 25 Hz than I had in 2024-Feb-26.

See the attached transfer functions of the DCPDA chain and the DCPDB chain.

Black is pre-OMC swap, 2023-Jul-11.
Brown is post-OMC swap, 2024-Feb-26.
Red is today, also-post OMC swap, 2024-May-28.
All measurements use the S2300003 whitening chassis, and the compensation from the 2023-Mar era compensation we've been using throughout O4.

The only "oh, well it could just be" that I can think of immediately is that the DCPDs had been powered down from 10:10a to 11:30a PDT today to characterize the measurement setup in analog (see LHO:78090), and these were measured "only" 20 minutes after being powered back on at 11:50a. So -- we'll have to take the measurement again at the next opportunity -- such that the TIA electronics have what we think it the appropriate amount of time to thermalize -- a few hours.

           Just maddening.

Data lives in 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/SensingFunction/OMCA/Data/
        20240528_H1_TIAxWC_OMCA_S2100832_S2300003_DCPDA_RemoteTestChainEXC.xml
        20240528_H1_TIAxWC_OMCA_S2100832_S2300003_DCPDB_RemoteTestChainEXC.xml

Pictures of the OMC IO Chassis.

LLO noted a 10 Hz comb that was attributed to the IRIG B monitor channel at the end station connected to the PEM chassis. (https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=71217)

LHO has agreed to remove this signal for a week to see how it impacts our DARM signal.

EX and EY cables have been disconnected.

On May 13th (as part of my DQ shift), I noticed a line of 4kHz glitches in the glitchgram, and they have appeared every day since then. Checking the summary pages revealed they’ve been intermittently present since Apr 8, 2024 but not previously (I checked from Dec 1, 2023 onwards). Fig. 1 shows an example glitchgram from May 13th. Figs. 2-4 show Omegascans for some of these glitches. I also created a spreadsheet to characterize these glitches, and did not find any pattern or regularity to their appearance.

I checked the aLogs for possible sources and found the SQZ angle was being tuned around the time the glitches started (aLog). I then compared the timing of the glitches to the SQZ: FC ASC channels and found a correlation between the deviation in the output and the strength of the glitches. See Figs 5-7 for examples, as well as the spreadsheet. I will be meeting with the LSC fellows on Tuesday to discuss these.

Naoki, Karmeng, Andrei, Sheila

We did NLG sweep on DARM at NLG 16.9 (nominal) and 42. The IFO was locked for more than 20 hours and well thermalized. We also tried NLG of 65.9, but the squeezing level was not stable so we gave up this NLG. We will take the third NLG data tomorrow if IFO is thermalized. 

Previous NLG sweep on DARM: 73747

How to measure NLG: 76542

How to change NLG: 73801

Note:

• Requesting SQZ_MANAGER guardian from FDS to FIS does not work. We need to request DOWN and then request FIS.
• With NLG 42, as soon as the seed was injected, the pump ISS failed. We reduced ISS gain from 31dB to 21dB to avoid it.
• With NLG 65.9, reducing ISS gain did not help, so we measured NLG without pump ISS. We requested OPO guardian to LOCKED_CLF_DUAL_NO_ISS and adjusted the OPO trans by changing the drivepoint of ISS.