Displaying report 1-1 of 1.
Reports until 19:55, Wednesday 06 March 2024
H1 ISC
jennifer.wright@LIGO.ORG - posted 19:55, Wednesday 06 March 2024 - last comment - 22:07, Wednesday 06 March 2024(76166)
Alignment Notes - Evening

Jenne, Elenna, Jennie W., Camilla, Ryan S., Austin, Matt, Gabriele, Georgia.

 

Going to offload DRMI ASC and try and offload things by hand as build-ups are decaying.

Got to Offload DRMI ASC.

Elenna changing PRM to improve build-ups. LSC-POPAIR_B_RF90_I_NORM and LSC-POPAIR_B_RF18_I_NORM.

PR2 helped.

SRM and SR2.

All of these pitch needed changing.

DHARD hit some limits at CARM offset reduction and we lost lock. First image.

DHARD YAW and DHARD PITCH rung up.

Annother lockloss (image 2) from state 309 but lockloss is reporting state number incorrectly.

We think its losing lock around DHARD WFS.

SRM yaw changed. Improves things.

Noticing some glitches on DHARD Pitch out - not sure what is causing them. Third image.

Changing CHARD alignment to improve ASC.

Lost lock. Possibly from state 305 (DHARD WFS)

PRM pitch being changed helps with build-ups (OFFLOAD DRMI ASC state).

Then stepping the guardian manually up the states making tweaks.

Tried to go from CARM offset reduction to Carm 5 picometers and LSC channels rung up at 60 Hz and we lost lock.

One of the LSC loops might have too much gain.

Elenna measuring TFs to check the loops, but DARM measurement is not giving good coherence and increasing the gain.

Power Normalisation of some loops uses IM4_TRANS_QPD and this is very mis-centred so may be adding in noise. (image 4)

Lockloss due to excitation?

Reached OFFLOAD DRMI ASC again and Elenna moving IM3.

Moved IM4 and less clipping on IM4_TRANS.

We lost lock.

DARM is normalised by X_ARM_TRANS and BRS X has been taken out of loop so Jenne changed the normalisation to be with Y-ARM in ISC_LOCK guardian.

Jenne aligning BS and we are in FIND IR.

Lost lock again.

Elenna doing went to MANUAL Initial Alignment state.

Had to undo the changes Jenne made to IM3 and IM4.

Gabriele is going to measure DARM with white noise measurement.

This shows the UGF is 15Hz instead of what we think it should be (50Hz).

Increased DARM gain by 50%.

Lockloss.

Problem comes with DHARD gain increase during DHARD WFS state (305). Georgis is commenting this out  in line 2337 and 2338 of ISC_LOCK.

Keep losing LOCK from LOCKING GReen ARMS State.

When we lose lock the power normalisation for DARM should reset to 0 but it did not and so was causing noise on the ALS DIFF input. Probably because the DOWN STATE of the guardian is not set to do it.

Elenna updated prep for locking to set this state to 0 even with using Y ARM for the power normalisation instead of X.

We fell out at CARM to TR.

Images attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 20:04, Wednesday 06 March 2024 (76171)

Adding some overall thoughts/conclusions:

It seems like there is some alignment *somewhere* that is still bad, but we can't figure out what it is. Earlier today we could reach "Prep asc for full ifo", and things seem to have degraded to where we cannot pass DHARD WFS. It seems like part of the issue is matching the alignment of the arms, since engaging DHARD WFS is such a problem. However, we are struggling to correct that alignment during the carm reduction in a way that maintains the lock. Also, some earlier attempts involved us trying to fix some of the input pointing that could be clipping, but the changes that Jenne made to IM3 and IM4 were "bad" in the sense that the INPUT ALIGN state no longer worked after that change.

We are also worried about the DARM unity gain in "darm to rf". It seems low to us (~15 Hz) but we actually don't know how high it should be (it should be closer to 60 Hz by the time carm is on resonance). It's also worrying to see the POP alignment degrade through the carm reduction process, but that's the normal process- we don't have PRC or SRC ASC engaged during the process normally either. We can achieve decent DRMI alignment by hand before the carm offset reduction phase.

It would be helpful to think of some way we can "offload" beneficial alignment steps from lock to lock as we retry carm offset reduction so we don't need to start from scratch every lock process. I think we should still also be concerned with whatever is going on at EX (BRS, ISI, etc). We get saturation warnings for EX that don't match our actions so maybe things aren't great down there.

Adding: Georgia moved the SRM before engaging DHARD and it helped significantly, especially with the glitchiness in the DHARD control signal.

Important to note: we commented out the gain increase for DHARD in the guardian. After the SRM move, Georgia tried increasing the gains again by hand. We immediately lost lock. So the higher DHARD gain is no good and is still commented out in the guardian.

elenna.capote@LIGO.ORG - 22:07, Wednesday 06 March 2024 (76172)

Further notes:

In a fit of frustration I re-engaged the DRMI ASC loops in the guardian except for PRC1 (PRM) and SRC2 (SR2) since those rely on QPDs whose offsets we do not trust. This made life easier, and before engaging DHARD WFS, I adjusted the SR2 alignment to improve the arm matching, and then the PRM alignment to increase the RF18 buildup (SRM is controlled by SRC1 and was offloaded in the DRMI ASC state). I also further walked DHARD in pitch and yaw using the move_arms_dev.py script. This improved the DHARD engagement further and the DHARD alignment converged decently. However, before I could move to the next state, I watched the green arm signals. The ALS Y signal drops out slightly before lockloss. I don't think there is any feedback on this signal, but maybe this is a sign that the arms aren't doing so well after all in this alignment, even though DHARD converges.

My current method: take the IFO to "DRMI_LOCKED_CHECK_ASC" and move PRM and SR2 to improve the POP build ups and camera image. Wait for other ASC signals to reconverge. Then, go to DRMI ASC alignment offload. From there, go to "DARM_TO_RF" and check the arm alignment.

I decided to revert the ITMs to the position they were in the last time we achieved "prep asc for full ifo" (see screenshot). I trended back the ITM oplevs. It appears that the most movement has occurred in ITMY yaw (4.8 versus 1.5). Perhaps this is one reason why our attempts to engage DHARD are failing. After this change I reran manual initial alignment to get the beamsplitter back to a good place.

Even with that change, the ALS Y arm buildup is still less than one (at locking arms green). This seems wrong, but nothing we have done makes it better. We did have a better buildup for ALS Y early yesterday that all our alignment efforts seem to degrade.

Ok, this did not work. Engaging DHARD WFS still pulls the Y arm ALS buildup off and then causes a lockloss. I am leaving in down. Please check ITM alignment before beginning locking attempts in the morning.

Images attached to this comment
Displaying report 1-1 of 1.