Displaying reports 2761-2780 of 83040.Go to page Start 135 136 137 138 139 140 141 142 143 End
Reports until 07:33, Thursday 06 February 2025
H1 General
ryan.crouch@LIGO.ORG - posted 07:33, Thursday 06 February 2025 (82663)
OPS Thursday day shift start

TITLE: 02/06 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 162Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 8mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.21 μm/s
QUICK SUMMARY:

H1 SQZ
oli.patane@LIGO.ORG - posted 04:34, Thursday 06 February 2025 (82662)
OWL Intervention

H1 Manager contacted me because we couldn't get into squeezing. the filter cavity was having trouble locking even green. It was locking on the wrong modes(02 and 01), with FC_TRANS_C_LF_OUTPUT reading below 100. Referencing 72084, I paused the FC guardian, closed the servo for SQZ green, and checked the FC2 driftmon. FC2 had drifted A LOT in the past hours (ndscope). I tried moving the sliders until we were back in the location where we were 4 hours ago when our squeezing was good, but this wasn't enough to let us get back to a 00 mode, and moving the sliders around more in other directions didn't get me closer either. I then checked the SQZ troubleshooting wiki and plotted the M3 witness channels along with the driftmon for both FC1 and FC2. I adjusted the sliders according to the witness channels for FC1 and we got back to a 00 mode! I then fiddled back and forth between using the driftmon channels and using the witness channels to maximize FC_TRANS_C_LF_OUTPUT until we looked good, then I unpaused the FC node and we were able to enter FDS and then Observing!

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 22:00, Wednesday 05 February 2025 (82658)
Wed EVE Ops Summary

TITLE: 02/06 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

To Do List:  Hit LOAD for VIOLIN_DAMPING guardian at next lockloss and use settings for IY5 that RyanC mentions in his summary.

Overall the ITMy Mode5/6 are slowly being damped down with Ryan's settings and have been monitoring to see that it continues to damp down.  Hopefully H1 can stay locked overnight to damp these modes down.

