Grabbed the PMC data

I went to set up the spectrum analyzer measurements through GPIB, but inadvertently deleted the contents of ~/Agilent/netgpibdata/ (made a soft link in my folder, decided I wanted it gone but rm'ed instead of unlink). I copied what I think was in that folder back (from /opt/rtcds/caltech/c1/scripts/general/labutils/netgpibdata).

Again, the spectra are:

• R-- PMC TRANS PD into SR560 with G=2 DC coupled, no filtering
• A-- PDH IF into SR560 with G=2, DC coupled, no filtering
• B-- PMC PZT HV MON into SR560 with G=2, AC coupled, no filtering

I recorded the three spectra with the following parameters:

• Three separate spans:
  • 10 Hz to 150 kHz
  • 100 to 550 kHz
  • 500 kHz to 2.5 MHz
• bwSpanRatio = 0.1 %
• averages: 10
• number of points: 801
• spec type: noise (PSD units)

I then ran AGmeasure with the above parameters in the yaml, with the rest following the defaults in AgilentTemplate.yaml. I saved the data in /users/aaron/40m/data/PMC/190617/

Looks like the header contains all of the parameters, so I shouldn't have trouble distinguishing the spectra. I didn't get the instant plotting working, but the data seem to be there.

I'm still having trouble getting the data from the oscilloscope. I'm not sure why the tektronix scrips I've used before aren't working, I'm checking it now.

update: Grabbed the data, the issue was just using the wrong IP address. 

The analog camera is aligned and we are able to see all the 4 OSEMs (pictures attached). Due to secondary reflection from the beamspiltter (BS1-1064-33-2037-45S), when the MC2 is locked, we are getting a ghost image of the beam spot along with the primary image. 

The pylon app in Paola was reporting an error saying "0xE1000014: The buffer was incompletely grabbed". I followed the instructions given in this site, and changed the 'Packet Size' to 1500 and 'Inter-Packet Delay parameter' to a value greater than 20,000 (µs). This did the trick and I was able to use the continuous shot mode without any interruption. I'm attaching a picture of MC2 that I captured using GigE.

The circuit diagram for the PMC servo card is D980352. From this diagram, I see that I can send an excitation from the network analyzer to FP2TEST (9.09 kOhm input impedance) where it is added to the PMC error signal before going to the loop filters.

I hook up the following

• Agilent 4395A output to SR560 (300 Hz HP, gain of 1)
• SR560 to FP2TEST and to Agilent's channel R
• PMC error signal IF (mixer box mounted to rack, I noticed the IF BNC->SMA were a bit loose/stressed by a hanging LP RF filter) to SR560 (also 300 Hz HP, gain of 2)
• SR560 to Agilent channel A

I 'Enable' Test 2 on the PSL screen, so FP2TEST gets added to the error signal.

PDH signal

• TDS 3034B with four channels
  • 1. PMC servo box external drive (split off from the function generator)
  • 2. PMC servo box output monitor (mirrors the drive, shows when drive is saturating)
  • 3. IF signal (split off after the mixer)
  • 4. PMC Trans (long BNC from the PSL table)
• SRS DS345 function generator (into the PMC servo box' external drive)
  • 100 Hz signal (there's a 10 Hz pole on the PZT drive, so any faster than this and I can't see both sidebands without the HV output mon clipping)
  • 3.19 Vpp amplitude (smallest amplitude at 100 Hz such that both sidebands are well resolved)
  • 1.52 V offset (center the carrier's PDH error signal at pi/2 out of phase with the drive)

I was able to see the carrier and both sidebands.

I tried to grab this data from the scope via ethernet, but was unsuccessful (timeout errors, I'm using the scripts from scripts/tektronix/tek-dump, and the GPIB box that Kruthi had been using for the GigE cam; I also tried plugging in directly scope->ethernet. Never got anything but timeout errors, so maybe I'm not specifying the port correctly. Anyway the trace is frozen on the scope for later use, or I can easily repeat this now that I know how).

Spectrum

Next, I locked the PMC (Test1 is off, tune DC output adjust until I get some transmission, turn on the loop at Test1, increase the gain to before the loop goes unstable). I'm sending the following channels to SR560 (gain = 2, no filtering, high dynamic reserve, 50 Ohm outputs), and reading spectra from the Agilent 4395A:

• R-- PMC TRANS PD
• A-- PDH IF
• B-- PMC PZT HV MON

The HV mon was always saturating the preamp, so I disconnected it; I added a 50 Hz (6db) high pass to the Trans PD signal, since it has a DC component.

I got to take a look at the traces on the spectrum analyzer front panel, but too tired to do the GPIB for now. There are peaks, things look reasonable.

Today, I tried aligning it further; I'm attaching a picture of it. We are not able to see all the 4 OSEMs yet. In the reference picture I had taken, before taking off the previous analog setup, the OSEMs are not seen. So, I don't really understand what the other 2 spots seen on the current screen are. Are they actually OSEMs?

I need a laptop next to MC2, so that I can have a look at it and make further alignments. So, I tried accessing the GigE attached to the telescope using Paola. The pylon app in it, throws an error, few seconds after running it in continuous shot mode, and disconnects the GigE; everything works fine on Rossa though. I'll put up further details soon.

SURFS want some locking of IMC for camera adjustment.

So I left the IMC with intermediate gains so that it keeps locking and unlocking.

VCO (overall) iMC gain of -32, FSS common gain 3, and the FAST gain 20. I believe MC2tickle is ON too.

SURFs had trouble connecting paola to martian via wireless.
Of course, it requires a fixed IP but it had not it yet. So I went to chiara and gave 192.168.113.110 as "paolawl". Note that the wired connection has .111 and it is "paola".

Followed the instruction on http://nodus.ligo.caltech.edu:8080/40m/14121

As directed by Gautam, I have set up one script- interact.py (at /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/interact.py) to perform the following two tasks:

1. View the GigE feed for a fixed period of time.
2. Record the GigE feed for a fixed amount of time.

Steps to view GigE feed for a fixed amount of time:

1. Run the following commands in the terminal to navigate to the concerned directory and then view the feed
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python interact.py --path_to_config <path_config> --mode 0 --view_time <viewing_time>, where
      1. path_config: full path to configuration file, defaults to /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini if --path_to_config is not used
      2. viewing_time: time in seconds for which the feed is to be displayed. The server is closed  after this time and the window freezes and can be manually closed.
   3. Exiting the feed in between: The script terminates automatically after the specified time. To terminate the feed in between, close the window manually using the x icon the top right. This makes sure that the server is correctly closed. If closed using the Ctrl-C command in the terminal, the server is left running and any attempt to unwittingly set up another results in an error (see Attachment #1). In this case, the server and client processes needs to be identified manually and killed. I have used the following steps
      1. ps -eaf | grep server, then identify the PID for the python camera_server.py process
      2. kill PID
      3. similarly for the client file

Steps to record the GigE feed for a fixed amount of time:

I tried to look for elegant solutions that wouldn't require editing the code that Jon wrote and stumbled upon this useful bit of information but ended up deciding that it was just easier to change the camera_client_movie.py (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_client_movie.py). It can still be run as previously described, where video recording is terminated by using Ctrl-C. Steps to record for a fixed period of time are

1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
2. python interact.py --path_to_config <path_config> --mode 1 --save_time <recording_time> --file_name filename, where\
   1. path_config: full path to configuration file, defaults to /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini if --path_to_config is not used
   2. recording_time: time in seconds for which the feed is to be saved. No video is displayed during this time.
   3. filename: full path to the file where the video is to be saved. Overwrites any existing files.

I'll make aliases for these to make the whole process more user friendly. I'm halting this for now and will discuss what else needs to be done once Gautam gets back.

Regarding the autolocker: I spoke to Aaron today and as he is in tomorrow, I'll ask him about the burt files and the ideal configuration.

I'm also starting with GANs now.

Continuing this investigation of the IMC, today I am getting familiar with the PMC and FSS. I'd like to measure the frequency noise of the PSL referenced to the PMC.

I checked that the PSL shutter is off, so no light reaches the IMC.

I'm not really sure what I'm looking for on the FSS boxes. I found a few documents to guide:

• On the tabletop testing of FSS for LIGO
• 40m wiki

I ran the FSS autolock script from C1PSL_FSS, nothing obvious changes when I do so. The FSS error signal (which I think is PSL-FSS_MIXERM) is flatlined, and the RC-RF_PD has no LO (PSL-FSS_LOCALC is nan).

Rich dropped by at around 3:00 PM today and picked up the VCO in Attachment #1 and left the note in Attachment #2 on Gautam's desk with the promise of bringing it back soon.

don't need to lock - make sure the 4 OSEMs are centered on the camera field just as we have for the arm cavity mirrors

Today, Rana asked me to work on improving simulations based on the ideas we discussed last week. As of the previous elog the simulation accomodated only

1. Simulation of Gaussian beam spot.
2. Arbitrary motion.

Today, I added the simulation of point scatterers.

What?

The image on the sensor (camera) is produced in roughly the following steps.

1. Motion of the Gaussian beam on the optic (X,Y coordinates) which is what has been simulated so far.
2. Reflection from the surface of the optic which can be modeled using knowledge of the BRDF has not been included as of this elog as I wish to do a little more reading before doing so.
3. Reflection from point scatterers (dust particles burnt into the optic surface by the laser and so forth) which are characterised as peaks (impulses) in the TIS vs position plot. The laser beam is incident nearly normally on the optic and this behaviour is independent of the angle of observation. This is what has been added to the simulation.

How?

1. Increased the frame resolution to 720 x 480.
2. Defined an array of the same size and set values of at most "num_scatter" number of points at random positions to values determined randomly between 1 and "scatter_amp" + 1 where scatter_amp is non-negative.
3. Multiplied the resulting array by the resulting Gaussian beam. The motivation was to imitate the bright specks obtained on various camera feeds in the lab. Physically, this also implies normal incidence and normal observation which is not the real case at all. I shall add these features in a day or two.

Herewith, in attachments #1, #2, #3 I am attaching videos obtained by varying scattering amplitude and number of scattering points in a vain attempt to reproduce this data. I shall work more on this simulation on Friday.

Scripting stuff:

1. Previous elogs detail how to take gige images at various exposure times. I am still waiting on Kruthi to use the script.
2. Tomorrow I shall work on the scripting software to interact with the GigE and take video for a fixed duration etc. I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.

Neural network stuff:

GANs for simulation:

1. Other than putting the physics into simulation i.e the first portion of this elog, GANs can be trained to generate images similar to the original data. I am unfamiliar with training GANs and the various tricks that are used specifically for them. I will do a bit of reading and make an update by Friday. As of now, the data I plan to use is this and I will train it using the GTX 1060 on my machine.

Networks for beam tracking:

1. I will use the architectures suggested in this work with a few modifications. I will use MSE loss function, Adam optimizer and my local GPU for training.

I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked). 

[Koji, Kruthi]

Yesterday, Koji helped me clean all the optics that are being used for the setup. We tried aligning the cameras with the previous configuration we had, but after connecting the analog camera cables there wasn't much room to align the beam splitter. Today, I tried a different configuration and tested the alignment of analog camera, GigE, beam splitter and the mirror using a laser beam [pictures attached]. But the MC2 isn't locked to test if the whole setup is actually aligned with the mirror inside the vacuum. 

Also, with this setup, just by using posts of different lengths with the middle 90º-post-clamp, we will be able to move all the components. This way, we can easily image the beam spot in all the cavities.

I drew out some idea of how we might use a single OMC to clean both paths of the BHD after mixing, without being susceptible to polarization-dependent effects within the OMC. Basically, can we send the two legs of the BHD into the OMC counterpropagating. I've attached a diagram.

I think one issue would be scattered light, since any backscatter directly couples into the counterpropagating mode, and thus directly to the PD. However, unless the polarization of the scattered light rotates it would not scatter back to the IFO. And, since the LO and signal mix before the OMC, this scattered light would not directly add phase noise.

Maybe more problematic would be that if the rejection at the PBS (or the polarization rotation) isn't perfect, light from the LO directly couples into the dark port. Can we get away with a Faraday isolator before the OMC? 

Diagram attached.

[Kruthi, Milind]

Today, with Milind's help, I installed the analog camera into the MC2 enclosure [picture attached]; but it is not yet focused. We replaced the bulky angular bracket with a simple one, this saved a lot of space inside and it's easier to align other components now. I'll finish setting it up tomorrow.

Telescope design for MC2:  Instead of using two 3" long stackable lens tubes (SM2L30), we can use one 3" lens tube with an adjustable lens tube (SM2V10), as shown in the picture. This gives a flexibility to change the focal plane distance by 1" and also reduces the overall length of telescope from 9 inches to 6-7 inches. I decided to use two 150mm biconvex lens instead of a combination of 150mm and 250mm lenses, as the former combination results in lower focal plane distance for a given distance between the lenses.

Specifications of current telescope system (for future reference):

With the above telescope, assuming the MC2 mirror to be at a distance of approx 75cm, the focal plane distance will range from 7.9cm to 8.1cm. Using the adjustable lens tube, we can further make the fine adjustment.

Today, Rana had me key the PSL crate.

1. Locating the rack: the crate is 1X1. This link provides details of the locations and functions of the racks.
2. Keying the crate: the key is located at the bottom of the rack (in this case). Keying it requires one to turn the key through 90 degrees (anti clockwise facing the rack) and back to to the original position.

Locking the PMC:

1. Accessing the medm screen for the PMC: open a new terminal and use the command sitemap. This should open up the sitemap medm screen. Click on the PSL button and then select C1PSL_PMC from the dropdown that is produced. This opens up a medm screen similar to that in Attachment #1.
2. The correct toggling: The keying of the crate sometimes scrambles the settings on the medm screen. Rana and I performed extensive toggling of the buttons and concluded that the combination in Attachment #1 ought to be the correct one.
3. Locking the PMC: The state of the PMC was deduced by observing CH01 on monitor 7. When not locked, there is no observable bright spot. At this point the "Input Offset (V)" slider is set to zero and the "Servo Gain Adjust (dB)" slider is set to minimum. To obtain lock, complete step 2 and then move the "DC Output Adjust (V)"  slider (at the bottom left on the screen) around rapidly while looking for a bright spot. On observing such a spot on the monitor, release the slider and quickly increase the "Servo Gain Adjust (dB)" slider to around 15 dB. Higher gain values produce a bright spot on CH02 as well which vanishes (almost) on decreasing the gain to the aforementioned value.

Steps to take snapshots using GigE at different exposures [Instructions for Kruthi]:

1. Setup C1-CAM-ETMX.ini (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) appropriately. The parameter Number of Snapshots determines how many snapshots will be taken at any given exposure. Set Name Overlay, Time Overlay, Calculation Overlay, Calculations (if using very low values of exposure) and Auto Exposure to False. Ensure that that the IP address of the Camera in use and that in the configuration file match.
2. Launch a server using the following commands (as described in elog 14649)
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python camera_server.py -c C1-CAM-ETMX.ini
3. Open another terminal in the same directory and then run the following command
   1. python exposure_variation.py --minval <minval> --maxval <maxval> --step <step> where
      1. minval: lower bound of range of exposure values, defaults to 150
      2. maxval: upper bound of range of exposure values, defaults to 100000
      3. step: step size of variation in the range [minval, maxval], defaults to 2000

The python script takes in the above parameters and then takes snapshots by setting the exposure to values starting at minval and going upto maxval incrementing by step at each turn. This uses a simple for loop and is nothing elaborate.

A few unrelated updates:

1. On a sidenote, I installed Sublime Text editor on rossa following the instructions at this site (check install using yum section). Further, I have also installed miniconda but did not set it up fully as I was in a rush and did not want to disturb any previously set up environment variables.
2. I have cloned Gabriele's repository and am trying to get it to work on my system. As Gautam has pointed out that the end goal is to get stuff working on the lab machines, I will sharea .yml file with the necessary environment details upon completion.
3. I will upload details of how I am going to construct the two learning tasks that Rana, Gautam and I discussed in a day or two including details of the use of simulation data for training data in the absence of real data (until Kruthi is done setting up the GigE) which Gautam suggested I do to speed things up.

I managed to fit all the parts into the cylindrical enclosure without having to drill a hole in the enclosure to mount the analog camera (pictures attached); thanks to Koji for helping me find some fancy mechanical components (swivel post clamps, right angle post clamps and brackets). On Thursday, with Chub's help, I took a look at all the current analog camera positions with respect to the cylindrical enclosures. I think this setup gives me enough flexibility to align the components, as necessary, to be able to image the test masses/mirrors in all the cavities. I'll set it up for MC2 tomorrow.

As per Gautam's request, I looked at the IMC situation.

Locking path

• Acquisition: IMC IN1 Gain +4 (nominal), Boost 0, VCO Gain (-32), FSS Common +6 (nominal), FSS FAST +20
  This is too low gain. So oscillate VCO Gain between -32 and ~0 until TEM00 lock is acquired
• Once lock is acquired, bring the VCO gain to +11 (new nominal), and increase the FSS FAST to +23 (new nominal). Change the IMC BOOST to 3 (nominal)

Diagnosis

• The PMC servo gain was checked. The control signal monitor for the PMC actuation was hooked up to SR785. The nominal gain was +18dB. Increasing the gain to 20dB made the servo oscillating. So the nominal gain of +18dB seems still reasonable.
• The status of NOISE EATER was checked. Both the PMC REFL and TRANS were looked at by AG4395A. The power spectrum of them did not change much around the kHz~MHz region. It made the PSD slightly (x2~3) improved below 1kHz. I also did not recognize the relaxation oscillation peak. So I could not figure out where to see. NOISE EATSER was on and is still on.
• IFO Modulation Freq: I took this chance to look at the IMC absolute length using the peak at 3.6MHz. The TP1A output of the IMC servo board was hooked up to AG4395A.
  The new FSR of the IMC (and thus the modulation frequency for the IFO) is 11.066275MHz (instead of the previous 11.066209MHz).
  This corresponds to 0.16mm difference in the roundtrip length.
• (*Still working) IMC SERVO configuration:
  • FAST 25 (nominal) sometimes invoke the oscilattion. 24 has gain peaking ~30kHz. There is a big line peak at 35kHz so wanted to avoid the servo bump (PZT-EOM cross over). So decided to use 23dB. (This is not optimal for the CM servo as we need as much as bandwidth for CM servo.)
  • IMC VCO GAIN (bad name. this is actually overall output gain for IMC) was increased from the nominal 7 to 11. Increasing this above 11 makes the servo oscillating at ~200kHz.
• (*Still working) Measured power spectrum of the error signal. Too many line peaks.
• (*Still working) Single trigger observation: Oscilloscope monitoring started from 35kHz going up and ~20kHz oscillation +/-6V of the IMC servo output was observed. Could not capture good data for this. Try the other day.

I'll complete the entry later.

Summary:

I did some more calculations based on our discussions at the meeting yesterday. Posting preliminary results here for comments.

Details:

Attachment #1 - Schematic illustration for the scattering scenarios. For all three scenarios, we would like for the scattered field to be lower than unsqueezed vacuum (safety factor to be debated).

Attachment #2 - Requirements on a fraction  of the counter-propagating resonant mode of the OMC scattering back into the antisymmetric port, as a function of RIN and phase noise on this field (y-axis) and amount of field (depends on the amount of contrast defect light which can become resonant in the counter propagating mode). I don't encode any frequency dependence here.

Attachment #3 - Requirements on the direct scatter from the arm cavity resonant field (assumed to dominate any contribution from the PRC) onto the OMC DCPDs, for some assumed phase noise (y-axis) and fraction of the field that makes it onto the OMC DCPDs. This is a pretty stringent requirement. But the probability is low (it is the product of three presumably small numbers, (i) probablity of the beam scattering out of the TEM00 mode, (ii) BRDF of the scattering surface, (iii) probability of scattering back towards the DCPDs), so maybe feasible? I didn't model any RIN on this field, which would be an additional noise term to contend with. The range of the y-axis was chosen because I think these are reasonable amplitudes for chamber wall  / other scattering surface motion at acoustic frequencies.

[Koji, Milind]

Today I ran into the following errors:

1. Inability to access the EPICS channels using the commands caget and caput and thus the generation of a blank medm screen (error in Attachment #1) when simultaneously running the code in camera_server.py (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py).
2. Inability to run camera_server.py code with an active medm screen with a "... failed to read <EPICS channel>" error.

Therefore, Koji and I took a look at it and putting our faith in Gautam's hunch from elog 13023, we walked down to rack 1Y1 and keyed it. Following this, all the functionality previously described was restored! Koji then took a look at all the channels handled by this machine and bestowed upon me the permission to key the crate should I lose control of the GigE again.

Thanks! It does indeed do the trick! With that I was able to

1. Obtain current exposure value using the terminal command caget C1:CAM-ETMX_EXP
2. Set exposure value using the terminal command caput C1:CAM-ETMX_EXP <desired_exposure_value>

Further, a quick look at the camera server code in /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py revealed that the script expects the details of "Number of Snapshots" in "Camera Settings" in the configuration file i.e in C1-CAM-ETMX.ini at ( /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) which wasn't present before. Adding this parameter to the config file allows one to take a snapshot using the medm screen. Infact, unlike as described in this elog, I was able to start the server and client as described in elog 14649, and then obtain snapshots using the terminal command  caput C1:CAM-ETMX_SNAP 1.

caget/caput probably does the job.

Figured out how to get/grab frames by looking at the pypylon documenation as that turned out to be easier than modifying Jon's code. Still not sure about how to modify the exposure time (other than using the pylon app, the only technique I know so far is to adjust the exposure manually on the medm screen and then run the scripts as described in the previous elog). I will figure that out tomorrow and make a script suitable for Kruthi's usage (obtain a bunch of images with different exposure times). I will also try and integrate the video saving and streaming code into this and have a neat little script set up asap.

I briefly managed to lock the IMC today - it stayed locked for ~10 minutes. Attachment #1 shows spectra of a few error and control signals for today's lock, and from a stretch yesterday before the problems surfaced*. The 60 Hz lines are much bigger, and MC_F signals broadband excess noise above a few Hz. I suspect a problem somewhere in the electronics.

*I confess the comparison isn't entirely valid because I had to tweak the FSS FAST gain from its nominal value of 22 to 25 in order to get the PC drive RMS down to the ~1.5V level. At the nominal gain setting, with the laser frequency locked to the cavity length, the PC Drive RMS was ~4 V. Still, indicative of something being off in the electronics.

​Summary:

Attachment #1 shows the RIN and phase noise requirements for the 40m BHD for measuring Ponderomotive squeezing.

Some details:

1. The interferometer topology is not systematically optimized - I just picked values which are likely close to what we will eventually choose. Namely, , , , , . Nevertheless, I think these requirements will not change by more than 30% for changes to the interferometer config.
2. The requirements are evaluated using the following criterion: assuming that the dominant noises are (i) coil driver at mid-frequencies and (ii) quantum noise at high frequencies, what do the RIN and phase noise on the LO have to be such that the equivalent displacement noise is a factor of 10 below? I opted for a safety factor of 10, this can be relaxed. 
3. An unknown is how much contrast defect light we will end up having due to the mismatch between arms. I assumed a few representative values.
4. The calculations were done analytically. This paper provides a good summary of the relations - although my RIN requirement is more stringent because of the safety factor of 10, and phase noise requirement is less stringent (despite the same safety factor) because we plan to read out at nearly the amplitude quadrature.
5. Since we are discussing the possibility of delivering the LO field using a fiber-coupled pickoff of the laser prior to RF sidebands being added, these requirements do not benefit from passive filtering from the cavity transfer functions. Consequently, the requirements are pretty challenging I think.

Conclusions:

1. The RIN requirement looks very challenging - we will need a shot noise limited ISS with 100 mW DC sensing light, and will likely have to relax the safety factor depending on how much contrast defect light we end up having. This actually sets some requirement on the amount of filtering we need from the OMC (next step).
2. The phase noise requirement also looks very challenging - I need to look up what is possible with the double-pass through fiber technique.

​Next steps:

1. Evaluate the pointing stability requirement on the LO field (IFO output is filtered by the OMC).
2. We still need to think of a control scheme for the LO phase - likely, I think we will need a suspended optic between the fiber collimator delivering the light to the BHD setup with some kind of length actuation capability. 
3. Numerical validation of this analytic study. I believe Finesse is still missing some capabilities that allow us to calculate these couplings, but I'll ask the experts to be sure.
4. Build up the requirements on the OMC cavity:
   • Backscatter requirement (related = OFI isolation requirement, relative length noise between SRM and OMC, OFI and SRM). Does the OFI also have to be suspended?
   • Filtering requirement
   • Pointing stability requirement
   • Length noise requirement 

Chub and I are trying to figure out a way to co-mount GigE into the existing cylindrical enclosure. I'm attaching a picture of the current setup that is being used for imaging MC2. As of now, I have thought of 3 possible setups (schematics attached); but I don't know how feasible they are. Let us know if you have any other ideas.

Update: The setup 3 would require us to use the 52cm long enclosure. It has a long breadboard welded to it, which makes it very convienient, but the whole setup becomes quite heavy and it's not that safe to install such heavy enclosure on top of the vaccuum system. Also, aligning its components would be more complicated than other setups.

I decided to start with the simple one, therefore, I tried implementing setup 1. Fitting in the analog camera horizontally alongside the telescope turned out to be tricky. Though I did manage to fit it in, it didn't leave any room to change the orientation of the beamsplitter. Like Koji suggested, I'll be trying the setup 2.

I was working with the git repo in the SnapPy_pypylon folder (/cvs/cds/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon) and needed to create a branch. To avoid any confusion, I modified the PS1 variable and that alone in the bashrc file to reflect the git branch so that the prompt now displays the git branch if you enter a repository. This is just an update.

The following steps summarize the steps to setting up and interacting with a GigE camera.

Launching the PylonViewerApp:

1. Open a new terminal using Ctrl + Alt + T on the keyboard.
2. Launch the app using the command pylon.

Using setup python scripts to interact with the GigE (a summary of the steps listed here and here)

1. Connect the GigE camera to the ethernet cable and record its IP address. If the IP address is not printed on the GigE, launch the PylonViewerApp and navigate to the "Tools" dropdown menu and select "pylon IP configurator" to be presented with a list of all connected cameras and their IP addresses.
2. To simply observe the camera feed, open a new terminal and run the following commands:
   1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
   2. python camera_server.py -c C1-CAM-ETMX.ini  (only one config file is present currently and more will be added as more cameras are set up. The "Camera IP" in the  .ini file must match that determined in step 1). This starts the camera server.
3. Open a new tab (Ctrl + Shift + T on the keyboard) in the terminal. You should still be in the same directory as navigated to in step 2.1. Run the following command.
   1. python camera_client.py -c C1-CAM-ETMX.ini
4. This should bring up a feed from the camera. Close at will.
5. To record a video file, repeat steps 1 and 2. Open a new tab as described in step 3. Then run the following command:
   1. python camera_client_movie.py -c C1-CAM-ETMX.ini
6. Enter the full path to the file where you wish to save the movie in the prompt that appears. Use ./your_file_name_here.avi to save the the video in the working directory. Press Ctrl + C to stop recording. The recording can be played by navigating to the location where the recording is stored and running vlc your_file_name_here.avi.
7. To adjust the exposure setting of the camera, open a new terminal and run the command sitemap . This should bring up the medm display in Attachment #1. Click on the Video/Lights button highlighted in red and select GigE. Adjust the exposure value in the next window using the slider before starting the server in step 1. Adjusting the slider once the server is started causes the program to freeze. Also set the Snapshot channel C1:CAM-ETMX_SNAP to off as mentioned in elog 14037.

Upcoming updates:

1. Automatic script to run the above steps.
2. Pre-determining the time duration of the recorded video.
3. Obtaining snapshots.

Since ~ 2 hours ago, the IMC autolocker has not been able to keep the IMC locked. I don't see any obvious trends in the wall StripTool that may point to what's going on. For the brief periods in which a TEM00 mode is locked, the PC Drive RMS level is ~5x what the nominal level is, and while the autolocker is trying to lock the IMC, the PC drive RMS level is hovering around 4V DC, which is high. The PMC Error and Control signal spectra show huge 60 Hz (and harmonics) peaks, and indeed this is visible in the time domain signals as well (on ndscope or on the oscilloscope on the PSL table), but this is not a new feature in the last two hours. Usually, this kind of problem signals that either/both the c1psl or c1iool0 slow machines need to be power-cycled, but I confirmed that both machines are online and telnet-able. Possibilities: (i) some card in the c1psl / c1ioo crates have failed or (ii) something in the MC/FSS electronics chain has failed or (iii) there is a huge amount of excess high-frequency noise from the NPRO.

I am leaving the PSL shutter closed.

no BMP files 

Coupling into the fast axis of the fiber:

The PM couplers I bought require that the light is coupled to the fast axis. The Thorlabs part that Andrew ordered, and which Anjali was using for the MZ experiment, was the opposite configuration, and so the input coupler K6XS mount was rotated to accommodate this polarization. The HWP was also rotated to cut the power into the fiber. I undid these changes. Mode-matching is ~65% (2.42mW/3.70mW) which isn't stellar, but good enough. The PER is ~15dB (ratio of power in fast axis to slow axis is ~40), which I verified using another collimator at the output, and a PBS + two photodiodes. Again isn't stellar but good enough.

EX laser temperature adjustment:

Rana adjusted the temperature of the main laser to 30.61 C. According to the calibration, the EX laser temperature needed to be ~32.8 C. It was ~31.2 C. I made the change by rotating the dial on the front panel of the EX laser controller. Fine adjustment was done using the temperature slider on the ALS screen. With an offset of ~+610 counts, I found a beat at ~80 MHz.

First look at PM beamsplitters:

From my initial test, the beat amplitude was stable to my moving of the fibers . The NF1611 DC monitor reports 2.6 V DC with only the EX light, and 3.15 V DC with only the PSL light. So I should probably cut the PSL power a little to improve the contrast. Assuming the 10 kohm DC transimpedance spec can be believed, this means the expected signal level is 4*sqrt(260uA * 315uA)*700V/A ~0.8 Vpp, and I see ~0.9 Vpp, so roughly things add up (this is actually more consistent with an RF transimpedance of 800V/A, which is maybe not unreasonable). The RF amps for routing this signal to the delay line has been borrowed for the 2um frequency noise experiemnt - I will reacquire it today and check the ALS noise performance.

So overall, I am happy with the performance of the current iteration of the BeatMouth.

[Kruthi, Milind]

Yesterday, we were able to capture some images of objects at a distane of approx 60cm (see the attachment), with the GigE mounted onto the telescope. I think, Johannes had used it earlier to image the ETMX (https://nodus.ligo.caltech.edu:8081/40m/13375). His elog entry doesn't say anything about the focal length of the lenses that he had used. The link to the python code he had used to calculate the lens solution wasn't working. After Gautam fixed it, I took a look at it. He has used 150mm (front lens) and 250mm (back lens) as the focal length of lenses for the calculation. Using the lens formula and an image of a nearby light source, with a very rough measurement, I found the focal lengths to be around 14 cm and 23 cm. So, I'm assuming that the lenses in the telescope are of same focal lengths as in his code, i.e 150mm and 250mm.

To maintain PM fibers all the way through to the photodiode, I had ordered some PM versions of the 50/50 fiber beamsplitters from AFW technologies. They arrived some days ago, and today I installed them in the BeatMouth. Before installation, I checked that the ends of the fibers were clean with the fiber microscope. I also did a little cleanup of the NW corner of the PSL table, where the 1um MZ setup was completely disassembled. We now have 4 non-PM fiber beamsplitters which may be useful for non polarizaiton sensitive applications - they are stored in the glass-door cabinet slightly east of the IY chamber along the Y arm, together with all the other fiber-related hardware.

Anjali had changed the coupling of the beam to the slow axis for her experiment but I ordered beamsplitters which have the slow axis blocked (because that was the original config). I need to revert to this config, and then make a measurement of the ALS noise - if things look good, I'll also patch up the Y arm ALS. We made several changes to the proposed timeline for the summer but I'd like to see this ALS thing through to the end while I still have some momentum before embarking on the BHD project. More to follow later in the eve.

[chub, gautam]

Today, we tried to resuscitate the c1iscaux2 channels by swapping the existing, failed VME crate with the newly freed up crate from c1susaux. In summary, the crate gets power, and the EPICS server gets satrted, but I am unable to switch the whitening gain on the whitening boards. I belive that this has to do with the FAIL LEDs that are on for the XVME-220 units. We were careful to preserve the location of the various cards in the VME crates during the swap. Rather than do a detailed debugging with custom RJ45 cables and terminal emulators, I think we should just focus the efforts on getting the Acromag system up and running.

Our work must have bumped a cable to the c1lsc expansion chassis in the same rack - the c1lsc FE had crashed. I rebooted it using the script - everything came back gracefully.

The vacuum itself was fine - CC1 gauge reported a pressure of 1.3e-5 torr. Note to self: the C1:Vac-CC1_HORNET_PRESSURE channel, which is the analog readback of the Hornet gauge and which is hooked up to an Acromag ADC in the c1auxex chassis, is independent of the status of the c1vac machine, and so can serve as a diagnostic.

However, I was unable to interact with c1vac in any way, the monitor hooked up directly to it was showing a frozen display. So I hard-rebooted the system. It took a few minutes to come back online - but even after 10 minutes of waiting, still no display. In the process of the reboot, several valves were closed off - when the EPICS processes restart, there are momentary instances where the readback channels get an "undefined" value, which prompts the main interlock process to transition to a "SAFE" state. 

Running df -h, I saw that the /var partition was completely full. Maybe this was somehow interfering with the machine running smoothly? Two files in particular, daemon.log and daemon.log.1 were ~1GB each. The contents of these files seemed to be just the readbacks for the caget and caput commands. So I cleared both these files, and now the /var partition usage is only 26%. I also got the display back up and running on the physical monitor hooked up to the c1vac machine's VGA port. Let's see if this has improved the stability situation. The CPU load is still high (~6-7), with most of this coming from the modbus process. Why is this so high? c1susaux has more Acromag units but claims a much lower load of 0.71. Is the CPU of the c1vac machine somehow inferior?

In the meantime, I ssh-ed into c1vac and restored the "Vacuum normal" valve config. During this little escapade, the main volume pressure rose to ~6e-5 torr. It's coming back down smoothly.

Unrelated to this work: we had turned the RGA off for the vent, I powered it back on and re-initialized it this morning.

I've been monitoring the status of the pumpdown remotely with ndscope lookbacks of C1:Vac-CC1_pressure. Today morning, I saw that the channel was putting out a constant value (signature of EPICS server being frozen). caget did not work either. Then I tried ssh-ing into c1vac to see if there were any issues but I was unable to. The machine isn't responding to ping either. The EPICS value has been frozen since ~1030pm PDT 26 May 2019.

I will try and head to campus later today to check on it. Isn't an email alert or soemthing supposed to be sent out in such an event?

On Friday, I tried calibrating the CCD with the following setup. Here, I present the expected values of scattered power (P_s) at s = 45°, where s is scattering angle (refer figure). The LED box has a hole with an aperture of 5mm and the LED is placed at approximately 7mm from the hole. Thus the aperture angle is 2*tan^-1(2.5/7) ≈ 40° approx. Using this, the spot size of the LED light at a distance 'd' was estimated. The width of the LED holder/stand (approx 4") puts a constraint on the lowest possible s. At this lowest possible s, the distance of CCD/Ophir from the screen is given by . This was taken as the imaging distance for other angles also.

In the table below, P_i is taken to be 1.5mW, and P_s and  were calculated using the following equations:

d (cm)	Estimated spot diameter (cm)	Lowest possible s  (in degrees)	Distance of CCD/Ophir from the screen (in cm)	(in sr)	Expected Ps at   s = 45° (in µW)
1.0	1.2	78.86	5.2	0.1036	34.98
2.0	2.0	68.51	5.5	0.0259	8.74
3.0	2.7	59.44	5.9	0.0115	3.88
4.0	3.4	51.78	6.5	0.0065	2.19
5.0	4.1	45.45	7.1	0.0041	1.38
6.0	4.9	40.25	7.9	0.0029	0.98
7.0	5.6	35.97	8.6	0.0021	0.71
8.0	6.3	32.42	9.5	0.0016	0.54
9.0	7.1	29.44	10.3	0.0013	0.44
10.0	7.8	26.93	11.2	0.0010	0.34

On measuring the scattered power (P_s) using the ophir power meter, I got values of the same order as that of  expected values given the above table. Like Gautam suggested, we could use a photodiode to detect the scattered power as it will offer us better precision or we could calibrate the power meter using the method mentioned in Johannes's post: https://nodus.ligo.caltech.edu:8081/40m/13391.

1. I used the same motion as defined in the previous elog. I gradually added noise to the images. Noise added was uniform random noise - a 2 dimensinoal array of random numbers between 0 and a predetermined maximum (noise_amp). The previous elog provides the variation of the y coordinate. In this, I am also uploading the effect of noise on the error in the prediction of the x coordinate. As a reminder, the motion of the beam spot center was purely vertical. Attachement #1  is the error for noise_amp = 0, #2 for noise_amp = 20 and #3  for noise_amp = 40. While Attachment #3 does provide the impression of there being a large error, this is not really the case as without normalization, each peak corresponds to a deviation of one pixel about the central value, see Attachement #4 for reference.
2. While the error does increase marginally, adding noise has no significant effect on the prediction of the y coordinate of the centroid as Attachment #5 shows at noise_amp = 40.
3. I am currently running an experiment to obtain the variation of mean square error with different noise amplitudes and will put up the plots soon. Further, I shall vary the resolution of the image frames and the the standard deviation of the Gaussain beam with time and try to obtain simulations very close to the real data available and then determine the performance of the algorithm.
4. The following videos will serve as a quick reference for what the videos and detection look like at
   1. noise_amp = 20
   2. noise_amp = 40
5. I also performed a quick experiment to see how low the amplitude of motion could be before the algorithm falied to detect the motion and found it to occur at 2 orders of magnitude below the values used in the previous post. This is a line of thought I intend to pursue more carefully and I am looking into how opencv and python handle images with floats as coordinates and will provide more details about the previous trial soon. This should give us an idea of what the smallest motion of the beam spot that can be resolved is.

At ~4pm, the main volume pressure (CC1) was reported to be ~5e-5 torr. So I replaced the HR mirror in the MC REFL path with the usual 10% beamsplitter, and aligned the beam onto MCREFL photodiode. I also replaced the ND filter on the AS port camera, and in front of the IPPOS QPD.

Then I turned up the power by HWP rotation - at the input to the IMC, I now measured 960 mW with the Coherent power meter, so the NPRO power has certainly decayed by ~10% from 2018 July. Normal high-power IMC autolocker script was re-enabled on megatron (and the slow servo enable threshold raised from 1000 cts to 8000cts). IMC was readily locked, after some hand alignment, I got a maximum of 14500 cts transmission. I was then able to lock the Y-arm. The dither alignment servo did not work with the nominal settings, but by hand alignment, I was able to get TRY up to 0.6 (I didn't try too hard to optimize this in any systematic way). X arm was also locked.

AUX drypump valved off and shutdown at ~610pm. I also switched both TP2 and TP3 to their lower rotation "standby" mode. So overall no major mishaps this time around. I am leaving the PSL shutter open over the long weekend. For in-air vs vacuum suspension spectra comparison, I kicked the ETMY optic at Fri May 24 18:26:10 PDT 2019.

[chub, gautam]

Overnight, the pressure of the main volume only rose by 10 mtorr, so there was no need to run the roughing pumps again. So we went straight to the turbos - hooked up the AUX drypump and set it up to back TP2. Initially, we tried having both TP2 and TP3 act as backing pumps for TP1, but the wimpy TP3 current was always passing the interlock threshold. So we decided to pump down with TP3 valved off, only TP2 backing TP1. This went smooth - we had to keep an eye on P2, to make sure it stayed below 1 torr. It took ~ 1 hour to go from 500 mtorr to 100 mtorr, but after that, I could almost immediately open up RV2 completely. A safe setting to run at seems to be to have RV2 open by between 0.5 and 1 turn (out of the full range of 7 turns) until the pressure drops to ~100 mtorr. Then we can crank it open. We are, at the time of writing, at ~8e-5 torr and the pressure is coming down steadily.

I had to manually clear the IG error on the CC1 gauge, and re-enabled the High Voltage, so that we have a readback of the main volume pressure in that range. I made a script to do this (enable the HV, the IG error still has to be cleared by pushing the appropriate buttons on the Hornet), it lives at /opt/target/python/serial/turnHornetON.py. I guess it'll take a few days to hit 8e-6 torr, but I don't see any reason to not leave the turbos running over the weekend.

Remaining tasks are (i) disconnect the roughing pump line and (ii) pump down the annuli, which will be done later today. Both were done at ~2pm, now we are in the vacuum normal config. I'll turn the two small turbos to run on "Standby Mode" before I head home today. I think TP3 may be close to end-of-life - the TP3 current went up to 1A even while evacuating the small volume of the annular line (which was already at 1 torr) with the AUX drypump backing it. The interlock condition is set to trip at 1.2A, and this pump is nominally supposed to be able to back TP1 during the pumpdown of the main volume from 500 mtorr, which it wasn't able to do.

1. Implemented image level noise for simulation. Added only uniform random noise.
2. Implemented addition of uniform random noise to any sinusoidal motion of beam spot.
3. Implemented motion along y axis according to data in "power_spectrum" file.
4. Impelemented simulation of random motion of beam spot in both x and y directions (done previously by Pooja, but a cleaner version).
5. Created a video file for 10s with motion of beam spot along the y direction as given by Attachment #1. This was created by mixing four sinusoids at different amplitudes (frequencies (0.1, 0.2, 0.4, 0.8) Hz Amplitudes as fractions of N = 64 (0.1 0.09 0.08 0.09). FPS = 10. Total number of frames = 100 for the sake of convenience.  See Attachment #5.
6. Following this, I used the thresholding (threshold = 127, chosen arbitrarily), contour detection and centroid computation sequence (see Attachment #6 for results) to obtain the plot in Attachment 2 for the predicted motion of the y coordinate. As is evident, the centering and scale of values obtained are off and I still haven't figured out how to precisely convert from one to another.
7. Consequently, as a workaround, I simply normalised the values corresponding to each plot by subtracting the mean in each case and dividing the resulting series of values by their maximum. This resulted in the plots in Attachments 3 and 4 which show the normalised values of y coordinate variation and the error between the actual and predicted values between 0 and 1 respectively.

Things yet to be done:

Simulation:

1. I will implement the mean square error function to compute the relativer performance as conditions change.
2. I will add noise both to the image and to the motion (meaning introduce some randomness in the motion) to see how the performance, determined by both the curves such as the ones below and the mean square error, changes.
3. Following this, I will vary the standard deviation of the beam spot along X and Y directions and try to obtain beam spot motion similar to the video in Attachment #2 of elog post 14632.
4. Currently, I have made no effort to carefully tune the parameters associated with contour detection and threshold and have simply used the popular defaults. While this has worked admirably in the case of the simple simulated videos, I suspect much more tweaking will be needed before I can use this on real data.
5. It is an easy step to determine the performance of the algorithm for random, circular and other motions of the beam spot. However, I will defer this till later as I do not see any immediate value in this.
6. Determine noise threshold. In simulation or with real data: obtain a video where the beam spot is ideally motionless (easy to do with simulated data) and then apply the above approach to the video and study the resulting predicted motion. In simulation, I expect the predictions for a motionless beam spot video (without noise) to be constant. Therefore, I shall add some noise to the video and study the prediction of the algorithm.
7. NOTE: the above approach relies on some previous knowledge of what the video data will look like. This is useful in determining which contours to ignore, if any like the four bright regions at the corners in this video.

Real data:

1. Obtaining real data and evaluate if the algorithm is succesful in determining contours which can be used to track the beam spot.
2. Once the kind of video feed this will be used on is decided, use the data generated from such a feed to determine what the best settings of hyperparameters are and detect the beam spot motion.
3. Synchronization of data stream regarding beam spot motion and video.
4. Determine the calibration: anglular motion of the optic to beam spot motion on the camera sensor to video to pixel mapping in the frames being processed.

Other approaches:

1. Review work done by Gabriele with CNNs, implement it and then compare performance with the above method.

[chub, koji, gautam]

1. We executed the pre-pumpdown tasks per the checklist - heavy doors were on by ~1030am.
2. We were thwarted by the display of c1vac becoming unresponsive - the mouse cursor moves, but we could not interact with any screens. Connecting to c1vac by ssh with the -X option, we could interact with everything. Using top, we saw that the load average was reporting ~8 - this is pretty high! The most demanding processes were the modbus IOC and some python processes, presumably connected with the interlocks. We tried stopping the interlock systemctl process, kill -9ing the heavy processes, but to no avail. Next, we tried killing the X display proces, but this also did not fix the problem. Finally, we did a soft reboot of c1vac - the machine came back up, but still no interactivity. So we moved asia, the EY laptop, to the vacuum station for this pumpdown. We will fix the situation once the vacuum is in the nominal state.
3. The actual pumpdown commenced by first evacuating the EY and IY annular volumes with the roughing pump. There is an interlock condition that prevents V6 from being opened if the PRP gauge reports < 0.25 torr (this is to protect against oil backstreaming from the roughing pumps I believe). To get around this, we gave the roughing pumps some work by exposing the annular line to the atmospheric pressure of the EY and IY annuli. In a few minutes, both of these reported < 1 torr.
4. Main volume pumping started around noon - we have been going down in pressure steadily at ~3 torr/min (Koji has a nice python utility made that calculates the rate from the pressure channel).
5. At the time of writing, after ~3.5 hrs of pumping, we are at 25 torr. I will keep going till ~1 torr, and then valve off the main volume until tomorrow, when Chub and I will work on getting the turbo pumps exposed to the main volume. Pausing at 355pm while I go for the colloquium. Resumed later in the evening, stopping for today at 500 mtorr.
6. In preparation for the increased load on TP2 and TP3, I spun them up to the "high RPM mode" from their nominal "Standby mode".

Close up photos of the EY and IY chambers may be found here.

Update on the display manager of c1vac: I was able to get it working again by running sudo systemctl restart display-manager. Now I can interact with the MEDM screens on c1vac. It is a bit annoying that this machine doesn't have the users directory so I don't have access to the many convenient StripTool templates though - maybe I'll make local copies tomorrow for the pumpdown.

On Tuesday, I tried reproducing Pooja's measurements (https://nodus.ligo.caltech.edu:8081/40m/13986). The table below shows the values I got. Pictures of LED circuit, schematic and the setup are attached. The powermeter readings fluctuated quite a bit for input volatges (Vcc) > 8V, therefore, I expect a maximum uncertainity of 50µW to be on a safer side. Though the readings at lower input voltages didn't vary much over time (variation < 2µW), I don't know how relaible the Ophir powermeter is at such low power levels. The optical power output of LED was linear for input voltages 10V to 20V. I'll proceed with the CCD calibration soon.

I have done the following thus far since elog #14626:

Simulation:

1. Cleaned up Pooja's code for simulating the beam spot. Added extensive comments and made the code modular. Simulated the Gaussian beam spot to exhibit 
   1. Horizontal motion
   2. Vertical motion
   3. motion along both x and y directions:
2. The motion exhibited in any direction in the above videos is the combination of four sinusoids at the frequencies: 0.2, 0.4, 0.1, 0.3 Hz with amplitudes that can be found as defaults in the script ((0.1, 0.04, 0.05, 0.08)*64 for these simulations.). The variation looks as shown in Attachment 1. For the sake of convenience I have created the above video files with only a hundred frames (fps = 10, total time ~ 10s) and this took around 2.4s to write. Longer files need much longer. As I wish to simply perform image processing on these frames immediately, I don't see the need to obtain long video files right away.
3. I have yet to add noise at the image level and randomness to the motion itself.  I intend to do that right away. Currently video 3 will show you that even though the time variation of the coordinates of the center of the beam is sinusoidal, the motion of the beam spot itself is along a line as both x and y motions have the same phase. I intend to add the feature of phase between the motion of x and y coordinates of the center of the beam, but it doesn't seem all too important to me right now. The white margins in the videos generated are annoying and make tracking the beam spot itself slightly difficult as they introduce offset (see below). I shall fix them later if simple cropping doesn't do the trick.
4. I have yet to push the code to git. I will do that once I've incorporated the changes in (3).

Circle detection:

1. If the beam spot intensity variation is indeed Gaussian (as it definitely is in the simulation), then the contours are circular. Consequently, centroid detection of the beam spot reduces to detecting these contours and then finding their centroid (center). I tried this for a simulated video I found in elog post 14005. It was a quick implementation of the following sequence of operations: threshold (arbritrarily set to 127), contour detection (video dependent and needs to be done manually), centroid determination from the required contour.  Its evident that the beam spot is being tracked (green circle in the video). Check #Attachment 2 for the results. However, no other quantitative claims can be made in the absence of other data.
2. Following this, Gautam pointed me to a capture in elog post 13908. Again, the steps mentioned in (1) were followed and the results are presented below in Attachment #3. However, this time the contour is no longer circular but distorted. I didn't pursue this further. This test was just done to check that this approach does extend (even if not seamlessly) to real data. I'm really looking forward to trying this with this real data.
3. So far, the problem has been that there is no source data to compare the tracked centroid with. That ought to be resolved with the use of simulated data that I've generated above. As mentioned before, some matplotlib features such as saving with margins introduce offsets in the tracked beam position. However, I expect to still be able to see the same sinusoidal motion. As a quick test, I'll obtain the fft of the centroid position time series data and check if the expected frequencies are present.

I will wrap up the simulation code today and proceed to going through Gabriele's repo. I will also test if the contour detection method works with the simulated data. During our meeting, it was pointed out that when working with real data, care has to be taken to synchronize the data with the video obtained. However, I wish to put off working on that till later in the pipeline as I think it doesn't affect the algorithm being used. I hope that's alright (?).

I did the following:

1. Checked the ETMY OSEM sensing matrix and OSEM actuation matrix - more on this later, but everything seems much more reasonable than it was prior to this vent.
2. Checked that the IMC could be locked with the low-power beam
3. Aligned the Y-arm cavity using the green beam. Then tweaked the TT1/TT2 alignment until I saw IR flashes in TRY.
4. Repeated #2 for the X arm, using the BS to control the beam pointing.
5. Confirmed that the AS beam makes it out of the vacuum. It is only ~30uW in a large (~1cm dia) beam, so not the clearest spot on an IR card, but looks pretty clean, no evidence of clipping. I removed an ND filter on the AS port camera in order to better see the beam on the CRT monitor, this should be re-installed prior to ramping the input power to the IMC again.
6. With the PRM aligned, I confirmed that I could see resonant flashes in the POP QPD.
7. With the SRM aligned, I confirmed that I could see SRC cavity flashes on the AS camera.

I think this completes the pre-pumpdown alignment checks we usually do. The detailed plan for tomorrow is here: please have a look and lmk if I missed something. 

Yesterday we noticed that the POS and SIDE eigenmodes were degenerate (with 1mHz spectral resolution). Moreover, the YAW peak had shifted down by ~500 mHz compared to earlier this week, although there was still good separation between PIT and YAW in the Oplev error signals. Ideas were (i) check if EQ stops were not backed out sufficiently, and (ii) look for any fibers/other constraints in the system. Today morning, I inspected the optic again. I felt the EQ stop viton tips were a bit close to the optic, so I backed them out further. Apart from this, I adjusted the LR and SIDE OSEM position in their respective holders to make the sensor voltages closer to half-light. Kicked the optic again just now, let's see if there is any change.

Remaining tasks:

1. Check EY table leveling.
2. Check EY actuation matrix diagonality using this technique.
3. Check that IR resonances are seen (and all the usual pre-pumpdown alignment checks).
4. Take close out pictures.
5. Heavy doors on, pump down.

If everything goes smoothly, I think we should plan for the heavy doors going back on and commencing the pumpdown tomorrow. After discussion with Koji, we came to the conclusion that it isn't necessary to investigate IPANG (high likelihood of it falling off the steering optics during the pumpdown) / AS beam clipping (no strong evidence that this is a problem) for this vent.

Update 1235: Indeed, the eigenmodes are back to their positions from earlier this week. Indeed, the POS and SIDE modes are actually better separated! So, the OSEM/magnet and EQstop/optic interactions are non-negligible in the analysis of the dynamics of the pendulum.

[koji, gautam]

We executed this plan. Photos are here. Summary:

1. Optic was EQ-stopped (face stops only)., with the OSEMs in situ. We tried to do this as evenly as possible to avoid any magnets getting stuck on OSEMs.
2. We used the specially procured acetone from Chub to drag wipe the HR face. This was a definite improvement, we should always get the correct grade of solvents when we attempt cleaning optics.
3. It was observed that drag-wiping did not really have the desired cleaning effect. So Koji went in with hemostat / lens tissue soaked in acetone and wiped the HR face. This improved the situation.
4. Applied a layer of F.C. Waited for it to dry, and then peeled it off. Under the green flashlight, the optic still looks horrific - but we decided against further drag-wiping/first-contacting. If the loss is truly 50 ppm, this is totally not a show-stopper for now.
5. Suspension cage was replaced. EQ stops were released. Bias voltages were adjusted to bring the Oplev spot back to the center of the QPD. Now a free-swinging data collection is ongoing...

So if nothing, we got to practise this new wiping technique with OSEMs in situ successfully.

Summary:

1. ETMY now shows four suspension eigenmodes, with sensible phasing between signals for the angular DoFs. However, the eigenfrequencies have shifted by ~10% compared to 16 May 2019.
2. PIT and YAW for ETMY as witnessed by the Oplev are now much better separated.
3. ITMY can have its bias voltage set to zero and back to nominal alignment without it getting stuck.
4. The sensing matrix for ETMY that I get doesn't make much sense to me. Nevertheless, the optic damps even with the "naive" input matrix.

So the primary vent objectives have been achieved, I think. 

Details:

1. ETMY free-swinging data after adjusting LL and SIDE coils such that these were closer to half-light values
   • Attachment #1 - oplev witnessing the angular motion of the optic. PIT and YAW are well decoupled.
   • Attachment #2 - complex TF between the suspension coils. There is still considerable imbalance between coils, but at least the phasing of the signals make sense for PIT and YAW now.
   • Attachment #3 - DoFs sensed using the naive and optimized sensing matrices.
   • Attachment #4 - sensing matrix that the free swinging data tells me to implement. If the local damping works with the naive input matrix but we get better diagonality in the actuation matrix, I think we may as well stick to the naive input matrix.
2. BR mode coupling minimization:
   • As alluded to in my previous elog, I tried to reduce the bounce mode coupling into the shadow sensor by rotating the OSEM in its holder.
   • However, I saw negligible change in the coupling, even going through a full pi radian rotation. I imagine the coupling will change smoothly so we should have seen some change in one of the ~15 positions I sampled in between, but I saw none.
   • The anomalously high coupling of the bounce mode to the shadow sensor readout is telling us something - I'm just not sure what yet.
3. ITMY:
   • The offender was the LL OSEM, whose rotational orientation was causing the magnet to get stuck to the teflon part of the OSEM coil when the bias voltage was changed by a sufficiently large amount.
   • I rectified this (required adjustment of all 5 OSEMs to get everything back to half light again).
   • After this, I was able to zero the bias voltage to the PIT/YAW DoFs and not have the optic get stuck - huzzah 😀 
   • While I have the chance, I'm collecting the free-swinging data to see what kind of sensing matrix this optic yields.

Tomorrow and later this week:

1. Prepare ETMY for first contact cleaning to remove the residual piece. 
   • Drag wipe the HR surface with dehydrated acetone 
   • Apply F.C. as usual, inspect the HR face after peeling for improvement if any.
   • This will give us a chance to practise the F.C.ing with the optic EQ-stopped (moving cage etc).
2. Confirm ETMY actuation makes sense.
   • Use the green beam for an ASS proxy implementation?
3. High quality close out pictures of OSEMs and general chamber layout.
4. Anything else? Any other tests we can do to convince ourselves the suspensions are well-behaved?

While we have the chance:

1. Fix the IPANG alignment? Because the TT drift/hysteresis problem is still of unknown cause.
2. Check that the AS beam is centered on OMs 1-6?
3. Recover the 70% AS light that is being diverted to the OMC?

Unrelated to this work: megatron is responding to ping but isn't ssh-able. I also noticed earlier to day that the IMC autolocker blinky wasn't blinking. So it probably requries a hard reboot. I left the lab for tonight so I'll reboot it tomorrow, but no nds data access in the meantime... 

For good measure: