Displaying reports 1-20 of 89075.Go to page 1 2 3 4 5 6 7 8 9 10 End
Reports until 14:18, Saturday 29 August 2026
H1 IOO
jennifer.wright@LIGO.ORG - posted 14:18, Saturday 29 August 2026 (91737)
JAC Heater Guardian updated

Following on from yesterday's alog #91730 today I turned off the JAC Heater controller and switched the gain back to -0.1 and the second pole at 1Hz off also.

I then updated the JAC heater guardian so it switches on and off the Beckhoff JAC Heater Controller and also adds in the normalised control signal from the length feedback to the JAC PZT as an error to the Heater control signal.

The code that does this is:

class HEATER_SERVO_OFF(GuardState):
    index = 20
    request = True
    def run(self):
        ezca['JAC-HEATER_CONTROL_LOOP_SWITCH'] = 'Off'
        ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = 0

        if beckhoff_check():
            return True
        else:
            notify('Heater off! Check Driver and Beckhoff controller.')
            return False


class HEATER_SERVO_ON(GuardState):
    index = 1
    request = True
    def main(self):
        self.pzt_fb = ezca['JAC-PZT_DRIVER_VOLTS']
        self.pzt_low = ezca['JAC-PZT_DRIVER_PZTHIGH']
        self.pzt_high = ezca['JAC-PZT_DRIVER_PZTLOW']
        self.servo_setpoint = ezca['JAC-HEATER_CONTROL_SETTEMP']
        self.in_loop_sensor = ezca['JAC-HEATER_THERMISTOR_1_TEMPERATURE']
        self.sensor = 1

    def run(self):
        if beckhoff_check():
            notify(f'Servo on with set temperature: {self.servo_setpoint} deg.')
            ezca['JAC-HEATER_CONTROL_LOOP_SWITCH'] = 'On'
            if ISC_library.JAC_locked():
                ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = (self.pzt_fb/(self.pzt_high - self.pzt_low))
            else:
                ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = 0
            return True
        else:
            notify('Heater off! Check Driver and Beckhoff controller.')
            return 'HEATER_SERVO_OFF'

                
edges = [
        ('HEATER_SERVO_ON', 'HEATER_SERVO_OFF'),
        ('HEATER_SERVO_OFF', 'HEATER_SERVO_ON'),
        ]

 

It is necessary to normalise the PZT fb signal by the total range of the PZT HV driver before adding the signal into the error point to normalise it.

The code should only include the offset from the PZT error point if the JAC is locked, this is because we don't want it adding random offset while the pzt is scanning.

However we do still want the JAC heater locked to its set temperature when the JAC is unlocked.

From the image you can see that the JAC-HEATER_CONTROL_VOLTSOFFSET is zero until we get past the scanning state (number 20) in the JAC locking sequence.

I will leave this servo on all weekend to test it with the new guardian control.

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 18:38, Friday 28 August 2026 (91729)
Fri Ops EVE Summary

TITLE: 08/28 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

