[Yuta, Anchal]

We investigated why WFS loop wasn't working. It seemed like WFS1 PIT error signal has a huge offset which would push the loop to misalign all optics' PIT. So we did the following steps:

• Cover the WFS with Aluminium foils. Run Sitemap>IOO>C1_IOO_WFS_MASTER>!Actions>Correct WFS DC offsets.
• Then center the WFS beams on the QPDS while looking at C1:IOO-WFS1/2_PIT/YAW_DC channels.
• Then Switch off WFS loop, Switch off Autolocker, toggler the PSL Shutter so that IMC unlocks and does not catch lock back, and tehn run Sitemap>IOO>C1_IOO_WFS_MASTER>!Actions>Correct WFS RF offsets.
• The above script found significant changes required in WFS1 RF offsets. After this, we opened the shutter and WFS loops were working fine.

As I went to correct the ITMX Oplev mirrors, I found that both mirrors were placed in very different positions than the design position. Part of the reason I think was to preserve outside oplev path, and party because a counterweight was in ITMXOL1 position. I had to do following steps to correct this:

• I noted down level meter readings of the table before making any changes.
• I removed the counter weight from near the center of the table.
• I placed the Oplev mirrors in the nominal positions.
• I placed the counter weight near previous position.
• I moved a edge hanging counter weight to get back the level meter to its previous state coarsely.
• Then I used dataviewer to find the previous OSEM PD monitor values and changed ITMX PIT and YAW to come closer to those PD values. And voila, I regained the flashing on Xarm. I nudged the ITMX pit and yaw bit more to maximize it.
• I then went back to aligning the Oplevs properly.
• Then I adjusted the POP mirrors to get the beam back through center of window. This was very tricky and took a lot of time.
• Now the beam is going through near center and the oplev beams are far away enough from POP_SM5.
• On the outside table, I noted the POP beam and the oplev beam. I corrected the pit of the returning beam to get the oplev beam at nominal height on outside table.

ITMX Sat Amp is flaky

[Anchal, Paco]

During the above work, i must have kicked the cable between the vacuum flange and the satellite amplifier box for ITMX. This disconnected all the OSEMs and Coils. We tried several things to debug this and finally found that nudging the connections on Sat Amp box brought the OSEMs and coils back online. Note that the connector was not partially out or in a state that obviously showed disconnection of the pins. I'm glad we are putting in new electronics soon for the vertex optics as well.

Next steps:

• I showed Tega the returning oplev beam and the POP beam coming out of the ITMX chamber.
• The Oplev beam paths need to be adjusted.
  • The ongoing beam steering mirror is blocking the returning beam, so the ongoing path needs to be changed.
  • First setup two irises to save ingoing path.
  • Then make space for the returning beam by changing the steering mirror positions.
  • Then recover the ingoing path to the center of irises.
  • Steer the returning beam to the QPD.
  • Then maximize the flashing on XARM and center the oplev to save this position.
• POP beam needs to be directed to previous setup on far side of table.
  • The POP beam is coming out at the rising angle.
  • This is good for us if we do bit unconventional stuff and transfer the beam to other side of table at an elevated height. Given how close all the beams are coming out of the viewport, I think this is the best solution in terms of saving time.
  • Get the beam down to the old setup which was camera and photodiodes all aligned.

I successfully steered out the two output beams from BHD BS to ITMY table today. This required significant changes on the table, but I was able to bring back the table to balance coarsely and then recover YARM flashing with fine tuning of ITMY.

• The counterweights were kept at the North end of the table which was in way of one of the output beams of BHD.
• So I saved the level meter positions in my head and removed those counterweights.
• I also needed to remove the cable post for ITMY and SRM that was in the center of the table.
• I installed a new cable post which is just for SRM and is behind AS2. ITMY's cable post is next to it on the other edge of the table. This is to ensure that BHD board can come in later without disturbing existing layout.
• I got 3 Y1-45P and 1 Y1-0 mirror. The Y1-0 mirror was not installed on a mount, so I removed an older optic which was unlabeled and put this on it's mount.
• Note that I noticed that some light (significant enough to be visible on my card) is leaking out of the 45P mirrors. We need to make sure we aren't loosing too much power due to this.
• Both beams are steered through the center of the window, they are separating outside and not clipping on any of the existing optics outside. (See attachment 1, the red beam in the center is the ITMY oplev input beam and the two IR beams are the outputs from BHD BS).
• Also note that I didn't find any LO beam while doing this work. I only used AS beam to align the path.
• I centered the ITMY oplev at the end.

Next steps:

• LO path needs to be tuned up and cleared off again. We need to match the beams on BHD BS as well.
• Setup steering mirrors and photodiodes on the outside table on ITMY.

[Anchal, Paco, JC]

Thanks Chris for the fix. We are able to access the testpoints now but we started facing another issue this morning, not sure how it is related to what you did.

• The C1:LSC-TRX_OUT and C1:LSC-TRY_OUT channels are stuck to zero value.
• These were the channels we used until last friday to align the interferometer.
• These channels are routed through the c1rfm FE model (Reflected Memory model is the name, I think). These channels carry the IR transmission photodiode monitors at the two ends of the interferometer, where they are first logged into the local FEs as C1:SUS-ETMX_TRX and C1:SUS-ETMY_TRY .
• These channels are then fed to C1:SCX-RFM_TRX -> C1:RFM_TRX -> C1:RFM-LSC_TRX -> C1:LSC-TRX and similar for Y side.
• We are able to see channels in the end FE filtermodule testpoints (C1:SUS-ETMX_TRX_OUT & C1:SUS-ETMY_TRY_OUT)
• However, we are unable to see the same signal in c1rfm filter module testpoints like C1:RFM_TRX_IN1, C1:RFM_TRY_IN1 etc
• There is an IPC error shown in CDS FE status screen for c1rfm in c1sus. But we remember seeing this red for a long time and have been ignoring it so far as everything was working regardless.

The steps we have tried to fix this are:

• Restart all the FE models in c1lsc, c1sus, and c1ioo (without restarting the computers themselves) , and then burt restore.
• Restart all the FE models in c1iscex, and c1iscey (only c1iscey computer was restarted) , and then burt restore.

These above steps did not fix the issue. Since we have  the testpoints (C1:SUS-ETMX_TRX_OUT & C1:SUS-ETMY_TRY_OUT) for now to monitor the transmission levels, we are going ahead with our upgrade work without resovling this issue. Please let us know if you have any insights.

[Anchal, Paco, Yuta]

• We aligned AS path avoiding any clipping to the AP table where we setup a camera with a lens.
  • To do this we had to move AS6 in North direction for ~1cm.
  • The Injection table was imbalanced by this move to drop the IMC transmission to half.
  • We did not balance the table again, we steered the input mirror to reach to 1000 counts (out of 1200 nominal) and then used WFS loop to get to the last bit.
  • The input to the arm cavities did not change much, XARM was still flashing to 0.8 max height and YARM to 0.2. We recovered these easily using the cavity mirror pair.
• We aligned the LO beam to be spatially matched on BHDBS with AS path.
  • The LO beam was steered to roughly overlap with the AS beam outputs on the BHDBS.
  • However, the LO beam size is very large and diverges after LO4.
  • According to 40m/15379, the 0.15m ROC of LO4 right after the beam waist is supposed to collimate the beam to a 522 um waist.
  • We confirmed that LO4 is marked as a 0.15m ROC mirror on its edge and the HR coating is facing the incident beam.
    • Conjecture (AG): The coating was applied to the flat side of the optic instead of the curved side.
    • This would explain why the beam is continuing to diverge after reflecting from LO4, and diverging fast.
  • We need to fix this issue before pumping down otherwise the mode matching would be too poor in BHDBS to have any meaningful results.
• The output of BHDBS was steered out and a GigE camera is set up to see this path.
  • The camera is set to see the transmitted AS beam from BHD BS (and reflected LO beam).
  • But the camera is unable to see any LO beam due to large divergence.
  • The LO beam essentially disappears after ~30 cm from the BHDBS.

[Anchal, Paco, Yuta]

SRM Placement

