Tue Jun 25 10:08:05 2024 INFO: Fill completed in 8min 2secs
Gerardo confirmed a good fill curbside.
[Dave, Erik]
Dave found that DACs in h1sush2a were in a FIFO HIQTR state since 2024-04-09 11:33 UTC.
FIFO HIQTR means that DAC buffers had more data than expected. DAC latency would be proportionally higher than expected.
The models were restarted, which fixed the issue.
The upper bound on sush2a latency for the first three months of O4B is 39 IOP
cycles. At 2^16 cycles per second, that's a maximum of 595
microseconds.
At 1 kHz that's 214 degrees of phase shift.
Normal latency is 3 IOP cycles, 46 microseconds, 16 degrees phase shift
@ 1 kHz.
The minimum latency when sush2a was in error was 4 cycles, 61
microseconds, 23 deg @ 1 KHz.
[Erik, Marc, Dave]
h1susex now has a a LIGO 28-bit 32-channel DAC installed.
The timing card was also swapped out for a new card with firmware that's compatible with the DAC.
h1susex now boots from h1vmboot0 running models built with RCG 5.3.0, necessary to support the DAC, as opposed to the rest of the front ends which boot from h1vmboot1 running RCG 5.1.4.
The timing fanout is reporting an firmware version error on the port for h1susex (physical port 4, medm port 3). This is probably because the firmware on the timing card is new. We think we can run with this error.
After the install, DAQ leg 0 was restarted but it only connected to h1susex. When setting up bootserver h1vmboot0, I'd accidentally replaced the DAQ master file. Restoring the old master file resolved the issue.
Ligo 28-bit 32-channel DAC serial number is S2400042
LIGO Timing Card installed is S2101152 flashed with FPGA code version 1000.
LIGO DB25 to BNC Breakout box installed on LD32 port 0 (directly to the adapter board). BNC's 1-8 attach to 2nd PEM chassis ports 1-8.
Fil, Camilla
After finding that the sqz laser glitches may be linked ot the last 9th May TTFSS swap 78549, today Fil and I swapped D2300329 Laser Locking Fiber Beat Note Chassis back to the original.
Installed Chassis S2300258
Removed Chassis (but left in the rack) S2300259
To avoid issues seen after swapping chassis before 77754, 77746 we may want to adjust TTFSS beatnote threshold polarization as RFAMP has dropped from 7.7 to 1.8dB. Plot
TITLE: 06/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
SEI_ENV state: MAINTENANCE
Wind: 5mph Gusts, 3mph 5min avg
Primary useism: 0.06 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY: We went down earlier to start our early maintanence day.
22:00UTC Observing after Tuesday Maintenance finished
WP11928
TJ, Marc, Dave, Erik
h1susex is currently powered down, we are installing the LIGO 28AO32 DAC card.
I ended the lock to start an early maintenance today in coordination with LLO. To prep for the EX CDS work I transitioned:
Dave was removing the link for the software watchdog as I was typing this. CDS team should be ready to go.
TITLE: 06/25 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Quiet shift with H1 locked the whole time; current lock stretch is up to 11 hours.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
18:36 | SAF | - | LVEA | YES | LVEA is laser HAZARD | Ongoing |
16:27 | sqz | terry.KarMeng | optics lab | yes | shg work | 23:33 |
18:05 | PCAL | rick.tony.francisco | PCAL Lab | Yes | pcal work | 23:28 |
State of H1: Observing at 153Mpc; locked for almost 7 hours.
Dropped observing from 23:42 to 00:17 UTC to implement new SRCL FF (alog78632), get 12 minutes of no-SQZ time (from 23:52 to 00:04 UTC), and optimize SQZ angle with the SCAN_SQZANG Guardian state. Otherwise, it's been a quiet shift so far.
There was a glitch during this no SQZ time, we have 9 minutes without a glitch from 1403308348 (2024/06/24 23:52:10 UTC) to 1403308880 (2024/06/25 00:01:02 UTC).
FAMIS 20703
There was an interesting jump down in NPRO output power at the same time as a jump up in AMP1 and AMP2 output powers earlier today. Pump currents and diode powers seem unchanged, so I'm not sure why a change in power like this would've happened.
PMC REFL is on the rise again, which seems to be bringing down PMC TRANS, ISS diffracted power, and RefCav transmitted power along with it. I can adjust the RefSignal to boost the diffracted power when we're next unlocked.
Jennie, Ryan S, Camilla
After Jennie's 78629 measurements, we fit the SRCL FF (not time for MICH). Possible we might add noise at 300Hz but this is FF looks overall better.
Old SRCLFF was FM2 with gain 1.18 (didn't account fort this is code but should have changed this to 1 for best iterative fitting). New FF is FM4 gain 1.18. Plot attached. SDF saved and ISC_LOCK edited and loaded.
TITLE: 06/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: RyanS
SHIFT SUMMARY:
Today there was a 3hr Commissioning Period, but down time extended a couple of hours after that due to a lockloss (which also had a very misaligned BS & SR2 and SRM). There was a retracted superevent. And during the handoff a few minutes ago, H1 was dropped from observing due to the Camera26 (Beamsplitter); Dave restarted it to get us back to Observing. There is high frequency noise for H1 even after 2.5hrs of thermalizing. Ryan and Camilla chatted about dropping H1 out of OBSERVING to run the SQZ ANG and also try a feed forward set-up within this hour.
LOG:
TITLE: 06/24 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 19mph Gusts, 8mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.15 μm/s
QUICK SUMMARY: H1 has been locked and observing for 2 hours. High frequency range doesn't seem great, but there's a plan from commissioners to take no-SQZ time and try a new SRCL FF this evening.
I followed Camilla's instructions at
/opt/rtcds/userapps/release/lsc/h1/scripts/feedforward/README.txt
I requested the ISC_LOCK guardian go to NLN CAL MEAS.
Ran SRCL_excitation.xml in /opt/rtcds/userapps/release/lsc/h1/scripts/feedforward/
The FF filtersd are at sitemap->LSC->OVerview -> IFO_FF
Set the gain of SRCLFF1 filter bank to 0, turned off ff and input, cleared history, turned gain back to 1
Ran SRCLFF_excitation_ETMYpum.xml
Ramped the gain to 0, turned on ff filter and input, turned gain back to 1 on SRCLFF1 block.
Accidentally ranthe wrong template (MICHFF_excitation.xml) so I aborted the measurement and ran the correct template
MICH_excitation.xml instead.
Ramped the gain of MICH FF block to 0, turned off ff and input, cleared history, then turned gain back to 1.
Ran MICHFF_excitation_ETMYpum.xml
Finished FF measure at 16:49:19 UTC
Fitting to come...
Although after discussion at the commissioning meeting earlier we think the thermal transient OM2 causes will not settle to a steady state till two days time so this measurement may need to be redone if the output mode-matching of the interferometer changes.
Committed versions of the MICH and SRCL FF measurements today all with the suffix _OM2_heating, I didn't want to commit the modified templates that don't have this suffix in case I had saved over anything so made these copies.
Jennie W, Sheila
At the start of the commissioning period we did some OMC Alignment tests to see if this improved our optical gain.
First Sheila turned off injection of squeezing.
15:32:50 UTC Started OM1 and OM3 dithers at 15:32 UTC roughly from OMC control screen. sitemap -> OMC -> OMC Control then push slider shown in this image to on.
15:32:50 UTC started low frequency OMC ASC dither lines via template at /ligo/home/jennifer.wright/Documents/OMC_Alignment/20240419_OMC_Alignment_EXC.xml
Stopped OMC ASC lines at 16:03:07 UTC.
The lines effect on the OMC ASC degrees of freedom and kappa C (optical gain) can be seen here.
Then we re-injected freq dep squeezing.
OM1 and OM3 dither lines were turned off at 16:03 UTC.
After these tests we proceeded to run A2L optimisation recorded here.
To analyse the date I used a version of Gabriele's method where we demodulate OMC DCPD SUM at the OMC ASC dither frequencies and then the 410Hz PCAL line, to see what combination of QPD alignment offsets gives the highest optical gain.
The notebook is at /ligo/home/jennifer.wright/Documents/OMC_Alignment/OMC_Alignment_2024_06_24.ipynb
and can be ran using:
jupyter notebook OMC_Alignment_2024_06_24.ipynb
and then opening the provided link in your browser.
The time series of the QPD offsets being changed are in this image. The right-hand plots show the cleaned DARM time series for different BLRMs regions. It can be seen that the first three have large glitches in the time series, but the 410 Hz one on the bottom right does not and so this frequency should be good for analysis.
The same plot but using data from the OMC DCPDs in the same frequency regions on the right is here. Again, there are glitches in the other BLRMS frequencies, but the 410 Hz one looks clear.
The final plot shows the BLRMS at 410Hz after the double demodulation against the QPD offsets, the red lines are set to be the proposed change in QPD offset. For three it does not look like changing ther QPD offset will improve the optical gain. For the bottom right (H1:OMC-ASC_QPD_B_YAW_OUTPUT) the correct offset change could be 0 or it could be +0.1.
It was decided not to change any of the ASC alignment offsets therefore.
A few weeks back Oli put in an alog about IMC and SRM M3 saturations during earthquake lock losses. In April of 2023 Gabriele had redesigned the M1-M3 offload, reducing the gain of the offload somewhat to get rid of 3-ish hz instabilities in the corner cavities. This may have contributed to the SRM saturations that Oli found, so we want to try adding some low frequency gain back into the SRM offloading.
Sheila wrote out the math for me for the stability of both the SRCL loop and the stability of the M1-M3 crossover, so I have been looking at ways to increase the low frequency gain without affecting the stability above 1hz. The open look gain for SRCL looks like :
SRCL_OLG = SRCL_sens * SRCL_FIlter * (SRM_M3_PLANT+SRM_M1_LOCK_FILTER * SRM_M1_PLANT);
The SRM M1-M3 offloading looks like:
SRM_OFFLOAD_OLG = SRM_M1_LOCK_FILTER * SRM_M1_PLANT * SRCL_sens * SRCL_Filter / (1-SRM_M3_PLANT * SRCL_sens * SRCL_FILTER);
Both of these are (or behave like) open loop gains (g), so the suppression/gain peaking can be show by looking at the 1/(1-g) for each.
I made a 50mhz boost filter for this and tried it during the commissioning window this morning. Bode plots for the boost (red), boost *m1 lock filters(blue) and the nominal M1 lock filter(green) are shown in the first image). The affect on M3 drives and SRCL are shown in the second image asds, live traces are with the new boost, refs are without. There is good reduction below 100mhz, but there is gain peaking from the M1-M3 offloading at .2-.4hz. which might bleed into the secondary microseism during the winter. I'm working on a filter with similar gain, but less gain peaking in a region that won't affect the overall rms of the m3 drive as much. I will try installing and testing during maintenance tomorrow.
These are some of the design plots I have been using. First image is the M1-M3 cross-over, red is the Mar 2023 filter that may have been causing 3ish hz instabilities, solid blue is the filter that Gabriele installed at that time, dashed purple is the boost I tried this morning, and dotted yellow is a modified boost that I want to try tomorrow. Second plot is the suppression for each filter. The .2-.3 hz gain peaking I saw during the test this morning is easy to see in the dashed purple on the second plot, I think the dashed yellow will have less gain peaking and move it closer to .7-1hz where it won't affect the rms of the M3 drive as.
The new boost is installed on SRM and ready to try when we get a chance. Attached image shows the bode plots for the boost filter (red), boost*nominal M1 filters(blue), and the nominal M1 filters (green). I think we might try to test these on Thursday.
I tested this new boost yesterday, it works well, so I'm adding engaging FM5 to the ISC_DRMI guardian. Will post a log with the results in a bit.