Had about 60-90min of snow falling and sticking tonight (only about less than 0.5").
LOG:

LHO FMCS (PEM)
corey.gray@LIGO.ORG - posted 19:14, Wednesday 05 February 2025 (82661)
HVAC Fan Vibrometers FAMIS Check (FAMIS 26359)

For FAMIS #26359:  All looks well for the last week for all site HVAC fans (see attached trends).

Images attached to this report
H1 SUS (SUS)
corey.gray@LIGO.ORG - posted 18:51, Wednesday 05 February 2025 (82660)
Quarterly Inspection of HWWD Trends (FAMIS #26510)

3-month trend for the SUS HWWDs. 

As far as this 3-month stretch, we get at least ONE bit for all FOUR Test Masses.  No further action needed.

Images attached to this report
H1 TCS (TCS)
corey.gray@LIGO.ORG - posted 17:51, Wednesday 05 February 2025 - last comment - 09:41, Monday 10 February 2025(82659)
TCS Monthly Trends (FAMIS #28457)

Attached are monthly TCS trends for CO2 and HWS lasers.  (FAMIS link)

Comments related to this report
corey.gray@LIGO.ORG - 09:41, Monday 10 February 2025 (82717)TCS

Whoops!  Forgot to attach the actual trends!! (thanks for catching this, Camilla!)  Attachements are now attached!

Images attached to this comment
LHO General
corey.gray@LIGO.ORG - posted 16:34, Wednesday 05 February 2025 (82657)
Wed EVE Ops Transition

TITLE: 02/06 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 16mph Gusts, 11mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.28 μm/s
QUICK SUMMARY:

H1's been locked 5.75hrs.  Ryan-C mentioned the issues with IY5 violin mode, but sounds like he has a setting that is slowly damping it down.  If there is a lockloss, I need to do a LOAD of the VIOLIN DAMP guardian (so the IY5 damps with 0 gain) & then enter the settings which work for him.

Microseism has been trending down over the last 8-ish hours and winds look a little calmer compared to 24hrs ago.

H1 General (OpsInfo, SUS)
ryan.crouch@LIGO.ORG - posted 16:30, Wednesday 05 February 2025 (82653)
OPS Wednesday day shift summary

TITLE: 02/05 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: 1 lockloss with an easy relock, we've been locked for 6 hours.
LOG:                                                                                                             

Start Time System Name Location Lazer_Haz Task Time End
17:16 SAFETY LASER SAFE  ( \u2022_\u2022) LVEA SAFE! LVEA  SAFE!!! 19:08
17:13 PSL Jason CR N ISS loop adjustment 17:15
17:15 CAL Tony PCAL lab Y PS11 measurement 17:40
18:03 FAC Kim Receiving N Cardboard 18:54
18:12 VAC Travis LVEA N Quick part check near high bay 18:16
19:31 FIT Matt Xarm N Runnin' 20:13
21:36 ISC Matt Optics lab N Cheeta optics mounting 22:28
21:40 CAL Tony PCAL lab Y PCAL work 22:28

17:10 UTC lockloss

18:34 UTC Observing

ITMY mode5/6s damping didn't seem to be going well today, I've been monitoring it on DTT after seeing the tall line on DARM and the DCPD min/max plot looking flat. I've found some new settings that seem to be bringing it down, based on the long & short monitors and DTT but more testing is needed to confirm. The new settings are FM5 + FM6 + FM10 G= -0.01, removing FM8. (Tagging SUS, OPS). I've set the gain to 0 in lscparams but I have not loaded the VIOLIN_DAMPING guardian.

21:52 UTC superevent S250205ee

00:00 - 00:03 UTC we dropped observing as the SUS_PI guardian fought (successfully) PI 24 in the new "XTREME_PI_DAMPING" state

Non-image files attached to this report
H1 SQZ
camilla.compton@LIGO.ORG - posted 12:27, Wednesday 05 February 2025 - last comment - 14:24, Thursday 06 February 2025(82654)
SQZ_MANAGER edits: saved not loaded.

Sheila, Camilla, follow on from 82640.

We made some more changes to SQZ_MANGER to hopefully simplify it:

Saved and added to svn but not loaded.

Once reloaded, as states have been changed, any open SQZ_MANAGER medm's should be closed and reopened.

Comments related to this report
sheila.dwyer@LIGO.ORG - 14:24, Thursday 06 February 2025 (82672)

I did load this today, there don't seem to have been any issues in this lock.

H1 ISC
elenna.capote@LIGO.ORG - posted 12:17, Wednesday 05 February 2025 - last comment - 14:28, Tuesday 11 February 2025(82656)
Quick check of POP A LF calibration

Sheila and I are continuing to check various PD calibrations (82260). Today we checked the POP A LF calibration.

Currently there is a filter labeled "to_uW" that is a gain of 4.015. After some searching, Sheila tracked this to an alog by Kiwamu, 13905, with [cnts/W] = 0.76 [A/W] x 200 [Ohm] x 216 / 40 [cnts/V]. Invert this number and multiply by 1e6 to get uW/ct.

Trusting our recalibration of IM4 trans, we have 56.6 W incident on PRM. We trust our PRG is about 50 at this time, so 2.83 kW are in the PRC. PR2 transmission is 229 ppm (see galaxy optics page). Then, the HAM1 splitter is 5.4% to POP (see logs like 63523, 63625). So we expect 34 mW on POP. At this time, there was about 30.5 mW measured on POP according to Kiwamu's calibration.

Comments related to this report
elenna.capote@LIGO.ORG - 12:56, Monday 10 February 2025 (82724)

I have added another filter to the POP_A_LF bank called "to_W_PRC", that should calibrate the readout of this PD to Watts of power in the PRC.

POP_A_LF = T_PR2 * T_M12 * PRC_W, and T_PR2 is 229 ppm and T_M12 is 0.054. I also added a gain of 1e-6 since FM10 calibrates to uW of power on the PD.

Both FM9 (to_W_PRC) and FM10 (to_uW) should be engaged so that POP_A_LF_OUT reads out the power in the PRC.

I loaded the filter but did not engage it.

elenna.capote@LIGO.ORG - 14:28, Tuesday 11 February 2025 (82755)

More thoughts about these calibrations!

I trended back to last Wednesday to get more exact numbers.

input power = 56.8 W

PRG = 51.3

POP A LF (Kiwamu calibration) = 30.7 mW

predicted POP A LF = 0.054 * 229 ppm * 56.8 W * 51.3 W/W = 36 mW

ratio = 30.7 mW / 36 mW = 0.852

If the above calibrations of PRG and input power are correct, we are missing about 15% of the power on POP.

H1 ISC
mayank.chaturvedi@LIGO.ORG - posted 10:53, Wednesday 05 February 2025 (82641)
We tried measuring the width of aperture of scrapper baffle in front of PR2

Sheila, Mayank

We tried measuring the width of aperture of scrapper baffle in front of PR2.

The plan was to change the beam spot on PR2 mirror while simultaneosly monitoring the circulating power in X (ASC-X_PWR_CIRC_OUT) ( It is a caliberated channel derived from ASC-X_TR_A_SUM_OUT_16 and ASC-X_TR_B_SUM_OUT_16) . When the beam starts hitting the edge of aperture of scrapper baffle the circulating power in X will drop.

In oder to change the PR2 beam spot. We changed the PR3 yaw slider while activating PR2spotmove script (It adjust the slider values of PR2 and PRM and IM4 in such a way the the light going from PR3 to the the Interferometer remaines unchanged while the spot on PR2 moves.)

Steps we followed

  1. Lock X-arm.
  2. Decrease the PR3 slider untill the Circulating power drops ( due to beam hitting one edge of baffle).
  3. Unlock X-arm and Lock PRX. Run A2L on PRCL to estimate beam position on PR2.
  4. UnLock PRX and Lock X-arm
  5. Increase the PR3 slider untill the Circulating power drops ( due to beam hitting other edge of baffle).
  6. Unlock X-arm and Lock PRX. Run A2L on PRCL to estimate beam position on PR2

A2L procedure   

  1.     Dither PRM PR2 PR3 at three different frequecy (29Hz , 30 Hz , 31Hz with amplitudes of 30,1000,1000 cts)
  2.     Obeserve these peaks in PRCL.
  3.     Minimize these peaks by chaning the "A2L gain" on PR2 and PR3 and PRM.  
  4.     From "A2L gain" the beam spot on the optics can be estimated.

What we did

  1. We started  at  PR3 yaw slider of 96 and TRX value of 0.05 with following a2L gain.

       2. Perfomed  A2L on the three mirrors PR2 PRM PR3 to estimate original position.  The gains which minimized the three injection peaks were.

       3.The PR3 Yaw slider was decreased to 75.2 the such that the TRX value dropped to 0.047 (6%)
          Perfomed  A2L on the three mirrors PR2 PRM PR3 to estimate one edge of the Baffle.  The gains which minimized the three injection peaks were

       4. The PR3 Yaw slider was increased to 103  such that the TRX value dropped to 0.047 (6%)
           Perfomed  A2L on the three mirrors PR2 PRM PR3 to estimate other edge of the Baffle.  The gains which minimized the three injection peaks were

As expected the beam spot does not move on PR3 and PRM.  

The PR2 beam spot moved by 1.612 mm.

Thoughts: Sheila suggested that this movement of 1.612 mm is too small to see the clipping at the baffle. Most likely the reduction in circulating power was due to something else. To probe this, we tried to go further on the PR3 Yaw sliders (greater than the 103 and less than 75.2) however the X arm was not locking. This was probably because we were not getting the required PDH signal for Xarm locking on the POP port due to misalignment. Sheila suggested that we can 

  1. Repeat the same procedure while Pico on POP signal so that we dont loose lock.
  2. Alternatively we can choose REFL port signal for Xarm locking and repeat the measuement.  

 

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:27, Wednesday 05 February 2025 (82651)
Wed CP1 Fill

Wed Feb 05 10:09:57 2025 INFO: Fill completed in 9min 54secs

Gerardo confirmed a good fill curbside. TCmins [-81C, -79C] OAT (0C, 32F) DeltaTempTime 10:09:58

Images attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 09:21, Wednesday 05 February 2025 (82649)
OMC ASC offsets, optical gain

The attached screenshot shows what's happened with out OMC ASC offsets over the laser two weeks. 

On Jan 21st, Jennie W measured the OMC ASC offsets 82383, but there was a sign error in putting them in so kappa C decreased, the range was also lower during this time with the wrong offsets. During Monday's commissioning time we understood the error and went back to the settings before the change, and kappa C increased more than we expected it to.  There was also some recovery of range which was probably because the squeezing improved with the fixed OMC alignment, but could also be becuse of Ibrahim improved A2L, then range is still not as good as it was 3 weeks ago. 

Yesterday there was a problem where the ASC safe.snap file was overwritten with many wrong values, perhaps the observe settings were erroneously saved to the safe (Dave is investigating) 82637.  This ended up blasting large numbers to the PUMs, and ringing up the violin modes, which cost us an hour of observing time and high violins over night, but it could have had worse consequences if we hadn't caught it quickly. 

Dave helped us recover by reverting the safe.snap to a week old file, which had the wrong OMC QPD offsets in it.  Then when Corey got to observe, he accepted the OMC offsets 82643, which meant that we had lower optical gain and worse squeezing overnight. 

Now we have lost lock and I've edited the safe.snap to have the previous (better) offsets, this means that when we get to observe we should accept differences, and check that kappa c is 1.01 or 1.02 after we thermalize.

Images attached to this report
H1 General (Lockloss)
ryan.crouch@LIGO.ORG - posted 09:11, Wednesday 05 February 2025 - last comment - 10:34, Wednesday 05 February 2025(82650)
17:10 UTC lockloss

17:10 UTC lockloss

Comments related to this report
ryan.crouch@LIGO.ORG - 10:34, Wednesday 05 February 2025 (82652)

18:34 UTC Observing, ASC SDF diffs accepted.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 08:06, Wednesday 05 February 2025 - last comment - 08:23, Wednesday 05 February 2025(82647)
CDS Maintenance Summary: Tuesday 4th February 2025

WP12248 OMC0 double duotone frequency

Erik, EJ, Jonathan, Dave:

The duotone frequency generated by the LIGO Timing Card in h1omc0's IO Chassis was increased from (960, 961)Hz to (1920, 1921)Hz

The available frequencies are hard-coded in the FPGA code on the timing card. The IOP model can request one of these frequencies, configued by the following line in the CDS params block:

duotone_frequency=1920

All models on h1omc0 were restarted with the new iop model:

Tue04Feb2025
LOC TIME HOSTNAME     MODEL/REBOOT
12:24:55 h1omc0       h1iopomc0   
12:25:09 h1omc0       h1omc       
12:25:23 h1omc0       h1omcpi     
 

An identical change was made at LLO on l1lsc0's Timing Card.

Comments related to this report
david.barker@LIGO.ORG - 08:23, Wednesday 05 February 2025 (82648)

3 day trend of h1iopomc0's duotone zero crossing calculation channel:

Images attached to this comment
H1 TCS (CAL)
matthewrichard.todd@LIGO.ORG - posted 17:18, Tuesday 04 February 2025 - last comment - 14:06, Friday 07 February 2025(82631)
Summary -- Calibrating CHETA RIN into RMS counts at various points

[M. Todd, C. Compton, G. Vajente, S. Dwyer]

Summary

To understand the effect of the Relative Intensity Noise (RIN) of the CO2 laser (Access 5W L5L) proposed for CHETA on the DARM loop, we've done a brief study to check whether the addition of the RIN as displacement noise in deltaL will cause saturation at several key points in the DARM loop such as the ESD driver and DCPDs. The estimates we've made on the RIN at these points are calibrated with the DARM model in pydarm, which models the DARM loop during Nominal Low Noise; however, appropriate checks have been made that these estimates are accurate or at least over-estimating of the effects during lower power stages (when the CHETA laser will be on).


CHETA RIN to ESD drive

This estimate is done by propagating displacement noise in deltaL (how CHETA RIN is modeled, m/rtHz) to counts RMS of the ESD DAC. The RMS value of this should stay below 25% or so of the saturation level of the DAC, which is 2**19. To do this, we multiply the loop suppressed CHETA RIN (calibrated into DARM) by the transfer functions mapping deltaL to ESD counts (all are calculated at NLN using pydarm).

The CHETA RIN in ESD cts RMS is 0.161% of the saturation level, and in L2 coil cts RMS is 1.098%, and in L3 coil cts RMS is 0.015%. It is worth noting that the CHETA RIN RMS at these points is around 10x higher than that which we expect with just DARM during NLN.

We also checked to make sure that the ESD cts RMS during power-up states is not higher than that during NLN, meaning the calibration using NLN values gives us a worst case scenario of the CHETA RIN impact on ESD cts RMS.

List of Figures:

    1) Loop Model Diagram with labeled nodes
    2) CHETA RIN in ESD cts RMS
    3) CHETA RIN in L2coil cts RMS
    4) CHETA RIN in L1coil cts RMS
    5) DARM Open Loop Gain - pydarm
    6) DARM Sensing Function - pydarm
    7) DARM Control Function (Digitals) - pydarm
    8) Transfer Function: L3DAC / DARM_CTRL - pydarm
    9) Transfer Function: L2DAC / DARM_CTRL - pydarm
    10) Transfer Function: L1DAC / DARM_CTRL - pydarm
    11) ASD/RMS ESD cts during power-up states - diaggui H1:SUS-ETMX-L3_MASTER_OUT_UL_DQ
    12) CHETA RIN ASD (raw)