• SRM was moved from its parked location to the nominal position in the ITMY chamber.
• This imbalanced the table a lot as all SOS towers ended up on the south side of the table.
• I needed additionally three SOS tower side walls to recover the balance of the table.
  • I initially tried to use a level meter on my phone which claimed to have 0.1 degrees of accuracy. But it turned out to be a bad idea.
  • Eventually, I used the spirit bubble level meter we have, along with the OSEM values of ITMY, AS1, and AS4.
• At the end, the table is balanced as it was before, all SOS are damping usually.

SRM Sat Amp Box setup

• SRM Gold Box Sat Amp was found near the BS chamber.
• This box was moved to the ITMY chamber.
• The new flange on the East end was marked earlier for SRM. This flange on the vacuum side was connected with new in-vacuum blue ribbon cables.
• We had previously moved the cable post for SRM (40m/16849) behind AS2. This cable post is connected to the old in-vacuum cable.
• It would have changed the table balance to remove this cable post and connect new in-vacuum cables to it, so we decided to do this in the next vent when we put the BHD board on the table.
• For now, we connected the old in-vacuum cable to the new in-vacuum blue ribbon cables inside.
  • Note, that the old in-vacuum cable has a gender flipping section which also mirrors the pin layout.
  • We installed pin mirroring cables on the outside between the Sat Amp Box and the vacuum flange to revert back the additional mirroring.
  • However it happened, now the Sat Amp Box is working, with all OSEMs and coils alive.
• One peculiarity we found was that the SRM face OSEMs have only about 250-300 um of range, which is roughly 3 times less than the other OSEMs in other SOSs.
• SRM side OSEM however behaves normally.
• After installment, at the free-hanging state, SRM LL OSEM is saturated (too bright) and other face OSEMs are close to total brightness state.
• We'll first put the alignment offsets to get the SRM perpendicular to the beam coming from SR2 and then center the OSEMs in this tiny range.
• The low OSEM range could be due to improper biasing from the Sat Amp Box. Hopefully, with new electronics, this issue would go away in future.

I centered WFS1 PD so that IMC WFS Servo does not go out of range.

[Anchal, Paco, Yuta, JC]

SRM Oplev setup

• We setup SRM oplev path for the aligned position of SRM.
• This was bit hard, because the return beam was following almost the same path as the input beam, and the return beam had become about 1 cm in diameter.
• We replaced one of the in-air steering mirror of SRM op-lev input beam with a 1 inch BS on a non-steeerable mount.
• The returning oplev beam is picked at transmission from this BS.
• Note: we are not sure if this BS is actually coated for IR or Visible. We couldn't find a visible BS in the lab. We should order a 2 in diameter visible BS to be placed in this position.
• Half of the input beam would be used for PRM Oplev input.
• The returning beam was focused with a 100mm focal length lens. Again, this lens is not verified to be for visible wavelength. We think it might have an AR coating for IR. We should get a visible lens for this position also.

PRM Placement

• PRM placed in nominal position + 2 cm, East.
• Currently, PRM SOS tower is blocking BS oplev input beam, this needs to be adjusted.
• Installed PRMOL at nominal position + 2 cm East (to clear path from TT2)
• I balanced the table succesfully, first using spirit bubble level and then OSEM levels of BS, SR2, PR3 and LO2.
  • Note, that we need to adjust OSEM positions in many of these SOS before pumping down.
• Input beam from TT2 is going through center of PRM but the reflction is not coming back from PR2, maybe it is missing PR2 or PR2 alignment needs to be adjusted.

[Anchal, Paco, Yuta]

BS Oplev Path

• The changed position of PRM (40m/16863) meant that BS oplev path is getting clipped by the PRM SOS tower.
• We had to move BSOL ~ 16 cm North and ~ 1.7 cm East.
• This means that the BS Oplev input beam is now coming behind TT2 instead of infront of it.
• We also had to align the beam such that input and returning beam are colinear.
• This meant we, had to change the mount of the upstream beamsplitter in the in-air table so that we can use that for separating the return beam.
• Again, we should order 2 inc visible BS for this path.
• Half of the return beam is making its way all the way back to the laser head. I'm not sure if that can be an issue for our oplev loops.
• We kept the SRM Oplev path same using irises on the table.

PRM Oplev

• Again, due to changed position of PRM and BS Oplev, it became very hard to setup oplev for PRM.
• We found a special position which allows us to catch returning beam through the center of the window.
  • But this returning beam is not prompt reflection from PRM, it is reflection of the HR surface.
  • We are hitting about ~5 mm from the edge of PRMOL mirror (because we cannot move the mirror anymore south to avoid clipping BS and SRM input oplev beams)
  • We put in a 1.1m focal length lens in the input beam to narrow the beam on PRMOL so that it doesn't clip
• We did not put any lens for the return beam. The sensitivity of this oplev might be low due to slighlty bigger beam on the QPD than others (SRM, BS). We can revisit and insert a lens later if required.

Interferometer alignment and PRM alignment

• The work on BS table did not change the table balance much. We got back the alignment pretty much instantly.
• We were able to maximize the arm transmissions.
• Then we used a beam card with hole to check for reflection from PRM and used PRM (mostly pitch correction) to get the return beam back in same way.
• This recovered REFL beam on the camera. We used REFLDC signal to align PRM better and maximized it.
• We centered BS, SRM and PRM oplevs after this point.

LO beam mode correction and spatial overlap

• We tried changing the distance between LO3 and LO4 to get a better output LO beam.
• We also tried to swap the LO4 mirror with the spare mirror but we had the same result.
• Eventually, we decided to move LO3 back to East and LO4 to the west edge of the table. This made the beam sizes comparable.
  • Future exercise: We think that LO1 or LO2 might be significantly off-spec in their ROCs which might cause this issue.
  • We should rerun the calculations with the ROC values of LO1 and LO2 written in the datasheets and figure out the correct LO3-LO4 length required.
  • We can make this change in the next vent if required.
• After the beam sizes were looking approximately similar but more iterations of changing length and realigning are required.

Remaining tasks before pumpdown

• Push/pull too bright/dark OSEMs in the SOSs (40m/16865).
• Finish LO beam mode correction and spatial overlap.
• Center all oplevs, note all beam positions on camera, and note down all DC PD values at proper alignment.

I modified the script freeSwing.py to use damping loop output switches to free the optic instead of watchdog or coil output filters. This ensures that the free swing test is being done at the nominal position of the optic. I started tests for LO1, LO2, As2, As4, PR2, PR3, and SR2 in a tmux session names freeSwing on rossa.

Note: LO2 face OSEMs are hardly sensitive to any motion right now due to excessive pitch offset required for LO beam. We should relieve this offset to LO1 and rerun this test later.

Since UL coil actuation is lost, we modified the output matrix of ITMY to use only UR, LR and LL face coils for POS, PIT and YAW actuation. The output matrix was changed to following:

After this change, the damping was still working as good as before. I took PIT to POS/PIT/YAW and YAW to POS/PIT/YAW coupling measurements by exciting C1:SUS-ITMY_ASCPIT[YAW]_EXC and seeing effect at C1:SUS-ITMY_SUS[POS/PIT/YAW]_IN1 when the damping loops were off. Attached are the results. We were able to reduce PIT to YAW and YAW to PIT coupling by 10 dB by this simple change in output matrix. More coil balancing or off-diagonal termsmight help more and should be attempted if required. The coupling to POS did not change much.

Note that attachment 1 shows transfer functions from excitation point to the DOF sensing inputs while attachment two looks at ratio of C1:SUS-ITMY_SUS[POS/PIT]_IN1 to C1:SUS-ITMY_SUSYAW_IN1 which is the actual quantity of interest. I didn't repeat the PIT measurement due to lack of time.

Also note that all such measurements are being recorded in our new measurements git repo. We'll populate this repo with diaggui template+data files as we do measurements.

[Anchal, Yuta]

In the weekend, I ran a free swing test on all optics. During this test, LO2 magnets got stuck to the coil because LO2 PIT alignment was very high, making its lower OSEMs almost fully dark and upper OSEMs almost fully bright. Today we realized that LO2 is actually stuck and is not coming off even when we dither PIT alignment. We tried several ways but could not get this off.

Do we have any other method to get magnets off in vaccum?

It will be pretty bad if we try anything related to BHD with LO beam reflecting off a stuck mirror. Does anyone have any suggestions other than venting and fixing the issue?

