40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 327 of 339  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  16816   Thu Apr 28 09:12:18 2022 AnchalUpdateBHDRestoring arm alignment

This would be a daily first task in the morning. We'll need to check the status of arm alignment and optimize it back to maximum every morning for the rest of the day's work.

Today, when I came, on openin gthe PSL shutter, IMC was aligned good, both arms were flashing but YARM maximum transmission count was around 0.7 (as opposed to 1 from yesterday) and XARM maximum transmission count was 0.5 (as opposed to 1 from yesterday). I did not change the input alignment to the interferometer. I only used ITMY-ETMY to regain flashing count of 1 on YARM and used BS and tehn ITMX-ETMX to regain flashing count of 0.9 to 1 in XARM.

Even thought the oplevs were centered yesterday, I found the oplev had drifted from the center and the optimal position also is different for all ooptics except EMTY and BS. It is worth nothign that in optimal position both PIT and YAW of ITMY and ITMX are off by 70-90 uradians and ETMX Pit oplev is off by 55 uradians.

 

  16817   Thu Apr 28 11:53:10 2022 AnchalSummaryBHDPOP_SM4 and POP_SM5 Assembly

POP_SM4

I tried out this stack today and found some change of plans.

  • The attachment in elog 40m/16640 says to use 1/4-20 silver coated non-vented screws for joining BA2V to PLS-T238, however PLS-T238's bottom hole is a blind hole and is not vented. So we actually required <1 in long silver plated vented 1/4-20 cap screw for this purpose. Jordan and I were only able to find the correct length silver plated screw but it is not vented. So we decided to make a venting hole on the post from the side.
  • I had to use a 0.14" spacer as washer between PLS-T238 and BA1V. The 1" post shim that Koji got for this purpose had too small a hole in the center to let the 8-32 screw pass (I know, weird). but I think we had 3 spare 0.14" ad we bought 10 when we required 7, so we should be good.
  • The attachment in elog 40m/16640 also says to use 8-32 silver coated vented setscrew for joining TR-1.5 to LMR1V mount. I found one vented silver coated set screw nearby in the clean room but it turned out to be too long. Worse, I overtightened the setscrew when trying this connection which damaged the inner threads of one of the LMR1V. So we need to buy one more LMR1V (maybe an additional spare too) for future installation of OMC1R1/OMC2R1.
    • Then Jordan and I searched for a smaller silver coated and vented 8-32 setscrew but didn't find any. Jordan also noted that LMR1V is an aluminium mount and we should not use silver coated setscrew with it. Since the TR-1.5 mount is ok to be sacrificed if a cold weld happens, we'll just use an uncoated SS 8-32 setscrew to join TR-1.5 and LMR1V. We could not such vented setscrews, but we have plenty of non-vented once. So Jordan is going to make a venthole in TR1.5 top end as well. LMR1V already has a vent hole on its side.

tl,dr; Jordan is preparing PLS-T238 and TR-1.5 with venting holes and C&B and they would be ready by tomorrow. I have collected all other parts for assembly, still looking for the mirror but I know other lab members know where it is, so no big issue there.


POP_SM5

The assemly of this mirror is complete. A slight change here as well, we were supposed to use the former POYM1 (Y1-2037-0) mirror for POP_SM5 but I could not find it. It was stored on the right most edge of the table (see 40m/16450), but it is not there anymore. I found another undocumented mirror on the flow bench on the left edge marked (2010 July: Y1-LW1-2037-UV-0-AR) which means this mirror has a wedge of 1 degree and an AR coating as well. We do not need or care about the wedge or AR coating, so we can use this mirror for POP_SM5. Please let me know if someone was saving this mirror for some other purpose.


I'll finish assembly of POP_SM4 tomorrow and install them in ITMX chamber and resurrect POP path.

Quote:

Here is more detail of the POP_SM4 mount assembly.

It's a combination of BA2V + PLS-T238 + BA1V + TR-1.5 + LMR1V + Mirror: CM254-750-E03
Between BA1V and PLS-T238, we have to do a washer action to fix the post (8-32) with a 1/4-20 slot. Maybe we can use a 1" post shim from thorlabs/newport.
Otherwise, we should be able to fasten the other joints with silver-plated screws we already have/ordered.

I think TR-1.5 (and a shim) has not been given to Jordan for C&B. I'll take a look at these.

 

  16818   Thu Apr 28 17:45:53 2022 AnchalUpdateBHDPOX Beam issues

[Anchal, Paco]

We investigated the low power issue with POX11 photodiode.

  • We used a power meter to confirm that above 12 uW of power is reaching the ITMX oplev table.
  • But the power reaching the photodiode was only 3 uW, because the 2 steering mirrors used were discarding half of the light. These mirrors were taken from former POP setup and are probably BS or meant for different incidence angle/polarization.
  • We used flashlight to test that the photodiode gives a response, so it is not dead.
  • We also put in a db15 breakout board in line to the PD and confirmed that power input is correct, temperature is nominal, enable is ON, and DC out is responsive to flashlight.
  • So we decided to redo the path with Y1-45P 1inch mirrors. I found two such mirrors in the lab.
  • When setting up the path again, I realized that the beam shape is not even. I took a photo of the beam on the card (see attachment 1) and indeed the POX beam that is coming to the table is half clipped.
  • So tomorrow, we'll open the chamber and find out where this is happening. For now, I've setup a nominal path to the POX11 photodiode, but we'll tune it after we get a clear POX beam on the table.