CHETA RIN to DCPD ADC

This estimate is done by propagating displacement noise in deltaL (how CHETA RIN is modeled, m/rtHz) to counts RMS of the DCPD ADC. The RMS value of this should stay below 25% or so of the saturation level of the DAC, which is 2**15. To do this, we multiply the loop suppressed CHETA RIN (calibrated into DARM) by the transfer functions mapping deltaL to DCPD ADC counts, using the filters in Foton files. This gives us the whitened ADC counts, so by multiplying by the anti-whitening filter we get the unwhitened DCPD ADC cts RMS, which is what is at risk of saturation.

The CHETA RIN in DCPD cts RMS is 3.651% of the saturation level. Again, it is worth noting that the CHETA RIN RMS at this point is around 10x higher than that which we expect with just DARM during NLN.

We also checked to make sure that the DCPD-A ADC channel is coherent with DARM_ERR. In short, it is up to 300Hz, where controls noise dominates our signal -- after 300Hz shot noise becomes the dominant noise source and reduces our coherence.

List of Figures:

    1) Loop Model Diagram with labeled nodes
    2) CHETA RIN in DCPD ADC cts RMS
    3) Transfer Function: DCPD-ADC / DELTAL_CTRL
    4) Coherence: DCPD-A / DARM_ERR


