Displaying reports 141-160 of 83003.Go to page Start 4 5 6 7 8 9 10 11 12 End
Reports until 17:41, Tuesday 24 June 2025
H1 General
oli.patane@LIGO.ORG - posted 17:41, Tuesday 24 June 2025 (85310)
Ops Day Shift End

TITLE: 06/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

Currently Observing at 150Mpc and have been Locked for just over 2 hours. Relocking went pretty smooth, with the only issue being DRMI/PRMI taking very long to catch still. During maintenance today, the auxiliary pumps around HAM1 were turned off, and the jitter noise that we had been seeing around 550-600Hz is basically almost fully gone.


LOG:

14:30 Observing at 145Mpc and have been Locked for almost 4 hours
14:45 Out of Observing to run SUS Charge measurements
15:00 Lockloss during SWAP_BACK_ETMX
    - It doesnt look like it was due to anything that was happening with the swap

19:31 Started relocking
    - Initial alignment
    - Lockloss from MOVE_SPOTS
22:33 NOMINAL_LOW_NOISE
22:34 Observing

Start Time System Name Location Lazer_Haz Task Time End
15:03 FAC Chris, Eric XARM n Bee-am sealing 17:32
15:09 FAC Randy LVEA n Drilling holes in a pipe 16:17
15:10 FAC Nellie, Kim LVEA n Tech clean 16:27
15:21 VAC Gerardo, Jordan LVEA, FCETube n Turning off HAM1 pump, replacing gauge in FCETube, craning onto termination slab 19:25
15:33 VAC Janos EX, EY n Pumping line parts collection 18:40
15:39 FAC Tyler XARM n Driving Big Red to move spool 16:39
15:45 SQZ Camilla, Sheila LVEA y(local) SQZT7 work 18:49
15:45 PSL Jason LVEA n Inventory 17:32
15:46 FAC Mitchell LVEA n Inventory 16:09
15:53 CDS Jonathan remote n Rebuilding camera software 16:01
15:54 VAC Travis LVEA n Helping Gerardo and Jordan 17:21
16:07 SUS RyanC CR N OPLEV charge measurements, EY & EX 17:38
16:14 FAC Richard, Ken LVEA n Looking at cable tray near HAM6 16:27
16:15   Christina LVEA n Inventory 16:33
16:16 VAC Jackie FCETube n Joining Jordan and Gerardo 17:14
16:18 CDS Patrick remote n Reimaging VAC Beckhoff computer 19:05
16:33 FAC Randy MX n Craning 18:20
16:33   Christina MY n Taking a photo 17:01
16:36 SEI Jim remote n HAM1 ISI measurements 19:05
16:52 FAC Mitchell FCETube n Inventory 17:59
16:52 FAC Tyler XARM n Meeting up with Chris, Eric, and the bees 17:07
16:57   Keita LVEA n Checking analog camera inventory 17:33
16:59 FAC Kim, Nellie HAM Shack n Tech clean 17:27
17:05 EE Fil, Marc LVEA n Fixing BSC temp sensor 18:35
17:11   Jennie, Leo, Tooba LVEA n Tour 17:42
17:24   Betsy, Brian O, LIGO India people LVEA n LIGO India planning 18:09
17:24   Christina LVEA n Inventory 17:33
17:27 FAC Kim MX n Tech clean 18:28
17:28 FAC Nellie MY n Tech clean 18:58
17:34   Christina HAM Shack n Looking for a forklift 18:17
17:42 SQZ Jennie, Leo LVEA y(local) Joining on SQZT7 18:31
18:16   Betsy + others EY n Looking at stuff 19:05
18:18   Christina LVEA n Still looking for a forklift 18:48
18:49   Camilla OpticsLab n   18:51
19:11   RyanC LVEA n Sweep 19:35
19:37   Matt LVEA n Unplugging a cable 19:40
19:48 EE Fil MX n Dropping stuff off 20:18
20:19 FAC Chris MY, EY n Checking filters 21:16
20:23 FAC Tyler XARM n Checking out more bees 20:51
20:36 VAC Gerardo, Jordan FCETube n Opening FC gate valve 21:09
22:10 PCAL Tony PCAL Lab y(local) Taking stuff 22:16
H1 GRD (ISC)
elenna.capote@LIGO.ORG - posted 17:38, Tuesday 24 June 2025 - last comment - 17:16, Wednesday 25 June 2025(85309)
Guardian edits to speed up ADS

Ryan S., Elenna

Ryan and I are still trying to speed up the MOVE_SPOTS state. Today, Ryan implemented new code that checks the convergence of the loops and only ramps up the ADS gains of loops that are not yet converged to help them converge faster. This appeared to work well, although the state is still slow. We are now taking the spots to the FINAL spots that the camera servos go to, instead of some old spot, so it's possible that which loops that are far off have changed.

