"It is a truth universally acknowledged, that a single man in possession of a good fortune, must be in want of a wife"

- Jane Austen, opening line of Pride and Prejudice

But unfortunately for both us and them, sometimes those men are winged termites in the Optics Lab.

As Elenna and I were cleaning up our work in the back optics table this afternoon, we noticed a few winged termites, and ended up finding maybe almost 10 in total walking around on the floor in the back area of the optics lab near the wall mounted cabinets between the two cleanrooms. We got rid of them but couldn't find where they had come from. I'm wondering if they're maybe coming from an opening under one of those cabinets? Last year this happened but those came out from under the flow benches along the wall - not sure if this is part of that same colony that survived or a different colony.

J. Kissel, M. Pirello

While in SUS-R2 and thinking SPI, and looking at the proposed rack layout from G2401479, and accounting for all the SUS (BBSS, LO1, LO2) that's incoming for O5 -- I found that SPI can have a bit more space if we just move the SUS-PR3 optical lever whitening chassis up 5 U-heights from "32" to "27." I put the u-height in quotes because this is an old style rack with the u-heights labeled from top down, rather than the bottom up per industry convention. I would have and could have gone higher, but the 27 slot already had mounting clips in it, so I went there. We can go as high as "25" if need be in the future.

Pics of before vs. after are attached.

We previously reported that the wiring to ground on the OMCA DCPD dsub9 cables seemed odd, see 89562. There appears to be two conflicting diagrams of the pin wiring, D2200276 and D2300119. Neither of these diagrams follow the correct pin naming practice either.

Today, Oli and I checked the ground connectivity for the OMCB DCPD dsub9. The case ground is wired to what is labeled pins 6 and 9, according to both of the diagrams above and also proper convention. However, this is different from OMCA, where the case ground is wired to pins 2 and 5 (following the incorrect naming of the diagrams above), or pins 1 and 4 (following correct naming conventions).

So either way, we have two different wiring set ups for OMCA and OMCB. We have only checked the ground pins so far, and it seems like we should confirm the cathode and anode wiring as well.

To summarize:

- we have two different diagrams for pin wiring

- OMCA and OMCB are wired differently from each other

- the diagrams are not following proper pin naming convention which is making this more confusing

J. Kissel, R. Short, J. Oberling

This is the first installment of aLOGs documenting the setup of a new stand-alone 1064 nm NPRO laser system whose current "end game" intent is to provide ~100 [mW] of fiber-coupled p-pol light to the SPI laser prep chassis.

Step 1: Gathering materials, find what optics / mounts we had vs. what would be need, and physically layout the plan.

Jason lets Ryan and I know that there are three NPROs in the optics lab, two of which are PSL spares that cannot be used. 
The remaining laser is S/N 1661, the laser used in the PSL during O3 which is *functional* but was briefly installed during O4 circa Fall/Winter 2024 then removed from use in the PSL because of reported glitching / incompatibility with the frequency stabilization servo (FSS) issues -- see the bottom of LHO:81391 for a nice summary, and LHO:81409 for record of its removal.

