I've applied LQR feedback technique to BS oplev in pitch. I think the most inconvenient thing in using LQR controller is the amount of additional states created during cost function shaping. It requires 1 filter bank for each state. To avoid this I wrote state estimation code so all states are calculated inside one function.

On the plots below cost function and oplev feedback controller performance are shown.

The BS oplev has been misbehaving and kicking the optic from time to time since noon. The kicks are not strong enough to trip the watchdogs (current watchdog max counts for the sensors is 135).

I took a look at the spectrum of the BS oplev error in pit and yaw with both loops enabled while the optic was stable. There is nothing alarmingly big except for some additional noise above 4Hz.

I have turned the BS oplev servo OFF for now.

I saw this kicking before  

I think that this happens when the beam gets too close to the edge of the QPD.  We see this regularly in the ETMs, if they've been kicked a bit, but not enough to trip the watchdogs.  I think it might be the step/impulse response of the RES3.3 filter, which rings for almost 20 seconds. 

Anyhow, I've just recentered the BS oplev.  It was at -21urad in pitch, and had more than 400 counts on the top two quadrants, but only about 100 counts on the bottom two.  Now it's around 300 counts on all 4 quadrants.

As a totally unrelated aside, I have installed texlive on Donatella, so that I could run pdflatex.

The BS oplev servo was kicking up the BS. It was turned off

Healthy BS oplev

 I repeated the BS oplev spectrum today and I do not understand why it does look different. I did it as Kiwamu describes it in entry#4948  The oplev servo was left ON!

 It is working today! Finally I repeated the BS spectra, that we did with Kiwamu last week

Kiwamu and Steve,

The He/Ne oplev shows no coherece so relative intensity noise is not limiting factor for the oplev servo

Yesterday I inspected this BS oplev viewport. The heavy connector tube was shorting to table so It was moved back towards the chamber. The connection is air tight with kapton tape temporarly.

 The beam paths are well centered. The viewport is dusty on the inside.

The motivation was to improve the oplev noise.

[Sendhil, Yuta]

After aligning IFO and putting the access connector on, we also centered IPANG/IPPOS and all oplevs (except SRM).
To avoid clipping of PRM/BS oplevs, we re-arranged oplev steering mirrors on BS table.

What we did:
  1. Checked IPANG comes out unclipped after putting on the access connector.
  2. Centered IPANG on its QPD.
  3. Checked oplevs beams for ITMX/ITMY centered on in-vac mirrors, and centered them on their QPDs.
  4. Checked IPPOS beam is centered on the mirrors inside BS chamber, and centered IPPOS on its QPD.
  5. Tweaked oplev mirrors on BS chamber to make PRM/BS oplev beam unclipped and centered on mirrors, and centered them on their QPDs. To avoid clipping of oplev beams in BS table, we re-arranged oplev steering mirrors on BS table (outside the vaccum).


Current status:
  QPD values, IFO_ALIGN/MC_ALIGN screens, OSEM values attached.

  - IR incident beam and IFO aligned
  - X/Y end green coming out to PSL table (in higher order modes)
  - IPANG/IPPOS available
  - All oplevs available
  - AS/REFL/POP cameras ready
  - access connector, ETMX/ETMY heavy doors on
  - ITMX/ITMX/BS heavy doors are not on
  - AS/REFL/POP PDs not centered
  - POX/POY/TRX/TRY not aligned
  - AS beam coming out of the OMC chamber low by ~ 1 beam diameter (my bad)


Tomorrow:
  - Align AS/REFL/POP PD and lock PRMI
  - Take pictures of ITMX/ITMY/BS stacks
  - Put heavy doors on ITMX/ITMY/BS chambers
  - Start pumping down

Please confirm the SRM OL beam is not too bad and also find where the mis-aligned SRM puts its beam. WE want to be sure that there is not too much unwanted scattering from SRM into the PRFPMI.

 Jenne, Annalisa & Steve

We will open the BS and ITMY doors first thing tomorrow morning. I plan to try to be in around 9 am. The first order of business will be to flip the folding mirrors that are not currently flipped (SR2, SR3, PR3).

[Gabriele, Jenne]

We have implemented 4Hz resonant gains for both PRM and BS yaw.  The filter was already in place for PRM Yaw, so we just turned it on, but we also copied the filter over to BS Yaw.  We also changed the 3.3Hz res gain and the ELP for the PRM servo to match the BS servo, since after implementing the 4Hz gain, PRM was still much noisier than BS.  Now the 2 servos match, and PRM is a little quieter.  We hope that tonight's locking might be a little more stable after this work.

