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 another look at the data from last week where we put lines on the OMC angular control loops and then used the BLRMS at the PCAL line 410Hz to look at which combination of offsets increased the optical gain.

The plot shown has cursors at the values I think we should change the current offsets by to maximise our optical gain. We expect this could maybe improve the gain by 1%.

I added these values to H1:ASC-OMC_A_PIT_OFFSET, H1:ASC-OMC_A_YAW_OFFSET, H1:ASC-OMC_B_PIT_OFFSET, H1:ASC-OMC_B_YAW_OFFSET.

The second image shows the old values: -0.37, 0.25, -0.17, -0.11

The new values are: -0.45, 0.325, -0.245, -0.19.

At the bottom I attach picturers of where I accepted these sdfs in the safe and OBSERVE snap files. As far as I can tell they are not reset by guardian at any point.

For ETMX, the OPLEV pitch output was higher than typical during the measurement, there is no clear trend across the DOF/quads but the charge is at or above 50V on all DOF/quads except for LL yaw.

ETMY seems to have a small upward trend and is getting over 50V in half of the DOF/quads.

Going back to investigations last week on in-band line artifacts due to aliasing of higher frequency DCPD channel artifacts (see LHO aLOG 82329), here we check the 16 kHz data of H1:OMC-DCPD_[A|B]_OUT_DQ against the saved reference spectra of DCPD B on ADC channels 1, 5, 9, and 13. Attached are spectra showing:

1. 1 Hz - 7000 Hz
2. 20 Hz - 100 Hz
3. 100 Hz - 500 Hz
4. 500 Hz - 1000 Hz
5. 1000 Hz - 1500 Hz
6. 1500 Hz - 2000 Hz
7. 2000 Hz - 7000 Hz

One can see man and a lot of artifacts that are visible in the 16k channels, but not visible in the 524k channels. In addition, the DCPD A sum channel artifacts appear larger than DCPD B sum channel artifacts. As mentioned in the previous aLOG, spending some time watching the time variability of the artifacts, the artifacts change amplitude and frequency over time. The higher frequency bands show a lot of artifacts, more in the A channels, and the artifacts in question do not appear in the 524k channels.

Solving these issues, perhaps with stronger suppression through digital filtering, would be greatly beneficial to searches for persistent, narrowband gravitational wave signals.

J. Kissel, E. Goetz, L. Dartez

As mentioned briefly in LHO:82329 -- after discovering that there is a significant amount of aliasing from the 524 kHz version of the OMC DCPD signals when down-sampled to 16 kHz -- Louis and Evan tried a versions of the (test, pick-off, A1, A2, B1, and B2) DCPD signal path with two copies, each, of the existing 524 kHz to 65kHz and 65 kHz to 16 kHz AA filters as opposed to one. In this aLOG, I'll refer to these filters as "Dec65k" and "Dec16k," or for short in the plots attached "65k" and "16k."

Just restating the conclusion from LHO:82329 :: Having two copies of these filters -- and thus a factor of 10x more suppression in the 8 to 32kHz region and 100x more suppression in the 32 to 232 kHz region -- seems to dramatically improve the amount of aliasing.

Recall these filters were designed with lots of compromises in mind -- see all the details in G2202011.

Upon discussion of applying this "why don't we just add MOAR FIRE" option 2xDec65k and 2xDec16k option for the primary signal path, there was concerns about 
    - DARM open loop gain phase margin, and
    - Computational turn-around time for the h1iopomc0 front-end process.

I attach two plots to help facilitate that discussion,
    (1st attachment) Bode plot of various combinations of the Dec65k and Dec16k filters.
    (2nd attachment) Plot of the CPU timing meter over the weekend, the during in which these filters were installed and ON in the 4x test banks on the same computer.

For (1st) :: Here we show several of the high-frequency suppression above 1000 Hz, and phase loss around 100 Hz for a couple of simple combinations of filtering. The weekend configuration of two copies of the 65k and 16k filters is shown in BLACK, the nominal configuration of one copy is shown in RED. In short -- all these combinations incur less than 5 deg phase loss around the DARM UGF. Louis is going do some modeling to show the impact of these combinations on the DARM loop stability via plots of open loop gain and loop suppression. We anecdotally remember that the phase margin is "pretty tight," sub-30 [deg], but we'll wait for the plots.