Inspired by the setup at Stanford Sina shared with us, we're looking to build up the following system to accomplish the goal:
    - NPRO (presumed to be elliptically polarized with Is / Ip = 5:1)
    - QWP (to linearize the polarization)
    - HWP1 (to rotate the polarization into horizontal)
    - FI (accepts horizontal linear polarization, to ensure back-reflections from down-stream components don't seed the NPRO causing glitches/mode hopes/frequency noise)
    - HWP2 (to rotate the FI output polarization into the desired amount of vertical polarization -- aka the desired amount p-polarization)
    - PBS (to filter out and dump the unneeded horizontal / s-pol light, and transmit the desired power of p-pol)
    - SM1 (one of two steering mirrors to align the beam into the fiber collimator)
    - L1 (the single-lens mode-matching solution to convert the NPRO beam into what the fiber collimator needs)
    - SM2 (two of two steering mirrors for alignment into the fiber collimator)
    - 50:50 PWR BS (45 [deg] AOI, optimized for p-pol; to provide a pick-off port for live power measurement)
    - Fiber Collimator

Ryan started with a 24" by 12" breadboard that was lying around in the optics lab. He build up a makeshift stand from three posts and dogs in the lower left corner such that the S/N 1661 NPRO projects the beam at 4" height. The 0.5" thick breadboard has a 1 inch hole pattern offset by 0.5" from the edges. I'll refer to this grid as having axes "m" and "n" where the m-axis are the "row" holes running from 0 to 23, and the "column" n-axis holes run from 0 to 11. I chose (m,n) breadboard coordinates so as to not confuse them with traditional beam profile coordinates of (z [propagation distance], x (transverse horizontal), y (transverse vertical)). 

Thus, the NPRO being in the "lower left" means it projects the beam along the m = 3 row, and the front face of the NPRO is sitting at n = 8. We'll call this beam position z = 0.

We then proceeded to gather as much as we could of optical components from the optics lab drawers, and ended up with this pictured preliminary version of the setup.

Step 2. Power up the NPRO.
Here's were we ran into our first snag. Normally, NPROs are paired/tuned with specific controller boxes. However, when Ryan turned on the S/N 1661 laser with the S/N 1661 control box, the crystal temperature readback reported the temperature was quickly, linearly rising well beyond the desired temperature of 24.7 [deg C]. At ~42 [deg C], (but still below the internal automatic watchdog threshold of 50 [deg C]), Ryan knew something was wrong and turned it all off. He repeated the turn on just in case, and it did the same.

After conversing with Jason, we figure it's good enough to run with one of the other controllers for now, and in the mean time figure out how what's wrong and repair the S/N 1661 controller.

So, we're running with the S/N 7974, and things seem fine. 
    Laser Diode Temp Setup:
        Diode 1 33.7 [deg C]
        Diode 2: 33.1 [deg C]
        Laser diode injection current readback 2.08 [A] (for both diodes)
    Crystal Temp setting is 24.7 [deg C]

We measured the output power*** with no optical elements at all as 1.820 +/- 0.005 W (not noisey, but a slow drift around).
Good enough! Onward and upward!

*** Power measured by ThorLabs power meter
	Model S302C
	SN 111149
	Sensing factor of 316.25 [mV/W]
	(last calibrated Feb 3 2012).

Robert, Anamaria

Following up on tests done at L1, we wanted to do the same tests at H1 and compare. We see similar large shelves when we shake RX and RY at 0.2 Hz. This mechanism is not directly limiting DARM since we have to inject a lot to see it, but it allows us to estimate how much light is around the BS area available for scattering into DARM. 

The stranger difference between the sites is that the ratio of the first shelf to the second shelf for H1 is much smaller, circa 10, so implies a second reflective path that's still fairly in line (eg like the R0 ESD reflections).

I drove 100 cts into the the corresponding ISO filter bank.

RX injection start: Oct 2 17:41:39 utc
duration: 8 min

RY injection start: Oct 2 17:58:20 utc
duration: 2 min (lost lock shortly after so weren't able to get more data)

dtts can be found in /ligo/home/anamaria.effler/ddt/ with suggestive names. I had also copied over the equivalent L1 dtts in the same directory.

Robert will folow up with some more tests.

WP12479 Fil, Dave:

Fil has fixed the missing slow controls Beckhoff terminals at EX which were lost after the site power outage Sun 6th April 2025 18:05 PDT.

Attached 18 day trend of the baffle PD signals show the loss and restoration of signal.

The CDS overview had been expecting only 125 of 127 terminals, and was displaying the degraded DEV4 in dark green, turning to red now all 127 terminals are back. I have removed this exception, DEV4 is now nominal green when new overviews are opened.

Tagging AOS.

I made a couple of ancilliary investigations while I was in-chamber helping adjust CPY. First, I shined a flashlight through the ITMY elliptical baffle towards the BS. Figure 1 shows that this produced a 45 degree annular beam, similar to the one observed during lock that I noted here ( 83050 ) , consistent with the hypothesis that it is a reflection from the BS cage (see linked alog).

Second, our entry through BSC8 also reminded me that LHO has some unique potential scattering sites that LLO does not have.  Figure 2 shows that several of the blanked off nozzles in BSC8 act as corner retroreflectors visible to the beam spot on ITMY, and there is a reflection from the chamber, just below the beam.  A look at my compilation of beam spot photos from several years ago ( 41142-Figure3 ) also shows these issues at ITMX (second page of Fig. 2). We should probably put in nozzle baffles next time we are in-chamber near BSC8 and 7.

I recently reported on multiple potential stray light issues in the vertex area, including a 45 degree conical annular beam from the beamsplitter, and a reflection of the halo of the beam passing through the ITMX elliptical baffle that is roughly directed at ITMY (83050). In a first attempt to study potential scattered light noise problems from these beams, before the break I injected 0.2 Hz X and Y motion onto the BS HEPI, with motion amplitudes of about 1e-6 m at stages, 0 and 2 (see figure).  The figure demonstrates with spectrograms and spectra (second page), that there is a slight increase in DARM noise for both X and Y injections,  mainly below 60 Hz. I turned the injections on and off multiple times because the noise is pretty subtle. I think we should further study these potential scattering issues after the break.

J. Kissel
ECR E1700228
WP 12370

I've executed the PR3 Optical Lever QPD AA Cable move from SUS-C4 U11 D9 Port 7 to SUS-C4 U32 D9 Port 8 described in more detail a few days ago (LHO:83168) in order to make room for the incoming PM1 (per ).

See LHO:83168 for "before" pictures; I attach "after" pictures here:
    - 2025-03-11_SUS-C4_PR3OplevMove_U11_AAChassis_After_1 shows that D9 port 7 and 8 of U11 AA chassis are now vacant, 
    - 2025-03-11_SUS-C4_PR3OplevMove_U11_AAChassis_After_2.jpg shows that this AA chassis is serial number S1202339.
    - 2025-03-11_SUS-C4_PR3OplevMove_U32_AAChassis_After_1.jpg shows the big-picture scene around U32 AA chassis,
    - 2025-03-11_SUS-C4_PR3OplevMove_U32_AAChassis_After_2.jpg shows the cable, "H1:OP LEV_PR3_AA" or "H1:SUS-HAM2_88" specifically, connected into to U32 AA chassis D9 port 8, the last "IN29-31," spigot of this AA chassis that supports sush2a's ADC1.
    -  2025-03-11_SUS-C4_PR3OplevMove_U32_AAChassis_After_3.jpg shows that this U32 AA chassis is serial number S1202340

Jeff, Oli

ECR E1700228

More preparation to make way for PM1 - Jeff and I went into the h1sushtts simulink model and added in PM1 and its necessary connections(h1sushtts before). It was basically a copy of the RM1 and RM2 control blocks, with the input ADC channels taking 24 - 27, and channels 8 - 11 on the DAC (h1sushtts after - PM1+output).

We also copied the RMs PCIe inputs, but the channels coming in from the TTL4C on HAM1 are going to be removed for the RMs when the ISI is installed on HAM1 and replaced with the new ISI channels, and so PM1 will never have the HAM1_TTL4C channels. Since we want to be able to compile and test the model before then, I have put in a constant 0 in place of the TTL4C channels for PM1 (h1sushtts after - IPC INP). Once we have the new ISI channels, we can add these connections in using those channels, as well as update the channels for the RMs.

Daniel just added in the new ASC channels for PM1 (83195), so I was able to successfully compile h1sushtts. It has not yet been installed.

The model file can be found in /opt/rtcds/userapps/release/sus/h1/models/, and the changes to h1sushtts.mdl have been committed to the svn as revision 30907.

Jeff, Oli

WP 12370

ECR E1700228

In a continuation of preparing for the addition of PM1 (83168), Jeff and I have made the necessary model changes for the PR3 OpLev. As outlined in 83168, the stuff that needed to be changed in the model (to match with the physical changes) was to move the PR3 OpLev channels. They were originally located in the top level of h1susim.mdl and sent via IPC to PR3, but we moved them over to the h1suspr3.mdl model. This means that the outgoing IPC connection from h1susim going into h1suspr3 has been removed(h1susim before, h1susim after), and the PR3 oplev channels have been directly connected from ADC1(h1suspr3 before, h1suspr3 after).

Both models were compiled successfully but  have not yet been installed.

Model files can be found in /opt/rtcds/userapps/release/sus/h1/models/, and changes to h1susim.mdl and h1suspr3.mdl have been committed to the svn as revision 30905.

I have recently reported that the “mystery” beam on the spool piece wall near HAM3 was coming from the direction of ITMX (82252). To further this investigation, I started photographing the area around the ITMs and BS as best I coluld through our viewports (there is not a good view towards HAM3).  I found several unexpected distributions of light in the vertex:

1. 20 degree conical annular beams from ITMs

Both ITMX/CPX (Figure 1) and ITMY/CPY (Figure 3) cast an expanding annular “beam” towards the BS with a cone half angle of roughly 20 degrees from the main beam. My best guess is that it is produced by arm cavity light hitting the bevel of the ITMs (see cartoon in Figure 1). A good test of this would be to install the new test mass cage baffles at one or more of the ITMs at LLO (presuming Anamaria finds this beam at LLO) this upcoming break. The baffle should hide the bevel and eliminate the ring of light.

2. 45 degree conical annular beams from BS

The BS appears to cast an expanding annular “beam” with a cone half angle of 45 degrees, centered around the -X, -Y direction (Figure 2), and likely another annular beam, also with a half angle of 45 degrees, centered around  the  -X, +Y direction (evidence in Figure 3). I tried to find a geometry where the bevels were also the source of these beams but didn’t. My best guess is that the annular cone is produced by reflections of light from PR3 and the ITMs off of the inner surface of the circular cage around the BS, or the inside surface of the circular barrel of the BS itself (see drawings on third page of Figure 2). 

3. Reflection of BS in ITM elliptical baffles likely visible at ITMY and HAM3

The BS beam spot is reflected towards ITMY by the slanted piece of the ITMX elliptical baffle (Figure 3). While the actual beam is not reflected towards ITMY (it isn’t clipped), the baffle reflects light towards ITMY that is scattered out of the main beam by only a few degrees.

This is a sister alog to LLO:72613. After discussion with the calibration group, Joe and I have proposed and pushed a small but important fix to the CAL_LINE_MONITOR_MASTER/COHERENCE block. When the IFOs are down, the coherence for various calibration and monitoring line transfer functions is 0 (this is good). However, the TF uncertainty, which is also produced by the coherence block, was found to be railing at 0 too. How can the uncertainty be 0 if there is no coherence?! It turns out that a coherence of 0 was causing a divide by 0 that, on the front end, presents as ... you guessed it, 0. The new h1calcs models (updated at LLO then synchronized by me to LHO) fix that. 

Now the coherence signal entering the uncertainty-calculation logic will be kept within 1e-6 to 2. We allowed for a coh value above 2 in order to avoid inadvertently 'hiding' egregious errors in the coherence calculation by forcing it to stay below 1. Thinking about this further now that I'm writing this...that wasn't necessary as the coherence channel itself isn't affected by our new changes. oh well.

I've attached an annotated screenshot of Joe's screenshot in LLO:72613 to show the new component we've installed. 

The h1calcs updates should be put in place during tomorrow's maintenance period.

Alena Anayeva has been working on some zeemax modeling to help us understand what happened when our output arm seems to have changed on April 22/23rd. 

She has been using shifts in alignment based on slider numbers as reported in 77388, but the shifts that this is giving her are too large. 

This is a quick look at the slider calibrations.  There is a discrepancy for SR2, the slider calibration agrees with the M2+M3 osems, M1 osems are reporting a 62% smaller shift. For SR3, the sliders and osems agree to within 10%.

After the large shift we have been falling off the SR3 optical lever, so that is not a useful comparison.

Robert, Anamaria

Yesterday we opened the viewports of the oplevs for both ITMX and ITMY to find the alignment of the CP's.
The procedure relies on the fact that the optics are not coated for red so we can see all four surfaces. The separation between the beams at this distance (~34m) is about 10cm due to the wedges (in the table below from the galaxy page). The test mass has a vertical wedge, thick down, so the AR beam will show up directly below. The CP is supposed to be perfectly parallel to the back surface so the closest surface of the CP (CP1) would land essentially right on top of the ITM AR beam. Then the CP has a similar size wedge, but horizontal, so the second CP surface would hit at the same level as CP1 and ITM AR but to the left or right, depending which ITM. 

The first plot attached shows the nominal view of these beams as seen at the oplev viewport on the white page. The yellow pages were attached to the lexand covering the viewport and the beams were marked. The full view of all the beams no longer fits through the viewport due to the addition of nozzle baffles so we had to walk the oplev sender to find all the beams. For the ITMX we lucked out and the ITM AR beam was visible at the top gap of the baffle at the same time as the second AR reflection and the CP beam were visible in the aperture. As such we are able to scale the misalignments to the wedge value. We verified the CP beams by moving the CPs, and we scanned to find the second CP surface (CP2) horizontally at about the right distance from CP1. 

By down I mean they are further pitched down towards the arm.

One would think that we have +/- 440 urad range in pitch on the R0, but it seems its range is much less than advertised. Even stranger, this was also found to be the case at L1, on both ITM R0. When we moved CPY, with respect to this calibration it only moves ~230 urad. So we cannot make it back to the nominal position of overlapping the ITM AR beam. For yaw we did a smaller step so more error on it, but it's about 60% of slider value. More on this later.

(CPY is the one that Robert found to modulate the noise from the MC tube baffle.) Speaking of the L1 experience, we even had to vent back in 2016 to fix one of these CP misalignments, which was too close to HR actually. The interesting thing to me, looking back, is that L1 still has a similar misalignment for CPX to the H1 CPY and we don't see as high noise coupling at the IMC tube. 

CPX is very misaligned by comparison, but not linked to the MC tube scatter. Alena has agreed to help us track where these ghost beams land at P/SR3 and the scraper baffles, now that we know their exact orientation. 

Robert, Jason, Anamaria

Today we used the oplev to determine the CP alignment for both ITMX and ITMY. We had to move the sender around to find all the beams so here I mark the shift in the beam location in case someone later wants to look at drifts. The ITMs were realigned slightly after our test so it's not good to 1urad but the oplevs drift around more than that anyway. I also had to choose times after lockloss and before relocking, to not have ASC interfere.

Since people don't open the receiver box or the sender box very often we note:  
a) The beams on the oplevs are as large as the QPD which is not great, but depends what they're used for.
b) We found the ITMX oplev beam to be clipping on the nozzle baffle. Jason helped us shift the QPD and then we realigned to this new, more central location.
c) Replacing the sender cover is very difficult without causing a shift in the oplev beam, though we were quite careful to not touch the telescope while doing that. This is why we were not able to center them better.
d) I suppose the last few urad should be done with the QPD stages, but one has to be careful to check from time to time that it doesn't walk out of the aperture over time (which is smaller since the installation of nozzle baffles).

