40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 234 of 341 Not logged in
ID Date Author Type Category Subject
8337   Mon Mar 25 15:24:41 2013 ranaUpdateLockingTT1 drift

I doubt that it has truly disappeared. Can you please make a measurement of it and quantify the hysteresis using some angle sensor?

8347   Tue Mar 26 00:06:37 2013 JenneUpdateLockingAS beam put back on PD

[Jenne, Gabriele]

We aligned MICH (first locked Yarm, but didn't optimize since we don't have TRY, then locked Xarm, then aligned MICH), but there was no beam on AS55.  We went out to check, and the beam was almost not hitting the small steering mirror between AS55.  We adjusted the BS splitting the beam between camera and PD, and got the beam back on AS55. We could then lock MICH.

We also futzed with the REFL55 phase to get PRCL stuff in I, and MICH stuff in Q.  The procedure was to align PRMI, then kick PRM in pos, and adjust the phase so we got signal mostly in I after the kick.  We started at the original value of 60deg, but are leaving it at -20deg.

8348   Tue Mar 26 00:17:47 2013 JenneUpdateLockingREFL pickoff fraction

To see how much of the light that comes out of the REFL port actually goes to the PDs, I measured the power immediately after leaving the vacuum (~575mW) and in front of REFL11 (~5mW) and REFL55 (~6mW).

So, 0.01 of the power leaving the vacuum actually goes to the REFL PDs. This number will be useful when calculating the actual signals (in volts) that we expect to see.

8351   Tue Mar 26 11:08:03 2013 JenneUpdateLockingPRMI locking should be possible - let's get it done!

[Jenne, Gabriele, Jamie]

We have looked at Koji's old Finesse code, and determined that the PRMI sensing matrix that he calculated was for the sideband-resonant case.  Thus, this is the sensing matrix we are interested in for locking. Gabriele has confirmed this using independently written code with his software, Mist.

Pics or it didn't happen:

The sensing matrix is:

Numerical values are on the wiki:  https://wiki-40m.ligo.caltech.edu/IFO_Modeling/SensingMatrix

For any of the REFL PDs (1*f1, 1*f2, 3*f1, 3*f2), the PRCL signal is a factor of ~100 larger than the MICH signal.  Rana assures us that, with some clever triggering, we should be able to lock the PRMI.

This means that we will not be venting in the next few days to flip the SRC folding mirror.  We will work on PRMI lock (probably first with 1*f, but then quickly moving on to 3*f), and as soon as Annalisa and Manasa have the new ETMY table ready for us, we will then do PRFPMI.  (We can also play with the Xarm green until Yarm green is back).

8360   Wed Mar 27 15:46:13 2013 JenneUpdateLockingPRMI progress

[Gabriele, Jenne]

We have achieved PRMI locks of the order ~5 seconds! Here is an example lock:

This was actuating MICH on the ITMs (+1 for ITMY, -1 for ITMX in the output matrix), and PRCL on PRM (+1).

PRCL gain was +1, MICH gain was -10.

PRCL signal was normalized with POP22I with a matrix value of 0.003 . (No normalization of MICH).

Both PRCL and MICH were triggered on POP22I with high thresh of 200, low of 50.  MICH and PRCL FM2 (integrators) were triggered on POP22I with thresh of 400 and low thresh of 50.  FMs 4 and 5 were on for both MICH and PRCL always.

We zoomed in on the MICH_OUT signal, and the instability looks like it is around 300 Hz.  We aren't sure what this is.  I think this is a similar frequency to an oscillation that Yuta saw, but I'll have to check the old elogs.

PRM and BS SUS_LSC_POS filter banks both have notches between 1280-1290Hz.  The ITMs do not have this "Vio2" filter.

This is one of the first locks with the new triggering of both the INPUT and OUTPUT of the control filter banks.  I modified the lsc model before lunch.

To do:  Where is this 300Hz coming from, and what can we do about it?  Why are we losing lock?  It's not due to the oscillation - maybe too much afternoon seismic?  Steve says he went next door and the rock monster / river is on medium/high.

8363   Thu Mar 28 01:59:33 2013 JenneUpdateLockingPRMI progress - even better!

[Gabriele, Rana, Jenne, Jamie, Lisa, Zach]

We tweaked some things after dinner, and our locks got longer (~10sec) and more frequent!

What happened / notes:

* Increased analog gain from 15dB to 27dB for REFL55 I&Q.

* No analog whitening during lock acquisition.  (Need trigger + wait so whitening comes on after ~1sec...but this is not our limitation right now).

* Limit MICH and PRCL control to 5000, so that we don't kick optics too much, which makes them take too long to settle.

* ITMX and ITMY Vio2 filters turned off (PRM still has it on) in the SUS-optic_LSC module.

* MICH and PRCL DoFs triggering on POP22I, with levels 200 & 50.  FMs 4&5 always on.

* MICH and PRCL FM2 triggering on POP22I with levels 400 & 50.

* MICH gain = -0.200

* PRCL gain = +0.150

* MICH and PRCL normalization using POP22I, with matrix values 0.00160 .  This value is ~1/600, where 600 was the peak value of POP22I_ERR.

* REFL 55 phase set back to -15, to minimize PRCL signal in I phase.

* Checked signs for ITMX and ITMY in output matrix for MICH.  Lock MICH using only ITMX or ITMY, find sign to hold on the dark fringe for each.  +1 for ITMY, -1 for ITMX was correct.

* Tweaked up the oplev servos.  See separate elog 8362.  May need more tweaking, such as increasing the UGF, engaging 1Hz resonant gain.

* May need better coil actuator balancing on suspensions at 1Hz.

* Found a weird thing in DTT, which went away after closing and reopening, when looking at time series.  Sometimes we would see a square wave-like jump in the signals, all signals at the same time, with a frequency of 16.6Hz.  This was not present in other data retreival programs, like Jamie's getdata python script.

* We are not sure right now why we are falling out of lock.  We need to investigate more signals, to try to figure out what our current problem is.

* Reduced the amount of misalignment with the "misalign" script, to reduce hysteresis.

To Do / ideas:

* Calibrate oplev signals - see if one optic is moving more than others.

* Calibrate ERR and CTRL  - look at CTRL in meters, see if cavities are moving around like crazy.

* Calibrate POP22 using something like an AM laser modulation trick into units of PRCL SB gain. Compare with expectation - are we locked optimally, or do we have more power that we can be getting out?

* Try feeding back PRCL CTRL to MC2, to make the laser to follow the power recycling cavity, in hopes of reducing angular motion.  Rana tried this quickly with a 1 in the output matrix, but this kicked the MC out of lock - need to try smaller values.

8364   Thu Mar 28 04:21:40 2013 ranaUpdateLockingPRMI progress - even better!

A key step was turning off the whitening filters. With the previous setting (G = 15 dB, white on), the error signals (post anti-whitening) had amplitudes of ~500 counts. This means that they can go as high as (150/15)^2 * 500 = 50000 counts on the ADC.

The purpose of the whitening filter is to match the noise / range of the signal to the ADC. What we would like to do is use the minimum gain so as to make the RFPD electronics noise + shot noise be ~equal to the ADC noise. i.e.

sqrt(V_PD^2 + v_shot^2) * G_white = V_ADC

The RFPD noise is ~3 nV before the internal preamp. The MAX4107 has a gain of 10. There is a factor of 1/2 from the voltage division of the RFPD's 50 Ohm series resistor and the input impedance of the mixer. There is also a power splitter between the PD output and the mixer which gives us a 3 dB loss. The mixer has a conversion loss of ~5-6 dB depending upon the LO level.

V_PD = 3e-9 * (10 * 1/2 * 1/sqrt(2) * 1/2) = 5e-9 V/rHz   (this is already bad; the signal coming out of the mixer needs to be amplified by x10 before going out to the whitening board).

In any case, its clear that we need something like 60 dB of gain for the PD noise to match the ADC noise. This is why increasing the whitening gain improves the error signal's SNR, reduces the hash driving the optics, and improves the locking. We should run with 45 dB gain and the switch on whitening after the lock.

Even better would be to modify the LT1128 input stage of the card to have the single stage of fixed whitening as we did for iLIGO. Then we can have triple whitening in lock.

8385   Mon Apr 1 17:59:04 2013 JenneUpdateLockingPRMI videos

[Gabriele's work, I'm just spectating]

Annalisa is working on finding the PSL/AUX laser beatnote, so the PSL temp is changing, but Gabriele is still able to lock.  Here are some videos:

8399   Wed Apr 3 03:18:23 2013 JenneUpdateLockingPRMI locked with REFL55 I&Q for more than 1 minute

[Rana, Gabriele, Jenne]

We have now locked the PRMI using REFL55 I&Q for more than one minute!!!!!

This isn't really the most useful plot as is, but it was created using:

/opt/rtcds/caltech/c1/scripts/general/getdata C1:LSC-POP22_I_ERR_DQ C1:LSC-REFL55_I_ERR_DQ C1:LSC-REFL55_Q_ERR_DQ C1:LSC-MICH_IN1_DQ C1:LSC-MICH_OUT_DQ C1:LSC-PRCL_IN1_DQ C1:LSC-PRCL_OUT_DQ -d 80 -s 1049013520 -c

This is just one of several long lock stretches.  If I can get the TRIG_MON channels to be saved, we can automatically (versus my by-hand search) find lock stretches and make this kind of plot.  Although we want them saved in some raw format so we can zoom in on selected axes, I think.  This might require some python-fu from Jamie, or learning of python-fu for Jenne.

The secret sauce:

* The big key was changing REFL55's phase.  It was -4 when we looked at the I&Q signals, and minimized the PRCL information in the Q-phase.  We were able to get short lock stretches with this.  During these stretches, Rana changed the REFL55 phase until the lock sounded (audibly) quieter.  The final phase we settled on was +26. As we changed the phase, the lock stretches got longer and longer.

* We also tweaked up the POP22 phase.  It was close from our previous efforts of looking at non-locked time series, but we perfected it by minimizing the signal in the Q-phase during lock stretches.  We also found that it drifted (according to this method) by ~5 degrees over ~half an hour (I don't remember the exact time between our phase tunings).

* POP22's low pass filters (both options, ELP10 and ELP50) must be OFF for any lock to be acquired.  Turning on either filter prevents locking.

* Normalization helped a lot.  Without normalization we weren't really able to catch any locks, certainly not of any significant length. (0.004, using POP22I, for both MICH and PRCL).

* Parameters:

** Normalization:  use POP22I for both MICH and PRCL, value = 0.004

** Input matrix:  MICH with REFL55Q, value = 0.01; PRCL with REFL55I, value = 0.01  (we used the small number in the matrix so our servo gains weren't too tiny).

** POP22 lowpass filters OFF

** Analog whitening OFF for REFL55, POP22.

** Analog gain for REFL55 I&Q = 27 dB

** Analog gain for POP22 I&Q = 15 dB

** Output matrix:  MICH with -1 to ITMX, +1 to ITMY.  PRCL with +1 to PRM.

** Servo gains:  PRCL = 0.75;  MICH anywhere between -3 and -20.  Best in the -8 to -15 range.

** Vio2 filters in ITMX, ITMY, PRM (all actuated-on mirrors) were OFF. (Still need to lower the Q on these so they don't ring).

** PRCL and MICH triggering on POP22I.  The trigger-off was always 20, but the trigger-on changed throughout the night from ~170 to ~50.  I think 130 was a trigger value for at least some of the long-time locks.

** Low frequency seismic was small (i.e. no anomalous 0.1 Hz - 1 Hz noise) during successful lock times.  (Not to say it must be low, but it was low when we were able to lock for long stretches).

Things we had looked at and thought about throughout the evening:

* Oplev calibration.  See elog 8391 and 8393.  Optimized BS and PRM to reduce yaw angular motion.

* Actuators all functioning as expected.  We checked transfer functions of MICH_OUT/MICH_IN1 for locking with different optics, to ensure that at high frequency the response was 1/f^2.  Also, we locked MICH with (a) both ITMs, (b) BS, (c) ITMX and (d) ITMY.  We locked the PR-ITMY half-cav with (a) PRM and (b) ITMY.  We locked the PR-ITMX half-cav with (a) PRM and (b) ITMX.  Thus, we conclude that all of the PRMI-related optics are functioning as expected.

* Realigned REFL55 beam onto PD.  It was clipping a bit, so the DC power wasn't steady (when ITMs were misaligned, PRM aligned).  After alignment, the DC power as seen on a 'scope was much smoother.

* Turning off the limiters for the MICH and PRCL control signals allowed us to hear a high-pitched whine.  From looking at the time series, it's predominantly in MICH_OUT.  Rana speculates that perhaps the normalization is causing the UGF to wander temporarily to an unstable place.  For a time there was a high-Q peak between 500 and 600Hz, but reducing the gain (of MICH?) eliminated that.  Then we heard several times, irrespective of gain setting, the ~400Hz broad peak (I say broad because I was able to see it on DTT looking at the error and control signals, and it spanned +/-100Hz).

Things to investigate:

* Is there a good reason that we should switch to triggering on POP110, rather than the current POP22?  From Gabriele, Jamie and my Finesee/Mist modelling last week, without the arms, the 11MHz and 55MHz resonate at different PRC lengths.  If this difference is very small, then we are fine, but if the difference is large, it could be causing trouble - we're trying to catch the lock at the linear part of the 55MHz signal, but if that does not coincide with the linear part of the 11MHz signal, we're doing the wrong thing.

* For the POP normalization, should we be using the amplitude or the power ( POP22 or sqrt(POP22) )?  Why?  Look at this with a modelling sweep and/or analytically.

* Look at different noise sources, potentially sensing noise, coil actuator noise,.....  We should check these out, and make sure we're not limited by anything obvious.

Other To-Do:

* Make a "restore" medm screen, rather than restore script.  IFO Configure restore script can pull in values from the screen (EPICS values).  One screen per configuration.

* Get TRIG_MON signals saved, write script to search for triggered lock times (between given gps times), then plot interesting signals for just before lock, during lock, and until just after a lockloss.

8433   Wed Apr 10 01:10:22 2013 JenneUpdateLockingConfigure screen and scripts updated

I have gone through the different individual degrees of freedom on the IFO_CONFIGURE screen (I haven't done anything to the full IFO yet), and updated the burt snapshot request files to include all of the trigger thresholds (the DoF triggers were there, but the FM triggers and the FM mask - which filter modules to trigger - were not).  I also made all of the restore scripts (which does the burt restore for all those settings) the same.  They were widely different, rather than just different optics chosen for misaligning and restoring.

Before doing any of this work, I moved the whole folder ..../caltech/c1/burt/c1ifoconfigure to ..../caltech/c1/burt/c1ifoconfigure_OLD_but_SAVE , so we can go back and look at the past settings, if we need to.

I also changed the "C1save{DoF}" scripts to ask for keyboard input, and then added them as options to the CONFIGURE screen.  The keyboard input is so that people randomly pushing the buttons don't overwrite our saved burt files.  Here's the secret:  It asks if you are REALLY sure you want to save the configuration.  If you are, type the word "really", then hit enter (as in yes, I am really sure).  Any other answer, and the script will tell you that it is quitting without saving.

I have also removed the "PRM" option, since we really only want the "PRMsb" for almost all purposes.

Also, I removed access to the very, very old text file about how to lock from the screen.  That information is now on the wiki:  https://wiki-40m.ligo.caltech.edu/How_To/Lock_the_Interferometer

I have noted in the drop-down menus that the "align" functions are not yet working.  I know that Den has gotten at least one of the arms' ASSes working today, so once those scripts are ready, we can call them from the configure screen.

Anyhow, the IFO_CONFIGURE screen should be back to being useful!

8438   Thu Apr 11 02:00:21 2013 JenneUpdateLockingTRY gone???

TRY signals are all gone!  Both the PD and the camera show no signal.  I went down there to turn off the lights, and look to see what was up, and I don't see any obvious things blocking the beam path on the table.  However, Steve has experimentally bungeed the lids down, so I didn't open the box to really look to see what the story is.

Absent TRY, I redid the IFO alignment.  Yarm locked, so I assumed it was close enough.  I redid Xarm alignment pretty significantly.  Transmission was ~0.5, which I got up to ~0.85 (which isn't too bad, since the PMC transmission is 0.74 instead of the usual 0.83).  I then aligned MICH, and PRM.  After fixing up the BS alignment, the POP beam wasn't hitting the POP PD in the center any more.  I centered the beam on the PD, although as Gabriele pointed out to me a week or two ago, we really need to put a lens in front of POP, since the beam is so big.  We're never getting the full beam when the cavity flashes, which is not so good.

Den is still working on locking, so I'll let him write the main locking report for the night.

We see that the PRC carrier lock seems to be more stable when we lock MICH with +1 for ITMY and -1 for ITMX, and PRCL with -1 for both ITMs.  This indicates that we need to revisit the systematic problem with using the PRM oplev to balance the coils, since that oplev has a relatively wide opening angle.  I am working on how to do this.

8439   Thu Apr 11 02:49:18 2013 DenUpdateLockingPRCL on carrier

Jenne, Den

We suspect PRM shows significant length to angle coupling due to large oplev beam angle in yaw.  Tonight we locked PRCL with ITMs.

We could lock PRCL on carrier to power recycling gain of 15. Lock continued for a few hours but power rin RMS was 0.15.

We triggered and normalized on POP_DC. MICH gain was -1 (filters FM3-5), PRCL gain was -8 (filters FM2,4,5,6,9).

MC_L was OFF during locking.

Attachment 1: pop_rin.pdf
Attachment 2: power.png
8442   Thu Apr 11 03:38:40 2013 DenUpdateLockingangular motion

Spectra of BS, PRM, ITMX, ITMY are attached with oplevs ON and OFF (in units of urad). Loops reduce RMS from ~2urad to ~0.3urad but phase margin should be increased. REF traces show loop OFF. <-- really?

Note how PRM pitch and yaw spectra are different in the frequency range 0.5 - 7 Hz; yaw is factor of 50 larger then pitch at 2 Hz.

Attachment 1: oplevs.pdf
8443   Thu Apr 11 10:15:55 2013 SteveUpdateLockingPRM yaw oplev transferfunction

See   Feb 2012 PRM yaw transferfunctions, also check Valera's modified  side sensor may effect yaw motion

8446   Fri Apr 12 02:56:34 2013 DenUpdateLockingprcl angular motion

I compared PCRL and XARM angular motions by misaligning the cavities and measuring power RIN. Divergence angles for both cavities I calculated to be 100 urad.

XARM pointing noise sums from input steering TTs, PR2 and PR3 TTs, BS, ITMX, ETMY.

PRCL noise - from input TT, PRM, PR2 and PR3 TT, BS, ITMX, ITMY.

I would expect these noises to be the same as angular motion of different optics measured by oplves is simular. We do not have oplves on TT but they are present in both passes.

I measured RIN and converted to angle. Sharp 1 Hz resonance at XARM pointing spectrum is due to EMTX, it is not seen by PRCL. Other then that XARM is much quiter, especially at 3 - 30 Hz.

As PRM  is the main difference in two passes, I checked its spectrum. When PRCL was locked I excited PRM in pitch and yaw. I could see this excitation at RIN only when the peak was 100 times higher then background seismic noise measured by oplev.

Attachment 2: oplev_exc.pdf
8447   Fri Apr 12 09:20:32 2013 ranaUpdateLockingprcl angular motion

How is the cavity g-factor accounted for in this calculation?

8449   Fri Apr 12 13:21:34 2013 DenUpdateLockingprcl angular motion

 Quote: How is the cavity g-factor accounted for in this calculation?

I assume that pointing noise and dc misalignment couples 00 to 01 by a factor theta / theta_cavity

Inside the cavity 01 is suppressed by 2/pi*F*sin(arccos(sqrt(g_cav))).

For the XARM this number is 116 taking g-factor to be 0.32. So all pointing noise couples to power RIN.

Suppression factor inside PRC is 6.5 for g-factor 0.97. This means that 85% of jitter couples to RIN, I accounted for this factor while converting RIN to angle.

I did not consider translational motion of the beam. But still PRC RIN can not be explained by oples readings as we can see exciting optics in pitch and yaw. I suspect this RIN is due to PR3, as it can create stronger motion in yaw than in pitch due to incident angle and translational motion of the mirror. I do not have a number yet.

8450   Sat Apr 13 03:45:51 2013 ranaUpdateLockingprcl angular motion

Maybe its equivalent, but I would have assumed that the input beam is fixed and then calculate the cavity axis rotation and translation. If its small, then the modal expansion is OK. Otherwise, the overlap integral can be used.

For the ETM motion, its a purely translation effect, whereas its tilt for the ITM. For the PRM, it is also a mostly translation effect as calculated at the PRC waist position (ITM face).

8451   Sat Apr 13 23:11:04 2013 DenUpdateLockingprcl angular motion

 Quote: For the PRM, it is also a mostly translation effect as calculated at the PRC waist position (ITM face).

I made another estimation assuming that PRCL RIN is caused by translation of the cavity axis:

• calibrated RIN to translation, beam waist = 4mm
• measured PRM yaw motion using oplev
• estimated PR3 TT yaw motion: measured BS yaw spectrum with oplev OFF, divided it by pendulum TF with f0=0.9 Hz, Q=100 (BS TF), multiplied it by pendulum TF with f0 = 1.5 Hz, Q = 2 (TT TF with eddy current damping), accounted for BS local damping that reduces Q down to 10.

PRM and TT angular motion to cavity axis translation I estimated as 0.11 mm/urad and 0.22 mm/urad assuming that TTs are flat. We can make a more detailed analysis to account for curvature.

I think beam motion is caused by PR3 and PR2 TT angular motion. I guess yaw motion is larger because horizontal g-factor is closer to unity then vertical.

Attachment 1: pointing.pdf
8452   Sun Apr 14 15:03:17 2013 ManasaUpdateLockingFixing - progress

 Quote: TRY signals are all gone!  Both the PD and the camera show no signal.  I went down there to turn off the lights, and look to see what was up, and I don't see any obvious things blocking the beam path on the table.  However, Steve has experimentally bungeed the lids down, so I didn't open the box to really look to see what the story is. Absent TRY, I redid the IFO alignment.  Yarm locked, so I assumed it was close enough.  I redid Xarm alignment pretty significantly.  Transmission was ~0.5, which I got up to ~0.85 (which isn't too bad, since the PMC transmission is 0.74 instead of the usual 0.83).  I then aligned MICH, and PRM.  After fixing up the BS alignment, the POP beam wasn't hitting the POP PD in the center any more.  I centered the beam on the PD, although as Gabriele pointed out to me a week or two ago, we really need to put a lens in front of POP, since the beam is so big.  We're never getting the full beam when the cavity flashes, which is not so good. Den is still working on locking, so I'll let him write the main locking report for the night. We see that the PRC carrier lock seems to be more stable when we lock MICH with +1 for ITMY and -1 for ITMX, and PRCL with -1 for both ITMs.  This indicates that we need to revisit the systematic problem with using the PRM oplev to balance the coils, since that oplev has a relatively wide opening angle.  I am working on how to do this.

I'm fixing the TRY path.

I misaligned PRM and restored ETMY; but did not see the Y arm flashing. I am going ahead and moving the optics to get Y arm flashing again.

The slider values on the medm screen before touching any of them (for the record):

       tt1        tt2      itmy        etmy
p    -1.3886    0.8443     0.9320    -3.2583
y     0.3249    1.1407    -0.2849    -0.2751
8453   Sun Apr 14 17:30:14 2013 ManasaUpdateLockingFixed

TRY path fixed and ready for normalization.

I used 2" BS at R=50 and R=98 to reflect the Y arm transmission at QPD-Y and TRY PD respectively. The residual beam transmitted by the BS is now steered by a Y1mirror to the camera. With Y arm locked, transmission currently measures 40mW against the expected 70mW. TRY shows 0.45 counts in dataviewer.

8454   Sun Apr 14 17:56:03 2013 ranaUpdateLockingprcl angular motion

Quote:

 Quote: For the PRM, it is also a mostly translation effect as calculated at the PRC waist position (ITM face).

I made another estimation assuming that PRCL RIN is caused by translation of the cavity axis:

• calibrated RIN to translation, beam waist = 4mm

In order to get translation to RIN, we need to know the offset of the input beam from the cavity axis...

This should be possible to calibrate by putting a pitch and yaw excitation lines into the PRM and measuring the RIN.

See secret document from Koji.

8455   Sun Apr 14 23:20:42 2013 DenUpdateLockingFixed

 Quote: TRY path fixed and ready for normalization. I used 2" BS at R=50 and R=98 to reflect the Y arm transmission at QPD-Y and TRY PD respectively. The residual beam transmitted by the BS is now steered by a Y1mirror to the camera. With Y arm locked, transmission currently measures 40mW against the expected 70mW. TRY shows 0.45 counts in dataviewer.

I think it is too much. Incident power to IFO is 1.3 W. Even if we assume no losses and pick-offs on the path to the arms, we should get ~100 uW out of the cavity. I measured X and Y arms transmission to be 60 uW. Did you disable triggering during your measurement?

8463   Thu Apr 18 21:12:56 2013 ManasaUpdateLockingFixed

[Den, Manasa]

TRY & TRX power measurement was redone.

TRY measures 66uW and 0.8counts on dataviewer.
TRX measures 70.4uW and 0.84counts on dataviewer.

___________________________
Detector       Power
-------------------------------------------------
QPD-Y          33uW (50%)
TRY-PD         29.8uW (49%)
Y-Camera         1%
QPD-X         35.2uW (50%)
TRX-PD        25.1uW (90%)
X-Camera    10%
____________________________

8464   Fri Apr 19 04:20:41 2013 DenUpdateLockingPRMI on sidebands

Tonight PRMI was locked on REFL55 I&Q for PRCL and MICH with POP110I as a trigger and power normalizer.

I could see power fluctuations and beam motion on the POP camera very much the same as for carrier. The difference is that carrier stays for hours while sidebands for a few minutes.

POP110:

I&Q analog gains were set to 15 dB. Relative phase was set to 25 degrees by looking at I and Q components when the cavity goes through the resonance. Q should be 0.

## REFL55:

Phase rotation was measured by exciting PRM at 20 Hz and minimizing this line at REFL55_Q. I stopped at 33 degrees.

## RIN:

I compared power fluctuations of PRCL when it was locked on carrier (POP_DC) and on sidebands (POP110_I).

Time series of POP110_I during one of the locks

POP camera:

8489   Thu Apr 25 03:35:28 2013 JenneUpdateLockingAngular motion does not explain RIN

Den made a nice elog about the PRMI RIN that we see a few weeks ago:  8464.  The RIN that we're seeing is typically about ~30%.  The question at hand is: what is causing this power fluctuation, and more specifically, is it the angular motion of the mirrors?

I find that no, the angular motion that we see does not explain the RIN that we see.

In the attached Mathematica notebook, I calculate the power lost due to angular misalignments of one or more mirrors.  (Math comes from Appendix A of Keita's thesis.)

From calibrated oplev spectra, our mirrors are moving about 1 microradian (RMS, which is dominated by low frequencies).  From a super sophisticated "draw on the TV, then measure" method (details below), I have estimated that the maximum static misalignment that we're seeing is about 2 microradians.

With all of this, I find that for a g-parameter of 0.94, the power lost due to misalignments should, at maximum, be 0.6%.  I need a g-parameter of 0.995 to get a power loss of 23%.  Alternatively, if I take the derivative of the power coupling function, to find the static misalignment at the steepest slope of the curve (and thus, the place where any AC misalignment would have the most effect), for 1urad of AC misalignment, I get 40% power loss.

So, in order for the AC angular motion that we see to explain the RIN that we see, either our mirrors are very, very misaligned (so much so that we couldn't really be locking), or our cavity is much closer to unstable than expected from Jamie's calculations.  Since both of these cases (static misalignment or incorrect g-parameter calculation) have to be taken to extremes before they approximate the RIN that we see, I do not think that this power loss is due to angular fluctuations.

This means that we have to think of another potential cause for this RIN that we're seeing.

Details on the "draw on TV and measure" technique for determining static cavity misalignments:  Looking at the POP camera view, with the PRM significantly misaligned, I traced the straight-through beam spot.  I then restored the PRM, and during several momentary locks, I traced the beam spot, which I took to be the saturated area of the camera.  The idea here is that the straight-through beam represents the incident beam axis, while the locked beam represents the cavity axis.  I'm assuming that the camera image plane is at the face of PR2. I approximately found the center of each of my tracings, and found them to be ~1/4 inch apart.  I also measured the "spot size" of the sideband-locked PRMI, and found it to be ~3.5 inches.  So, very roughly, the ratio of (distance between spots)/(size of beam) is ~0.07. This corresponds to a static misalignment of either the ITM or the PRM of ~2urad, rounding up. (I use the Jamie's calculated g-parameters from elog 8316, the case of flipped PR2, tangential = 0.94 to calculate the effective RoC of the PRM).

Attachment 1: RIN_estimation_from_angular_motion.nb.zip
8490   Thu Apr 25 04:10:09 2013 JenneUpdateLockingMICH_CTRL drifting away??

Koji is elogging separately of his exploration of different configurations.  The lock stretch that I'm looking at here uses the same parameters as Koji had for PRMI sb lock, using AS55Q for MICH and REFL33I for PRCL, with MICH gain of -0.8 and PRCL gain of 0.05 .

All of these plots are the same few second lock stretch, with different zooming.  Jamie's super-sweet getdata python script only accepts integers for the start time and duration parameters, so lots of this zooming happened by hand, but I tried to always keep the time axis aligned within each screenshot.  Sometimes the plot axis labels say differently, but they're lying to you.

Plot 1:  gps start time is 1050915916, duration = 6 seconds.  Overall view of the lock stretch.

Plot 2:  gps start time is 1050915921, duration = 1 second.  We're looking at the lockloss that happens at the left side of the plots.

Plot 3:  zoomed in (along the time-axis) version of plot 2, so much shorter time duration.  Some zooming on y-axes.

Plot 4:  zoomed in (along y-axes) version of plot 2.

It seems to me from these plots that maybe MICH CTRL is drifting away?  It seems like we lose the MICH lock, and that destroys the whole thing.

Koji made some comments to me earlier, regarding his work this evening, that the MICH signal quality is poor in general, and that we should calculate/think about changing our schnupp asymmetry.

8535   Tue May 7 10:30:32 2013 KojiUpdateLockingPRM yaw responsible for RIN

 Quote: BS is contributing a little bit, but PRM is clearly contributing.

No.

While the peak in the PRM OPLEV was more than 10 times higher than the spectrum level without the excitation,
we only saw small peaks in the RIN spectra. This suggests that the PRM angular motion did not contribute to the RIN spectra.

You should divide the POP110I and POPDC spectra by 400 and 450, which was the DC values of these channels, in order to convert them into RIN (1/rtHz)
The OPLEV spectra is calibrated to be urad/rtHz (is this true?) so you can obtain the conversion factor from OPLEV to RIN (1/urad)
by matching the peaks. This way you make a angular noise projection.

 Quote: I think that I need to install one of the T240's on the new granite slab, and see what kind of coherence we have between seismic and PRM yaw motion, and if FF can get rid of it.

Yes we should do that. BTW what should be pushed?

8557   Thu May 9 02:19:53 2013 JenneUpdateLocking50% BS installed in POP path

Koji had the good idea of trying to measure the motion of the POP beam, and feeding that signal to PRM yaw to stabilize the motion.  To facilitate this, I have installed a 50% beam splitter before the POP 110/22 PD (so also before the camera).

Before touching anything, I locked the PRM-ITMY half-cavity so that I had a constant beam at POP.  I measured the POP DC OUT to be 58.16 counts.  I then installed a 1" 50% BS, making sure (using the 'move card in front of optic while watching camera' technique) that I was not close to clipping on the new BS.  I then remeasured POP DC OUT, and found it to be 30.63.  I closed the PSL shutter to get the dark value, which was -0.30 .  This means that I now have a factor of 0.53 less light on the POP110/22 PD.  To compensate for this, I changed the values of the power normalization matrix from 0.01 (MICH) to 0.0189, and 100 (PRCL) to 189.

After doing this, I restored the ITMX and am able to get several tens of seconds of PRMI lock (using AS55Q and REFL33I).

I found several QPDs in the PD cabinet down the Y arm, but no readout electronics.  The QPD I found is D990272.  I don't really want to spend any significant amount of time hacking something for this together, if Valera can provide a QPD with BNC outputs. For now, I have not installed any DC PD or razor blade (which can be a temporary proxy for a QPD, enough to get us yaw information).

8564   Mon May 13 18:44:04 2013 JenneUpdateLockingprcl angular motion

I want to redo this estimate of where RIN comes from, since Den did this measurement before I put the lens in front of the POP PD.

While thinking about his method of estimating the PR3 effect, I realized that we have measured numbers for the pendulum frequencies of the recycling cavity tip tilt suspensions.

I have been secreting this data away for years.  My bad.  The relevant numbers for Tip Tilts #2 and #3 were posted in elog 3425, and for #4 in elog 3303.  However, the data for #s 1 and 5 were apparently never posted.  In elog 3447, I didn't put in numbers, but rather said that the data was taken.

Anyhow, attached is the data that was taken back in 2010.  Look to elog 7601 for which TT is installed where.

Conclusion for the estimate of TT motion to RIN - the POS pendulum frequency is ~1.75Hz for the tip tilts, with a Q of ~2.

Attachment 1: TT_Q_measurements.pdf
14448   Mon Feb 11 19:53:59 2019 gautamSummaryLoss MeasurementLoss measurement setup

To measure the Y-arm loss, I decided to start with the classic reflectivity method. To prepare for this measurement, I did the following:

1. Placed a PDA 520 in the AS beam path on the AS table.
2. Centered AS beam on above PDA 520.
3. Monitored signal from PDA520 and the MC transmission simultaneously in the single-bounce from ITMY config (i.e. all other optics were misaligned). Convinced myself that variations in the two signals were correlated, thus ruling out in this rough test any interference from ghost beams from ITMX / PRM etc.
4. For the DAQ, I decided to use the two ALS Y arm channels in 1Y4, mainly because we have some whitening electronics available there - the OMC model would've been ideal but we don't have free whitening channels available there. So I ran long BNCs to the rack, labelled them.
5. It'd be nice to have these signals logged to frames, so I added DQ-channels for the IN1 points of the BEATY_FINE filters, recording at 2048 Hz for now. Of course this necessitated restart of the c1lsc model, which caused all the vertex FEs to crash, but the reboot script brought everything back smoothly.
6. Not sure what to make of the shape of the spectrum of the AS photodiode, see Attachment #1 - looks like some kind of scattering shelf but I checked the centering on the PD itself, looks good. In any case, with the whitening gains I'm using, seems like both channels are measuring above ADC noise.
7. Found that the existing misalignment to the ETMY does not eliminate signatures of cavity flash in the AS photodiode. So I increased the amount of misalignment until I saw no evidence of flashes in the reflected photodiode.
8. Johannes' old scripts didn't work out of the box - so I massaged it into a form that works.
9. Re-centered Oplevs to try and keep them as well centered in the linear range as possible, maybe the DC position info from the Oplevs is useful in the analysis.

I'm running a measurement tonight, starting now (~1130PM), should be done in ~1hour, may need to do more data-quality improvements to get a realistic loss number, but I figured I'd give this a whirl.

I'm rather pleased with an initial look at the first align/misalign cycle, at least there is discernable contrast between the two states - Attachment #2. The data is normalized by MC transmission, and then sig.decimated by x512 (8**3).

Attachment 1: DQcheck.pdf
Attachment 2: initialData.pdf
14449   Tue Feb 12 18:00:32 2019 gautamSummaryLoss MeasurementLoss measurement setup

Another arm loss measurement started at 6pm.

14450   Tue Feb 12 22:59:17 2019 gautamSummaryLoss MeasurementY arm loss

Summary:

There are still several data quality issues that can be improved. I think there is little point in reading too much into this until some of the problems outlined below are fixed and we get a better measurement.

Details:

1. Mainly, we are plagued by the inability of the ASS system to get back to the good transmission levels - I haven't done a careful diagnosis of the servo, but the ITM PIT output always seems to run away. As a result, the later measurements are poor, as can be seen in Attachment #2.
2. For this reason, we can't easily sample different spot positions on the ETM.
3. Data processing:
• Download AS reflection and MC transmission DQ channels
• Take their ratio
• Downsample to 4 Hz by repeated application of scipy.signal.decimate by a factor of 8 each time, thrice, with the filtfilt option enabled
4. Attachment #1 and #2 are basically showing the same data - the former collects all locked (top left) and misaligned (top right) data segments and plots them with the corresponding TRY values in the bottom row. The second plot shows a pseudo-continuous time series (pseudo because the segments transitioning from locked to misaligned states have been excised).

As an interim fix, I'm going to try and use the Oplevs as a DC reference, and run the dither alignment from zero each time, as this prevents the runaway problem at least. Data run started at 11:20 pm.

Attachment 1: segmented.pdf
Attachment 2: consolidated.pdf
14451   Wed Feb 13 02:28:58 2019 gautamSummaryLoss MeasurementY arm loss

Attachment #1 shows estimated systematic uncertainty contributions due to

1. ITM transmission by +/- 0.01 % about the nominal value of 1.384 %
2. ETM transmission of +/- 3 ppm about the nominal value of 13.7 ppm
3. Mode matching efficiency into the cavity by +/- 5% about the nominal value of 92%.

In all the measurements so far, the ratio seems to be < 1, so this would seem to set a lower bound on the loss of ~35 ppm. The dominant source of systematic uncertainty is the 5% assumed fudge in the mode-matching

To do:

1. Account for uncertainties on modulation depths
2. To estimate if the amount of fluctuation we are seeing in the reflected signal even after normalizing by the MC transmission, get an estimate of statistical uncertainty in the reflected power due to
• Pointing jitter - is there some spec for the damped angular displacement of the TT1/TT2?
• Cavity length in-loop residual

Bottom line: I think we need to have other measurements and simultaenously analyse the data to get a more precise estimate of the loss.

Attachment 1: systUnc.pdf
14454   Thu Feb 14 21:29:24 2019 gautamSummaryLoss MeasurementInferred Y arm loss

Summary:

From the measurements I have, the Y arm loss is estimated to be 58 +/- 12 ppm. The quoted values are the median (50th percentile) and the distance to the 25th and 75th quantiles. This is significantly worse than the ~25 ppm number Johannes had determined. The data quality is questionable, so I would want to get some better data and run it through this machinery and see what number that yields. I'll try and systematically fix the ASS tomorrow and give it another shot.

Model and analysis framework:

Johannes and I have cleaned up the equations used for this calculation - while we may make more edits, the v1 of the document lives here. The crux of it is that we would like to measure the quantity $\kappa = \frac{P_L}{P_M}$, where $P_{L(M)}$ is the power reflected from the resonant cavity (just the ITM). This quantity can then be used to back out the round-trip loss in the resonant cavity, with further model parameters which are:

1. ITM and ETM power transmissivities
2. Modulation depths and mode-matching efficiency into the cavity
3. The statistical uncertainty on the measurement of the quantity $\kappa$, call it $\sigma_{\kappa}$

If we ignore the 3rd for a start, we can calculate the "expected" value of $\kappa$ as a function of the round-trip loss, for some assumed uncertainties on the above-mentioned model parameters. This is shown in the top plot in Attachment #1, and while this was generated using emcee, is consistent with the first order uncertainty propagation based result I posted in my previous elog on this subject. The actual samples of the model parameters used to generate these curves are shown in the bottom. What this is telling us is that even if we have no measurement uncertainty on $\kappa$, the systematic uncertainties are of the order of 5 ppm, for the assumed variation in model parameters.

The same machinery can be run backwards - assuming we have multiple measurements of $\kappa$, we then also have a sample variance, $\sigma_{\kappa}$. The uncertainty on the sample variance estimator is also known, and serves to quantify the prior distribution on the parameter $\sigma_{\kappa}$ for our Monte-Carlo sampling. The parameter $\sigma_{\kappa}$ itself is required to quantify the likelihood of a given set of model parameters, given our measurement. For the measurements I did this week, my best estimate of $\kappa \pm \sigma_{\kappa} = 0.995 \pm 0.005$. Plugging this in, and assuming uncorrelated gaussian uncertainties on the model parameters, I can back out the posterior distributions.

For convenience, I separate the parameters into two groups - (i) All the model parameters excluding the RT loss, and (ii) the RT loss. Attachment #2 and Attachment #3 show the priors (orange) and posteriors (black) of these quantities.

Interpretations:

1. This particular technique only gives us information about the RT loss - much less so about the other model parameters. This can be seen by the fact that the posteriors for the loss is significantly different from the prior for the loss, but not for the other parameters. Potentially, the power of the technique is improved if we throw other measurements at it, like ringdowns.
2. If we want to reach the 5 ppm uncertainty target, we need to do better both on the measurement of the DC reflection signals, and also narrow down the uncertainties on the other model parameters.

Some assumptions:

So that the experts on MC analysis can correct me wheere I'm wrong.

1. The prior distributions are truncated independent Gaussians - truncated to avoid sampling from unphysical regions (e.g. negative ITM transmission). I've not enforced the truncation analytically - i.e. I just assume a -infinity probability to samples drawn from the unphysical parts, but to be completely sure, the actual cavity equations enforce physicality independently (i.e. the MC generates a set of parameters which is input to another function, which checks for the feasibility before making an evaluation). One could argue that the priors on some of these should be different - e.g. uniform PDF for loss between some bounds? Jeffrey's prior for $\sigma_{\kappa}$?
2. How reasonable is it to assume the model parameter uncertainties are uncorrelated? For exaple, $\eta, \beta_1, \beta_2$ are all determined from the ALS-controlled cavity scan
Attachment 1: modelPerturb.pdf
Attachment 2: posterior_modelParams.pdf
Attachment 3: posterior_Loss.pdf
14463   Sun Feb 17 17:35:04 2019 gautamSummaryLoss MeasurementInferred X arm loss

Summary:

To complete the story before moving on to ALS, I decided to measure the X arm loss. It is estimated to be 20 +/- 5 ppm. This is surprising to say the least, so I'm skeptical - the camera image of the ETMX spot when locked almost certainly looks brighter than in Oct 2016, but I don't have numerical proof. But I don't see any obvious red flags in the data quality/analysis yet. If true, this suggests that the "cleaning" of the Yarm optics actually did more harm than good, and if that's true, we should attempt to identify where in the procedure the problem lies - was it in my usage of non-optical grade solvents?

Details:

1. Unlike the Y arm, the ratio $\kappa = 1.006 \pm 0.002$ is quite unambiguously greater than 1, which is already indicative of the loss being lower than for the Y arm. This is reliably repeatable over 15 datapoints at least.
2. Attachment #1 shows the spectrum of the single-bounce off ITMX beam and compares it to ITMY - there is clearly a difference, and my intuition is to suspect some scatter / clipping, but I confirmed that on the AS table, in air, there is no clipping. So maybe it's something in vacuum? But I'm not sure how to explain its absence for the ITMX reflection. I didn't check the Michelson alignment since I misaligned ITMY before locking the XARM - so maybe there's a small shift in the axis of the X arm reflection relative to the Yarm because of the BS alignment. The other possibility is clipping at the BS?
3. Attachment #2 shows the filtered time series for a short segment of the measurement. The X arm ASS is mostly well behaved, but the main thing preventing me from getting more statistics in is the familiar ETMX glitching problem, which while doesn't directly break the lock causes large swings in TRX. Given the recent experience with ETMY satellite box, I'm leaning towards blaming flaky electronics for this. If this weren't a problem, I'd run a spatial scan of ETMX, but I'm not going to attack this problem today.
4. Attachments #3 and #4 show the posterior distributions for model parameters and loss respectively.
5. Data quality checks done so far (suggestions welcome):
• Confirmed that there is no fringing from other ITM (in this case ITMY) / PRM / SRM / ETM in the single-bounce off ITMX config, by first macroscopically misaligning all these optics (the spots could be seen to move on the AS port PD, until they vanished, at some point presumably getting clipped in-vac), and then moving the optics around in PIT/YAW and looking for any effect in the fast time-series using NDScope.
• Checked for slow drifts in locked / misaligned states - looks okay.
• Checked centering on PDA520 using both o'scope plateau method and IR viewer - I believe the beam to be well centered.

Provisional conclusions:

1. The actual act of venting / pumping down doesn't have nearly as large an effect on the round-trip loss as does working in chamber - the IX and EX chambers have not been opened since the 2016 vent.
2. The solvent marks visible with the green flashlight on ETMY possibly signals the larger loss for the Y arm.
Attachment 1: DQcheck_XARM.pdf
Attachment 2: consolidated.pdf
Attachment 3: posterior_modelParams_XARM.pdf
Attachment 4: posterior_Loss_XARM.pdf
14552   Thu Apr 18 23:10:12 2019 gautamUpdateLoss MeasurementX arm misaligned

Yehonathan wanted to take some measurements for loss determination. I misaligned the X arm completely and we installed a PD on the AS table so there is no light reaching the AS55 and AS110 PDs. Yehonathan will post the detailed elog.

14568   Wed Apr 24 17:39:15 2019 YehonathanSummaryLoss MeasurementBasic analysis of loss measurement

Motivation

• Getting myself familiar with Python.
• Characterize statistical errors in the loss measurement.

Summary

​The precision of the measurement is excellent. We should move on to look for systematic errors.

In Detail

According to Johannes and Gautam (see T1700117_ReflectionLoss .pdf in Attachment 1), the loss in the cavity mirror is obtained by measuring the light reflected from the cavity when it is locked and when it is misaligned. From these two measurements and by using the known transmissions of the cavity mirrors, the roundtrip loss is extracted.

I write a Python notebook (AnalyzeLossData.ipynb in Attachment 1) extracting the raw data from the measurement file (data20190216.hdf5 in Attachment 1) analyzing the statistics of the measurement and its PSD.

Attachment 2 shows the raw data.

Attachment 3 shows the histogram of the measurement. It can be seen that the distribution is very close to being Gaussian.

The loss in the cavity pre roundtrip is measured to be 73.7+/-0.2 parts per million. The error is only due to the deviation in the PD measurement. Considering the uncertainty of the transmissions of the cavity mirrors should give a much bigger error.

Attachment 4 shows noise PSD of the PD readings. It can be seen that the noise spectrum is quite constant and there would be no big improvement by chopping the signal.

The situation might be different when the measurement is taken from the cavity lock PD where the signal is much weaker.

Attachment 1: LossMeasurementAnalysis.zip
Attachment 2: LossMeasurement_RawData.pdf
Attachment 3: LossMeasurement_Hist.pdf
Attachment 4: LossMeasurement_PSD.pdf
14733   Mon Jul 8 17:33:10 2019 KruthiUpdateLoss MeasurementOptical scattering measurements

I came across a paper (see reference) where they have used DAOPHOT, an astronomical software tool developed by NOAO, to study the point scatterers in LIGO test masses using images of varying exposure times. I'm going through the paper now. I think using this we can analyze the MC2 images and make some interesting observations.

Reference:  L.Glover et al., Optical scattering measurements and implications on thermal noise in Gravitational Wave detectors test-mass coatings Physics Letters A. 382. (2018)

14758   Mon Jul 15 03:15:24 2019 KruthiUpdateLoss MeasurementImaging scatterometer

On Friday, Koji helped me find various components required for the scatterometer setup. Like he suggested, I'll first set it up on the SP table and try it out with an usual mirror. Later on, once I know it's working, I'll move the setup to the flow bench near the south arm and measure the BRDF of a spare end test mass.

14788   Sun Jul 21 02:07:04 2019 KruthiUpdateLoss MeasurementMC2 loss map

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.

14789   Sun Jul 21 12:54:18 2019 gautamUpdateLoss MeasurementMC2 loss map

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?

 Quote: The camera server is throwing an error and is not grabbing snapshots :(
14791   Sun Jul 21 17:17:03 2019 KruthiUpdateLoss MeasurementMC2 loss map

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.

Quote:

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?

 Quote: The camera server is throwing an error and is not grabbing snapshots :(
14792   Sun Jul 21 19:27:25 2019 MilindUpdateLoss MeasurementMC2 loss map

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?

 Quote: 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.
14796   Mon Jul 22 12:57:35 2019 KruthiUpdateLoss MeasurementMC2 loss map

In my script I have used "CAM-ETMX_SNAP" only; while entering it in the elog I made a mistake, my bad!

Quote:

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?

 Quote: 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.
14815   Mon Jul 29 13:32:56 2019 gautamUpdateLoss MeasurementLoss measurement PD installed in AS path

[yehonathan, gautam]

• we placed a PDA520 photodiode in the AS beampath, so AS110 and AS55 no longer see any light.
• ITMX and ETMX were misaligned (since the plan is to measure the Y arm loss).
• The PDA520 and MC2 transmission are currently going to the Y arm ALS beat channels in the DAQ system. Unfortunately, we have no control over the whitening gains for these channels because of the c1iscaux2 situation.
14816   Mon Jul 29 19:08:55 2019 yehonathanUpdateLoss MeasurementReviving loss measurement by reflection

1. X arm is totally misaligned in order to measure the Y arm loss using the reflection method. Each measurement round consists of measuring the reflected power when the Y arm is aligned and when it is misaligned.

2. The measurement script used is /scripts/lossmap_scripts/armLoss/measureArmLoss.py. It generates a log file in the /logs folder specifying the alignment and misalignment times.

3. The data extraction script dlData.py processes the raw data in the log file and creates a hdf5 file in the /Data folder conataining the data of the measurement it self.

4. dlData.py labels the the aligned and misaligned datas incorrectly when the number of measurement is odd. I use only even number of measurements then.

5. In order to clip the chaotic transition between the aligned and misaligned states I use tDur attribute smaller than the actual sleep time used in the measurement script itself.

6. plotData.py (written by Gautam) and AnalyzeLossData.ipynb (written by me) can be used to calculate the loss and to plot some analyses (see https://nodus.ligo.caltech.edu:8081/40m/14568). They give roughly the same answer. The descripancy can be explained by the different modulation and ITM transmissions used.

7. I take a measurement of 8 repeatitions. I plot the measured reflected power alternating between the aligned and misaligned states.

I find that the reflected power is repeatable to within 1%.

This is consistent with the transmission data plotted here which is also repeatable to within 1%.

8. I take an overnight measurement of 100 repeatitions.

14825   Fri Aug 2 17:07:33 2019 yehonathan, gautamUpdateLoss Measurement

We run a loss measurement on the Y arm with 50 repetitions.

14827   Mon Aug 5 14:47:36 2019 yehonathanUpdateLoss Measurement

Summary:

I analyze the 100 reps loss measurement of the Y arm using the AnalyzeLossData.ipynb notebook.

The mean of the measured loss is ~ 100ppm and the variation between the repititions is ~ 27%.

In Detail

In the real measurement the misaligned and locked states are repeatedly switched between each other. I plot the misaligned and locked PD readings seperately over time.

There seems to be a drift that is correlated between the two readings. This is probably a drift in the power after the MC2. To verify, I plot the ratio between those readings and find no apparent drift:

The variation in the ratio is less than 1%. The loss figure, computed to be 1 minus this ratio times a big number, give a much worse variation. I plot the histogram of the loss figure at each repitition (excluding extremely bad measurements):

The mean is ~ 100ppm. And the variation is ~ 27%.

Draft   Mon Aug 5 16:28:41 2019 yehonathanUpdateLoss Measurementwhat is going on with the loss measurements ?

We hypothesize that the systematic error in the loss measurement can come from the fact that the requirement on the alignment of the cavity mirrors is not stringent enough.

We repeat the loss measurement with 50 measurements. This time we change the thresholds for the error signals of the dither-align in the measureArmLoss.py file from 0.5 to 0.3.

We repeat the analysis done before:

We plot the reflected power of the two states on top of each other:

This  time it appears there was no drift. The histogram of the loss measurement:

The mean is 104ppm and the variation is 27%.

What I notice this time is that the PD readings in the aligned and misaligned states are anti-correlated. This is also true in the previous run (where there was drift) when looking in the short time scales. I plot several time series to demonstrate:

I wonder what can cause this behaviour.

ELOG V3.1.3-