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:

• 16:08 Lock loss
• 1838 All CS SEI tripped from ISC-C4 power supply work. Those in the control room at the time didn't realize that there was a connection between this rack and all of the CS ISIs. This power supply supplies the 71MHz RF that goes to a fanout for all of the these ISI's CPSs.
• 2349 Observing
• 0000 Dropped observing for 8 seconds due to some SDF diff in calcs.

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

Here're the bare-bones instructions to run the DARM loop critique -- an automated set of plots that were inspired by the presentations given over the years that compare the transfer functions of the DARM loop between the two sites, e.g. G1501372, G1700316, G2000149.

(0) Conda activate the latest pydarm environment.
    ~$ conda activate /ligo/groups/cal/conda/pydarm
This is a symbolic link to the latest tagged version of pydarm.
    () ~$ which pydarm
        /ligo/groups/cal/conda/pydarm/bin/pydarm
    () ~$ pydarm --version
        20240821.0
    () ~$ ipython
    In [1]: import pydarm
    In [2]: pydarm.__version__
    Out [2]: '20240821.0' 
Note the version of pydarm is the same on the command line and within the ipython session *because* we activated the correct pydarm conda environment. The command line pydarm internally activates this environment automatically, but any old ipython session may not have the right version of pydarm if you just import "from scratch" without making sure you're in the right environment first. So -- any time you're running script or python session pyDARM these days -- make sure that you've activated the conda environment.

Is this the right version? check https://git.ligo.org/Calibration/pydarm/-/tags see if that version is the latest, i.e. the top of the list.

It is. And this will *always* be true, by process of deploying the latest tag (see deploy script).
To compare previous versions of tags, go to https://git.ligo.org/Calibration/pydarm/-/compare?from=master&to=master and change the drop-down menu to compare one tag to the other.
If you want to activate an environment with an older version of pydarm, then head to the folder /ligo/groups/cal/conda/ and activate the environment you like.


(1) Grab the DARM loop model parameter sets that you want to plot and/or compare. If at LHO, wanting H1 parameter files, then (back out on the command line, not in yet in a python session)
Find the list of reports and tags:
   () ~$ pydarm ls -r
From that list, find the model parameters installed in the front-end:
   () ~$ pydarm ls -r | exported

Once you find what you like, go into that report directory, e.g.
   () ~$ cd /ligo/groups/cal/H1/reports/20240927T211612Z
Look for pydarm_H1.ini, and copy it somewhere you like, or at least store where it lives.

If you're at LHO, want L1 parameter files, then the easiest thing is to download it from the web. Head to the https://ldas-jobs.ligo-la.caltech.edu/~cal/ and scroll down to the list of all reports, and find the entry that's been exported most recently e.g. 20240408T200652Z, and download the pydarm_L1.ini and save it to a known location.

(2) Start critiquing:
~$ ipython
In [1]: from pydarm.darm import DARMModel

In [2]: d = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini')

# Plot a single parameter file's model:
In [3]: d.plot(filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_pydarm_H1_critique.pdf',label=['H1'])

# Compare against another, say, previous version of the model
d_prenewdarm = DARMModel('/ligo/groups/cal/H1/reports/20231027T203619Z/pydarm_H1.ini')

from pydarm.plot import critique

critique(d,d_prenewdarm,filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_vs_20231027T203619Z_pydarm_H1_critique.pdf',label=['H1 20240927T211612Z', 'H1 20231027T203619Z'])

# Compare two IFOs:
In [9]: d_H1 = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini')

In [10]: d_L1 = DARMModel('/ligo/home/jeffrey.kissel/2025-01-21/20240408T200652Z_pydarm_L1.ini')

critique(d_H1,d_L1,filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_H1_vs_20240408T200652Z_L1_critique.pdf',label=['H1 20240927T211612Z','L1 20240408T200652Z'])

# Compare one IFO's parameters, while updating one of the parameters on the fly
In [9]: d_H1 = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini')
In [10]: d_H1_moreAA = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini') #Intentionally the same
# Update the parameter you want,
In [6]: d_H1_moreAA.sensing.omc_filter_noncompensating_modules
Out[6]: [[9, 10], [9, 10]]

In [7]: d_H1_moreAA.sensing.omc_filter_noncompensating_modules = [[9,10,10],[9,10,10]]

In [8]: critique(d_H1,d_H1_moreAA,filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_H1_vs_20240927T211612Z_H1_2x16kDigitalAA_critique.pdf',label=['Nominal','1x More 16k AA'])

LVEA Zone 2A temperature rate alarm limit was relaxed from 0.001 Celsius/minut to 0.0012.  This will reduce daily alarms when the sky is clear and the sun is heating that part of the LVEA.

FAMIS 31069

Due to the chiller swap (alog82379) and PMC/RefCav alignment adjustments (alog82377), several trends show changes from this morning. Most notably is the large drop in RefCav transmission, which likely shows a need to tune up the FSS path on-table.

I've added some logic to ISC_LOCK in DRMI and PRMI to check if we've already tried PRMI, and or CHECK_MICH. Two counters are created and = 0 in each acquisition. On our second pass through PRMI or DRMI in an aquisition the POPAIR timers will be doubled and the threshholds will be halved. The changes have been svn commited.

J. Oberling, R. Short

While recovering the PSL after the chiller swap this morning (alog82379), we noticed the alignment of the PMC and RefCav looked poor according to the cameras, so we took the time to touch these up while still in the maintenance period. Starting with the PMC, I was able to slightly improve the alignment using the picomotors:

Moving on to the RefCav, once the FSS was locked I was able to improve the alignment here as well; the TPD signal increased from 620mV to 737mV. Not as much gain here as we hoped, and the RefCav Refl camera spot still looks like two vertical lobes, so the FSS path may need to be adjusted on-table.

Finally, since the output of the PMC had increased, I changed the ISS RefSignal to bring the diffracted power back down to our desired setpoint of around 4%.

All maintenance activities have completed and we are almost done with initial alignment.

[Ryan, Matthew]

Sweep done at 12:51 PSC, only things to note were two view ports (HAM2 and HAM3) had foil wrap instead of coverings. Unplugged a few scissor lifts, left one by the high bay plugged in.

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?"

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

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.