The calibration has been updated at LHO using Cal report 20240330T211519Z. 
The TDCF EPICS channel changes and the CALCS filter changes are attached. 

In O4b, the Calibration group is using a slightly different scheme for keeping track of cal reports, the front end pipeline settings, the GDS pipeline, and the hourly online uncertainty budgets. The biggest change is that each cal report is now also a git repository with its own history. This will allow for better tracking in situations for which it is deemed necessary to regenerate / reprocess calibration measurements. 

Additionally, there are now two additional channels available on the front end: H1:CAL-CALIB_REPORT_HASH_INT and H1:CAL-CALIB_REPORT_ID_INT. These new channels are populated by the pyDARM tools when someone in the control room runs 'pydarm export --push'. 

New Channels and their purpose:
H1:CAL-CALIB_REPORT_HASH_INT: numeric representation of the git commit hash for the report that was used to generate the current calibration pipeline 
H1:CAL-CALIB_REPORT_ID_INT: numeric representation of the report id (e.g. 20240330T211519Z) the current calibration pipeline is configured with.


Current channel values:

caget H1:CAL-CALIB_REPORT_HASH_INT H1:CAL-CALIB_REPORT_ID_INT


H1:CAL-CALIB_REPORT_HASH_INT   4.14858e+07
H1:CAL-CALIB_REPORT_ID_INT     1.39587e+09


