Peek Down X-arm TOMORROW! Here are notes regarding it:
Other Items:
Checked PSL filters. No debris noted in either filter. The crystal chiller filter is starting to yellow. The diode chiller filter has darkening somewhat, but not as much as the crystal chiller. I plan to swap both sets of filters (2 filters in the chiller room and 2 in the PSL enclosure) when the PSL goes down for the 70 watt amp change. I have all 4 filters on hand. Peter King - added 300ml water to crystal chiller this morning. Closing FAMIS task #8305
The ongoing "trippy" saga of "As the Diodes Weaken" is reflected in all aspects of the trends as LASER outages and incursions have been more frequent. Peter and Jeff are currently in the enclosure and the Pre-Mode cleaner appears to be off its alignment.
TITLE: 02/05 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
Wind: 9mph Gusts, 8mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.16 μm/s
QUICK SUMMARY:
The LVEA has transitioned to LASER SAFE.
I misplaced a small adapter needed to connect the leak detector but will pump down and leak check this new setup early next week.
A couple of status screens at the time of shutdown. Both the diode and crystal chillers are off. Internal and external shutters are closed. The PSL Beckhoff computer will remain on. The diode currents for all heads have been set to zero. head 1 diode current: 65.0A head 2 diode current: 59.8A head 3 diode current: 59.8A head 4 diode current: 59.8A Autolockers for the pre-modecleaner, intensity stabilisation and frequency stabilisation are off. I took the input modecleaner off line. "It is a far, far better thing that I do, than I have ever done; it is a far, far better rest that I go to than I have ever known." Sydney Carton
Jenne, TVo
We set out today trying to lock MICH with the newly aligned AS_A and AS_B senors from aLOG-40338, however, we had problems trying to get the light back on the diodes which is confusing because there weren't large alignment changes between now and this past Tuesday.
In the end of a lot of alignment tweaks, we were able flash MICH fringes and get light onto the AS_A, AS_B, and AS_C individually, but not at the same time as we would expect. Attached is the screenshot of our current alignment.
We did have some successes today in commissioning the new configuration of AS_A WFS.
Since our ASC_IMC model runs at 16k, we don't need our AS WFS to be up in the IOP model. Daniel and DaveB made the changes, however upon restarting the model today TVo found that the ADC connection in the model wasn't right, which is why we weren't getting any signals in. Once Dave fixed that and restarted the model again, we see sensible signals in the AS_A WFS.
We copied over the antiwhitening filters, as well as all of the EPICS settings from the old AS_A locations (since it's now on a new model). We also installed AA filters on the pitch and yaw filter banks just before the signals get sent from the 16k ASCIMC model down to the 2k ASC model.
We checked that the same signal in, for example, AS_A_Pit_I goes through the ASC input matrix to the inputs of the various degrees of freedom, as you would expect.
We also checked that the AS Sum signal goes through the LSC input matrix as you would expect.
So, the digital signals for the new AS A WFS configuration seem all okay now. *Then* we wanted to try to lock MICH, but as TVo said, couldn't get to a point where we had light on all the AS and OMC diodes that we were expecting, all at the same time. We'll relook at this on Monday after the PSL is back up, or perhaps wait until ~Wednesday after we've set the input alignment to match the Xarm.
Krishna
The new BRS DetChar Summary pages alerted me to a strange noise visible on Jan 19th and Jan 20th.
I looked at the rY_in DQ channel and the noise looks like short duration spikes in the angle channel. See first attached plot. The low-frequency oscillation of BRS-X is visible and the spikes start in the 17th minute of the plot. Zooming in (next plot), these spikes last for 8-10 second and the data resumes it's previous trend, with no apparent offset. I looked at most of the error bits listed in the BRS troubleshooting guide and saw no indication of any kind of hardware issue. I have also attached the DRIFTMON data showing a similar spike but appropriately smaller, indicating that it is a real deviation as seen by the C# code. I looked through two months of recent data and don't see any other similar noise.
I have two theories to explain this:
1. We have a literal bug in the autocollimator - most likely near the CCD. The CCD isn't fully enclosed and there is room for bugs/critters to get in there especially since they are attracted by the heat of the CCD. We had a similar issue some time ago in the lab. Whether or not this is what happened, Michael and I agree we should try to more fully seal the autocollimator so that this never happens.
2. The CCD is failing. I think this is less likely since it seems to be functioning perfectly now, even though the code hasn't been restarted since Jan 4. The previous time the CCD malfunctioned (Jan 31), the symptoms were very different (see 4th plot). However, we can't rule this out completely. We need to see if this happens again (after sealing up the CCD), and if needed the CCD can be replaced. It is an off-the-shelf item - Basler Racer raL4096-24gm.
Due to the large size of the isc userapps repository (4.1GB), while I was checking out the ISC from scratch some ALS MEDM macro-substitutions did not work. For other large systems I will do the checkout into a temp directory and then do the 1.6 to 1.8 upgrade in one atomic operation.
This also caused bogus filter-file-changed warning with no actual content changed.
We shifted the ALS laser in the X end stations by ~18.6GHz (-6.2V on the crystal temperature control voltage) to bring it close to the PSL. This offset was then relieved using the front panel potentiometer. The ALS autolocker is working again.
The same shift will have to be applied to the Y end laser.
Some other strangeness:
16:30 JeffB to LVEA
16:30 Bubba to EX, back 17:45
16:50 Hugh to HAM6
17:35 Nico to LVEA, back 18:10
17:45 JeffB to LVEA
18:15 TJ to optics lab
18:15 Jason to EY
18:25 Kyle to MY
18:30 - 18:56 UTC Corey and Richard to end X, looking at solar panels, batteries for
vacuum gauge
18:37 - 19:32 UTC Karen and Vanessa cleaning at mid Y
19:00 - 19:16 UTC Bubba taking measurements in LVEA
19:00 - ~20:00 UTC Marc WP 7327
19:00 - 19:23 UTC Filiberto WP 7309
19:07 - 19:34 UTC Amber and two visitors from OSA in LVEA
19:23 - 19:58 UTC Jeff B. to LVEA, ITM camera work
19:37 UTC Sheila back from optics lab (in about an hour ago)
19:44 UTC Chris opening OSB outer rollup door
19:45 UTC Dave restarting models, IMC down
19:48 UTC Jason back from end Y
21:15 TJ Nico to LVEA
21:15 TVo checking to see if light pipe was closed
21:15 Keita, Georgia, DaveO, Daniel to LVEA then EX
22:45 Sheila to optics lab
Thomas informed me that the PSL ISS was having issues. Upon investigation I found the HPO was only outputting ~117W. To keep the laser running for the remainder of the day, I tweaked the pump diode operating temperatures for DB1 and increased the operating current of DB2, 3, and 4 from 59.0A to 59.7A. The output power of the HPO increased to 131.0W; this also cleaned up the ISS, which was oscillating because of the low power out of the HPO.
During the upgrade process, some local working directories on the CDS file system will still be using the old 1.6 svn version, and others will be using the upgraded 1.8 version. Remember that the two versions are completely incompatible (in both directions).
The CDS workstations now have version 1.8 svn code installed in the default svn location (/usr/bin/svn). To permit running the 1.6 code if and when needed, please create an alias in your .bashrc file
alias svn1.6="/ligo/apps/debian8/subversion-1.6-17/bin/svn"
This is only a temporary work around, eventually all working directories will be migrated to 1.8.
IMPORTANT NOTE: when viewing a 1.6 working directory with a 1.8 svn program, the system may suggest you upgrade the directory using the 'svn upgrade' command.
Please do not do this!
In the upgrade process I am resolving local modification, adding files which should be under config control, and making sure files which are cluttering up the old working directories do not migrate to the new directories.
I've changed the CDS standard environment such that your default svn client should now be /usr/bin/svn (version 1.8).
If your svn code version does not match that which was used to create the working directory you are in, you will get an error message. The exact message differs for the different combinations of client-code/working-directory versions. In order to understand this, we must first understand the basic differences in the working-directory meta-data layout between SVN1.6 and SVN1.8.
In the old SVN1.6, every directory under the top level directory has a .svn directory. In SVN1.8, the .svn directory only exists in the top level directory, there are none in the lower directories.
If you are running client svn1.6 and looking at a SVN1.8 created working dir, then at the top level the client sees the .svn and sees that it has the wrong version. You get the error message
svn: The path '.' appears to be part of a Subversion 1.7 or greater
working copy. Please upgrade your Subversion client to use this
working copy.
However, if you navigate to lower directories, because they don't have .svn meta-data directories (this is SVN1.8), then client svn1.6 gives the bogus error
svn: warning: '.' is not a working copy
Now onto the second case of running client svn1.8 and looking at a SVN1.6 created working dir. Each sub directory has a .svn dir (this is SVN1.6), so at every level you get the message
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/opt/rtcds/userapps/trunk/cds_1.6/h1'
is too old (format 10) to work with client version '1.8.10 (r1615264)' (expects format 31). You need to upgrade the working copy first.
(again,please do not do an 'svn upgrade')
Elizabeth C., Marc P.
Taking advantage of a one hour window in operation we repaired the Corner 4 and Corner 6 squeezer readbacks per WP7309.
In Corner 4 we replaced module 19 on the left rail with a new EL3104 (4 channel differential ADC)
In Corner 6 we replaced module 5 on the right rail with a new EL1124 (4 channel digital input)
Both of the replaced modules appear to be working.
ASC-AS_B_RF42_DEMOD_LOMONCHANNLE_3/4 is fixed.
H1:ISC-RF_C_AMP42M4_POWEROK still reads zero. Maybe a cabling problem?
Fil C., Marc P.
It was a indeed an internal wiring problem. We moved the wires to the correct positions on the beckhoff terminal and verified OK1 through OK12 are working as intended.
Sheila, Nutsinee
Here I attached the SHG conversion efficiency measurement as a function of 1064 input power (red dots) plotted against theoretical prediction (the equation came from Polzik and Kimble 1991 paper on frequency doubling) . ~75% conversion efficiency at 400mW input, 48% conversion efficiency at 100mW input. For the fit I tweaked a couple parameters, intracavity losses (L) and the single-pass nonlinear conversion efficiency (Enl).
Here's everything I wrote down.
P in (1064, mW) | P out (532, mW) | P trans (1064, mW) | Common mode board gain (dB) | responsivity (A/W) |
100 | 48.6 | 2 | 24 | |
151 | 88 | 2.6 | 23 | |
102 | 49.5 | 0.313 | ||
206 | 135.5 | 3.1 | 22 | |
250 | 175 | 3.45 | 22 | |
300 | 220.2 | 3.8 | 21 | 0.297 |
350 | 267 | 4.1 | 21 | |
400 | 306.5 | 22 | ||
401 | 315.5 | 4.5 | 22 | 0.293 |
The common mode board common path gain was adjusted to keep the UGF at 3kHz.
The responsivity was adjusted to match the photodiode readback to the power meter.
P in and P out was measured with a 1W Thorlabs power meter. P trans was read out of the photodiode.
The optimized crystal temperature for green output was the same for all input power, at 35.9 C
More SHG characterizations: