Following our work in the PSL enclosure this morning (alog from Jason soon to come), I calibrated the PSL rotation stage since the output of the new PMC had again changed slightly.

The process this time had just a couple of hiccups (steps taken listed in alog74597). For starters, the MoveRotationStage.py script had somehow had its contents deleted last week and was robo-committed to svn that way, so I needed to revert it to the previous revision. Also, I'm not sure how I haven't noticed this before, but Jason pointed out while the rotation stage was stepping through each angle, the maximum power out did not line up exactly with one of the preset angles on the stage, so the maximum power stated by the script is not accurate. I'll think about how to rework thse scripts to produce a more accurate calibration curve.

J. Kissel
WP 11969

The attached screenshot shows the MEDM screen interface for the new routing of the h1iopomc0's ADC0 signals reading out copies of the OMC DCPD A and B ADC voltage at 524 kHz (see discussion of front-end -model implementation in LHO:78956). 
From the sitemap, pull down the "OMC" menu (circled in neon green) and select a new screen link "DCPD TEST" (arrow-ed in magenta)
That opens up the black overview screen which shows the ADC input matrix and the link to the filterbanks (circled in light blue).
That link opens up the screen on the far right of screenshot which displays
    - read only versions of the primary DCPD A0 and B0 524 kHz banks.
    - read only version of the PI DOWNCONV SIG filter 524 kHz bank.
    - The new A1, B1, and A2, B2 filter banks.

You can see these screens are already populated in the configuration I want to test first. These settings are all initialized, monitored, and accepted in the SDF settings.

Maintenance completed just after noon. Ryan and Jason then ran a calibration with the PSL rotation stage and then I started an initial alignment.

We are moving onto DC readout now.

WP 11971

The following cables were disconnected at the feedthrough:

1. H1:ISC-X9-82 (EX)
2. H1:ISC-X10-82 (EY)

Cables are for the in-vacuum picomotors. Picomotors are not used. A shortening plug was installed on the each flange (all pins tied to backshell, backshell tied to chamber ground via mounting screws). Will monitor DARM, PEM ESD VMON,and FScan for improvements.

We've consistently seens PRCL coherence with DARM that is higher than MICH and SRCL, and the coupling doesn't seem to be reduced well by decoupling PRCL from SRCL and MICH (see 77416 and 77289).  Here are some plots based on old LSC injections made when OM2 was cold, on May 9th.  Using the PRCL excitation, I've made an exess power projection to DARM, SRCL and MICH.  Then using the MICH (or SRCL) excitation I've projected where the PRCL contribution to MICH (or SRCL) noise that's from PRCL should be in DARM.  Both are much lower than the PRCL projection to DARM, indicating that this PRCL projection isn't a double counting of MICH and SRCL noise, and confirming that we won't be able to reduce the PRCL to DARM noise by improving the decoupling of PRCL from SRCL and MICH. 

Camilla has taken a more recent set of these injections 78782, so I will try to run this script for those injections.  I'd expect to get a similar result.  Camilla has now taken measurements to implement a PRCL feedforward. 

These measurements and script can be found at /ligo/home/sheila.dwyer/Noise/PRCL/PRCL_projection

We cannot make a reasonable assessment of energy deposited in HAM6 when we had the pressure spikes (the spikes themselves are reported in alogs 78346, 78310 and 78323, Sheila's analysis is in alog 78432), or even during regular lock losses.

This is because all of the relevant sensors saturate badly, and the ASC-AS_C is the worst in this respect because of heavy whitening. This happens each and every time the lock is lost. This is our limitation in configuration. I made a temporary change to partly mitigate this in a hope that we might obtain useful knowledge for regular lock losses (but I'm not entirely hopeful), which will be explained later.

Anyway, look at the 1st attachment, which is the trend at around the pressure spike incident at 10W (other spikes were at 60W, so this is the mildest of all). You cannot see the pressure spike because it takes some time for the puffs of gass molecules to reach the pirani.

Important points to take:

• Marker shows when the Fast Shutter was actually fired, which is witnessed by GS13 (bottom left).
• ASC-AS_C cannot be relied on. It started saturating badly even before the FS fired (look at INMONs, 3rd from the top, left), and it kept saturating for a long time.
• OMC QPDs cannot be relied on. They started saturating at about the same time as AS_C though they seem to have stopped saturating earlier  (2nd from the bottom, left).
• AS_B and AS_C cannot be relied on. They're much better than AS_C and OMC QPDs, they started railing some milliseconds earlier than the FS, but they railed (right middle for SUM, one below that for INMONs).
  • But the beam was NOT clipped by the Fast Shutter after it closed as the power dropped to zero, we can see that after WFS stopped saturating.

This is understandable. Look at the second attachment for a very rough power budget and electronics description of all of these sensors. QPDs (AS_C  and OMC QPDs) have 1kOhm raw transimpedance, 0.4:40 whitening that is not switchable on top of two stages of 1:10 that are switchable. WFSs (AS_A and AS_B) have 0.5k transimpedance with a factor of 10 gain that is switchable, and they don't have whitening.

This happens with regular lock losses, and even  with 2W RF lock losses (third attachment), so it's hard to make a good assessment of the power deposited for anything. At the moment, we have to accept that we don't know.

We can use AS_B or AS_A data even though they're railed and make the lower bound of the power, thus energy. That's what I'll do later.

(Added later)

After TJ locked the IFO, we saw strange noise bump ffrom ~20 to ~80 or so Hz. Since nobody had any idea, and since my ASC SUM connection to the PEM rack is an analog connection from the ISC rack that also has the DCPD interface chassis, I ran to the LVEA and disconnected that.

Seems like that wasn't it (it didn't get any better right after the disconnection), but I'm leaving it disconnected for now. I'll connect it back when I can.

WP11970 h1susex 28AO32 DAC

Fil, Marc, Erik:

Fil connected the upper set of 16 DAC channels to the first 16 ADC channels and verified there were no bad channels in this block. At this point there were two bad channels; chan4 (5th chan) and chan11 (12th chan).

Later Marc and Erik powered the system down and replaced the interface card, its main ribbon cable back to the DAC and the first header plate including its ribbon to the interface card. What was not replaced was the DAC card itself and the top two header plates (Fil had shown the upper 16 channels had no issues). At this point there were no bad channels, showing the problem was most probably in the interface card.

No DAQ restart was required.

WP11969 h1iopomc0 addition of matrix and filters

Jeff, Erik, Dave:

We installed a new h1iopomc0 model on h1omc0. This added a mux matrix and filters to the model, which in turn added slow channels to the DAQ INI file. DAQ restart was required.

WP11972 HEPI HAM3

Jim, Dave:

A new h1hpiham3 model was installed. The new model wired up some ADC channels. No DAQ restart was required.

DAQ Restart

Erik, Jeff, Dave:

The DAQ was restarted soon after the new h1iopomc0 model was installed. We held off the DAQ restart until the new filters were populated to verify the IOP did not run out of processing time, which it didn't. It went from 9uS to 12uS.

The DAQ restart had several issues:

both GDS needed a second restart for channel configuration

FW1 spontaneously restarted itself after running for 9.5 minutes.

WP11965 DTS login machine OS upgrade

Erik:

Erik upgraded x1dtslogin. When it was back in operation the DTS environment channels were restored to CDS by restarting dts_tunnel.service and dts_env.service on cdsioc0.

All the Dust Monitors in use passed the zero count and flow rate test for this cycle. Closes FAMIS27659, this was last done by me last December alog74610.

I ran the zero count and flow rate test for all the dust monitors in use around the site. Passing is having zero counts of 0.3 and 0.5 micron particles and a flow rate of 2.8 L/min.

We also have 4 working spares, 3 pumpless & 1 pumped, 3 (the 3 PL) of which have been calibrated by METONE earlier this year.

CS:

• PCAL lab: Passed zero count test and flow rate.
• Optics lab: Passed zero count on the first test and had a good flow rate.
• PSL: I didn't check these as they're done as TOO by RyanS during PSL incursions.
• Diode room: Passed zero count on the first test and flow rate test.
• VPW: Passed zero count on the first test and flow rate test.
• LVEA
  • 5: Appears to have been frozen/off since 06/03/24, it was turned off when I found it. This is a pumped DM, it passed the zero count and flow test. I left it off as its pumped which is noisy.
  • 6: Had 1 0.3 particle on the first test and zero on the second test which is a pass, and the flow was 3.0 which I adjusted down to 2.8.
  • 10: 1 0.3 particle on the first test and zero on the second test which is a pass, and the flow was good.
• FCES: Passed zero count on the first test, good flow. Another pumped DM.

ARMs:

EX: Passed zero count on the first test and flow rate test.

EY: 2 0.3 particle counts on the first test, zero on the second which is a pass, and the flow rate was good.

The LVEA as been swept, no items to note.

FAMIS tasks 24877 and 24853, WP 11966

Procedure checklist for both stations completed.  No issues were identified at this time.

MX: Scroll pump hours: 219.6

       Turbo pump hours: 130

       Crash bearings: 100%

EX: Scroll pump hours: 7147.6

       Turbo pump hours: 1099

       Crash bearings: 100%

Jennie, Jenne, Sheila, Keita

While the PSL team were preparing for a PSL in cursion, I started moving MC3 based on our plan to re-align onto the ISS array and IM4 TRANS QPD after the PMC swap last week.

We tried going up in yaw, saw some increase in power on IM4 trans QPD but then the ISS second loop QPD started to become further from the centre position as did the IM4_TRANS QPD (this is well centred enough that we could see the power drop whereas the ISS QPD started quite far off centre so that the nsum is quite close to zero).

We went back to the maximum value then tried IM3 alignment is both DOFs but this did not improve things in both QPDs so we tried MC3 pitch. Sheila then noticed that we were mazking the IMC relflected spot some horrible higher order mode so we decided to stop and think.

MC1 and MC3 changed in common yaw due to the WFS as we changed the uncorntolled differential DOF (MC1 - MC3), which we did not expect, to recover our alignment we would need MC1 and MC3 to change differentially as they did after the PMC swap, in this image.

The ndscope channels I used for this alignment walking session are attached with cusors before we changed anything and after we recovered the IMC alignment to pre-maintenance.

In conclusion we have reverted the IMC alignment back to before our changes as we think some action before the in-vacuum mirrors is needed.

Plan: To revert periscope PZT and MC1 back to their positions before the PMC swap and get Jason/Ryan to move steering mirrors in the PCAL enclosure to recover the prompt reflection from the IMC as witnessed by the MC WFS behind MC1. Then we can re-align the IMC.

J. Kissel, D. Barker, E. von Reis
WP 11969

The h1iopomc0 model changes I prepped this morning LHO:78956 have been installed.

Further, one at at time, I've installed copies of the primary OMC DCPD A0 and B0 filter bank filters into the A1, A2, and B1, B2 filters in order to test the consumption of computational turn around time (see preliminary discussions in LHO:78958). Finally, I've added a reasonably high-order high-pass filter into the A1 and B1 banks to test whether we can add even *more* filters enough to accomplish the tests discussed in LHO:78956.

Attached is an annotated time series of the CPU meter channel (H1:FEC-179_CPU_METER) as each of these things happened.

In short -- even with new the filters "fully loaded," the model computational turn around time runs at 12 [usec], occasionally popping up to 13 [usec] -- under the ideal limit of 15.3 [usec].
In addition, we don't see any IPC timing errors in either the OMC user model or the end station PI models that are receiving IPC from the h1iopomc0 model.

So, we'll leave this diagnostic infrastructure in place for a few weeks, until we decide we don't need it anymore.

Lockloss @ 07/09 05:52 UTC

Bruco ran for last night's 159MPc range (instructions from Elenna), using command below. Results here.

python -m bruco --ifo=H1 --channel=GDS-CALIB_STRAIN_CLEAN --gpsb=1404222629 --length=1000 --outfs=4096 --fres=0.1 --dir=/home/camilla.compton/public_html/brucos/GDS_CLEAN_1404222629 --top=100 --webtop=20 --plot=html --nproc=20 --xlim=7:2000 --excluded=/home/elenna.capote/bruco-excluded/lho_DARM_excluded.txt

Can see:

• CHARD_P is bad 10-30Hz and CHARD_Y is very bad < 25Hz
• PRCL bad coherence 10-20Hz 
• SRCL looks good and MICH only has a little coherence 10-20Hz 
• OMC ASC signals dominate <16Hz, maybe this is expected....  
• HAM1 signals are high 10-30Hz, from PRCL coupling?

DriptaB, FranciscoL

After one week of having the inner beam up on the Rx sensor (alog 78807), on July 2, we moved the beam from up to center.

The last page of EndStationLog.pdf lists the voltage values after each significant step of procedure T2400163. The steps represent writing down a voltage value after a particular change to the beam position. Some highlights from the recorded values:

• ("moved beam") Finalized beam movement of inner beam. See InnerBeamAfter.jpg. Target still on Rx PS. Fine adjustments to yaw had to be done to maximize the signal.
• ("Target off") Recorded the voltage from the Rx sensor with the inner beam only and with the target removed from Rx PS. Readout of FLUKE voltmeter of 1.684V is higher by 6 HOPs to previous position (1.683V).
• ("Both beams") The measurement was recorded after removing beam block on outer beam and removing the target. See BothBeamsAfter.jpg. The measurement of 3.382V is *equal* to the initial measurement (3.382V).

The 'Initial' measurement is *equal* to the last voltage measurement from the previous movement, done on June 25 (alog 78807). The initial and final voltage measurement during today procedure did not change.