(Alexa, Daniel)

With the gain setting at 0dB for the external PD:

Transimpedance = 2kOhm

Ext PD Monitor = 1.28V

Beckhoff readback = 5.17V (there is a 4x gain between the monitor and controls output)

If the external PD is a silicon diode (responsitivty = .25A/W), this implies that we have 2.6mW on the diode. Alternatively, if we believe that we have ~1mW on the diode as referenced in alog, then the responsitivty of the diode is closer to .64A/W, which resembles that of an in-gas diode. The former is more likely.  **** Next time someone is in the PSL, can you please measure the power into the diode?

Meanwhile, I also confirmed that the gain setting on the ALS fiber distribution chassis is as expected. At the ext. PD input, I read -5.0V. Placing 100kOhm resistor at the input provides 50uA of current. Thus, one expects to read V=(50uA)(2kOhm) = 100mW at the ext PD monitor, which I verified. This is consistent with the test report for this chassis, which confirmed 3.13V at 30dB with 50uA. The factor for 30dB gives a factor of 31.26 in V.

Conclusion: ALS fiber distribution is okay. Diode is different than expected or we have more power ...

Starting at around noon, the QPD servos at end Y are running, we will leave this alone for about a day, then turn off a cleanroom to see if we have a repeat of the alingment drifts seen in end Y.

Before starting I moved the TMS  with the QPD servos locked, here are the responses in the PZT sensors and outputs:

Moving the TMS in yaw moves the PZT pit, and vice versa

for reference the times are:

nominal TMS positions PIT -3urad, Yaw -297urad UTC 18:45:35

PIT -3 urad YAW -197 urad  UTC 18:50

PIT -103 urad YAW -297 UTC 18:54:51

transissioning to level 2 I get

   Isolating 4 dofs: X Y RZ HP
   Using filter module(s): H1:HPI-BS_ISO_X H1:HPI-BS_ISO_Y H1:HPI-BS_ISO_RZ H1:HPI-BS_ISO_HP
   Isolation level: 2
   Starting gain ramp...
Time::HiRes::sleep(-0.451209): negative time not invented yet at /opt/rtcds/userapps/release//hpi/common/scripts/HPItool2.pl line 516.
 

And then the script stops, without runing on X, Y, RZ and HP.

Additionally, I noticed that a lot of these HPI turn-on scripts don't actually move to the set target position, but instead just throw a warning, asking for a manual move.  This seems like an alignment time bomb that will get us sooner or later.

Initial restarts of daqd on h1fw1 did not fix the problem. The framewriter ran for about 10 mins and then its uptime counter stopped incrementing.

I power cycled h1ldasgw1, and had to manually remount the QFS file system and NFS export it. I then restarted h1fw1 and it has been running for  about 20 mins now.

(Keiko, Chris)

The h1asc front end is now running with the latest version of the model. The previous version had been copied from L1 by Kiwamu back in May. Since then an Initial ALignment (IAL) system for the arm cavities (a dither scheme using the ALS green light) was added to h1asc by Stefan, but no other significant changes were made. Meanwhile the ASC model has been actively developed at LLO. Our goals were to update this model to track all the LLO changes, to merge in the IAL subsystem, and to start using library parts (which make it easier to verify that the LLO and LHO models are in fact the same).

Here's what's new:

• Almost everything LLO has added since May should now be available here. The exception: a couple of IPC receivers carrying POPAIR_B signals from the LSC model were disabled in the h1asc.mdl top level, since the corresponding senders in h1lsc don't exist yet. (These seem to be used only for dynamic power normalization.)
• Almost all contents of the model have been migrated by Keiko to a library part, asc/common/ASC_MASTER.mdl.
• The model is now using the "top_names" feature. We needed this to get channel names correct, since the ASC_MASTER library part introduces an extra subsystem layer. However, the names of filter modules (as defined in the Foton filter file) change when "top_names" is used. Keiko took care of regenerating this file for L1, and I just copied it over for H1 (asc/h1/filterfiles/H1ASC.txt).
• Other library parts were defined by Stefan for the IAL subsystem: IAL_LOCKIN.mdl, IAL_MASTER.adl.
• I genericized all L1ASC MEDM screens, and installed them in asc/common/medm. Note that there are no guarantees that script buttons work: I haven't yet tried to genericize the scripts.
• I created and linked the safe.snap file (asc/h1/burtfiles/h1asc_safe.snap)

The first new Guardian daemons are now running!

The IMC is now fully under guardian control.  The guardian components are (given by their full guardian identifier):