Attachment 1: PXL_20220429_002703686.jpg
PXL_20220429_002703686.jpg
  16819   Thu Apr 28 18:07:04 2022 AnchalUpdateBHDRestoring arm alignment at EOD

Restored arm algiment to get 0.8 max flashing on YARM and 1 max flashing on XARM. I had to move input alignment using TT2-PR3 pair and realign YARM cavity axis using ITMY-ETMY pair.

I would like to advertise this useful tool that I've been using for moving cavity axis or input beam direction. It's a simple code that makes your terminal kind of videogame area. It moves two optics together (either in same direction or opposite direction) by arrow key strokes (left, right for YAW, up, down for PIT). Since it moves two optics together, you actually control the cavity axis or input beam angle or position depening on the mode.

 

  16824   Mon May 2 17:51:30 2022 AnchalUpdateBHDPOX Beam aligned on RFPD, YARM locked

[Paco, Anchal]

We found that one of the Y1-1037-45P marked mirror that we used was actually curved. So we removed it and used a different Y1-1037-45P mirror, adjusted the position of the lens and got the beam to land on POX11 RFPD successfully.

Then in control room, we maximized the POX11_I_ERR PDH signal amplitude by changing C1:LSC-POX11_PHASE_R to 42.95 from -67.7. We kept the C1:LSC-POX11_PHASE_D same at 90. We were getting +/- 200 PDH signal on POX_I_ERR.

Then in our attempt to lock the XARM, when we ran the "Restore XARM (POX)" script, YARM locked!

We are not sure why the YARM locked, we might have gotten lucky today. So we ran ASS on YARM and got the transmission (TRY_OUT) stable at 1. The lock is very robust and retrievable.

Coming back to XARM, we realized that the transmission photodiode used for XARM was the low-gain QPD instead of the thorlabs high gain photodiode. The high-gain photodiode was outputing large negative counts for some reason. We went to the Xend to investigate and found that the high gain photodiode was disconnected for some reason. Does anyone know/remember why we disconnected this photodiode?

We connected the photodiode back and it seems to work normally. We changed the photodiode selection back to high gain photodiode for TRX and on 40 dB attenuation, we see flashing between 1.4 to 1.6. However, we were unable to lock the XARM. We tried changing the gain of the loop, played a little bit with the trigger levels etc but couldn't get it to lock. Next shift team, please try to lock XARM.

Quote:

[Paco, Anchal, Yuta]

We opened the BSC and ITMX chamber in the morning (Friday) to investigate POX11 beam clipping. We immediately found that the POX11 beam was clipping by the recently installed cable posts, so luckily no major realingment had to be done after reinstalling the cable post in a better location.


