The summery pages are working at a slow motion speed. It's response time 12 minutes.
Debian doesn't like EPICS. Or our XY plots of beam spots...Sad!
No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.
Ubuntu16 is not to my knowledge used for any CDS system anywhere. I'm not sure how you expect to have better support for that. There are no pre-compiled packages of any kind available for Ubuntu16. Good luck, you big smelly doofuses. Nyah, nyah, nyah.
Three replacement bulbs ordered
Rana can discribe how it happened.
IF A LAMP EXPLODES
This bulb was blown out on Feb 4, 2017 after 2 months of operation.
In http://nodus.ligo.caltech.edu:8080/40m/11793 I posted the calibrated PMC free-running displcament with/without IMC locked. Unfortunately, this measurement was done with a part of the IMC electronics not perfect (https://nodus.ligo.caltech.edu:8081/40m/11794). I did the same measurement after the fix, but there is no low freq data http://nodus.ligo.caltech.edu:8080/40m/11795.
Assuming we have the similar error signal leve in the low freq band as The entry 11793, the IMC is considered to be noisier than the PMC between 0.8 and 4Hz. But we should do the same measurement with the current electronics.
The PMC calibration can be found in this entry http://nodus.ligo.caltech.edu:8080/40m/11780
We are thinking to use the PMC signals to help us in figuring out the feedback / feedforward stuff and making it better.
Today we scoped out the PMC DAQ channels (which were never re-hooked up after the Joe/Jamie CDS upgrade 6 years ago).
There is a 4-pin LEMO connector on the front panel which gives
Both of these signals are buffered by the AD620 inst amp configured with a gain of 1. In the green scope trace, you can see that there's a ~110 MHz signal strongly evident there. In the spectrum analyzer screen shot there is a instrument noise trace and then a PMC error point trace. You can see that all the peaks are ony there when I connect to the servo board instead of a Terminator. This RF noise is mainly the higher harmonics of the 35.5 MHz modulation getting there. It seems to be in both the error and control DAQ outputs, and a question is whether or not it is also in the servo electronics.
I also attach a close up of the servo board in the region of the post-mixer LC low pass filtering. I think its supposed to be 4th order cutoff at 1 MHz, but maybe the caps are busted or there's a way for the RF from the mixer to bypass the filters and get into the main servo path?
In the medium term, we probably want to use the new PDH servo that Rich is making. Need to buy/make a HV driver to use, but that should be easy.
Going to the summary pages and looking at 'Today' seems to break it and crash the browser. Other tabs are OK, but 'summary' is our default page.
I've noticed this happening for a couple of days now. Today, I moved the .ini files which define the config for the pages from the old chans/ location into the /users/public_html/detcharsummary/ConfigFiles/ dir. Somehow, we should be maintaining version control of detcharsummary, but I think right now its loose and free.
The X arm air conditioner was not regulating properly. The arm temp was warmer than usual. I requested thermistor calibration.
The mechanic reset the thermostate to 68F last week. It was 70-71F before.
The ETMX oplev laser now running 4 C lower at 30 C inside the enclousure.
The ETMX optical table top is 5 C cooler at 21 C
The ETMX concrete wall temp 20 C at 9am with flow bench on.
ETMY conrete wall temp 23 C at 9am
The logging script is multiplying by 100 instead of 10 !
The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.
The HEPA filter speed at the Variac was turned down to 20V from 40
This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.
Some one turned up the PSL HEPA rotation voltage from 20 V to 33 ( 120V Variac ) and X-arm AC set temp lowered to 68F
Effects at 12" height from optical table :
1.0, 0.5 & 0.3 micron particle count goes to zero and temperature fluctuaion increased
Rotation speed voltage was set to 30V
What readouts do we have for the PMC length? If we could have a calibrated & whitened error and control signal for the PMC up to 16 kHz, perhaps we could see at what frequencies we can use it as a faux-RefCav.
On Wednesday at the meeting, we were discussing why we aren't able to achieve more seismic feedforward subtraction in MCL. We spent some time thinking about this yesterday, and this elog is meant to be a summary of the stuff we tried.
The seismometer spectra look similar enough to be explained by time of day variations, so perhaps the culprit is MC1. The ambient MCL spectrum is almost an order of magnitude higher above 4Hz now, with the nominal damping loop gains, as compared to back in January. I think the damping loops on MC1 need to be tweaked.
I repeated this measurement as follows:
Here is a calibrated MC_F spectrum:
RXA: I've added this plot of the free-running noise of the Lightwave NPRO which is probably similar to our Innolight Mephisto. Seems like the laser is quieter than MC_F everywhere below 100 Hz.
I've restored the damping loop gains to their nominal values. Analysis of the coherence between MCL and seismometer channels under this reduced gain setting is underway, results to follow.
I've reduced the gains of the damping on all 3 MC SUS by a factor of 3 for overnight observation as part of the ongoing feedforward noise cancellation investigations. I will return them to the nominal values tomorrow morning.
For sensing matrix, better to use single frequency sine response. We don't want to measure around the bounce or above the 28 Hz cutoff filters in the MC SUS.
Thanks to Koji's nice MATLAB script using DttData functions, I was able to quickly analyze the TF data. Essentially, this measurement was a repetition of what was done here. The difference is that the modulation depth has been increased by ~25x compared to that measurement from December 2016. Here are the measured TFs (before accounting for the 1/f^2 normalization) for the various quadrants and the PIT/YAW channels:
The plots above are just to illustrate that the measurement was clean between the band over which the averaging will be done to compute the TF amplitude - i.e. 7-15Hz. The full summary of TF amplitudes, standard deviations, and the sensing matrix in the style of the referenced elog (the actual excel spreadsheet is Attachment #4, minus some of the graphics Koji had on his excel sheet):
Inverting those matrices, we get the matrices that diagonalize the sensor-actuator chain:
I will try implementing these matrices tomorrow and take a look at the step responses of the loops - the idea is that perhaps the system wasn't optimally diagonalized before and perhaps we can now improve the bandwidths of all the loops.
I've taken a bunch of transfer function measurements from the MC ASC PIT and YAW channels to the WFS error signals using the same set of DTT templates Koji used while characterizing the WFS loops a couple of months ago, before the IMC RF changes. Analysis is underway and I will post the results here shortly...
As an aside, Rana had added 10dB and 20dB gains to all of the WFS filter banks yesterday. I tried engaging the 10dB gains on the two MC2_TRANS PD loops, and this did not seem to induce any instability. I stepped both loops and saw that as expected, the 1/e times for both of these loops is about 45 seconds now (compared to ~150 seconds at the nominal gain). These have been running all day today, and the IMC seems well behaved, so I am going to leave these on for now... Jacking up the gain on the MC2_TRANS_QPD loops by 20dB induced instability - same story for the 4 WFS loops with 10dB additional gain...
Motivation: see this elog
I was fiddling around for a few days trying to implement the method outlined in this paper to null this offset - I will post a separate elog about my efforts but Valera pointed out that we could try injecting an AF modulation at the IN2 input of the MC Servo Board. Last night, we hooked up an SR function generator (f = 312Hz, A = 0.01Vpp, IN2 gain = -5dB) to the unused BNC IN2 input of the MC Servo board. To avoid any additional offsets from the AO path during this measurement, I disconnected the LEMO cable (it is labelled).
We looked at the spectrum of the MC transmission around 312Hz and also 2*f = 624Hz. As a result of this modulation, we expect in the transmitted power, dP/P, a 2f term with amplitude ~(X_mod/X_0)^2 and a term at f with amplitude ~(X_offset * X_mod / X_0^2) - I may have missed out some numerical factors of order 1. So the latter should vanish if the offset at the error point is truly zero and the lock-point is the center of the resonance. Last night, we found that an offset in the range of -0.25 V to -0.19 V nulled this peak in the DTT spectrum. Today, the number was -0.05V. So the true offset seems to vary from lock to lock. Here are spectra around f=312Hz for a few different values of the offset slider (the center of the resonance seems to be -0.05V on the MEDM slider at this time).
Do these numbers make sense? Some time ago, I had pulled out the MC Servo board to find out what exactly is going on at this offset summing point. The MEDM slider goes from -10V to 10V, and by measuring the voltage at TP5 (see schematic below), I found that there is a 1/40 scaling factor between what is actually applied and the number on the MEDM slider (so for example, the numbers in the legend in the above plot have to be divided by 40). I've modified the MC Servo Board MEDM screen to reflect this. When I had pulled the board out, I noticed that in addition to the offset voltage applied via the backplane connector, there was also a potentiometer (R50 in the schematic below). I had nulled the voltage at TP5 using this potentiometer, but I guess drifts of ~5mV are possible.
Discussion on calibration of offset slider in Hz/V:
I've yet to do a rigorous calibration of this slider into Hz, but looking at the spectrum of the transmitted intensity at 2f, we estimated the coefficient (X_mod/X_0) ~ 3e-3 for an offset of 0.2V. dP/P ~1 when the applied modulation equals the linewidth of the cavity, which is 3.6kHz. So 0.2V of offset slider corresponds to ~ 10Hz frequency offset. In other words, I estimate the slider calibration to be 50Hz/V. So with the full range of +/- 10V, we should be able to scan ~1kHz of frequency offset. What does this imply about the variation of the offset slider value that removes the peak at 1f between locks? As mentioned above, this variation is ~0.2V over a day - with the calibration mentioned above, this corresponds to a change in cavity length of ~10um, which seems reasonable to me...
So how did all of this tie in with WFS SUM offsets? We did the following:
I neglected to screenshot the StripTool from the times we were doing these trials but I have the times, I will pull up some dataviewer plots and upload them here tomorrow...
We implemented the plan outlined in the previous elog. The visibility (Pmax-Pmin)/(Pmax+Pmin) calculated with the MC REFL PD levels with the MC locked/unlocked is now ~96% (up from 88%). The MC REFL DC level in lock is now ~0.12V (compared to 0.4V). Assuming a modulation depth of 0.1 @ 29.5MHz, about 25% of this (i.e. 0.03V) is from sideband light.
The procedure followed was (see sketch in previous elog for various optic labels):
We could probably tweak the fine positioning of L2 and L3 and improve the efficiency a little more, but the primary objective here was to see if there was any effect on the large common mode offset on the WFS demodulated "SUM" output. Unfortunately, we saw no effect.
Here are two photos of the relevant section of the PSL table before (left) and after (right) our work there:
The arrangement of filters in the WFS loop filter banks have been altered, Rana will update with details of the motivation behind these changes. Here is how the screen looks now:
I have updated the C1IOO SDF table, and also the mcwfson script to reflect these changes. The latter has been svn committed.
Last night, Valera and I looked into two aspects of the IMC:
I will post a more detailed elog about last night's work, but Valera also thought it might be a good idea to try and improve the mode-matching into the IMC. I couldn't find anything on the wiki/elog about the mode matching situation on the PSL table, so I quickly went over yesterday to measure some lengths. From looking at the MCREFL DC levels when the mode cleaner is locked (~0.37V) and unlocked (~5.7V), the current mode matching efficiency seems to be about 88%, so there is definitely some headroom for improvement.
Here is my cartoon of the situation on the PSL table. All lengths are measured in mm, and I would say correct to +/- 5 mm, so there could be considerable error here...
(L1 : f=+200mm. L2: f=-150mm. L3: f=+400mm)
I extracted the lengths from the edge of the PSL table to IM1 and MC1 from (what I think are) the latest CAD drawings on the DCC. I then put all this into an a la mode script [Attachment #5] - I assumed a waist of 370um at the PMC output mirror, and a waist of 1.78mm at MC1. I neglected the passage through the in-vac Faraday, EOM and BS1 (on the sketch above) and the MC1 substrate. I was able to achieve a theoretical mode-matching efficiency of 1 by just moving the positions of L2 and L3.
Given that there are probably errors of the order 0.5cm in the lengths on the PSL table, and also the in-vacuum distance to MC1, I figured it would be ideal to just move one lens and see if we can improve the efficiency. It looks like it may be more effective to move L2 than L3. The plot on the right shows that the sensitivity is approximately equal to the positioning of L2 and L3. Judging by this plot, looks like w.r.t. the coordinates in this plot, we are somewhere around (0.02,-0.02).
It looks like if we want to do this, moving L2 (f = -150mm) may be the best way to go.
%Create a beamPath object
InpPath = beamPath;
%Add components - for a first pass, ignore Faraday and HWPs, so only
%mirrors and lenses..
Koji diagnosed that the NAT router was to blame for this problem. I simply power cycled this router, and now the connectivity has been restored.
It was possible to log into nodus and then to pianosa - and it was also possible to log into the various control room machines once logged into nodus. However, the outward packets seemed to not get transmitted. Anyways, power cycling the NAT Router unit seems to have done the job.
There is no internet connectivity on any of the control room machines.
I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.
March 17, 2017 ETMX laser replaced at LT 3y with 1103P, sn T8070866
I did a quick measurement of the beam size on the MC REFL PD today morning. I disabled the MC autolocker while this measurement was in progress. The measurement set up was as follows:
This way I was able to get right up to the heat sink - so this is approximately 2cm away from the active area of the PD. I could also measure the beam size in both the horizontal and vertical directions.
The measured and fitted data are:
The beam size is ~0.4mm in diameter, while the active area of the photodiode is 2mm in diameter according to the datasheet. So the beam is ~5x smaller than the active area of the PD. I couldn't find anything in the datasheet about what the damage threshold is in terms of incident optical power, but there is ~100mW on th MC REFL PD when the MC is unlocked, which corresponds to a peak intensity of ~1.7 W / mm^2...
Even though no optics were intentionally touched for this measurement, I quickly verified that the spot is centered on the MC REFL PD by looking at the DC output of the PD, and then re-enabled the autolocker.
JDSU 1103P. sn T8070866, made March 2007, output power 2.7 mW, on pd 17,750 counts,
GV 17 March 3pm: I found the Innolight NPRO was off when I walked down to the X end earlier, possibly was accidentally tripped during the Oplev laser replacement. I turned it back on.
ETMX oplev laser is dead. It will be replaced this after noon. Sus damping recovered.
This 3 years old HeNe [ JDS 1103P, sn 351889 ] has been dying for some time or just playing possum at age 1,126 days
I did not replace the ETMX oplev laser because I was unable to bring up the the C1ASC_ETMX_OPTLEV_SERVO medm screen on laptops.
Finally I see what kicks the sus damping off
Huh? So should we ask them to put the container back? Or do you have some other theory about ETMX tripping that is not garbage related?
ETMX sus damping recovered.
Note: The giant metal garbage container was moved from the south west corner of CES months ago.
Rana suggested including some additional terms to the cost function to penalize high sensitivity to deviations in the layer thickness (L). So the list of terms contributing to the cost function now reads:
I did not include other sensitivity terms, like sensitivity to the refractive index values for the low and high index materials (which are just taken from GWINC).
There is still some arbitrariness in how I chose to weight the relative contributions to the cost function, but after some playing around, I think I have a solution that I think will work. Here are the spectral reflectivity and layer thickness plots for the HR and AR sides respectively.
HR side: for a 1% increase in the thickness of all layers, the transmission changes by 5% @ 1064nm p-pol and 0.5% @ 532nm s and p-pol
AR side: for a 1% change in the thickness of all layers, the transmission changes by <0.5% @ 532nm s and p-pol
(substrate to the right of layer 38)
I've also checked that we need 19 layer pairs to meet the spec requirements, running the code with fewer layer pairs leads to (in particular) large deviations from the target value of 50ppm @ 1064nm p-pol.
Do these look reasonable?
We have 50 pieces in the clean cabinet.
The east end AC unit is arching over and running rough at CES. Called for mechanic.......
Both belts were replaced and the unit is running happily.
Yarm script running on Pianosa. Still working on visualization of the ETMX lossmap.
Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.
Your technique works Koji
This was still running at ~9.30am today morning, at which point I manually terminated it after confirming with Johannes that it was okay to do so. Judging by the StripTool traces in the control room, the mode cleaner remained locked for most of the night, there should be plenty of usable data...
Note that I re-aligned the Y-arm (to experiment further with photo-taking) at about 9.30am, so the data after this time should be disregarded...
loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.
I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.
The MC was sort of misaligned. It was locking on some vertical HOMs. So I locked it and aligned the suspensions to the input beam (not great; we should really align the input beam to the centered spots on the MC mirrors).
With the HOMs reduced I looked at the MC servo board gains which Guatam has been fiddling with. It seems that since the Mod Depth change we're getting a lot more HOM locks. You can recognize this by seeing the longish stretches on the strip tool where FSS-FAST is going rail-to-rail at 0.03 Hz for many minutes. This is where the MC is locked on a HOM, but the autolocker still thinks its unlocked and so is driving the MC2 position at 0.03 Hz to find the TEM00 mode.
I lowered the input gain and the VCO gain in the mcdown script and now it very rarely locks on a HOM. The UGF in this state is ~3-4 kHz (I estimate), so its just enough to lock, but no more. I tested it by intentionally unlocking ~15 times. It seems robust. It still ramps up to a UGF of ~150 kHz as always. 'mcdown' commited to SVN.
The attached is the ETMY image with the single arm locked. This was the best I could do. Here is the recipe
I removed the video monitoring can and replaced it with Olympus SP-570UZ camera. It has no IR blocker. The OSEM light are dominant because I can not zoom in more.
I left the camera in place so you can try it. Leave the LEXAN plate on the glass window so no accident can happen. The illuminator is on and you can turn it off-on with the manual switch, close to the camera. Camera manual is on my desk.
As per Steve's request, I've checked the alignment of the IMC and the arms. These three cavities are locked and aligned.
Gautam and Steve,
Corrected oplev laser RIN plot at day 3
GV: The channel the PD Steve is using is hooked up to C1:ALS-FC_X_F_IN. As I found out today, there can be considerable RF pickup between the C1:ALS-FC_X_F_IN and C1:ALS-FC_Y_F_IN channels, which share a common 4-pin LEMO cable - this is because the rise time of the square wave output of the Wenzel dividers is <1us, so suitability of this particular channel for the RIN measurement set up has to be reconsidered. Perhaps we can use one of the six spare PEM channels over at 1X6.
We did the following:
1, switched data channel from C1:ALS-FC_X_F_IN to C1:PEM-MIC_1_OUT_DQ Actual connection at 1X7 rack, input C17
Tested channel with 1Hz, 100 mV sine wave through DV
2, placed BS into the beam path so the reflected value on the PDA100A 0.1mW, beam od ~1mm, beam path lenght 11 cm, gain 20dB 3.7Vdc
The full output of this 1103P 2.8 mW was saturating the PDA100A
Summery :finding it to be too good to be this good
Property tag found.
16 years old Lightwave NPRO M126-1064-700, sn 415 power output is tripping continously to zero.
The Lightwave Controller 125/126-OPN-POS sn516 was used in this test. Settings were lowered to close to nominal values without any success.
One can not determine what is broken: head or controller. This NPRO head was under Manasa's desk.
For a few days now, the "code status" page has been telling us that the summary pages are DEAD, even though the pages themselves seemed to be generating plots. I logged into the 40m shared account on the cluster and checked the status of the condor job (with condor_q), and did not find anything odd there. I decided to consult Max, who pointed out that the script that checks the code status (/home/40m/DetectorChar/bin/checkstatus) was looking for a particular string in the log files ("gw_daily_summary"), while the recent change in the default output of condor_q meant that the string actually being written to the log files was "gw_daily_summa". This script has now been modified to look for instances of "gw_daily" instead, and so the code status indicator seems to be working again...
The execution of the summary page scripts has also been moved back to pcdev1 (from pcdev2, where it was moved to temporarily because of some technical problems with pcdev1).
What we want from the light source for the AS port light injection:
We have four possible laser sources that we can use for the injection of 1064 nm from the back:
I think for maximum flexibility it's best to fiber-couple whichever source we choose on the PSL table and then just collimate it out of a fiber on the AS table. This way if we want to add fiber-coupled modulators of any kind it's a plug-and-play modification.
Different frequency control schemes are:
Either way we'll need a few things:
I'm working on how to best set this up at the AS port and interfere with normal operation as little as possible. Ideally we use a Faraday just like for squeezed light injection, but this requires some modification of the layout, although nothing that involves mode-matching.
All 3 cranes inspected by professional Fred Goodbar of Konecranes and load tested with 450 lbs at max reach on Friday, March 3, 2017
I've been sitting on some data for a while now which I finally got around to plotting. Here is a quick summary:
Attachment #1: I applied a step input to the offset of each of the six WFS loops and observed the step response. The 1/e time constant for all 4 WFS loops is <10s suggesting a bandwidth a little above 0.1Hz. However, the MC2 P and Y loops have a much longer time contant of ~150s. Moreover, it looks like the DC centering of the spot on the QPD isn't great - the upper two quadrants (as per the MEDM screen) have ~3x the cts of the lower pair.
I did not (yet) try increasing the gain of this loop to see if this could be mitigated. I accidentally saved this as a png, I will put up the pdf plot
Attachment #2: This is a comparison of the WFS error signals with the loops engaged (solid lines) vs disabled (dashed lines). Though these measurements were taken at slightly different times, they are consistent with the WFS loop bandwidths being ~0.1Hz.
Attachment #3: Comparison of the spectra of the testpoint channels and their DQ counterparts at the same time which are sampled at 512Hz. It does not look like there is any dramatic aliasing going on, although it is hard to tell what exactly is the order of the digital AA filter implemented by the RCG. Further investigation remains to be done... For reference, here are some notes: T1600059, T1400719
GV 7 March 2017 6pm: It looks like we use RCG v2.9.6, so it should be the latter document that is applicable. I've been going through some directories to try and find the actual C-code where the filter coeffs are defined, but have been unsuccessful so far...
I will update with the in-loop error signal spectra, which should give us some idea of the loop bandwidth.
I will look into lowering the sampling rate, and how much out-of-band power is aliasing into the 0-256 Hz band and update with my findings.