I finally got YARM AS to work today. It is hard to describe what worked, I did a lot of monkey business and some dirty offset measurements to create the ASS output matrix that gave results. Note that I still had to leave out ITMY PIT L error signal, but transmission was maximizing without it. The beam does not center fully on ITMY in Pit direction right now, but we'll mvoe on from this problem for now. Future people are welcome to try to make it work for this last remaining error signal as well.

commit

I used the same fre swing data to diagnolize input matrices of following optics:
MC1, MC2, MC3

BS ETMX ETMY

AS1 AS4 SR2 PR2 PR3

For all these optics, the new input matrices worked well. Next step should be to take the local damping open loop transfer functions and standardize the loops to same UGF.

What didn't work:

• The calculated input matrix for ITMX differed from existing matrix too much, including overall sign of rows POS and PIT. Even after correcting those signs, I was not able to get a good damping loop configuration. So I have committed the new matrix to the repo but have not implement it. More close analysis or another test might be required for this optic.
• LO1, LO2, and ITMY were not analysed because their free swing test was not valid. LO1 and ITMY had non-working coils and LO2 was stuck during the test. We'll take another free swing test for these three optics (and possible ITMX) in near time.

All diagonalization results are present in https://git.ligo.org/40m/scripts/-/tree/main/SUS/InMatCalc

For looking at the results at this point, go to this commit: https://git.ligo.org/40m/scripts/-/tree/7ef6a47d1b2051a0732f46477624a9e625737fe8

Over the weekend, I ran freeSwing test with sequential kicks in specific DOFs for LO1, ITMY, ITMX. LO1 results were successfully used to diagonalize LO1 input matrix. There are some issues for ITMY, ITMX still. I could not run LO2 test.

LO1

The free swing test ran successfully, resonant frequencies for different DOFs was extracted, and new input matrix was calculated. The new matrix was only slightly different from before and it worked fine with existing damping loops. The observed resonance frequencies were different from previous values by POS: -6 mHz, PIT : -3 mHz, YAW: -9 mHz, SIDE: -2 mHz. Attached are the diagonalization result.

ITMX

The peculiarity of ITMX remained even after the second free swing test. The calculated input matrix is very different from existing one with sign flips across PIT and POS rows. I found that our LR osem is always bright in ITMX at the current alignment position. I see that LR osem comes in range when C1:SUS-ITMX_PIT_COMM is raised above 0.5. Maybe we should run this test when we know for sure ITMX is in correct position.

ITMY

In ITMY on the other hand, I found that SIDE OSEM was completely bright. This happened during the YAW kick to ITMY. We'll need to reduce kick amplitudes for ITMY and redo this test.

LO2

