Displaying reports 1101-1120 of 82965.Go to page Start 52 53 54 55 56 57 58 59 60 End
Reports until 15:39, Tuesday 06 May 2025
H1 PEM (CDS)
ryan.crouch@LIGO.ORG - posted 15:39, Tuesday 06 May 2025 - last comment - 11:53, Wednesday 07 May 2025(84295)
Diode room dust monitor issues today

The DM first starting having issues at ~11am 2 weeks ago on April 22nd (Tues) for seemingly no reason, there wasn't any work or alogs that day that would made us suspicious of causing this.

Following my alog comments on alog84282, Dave showed me where the physical comtrol box is in the CER, restarting it brought the connection back but I then found that the dust monitor had no flow :(. This DM hasn't been used since we got it calibrated in April of 2024, so I swapped it for the last pumpless spare we had which has good flow but now it's not connecting again. I've tried powercycling the DM itself, the ioc, and the comtrol box then the ioc which is what got the other DM to reconnect, and it still getting "No reply from device within 1000 ms" for all its PVs. The DM it self is working and reading counts properly.

Doing a telnet network status (comand "ss -e") on h0epics for the diode room port yielded:

timer:(keepalive,38min,0) uid:1001 ino:20939307 sk:ffff8800b67bd500
ESTAB       0      0                                                                                        10.105.0.80:37347                                                                                    10.105.0.100:8000 

 

Comments related to this report
ryan.crouch@LIGO.ORG - 11:53, Wednesday 07 May 2025 (84304)

I opened up the DM that had no flow to find that the internal tubing was not even connected, I swapped this one back this morning and it came right back no problem and we can see it on epics. The one that I took off has some kind of network issue.

Images attached to this comment
LHO General (EPO, PEM, SEI)
corey.gray@LIGO.ORG - posted 15:27, Tuesday 06 May 2025 (84294)
EX Wind Fence Status: Remaining 3-Old Fence Panels Removed, Compacting Soft Sand, Start Upgrade Installation

(CoreyG, MitchR, RandyT, JimW)

Previous work posted here.

Today started with Randy and Mitch getting the small green tractor to EX and then working on compacting some of the very soft sand around the wind fence (on the front side of the Wind Fence---closest to EX).

Started to remove the final 3-wind fende panels (of 6 total).  While driving the orange rental manlift (on the backside of the wind fence), it managed to get dug in some pretty deep sand a few times.  On the last dig-in, we kept the manlift here (dug out/compacted sand around it and focused work on the furthest away wind fence panel since we already had the orange manlift here).  The plan is to do everything for this panel location all at once:

  1. Remove old (crappy) hardware,
  2. Install better hardware,
  3. Clamp horizontal wires to the end/furthest pole,
  4. Start tensioning the 5-horizontal wires into place
  5. Install new wind fence panel

Today we made it to step 4 and did the 1st/bottom horizontal wire.  

We ran out of the thick wire, so the trailer was brought back to the Corner Station so the 1200lb spool can be loaded into the trailer in the morning.  Then will continue getting that 1-panel installed....and then work on getting the orange manlift unstuck.

Images attached to this report
H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 13:55, Tuesday 06 May 2025 (84289)
RM1 and RM2 Signs... Again
J. Kissel

It was brought to my attention that the DC centering loops for the REFL path weren't working, so we revisited the sign of the RM1 and RM2 signal chains to confirm the functionality. 

Recall, 
- 2025-04-21 Daniel Fil and Marc found that raw ADC input voltage for OSEM sensor readbacks for the RMs were negative, and have been for over a decade, discovered as they replaced the in-air, sat-amp to vac feedthru cable which flipped the sign for both RM1 and RM2 OSEM sensors. LHO:84027
- 2025-04-25 Daniel, acknowledging that this OSEM sensor sign flip should be accounted for somewhere, decided to stick the sign flip in the 4x COILOUTF gains, typically reserved for magnet polarity compensation. LHO:84123
He acknowledged that putting the compensating sign there would impact the REFL WFS DC centering loops, and we've later realized this will also impact the alignment sliders. 
- 2025-04-29 For the above three "don't put the sign flip there!" reasons, on 2025-04-29, I reverted Daniel's COILOUTF gain sign flip. LHO:84186
That means that regardless of whether RM1 or RM2 have the wrong magnet polarity (see LHO:40853 which concluded it was RM2***), the actuator chain's sign will be the same as it has been for a very long time, and no ISC or alignment loops should need adjusting.
I left that aLOG with a "we'll adjust the damping loop signs once the in-chamber work dust settles."
- 2025-04-30 Rahul, a day later, wanted to resolve the remaining issue. I then communicated to Rahul that we needed to flip the sign in the DAMPING loops, and *only* in the DAMPING loops, because these are the only loops that would need to be changed. He instead re-flipped the coil output filter COILOUTF gains again, see LHO:84204, and accepted them into SDF.

So, today, 2025-05-06
I again reverted the sign back to how they've been since 2013 
    $ caget H1:SUS-RM1_M1_COILOUTF_UL_GAIN H1:SUS-RM1_M1_COILOUTF_LL_GAIN H1:SUS-RM1_M1_COILOUTF_UR_GAIN H1:SUS-RM1_M1_COILOUTF_LR_GAIN
    H1:SUS-RM1_M1_COILOUTF_UL_GAIN 1
    H1:SUS-RM1_M1_COILOUTF_LL_GAIN -1
    H1:SUS-RM1_M1_COILOUTF_UR_GAIN -1
    H1:SUS-RM1_M1_COILOUTF_LR_GAIN 1

    $ caget H1:SUS-RM2_M1_COILOUTF_UL_GAIN H1:SUS-RM2_M1_COILOUTF_LL_GAIN H1:SUS-RM2_M1_COILOUTF_UR_GAIN H1:SUS-RM2_M1_COILOUTF_LR_GAIN
    H1:SUS-RM2_M1_COILOUTF_UL_GAIN -1
    H1:SUS-RM2_M1_COILOUTF_LL_GAIN 1
    H1:SUS-RM2_M1_COILOUTF_UR_GAIN 1
    H1:SUS-RM2_M1_COILOUTF_LR_GAIN -1

and now have also flipped the damping loop sign, to account for the OSEM sensor readback sign change fixed from the in-air satamp to feedthru change
    $ caget H1:SUS-RM1_M1_DAMP_L_GAIN H1:SUS-RM1_M1_DAMP_P_GAIN H1:SUS-RM1_M1_DAMP_Y_GAIN
    H1:SUS-RM1_M1_DAMP_L_GAIN      1
    H1:SUS-RM1_M1_DAMP_P_GAIN      1
    H1:SUS-RM1_M1_DAMP_Y_GAIN      1
    $ caget H1:SUS-RM2_M1_DAMP_L_GAIN H1:SUS-RM2_M1_DAMP_P_GAIN H1:SUS-RM2_M1_DAMP_Y_GAIN
    H1:SUS-RM2_M1_DAMP_L_GAIN      1
    H1:SUS-RM2_M1_DAMP_P_GAIN      1
    H1:SUS-RM2_M1_DAMP_Y_GAIN      1

This *positive* damping loop gain is markedly different than any other suspension, which have damping loop gains negative. Now I'm pretty confident that means that RM1's magnet polarities have been installed incorrectly, rather than RM2 as declared in 2018 ***.
However, because we tried during this vent and can't access the magnets to verify the polarity, let alone change it (see LHO:84178), we will leave this situation as is because we don't want to have to think about the down-stream impacts of alignment and DC centering.

That being said, the ISC team is going to put a positive digital alignment offset in PIT and YAW now, and will confirm that this steers the beam according to standard SUS convention:
    :: with a right-handed coordinate system defined by +L perpendicular to, and coming out from, the HR surface, and +V pointing up,
    :: +PIT should push the optic "down" curling around the +T access, and 
    ::: +YAW should push the optic "counter clockwise, if you're looking from above the mirror, down the -V axis." 
If they find this backwards, the may request a change...

For now, in this sign configuration, I've
- Confirmed that the damping loops close and are stable, and
- Saved the current sign state into the userapps repo copy of the h1sushtts_safe.snap, to which the target area's safe.snap and OBSERVE.snap both point,
    /opt/rtcds/lho/h1/target/h1sushtts/h1sushttsepics/burt$ ls -l safe.snap 
        lrwxrwxrwx 1 controls advligorts 64 Oct  5  2017 safe.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sushtts_safe.snap
    /opt/rtcds/lho/h1/target/h1sushtts/h1sushttsepics/burt$ ls -l OBSERVE.snap 
        lrwxrwxrwx 1 controls advligorts 64 Jun 22  2018 OBSERVE.snap -> /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sushtts_safe.snap


Attached are
    - a screenshot of me accepting the correct, above mentioned, COILOUTF and DAMP gains in SDF (I swear and promise I hit accept after I took the shot.)
    - a one-month trend of the RM1 COILOUTF gains, with the above associated timeline called out
    - a one-month trend of the RM2 COILOUTF gains, with the above accociated timeline called out
Images attached to this report
H1 ISC (SQZ)
jennifer.wright@LIGO.ORG - posted 13:37, Tuesday 06 May 2025 - last comment - 13:37, Tuesday 06 May 2025(84255)
Mode-matching model for single bounce case

Jennie W, Sheila,

 

I have been working on a numerical model to check against some of our single bounce and full IFO measurements of the OMC to IFO mode-matching. Keita did a similar analysis using single bounce measurements and an alamode mode-matching simulation here alog #71145. In this entry while trying to check input parameters for the model, Sheila, Keita, Camilla and I worked out that the original; design for the OMC telescope has an extra 14 cm between OM1 and the input to the OMC.

 

My model takes the parameters for the bow-tie OMC cavity design from LIGO-T1300189, page six.

distance between two flat mirrors = distance between two curved mirrors =  0.2816m

diagonal distance between one curved and one flat mirror = 0.2844m

The RoC for each curved mirrors is take from LIGO-T1500060

Mirror C6 in table in appendices is curved mirror 1 in OMC design.

RoC CM1  = 2.57321 m

Mirror C5 is CM2

RoC CM2 = 2.57369 m.

Using the ABCD matrices for each mirror and the spaces between them I solved for the q parameter of the circulating mode just inside the input coupler.

This is  q = -0.1408 + 0.7102i m.

This gives a beam waist between the two flat mirrors of 4.9044e-4 m. Note: The following analysis is all for the vertical modes, since the OMC has some astigmatism due to a non-zero angle of incidence in the horizontal direction we simplify our analysis by only considering the vertical modes in the mode propagation, this is especially easy for our particular OMC (OMC001) as it has a very small degree of astigmatism (108 kHz  difference vs the fwhm of the resonance at 667 kHz) between the vertical and horizontal modes.

 

I then start just in front of OM2 using a q parameter (q_pre_OM2 = 0.8902 + 0.8034j) Sheila worked out from propagating the q from table 1 of LIGO-T1200410 for just after SRM using her alamode model from (alog #84089) entry.

I construct some 70 x 70 grid of possible q parameters.

I then propagate this towards the OMC using both the hot (1.75m RoC) and cold (2.1m RoC) that OM2 can have in its two PSAMS states (for calibration of the heater see alog #65276 and for the radii of curvature see alog #71145).

The q parameter can be used to define the electric field amplitude transverse to the beam propagation direction z:

U = 1/q ( exp( -jk ( x2 + y) / 2q ))

where k is the wavenumber of the light and x and y are the transverse distances from the center of the beam in the horizontal and vertical directions.

Using the overlap integral:

O(q1,q2) = | U2 U1|2 / ( |U1|2 |U1|2​ )​​​​​ 

where U1 is the field amplitude for TM 00 mode of the OMC and U2 is the field amplitude of the pre-OM2 mode after propagation to the OMC.

for the OMC field and each of the fields propagated from before OM2 I work out two mode mis-match plots, where mode-mismatch (MM) is:

MM % = (1 - O(q1,q2)) * 100,

in terms of the imaginary and real parts of the q parameter I started with upstream of OM2. See image 1 for the grid of pre-OM2 modes against the mis-match each mode would have with the OMC mode at the OMC after propagating through a cold OM2 and OM3. See image 2 for the same plot but with the mis-match the pre-OM2 grid would have after propagating through a hot OM2 and OM3.

On both images the original mode before OM2 is shown by a white star and the coloured countours show the mode-mis-match percentage at the OMC. The white contour in each plot is a measurement of the single bounce mode-mismatch measured in alog #79229 for the cold state and in alog #78727 for the hot state.

Sheila verified these mode-matching values for the hot and cold state of OM2 by propagating q_pre_OM2 in her model to the OMC and overlapping it with the OMC q parameter from my model.

The points where the two measurement contours overlap give us two possible q parameters for the real mode pre-OM2 in the single bounce state. See the third image, where the blue contour is the mode-mismatch measured with the OM2 in the cold state and the red contour that measured with the OM2 in the hot state. The light blude star is the pre-OM2 q used in my numerical model obtained from Sheila's alamode model.

The two possible qs that match experiment are q1 = 0.593 + 0.925j and q2 = 1.626 + 0.967j.  This gives a beamwaist of 5.597e-4 m located 0.681 m behind OM2 or a beamwaist of 5.722e-4m located 1.714m behind OM2.

Terra Hardwick and others did some on-bench beam profiler measurements in HAM6 (alog #41490) and their model for between OM1 and OM2 seems to be consistent with q1 rather than q2.

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 13:31, Tuesday 06 May 2025 (84284)

The OMC waist used in the orginal mode-matching design document for the OM1-OM2-OM3 telescope (LIGO-T1000317) was 5.09e-4 m.

Note the OMC has two waists, one between the two flat mirrors (closer to the input coupler) and a larger waist between the two curved mirrora.

The waist (in the vertical direction) I calculated for the as-built curvatures was 4.9043e-4 m. This was with the flat mirror-flat mirror distance in the OMC as 0.2816 m and the flat mirror-curved mirror diagonal as 0.2844m.

The waist from Zac Korth's measurements (LIGO-D1300507) of our OMC before installation was 4.907e-4 m (vertical waist between two flat mirrors) with the flat-flat distance as 0.2815m and the flat-curved diagonal distance as 28.42m.

Code used to run analysis is at https://git.ligo.org/aligo_commissioning/omc-mode-matching and the main file is OM2_to_OMC_h_c.m. The commit is 50465375.

LHO VE
jordan.vanosky@LIGO.ORG - posted 13:14, Tuesday 06 May 2025 (84290)
Pumpdown of LN2 Dewar Jackets

After the survey of the large LN2 dewar jacket pressures (alog 84028) we used an ISP500 scroll pump to pump the jackets on CP2 and CP3.

CP3 took ~4 days of pumping to bring the pressure from 220 mtorr to <10 mtorr. CP2 was much faster with about 8 hours of pumping from 18 mtorr to 9 mtorr.

All other tanks (excluding CP4 not in use) had jacket pressures around 10 mtorr, so no additional pumping needed.

Closing WP 12498

H1 General (DetChar, PEM, SEI)
debasmita.nandi@LIGO.ORG - posted 12:50, Tuesday 06 May 2025 (84283)
Effect of microseismic ground motion on DARM sensitivity

Debasmita, Preeti, Gaby

Robert did some injections at 0.2 Hz in the BS HEPI which showed a slight increase in DARM. We wanted to check further if the microseismic ground motion (0.1-1.0 Hz) is creating any noise in LHO as it does in LLO. For this, we chose the glitches in DARM picked up by omicron, having frequency in the range 10-60 Hz and SNR in the range 5-20.

  glitch rate vs ground motion in 0.1-0.3 Hz glitch rate vs ground motion in 0.3-1.0 Hz
Pearson correlation coefficient 0.605 0.472
Spearman correlation coefficient

0.602

0.439

The attached pdf shows qscans of some of the glitches chosen from high microseismic days. It is not very clear from the qscans if the glitches have arch like morphology, which is usually the case for glitches caused by scattered light. But, some of the glitches do show repetition within short time interval which make us suspect if they are produced by scattered light. We are still working on this to figure out if it is the process of scattering which is upconverting the low frequency ground motion to create noise in the 10-60 Hz band.

In summary, it looks like the microseismic ground motion is affecting the DARM sensitivity at LHO, maybe not as much as it does at LLO.

Images attached to this report
Non-image files attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 12:40, Tuesday 06 May 2025 - last comment - 13:06, Tuesday 06 May 2025(84286)
CDS Maintenance Summary: Tuesday 6th May 2025

WP12510 Add Geist environment sensors

Jonathan, Dave:

Last Friday I started five EPICS IOCs for the four new out-building sensors and one for the existing MSR sensor.

Yesterday I installed the MX and MY Geist watchdog 1250 sensor units in the CDS VEA racks (details in forthcoming alog).

Today we added the new EPICS Channels to the EDC+DAQ. A new H1EPICS_ENV.ini file was created, it is generated by running generate_env_ini.py

This new INI was added to the edcumaster.txt file.

WP12511 Add h1daqfw2 EPICS LOAD MON channels to DAQ

Jonathan, Dave:

A new H1EPICS_CDSMON.ini was created with the addition of h1daqfw2's channels.

New JAC Slow Controls channels

Daniel, Dave:

A previous slow controls upgraded generated new INI channels for the JAC system. Back then we elected to not add them to the DAQ immediately, rather wait for the next target-of-opportunity, which was today.

DAQ restart

Jonathan, Erik, Dave:

The DAQ was restarted to install the new channels for:

No major issues, GDS0 needed a second restart. Due to vent activities we did not take the trend writers offline for this restart, rather just restarted the EDC following the 0-leg restart.

Jonathan tested his new restart-less frame writer during this restart.

EDC channel count 59188 + 84 = 59,272 

Comments related to this report
jonathan.hanks@LIGO.ORG - 13:06, Tuesday 06 May 2025 (84287)

This daqd restart was used as a test of h1daqfw2's ability to adjust on the fly. It went well. As expected the new code saw the changes and adjusted.

Amoung the changes were additions to the system monitoring channels.  We did the restart towards the end of the hour.  Normally that would mean losing close to an hours worth of trend data.  In this case the framewriter adjusts its channel list on the fly.  Below you can see two channels dumped from a 1hr minute trend frame.  The ...H1DAQFW1... was an old pre-existing channel, ...H1DAQFW2... channel was new.  You can see that the new channel was added midway with a zero fill of the data before it existed, while the older channel was not impact (or thrown away with the daqd restart).

In addition, over the weekend I figured it wouldn't take too much work to put a minimal nds1 interface onto the framewriter.  So both Erik and I were able to take some simple measurements through the daqd restart without interruption.  I did have some issues with streaming the data from the edc (the bit we restarted).  This functionality is very much not ready for control room use, but did work as a proof of principle.

Dump of a old and a new channel from a frame generated while the other frame writers were being restarted:

root@h1daqfw2:/frames/trend/minute/14305# framecpp_dump_channel --channel H1:CDS-MONITOR_H1DAQFW1_CPU_LOAD_PERCENT.mean H-H1_M-1430589600-3600.gwf
Frame file: H-H1_M-1430589600-3600.gwf
DEBUG: Processing channel: H1:CDS-MONITOR_H1DAQFW1_CPU_LOAD_PERCENT.mean
DEBUG: Trying as ADC
DEBUG: Is a ADC
Name:     
Compress: 266 (Endianness: Little Scheme: 10)
Type:     2
NData:    60
NBytes:   416
Data: 6.28729164004326, 4.17406255081296, 3.57833329414328, 3.60958333561818, 3.66750004241864, 3.67500002260009, 3.71916669532657, 3.74739585369825, 3.8817708991468, 3.82260420769453, 5.55906248788039, 3.87937504226963, 3.93562503432234, 3.91968751251698, 3.82739583849907, 3.62052083040277, 3.62010418747862, 3.69833336497347, 3.68625002404054, 3.66718753005068, 5.32447914779186, 3.67375002975265, 3.71656252965331, 3.73489584351579, 3.89322916989525, 3.90125003928939, 3.93125004768372, 3.86749999498328, 3.91406253824631, 3.71927081222336, 5.44343745956818, 3.61781248822808, 3.68937503372629, 3.71395837391416, 3.7930208645761, 3.76812503834565, 3.7355208667616, 3.62187499354283, 3.70145832026998, 3.80020837162932, 5.48312501261632, 3.90666671544313, 3.92562501778205, 3.9627083795766, 3.95802086566885, 3.92802087018887, 3.80010416110357, 3.63791664664944, 3.62510419090589, 3.62989583437641, 5.31531244814396, 2.30302085528771, 0.95135415866971, 3.71520840749145, 3.72906252816319, 3.93354169155161, 4.05625004221996, 2.55833331122994, 2.94218750347694, 4.27510416905085
root@h1daqfw2:/frames/trend/minute/14305#
root@h1daqfw2:/frames/trend/minute/14305# framecpp_dump_channel --channel H1:CDS-MONITOR_H1DAQFW2_CPU_LOAD_PERCENT.mean H-H1_M-1430589600-3600.gwf 
Frame file: H-H1_M-1430589600-3600.gwf
DEBUG: Processing channel: H1:CDS-MONITOR_H1DAQFW2_CPU_LOAD_PERCENT.mean
DEBUG: Trying as ADC
DEBUG: Is a ADC
Name:     
Compress: 266 (Endianness: Little Scheme: 10)
Type:     2
NData:    60
NBytes:   96
Data: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.34916668335597, 4.81020835687717, 4.67812503005068, 4.78708336452643, 4.95833332886299, 4.98052083601554, 4.76249999230107, 4.90572916567326
root@h1daqfw2:/frames/trend/minute/14305#
LHO FMCS
eric.otterman@LIGO.ORG - posted 12:20, Tuesday 06 May 2025 (84285)
Loop temperature changes
The chilled water pumps at Mid X and Mid Y were run for several minutes today in order to exercise the bearings and re-wet the seals. This caused a drop in the temperature trending in NDSCOPE but is not an indication of a problem. 
LHO VE
david.barker@LIGO.ORG - posted 10:35, Tuesday 06 May 2025 (84280)
Tue CP1 Fill

Tue May 06 10:12:46 2025 INFO: Fill completed in 12min 43secs

 

Images attached to this report
H1 ISC (ISC)
valery.frolov@LIGO.ORG - posted 09:44, Tuesday 06 May 2025 (84277)
Regression of PR3 damping signals from C/DHARD dofs

The first four attached plots shows the regression of the PR3 damping signals from C/DHARD dofs (residual motion CHARD_P_IN1 etc).

The last two plots shows the regression of the HAM2 ISI signals from PR3 damping signals - the coherence and spectra.

The data is from one hours low noise H1 lock on March 27, 2025 6:00 UTC.

The corresponding results for L1 are in 76513

Images attached to this report
H1 ISC
camilla.compton@LIGO.ORG - posted 09:27, Tuesday 06 May 2025 (84274)
ISC Alignment Work, Day 4 in HAM1: Diode Connectors fixed, REFL beam profiling finished.

Betsy, Daniel, Fil, Elenna, Jennie, Sheila, Ryan S, Camilla

Day 1: 84193, Day 2: 84228, Day 3: 84230 and 84239

To do's from this alog: Confirm ASC REFL RF cable numbers, decide whether to swap SLED pico cables or medm names, tilt ASC REFL B diode to dump reflected beam and realign.

Other things that still need to be done in REFL path: Move LSC diodes to correct to distance (so beam has 0.2 to 0.3mm beam raduis) and check alignment of beam on these diodes.

After this we will be ready ot move onto the POP path, Keita is checking the expected separation of POP and ASLS beams as it's important we don't center the shared optics on the POP path only.

Images attached to this report
LHO VE
jordan.vanosky@LIGO.ORG - posted 09:02, Tuesday 06 May 2025 (84276)
Morning Purge Air Checks 5-6-25

Dry air skid checks, water pump, kobelco, drying towers all nominal.

Dew point measurement at HAM1 -42.1 °C.

Images attached to this report
H1 SEI
ryan.crouch@LIGO.ORG - posted 08:44, Tuesday 06 May 2025 (84273)
ISI CPS Noise Spectra Check Weekly FAMIS

FAMIS26041 (I meant to do this famis task last Friday)

Most chambers are still elevated due to the vent.

Non-image files attached to this report
LHO FMCS
ryan.crouch@LIGO.ORG - posted 08:33, Tuesday 06 May 2025 (84272)
HVAC Fan Vibrometers FAMIS Check

Closes FAMIS26377

For the CS, everything looks fine. MR_FAN5_170_1 is the noisiest fan at ~ 0.4.

For the OUT buildings, MY_FAN1_270_1 looks fairly noisy and got a little worse 2 days ago.

Images attached to this report
H1 PSL
ryan.crouch@LIGO.ORG - posted 08:27, Tuesday 06 May 2025 (84271)
PSL Status Report - Weekly

Laser Status:
    NPRO output power is 1.828W
    AMP1 output power is 70.35W
    AMP2 output power is 140.2W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 13 days, 19 hr 33 minutes
    Reflected power = 23.39W
    Transmitted power = 105.5W
    PowerSum = 128.9W

FSS:
    It has been locked for 0 days 17 hr and 26 min
    TPD[V] = 0.8035V

ISS:
    The diffracted power is around 3.6%
    Last saturation event was 1 days 23 hours and 16 minutes ago


Possible Issues:
    PMC reflected power is high

LHO General
ryan.short@LIGO.ORG - posted 07:35, Tuesday 06 May 2025 - last comment - 14:35, Tuesday 06 May 2025(84267)
Ops Day Shift Start

TITLE: 05/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 9mph Gusts, 5mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY: Vent work continues today with more HAM1 alignment and wind fence work.

Comments related to this report
ryan.crouch@LIGO.ORG - 10:06, Tuesday 06 May 2025 (84278)

The DR dust monitor counts did not look correct, its was only reading zero for over 2 weeks, I went out and power cycled it and made some counts which I was not able to see on epics. I then tried to restart the IOC, and it struggled to come back. After a little over 5 minutes it did come back and started showing counts again.

ryan.crouch@LIGO.ORG - 11:12, Tuesday 06 May 2025 (84282)CDS, PEM

The DR is having network issues again, ~an hour after the restart. I'll try swapping this one with one of our 2 pumpless spares.

2025/05/06 11:09:20.443023 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: No reply from device within 1000 ms
2025/05/06 11:09:21.444241 gt521s1 H1:PEM-CS_DUST_DR1_STATE: No reply from device within 1000 ms
2025/05/06 11:09:21.787891 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "SH 600*00337" mismatch after 0 bytes
2025/05/06 11:09:21.787919 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "SH 600*00337" where "OP " was expected
2025/05/06 11:09:22.344822 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: Input "OP H 58*00404" mismatch after 0 bytes
2025/05/06 11:09:22.344838 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: got "OP H 58*00404" where "SH " was expected
2025/05/06 11:09:22.394988 gt521s1 H1:PEM-CS_DUST_DR1_STATE: Input "H 57*00403" mismatch after 0 bytes
2025/05/06 11:09:22.395020 gt521s1 H1:PEM-CS_DUST_DR1_STATE: got "H 57*00403" where "OP " was expected
2025/05/06 11:09:22.445131 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "P H 57*00403<8d>OP H 57" mismatch after 0 bytes
2025/05/06 11:09:22.445164 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "P H 57*00403<8d>OP H 57" where "OP " was expected

 

Swapped the dust monitor and now it won't come back and the IOC can't connect to/see the DM.

2025/05/06 11:42:20.506771 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIME: No reply from device within 1000 ms
2025/05/06 11:42:20.507000 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: @init handler failed
2025/05/06 11:42:20.507100 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: Record initialization failed
Bad init_rec return value  PV: H1:PEM-CS_DUST_DR1_HOLDTIME ao: init_record

2025/05/06 11:42:21.508499 gt521s1 H1:PEM-CS_DUST_DR1_SAMPLETIME: No reply from device within 1000 ms
2025/05/06 11:42:21.508670 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: @init handler failed
2025/05/06 11:42:21.508762 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: Record initialization failed
Bad init_rec return value  PV: H1:PEM-CS_DUST_DR1_SAMPLETIME ao: init_record

H1 ISC
elenna.capote@LIGO.ORG - posted 16:55, Thursday 01 May 2025 - last comment - 09:17, Thursday 08 May 2025(84230)
REFL Beam Profile Measurements

Keita, Elenna, Jennie W.

We have taken three beam profile measurements along the REFL path on HAM1: one in the location where REFL WFS B will go, one in the location where REFL WFS A will go, and one measurement further "downstream" where we placed a steering mirror after where WFS B will go and steered back towards the edge of the table. We will post further details later, more measurements to be made along this path tomorrow.

Comments related to this report
keita.kawabe@LIGO.ORG - 16:32, Friday 02 May 2025 (84241)

Note that the same glitches we had in the original installation (alog 8934) were still there. Quoting my alog from 2013,

it was still difficult to obtain good data because of some kind of glitches. It's not clear if it was due to NanoScan or the beam, the beam was well damped and was not moving on the viewer card, there was no noticable intensity glitch either. But the symptom was that the statistics window shows nice steady data for anywhere from one second to 30 seconds, then there's some kind of glitch and the scan/fit image looked noticably different (not necessarily ugly), the diameter mean becomes larger and the stddev jumps to a big number (like 10% or more of the mean, VS up to a couple % when it's behaving nice), and the goodness of fit also becomes large. Somehow no glitch made the beam diameter number smaller. I just kept waiting for a good period and cherry-picked.

keita.kawabe@LIGO.ORG - 16:30, Friday 02 May 2025 (84240)

We measured the beam radius using NanoScan at four points around the WFS sled (roughly WFSA position, roughly WFSB position, far field 1, far field 2). We used D4sigma numbers instead of 1/e**2 numbers. NanoScan outputs diameter not the radius, and the table below shows the raw number.

We assumed that the WFS position would be ~0.5" from the +Y edge of the WFS sled for both A and B. Distances were measured using stainless steel rulers and are relative to the 50:50 splitter on the WFS sled that also acts as the steering mirror for WFSa.

position distance [mm] 2*avg(wx) [um] 2*std(wx) 2*avg(wy) 2*std(wy)
WFSA 94 670.26 2.34 778.95 2.82
WFSB 466.5 793.73 6.38 711.29 11.95
downstream 2 788.5 1484.15 12.46 1387.24 58.32
downstream 1 1092.5 2253.78 50.67 2119.24 68.30

In all of the above measurements, "Profile averages" was 10, "Rolling profile Averages" was 3.

We also measured between M5 and 50:50 splitter for ASC-LSC split as well as between M2 and RM1. Numbers will be added to this alog.

We'll also measure the beam size at LSC REFL_B location on Monday before proceeding to POP path.

elenna.capote@LIGO.ORG - 16:41, Friday 02 May 2025 (84242)

Here are some comments about the measurement process:

The beam profiler is difficult to use because the profiler head easily swivels once it is place. The swivel seems to be driven by the fact that the cable is very stiff and made stiffer by the addition of the foil so it is cleanroom safe. Several times today, I would pick up or set down the profiler and the head would swivel. I tried tightening the screw holding the post to the base, and I tried tightening the screw that holds the post to the head, but it is not tight enough to prevent swiveling. I found the best method was to line up the profiler in the designed location, and hold the head and cable in place while someone else ran the measurement. That makes this a minimum two person job, but there was enough juggling that having a third person was sometimes helpful.

When we went in around 3 pm to do the final measurement of the day I measured the particle count: 0.3u was 10 and 0.5u was 0. I used the standing particle counter on the +Y side of the HAM1 chamber- briefly unplugged to carry it over to the -Y side for the measurement. I didn't measure when closing up because Keita is heading out to do a few more tasks on HAM1. The handhelp particle counter isn't working, so we have to carry this large one on a stand around to use.

keita.kawabe@LIGO.ORG - 11:10, Monday 05 May 2025 (84252)

WFS sled is still excellent, 84 to 85 deg Gouy phase separation.

In the attached, four measurement points have error bars both in the position and the beam size but it looks negligible. There's no concern for WFS, it's good to go as is. 

However, just for the record, the astigmatism is bigger now (which is inconsequential in that ASC DOF separation is determined by the Gouy phase even if there's an astigmatism). The waist location difference is ~49mm now VS ~14mm or so before (just eyeballing the old plot from alog 8932) for a beam with the Rayleigh range of ~200mm. Not sure if this is the result of the AOI change or beam position change on curved mirrors and lenses, but I won't fix/correct this.

Images attached to this comment
elenna.capote@LIGO.ORG - 11:40, Monday 05 May 2025 (84254)

This morning we entered to do one more beam profile measurement. First Jennie and I refoiled the cable of the nanoscan profiler, since it was very stiff from multiple layers of foil. Then, before opening the cover to the table, I measured the dust counts by carrying the stand particle counter over to our working side like I did on Friday. The read was 0 and 0 for 0.3um and 0.5 um particles. I know it was working however, because as I carried the counter over outside the cleanroom it counted 19 each of 0.3 and 0.5 um particles.

Then, Jennie and I took one more beam profile measurement, this time on the LSC REFL path, after the final beamsplitter (M18). LSC REFL A (on transmission of M18) is placed on the table as in the drawing, but the LSC REFL B sensor (reflection of M18) was further away relative to the splitter. My quick rough measurement showed that LSC REFL B was about 160 mm away from M18.

I measured the distance of LSC REFL A to the front surface of M18 to be 128 mm. Then, I set LSC REFL B off to the side, and placed the profiler about 128 mm away from M18 on reflection of the splitter. We measured the beam profile, and then I re-placed LSC REFL B, this time at a distance of 128 mm to M18.

elenna.capote@LIGO.ORG - 12:26, Monday 05 May 2025 (84256)

I have attached a very rough drawing of the REFL path and the locations where we made beam profile measurements. Each X on this drawing marks a beam profile measurement location. I also marked the Xs with letters A-G.

The measurements Keita reports above correspond the measurements C, D, E and F on this drawing. The difference between E and F, which is not depicted in my drawing, is a different placement of the temporary steering mirror relative to the sled.

 We still need to report details on the measurements for locations A, B, and G.

Images attached to this comment
keita.kawabe@LIGO.ORG - 15:31, Monday 05 May 2025 (84257)

Beam size upstream of the WFS sled

Unfortunately this is preliminary.

We measured the beam size at 4 different location upstream of the WFS sled marked as A, B, C and D. D data cannot be used as there's no data/picture of D locaiton but that's fine as far as position A data is good. Unfortunately, though, the position A horizontal width looks narrower than it really is (2nd attachment). The beam might be clipping in the nanoscan aperture or there might be a ghost beam or bright background light in the Region Of Interest (ROI), or ROI is defined poorly, effectively clipping the beam. Must remeasure.

LSC REFL_B (and therefore REFL_A) beam radius is ~0.1mm, which is tinier than my preference, the diode is 3mm (in diameter) so the beam could be larger.  The diodes are placed close to the focus of the lens upstream (number 18 in a circle in the first attachment) so the beam won't move when the beam position moves on that lens. Moving away from that position will be fine as far as the deviation is much smaller than the focal length (~200mm). Rayleigh range is like 3cm or maybe smaller (0.1mm waist -> RR=10*pi mm),  it should be easy to double the beam size by moving the sensors away from the lens by a couple inches. We'll do this after POP alignment.

Location Distance from the closest component wx [um] std(wx) [um] wy [um] std(wy) [um]
A

225mm downstream of M2, hard to measure the position accurately.

Nanoscan wx*2 number looks narrower than it really is. Must remeasure.

2683.6/2
14.2/2
3562.9/2 4.4/2
B 303mm downstream of M5. 3936.9/2 64.5/2 3960.8/2 83.1/2
C

128mm downstream of the last 50:50 for LSC REFL_A/B. LSC-REFL_B location (tentative).

211.6/2 12.7/2 247.3/2 4.5/2
D Exact position unknown, between RM1 and M2, less than 1400 downstream of M2. Beam size numbers look good. 3703.6/2 3.0/2 4332.8/2 4.5/2

After everything is done we'll make a good measurement of distances between everything by either using a long/short ruler (preferred) or counting bolt holes or both.

Images attached to this comment
camilla.compton@LIGO.ORG - 09:04, Tuesday 06 May 2025 (84263)

Yesterday Betsy and I measured the distances between these optics:

  • 856mm from RM1 to RM2, measured 827mm between the front D1000767 plate structure of each SUS and Don and Rahul measured on D1001396 the horizontal distance between plate and optic is 14.3mm for each RM1 and RM2.
  • 895mm from RM2 to M5: Front of RM2 mirror to HR of M5 mirror
  • 758mm from M5 to M6 (BS): HR of M5 mirror to front HR of M6 BS (-X side of M6)
  • 468mm from M6 (BS) to 2" Lens on SLED: front HR of M6 BS (-X side of M6) to front side of 2" lens (0.5" thick lens holder, from siskiyou FOH 2", so add 0.25" if you want center of lens).
elenna.capote@LIGO.ORG - 17:24, Tuesday 06 May 2025 (84266)

Camilla and I went back out today to redo the measurements at the locations labeled "A" and "D" in Keita's diagram. This table reports the D4sigma values, like Keita's tables above.

We forgot that we had left ITMX aligned, so the original measurements in this alog are no good. Keita and I remeasured these again today (May 6) and I am updating the table below with the new data. We also got two more measurements in new locations that are not indicated in Keita's diagram.

Location Distance from closest component wx [um] std wx [um] wy [um] std wy [um]
A 238 mm (+- 3 mm) downstream of M2 (nanoscan image) 4038.9/2 1.4/2 4206.2/2 3.3/2
D 314 mm (+- 3 mm) upstream of RM1 (measured from nanoscan front to metal ring around the RM, the mirror surface may be set back from the ring by another 1mm or so, hard to tell) (nanoscan image) 3950.6/2 2.8/2 4315.0/2 2.6/2
New location, after RM2 374 mm upstream of M5 (nanoscan image) 2304.8/2 36.3/2 2335.9/2 37.1/2
New location, between RM1 and RM2 345 mm upstream of RM2 (measured from nanoscan front to metal ring around RM) (nanoscan image) 1650.9/2 2.3/2 1805.1/2 3.2/2

Leaving this older comment: It is difficult to measure these distances well with the ruler, so I would guesstimate error bars of a few mm on each distance measurement reported here.

Some new notes: when we reduce teh purge air flow, the measurements become much more stable and there is no need to "cherry pick" data as Keita discussed in earlier comments. Also, I think we have finally managed to tighten the screws on the nanoscan posts enough that it doesn't slide around anymore.

Images attached to this comment
Displaying reports 1101-1120 of 82965.Go to page Start 52 53 54 55 56 57 58 59 60 End