Because we had the BSC open, we decided to steer the AS1 mirror to align the AS path from ITMY all the way to the vertex chamber.  Relatively small AS1 offsets (of ~ 2000 counts each) were added on PIT / YAW to center the beam on ASL (there is slight clipping along PIT, potentially because of the AS2 aperture. We then opened the vertex chamber and located the AS beam with relative ease. We decided to work on this chamber, since major changes propagate heavily downstream (simply changing the IMC pointing).

Anchal removed old optics from the vertex chamber and we installed the steering pair of mirrors for AS path. This changed the balance of the vertex table by a lot. By using the MC REFL camera beam spot we managed to coarsely balance the counterweights and recover the nominal IMC injection pointing. Simply reenabling the IMC autolocker gave us high transmission (~ 970 counts out of the typical 1200 these days).

The final IMC alignment was done by Anchal with delicate PIT motion on the input injection IMC miror to maximize the transmission (to our satisfaction, Anchal's motion was fine enough to keep the IMC locked). The end result was quite satisfying, as we recovered ~ 1200 counts of MC transmission.

Finally, we looked at the arm cavity transmission to see if we were lucky enough to see flashing. After not seeing it, we adjusted TT1 / TT2 to correct for any MMTT1 pitch adjustment needed after the vertex table rebalancing. Suprisingly, we didn't take too long and recovered the nominal arm cavity pointing after a little adjustment. We stopped here, but now the vertex table layout is final, and AS beam still needs to be aligned to the vertex in-air table.

 

  16826   Tue May 3 14:02:09 2022 AnchalSummaryBHDInstalled POP path in ITMX Chamber

[Anchal, JC]

I installed POP_SM4 and POP_SM5 in the ITMX chamber in the nominal positions. This must have affected the ITMX Oplev because I could see that one of the ITMX oplev beam was going through POP_SM5. It needs to be changed in order to follow the original plan. However, since POP_SM5 is a 1064 line mirror, it is transparent to the opleve beam, so maybe we can just use the ITMX oplev in the current fashion.

Next steps:

  • Get flashing back on the XARM.
  • Try to get the correct phase angle in POX11 so that we can lock XARM with IR too.
  • Inspect ITMX Oplev. The quadrant sum is low so maybe it needs adjustment in the in-ar table.
  • Check if ITMX oplev path needs to be adjusted inside the chamber.
  16829   Wed May 4 13:09:42 2022 AnchalUpdateBHDIMC table balanced again, IMC is locking, YARM is locking

[Paco, JC, Anchal]

We balanced the IMC table back again to point that got us 50% of nominal transmission from IMC. Then we tweaked the steering mirror for injection to IMC to get up to 90% of nominal transmission. Finally, we used WFS servo loop to get to the 100% nominal transmission from IMC. However, we found that the WFS loop has been compromised now. It eventually misaligns IMC if left running for a few minutes. This needs to be investigated and fixed.

Next steps:

  • Align X-arm cavity and regain flashing.
  • Fix the Oplev path for ITMX.
  • Tune POX11 phase angle to get an error signal with which we can lock the cavity.
  • Finish AS beam path setup.
  16832   Thu May 5 14:46:22 2022 AnchalUpdateBHDPOP beam height lowered, POP_SM4 raised

[Anchal, JC]

We first aligned the single arm cavity resonance for both arms to get maximum flashing. As we opened the chamber, I found that the POP beam was mostly hitting the POP_SM4 mirror but was clipping about 2 mm on the top edge.

I used TT2-PR3 to lower the injection beam angle and moved pairs of ITMY-ETMY, and ITMX-ETMX to recover as much flashing as I could in the both arms. Then, I moved PR2 in pitch from 49 to 71 to maximize the arm flashing again. After these steps, the POP beam was clearly within the POP_SM4 mirror but still in the upper half of the optic and there was maybe just a mm of clearance from the top edge. I decided to raise POP_SM4 mirror by 0.14" spacer. Now the beam is still in upper half of the mirror but has a good clearance from the edge.

The POP beam is coming outside in the in-air table at as a rising beam in the nominal path near the center of the window. This beam needs to be directed to the POP camera and RFPD on the far-side of the table.

Next steps:

  • In-air table work: Setup POP camera and RFPD.
  • In ITMX chamber, rotate ITMX Oplev mirror to clear the oplev beam off POP_SM5. Change oplev beam path outside accordingly.
  • Install green transmission from X-arm steering mirrors in BS chamber.
  • Install 4 steering mirrors in ITMY chamber at the two outputs of BHD BS to direct the beam outside.
  • Figure out POX11 rotation angle and get XARM locking as well.

 

  16835   Fri May 6 13:48:34 2022 AnchalUpdateBHDWFS loop instability fixed

[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.
  16837   Mon May 9 18:43:03 2022 AnchalUpdateBHDITMX table layout corrected

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.

 

 

  16849   Thu May 12 20:11:18 2022 AnchalUpdateBHDBHDBS Output beams steered out to ITMY table

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.
Attachment 1: signal-2022-05-12-201844.jpeg
signal-2022-05-12-201844.jpeg
  16854   Mon May 16 10:49:01 2022 AnchalUpdateDAQDAQ troubleshooting

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

  16859   Mon May 16 19:14:17 2022 AnchalUpdateBHDCamera set on AS path and BHDBS output path

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

 

  16860   Tue May 17 18:43:38 2022 AnchalUpdateBHDPlaced SRM in ITMY Chamber

[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.
  16862   Wed May 18 09:02:52 2022 AnchalUpdateBHDWFS1 PD centered

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

 

  16863   Wed May 18 17:23:15 2022 AnchalUpdateBHDPlaced PRM in BS Chamber

[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.
  16866   Thu May 19 19:05:59 2022 AnchalUpdateBHDBS Chamber all work finished, BHD path setup

[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.
  16872   Tue May 24 15:21:13 2022 AnchalUpdateBHDFreeswing tests of new SOS started

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.

  16899   Tue Jun 7 19:40:45 2022 AnchalUpdateSUSITMY changed output matrix to disable use of UL coil

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:

  POS PIT YAW SIDE
UL 0 0 0 0
UR 1 1 0 0
LL 1 0 1 0
LR 0 -1 -1 0
SIDE 0 0 0 1

 

 

 

 

 

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.

Attachment 1: ITMY_PIT_to_POS-PIT-YAW_Coupling.pdf
ITMY_PIT_to_POS-PIT-YAW_Coupling.pdf
Attachment 2: ITMY_YAW_to_POS-PIT-YAW_Coupling.pdf
ITMY_YAW_to_POS-PIT-YAW_Coupling.pdf
  16913   Tue Jun 14 18:45:43 2022 AnchalUpdateSUSLO2 lower magnets are stuck in coil, won't come off

[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. sad

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?

  16915   Tue Jun 14 20:57:15 2022 AnchalUpdateASCYarm ASS working now

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

 

  16925   Thu Jun 16 18:30:07 2022 AnchalUpdateSUSNew diagonalized input matrices applied

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

Attachment 1: SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf
SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf SUSInpMatDiag_MC1_MC2_MC3_BS_IMTX_ETMX_ETMY_AS1_AS4_SR2_PR2_PR3.pdf
  16931   Tue Jun 21 08:36:50 2022 AnchalUpdateSUSDiagonalized input matrices for LO1, freeSwing on ITMY and ITMX

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.


Attachment 1: SUSInpMatDiag_LO1.pdf
SUSInpMatDiag_LO1.pdf
  16938   Wed Jun 22 14:44:03 2022 AnchalUpdateBHDFixed DC error in c1su2, added new library model for suspensions

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.

  16946   Sat Jun 25 14:29:48 2022 AnchalUpdateIOOWFS issues

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.

  16957   Tue Jun 28 17:07:47 2022 AnchalUpdateCalibrationAdded Beatnote channels in demodulation of c1cal

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.

  17010   Mon Jul 18 04:42:54 2022 AnchalUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

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

Let \overrightarrow{\Theta} be set of astrophysical parameters (like component masses, distance etc), \overrightarrow{\Lambda}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 h(f; \overrightarrow{\Theta}), and the detector transfer function is given by \mathcal{R}(f; \overrightarrow{\Lambda}), then the detected gravitational waveform becomes:
g(f; \Theta, \Lambda) = \frac{\mathcal{R}(f; \overrightarrow{\Lambda_t})}{\mathcal{R}(f; \overrightarrow{\Lambda})} h(f; \overrightarrow{\Theta})

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

\Gamma_{ij} = \left( \frac{\partial g}{\partial \mu_i} | \frac{\partial g}{\partial \mu_j}\right )

where the bracket denotes iner product defined as:

\left( k_1 | k_2 \right) = 4 Re \left( \int df \frac{k_1(f)^* k_2(f))}{S_{det}(f)}\right)

where S_{det}(f) is strain noise PSD of the detector.

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

\frac{\Delta \Theta_j}{\Theta_j} = - \mathbf{H}^{-1} \mathbf{M} \frac{\Delta \Lambda_j}{\Lambda_j}

where \mathbf{H}_{ij} = \left( \frac{\partial g}{\partial \Theta_i} | \frac{\partial g}{\partial \Theta_j}\right ) and \mathbf{M}_{ij} = \left( \frac{\partial g}{\partial \Lambda_i} | \frac{\partial g}{\partial \Theta_j}\right ).


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 \tilde{\Lambda} 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

Attachment 1: BNSparamsErrorwrtfdError-merged.pdf
BNSparamsErrorwrtfdError-merged.pdf BNSparamsErrorwrtfdError-merged.pdf
Attachment 2: BBHparamsErrorwrtfdError-merged.pdf
BBHparamsErrorwrtfdError-merged.pdf BBHparamsErrorwrtfdError-merged.pdf
Attachment 3: BNSparamsEPSwrtCalError.pdf
BNSparamsEPSwrtCalError.pdf
Attachment 4: BBHparamsEPSwrtCalError.pdf
BBHparamsEPSwrtCalError.pdf
  17016   Mon Jul 18 21:41:42 2022 AnchalSummaryLSCFPMI locking procedure using REFL55 and AS55

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.

  17017   Tue Jul 19 07:34:46 2022 AnchalUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

Addressing the comments as numbered:

  1. Yeah, that's correct, that equation normally \Delta \Theta = -\mathbf{H}^{-1} \mathbf{M} \Delta \Lambda but it is different if I define \Gamma bit differently that I did in the code, correct my definition of \Gamma to :
    \Gamma_{ij} = \mu_i \mu_j \left( \frac{\partial g}{\partial \mu_i} | \frac{\partial g}{\partial \mu_j} \right )
    then the relation between fractional errors of detector parameter and astrophysical parameters is:
    \frac{\Delta \Theta}{\Theta} = - \mathbf{H}^{-1} \mathbf{M} \frac{\Delta \Lambda}{\Lambda}
    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 M_c 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 f_{gw} must be the lowest frequency that comes within the detection band during inspiral. This function is:
      t_c = \frac{5}{256 \pi^{8/3}} \left(\frac{c^3}{G M_c}\right)^{5/3} f_{gw}^{-8/3}
      For my calculations, I've taken f_{gw} 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:
      f_{gw}(t) = \left( f_{gw0}^{-8/3} - \frac{768}{15} \pi^{8/3} \left(\frac{G M_c}{c^3}\right)^{5/3} t \right)^{-3/8}
      where f_{gw0} is the frequency at t=0. I integrated this frequency evolution for t_c time to get the coalescence phase phi_c as:
      \phi_c = \int^{t_c}_0 2 \pi f_{gw}(t) dt
  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.
Quote:

1. In the error propogation equation, it should be \Delta \Theta = -H^{-1} M \Delta \Lambda, instead of the fractional error. 

2. For the astro parameters, in general you would need t_c for the time of coalescence and \phi_c for the phase. See, e.g., https://ui.adsabs.harvard.edu/abs/1994PhRvD..49.2658C/abstract.

3. Fig. 1 looks very nice to me, yet I don't understand Fig. 3... Why would phase or amplitude uncertainties at 30 Hz affect the tidal deformability? The tide should be visible only > 500 Hz.

4. For BBH, we don't measure individual spin well but only their mass-weighted sum, \chi_eff = (m_1*a_1 + m_2*a_2)/(m_1 + m_2). If you treat S1z and S2z as free parameters, your matrix is likely degenerate. Might want to double-check. Also, for a BBH, you don't need to extend the signal much higher than \omega ~ 0.4/M_tot ~ 10^4 Hz * (Ms/M_tot). So if the total mass is ~ 100 Ms, then the highest frequency should be ~ 100 Hz. Above this number there is no signal.

 

Attachment 1: BNSparamsErrorwrtfdError.pdf
BNSparamsErrorwrtfdError.pdf BNSparamsErrorwrtfdError.pdf
Attachment 2: BBHparamsErrorwrtfdError.pdf
BBHparamsErrorwrtfdError.pdf BBHparamsErrorwrtfdError.pdf
Attachment 3: BNSparamsEPSwrtCalError.pdf
BNSparamsEPSwrtCalError.pdf
Attachment 4: BBHparamsEPSwrtCalError.pdf
BBHparamsEPSwrtCalError.pdf
  17045   Thu Jul 28 20:16:26 2022 AnchalUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

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.
  17049   Sat Jul 30 10:38:12 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

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:

-------------------------------------------------------------------------
This computer runs four services as of Feb 18, 2022 for 40m lab. To check
status of these services, type
> sudo docker ps
For restarting a particular service, type:
> sudo docker restart container_name
where container name can be found from ps command above.
Fimilarly, to check status of a service, type:
> sudo docker logs container_name

In case, you have just rebooted the machine, to start these services do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose up -d
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose up -d

To stop the docker services completely, for example before a reboot, do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose down
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose down

This should remove all active containers from the computer.

To check IP address of running containers, type:
> sudo docker inspect -f '|| {{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}   ||   {{.Name}} ||' $(sudo docker ps -aq)

The softchansmodbus directory runs modbusEPICS docker image to host some
useful soft EPICS channels. The scripts directory runs pyep docker
image to run MC autolocker, PMC autolocker and FSS PID locker.
-------------------------------------------------------------------------

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

sudo docker logs scritps_AL_MC_1

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

sudo docker logs scripts_PID_

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:

sudo docker stop container_name

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:

sudo docker restart container_name

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:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

For MC autolocker:

sudo systemctl enable MCautolocker
sudo systemctl restart MCautolocker

For diabling these services again, do:

sudo systemctl stop FSSSlow
sudo systemctl disable FSSSlow
sudo systemctl stop MCautolocker
sudo systemctl disable MCautolocker

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.

  17057   Thu Aug 4 11:28:22 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

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.

  5243   Mon Aug 15 21:43:29 2011 Anamaria and KeikoSummaryLockingcentral part ifo locking project

 REFL33 and REFL165 cables were connected from the AP table to the rack.  Cables on the rack for REFL33I, 33Q, 165I, 165Q ports were connected, too. Connections were confirmed by the data viewer. Two SMA cables which will be used for the two PDs on the AP tabl were built. We will be able to place the two PDs tomorrow. The beamsplitters to split the laser to REFL33 and REFL165 ports were mounted and ready to be placed.

  5249   Tue Aug 16 16:59:20 2011 AnamariaUpdateRF SystemAM in the PM

Kiwamu, Keiko, Anamaria

Looking at the I and Q signals coming from REFL11 and REFL55 we saw large offsets, which would mean we have amplitude modulation, especially at 11MHz. We checked the PD themselves with RF spectrum analyzer, and at their frequencies we see stationary peaks (even if we look only at direct reflection from PRM). We changed the attenuation of the PSL EOM, and saw the peak go down. So first check is beam out of PSL EOM, to make sure the input beam is aligned to the crystal axis and is not giving AM modulation in adition to PM.

  5255   Wed Aug 17 15:47:18 2011 AnamariaUpdateSUSETMX Side Sensor slow channel down for a long time

Jenne, Anamaria

We aligned the ETMX OSEMs and ran into this issue. Looking at the SENSOR_SIDE channel, we pulled out the OSEM and determined that the open light voltage is 874 counts, so we centered it around 440 as well as we could. This is same channel as its slow counterpart SDSEN_OUTPUT (grey number immediately to the right on SUS medms).

 

 

Quote:

The slow signal from the side sensor on ETMX was last seen in action sometime in May 2010!  And then the frame builder has no data for a while on this channel.  After that the channel shows some bistability starting Sept 2010 but has not been working.  The fast channel of this sensor  (C1:SUS-ETMX_SDSEN_OUTPUT) does work so the sensor is working.  Probably is a loose contact... needs to be fixed.

 

 

  5278   Mon Aug 22 20:37:43 2011 AnamariaConfigurationRF SystemPlan for install of 3f PDs

I made a quick sketch of how to include two more RF PDs on the REFL beam, given the space we have on the table. We want to install REFL33 and REFL165, 3f signals for the the two modulation frequencies we are using. The point is to make the distance from first beam splitter the same to all PDs so that we can use only one lens before this BS to make the beam the right size. Currently there are 2 PDs on the refl beam, REFL11 and REFL55, predictably. So the drawing shows 4 PDs. Drawing is to scale but is a bit coarse. Hopefully we'll take pictures once we're done.

Reference from current BS splitting beam to the existing PDs.

Attachment 1: 40m3fReflPdLayout.pdf
40m3fReflPdLayout.pdf
  5284   Tue Aug 23 06:49:24 2011 AnamariaUpdateGeneralmore in-vac work : AS clipping fixed and OSEM/oplev adjustment

Where was the AS clipping?! Ah, the suspense...

Quote:

  + fixed the AS clipping issue

 

Quote from #5275

We need to check/fix the AS beam clipping and once it's done we will readjust the OSEM mid range and the oplevs.

 

 

 

  5389   Mon Sep 12 18:45:04 2011 AnamariaConfigurationLSCAP table current layout

Before we install the REFL 3f PDs I made a drawing of the current table layout, since there has been no update lately. Once I've incorporated the two extra PDs (now seen sitting bottom left), I will update the drawing and post in the wiki as well.

Attachment 1: 40mAPtable.pdf
40mAPtable.pdf
  5401   Wed Sep 14 01:19:20 2011 AnamariaConfigurationLSC3f PD Install in Progress

I have reconfigured the refl beam path on the AP table to include REFL33 and REFL165. Would be done if we hadn't prepared P BSs instead of S, which required some serious digging to find two others. And if someone hadn't stolen our two 3m SMA cables that Keiko and I made on our previous visit and I had left with the 3f PDs. I don't expect them to reappear but if they do, it would be grand.

Note: Refl beam from ifo looks a bit high, ~1cm on the lens 20'' from output port. Not sure what that means about ifo alignment change, I've left it as is. When we know we have a good alignment, we should be able to easily realign the beam path if necessary. If it remains the same, we might want to change the lens height.

Done:

1) REFL11 and REFL55 are now hooked up and aligned in a low power beam. (I set the power as low as I could by eye to not risk burning the PDs during alignment)

2) The required BSs and REFL33 and REFL165 are in place, powered.

3) I have set them in a configuration such that the beam is the same distance from the main beam, to adjust beam size easily for all 4.

4) Camera has been moved from main beam to behind a steering mirror, ND filters removed, centered on camera.

To Do:

1) Find one more longish SMA cable.

2) Align beam on REFL33 and REFL165.