I found that the BS/PRM OL SUM channels were reading close to 0. So I went to the optical table, and found that there was no beam from the HeNe. I tried power-cycling the controller, there was no effect. From the trend data, it looks like there was a slow decay over ~400000 seconds (~ 5 days) and then an abrupt shutoff. This is not ideal, because we would have liked to use the Oplevs as a DC alignment reference during the ventI plan to use the AS camera to recover some sort of good Michelson alignment, and then if we want to, we can switch out the HeNe.

*How can I export PDF from NDscope?

I replaced the BS/PRM Oplev HeNe with one of the heads from the SP table where Steve was setting up the OL RIN/pointing noise experiment. The old one was dead. The new one outputs 3.2 mW of power, I've labelled it with this number, serial number and date of replacement. The beam comes out of the vacuum chamber for both the BS and PRM, and the RIN spectra (Attachment #1) look alright. The calibration into urad and loop gains possibly have to be tweaked. Since the beam comes out of vacuum, I say that we shouldn't open the BS/PRM chamber for this vent - we don't have a proper plan for the in-air layout yet, so we can add this to the list of to-dos for the next vent.

I think we are down to our last spare HeNe head in the lab - @Chub, please look into ordering some more, the ITMX HeNe is going to need replacement soon.

[Koij Hiroki]

While KA was working on the DAC issue, BS/PRM/SRM Oplev died.

It seems that the BS/PRM/SRM HeNe died and was replaced in 2019 (4yrs + 200 days ago) and 2021 Jan (2yrs + 209 days ago).

We have no energy to work on the HeNe replacement tonight. This needs to be done on Monday.

Tag: OPLEV oplev HeNe died dead

[JC, Paco]

We replaced the HeNe laser for the BS/PRM/SRM Oplev.

After we found a 1103P head replacement in a cabinet along the YARM, JC and I swapped the Oplev laser for BS/PRM/SRM. The head's form factor was the same luckily so we didn't struggle much to recover the QPD signals for BS and PRM. The final alignment aimed to restore ~ 5400 counts in BS (SUM_INMON) and ~ 3100 counts in PRM (SUM_INMON) when aligned.

Found that the BS whitening was off. Gautam says that "it has always been that way" and "there's nothing in the elog about this" and "I have no special relationship with Putin".

I looked at DV and DTT while turning the OSEM whitening back on. As expected, the sensor noise improved by 10x above 10 Hz. The time series shows no problems - its just less fuzzy now.

All OSEM spectra after the switch show on upper panel of plot. Lower panel shows comparison of BS UL before/after. To rotate the DTT PDF landscape output I typed this:

pdftk BS-white.pdf cat 1N output BSwhite.pdf

"if you see something, do something"

I tried to run the seismic StripTool tonight, which seems liek a simple task. But instead I fell through the rabbit hole again...

The seismic.stp couldn't be run from zita/op340m because zita doesn't have EPICS or MEDM and because the op340m version of StripTool cannot load the new file format in which rossa/pianosa save their files.

Once I got it running by sshing in to rossa, I noticed that the BLRMS trends didn't make any sense. Correctly guessed that this was because all of the BP and LP filters were off. Why? Because of bad BURT, that's why.

As it turns out (if you look through the autoburt logs), several of our FE machines haven't been correctly saving snapshots because of some channel count mismatch between old and new SNAP files. So we are not getting the settings restored correctly for these systems when they get booted. Probably, someone has got to suss out the source of the BURT snap messages; it may be that we have to rehash the snap process after any substantial model rebuild.

For c1pemepics, I did a manual restore from the time when Mirko last ELOG'd that BLRMS was trending OK (Nov 23 @ 3 AM).

Seems like we should also get some kind of auto email warning if the BURTs fail in this way. Otherwise, we'll lose a lot of work if it goes on for weeks.

Bottom line: fix the autoburt so that it doesn't fail after model rebuilds.

I *finally* figured out how to bend Matlab to my will, and close a very simple oplev loop using LQR technology. 

This is super, super simple, but it's a step in the right direction.  There is no noise, just a simple pendulum with a resonant frequency of 0.75Hz, and a Q of 10.  The LQR tries to keep the position of the pendulum at a minimum, and does not care at all about the velocity.  You cannot (with Matlab's LQR, at least that I can find) make it care "0" about the control output, so it cares about the control output a factor of 1e-4 as much as the position.

Here are some plots:

The first plot has the open loop system (just the pendulum, no control at all), as well as the closed loop system (the pendulum under control).

Plot 2 is the open loop gain of the controller that the LQR designed.

Plots 3 and 4 are the step and impulse responses of the open loop (pendulum with no control), and closed loop (pendulum with feedback) systems.

