Raw and JPG formats of the pictures are saved on the Mac in the control room and at this link:
The camera was mounted using the JOBE arm wrapped around a small heavy piece of metal. The lights were kept on, the camera was zoomed in as closely as possible (so the light would take up most of the frame), F number of 8 was used, and shutter speeds from 1/2 to 1/100 seconds were used.
The pictures still look a bit blurry, probably because looking back at the details of the image, the focal length was 86.34m (as short of a focal length would be ideal, and Olympus is capable of going down to 1m).
Next steps include looking at the saturation in the pictures and setting up a more stable mount.
A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight.
The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa
Apologies for any inconvenience.
Data analysis will follow.
The previous run of the script had produced some dubious results!
The script has been modified and now scans the transmission sum for a longer duration to provide a better estimate on the average transmission. The pitch and yaw offsets have been set to the values that were randomly generated in the previous run as this would enable comparison with the current data.
I am starting it on Donatella and it should run for a couple of hours.
Apologies for the inconvenience.
The script didn't run properly last night, due to an oversight of variable names! It's been started again and has been running for half an hour now.
The values generated from the script were analyzed and a 3D scatter plot in addition to a 2D map were plotted.
Yesterday, Rana pointed me to another method of collecting and analyzing the data. So I worked on the code today and have left a script (MC2rerun.py) running on Ottavia which should run overnight.
The script is being executed again, now.
I worked on the code today and have left a script (MC2rerun.py) running on Ottavia which should run overnight.
Steve went over to the MC2 walkway and stepped over the barrier to pick up some stuff there. MC2 stack shifted and MC2 pitch as off. MC unlocked and could not relock till the MC2 pitch bias was readjusted
previous MC2PIT reading: 3.6235 current MC2PIT reading: 3.9565
Without the WFS the MC to PSL alignment is poor, but it is largely due to a shift in the MC and not a shift in the PSL beam. We know this 'coz the shift in the DC spot positions on WFS (when the MC is unlocked) is not significant nor is the shift on the C1:IOO-QPD. When WFS loops are engaged the MC optics are turned to optimise the PSL to MC alignment, but the shift is large at the moment.
(Sorry Mirko your measurement could not be completed. The MC unlocked in the middle)
Please Note: If you need to access the blocked off area near MC2 stack, do not step over the barrier. The disturbance is too great and the MC2 stack will shift. Instead please move the barrier aside and walk as gently as possible near it, taking care not to touch the MC2 Chamber.
Apparently the MC2 stack had not finished shifting. The MC unlocked while Steve was working on the PSL table installing the mirror for IOO_QPD and then it could not relock. So I moved the MC2 once again in Pitch. The current status of the sliders is here
Yesterday I fixed the yellow buttons on the MC_ALIGN and MCLOCK screens. They use the new updatesnap script . Could we also add a couple of lines to this script so that eveytime we save a snap shot the various values are written(appended) to a text file? That way we do not need to depend solely on the conlog, which is quite slow.
MC was not locked for more than 5 hours because of the misalignment.
Noticed that MC2 WFS feedback filters had big outputs (particularly in Pitch).
They were reset to zero.
MC2 was aligned and recovered the lock. Once the WFS is engaged, the transmission returned to the uisual value.
I found the YARM LSC feedback going to MC2 and the MC2 violin mode (at 644.69 Hz) rung up. The existing notch was just a second order Twin-T style notch (so not a good idea) and also not turned on, since it was in the FM4 spot of LSC-MC2 and the vio triggers are ganged between all mirrors and don't touch FM4.
I copied the PRM vio bandstop into FM2 of this bank, deleted the old notch, and tuned the bandstop frequencies a little to get the violin peak into one of the zeros of the elliptic bandstop. Attached are the Y-arm / MCF spectrum with the mode rung up as well as the new filter's TF compared with the old notch.
P.S. I installed http://en.wikipedia.org/wiki/Midnight_Commander on pianosa.
the POS column should be all 1 for the AC balancing. Where did those non-1 numbers come from?
Yes, during the AC balancing, POS column was set to all 1. This table shows the final values after all the steps. The first 3 columns are DC balancing results when output matrix was changed. While the last column is for AC balancing. During AC balancing, the output matrix was kept to ideal position as you suggested.
After centering the spot on the MC2, I started to adjust the spot position on MC_TRANS_QPD to center the beam on it. I noticed that the spot size was about 3 to 4mm dia. because the 200mm lens was too close to the QPD. I moved it back and decreased the spot size to about 1mm and the sensitivity to spot position increased. However, Koji noted that the QPD sectors were near saturation, so I put in a ND=0.3 filter to reduce the incident power on the QPD.
At optimal alignment the current QPD_SUM is around 25k to 26k counts (factor of 2 down). Eventually the gain of the QPD ckts have to be reduced to prevent saturation, for the moment this is temporary fix.
The MC_TRANS_SUM trigger for MC autolocker is working fine no further change was required.
While at the MC2 table, we noticed that it has some optical problems:
We estimated that the power in the IMC is (1 W)*Finesse/pi = 500 W. The MC2 Transmission spec is < 10 ppm, so the power on the table is probably ~5 mW. Since the PDA255 has a transimpedance of 10 kOhm and a max output power of 10V, it can handle up to ~1 mW. Probably we can get the QPD to handle 4 mW.
Gautam, Steve 3-27
We measured MC2 transmitted power right at the uncoated window ~2.5 mW The beam was just a little bigger than the meter.
The MC2 watchdogs tripped. I just restored them.
I also had to relock the MZ and then the Mode Cleaner.
the mode cleaner was having trouble locking in a 00 mode, needing several tries. I changed the MC2 coil biases, and it seems better for now.
We went near the MC2 area and opened the lid to inspect the GigE and analog video monitors for MC2. Looked like whatever image is coming through the viewport is split into the GigE (for beam tracking) and the analog monitor. We hooked the monitor found on the floor nearby and tweaked the analog video camera around to get a feel for how the "ghost" image of the transmission moves around. It looks like in order to try and remove this "extra spots" we would need to tweak the beam tracking BS. We will consult the beam tracking authorities and return to this.
[Kruthi, Yehonathan, Gautam]
Today evening, Yehonathan and I aligned the MC2 cameras. As of now there are 2 GigEs in the MC2 enclosure. For the temporary GigE (which is the analog camera's place), we are using an ethernet cable connection from the Netgear switch in 1x6. The MC2 was misaligned and the autolocker wasn't able to lock the mode cleaner. So, Gautam disabled the autolocker and manually changed the settings; the autolocker was able to take over eventually.
Kiwamu, Koji, Valera
We centered the beam on MC2 in pitch by moving the MC1,2,3 in the following combination [-9,+3,-7]. This actuation vector mostly moves the spot on MC2 vertically. The attached plot shows the dither before and after the centering. We monitored the demodulated signals and saw the reduction of the MC2 pit response from -1.0 to -0.22 which corresponds to the beam spot position change from 9 to 2 mm. Thus all the spots on MC mirrors are within 2 mm of the center. We estimate based on the distance between the MC1-MC3 of 20 cm, the distance from the center between MC1 and MC3 to the end of the Faraday isolator of 80 cm, and the aperture of the FI of 12 mm, the maximum angle out of MC of 3/200 rad. Which implies the maximum differential spot motion of 3 mm not to be limited by the FI aperture.
Thinks to do before the NEXT realignment:
B, tie 4 ancher bolts on table legs to the floor
C, tie 4 dog clamps between table and chamber
D, check the locked position of the 4 x 4 positioning screws
E, check bellow protecting 4 tubes are not shorting
A, here is the concrete slab cut
It reminds me to check the IFO vacuum envelope dog clamps on the chambers to floor with torque wrench.
I locked the PMC and MC resonated in TM00 right on. Than I started checking anchoring screws with the torque wrench.
B, 3/8 foor bolts were tight, They were set to 50 ft/lbs
C, dog clamp bolts were tight at 80 ft/lbs
D, horizontal position locks were lose. They were locked by finger.
E, below covers were reset not to short
The MC is locking in TM01 mode now
we measured the RIN of the MC2 transmission using the PDA255 I had put on the MC2 trans table sometime ago for ringdowns. Attached are (i) spectra for the RIN, (ii) spectra for the classical rad. pressure noise assuming 500W circulating power and (iii) a tarball of data and code used to generate these plots.
We took a full span measurement (to make sure there aren't any funky high-freq features) and a measurement from DC-800 Hz (where we are looking for excess noise). The DC level of light on the photodiode was 2.76V (measured using o'scope)
I'll add this to the noise budget later. But the measured RIN seems consistent with a 2013 measurement at 100Hz (though the 2013 measurement is using DTT and so doesn't have high frequency information).
Following up from morning's work, I balanced the coils at DC as well. Attachment 1 is screenshot of striptool in which blue and red traces show ASCYAW and ASCPIT outputs when C1:SUS-MC2_LSC_OFFSET was switched by 500 counts. We see very slight disturbance but no real DC offset shown on PIT and YAW due to position step. This data was taken while nominal F2A filter calculated to balance coils at DC was uploaded
I have uploaded the filters on filter banks 7-10 where FM7 is the nominal filter with Q close to 1 and 8-10 are filters with Q 3, 7 and 10 respectively. The transfer function of these filters can be seen in Attachment 2. Note, that the high frequency gain drops a lot when higher Q filters are used.
These filters are designed such that the total DC gain after the application of coil outputs gains for high frequency balancing (as done in morning 16054) balances the coils at DC.
Since I had access to the complete output matrix that balances the coils to less than 1% cross coupling at high frequencies from 16009, I also did a quick test of DC coil balancing with this kind of high frequency balancing. In this case, I uploaded another set of filters which were made at Q close to 1 and gain such that effective DC gain matrix becomes what I got by balancing in the above case. This set of filter also worked as good as the above filters. This completes the proof that we can also use complete matrix for high frequency coil balancing which can be calculated by a script in 20min and works with DC coil balancing as well. In my opinion, this method is more clear and much faster than toggling values in coil output gains where we have only 4 values to optimize 6 cross-coupling parameters. But don't worry, I'm not wasting time on this and will abandon this effort for now, to be taken up in future.
Corrected the calculation of filters in case of Q different than . There was a bug in the code which I overlooked. I'll correct the filter bank modules tomorrow.
Edit Wed Apr 21 11:06:42 2021 :
I have uploaded the corrected foton filters. Please see attachment 3 for the transfer functions calculated by foton. They match the filters we intended to upload. Only after uploading and closing the foton filter, I realized that the X=7 filter plot (bottom left in attachment 3) does not have dB units on y-axis. It is plotted in linear y-scale (this plot in foton is for phase by default to I guess I forgot to change the scaling when repurposing it for my plot).
We did some quick DC balancing of the MC2 coil drivers to reduce the l2a coupling. We updated the gains in the C1:SUS-MC2_UL/UR/LR/LLCOIL to be 1, -0.99, 0.937,-0.933, respectively. The previous values were 1, -1, 1, -1.
The procedures are the following:
Drive UL+LR and change the gain of LR to zero pitch.
Drive UR+LL and change the gain of LL to zero pitch.
Lastly, drive all 4 coils and change UR & LR together to zero yaw.
We used C1:SUS-MC2_LOCKIN1_OSC to create the excitations at 33 Hz w/ 30,000 cts. The angular error signals were derived from IMC WFSs.
While this time we did things by hand, in the future it should be automated as the procedure is sufficiently straightforward.
My old scheme was flawed as I used pitch as the readback. The pitch signal could not distinguish the cross-coupling due to coil imbalance and that due to the natural suspension L2P. A new scheme based on yaw alone has been developed and will be integrated into ifo_test. For now we revert the C1:SUS-MC2_UL/UR/LR/LLCOIL gains back to 1, -1, 1, -1.
I was looking at some signals from last night, see Attachment #1.
Attachment #2 shows some ASC metrics. My conclusion here is that running the PRCL and MICH dither alignment servos (former demodulating REFLDC and latter demodulating ASDC to get an error signal) that running the dither alignment servo and hand tuning the arm ASC loop offsets improves the mode matching to the IFO, because:
The REFLDC behavior needs a bit more interpretation I think, because if the IFO is overcoupled (as I claim it is), then better alignment would at some point actually result in REFLDC increasing.
All the DC signals recorded by the fast system come from the backplane P2 connector of the PD interface boards. According to the schematic, these signals have a voltage gain of 2. The LSC photodiodes themselves have a nominal DC gain of 50 ohms. So, the conversion from power to digital counts is: 0.8 A/W * 50 V/A * 2 * 3276.8 cts/V * whtGain. Inverting, I get 3.8 uW/ct for a whitening gain of 1. This is power measured at the photodiode - optical losses upstream of the photodiode will have to be accounted for separately.
Assuming a modulation depth of 0.2, the 55 MHz sideband power should be ~20 mW. The Schnupp asymmetry is supposed to give us O(1) transmission of this field to the AS port. Then, the SRM will attenuate the field by a factor of 10, so we expect ~2 mW at the AS port. Let's assume 80 % throughput of this field to the AP table, and then there is a 50/50 beamsplitter dividing the light between the AS55 and AS110 photodiodes. So, we expect there to be ~700 uW of power in the TEM00 mode 55 MHz sideband field. This corresponds to 1600 cts according to the above calibration (the ASDC whitening gain is set to 18 dB). The fact that much smaller numbers were seen for ASDC indicates that (i) the schnupp asymmetry is not so perfectly tuned and the actual transmission of the sideband field to the dark port is smaller, or (ii) one or more optical splitting fractions assumed above is wrong. If the former is true, we can still probably infer the contrast defect if we can somehow get an accurate measurement of the sideband transmission to the dark port.
> Can't we offload this DC signal to the laser crystal temperature servo?
No. PSL already follows the MC length. So this offset is coming from the difference between the MC length and the CARM length.
What you can do is to offload the MC length to the CARM DC if this helps.
MC2 damping restored, MZ locked and the arms are flashing now.
I turned on some filters and gain in the SUS-MC2_MCL filter bank tonight so as suppress the seismic noise influence on MC_F. This may help the MC stay in lock in the daytime.
Koji updated the mcdown and mcup scripts to turn the MCL path on and off and to engage the Boost filters at the right time.
The attached PNG shows the MCL screen with the filters all ON. In this state the crossover frequency is ~45 Hz. MC_F at low frequencies is reduced by more than 10x.
I also think that this may help the X-Arm lock. The number of fringes per second should be 2-3x less.
Earthquake mag 4.0 at Lennox, Ca trips MC2 watchdogs http://quake.usgs.gov/recenteqs/Quakes/ci10411545.html
See 40m accelerometers as they see it.
The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.
Round 3 for the day of MC2 watchdogs tripping.
The analog de-whitening filters for MC2 are different from those on the other optics (i.e. ITMs and ETMs). They have one complex pole pair @7Hz, Q~sqrt(2), one complex zero pair @50Hz, Q~sqrt(2), one real pole at 2.5kHz, and one real zero @250Hz (with a DC gain of 10dB).
I took the opportunity last night to measure all 4 de-whitening channel TFs. Measurements and overlaid LISO fits are seen in Attachment #1.
The motivation behind this investigation was that last week, I was unable to lock the IMC to one of the arms. In the past, this has been done simply by routing the control signal of the appropriate arm filter bank (e.g. C1:LSC-YARM_OUT) to MC2 instead of ETMY via the LSC output matrix (if the matrix element to ETMY is 1, the matrix element to MC2 is -1).
Looking at the coil output filter banks on the MC2 suspension MEDM screen (see Attachment #2), the positions of filters in the filter banks is different from that on the other optics. In general, the BIO outputs of the DAC are wired such that disengaging FM9 on the MEDM screen engages the analog de-whitening path. FM10 then has the inverse of the de-whitening filter, such that the overall TF from DAC to optic is unity. But on MC2, these filters occupy FM7 and FM8, and FM9 was originally a 28Hz Elliptic Low-pass filter.
So presumably, I was unable to lock the IMC to an arm because for either configuration of FM9 (ON or OFF), the signal to the optic was being aggressively low-passed. To test this hypothesis, I simply copied the 28Hz elliptic to FM6, put a gain of 1 on FM9, left it engaged (so that the analog path TF is just flat with gain x3), and tried locking the IMC to the arm again - I was successful. See Attachment #3 for comparison of the control signal spectra of the X-arm control signal, with the IMC locked to the Y-arm cavity.
In this test, I also confirmed that toggling FM9 in the coil output filter banks actually switches the analog path on the de-whitening boards.
Since I now have the measurements for individual channels, I am going to re-configure the filter arrangement on MC2 to mirror that on the other optics.
Unrelated to this work: the de-whitening boards used for MC1 and MC3 are D000316, as opposed to D000183 used for all other SOS optics. From the D000316 schematic, it looks like the signals from the AI board are routed to this board via the backplane. I will try squishing this backplane connector in the hope it helps with the glitching MC1 suspension.
GV Aug 13 11:45pm - I've made a DCC page for the MC2 dewhitening board. For now, it has the data from this measurement, but if/when we modify the filter shape, we can keep track of it on this page (for MC2 - for the other suspensions, there are other pages).
I briefly checked the MC2 analog dewhitening filters.
It turned out that the switching of the dewhitening filters from epics worked correctly except for the UR path.
I couldn't get a healthy transfer function for the UR path probably because the UR monitor at the front panel on either the AI filter or the dewhitening filter maybe broken.
Need a check again.
Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.
We need to re-look at this new MC autolocker stuff, and the new MCL filters.
MC2 is getting kicked up (sometimes the watchdog trips, sometimes it just comes close) pretty regularly. I'm not sure yet what is causing this, but we need to deal with it since it's pretty obnoxious.
Mirko and Den are measuring MC_F, which they will report about later, but I noticed that MC2 is totally crazy right now. It shouldn't matter that they are doing things (like unplugging the feedback to the PSL's PZT), because we actuate on the laser, not on the MC. I disabled the MC autolocker before they started working.
Anyhow, somehow MC2 got kicked up (whatever, that happens), but it won't re-damp. I think it's the WFS. The yaw output from the WFS is truely crazy.
I have disabled the WFS output / ASC input on the MC SUS screens, and MC2 was then able to damp. My disabling only the MC2 WFS input at first kicked up MC1 and 3, so I disabled all of the WFS stuff, and all 3 MC mirrors are again happy.
SURESH: FIX ME! (signed, The WFS)
Turning off the WFS servo loops usually should be done using the 'mcwfsoff' script. The script takes care of switching off the integrators and Clears the History.
'mcdown' and 'mcup' scripts run the 'mcwfsoff' and 'mcwfson' scripts so when the MC unlocks the WFS servos are shutdown and restarted properly. However if the MC autolocker script is suspended by pressing the Enable/Disable switch in the LOCKMC screen and then the MC unlocks, it results in the WFS servo integrators accumulating large values. If these values are passed through the ASC filter banks the optic will get a pretty huge kick.
I have added some indicators which will let us know if the WFS Servo Filter outputs are larger than +/-1000. When engaging the WFS loops the user has to take care to Clear History in the servo filter banks if these indicators are steadily Red. before engaging the WFS Servo loops ensure that the servo filter outputs are zeroes.
Koji and I discussed whether it would be useful to run the 'mcwfsoff' script when the Disable button is pressed in the autolocker. His recommendation is that we should keep the autolocker script simple and that user has to be cautious when switching on the WFS servos and when directing the ASC outputs to the suspensions.
MC2 is having a bad day, and I'm not yet sure why. It's to do with the damping though. When the damping is off, after a little while it will settle to ~30mV or so on the Watchdog screen. When I enable all of the outputs and then turn on the damping, the optic gets kicked up. It's like there's a minus sign error somewhere, maybe in a bad burtrestore? This has been going on since I did my morning bootfest.
It's started to sit down and play nicely now. Is someone doing magic remotely that is fixing things that I hadn't figured out yet?
The MCL path of MC2 was in a strange state as the filters were activated as if it is in lock even though we had no lock. So I manually ran "mcdown". This reset the filters of the MCL path.
I'm running the MC2 loss map scripts on pianosa now. The camera server is throwing an error and is not grabbing snapshots :(
Update: I finished taking the readings for MC2 loss map. I couldn't get the snapshots with the script, so I manually took some 4-5 pictures.
Can you please be more specific about what the error is? Is this the usual instability with the camera server code? Or was it something new?
The camera server is throwing an error and is not grabbing snapshots :(
The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) ezca.Ezca().write(CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.
I think ezca.Ezca().write() takes the string "CAM-ETMX_SNAP" as an argument and not C1:CAM-ETMX_SNAP. See this, line 47. Are you sure this is not the problem?
The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.
In my script I have used "CAM-ETMX_SNAP" only; while entering it in the elog I made a mistake, my bad!
I aligned MC2 suspension by 0.01 in pit and yaw to align the MC better to the PSL beam. Then I turned the WFS back on. The beams are not centered on the WFS heads.
Nic and Gabriele ought to send their SURF some example code (in April) for how to start redesigning the WFS telescopes so that we can order some optics in early June.
I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.