3) Check beam size carefully. (I get a plateau on the scope, and I can "hide" the beam on the PD, but it could be better. The path has become longer by ~5-8inches.)

4) Adjust power.

5) Redo layout diagram, post in wiki.

  5414   Thu Sep 15 02:18:19 2011 AnamariaUpdateLSCMICH locked and attempt to lock PRCL

Kiwamu, Keiko, Anamaria

 

We were able to lock PRC using REFL11I after improving the MICH dark fringe a bit (moving BS) and rotating AS55 and REFL11 such that the signal was maximized in the phases we were using. The dark port is not so dark... but the lock is stable.

I had finished the whole REFL path alignment, but I didn't have a good input beam reference at the time, which is why we had to realign the PDs and the camera. We only had strength to realign 11 and 55. Otherwise, we just need to tweak and center beam on 33 and 165, figure out what's up with 55 and be done with the AP table mods. I hope.

 

Quote:

 Anamaria, Keiko

- We aligned MICH and were successfully locked MICH using AS55Q. The other mirrors were misaligned so that the other degrees of freedom didn't exist. AS55 was fed back to BS. The f2a filters on BS suspension were required to lock, because the pos feedback was unbalanced to angle degrees of freedom.

- We tried to lock PRCL next, however, because we aligned the MICH and the REFL beam paths were changed, REFL PDs didn't have the light anymore. The REFL paths were modified now, so we will try the PRCL locking next.