The conclusion from the plots (if this were an interesting system) is that it doesn't take much to damp an ideal pendulum.  The real conclusion here is that I think I now know how to use the Matlab LQR function, and can make a loop with some noise now.

Did someone unlock the back door by the (unofficial) bike storage lately?  Out of habit, I checked the door behind me while about to leave, and it is unlocked. 

Please recall that if you leave through that door, it should automatically lock behind you (if it was locked already), however if you unlock and enter through the back door, it stays unlocked until someone locks it again.

(Obviously, I'm locking the door before I actually go).

[Steve, Kiwamu, Jenne]

The 40m is now back in Laser Hazard mode.  Safety glasses are required for entry into the LVEA / IFO room.

The insects and the laser trouble... Strange coincidences with LHO surprised me, but now I have been relieved.

The refreshed ALS didn't look so bad today (elog forthcoming), so I decided to give PRFPMI locking a shot tonight. I was able to hold the PRMI while swinging through resonsance, but transitions to RF signals failed. Demod angles / whitening gains/ etc. etc. all need to be rechecked

Some little things here and there that got cleaned up...

• The PRM oplev beam was being blocked. Why? I removed the block. Should recheck OLTF/spot size on QPD. 
• ALS -> CARM, DARM signs changed, maybe because I've used the delayed beat as the RF input on the demod board, whereas I imagine it may have been the LO in the beatbox. No big deal.
• REFL165 whitening gain and input matrix updated. Should recheck demod angles.
• PRMI triggering settings weren't being set in the script. It's important to include arm transmission signals, since POP2F signals can momentarily dive when swinging through resonance. 
• I should revisit phase tracker UGF normalization. I/Q amplitudes are varying quite a bit from lock to lock. 
• PRC angular feedforward disabled for now; need to remeasure the witness/target data with DC coupled ITM oplevs
• I think there has been a little bit of MC servo tweaking since our last locks, may need to recheck AO TF / gains. 

[Joe, Jenne]

The nightly backup of the frames and the /cvs/cds directories is back up and running.  We are free again to do crazy stuff at will, and it will all be saved for eternity.

Tega mentioned in the meeting that it could be safer to separate some of nodus's functions from the martian file system.
That's an interesting thought. The summary pages and other web services are linked to the user dir. This has high traffic and can cause the issure of the internal network once we crash the disk.
Or if the internal system is crashed, we still want to use elogs as the source of the recovery info. Also currently we have no backup of the elog. This is dangerous.

We can save some of the risks by adding two identical 2TB disks to nodus to accomodate svn/elog/web and their daily backup.

I had to realign the IMC today. When I came in, it was very bad, not much flashing at all, I had to do it from scratch. CH01 Camera on MON7 in the control room is completely white. Did the camera go out over the weekend? I will come back to poke around later, I have headed over to WB for a moment and will be back soon. sitemapsi

It took a while, but I was finally able to align IMC. It seems like WFS has been getting really whacky lately when we arent in the lab watching it . The picture attached has an arrow of where the beam spot was at this morning

At about 10AM, the C1LSC frontend stopped reporting any EPICS information. The arms were locked at the time, and remained so for some hours, until I noticed the totally whited-out MEDM screens. The machine would respond to pings, but did not respond to ssh, so we had to manually reboot.

Soon thereafter, we had a global 15min EPICS freeze, and have been in a weird state ever since. Epics has come back (and frozen again), but the fast frontends are still wonky, even when EPICS is not frozen. Intermittantly, the status blinkers and GPS time EPICS values will freeze for multiple seconds at a time, sporadically updating. Looking at a StripTool trace of an IOPs GPS time value shows a line with smooth portions for about 30 seconds, about 2 minutes apart. Between this is totally jagged step function behavior. C1LSC needed to be power cycled again; trying to restart the models is tough, because the EPICS slowdown makes it hard to hit the BURT button, as is needed for the model to start without crashing.

The DAQ network switch, and martian switch inside were power cycled, to little effect. I'm not sure how to diagnose network issues with the frontends. Using iperf, I am able to show hundreds of Mbit/s bandwidth betweem the control room machines and the frontends, but their EPICS is still totally wonky. 

What can we do??? 

The frontends have some paths NFS-mounted from fb. fb is on the ragged edge of being I/O bound. I'd suggest moving those mounts to chiara. I tried increasing the number of NFS threads on fb (undoing the configuration change I'd previously made here) and it seems to help with EPICS smoothness -- although there are still occasional temporal anomalies in the time channels. The daqd flakiness (which was what led me to throttle NFS on fb in the first place) may now recur as well.

I've been able to get all models running. Most optics are damped, but I'm having trouble with the ITMs, BS and PRM. 

