40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 205 of 349  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  13868   Fri May 18 20:03:14 2018 PoojaUpdateCamerasTelescopic lens solution for GigE

Aim: To find telescopic lens solution to image test mass onto the sensor of GigE camera.

I wrote a python code to find an appropriate combination of lenses to focus the optic onto the camera keeping in mind practical constraints like distance of GigE camera from the optic ~ 1m and distance between the lenses need to be in accordance with the Thorlab lens tubes available. We have to image both the enire optic of size 3" and beam spot of 1" using this combination of lens. The image size that efficiently utilizes the entire sensor array is 1/4". Therefore the magnification required for imaging the entire optic is 1/12 and that for the beam spot is 1/4.

I checked the website of Thorlabs to get the available focal lengths of 2" lenses (instead of 1" lenses to collect sufficient power). I have tried several combination of lenses and the ones I found close enough to what is required have been listed below along with thier colorbar plots.

a) 150mm-150mm (Attachment 2 & 3)

With this combination, object distance varies like 50cm for 1" beam spot to 105cm for 3" spot. Therefore, it posses a difficulty that there is a difference of ~48cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

b) 125mm-150mm (Attachment 4 & 5)

With this combination, object distance varies like 45cm for 1" beam spot to 95cm for 3" spot. There is a difference of ~43cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

c) 125mm-125mm (Attachment 6 & 7)

The object distance varies like 45cm for 1" beam spot to 90cm for 3" spot. There is a difference of ~39cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

Sensitivity check was also done for these combination of lenses. An error of 1cm in object distance and 5mm in the distance between the lenses gives an error in magnification <2%.

The schematic of the telescopic lens system has been given in Attachment 8.


Attachment 1: IMG_5650.jpeg
Attachment 2: plot_2018-05-18_tel-lens_150_150_1.pdf
Attachment 3: plot_2018-05-18_tel-lens_150_150_3.pdf
Attachment 4: plot_2018-05-18_tel-lens_125_150_1.pdf
Attachment 5: plot_2018-05-18_tel-lens_125_150_3.pdf
Attachment 6: plot_2018-05-18_tel-lens_125_125_1.pdf
Attachment 7: plot_2018-05-18_tel-lens_125_125_3.pdf
Attachment 8: tel_design.pdf
  227   Tue Jan 8 15:20:17 2008 PkpUpdateCamerasGigE update
[Tobin , Pinkesh]

