TITLE: 01/23 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
H1 has been locked and Observing for just under 8 hours.
It's been a quiet night.
No locklosses, but No events either though.
Looking for the latest In-Lock Sus Charge files i find that last ones were made on Jan 7th and already alogged 82163 .
cdsws25: ls /opt/rtcds/userapps/release/sus/common/scripts/quad/InLockChargeMeasurements/rec_LHO -lt | head -n 6
total 527
-rw-r--r-- 1 test_user controls 160 Jan 7 07:58 ETMX_12_Hz_1420300733.txt
-rw-r--r-- 1 test_user controls 160 Jan 7 07:50 ETMY_12_Hz_1420300262.txt
-rw-r--r-- 1 test_user controls 160 Jan 7 07:50 ITMY_15_Hz_1420300244.txt
-rw-r--r-- 1 test_user controls 160 Jan 7 07:50 ITMX_13_Hz_1420300243.txt
-rw-r--r-- 1 test_user controls 160 Dec 17 07:58 ETMX_12_Hz_1418486333.txt
Since I thought I remember us being locked this past Tuesday morning I checked to see if the SUS_Charge Guardian ran and it looks like it didn't run, but we were actually locked?
I don't see a reason why it wouldn't have run. It looks like since the h1guardian1 machine reboot ont he 14th it hasn't run. Looking at the code it wait for exactly 07:45:00 PT. Maybe it missed that exact second for some reason? That said, the EXECTIME channel for that node shows 0, so I would expect it to catch that second. I've reran SUS_CHARGE through INIT and we'll see if it does it next Tuesday. If not, perhaps we change this to have a >1 second buffer on start time.
TITLE: 01/23 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Planned commissioning time today that focused on a PR2 spot move. There was a lock loss during this spot move and we decided to revert the move. Recovery was a bit challenging, but pico hysteresis or similar could be the cause. Read more below. One side effect of the picoing from the PR2 move, is that the ALS camera spots are slightly different. Some of the clipping that we would see on ALSY is no longer there and ALSX now has some in the top left corner.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 17:16 | SAFETY | LAZER HAZ (\u2310\u25a0-\u25a0) | LVEA | !!!YES!!! | LVEA = LASER HAZARD! | 16:51 |
| 16:01 | FAC | Kim | Opt Lab | n | Tech clean | 16:24 |
| 16:33 | PEM | Robert | LVEA | yes | Viewport beam spot measuring | 17:26 |
| 18:42 | FAC | Kim | MX | n | Tech clean | 19:30 |
| 19:02 | VAC | Janos, tourer | EX, MX | n | Tour | 20:51 |
| 19:30 | PEM | Robert | LVEA | yes | Closing up viewports | 20:00 |
| 21:25 | PCAL | Tony | PCAL Lab | local | PCAL lab work | 23:50 |
| 23:31 | ISS | Keita, Rick, Jennie, Mayank, Sivananda | Opt Lab | n | ISS array |
|
TITLE: 01/23 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: SEISMON_ALERT
Wind: 2mph Gusts, 1mph 3min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.20 μm/s
QUICK SUMMARY:
All systems seem to be working well. (Execpt that Dust monitor)
Just transitioned into Earthquake mode for a 5.8 M earthquake, hopefully we can ride it out.
Sheila, Jenn{e,ie}, Robert
Continuing efforts to find out how to minimise the beam from PR2 clipping on the scraper baffle, as investigated in alogs #[77870, 77968, 77988, 81329].
At the start Sheila and Jenne agreed we should try to find the two extrema where the beam going from PR2 to PR3 clips the scraper baffle and the one going from PRM to PR2 clips the scraper baffle.
Sheila measured the PR2 Y2L gain by minimising the transfer function from PR2 yaw position to PRCL_OUT, while injecting a line at 30Hz as in [LHO alog #82251] entry.
New P2L: -0.36 from the measurement I did the other week.
New Y2L: -6.25
Now the aim was to move the spot on PR2 to find where each beam hitting it clips the PR2 scraper baffle.
Move PR3 in negative yaw while monitoring LSC-POP_A_LP_NORM (pop power) and PR2 inmon on M1 to check ASC is not changing much to ensure we do not unlock the IFO. Every 13 PR3 microradians is 0.5mm.
We stepped 96 uradians to 68 microradians on PR3 yaw and corrected pitch down every time we dipped too low on LSC-POP or PWR_CIRC, every 1 microradian or so jenne moved picomotor A_8 (the one that aligns to both the ALS PDs and the LSC-POP PDs) by -50 counts to bring back the LSC POP alignment.
I measured our new Y2L to be -5.75 gain at this new value (moved 1 mm according to Jenne's script). Robert looked at the beam reflected off the baffle to the viewport at this point as a check of the power in it relative to our nominal position for the PR2 beam spot.
We kept going after this point but lost lock after moving about 8.5 microradians.
ETMX glitch, and it looks like it was glitching for a tens of seconds before we lost lock - shot from lock lost tool.
Interestingly, ALSX was having issues staying locked after this lock loss. See attached for an example.
L. Dartez, E. Goetz, J. Kissel Yesterday's test results and plots show that (a) Installing one additional copy of the existing 65 kHz to 16 kHz "Dec16k" filter improves the 20-2000 Hz band aliasing dramatically, where as that *and* one additional copy of the 524 kHz to 65 kHz "Dec65k" filter does not significantly improve the 20-2000 Hz band aliasing (but one copy is still required). See LHO:82405 (b) We have (just barely) enough phase margin in the DARM loop to install more digital anti-aliasing. (I plan to make better plots today, but see page 1 of 4th attachment of LHO:82387) (c) We have (just barely) enough CPU clock-cycle turn-around time to install a few more filters (see 2nd attachment of LHO:82375). If this proves problematic, we can start clearing out test filters to claw back computation time. As such, we plan to move forward with installing an additional 65k to 16 kHz "Dec16k" filter in the primary GW-channel, 524 kHz, DCPD A0 and B0 banks tomorrow. We happen to be unlocked now, so I've staged (loaded in, installed, but NOT turned off) the new additional filter in the A0 and B0 bank into the H1IOPOMC0.txt foton file. While there, I took the time to improve the name and clarity of the A0 and B0 filter banks, much like I've done in the A1, A2, B1, B2 test banks (in LHO:82313), - Renamed "NewV2A" and "NewAW" in the A0 and B0 banks -- which are *different* filters, to compensate for the *different* analog electronics in those PDA and PDB chains -- to . "PDA_V2A" and "PDA_AW" . "PDB_V2A" and "PDB_AW" - Split out the gain that was in "cts2V" = gain(0.0006105)*gain(0.25)*gain(0.25) into two banks "18b_cts2V" and "sum4avg" . For the "18b_cts2V" gain, even though gain(0.0006105)*gain(0.25) = gain(0.000152625) which DOES NOT equal the "right" gain of 40/2^18 = 0.000152587890625, (a ratio of 1.0002432, or 0.24% different). In the spirit of moving stuff around without changing anything I installed the a gain(0.000152625) for now. Also, at the 0.24% level, the channel to channel gain is probably different anyways, and comes out to some make-shift value anyways in the 4-channel averaging. The "not right" gain comes from the typo of 40/2^16 = 0.0006103515625, which was installed as 0.0006105. . The "sum4avg" is the gain(0.25) you would expect to turn the sum of 4 channels into an average. - Moved the "18b_cts2V" , "sum4avg" and "A2mA" gains to be in FM3, FM4, and FM5 - Such that now there's a "Dec65k" in FM8, and two copies of "Dec16k" in FM9 and FM10. Also -- since the H1:OMC-PI_DOWNCONV_INMTRX matrix is configured to use only DCPD A, I made similar changes OMC PI DOWNCONV SIG bank, except -- in tthe event we ever need to switch the sig bank over to DCPD B, I installed the "PDB_V2A" and "PDB_AW" filters there as well. See attached screenshots. (1st) Screenshot of the A0 and B0 banks *before* any changes were made (2nd) Screenshot of the A0 and B0 banks *after* the changes described above were made. NOTE that FM10 is turned OFF. (3rd) Screenshot of the OMC PI DOWNCONV SIG bank *after* the changes. (4th) Screenshot of SDF accept of new arrangement of A0 and B0 filters. (5th) Screenshot of SDF accept of new arrangement of OMC PI DOWNCONV SIG filters. The updated filter file is commited to /opt/rtcds/userapps/release/cds/h1/filterfiles/H1IOPOMC0.txt rev 30480 The updated safe.snap (which is linked to both the safe.snap and OBSERVE.snap) has been committed to /opt/rtcds/userapps/release/cds/h1/burtfiles/h1iopomc0/safe.snap rev 30481
As noted in LHO aLOG 82394, I recommend starting improvements by adding an additional 16k downsampling filter. Attached is a figure showing a comparison of the current situation (red), just 2 16k filters (green), 2 16k filters and 1 65k filter (magenta), and 2 16k filters and 2 65k filters (black). The curve colors are the same as the original FOTON plots in LHO aLOG 82375. These curves are ratios of PSDs using different downsampling filters on the time series data that is manually downsampled by a factor of 32 (524k ==> 16k) versus PSD of the original 524k data (cut off with the maximum frequency of 8192 Hz). The narrow instrumental artifacts are visible by eye in the 8 s FFTs of the DTT measurements, and are much more visible in the CW analyses that use longer coherence times. We can quantitatively assess the improvement by comparing the number of bins in this short analysis that are 1% in excess of the nominal ratio of 1: Full band: 16k 65k bins above 1% = 14847 16k 16k bins above 1% = 6686 16k 16k 65k bins above 1% = 4892 16k 16k 65k 65k bins above 1% = 4809 0 - 2 kHz band: 16k 65k bins above 1% = 430 16k 16k bins above 1% = 21 16k 16k 65k bins above 1% = 0 16k 16k 65k 65k bins above 1% = 0 Note that even though the 2 kHz band has only a few hundred bins above 1%, these artifacts are strongly visible in run-averaged spectra that use longer coherent baselines, similar to all-sky CW searches. One can see that the additional 16k filter does most of the clean up (we don't see a significant change by an extra 65k filter). By employing an additional filter, this should hopefully reduce or eliminate the impact of the narrow instrumental artifacts.
Wed Jan 22 10:03:51 2025 INFO: Fill completed in 3min 48secs
Gerardo confirmed a good fill curbside. TCmins [-78C, -60C] OAT (-1C, 30F)
TITLE: 01/22 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 3mph Gusts, 2mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.25 μm/s
QUICK SUMMARY: Locked for 12 hours, useism dropped quickly overnight. Planned commissioning time this morning.
TITLE: 01/22 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
One lockloss and a successful return to Observing at 3:43 UTC.
Otherwise a quiet night.
LOG:
No Log
TITLE: 01/22 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.64 μm/s
QUICK SUMMARY:
The h1cam23 camera process got stuck. I looked at it with Tony. We shutdown and restarted the corresponding network switch port to power cycle the camera. Then restarted the server process via monit. That didn't work. I ended up having to go onto h1digivideo2 and manually issue the kill command and send a SIGKILL to the camera process. After that the camera process started up nicely and gave us a feed.
J. Freed
Before the hoidays as shown in 81658, the Double Mixer had large phase noises at 4096Hz that were thought to be caused by phase offest difference in the Double Mixer. Thanks to Marc Pirello for the suggestion and help to manually adjust the phase difference by extending the wire lengths inside the double mixer.
DM_PN2.pdf Shows the lower 4096Hz peak in the path adjust(green) as compared to the no path adjust (blue) and both compared to an independant SRS (orange). The harmonics are still large so DAC output had a ~5kHz low pass applied but with negledgable improvement. Investigation was ongoing when I went on holiday.
Today I plugged in the double mixer into a network analyzer to see the power spectrum density of the signal
DM_NA_WIDE.pdf Shows that although the DM has better noise floor, the harmonics of the double mixer are quite a bit worse in the Power spectral desnity than shown in phase noise DM_PN2. The best result (shown) was with NO added length. Unsure why this is.
DM_NA_NARROW.pdf Besides that the signal has a fairly pure tone, though this is limmited by the resolution.
Investigations ongoing
Following up on log 82252, I made movies of HAM3 from the PR2 camera viewport last Thursday as I moved CPy over its pitch range and then, at nearly maximum pitch up, I ran it over its yaw range. In the movie (https://youtu.be/0f0F7cWqpwQ ), the beam spot appears to stay on the ballast baffle. At this highest pitch there appears to be a second spot on the support structure of the baffle. This second spot would be a little lower at the nominal setting. A steeply angled baffle that stuck down a little below the edge of the table might mitigate both of these stray beams.
TITLE: 01/22 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: USEISM
Wind: 5mph Gusts, 3mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.62 μm/s
QUICK SUMMARY:
H1 is Locked and Observing.
Microseism is falling back down.
Noting random Issues :
MC2 PR2 Cameras still unplugged likely due to robert's work in the the LVEA.
ITMY camera not working for some reason.
H1:PEM-CS_DUST_LAB2 Still out sick
TITLE: 01/22 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Maintenance day today, recovery was straight forward in terms of alignment, but we had a lock loss after DRMI ASC and then one at Transition_From_ETMX, which made recovery take a bit longer.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 17:16 | SAFETY | LAZER HAZ (\u2310\u25a0-\u25a0) | LVEA | !!!YES!!! | LVEA = LASER HAZARD! | 16:51 |
| 16:07 | FAC | Chris | LVEA | yes | FAMIS tasks | 16:38 |
| 16:10 | PCAL | Francisco | EX | YES | PCAL spot move | 17:33 |
| 16:27 | SUS | RyanC | CR | N | ETMY oplev charge measurement | 17:36 |
| 16:32 | FAC | Kim, Nelly | LVEA | yes | Tech clean | 17:33 |
| 16:48 | SYS | Mitchell | LVEA | yes | Looking for cables | 17:21 |
| 16:59 | FAC | Chris | LVEA | yes | Battery fluid | 17:46 |
| 17:02 | PEM | Robert | LVEA | yes | Setting up equipment | 19:42 |
| 17:06 | PSL | Jason, Ryan S | CS | n | Chiller swap (PSL DOWN!) | 19:37 |
| 17:22 | VAC | Janos, Travis | LVEA | yes | Chat with Chris | 17:32 |
| 17:25 | CDS | Fil, Marc | CER | n | Investigating for future OMC work | 17:42 |
| 17:33 | FAC | Kim, Nelly | EX | n | Tech clean | 18:35 |
| 17:37 | FAC | HFD | Ends | n | Radio testing | 18:52 |
| 17:47 | FAC | Chris | H2 | n | Tumbleweed clearing | 19:41 |
| 18:04 | VAC | Janos, Travis | EX mech room | n | Compressor work | 20:02 |
| 18:27 | CDS | Fil, Marc, Sivananda | CER | n | Power supply fan swap | 19:54 |
| 18:28 | PSL | Jason | PSL ante. room | yes | Looking for ISS array parts | 18:47 |
| 18:36 | FAC | Kim, Nelly | FCES | n | Tech clean | 19:00 |
| 18:51 | SYS | Mitchell | LVEA | yes | Cable hunt Rd2 | 19:04 |
| 19:00 | SUS | RyanC | CR | N | ETMX oplev charge meas | 20:08 |
| 19:06 | SEI | Jim | CR | n | BSC filter testing | 20:02 |
| 19:10 | FAC | Kim | EY | n | Tech clean | 19:47 |
| 19:19 | TCS | Camilla, Matt | LVEA | YES | TCS table power meas. | 20:12 |
| 19:55 | SYS | Chris, Mitchell | LVEA | yes | Scissor lift troubleshooting | 20:01 |
| 19:58 | ALS | Keita, Mayank | CR | n | ALSY demod phase measurement | 20:58 |
| 20:00 | - | Mike, Haydee | LVEA | yes | Tour | 20:19 |
| 20:22 | IAS | Ryan C | LVEA | yes | Faro power cycle | 20:24 |
| 20:24 | - | Ryan S, Matt | LVEA | yes | LVEA sweep | 20:55 |
| 22:28 | PEM | Robert | LVEA | Yes | Setup stray beam at viewport equipment | 23:49 |
[Keita, Mayank] We optimized the ALSY PDH demod phase of the CM board. We measured the OLTF of the PDH loop using the setup detailed in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=82166 at 3142Hz. (Note that the raw number measured is 40dB smaller than the actual gain due to electronics gain in the generic DAQ filter in the denominator.) We changed the delay line between the local oscillator and the demod board to maximize the OLTF amplitude. Before we changed anything, we measured the ALSY OLTF and it was about 9 dB smaller than ALSX at 3142Hz. As we changed the delay line we eventually had to decrease the IN1 LOCKED gain of the CM board (H1:ALS-Y_REFL_LOCK_LOCKEDGAIN) by 3dB so that ALSY OLTF becomes about the same as ALSX. ALSY locked and ran fine with that setting. Initial values: Delay line Phase: 223 Degree (421 steps), CM board LOCK IN1 gain +10dB, TF magnitude measured -37 dB. Tuned value: Delay line Phase: 165 Degree (311 steps), CM board LOCK IN1 gain +7dB, TF magnitude measured -27 dB. Attached is the screenshot of before (blue) and after (red) the tuning as well as ALSX (black dotted)
J. Kissel Pushing forward and making filter file changes while out of observing, I've changed the arrangement and amount of filtering in the OMC DCPD A1, A2, B1, and B2 banks again. Last time, I configured the banks to be analog channel agnostic, so I used up the spare filter banks to include copies of both the A and B analog electronics compensation in each of the four paths (LHO:82313). Talking with Louis and Evan this morning, in light of the discovery that more digital anti-aliasing would be prudent, I instead use up the spare banks for copies of the existing anti-aliasing filters (much like Louis and Evan had done over the weekend). Check out screenshot of the configuration setup for one test we plan to do: using the 1st attachment in LHO:82375, comparing the performance of the RED, Dec65k*Dec16k filtered nominal trace to GREEN Dec16k*Dec16k and MAGENTA Dec65k*Dec16k*Dec16k. These options, which have lesser phase impact that the straight 2x copy of the existing filters, will also tell us whether it's the frequency content in the signal between 7 and 32 kHz or that of 32 kHz and above that matters in the GW band.
I took data from both the A and B TEST paths for the two filter arrangements right now: 2x16k filtering or 2x16k + 1x65k filtering. Attached are ratio plots of the PSD of simple decimation of the filtered data over the PSD of the full data rate filtered data. For both the A and B path, the 2x16k + 1x65k filtering (orange curve) is much better than just 2x16k filtering (blue curve). This is shown by the orange curve having values much closer to 1 over a broader frequency range than the blue curves.
E. Goetz, J. Kissel, L. Dartez Summary: There is evidence that some of the lines found in the gravitational wave band are actually aliased lines from higher frequencies. So far it is unclear exactly how many of the lines in the run-averaged list are due to this problem and if the lines are stationary or if violin ring-ups may induce more lines in band due to aliasing artifacts. Further investigation is needed, but this investigation suggests that the current level of anti-aliasing is insufficient to suppress the artifacts at high frequency aliasing into the gravitational wave band. Details: We used the live, test-point acquisition of the 524 kHz sampled DCPD data in DTT, channel H1:OMC-DCPD_B1_OUT (equivalent to the nominal H1:OMC-DCPD_B0_OUT channel used in loop). This channel had the same 524k-65k and 65k-16k decimation digital AA filtering applied. The time series was exported from DTT and processed by stitching together the time segments into a single time series. Then one can process the time series using the scipy.signal.welch() function of 1) the full 524 kHz sampled data, 2) 524 kHz sampled data decimated (no additional AA filtering) by a factor of 32 to get the 16 kHz sampled frequency data, 3) 524 kHz sampled data decimated using additional AA filtering by using the scipy.signal.decimate() function which has a built-in anti-aliasing filter. We also plotted in DTT the individual channels against the 16k H1:OMC-DCPD_B_OUT_DQ channel, showing that some of the lines are visible in the in-loop DCPD 16 kHz channel, but not visible in the test point 524 kHz channels. Figure 1: ASD of raw 524 kHz data (blue), decimated data without any extra anti-aliasing filter applied (orange), and decimated data with additional anti-aliasing filtering (green). Orange peaks are visible above the blue and green traces above ~750 Hz. Figure 2: ASD ratio of the decimated data without anti-aliasing filtering to the raw data showing the noise artifacts Figure 3: Zoom of figure 2 near 758 Hz Figure 4: ASD computed from DTT showing DCPD B Ch 1, 5, 9, 13 and and the H1:OMC-DCPD_B_OUT_DQ channel at the same time as the 9 and 13 channels were acquired (limitations of the front end handling of 524 kHz test points to DTT) Figure 5: Zoom of figure 4 near 758 Hz We were also interested in the time-variability of these artifacts and watched the behaviour of H1:OMC-DCPD_B_OUT_DQ, and saw amplitude variations on the order of factors of a few and frequency shifts on the order of 0.1 Hz, at least for the artifacts observed near 758 Hz. Figures 4 and 5 indicate that there are more artifacts not necessarily directly caused by aliasing; perhaps these are non-linearity artifacts? This needs further study. A count of the number of 0.125 Hz frequency bins from 0 to 8192 Hz of the ratio between downsampling without additional anti-aliasing filtering and the raw 524 kHz ASD indicates that ~4900 bins are above a threshold of 1.1 (though most of those bins are above 2 kHz, as indicated by figure 2).
E. Goetz, L. Dartez We temporarily added extra digital AA filtering in the DCPD A1/2 B1/2 TEST banks (we are planning to revert to https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=82313 on Tuesday), to see if we can suppress the aliased artifacts. Repeating the same procedure as before: computing the ratio of the ASD of the decimated data to the ASD of the full 524 kHz band data, both with and without the extra digital AA filtering we can see a significant improvement in the low frequency artifacts. The temporary filtering is just copies of the standard 524k-65k and 65k-16k filters, but it shows significant reduction in low frequency artifacts (see especially Figure 2). This suggests that improvements to the sensing path anti-aliasing filtering would be beneficial to detector sensitivity, reducing the impacts of high frequency artifacts that are being aliased to in-band.
The temporary TEST filter modifications that duplicated the decimation filters into additional filter banks has been reverted back to LHO aLOG 82313.
For easier comparison, I've attached ratio plots the same size and scale as in other aLOGs