- We couldn't confirm REFL55 signals although we alined the REFL paths to REFL55 PD.

 

  5430   Fri Sep 16 03:22:11 2011 AnamariaUpdateLSCMore Refl PDs Work and Attempt at DRMI

Kiwamu, Keiko, Anamaria

I started today with a different input beam, so I had to realign the REFL path again. Then we measured the RF signal out of the 4 REFL PDs and found them to be too low. We increased the power to around 10mA for each diode, and we can see the right modulation frequency on each diode, though REFL165 is way too weak so we might need an RF amplifier on it. We will measure demod board noise tomorrow.

We had an issue with REFL165 not giving the right DC level, low by a factor of 10, even though it was receiving the same optical power as the others. We fifteen-checked clipping and alignment, then pulled it out and measured it on the test stand - found it to be ok. So I uplugged its power cable at the rack and connected it to the AS165 slot. Problem sloved. Not sure what was wrong with the other power slot.

Then we found REFL55 to be clipping on its black glass, we fixed that. But the REFL55 DC power still changes a lot with seemingly not huge motions of the PRM. We'll investigate more tomorrow.

We added a lens in the path to REFL165 because unlike the others it is a 1mm diode. All diodes have about half a turn to a full turn flatness of maximum (on tiny steering mirror).

We set the whitening gain on all four diodes to 21 db.