Finally we got the camera doing something (other than giving out its attributes). The only thing that seems to work so far is a program called AAviewer, which converts the image into an ASCII format and displays it on the screen. If you want to play around with it, log into mafalda ( via rana.ligo.caltech.edu. Access /cvs/cds/caltech/target/Prosilica/bin-pc/x86/ and there should be a few programs in there, one of which is AAviewer, which requires you to get an IP address (which is for the camera right now. (You can also get the IP information via the ListCameras program). The camera is physically in the 40m near the network rack.

Other programs dont seem to be working and its probably due to the network/packetsize issues. Since linux2 can change its packetsize to a higher number, I will get it to compile on linux2 for now and then give it a shot.
  234   Thu Jan 10 13:45:52 2008 PkpUpdateCamerasGLIBC Error
So, I have tried to compile the camera files which are in /cvs/cds/caltech/target/Prosilica/examples for the past 2 days now and have been unable to get rid of the following error. (specifically ListCameras.cpp, as it doesnt have any other libraries required, which unnecessarily complicates things)

../../bin-pc/x86/libPvAPI.so: undefined reference to `__stack_chk_fail@GLIBC_2.4'
collect2: ld returned 1 exit status
make: *** [sample] Error 1

I used to get this error on mafalda too, but I had fixed it by installing the latest version of the glibc libraries. Inspite of doing so on linux2, the error still persists. I suspect it had something to do with it being a FC3 machine. My own laptop, which also runs Ubuntu works fine too. The problem with these Ubuntu machines is that they dont let me set the packet sizes to 9 kb which is required by the camera. Linux2 does.

If anyone has any idea how to resolve this issue, please let me know.

  9028   Mon Aug 19 10:16:15 2013 PicassoMetaphysicsTreasureoutsider art


  1950   Wed Aug 26 16:10:28 2009 Peter KingConfigurationPSLPSL reference cavity temperature box modifications

The 40m Lab reference cavity temperature box S/N BDL3002 was modified as per DCN D010238-00-C.

These were:

    R1, R2, R5, R6 was 10k now are 25.5k metal film

    R11, R14 was 10k now are 24.9k metal film

    R10, R15 was 10k now are 127k thick film - no metal film resistors available

    R22 was 2.00k now is 2.21k

    R27 was 10k now is 33.2k

    U5, the LM-336/2.5 was removed

    An LT1021-7, 7 V voltage reference was added.  Pin 2 to +15V, pin 4 to ground, pin 6 to U6 pin 3.

    Added an 8.87k metal film resistor between U6 pin 1 and U4 pin 6.

    Added an 8.87k metal film resistor between U6 pin 1 and U4 pin 15.

    The 10k resistor between J8 pin 1 and ground was already added in a previous modification.

In addition R3, R4, R7, R8, R12 and R13 were swapped out for metal film resistors of the same value


    The jumper connection to the VME setpoint was removed, as per Rana's verbal instructions.

This disables the ability to set the reference cavity vacuum chamber temperature by computer.




  5419   Thu Sep 15 17:00:10 2011 Paul and SteveUpdateSUSNew ITMY and SRM oplev plan

 We have made a new plan for the ITMY and SRM oplev optical path which uses as few optics as possible. This should help to reduce coupling from vibrations of optics in the oplev path back into the GW channel. To get enough room for the turning mirror into the SRM it might be necessary to move the POY optics a bit nearer to the tank. 

Attachment 1: oplev_plan1.png
  5418   Thu Sep 15 16:45:59 2011 PaulUpdateSUSITMY and SRM Oplev status

Today I worked on getting the ITMY and SRM oplevs back in working order. I aligned the SRM path back onto the QPD. I put excitations on the ITMY and SRM in pitch and yaw and observed the beam at the QPDs to check for clipping. They looked clean from clipping.

Measurements of the beam power at various points:
Straight after the laser - 7.54mW
After the BS in the SRM path - 1.59mW
After the BS in the ITMY path - 3.24mW
Incident on the SRM QPD - 0.03mW
Incident on the ITMY QPD - 0.25mW
Counts registered from the QPD sum channels:
SRM QPD SUM dark count - 1140
SRM QPD SUM bright count - 3250
ITMY QPD SUM dark count - 150
ITMY QDP SUM bright count - 12680
The power incident on the SRM QPD seems very low with respect to the ITMY QPD. Is the SRM mirror coating not very reflective for the He-Ne laser?There are some back reflections from lenses, which we should be careful of to avoid scattering.
  5422   Thu Sep 15 18:24:54 2011 PaulUpdateSUSITMY and SRM Oplev current status - comparison with ITMY

Just to find out where we are currently, I plotted the ITMY and SRM oplev spectra along with the ETMY oplev spectra. ETMY seems to be very good, so comparing with this seemed useful, so we know how much we have to improve by. The SRM power spectrum appears to be around 2 orders of magnitude higher than ETMY over pretty much the whole measurement band. The ITMY power spectrum is not so bad as the SRM above about 60Hz. Next thing to do is to check the dark noise level for the ITMY and SRM QPDs.

Attachment 1: oplev_spectra_comparison.pdf
  5423   Thu Sep 15 18:31:27 2011 PaulUpdateSUSITMY and SRM Oplev current status - comparison with ITMY


Just to find out where we are currently, I plotted the ITMY and SRM oplev spectra along with the ETMY oplev spectra. ETMY seems to be very good, so comparing with this seemed useful, so we know how much we have to improve by. The SRM power spectrum appears to be around 2 orders of magnitude higher than ETMY over pretty much the whole measurement band. The ITMY power spectrum is not so bad as the SRM above about 60Hz. Next thing to do is to check the dark noise level for the ITMY and SRM QPDs.

 The title of this post should of course have been " ... - comparison with ETMY" not " ... - comparison with ITMY"

  5427   Thu Sep 15 22:26:32 2011 PaulUpdateSUSITMY Oplev QPD dark noise PSD

 I took a dark noise measurement for the ITMY QPD, for comparison with measurements of the oplev noise later on. Initially I was plotting the data from test points after multiplication by the oplev matrix (i.e. the OLPIT_IN1 / OLYAW_IN1), but found that the dark noise level seemed higher than the bright noise level (!?). Kiwamu realised that this is because at that test point the data is already divided by QPD SUM, thus making the dark noise level appear to be greater than the bright level, since QPD SUM is much smaller for the dark measurements. The way around this was to record the direct signals from each quadrant before the division. I took a power spectrum of the dark noise from each quadrant, then added them in quadrature, then divided by QPD SUM at the end to get an uncalibrated PSD. Next I will convert these into the equivalent for pitch and yaw noise spectra. To calibrate the plots in radians per root Hz requires some specific knowledge of the oplev path, so I won't do this until I have adjusted the path.

Attachment 1: ITM_dark_QPD_PSD.pdf
  5429   Fri Sep 16 00:08:30 2011 PaulUpdateSUSITMY Oplev QPD dark and bright noise spectra

 I tried again at plotting the ITMY_QPD noise spectra in for dark and bright operation. Before we had the strange situation where the dark noise seemed higher, but Kiwamu noticed this was caused by dividing by the SUM before the testpoint I was looking at. This time I tried just multiplying by the measured SUM for bright and dark to normalise the spectra against each other. The results looks more reasonable now, the dark noise is lower than the bright noise for a start! However, the dark noise spectrum now doesn't look the same as the one I showed in my previous post.

Attachment 1: ITMY_oplev_dark_noise_vs_bright_noise.pdf
  5432   Fri Sep 16 14:03:53 2011 PaulUpdateSUSSRM oplev QPD noise measurement

 I checked the dark and bright noise of the SRM oplev QPD. The SRM QPD has a rather high dark level for SUM of 478 counts. The dark noise for the SRM QPD looked a little high in the plot against the bright noise (see first attachment), so I plotted the dark noise with the ITMY QPD dark noise (see second attachment). It seems that the SRM QPD has a much higher dark noise level than the ITMY! In case anyone is wondering, to make these traces I record the data from the pitch and yaw test points, then multiply by the SUM (to correct for the fact that the test point signal has already been divided by SUM). I will check the individual quadrants of the SRM QPD to see if one in particular is very noisy. If so, we/I should probably fix it.

Attachment 1: SRM_oplev_dark_noise_vs_bright_noise.pdf
Attachment 2: SRM_ITMY_QPD_dark_noise_comparison.pdf
  5436   Fri Sep 16 16:34:54 2011 PaulUpdateSUSITMY SRM oplev telescope plan

I've calculated a suitable collimating telescope for the ITMY/SRM oplev laser, based on the specs for the soon-to-arrive 2mW laser (model 1122/P) available here: http://www.jdsu.com/ProductLiterature/hnlh1100_ds_cl_ae.pdf

Based on the fact that the 'beam size' value and 'divergence angle' value quoted don't match up, I am assuming that the beam radius value of 315um is _not_ the waist size value, but rather the beam size at the output coupler. From the divergence angle I calculated a 155um waist, (zR = 12cm). This gives the quoted beam size of about 316um at a distance of 8.5" away from the waist. This makes me think that the output coupler is curved and the waist is at the back of the laser, or at least 8.5" from the output coupler.

The collimating telescope gives a waist of size 1142um (zR=6.47m) at a distance of 1.427m away from the original laser waist, using the following lens combo:


L1 f=-0.15 @ 0.301m

L2 f=0.3 @ 0.409m


This should be fine to get a small enough spot size (1-2mm) on the QPDs.


Attachment 1: ITMY_SRM_telescope.png
  5437   Fri Sep 16 17:09:07 2011 PaulUpdateSUSITMX oplev plan

 I just drew a basic picture of how the ITMX oplev path could be reworked to minimise the number of optics in the path. Only possible problem with this might be the turning mirror onto the ITMX getting in the way of the collimating lenses. Should be easy to solve though. Does anyone know if there is a ITMX pick off beam I should be careful to avoid?

Attachment 1: ITMX_oplev_plan.png
  5442   Fri Sep 16 22:11:21 2011 PaulUpdateSUSITMY transfer function

First of all I moved the lenses on the ITMY/SRM oplev path to get a smaller spot size on the QPDs. I couldn't get the beam analyzer to work though, so I don't know quite how successful this was. The software brought up the error "unable to connect to framegrabber" or something similar. I don't think the signal from the head was being read by the software. I will try to get the beam analyzer working soon so that we can characterize the other oplev lasers and get decent spot sizes on the QPDs. I searched the elog for posts about the analyzer, and found that it has been used recently, so maybe I'm just doing something wrong in using it. 

After this I measured the transfer function for the ITMY oplev yaw. I did a swept sine excitation of the ITMY in yaw with an amplitude of 500, and recorded the OSEM yaw values and the oplev yaw values. This should show a flat response, as both the QPD and the OSEMS should have flat frequency response in the measurement band. This measurement should therefore just yield a calibration from OSEM yaw to oplev yaw. If the OSEM yaw values were already calibrated for radians, we would then immediately have a calibration from oplev yaw values to radians. However, as far as I'm aware, there is not a calibration factor available from OSEM yaw values to radians. Anyway, the TF I measured did not appear to be very flat (see attached plot). Kiwamu suggested I should check the correlation between the OSEM measurements and the oplev QPD measurements - if the correlation is less than 1 the TF is not reliable. Indeed the coherence was poor for this measurement. This was probably because at frequencies above the pendulum frequency, the excitation amplitude of 500 was not enough to cause a measurable change in the optic angle. So, the plot attached is not very useful yet, but I learned something while making it.


Attachment 1: ITMY_osem_to_oplev_TF.pdf
  5443   Fri Sep 16 22:51:52 2011 PaulUpdateSUSCalibration plan for the oplevs

 In order to estimate the amount of noise that the oplevs are injecting into the GW channel, we first need to calibrate oplev signals in terms of angular change in the optic. I said in my previous post that there wasn't a calibration factor for OSEM values to radians, but I found that Kakeru had estimated this in 2009 - see entry 1413. However, Kakeru found that this was quite a rough estimate, and that it didn't agree with his calibrated oplev values well. He does quote the 2V/mm calibration factor for the OSEM readings though - does anyone know the provenance of this factor? I searched for OSEM calibration and found nothing.

Kiwamu and Suresh suggested a way to calibrate the oplevs without needing to calibrate the OSEMs in the way that Kakeru describes in entry 1413. This should give a calibration for the OSEMs _and_ the oplevs in fact. The method should be as follows:
1) Change the coil driver values in DC to give tip or tilt the optic. Measure the resulting change in spot position at a known distance from the optic, perhaps just using a ruler. Record the spot position and OSEM values for each coil driver value. This will definitely require a smaller spot size, so I'll implement the new telescopes first.
2) Knowing the length of the lever arm from the optic to the spot measurement position, we can calibrate the OSEM values to radians.
3) We can now put the beam onto the oplev QPD, and either change the coil driver values again in the same way (but over a smaller range), or excite the test mass in pitch or yaw, this time measuring both the OSEM values and the oplev QPD values. Since we can already convert from OSEM values to radians, we can now convert from oplev values to radians too.
4) I should be careful to consider the input sensing matrix for both the OSEMs and the oplevs in these measurements. Should I divide those out of the calibration to avoid that if they change the calibration factor changes too?
  5457   Mon Sep 19 12:23:30 2011 PaulUpdateSUSITMY and SRM oplev beam size reduced + next steps

I replaced the lenses that were there with a -150mm lens followed by a +250mm lens. This gave a significantly reduced beam size at the QPDs. With the beam analyzer up and running it should be possible to optimize this later this afternoon. Next I will remove the SRM QPD from the path and make measurements of the beam spot position movement and corresponding OSEM values for different DC mirror offsets. I will then repeat the process for ITMY.

  5458   Mon Sep 19 13:13:10 2011 PaulUpdateSUSITMY oplev available for use: SRM not for the moment

 I've got the bench set up for the measurement of the beam spot change with DC SRM alignment offsets. The ITMY oplev is aligned and fine to use, but the SRM one isn't until further notice (probably a couple of hours).

  5460   Mon Sep 19 15:30:22 2011 PaulUpdateSUSSRM oplev OSEM yaw calibration curve

 I made the first measurements towards oplev calibration measurements: calibrating the oplevs in SRM YAW. The measurements seemed fine, I had a range of between -1.5 and 1.5 in SRM DC alignment before clipping on mirrors on the oplev bench became a problem. This seemed to be plenty to get a decent fit for the spot position against DC alignment value - see attached plot. The fitted gradient was -420um oplev yaw count. I calculated oplev yaw values as UL+LL-UR-LR. Pitch next.

Attachment 1: SRM_YAW_calib_curve.png
  5465   Mon Sep 19 16:56:29 2011 PaulUpdateSUSSRM oplev pitch calibration

 Same measurements for SRM pitch (as previously done for yaw in entry 5460) are complete. The QPD is back in the path and aligned. I will be doing the same measurements for ITMY now though, so please ask before activating the SRM or ITMY oplev servos, as I may be blocking the beam.

  5468   Mon Sep 19 20:56:36 2011 PaulSummarySUSRemaining SRM and ITMY OSEMs calibrations


I've now taken data for the pitch and yaw calibrations for the OSEMs of SRM and ITMY. Until such time as I know what the calibrated oplev noise spectra are like, I'm leaving the servo gains at zero.

I estimate the length of the lever arm from SRM to measurement position to be 3.06m, and the length of the lever arm from the ITMY to the measurement position to be 3.13m.

From the fits shown on the attached plots, this gives the following calibration factors for the SRM and ITMY OSEMs pitch and yaw counts (i.e. counts from channels such as SUS-ITMY_ULSEN_SW2 multiplied by a matrix of 1s and -1s) to pitch and yaw angle:


SRM PITCH: 1 OSEMs pitch count = 11.74 microradians

SRM YAW: 1 OSEMs yaw count = 12.73 microradians


ITMY PITCH: 1 OSEMs pitch count = 13.18 microradians

ITMY YAW: 1 OSEMs yaw count = 13.52 microradians


Next step is to do some DC offsets with the oplev paths back in place to get the final calibration between OSEMs counts and oplev counts, thus finally getting a conversion factor from oplev counts to radians.

I noticed while taking these measurements that the DC offsets I put on ITMY caused around 5 times larger change in angle than those on the SRM. The different path length is not enough to account for this, so I propose that the actuation is working differently for the two. I guess this should be taken into account when designing the output matrices (unless the control is passed through a different output matrix than the DC offsets?). I'll quantify the difference shortly, and write a conversion factor between output alignment count (e.g. SUS-ITMY_PIT_COMM) and angle.



Attachment 1: SRM_PITCH_calib_curve.png
Attachment 2: SRM_YAW_calib_curve.png
Attachment 3: ITMY_PITCH_calib_curve.png
Attachment 4: ITMY_YAW_calib_curve.png
  5487   Tue Sep 20 18:03:45 2011 PaulUpdateSUSITMY and SRM oplev calibrations - measured and estimated

The measured calibration factors for the oplevs are as follows:

SRM pitch: 666urad per count on channel C1-SUS-SRM-OLPIT-INMON
SRM yaw: 557urad per count on channel C1-SUS-SRM-OLYAW-INMON
ITMY pitch: 470urad per count on channel C1-SUS-ITMY-OLPIT-INMON
ITMY yaw: 491urad per count on channel C1-SUS-ITMY-OLYAW-INMON
Since I'm going to calibrate all the other oplevs with the rougher technique of estimating the angle from the OSEM signals directly, I thought I would check the result of such an estimation for the oplevs I have calibrated already. My method was as follows:
dA = change in angle
dx = change in OSEM flag position
dV = change in OSEM PD voltage
dC = change in OSEM counts
D = optic diameter
L = distance between OSEMs = D/sqrt(2)-0.002m = 0.052m
dV/dx = OSEMs volts per meter flag position change = 1700 V/m
dC/dV = OSEM counts per volt = 2^16/40 = 65536/40 counts/V
counts per radian = dC/dA = dV/dx  x   dC/dV   x  1/L = 1700*65536/40/0.052 = 5.3564x10^7 counts/rad
radians per count = dA/dC = 1.867x10^-8, or 0.019 urad/count
This is around a factor of 1000 smaller than what I measured earlier, reported in entry 5468. I guess this might be an issue with the whitening filter on the OSEMs, but my initial feeling was that this was only a factor of a few. If anyone can see a big obvious mistake in my above calculations please let me know!
  5488   Tue Sep 20 19:00:49 2011 PaulUpdateSUSITMY and SRM oplev calibrations - measured and estimated


Kiwamu noticed that the 1/L in the counts per radian should have just been L, which accounts for most of the discrepancy. We checked the input filters on the OSEMs, and they have 10dB of gain at DC. Accounting for this, estimates on the order of 20urad/count, which is much more reasonable!

  5496   Wed Sep 21 09:10:15 2011 PaulUpdateSUSITMY and SRM oplev calibrations - measured and estimated


I found that some of the Optical Lever Servos were ON today and injecting nonsense into the interferometer optics. I have set all of the gains = 0 to save us more headaches.

Please leave them OFF until we review the servo and noise characterization results in the elog.

 I had previously set the gains to zero, see the first line of my entry on Monday 5468. I should have the servo and noise characterisation done today for these oplevs today, so we can review it soon.

  5499   Wed Sep 21 14:44:25 2011 PaulUpdateSUSITMY and SRM open loop transfer functions


 Here are the open loop transfer functions for ITMY and SRM. The various settings for the OLTFs were as follows:

Oplev filter used for all OLTFs: 300^2:0

Gains for oplev servos (for each OLTF only the 1 servo for the measured TF was on. They are all set back to 0 now):

SRM yaw gain = 1

SRM pitch gain = -1

ITMY yaw gain = -1

ITMY pitch gain = 1

measurement band = 0.2Hz to 200Hz

points = 33

swept sine magnitude envelope: amp = 2 for f > 60Hz, amp = 0.1 for f < 60Hz

Measurement points were from e.g. C1-SUS-ITMY-OLPIT-IN2 to C1-SUS-ITMY-OLPIT-IN1 to give a TF of -(loop gain).

Next step is to divide this through by the sensor reponse (i.e. the calibration factor measured earlier) and the filter response to get just the actuator response. 


Attachment 1: ITMY_SRM_oplev_OLTFs.png
  5501   Wed Sep 21 16:31:28 2011 PaulUpdateSUSITMY and SRM actuator response functions

 I divided the open loop transfer functions by the filter response and the sensor responses (previously measured calibration factors) to leave just the actuator responses. I've attached the actuator responses plotted in radians/count and phase over frequency.

Next step: fit the actuator response with poles and zeros.

EDIT: I divided by the wrong filter function earlier - the plots there now are divided by the correct filter function

Attachment 1: ITMY_PITCH_actuator_response.png
Attachment 2: ITMY_YAW_actuator_response.png
Attachment 3: SRM_PITCH_actuator_response.png
Attachment 4: SRM_YAW_actuator_response.png
  5507   Wed Sep 21 23:05:16 2011 PaulUpdateSUSITMY and SRM actuator response functions - fitting results

 I used an fminsearch function to fit the SRM and ITMY actuator response magnitudes. The testfunction was just that for a single second order pole, but it gave what I consider to be good fits for the following reasons:

*for 3 of the 4 fits the residuals were less than 0.5% of the summed input data points. The worst one (ITMY pitch) was about 2.7%, which I think is due to the resonance happening to be right in the middle of two data points.

*the tolerance of 1 part in 10^9 was reached quickly from not very finely tuned starting points.

The test function was: G=abs(Gp./(1+1i.*f./fp./Qp-(f./fp).^2)), where G(f) is the actuator response magnitude, Gp is the pole gain, fp is the pole frequency, and Qp is the pole Q factor.

In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?

Anyway, here are the results of the fits, and I've attached plots of each too (each one in linear and log y axis because each on its own might be misleading for fits):

EDIT - I added more points to the otherwise sparse looking fitted curves


ITMY PITCH actuator response fit

-- Fit completed after 190 iterations--

 Started with: Gain = 3e-06,

 Q factor = 5,

 Pole frequency = 1,

 Fit results:  Gain = 1.32047e-06,

 Q factor = 4.34542,

 Pole frequency = 0.676676

 Residual (normalised against the sum of input datapoints) = 0.0268321


ITMY YAW actuator response fit

-- Fit completed after 156 iterations--

 Started with: Gain = 3e-06,

 Q factor = 5,

 Pole frequency = 1,

 Fit results:  Gain = 1.14456e-06,

 Q factor = 8.49875,

 Pole frequency = 0.730028

 Residual (normalised against the sum of input datapoints) = 0.00468077


SRM PITCH actuator response fit

 -- Fit completed after 192 iterations--

 Started with: Gain = 3e-06,

 Q factor = 5,

 Pole frequency = 1,

 Fit results:  Gain = 7.94675e-06,

 Q factor = 7.16458,

 Pole frequency = 0.57313

 Residual (normalised against the sum of input datapoints) = 0.00301265


SRM YAW actuator response fit

 -- Fit completed after 156 iterations--

 Started with: Gain = 3e-06,

 Q factor = 5,

 Pole frequency = 1,

 Fit results:  Gain = 3.34179e-06,

 Q factor = 9.57601,

 Pole frequency = 0.855322

 Residual (normalised against the sum of input datapoints) = 0.000840468

Attachment 1: ITMY_PITCH_actuator_response_FIT.png
Attachment 2: ITMY_YAW_actuator_response_FIT.png
Attachment 3: SRM_PITCH_actuator_response_FIT.png
Attachment 4: SRM_YAW_actuator_response_FIT.png
  5509   Wed Sep 21 23:44:45 2011 PaulUpdateSUSRe:ITMY and SRM actuator response functions - fitting results


Did you take the 180 deg shift into your account ?

Since your measurement was done when the loop was closed, there must be an additional 180 deg phase shift (in other words, minus sign).

Quote from #5507

In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?

 I thought I had, but apparently not, and I'd made another error or two in the complex version of my fitting routine. I've fixed them now, thanks! I'll put up the new fitting results tomorrow morning.

  5510   Thu Sep 22 00:00:10 2011 PaulUpdateSUSITMY and SRM actuator response functions - complex fitting results

Here are the results of the complex fitting. The residuals are bigger this time, but still probably small enough to be ok(?), with the possible exception of ITMY PITCH (due again I think to the data points straddling the resonance).

ITMY YAW actuator response complex fit

-- Fit completed after 282 iterations--

 Started with: Gain = 3e-05,
 Q factor = 5,
 Pole frequency = 0.6776,
 Fit results:  Gain = 1.14673e-06,
 Q factor = 12.9471,
 Pole frequency = 0.766531
 Residual (normalised against the sum of input datapoints) = 0.0688174
ITMY PITCH actuator response complex fit
-- Fit completed after 191 iterations--
 Started with: Gain = 3e-05,
 Q factor = 5,
 Pole frequency = 0.6776,
 Fit results:  Gain = 1.25105e-06,
 Q factor = 3.88981,
 Pole frequency = 0.706744
 Residual (normalised against the sum of input datapoints) = 0.144165
SRM YAW actuator response complex fit
-- Fit completed after 246 iterations--
 Started with: Gain = 3e-05,
 Q factor = 5,
 Pole frequency = 0.6776,
 Fit results:  Gain = 3.34137e-06,
 Q factor = 9.6875,
 Pole frequency = 0.854913
 Residual (normalised against the sum of input datapoints) = 0.0153646
SRM PITCH actuator response complex fit
-- Fit completed after 266 iterations--
 Started with: Gain = 3e-05,
 Q factor = 5,
 Pole frequency = 0.6776,
 Fit results:  Gain = 7.97529e-06,
 Q factor = 7.63888,
 Pole frequency = 0.568227
 Residual (normalised against the sum of input datapoints) = 0.0319653
Attachment 1: ITMY_PITCH_actuator_response_complex_FIT.png
Attachment 2: ITMY_YAW_actuator_response_complex_FIT.png
Attachment 3: SRM_PITCH_actuator_response_complex_FIT.png
Attachment 4: SRM_YAW_actuator_response_complex_FIT.png
  5514   Thu Sep 22 10:43:50 2011 PaulUpdateSUSPower spectrum with different filter gains

 I thought it might be informative before trying to optimise the filter design to see how the current one performs with different gain settings. I've plotted the power spectra for ITMY yaw with filter gains of 0, 1, 2, 3 and 4.

All of the higher gains seem to perform better than the 0 gain, so can I deduce from this that so far the oplev control loop isn't adding excess noise at these frequencies?

Attachment 1: ITMY_YAW_closed_vs_open_noise.pdf
  5517   Thu Sep 22 13:45:17 2011 PaulUpdateSUSETMX actuator response fits

Fitting results: 


-- Fit completed after 305 iterations--
 Started with: Gain = 3e-05,
 Q factor = 5,
 Pole frequency = 0.6776,
 Fit results:  Gain = 1.85497e-06,
 Q factor = 23.7233,
 Pole frequency = 0.956686
 Residual (normalised against the sum of input datapoints) = 0.0202483
-- Fit completed after 334 iterations--
 Started with: Gain = 3e-05,
 Q factor = 5,
 Pole frequency = 0.6776,
 Fit results:  Gain = 2.518e-06,
 Q factor = 7.21618,
 Pole frequency = 0.853559
 Residual (normalised against the sum of input datapoints) = 0.0570132
Attachment 1: ETMX_PITCH_actuator_response_complex_fit.png
Attachment 2: ETMX_YAW_actuator_response_complex_fit.png
  5532   Fri Sep 23 17:57:34 2011 PaulUpdateSUSOplev filter optimization for 2 poles and 2 zeros

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I have a attached a plot showing the power spectrum and RMS curves for the optimization result for 2 zeros and 2 poles, optimized to give a minimal RMS below 20Hz.

I have also attached a plot showing the loop gain and the filter transfer function.

The noise spectrum shows that the optimised filter gives a better noise performance below 10Hz, but a servo oscillation at the UGF of 10 Hz means it injects a lot of motion around this frequency. Should I consider some more aggressive way to force the script to keep a decent phase margin?

The fminsearch results show that the 'optimized' solution is two resonant peaks:


 -- Optimisation completed after 571 iterations--

 Started with: 

 Pole 1 frequency = 1 Hz 

 Pole 2 frequency = 2 Hz 

 Zero 1 frequency = 0.1 Hz 

 Zero 2 frequency = 5 Hz 

Overall gain = 1 

 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz 

Overall gain = 71970.1 

 Initial RMS below 10 Hz = 5.90134e-06

 Remaining RMS below 10 Hz = 8.42898e-07




Attachment 1: optimised2p2z_v1.png
Attachment 2: optimised2p2z_v1_TFs.png
  5540   Sat Sep 24 17:45:56 2011 PaulUpdateSUSRe:Oplev filter optimization for 2 poles and 2 zeros


 (B) The resultant poles and zeros seem canceling each other but the filter still has a structure. Is something wrong ?

Quote from #5332

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz

 Ah yes, well noticed. I think I have tracked this down to just a bug in printing of fitting results: It was just printing the pole results for the zeros too. The results for the same fit now read:


 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0972455 Hz 

 Zero 2 frequency = 6.50126 Hz 

Overall gain = 71970.1

EDIT: sorry, I forgot that when you write a reply, the author is still by default the person you are replying to unless you change it!


  5554   Tue Sep 27 08:51:29 2011 PaulUpdateSUSOplev filter optimization for 2 poles and 2 zeros



I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.

Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:

1) Limit the gain peaking at the upper UGF to 6 dB.

2) Minimum phase margin of 45 deg.

3) Minimum gain margin of 10 dB.

4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.

5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.

6) Looser noise contraint above 50 Hz for the non TM loops.

 I moved two matlab scripts into the folder /cvs/cds/rtcds/caltech/c1/scripts/SUS/Oplev_filter_optimization

These are the function 'filter_optimiser_zeros_and_poles.m', and the example script to run the function 'run_filter_optimiser.m'. Type 'help filter_optimiser_zeros_and_poles.m' to get details about the function.

I haven't implemented the new weights yet. I've pasted them into the the file header to remind me/us of the work to be done on the function.

  15857   Wed Mar 3 12:00:58 2021 Paco, AnchalHowToIMCMC_F ASD

[Paco, Anchal]

- Saved BURT backup in /users/anchal/BURTsnaps/
- Copied existing code for mode cleaner noise budget from /users/rana/mat/mc. Will work on this from home to convert it inot new pynb way.

Get baseline IMC measurements (passive):
- MC_F:
  - What is MC_F? Let's find out.
  - On MC_F Cal window titled 'C1IOO-MC_FREQ', we turned off ON/OFF and back on again.
  - Using diaggui, we measured ASD of MC_F channel in units of counts/rtHz.

[Rana, Paco]

- Using diaggui, measured ASD from a template (under /users/Templates) and overlay the 1/f noise of the NPRO (Attachment 1)

[Anchal, Paco]

- WFS Master
  - Went through the schematic and tried to understand what is happening.
  - Accidentally switched on MC WF relief (python 3). Bunch of things were displayed on a terminal for a while and then we Ctrl-C it.
  - The only thing we noticed that change is a slight increase in WFS1 Yaw, and a corresponding decrease in WFS1 Pitch, WFS2 Pitch, and WFS2 Yaw.
  - We need to find out what this script does.

Future work:

  • Create an automated script for taking MC_F_DQ spectrum and refer it against reference trace.
  • Use pynb to create a noise budget for mode cleaner.
  • Identify excess noise between 10-40 Hz.
  • Configure output matrix in WFS Master to reduce the noise. Automate this process as well.
Attachment 1: 20210303_MC_F_Spectrum.pdf
Attachment 2: 20210303_MC_F_Spectrum.tar.gz
  15861   Thu Mar 4 10:54:12 2021 Paco, AnchalSummaryLSCPOY11 measurement, tried to lock Green Yend laser

[Paco, Anchal]

- First ran burtgooey as last time.

- Installed pyepics on base environment of donatella

- Clicked on ON in the drop down of "! More Scripts" below "! Scripts XARM" in C1ASS.adl
- Clicked on "Freeze Outputs" in the same menu after some time.
- Noticed that the sensing and output matrix of ASS on XARM and YARM look very different. The reason probably is because the YARM outputs have 4 TT1/2 P/Y dof instead of BS P/Y on the XARM. What are these TT1/2?

(Probably, unrelated but MC Unlocked and kept on trying to lock for about 10 minutes attaining the lock eventually.)

Locking XARM:
- From scripts/XARM we ran lockXarm.py from outside any conda environment using python command.
- Weirdly, we see that YARM is locked??? But XARM is not. Maybe this script is old.
- C1:LSC-TRY-OUTPUT went to around 0.75 (units unknown) while C1:LSC-TRX-OUTPUT is fluctuating around 0 only.

POY11 Spectrum measurement when YARM is locked:
- Created our own template as we couldn't find an existing one in users/Templates.
- Template file and data in Attachment 2.
- It is interesting to see most of the noise is in I quadrature with most noise in 10 to 100 Hz.
- Given the ARM is supposed to be much calmer than MC, this noise should be mostly due to the mode cleaner noise.
- We are not sure what units C1:LSC-POY11_I_ERR_DQ have, so Y scale is shown with out units.

Trying to lock Green YEND laser to YARM:
- We opened the Green Y shutter.
- We ensured that when temperature slider og green Y is moved up, the beatnote goes up.
- ARM was POY locked from previous step.
- Ran script scripts/YARM/Lock_ALS_YARM.py from outside any conda environment using python command.
- This locked green laser but unlocked the YARM POY.

Things moving around:
- Last step must have made all the suspension controls unstable.
- We see PRM and SRM QPDs moving a lot.
- Then we did burt restore to /opt/rtcds/caltech/c1/burt/autoburt/today/08:19/*.snap to go back to the state before we started changing things today.

[Paco left for vaccine appointment]

- However the unstable state didn't change from restore. I see a lot of movement in ITMX/Y. PRM and BS also now. Movement in WFS1 and MC2T as well.
 - I closed PSL shutter as well to hopefully disengage any loops that are still running unstably.
 - But at this point, it seems that the optics are just oscillating and need time to come back to rest. Hopefully we din't cause too much harm today :(.

My guess on what happened:

  • Us using the Lock_ALS_YARM.py probably created an unstable configuration in LSC matrix and was the start of the issue.
  • On seeing PRM fluctuate so much, we thought we should just burst restore everything. But that was a hammer to the problem.
  • This hammer probably changed the suspension position values suddenly causing an impulse to all the optics. So everything started oscillating.
  • Now MC WFS is waiting for MC to lock before it stablizes the mode cleaner. But MC autolocker is unable to lock because the optics are oscillating. Chicken-egg issue.
  • I'm not aware of how manually one can restore the state now. My only known guess is that if we wait for few hours, everything should calm back enough that MC can be locked and WFS servo can be switched on.
Attachment 1: 20210304_POY11_Spectrum_YARMLocked.pdf
Attachment 2: 20210304_POY11_Spectrum_YARMLocked.tar.gz
  15862   Thu Mar 4 11:59:25 2021 Paco, AnchalSummaryLSCWatchdog tripped, Optics damped back

Gautam came in and noted that the optics damping watchdogs had been tripped by a >5 magnitude earthquake somewhere off the coast of Australia. So, under guided assistance, we manually damped the optics using following:

  • Using the scripts/SUS/reEnableWatchdogs.py script we re-enabled all the watchdogs.
  • Everything except SRM was restored to stable state.
  • Then we clicked on SRM in SUS-> Watchdogs, disabled the Oplevs, shutdown the watchdog.
  • We changed the threshold for watchdog temporarily to 1000 to allow damping.
  • We enabled all the coil outputs  manually. Then enabled watchdog by clicking on Normal.
  • Once the SRM was damped, we shutdown the watchdog, brought back the threshold to 215 and restarted it.

Gautum also noticed that MC autolocker got turned OFF by me (Anchal), we turned it back on and MC engaged the lock again. All good, no harm done.

  15877   Mon Mar 8 12:01:02 2021 Paco, AnchalSummarytrainingInvestigate how-to XARM locking

[Paco, Anchal]

- Started zoom stream; thanks to whoever installed it!
- Spent some time trying to understand how anything we did last thursday lead to the sensing matrix change, but still cannot figure it out. 
- Tracking back on our actions, at ~10:30 we ran burt Restore with the 08:19/.*snap and in lack of a better suspect, we blame it on that action for now.

# ARM locking??
- Reading (not running) the scripts/XARM/lockXarm.py script and try to understand the workflow. It is pretty confusing that the result was to lock Yarm last time.
- It looks like this script was a copy of lockYarm.py, and was never updated (there's a chance we ran it for the first time last thursday)
- *Is there a script to lock the Arms?* Or should we write one? To write one, we first attempt a manual procedure;
    1. No need to change RFPD InMTRX
    2. All filters inputs / outputs are enabled 
    3. Outputs from XARM and YARM in the Output matrix are already going to ETMX and ETMY
      - Maybe we can have the ARM lock engage by changing the MC directly?
    4. Change C1:SUS-MC2_POS_OFFSET from -38 to -0, and enable C1:SUS-MC2_POS_OFFSET_ON
    5. Manually scan MC2_POS_OFFSET to 250 (nothing happens), then -250, then back to -38 (WFS1 PIT and YAW changed a little, but then returned to their nominal values)
      - Or maybe we need to provide the right gain...
    6. Disabled C1:SUS-MC2_POS_OFFSET_ON (back to nominal state)
    7. Look into manually changing C1:LSC-XARM_GAIN;
      From the command line using python:
      >> import epics
      >> ch_name = 'C1:LSC-XARM_GAIN'
      >> epics.caput(ch_name, 0.155) # nominal = 0.150
      - Could be unrelated, but we noted a slow spike on C1:PSL-FSS_PCDRIVE (definitely from before we changed anything)
      - Still nothing is happening
    8. Changed the gain to 0.175, then back to 0.150, no effect... then 0.2, 0.3 ...
      - Stop and check SUS_Watchdogs (should not have changed?) and everything remains nominal
      - Revert all changes symmetrically.
      - Could we have missed enabling FM1?
      - Briefly lost MC lock, but it came back on its own (probably unrelated)

- Wrap it up for the day. In summary; no harm done to our knowledge.

  15884   Tue Mar 9 10:57:06 2021 Paco, AnchalSummaryIMCXARM lock and POX spectra

[Paco, Anchal]

- Upon arrival, MC is locked, and we can see light in MON5 (PRM) (usually dark).

# XARM locking
- Read through "XARM POX" script (path='/cvs/cds/rtcds/caltech/c1/burt/c1configure/c1configureXarm')
- Before running the script, we noticed the PRM watchdog is down, so we manually repeat the procedure from last time, but see more swinging even though the watchdog is active.
- Run a reEnablePRMWatchdogs.py script (a copy of reEnableWatchdogs.py with optics=['PRM']), which had the same effect. 
- We manually disable the watchdog to recover the state we first encountered, and wait for the beam in MON5 to come to rest.
    - The question is; is it fine to lock Xarm with PRM watchdog down?
    - To investigate this, we look at the effect of the offset on the unwatchdog-PRM.
    - Manually change 'PRM_POS_OFFSET' to 200, and -800 (which is the value used in the script) with no effect on the PRM swinging.
- Moving on, run IFO > CONFIGURE > ! (X Arm) > RESTORE XARM (XARM POX), and ... success.

# MC-POX noise spectra
- With XARM locked, open diaggui and take spectra for C1:LSC-POX11_I_ERR_DQ, C1:LSC-POX11_Q_ERR_DQ, C1:IOO-MC_F_DQ
- Lost XARM lock while we were figuring out unit conversions...
    - Assuming 2.631e-13 m/counts (6941) and using 37.79 m (arm length), 1064.1 nm wavelength, we get a calibration factor of 2.631e-13 * c / (2*L*lambda) ~ 0.9809 Hz/count 
    - (FAQ?, how to find/compute/measure the correct calibration factors?)
- Relock XARM, retake spectra. Attachment 1 has plots for POX11_I/Q_ERR_DQ spectrum (cts/rtHz, we couldn't find relevant calibration) and MC_F_DQ in (Hz/rtHz from referring to 15576, we couldn't get the units to show on y scale.)

# MC-POY noise spectra (attempt)
- Now, run IFO > CONFIGURE > ! (Y Arm) > RESTORE YARM (YARM POY), and XARM locks (why?)
    - Could PRM watchdog being down be the cause? 
- Try C1ASS > (YARM) ! More Scripts > ON, and looked at YARM PIT/YAW striptool. 
- C1ASS > (YARM) ! Freeze Outputs, then OFF
- Go back to IFO > CONFIGURE > ! (Y Arm) > Align YARM  (ASS ON: Unfreeze), try running this then Freeze, then OFF Zero Outputs.
- Try RESTORE YARM (POY) again, still not working.
- Try RESTORE YARM ALS, then try again after opening the shutter, but also fail to lock AUX.
    - Is the PRM WD behind some evil misalignment? Will move forward with XARM bc it is happy.

# ARM locking
- Attempted the IFO > CONFIGURE > ! (X Arm) > RESTORE Xarm (XARM ALS) but green failed to lock and we lost XARM lock.
- Try to recover XARM lock... success. It's nice to have a (repeatable) checkpoint.
- Attempt YARM lock. Not successful. It just seems like the lock Triggers are not raised (misalignment?)
    - From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_YAW_OFFSET" manually to reduce the OPLEV_YERROR. Changed from -47 to -57.
    - Retry YARM lock script... no luck
    - From C1SUS_PRM, try changing the bias "C1:SUS-PRM_PIT_OFFSET" manually to reduce OPLEV errors. Changed from 34 to 22 with no effect, then realized the coil outputs are disabled because the WD is down...
    - So we do the following BIAS changes "C1:SUS-PRM_PIT_OFFSET" = 34 > 770 and "C1:SUS-PRM_YAW_OFFSET" = 134 > -6
    - Enable all Coil Outputs, turn WD to Normal, turn OPLEVs ON, (this time the beam does not swing like crazy).
    - Fine tune BIASes "C1:SUS-PRM_PIT_OFFSET" = 770 > 805  and "C1:SUS-PRM_YAW_OFFSET" = -6 > 65
        - Saw YARM locking briefly, then unlocking, but we stopped once the OPLEV_ERRs no longer overloaded (from magnitudes > 50 to ~ 40).
- Retry YARM lock... no luck
    - From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_PIT_OFFSET" from -1 to 6. 

Stop for the day. Leave XARM locked, MC locked. 

Attachment 1: 20210309_POX11_Spec_XARMLocked.pdf
Attachment 2: 20210309_XARM_Locked.tar.gz
  15893   Wed Mar 10 11:46:22 2021 Paco, AnchalSummaryIMCIMC free swinging prep

[Paco, Anchal]

# Initial State
- MC is locked. The PRM monitor shows some oscillations.
- POP monitor shows light flashing once in a while.
- AS monitor shows one beam along with some other flashing beam around it.
- PRM Watchdog is tripped and shutdown. Everything else is normal except for overload on SRM OpLevs.
- Donatella got a mouse promotion

# Reenabling PRM watchdog:
- The custom reEnablePRMWatchdog.py has been deleted.
- Tried enabling the coil outputs manually and switching watchdog to Normal.
- Again saw large fluctuations like yesterday.
- Probably still the same issue of how current calculated actuations to the coils is in range -600 to -900 and gives and impulse to the optics when suddenly turned on.
- Waiting for PRM to damp down a little.
- Today we plan to change the position bias on PRM C1:SUS-PRM_POS_OFFSET instead of changing biases in pitch and yaw.
- Changing C1:SUS-PRM_POS_OFFSET from 0 to +/- 100 without enabling the coils, it seems upper and lower coils are anticorrelated with just changing the position. So going back to changing pitch.
- Changing C1:SUS-PRM_PIT_OFFSET from 0 -> 780. Switched on watchdog to normal.
- PRM damped down. OpLev errors are also within range.
- Enabled both OpLevs.

# Try locking Y-Arm
- IFO>CONFIGURE>YARM>Restore YARM (POY) using Donatella. See a bunch of python error messages in the call complaining about unable to find some python 2 files. Closed it with Ctrl-C after a stuck state.
- Tried running it on Pianosa, the script ran without error but Y-Arm didn't lock.

# Try locking X-Arm
- IFO>CONFIGURE>XARM>Restore XARM (POX) on Donatella. Again a bunch of OSError messages. Donatella is not configured properly to run scripts.
- Tried running it on Piasnosa, the script ran without error but X-Arm didn't lock.
- This might mean that both arms are misaligned or the BS/PRM is misaligned.
- Moving around C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET in order to see if the transmitted light is misalgined. Both arms are set to acquire lock if possible. No luck.

# Hypothesis: The Arm cavity is not aligned within itself (ITM-ETM)
- Will try to lock X-Arm with green light while tuning the ETMX. Hopefully the BS and ITM are aligned so that once we align ETMX to get a green lock, the IR will also lock from the other side.
- Running IFO>CONFIGURE>XARM>Restore XARM (ALS) on Pianosa. No lock, moving forward with tunning ETMX pitch and yaw offsets. Nothing changed. Brought back to same values.

[Rana joined, Anchal moved to Rossa from Pianosa]

# Moving on to IMC suspensions characterization:
- Closed the PSL shutter, to our suprise, the MC was still locked. We thought this would take away any light from IMC but it doesn't. Maybe the IFO Overview needs to show the schematic in a way where this doesn't happen: "No light from any laser entering the MC but it still is locked with a resonating field inside."
- Shutting IMCR shutter (hoping that would unlock the IMC), still nothing happend.
- Tried shutting PSL shutter from Rossa, nothing happened to MC lock still.
- Closed shutter IOO>Lock MC> Close PSL and this unlocked the IMC. Found out that this shutter channel is C1:PSL-PSL_ShutterRqst while the one from the sitemap>Shutter>PSL changes C1:AUX-PSL_ShutterRqst. Some clarification on these medm screens would be nice.
- Disabled the MC autolocked from IOO>Lock MC screen (C1:IOO-MC_LOCK_ENABLE).
- Checked the scripts/SUS/freeswing.py to understand how kick is delivered and optic is left to swing freely.
- Next, we are looking at the C1SUS_MC1 screen to understand what channels to read during data acquisition.
- In sensor matrix, we see INMON for each sensor which is probably raw counts data from the OSEMs. Rana mentioned that OSEM data comes out in units of microns. These are C1:SUS-MC1_ULSEN_OUTPUT (and so on for UR, LL, LR, SD).

- In prep for finishing, recovered Autolocker by first opening the PSL mechanical shutter, then re-enabling the Autolocker. The IMC lock didn't immediately recover, and we saw some fuzz on the PSL-FSS_FAST trace, so we closed the shutter again, waited a minute, then re-opened it and MC caught its lock.

  15897   Wed Mar 10 15:35:25 2021 Paco, AnchalSummaryIMCIMC free swinging experiment set to trigger at 5:00 am

A tmux session named "MCFreeSwingTest" will run on Rossa. This session is running script scripts/SUS/freeSwingMC.py (also attached) which will trigger at 5:00 am to impart 30000 counts kick to MC1, MC2, and MC3 after shutting PSL shutter and disabling the MC autolocker. It will let them freely swing for 1050 sec and will repeat 15 times to allow some averaging. In the end, it will undo all the changes it does and switches on autolocker on IMC. The script is set to restore any changes in case it fails at any point or a Ctrl-C is detected.

Attachment 1: freeSwingMC.py.zip
  15902   Thu Mar 11 08:13:24 2021 Paco, AnchalUpdateSUSIMC First Free Swing Test failed due to typo, restarting now

[Paco, Anchal]

The triggered code went on at 5:00 am today but a last minute change I made yesterday to increase number of repititions had an error and caused the script to exit putting everything back to normal. So as we came in the morning, we found the mode cleaner locked continuously after one free swing attempt at 5:00 am. I've fixed the script and ran it for 2 hours starting at 8;10 am. Our plan is to get some data atleast to play with when we are here. If the duration is not long enough, we'll try to run this again tomorrow morning. The new script is running on same tmux session 'MCFreeSwingTest' on Rossa

10:13 the script finished and IMC recovered lock.

Thu Mar 11 10:58:27 2021

The test ran succefully with the mode cleaner optics coming back to normal in the end of it. We wrote some scripts to read data and analyze it. More will come in future posts. No other changes were made today to the systems.

  15912   Fri Mar 12 11:44:53 2021 Paco, AnchalUpdatetrainingIMC SUS diagonalization in progress

[Paco, Anchal]

- Today we spent the morning shift debugging SUS input matrix diagonalization. MC stayed locked for most of the 4 hours we were here, and we didn't really touch any controls.

  15919   Mon Mar 15 08:55:45 2021 Paco, AnchalSummarytraining 

[Paco, Anchal]

  • Found IMC locked upon arrival.
  • Since "allegra" was set up as an additional workstation, we tried using it but discovered the monitor ist kaput. For the sake of debugging, we tested VGA and DVI inputs and even the monitor lying around (also labeled "allegra") with no luck. So <ssh> it is for now.

IMC Input sensing matrix

  • Rana joined us and asked us to use Rossa for now so that we can sit socially distantly.
  • Attaching some intermediate results on our analysis as pdf and zip file containing all the codes we used.
  • We used channels C1:SUS-MC1_USSEN_OUTPUT  (16 Hz channels) and so on which might not be the correct way to do it as Rana pointed out today, we should have used channels like C1:SUS-MC1_SENSOR_UL etc.
  • During the input matrix calculation, we used the method of TF estimate (as mentioned in 4886) to calculate the sensor matrix and inverted it and normalized all rows with the maximum absolute value element (we tried few other ways of normalization with no better results either).
  • We found the peak frequencies by fitting lorentzian to the sensor data rotated by the current input matrix in the system. We also tried doing this directly on the sensor data (UL for POS, UR for PIT, LR for YAW and SD for SIDE as this seemed to be the case in the old matlab codes) but with no different results.
  • The fitted peak frequencies, Q and amplitude values are in fittedPeakFreqs.yml in the attached zip.
Attachment 1: IMC_InputMatrixDiagonalization.pdf
IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf
Attachment 2: inputMatrixCalculationMC.tar
Attachment 3: freeSwingMC.py.tar
Attachment 4: SUSfreeswing_1299514263.txt.tar
  15926   Tue Mar 16 19:13:09 2021 Paco, AnchalUpdateSUSFirst success in Input Matric Diagonalization

After jumping through few hoops, we have one successful result in diagonalizing the input matrix for MC1, MC2 and MC3.


  • Attachment 2 has the code file contained. For now, we can only guarantee it to work on Donatella in conda base environment. Our code is present in scripts/SUS/InMatCalc
  • We mostly follow the steps mentioned in 4886 and the matlab codes in scripts/SUS/peakFit.
  • Data is first multiplied with currently used inpur matrix to get time series data in DOF (POS, PIT, YAW, SIDE) basis.
  • Then, the peak frequencies of each resonance are identified.
  • For getting these results, we did not attempt to fit the peaks with lorentzians and took the maxima point of the PSD to get the peak positions. This is only possible if the current input matrix is good enough. We have to adjust some parameters so that our fitting code works always.
  • TF estimate between the sensor data w.r.t UL sensor is taken and the values around the peak frequencies of oscillations are averaged to get the sensing matrix.
  • This matrix is normalized along DOF axis (columns in our case) and then inverted.
  • After inversion, another normaliation is done along DOF axis (now rows).
  • Finally we plot the comparison of ASD in DOF basis when using current input matrix and when using our calculated inpur matrix (diagonalizing).
  • You can notice in Attachment 1 that after the diagonalization, each DOF shows resonance at only one and its own resonance frequency while earlier there was some mixing shown.
  • Absolute value of the calculated DOF might have changed and we need to calibrate them or apply appropriate gain factors in the DOF basis filter chains.

Next steps:

  • We'll complete our scripts and make them more general to be used for any optic.
  • We'll combine all of them into one single script which can be called by medm.
  • In parallel, we'll start onwards from step 2 in 15881.
  • Anything else that folks can suggest on our first result. Did we actually do it or are we fooling ourselves?
Attachment 1: IMC_InputMatrixDiagonalization.pdf
IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf
Attachment 2: InMatCalcScripts.zip
  15928   Wed Mar 17 09:05:01 2021 Paco, AnchalConfigurationComputers40m Control Room Changes
  • Switched positions of allegra and donatella.
  • While doing so, the hdmi cable previously used by donatella snapped. We replaced this cable by another unused cable we found connected only on one end to rossa. We should get more HDMI cables if that cable was in use for some other purpose.
  • Paco bought a bluetooth speaker/mic that is placed infront of allegra and it's usb adapter is connected to iMac's keyboard in the bottom. With the new camera installed, the 40m video call environment is now complete.
  • Again, we have placed allegra's monitor for place holder but it is not working and we need new monitors for it in future whenever it is going to be used.
  15937   Thu Mar 18 09:18:49 2021 Paco, AnchalUpdateSUSTesting of new input matrices with new data

[Paco, Anchal]

Since the new generated matrices were created for the measurement made last time, they are of course going to work well for it. We need to test with new independent data to see if it works in general.

  • We have run scripts/SUS/InMatCal/freeSwingMC.py for 1 repition and free swinging duration of 1050s on tmux session FreeSwingMC on Rossa. Started at GPS: 1300118787.
  • Thu Mar 18 09:24:57 2021 : The script ended successfully. IMC is locked back again. Killing the tmux session.
  • Attached are the results of 1-kick test, time series data and the ASD of DOFs for calculated using existing input matrix and our calculated input matrix.
  • The existing one was already pretty good except for maybe the side DOF which was improved on our diagonalization.


After Anchal left for his test, I took the time to set up the iMAC station so that Stephen (and others) can remote desktop into it to use Omnigraffle. For this, I enabled the remote login and remote management settings under "Sharing" in "System Settings". These two should allow authenticated ssh-ing and remote-desktopping respectively. The password is the same that's currently stored in the secrets.

Quickly tested using my laptop (OS:linux, RDP client = remmina + VNC protocol) and it worked. Hopefully Stephen can get it to work too.

Attachment 1: MC_Optics_Kicked_Time_Series_1.pdf
Attachment 2: TEST_Input_Matrix_Diagonalization.pdf
TEST_Input_Matrix_Diagonalization.pdf TEST_Input_Matrix_Diagonalization.pdf TEST_Input_Matrix_Diagonalization.pdf
  15943   Fri Mar 19 10:49:44 2021 Paco, AnchalUpdateSUSTrying coil actuation balance

[Paco, Anchal]

  • We decided to try out the coil actuation balancing after seeing some posts from Gautum about the same on PRM and ETMY.
  • We used diaggui to send swept sine excitation signal to C1:SUS-MC3_ULCOIL_EXC and read it back at C1:SUS-MC3_ASCPIT_IN1. Idea was to create transfer function measurements similar to 15880.
  • We first tried taking the transfer function with excitation amplitude 0f 1, 10, 50, 200 with damping loops on (swept from 10 to 100 Hz lograthmically in 20 points).
  • We found no meaningful measurement and looked like we were just measuring noise.
  • We concluded that it is probably because our damping loops are damping all the excitation down.
  • So we decided to switch off damping and retry.
  • We repeated teh above measurements going up in amplitudes of excitation as 1, 10, 20. We saw the oscillation going out of UL_COIL but the swept sine couldn't measure any meaningful transfer function to C1:SUS-MC3_ASCPIT_IN1. So we decided to just stop. We are probably doing something wrong.

Trying to go back to same state:

  • But C1:SUS-MC3_ASCYAW_INMON had accumulated about 600 offset and was distrupting the alignment. We switched off C1:SUS-MC3_ASCYAW_SW2 hoping the offset will go away once the optic is just damped with OSEM sensors, but it didn't.
  • Even after minutes, the offset in C1:SUS-MC3_ASCYAW_INMON kept on increasing and crossed beyond 2000 counts limit set in C1:IOO-MC3_YAW filter bank.
  • We tried to unlock the IMC and lock it back again but the offset still persisted.
  • We tried to add bias in YAW DOF by increasing C1:SUS-MC3_YAW_OFFSET, and while it was able to somewhat reduce the WFS C1:SUS-MC3_ASCYAW_INMON offset  but it was misalgning the optic and the lock was lost. So we retracted the bias to 0 and made it zero.
  • We tried to track back where the offset is coming from. In C1IOO_WFS_MASTER.adl, we opened the WFS2_YAW filter bank to see if the sensor is indeed reading the increasing offset.
  • It is quite weird that C1:IOO-WFS2_YAW_INMON is just oscillating but the output in this WFS2_YAW filter bank is slowly increasing offset.
  • We tried to zero the gain and back to 0.1 to see if some holding function is causing it, but that was not the case. The output went back to high negative offset and kept increasing.
  • We don't know what else to do. Only this one WFS YAW output is increasing, everything else is at normal level with no increasing offset or peculiar behavior.
  • We are leaving C1:SUS-MC3_ASCYAW_SW2 off as it is disrupting the IMC lock.

[Jon walked in, asked him for help]

  • Jon suggested to do burt restore on IOO channels.
  • We used (selected through burtgooey):
    burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/Mar/19/08:19/c1iooepics.snap -l /tmp/controls_1210319_113410_0.write.log -o /tmp/controls_1210319_113410_0.nowrite.snap -v <
  • No luck, the problem persists.
  15951   Mon Mar 22 11:57:21 2021 Paco, AnchalUpdateSUSTrying coil actuation balance

[Paco, Anchal]

  • For MC coil balancing we will use the ASC (i.e. WFS) error signals since there are no OPLEV inputs (are there OPLEVs at all?).

Test MC1

  • Using the SUS screen LockIns the plan is to feed excitation(s) through the coil outputs, and look at the ASC(Y/P) error signals.
  • A diaggui xml template was saved in /users/Templates/SUS/MC1-actDiag.xml which was based on /users/Templates/SUS/ETMY-actDiag.xml
  • Before running the measurement, we of course want to plug our input matrix, so we ran /scripts/SUS/InMatCalc/writeMatrix.py only to find that it tripped the MC1 Watchdog.
    • The SIDE input seems to have the largest rail, but we just followed the procedure of temporarily increasing the WD max! threshold to allow the damping action and then restoring it.
    • This happened because in latest iteration of our code, we followed an advice from the matlab code to ensure the SIDE OSEM -> SIDE DOF matrix element remains positive, but we found out that MC1 SIDE gain (C1:SUS-MC1_SUSSIDE_GAIN) was set to -8000 (instead of a positive value like all other suspensions).
    • So we decided to try our new input matrix with a positive gain value of 8000 at C1:SUS-MC1_SUSSIDE_GAIN and we were able to stablize the optic and acquire lock, but...
    • We saw that WFS YAW dof started accumulating offset and started disturbing the lock (much like last friday). We disabled the ASC Input button (C1:SUS-MC1_ASCYAW_SW2).
    • This made the lock stable and IMC autolocker was able to lock. But the offset kept on increasing (see attachment 1).
    • After sometime, the offset begain to exponential go to some steady state value which was around -3000.
  • We wrote back the old matrix values and changed the C1:SUS-MC1_SUSSIDE_GAIN back to -8000. But the ASCYAW offset remained to the same position. We're leaving it disabled again as we don't know how to fix this. Hopefully, it will organically come back to small value later in the day like last time (Gautum just reenabled the ASCYAW input and it worked).

Test MC3

  • Defeated by MC1, we moved to MC3.
  • Here, the gain value for C1:SUS-MC3_SUSSIDE_GAIN was already positive (+500) so it could directly take our new matrix.
  • When we switched off watchdog, loaded the new matrix and switched the watchdog back on.
  • The IMC lock was slightly distrupted but remain locked. There was no unusual activity in the WFS sensor values. However, we saw the the SIDE coil output is slowly accumulating offset.
  • So we switched off the watchdog before it will trip itself, wrote back the old matrix and reinstated the status quo.
  • This suggests we need to carefully look back our latest changes of normalization and have new input matriced which keep the system stable other than working on paper with offline data.
Attachment 1: 210322_MC1_ASCY.pdf
Attachment 2: NewandOldMatrices.tar.gz
  15954   Mon Mar 22 19:07:50 2021 Paco, AnchalUpdateSUSTrying coil actuation balance

We found that following protocol works for changing the input matrices to new matrices:

  • Shut the PSL shutter C1:PSL-PSL_ShutterRqst. Switch off IMC autolocker C1:IOO-MC_LOCK_ENABLE.
  • Switch of the watchdog, C1:SUS-MC1_LATCH_OFF.
  • Update the new matrix. (in case of MC1, we need to change sign of C1:SUS-MC1_SUSSIDE_GAIN for new matrix)
  • Switch on the watchdog back again which enables all the coil outputs. Confirm that the optic is damped with just OSEM sensors.
  • Switch on IMC autolocker C1:IOO-MC_LOCK_ENABLE and open PSL shutter C1:PSL-PSL_ShutterRqst.

We repeated this for MC2 as well and were able to lock. However, we could not do the same for MC3. It was getting unstable as soon as cavity was locked i.e. the WFS were making the lock unstable. However, the unstability was different in different attempts but we didn't try mroe times as we had to go.

Coil actuation balancing:

  • We set LOCKIN1 and LOCKIN2 oscillators at 10.5 Hz anf 13.5 Hz with amplitude of 10 counts.
  • We wrote PIT, YAW and Butterfly actuation vectors (see attached text files used for this) on LOCKIN1 and LOCKIN2 for MC1.
  • We measured C1:SUS-MC1_ASCYAW_IN1 and C1:SUS-MC1_ASCPIT_IN1 and compared it against the case when no excitation was fed.
  • We repeated the above steps for MC2 except that we did not use LOCKIN2. LOCKIN2 was found to already on at oscillator frequency of 0.03Hz with amplitude of 500 counts and was fed to all coils with gain of 1 (so it was effectively moving position DOF at 0.03 Hz.) When we changed it, it became ON back again after we turned on the autolocker, so we guess this must be due to some background script and msut be important so we did not make any changes here. But what is it for?
  • We have gotten some good data for MC1 and MC2 to ponder upon next.
  • MC1 showed no cross coupling at all while MC2 shoed significant cross coupling between PIT and YAW.
  • Both MC1 and MC2 did not show any cross coupling between butterfly actuation and PIT/YAW dof.

On another news, IOO channels died!

  • Infront of us, the medm channels starting with C1:IOO just died. See attachment 8.
  • We are not sure why that happened, but we have reported everything we did up here.
  • This happened around the time we were ready to switch back on the IMC autolocker and open the shutter. But now these channels are dead.
  • All optics were restored with old matrices and settings and are damped in good condition as of now.
  • IMC should lock back as soon as someone can restart the EPICS channels and switch on C1:IOO-MC_LOCK_ENABLE and C1:PSL-PSL_ShutterRqst.
Attachment 1: 20210322_MC1_CoilBalancePIT.pdf
Attachment 2: 20210322_MC1_CoilBalanceYAW.pdf
Attachment 3: 20210322_MC1_CoilBalanceBUTT.pdf
Attachment 4: 20210322_MC2_CoilBalancePIT.pdf
Attachment 5: 20210322_MC2_CoilBalanceYAW.pdf
Attachment 6: 20210322_MC2_CoilBalanceBUTT.pdf
Attachment 7: 20210322_IMC_CoilBalance.tar.gz
Attachment 8: image-e6019a14-9cf3-45f7-8f2c-cc3d7ad1c452.jpg
ELOG V3.1.3-