40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 89 of 339 Not logged in
ID Date Author Type Category Subject
12617   Tue Nov 15 20:26:35 2016 JohannesUpdateCamerasBasler GigE-Camera on Optimus (+Mafalda dead)

I powered up the existing ace100gm GigE cam with the PoE injector and tried to interface with it as described in elog 4163. After a few initial problems with IP assignment and interfacing I connected it to one of the gigabit hubs and installed the most recent pre-compiled software suite on /opt/pylon5 on optimus, after which I was able to find it with the configuration software. I named it "c1gige_bas100-1" and gave it the static IP address 192.168.113.151.

Afterwards the image acquisition worked without problems.

It may be a good idea to leave the gigecam interfacing up to a dedicated machine. I was thinking I could use Mafalda for this, and also for developing the code for framegrabbing and imager settings, but found that it was dead, burnt at the stake so to say. I guess it wasn't running anything critical, since it wasn't even connected to the network and smelled like burnt electronics. I'll get a replacement desktop for it.

Attachment 1: gige_test.png
12616   Tue Nov 15 19:22:17 2016 gautamUpdateGeneralhousekeeping

PRM and SRM sat. boxes have been switched for some time now - but the PRM sat. box has one channel with a different transimpedance gain, and the damping loops for the PRM and SRM were not systematically adjusted to take this into account (I just tweaked the gain for the PRM and SRM side damping loops till the optic damped). Since both sat. boxes are nominally functioning now, I saw no reason to maintain this switched configuration so I swapped the boxes back, and restored the damping settings to their values from March 29 2016, well before either of this summer's vents. In addition, I want to collect some data to analyze the sat. box noise performance so I am leaving the SRM sat. box connected to the DAQ, but with the tester box connected to where the vacuum feedthroughs would normally go (so SRM has no actuation right now). I will collect a few hours of data and revert later tonight for locking activities....

12615   Mon Nov 14 19:32:51 2016 ranaSummaryCDSReplacing DIMM on Optimus

I did apt-get update and then apt-get upgrade on optimus. All systems are nominal.

12614   Mon Nov 14 19:15:57 2016 JohannesUpdateGeneralAchievable armloss measurement accuracy

Looking back at elog 12528, the uncertainty in the armloss number from the individual quantities in the equation for $\mathcal{L}$ can be written as:

$\delta\mathcal{L}^2=\left(\frac{T_1(1-\frac{P_L}{P_M}-2T_1)}{4\gamma}\right)^2\left(\frac{\delta T_1}{T_1}\right)^2+T_2^2\left(\frac{\delta T_2}{T_2}\right)^2+\left(\frac{T_1(1-\frac{P_L}{P_M}-T_1)}{4\gamma}\right)^2\left(\frac{\delta\gamma}{\gamma}\right )^2+\left(\frac{T_1}{4\gamma}\right )^2\left[\left(\frac{\delta P_L}{P_L}\right )^2+\left(\frac{P_L}{P_M} \right )^2\left(\frac{\delta P_M}{P_M}\right )^2\right ]$

Making some generous assumption about the individual uncertainties and filling in typical values we get in our measurements, results in the following uncertainty budget:

$\delta\mathcal{L}^2\approx\left(12\,\mathrm{ppm}\right)^2\left(\frac{\delta T_1/T_1}{5\%}\right)^2+(0.7\,\mathrm{ppm})^2\left(\frac{\delta T_2/T_2}{5\%}\right)^2+\left(2\,\mathrm{ppm}\right)^2\left(\frac{\delta\gamma/\gamma}{1\%}\right )^2+\left(140\,\mathrm{ppm}\right )^2\left(\frac{\delta P/P}{2.5\%}\right )^2$

In my recent round of measurements I had a 2.5% uncertainty in the ASDC reading, which completely dominates the armloss assessment.

The most recent numbers are 57 ppm for the YARM and 21 ppm for the XARM, but both with an uncertainty of near 150 ppm, so while these numbers fit well with Gautam's estimate of the average armloss via PRG, it's not really a confirmation.

I set the whitening gain in ASDC to 24 dB and ran LSC offsets, and now I'm getting a relative uncertainty in measured reflected power of .22%, which would be sufficient for ~25ppm accuracy according to the above formula. I'm going to start a series of measurements tonight when I leave, should be done in ~2 hours (10 pm) the latest.

If anybody wants to do some night work: I misaligned ITMY by a lot to get its reflection off ASDC. Approximate values are saved as a restore point. Also the whitening gain on ASDC will have to be rolled back (was at 0dB) and LSC offsets adjusted.

12613   Mon Nov 14 14:21:06 2016 gautamSummaryCDSReplacing DIMM on Optimus

I replaced the suspected faulty DIMM earlier today (actually I replaced a pair of them as per the Sun Fire X4600 manual). I did things in the following sequence, which was the recommended set of steps according to the maintenance manual and also the set of graphics on the top panel of the unit:

1. Checked that Optimus was shut down
2. Removed the power cables from the back to cut the standby power. Two of the fan units near the front of the chassis were displaying fault lights, perhaps this has been the case since the most recent power outage after which I did not reboot Optimus
3. Took off the top cover, removed CPU 6 (labelled "G" in the unit). The manual recommends finding faulty DIMMs by looking for an LED that is supposed to indicate the location of the bad card, but I couldn't find any such LEDs in the unit we have, perhaps this is an addition to the newer modules?
4. Replaced the topmost (w.r.t the orientation the CPU normally sits inside the chassis) DIMM card with one of the new ones Steve ordered
5. Put everything back together, powered Optimus up again. Reboot went smoothly, fan unit fault lights which I mentioned earlier did not light up on the reboot so that doesn't look like an issue.

I then checked for memory errors using edac-utils, and over the last couple of hours, found no errors (corrected or otherwise, see Praful's earlier elog for the error messages that we were getting prior to the DIMM swap)- I guess we will need to monitor this for a while more before we can say that the issue has been resolved.

Looking at dmesg after the reboot, I noticed the following error messages (not related to the memory issue I think):

[   19.375865] k10temp 0000:00:18.3: unreliable CPU thermal sensor; monitoring disabled
[   19.375996] k10temp 0000:00:19.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376234] k10temp 0000:00:1a.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376362] k10temp 0000:00:1b.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376673] k10temp 0000:00:1c.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376816] k10temp 0000:00:1d.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376960] k10temp 0000:00:1e.3: unreliable CPU thermal sensor; monitoring disabled
[   19.377152] k10temp 0000:00:1f.3: unreliable CPU thermal sensor; monitoring disabled

I wonder if this could explain why the fans on Optimus often go into overdrive and make a racket? For the moment, the fan volume seems normal, comparable to the other SunFire X4600s we have running like megatron and FB...

12612   Sun Nov 13 23:42:43 2016 LydiaUpdateSUSETMX output matrix data

I took data of the ETMX SUSPOS, SUSPIT and SUSYAW channels while driving each of the 4 face coils. I manually turned off all the damping except the side.

Excitation: I used white noise bandpassed from 0.4 to 5 Hz in order to examine the responses around the resonance frequencies. To avoid ringing things up too much, I started with a very weak drive signal and gradually increased it until it seemed to have an effect on the mirror motion by looking at the oplev signals/sensor RMS values on the SUS screen; it's possible I'll need to do it again with a stronger signal if there's not enough coherence in the data.

Finding the matrix: The plan is to estimate the transfer function of the coil drive signal with the sensed degrees of freedom (specified by the already diagonalized input matrix). This transfer function can be averaged around the resonance peak for each dof to find the elements of the matrix that converts signals to dof responses, (the "response matrix", which is the inverse of the output matrix). Each column of the response matrix gets normalized so that the degrees of freedom influence the drive signals in the right ratio.

Other notes:

• I had some trouble getting the awg python library to work: I had to manually edit a CDLL statement to use the absolute path of an .so file. I wasn't sure what environment variable to set to make it look in the right folder automatically.
• The awg ArbitraryLoop object seems to be affected by cds getdata calls (The EXC signal stopes early and then stop() hangs) so I ended up doing the excitation and data reading in 2 separate scripts.
• Reminder that the watchdogs must be on "Normal" for the EXC signal to make it to the coils, so the damping must be turned off manually with the watchdogs still on if you want to drive without damping.
12611   Sat Nov 12 01:09:56 2016 gautamUpdateLSCRecovering DRMI locking

Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.

As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

12610   Thu Nov 10 19:02:03 2016 gautamUpdateCDSEPICS Freezes are back

I've been noticing over the last couple of days that the EPICS freezes are occurring more frequently again. Attached is an instance of StripTool traces flatlining. Not sure what has changed recently in terms of the network to cause the return of this problem... Also, they don't occur coincidentally on multiple workstations, but they do pop up in both pianosa and rossa.

Not sure if it is related, but we have had multiple slow machine crashes today as well. Specifically, I had to power cycle C1PSL, C1SUSAUX, C1AUX, C1AUXEX, C1IOOL0 at some point today

Attachment 1: epicsFreezesBack.png
12609   Wed Nov 9 23:21:44 2016 gautamUpdateGreen LockingGreen beat setup on PSL table

I tried to realize an improvement in the mode matching onto the BBPDs by moving the lens mentioned in the previous elog in this thread. My best efforts today yielded X and Y beats at amplitudes -15.9dBm (@37MHz) and -25.9dBm (@25MHz) respectively. The procedure I followed was roughly:

1. Do the near-field far-field alignment of the arm and PSL green beams
2. Steer beam onto BBPD, center as best as possible using the usual technique of walking the beam across the photodiode
3. Hook up the output of the scope to the Agilent network analyzer. Tweak the arm and PSL green alignments to maximize the beat amplitude. Then move the lens to maximize the beat amplitude.

As per my earlier power budget, these numbers translate to a mode matching efficiency of ~53% for the X arm beat and ~58% for the Y arm beat, which is a far cry from the numbers promised by the a la mode simulation (~90% at the optimal point, I could not achieve this for either arm scanning the lens through a maximum of the beat amplitude). Looks like this is the best we can do without putting in any extra lenses. Still a marginal improvement from the previous state though...

12608   Wed Nov 9 11:40:44 2016 ericqUpdateCDSsafe.snap BURT files now in svn

This is long overdue, but our burt files for SDF now live in the LIGO userapps SVN, as they should.

The canonical files live in places like /opt/rtcds/userapps/release/cds/c1/burtfiles/c1x01_safe.snap and are symlinked to files like /opt/rtcds/caltech/c1/target/c1x01/c1x01epics/burt/safe.snap

12607   Tue Nov 8 17:51:09 2016 LydiaUpdateCDSacromag chassis hooked up to PSL

We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.

12606   Tue Nov 8 11:54:38 2016 gautamUpdateSUSPRM Sat. Box. looks to be fixed

Looks like the PRM Sat. Box is now okay, no evidence of the kind of glitchy behaviour we are used to seeing in any of the 5 channels.

 Quote: GV Edit 2230 hrs 7Nov2016: The signs from the last 6 hours has been good - see the attached minute trend plot. Usually, the glitches tend to show up in this sort of time frame. I am not quite ready to call the problem solved just yet, but I have restored the connections to the SRM suspension (the PRM and SRM Sat. Boxes are still switched). I've also briefly checked the SRM alignment, and am able to lock the DRMI, but the lock doesn't hold for more than a few seconds. I am leaving further investigations for tomorrow, let's see how the Sat. Box does overnight.

12605   Tue Nov 8 08:51:59 2016 SteveUpdatePEMmouse hole sealed

This is where the mammal came though. It is reach able from room 108 CES

 Quote: We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

Attachment 1: CES108rs.jpg
12604   Mon Nov 7 19:49:44 2016 JohannesUpdateCDSacromag chassis hooked up to PSL

[Lydia, Johannes]

We're waiting on the last couple electrical components to arrive that are needed to complete the acromag chassis, but it is essentially operational. Right now it is connected to the PSL Mephisto's diagnostics port, for which only a single XT1221 A/D unit is needed. We assigned the IP address 192.168.113.121 to it. For the time being I'm running a tmux session on megatron (named "acromag") that grabs and broadcasts the epics channels, with Lydia's original channel definitions. Since the chassis is 4U tall, there's not really any place in the rack for it, so we might want to move it to the X-end before we start shuffling rack components around. Once we finalize its location we can proceed with adding the channels to the frames.

For the eventual gradual replacement of the slow machines, we need to put some thought into the connectors we want in the chassis. If we want to replicate the VME crate connectors we probably need to make our own PCB boards for them, as there don't seem to be panel-mount screw terminal blocks readily available for DIN 41612 connectors. Furthermore, if we want to add whitening/AA filters, the chassis may actually be large enough to accomodate them, and arranging things on the inside is quite flexible. There are a few things to be considered when moving forward, for example how many XT units we can practically fit in the chassis (space availability, heat generation, and power requirements) and thus how many channels/connectors we can support with each.

Steve: 1X3 has plenty of room

Attachment 1: acromag_chassis_location.jpg
Attachment 2: acromag_chassis_top_view.jpg
12603   Mon Nov 7 17:24:12 2016 gautamUpdateGreen LockingGreen beat setup on PSL table

I've been trying to understand the green beat setup on the PSL table to see if I can explain the abysmal mode-matching of the arm and PSL green beams on the broadband beat PDs. My investigations suggest that the mode-matching is very sensitive to the position of one of the lenses in the arm green path. I will upload a sktech of the PSL beat setup along with some photos, but here is the quick summary.