• ISC_IMC
  • /opt/rtcds/userapps/release/ioo/common/guardian/ISC_IMC.py
  • handles H1:IMC- channels
• SUS_MC2
  • /opt/rtcds/userapps/release/sus/common/guardian/SUS_MC2.py
  • handles H1:SUS-MC2 channels.  Currently this is inheriting from the generic SUS module (/opt/rtcds/userapps/release/sus/common/guardian/SUS.py), and adding additional control states on top.
• IFO_IMC
  • /opt/rtcds/userapps/release/sys/common/guardian/IFO_IMC.py
  • IMC manager that controls both ISC_IMC and SUS_MC2 guardians

The paths listed are the fulls paths to the guardian system description modules that are being executed for each guardian process.  Given a system identifier FOO, guardian looks for a python module named FOO.py in the common/guardian subdirectories of the various relevant subsystems in the userapps path.

The IFO_IMC manager is the top level control.  It instructs SUS_MC2 and ISC_IMC to go to their ACQUIRE states if the IMC is not locked, and then transitions SUS_MC2 to turn on boost filters after ISC_IMC guardian reports that the IMC lock has been achieved.  If ISC_IMC looses lock, IFO_IMC sees this and moves SUS_MC2 and ISC_IMC back to their ACQUIRE states.

MEDM interface

The primary interface for controlling the processes is their medm screens, which are accessible from the "GRD" menu in the sitemap:

The REQUEST button selects the requested state of the system.  The MODE button selects the operational mode of the guardian process.  EXEC indicates that it is executing guardian code.  The STATUS reflects the guardian process status.  In this case, the IFO_IMC guardian is executing the RUN method of the LOCKED state.

The buttons at the upper right allow for displaying the log of the daemon, displaying the current system graph, and editing the underlying system module code.

guardian daemon controls

All three guardian processes are running under the new guardian control infrastructure on h1guardian0:

controls@operator1:~ 0$ guardctrl list
IFO_IMC * run: IFO_IMC: (pid 8739) 7805s, want down; run: log: (pid 13060) 78412s
ISC_IMC * run: ISC_IMC: (pid 6400) 9332s, want down; run: log: (pid 1346) 66758s
SUS_MC2 * run: SUS_MC2: (pid 2208) 66732s, want down; run: log: (pid 2050) 66737s
SUS_SR2 * run: SUS_SR2: (pid 32679) 96154s, want down; run: log: (pid 23722) 230173s
controls@operator1:~ 0$ 

The guardctrl command line interface can be used to start/stop/restart the daemon process, as well as create new ones as needed.

TODO

Some immediate todo task for the next week:

• The rest of the IMC suspensions (at least MC1 and MC3, and maybe others?) need to be brought under the control of IFO_IMC.  These should be ready to go now
• The base SUS module needs to be improved to properly handle watchdog trips, and other potential critical deviations of the suspensions.
• Add HAM2 ISI under IFO_IMC.  This depends on status of the ISI code, which may be ready next week.
• Add GRD MEDM overview
• Add GRD channels to frames

There are also an ever-growing list of guardian bugs (not a bad thing at this point, since it means the system is actually being used now) that I will start filling in in the new guardian bugzilla (thanks Jonathan).