In an effort to ease the IO load on the framebuilder, I've cleaned up the DQ channels being written to disk. The biggest impact was seven 64kHz channels being written to disk, on ADC channels corresponding to microphones. 

The frame files have gone from 75MB to 57MB. 

We found today that there was some (unforgivably un-elogged) PSL-POS & PSL-ANG work today.

The wedge splitter at the end of the PSL table is so terribly dogged that it actually moves around irreversibly if you touch the post a little. Pictures have been recorded for the hall of shame. This should be replaced with a non-pedestal / fork mount.

I was so sad about the fork clamp, that I edited the SUS Master screen instead according to Joe-Yuta instructions; see attached.

There's clearly several broken/white links on there, but I guess that Yuta is going to find out how to fix these from Joe in the morning.

I am in the process of calibrating AS55's shot noise, and I noticed that the AS55 PD input to the demod board was only finger-tight.  I then checked all of the other SMA connections in the set of RF PD demod boards, and found several more that were loose, including all of the REFL55 connections.  This is no good!!!! RF connections need to be tightened!  I went through and tightened all of the offending connections with my personal Snap-on SMA wrench. 

Someone has been moving the big blue recycling bin in front of the laser-chiller-chiller (the air conditioner in the control room).  This is unacceptable.  The chiller temp was up to 20.76C.  No good. 

You are free to move the recycling bin around so you can access drawers or the bike-exit-door in the control room, but make sure that it does not block air flow between the chiller-chiller and the chiller. 

The attached photo shows the BAD configuration.

For the current baffle (dia. 40mm) centered along the beamline place at 1.77" from the test mass, the baffle will allow ~8.6mm visibility on the camera from the center of the test mass (in case of ETMY).

*assuming the pick off mirror is placed at the edge of the tunnel

Estimations of the visibility region (r₁ on the test mass) with baffle (aperture size 40mm).

The baffle is installed on the cage at 1.125" from the test mass (distance changed from the previous elog after a double check).

The 40mm aperture is in no way going to help get clear view of the ITMs; 

Required baffle diameter to have a visibility region r₁ = 3 times the beam diameter

If we use a digital PLL for locking the frequency of the PSL and END green lasers then we can expect a UGF of around 1kHz (assuming a sampling rate of 16kHz). Let's assume a simple 1/f loop giving a loop gain of ~1000x at 1Hz. If the free-swinging ETM pendulum motion at 1Hz is of the order of 1 micron, then the residual motion at 1Hz, once we lock the digital PLL by actuating on the ETM position, will be of the order of 1nm. This is bordering on too high.

Alternatively, is we use an analogue PLL then we can expect a much higher UGF and many orders of magnitude more gain at 1Hz (see here). So we would expect the residual motion of the pendulum to be much smaller - probably limited by some other noise source somewhere in the system (I doubt it's going to be reduced by 12 orders of magnitude).

RA: I think ballpark's not good enough for this. To see what's good enough, we need to to an analysis similar to what Bram has for the ALS. Get the 40m seismic spectrum from the arm locking spectrum or the green laser feedback signal and then correct it for a realistic loop shape.

KA: For this purpose I have made the simulink model for the green locking more than a year ago, but the entire green team has consistently neglected its presence...
https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/Green_Locking/Servo_modeling/091121/

 Agreed. It doesn't completely rule out the digital PLL. I'll check out Kiwamu's model.

I applied a bandpass filter to the accelerometer huddle data as a pre-filter. The passband was from 5 Hz to 20 Hz. I found that applying this pre-filter did very little when comparing the PSD after pre-filtering to the PSD with no pre-filtering. There was some improvement though, just not a significant amount. For some reason, it also seemed as though the second accelerometer improved the most from pre-filtering the data, while the first and third remained closer to the unfiltered noise. Also, I have not yet figured out a consistent method for choosing passband ripple and stopband attentuation, both of which determine how good the filter is. 

My next step in pre-filtering will be determining a good method for choosing passband ripple and stopband attenuation, along with implementing other pre-filtering methods to combine with the bandpass filter. 

[Rana, Radhika]

While discussing xarm AUX laser locking, we noticed excess motion of ITMX. We took spectra of all ITMX sensor outputs and observed a 16 Hz peak, corresponding to the bounce mode of the optic [Attachment 1, 2 (zoomed)]. The UL sensor in particular is sensitive to the bounce DOF. A peak at the roll resonance can also be seen.

To suppress the bounce resonance, we altered the BounceRoll filter in the SUSPOS, SUSPIT, and SUSYAW filter modules. The bounce bandstop filter was widened to the range 15.25-17 Hz [Attachment 2]. The roll bandstop filter was left as is.