End-to-end procedure for updating the Calibration pipeline:
0. Take new calibration measurements following the instructions in OpsWiki/TakingCalibrationMeasurements.

1. make sure that the current pyDARM deployment version is up-to-date

    1.a) run pydarm -v and check that the returned version (e.g. 20240405.1) matches the latest 'production release' tag listed at https://git.ligo.org/Calibration/pydarm/-/tags.
    1.b) if the tags do not match, have a member of the Calibration group deploy the latest pyDARM tools to the site and the ldas cluster. They should follow the instructions laid out here.

2. generate a new cal report 
    2.a) run pydarm report (if this measurement set should be considered an epoch in sensing or actuation then apply the appropriate command line options as listed in the pyDARM help menu (pydarm  report -h)). Report generation will now populate the report directory at /ligo/groups/cal/H1/reports/<report id>/ with various 'export' products. These include dtt calibration files, inverse sensing foton exports, and TDCF EPICS records that would be updated if this report were to be exported to the front end.

    Here is a quick list of the some of the products that get stored at this step:
    pcal_calib_dtt.txt: Pcal calibration into meters of displacement
    deltal_external_calib.txt: calibration of DELTAL_EXTERNAL into strain
    pydarm_version: the pyDARM tag indicating the version of pyDARM used to generate the report
    export_epics_records.txt: list of each EPICS channel name and the value it would get set to when the report is exported to the front end
    gstlal_compute_strain_C00_filters_H1.npz: a set of GDS filters and meta data that is sent to the GDS pipeline when the report is exported.