For (2nd) :: With the weekend configuration of filters, with eight more filters (the copies of the 65k and 16k, copied 4 times in each of the A1, A2, B1, B2 banks) installed and running, the extremes of CPU clock cycle turnaround time did increase, from "never above 13 [usec]" to "occasionally hitting 14 [usec]" out of the ideal 1/2^16 = 15.26 [usec], which is rounded up on the GDSTP MEDM screen to be an even 16 [usec]. This is to say, that "we can probably run with 4 more filters in the A0 and B0 banks," though that may necessarily limit how much filtering can be in the A1, A2, B1, B2 banks for future testing. Also, no one has really looked at what happens to the gravitational wave channel when the timing of the CPU changes, or gets near the ideal clock-cycle time, namely the basic question "Are there glitches in the GW data when the CPU runs longer than normal?"

R. Short, J. Oberling

Today we swapped the in-service PSL chiller for the spare, so we can do required regular maintenance on the in-service chiller, and changed the system filter.

The PSL was shut down and the chiller lines swapped over to the new chiller.  At this point we swapped the system filter with a new one.  The filter cup was pre-filled with coolant (10% mix of OptiShield in lab water) and the chiller reservoir was filled.  We turned the new chiller on and set the flow to ~4 lpm to help push out air bubbles; the system ran in this configuration for ~90 minutes.  Interestingly, we are back to having small collections of air pockets around the filter cup.  We'll monitor this and bleed air from the filter cup as necessary, but there are no more visible air bubblles moving through the chiller lines that we can see.  I'm wondering if chiller position in the rack has something to do with this?  The old chiller sat ~2 feet lower than the new one, maybe that's contributing to the air pockets (total WAG on my part)?  We're thinking that next time we swap chillers we'll move everything down a shelf and see if/how things change.

The chiller flow was set to ~2.8 lpm, as this is where the old chiller was operating, and the PSL restarted.  Everything came back up without issue and the PSL is running and ready for IFO recovery.  The old chiller was moved to the mechanical room, where we will flush it out and start going through its regular maintenance checks.  This closes LHO WP 12290.

Per WP12295 we replaced the +/-18V Kepco supplies located on the CER Mezanine Rack C2 U17-19.  We replace them as a set, so both plus and minus were replaced.  This was a result of one of these supplies fans failing noisliy.

Supplies Replaced:
S1201926 installed in 2012 was replaced with S1300296 which has an updated ball bearing fan.
S1201923 installed in 2012 was replaced with S1300290 which has an updated ball bearing fan.

Both supplies were tested and measured to output +/-18.5V respectively at the sequencer.  Once powered on they were further adjusted to +/-18.5V when loads were applied.

F. Clara, M. Pirello, S, Reddy

Tue Jan 21 10:04:45 2025 INFO: Fill completed in 4min 41secs

Gerardo confirmed a good fill curbside. TCmins [-71C, -69C] OAT (-2C, 29F). DetaTemp trip time 10:04:45.

The ITMX HWS spherical power was not centered around zero, so after the IFO had been unlocked for 2+ hours, I took new references on ITMX and ITMY HWS at around 18:10UTC. Following tcs wiki. 

Closes FAMIS#26474, last checked 81923

The only thing of note is a small pressure spike at EX seen last week, seen in the pressure and ctrl channel.

FAMIS Link:  26027

Only CPS channels which look higher at high frequencies (see attached) would be the following (which have been like this for a while):

1. ITMx St1 V1
2. ITMy St1 V2

TITLE: 01/21 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 5mph Gusts, 3mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.79 μm/s
QUICK SUMMARY: Locked for 20 min, it looks like 2 auto relockes overnight. The useism is peaking above 1um/s, we'll see if we can relock after maintenance.

Workstations were updated and rebooted.  This was an OS packages update.  Conda packages were not updated.