I calculated the spot centering on the IMC mirrors, with help from Kiwamu and Jax (alog #6676).

All beam spots are with 2.3mm on center on all 3 mirrors, which is slightly better than what Jax measured in June.

I have changed the default nds server to h1nds0 until we can sort out what is wrong with h1fw1.  Note that this only affects newly opened shells and newly started programs.

Also note that h1nds0 does not offer the same set of channels, it is set up to write science frames instead of commissioning frames.

I will change the default back to h1nds1 as soon as h1fw1 is functional.

[Filiberto, Keita, ChrisW, Arnaud, Kiwamu]

We steered PR2 to get the beam on the center of PR3. Now we can see a beam hitting somewhere in the BS chamber. This beam spot appears to be the dark port beam.

Then one time, we were able to make the PR-Y cavity flash, but after some time of damping works, we lost it and never found it again. Tomorrow we are going to try a more systematic alignment. The attached is the alignment from the time when we saw fringes.

HAM3 spool Camera:

We first tried GigE cameras to look at the front surface of PR3 from the HAM3 spool position. This didn't work. The cameras were not so sensitive enough to resolve weak light. Then we removed a GigE and installed an analog camera on the 0 o'clock position on the spool. This then allowed us to see a spot on the PR3 cage as well as the swiss cheese baffle. We locally hooked up a monitor on the floor.

Later, Keita told me that it could be much more sensitive if we changed a gain in medm.

PR2 steering:

In the process of steering PR2, I found that PR2 kept tripping its watchdogs. It was due to the OSEMS hitting the open light threshold. I had to offload the alignment biases to IM3 and IM4 to mitigate this issue. The offloading worked well -- I was able to steer the beam onto PR3 while keeping the beam on both IM4 trans and POP_A. Unfortunately POP_B lost the beam but the recovery should be easy as we still have the beam on POP_A. The centering on PR3 was good in yaw and OK in pitch. I used scattered light from the lower part of the cage for aligning yaw and used the baffle to align the beam height. Also, PRM was aligned to obtain the retro-refletion back to PSL.

We got PR-Y flashing, but the spot seemed moving a lot:

Then we started steering PR3 by looking at the BS camera. The idea is to align the PR-Y cavity without wildly touching BS and ITMY which are thought to be a reference. Since I couldn't find a power cable for the illuminator on BS, the BS camera view has been simply dark. At some point, we found a moving spot out of this dark monitor. Because this spot responds to the angle of ITMY and BS, we believe this was the dark port beam which is now hitting somewhere in the BS chamber. By a yaw scan in PR3, we started seeing fringes in POP_A_SUM and REDL_A_LF. POP_A_SUM could go up to 10 counts when flashing while it is 5 counts nominally. However, the fringes didn't look stable -- sometime it didn't flash at all and sometime it flashed a lot. We suspected that something was moving and indeed PR3 was moving the spot position a lot. This was visible in the BS camera when we introduced an intentional offset in PR3 in yaw. The spot was moving vertically at about 1 Hz with an amplitude of approximately three beam sizes. Chris investigated why PR3 wobbled so much and eventually found that turning the HAM2 ISI on at level 3 made it quitter. After the investigating, we restored PR3 back. However we became unable to find the fringe any more. It is unclear what happened.

- Corey to EY
- Gerardo to BSC2 for camera work
- Keita/Filiberto input spool camera 
- Justin, card access changed - doors now lock
- Richard to EX for fiber - Dale tour at 11AM
- praxair delivery
- Mounts Lock here to work on doors
- Townsend Elect. on site
- EY - alignment then welding
- Jamie - guardian work on IMC locking

After an initial assessment that stated "not too bad, not too good" (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=8919), which was based on just two data points (beam radius on WFSs), I added the third point further downstream of the WFS2 and it turns out that actually it's excellent.

In the attached plot, blue circles represent the measured beam width, blue crosses on both sides of blue circle represent the potential position error (Jamie claims +-1cm though probably it's too generous), red line is a fit over the three points, green is the curve generated by the design parameters.

As you can see, in both horizontal and vertical direction, the waist is very close to the middle of the WFSs, and the waist radius is very close to the designed 250um.  Gouy separation for X (horizontal) and Y (vertical) are 82.6 and 87.1 degrees, respectively.

This was obtained from just two iterations of measurming at WFS1 and WFS2 and pushing RM2 toward RM1 based on the measurement. Downstream was measured just once after we were satisfied with WFS1 and WFS2.

Distance from RM3 to the first lens on the sled is, according to Jamie, between 48.0 and 48.25 inches.

Also, as noted earlier, the above data was obtained after having moved RM2 toward RM1 by 22.5mm. Everything else is the same as what Sheila reported much earlier.

We also measured at one point between RM3 and the sled (14.5" downstream of RM3).  Together with upstream number measured yesterday (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=8893), these are:

In all of the above measurements, "Profile averages" was 10, "Rolling profile Averages" was 3, the actual number of measuremets (i.e. the number of scans performed before I stopped the measurement) were larger than 10 but I don't know if the software was taking more than 10 points into the statistics or not.

end-Y spent day moving suspension onto stand, setting up metrology and aligning test masses. End of play we have masses aligned and set in height. We have one fibre in position ready to start welding (S1301759). Tomorrow we will double check mass separation and pitch before commencing welding.
Angus, Alastair, Doug and Travis

Addressing "Bug 256", the pair of ring heaters installed at the pilot ETM were from Production Lot #1. These have been replaced with a pair of ring heaters from Production Lot #3. See also T1300463-v17.

As noted in alog6341, the gain on the Dual PD Amp board was set to 30dB (photo 1). I have reduced the gain to 10dB (photo 2). However, I still see saturation at 10V in the external PD monitor. Tomorrow I will try reducing the gain to 0dB.