This evening I was able to obtain some images with the same lens on the GigE. 
The problem earlier, as Johannes pointed out, was that we were using too many adapters on the camera and so it was able to focus at really shallow distances or at really low depths of focus. 
So after removing the adapters we were able to focus on objects at much larger distances.

The mug for example was at a distance greater than 1.5 meters from the camera.

Here are some images that were captured on Allegra by plugging in the GigE to the PoE connector connected to the Martian. 

And here's another picture of Kaustubh, my fellow SURF, captured in all his glory by Rana! :)

50mm 1.8 lens with Basler camera at MC2 face with micro clamp 350617    Camera manuals plus

I tried to capture some images with the GigE inside the Interferometer area in the 40m today. For that, I connected the POE injector to the Netgear Switch in 1x6 and connected it to the GigE. I then tried to access the Pylon Viewer App through Paola but that seemed to have some errors. When trying to connect to the Basler, quite a few errors were encountered in establishing connection and trying to capture the image. There were a few errors with single shot capture but the continuous shot could not even be started. To locate the problem, I tried running the Pylon installation through Allegra in the control room and everything seemed to work fine there.

Few error messages encountered

createPylondevice error :Failed to read memory at 0xc0000000, 0xd800 bytes. Timeout. No message received.
Failed to stop the camera; stopgrab: Exception Occurred: Control Channel not open

Eventually I connected Paola to the Switch with an Ethernet cable and over this wired connection, the errors were resolved and I was able to capture some images in Continuous shot mode at 103.3 fps without any problem.

In the afternoon, Steve and I tried to install the camera near MC2 and get some images of the mirrors. Due to a restricted field of view of the lens on the camera, after many efforts to focus on the optic, we were able to get this image. MC2 was unlocked so this image captures some resonating higher order mode.

With MC2 locked, I will get some images of the mirror at different exposure times and try to get an HDR image.  
As per Rana's suggestion, I am also looking up which compression format would be the best to save the images in.

Thanks to Steve and Gautam, the IMC was locked.

I was able to capture images with the Rainbow 50 mm lens at exposure times of 100, 300, 1000, 3000, 10000 and 30 microseconds.(The pictures are in the same order). These pictures were taken at a gain of 300 and black level 64.

Special credits to Steve spent a lot of time help me a with setting up the hardware and focusing on the beam spot with the camera. 
I can't thank you enough Steve! :) 

Good installation. I think the images are still out of focus, so try to resolve into some small dots at the low exposure setting.

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 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.