Codes used:

Calibrating CHETA RIN to ESD cts RMS

Calibrating CHETA RIN to DCPD ADC cts RMS


Previous related alogs:
    1)  alog 82456

Images attached to this report
Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 07:31, Wednesday 05 February 2025 (82645)

Is the propagation of RIN into displacement consistent with the photothermal calculations done by Braginsky and Cerdonio? One can use Eq. 8 of Braginsky (1999) except with the replacement of the absorbed shot noise power 2 hbar omega_0 Wabs with the absorbed classical laser power. Then using

alpha = 0.6 ppm/K
sigma = 0.17
rho = 2200 kg/m^3
C = 700 J/(kg K)
r0 = 53 mm / sqrt(2)

I find sqrt(Sxx) = 1.6e-18 m/rtHz as the displacement from a single test mass assuming a CHETA RIN of 1e-5/rtHz and an absorbed power of 1 W.

matthewrichard.todd@LIGO.ORG - 11:28, Wednesday 05 February 2025 (82655)

[M. Todd, E. Hall]

Indeed the propagation of RIN int DARM laid out in T050064 is consistent with the work done by Braginsky and Cerdonio. The calibration follows the form in Figure 1.

Attached is a comparison plot of the two propagtions, using the parameters set above in Evan's comment.

Images attached to this comment
Non-image files attached to this comment
matthewrichard.todd@LIGO.ORG - 14:06, Friday 07 February 2025 (82674)