Ryan also pointed out that the ENGAGE_ASC_FOR_FULL_IFO state is taking a while because it is limited by the convergence of the PIT3 ADS. This is likely because the POP A offset used in DRMI ASC is not quite right, so I adjusted it for pitch so the PRM should be closer to the full lock position. SDFed.

Images attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 12:55, Wednesday 25 June 2025 (85333)

With regards to ENGAGE_ASC_FOR_FULL_IFO, the three locks that we've had after the adjustment made yesterday have made the state take an average of 4.5 minutes to get through. Before making this change, it was taking us an average of 8.5 minutes (looking at the four locks before this change), so this has made a big improvement for this state!

However, it looks like the main reason why this state still takes a pretty long time compared to most other states is because it's still needing to wait a long time for the PIT3 and YAW3 ADS to converge (ndscope). Here's the log from this last time that we went through ENGAGE_ASC and you can see that most of the time is waiting for ADS. The actual wait timers in there are only 50 seconds of waiting, so the rest of the wait timers (the one second timers) are just from the convergence checker.

Images attached to this comment
Non-image files attached to this comment
elenna.capote@LIGO.ORG - 17:16, Wednesday 25 June 2025 (85350)

I updated the POP A yaw offset so that PRC1 in DRMI will bring the PRM closer to the full lock point and hopefully make convergence in this state faster.

Images attached to this comment
H1 SUS
oli.patane@LIGO.ORG - posted 17:30, Tuesday 24 June 2025 (85288)
SR3 SUSPOINT TFs and regular damping TFs taken for estimator work

The last work that was done for the estimator was back on May 21st 84548. The data that I got then was of the Open Loop TFs for when SR3 OSEMINF gains were nominal (aka what they are now) vs our 'more calibrated' values that are shown in 84367. I then wrote a script that takes in the OLTF traces that were exported from diaggui and divides them for each DOF (results). The average between the two divided traces is what we are going to be using as the gain values needed to counter the 'more calibrated' values. I put these gains in as FM7(previously had old unused gains in) in the DAMP filter bank.

Today I changed the M1 coil driver state to 1, set the OSEMINF gains to the ones listed in 84367,  turned on FM7 for all degrees of freedom in the DAMP filter bank to turn on the gain corrections, changed the gain for DAMP Y to be -0.1 instead of the nominal -0.5, and then took SUSPOINT to M1 transfer function measurements.The measurements can be found in: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/Common/Data/2025-06-24_1700_H1ISIHAM5_ST1_WhiteNoise_SR3SusPoint_{L,T,V,R,P,Y}_0p02to50Hz.xml, in svn as r12356.

After that, I took regular transfer functions with damping on for SR3 M1 to M1. Unfortunately I accidentally took the transfer functions for Pitch with the wrong bin width, so the original xml file there has double the values as the other ones. The saved .mat file, though, has the data all the same size. The measurements can be found in: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/2025-06-24_1900_H1SUSSR3_M1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml, in svn as r12359. The results are found in: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Results/2025-06-24_1900_H1SUSSR3_M1_ALL_TFs.pdf, also r12359.

After these measurements, everything was put back to how it was before, including the OSEMINF gains, the DAMP Y gain, and the DAMP FM7 filters turned back off.

 

Images attached to this report
H1 ISC
anthony.sanchez@LIGO.ORG - posted 17:09, Tuesday 24 June 2025 - last comment - 09:31, Wednesday 25 June 2025(85307)
Range Comparison: April 2024 vs Today.

Range comparison plot:
Command Ran:  python3 range_compare.py 1396833438 1434842418 --span 1800
time 1 is April 11th 2024
time 2 is today at 23:20 UTC June 24th 2025
 

Non-image files attached to this report
Comments related to this report
elenna.capote@LIGO.ORG - 17:25, Tuesday 24 June 2025 (85308)

I ran two brucos, one on NOLINES and one on CLEAN.

bruco NOLINES

bruco CLEAN

Overall, the message of Tony's alog is that, relative to our best range, we have lost 10 Mpc by the time we reach 100 Hz, and an additional 5 Mpc by the time we reach 1 kHz. The brucos above show a lot of low level coherence with: MICH, SRCL, PRCL, REFL RIN. There is a chance that making additional improvements to the feedforward can help. Right now it's hard to tell how many Mpc that gets us back, but it's where we should start.

oli.patane@LIGO.ORG - 09:21, Wednesday 25 June 2025 (85321)