1. I first mapped the various optical components and distances between them on the PSL table, both for the arm green path and the PSL green path
2. Next, setting the PSL green waist at the center of the doubling oven and the arm green waist at the ITMs (in vacuum distances for the arm green backed out of CAD drawing), I used a la mode to trace the Gaussian beam profile for our present configuration. The main aim here was to see what sort of mode matching we can achieve theoretically, assuming perfect alignment onto the BBPDs. The simulation is simplified, the various beam splitters and other transmissive optics are treated as having 0 width
3. It is pretty difficult to accurately measure path lengths to mm accuracy, so to validate my measurement, I measured the beam widths of the arm and PSL green beams at a few locations, and compared them to what my simulation told me to expect. The measurements were taken with a beam profiler I borrowed from Andrew Wade, and both the arm and PSL green beams have smooth Gaussian intensity profiles for the TEM00 mode (as they should!). I will upload some plots shortly. The agreement is pretty good, to within 10%, although geometric constraints on the PSL table limited the number of measurements I could take (I didn't want to disturb any optics at this point)
4. I then played around with the position of a fast (100mm EFL) lens in the arm green path, to which the mode matching efficiency on the BBPD is most sensitive, and found that in a +/- 1cm range, the mode matching efficiency changes dramatically

Results:

Attachments #1 and 2: Simulated and measured beam profiles for the PSL and arm green beams. The origin is chosen such that both beams have travelled to the same coordinate when they arrive at the BBPD. The agreement between simulation and measurement is pretty good, suggesting that I have modelled the system reasonably well. The solid black line indicates the (approximate) location of the BBPD

Attachment #3: Mode matching efficiency as a function of shift of the above-mentioned fast lens. Currently, after my best efforts to align the arm and PSL green beams in the near and far fields before sending them to the BBPD results in a mode matching efficiency of ~30% - the corresponding coordinate in the simulation is not 0 because my length measurements are evidently not precise to the mm level. But clearly the mode matching efficiency is strongly sensitive to the position of this lens. Nevertheless, I believe that the conclusion that shifting the position of this lens by just 2.5mm from its optimal position degrades the theoretical maximum mode matching efficiency from >95% to 50% remains valid. I propose that we align the beams onto the BBPD in the near and far fields, and then shift this lens which is conveniently mounted on a translational stage, by a few mm to maximize the beat amplitude from the BBPDs.

Unrelated to this work: I also wish to shift the position of the PSL green shutter. Currently, it is located before the doubling oven. But the IR pickoff for the IR beat setup currently is located after the doubling oven, so when the PSL green shutter is closed, we don't have an IR beat. I wish to relocate the shutter to a position such that it being open or closed does not affect the IR beat setup. Eventually, we want to implement some kind of PID control to make the end laser frequencies track the PSL frequency continuously using the frequency counter setup, for which we need this change...

Attachment 1: CurrentX.pdf
Attachment 2: CurrentY.pdf
Attachment 3: ProposedShift_copy.pdf
12602   Mon Nov 7 16:05:55 2016 gautamUpdateSUSPRM Sat. Box. Debugging

Short summary of my Sat. Box. debugging activities over the last few days. Recall that the SRM Sat. Box has been plugged into the PRM suspension for a while now, while the SRM has just been hanging out with no electrical connections to its OSEMs.

As Steve mentioned, I had plugged in Ben's extremely useful tester box (I have added these to the 40m Electronics document sub-tree on the DCC) into the PRM Sat. Box and connected it to the CDS system over the weekend for observation. The problematic channel is LR.  Judging by Steve's 2 day summary plots, LR looks fine. There is some unexplained behavior in the UR channel - but this is different from the glitchy behaviour we have seen in the LR channel in the past. Moreover, subsequent debugging activities did not suggest anything obviously wrong with this channel. So no changes were made to UR. I then pulled out the PRM sat.box for further diagnostics, and also, for comparison, the SRM sat. box which has been hooked up to the PRM suspension as we know this has been working without any issues.

Tracing out the voltages through the LED current driver circuit for the individual channels, and comparing the performance between PRM and SRM sat. boxes, I narrowed the problem down to a fault in either the LT1125CSW Quad Op-Amp IC or the LM6321M current driver IC in the LR channel. Specifically, I suspected the output of U3A (see Attachment #1) to be saturated, while all the other channels were fine. Looking at the spectrum at various points in the circuit with an SR785, I could not find significant difference between channels, or indeed, between the PRM/SRM boxes (up to 100kHz). So I decided to swap out both these ICs. Just replacing the OpAmp IC did not have any effect on the performance. But after swapping out the current buffer as well, the outputs of U3A and U11 matched those of the other channels. It is not clear to me what the mode of failure was, or if the problem is really fixed. I also checked to make sure that it was indeed the ICs that had failed, and not the various resistors/capacitors in the signal path. I have plugged in the PRM sat. box + tester box setup back into our CDS data acquisition for observation over a couple of days, but hopefully this does the job... I will update further details over the coming days.

I have restored control to PRM suspensions via the working SRM sat. box. The PRM Sat. Box and tester box are sitting near the BS/PRM chamber in the same configuration as Steve posted in his earlier elog for further diagnostics...

GV Edit 2230 hrs 7Nov2016: The signs from the last 6 hours has been good - see the attached minute trend plot. Usually, the glitches tend to show up in this sort of time frame. I am not quite ready to call the problem solved just yet, but I have restored the connections to the SRM suspension (the PRM and SRM Sat. Boxes are still switched). I've also briefly checked the SRM alignment, and am able to lock the DRMI, but the lock doesn't hold for more than a few seconds. I am leaving further investigations for tomorrow, let's see how the Sat. Box does overnight.

Attachment 1: D961289-B2.pdf
Attachment 2: PRMSatBoxtest.png
12601   Mon Nov 7 08:00:11 2016 SteveUpdateSUSSRM -PRM sat. amp swap

I just realized that Gautam set this test up and turned damping off......He will explane the details

Attachment 1: SRM.jpg
Attachment 2: SRM-UR_OK.png
12600   Sat Nov 5 15:45:44 2016 ranaUpdateCDSc1auxex channels/pins for Acromag

We don't need to record any of the AIOut channels, the OL channels (since we record them fast), or the _MEAN channels (I think they must be CALC records or just bogus).

12599   Fri Nov 4 18:31:05 2016 LydiaUpdateCDSc1auxex channels/pins for Acromag

Here are the channels we are planning to switch over from c1auxex to Acromag, and their current pin numbers on the existing VME boards.

C1:SUS-ETMX_UL_AIOut    #C0 S0
C1:SUS-ETMX_LL_AIOut    #C0 S1
C1:SUS-ETMX_UR_AIOut    #C0 S2
C1:SUS-ETMX_LR_AIOut    #C0 S3
C1:SUS-ETMX_Side_AIOut    #C0 S4
C1:SUS-ETMX_OL_SEG1    #C0 S5
C1:SUS-ETMX_OL_SEG2    #C0 S6
C1:SUS-ETMX_OL_SEG3    #C0 S7
C1:SUS-ETMX_OL_SEG4    #C0 S8
C1:SUS-ETMX_OL_X    #C0 S9
C1:SUS-ETMX_OL_Y    #C0 S10
C1:SUS-ETMX_OL_S    #C0 S11
C1:SUS-ETMX_ULPD    #C0 S12
C1:SUS-ETMX_LLPD    #C0 S13
C1:SUS-ETMX_URPD    #C0 S14
C1:SUS-ETMX_LRPD    #C0 S15
C1:SUS-ETMX_SPD    #C0 S16
C1:SUS-ETMX_ULV    #C0 S17
C1:SUS-ETMX_LLV    #C0 S18
C1:SUS-ETMX_URV    #C0 S19
C1:SUS-ETMX_LRV    #C0 S20
C1:SUS-ETMX_SideV    #C0 S21
C1:SUS-ETMX_ULPD_MEAN    #C0 S12
C1:SUS-ETMX_LLPD_MEAN    #C0 S13
C1:SUS-ETMX_SDPD_MEAN    #C0 S16

Analog Outputs:

C1:ASC-QPDX_S1WhiteGain    #C0 S0
C1:ASC-QPDX_S2WhiteGain    #C0 S1
C1:ASC-QPDX_S3WhiteGain    #C0 S2
C1:ASC-QPDX_S4WhiteGain    #C0 S3
C1:LSC-EX_GREENLASER_TEMP    #C0 S0 This appears to have the same pin as another channel-- is it not being used?

Binary Outputs:

C1:SUS-ETMX_UL_ENABLE    #C0 S0
C1:SUS-ETMX_LL_ENABLE    #C0 S1
C1:SUS-ETMX_UR_ENABLE    #C0 S2
C1:SUS-ETMX_LR_ENABLE    #C0 S3
C1:SUS-ETMX_SD_ENABLE    #C0 S4
C1:ASC-QPDX_GainSwitch1    #C0 S7
C1:ASC-QPDX_GainSwitch2    #C0 S8
C1:ASC-QPDX_GainSwitch3    #C0 S9
C1:ASC-QPDX_GainSwitch4    #C0 S10
C1:AUX-GREEN_X_Shutter2    #C0 S15

12598   Thu Nov 3 16:30:42 2016 LydiaConfigurationSUSETMX to coil matrix expanded

[ericq, lydia]

Background:

We believe the optimal OSEM damping would use an input matrix diagonalized to the free swing modes of the optic, and an output matrix which drives the coils appropriately to damp these free swing modes. As was discovered, a free swinging optic does not necessarily have eigenmodes that match up perfectly with pitch and yaw, however in the current state the "TO_COIL"  output matrix that determines the drive signals in response to the diagonlized sensor output also controls the drive signals for the oplevs, LSC/ASC, and alignment biases. So attempts to diagonalize the output matrix to agree with the input matrix have resulted in problems elsewhere. (See previous elog). So, we want to expand the "TO_COIL" matrices to treat the OSEM sensor inputs separately from the others.

Today:

• We modified the ETMX suspension model (c1scx) to use a modified copy of the sus_single_control block (sus_single_control_mod) that has 3 additional input columns. These are for the sensing modes determined by the input matrix, and are labeled "MODAL POS", "MODAL PIT", and "MODAL YAW."
• The regular POS, PIT, and YAW columns no longer include the diagonalized OSEM sensor signals for ETMX.
• The suspension screen now out of date; it doesn't show the new columns under Output Filters and the summed values displayed for each damping loop do not incluse the OSEM damping.
• The new matrix can be acessed at /opt/rtcds/caltech/c1/medm/c1scx/C1SUS_ETMX_TO_COIL.adl (see Attachment 1). For now, it has the naive values in the new columns so the damping behavior is the same.
• In trying to get a properly generated MEDM screen for the larger matrix, we discovered that the Simulink block for TO_COIL specifies in its description a custom template for the medm autogeneration. We made a new verion of that template with extra columns and new labels, which can be reused for the other suspensions. These templates are in /opt/rtcds/userapps/release/sus/c1/medm/templates, the new one is SUS_TO_COIL_MTRX_EXTRA.adl
• I will be setting the new column values to ones that represent the diagonlized free swing modes given by the input matrix. Hopefully this will improve OSEM damping without getting in the way of anything else. If this works well, the other SUS models can be changed the same way.
Attachment 1: 01.png
12597   Thu Nov 3 13:36:16 2016 ericqUpdateCDSc1pem revamped

It seems that the EX and EY BLRMS banks were missing the BP and LP filters for the 0.03-0.1 and 0.1-0.3 bands. I've copied over the filters from the BS seismometer.

However, if it looks like the integrated C code BLRMS block works out well, we could replace the seismometers' filter module heavy BLRMS blocks and cut down on the PEM model bloat.

12596   Thu Nov 3 12:40:10 2016 gautamUpdateGeneral projector light bulb is out

The projector failed just now with a pretty loud 'pop' sound - I've never been present when the lamp goes out, so I don't know if this is usual. I have left the power cable unplugged for now...

Replacement is ordered Nov 4

12595   Thu Nov 3 12:38:42 2016 gautamUpdateCDSc1pem revamped

A number of changes were made to C1PEM and some library parts. Recall that the motivation was to add BLRMS channels for all our suspension coils and shadow sensor PDs, which we are first testing out on the IMC mirrors.

Here is the summary:

BLRMS_2k library block

• The name of the custom C code block in this library part was named 'BLRMSFILTER' which conflicted with the name of the function call in the C code it is linked to, which lead to compilation errors
• Even though the part was found in /opt/rtcds/userapps/release/cds/c1/models and not in the common repository, just to be safe, I made a copy of the part called BLRMS_2k_40m which lives in the above directory. I also made a copy of the code it calls in /opt/rtcds/userapps/release/cds/c1/src

C1PEM model + filter channels

• Adding the updated BLRMS_2k_40m library part still resulted in some compilation errors - specifically, it was telling me to check for missing links around the ADC parts
• Eric suggested that the error messages might not be faithfully reporting what the problem is - true enough, the problem lay in the fact that c1pem wasn't updated to follow the namespace convention that we now use in all the RT models - the compiler was getting confused by the fact that the BLRMS stuff was in a namespace block called 'SUS', but the rest of the PEM stuff wasn't in such a block
• I revamped c1pem to add namespace blocks called PEM and DAF, and put the appropriate stuff in the blocks, after which there were no more compilation errors
• However, this namespace convention messed up the names of the filter modules and associated channels - this was resolved with Eric's help (find and replace did the job, this is a familiar problem that we had encountered not too long ago when C1IOO was similarly revamped...)
• There was one last twist in that the model would compile and install, but just would not start. I tried the usual voodo of restarting all the models, and even did a soft reboot of c1sus, to no avail. Looking at dmesg, I tracked the problem down to a burt restore issue - the solution was to press the little 'BURT' button next to c1pem on the CDS overview MEDM screen as soon as it appeared while restarting the model

All the channels seem to exist, and FB seems to not be overloaded judging by the performance overnight up till the power outage. I will continue to monitor this...

GV Edit 3 Nov 2016 7pm:

I had meant to check the suitability of the filters used - there is a detailed account of the filters implemented in BLRMSFILTER.c here, and I quickly looked at the file on hand to make sure the BP filters made sense (see Attachment #1). These the BP filters are 8th order elliptical filters and the lowpass filters are16th order elliptical filters scaled for the appropriate frequency band, which are somewhat different from what we use on the seismometer BLRMS channels, where the filters are order 4, but I don't think we are significantly overloaded on the computational aspect, and the lowpass filters have sufficiently steep roll-off, these should be okay...

Attachment 1: BLRMSresp.pdf
12594   Thu Nov 3 11:33:24 2016 gautamUpdateGeneralpower glitch - recovery

I did the following:

• Hard reboots for fb, megatron, and all the frontends, in that order
• Checked time on all FEs, ran sudo ntpdate -b -s -u pool.ntp.org where necessary
• Restarted all realtime models
• Restarted monit on all FEs
• Reset Marconi to nominal settings, fCarrier=11.066209MHz, +13dBm amplitude
• In the control room, restarted the projector and set up the usual StripTool traces
• Realigned PMC
• Slow machines did not need any touchups - interestingly, ITMX did not get stuck during this power glitch!

There was a regular beat coming from the speakers. After muting all the channels on the mixer and pulling the 3.5mm cable out, the sound persisted. It now looks like the mixer is broken

12593   Thu Nov 3 08:07:52 2016 SteveUpdateGeneralpower glitch

Building:         Campus Wide

Date:             Thursday 11/03/16 at Approx. 6:20 a.m.

Notification:     Unplanned City Wide Power Glitch Affecting Campus

*This is to notify you that the Caltech Campus experienced a campus wide power glitch at approx. 6:20 a.m. this morning.

The city was contacted and they do not expect any further interruptions related to this event.

The vacuum was not effected. ITM sus damping restored. IFO room air conditions on.

PSL Innolight and ETMY Lightwave lasers turned on

Attachment 1: powerGlitch.png
12592   Wed Nov 2 22:56:45 2016 gautamUpdateCDSc1pem revamped

installing the BLRMS 2k blocks turned out to be quite non-trivial due to a whole host of CDS issues that had to be debugged, but i've restored everything to a good state now, and the channels are being logged. detailed entry with all the changes to follow.

12591   Wed Nov 2 12:05:00 2016 ericqUpdateASCQuick WFS thoughts

I poked around a bit thinking about what we need for a single AS WFS.

New things that we would need:

Things we have:

• Many Eurocard-style Whitening chassis, such as we use for all of the LSC PDs.
• Enough ADC (c1ioo has two ADCs, but doesn't even use 32 channels, so we can steal one, and throw it into c1lsc)

We'd have 12 new signals to acquire: 4 quadrants x DC, I, Q. In principle the DC part could go into a slow channel, but we have the ADC space to do it fast, and it'll be easier than mucking around with c1iscaux or whatever.

Open question: What to do about AA? A quick search didn't turn up any eurocard AA chassis like the ones we use for the LSC PDs. However, given the digital AA that happens from 64kHz->16kHz in the IOP, we've talked about disabling/bypassing the analog AA for the LSC signals. Maybe we can do the same for the QPD signals? Or, modify the post-demod audioband amplifer in the demod chassis to have some simple, not too agressive lowpass.

12590   Tue Nov 1 09:03:08 2016 SteveUpdateSUSseismic activity is up

Salton See is shaking again.

Attachment 1: seismicActivity.png
12589   Mon Oct 31 16:20:50 2016 SteveUpdateVACRGA is reinstalled

Quad rods and  ionizer kit: consisting of repeller cage, anode grid, focus plate and  filament were replaced....... under repair # RGA200/12 ECA 100416-12967

The electronic ECU is not connected. It is beeing pumped at IFO ITcc 9.7E-6 Torr vacNormal

 Quote: The RGA is removed for repaire. It's volume at atmophere and sealed.. P4 reading of 38 Torr is not correct.

12588   Fri Oct 28 19:13:57 2016 ranaUpdateGeneralPR gain

I don't think the loss of 25 ppm is outrageous. Its just surprisingly good. The SIS model predicted numbers more like 1 ppm / mirror taking into account just the phase map and not the coating defects.

However, we should take into account the lossed in the DRMI to be more accurate: AR coating reflectivities, scatter loss on those surfaces, as well as possible clipping around BS or some other optics.

https://chat.ligo.org/ligo/channels/40m

12587   Fri Oct 28 15:46:29 2016 gautamSummaryLSCX/Y green beat mode overlap measurement redone

I've been meaning to do this analysis ever since putting in the new laser at the X-end, and finally got down to getting all the required measurements. Here is a summary of my results, in the style of the preceeding elogs in this thread. I dither aligned the arms and maximized the green transmission DC levels, and also the alignment on the PSL table to maximize the beat note amplitude (both near and far field alignment was done), before taking these measurements. I measured the beat amplitude in a few ways, and have reported all of them below...

             XARM   YARM
o BBPD DC output (mV), all measured with Fluke DMM
 V_DARK:     +1.0    +3.0  V_PSL:      +8.0    +14.0  V_ARM:      +175.0  +11.0

o BBPD DC photocurrent (uA)
I_DC = V_DC / R_DC ... R_DC: DC transimpedance (2kOhm)  I_PSL:       3.5    5.5  I_ARM:      87.0    4.0

o Expected beat note amplitude I_beat_full = I1 + I2 + 2 sqrt(e I1 I2) cos(w t) ... e: mode overlap (in power) I_beat_RF = 2 sqrt(e I1 I2) V_RF = 2 R sqrt(e I1 I2) ... R: RF transimpedance (2kOhm) P_RF = V_RF^2/2/50 [Watt]      = 10 log10(V_RF^2/2/50*1000) [dBm]
     = 10 log10(e I1 I2) + 82.0412 [dBm]
     = 10 log10(e) +10 log10(I1 I2) + 82.0412 [dBm]

for e=1, the expected RF power at the PDs [dBm]  P_RF:      -13.1  -24.5

o Measured beat note power (measured with oscilloscope, 50 ohm input impedance)        P_RF:      -17.8dBm (81.4mVpp)  -29.8dBm (20.5mVpp)   (38.3MHz and 34.4MHz)       e:        34                    30  [%]                           o Measured beat note power (measured with Agilent RF spectrum analyzer)         P_RF:      -19.2  -33.5  [dBm] (33.2MHz and 40.9MHz)       e:       25     13    [%]                          

I also measured the various green powers with the Ophir power meter:

o Green light power (uW) [measured just before PD, does not consider reflection off the PD]
 P_PSL:       16.3    27.2  P_ARM:       380     19.1

Measured beat note power at the RF analyzer in the control room  P_CR:      -36    -40.5    [dBm] (at the time of measurement with oscilloscope) Expected    -17    - 9    [dBm] (TO BE UPDATED)

Expected Power: (TO BE UPDATED) Pin + External Amp Gain (25dB for X, Y from ZHL-3A-S)     - Isolation trans (1dB)     + GAV81 amp (10dB)     - Coupler (10.5dB)

The expected numbers for the control room analyzer in red have to be updated.

The main difference seems to be that the PSL power on the Y broadband PD has gone down by about 50% from what it used to be. In either measurement, it looks like the mode matching is only 25-30%, which is pretty abysmal. I will investigate the situation further - I have been wanting to fiddle around with the PSL green path in any case so as to facilitate having an IR beat even when the PSL green shutter is closed, I will try and optimize the mode matching as well... I should point out that at this point, the poor mode-matching on the PSL table isn't limiting the ALS noise performance as we are able to lock reliably...

12586   Fri Oct 28 01:44:48 2016 gautamUpdateGeneralPRFPMI model vs data studies

Following Koji's suggestion, I decided to investigate the relation between my Finesse model and the measured data.

For easy reference, here is the loss plot again:

Sticking with the model, I used the freedom Finesse offers me to stick in photodiodes wherever I desire, to monitor the circulating power in the PRC directly, and also REFLDC. Note that REFLDC goes to 0 because I am using Finesse's amplitude detector at the carrier frequency for the 00 mode only.

Both the above plots essentially show the same information, except the X axis is different. So my model tells me that I should expect the point of critical coupling to be when the average arm loss is ~100ppm, corresponding to a PRG of ~17 as suggested by my model.

Eric has already put up a scatter plot, but I reproduce another from a fresh lock tonight. The data shown here corresponds to the IFO initially being in the 'buzzing' state where the arms are still under ALS control and we are turning up the REFL gain - then engaging the QPD ASC really takes us to high powers. The three regimes are visible in the data. I show here data sampled at 16 Hz, but the qualitative shape of the scatter does not change even with the full data. As an aside, today I saw the transmission hit ~425!

I have plotted the scatter between TRX and REFL DC, but if I were to plot the scatter between POP DC and REFL DC, the shape looks similar - specifically, there is an 'upturn' in the REFL DC values in an area similar to that seen in the above scatter plot. POP DC is a proxy for the PRG, and I confirmed that for the above dataset, there is a monotonic, linear relationship between TRX and POPDC, so I think it is legitimate to compare the plot on the RHS in the row directly above, to the plot from the Finesse model one row further up. In the data, REFL DC seems to hit a minimum around TRX=320. Assuming a PRM transmission of 5.5%, TRX of 320 corresponds to a PRG of 17.5, which is in the ballpark of the region the model tells us to expect it to be. Based on this, I conclude the following:

• It seems like the Finesse model I have is quite close to the current state of the IFO
• Given that we can trust the model, the PRC is now OVERCOUPLED - the scatter plot of data supports this hypothesis
• Given that in today's lock, I saw arm transmission go up to ~425, this suggests that at optimal alignment, PRG can reach 23. Then, Attachment #1 suggests the average arm loss is <50ppm, which means the average loss per optic is <25ppm. I am not sure how physical this is, given that I remember seeing the specs for the ITMs and ETMs being for scatter less than 40 25ppm, perhaps the optic exceeded the specs, or I remember the wrong numbers, or the model is wrong

In other news, I wanted to try and do the sensing matrix measurements which we neglected to do yesterday. I turned on the notches in CARM, DARM, PRCL and MICH, and then tuned the LO amplitudes until I saw a peak in the error signal for that particular DOF with peak height a factor of >10 above the noise floor. The LO amplitudes I used are

MICH: 40

PRCL: 0.7

CARM: 0.08

DARM: 0.08

There should be about 15 minutes of good data. More impressively, the lock tonight lasted 1 hour (see Attachment #6, unfortunately FB crashed in between). Last night we lost lock while trying to transition control to 1f signals and tonight, I believe a P.C. drive excursion of the kind we are used to seeing was responsible for the lockloss, so the PRFPMI seems pretty stable.

With regards to the step in the lock acquisition sequence where the REFL gain is turned up, I found in my (4) attempts tonight that I had most success when I adjusted the CARM A slider while turning up the REFL gain to offload the load on the CARM B servo. Of course, this may mean nothing...

Attachment 1: loss.pdf
Attachment 2: REFLDC.pdf
Attachment 3: CriticalCoupling.pdf
Attachment 4: PRFPMI_Oct282016.pdf
Attachment 5: PRFPMI_scatter.pdf
Attachment 6: 1hourPRFPMILock.png
12585   Thu Oct 27 23:29:47 2016 ericqUpdateGeneralPRFPMI locked, arms loss improved

As Gautam mentioned, we had some success locking the PRFPMI last night. (SRM satellite box is still in surgery...)

Unsurprisingly, changing the loss/PRG/CARM finesse means we had to fiddle with the common mode servo parameters a little bit to get things to work. However, before too long, we achieved a first lock on the order of a few minutes. Not long afterwards, we had a nice half hour lock stretch where we could tune up the AO crossover and loop UGFs. The working locking script was committed to SVN. Really, no fundamentally new tactics were used, which is encouraging. (One thing I wondered about was whether a narrower CARM linewidth would still let our direct ALS->REFL11 handoff with no offset reduction work. Turns out it does)

However, the step where we increase the analog CARM gain isn't as bulletproof as it once had been. The light levels "sputter" in and out sometimes if the gain increases are too agressive, and can cause a lockloss. Maybe this is an effect of the narrower linewidth and injecting more ALS noise at high frequencies with the higher CARM bandwidth.

The spatial profiles of the light on the cameras is totally bananas. Here's AS and REFL.

As Koji suggested, here is a 2D histogram of TRY vs REFLDC. It appears that the visibility would max out at 75% or so at arm powers around 400. Indeed, we briefly saw powers that high, but as can be seen on the plot, we were usually a little under 300. Exploring the transmon QPD offset space didn't seem to have much effect here.

One thing that I hadn't looked at in previous locks is coherence with our ground seismometers. It would be cool to have more seismic feedforward, and looking at the frequency domain multiple coherence, it looks like we can win a lot between 1 and 20 Hz. I expected more of a win at 1Hz, though.

Attachment 4: seis_sub.pdf
12584   Thu Oct 27 13:48:20 2016 KojiUpdateGeneralPRFPMI locked, arms loss improved

It is also difficult to have a high arm transmission without having high PRG.

What about to plot the arm trans and the REFL DC power in a timeseries?
Or even in a correlation plot (X: Arm Trans or PRG vs Y: REFL Reflectivity)

This tells you an approximate location of the critical coupling, and allows you to calibrate the PRG, hopefully.

12583   Thu Oct 27 12:06:39 2016 gautamUpdateGeneralPRFPMI locked, arms loss improved
 Quote: Great to hear that we have the PRG of ~16 now! Is this 150ppm an avg loss per mirror, or per arm?

I realized that I did not have a Finesse model to reflect the current situation of flipped folding mirrors (I've been looking at 'ideal' RC cavity lengths with folding mirrors oriented with HR side inside the cavity so we didn't have to worry about the substrate/AR surface losses), and it took me a while to put together a model for the current configuration. Of course this calculation does not need a Finesse model but I thought it would be useful nevertheless.

In summary - the model with which the attached plot was generated assumes the following:

• Arm lengths of 37.79m, given our recent modification of the Y arm length
• RC lengths are all taken from here, I have modelled the RC folding mirrors as flipped with the substrate and AR surface losses taken from the spec sheet
• The X axis is the average arm loss - i.e. (LITMX+LITMY+LETMX+LETMY)/2. In the model, I have distributed the loss equally between the ITMs and ETMs.

This calculation agrees well with the analytic results Yutaro computed here - the slight difference is possibly due to assuming different losses in the RC folding mirrors.

The conclusion from this study seems to be that the arm loss is now in the 100-150ppm range (so each mirror has 50-75ppm loss). But these numbers are only so reliable, we need an independent loss measurement to verify. In fact, during last night's locking efforts, the arm transmission sometimes touched 400 (=> PRG ~22), which according to these plots suggest total arm losses of ~50ppm, which would mean each mirror has only 25ppm loss, which seems a bit hard to believe.

Attachment 1: PRG.pdf
12582   Thu Oct 27 09:38:32 2016 SteveUpdatePEMmouse

We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

Attachment 1: mouse.jpg
12581   Wed Oct 26 16:06:01 2016 JohannesUpdateGeneralAutolocker maintenance

[Gautam, Johannes]

The autolocker was acting up today, Gautam traced it to EPICS channels ( namely C1:IOO-MC_LOCK_ENABLE and C1:IOO-MC_AUTOLOCK_BEAT ) served by c1iool0 not being responsive and keyed the crate. This restored it nominal operation.

12580   Tue Oct 25 18:07:28 2016 KojiUpdateGeneralPRFPMI locked, arms loss improved

Great to hear that we have the PRG of ~16 now!

Is this 150ppm an avg loss per mirror, or per arm?

12579   Tue Oct 25 15:56:11 2016 gautamUpdateGeneralPRFPMI locked, arms loss improved

[ericq,gautam]

Given that most of the post vent recovery tasks were done, and that the ALS noise performance looked good enough to try locking, we decided to try PRFPMI locking again last night. Here are the details:

PRM alignment, PRMI locking

• We started by trying to find the REFL beam on the camera, the alignment biases for the 'correct' PRM alignment has changed after the vent
• After aligning, the Oplev was way off center so that was fixed. We also had to re-center the ITMX oplev after a few failed locking attempts
• The REFL beam was centered on all the RFPDs on the ASDC table

Post the most recent vent, where we bypass the OMC altogether, we have a lot more light now at the AS port. It has not yet been quantified how much more, but from the changes that had to be made to the loop gain for a stable loop, we estimate we have 2-3 times more power at the AS port now.

PRFPMI locking

• We spent a while unsuccessfully trying to get the PRMI locked and reduce the carm offset on ALS control to bring the arms into the 'buzzing' state - the reason was that we forgot that it was established a couple of weeks ago that REFL165 had better MICH SNR. Once this change was made, we were readily able to reduce the carm offset to 0
• Then we spent a few attempts trying to do blend in RF control - as mentioned in the above referenced elog, the point of failure always was trying to turn on the integrator in the CARM B path. We felt that the appearance of the CARM B IN1 signal on dataviewer was not what we are used to seeing but were unable to figure out why (as it turns out, we were locking CARM on POY11 and not REFL11 , more on this later)
• Eric found that switching the sign of the CARM B gain was the solution - we spent some time puzzling over why this should have changed, and hypothesized that perhaps we are now overcoupled, but it is more likely that this was because of the error signal mix up mentioned above...
• We also found the DC coupling of the ITM Oplev loops to be not so reliable - perhaps this has to do with the wonky ITMY UL OSEM, more on this later. We usually turn the DC coupling on after dither aligning the arms, and in the past, it has been helpful. But we had more success last night with the DC coupling turned off rather than on.
• Once the sign flip was figured out, we were repeatedly able to achieve locks with CARM partially on RF - we got through about 3 or 4, each was stable for just tens of seconds though. Also, we only progressed to RF on CARM on 1 attempt, the lock lasted for just a few seconds
• Unfortunately, the mode cleaner decided to act up just about after we figured all this out, and it was pushing 4am so we decided to give up for the night.
• The arm transmissions hit 300! We had run the transmission normalization scripts just before starting the lock so this number should be reliable (compare to ~130 in October last year). The corresponding PRG is about 16.2, which according to my Finesse models suggest we are still undercoupled, but are close to critical coupling (this needs a bit more investigation, supporting plots to follow). => Average arm loss is ~150ppm! So looks like we did some good with the vent, although of course an independent arm loss measurement has to be done...
• Lockloss plot for one of the locks is Attachment #1

Other remarks:

• Attachment #2 shows that the ITMY UL coil is glitchy (while the others are not). At some point last night, we turned off this sensor input to the damping servos, but for the actual locks, we turned it back on. I will do a Satellite box swap to see if this is a Sat. Box problem (which I suspect it is, the bad Sat. Boxes are piling up...)
• Just now, eric was showing me the CM board setup in the LSC rack, because for the next lock attempts, we want to measure the CARM loop - but we found that the input to the CM board was POY and not REFL! This probably explains the sign flip mentioned above. The mix-up has been rectified
• The MICH dither align doesn't seem to be working too well - possibly due to the fact that we have a lot more ASDC light now, this has to be investigated. But last night, we manually tweaked the BS alignment to make the dark port dark, and it seemed to work okay, although each time we aligned the PRMI on carrier, then went back to put the arms on ALS, and came back to PRMI, we would see some yaw misalignment in the AS beam...
• I believe the SRM sat. box is still being looked at by Ben so it has not been reinstalled...
• Eric has put together a configure script for the PRFPMI configuration which I have added to the IFO configure MEDM screen for convenience
• For some reason, the appropriate whitening gain for POX11 and the XARM loop gain to get the XARM to lock has changed - the appropriate settings now are +30dB and 0.03 respectively. These have not been updated in some scripts, so for example, when the watch script resets the IFO configuration, it doesn't revert to these values. Just something to keep in mind for now...
Attachment 1: PRFPMIlock_25Oct2016.pdf
Attachment 2: ITMYwoes.png
12578   Mon Oct 24 11:39:13 2016 gautamUpdateGeneralALS recovered

I worked on recovering ALS today. Alignments had drifted sufficiently that I had to to the alignment on the PSL table onto the green beat PDs for both arms. As things stand, both green (and IR) beats have been acquired, and the noise performance looks satisfactory (see Attachment #1), except that the X beat noise above 100Hz looks slightly high. I measured the OLTF of the X end green PDH loop (after having maximized the arm transmission, dither alignment etc, measurement done at error point with an excitation amplitude of 25mV), and adjusted the gain such that the UGF is ~10kHz (see Attachment #2).

Attachment 1: ALSOutOfLoop20161024.pdf
Attachment 2: XendPDHOLTF20161024.pdf
12577   Fri Oct 21 09:28:21 2016 SteveUpdateVACVac Normal reached

Dry pump of TP3 replaced after 9.5 months of operation.[ 45 mTorr d3 ]

The annulosses are pumped.

Valve configuration: vac normal, IFO pressure 4.5E-5 Torr [1.6E-5 Torr d3 ] on new ITcc gauge, RGA is not installed yet.

Note how fast the pressure is dropping when the vent is short.

 Quote: IFO pressure 1.7E-4 Torr on new not logged cold cathode gauge. P1 <7E-4 Torr Valve configuration: vac.normal with anunulossess closed off. TP3 was turned off with a failing drypump. It will be replaced tomorrow.

All time stamps are blank on the MEDM screens.

Attachment 1: VacNormal.png
12576   Fri Oct 21 02:06:20 2016 gautamUpdateGeneralIFO recovery

The pressure on the newly installed gauge on the X arm was 6E-5 torr when I came in today evening, so I decided to start the recovery process.

1. I first tried working at low power. I was able to lock the IMC as well as the arms. But the dither alignment didn't work so well. So I decided to go to nominal PSL power.
2. I first changed the 2" HR mirror that is used to send all the MC REFL light to the MC REFL PD in low power operation with a 10% BS. I then roughly aligned the beam onto the PD using the tiny steering mirror. At this point, I also re-installed the ND filters on the end Transmon QPDs and also the CCD at the Y end.
3. I then rotated the waveplate (the second one from the PSL aperture) until I maximized the power as measured just before the PSL shutter with a power meter. I then re-aligned the PMC to maximize transmission. After both these steps, we currently have 1.09W of IR light going into the IMC
4. I then re-aligned MC REFL onto the PD (~90mW of light comes through to the PD) and maximized the DC output using an oscilloscope. I then reverted the Autolocker to the nominal version from the low power variant that has been running on megatron during the vent (although we never really used it). The autolocker worked well and I was able to lock the IMC without much trouble. I tweaked the alignment sliders for the IMC optics, but wasn't able to improve the transmission much. It is ~14600 cts right now, which is normal I think
5. I then centered the beams onto the WFS QPDs, ran the WFSoffsets script after turning the inputs to the WFS servos off, and ran the relief script as well - I didn't try anything further with the IMC
6. I then tried to lock the arms - I first used the green to align the test-masses. Once I was able to lock to a green 00-mode, I saw strong IR flashes and so I was able to lock the Y arm. I then ran the dither. Next, I did the same for the X arm. Even though I ran LSCoffsets before beginning work tonight, the Y arm transmission after maximization is ~5, and that for the X arm is ~2.5. I refrained from running the normalization scripts in case I am missing something here, but the mode itself is clearly visible on the cameras and is a 00-mode.
GV edit 21Oct2016: For the Y-arm, the discrepancy was down to TRY being derived from the high gain PD as opposed to the QPD. Switching these and running the dither, TRY now maxes out at around 1.0. For TRX, the problem was that I did not install one of the ND filters - so the total ND was 1.2 rather than 1.6, which is what we were operating at and which is the ND on TRY. Both arms now have transmission ~1 after maximizing with the dither alignment...
7. The AS spot looks nice and round on the camera, although the real check would be to do the sort of scan Yutaro and Koji did, and monitor the ASDC levels. I am leaving this task for tomorrow, along with checking the recycling cavities.
8. Lastly, I centered the Oplevs for all the TMs

12575   Thu Oct 20 15:59:52 2016 SteveUpdateVACPumpdown 80 has completed

IFO pressure 1.7E-4 Torr on new not logged cold cathode gauge. P1 <7E-4 Torr

Valve configuration: vac.normal with anunulossess closed off.

TP3 was turned off with a failing drypump. It will be replaced tomorrow.

Attachment 1: 7hPd80.png
Attachment 2: 8hPd80.png
Attachment 3: 9hPd80.png
12574   Thu Oct 20 09:17:08 2016 SteveUpdateVACPumpdown 80 has started

Pumping again after 7 days at atmosphere.

BS, ITMY and OMC chambers were open only.

Checked: jam nuts, viewport covers and beam shutters.

Oplev servo turned off and medm screens shots taken.

New item in vacuum:  green shade 14 glass beam block at IR-input [ from the PSL ] viewport to block green reflection-scatter.

Reminder: viewport is not AR coated for green!

Attachment 2: beforePd80.png
Attachment 3: pd80at1h.png
Attachment 4: 7d_atm.png
12573   Wed Oct 19 18:32:25 2016 rana, yinziUpdatePSLRefCav thermal control: heater is dead

#### We wanted to re-activate the Heater for the reference cavity today to use it as a testbed for PID autotuning and the new heater driver circuit that Andrew is working on for the coating thermal noise experiment.

Unfortunately, it seems that the large power supply which is used for the heater is dead. Or maybe I don't remember how to use it?

The AC power cord was plugged in to a power strip which seems to work for IO chassis. We also tried swapping power strip ports.

We checked the front panel fuses. The power one was 3 Ohms and the 'bias' one was 55 Ohms. We also checked that the EPICS slider did, in fact, make voltage changes at the bias control input.

Non of the front panel lights come on, but I also don't remember if that is normal.

Have those lights been dead a long time? We also reconnected the heater cable at the reference cavity side.

12572   Wed Oct 19 17:02:34 2016 ranaUpdateGeneral Viewports & coating of 2016

These old specs are not so bad. But we now want to get replacements for the TRX and TRY and PSL viewports that are R <0.1% at 532 and 1064 nm.

I don't know of any issues with keeping BK-7 as the substrate.

12571   Wed Oct 19 16:41:55 2016 gautamUpdateGeneralHeavy doors back on

[ericq, lydia, steve, gautam]

• We aligned the arms, and centered the in-air AS beam onto the PDs and camera
• Misaligned the ITMs in a controlled ramp, observed ASDC level, didn't see any strange features
• We can misalign the ITMs by +/- 100urad in yaw and not see any change in the ASDC level (i.e. no clipping). We think this is reasonable and it is unlikely that we will have to deal with such large misalignments. We also scanned a much larger range of ITM misalignments (approximately +/-1mrad), and saw no strange features in the ASDC levels as was noted in this elog - we used both the signal from the AS110 PD which had better SNR and also the AS55 PD. We take this to be a good sign, and will conduct further diagnostics once we are back at high power.
• Opened up all light doors, checked centering on all 6 OM mirrors again, these were deemed to be satisfactory
• To solve the green scattering issue, we installed a 1in wide glass piece (~7inches tall) mounted on the edge of the OMC table to catch the reflection off the window (see Attachment #1) - this catches most of the ghost beams on the PSL table, there is one that remains directly above the beam which originates at the periscope in the BS/PRM chamber (see Attachment #2) but we decided to deal with this ghost on the PSL table rather than fiddle around in the vacuum and possibly make something else worse
• Re-aligned arms, ran the dither, and then aligned the PRM and SRM - we saw nice round DRMI flashes on the cameras
• Took lots of pictures in the chamber, put heavy doors back on. Test mass Oplev spots looked reasonably well centered, I re-centerd PRM and SRM spots in their aligned states, and then misaligned both
• The window from the OMC chamber to the AS table looked clean enough to not warrant a cleaning..
• PSL shutter is closed for now. I will check beam alignment, center Oplevs, and realign the green in the evening. Plan is to pump down first thing tomorrow morning

AS beam on OM1

AS beam on OM2

AS beam on OM3

AS beam on OM4

AS beam on OM6

I didn't manage to get a picture of the beam on OM5 because it is difficult to hold a card in front of it and simultaneously take a photo, but I did verify the centering...

It remains to update the CAD diagram to reflect the new AS beam path - there are also a number of optics/other in-vacuum pieces I noticed in the BS/PRM and OMC chambers which are not in the drawings, but I should have enough photos handy to fix this.

Here is the link to the Picasa album with a bunch of photos from the OMC, BS/PRM and ITMY chambers prior to putting the heavy doors back on...

SRM satellite box has been removed for diagnostics by Rana. I centered the SRM Oplev prior to removing this, and I also turned off the watchdog and set the OSEM bias voltages to 0 before pulling the box out (the PIT and YAW bias values in the save files were accurate). Other Oplevs were centered after dither-aligning the arms (see Attachment #8, ignore SRM). Green was aligned to the arms in order to maximize green transmission (GTRX ~0.45, GTRY ~0.5, but transmission isn't centered on cameras).

I don't think I have missed out on any further checks, so unless anyone thinks otherwise, I think we are ready for Steve to start the pumpdown tomorrow morning.

Attachment 1: IMG_2332.JPG
Attachment 2: IMG_2364.JPG
Attachment 3: IMG_2337.JPG
Attachment 4: IMG_2338.JPG
Attachment 5: IMG_2356.JPG
Attachment 6: IMG_2357.JPG
Attachment 7: IMG_2335.JPG
Attachment 8: Oplevs_19Oct2016.png
12570   Wed Oct 19 14:43:15 2016 SteveUpdateGeneral Viewports & coating of 2001

Tilted viewports installed in horizontal position. Atm2

Attachment 1: vacViewp2001.PDF
Attachment 2: tiltedViewport.PDF
12569   Wed Oct 19 08:28:11 2016 SteveUpdateSUSITMY_UL

Everybody is happy, except ITMY_UL or satalite box.

Gautam shows perfect form in the OMC chamber.

Attachment 1: 12hrs.png
Attachment 2: vent79.jpg
12568   Tue Oct 18 18:56:57 2016 gautamUpdateGeneralOM5 rotated to bypass OMC, green scatter is from window to PSL table

[ericq, lydia, gautam]

• We started today by checking leveling of ITMY table, all was okay on that front after the adjustment done yesterday. Before closing up, we will have detailed pictures of the current in vacuum layout
• We then checked centering on OMs 1 and 2 (after having dither aligned the arms), nothing had drifted significantly from yesterday and we are still well centered on both these OMs
• We then moved to the BS/PRM chamber and checked the leveling, even though nothing was touched on this table. Like in the OMC chamber, it is difficult to check the leveling here because of layout constraints, but I verified that the table was pretty close to being level using the small (clean) spirit level in two perpendicular directions
• Beam centering was checked on OMs 3 and 4 and verified to be okay. Clearance of beam from OM4 towards the OMC chamber was checked at two potential clipping points - near the green steering mirror and near tip-tilt 2. Clearance at both locations was deemed satisfactory so we moved onto the OMC chamber
• We decided to go ahead and rotate OM5 to send the beam directly to OM6 and bypass the partially transmissive mirror meant to send part of the AS beam to the OMC
• In order to accommodate the new path, I had to remove a razor beam dump on the OMC setup, and translate OM5 back a little (see Attachment #1), but we have tried to maintain ~45 degree AOI on both OMs 5 and 6
• Beam was centered on OM6 by adjusting the position of OM5. We initially fiddled around with the pitch and yaw knobs of OM4 to try and center the beam on OM5, but it was decided that it was better just to move OM5 rather than mess around on the BS/PRM chamber and introduce potential additional scatter/clipping
• OMC table leveling was checked and verified to not have been significantly affected by todays work
• It was necessary to loosen the fork and rotate OM6 to extract the AS beam from the vacuum chambers onto the AP table
• AS beam is now on the camera, and looks nice and round, no evidence of any clipping. Some centering on in air lenses and mirrors on the AP table remains to be done. We are now pretty well centered on all 6 OMs and should have more power at the AS port given that we are now getting light previously routed to the OMC out as well. A quantitative measure of how much more light we have now will have to be done after pumping down and turning the PSL power back up
• I didn't see any evidence of back-scattered light from the window even though there were hints of this previously (sadly the same can't be said about the green). I will check once again tomorrow, but this doesn't look like a major problem at the moment

Lydia and I investigated the extra green beam situation. Here are our findings.

1. There appears to be 3 ghost beams in addition to the main beam. These ghosts appeared when we locked the X green and Y green individually, which lead us to conclude that whatever is causing this behaviour is located downstream of the periscope on the BS/PRM chamber
2. I then went into the BS/PRM chamber and investigated the spot on the lower periscope mirror. It isn't perfectly centered, but it isn't close to clipping on any edge, and the beam leaving the upper mirror on the periscope looks clean as well (only the X-arm green was used for this, and subsequent checks). The periscope mirror looks a bit dusty and scatters rather a lot which isn't ideal...
3. There are two steering mirrors on the IMC table which we do not have access to this vent. But I looked at the beam coming into the OMC chamber and it looks fine, no ghosts are visible when letting the main beam pass through a hole in one of our large clean IR viewing cards - and the angular separation of these ghosts seen on the PSL table suggests that we would see these ghosts if they exist prior to the OMC chamber on the card...
4. The beam hits the final steering mirror which sends it out onto the PSL table on the OMC chamber cleanly - the spot leaving the mirror looks clean. However, there are two reflections from the two surfaces of the window that come back into the OMC chamber. Space constraints did not permit me to check what surfaces these scatter off and make it back out to the PSL table as ghosts, but this can be checked again tomorrow.