Not sure if we should set the power to be different on these diodes since their sensitivity is different to RF, and now REFL11 sees huge signal.

We continued the DRMI locking attempt and brought in the SRC, using AS55I to control it. It kind of works/stays locked. We did manage to get MICH and PRC better controlled than last night, but with SRC in the mix, something is wrong. We have to redo f2a filters on SRM and hopefully things will be better after Jenne's suspension work tomorrow. Oplevs not optimized yet either.

We intend to realign POY beam path so we can monitor power in cavities.

  5475   Tue Sep 20 03:12:14 2011 AnamariaUpdateSUSJenne's Scripts started

I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.

  5489   Tue Sep 20 20:58:35 2011 AnamariaConfigurationLSCNew AP Table Drawing

As promised, I have made a final AP table drawing, including the MC camera relocation changes by Kiwamu. I have posted it in the wiki on the tables list, and on the AP table page I've attached the inkscape .svg I used to make it, if someone needs to do small modifications.

Attached is a pdf version of it.

Big changes:

1) REFL beam has been split into 4, to go in equal powers and equal beam size to the now 4 REFL RFPDs, 11, 33, 55 and 165. A lens had to be added for REFL165 because it's a 1mm PD instead of 2mm like the other 3.

2) MC camera has moved.

3) I've cleaned up most of the random components on the table, put them away, and tidied up the cabling.

 

