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:
The IMC is now fully under guardian control. The guardian components are (given by their full guardian identifier):
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
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.
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.
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.
Some immediate todo task for the next week:
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).
All the locking code guardian modules has been committed to the userapps repo at:
/opt/rtcds/userapps/release/ioo/common/guardian/ISC_IMC.py /opt/rtcds/userapps/release/sus/common/guardian/SUS_MC2.py /opt/rtcds/userapps/release/sus/common/guardian/SUS.py /opt/rtcds/userapps/release/sys/common/guardian/IFO_IMC.py
The guardian and cdsutils versions are:
cdsutils and guardian are installed in their proper places in /ligo/apps/linux-x86_64/
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.
| Beam Centering Measurements: 12/12 | P2L/Y2L gain | smallest peak amplitude | EL/EP | alpha | alpha in % | distance from center of mirror, in mm |
| 0.25/5.2382 | (EL/EP)*P2L/Y2L gain | % * 0.375 | ||||
| MC1 | ||||||
| P | -0.90 | 0.05 | 0.048 | -0.043 | -4.3 | -1.6 |
| Y | 0.60 | 0.30 | 0.048 | 0.029 | 2.9 | 1.1 |
| MC2 | ||||||
| P | -1.30 | 0.05 | 0.048 | -0.062 | -6.2 | -2.3 |
| Y | -1.00 | 0.50 | 0.048 | -0.048 | -4.8 | -1.8 |
| MC3 | ||||||
| P | 0.85 | 0.12 | 0.048 | 0.041 | 4.1 | 1.5 |
| Y | -1.10 | 0.05 | 0.048 | -0.052 | -5.2 | -2.0 |
I'm revisiting beam centering measurements, and have recalculated the beam centering logged here, based on my enhanced knowledge, and with both the procedure used in 2013 and in 2017.
My sign conventions in this 2013 alog are incorrect, and I'm now correcting them, and posting values using both the 2013 and 2017 procedure.
In 2013, though it's not stated, I used the Eul2OSEM values that match the UR OSEM, which matches the procedure I used in 2017, alog 34973
Updated Results (details in attached pdf):
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.
We also fully turned back on ISI and HEPI of ITMY and BS, which notably reduced the beam motion seen on the BS camera . The configuration of both systems was set to the one described by Hugo in his alog 8860. We increased the threshold of the T240 watchdogs for ITMY ISI to avoid the system to trip on the T240 when starting the loops. For the BeamSplitter ISI, we had to exclude the T240 out of the loop to turn it on. We then lowered the blends and included the T240. The isolation was turned on independentely for both stages of each ISI.
This is a picture of the HAM3 spool camera that looks at the front surface of PR3 through the swiss cheese baffle.
The green circle in the picture indicates the scattered light off of the upper side of the PR3 cage. This is the original position before we started aligning anything.
- 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
Card access not changed; door closing mechanisms adjusted.
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.
| relative position (mm) | position error (mm) | X diameter mean (um) | X diameter std | X goodness of fit | X goodness of fit std | Y diameter mean | Y diameter std | Y goodness of fit mean | Y goodness of fit std | |
| WFS1 | 0 | +-10 | 746.79 | 4.6 | 0.01 | 0.000 | 688.9 | 4.2 | 0.00 | 0.000 |
| WFS2 | 369 | +-10 | 746.25 | 10.1 | 0.00 | 0.000 | 758.18 | 4.4 | 0.00 | 0.000 |
| downstream | 763.2 | +-10 | 1574.92 | 4.95 | 0.02 | 0.000 | 1666.38 | 1.79 | 0.01 | 0.000 |
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:
| position | position error | X diameter (um) | X std | X goodness of fit mean | X goodness of fit std | Y diameter | Y std | Y goodness of fit | Y goodness of fit std | |
| After RM3 | 14.5" downstream of RM3 | +-10mm | 3750.18 | 4.885 | 0.01 | 0.000 | 3923.63 | 2.137 | 0.00 | 0.000 |
| Upstream of telescope | 44.7" downstream of 50:50BS right after the HWP | +-1" | 3851.01 | 1.982 | 0.01 | 0.000 | 3959.23 | 1.232 | 0.01 | 0.000 |
| Upstream of telescope, head rotated 45 degrees | same as above | same as above | 4117.74 | 1.475 | 0.02 | 0.000 | 3845.62 | 0.763 | 0.00 | 0.000 |
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.
Several things to note.
We decided that we did NOT want to propagate the upstream measurements to downstream, because it was difficult to obtain more than one data points. (ModeMaster is supposed to overcome this, but in reality there are many caveats and you should know how to tell when which caveat applies.)
With NanoScan and limiting ourselves to the measurements with small beam, it was still difficult to obtain good data because of some kind of glitches. It's not clear if it was due to NanoScan or the beam, the beam was well damped and was not moving on the viewer card, there was no noticable intensity glitch either. But the symptom was that the statistics window shows nice steady data for anywhere from one second to 30 seconds, then there's some kind of glitch and the scan/fit image looked noticably different (not necessarily ugly), the diameter mean becomes larger and the stddev jumps to a big number (like 10% or more of the mean, VS up to a couple % when it's behaving nice), and the goodness of fit also becomes large. Somehow no glitch made the beam diameter number smaller. I just kept waiting for a good period and cherry-picked.
When the beam was moving it was impossible to obtain good data.
Another kind of glitch was "saturating" glitch where the software says there is a saturation. We disabled AGC of NanoScan and lowered the gain by 3dB in an attempt to eliminate saturation, it seemed to help but we couldn't kill that error completely.
We (I and Jamie) will go in HAM1 tomorrow to set the eddy current damper spacing (now that Bram wrote a procedure to do that, plus it turned out that Jamie didn't check the ECD spacing on the back plates).
Measurement apparatus. We flipped one steering mirror on the sled to direct the beam to Nanoscan that is placed at the same distance from the steering mirror as the WFS. Made measurement, flipped the mirror back, and moved to the next one.
Very nice! This will become version 12 in D1000313. It would be good to add the corresponding alamode file with the final distances here: https://dcc.ligo.org/T1300960-v1, I added a note to remind us that this is the relevant log entry.
A update on 2014.Jan.12:
Alexa, Koji and I changed the position of both WFSs to dump the reflected light off of the diode (see alog 9226).
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
Another plot of the vertex pumpdown - this time with a different "T0" and ASCII data for others to play with.
(Alexa, Richard)
We have replaced the fiber going from the MPC to the end station patch panel in the MSR and the fiber on the inside of ISCTEX. Now we have:
Input of MPC @ MSR = .18mW (expected drop due to ref cav misalignment)
To EX from MSR = .13mW
Patch panel of ISCTEX = 62uW
Fiber Output on ISCTEX = 58uW
This is much better than the previous measurements (alog 8912)
Robert, Chris, Sheila
Chris and Jamie got the script that records the psl camera centroids working on the gaurdian machine, it generates epics channels H1:PSL-FSS_TRANS_CENTROID_PIT, H1:PSL-FSS_TRANS_CENTROID_YAW, H1:PSL-PMC_TRANS_CENTROID_PIT, H1:PSL-PMC_TRANS_CENTROID_YAW with the position of the centroids in pixels. For now the script is in userapps/isc/h1/scripts/AnalogCameras.
You need to give it the username and password for the cameras when you call the script.
For the ref cav trans, pitch has not really moved since Nov 22 (when chris first got this script running) (pit is 119, yaw is 177) https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=8707
So, it seems like this position has been fairly stable. the ref cav alignment always drifts up (meaning that the beam is high compared to the cavity position based on the refl camera), so if this was due to the cavity moving we would have seen some difference in the trans centroid position. It seems like the beam moving, not the cavity.
With Robert we looked at the long term drift, which doesn't seem to be correlated with temperature. (the 20 minute fluctuations are).
In the last several weeks we have had two times when the transmitted power was stable for several day stretches, both of those were times when the transmitted power was 1.2V. (perhaps we need to realign the AOM and the cavity periscope each time we realign to get the power that high).
I've attached a trend of the ref cav trans PD and the threshold over a long period of time. It seems like this has never been stable, but the resonant threshold was set to be much lower than the normal value for most of the time since the PSL came online.
It may be that no one has cared about the stability of the reference cavity transmitted power until we started using it for ALS.
- Kiwamu, Cheryl
I ran excitations to get gains that we turn into beam centering. Here are the raw gains, and the minimum peak amplitudes. Most peaks were reduced to the noise level at 0.05e-12, but two were not, and those are MC3 pitch (0.12), and MC1 yaw (0.3).
| Beam Centering Measurements: 12/12 | ||
| P2L/Y2L gain | smallest peak amplitude | |
| MC1 | ||
| P | -0.90 | 0.05 |
| Y | 0.60 | 0.30 |
| MC2 | ||
| P | -1.30 | 0.05 |
| Y | -1.00 | 0.05 |
| MC3 | ||
| P | 0.85 | 0.12 |
| Y | -1.10 | 0.05 |
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.
Pictures of the replacement.
NOTE: Only the upper and lower ring heating segments were replaced. All associated cables remain the same; hence, there should be no grounding concerns.