Updating this post with some busier plots that show how other CO2 laser noise is projected into the various stages. As well as adding flat RIN curve propagations to give an intuition as to what RINs we do not need to even worry about in NLN.

I've also reattached the codes used because of a correction to the way the ASD integration was being done.

The plots also extend to lower frequency to show the behavior of the RIN propagation to each channel (mostly falling off below 10Hz). This is why we take the "RMS" value to be the integrated value of the ASD at 10Hz, and compare that to the saturation limit. It also gives a better display of the RMS from DARM in NLN at propagated to the above channels, showing that overall the RIN should have a small effect on these drives and ADCs.

Non-image files attached to this comment
H1 ISC (CDS, ISC)
sheila.dwyer@LIGO.ORG - posted 16:09, Tuesday 04 February 2025 - last comment - 08:26, Thursday 06 February 2025(82637)
ASC safe.snap file problem

Sheila, Dave, Ryan Crouch, Tony

This afternoon after the maintence window when we first started using guardian, once the ASC safe.snap was loaded by SDF revert we started sending large signals to the quads.  We found that this was due to the camera servos having their gains set to large numbers.  This was set this was in the safe.snap file. 

After I set these two zero in safe.snap (which is really down.snap), Ryan again went through the guardian down, and this time we started to saturate the quads because of the arm asc loops (which we probably didn't notice the first time because we tried running down when we saw that there was a problem, and down would turn these off but not the camera servos).

Dave looked in the svn for this file, which he had committed this morning with this set of: diffs from this mornings svn commit  .  Looking through these, it kind of seems like somehow the safe.snap may have been overwritten with the observe.snap file. 

Dave reverted that to the file from 7 days ago, which has Elenna's changes to the POP QPD offsets. Then I reverted all the diffs, so that we set all settings back to 7 days ago except those that are not monitored.

After this, Mayank and I were using various initial alignment states to make some clipping checks, which Mayank will alog.  We noticed that the INP1Y loop (to IM4) was oscillating, so we reduced the gain in that from 10 to 40, on line 917 of ALIGN_IFO.py  We also saw that there is an oscillation in the PRC ASC if we sit in PRX, but we haven't fixed that.  These should not be due to whatever our safe.snap problem is, we hope.

Edit to add: We looked at the last lockloss, when the guardian went through SVN revert at 7 am yesterday Feb 3rd.  It looks like the camera gains were 0 in the safe.snap at that time, but it was 100 by the time we did SDF revert at 20:51 UTC (1pacific time) today.

Comments related to this report
david.barker@LIGO.ORG - 08:26, Thursday 06 February 2025 (82664)
Displaying reports 2761-2780 of 83040.Go to page Start 135 136 137 138 139 140 141 142 143 End