Attachment 1: APtableSep20th.pdf
APtableSep20th.pdf
  5513   Thu Sep 22 04:49:14 2011 AnamariaUpdateLSCLocking status update - Some Scripts, No Louck

The scripts I wrote can be found in /users/anamaria/scripts/sensemat/

]There are two of them:

- one that sets all the switches, gains, frequencies, etc, then cycles through the various RFPDs I and Q into the LOCKIN signal, so as to see the sensing matrix.

- the second one is a matlab script that takes the crappy file tdsavg outputs and makes it into a cute mag/phase matrix.

They're quite primitive at this point, I've forgotten a lot of tcsh... may improve later. But could be useful later to someone else at least.

I don't think it's particularly the fault of the script that we can't measure the sensing matrix. We can slam on the excitation by hand, and it holds for a little while. I set a wait time for lock to adjust, and most times it just oscillates a bit for a few seconds. Also, the script turns on the excitation and it's done, the rest is just measurement, then turns it off at the end. So during the script, there's not much to deal with, except keeping the lowpass filters quiet when switching the signal to demod; but that doesn't go anywhere, so it definitely doesn't disturb the ifo. Turns out pressing the RSET clear history button needs a 2 to make it happen.

I think I might prefer to set the excitation to run, and then do the old retrieve-data-later-nds-matlab thing. I do not trust these measurements without coherence and a bit of variance study, given instabilities.

Point is... Even on carrier, the PRC lock is not stable by any means. Can barely turn on low freq boosts, every other lock. Until we fix the lock stability issue, there's not much to measure I guess.

Unfortunately, I don't know how to make that happen. Before we leave on Friday we could do a few sanity checks such as measuring the noise of the RFPDs vs ADC+whitening, which I may have said I would do; and perhaps setting up a couple OSAs, one on REFL, one on AS, to make sure we know what the sidebands are doing. Both of which Rana suggested at some point.

(There used to be a quote here from Keiko here but I got mad when it reformated my entire log to be one cluster- hence the look)

  5525   Thu Sep 22 22:55:01 2011 AnamariaUpdateLSCPOX channel = POY PD connected + Bad Rack

Keiko, Anamaria

We decided we needed a DC channel to sense the gain in the PRC, so we set to align POY55. It took a while because the beam was very weak, and it comes in upwards, so we used a couple of mirrors to bring to a reasonable flat level, and put it on the PD. Then we went to read the DC out and we got 1.3V stationary! Nonsense. We also realized there is no LO for this PD, or any other 55MHz PD, aside from REFL55. Oh well, we only wanted the DC for now. POY55 is aligned (decently).

Koji told me to try swapping the power cable, so I unplugged it at the rack and plugged it in another power card. And it worked! I then moved the DC out (back of rack) to follow the front, and it turns out POY55 diode is read on the POXDC channel. I plugged and unplugged it in disbelief, but it is what it is. At least we have a readout on the power level in PRC.

I attach a picture of the power cards for the LSC RFPDs, with the 3 I found to be bad, and showing current config. I had to move REFL11 and POY55 from their assigned spot.

The two on the lower left are bad in the sense that they put an offset on the PD and make the DC readout be 1.3V for no reason (when working, for example, POY55 read 60mV). The one on the lower right I had trouble with some time ago, it made the PD not read any voltage at all (when working it would read at least 100mV). Beyond that I have not investigated what is up, since I could find working plugins.

Attachment 1: RFPDpowerRack2.pdf
RFPDpowerRack2.pdf
  5545   Mon Sep 26 15:15:45 2011 AnamariaUpdateLSCRealignment of REFL / Some 3f PRMI locking / Recycling Gain

A few comments on REFL table alignment and REFL165.

Last time we realigned the table was after the PZT work by Koji/Kiwamu; we made sure that the beam was going through optics satisfactorily and that we were reading reasonable numbers. I did use primarily a viewer to align onto PD, after which we used the voltage reading to center better around that spot. As desired, I could not see the beam once it was centered on the PD. I never touched the PBS unfortunately, so I never noticed it was not fixed. Sad.

I am very surprised to hear the reading from REFL165, since I was reading around 400mV from it a few days before. Something strange happened in the mean time. I hope not when I was plugging and unplugging at the power rack for the POY work. But I would not have needed to touch REFL165. Those cables should get some strain relief at the rack, by the way.

I thought about it, and I must admit that after we centered camera on REFL (paired with an alignment), we did not check the beam path later, even after we saw that the REFL beam had moved. We only did a quick by-viewer check that the beams were not off of the PDs.

Quote:

[Koji Suresh]

- The REFL path has been thoroughly aligned
Many optics had the spots not on the middle of the optic, including the PBS whose post was not fixed on the post holder.
We aligned the optical paths, the RF PDs, and the CCD. The alignment of the PD required the use of the IR viewer.
One should not trust the DC output as a reference of the PD alignment as it is not enough sensitive to the clipping.