I made a range comparison with a time form last night when we got up to 155Mpc (Jun 25, 2025 05:07:30 UTC (1434863268)) and compared it to a time of good range before the vent, Apr 01, 2025 03:05:42 UTC (1427511960). Here's the range comparison.

Non-image files attached to this comment
elenna.capote@LIGO.ORG - 09:31, Wednesday 25 June 2025 (85322)

This is interesting because it indicates that the range loss at low frequency in DARM now versus right before the vent is much smaller, only 3 Mpc. But looking back to our best range in April 2024, there is even more loss in sensitivity at low frequency.

LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 16:45, Tuesday 24 June 2025 - last comment - 17:58, Thursday 26 June 2025(85303)
Filter Cavity Tube Bad Gauge Removal and Replacement-Replacement

(Jordan V., Gerardo M.)

Today we replaced the MKS gauge at FC-C-1, this is the first 6 way cross inside the filter cavity tube enclosure, we installed serial number 390F00490, twice, yes two times.  It turns out that the flange has some scratches on the knife edge, and it was not going to seal regardless of the effort that we put into it.  Once the gauge was removed the scratches transferred to the copper gasket.  We replaced it with serial number 390F00495, this one seems to be doing good.  New conflat was leak tested and no leak was detectable above 2.42e-10 torr*l/sec.

The old gauge serial number is 390F00406 with a date code of June 2021.

Images attached to this report
Comments related to this report
jordan.vanosky@LIGO.ORG - 16:50, Tuesday 24 June 2025 (85305)

Additional pictures of the knife edge damage/dirty flange from manufacturer.

Images attached to this comment
gerardo.moreno@LIGO.ORG - 17:58, Thursday 26 June 2025 (85375)VE

More photos of the MKS390 gauge due to new found features.

We found some features internal to the gauge, see attached photos, maybe when welding the conflat to the gauge body they did not use shielding gas internal to the gauge.

Future reference, we did a test on the gauge with an annealed copper gasket, no leaks detected above the 1.0e-10 torr*l/sec.  So, if this gauge is deemed good we can use it, contacting vendor with lots of questions.  Serial number 390F00495 is for the featured gauge on attached photos.

Images attached to this comment
H1 General
anthony.sanchez@LIGO.ORG - posted 16:38, Tuesday 24 June 2025 (85302)
Tuesday Ops Eve Shift.


TITLE: 06/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 7mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:
H1 has been Locked for close to an hour.

Note:
CDS Alarm H0:VAC-LY_Y3_PT114B_PRESS_TOUR  alarmed at 1434843240.  Oli metioned that Davis said this is nothing to worry about, I'm just documenting it here.
Everything else looks fine.
 

 

H1 SEI
jim.warner@LIGO.ORG - posted 15:40, Tuesday 24 June 2025 (85300)
Comparing HAM1 ISI motion to HAM1 Passive stack TT L4Cs

I did a very quick search and didn't find any other posts, so I putting a plot here comparing the motion of the pre-vent HAM1 TT L4C passive stack motion to the current HAM1 ISI motion. ISI motion is generally 1-3 orders of magnitude better, only with a very narrow window at 15hz where the passive stack barely reached down to the ISI motion, but only for the x dof. Blue, green and brown are the ISI, cyan, pink and black are the passive stack.

Almost done with the st0 feedforward, X,Y,Z and RY are running. Still have to do tilt decoupling (which will improve low frequency motion), vac work at the chamber kept tripping the ISI during my measurements this morning.

Images attached to this report
H1 SQZ
camilla.compton@LIGO.ORG - posted 15:31, Tuesday 24 June 2025 - last comment - 19:51, Tuesday 24 June 2025(85295)
7dB on SQZ HD with New Spot in OPO Crystal

Sheila, Camilla. WP#12573

Sheila and I realigned the Homodyne after it needed to be touched to re-seat one of the PDs in 85116. Sheila balanced powers using the LO waveplate and measured visibility to be 98.4% (11.4mV min 1.46 V max).

We then used SQZ_MANAGER SQZ_READY_HD (needed to change LO gain, see sdf). Attached plot.

Last done by Kevin/Vicky in 84661, they got 6.4 to 7 dB of SQZ, 14.6 dB of anti-SQZ, and 12.1 dB of mean squeezing.

Type NLG Angle SQZ (@300Hz) DTT Ref
LO shot noise N/A N/A Used as 0dB ref 1
ASQZ 10 (+) 204 14.3dB ref 2
SQZ 10 (-) 114 -7dB ref 3
Mean SQZ 10 N/A 10.7dB ref 4
 
OPO Setpoint Amplified Max Amplified Min UnAmp Dark NLG OPO Gain
95uW 0.0530 0.001913 0.005307 9.1e-5 10.16 -8
Images attached to this report
Comments related to this report
kevin.kuns@LIGO.ORG - 19:51, Tuesday 24 June 2025 (85313)

After Sheila and Camilla realigned the homodyne, I tried estimating the NLG by looking at the ADF beatnote while varying the squeezing angle to map out the ADF-LO ellipse as described in the ADF paper.

The channels used to measure the beatnote were H1:SQZ-ADF_HD_DIFF_NORM_{I,Q}. The squeeze angle was varied by sweeping H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG from 0 to 275 degrees with both polarities of the CLF servo (H1:SQZ-CLF_SERVO_IN2POL).

I then fit the data to an ellipse. The ratio of the semi-major to semi-minor axes is denoted by G in the ADF paper and was then used to compute the NLG. This results in
G: 5
NLG: 8.8

By comparison, an NLG of 10.2 is equivalent to G=5.4, which is consitent with the accuracy of this data. This kind of measurement could probably be improved in the future by taking more data near the anti-squeezing points on the ellipse.

It's not obvious from the ADF paper how to convert from G to NLG and back. For posterity, the functions I used for these conversions are also attached. These use the "alternative OPO configuration" shown in Fig 6(a) of the ADF paper.

The data is located at /ligo/gitcommon/squeezing/sqzutils/data/NLG_HD_06_24_2025.h5.

Images attached to this comment
Non-image files attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 15:30, Tuesday 24 June 2025 - last comment - 15:52, Tuesday 24 June 2025(85299)
Vacuum burt-restore script

Following the restart of any vacuum Beckhoff controller it is necessary to burt-restore the settings back to what they were prior to the restart (e.g. CP PID settings). We are using the slow controls Vacuum SDF to display which settings need to be restored, but the SDF cannot do the revert itself since it runs on a non-authorized server (h1ecatmon0) which does not have write access to the vacuum system.

Previously I had written a script in user vacuum's home directory on zotvac0 to do this restore for h0vaclx, today I made the script generic, taking the system to be restored as an argument.

The restoration process following a restart of a vacuum system is now:

On any CDS workstation open the vacuum SDF window showing the differences list, we will use this to verifty the restore worked correctly

As user vacuum on zotvac0 (restricted access to vacuum team, CDS and OPS) run the ./burt_restore_vac.bsh script with no arguments to get the usage:

vacuum@zotvac0:~$ ./burt_restore_vac.bsh 
Incorrect arguments given
 
Usage:
    burt_restore_vac.bsh SYS
    where SYS is one of:
    lx ly ex ey mx my mr

 
This morning I ran the script with argument = ly which correctly restored the h0vacly settings to those in h1vacuumsdf's safe.snap file***

Comments related to this report
david.barker@LIGO.ORG - 15:52, Tuesday 24 June 2025 (85301)

***

unfortunately a late morning change to reduce CP1's LLCV value from 37.4% to 29.0% in preparation for today's dewar fill did not make it to the h1vacuumsdf_safe.snap file and so the burt restore restored the 37.4% value. This was caught in a few hours by CP1's TCs dropping below -110C and its discharge line pressure rising to 0.3PSIG.

H1 SQZ (OpsInfo)
camilla.compton@LIGO.ORG - posted 15:20, Tuesday 24 June 2025 (85297)
OPO Crystal Spot Moved

Sheila, Camilla, WP#12632.

Moved OPO Crystal Spot using instructions in 80451, last done in January 2025 82134.

For all of the used spots we moved through, to the left of the co-resonance, the loss suddenly increased as in the spot to the side of the current co-resonance was in the past used. This made us think that we are set to a different temperature to other times we have moved the spot. 

Measured NLG to be 10 with the OPO TRANS setpoint set to 95uW, the NLG was very low 7 with 80uW, hence staying at 95uW, the NLG's seemed to have dropped this week 85252, we don't know why. 

Tagging OpsInfo: This change will mean that for the next week or so we'll need to more regularly adjust the OPO TEC temperature, instructions are in 80461. Should be done pro-actively when relocking and if range is low in observing. Pop out of observing to adjust while in Observing. 

Non-image files attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 15:10, Tuesday 24 June 2025 (85298)
New rev-lock model build/install procedure

Today's h1asc model change was a good opportunity to consolidate the new model build procedure now that H1 models are rev-locked (source code locked to specific subversion revision numbers).

1) build the model as normal to verify that it builds (user controls on h1build)

> rtcds build h1asc

2) run model through check_model_changes to check if DAQ changes are pending (user myself on opslogin0)

> check_model_changes h1asc

In this case 4 fast channels are to be added to the DAQ

3) run rev-update on model to check subversion status (user controls on h1build)

> rtcds rev-update h1asc