TITLE: 01/21 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Just got back into Observing after popping out to adjust the opo temperature. Our range had been steadily dropping over the past few locks and had gotten down below 150 Mpc, and our squeezing was getting worse along with it, so I decided to try adjusting the opo temperature before I left. I got us from an average of -3 down to -4.5dB squeezing for the 1.7kHz band. The evening has been quiet and relocking went well earlier with nothing needing to be touched.
LOG:

00:08 Lockloss
01:12 NOMINAL_LOW_NOISE
01:15 Observing

05:54 Out of Observing to adjust OPO temp
06:00 Back into Observing

Since we've been seeing ETMY mode 1 (and mode6 to a lesser extent) increasing during lock stretches for the last 5 or 6 days, I've gone ahead and edited lscparams to use the new filter/gain configuration that TJ noted in 82337 - he does say in there that this configuration has been noted previously to cause mode1 to start ringing back up, but so far we have had a 20 hour stretch a couple days ago with these settings and didn't see any ringing up, so I think we might be okay.

I've reloaded ISC_LOCK and VIOLIN_DAMPING.

12:19 UTC lockloss, IFO_NOTIFY says its was in NLN with SDF diffs, but we lost lock moments before I logged in.

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).

We haven't aligned the OMC ASC for while so today I did Gabriele's method where we inject lines in the four OMC ASC loops at different frequencies and then demodulate the 410 Hz PCAL line at these frequencies and then at 410Hz to look at which combination of offsets improves our optical gain the most.

The plot of BLRMS of the DCPD_SUM_OUT at 410 Hz vs. QPD offset is shown below.

The start and end times used were 17:22:40 UTC and 17:42:40 UTC.

The detector was in NLN s but squeezing was turned off.

The code is at /ligo/home/jennifer.wright/git/2025/OMC_Alignment/OMC_Alignment_2025_01_16.ipynb.

Usually the start and end times the plots use contain some times without the OMC ASC lines but that was not possivle here as we went to NLN_CAL_MEAS before I had turned off the lines.

Looking at the plot, I think we need to change

H1:ASC-OMC_A_PIT_OFFSET by -0.1

H1:ASC-OMC_A_YAW_OFFSET by 0.075

H1:ASC-OMC_A_PIT_OFFSET by -0.075

H1:ASC-OMC_A_YAW_OFFSET by 0.08

or something close to these.

Camilla, TJ, Marc, Fil. WP#12281

We attached the AOM drive cable from the back of the D1300649 chassis to the lowest TEST point in the PEM feed through photo on the CO2X table. We used two barrel connectors (photos attached) to do this as it looks like there used to be an AOM driver on the table that the signal went into before going to the AOM.  

We thought that we could use the digital filters in the h1tcscs model to create a loop with this output and feed to the Synrad UC-2000 PWM controller (needs 0-10VDC). The max of CTRL2 was capped at +/-2 (unsure why) and this was actually +/- 0.6V on the BNC via an oscilloscope. We'll need to increase this by ~x10 to get PWM to work. Reverted changed sdfs. 

There was an unknown cable also labeled AOM drive coming into the table, not connected to anything photo. 

In 81863 we looked a the RIN of the CO2 lasers on vs off. Today we repeated with PWM (from Synrad UC-2000), the noise level is considerably higher when PWM is on. Note that this isn't really the RIN as we're not dividing by the DC power.

Data saved to camilla.compton/Documents/tcs/templates/dtt/20250107_CO2_RIN.xml and 20250107_CO2Y_RIN.xml

• Refs 0-3: Laser on CW
• Refs 4-7: Laser off.
• Refs 8-11: 50% PWM (CO2X laser locked, CO2Y unlocked)
• Refs 12-15: 25% PWM (CO2X laser unlocked)
• Refs 16-19: 95% PWM (CO2X laser relocking)
• Refs 20-23: Laser on CW

The CO2Y plots also show the dark noise as there is no photo detector plugged into CO2Y_ISS_IN.

• CO2Y plots: AC only, DC only, all.
• CO2X plots: AC only, DC only
  • It's strange that there more CO2X DC noise with the laser off and that the 25%, 50%, 95% PWM's are the opposite way around for the AC and DC outputs.

For some of the CO2X data, the CO2 guardian was relocking (sweeping PZT), noted above.