We aligned the optical paths again after the reasonable alignment of PRM is established with the interferometer.
"Next time when you see REFL spot is not at the center of the camera, think what is moved!"

- The REFL165 PD is disconnected from the power supply
I found that the REFL165 PD is producing 7.5V output at the DC monitor no matter how the beam is blocked.
As I could not recover this issue by swapping the power connector at the LSC rack, I disconnected the cable
at the RFL165 PD side. I need to go through the PD power supply circuit next week.

 

  7146   Fri Aug 10 17:17:41 2012 Alex Masha DenUpdatePEMclassify seismic c code

Den and I installed a module in the c1pem model which has a feedforward neural network to classify seismic disturbance (10 means quiet, 20 truck, 30 earthquake). There is a channel SEIS_CLASS which should specify the class of the seismic signal. The code works for signals sampled at 256 Hz, so an anti-aliasing filter must be installed in order to decimate from the 2048 model.

The models were compiling slowly, so Alex removed the archiving feature (gzip and tar were taking a lot of time).

Den and I also had trouble with a simple for loop in our model, so we talked to Alex who noted that the -O3 compiler unravels for loops in a buggy way. Thus, we have compiled c1pem using the -O compiler.

PS: the Trilium seismometer now has legs.

  2075   Fri Oct 9 14:23:53 2009 Alex IvanovConfigurationDAQtpchn mystery

"Yes. This master file is used."

Quote:

Does anyone know if this master file is the real thing that's in use now? Are we really using a file called tpchn_C1_new.par? If anyone sees Alex, please get to the bottom of this.

allegra:daq>pwd
/cvs/cds/caltech/chans/daq
allegra:daq>more master
/cvs/cds/caltech/chans/daq/C1ADCU_PEM.ini
#/cvs/cds/caltech/chans/daq/C1ADCU_SUS.ini
/cvs/cds/caltech/chans/daq/C1LSC.ini
/cvs/cds/caltech/chans/daq/C1ASC.ini
/cvs/cds/caltech/chans/daq/C1SOS.ini
/cvs/cds/caltech/chans/daq/C1SUS_EX.ini
/cvs/cds/caltech/chans/daq/C1SUS_EY.ini
/cvs/cds/caltech/chans/daq/C1SUS1.ini
/cvs/cds/caltech/chans/daq/C1SUS2.ini
#/cvs/cds/caltech/chans/daq/C1SUS4.ini
/cvs/cds/caltech/chans/daq/C1IOOF.ini
/cvs/cds/caltech/chans/daq/C1IOO.ini
/cvs/cds/caltech/chans/daq/C0GDS.ini
/cvs/cds/caltech/chans/daq/C0EDCU.ini
/cvs/cds/caltech/chans/daq/C1OMC.ini
/cvs/cds/caltech/chans/daq/C1ASS.ini
/cvs/cds/gds/param/tpchn_C1_new.par
/cvs/cds/gds/param/tpchn_C2.par
/cvs/cds/gds/param/tpchn_C3.par

 

  4779   Thu Jun 2 10:19:37 2011 Alex IvanovSummaryDAQinstalled new daqd (frame builder) program on fb (target/fb/daqd)

I hope that new daqd code will fix the problem with non-aligned at 16 seconds frame file GPS times.

I have compiled new daqd program under /opt/rtcds/caltech/c1/core/release/build/mx and installed it under

target/fb/daqd, then restarted daqd process on "fb" computer. It was installed with the ownership of user root

and I did chmod +s on it (set UID on execution bit). This was done in order to turn on some code to renice daqd process

to the value of -20 on the startup. Currently it runs as the lowest nice value (high priority).

 

controls@fb /opt/rtcds/caltech/c1/target/fb $ ls -alt daqd
-rwsr-sr-x 1 root controls 6592694 Jun  2 10:00 daqd

 

Backup daqd is here:

 

controls@fb /opt/rtcds/caltech/c1/target/fb $ ls -alt daqd.02jun11
-rwxr-xr-x 1 controls controls 6768158 Feb 21 11:30 daqd.02jun11

 

 

  6094   Fri Dec 9 14:33:16 2011 Alex IvanovUpdateAdaptive FilteringC1OAF

Quote:

I tried to figure out why red NO SYNC label became present in the C1OAF_GDS_TP screen after I added AA filters to the C1OAF model.

C1OAF model contains 8 libraries C1OAF_ADAPT for 8 DOF. I changed C1OAF_ADAPT library to C1OAF_ADAPT_AA library where I added 28 AA filters for 28 witness channels. It turns out that if I use this library for all 8 DOF then I see NO SYNC label, if only for one DOF (MCL) then I see green IOP label. This means that using AA filters for each DOF too much channels of filters are created for online system to operate. I think there is some number inside the code that one can not exceed. Analyzing compilation output after "make c1oaf" I figured out that without using AA filters we have 632 filters and using AA we have 856 filters.

For now I'll use AA filters for MCL only.

 I have a feeling we are not fitting into pre-allocated memory space in the shared memory between the front-end process and the epics process. Filter module data is overwriting some other data and that's why we are not getting a sync light. I suggest we upgrade to 2.4 code first and then we will figure out a way to expand memory areas to fit 856 filters.

ELOG V3.1.3-