For LO2, I could not initiate the test. On reducing the alignment offsets for LO2 (so that it doesn't get stuck in the fre swing test), the damping loops were not working. This is a clear evidence also that input matrix is different for different positions of the optic. We need to think about some other strategy to do this test, maybe see if ideal input amtrix works at no offsets and use that to damp during the test.

The 0x2000 error in c1su2 happens whenever we make it and install it as the default data acquisition rates are too much in the suspension model. Earlier we used activateSUS2DQ.py to fix this. I followed the suggestion in 40m/16537 to include COIL_OUT at 16k, damping channels at 256 Hz and OL channels at 1024 Hz. I created new suspension model at /cvs/cds/rtcds/userapps/trunk/sus/c1/models/lib/sus_single_control_new.mdl. The model also contains filter modules names C1SUS_OPT_BIASPOS, C1SUS_OPT_BIASPIT, C1SUS_OPT_BIASYAW which acts on the alignment offsets so that a low pass filter can be added there and alignment offsets always happen slowly. The new suspension model is now used inc1su2 for teh 7 new suspensions, and now the model starts without errors.

Still remaining to fix: IPC communication between c1hpc and c1lsc.

This issue is very weird and still unresolved. Without WFS loops, we'll have to realign IMC often and we might loose IMC alignment completely during weekends or long weekends.

I tried following things today but nothign worked:

• Blocked WFS PDs and reset DC offsets (sitemap>C1IOO>C1IOO_WFS_MASTER>! Actions>Correct WFS DC Offsets).
• Switched off MC chamber lights.
  I felt that they might be on, but later I feel that wasn't the case. Anyways, this didn't help.
• Algined IMC manually using cavAlign tool with MC2-MC3 and then tweaking MC1 and MC3 a little bit. Reach 13.6k in C1:IOO-MC_TRANS_SUM. Then I unlocked IMC with autolocker off, centered beam on WFSs (they were pretty off even though we have been centering them this week), and then reset RF offsets (sitemap>C1IOO>C1IOO_WFS_MASTER>! Actions>Correct WFS DC Offsets). This did not help either.
• The fact that IMC started misbehaving since Thursday onwards was bugging me that maybe the FE models did not come online properly, that maybe some RTS link is broken in IOO model which is causing the feedback loop to not work. So I went ahead and restarted all models, that didn't help either.
  • Now we have a restartAllModels.sh script which restarts all cds system and restores state to just before restarting. It also makes sure that watchdogs are engaged safely particularly for new suspesnions where alignment offsets are ramped.

We need to investigate this as first priority. Maybe some cable is loose, some PD power supply not working etc. Until we fix this, people should align IMC to > 12000 transmission counts whenever they have a spare 5 min. We need to work in place of WFS for sometime.

I added today demodulation of C1:LSC-BEATX/Y_FINE_I/Q in the c1cal demodulation where different degrees of freedom can be dithered. For McCal (formerly soCal), we'll dither the arm cavity for which we can use any of the DOFs (like DARM) to send the dither to ETMX/ETMY. Then with green laser locked as well, we'll get the calibration signal from the beatnotes in the demodulaed channels. We can also read right after the mixing in c1cal model and try differnt poles for integration .

I've also added medm screens in the sensing matrix part of LSC screen. These let you see demodulation of beatnote frequency signals.

We can calculate how much detector calibration uncertainty affects the estimation of astrophysical parameters using the following method:

Let be set of astrophysical parameters (like component masses, distance etc), be set of detector parameters (like detector pole, gain or simply transfer function vaue for each frequency bin). If true GW waveform is given by , and the detector transfer function is given by , then the detected gravitational waveform becomes:

One can calculate a derivative of waveform with respect to the different parameters and calculate Fisher matrix as (see correction in 40m/17017):

where the bracket denotes iner product defined as:

where is strain noise PSD of the detector.

With the gamma matrix in hand, the error propagation from detector parameter fractional errors to astrophysical paramter fractional errors is given by (eq 26 in Evan et al 2019 Class. Quantum Grav. 36 205006):

where and .

Using the above mentioned formalism, I looked into two ways of calculating error propagation from detector calibration error to astrophysical paramter estimations:

Using detector response function model:

If we assume detector response function as a simple DC gain (4.2 W/nm) and one pole (500 Hz) transfer function, we can plot conversion of pole frequency error into astrophysical parameter errors. I took two cases:

• Binary Neutron Star merger with star masses of 1.3 and 1.35 solar masses at 100 Mpc distance with a of 500. (Attachment 1)
• Binary black hole merger with black masses of 35 and 30 at 400 MPc distance with spin along z direction of 0.5 and 0.8. (I do not fully understand the meaning of these spin components but a pycbc waveform generation model still lets me calculate the effect of detector errors) (Attachment 2)

The plots are plotted in both loglog and linear plots to show the order of magnitude effect and how the error propsagation slope is different for different parameters. 'm still not sure which way is the best to convey the information. The way to read this plot is for a given error say 4% in pole frequency determination, what is the expected error in component masses, merger distance etc. I

Note that the overall gain of detector response is not sensitive to astrophysical error estimation.

Using detector transfer function as frequency bin wise multi-parameter function

Alternatively, we can choose to not fit any model to the detector transfer function and simply use the errors in magnitude and phase at each frequency point as an independent parameter in the above formalism. This then lets us see what is the error propagation slope for each frequency point. The hope is to identify which parts of the calibration function are more important to calibrate with low uncertainty to have the least effect on astrophysical parameter estimation. Attachment 3 and 4 show these plots for BNS and BBH cases mentioned above. The top panel is the error propagation slope at each frequency due to error in magnitude of the detector transfer function at that frequency and the bottom panel is the error propagation slope at each frequency due to error in phase of the detector transfer function.

The calibration error in magnitude and phase as a function of frequency would be multiplied by the curves and summed together, to get total uncertainty in each parameter estimation.

This is my first attempt at this problem, so I expect to have made some mistakes. Please let me know if you can point out any. Like, do the order of magnitude and shape of error propagation makes sense? Also, comments/suggestions on the inference of these plots would be helpful.

Finally, I haven't yet tried seeing how these curves change for different true values of the merger event parameters. I'm not yet sure what is the best way to extract some general information for a variety of merger parameters.

Future goals are to utilize this information in informing system identification method i.e. multicolor calibration scheme parameters like calibration line frequencies and strength.

Code location

Now that you have found a working configuration, I suggest we update CARM and DARM filter banks so that they are used in locking those degrees of freedom instead of repurposing XARM/YARM banks. It would be bit easier to understand and leaves room for future changes for one configuration while keeping single arm lock configurations untouched.

Addressing the comments as numbered:

1. Yeah, that's correct, that equation normally but it is different if I define bit differently that I did in the code, correct my definition of to :
   
   then the relation between fractional errors of detector parameter and astrophysical parameters is:
   
   I prefer this as the relation between fractional errors is a dimensionless way to see it.
2. Thanks for pointing this out. I didn't see these parameters used anywhere in the examples (in fact there is no t_c in documentation even though it works). Using these did not affect the shape of error propagation slope function vs frequency but reduced the slope for chirped Mass by a couple of order of magnitudes.
   1. I used the get_t_merger(f_gw, M1, M2) function from Hang's work to calculate t_c by assuming  must be the lowest frequency that comes within the detection band during inspiral. This function is:
      
      For my calculations, I've taken as 20 Hz.
   2. I used the get_f_gw_2(f_gw_1, M1, M2, t) function from Hang's work to calculate the evolution of the frequency of the IMR defined as:
      
      where is the frequency at t=0. I integrated this frequency evolution for t_c time to get the coalescence phase phi_c as:
      
3. In Fig 1, which representation makes more sense, loglog of linear axis plot? Regarding the affect of uncertainties on Tidal amplitude below 500 Hz, I agree that I was also expecting more contribution from higher frequencies. I did find one bug in my code that I corrected but it did not affect this point. Maybe the SNR of chosen BNS parameters (which is ~28) is too low for tidal information to come reliably anyways and the curve is just an inverse of the strain noise PSD, that is all the information is dumped below statistical noise. Maybe someone else can also take a look at get_fisher2() function that I wrote to do this calculation.
4. Now, I have made BBH parameters such that the spin of the two black holes would be assumed the same along z. You were right, the gamma matrix was degenerate before. To your second point, I think the curve also shows that above ~200 Hz, there is not much contribution to the uncertainty of any parameter, and it rolls-off very steeply. I've reduced the yspan of the plot to see the details of the curve in the relevant region.

Some insights from the inside vacuum situation:

• The beam is an incident near normal on PR2 close to the center of the optic. It wasn't hard to align this part, I'm very confident that we aligned it to the center of PR2. So I do not think the LO beam is ghost beam from PR2.
• The place that is most susceptible to clipping is POP_SM5 mirror in front of LO1. The LO beam has little clearance from the edge of the mirror.
• Another possibility of clipping in LO beam is through the cage of LO2. LO2 is a 45-degree incidence mirror, so it is possible we are clipping off the cage or seeing a ghost beam mixed in LO beam here.
• The fact that moving PR2 is affecting LO beam is weird but doesn't necessarily mean it is a ghost from PR2.

The FSSSlow script was not properly documented and it was not working, so I had to use one that I knew worked from CTN. This scripts lives in

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDLocker.py

and uses a configuration file

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDConfigFSS.yml

The script runs all the time inside docker container which keeps it running. The heart-beat blinker shows if the script is active or not, but it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1. The second channel is a button on C1PSL_SLOW screen to engage autolocker. It has to be turned on for FSS to work.

docker instructions:

The following message is displayed on login in optimus:

For checking log files of autolocker script, on optimus do:

For checking log files of FSS PID loop, on optimus do:

In the above commands, add < | tail -15> to just see the most recent 15 lines in the log file. change 15 to whatever number of lines you want to see from the end.

At any time, if you want to know how docker is running stuff, check out the /opt/rtcds/caltech/c1/Git/40m/scriptsdocker-compose.yml file for self-explanatory script usage.

I'll add some documentation on the wiki soon. That is indeed required and should have been done already.

Debugging scripts:

All scripts could be debugged by running them on rossa by directly using python command. You can stop the docker container on optimus using:

and then run the file on rossa to check it's behavior. After debugging and fixing any issues, please commit the file to gitlab repo and go back to optimus and restart the docker container:

I'll add this procedure to a wiki page as well.

Reverting back to systemd on megatron

The setup on megatron was not removed at all. All service files exist in same place and old scripts can be started in the old manner by doing following on megatron:

For FSSSlow:

For MC autolocker:

For diabling these services again, do:

Note that one should stop docker containers on optimus before starting these systemd services to avoid conflicting scripts running together.

I have added above instructions on megatron motd. So on loging into megatron, these updated instructions would come.

If someone wants to fix the old scripts and use systemd for managing those scripts, please do so but I won't be able to help in debugging those old scripts. The shell scripts are very complicated and beyond my knowledge and python scripts are lacking documentation.

I'm happy to help debug or extend the functionality of the new scripts that live in the git directory.

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

All steps taken have been recorded here:
https://wiki-40m.ligo.caltech.edu/Complete_power_shutdown_2022_08

[Anchal, Paco, Tega]

Disk full issue:

c1vac was showing /var disk to be full. We moved all gunzipped backup logs to /home/controls/logBackUp. This emptied 36% of space on /var. Ideally, we need not log so much. Some solution needs to be found for reducing these log sizes or monitoring them for smart handling.

Pressure sensor malfunctioning:

We were unable to opel the PSL shuttter, due to the interlock with C1:Vac-P1a_pressure. We found that C1:Vac-P1a_pressure is not being written by serial_MKS937a service on c1vac. The issue was the the sensor itself has become bad and needs to be replaced. We believe that "L 0E-04" in the status (C1:Vac-P1a_status) message indicates a malfunctioning sensor.

Quick fix:

We removed writing of C1:Vac-P1a_pressure and C1:Vac-P1a_status from MKS937a and mvoed them to XGS600 which is using the sensor 1 from main volume. See this commit.

Now we are able to open PSL shutter. The sensor should be replaced ASAP and this commit can be reverted then.

[Anchal, Tega]

As a first step to characterize all the local damping loops, we ran an open loop transfer function measurement test for all BHD optics, taking transfer function using band-limited (0.3 Hz to 10 Hz) gaussian noise injection at error points in different degrees of freedom. Plots are in the git repo. I'll make them lighter and post here.

We have also saved coherence of excitation at the IN1 test points of different degrees of freedom that may be later used to determine the cross-coupling in the system.

The test ran automatically using measSUSOLTF.py script. The script can run the test parallelly on all suspensions in principle, but not in practice because the cdsutils.getdata apparently has a limitation on how many real-time channels (we think it is 8 maximum) one can read simultaneously. We can get around this by defining these test points at DQ channels but that will probably upset the rtcds model as well. Maybe the thing to do is to separate the c1su2 model into two models handling 3 and 4 suspensions. But we are not sure if the limitation is due to fb or DAQ network (which will persist even if we reduce the number of testpoints on one model) or due to load on a single core of FE machines.

The data is measured and stored here. We can do periodic tests and update data here.

Next steps:

• Run the test for old optics as well.
• Fit the OLTF model with the measured data, and divide by the digital filter transfer function to obtain the plant transfer function for each loop.
• Set maximum noise allowed in the local damping loop for each degree of freedom, and criteria for Q of the loop.
• Adjust gains and or loop shape to reach the requirements on all the suspensions in a quantitative manner.
• (optional) Add a BLRMS calculation stream in SUS models for monitoring loop performance and in-loop noise levels in the suspensions.
• More frequency resolution, please. (KA)

I made measurements of old optics OLTF today. I have reduced the file sizes of the plots and data now. It is interesting that it is allowed to read 9 channels simultaneously from c1mcs or c1sus models, even together. The situation with c1su2 is a bit unclear. I was earlier able to take measurements of 6 channels at once from c1su2 but not I can't read more than 1 channel simultaneously. This suggests that the limit is dictated by how much a single model is loaded, not how much we are reading simultaneously. So if we split c1su2 into two models, we might be able to read more optics simultaneously, saving time and giving us the ability to measure for longer.

Attached are the results for all the core optics. Inferences will be made later in the week.

Note: Some measurements have very low coherence in IN2 channels in most of the damping frequency region, these loops need to be excited harder. (eg PIT, POS, YAW, on ITMs and ETMs).

[Anchal, Radhika]

Attachment 2: The custom cables which were part of the intermediate setup between old electronics architecture and new electronics architecture were found.
These include:

• 2 DB37 cables with custom wiring at their connectors to connect between vacuum flange and new Sat amp box, marked J4-J5 and J6-J7.
• 2 DB15 to dual head DB9 (like a Hydra) cables used to interface between old coil drivers and new sat amp box.

A copy of these cables are in use for MC1 right now. These are spare cables. We put them in a cardboard box and marked the box appropriately.
The box is under the vacuum tube along Yarm near the center.

[Anchal, Radhika]

The cables in USPS open box were important cables that are part of the new electronics architecture. These are 3 ft D2100103 DB15F to DB9M Reducer Cable that go between coil driver output (DB15M on back) to satellite amplifier coil driver in (DB9F on the front). These have been placed in a separate plastic box, labeled, and kept with the rest of the D-sub cable plastic boxes that are part of the upgrade wiring behind the tube on YARM across 1Y2. I believe JC would eventually store these dsub cable boxes together somewhere later.

[Anchal, Yehonathan]

I laid down another temporary cable from Xend to 1Y2 (LSC rack) for also measuring the Q output of the DFD box. Then to get a quick measurement of these long cable delays, we used Moku:GO in oscillator mode, sent 100 ns pulses at a 100 kHz rate from one end, and measured the difference between reflected pulses to get an estimate of time delay. The other end of long cables was shorted and left open for 2 sets of measurements.

I-Mon Cable delay: (955+/- 6) ns / 2 = 477 +/- 3 ns

Q-Mon Cable delay: (535 +/- 6) ns / 2 = 267 +/- 3 ns

Note: We were underestimating the delay in I-Mon cable by about a factor of 2.

I also took the opportunity to take a delay time measurement of DFD delayline. Since both ends of cable were present locally, it made more sense to simply take a transfer function to get a clean delay measurement. This measurement resulted with value of 197.7 +/- 0.1 ns. See attached plot. Data and analysis here.

The coil driver actuation strength for face coils was increased by 13 times in LO1, LO2, SR2, AS1, AS4, PR2, and PR3.

After the change the damping strenghth of POS, PIT, and YAW were reduced, but not SIDE coil output filter module requires higher digital input to cause same force at the output. This wouldn't be an issue until we try to correct for cross coupling at output matrix where we would want to give similar order of magnitude coefficients for SIDE coil as well. So I did the following changes to make input to all coil output filters (Face and side) same for these particular suspensions:

• C1:SUS-LO1_SUSSIDE_GAIN 40.0 -> 3.077
  C1:SUS-AS1_SUSSIDE_GAIN 85.0 -> 6.538
  C1:SUS-AS4_SUSSIDE_GAIN 41.0 -> 3.154
  C1:SUS-PR2_SUSSIDE_GAIN 150.0 -> 11.538
  C1:SUS-PR3_SUSSIDE_GAIN 100.0 -> 7.692
  C1:SUS-LO2_SUSSIDE_GAIN 50.0 -> 3.846
  C1:SUS-SR2_SUSSIDE_GAIN 140.0 -> 10.769

• C1:SUS-LO1_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-AS1_SDCOIL_GAIN 1.0 -> 13.0
  C1:SUS-AS4_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-PR2_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-PR3_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-LO2_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-SR2_SDCOIL_GAIN -1.0 -> -13.0

In short, now 10 cts of input to C1:SUS-AS1_ULCOIL would create same actuation on UL as 10 cts of input to C1:SUS-AS1_SDCOIL will on SD.

In reply to

With limited proof of working for a few times (but robustly), I'm happy to report that ASS on YARM and XARM is working now.

What is wrong?

The issue is that PR3 is not placed in correct position in the chamber. It is offset enough that to send a beam through center of ITMY to ETMY, it has to reflect off the edge of PR3 leading to some clipping. Hence our usual ASS takes us to this point and results in loss of transmission due to clipping.

Solution: We can not solve this issue without moving PR3 inside the chamber. But meanwhile, we can find new spot positions on ITMY and ETMY, off the center in YAW direction only, which would allow us to mode match properly without clipping. This would mean that there will be YAW suspension noise to Length coupling in this cavity, but thankfully, YAW degree of freedom stays relatively calm in comparison to PIT or POS for our suspensions. Similarly, we need to allow for an offset in ETMX beam spot position in YAW. We do not control beam spot position on ITMX due to lack of enough actuators to control all 8 DOFs involved in mode matching input beam with a cavity. So instead I found the right offset for ITMX transmission error signal in YAW that works well.

I found these offsets (found empirically) to be:

• C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET: 22.6
• C1:ASS-YARM_ITM_YAW_L_DEMOD_I_OFFSET: 4.2
• C1:ASS-XARM_ETM_YAW_L_DEMOD_I_OFFSET: -7.6
• C1:ASS-XARM_ITM_YAW_T_DEMOD_I_OFFSET: 1

These offsets have been saved in the burt snap file used for running ASS.

Using ASS

I'll reiterate here procedure to run ASS.

• Get YARM locked to TEM00 mode and atleast 0.4 transmission on C1:LSC-TRY_OUT
• Open sitemap->ASC->c1ass
• Click ! Scripts YARM -> Striptool to open a striptool monitor for ASS error signals.
• Click on ! Scripts YARM -> Dither ON to switch on the dither.
• Wait for all error signals to have settled around zero (this should also maximize the transmission channel (currently maximizing to 1.1).
• Click on ! Scripts YARM -> Freeze Offsets
• Click on ! Scripts YARM -> Offload Offsets
• Click on ! Scripts YARM -> Dither OFF.
• Then proceed to XARM. Get it locked to TEM00 mode and atleast 0.4 transmission on C1:LSC-TRX_OUT
• Open sitemap->ASC->c1ass
• Click ! Scripts XARM -> Striptool to open a striptool monitor for ASS error signals.
• Click on ! Scripts XARM -> Dither ON to switch on the dither.
• Wait for all error signals except C1:ASS-XARM_ITM_PIT_L_DEMOD_I_OUT16 and C1:ASS-XARM_ITM_YAW_L_DEMOD_I_OUT16 to have settled around zero (this should also maximize the transmission channel (currently maximizing to 1.1).
• Click on ! Scripts XARM -> Freeze Offsets
• Click on ! Scripts XARM -> Offload Offsets
• Click on ! Scripts XARM -> Dither OFF.

[Paco, Anchal]

We performed local damping loop tuning for ETMs today to ensure all damping loops' OLTF has a Q of 3-5. To do so, we applied a step on C1:SUS-ETMX/Y_POS/PIT/YAW_OFFSET, and looked for oscillations in the error point of damping loops (C1:SUS-EMTX/Y_SUSPOS/PIT/YAW_IN1) and increased or decreased gains until we saw 3-5 oscillations before the error signal stabilizes to a new value. For side loop, we applied offset at C1:SUS-ETMX/Y_SDCOIL_OFFSET and looked at C1:SUS-ETMX/Y_SUSSIDE_IN1. Following are the changes in damping gains:

C1:SUS-ETMX_SUSPOS_GAIN : 61.939   ->   61.939
C1:SUS-ETMX_SUSPIT_GAIN :   4.129     ->   4.129
C1:SUS-ETMX_SUSYAW_GAIN : 2.065     ->   7.0
C1:SUS-ETMX_SUSSIDE_GAIN : 37.953  ->   50
C1:SUS-ETMY_SUSPOS_GAIN : 150.0     ->   41.0
C1:SUS-ETMY_SUSPIT_GAIN :   30.0       ->   6.0
C1:SUS-ETMY_SUSYAW_GAIN : 30.0       ->   6.0
C1:SUS-ETMY_SUSSIDE_GAIN : 50.0      ->   300.0

I updated follwoing in teh rtcds models and medm screens:

• c1lsc
  • Added reading of ADC0_20 and ADC0_21 as demodulated BHD output at 55 MHz, I and Q channels.
  • Connected BH55_I and BH55_Q to phase rotation and creation of output channels.
  • Replaced POP55 with BH55 in the RFPD input matrix.
  • Send BH55_I and BH55_Q over IPC to c1hpc
  • Added BH55 RFPD model in LSC screen, in RFPD input matrix, whitening box. Some work is still remaining.
• c1hpc
  • Added recieving BH55_I and BH55_Q.
  • Added BH55_I and BH55_Q to sensing matrix through filter modules. Now these can be used to control LO phase.
  • Added BH55 signals to the medm screen.
• c1scy
  • Updated SUS model to new sus model that takes care of data acquisition rates and also adds BIASPOS, BIASPIT and BIASYAW filter modules at alignment sliders.

Current state:

• All models built and installed without any issue or error.
• On restarting all models, I first noticed 0x2000 error on c1lsc, c1scy and c1hpc. But these errors went away with doing daqd restart on fb1.
• BH55 FM buttons are not connected to antialiasing analog filter. Need to do this and update medm screen accordingly.
• The IPC from c1lsc to c1hpc is not working. One sender side, it does not show any signal which needs to be resolved.

BH55

I further updated LSC model today with following changes:

• BH55 whitening switch binary output signal is now routed to correct place.
  • Switching FM1 which carries dewhitening digital filter will always switch on corresponding analog whitening before ADC input.
• The whitening can be triggered using LSC trigger matrix as well.
• The ADC_0 input to LSC subsystem is now a single input and channels are separated inside the subsystem.

The model built and installed with no issues.

Further, the slow epics channels for BH55 anti-aliasing switch and whitening switch were added in /cvs/cds/caltech/target/c1iscaux/C1_ISC-AUX_LSCPDs.db

IPC issue resolved

The IPC issue that we were facing earlier is resolved now. The BH55_I and BH55_Q signal after phase rotation is successfully reaching c1hpc model where it can be used to lock LO phase. To resolve this issue, I had to restart all the models. I also power cycled the LSC I/O chassis during this restart as Tega suspected that such a power cycle is required while adding new dolphin channels. But there is no way to find out if that was required or not. Good news is that with the new cds upgrade, restarting rtcds models will be much easier and modular.

ETMY Watchdog Updated

[Anchal, Tega]

Since ETMY does not use HV coil driver anymore, the watchdog on ETMY needs to be similar to other new optics. We made these updated today. Now ETMY watchdog while slowly ramps down the alignment offsets when it is tripped.

More model changes

c1lsc:

• BH55_I and BH55_Q are now being read at ADC_0_14 and ADC_0_15. The ADC_0_20 and ADC_0_21 are bad due to faulty whitening filter board.
• The whitening switch controls were also shifted accordingly.
• the slow epics channels for BH55 anti-aliasing switch and whitening switch were added in /cvs/cds/caltech/target/c1iscaux/C1_ISC-AUX_LSCPDs.db

c1mcs:

• MC1, MC2, and MC3 are running on new suspension models now.

c1hpc:

• DCPD_A and DCPD_B have been renamed to BHDC_A and BHDC_B following naming convention at other ports.
• After the input summing matrix, the signals are called BHDC_SUM and BHDC_DIFF now.
• BHDC_SUM and BHDC_DIFF can be directly using in sensing matrix bypassing the dither demodulation (to be used for DC locking)
• BH55_I and BH55_Q are also sent for dither demodulation now (to be used in double dither method, RF and audio).
• SHMEM channel names to c1bac were changed.

c1bac:

• Conformed with new SHMEM channel names from c1hpc

I updated c1ass model today to use PR2 PR3 instead of TT1 TT2 for YARM ASS. This required changes in c1su2 too. I have split c1su2 into c1su2 (LO1., LO2, AS1, AS4) and c1su3 (SR2, PR2, PR3). Now the two models are using 31 and 21 CPU out of 60 which was earlier 55/60. All changed compiled correctly and have been uploaded. Models have been restared and medm screens have been updated.

Model changes

c1su2:

• Everything related to SR2, PR2, and PR3 have been moved to c1su3.
• Extra binary output channels are also distributed between c1su2 and c1su3. BO_4 and BO5 have been moved to c1su3.

c1su3:

• Added IPC receiving from ASS for PR2 and PR3

c1ass:

• Inputs to TT1 and TT2 PIT and YAW filter modules have been terminated to ground.
• The ASS outputs for YARM have been renamed to PR2 and PR3 from TT1 and TT2.
• IPC sending blocks added to send PR2 and PR3 ASC signals to c1su3.

To do:

• Updated YARM ASS output matrix to handle change in coil driver actuation on PR2 and PR3 in comparison to TT1 and TT2.
• Yuta suggested dithering PR2 and PR3 for input beam pointing for YARM alignment.

I turned on WFS on IMC at:

PDT: 2022-10-01 13:09:18.378404 PDT
UTC: 2022-10-01 20:09:18.378404 UTC
GPS: 1348690176.378404

The following channels are being saved in frames at 1024 Hz rate:

• C1:IOO-MC_TRANS_PIT_ERR (Same as C1:IOO-MC_TRANS_PIT_OUT)
• C1:IOO-MC_TRANS_YAW_ERR (Same as C1:IOO-MC_TRANS_YAW_OUT)
• C1:IOO-MC_TRANS_SUM_ERR (Same as C1:IOO-MC_TRANS_SUMFILT_OUT)

We can keep it running over the weekend as we will not use the interferometer. I'll keep an eye on it with occasional log in. We'll post the time when we switch it off again.

The IMC lost lock at:

UTC    Oct 03, 2022    01:04:16    UTC
Central    Oct 02, 2022    20:04:16    CDT
Pacific    Oct 02, 2022    18:04:16    PDT

GPS Time = 1348794274

The WFS loops kept running and thus took IMC to a misaligned state. Between the above two times, IMC was locked continuously with very brief lock loss events, and had all WFS loops running.

[Yuta, Paco, Anchal]

BH55 RFPD installation was still not complete until yesterday because of a peculiar issue. As soon as we would increase the whitening gain on this photodiode, we saw spikes coming in at around 10 Hz. Following events took place while debugging this issue:

• We first thought that RFPD might be bad as we had just picked it up from what we call the graveyard table.
• Paco fixed the bad connection issue at RF out and we confired RFPD transimpedance by testing it. See 40m/17159.
• We tried changing the whitening filter board but that did not help.
• We used BH55 RFPD to lock MICH by routing the demodulation board outputs to AS55 channels on WF2 board. We were able to lock MICH and increase whitening gain without the presence of any spikes. This ruled out any issue with RFPD.
• Yuta and I tried swapping the whitening filter board but the problem persisted, which made us realize that the issue could be in the acromag that is writing the whitening gain for BH55 RFPD.
• We combed through the /cvs/cds/caltech/target/c1iscaux/C1_ISC-AUX_LSCPDs.db file to check if the whitening gain DAC channels are written twice but that was not the case. But changing the scan rate of the whitening gain output channel did change the rate at which teh spikes were coming.
• This proved that some other process is constantly writing zero on these outputs.
• It tuned out that all unused channels of acromags for c1iscaux are still defined and made to write 0 through /cvs/cds/caltech/target/c1iscaux/C1_ISC-AUX_SPARE.db file. I don't think we need this spare file. If someone wants to use spare channels, they can quickly add it to dB file and restart the modbusIOC service on c1iscaux, it takes less than 2 minutes to do it. I vote to completely get rid of this file or atleast not use it in the cmd file.
• After removing the violating channels, the problem with BH55 RFPD is resolved.

The installation of BH55 RFPD is complete now.

[Chris, Anchal]

Chris and I discussed our plan for CDS upgrade which amounts to moving new FEs, new chiara, and new FB1 OS system tomartian network.

Preparation:

• Chiara (clone) (will be called "New Chiara" henceforth) will be resynced to existing chiara to get all model and medm changes.
• All models on New Chiara will be rebuilt, and reinstalled.
• All running servies on existing chiara will be printed and stored for comparison later.
• New Chiara's OS drive will be updraged to Debian 10 and all services will be restored:
  • DHCP
  • DNS
  • NFS
  • rsync
• Existing fb1 DAQ network card (10 GBps ethernet card) will be verified.
• Make a list of all fb1 file system mounts and their UUIDs.

Upgrade plan:

Date: Fri Oct 7, 2022
Time: 11:00 am (After coffee and donuts)
Minimum required people: Chris, Anchal, JC (the more the merrier)

Steps:

1. Ensure a snapshot of all channels is present from Oct 6th on New Chiara.
2. Shutdown all machines:
   1. All slow computers (Except c1vac).
      Computer List: ssh into the computers and run:

      sudo systemctl stop modbusIOC.service
      sudo shutdown -h now

      1. c1susaux
      2. c1susaux2
      3. c1auxex
      4. c1auxey1
      5. c1psl
      6. c1iscaux
   2. All fast computers. Run on rossa:

      /cvs/cds/rtcds/caltech/c1/Git/40m/scripts/cds/stopAllModels.sh

      Disconnect left ethernet cables from the back of these computers.
   3. Power off all I/O chassis
   4. Swap the oneStop cables on all I/O chassis to fiber cables. On c1sus, connect the copper oneStop cable to teststand c1sus FE.
   5. Tun on all I/O chassis.
3. Exchange chairas.
   1. Connect old chiara to teststand network.
   2. Connect New Chiara to martian network.
   3. Turn on both old and new chiara.
   4. Ensure all services are running on New Chiara by comparing with the list made earlier during preparation.
4. fb1.
   1. Move fb1(clone)'s OS drive into existing fb1 (on 1X6)
   2. Turn on fb1 (on 1X6).
   3. Ensure fb1 is mounting all it's file systems correctly.
5. New FEs
   1. Connect the network switch for new FEs to martian network. Make sure that old chiara is not connected to this same switch.
   2. Turn on the new FEs. All models should start on boot in sequence.
   3. Check if all models have green lights.
6. Burt restore using latest snapshot available.
7. Perform tests:
   1. Check if all local damping loops are working as before.
   2. Check if all IPC channels are transmitting and receiving correctly.
   3. Check if IMC is able to lock.
   4. Try single arm locking
   5. Try MICH locking.
8. Make contingency plan on how to revert to old system if something fails.

[Yuta, Paco, Anchal]

BH55 meas diff

We estimated meas diff angle for BH55 today by following this elog post. We used moku:lab Moku01 to send a 55 MHz tone to PD input port of BH55 demodulation board. Then we looked at I_ERR and Q_ERR signals. We balanced the gain on I channel to 1.16 to get the two signals to same peak to peak heights. Then we changed the mead diff angle to 91.97 to make the "bounding box" zero. Our understanding is that we just want the ellipse to be along x-axis.

We also aligned beam input to BH55 bit better. We used the single bounce beam from aligned ITMY as the reference.

LO phase lock with single RF demodulation

We attempted to lock LO phase with just using BH55 demodulated output.

Configuration:

• ITMX, ETMs were significantly misaligned.
• At BH port, overlapping beams are single bounce back from ITMY and LO beam.

We expected that we would be able to lock to 90 degree LO phase just like DC locking. But now we understand that we can't beat the light with it's own phase modulated sidebands.

The confusion happened because it would work with Michelson at the dark port output of michelson, amplitude modulation is generated at 55 MHz. We tried to do the same thing as was done for DC locking with single bounce  and then michelson, but we should have seen this beforehand. Lesson: Always write down expectation before attempting the lock.

[Chris, Anchal, JC, Paco, Yuta]

We finished all steps upto step 3 without any issue. We restarted all workstations to get the new nfs mount from New Chiara. Some other machined in lab might requrie restart too if they require nfs mounts. Note, c1sus was initially connected using a fiber oneStop cable that tested OK with the teststand IO chassis, but it still did not work with the c1sus chassis, and was reverted to a copper cable.

[Chris, Anchal, JC]

While doing step 4, we realized that all 8 drive bays in the existing fb1 are occupied by disks that are managed by a hardware RAID controller (MegaRAID). All 8 hard disks seem to be combined into a single logical volume, which is then partitioned and appears to the OS as a 2 TB storage device (/dev/sda for OS) and 23.5 TB storage device (/dev/sdb for frames). There was no free drive bay to install our OS drive from fb1 (clone), nor was there any already installed drive that we could identify as an "OS drive" and swap out, without affecting access to the frame data. We tried to boot fb1 with the OS drive from fb1 (clone) using multiple SATA to USB cables, but it was not detected as a bootable drive. We then tried to put the OS drive back in fb1 (clone) and use the clone machine as the 40m framebuilder temporarily, in order to work on booting up fb1 in parallel with the rest of the upgrade. We found that fb1 (clone) would no longer boot from the drive either, as it had apparently lost (or never possessed?) its grub boot loader. The boot loader was reinstalled from the debian 10 install thumbdrive, and then fb1 (clone) booted up and functioned normally, allowing the remainder of the upgrade to go forward.

[Chris, Jamie]

Jamie investigated the situation with the existing fb1, and found that there seem to be additional drive bays inside the fb1 chassis (not accessible from the front panel), in which the new OS disk could be installed and connected to open SATA ports on the motherboard. We can try this possible route to booting up fb1 and restoring access to past frames next week.

[Chris, Anchal]

We carried out the rest of the steps upto 7.3. We started all slow machines, some of them required reloading the daemons using:

We found that we were unable to ssh to c1psl, c1susaux, and c1iscaux. It turned out that chiara (clone) had a very outdated martian host table for the nameserver. Since Chris had introduced some new IPs for IPMI ports, dolphin switch etc, we could not simply copy back from the old chiara. So Chris used diff command to go through all changes and restored DNS configuration.

We were able to burt restore to Oct 7, 03:19 am point using the latest snapshot on New Chiara. All suspensions were being locally damped properly. We restarted megatron and optimus to get nfs mounts. All docker services are running normally, IMC autolocker is working and FF slow PID is working as well. PMC autolocker is also working fine. megatron's autourt cron job is running properly and restarted creating snapshots from 6:19 pm onwards.

Remaining things to do:

• Test basic IFO locking
• Resume BHD commissioning activities.
• Chris and Jamie would work on transfering fb1 job to real fb1. This would restore access to all past frames which is not available right now.
• Eventually, move the new FEs to 1X7 for permanent move into new CDS system.
• After a few weeks of succesful run, we can remove old FEs from racks and associated cables.

[Tega, Anchal]

c1mcs and c1ioo models have been updated to add new acquisition of data.

IOO:WFS channels

We found from https://ldvw.ligo.caltech.edu/ldvw/view that following channels with "WFS" in them are acquired at the sites:

• :IOO-WFS1_IP
• :IOO-WFS1_IY
• :IOO-WFS2_IP
• :IOO-WFS2_IY

These are most probably error signals of WFS1 and WFS2. At 40m, we have following channel names instead:

• C1:IOO-WFS1_I_PIT_OUT
• C1:IOO-WFS1_I_YAW_OUT
• C1:IOO-WFS2_I_PIT_OUT
• C1:IOO-WFS2_I_YAW_OUT

And similar for Q outputs as well. We also have chosen quadrature signals (signals after sensing matrix) at:

• C1:IOO-WFS1_PIT_OUT
• C1:IOO-WFS1_YAW_OUT
• C1:IOO-WFS2_PIT_OUT
• C1:IOO-WFS2_YAW_OUT

We added following testpoints and are acquiruing them at 1024 Hz:

• C1:IOO-WFS1_IP  (same as C1:IOO-WFS1_I_PIT_OUT)
• C1:IOO-WFS1_IY  (same as C1:IOO-WFS1_I_YAW_OUT)
• C1:IOO-WFS2_IP  (same as C1:IOO-WFS2_I_PIT_OUT)
• C1:IOO-WFS2_IY  (same as C1:IOO-WFS2_I_YAW_OUT)

IOO-MC_TRANS

For the transmission QPD at MC2, we found following acquired channels at the site:

• :IOO-MC_TRANS_DC
• :IOO-MC_TRANS_P
• :IOO-MC_TRANS_Y

We created testpoints in c1mcs.mdl to add these channel names and acquire them. Following channels are now available at 1024 Hz:

• C1:IOO-MC_TRANS_DC
• C1:IOO-MC_TRANS_P
• C1:IOO-MC_TRANS_Y

We started acquiring following channels for the 6 error signals at 1024 Hz:

• C1:IOO-WFS1_PIT_IN1
• C1:IOO-WFS1_YAW_IN1
• C1:IOO-WFS2_PIT_IN1
• C1:IOO-WFS2_YAW_IN1
• C1:IOO-MC2_TRANS_PIT_IN1
• C1:IOO-MC2_TRANS_YAW_IN1

We started acquiring following 6 control signals at 1024 Hz as well:

• C1:IOO-MC1_PIT_OUT
• C1:IOO-MC1_YAW_OUT
• C1:IOO-MC2_PIT_OUT
• C1:IOO-MC2_YAW_OUT
• C1:IOO-MC3_PIT_OUT
• C1:IOO-MC3_YAW_OUT

RXA: useful to know that you have to append "_DQ" to all of the channel names above if you want to find them with nds2-client.

Other changes:

In order to get C1:IOO-MC_TRANS_[DC/P/Y], we had to get rid of same named EPICS output channels in the model. These were been acquired at 16 Hz before this way. We then updated medm screens and autolocker config file. For slow outputs of these channels, we are using C1:IOO-MC_TRANS_[PIT/YAW/SUMFILT]_OUTPUT now. We had to restart daqd service for changes to take effect. This can be done by sshing into fb1 and running:

Now there is a convinient button present in FE overview status medm screen to restart DAQD service by a simple click.

[Radhika, Anchal]

We have added an RF amplifier to the output of BH55. See the MICH signal on BH55 outputs as compared to AS55 output on the attached screenshot.

Details:

• Radhika first tried to use ZFL-500-HLN+ amplifier taken out from the amplifier storage along X-arm.
• She used a DB15 breakout board to source the amplifier power from PD interface cable.
• However, she reported no signal at the output.
• We found that BH55 RFPD was not properly fixed tot eh optical table. We bolted it down properly and aligned the beam to the photodiode.
• We still did not see any RF output.
• I took over from Radhika on this issue. I tested the transfer function of the amplifier using moku:lab. I found that it was not amplifying at all.
• I brought in a beanchtop PS and tested the amplifier by powering it directly. It drew 100 mA of current but showed no amplififcation in transfer function. The transfer function was constant at -40 dB with or without the amplifier powered.
• I took out another RF amplifier from the same storage. This time a ZFL-1000-LN. I tested it with both benchtop PS and PD interface power source, it was wokring with 20 dB amplification.
• I completed the installation and cable management. See photos attached.
• I also took the opportunity to center the ITMY oplev.

Please throw away malfunctioning parts or label them malfunctioning before storing them with other parts. If we have to test each and every part before installation, it will waste too much of our time.

WFS loops were running for past 2 hours when I made the overall gain slider zero at:

PDT: 2022-10-18 20:42:53.505256 PDT
UTC: 2022-10-19 03:42:53.505256 UTC
GPS: 1350186191.505256

The output values are fixed to a good alignment. IMC transmission is about 14100 counts right now. I'll turn on the loop tomorrow morning. Data from tonight can be used for monitoing open loop noise.

Turning WFS loops back on at:

PDT: 2022-10-19 09:48:16.956979 PDT
UTC: 2022-10-19 16:48:16.956979 UTC
GPS: 1350233314.956979

After the amplifier was modified with a capacitor, we continued trying to approach locking LO phase to in quadrature with AS beam. Following is a short summary of the efforts:

• To establish some ground, we tested locking MICH using BH55_Q instead of AS55_Q. After amplification, BH55_Q is almost the same level in signal as AS55_Q and a robust lock was possible.
• Then we locked the LO phase using BH55_Q (single RF sideband locking), which locks the homodyne phase angle to 90 degrees. We were able to successfully do this by turning on extra boost at FM2 and FM3 along with FM4 and FM5 that were used to catch lock.
• We also tried locking in a single ITMY bounce configuration. This is a Mach-Zehnder interferometer with PR2 acting as the first beam splitter and BHDBS as the recombination beamsplitter. Note that we failed earlier at this attempt due to the busted demodulation board. This lock worked as well with single RF demodulation using BH55_Q.
• The UGF achieved in the above configurations was ~15 Hz.
• In between and after the above steps, we tried using audio dither + RF sideband, and double demodulation to lock the LO phase but it did not work:
  • We could see a good Audio dither signal at 142.7 Hz on the BH55_Q signal. SNR above 20 was seen.
  • However, on demodulating this signal and transferring all signal to C1:HPC-BH55_Q_DEMOD_I_OUT, we were unable to lock the LO phase.
  • Using xyplot tool, we tried to see the relationship between C1:HPC-BHDC_DIFF_OUT and C1:HPC-BH55_Q_DEMOD_I_OUT. The two signals, according to our theory, should be 90 degrees out of phase and should form an ellipse on XY plot. But what we saw was basically no correlation between the two.
  • Later, I tried one more thing. The comb60 filter on BH55 is not required when using audio dither with it, so I switched it off.
    • I turned off comb60 filters on both BH55_I and BH55_Q filter modules.
    • I set the audio dither to 120 Hz this time to utilize the entire 120 Hz region between 60 Hz and 180 Hz power line peaks.
    • I changed the demodulation low pass filter to 60 Hz Butterworth filter. I tried using 2nd order to lose less phase due to this filter.
    • These steps did not fetch me any different results than before, but I did not get a good time to investigate this further as we moved into CDS upgrade activities.

Following discussion in this elog thread (40/6004), I used the design of F2A (force to angle(pitch)) decoupling filter as mentioned in this DCC doc T010140. This document is very useful as it talks about the overall control loops of a suspension, including sensor signal conditioning, damping filter shapes, force to pitch decoupling, pitch to position decoupling, and coil strength balancing. In future, if people are working on suspension characterization and damping, this document is a good resource to read.

Force to Angle (Pitch) decoupling filter

The document address this problem with first principle calculation using the geometry of single suspensions. As a first pass, I decided to use the design value of these geometric paramters to create a filter design for upper coils and one for lower coils. The parameters are listed in table 2. I used following:

	Description	Value used
L	Vertical dis-tance  from  the  suspension  point  to  the  wire  take-off  point	247.1 mm
h	Pitch distance (distance above the center-of-mass of the wire take-off point)	0.9 mm
l	L + h	248 mm
D	Vertical distance from a magnet to the center of the optic	24.7 mm
Q	Q value used in poles of the filter (doc says to use 1000)	3, 5, 10
	Position resonant angular frequency given by	6.288 rad/s

Using above parameters, we can define the F2A filter for upper coils as:

and for lower coil:

I used the design values as listed in the table above and got the filters as shown in attachment 1 for Q=3 case. I think the Q is higher than what other f2a filters I have seen for example at ETMY, the filters are as shown in attachment 2.

I tried turning on MC1 f2a filters but the watchdog tripped in about 4 minutes. This was the case when WFS were turned off. Another trial also lead to the same result. I tried this on MC2 and MC3 as well, all of them tripped after som time. See attachment 3 to see MC1 tripping on these filters.

I'll now try to use a lower Q filter.

After a quick discussion with Yuta, we figured that the introduction of a finite Q that Peter Fritschel does in this DCC doc T010140 for the poles pair, he should have done the same for the zeros pair as well otherwise there will be a notch at around 1 Hz. So I simply modified the filter design to have same Q for both zero pair and pole pair and got following transfer functions:

For upper coils:

for lower coils:

Attachment 1 shows the new filter design. I tested this filter set on MC1 and the optic kept on going as if nothing changed. That is atleast a good sign. Now next step would be test test if this actually helped in reducing the POS->PIT coupling on MC1, maybe using WFS signals.

The filters were added using this createF2Afilters.py script.