3. inspect the plots in the cal report to make sure they're reasonable. Typically this done by a member of the calibration group that is well-acquainted with the IFO and the calibration pipeline.
    3.a) if the cal report is valid, set the 'valid' tag in the cal report: touch /ligo/groups/cal/H1/reports/<report id>/tags/valid.
    3.b) if the cal report was marked valid in 3.a), then 'commit' the report now that its contents have been changed: pydarm commit <report id>. If you have not done this before, you may see a message from git complaining about dubious ownership. If that happens, follow the instructions in the message and try committing again. If you continue to have trouble, reach out to me, Jamie Rollins, or another member of the Calibration group that is knowledgeable about the new infrastructure.

4. if the report is 'valid', export the new calibration to the front end.
    4.a) to first compare the cal report against the currently installed calibration pipeline, run pydarm status
    4.b) to have pyDARM list all of the changes it would make if exported, run pydarm export
    4.c) once you are certain that you want to update the calibration, run pydarm export --push. This will write to all of the EPICS channels listed in export_epics_records.txt and perform various CAL-CS frontend foton filter changes. 
    4.d) reload the CAL-CS front end coefficients via the MEDM screen system to make sure the new changes are loaded into place.
    4.e) add an 'export' tag to the current report (touch /ligo/groups/cal/H1/reports/<report id>/tags/exported) and commit it again (pydarm commit <report id>).

