Displaying reports 9041-9060 of 84061.Go to page Start 449 450 451 452 453 454 455 456 457 End
Reports until 20:59, Thursday 18 April 2024
H1 CAL
oli.patane@LIGO.ORG - posted 20:59, Thursday 18 April 2024 (77277)
CAL kappa value increases

Between yesterday 2024/04/17 16:48utc and today's lockloss at 2024/04/18 15:25utc, there were three sets of times where the calibration kappa values were suddenly louder than normal. Attachment1 and attachment2 show the three lock stretches (labeled 1, 2, and 3) over which this was seen, as well as showing kappa ranges from other locked times. The white dotted lines give an idea of the boundaries that the majority of kappa values fall within. The first time this showed up was 2024/04/17 16:48utc(stretch1), where we were locked in NOMINAL_LOW_NOISE and commissioning. The kappa values had flatlined for three minutes before then coming back larger than normal. Stretch2 and stretch3 were over the entirety of the next two locks. However, the lock following those two starting at 2024/04/18 17:26utc, the values seemed to be back to normal. 
I mentioned this increase to Louis last night and he said "I think we need to increase the calibration line amplitudes". I'm not sure if something was done about this today between locks that brought the values back to what they were previously.

Images attached to this report
H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 18:03, Thursday 18 April 2024 - last comment - 19:26, Thursday 18 April 2024(77275)
Lockloss

Lockloss 04:19 01:02UTC from unknown cause

Comments related to this report
oli.patane@LIGO.ORG - 19:26, Thursday 18 April 2024 (77276)

02:23 Observing

H1 General
oli.patane@LIGO.ORG - posted 16:36, Thursday 18 April 2024 (77274)
Ops EVE Shift Start

TITLE: 04/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 8mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

Observing and have been locked for 6 hours.

LHO General
corey.gray@LIGO.ORG - posted 16:24, Thursday 18 April 2024 (77265)
Thurs DAY Ops Summary

TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

The day started out with plans of coordinated-Commissioning but that soon changed after another earthquake took H1 down (so coordinated-commissioning was shifted to later in the morning) and a return to Observing in the afternoon.
LOG:

H1 SEI
thomas.shaffer@LIGO.ORG - posted 15:15, Thursday 18 April 2024 (77273)
H1 ISI CPS Noise Spectra Check - Weekly

FAMIS25987

All plots looks good to me. Jim happened to be next to me while I ran this and said that there may have been an earthquake during the time this uses, but it seems to have only raised the low frequency up and not changed the high frequency that we care about for these CPS checks. All good.

Non-image files attached to this report
H1 ISC
jenne.driggers@LIGO.ORG - posted 14:55, Thursday 18 April 2024 (77272)
There may be a bit more Jitter Cleaning to do

Now that Sheila and Jennie have done lots of work to get our arm pointing and A2L couplings improved, there may be a small amount of jitter cleaning improvement that can be gained.

In the attached image, red and blue are from today after the commissioning time.  Green and brown are from a week ago when we had ~165 Mpc cleaned range.  Red and Green are pre-cleaning, and Blue and Brown are after line subtraction and cleaning. In the area between 100-200 Hz, it looks like the blue current trace is perhaps not quite as flat as the brown trace, so maybe there is a teeny bit more that an updated cleaning coefficient set could eeek out.  Once the cleaned trace is flat, if there is an overall level change, that probably wouldn't be able to be cleaned out.

I'll try to look at some Observing time from tonight, to see if there is an improved candidate set of coefficients we can try.  As a reminder, the jitter coupling is still quite close to what it was in O4a, and the cleaning coefficients are currently the same as they have been since Fall 2023.

Images attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 13:41, Thursday 18 April 2024 - last comment - 12:26, Friday 19 April 2024(77269)
A2L decoupling, depends on thermalization

Jennie W, Sheila

Summary: We spent some time today resetting A2L gains, which make a large impact on our range.  We are leaving the gains set in guardian to be the ones that we've found for 3 hours into the lock, but this will probably cost us about 5Mpc of range early in the lock.

Overnight, our our low range was partially because the angle to length decoupling was poor (and partly because the squeezing angle was poor). We were running the angle to legnth decoupling script this morning when an EQ unlocked the IFO, and now we have re-run it with a not thermalized IFO. 

I manually changed the amplitudes for the A2L script again on a per optic bassis to get each A2L set in a first round, there was still significant CHARD P coherence.  I've edited the run_all_a2L.sh script so that some degrees of freedom are run with amplitudes of 1, 3 or 10 counts excitations, this has now run and suceeded in tuning A2L for each DOF on each optic, this second round seems to have improved the sensitivity.  We may need to tune these amplitudes each time we run a2L for now.

After our second round of A2L, the ASC coherences were actually worse than after only one round.  We tried some manual tuning using DHARD and CHARD injections, but that didn't work well probably because we took steps that were too large.

