Chub has placed the order for two new UPS units (115V for TP2/3 and a 220V version for TP1).

They will arrive within the next two weeks.

Summary:

We can probably learn something about the interferometer / top level BHD plan with an in-air BHD setup, even if the noise is bad. Here are some thoughts about how we would do it. 

LO delivery:

For this first attempt, we don't really care about the PRC filtering. So possible places to pick off an LO beam are:

In all cases, I think the easiest option to actually route whatever beam we choose into a fiber, and then bring it over to whatever cavity we choose to use for an OMC. I'm assuming whatever phase control technique we end up using can cancel the fiber phase noise at relevant frequencies.

LO phase control

• Stress the fiber? This will require us to purchase some custom hardware, and interface it to the CDS system.
• PZT mirror? We should have sufficient hardware available to drive a PI style PZT mirror.

There is a question about the range, but I think these are the only two realistic options we can implement on a reasonable time scale.

OMC:

Again, there are a few options. Here are some pros and cons that come to my mind.

If we can do a vent (we'd just need a single chamber open), I'd go for the option of getting the copper OMC out and using that. Attachment #1 shows the approximate sizes of the various components (OMMT, OMC cavity, DCPDs), while Attachment #2 shows a rough sketch of where things would go on the AP table, with the rectangles approximately to scale.

CDS:

I'd made a c1omc model sometime ago. Basically, I think we have sufficient ADC/DAC channels in the c1ioo machine for any of the options listed above - but using the copper OMC and associated peripherals would allow the easiest interfacing.

Criticisms/comments/thoughts please.

I noticed these streaky lines again today (but they were not a problem last night). It is annoying if we have to reboot this machine all the time. I wonder if this has something to do with missing drivers. When I ran sudo apt update && sudo apt upgrade, I got several lines like (this isn't the whole stack trace)

Is this indicative of the graphics drivers being installed incorrectly? I am hesitant to mess with this because I think in the past, it was always trying to update some graphics driver that crashed the whole machine into some weird state where we have to wipe the drive and do a fresh re-install of the OS.

Should we just follow these instructions? The graphics card is apparently Quadro P400, which is one of the supported ones according to the list of supported devices.

Or just swap donatella and rossa monitors and defer the problem for later?

Here is the procedure for setting up the three new BHD front-ends (c1bhd, c1sus2, c1ioo - replacement). This plan is based on technical advice from Rolf Bork and Keith Thorne.

The overall topology for each machine is shown here. As all our existing front-ends use (obsolete) Dolphin PCIe Gen1 cards for IPC, we have elected to re-use Dolphin Gen1 cards removed from the sites. Different PCIe generations of Dolphin cards cannot be mixed, so the only alternative would be to upgrade every 40m machine. However the drivers for these Gen1 Dolphin cards were last updated in 2016. Consequently, they do not support the latest Linux kernel (4.x) which forces us to install a near-obsolete OS for compatibility (Debian 8).

Hardware

• Servers: SuperMicro 5018R-M [RECEIVED]
• IPC cards: Dolphin DXH510-A0 (PCIe x4 Gen1) [LLO will provide; I've asked Keith Thorne to ship them]
• I/O cards: One Stop Systems OSS-PCIe-HIB25-x4-H-H (PCIe x4 Gen2) [Rich Abbott will provide; part of the I/O chassis hardware we are receiving from aLIGO]
• I/O cables: One Stop Systems OSS-PCIe-CBL-x4-3M (PCIe x4 3m) [RECEIVED]
• IPC cables: Data Storage Cables C5252-40ME-O (fiber optic 40m) [RECEIVED]

Software

• OS: Debian 8.11 (Linux kernel 3.16)
• IPC card driver: Dolphin DX 4.4.5 [works only with Linux kernel 2.6 to 3.x]
• I/O card driver: None required, per the manual

Install Procedure

1. Follow Keith Thorne's procedure for setting up Debian 8 front-ends
2. Apply the real-time kernel patches developed for Debian 9, but modified for kernel 3.16 [these are UNTESTED against Debian 8; Keith thinks they may work, but they weren't discovered until after the Debian 9 upgrade]
3. Install the PCIe expansion cards and Dolphin DX driver (driver installation procedure)

I will be in the Clean and Bake lab today from 9am to 3pm

I wanted to try using rossa as my locking workstation today. However, a few problems became quickly evident. Basically, any of our scripts that rely on the cdsutils package (there are MANY) will not work on rossa, because of some library error. This machine is running Debian 10, while the cdsutils package is being loaded from a pre-compiled install on the shared drive, so perhaps this isn't surprising?

Digging a little more, I found that actually, a version of cdsutils that actually works with python3 is actually shipped with the standard cds-workstation meta-package. This is great news, and we should try and use this where possible I guess. Deferring further debugging for daytime work.

Anyway, I added a symlink: sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5, and installed wmctrl using sudo apt install wmctrl. 

I will be in the clean and bake lab today from 9am to 3pm.

Summary:

I want to be able to run the dither alignment servo with the PRFPMI locked - I've been thinking about what the scheme should be, and I list here some questions I had while thinking about this.

Details:

1. ITM Oplev DC coupling
   • In the current scheme, I DC couple the ITM Oplev servos after the arms have been aligned to maximize POX/POY transmission.
   • However, looking back at data from when the CARM offset is reduced (e.g. Attachment #1), it looks like the ITMs are being torqued quite a bit during this process (ITMX PIT changes by ~20urad, ITMY YAW by ~10urad in this particular lock attempt). 
   • So the spots are not actually being centered on the test-masses? I guess the spot position on ITMX isn't actually controlled because we have only one actuator (BS) for the XARM beam axis. Is it unexpected that ITMY gets torqued so much? 
   • It is unclear what would happen if the ITM Oplev servos are not DC coupled. I wonder if I'd still be able to reach the high circulating powers and then rely solely on the TR QPDs for the arm cavity angular control.
   • Another possibility is to offload the DC part of the control signal to the optic's slow bias voltage slider, and then turn off the DC coupling. After that, the dither alignment can optimize the cavity alignment.
2. Dither alignment at high circulating power
   • I think that the system should work with the same settings as for the POX/POY locking, with the following changes:
     • Scale the overall loop gain by the arm transmission.
     • Change LSC2ASS matrix element from XARM/YARM ---> DARM.
       Does this sound right?
   • In light of the above, I was thinking that we should introduce a gain scaling field in the c1ass RTCDS model (like we have for the LSC power normalization matrix). Is it worth to go through the somewhat invasive process of model recompilation etc?
   • With the PRFPMI locked, I am wondering if I can simultaneously run the dither alignment loops for all the DoFs. Probably not, especially for MICH, since the actuator is the BS, which is also the actuator for the XARM loop?

Last Tuesday evening, while attempting the PRFPMI locking, I noticed a strange feature in the LSC signals, which is shown in Attachment #1 (the PDF exported by dataviewer is 14MB so I upload the jpeg instead). As best as I can tell, the REFL33 and POP22 channels show an abrupt jump in the signal levels, while the other channels do not. POP110 shows a slight jump at around the same time, and the large excursion in AS110_Q actually occurs a few seconds later, and is probably some angular excursion of the PRC/BS. I'm struggling to interpret how this can be explained by some interferometric mechanism, but haven't come up with anything yet. The LO for the 3f error signals is the 2f field, but then why doesn't the POP110 channel show a similar jump if there is some abrupt change in the resonant condition? Is such a change even feasible from a cavity length change point of view? Or did the sideband frequency somehow abruptly jump? But if so, why is the jump much more clearly visible in one sideband than the other?

Does anyone have any ideas as to what could be going on here? This may give some clue as to what's up with the weird sensing matrices, but may also be something boring like broken electronics... 

As suggested last week, Hang and I have reviewed the A+ BHD status (DRD, CDD, and reviewers' comments) and compiled a list of key unanswered questions which could be addressed through Finesse analysis.

In anticipation of others helping with this modeling effort, we've tried to break questions into self-contained projects and estimated their level of difficulty. As you'll see, they range from beginner to Finesse guru.

Indeed, this is now fixed by following instructions from here. I rebooted rossa at ~1250 PDT and confirmed that resolv.conf didn't get overwritten. The resolv.conf file also now has the following useful lines at the head:

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

I will be in the Clean and Bake lab today from 8:30am to 4pm

This is strange - I was definitely able to launch medm when I was working on this machine remotely on Friday. But now, there does seem to be a problem with this shared library being missing.

First of all, I installed mlocate to find where the shared library files are installed. Then I made the symlink, and now sitemap seems to work again.

Weirdly, my changes to /etc/resolv.conf got overwritten somehow. Was this machine rebooted? Uptime suggests it's only been running for ~6 hours at the time of writing of this elog.

I did

sudo usermod -a -G lpadmin controls

and then was able to add Grazia to the list of printers for Rossa by following the instructions on the 40m Wiki.

I installed color syntax highlighting on Rossa using the internet (https://superuser.com/questions/71588/how-to-syntax-highlight-via-less). Now if you do 'less genius_code.py', it will be highlighting the python syntax.

when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
 

in the lab, checkin on the WFS

Sun Jul 5 18:25:50 2020

I redid Gautam's measurements to get a baseline before changing the head, and my results are very different: To me it looks like the WFS2 quadrants are all OK.

Measurement Details:

1. The whole AG4395 + breadboard Jenne laser is wheeled over next to the SW side of the AP table.
2. The output of the 1611 goes into channel R of the 4395
3. I disconnected all the LEMO cables from the head and then plugged a LEMO-BNC cable into the plugs one at a time. The existing LEMO connectors, which take the signals back to the demode board, were all a little loose, so I adjusted them with some pliers (see video).
4. The Atten = 0 dB for all AG4395 channels
5. Source drive = 0 dBm. Checked with a -10 dBm drive that there was no change in the observed TFs, so I guess a 0 dBm drive doesn't make things nonlinear.
6. When I first turned the setup on, the Yellow 'limit' light was ON on the ILX laser current driver, so maybe the modulation wasn't getting to the laser diode as we wish.
7. did not change any WFS MEDM settings for these measurements. Not sure if any of those buttons work anyway.

I've left the setup as is in case either me or Gautam want to double check. If we're agreed on this response, I'll remove the notches and disable the RF attenuators.

Sun Jul 5 21:42:45 2020

maybe we should make a "dd" copy of pianosa in case rossa has issues and someone destroys pianosa by accidentally spilling coffee on it.

As part of an ongoing effort to improve airflow in workspaces/bathrooms on campus, I have installed an air scrubber unit in each of the bathrooms at the 40m lab.

In an effort to make a second usable workstation, I did the following (remotely) on rossa today (not necessarily in this order, I wasn't maintaining a live log so I forgot):

1. Fixed /etc/resolv.conf, so that the other martian machines can be found.
2. Copied over .bashrc file, and the appropriate lines from /etc/fstab from pianosa to rossa.
3. Ran sudo apt install nfs-common. Then ran sudo mount -a to get /cvs/cds mounted.
4. Made symlinks for /users and /opt/rtcds , and /ligo. All of these are used by various environment-setting scripts and I chose to preserve the structure, though why we need so many symlinks, I don't know...
5. Set up the shell variable $NDSSERVER using export NDSSERVER=fb:8088. I'm not sure how, but I believe DTT, awggui etc use this on startup to get the channel list (any
6. Followed instructions from Erik von Reis at LHO to install the cds workstation packages and dependencies. Worked like a charm 🎃! 
7. As a test, I plotted the accelerometer spectra in DTT, see Attachment #1. I also launched foton from inside awggui, and confirmed that the sample rate is inherited and I could designate a filter. But I haven't yet run the noise injection to test it, I'll do that the next time I'm in the lab.
8. Also checked that medm, StripTool and ndscope, and anaconda python all seem to work 👍🏾.

So, in summary, rossa is now all set up for use during lock acquisition. However, until this machine has undergone a few months of testing, we should freeze the pianosa config and not mess with it.

Note that this version of the "crtools" is rather new. Please, use them and if there is an issue, report the errors! I am going to occassionally try lock acquisition using rossa. 

​I looked into how the new UPS devices suggested by Chub would communicate with the vac interlocks. There are several possible ways, listed in order of preference:

• Python interlock service directly queries the UPS via a USB link using the (unofficial) tripplite package. Direct communication would be ideal because it avoids introducing a dependency on third-party software outside the monitoring/control capability of the interlock manager. However the documentation warns this package does not work for all models...
• Configure Tripp Lite's proprietary software (PowerAlert Local) to send SYSLOG event messages (UDP packets) to a socket monitored by the Python interlock manager.
• Configure the proprietary software to execute a custom script upon an event occurring. The script would, e.g., set an EPICS flag channel which the interlock manager is continually monitoring.

I recommend we proceed with ordering the Tripp Lite 36HW20 for TP1 and Tripp Lite 1AYA6 for TP2 and TP3 (and other 120V electronics). As far as I can tell, the only difference between the two 120V options is that the 6FXN4 model is TAA-compliant.

I re-connected the 3 accelerometers located near the MC1/MC3 chamber. It was a bit tedious to get the cabling sorted - I estimate the cable is ~80m long, and the excess length had to be wound around a spool (see Attachment #1), which wasn't really a 1 person job. It's neat-ish for now, but I'm not entirely satisfied. I think we should get shorter cables (~20m), and also mount the pre-amp/power units in a rack instead of leaving it on the floor. The pre-amp settings are x100 for all three channels. The MC2 channels are powered, but are unconnected to the seismometers - it was too tedious to unroll the other spool yesterday. Apart from this, the cable for the "Z" channel had to be re-seated in the strain relief clamp.

I did not enable any of the CDS filters that convert the raw signal into physical units, so for now, these channels are just recording raw counts.

Update 7pm: the spectra in the current config are here - not sure what to make of the MC2_Z channel appearing to show lower noise?

Update July 13 2020 430pm: This afternoon, I hooked up the MC2 accelerometer channels too...

I will be in the Clean and Bake lab from 9am to 4pm today.

This problem reared its ugly head again. I am inclined to believe the problem is electronic and not on the light, since the POY channels seem immune to this issue (see Attachment #1). I will investigate in the daytime tomorrow. Note that while the POX photodiode head has ~twice the transimpedance than POY (per measurement), the POY signal gets amplified by a ZHL-500-HLN amplifier before heading to the demod electronics (nominal gain is 19dB = x9). There is also some imbalance in the light level at the photodiodes I guess, because overall, the PDH fringe is ~twice as large for the Y arm as the X arm. Basically, the y-axes of the attached plot cannot be directly compared between POX and POY.

Mostly this is an annoyance - right now, the POX signal is only used for locking and dither aligning the X arm cavity, and so once that is done, the locking can proceed (as long as the other channels, e.g. REFL11, aren't glitching as well...)

Summary:

I injected some sensing lines and measured their responses in the various photodiodes, with the interferometer in a few different configurations. The results are summarized in Attachments #1 - #3. Even with the PRMI (no arm cavities) locked on 1f error signals, the MICH and PRCL signals show up in nearly the same quadrature in the REFL port photodiodes, except REFL165. I am now thinking if the output (actuation) matrix has something to do with this - part of the MICH control signal is fed back to the PRM in order to minimize the appearance of the MICH dither in the PRCL error signal, but maybe this matrix element is somehow horribly mistuned?

Details:

Attachment #1:

• ETMs were misaligned and the PRMI was locked with the carrier resonant in the cavity (i.e. sidebands reflected).
• The locking scheme was AS55_Q --> MICH and REFL11_I --> PRCL.

Attachment #2:

• The PRFPMI was locked. The vertex DoFs were still under control using 3f error signals (REFL165_I for PRCL and REFL165_Q for MICH).
• Still, the MICH/PRCL degeneracy in all photodiodes except REFL165 persists.

Attachment #3:

• Nearly identical configuration to Attachment #2.
• The main difference here is that I applied some offsets to the MICH and PRCL error points.
• The offsets were chosen so that the appearance of a ~300 Hz dither in the length of MICH/PRCL was nulled in the AS110_Q / POP22_I signals respectively.
• For the latter, the appearance of this peak in the POP110_I signal was also nulled, as it should be if our macroscopic PRC length is set correctly.
• The offsets that best nulled the peak were 110 cts for PRCL, 25 cts for MICH. The measured sensing response is 1e12 cts/m for PRCL in REFL165_I and 9.2e11 cts/m for MICH in REFL165_Q. So these offsets, in physical units, are: 110 pm for PRCL and 27 pm for MICH. They seem like reasonable numbers to me - the PRC linewidth is ~7.5 nm, so the detuning without any digital offset applied is only 1.5% of the linewidth.
• Note that I changed the POP22/POP110 demod phases to maximize the signal in the I quadrature. The final numbers were -124 degrees / -10 degrees respectively.
• Yet another piece of evidence suggesting these were the correct offsets is that the DC value of POX and POY were zero on average after these offsets were applied.
• However, the MICH/PRCL responses in the 1f REFL port photodiodes remain nearly degenerate.

Some other mysteries that I will investigate further:

1. While POP22 indicated stable buildup of 11 MHz power in the PRC, I couldn't make any sense of the AS110 signals at the dark port - there was large variation of the signal content in the two quadratures, so unlike the POP signals, I couldn't find a digital demod phase that consistently had all the signal in one of the two quadratures. This is all due to angular fluctuations?
2. My ASC simulations suggest that the POP QPD is a poor sensor of PRM motion when the PRFPMI is locked. However, I find that turning on a feedback loop with the POP QPD as a sensor and the PRM as the actuator dramatically reduces the low-frequency fluctuations of the arm cavity carrier buildup. 🤔

I blew the long lock last night because I forgot to not clear the ASS offsets when trying to find the right settings for running the ASS system at high power. Will try again tonight...

I will be in the clean and bake lab today from 9am to 4pm.

Sigh. Do we have a spare sat box?

A more comprehensive report has been uploaded here. I'll zip the data files and add them there too. In summary:

1. There are several problems with the WFS heads
   • Some attenuators don't seem to work. This could be a problem with the Acromag BIO, or with the relay on the head itself.
   • The measured transimpedance at 29.5 MHz is much lower than expected. We expect ~50 kohms with no attenuation, and 5 kohms without. I measure 100 ohm - 2 kohm with the attenuation disabled, and ~200 ohms with it enabled.
   • Quadrant #3 on both WFS heads behaves differently from the others. There is also evidence of a 200 MHz oscillation for quadrant 3.
   • For some reason, there is a relative minus sign between the TFs measured for the WFS and for the RFPDs. I don't understand where this is coming from - all the OpAmps in the LSC PDs and WFS heads are configured as non-inverting, so why should there be a minus sign? Is this indicative of the polarity of the LEMO output being somehow flipped?
2. POX 11 photodiode does not have a notch at 22 MHz.
3. AS55 resonance appears to have shifted closer to 60 MHz, would benefit from a retuning. But the notches appear fine.
4. PDA10CF photodiode used as the POP22/POP110 readback appears broken in some strange way. As shown in the linked document, a spare PDA10CF in the lab has a much more reasonable response, so I am going to switch out the POP22/POP110 diode with this spare.

I'll upload the data and analysis notebook + liso fit files to the wiki as well shortly. The data, a Jupyter notebook making the plots, and the LISO fit files have been uploaded here.

I didn't do it this time but it'd be nice to also do the noise measurement and get an estimate for the shot-noise intercept current.

There was no improvement to the situation overnight. So, I did the following today:

1. Ramped bias voltages for SRM and MC1 to 0, shutdown watchdogs.
2. Switched SRM and MC1 satellite boxes. The SRM satellite box lid was opened, while the MC1 lid was left open. The boxes have also been re-labelled lest there be some confusion about which box belongs where.
3. Restored watchdogs and bias voltages. Curiously, the MC1 optic now only requires half the bias voltages it did before to have the correct DC alignment for the optic. The Satellite box is just supposed to be a passive conduit for the drive current, so this is indicative of some PCB traces/cabling being damaged inside what was previously the MC1 satellite box?

IMC is now locked again, I will monitor for glitching/stability.

Update 6pm PDT: as shown in Attachment #1, there is a huge difference in the stability of the lock after the sat box swap. Let's hope it stays this way for a while...

I will be in the Clean and Bake lab today from 11:30am to 4pm

Hmm I can't seem to export with the colorbar, might be just my phone though. I tried to add some "cursors" with the temperature at a few spots, but the font color contrast is poor so you have to squint really hard to see the temperatures in the photo I attached.

I'll leave the MC1 box open overnight and see if that improves the situation, and if not, I'll switch in the SRM satellite box tomorrow.

does the FLIR have an option to export image with a colorbar?

How about just leave the lid open? or more open? I don't know what else can be done in the near term. Maybe swap with the SRM sat box to see if that helps?

Judging by the summary pages, some 18 hours after this change was made and the board re-installed, the MC1 shadow sensors began to report frequent glitches. I can't think of a plausible causal connection, especially given the 18 hour time lag, but also hard to believe there isn't one? As a result, the IMC is no longer able to stay locked for extended periods of time. I did the usual cable squishing, and also took off the lid to see if that helps the situation.

While the reduced series resistance means there is more current flowing through the slow path, 

1. There isn't actually an increase in the net current flowing through the satellite box - this change just re-allocates the current from the fast path to the slow path, but by the time it reaches the satellite box, the current is flowing through the same conductor.
2. afaik, the current buffers on the coil driver aren't overdriven - they are rated for 300 mA. No individual coil is drawing more than 30 mA.
3. the resistors themselves should be running sufficiently below their rated power of 3W (I estimate 2.5 V ^2 / 100 ohms ~ 60 mW).
4. The highest current should be through the UL and LR coils according to the voltage outputs from the Acromag. But the UL coil doesn't show significant glitching, and the LL one does despite drawing negligible DC current.

The attached FLIR camera image re-inforces what we already know, that the thermal environment inside the satellite box is horrible. The absolute temperature calibration may be off, but it was difficult to touch the components with a bare finger, so I'd say its definitely > 70 C.

Summary:

While the vacuum system was knocked out, I measured the RF transimpedance (using the AM laser setup, didn't do the shot noise intercept current measurement for now) of all the RFPDs (except PMC REFL). At the very least, the following photodiodes are suspect:

1. WFS heads - expected transimpedance is 50 kohm unattenuated, and 5 kohm attenuated. I measure values that are x10 lower than this, and the segments are significantly imbalanced. Morover, the attenuators for some quadrants appear to do nothing. This could be a problem with the Acromag system I guess, but the measured transimpedance is nowhere close to the "expected" value. See Attachments #1 and #2. You can also see that the response at 55 MHz is significantly attenuated, so I'm guessing trying to measure the AS port ASC sensing response is going to be difficult.
   
   Note that I assumed a 1kohm DC transimpedance, which is what I expect from the schematic and also is consistent with the DC voltage I measured, knowing the approximate optical power incident on the photodiode.
2. POP 22/ POP 110 - this is a Thorlabs PDA10CF diode. It should have a flat gain profile out to ~100 MHz, but I measure some weird features. The other PDA10CF we use, at AS110, shows a more reasonable response. See Attachment #3. I don't know what kind of failure mode this is? Anyway I'll try testing another PDA10CF and if it looks more reasonable, I'll switch out this diode. FWIW, the measured AS110 gain is ~3kohms, whereas the datasheet tells us to expect 5 kohms.

For the remaining photodiodes, I measure a transimpedance that is within ~20% of what is on the wiki page. The notches may benefit from some retuning. While I have the data, I will fit this and post a more complete report on the wiki.

Update July 6 1145am: WFS response plots now have legends mapping quadrants, and I've also added the response of a spare PDA10CF (which is now the new POP22/POP110 photodiode).

I will be in the Clean and Bake lab today from 11am to 4pm.

I implemented this change today. We only had 100 ohm, 3W resistors in stock (no 200 ohm with adequate power rating). Assuming 10 V is dropped across this resistor, the power dissipation is V^2/R ~ 1 W, so we should have sufficient margin. DCC entry has been updated with new schematic and photo of the component side of the board. Note that the series resistance of the fast actuation path was untouched.

As expected, the requested voltage no longer exceeds the Acromag DAC range, it is now more like 2.5 V. However, I still notice that the MC REFL spot moves somewhat diagonally on the camera image - so maybe the coil gains are seriously imbalanced? Anyway, the WFS control signals can once again be safely offloaded to the slow bias voltages once again, preserving the fast ADC range for other actuation.

The Johnson noise of the series resistor has now increased by a factor of 2, from ~6.4 pA/rtHz to 12.8 pA/rtHz. Assuming a current to force coefficient of 1.6 mN/A per coil, the length noise of the cavity is expected to be 12.8e-12 * 0.064/0.25/(2*pi*100)^2 ~ 8e-18 m/rtHz at 100 Hz. In frequency units, this is 80 uHz/rtHz. I think our IMC noise is at least 10 times higher than this at 100 Hz (in any case, the noise of the coil driver is NOT dominated by the series resistance). Attachment #1 confirms that there isn't any significant MCF noise increase, and I will check with the arm cavity too. Nevertheless, we should, if possible, align the optic better and use as high a series resistance as possible.

The watchdog for MC1 was disabled and the board was pulled out for this work. After it was replaced, the IMC re-locks readily.

I will be in the Clean and Bake lab from 11pm to 4pm

This earthquake tripped all suspensions and ITMX got stuck. The watchdogs were restored and the stuck optic was released. The IFO was re-aligned, POX/POY and PRMI on carrier locking all work okay.

Per the discussion at the meeting today, the plan of action is:

1. Lock the PRMI on carrier and measure the sensing matrix, see if the MICH and PRCL signals look sensible in 1f and 3f photodiodes.
2. Try locking CARM on POP55 (since there is currently no POP55 photodiode, can we use POX/POY as an intermediary?).
3. For the ASC, can we hijack one of the IMC WFS heads to study what the AS port WFS signals would look like, and maybe close a feedback loop on the ETMs?
   • My guess is no, because currently, the L2A is so poorly tuned on MC2 that the CARM length control messes with the alignment of the IMC significantly.
   • So we need the IMC WFS loops to maintain the pointing.
   • Of course, the MC2 L2A can be tuned to mitigate this problem. 
   • I also believe there is something funky going on with the WFS heads. More to follow on that in a later elog.
   • Apart from these issues, for this scheme to be tested, some mods to the c1ioo model will have to be made so that we can route the servo output to the ETMs (as opposed to the IMC mirrors as is the usual case).

If I missed something, please add here.

I will be in the Clean and Bake lab today from 10am to 4pm.

I propose we go for all CAPS for all channel names. The lower case names is just a holdover from Steve/Alan from the 90's. All other systems are all CAPS.

It avoids us having to force them all to UPPER in the scripts and channel lists.

This work is finally complete. The dry pump replacement was finished quickly but the controls updates required some substantial debugging.

For one, the mailer code I had been given to install would not run against Python 3.4 on c1vac, the version run by the vac controls since about a year ago. There were some missing dependencies that proved difficult to install (related to Debian Jessie becoming unsupported). I ultimately solved the problem by migrating the whole system to Python 3.5. Getting the Python keyring working within systemd (for email account authentication) also took some time.

Edit: The new interlock flag channel is named C1:Vac-interlock_flag.

Along the way, I discovered why the interlocks had been failing to auto-close the PSL shutter: The interlock was pointed to the channel C1:AUX-PSL_ShutterRqst. During the recent c1psl upgrade, we renamed this channel C1:PSL-PSL_ShutterRqst. This has been fixed.

The main volume is being pumped down, for now still in a TP3-backed configuration. As of 8:30 pm the pressure had fallen back to the upper 1E-6 range. The interlock protection is fully restored. Any time an interlock is triggered in the future, the system will send an immediate notification to 40m mailing list. 👍

The machine needed a hard reboot as it was un-ssh-able. 

The exact time that the machine went down is unknown because the blinkys were not DQ-ed. I've now added these to the EDCU to make these channels actually useful, and we may look back on the reliability (or otherwise) of the Acromag system. To my memory, this is the ~5th time one of the new Acromag servers has needed a hard reboot. While this may be less frequent (?) than the VME machines, perhaps there is some other reason for these dropouts. Maybe something to do with the martian network?

Anyway the machine is back up and running now.

I will be at the 40m today from 11am to 4pm.

The vac system is going down at 11 am today for planned maintenance:

• Re-install the repaired TP2 and TP3 dry pumps [ELOG 15417]
• Incorporate an auto-mailer and flag channel into the controls code for signaling tripped interlocks [ELOG 15413]

We will advise when the work is completed.

The PSL shutter was closed from the vacuum interlock trip. Today, I did the following:

• Re-aligned input beam to PMC to recover high transmission / low reflection.
• Re-set the LSC offsets.
• ETMX watchdog was tripped. Reset it.
• Opened the PSL shutter, IMC autolocker was able to lock the cavity almost immediately.
• Tested POX/POY locking, ran the ASS to maximize single arm transmission.

All looks good for now. I will probably get back to PRFPMI locking Monday.

Summary:

I want some input about what the short-term (next two weeks) commissioning goals should be.

Details:

Before the vacuum fracas, the locking was pretty robust. With some human servoing of the input beam, I could maintain locks for ~1 hour. My primary goals were:

1. Transition the vertex length DoF control from 3f signals to 1f signals.
2. Turn on some MICH-->DARM feedforward cancellation, because the noise between ~100 Hz and ~1kHz is dominated by this cross-coupling.

I didn't succeed in either so far.

1. I find that there is poor separation of the length DoFs in the 1f sensors, which makes this transition hopeless.
   • Why should this be? I can't get any sensing matrix in Finesse to line up with what I measure in-lock.
   • One hypothesis I came up with (but haven't yet tested) is that the offsets from the 3f photodiodes are changing from time to time, which somehow changes the projection of the various DoFs onto the photodiode quadratures. 
   • The attached GIF shows the variation in the measured sensing matrix on two days - while the sensing of MICH/PRCL in the 3f photodiodes have hardly changed, they are significantly different in the 1f photodiodes. Note that the I and Q have changed for REFL11 and REFL55 between the two days because I changed the demod phase.
   • I also thought that maybe the CARM suppression isn't sufficient for REFL11 to be used as a PRCL sensor - but even after engaging a CM board SuperBoost, I was unable to realize the PRCL 3f-->1f transition, even though the CARM-->REFL11 coupling did get smaller in the measured sensing matrix (red line in the GIF). I don't think we can juice up the CARM gain much more without modifying the CM board boosts, see Attachment #1.
2. I was able to measure the MICH CTRL --> DARM ERR transfer function with somewhat high coherence (~0.98).
   • I then used the infrastructure available in the LSC model to try and implement some cancellation, but didn't really see any effect.
   • Perhaps the TF needs to be measured with higher coherence.
   • It may also be that if I am able to successfully execute the 3f-->1f transition, the coupling gets smaller because the 1f sensing noise is lower?

I guess apart from this, we want to run the ALS scan to try and infer something about the absorption-induced thermal lens. I guess at this point, the costs outweigh the benefits in trying to bring in the SRC as well, since we will be changing the SRC config?

Summary:

In ELOG 15368, I had claimed that the POP QPD based feedback servo actuating on the PRM stabilized the lock. I now believe this scheme of sensing using the POP QPD and feeding back to the PRM is not a good topology for stabilizing the PRC angular motion.

Details:

• I was never able to get a measurement of the OLTF of this loop that made sense 
  • the loop was initally commissioned with the PRMI locked on the carrier, and the settings hence inferred to give a ~5 Hz UGF loop were used in the PRFPMI lock.
  • In the PRFPMI configuration, however, the loop gain seemed way too low when I measured using the usual IN1/IN2 method.
  • So it is critical for the lock stability that the angular feedforward works well, which it kind of does now (not that I have changed anything, but the glitches in the seismometer have not resurfaced recently).
  • Hopefully, this becomes less of an issue once we replace the TTs with SOS and OSEM based damping.
• To get some more insight, I did some finesse modeling
  • Attachment #1 shows the sensing response at the QPDs we have available currently (POP and TR). 
  • I included the telescopes (propagation distances, in-air lenses) to these QPDs as best as I could.
  • A simplified model (3 mirror coupled cavity) is used, so there isn't really a common/differential mode in this picture, but we still get some insight I think.
  • Specifically, once the full lock is realized, the PRC optic motion isn't sensed well with our QPDs, and so it was some fluke that turning on these PRC angular feedback loops worked. 
  • Attachment #2 shows the same info as Attachment #1, but with the pendulum transfer functions (and radiation pressure effects) included. The SOS suspensions are modelled as f0=0.7/0.8 Hz (for P/Y), Q=5, while the tip-tilts have f0~5 Hz, Q~10. The high frequency phase is 0 degrees and not 180 as expected because of the pendulum complex pole pair because of the way the quantity is computed in Finesse.
• The current scheme I use is:
  • DC couple the ITM oplevs, using their individual Oplev QPDs.
  • Use the TR QPDs, mixed to actuate on the ETMs in a common/differential way.
  • I think the system is under-determined with the sensors we currently have - we wan't to sense the 10 angular modes - PIT and YAW for the PRC, Csoft, Chard, Dsoft and Dhard (using the terminology from Kate's thesis), but we only have 6 sensors of the same field (POP, TRX and TRY QPDs, PIT and YAW from each).
  • So we need more sensors?
• One thing that can easily be improved I think is to make the ASS system work at high power. 
  • I think this should be as simple as scaling the gain for the loops to work for the high power.
  • Then we can counteract the input pointing drift at least.
  • But the ITM Oplev DC coupling would need to be turned OFF and then ON again, I'm not sure if this will introduce some transient that will destroy the lock...

I would also like to bring up the topic of implementing some WFS for the interferometer fields again, there doesn't seem to be any mention of this in the procurement/planning for the BHD. It is not obvious to me yet that we need WFS and not just DC QPDs from a noise point of view, but at least we should discuss this.

Tip Seals were replaced on the forepumps for TP2 and TP3, and both are ready to be installed back onto the forelines.

TP2 Forepump Ultimate Pressure: 180 mtorr

TP3 Forepump Ultimate Pressure: 120 mtorr

The four 4x25DSUB and single 8x25DSUB feedthrough flanges have arrived and will be picked up from the dock and brought to the 40M lab.