At the  begining of the shift ETMy ESD was being restored and then this allowed Commissioners to work on locking (since ETMx is finicky, they were working on using ETMy (which has its own problems) for ALS DIFF---see Elenna/Louis alogs.
LOG:

H1 ISC (SUS)
elenna.capote@LIGO.ORG - posted 18:26, Friday 28 August 2026 (91736)
Balancing BS M2 and M3 coils, L2A tfs measured

Oli, Elenna

Today, we tried to balance the coils on the BBSS M2 and M3 stages. I chose to use AS_C as an optical lever, since we have previously observed some strange cross coupling on the BBSS oplev and I didn't want to get confused.

Coil balancing steps:

I was able to get a 20 dB reduction in pitch and yaw on M2, but only a decent pitch reduction on M3. I should revisit the M3 measurement again, since I was just guessing which way to go with the gains, and there is probably a much more procedural way to go about this.

Bs M2 shows the improvement in pitch and yaw and the final gains.

BS M3 shows the improvement in pitch and little improvement in yaw, also final gains.

I SDFed these coil gains (91735)

I had previously measured the L2P and L2Y coupling on M2 and M3 before balancing the coils. I remeasured the transfer functions afterwards, again using single bounce to AS_C. There was only a significant difference in the M3 L2Y coupling- I was unable to measure it at all, despite using the same drive as before. I couldn't bump up the measurement drive since I was close to falling off AS_C.

I have attached screenshots of each measurement. The blue reference traces are from before the coil balancing.

I will fit these measurements and implement them in the drivealign matrices. Then, we can check the decoupling of the L2A during PRMI/DRMI locking.

Images attached to this report
H1 AOS
elenna.capote@LIGO.ORG - posted 18:04, Friday 28 August 2026 (91735)
SDFs before revert

Here are some SDFs of BS, ASC, and LSC before SDF revert today.

Images attached to this report
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 17:20, Friday 28 August 2026 (91734)
Functionality Test At Purge Air Systems For End Stations

FAMIS task complete, started both systems at end stations, left the compressor and dryer units run for 2.5 hours each, found a couple of air leaks, fixed the leaks and the dew point for both systems look good.

Images attached to this report
H1 SPI
jim.warner@LIGO.ORG - posted 17:15, Friday 28 August 2026 (91731)
SPI Diff length and HAM2&3 ISI motion

Posting some initial plots of SPI DIFF L, doing my best to line up with my results here with alog 73976, where Jeff looks at IMC F length in hz/rthz and compares that to ISI motion. On the attached image, I show spectra for the differential HAM2-3 X super sensors (calculated online in seiproc, using blended cps and gs13s from each chamber), HAM2 and 3 X gs13s and IMC F, all calibrated to hz/rthz using Jeff's factors from 73976. H1:SPI-H23_DIFFDISP_MAIN_OUT_DQ is also calibrated to hz/rthz using the same 70.551 hz/nm Jeff calculated for the ISI. With that calibration, SPI DIFFDISP is still off from the other sensors by about a factor of 3. 

For the second image, I made a new copy of Jeff's template from 2023, re ran it for last night and added SPI DIFFDISP. We don't have CARM yet, so it's not complete, but I updated references. Again, I used Jeff's 70.551 calibration factor to convert SPI DIFFDISP from nm to hz. SPI seems to agree better here, so I'm not sure what the differences are from from first plot. 

 

Images attached to this report
H1 IOO (ISC, OpsInfo)
jennifer.wright@LIGO.ORG - posted 17:06, Friday 28 August 2026 (91732)
JAC sdf housekeeping

Since we were going through sdf revert today I accepted some JAC ASCIMC and LSC model diffs. See first two images.

The next image is some slow controls settings we want to stay constant when the Bekchoff computer restarts. I didn't accept the pole value as I am still making changes to the heater servo this pertains to.

The last picture shows that i unmonitored the input switch, FM1 and FM2 switches on the JAC-L_SERVO filter bank. These are switched on by the guardian when we lock the JAC so we don't want the JAC to unlock when we sdf revert (as happened today before I made this change to the sdf monitor).

Images attached to this report
H1 IOO
jennifer.wright@LIGO.ORG - posted 16:45, Friday 28 August 2026 (91730)
JAC Heater commissioning

Jennie W,

Last night I added a second pole to the JAC controller with the view to increasing the damping. It has not helped (JAC temperature is still oscillating after ~20 hours).

This is no improvement on how long it took to damp when we increased the set power of the JAC on Tuesday 18th alog #91587.

After thinking about it a bit more and comparing the temperature stability before and after I increased the gain magnitude of the servo (also on Tuesday 18th), I think our gain is too high and causing the system to oscillate.

I think the order of operations over the weekend is to remove the second pole, turn down the gain and then set up the guardian node to add in the PZT feedback signal to the heater controller error point. I will test this over the weekend when it won't affect corner commissioning.

Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 16:30, Friday 28 August 2026 (91723)
Ops Day Shift End

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

LOG:

Start Time System Name Location Lazer_Haz Task Time End
17:02 SEI, CC Mitch Ends n FAMIS HEPI checks and CC checks at EX 17:46
17:07 PEM Robert EX n Grounding investigation 18:13
22:36 PEM Robert EX n Grounding investigation 00:36
22:39 - Mike, Daniel, Tourist x2 LVEA Y Tour 00:09
22:52 SEI Jim, Shoshana CER y Checking on CRS damping signal 23:04
23:19 SUS Sheila, Mark EY n Checking on ESD 00:19
H1 SUS (ISC)
oli.patane@LIGO.ORG - posted 14:28, Friday 28 August 2026 (91728)
BBSS vs BSFM DOF noise measurements

I've made plots comparing the M1 stage BSFM BOSEM noise to the BBSS QOSEM noise to see how much better we are. This is similar to the plots TJ O made in 91466. During the time the BBSS data was taken from, we did have the LED sum current feedback switched on, but comparing our BBSS QOSEM noise to the two QOSEM noise floor plots (taken from G2501105 slide 29), it really looks like we are currently being limited by the constant LED current, as if we didn't have the feedback on at all.

We know the sum current feedback loops are doing something because when we first turned them on, they adjusted the sum counts on two of the osems that were reading too high of counts, but based on these plots it doesn't look like they're doing much? TJ O and I will talk with Tom to investigate more.

Results:
/ligo/svncommon/SusSVN/sus/trunk/BBSS/H1/BS/SAGM1/Results/2026-07_OLG_tfs_4_BSFMvsBBSS/allDampRegressCompare_H1SUSBSFMvsBBSS_M1_NoiseComparison_1435435038vs1469227619-1200.pdf
r13134

Loop suppression used to divide out:
BBSS: /ligo/svncommon/SusSVN/sus/trunk/BBSS/H1/BS/SAGM1/Data/Data/2026-07_OLG_tfs_4_BSFMvsBBSS/2026-07_H1SUSBS_M1_CDBIOState1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz_OLGTF.xml
BSFM: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/2023-07-18_1740_H1SUSBS_M1_CDBIOState_1_OLDampingON_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz_OpenLoopGainTF.xml

Non-image files attached to this report
H1 ISC
thomas.shaffer@LIGO.ORG - posted 14:12, Friday 28 August 2026 (91727)
Clipping scan with PR3 in single bounce

In an attempt to look for obvious clipping in the PRC, I scanned around +/-150 urads from our PR3 alignment while in single bounce and with SR2 following along to keep AS_C centered. This was a painfully slow process as I would move PR3 until SRC2 would near its limiters, wait for it to settle down, then move again. I ended up bumped the SRC2 gains way up to help speed this up, but it only helped a bit. 

I saw no signs of clipping in the +/-150 range, so I continued in yaw until AS_C nsum finally started to decrease. This didn't happen until +500urad in Y from our starting point. We stopped here to run some more pertinent tests. I reverted all alignments back to before this test.

Images attached to this report
H1 AOS
louis.dartez@LIGO.ORG - posted 13:00, Friday 28 August 2026 (91726)
PRM beam spot position
At Sheila's suggestion this morning I measured the beam spot position on PRM in PRMI. The drivealign gains that reduce the A2L coupling are P:0.38, Y:0.81. I used the same procedure as in 91701. This corresponds to an offset from center of 0.713 mm in PIT and 1.52 mm in YAW.

Images attached to this report
H1 AOS
louis.dartez@LIGO.ORG - posted 11:49, Friday 28 August 2026 (91724)
MICH and PRCL OLG in PRMI
Here are MICH and PRCL OLGs from today while in PRMI.
Images attached to this report
LHO General
thomas.shaffer@LIGO.ORG - posted 07:34, Friday 28 August 2026 (91720)
Ops Day Shift Start

TITLE: 08/28 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 7mph Gusts, 3mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s 
QUICK SUMMARY: No alarms, calm environment. The EX VEA temperature has been moving around quite a bit the last few days. Looks like this was from the cleanroom being turned on.

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 18:11, Thursday 27 August 2026 (91719)
Thurs EVE Ops Summary

TITLE: 08/27 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

Commissoiners (Elenna, Louis, Camilla) were working on H1.  Once they were done, I let Jim know so he could run SPI injections on HAM2 & HAM3 over night.

LOG:

H1 AOS
louis.dartez@LIGO.ORG - posted 17:33, Thursday 27 August 2026 (91702)
pr2 spot move to determine how close we are to O4 beamspot position on PR2
[Elenna, Sheila, Louis, Keita, + input from others in CR]

This log is for work done yesterday August 26, 2026.

Yesterday we set out to move the beam spot position on PR2 with a dither line to determine whether the current beam spot position is the same as it was during O4. This test is part of the same line of investigation mentioned in 91701. The idea is that if the beam is still at the O4 spot position on PR2 then moving the beam in pit or yaw should result in higher A2L coupling than you would get at the nominal position. This test was done in PRMI. 

We had to pause midway and rethink the execution of this test because we kept losing PRMI lock. 

We used the guardian state PR2_SPOT_MOVE to move the beam spot position on PR2 while monitoring the A2L coupling using a dither on PR2's M3 DITHER bank (8.125 Hz, same as before). The guardian state lets us move the PR3 sliders and it will move IM4 and PR2 to compensate. 

Since this move has downstream effects in the POP path, Elenna held the output on POPAIR RF18_I, which provides the trigger signal for PRCL and MICH. We started off going in the +Yaw direction in steps of 0.3 urad using the PR3 slider. We noticed that each move would kick the MICH and PRCL loops. I was only able to move about 2 urad before losing PRMI. This was repeatable: I lost lock after moving 2.7 urad (yaw slider value -234.0) and later after only moving 2.4 urad (PR3 slider value -234.3). The nominal slider values for PR3 at the start of this test is Yaw: -236.7, Pit:-142.7. 

We considered that we could be falling off of the REFLAIR diode during these moves. REFLAIR_A_RF9_I and REFLAIR_A_RF45_Q are used as the input signals for PRCL and MICH, respectively. Interestingly, we noted that as we continued to move in the +yaw direction the demod diodes would see a small kick while the DC signal (REFLAIR_A_LF) was increasing (ndscope screenshot). This was repeatable and doesn't make sense to me right now. Meanwhile, we were losing power on POPAIR 18 and 90 (not surprising) and on POPX (not surprising). We turned off the DC centering for POPX because PM1 starts to rail pretty quickly if you don't. 

After losing lock a couple of times Elenna suspected that something weird might be happening with the MICH and/or PRCL loops. So she measured the OLGs while I moved the beam spot position on PR2. I've uploaded DTT screenshots of the MICH OLG and PRCL OLG. Both of these OLGs were taken after moving and pausing 2.1 urad away from the nominal position on the PR3 sliders (PR3 slider yaw: -234.6). 

The PRCL OLG looks to have experienced a loss in gain. We tried compensating by increasing the gain, but this didn't help avoid losing lock. The MICH OLG measurement showed some more egregious changes that are not fully understood at the moment. It is not immediately clear to us how moving the spot position on PR2 would result in the OLG changing like this. 

In any case, we think we want to be able to continue moving the spot by moving PR3 in +yaw because the A2L coupling was getting better as we did (dtt_pr2_spot_a2l.png. So it would be nice to be able to repeat this and move further without losing PRMI. 

The DTT used for the A2L coupling measurement lives in my home directory under Templates/pr2_spot_move_a2l.xml. The 8.125 Hz line was injected using awggui.
Images attached to this report
H1 General (OpsInfo)
anthony.sanchez@LIGO.ORG - posted 16:56, Thursday 27 August 2026 (91712)
Thurday Day OPS Report & Manual Initial Alignment Notes.

TITLE: 08/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

Elenna's current Manual Initial Alignment steps: 
Get ALS Gaurdians for Y arm to ETMS WFS OFFLOADED [13], (except X arm is messed up so only for Y arm currently). ETMX was left in Locking [-23] and ETMX and TMSX were touched up to maximixe the ALS-C_TRX. 
Then once they are locked and stable. unlock them.
COMM Beatnote was 6.5 
DIFF was -9 ish
Then use ALIGN_IFO to start a manual Initial alignment. But we cannot use ASC at all because the diodes need to be "rephased" something about the sidebands are all different now.
This means we take ALign IFO to  AQUIRE_XARM_IR[11]. Once that is done.
We go to Aquire PRX.  Moved PRM to to maximize ASC-AS_A_DC_NSUM.
Then went to Prep_for_mitch[41] > mitch dark locked and moved the beam splitter while watching the AS Air cam for maximum darkness and a ring around a center dot.
SR2 Align[58] was ran and automatically worked. Which uses a QPD and does not need sidebands.
Moving SRM while in SRY_LOCKED[62] to maximize ASC_AS_A_DC_NSUM. 
AS_CENTERING[77] also ran with out intervention.
Then take the power back down to 2 watts.
We are ready to try locking!!!

The Verbal Alrams did a weird thing today. The VAC Alarms sounded off for PT-134  , PT152, and PT-180... 
I called Travis over to come check it out and he said everything looks fine. 
PT-134 is tripped due to someone's phone tripped it a while ago.
PT-152 is correctly telling us the pressure because that sensor is indeed at atmospheric pressure between HAM 5 and 7.
And PT-180 was replaced on tuesday but it's new channel name is PT-180_MOD2 now instead of MOD1.
Which brings up the great point that the Verbal's VAC alarm channels need to be updated.

PEM note: 
A garbage truck slammed a garbage dumpster on the ground around 22:49 UTC today. It was felt in the ground by multiple staff's highly calibrated foot seismometer.

Craning over X arm never happened because they ran out of time. Even if it is mentioned in the Reservation system table below.


LOG: 

Start Time System Name Location Lazer_Haz Task Time End
14:39 FAC Kim OpticsLab N Technical cleaning 14:52
14:53 FAC Kim End X N Technical cleaning & Resupply 16:06
15:59 EE Fil LVEA HAM6 yes Checking out a chassis. 16:22
16:08 EE Richard LVEA HAM6 yes Helping Fil hold his tools. 16:22
16:19 ISC Sheila & Elenna LVEA ISCT1 yes Alignment of PD's on ISCT1 17:09
17:21 EE Fil & Sheila LVEA HAM3 y Checking HAM3 Flange cabling 17:51
17:31 DetEngr Betsy LVEA HAM3 y Checking flange cabling for pico motor 17:50
17:36 PEM Robert End X No Working on grounding. 20:11
17:38 TCS Camilla CHeTA Lab N Grabbing parts 17:51
18:12 ISC Sheila, Elenna LVEA Y ISCT1 19:00
18:15 FAC Kim LVEA - Garb checks 19:15
19:05 VAC Jordan Travis LVEA X arm y Craning  19:51
19:06 CDS Dave Remote n DAQ restarts. Now Waiting on the FWs to agree ~21:00 UTC 21:08
20:55 ISC Camilla & Mitchel LVEA Arms YES Replacing Viewport covers with boxes on the Arms need Gatevalves. Mitchel out first. 22:25
20:56 ISC Ryan  & Sheila LVEA ISCT1 yes ISCT1 alignment. 21:36
21:10 Safety Richard LVEA y Taking measurements. 21:25
23:06 PEM Robert EX - Grounding studies 02:06

 

 

H1 TCS
camilla.compton@LIGO.ORG - posted 16:52, Thursday 27 August 2026 (91716)
Fit Check of Modified CHETA camera steering mirror assembly D2500166

Mitch, Camilla, WP#13559

Tyler modified the D2500166 as it was too wide to sit next to the Oplev laser enclosure. Tyler modified: D1300702 and D1300703 so that the box is now ~0.75" offset of the center. Will add more deatils to these modifications in the DCC. 

At the X-arm adapter plate this technically fits but is close to interfering with the  op-lev laser enclosure. The 10-32 bolt next to it will want to be replaced with a button or countersunk bolt.  Photos attached: side view, below view, ruler.

At the Y-arm adapter plate this fits well. Photo attached: side view, below view, ruler.

Images attached to this report
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 10:01, Wednesday 26 August 2026 - last comment - 17:07, Friday 28 August 2026(91688)
BSC9 Annulus Ion Pump Railed

The annulus ion pump for BSC9 just railed, about 15 minutes ago.
Nothing to do for now, but we will asses ASAP to see what is wrong with it.

Images attached to this report
Comments related to this report
gerardo.moreno@LIGO.ORG - 17:07, Friday 28 August 2026 (91733)VE

(Jordan, Gerardo)
And after a couple of taps, is back on.  We will keep an eye on it.

H1 SEI (SEI)
shoshana.apple@LIGO.ORG - posted 18:31, Wednesday 01 July 2026 - last comment - 09:24, Friday 28 August 2026(90851)
CRS Installed on HAM3

[Jim, Shoshana]

Yesterday when I went to put the cover on the CRS to get it ready to move to the clean area right next to HAM3, I noticed one of the flexures (SN 15) was broken [picture attached]. It's unclear how this flexure broke as it had been locked since last Wednesday (?), and it is strange that only one flexure broke.

We decided that it would be better to install a new pair of flexures and re-suspend next to the chamber rather than in the temporary clean room to reduce the risk of them breaking again. So today we wheeled the table the CRS is on to the space next to HAM3 and I re-suspended the CRS there and roughly balanced it.

Following the procedure outlined in E2600210 and work permit 13356,  we moved the CRS to the table and lined everything up so that the CRS baseplate can be bolted directly to the table in one spot.

We installed the fiber feedthrough, and dealt with all the cabling (fiber and DB25) that required Jim to be physically inside the chamber and we'll install the rest of the cable clamps which we can reach from outside the chamber tomorrow and finish connecting all the cables and dog clamping the CRS down (hopefully)

Comments related to this report
shoshana.apple@LIGO.ORG - 09:25, Thursday 02 July 2026 (90874)

Attaching pictures (which I forgot to do last night)

Images attached to this comment
brian.lantz@LIGO.ORG - 09:10, Friday 03 July 2026 (90892)EPO

Congratulations on getting the CRS onto HAM3! I'm tagging EPO

Looking forward to seeing it running

shoshana.apple@LIGO.ORG - 09:24, Friday 28 August 2026 (91721)
Images attached to this comment
Displaying reports 1-20 of 89075.Go to page 1 2 3 4 5 6 7 8 9 10 End