After the IFO had been locked and at high power for ~3 hours, we re-ran the A2L script again, which again set all 4 A2L gains, and impoved the range by ~5Mpc compared to the A2L settings early in the lock (see screenshot).  I've accepted these in SDF and added them to LSCparams:

        'FINAL':{
            'P2L':{'ITMX':-0.9598, #+1.0,
                   'ITMY':-0.3693, #+1.0,
                   'ETMX':4.1126,
                   'ETMY':4.2506}, #+1.0},
            'Y2L':{'ITMX':2.8428, #+1.0,
                   'ITMY':-2.2665, #+1.0,
                   'ETMX':4.9016,
                   'ETMY':2.9922 },#+1.0}

This means that the A2L probably won't be well tuned for early in the locks when we relock, which may cost us range early in the locks.  In O4a we werw also using the camera servo, not ADS, and since we set the camera servo offsets to match ADS alignment early in the locks, we probably had less than optimal decoupling late in the lock stretches.  This probably had less of an impact on range since these noises are contributing in the same frequency range as the ESD noise was in O4a.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 12:26, Friday 19 April 2024 (77290)

about 1 day after this retuning, it seems that the ASC coherence is similar to right after the tuning, with CHARD Y coherence below 15 Hz.  This was before the HAM1FF changes today.

Images attached to this comment
H1 SQZ
naoki.aritomi@LIGO.ORG - posted 13:39, Thursday 18 April 2024 (77268)
PSAMS revert

Naoki, Camilla

We reverted PSAMS from 7.5/0.55 to 8.8/-0.67, which was done last Friday in 77133. Before and after PSAMS change, we ran SCAN_ALIGNMENT and took 5+5 min asqz/sqz data. The attached figure shows that 8.8/-0.67 is better than 7.5/0.55. In parallel, A2L tuning was ongoing so the noise below 100 Hz in SQZ should be due to A2L.

asqz 120/137 (strain voltage 7.5/0.55) (5 min)

PDT: 2024-04-18 10:59:48 PDT
UTC: 2024-04-18 17:59:48 UTC
GPS: 1397498406

sqz 120/137 (strain voltage 7.5/0.55) (5 min)

PDT: 2024-04-18 11:06:29 PDT
UTC: 2024-04-18 18:06:29 UTC
GPS: 1397498807

asqz 170/95 (strain voltage 8.8/-0.67) (5 min)

PDT: 2024-04-18 12:01:57 PDT
UTC: 2024-04-18 19:01:57 UTC
GPS: 1397502135

sqz 170/95 (strain voltage 8.8/-0.67) (5 min)

PDT: 2024-04-18 13:35:01 PDT
UTC: 2024-04-18 20:35:01 UTC
GPS: 1397507719

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:16, Thursday 18 April 2024 (77267)
Thu CP1 Fill

Thu Apr 18 10:06:27 2024 INFO: Fill completed in 6min 23secs

Jordan confirmed a good fill curbside.

Images attached to this report
H1 General
corey.gray@LIGO.ORG - posted 08:12, Thursday 18 April 2024 (77264)
Thurs DAY Ops Transition

TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 6mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

H1's had range hovering between 150-155Mpc 24hrs ago.  After the EQs last night, H1 made it back UP. but seems a bit off with a range down near 110Mpc.  Sheila has just walked in and mentioned Commissioning time is planned from 8-11am this morning and she is jumping in on that---so we are out of OBSERVING.  Heard Sheila mentioned angular coupling and tried No Squeezing and is now looking at A2L (but we are at the very beginning of investigations and commissioning). 

The togglingof No Squeezing to Freq Dep Squeezing helped with the range already.  And Sheila is currently running an A2L.  And it looks like L1 is also joining us with commissioning.

H1 SUS
anthony.sanchez@LIGO.ORG - posted 02:54, Thursday 18 April 2024 (77263)
SUS SDF Diffs Accepted

I accepted these P2L spot gain SDF Diffs to get into Observing.

Images attached to this report
H1 DetChar (DetChar)
manasadevi.thirugnanasambandam@LIGO.ORG - posted 02:41, Thursday 18 April 2024 (77262)
DQ shift report for week from 2024-04-08 to 2024-04-14

Summary highlights of DQ shift the week from 2024-04-08 to 2024-04-14

Full DQ shift report with daily observations can be found in the wiki page here: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20240408

 

H1 SEI
anthony.sanchez@LIGO.ORG - posted 01:04, Thursday 18 April 2024 (77261)
Owl Shift update.

TITLE: 04/18 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM_EARTHQUAKE
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.97 μm/s
    Secondary useism: 1.28 μm/s
QUICK SUMMARY:

Starting the Shift Oli and I noticed that the IFO was still relocking and needed an initial_alignment.
Since then Initial_alignment had stalled and been restarted. Possibly because the IMC was unlocked. I'm usure if Oli had done that or not.

Once that completed Another earthquake hit but was not announced over verbals.
M 5.3 - 60 km WSW of Pozo Dulce, Mexico 2024-04-18 07:39:45 (UTC)26.546°N 110.267°W10.0 km depth
So I'm just waiting on the earthquake to pass.

H1 General
oli.patane@LIGO.ORG - posted 00:10, Thursday 18 April 2024 (77260)
Ops EVE Shift End

TITLE: 04/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Quiet night most of the night, but had a local earthquake knock us out close to the end of my shift. Currently running an initial alignment with the help of H1 MANAGER running an initial alignment and Tony watching H1 MANAGER run the initial alignment to make sure H1 MANAGER gets us locking once that's done.
LOG:

23:00 Detector Observing and Locked for over 15 hours

06:08 Earthquake mode activated
06:11 Lockloss due to local earthquake
    - ALS flashed were really low and took a while to get up
07:03 Started an Initial Alignment

 

H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 23:12, Wednesday 17 April 2024 (77259)
Lockloss

Lockloss 04/18 06:11UTC due to local earthquake :( We were locked for 22.5 hours

H1 General
oli.patane@LIGO.ORG - posted 20:45, Wednesday 17 April 2024 (77258)
Ops Eve Midshift Status

Observing at 155Mpc and locked for 20 hours exactly. Calm evening with low wind

H1 SQZ (ISC, SQZ)
jennifer.wright@LIGO.ORG - posted 17:12, Wednesday 17 April 2024 - last comment - 10:37, Wednesday 09 July 2025(77213)
OMC Scan with SQZ beam yesterday

Naoki, Vicky, Jennie W

 

Naoki followed the directions in to set up the SQZ beam OMC scan.

We had a problem with the DC centering loops. After we switched them on they saturated the OM1 and OM2 suspensions.

We got around this by switching each of the 4 degrees of freedom on first - ie. DC3 Y, DC3 P, DC4 Y, DC4 P.

Then we engaged OMC ASC and this seemed to work ok.

When we tried to manually lock the OMC length loop we had problems as when we switched the gain of 1 on it would lose lock, even when on a TM00 mode of the expected height (0.6mA on DCPD_SUM).

Vicky got around this this using a lower gain and not engaging the BOOST filter in the servo filter bank.

Then she had to touch up the alignment in lock with OM3.

locked quiet time 1397329970 GPS 1 min:

OMC-REFL_A_LF_OUT16 = 0.0930255 mW

OMC-DCPD_SUM_OUTPUT = 0.652156 mA

 

unlocked quiet time 1397330106 GPS 1 minute:

OMC-REFL_A_LF_OUT16  = 1.04825 mW

OMC-DCPD_SUM_OUTPUT = -0.00133668 mA

 

dark measurement 1397330625 GPS 1 minute:

OMC-REFL_A_LF_OUT16  = -0.0133655 mW

OMC-DCPD_SUM_OUTPUT = -0.00133668 mA

 

I noticed after I took the dark measurement that OM1 and 2 were staurating again and need to clear history twice on OM1 to remove this.

Reverted OM1 and 2, 3 OMC sliders at 8:33 am (local time) on the 16th April.

Data is saved as REf 3, 4 and 5 in /ligo/home/jennifer.wright/Documents/OMC_scan/2024_04_16_OMC_scan.xml. Where 3 is the scan channel OMC-DCPD_SUM_OUT_DQ on the bottom right plot, 4 is the PZT excitation channel OMC-PZT2_EXC on the bottom left plot, and 5 is the monitor of the actual PZT output voltage OMC-PZT2_MON_DC_OUT_DQ on the top right plot.

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 20:43, Monday 06 May 2024 (77672)

Using Sheila's code from this entry and updating the code with the current OMC values for transmission of the mirrors:

Tio = 7670e-6 #according to T1500060 page 116 input and output mirror transmission

R_inBS = 1-7400e-6

The outout of the code gives us the following values for the cavity incident power, efficiency and finesse:

Power on refl diode when cavity is off resonance: 1.062 mW

Incident power on OMC breadboard (before QPD pickoff): 1.078 mW

Power on refl diode on resonance: 0.106 mW

Measured effiency (DCPD current/responsivity if QE=1)/ incident power on OMC breadboard: 70.5 %

assumed QE: 100 %

power in transmission (for this QE) 0.760 mW

HOM content infered: 8.748 %

Cavity transmission infered: 77.827 %

predicted efficiency () (R_inputBS * mode_matching * cavity_transmission * QE): 70.493 %

omc efficency for 00 mode (including pick off BS, cavity transmission, and QE): 77.251 %

round trip loss: 2063 (ppm)

Finesse: 362.923

 

I need to compare the HOM content measurement with that derived from the mode scan.

jennifer.wright@LIGO.ORG - 10:37, Wednesday 09 July 2025 (85637)

Just realising now that I need this data that I never posted the results of the OMC scanm with this squeezed beam for the ZM4 = 120, ZM5 = 137 PSAMS settings.

The analysis was run with /labutils/omc_scan/fit_two_peaks_no_sidebands10.py and the function this uses to fit the whole scan is OMCscan_no_sidebands10.py, this code is in the /ligo/gitcommon/labutils/omc_scan repository but in the dev branch.

The first graph shows the full scan, the second zoomed in on the fit for the CO2 mode, since the astigmatism in our OMC is too small to resolve the two modes this fit has less value than with the old OMC.

To work out mode-matching it is probably enough to use the C02 height from the data and not the fit.

Non-image files attached to this comment
H1 ISC (SEI)
jim.warner@LIGO.ORG - posted 14:34, Wednesday 17 April 2024 - last comment - 12:27, Thursday 18 April 2024(77254)
New HAM1 FF

Jennie, Jim

We tried Gabriele's newest version of the HAM1 ASC feedforward. New filters were installed last week, but we ran out of time during the commissioning window. It seems like we can still only get good subtraction from the pitch degrees of freedom, we got a lot of 10-ish hz injection when we engaged the yaw degrees of freedom.

To start we turned off the HAM1 ff, by setting H1:HPI-HAM1_TTL4C_FF_INF_{RX,RY,Z,X)}_GAIN to zero, then shutting off the H1:HPI-HAM1_TTL4C_FF_OUTSW. While collecting that data we switched to the new filters, and zerod the gains for all of the individual H1:HPI-HAM1_TTL4C_FF_CART2ASC{P,Y}_{DOF}_{DOF}_GAIN filter banks.  We then tried turning on all of the pitch feedforward first, by ramping the gains in a couple of steps from 0 to 1. It seemed like it worked well, but I don't think we actually got to full gain of 1. We then tried turning on the yaw FF, but that pretty quickly started injecting noise around 10hz, first attached spectra, red traces are with the new ff, blue are with ff off.

Second image are trends where Jennie tries to reconstruct the timeline, which is how we found the first pitch test wasn't complete. Sheila ran an A2L measurement, then we tried the pitch ff again, spectra in the third plot. All of the red traces are new P ff (1397415884), blue is the old (1397407980), green is with the ff off (1397405754).  This worked well, we got some slight improvements around 15hz, new chard p gets rid of some noise injection around 2hz. We didn't see the pitch ff affect the yaw dofs.

We left the new pitch filters running, and accepted in the Observe SDF. The yaw filters were left off.

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 12:27, Thursday 18 April 2024 (77271)

I looked at the attempt of engaging the HAM1 yaw FF:
1) the filter that were loaded were correct, meaning they were what I expected
2) retraining with a time when the HAM1 pitch FF were on yields yaw filters that are similar to what was tried, so it doesn't look like it's a pitch / yaw interaction (Jennie also pointed to some evidence of this in the alog)

I suspect there might be cross coupling between the various yaw dofs. I would suggest that we upload the newly trained filters (attached) and try to engage the yaw FF one by one, starting from CHARD that is the one we care most

Images attached to this comment
Non-image files attached to this comment
H1 SQZ (OpsInfo)
camilla.compton@LIGO.ORG - posted 09:20, Wednesday 17 April 2024 - last comment - 09:13, Thursday 18 April 2024(77238)
SCAN_SQZANG added to nominal SQZ path

Sheila, Naoki, Vicky, Camilla

As we continue to see the nominal SQZ angle change lock-to-lock (attached BLRMs). We edited SQZ_MANAGER to scan sqz angle (takes 120s) every time the SQZ locks, i.e. every time we go into NLN.

In  SQZ_MANAGER we have:

We tested this taking SQZ_MANAGER down and back up, it went though SCAN_SQZANG as expected and improved the SQZ by 1dB, range improved by ~10MPc.

We'll want to monitor that the change as SCAN_SQZANG may not give us the best angle at the start of the lock when SQZ is very variable. We expect this won't delay us going into observing as only added 120s and ISC_LOCK is often still waiting for ADS to converge during  this time.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 09:13, Thursday 18 April 2024 (77266)

I have removed this change of path by removing thew weighting as we can see last night SCAN_SQZANG at the start of the lock took us to a bad squeezing once thermalized.

We weren't seeing this changing angular dependence as much before 77133 with the older PSAMS settings (8.8V,-0.7V)  or (7.2V, -0.72V). Current (7.5V,0.5V). We think we should revert to the older setting.

Images attached to this comment
Displaying reports 9041-9060 of 84061.Go to page Start 449 450 451 452 453 454 455 456 457 End