5. upload the newly exported report to the ldas cluster.
    5.a) run pydarm upload <report id>
    5.b) wait about 1-2 minutes after the upload to allow time for the systemd timers on the ldas cluster to recognize that the new report exists. You can confirm that the latest report is recognized by the ldas cluster by verifying that https://ldas-jobs.ligo-wa.caltech.edu/~cal/archive/H1/reports/latest/ points to the correct report.

6. restart the GDS pipeline
    6.a) run pydarm gds restart to begin the process of restarting the GDS pipeline. This will show prompts from the DMT machines (DMT1 and DMT2) asking you to confirm that the hash for the GDS pipeline package (gstlal_compute_strain_C00_filters_H1.npz). The prompts will contain the following line:

        b1c9f6cd1ba3c202a971c6b56c7a1774afb1931625a7344e9a24e6795f3837d7  gstlal_compute_strain_C00_filters_H1.npz

        To confirm that the hash above is correct, run sha256sum /ligo/groups/cal/H1/reports/<report id>/gstlal_compute_strain_C00_filters_H1.npz and verify that the two hashes are identical. If they are the same then type 'yes' and continue with the GDS restart process. After performing this process for the second DMT machine, pyDARM will continue with the pipeline restart. The GDS pipeline currently takes about 12 minutes to fully reboot and begin producing data again. During this time, no GDS calibration data will be receivable. 

    6.b) If the two hashes are not the same and all of the above checks were done, then something is likely wrong with the pyDARM+GDS pipeline system and you cannot continue with the calibration push. Take the following steps to reset the calibration to its former state: 

        1. open the CAL-CS SDF table and revert all of the EPICS channel pushes listed in export_epics_records.txt.
        2. reset the foton filters by reverting to the last installed h1calcs filter before you exported the calibration report.
        3. remove the exported tag from the new report (rm /ligo/groups/cal/H1/reports/<report id>/tags/exported), commit it (pydarm commit <report id>), and re-upload it to the ldas cluster (pydarm upload <report id>).