This showed that the h1asc.mdl model has local mods pending commit.

4) commit local mods to subversion (user myself on opslogin0)

Using the DAQ change information from 2) I committed h1asc.mdl to subversion

> svn ci -m "Elenna 23jun2025 add 4 DQ chans DC6_[P,Y]_[IN1,OUT]" h1asc.mdl

5) run rev-update again (user controls on h1build)

> rtcds rev-update h1asc

At this point I was able to accept svn HEAD as the rev-lock versions for h1asc's source files

6) do a rev-locked build of h1asc (user controls on h1build)

> rtcds build --rev-locked h1asc

7) install the model (user controls on h1build)

> rtcds install h1asc

 

H1 SUS
jeffrey.kissel@LIGO.ORG - posted 14:58, Tuesday 24 June 2025 (85289)
2025-06-24 Inventory of (UK Satamp) SUS Damping Loop Open Loop Gain TF Measurements
J. Kissel

In order to prepare for implementing ECR ECR E2400330 which improves the whitening within the UK sat amps to improve the OSEM signal chain's total sensor noise between 0.05 and 10 Hz (see CSWG:11249 for a model of the noise improvement), I want to be sure we have a up-to-date measurement of the damping loop's suppression. This is so it can be divided out from the estimate of sensor noise before vs. after the change. Also, in general, it's good it we have pre-tuned templates for open loop gain transfer functions, as they use a markedly different excitation than "standard" "health check" transfer functions because the excitation must go through the damping loop controller filter.

Note: if we compensate for the change in satamp frequency response well (with the anti-whitening filters in the OSEMINF banks), then the open loop gain / loop suppression / close loop gain should remain unchanged across the whitening filter change, so one we have these we shouldn't need to take them again (unless commissioning demands more changes to the filters). 

Since this kind of inventory is best done digitally for other folks reference and in case I have to delegate, I share it here. 
The following is a table of available and believed "should be the same as now" open loop gain TF templates and aLOGs for all suspensions with UK satellite amplifiers (and the Filter Cavity HSTSs FC1 and FC2 for good measure).
Where there isn't templates that are "still valid," I give a brief note as to why. 

Optic    aLOG             Templates                                                                                         Still Valid?        If not, why not?
ETMX M0  (n/a)            none                                                                                              NO                  *Never measured
ETMX R0  (n/a)            none                                                                                              NO                  *Never measured

ETMY M0  LHO:6933         2013-07-??_????_H1SUSETMY_M0_*_WhiteNoise_OLGTF.xml                                               NO                  *Way old, not enough DOFs
ETMY R0  LHO:68405        2023-04-04_1731_H1SUSETMY_R0_WhiteNoise_*_0p01to50Hz_OpenLoopGainTF.xml                           Yes                 *But would be good to remeasure w/ and w/o R0 tracking

ITMX M0  LHO:7720         2013-09-10_2306_H1SUSITMY_M0_[R,V]_WhiteNoise_OLGTF.xml                                           NO                  *Way old, not enough DOFs
ITMX R0  (n/a)            none                                                                                              NO                  *Never measured

ITMY M0  (n/a)            none                                                                                              NO                  *Never measured
ITMY R0  (n/a)            none                                                                                              NO                  *Never measured

TMSX     (n/a)            none                                                                                              NO                  *Never measured

TMSY     LHO:6654         2013-06-06_1511_H1SUSTMSY_M1_[L,P]_WhiteNoise_OLGTF.xml                                           NO                  *Only L and P measured
 
BS       LHO:71269        2023-07-12_2000_H1SUSBS_M1_CDBIOState_1_WhiteNoise_*_0p01to50Hz_OpenLoopGainTF.xml                Yes                 *Oplev Damping OFF
         LHO:71465        2023-07-18_1740_H1SUSBS_M1_CDBIOState_1_OLDampingON_WhiteNoise_*_0p01to50Hz_OpenLoopGainTF.xml    Yes                 *Oplev Damping ON

MC1      LHO:85291        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          Yes

MC2      LHO:85291        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          Yes

MC3      (n/a)            none                                                                                              NO

PRM      LHO:85292        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          NO                  *EPICs gains changed since

PR2      LHO:85292        2022-10-12_2020_H1SUSPR2_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          NO                  *EPICs gains changed since

PR3      LHO:64152        2022-07-26_1820_H1SUSPR3_M1_WhiteNoise_*_0p02to50Hz_OpenLoopGainTF.xml                            Yes

SRM      LHO:85285        2025-06-24_1704_H1SUSSRM_M1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF.xml                           NO                  *EPICs gains changed since

SR2      LHO:65314        2022-10-13_1900_H1SUSMC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          NO                  *EPICs gains changed since