[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.

[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'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). 

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, 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.

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.

There's this elog from Stephen about better 1064 sensitivity from Basler. We should consider getting one if he finds that its actual SNR is as good as we would expect from the QE improvement.

Might allow for better scatter measurements - not that we need more signal, but it could allow us to use shorter exposure times and reduce blurring due to the wobbly beams.

Nice, and we should also permanently install the camera server (c1cam) which is still sitting on the electronics bench. It is running an adapted version of the Python 2/Debian 8 site code. Maybe if COVID continues long enough I'll get around to making the Python 3 version we've long discussed.

I was giving a tour of the 40m yesterday. We were looking at the PSL table. About 30 seconds after I turned the lights on a glass cover from one of the lights (NW corner) popped out of its holder and smashed on the table.

I've cleaned up all the broken glass I could see but there may be some small shards there. Please use caution in that area.

Even in the switched state, the glitches stayed on MC1.

The coil driver electronics for MC1, upstream of the Satellite box, was what was previously MC3 electronics.

Attachment #1 shows that there were no glitches in MC3 sensor channels (which are now physically connected to what was previously MC1 coil driver electronics).

Attachment #2 shows the second trends for a 12 hour period for MC1 and MC3 sensor channels. The MC3 channels look well behaved, but there are frequent glitches (at least 9 in the last 12 hours ) visible in the MC1 channels.

So to recap:

• We switched MC1 satellite box - but glitch stayed on MC1, so it would seem the Satellite box is not to blame.
• We shutdown the watchdog and the glitches persisted.
• We switched the coil driver electronics for MC1, but glitches remained on MC1, and MC3 doesn't show any evidence of glitching. This and the previous bullet point suggest the coil driver electronics are not to blame.
• For the glitch posted in Attachment #1, I could see the MC-REFL spot moving around on the CCD monitors, so the glitches aren't just a feature in the shadow sensor readout. 

I need to confirm that the output of the coil driver board goes straight to the Sat. Box, but if there are no intermediate elements, the problem is either in the cable from coil driver to sat. box, or downstream of the Satellite box - i.e. vacuum feedthroughs or the suspension itself? The size of the glitches is roughly the same in all 4 face channels (~60-80cts pp).

GV addendum 14 Aug 2017, 10.30am: Attachment #3 shows the second trend for the MC sensor channels over the weekend. While there were many on Saturday, it seems that Sunday was quieter.

To add to Gautam's entry: we swapped the cables at the coil driver side (these are the ones that go from coil driver to sat box). In this state, damping is not useable since the MC1 servos would drive MC3.

~70 counts in the sensor means ~70 microns of motion. Since the watchdogs are off and the coil drivers are swapped, this can't be laser beam getting in to the sensors.

WE have to consider that these are some real strain release type events happening in the suspension wire or wire standoff, so may require a vent to inspect and possible repair MC1.

We used to have similar suspension excursion at ETMX. This was the motivation to replace the stand-offs from Al ones to ruby ones. Did the replacement solve the issue at ETMX?

I don't think we can say for sure. I was just talking to EricQ about this, he said the glitches were often seen when changing the alignment offsets when aligning the arm. I am pretty sure I have seen the ETMX alignment change abruptly since the Ruby Standoff replacement (the Oplev spot just slides across the MEDM display rapidly), but I can't find an elog where I've put in details. I also haven't done a whole lot of work with the arm cavities where I would have noticed this problem. There is this test that Eric did, and it didn't throw up any red flags. But the suspension can be well behaved for weeks at a time before this problem pops up again.

There was also the flaky power connection to the timing card on the ETMX expansion chassis which was fixed only recently, after which there has been no systematic investigation of the status of ETMX.

If it is true that these events are caused by strain building up in the suspension wire, I wonder how we can take systematic steps to avoid it. From what I remember of the SOS assembly procedure, the (unglued) standoff is slid along the optic with the wire under slight tension until the wire slips into the groove on the standoff. Then the tension in the wire is adjusted till the optic is pitch balanced and at the desired height. But it is easy to imagine imprinting some torsional stresses in the (40 um?) wire during this process of looping it around under the optic and placing it in the groove. But perhaps this mechanism makes a negligible contribution to the effect we are seeing, and some other mechanism is responsible in this case.

Kevin and I saw some weird IMC / PEM BLRMS behaviour today - see Attached screenshot. Not sure what was happening with the IMC, but MCtrans was oscillating at ~3Hz for a good 20 minutes or so. I just killed the lock, and restarted MCautolocker on megatron. There was a strange feature in the 3-10Hz BLRMS around that time as well. All seems back to normal now...

The wall StripTool indicated that the IMC wasn't too happy when I came in today. Specifically:

• MC1 watchdog was tripped.
• Even in the tripped state, MC REFL spot on the camera showed spot motion that was too large to be explained as normal seismic driven motion (i.e. with local damping supposedly disabled).
• Strange excursions were observed in the MC1 shadow sensor signal levels as well, see Attachment #1 - negative values don't make any sense for this readout.

The last time this happened, it was due to the Sorensens not spitting out the correct voltages. This time, there were no indications on the Sorensens that anything was funky. So I just disabled the MCautolocker and figured I'd debug later in the evening.

However, around 5pm, the shadow sensor values looked nominal again, and when I re-enabled the local damping, the MC REFL spot suggested that the local damping was working just fine. I re-enabled the MCautolocker, MC re-locked almost immediately. To re-iterate, I did nothing to the electronics inside the VEA. Anyways, this enabled us to work on the X arm ASS (next elog).

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...)

Here is an amplitude spectrum plot of y-arm cavity noise with a 50 Hz cutoff damping filter of the form zpk(0,[50;50],1). The low passing of this filter was intentionally extremely poor in order to see the damping noise in the cavity. The blue trace is the noise with no damping, which may be considered the 'best case' scenario from a noise point of view. The green has regular local damping on the ITMY. The ETMY has no damping for this measurement because the cavity control feedback to the ETMY takes care of its control when the cavity is locked. Notice the the large increase in noise from 40 Hz to 250 Hz, up to 1 order of magnitude. This noise is from the OSEM sensors passing through the damping loops. The red curve shows the y-arm noise with the exact same damping, except it is now applied in the global scheme. In this case, the damping noise falls completely below the baseline level of the cavity and becomes indistinguishable from the 'no damping' case.

If the damping injected enough noise I'd expect we would see a drop of 50 to 80 times switching from local to global. That is, the same factor measured in the transfer functions listed in log entry 8193.  However, the damping noise is only at most 1 order of magnitude above the baseline in this measurement. We would have to increase the damping noise by about another order of magnitude before we could expect to see the global damping noise in the cavity measurement.

The units of the cavity displacement in the plot were calculated using the 1.4e12 counts per meter calibration in log 6834. The measured UGF of the LSC loop at the time was 205 Hz. The peak in the plot above 200 Hz appears to be from this unity crossing. Moving the UGF also moves this peak.

Moral of the story: global damping can isolate the damping noise pretty well from the cavity signal.

The global damping input and output matrices were installed to run for the Y-arm. Since we are using just one arm for now, only the DARM and CARM DOFs were entered into the matrices.

The input matrix was set to have elements with magnitudes of 0.5 while the output matrix was set to have elements with magnitudes of 1. The input matrix gets the 0.5 because the sensor signals must be avergaed for each global DOF, to make an 'equivalent sensor' with the same gain. The output matrix gets magnitudes of 1 so that the overall gain of the global loops is the same as the local loops. A transfer function was measured on the CARM loop to check that the overall gain is in fact the same as the measured ITMY and ETMY loops.

Simple damping filters were installed for the ITMY and ETMY as well as the global y arm CARM and DARM loops.

The ETMY output tuning filter ETMY_GLOBPOS was set to have a gain of 0.4 because there is an extra gain of 2.5 relative to ITMY in some mysterious place as discussed in log 8172.

 New excitation points were added after the global damping loops for more testing options. The updated c1sus.mdl model was re-committed to the svn. Two interesting simulink 'requirements' were found during this minor modification. First, excitation points must be placed on the top level of the diagram. If they are in a subsystem you will get compiling errors. Second, the excitation name must end in _EXC. It will compile OK if you don't do this, but the excitation points will not put out any excitations.

To do further investigation on the mysterious gain factor of 2.5 between the ETMY and ITMY POS damping loops, I measured TFs in the POS direction to the locked YARM signal for each. This provides an additional sensor, common to both, so we can see if the gain is coming from the actuation side or sensing side of the damping loops. The difference in these TFs is about 

2.895

So it seems the majority of the damping gain difference is on the actuation side with some small difference on the sensing side. In order to allow for the later splitting of YARM LSC control between ITMY and ETMY (global damping and the cavity control must be along the same coordinate system), I placed this gain of 2.95 in ITMY_LSC.

To get a first measure of the relative performance of global damping to local damping I measured some TFs between the sensor signal inputs and YARM. So first, while the cavity was still locked with just ETMY, I measured a TF between C1:SUS-ITMY_SUSPOS_EXC and C1:LSC-YARM_IN1. Second, I split the cavity control evenly between the ETMY and ITMY by adjusting C1:LSC-OUTPUT_MTRX. I turned off the local damping and turned on the common DOF global damping (called CARM at this point despite being on just one arm). I then repeated the same TF but driving from C1:SUS-GLOBAL_CARMDAMP_EXC.

The resulting TFs are displayed in the attached figure. The blue curve is then the TF from local damping sensor noise to YARM. The green is global damping sensor noise to YARM. The suppression between local to global is in red. The global damping curve is about 50 to 100 times lower (better) than local damping. This can probably be improved with further tuning to account for remaining differences between the ITMY and ETMY.

Note, the damping loop used in the filter modules for all of these is zpk(0,[15 15],1), with a gain of 30. This purposely has little high frequency filtering so it is easier to see the influence on YARM.

Brett and Kamal

The global damping testing for the week is now complete. The c1sus.mdl simulink diagram settled on the attached screenshot. The top level of c1sus.mdl is shown on the left zoomed in over the new global damping block. The right shows the inside of that block. Also attached in the second screenshot are two of the modal damping MEDM screens. The left shows the main overview screen, the right shows the global damping filters. The overview screen is called C1SUS_GLOBAL.adl and is found in ...medm/c1sus/master/.

We have measured transfer functions and power spectra that show that global damping, with just a moderate amount of tuning (30 minutes of work) reduces the OSEM damping noise seen by YARM_IN1 by a factor between 50 and 80. Log 8193 highlights the transfer function measurements. The power spectra directly measure the noise in the cavity. I am not putting that data here because I have to catch. I will process the data and post it here later.

Overall the global damping tests appear to have been successful, isolating (not removing) the test mass damping noise from the cavity by almost 2 orders of magnitude. Presumably even more isolation is possible with more tuning.

I was looking at the laser head/amp and somehow decided to open the glue freezer. And it was stuck. I've managed to open it but the upper room was completely frozen.
Some of the batteries were embedded in a block of ice. I think we should throw them out.

Can the person who comes in the morning work on defrosting?

- Coordinate with Yehonathan and move the amps and the wooden crate so that you can move the freezer.

- Remove the contents to somewhere (it's OK to be room temp for a while)

- Unplug the freezer

- Leave the freezer outside with the door open. After a while, the ice will fall without care.

- At the end of the day, move it back to the lab. Continue defrosting the other day if the ice remains.

{Paco, Anchal, Yehonathan}

We emptied the fridge and moved the amplifier equipment on top of the amplifier crate. We unplugged the freezer and moved it out of the lab to defrost (attachment).

There is still a huge chunk of unmelted ice in the fridge. I moved the content of that fridge in the main fridge and put "do not eat" warning signs.

I returned the fridge to the lab and plugged it back in to prevent flooding.

Defrosting will have to continue on Monday.

{Anchal, Paco, Yehonathan}

We took the glue fridge outside.

{Paco, Yehonathan}

We broke the last chunk of ice and cleaned the fridge. We move the fridge back inside and plugged it into the wall. The glues were moved back from the main fridge.

The batteries that were found soaking wet are now somewhat dry and were left on the cabinet drawers for future recycling.

I examined the magnet-dumbbell joints under the microscope to see whether the glue that I applied yesterday was sufficient or in excess.

I think the pictures below speak for themselves !  

During the gluing process the Al dumbbell stays below and the magnet with a drop of glue on the lower face is placed on it and held in the teflon fixture.  As seen in the pics the glue seems to have run up the surface of the magnet and has not collected in the narrow part of the dumbell.  So it has climbed up along the narrow gaps between the magnet and the teflon fixture by capillary action. The glue stops where the teflon fixture ends, a little before reaching the free end of the magnet, which further indicates the capillary action.

Jenne and kiwamu

We have glued the dumbbells to the magnets that will be used for the ITMs

We made two sets of glued pair of the dumbbell and the magnet ( one set means 6 pairs of the dumbbell and the magnet. Therefore in total we got 12 pairs. )

You can see the detailed procedure we did on the LIGO document E990196.

Actually we performed one different thing from the documented procedure;

we made scratch lines on the surface of the both dumbbells and magnets by a razor blade.

According to Steve and Bod, these scratch make the strength of the glues stronger.

Now the dumbbell-magnet pairs are on the flow bench in the clean room, and supported by a fixture Betsy sent us.

- -  notes

On the bench the left set is composed by magnets of 244 +/- 3 Gauss and the right set is 255 +/- 3 Gauss.

[ericq, Lydia]

Here is a picture of the ETMX guide rod post-gluing. There is unfortunately a fair amount of excess. The "tab" is the result from the epoxy travelling along the finger of the fixture arm that held the guide rod.

We set out to glue the previously remove ETMX side magnet, and set up the fixture to do so. For ETMX we needed 3 mm of shimming on the thick side, and 6mm on the thin side.

However, while cleaning the magnet+dumbbell base of epoxy residue, I broke the dumbbell off of the magnet 

We then fetched the spare side magnet that Steve had been holding onto. While cleaning it, it was dropped and dissapeared from this plane of existence 

So, instead of gluing a side magnet today, we are gluing the existing magnet and dumbbell back together:

Sadly, this used up the last of our EP30.

Though Koji had the foresight to order more(), it will not arrive until Monday/Tuesday, so no side magnet gluing until then.

Goal of this week :  ALS on the Y arm

Minimum success : Detection of the green beatnote between the freq-doubled PSL and the Y arm transmitted light

Goal of this week : Noise budgeting on the Y arm ALS

Minimum success : bring the Y arm to the resonance by using ALS  NOISE BUDGETING!!!

 => as a preparation the incident beam pointing needs to be fixed by steering the MC suspensions.

Apparently when updating front end codes from rtlinux to the patched Gentoo, certain files don't get deleted when running make clean, such as the sysfe.rtl files in the advLigoRTS/src/fe/sys directories.  This fouls the start up scripts by making it think it should be configured for rtlinux rather than the Gentoo kernel module.

Introduction

This is an update of my previous reports on applications of deep learning to the reconstruction of PRMI degrees of freedom (MICH/PRCL) from real free swinging data. The results shown here are improved with respect to elog 13274 and 13294. The training is performed in two steps, the first one using simulated data, and the second one fine tuning the parameters on real data.

First step: training with simulation

This step is exactly the same already described in the previous entries and in my talks at the CSWG and LVC. For details on the DNN architecture please refer to G1701455 or G1701589. Or if you really want all the details you can look at the code. I used the following signals as input to the DNN: POPDC, POP22_Q, ASDC, REFL11_I/Q, REFL55_I/Q, AS55_I/Q. The network is trained using linear trajectories in the PRCL/MICH space, and signals obtained from a model that simulates the PRMI behavior in the plane wave approximation. A total of 150000 trajectories are used. The model includes uncertainties in all the optical parameters of the 40m PRMI configuration, so that the optical signals for each trajectory are actually computed using random optical parameteres, drwn from gaussian distributions with proper mean and width. Also, white random gaussian sensing noise is added to all signals with levels comparable to the measured sensing noise.

The typical performance on real data of a network pre-trained in this way was already described in elog 13274, and although being reasoble, it was not too good.

Second step: training with real data

Real free swinging data is used in this step. I fine tuned the demodulation phases of the real signals. Please note that due to an old mistake, my convention for phases is 90 degrees off, so for example REFL11 is tuned such that PRCL is maximized in Q instead of I. Regardless of this convention confusion, here's how I tuned the phases:

• REFL11: PRCL is all in Q when crossing the carrier resonance
• REFL55: PRCL is all in Q when crossing the carrier resonance
• AS55: MICH is all in Q when crossing the PRCL carrier resonance
• POP22: signal peaking in Q when crossing carrier or sideband resonances. Carrier resonance crossing gives positive sign

Then I built the following training architecture. The neural network takes the real signals and produces estimates of PRCL and MICH for each time sample. Those estimates are used as the input for the PRMI model, to produce the corresponding simulated optical signals. My cost function is the squared difference of the simulated versus real signals. The training data is generated from the real signals, by selection 100000 random 0.25s long chunks: the history of real signal over the whole 0.25s is used as input, and only the last sample is used for the cost function computation. The weights and biases of the neural network, as well as the model parameters are allowed to change during the learning process. The model parameters are regularized to suppress large deviations from the nominal values.

One side note here. At first sight it might seems weird that I'm actually fedding as input the last sample and at the same time using it as the reference for the loss function. However, you have to remember that there is no "direct" path from input to output: instead all goes through the estimated MICH/PRCL degrees of freedom, and the optical model. So this actually forces the network to tune the reconstruction to the model. This approach is very similar to the auto-encoder architectures used in unsupervised feature learning in image recognition.

Results

After trainng the network with the two previous steps, I can produce time domain plots like the one below, which show MICH and PRCL signals behaving reasonably well:

To get a feeling of how good the reconstruction is, I produced the 2d maps shown below. I divided the MICH/PRCL plane in 51x51 bins, and averaged the real optical signals with binning determined by the reconstructed MICH and PRCL degrees of freedom. For comparison the expected simulation results are shown. I would say that reconstructed and simulated results match quite well. It looks like MICH reconstruction is still a bit "compressed", but this should not be a big issue, since it should still work for lock acquisition.

Next steps

There a few things that can be done to futher tune the network. Those are mostly details, and I don't expect significant improvements. However, I think the results are good enough to move on to the next step, which is the on-line implementation of the neural network in the real time system.

This note reports analysis of cavity scans made by directly sweeping the AUX laser carrier frequency (no sidebands). The measurement is made by sweeping the RF offset of the AUX-PSL phase-locked loop and demodulating the cavity reflection/transmission signal at the offset frequency.

Y-Arm Scan

Due to the simplicity of its expected response, the Y-arm cavity was scanned first as a test of the AUX hardware and the sensitivity of the technique. Attachment 1 shows the measured cavity transmission with respect to RF drive signal.

The AUX laser launch setup is capable of injecting up to 9.3 mW into the AS port. This high-power measurement is shown by the black trace. The same measurement is repeated for a realistic SQZ injection power, 70 uW, indicated by the red curve. At low power, the technique still clearly resolves the FSR and six HOM resonances. From the identified mode resonance frequencies the following cavity parameters are directly extracted.

PRC Scan

An analogous scan was performed for the PRC, with the IFO locked on PSL carrier in PRMI. Attachment 2 shows the measurement of PRC transmission with respect to drive signal.

The scan resolves HOM resonances to at least ~13th order, whose frequencies yield the following cavity parameters.

SRC Scan

Ideally (and at the sites) the SRC mode resonances will be measured in SRMI configuration. Because every other cavity is misaligned, this configuration provides an easily-interpretable spectrum whose resonances can all be attributed to the SRC.

Due to time constraints at the 40m, the IFO could not be restored to lockability in SRMI. It has been more than two years since this configuration was last run. For this reason the scan was made instead with the IFO locked in DRMI, as shown in Attachment 3. The quantity measured is the AUX reflection with respect to drive signal.

This result requires far more interpretation because resonances of both the SRC and PRC are superposed. However, the resonances of the PRC are known a priori from the independent PRMI scan. The SRC mode resonances identified below do not conincide with any of the first five PRC mode resonances.

Based on the identified mode resonance frequencies, the SRC parameters are measured as follows.

Lessons Learned

From experience with the 40m, the main challenges to repeating this measurement at the sites will be the following.

• Pointing jitter of the input AUX beam. This causes the PSL-AUX beam overlap to vary at transmission (or reflection), causing variation in the amplitude of the AUX-PSL beat note. As far as we can tell, the frequency of the resonances (the only object of this measurement) is not changing in time, only the relative amplitudes of the diferent mode peaks. I believe the SQZ alignment loops will mitigate this problem at the sites.
• Stabilization of the network analyzer time base. We found the intrinsic frequency stability of the network analyzer (Agilent 4395A) to be unacceptably large. We solved this problem by phase-locking the Agilent to an external reference, a 10-MHz signal provided by an atomic clock.

From the Measurement Jon made, FSR is 3.967 MHz and the Gouy phase is 52 degrees. From this, the length of the Y-arm cavity seems to be 37.78 m and the radius of curvature of the mirror seems to be 60.85 m.

FSR = Free spectral Range

L = Lenth of the arm

R = Radius of curvature of the mirror (R1 =  , R2= unknown)

vanna --> QIL.

gautam 20190804: The GPIB module + power supply were returned to me by Duo ~5pm today at the 40m.

This is the grand plan we talked about in the beginning of the meeting.

• (Kiwamu) X-end Green cleaning up / Prep for DRMI
• (Bryan) Y-end Green
• (Suresh) Help Bryan / RF (w. Kevin)
• (Jenne) MC WFS / Y-arm IR alignment / MC adaptive feedforward (incl. CDS)
• (Koji) LSC
• (Joe) CDS cleaning up
• (Jamie) Help Joe / Noise Budget
• (Larisa) PMC scan / PSL photo&diagram
• (Barbarela) ASS

The seismometers showed an increased noise in the Y-direction when put on top of the granite slab. By tapping the slab, you can tell that its really a mechanical resonance of the lead balls + granite system at ~15-20 Hz.

I tried new balls, flipping the slab upside down, and sitting on the slab for awhile. None of this changed the qualitative behavior, although each of the actions changed the resonance frequencies by several Hz.

I have removed the granite/balls and put the seismometers back on the linoleum floor. The excess noise is gone. I have put the new big box back on top of them and we'll see how the data looks overnight.

I expect that we should remove the linoleum in a wider area and put the seismometers directly on the floor.

This plot shows the noise with the box on, but no granite. We're still pretty far off from the Guralp data sheet.

I implemented software rotation in the huddle subtraction as Valera suggested and it works much better. The two plots below show the before and after. So far this is just 2 deg. of rotation around the z-axis. I'm assuming that aligning the seismometers vertically via bubble level is good enough for the z-axis, but I haven't calibrated the bubble yet.

The residual slope is now suspiciously smooth. I somehow suspect that our readout electronics can still be responsible. We need to hook up a 9V battery to the input terminals to check it out. Its a little steeper than 1/f and I thought that we had exonerated the Guralp breakout box in the past, but now I'm not so sure. I'll let Jenne comment on that.

I also noticed that we have not yet divided by sqrt(2) to account for the fact that we are subtracting 2 seismometers. In principle, an unbiased estimate of the single seismometer noise will be lower by sqrt(2) than the green curve.

Graph Limits: The limits on graphs have been problematic.  They often reflect too large of a range of values, usually because of dropouts in data collection.  Thus, they do not provide useful information because the important information is washed out by the large limits on the graph.  For example, the graph below shows data over an unnecessarily large range, because of the dropout in the 300-1000Hz pressure values.

The limits on the graphs can be modified using the config file found in /40m-summary/share/c1_summary_page.ini.  At the entry for the appropriate graph, change the amplitude-lim=y1,y2 line by setting y1 to the desired lower limit and y2 to the desired upper limit.  For example, I changed the amplitude limits on the above graph to amplitude-lim=.001,1, and achieved the following graph.

The limits could be tightened further to improve clarity - this is easily done by modifying the config file.  I modified the config file for all the 2D plots to improve the bounds.  However, on some plots, I wasn't sure what bounds were appropriate or what range of values we were interested in, so I will have to ask someone to find out.

Next:  I now want to fix all the funny little problems with the site, such as scroll bars appearing where they should not appear, and graphs only plotting until 6PM.  In order to do this most effectively, I need to restructure the code and factor it into several files.  Otherwise, the code will not only be much harder to edit, but will become more and more confusing as I add on to it, compounding the problems that we currently have (i.e. that this code isn't very well documented and nobody knows how it works).  We need lots of specific documentation on what exactly is happening before too many changes are made.  Take the config files, for example.  Someone put a lot of work into them, but we need a README specifying which options are supported for which types of graphs, etc.  So we are slowed down because I have to figure out what is going on before I make small changes.

To fix this, I will divide the code into three main sectors.  The division of labor will be:
- Sector 1: Figure out what the user wants (i.e. read config files, create a ConfigParser, etc...)
- Sector 2: Process the data and generate the plots based on what the user wants
- Sector 3: Generate the HTML