Summary of pyDARM commands (for use in the control room):
pydarm report [<args ...> <report id>]: generate a calibration report based on the measurement set at <report id>. See output of pydarm report -h for additional customization.
pydarm status [<args ...> <report id>]: compare current calibration pipeline against what the pipeline would be if report <report id> were exported to the front end
pydarm commit [<args ...> <report id>]: make a new commit in the report <report id> git repository. this creates a new hash and should be done any time the report's contents are changed.
pydarm upload <report id>: upload/sync the report <report id> with the ldas cluster
pydarm gds restart: initiate a GDS pipeline restart
pydarm ls -r: list all reports

Gabriele, Louis

We've successfully run a full set of calibration swept-sine measurements in the new DARM offloading (LHO:76315). In December, I tried running simulines in the new DARM state without success. I reduced all injection amplitudes by 50% but kept knocking the IFO out of lock (LHO:74883). After those repeated failures, I realized that the right thing to do was to scale the swept-sine amplitudes by the changes that we made to the filters in the actuation path. I prepared four sets of simulines injections last year that we finally got to try this evening. The simulines configurations that I prepared live at /ligo/groups/cal/src/simulines/simulines/newDARM_20231221. In that directory are 1.) simulines injections scaled by the exact changes we made to the locking filters, 2.-4.) reductions by 10,100, and 1000 of the rescaled injections that I made out of an abundance of caution.

The measurements we took this evening are: 

2024-03-15 01:44:02,574 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20240315T012231Z.hdf5
2024-03-15 01:44:02,582 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20240315T012231Z.hdf5
2024-03-15 01:44:02,591 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20240315T012231Z.hdf5
2024-03-15 01:44:02,599 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20240315T012231Z.hdf5
2024-03-15 01:44:02,605 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20240315T012231Z.hdf5


We did not get to take a broadband PCALY2DARM measurement as we usually do as part of the normal measurement suite. Next steps are to update the pyDARM parameter file to reflect the current state of the IFO, process these new measurements, then use them to update the GDS pipeline and confirm that is working well. More on that progress in a comment.


Relevant Logs:
- success in transitioning to the new DARM offloading scheme in March 2024: LHO:76315
- unable to transition into the new offloading in January 2024, (we still don't have a good explanation for this): LHO:75308
- cal-cs updated for the new darm state: LHO:76392
- weird noise in cal-cs last time we tried updating the front end calibration for this state (still no explanation): LHO:75432
- previous problems calibrating this state in December: LHO:74977
- simulines lockloss in new darm state in December: LHO:74887

Cabling on the HAM5 D3 flange was redressed. Cables routed behind the cross beam. This required cables for the HAM5 DCPD and the OFI TEC/THERMISTORS to be disconnected. D. Sigg disabled the servo for the OFI TEC. Servo enabled after cable work was completed.