SR3      LHO:85255        2025-05-21_1800_H1SUSSR3_M1_WhiteNoise_*_0p02to50Hz_OpenLoopGainTF.xml                            Yes

FC1      LHO:85290        2022-10-14_2330_H1SUSFC1_M1_CDBIOState_1_WhiteNoise_*_0p01to100Hz_OpenLoopGainTF_new.xml          Yes

FC2      (n/a)             none                                                                                             NO

OMC      LHO:60054        2021-09-28_1640_H1SUSOMC_M1_WhiteNoise_*_0p02to50Hz_OpenLoopGain_2014vs2021Designs.xml            Yes

IM1      LHO:64039        2022-07-19_H1SUSIM1_M1_WhiteNoise_*_OLG.xml                                                       Yes

IM2      LHO:64039        2022-07-19_H1SUSIM2_M1_WhiteNoise_*_OLG.xml                                                       Yes

IM3      LHO:64039        2022-07-19_H1SUSIM3_M1_WhiteNoise_*_OLG.xml                                                       Yes

IM4      LHO:64039        2022-07-19_H1SUSIM4_M1_WhiteNoise_*_OLG.xml                                                       Yes 

So -- to we really need to focus our measurement energy on the QUADs which have really never been characterized and the recycling cavity HSTS which have their EPICs gains changed in 2023.
The good news is that 2023 me tuned a full set of QUAD R0 open loop gain TF templates using ETMY, so these templates should be viable for both the rest of the R0 chains as well as the main chain with little-to-no tuning (assuming alignment biases are not eating up a different amount of DAC range).
That leaves on the TMTS not having tuned templates, so that's where we'll have to spend our tuning time.
We obviously have templates that will work for the missing / out-of-date HSTSs.

I'll begin the campaign during upcoming Tuesdays, in advance of making the ECR E2400330 change.
H1 CDS
david.barker@LIGO.ORG - posted 14:41, Tuesday 24 June 2025 - last comment - 08:24, Friday 27 June 2025(85296)
CDS Maintenance Summary: Tuesday 24th June 2025

WP12623 h1asc add fast channels to DAQ

Elenna, Dave:

A new h1asc model was rev-locked and installed. Four new fast DQ channels were added to the DAQ (channel, rate):

> H1:ASC-DC6_P_IN1_DQ, 256
> H1:ASC-DC6_P_OUT_DQ, 512
> H1:ASC-DC6_Y_IN1_DQ, 256
> H1:ASC-DC6_Y_OUT_DQ, 512

DAQ restart needed.

WP12570 Restart Digivideo Cameras with latest pylon

Patrick, Jonathan, Dave:

Jonathan updated pylon on h1digivideo[4,5,6] and restarted all the camera servers on these machines. This should fix the bug of stuck open files accumulating when the camera connection is interrupted.

No DAQ restart needed.

Add PID SMOO channels to vacuum SDF

Dave:

Prior to today's h0vacly restart I added the missing CP PID-control SMOO channels to the vacuum SDF monitor.req and safe.snap files. SDF was restarted 08:29. No DAQ restart needed.

WP12577, 12608, 12615 Upgrade LY Vacuum Controls

Janos, Gerardo, Patrick, Jonathan, Erik, Dave:

Patrick installed a new h0vacly system this morning. Main items are:

Pleae see Patrick's alog for details.

A extended DAQ restart was required, renaming Ion Pump raw minute trend files for uninterrupted lookback and construcing new PT100 (HAM1) raw minute trends following the upgrade of h0vaclx last Tuesday (17th June 2025).

DAQ Restart

Jonathan, Erik, Patrick, Dave:

Immediately following the restart of h1asc at 11:52, the DAQ was restarted using the following procedure:

  1. both trend writers were turned off, allowing raw minute trend file changes on a static system
  2. ip_copy_scripts.bsh was ran on both TWs, for each Ion Pump channel which is being renamed, this copied the old file into the correct directory for the new file, preserving recent lookbacks.
  3. Erik ran his script to merge the previous HAM1 PT100 data sets into the new channel name.
  4. A new H0EPICS_VACLY.ini was generated
  5. 0-leg was restarted, followed by a EDC restart on h1susauxb123
  6. 1-leg was restarted, requiring a second restart of GDS1.

It was at this late point that I remembered that the temporary H1 version of PT100B is no longer needed, and indeed this channel has no data following the removal of the PT100B Volts channel from h0vacly. However since it is still in the EDC, we need to continue running the temporary IOC until the next DAQ restart. I've removed it from edcumaster.txt as a reminder.

GPS Leap Seconds Updates

Jonathan, Erik, Dave:

Erik's FAMIS task reminded us that the leapseonds files expiration date of 30 June 2025 is rapidly approaching. Although no leap seconds are to be applied, the files need to be updated to reset their expiration dates. Please see Erik and Jonathan's alog for more details.

DNS testing 

Erik:

ns1 (backup DNS server) was used by Erik to see if we can reproduce the error whereby loss of connection to GC caused internal CDS name resolution issues. It did not.

Comments related to this report
david.barker@LIGO.ORG - 16:42, Tuesday 24 June 2025 (85304)

Vacuum Ion Pump channel name changes (old-name, new-name)

 

H0:VAC-FCES_IP23_II123_AIP_IC_VOLTS H0:VAC-FCES_IPFCC9_IIC9_AIP_IC_VOLTS
H0:VAC-FCES_IP23_II123_AIP_IC_VOLTS_ERROR H0:VAC-FCES_IPFCC9_IIC9_AIP_IC_VOLTS_ERROR
H0:VAC-FCES_IP23_II123_AIP_IC_MA H0:VAC-FCES_IPFCC9_IIC9_AIP_IC_MA
H0:VAC-FCES_IP23_II123_AIP_IC_MA_ERROR H0:VAC-FCES_IPFCC9_IIC9_AIP_IC_MA_ERROR
H0:VAC-FCES_IP23_II123_AIP_IC_LOGMA H0:VAC-FCES_IPFCC9_IIC9_AIP_IC_LOGMA
H0:VAC-FCES_IP23_II123_AIP_IC_LOGMA_ERROR H0:VAC-FCES_IPFCC9_IIC9_AIP_IC_LOGMA_ERROR
H0:VAC-FCES_IP23_VI123_AIP_PRESS_TORR H0:VAC-FCES_IPFCC9_VIC9_AIP_PRESS_TORR
H0:VAC-FCES_IP23_VI123_AIP_PRESS_TORR_ERROR H0:VAC-FCES_IPFCC9_VIC9_AIP_PRESS_TORR_ERROR
H0:VAC-FCES_IP24_II124_AIP_IC_VOLTS H0:VAC-FCES_IPFCD1_IID1_AIP_IC_VOLTS
H0:VAC-FCES_IP24_II124_AIP_IC_VOLTS_ERROR H0:VAC-FCES_IPFCD1_IID1_AIP_IC_VOLTS_ERROR
H0:VAC-FCES_IP24_II124_AIP_IC_MA H0:VAC-FCES_IPFCD1_IID1_AIP_IC_MA
H0:VAC-FCES_IP24_II124_AIP_IC_MA_ERROR H0:VAC-FCES_IPFCD1_IID1_AIP_IC_MA_ERROR
H0:VAC-FCES_IP24_II124_AIP_IC_LOGMA H0:VAC-FCES_IPFCD1_IID1_AIP_IC_LOGMA
H0:VAC-FCES_IP24_II124_AIP_IC_LOGMA_ERROR H0:VAC-FCES_IPFCD1_IID1_AIP_IC_LOGMA_ERROR
H0:VAC-FCES_IP24_VI124_AIP_PRESS_TORR H0:VAC-FCES_IPFCD1_VID1_AIP_PRESS_TORR
H0:VAC-FCES_IP24_VI124_AIP_PRESS_TORR_ERROR H0:VAC-FCES_IPFCD1_VID1_AIP_PRESS_TORR_ERROR
H0:VAC-FCES_IP25_CS187_STATUS H0:VAC-FCES_IPFCH8A_CSH8A_STATUS
H0:VAC-FCES_IP25_II187_IC_VOLTS H0:VAC-FCES_IPFCH8A_IIH8A_IC_VOLTS
H0:VAC-FCES_IP25_II187_IC_VOLTS_ERROR H0:VAC-FCES_IPFCH8A_IIH8A_IC_VOLTS_ERROR
H0:VAC-FCES_IP25_II187_IC_AMPS H0:VAC-FCES_IPFCH8A_IIH8A_IC_AMPS
H0:VAC-FCES_IP25_II187_IC_AMPS_ERROR H0:VAC-FCES_IPFCH8A_IIH8A_IC_AMPS_ERROR
H0:VAC-FCES_IP25_VI187_PRESS_TORR H0:VAC-FCES_IPFCH8A_VIH8A_PRESS_TORR
H0:VAC-FCES_IP25_VI187_PRESS_TORR_ERROR H0:VAC-FCES_IPFCH8A_VIH8A_PRESS_TORR_ERROR

 

david.barker@LIGO.ORG - 08:24, Friday 27 June 2025 (85386)

Tue24Jun2025
LOC TIME HOSTNAME     MODEL/REBOOT
11:52:26 h1asc0       h1asc       <<< Elenna's new asc model

not shown, shutdown of both TW0 and TW1 for file manipulation at this point
12:17:51 h1daqdc0     [DAQ] <<<  0-leg restart
12:18:03 h1daqfw0     [DAQ]
12:18:03 h1daqtw0     [DAQ] 
12:18:05 h1daqnds0    [DAQ]
12:18:12 h1daqgds0    [DAQ]
12:18:15 h1susauxb123 h1edc[DAQ] <<< edc restart with new vacuum channel list
12:24:09 h1daqdc1     [DAQ] << 1-leg restart
12:24:22 h1daqfw1     [DAQ]
12:24:22 h1daqtw1     [DAQ]
12:24:23 h1daqnds1    [DAQ]
12:24:31 h1daqgds1    [DAQ]
12:25:06 h1daqgds1    [DAQ] <<< gds1 second restart
 

H1 CAL (CAL, DetChar)
kiet.pham@LIGO.ORG - posted 14:04, Tuesday 24 June 2025 - last comment - 14:11, Tuesday 24 June 2025(85293)
NonSENS 58-60Hz noise injection since Aug 24th 2024

Kiet, Evan, Anamaria 

We noticed that since August 24th, 2024—following the detector maintenance break in O4b—NonSENS has been consistently injecting noise into the 58–60 Hz band.

The ratio of strain after/before cleaning has been tracked via the DetChar summary pages. Attached to this alog are three examples, taken on August 24th, 2024; December 23rd, 2024; and March 31st, 2025. The peak around 58–60 Hz appears to grow over this period, and and remains present after the O4c commissioning break. 

We’ve also attached the NonSENS noise budget for March 31st, 2025. It shows a peak in the jitter noise at 58–60 Hz, which aligns with the band NonSENS has been injecting noise into, so perhaps it is not subtracting jitter correctly? 
 

Images attached to this report
Comments related to this report
kiet.pham@LIGO.ORG - 14:11, Tuesday 24 June 2025 (85294)CAL, DetChar

Same thing can be said for the peak in the ratio after/before cleaning at 28-29 Hz 

H1 TCS (DetChar-Request)
camilla.compton@LIGO.ORG - posted 13:20, Monday 23 June 2025 - last comment - 11:58, Thursday 26 June 2025(85247)
2Hz Comb in DARM from ITMX HWS Camera?

Ansel, Sheila, Camilla

Last week, Ansel noticed that there is a 2Hz comb in DARM since the break, similar to that that we've seen from the HWS camera sync frequency and power supplies and fixed in 75876.  The cabling has not been changed since, the camera sync frequency has been changed.

Our current camera sync frequencies are: ITMX = 2Hz, ITMY = 10Hz. We have typically seen these combs in H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_Y_DQ. With a 0.0005Hz BW on DTT I can't easily see these combs, see attached.

Images attached to this report
Comments related to this report
evan.goetz@LIGO.ORG - 13:31, Monday 23 June 2025 (85254)DetChar
It may be difficult to see in a standard spectrum, but can be clearly seen in Fscan plots linked off of the summary pages. For the "observing" Fscan, the interactive spectrum plot shows the 2 Hz comb marked automatically. See the attached image of H1:GDS-CALIB_STRAIN_CLEAN
Images attached to this comment
camilla.compton@LIGO.ORG - 17:04, Tuesday 24 June 2025 (85306)

Verifed that the cabling has not changed since 75876.

Next steps we should follow, as listed in 75876 would be to try using a different power supply or lowering the voltage to +12V. Or, there is a note suggesting Fil could make a new cable to power both the camera and CLink's via the external supply (14V is fine for both). 

evan.goetz@LIGO.ORG - 18:30, Tuesday 24 June 2025 (85312)DetChar
Thanks Camilla. If anything can be done more rapidly than waiting another week, it would be very much appreciated. Continuing to collect contaminated data is bad for CW searches.
camilla.compton@LIGO.ORG - 15:11, Wednesday 25 June 2025 (85341)

Matt and I turned down the Voltage supplied from 14V to 12V for each camera at ~22:00UTC when the IFO was relocking. Verified HWS cameras and code still running.

We also will plan to have Dave reimpliemnt the hws_camera_control.py script he wrote in 74951 to turn the HWS's off in Observing until we fix this issue.

kiet.pham@LIGO.ORG - 11:58, Thursday 26 June 2025 (85361)

The 2 Hz comb is still present in H1:GDS-CALIB_STRAIN_CLEAN after the voltage change (before the software update)

Images attached to this comment
Displaying reports 141-160 of 83003.Go to page Start 4 5 6 7 8 9 10 11 12 End