40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 103 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  11895   Mon Dec 21 14:31:41 2015 SteveUpdatePEMRat traps set

Two mechanical and two sticdky traps were set to catch univited visitor.

Absolutely no food or food remains into inside garbage cans!!!!!!!!!!!!!!!!!!!!!!!!!

Quote:

A small rat / large mouse just ran through the control room. Ugh.

 

Attachment 1: ratsNC.jpg
ratsNC.jpg
  11894   Mon Dec 21 02:29:49 2015 ericqUpdateLSCAUX X RIN measurements

I'll finish up the beat / frequency noise parts of the diagnosis tomorrow later, but I've done some investigation of the AUX X laser RIN. 

I placed a PDA255 at one of the rejected beams from the PBS on the downstream side of the IR faraday, making sure the power didn't saturate the PD. I measured the RIN on a SR785, and simultaneously looked at the signal on a 100MHz scope. 

The RIN has a very strong dependence on the laser diode current, and no noticable dependence on the crystal temperature or the presence of the PDH modulation / temperature control cables. Here are some traces, note that "nominal" current up until recently was 2.0A. 

When adjusting the diode current, a peak beings to appear in the tens of kHz, eventually noticible in the DC power trace on the scope. The point at which this occurs is not fixed.

At all times, I saw a strong intensity fluctuation at around 380-400kHz on the scope whose amplitude fluctuated a fair amount (at least 75mVrms over Vdc=6.5V, but would often be 2 or 3 times that).

I didn't look at the frequency noise while doing this, because the WiFi at the X end was too slow, I'll do more tomorrow in the daytime. 

Attachment 1: auxXRIN.pdf
auxXRIN.pdf
  11893   Sun Dec 20 23:23:54 2015 ericqUpdateALARMRats.

A small rat / large mouse just ran through the control room. Ugh.

  11892   Fri Dec 18 17:37:04 2015 ranaUpdateLSCUncooperative AUX X

Here's how we should diagnose the EX laser:

  1. Compare IR RIN of laser out to 100 kHz with that of another similar NPRO.
  2. Look at time series of IR beat signal with a fast scope. Are there any high frequency glitches?
  3. Disconnect all of the cables to the EX laser PZT and temperature control. Does the frequency noise change?
  4. Change the temperature by +/- 1 deg to move away from mode hop regions. Remeasure RIN and frequency noise and plot.
  11891   Thu Dec 17 16:44:03 2015 gautamUpdateCDSALS Slow control MEDM screen updated
Quote:

I've not updated the MEDM screens to reflect the two new paths yet, but will do so soon. It also remains to install appropriate filters for the servo path that takes the frequency readout as the input.

A few more related changes:

  1. The couplers that used to sit on the green beat PDs on the PSL table have now been shifted to the IR broadband PDs in the FOL box so that I can get the IR beat frequency over to the frequency counters. The FOL box itself, along with the fibers that bring IR light to the PSL table, have been relocated to the corner of the PSL table where the green beat PDs sit because of cable length constraints.
  2. I've updated the ALS slow control MEDM screen to allow for slow control of the beat frequency. The servo shape for now is essentially just an integrator with a zero at 1 Hz. The idea is to set an offset in the new filter module, which is the desired beat frequency, and let the integrator maintain this beat frequency. One thing I've not taken care of yet is automatically turning this loop off when the IMC loses lock. Screenshot of the modified MEDM screen is attached. 
  3. I checked the performance by using the temperature sliders to introduce an offset. The integrator is able to bring the beat frequency back to the setpoint in a few seconds, provided the step I introduced was not two big (~20 counts, but this is a pretty large shift in beat frequency, nearly 20MHz).

To do:

  1. Figure out how to deal with the IMC losing lock. I guess this is important if we want to use the IR beatnote as a diagnostic for the state of the X AUX laser.
  2. Optimize the servo gains a little - I still see some ringing when I introduce an offset, this could be avoided...
Attachment 1: ALS_SLOW_17DEC2015.png
ALS_SLOW_17DEC2015.png
  11890   Thu Dec 17 14:02:05 2015 gautamUpdateCDSIPC channels for beat frequency control set up

I've set up two IPC channels that take the output from the digital frequency counters and send them to the end front-ends (via the RFM model). A summary of the steps I followed:

  1. Set up two Dolphin channels in C1ALS to send the output of the frequency counter blocks to C1RFM (I initially used RFM blocks for these, but eric suggested using Dolphin IPC for the ALS->RFM branch, as they're faster.. Eric's removed the redundant channel names)
  2. Set up two RFM channels in C1RFM to send the out put of the frequency counter blocks to C1SCX/Y (along with CDS monitor points to monitor the error rate and a filter module between the ALS->RFM and RFM->SCX/Y IPC blocks - I just followed what seemed to be the convention in the RFM model).
  3. Set up the receiving channels in C1SCX and C1SCY
  4. Re-compiled and re-started the models in the order C1ALS, C1RFM, C1SCX and C1SCY.

I've set things up such that we can select either the "PZT IN" or the frequency counter as the input to the slow servo, via means of a EPICS variable called "FC_SWITCH" (so C1:ALS-X_FC_SWITCH or C1:ALS-Y_FC_SWITCH). If this is 0, we use the default "PZT IN" signal, while setting it to 1 will change the input to the slow servo to be the frequency readout from the digital frequency counter. I've not updated the MEDM screens to reflect the two new paths yet, but will do so soon. It also remains to install appropriate filters for the servo path that takes the frequency readout as the input.

Tangentially related to this work: I've modified the FC library block so that it outputs frequency in MHz as opposed to Hz, just for convenience..

  11889   Thu Dec 17 01:55:16 2015 ericqUpdateLSCUncooperative AUX X

[ericq, Gautam]

We were not able to fix the excess frequency noise of the AUX X laser by the usual laser diode current song and dance. Unfortunately, this level of noise is much too high to have any realistic chance of locking.  angry

We're leaving things back in the IR beat -> phase tracker state with free running AUX lasers, on the off chance that there may be anything interesting to see in the overnight data. This may be limited by our lack of automatic beatnote frequency control. (Gautam will soon implement this via digital frequency counter). I've upped the FINE_PHASE_OUT_HZ_DQ frame rate to 16k from 2k, so we can see more of the spectrum.

For the Y beat, there is the additional weird phenomenon that the beat amplitude slowly oscillates to zero over ~10 minutes, and then back up to its maximum. This makes it hard for the phase tracker servo to stay stable... I don't have a good explanation for this. 

  11888   Wed Dec 16 23:15:28 2015 ericqUpdateGreen LockingGreen beat channels temporarily set up as IR beat channels

With the IR beats going to the nominal ALS channels as Gautam left them, we're able to measure the free running frequency noise of the end AUX lasers. 

Specifically, the end shutters are closed, leaving the AUX lasers free running. The IR beats then consist of this free running light beating with the PSL light, and the ALS phase trackers give a calibrated frequency noise spectrum. I've stabilized the PSL light by locking the laser to the Y arm via MC2 acutation, so the free running AUX laser noise should dominate by a lot above the suspension resonances. This also has the benefit of giving me the use of the CAL'd Y arm displacement as a sanity check. 

At this point in time, it looks like the X laser is close to 10x noisier than the Y laser, though it does seem to be at the rule-of-thumb "10kHz/rtHz at 100Hz" level. 

Attachment 1: 2015-12-16_AUXfreerunning.pdf
2015-12-16_AUXfreerunning.pdf
  11887   Wed Dec 16 18:34:40 2015 gautamUpdateGreen LockingGreen beat channels temporarily set up as IR beat channels

Since there are a few hours to go before the locking efforts tonight, I've temporarily borrowed the channels used to read out the green beat frequency, and have hooked them up to the broadband IR PDs in the FOL box on the PSL table. I've used the network analyzer in the control room to roughly position the two beatnotes. I've also turned the green beat PDs back on (since the PSL shutter has to be open for the IR beat, and there is some green light falling on these PDs, but I've terminated the outputs).

So this needs to be switched back before locking efforts tonight...

  11886   Wed Dec 16 10:56:22 2015 gautamUpdateCDShard reboot of FB

[ericq,gautam]

Forgot to submit this yesterday...

While we were trying to get the X-arm locked to IR using MC2, frame-builder mysteriously crashed, necessitating us having to go down to the computer and perform a hard reboot (after having closed the PSL shutter and turning all the watchdogs to "shutdown"). All the models restarted by themselves, and everything seems back to normal now..

  11885   Wed Dec 16 10:22:14 2015 SteveUpdateIOOthis morning

c1sus and c1ioo were restarted. PMC locked.
 

Attachment 1: PMClocked.png
PMClocked.png
  11884   Tue Dec 15 18:08:22 2015 Max IsiUpdateGeneralSummary archive cleaning cron job

I have added a new cron job in pcdev1 at CIT using the 40m shared account. This will run the /home/40m/DetectorChar/bin/cleanarchive script one minute past midnight on the first of every month. The script removes GWsumm archive files older than 1 month old.

  11883   Tue Dec 15 11:22:53 2015 gautamUpdateCDSc1scx and c1asx crashed

I noticed what I thought was excessive movement of the beam spot on ITMX and ETMX on the control room monitors, and when I checked the CDS FE status overview MEDM screen, I saw that c1scx and c1asx had crashed. I ssh-ed into c1iscex and restarted both models, and then restarted fb as well. However, the DAQ-DCO_C1SCX_STATUS indicator remains red even after restarting fb (see attached screenshot). I am not sure how to fix this so I am leaving it as is for now, and the X arm looks to have settled down.

Attachment 1: CDS_FE_STATUS_OVERVIEW_15DEC2015.png
CDS_FE_STATUS_OVERVIEW_15DEC2015.png
  11882   Mon Dec 14 23:56:29 2015 ericqUpdateCDSc1pem reverted

To get C1PEM data back into the frames, I removed the new BLRMS blocks, recompiled, reinstalled, re-enabled it in daqd, restarted.

We still really want more headroom in our framebuilder situation. 

  11881   Mon Dec 14 23:49:03 2015 ericqUpdateOptical LeversCalibration of oplevs for ITMX/ETMX
Quote:

Based on calibration measurement I have done (elog 11785, 11831), I updated calibration factors of oplevs on medm screen as follows. Not to change loop gain oplev servo, I also changed oplev servo gain.

After making sure that the upper UGFs were properly in place, I saved these settings to the SDF files. Thanks Yutaro!

  11880   Mon Dec 14 16:46:42 2015 ericqUpdateWienerFilteringNoise Subtraction Puzzler

Here's something to ponder.

Our online MCL feedforward uses perpendicular vertex T240 seismometer signals as input. When designing a feedforward filter, whether FIR Wiener or otherwise, we posit that the PSD of the best linear subtraction one can theoretically achieve is given by the coherence, via Psub = P(1-C). 

If we have more than one witness input, but they are completely uncorrelated, then this extends to Psub = P(1-C1)(1-C2). However, in reality, there are correlations between the witnesses, which would make this an overestimate of how much noise power can be subtracted. 

Now, I present the actual MCL situation. [According to Ignacio's ELOG (11584), the online performance is not far from this offline prediction]

Somehow, we are able to subtract much more noise at ~1Hz than the coherence would lead you to believe. One suspicion of mine is that the noise at 1Hz is quite nonstationary. Using median [C/P]SDs should help with this in principle, but the above was all done with medians, and using the mean is not much different.

Thinking back to one of the metrics that Eve and Koji were talking about this summer, (std(S)/mean(S), where S is the spectrogram of the signal) gives an answer of ~2.3 at that peak at 1.4Hz, which is definitely in the nonstationary regieme, but I don't have much intution into just how severe that value is.

So, what's the point of all this? We generally use coherence as a heuristic to judge whether we should bother attempting any noise subtraction in the first place, so I'm troubled by a circumstance in which there is much more subtraction to be had than coherence leads us to believe. I would like to come up with a way of predicting MISO subtraction results of nonstationary couplings more reliably.

Attachment 1: subpuzz.pdf
subpuzz.pdf
  11879   Mon Dec 14 16:27:11 2015 gautamUpdateGreen LockingY-end AUX PDH noise breakdown

Summary:

I've attached the results from my measurements of the noise characteristics of the Y-end auxiliary PDH system.

Details:

The following spectra were measured, in the range DC-1MHz:

  1. Analyzer noise floor (measured with input terminated)
  2. Green REFL PD dark noise (measured with the Y-end green shutter closed)
  3. Mixer noise (measured with input to mixer terminated - measured with an SR560 with a gain of 100)
  4. Servo noise (measured with input to servo terminated)
  5. In loop error signal (measured with green locked to Y-arm, LSC off - using monitor point on PDH box)
  6. In loop control signal (measured with green locked to Y-arm, LSC off - using monitor point on PDH box)

In order to have good spectral resolution, the frequency range was divided into 5 subsections: DC-200Hz, 200Hz-3.4kHz, 3.4kHz-16.2kHz, 10kHz-100kHz, 100kHz-1MHz. The first three are measured using the SR785, while the last two ranges are measured with the Agilent network analyzer. The spectrum of the mixer output with its input terminated was quite close to the analyzer noise floor - hence, this was measured with an S560 preamplifier set to a gain of 100, and subsequently dividing the ASD by 100. To convert the Y-axis from V/rtHz to Hz/rtHz, I used two conversion factors: for the analyzer noise floor, PD dark noise, mixer noise and in-loop error signal, I made an Optickle simulation of a simple FP cavity (all parameters taken from the wiki optics page, except that I put in Yutaro's measured values for the arm loss and a modulation depth of 0.21 which I estimated as detailed here), and played around with the demodulation phase until I got an error signal that had the same qualitative shape as what I observed on an oscilloscope with the arms freely swinging (feedback to the laser PZT disabled). The number I finally used is 45.648 kHz/V (the main horns were 800mV peak-to-peak on an oscilloscope trace, results of the Optickle FP cavity simulation shown in Attachment #2 used to calibrate the X-axis). For the servo noise spectrum and in-loop control signal, I used the value of 2.43 MHz/V as determined here

I'm not sure what to make of the strong peaks in the mixer noise spectrum between ~60Hz and 10kHz - some of the more prominent peaks are 60Hz harmonics, but there are several peaks in between as well (these have been confusing me for some time now, they were present even when I made the measurement in this frequency range using the Agilent network analyzer. My plan is to repeat these measurements for the Xend now. 

Attachment 1: YAUX_NB_Dec2015.pdf
YAUX_NB_Dec2015.pdf
Attachment 2: PDH_errSig_Calib.pdf
PDH_errSig_Calib.pdf
  11878   Mon Dec 14 14:08:49 2015 SteveUpdateSUSRuby wire standoffs update

Two companies are willing to  make the ruby grooves and the third one is still working on their quote.

The price is ~$100 each. The cost goes down 10% if we  order 50 instead of 30 pieces.

How many should we get ?

  11877   Sun Dec 13 21:55:28 2015 gautamUpdateGreen LockingY end laser (Lightwave) PZT calibration

Summary:

After the discussions at the Wednesday meeting, I redid this measurement using a sinusoidal excitation summed at the error-point of the PDH servo as opposed to a DC offset. From the data I collected, I measured the actuator gain to be 2.43 +/- 0.04 MHz/V. This is almost half the value we expect, I'm not sure if I'm missing something obvious.


Details:

  1. Attachment #1 is a sketch of the measurement setup and points at which signals are measured/calculated. Some important changes:
    • I am now using the channel C1:ALS-Y_ERR_MON_OUT to directly measure the input signal to the servo. In order to get the calibration constant for this channel from counts to volts, I simply hooked up the input to the channel to an oscilloscope and noted the amplitude of the signal seen on the scope in volts. The number I have used is 52uV/count (note that the signal to the ADC is amplified by a factor of 10 by an SR560).
    • I measured the transfer function from the input to the servo (marked "A" in the sketch) to the output of the Pomona box going to the laser PZT (marked "B" on the sketch) using an SR785 - see Attachment #2. This allowed me to convert the amplitude of excitation at A to an amplitude at B, which is what we need, as we want to measure C/B.
  2. The measurement itself was done by locking the arms to IR, running ASS to maximize IR transmission, setting up a green beat note, and then measuring the two channels of interest with the excitation to the error-point on. 
  3. I was initially trying to use time-series plots to measure these amplitudes - Koji suggested I use the Fourier domain instead, and so I took FFTs of the two channels we are interested in (using a flat-top window with 0.1 Hz BW) and estimated the RMS values at the frequency at which I had injected an excitation. Data+code used is in Attachment #3. In particular, I was integrating the PSD over 1Hz centered at the excitation frequency in order to calculate the RMS power at the excitation frequency - it could be that for C1:ALS-BEATY_FINE_PHASE_OUT_HZ, the spectral leakage into neighbouring bins is more significant than for C1:ALS-Y_ERR_MON_OUT (see Attachment #4)?
  4. With the amplitudes thus obtained, I took the ratio C/B (see sketch) to determine the MHz/V actuator gain. I had injected excitations at 5 frequencies (916Hz, 933Hz, 977Hz, 1030Hz and 1067Hz, choses in relatively "quiet" parts of the spectrum of C1:ALS-Y_ERR_MON_OUT with no excitations), and the result reported is the average from these five measurements, while the error is the standard deviation in the 5 measurements.
  5. Unrelated to this meaurement - while I had the SR560 hooked up to the input of the PDH box, I inverted the mixer output to the servo input, as I thought I could use this method to estimate the modulation depth. I did so by locking the Y arm green to the sideband TEM00 mode, and comparing the green transmission in this state to that when the Y arm is locked to a carrier TEM00 mode. I averaged C1:ALS-TRY_OUT for 10 seconds in 3 cases: (i) Carrier TEM00, (ii)sideband TEM00, and (iii) shutter closed - from this measurement, I estimate the modulation depth to be 0.209 +/- 0.006 (errors used to calculate the total error were the standard deviations of the measured transmission). 

Next steps:

  1. Check that I have not missed out anything obvious in estimating the actuator gain - particularly the spectral leakage bit I mentioned above.
  2. If this methodology and measurement is legitimate, repeat for the X end, and complete the noise budgeting for both AUX PDH loops.
Attachment 1: IMG_5972.JPG
IMG_5972.JPG
Attachment 2: ServoY_TF_13Dec2015.pdf
ServoY_TF_13Dec2015.pdf
Attachment 3: DatanCode.zip
Attachment 4: PSD_916Hz.pdf
PSD_916Hz.pdf
  11876   Fri Dec 11 23:12:09 2015 KojiSummaryCOCLoss map measurement document

Yutaro left detailed slides for his loss map measurement

https://dcc.ligo.org/LIGO-G1501547

  11875   Fri Dec 11 16:16:36 2015 yutaroUpdateOptical LeversCalibration of oplevs for ITMX/ETMX

Based on calibration measurement I have done (elog 11785, 11831), I updated calibration factors of oplevs on medm screen as follows. Not to change loop gain oplev servo, I also changed oplev servo gain.

C1:SUS-ETMX_OL_PIT_CALIB, C1:SUS-ETMX_OL_PIT_GAIN

(45.1,16) => (200,3.5)

C1:SUS-ETMX_OL_YAW_CALIB, C1:SUS-ETMX_OL_YAW_GAIN

(85.6,8) => (222,3.0) 

C1:SUS-ETMY_OL_PIT_CALIB, C1:SUS-ETMY_OL_PIT_GAIN

(26,-16) => (140,-3.0) 

C1:SUS-ETMY_OL_YAW_CALIB, C1:SUS-ETMY_OL_YAW_GAIN

(31,-21) => (143,-4.5) 

C1:SUS-ITMX_OL_PIT_CALIB, C1:SUS-ITMX_OL_PIT_GAIN

(110,8) => (122,7.2) 

C1:SUS-ITMX_OL_YAW_CALIB, C1:SUS-ITMX_OL_YAW_GAIN

(81,-11) => (147,-6) 

C1:SUS-ITMY_OL_PIT_CALIB, C1:SUS-ITMY_OL_PIT_GAIN

(159,15) => (239,10) 

C1:SUS-ITMY_OL_YAW_CALIB, C1:SUS-ITMY_OL_YAW_GAIN

(174,-21) => (226,-16) 

 

  11874   Fri Dec 11 15:37:50 2015 yutaroUpdateLSCPower recycling gain estimation from arm loss measurement

Attached is the plot of relation between the average arm round trip loss and power recycling gain. 2 % loss due to PR3 AR reflection is taken into account.

Attachment 1: PRG_plot.png
PRG_plot.png
  11873   Fri Dec 11 13:28:36 2015 KojiUpdateLSCPower recycling gain estimation from arm loss measurement

Can I ask you to make a plot of the power recycling gain as a function of the average arm loss, indicating the current loss value?

  11872   Fri Dec 11 09:35:44 2015 yutaroUpdateLSCPower recycling gain estimation from arm loss measurement

I took PR3 AR reflectivity and calculated PRG (PR3 is flipped and so AR surface is inside PRC).

As shown in attached figure, which shows AR specification of the LaserOptik mirror (PR3 is this mirror), AR reflectivity of PR3 is ~0.5 %. Since resonant light in PRC goes through AR surface of PR3 4 times per round trip, round trip loss due to this is ~2 %. Then I got

PRG = 7.8.    

 

Attachment 1: LaserOptikAR.png
LaserOptikAR.png
  11871   Thu Dec 10 19:53:22 2015 yutaroUpdateLSCstrange behavior of ASDC

To check if the strange behavior of ASDC is caused by SR2/SR3 or not, I did the following measurement:

ASDC measures the power of the light reflected by ITMX. POXDC measures the power of the light reflected by ITMX and SRM successively. Then I varied the angle of ITMX in YAW direction and compared the behaviors of ASDC and POXDC.

The results are shown in Attachments 1-3.

As you can see in these figures, the strange up-and-down behavior appeared ONLY in ASDC. Therefore, the cause of this behavior exists between AS table and SRM (I had confirmed that the angle of SRM did not affect ASDC).

And this behavior is fringe-like, as can be seen in the figures (there seems to be 3 "peaks" and 2 "valleys"), so the cause could be interference between main path and not good AR reflection at a mirror after SRM before AS table (I suspect a mirror is flipped mistakenly).   

Attachment 1: 30.png
30.png
Attachment 2: 11.png
11.png
Attachment 3: 49.png
49.png
  11870   Thu Dec 10 12:33:04 2015 yutaroUpdateLSCstrange behavior of ASDC

I did additional tests for the strange behavior of ASCD. ETMY, ETMX and ITMY were misaligned so that only light reflected by ITMX went into AS port. I had done similar measurement before with ITMY YAW varied.

Attachment 1 shows how ASDC level changed when ITMX PIT varied.

Attachment 2 shows how ASDC level changed when ITMX YAW varied.

Attachment 3 shows how the power of light measured by a power meter just after the AS view port varied when ITMX YAW varied.

 

Comparing 1 & 2, we can say that this behavior is not unique to YAW direction.

From 2 & 3, we can say something strange is happening inside the chamber.   

 

Attachment 1: 07.png
07.png
Attachment 2: 28.png
28.png
Attachment 3: ASDC.png
ASDC.png
  11869   Wed Dec 9 23:16:13 2015 ranaUpdateComputer Scripts / ProgramsNodus security

NDS2 and the usual ports so that we can use optimus as a comsol server.

Quote:

 

I don't think there are any other ports we need open, but I could be wrong. Let me know if I broke something you need!

 

  11868   Wed Dec 9 19:01:45 2015 jamieUpdateCDSback to fb1

I spent this afternoon trying to debug fb1, with very little to show for it.  We're back to running from fb.

The first thing I did was to recompile EPICS from source, so that all the libraries needed by daqd were compiled for the system at hand.  I compiled epics-3.14-12-2_long from source, and installed it at /opt/rtapps/epics on local disk, not on the /opt/rtapps network mount.  I then recompiled daqd against that, and the framecpp, gds, etc from the LSCSoft packages.  So everything has been compiled for this version of the OS.  The compilation goes smoothly.

There are two things that I see while running this new daqd on fb1:

instability with mx_streams

The mx stream connection between the front ends and the daqd is flaky.  Everything will run fine for a while, the spontaneously one or all of the mx_stream processes on the front ends will die.  It appears more likely that all mx_stream processes will die at the same time.  It's unclear if this is some sort of chain reaction thing, or if something in daqd or in the network itself is causing them all to die at the same time.  It is independent of whether or not we're using multiple mx "end points" (i.e. a different one for each front end and separate receiver threads in the daqd) or just a single one (all front ends connecting to a single mx receiver thread in daqd).

Frequently daqd will recover from this.  The monit processes on the front ends restart the mx_stream processes and all will be recovered.  However occaissionally, possibly if the mx_streams do not recover fast enough (which seems to be related to how frequently the receiver threads in daqd can clear themselves), daqd will start to choke and will start spitting out the "empty blocks" messages that are harbirnger of doom:

Aborted 2 send requests due to remote peer 00:30:48:be:11:5d (c1iscex:0) disconnected
00:30:48:d6:11:17 (c1iscey:0) disconnected
mx_wait failed in rcvr eid=005, reqn=182; wait did not complete; status code is Remote endpoint is closed
disconnected from the sender on endpoint 005
mx_wait failed in rcvr eid=001, reqn=24; wait did not complete; status code is Remote endpoint is closed
disconnected from the sender on endpoint 001
[Wed Dec  9 18:40:14 2015] main profiler warning: 1 empty blocks in the buffer
[Wed Dec  9 18:40:15 2015] main profiler warning: 0 empty blocks in the buffer
[Wed Dec  9 18:40:16 2015] main profiler warning: 0 empty blocks in the buffer

My suspicion is that this time of failure is tied to the mx stream failures, so we should be looking at the mx connections and network to solve this problem.

frame writing troubles

There's possibly a separate issue associated with writing the second or minute trend files to disk.  With fair regularity daqd will die soon after it starts to write out the trend frames, producing the similar "empty blocks" messages.

  11867   Wed Dec 9 18:45:58 2015 KojiSummaryGeneralNetwork Topology Check

[Eric Q, Gautam, Koji]

We went through the network connections to produce the mapping of the instruments.
Gautam summarized the notes into a spread sheet. See attachments.

We didn't find any irregular connections except for the connection of NETMGR port of c1ioo to Martian Network.
This cable was removed.

Attachment 1: Network_topology_9Dec2015.xlsx
Attachment 2: Network_topology_9Dec2015.pdf
Network_topology_9Dec2015.pdf Network_topology_9Dec2015.pdf Network_topology_9Dec2015.pdf
  11866   Wed Dec 9 11:25:55 2015 SteveUpdateVACnormal RGA scan at day 435-436

Glitches are gone. Rga scan is good

 

Attachment 1: glichesGone.png
glichesGone.png
Attachment 2: d436.png
d436.png
  11865   Tue Dec 8 23:24:08 2015 gautamUpdateGreen LockingY end laser (Lightwave) PZT calibration

Summary:

I measured the PZT actuator gain for the Lightwave NPRO at the Y-end to be 3.6 +/- 0.3 MHz/V. This is somewhat lower than the value of 5 MHz/V reported here, but I think is consistent with that measurement. 

Details:

In order to calibrate the Y-axis of my Aux PDH loop noise budget plots, I wanted a measurement of the end laser actuator gain. I proceeded to measure this as follows:

  1. Use a function generator to add a DC offset to the error point - I did this by taking the output of the RF mixer -> Input A of an SR560, output of the function generator -> input B of the SR560 (via a 20 Ohm attenuator, and with a 50ohm T-eed to the input for impedance matching), and setting the output to A-B, and feeding that to the "Servo Input" on the PDH box.
  2. I then locked the arm to IR, ran the dither to maximize the green transmission, and set up a beat note at ~39 MHz with the help of the analyzer in the control room.
  3. Set phase tracker UGF, clear phase history.
  4. Vary the DC offset to the error point by using the offset on the function generator. I varied the offset until the green TEM00 lock was lost, in steps of 0.1 V. At each step, I averaged the output of the phase tracker for 15 seconds.
  5. Convert the applied DC offset to the DC offset appearing at the servo output using the transfer function of the servo box (DC gain measured to be ~65 dB), taking into account the 20dB attenuator also.

The attached plot shows the measured data. The X-axis is shown after the conversion mentioned in the last bullet point. The error bars are the standard deviations of the averaging at each DC offset. 


To do:

  1. The value of the DC gain of the servo, 65 dB, is an approximate one based on a rough measurement I did earlier today. I'll take a TF measurement with an SR785 tomorrow, but I think this shouldn't change the number too much.
  2. Upload the noise budget measurements for the Y-end PDH loop.
Attachment 1: Ycalib_8Dec.pdf
Ycalib_8Dec.pdf
  11864   Tue Dec 8 15:57:16 2015 yutaroSummaryLSCPower recycling gain estimation from arm loss measurement

I estimated power recycling gain with the results of arm loss measurement.

From elog 11818 and 11857, round trip losses including transmittivity of ETM of Y arm and X arm (let us call them T_\mathrm{loss,Y} and T_\mathrm{loss,X}) are 229+13.7=243 ppm and 483+13.7=495 ppm, respectively.

 

How I calculated:

I used the following formula.

Amplitude reflectivity of an arm cavity r_\mathrm{FP}

r_\mathrm{FP}=\sqrt{1-\frac{4T_\mathrm{ITM}T_\mathrm{loss}}{T^2_\mathrm{tot}}}   (see elog 11816)

Amplitude reflectivity of FPMI r_\mathrm{FPMI}

r_\mathrm{FPMI}=\frac{1}{2}(r_\mathrm{FP,X}+r_\mathrm{FP,Y})

With power transmittivity of PRM T_\mathrm{PRM} and amplitude reflectivity of PRM r_\mathrm{PRM}, power recycling gain is

\mathrm{PRG}=\frac{T_\mathrm{PRM}}{(1-r_\mathrm{PRM}r_\mathrm{FPMI})^2}.

 I assumed T_\mathrm{ITM}\simeq T_\mathrm{tot}=\frac{2\pi}{401}=0.01566T_\mathrm{PRM}=0.05637, and r_\mathrm{PRM}=\sqrt{1-T_\mathrm{PRM}}, and then I got

PRG = 9.8.

Since both round trip losses have relative error of ~ 4 % and PRG is proportional to inverse square of T_\mathrm{loss} up to the leading order of it, relative error of PRG can be estimated as ~ 8 %, so PRG = 9.8 +/- 0.8

 

Discussion

According to elog 11691, which says TRX and TRY level was ~125 when DRFPMI was locked, power recycling gain was \mathrm{PRG}=125\times T_\mathrm{PRM}=7.0 at the last DRFPMI lock.

Measured PRG is lower than PRG estimated here, but it is natural because various causes such as mode mismatch between PRC mode and arm cavity mode, imperfect contrast of FPMI, and so on could decrease PRG, which Eric suggested to me. 

 

Added on Dec 9

If T_\mathrm{loss,X} were as small as T_\mathrm{loss,Y}, PRG would be 16.0. PRC would be still under coupled.  

  11863   Tue Dec 8 15:40:48 2015 SteveUpdateVACglitchy RGA scan at day 434

The noise floor of the Rga scan is glitching less today

 

Attachment 1: lessGlichingToday.png
lessGlichingToday.png
  11862   Tue Dec 8 15:18:29 2015 ericqUpdateComputer Scripts / ProgramsNodus security

I've done a couple things to try and make nodus a little more secure. Some have worried that nodus may be susceptible to being drafted into a botnet, slowing down our operations. 

1. I configured the ssh server settings to disallow logins as root. Ubuntu doesn't enable the root account by default anyways, but it doesn't hurt.

2. I installed fail2ban. Function: If some IP address fails to authenticate an ssh connection 3 times, it is banned from trying to connect for 10 minutes. This is mostly for thwarting mass brute force attacks. Looking at /var/log/auth.log doesn't indicate any of this kind of thing going on in the past week, at least.

3. I set up and enabled ufw (uncomplicated firewall) to only allow incoming traffic for:

  • ssh
  • ELOG
  • Nodus apache stuff (svn, wikis, etc.)

I don't think there are any other ports we need open, but I could be wrong. Let me know if I broke something you need!

  11861   Tue Dec 8 11:24:45 2015 yutaroSummaryComputer Scripts / ProgramsScripts for loss map measurement

Here I explain usage of my scripts for loss map measurement. There are 7 script files in a same directory /opt/rtcds/caltech/c1/scripts/lossmap_scripts. With these scripts, round trip loss of an arm cavity with the beam spot on one mirror shifted to 5x5 (option: 3x3) points is measured. You can choose on which cavity you measure, the beam spot on which mirror you shift, and maximum shift of the beam spot in vertical and horizontal direction.

 

To start measurement from the beginning

Run the following command in an arbitrary directory and you will get several text files including the result of loss map measurement:

> python /opt/rtcds/caltech/c1/scripts/lossmap_scripts/lossmap.py [maximum shift in mm (PIT)] [maximum shift in mm (YAW)] [arm name (XorY)] [mirror name (E or I)]

Optionally, you can add "AUTO" at the end of the above command. Without "AUTO", you will be asked if the dithering has already settled down or not after each shift of the beam spot and you can let the scripts wait until the dithering settles down sufficiently. If you add "AUTO", it will be judged if the dithering has settled down or not according to some criteria, and the measurement will continue without your response to the terminal.

The files to be created in the current directory by the scripts are:

- lossmapETMX1-1.txt                                # [POX power (locked)] / [POX power (misaligned)]

- lossmapETMX1-2.txt                                # standard deviation of [POX power (locked)] / [POX power (misaligned)]

- lossmapETMX1-3.txt                                # TRX

- lossmapETMX1-1_converted.txt               # round trip loss (ppm) calculated from lossmapETMX1-1.txt

- lossmapETMX1-1_converted_sigma.txt     # standard deviation of round trip loss calculated from 1-1.txt and 1-2.txt

- lossmapETMX_result.txt                           # round trip loss and its error in a clear form.

The name of the files would be "lossmapITMY1-1.txt" etc. depending on which mirror you have chosen.

 

To restart measurement from a certain point

Run the following command in a directory containing "lossmap(mirror name)1-1.txt", "lossmap(mirror name)1-2.txt" and "lossmap(mirrorname)1-3.txt" which are created by previous not-completed measurement:

> python /opt/rtcds/caltech/c1/scripts/lossmap_scripts/lossmap.py [maximum shift in mm (PIT)] [maximum shift in mm (YAW)] [arm name (XorY)] [mirror name (E or I)] [restart point (PIT)] [restart point (YAW)]​ 

You can also add "AUTO".

How to designate the restart point:

Matrix elements of output of this measurement procedure are characterized by a pair of two numbers as the following shows.

   (-1,-1) ->  (-1,-0.5) ->  (-1,0) ->   (-1,0.5)  ->   (-1,1)
                                                                              v
   (-0.5,1) <- (-0.5,0.5) <- (-0.5,0) <- (-0.5,-0.5) <- (0.5,-1)
      v
   (0,-1) ->   (0,-0.5)  ->  (0,0)  ->   (0,0.5)  ->    (0,1)   
                                                                              v
   (0.5,1)  <- (0.5,0.5)  <- (0.5,0)  <- (0.5,-0.5)  <- (0.5,-1)
      v
   (1,-1) ->   (1,-0.5) ->   (1,0)  ->   (1,0.5)   ->   (1,1)

Please write the numbers that correspond to the matrix element you want to restart at. Arrows show the order of sequence of measurement. About the correspondence between the matrix elements and real position on the ETMY and ETMX, see elog 11818 and 11857, respectively. 

This script will overwrite the files (~1-1.txt etc.) so it is safer to make backup of the files before you run this script.

 

Some notes on the scripts and measurement

- Calibration has been done only for ETMs, i.e. for ITMs unit of [maximum shift] is not mm, but the values written in [maximum shift] equal to the maximum offsets added just after demodulation of ASS loop (ex. C1:ASS-YARM_ITM_PIT_L_DEMOD_I_OFFSET).

- It should be checked before doing measurement if the following parameters are correct or not.

POXzero (L47 in lossmapx.py and L52 in lossmapx_resume.py: the value of C1:LSC-POXDC_OUTPUT when no light injects into POXPD.)

POYzero (L45 in lossmapy.py and L50 in lossmapy_resume.py: the value of C1:LSC-POYDC_OUTPUT when no light injects into POYPD.)

mmr (L11 in lossmap_convert.py: (mode matching carrier power)/(total power))

Tf (L12 in lossmap_convert.py; transmittivity of ITM) 

Tetm (L13 in lossmap_convert.py: transmittivity of ETM in ppm)

- Changing n (L50 in lossmap.py) from 5 to 3, the grid points will be 3x3 changed from the default value of 5x5. If 3x3, the matrix elements are characterized by

   (-1,-1) -> (-1,0) -> (-1,1)
                                    v
   (0,1)  <-  (0,0) <-  (0,-1)   
      v
   (1,-1) ->  (1,0) ->  (1,1)  

similarly to the case of 5x5.

- You can copy the directory lossmap_scripts anywhere in controls and use it. These scripts will work as long as all the 7 scripts exist in a same directory. 

  11860   Mon Dec 7 15:56:35 2015 yutaroUpdateLSCXARM lock with ITMX actuated and related change on ASS

I changed the snapshot file for ASS, /opt/rtcds/caltech/c1/scripts/ASS_DITHER_ON.snap as follows:

L124 >  C1:ASS-XARM_ETM_PIT_GAIN 1 -5.000000000000000e-02

        => C1:ASS-XARM_ETM_PIT_GAIN 1 -1.500000000000000e-02

L128>   C1:ASS-XARM_ETM_YAW_GAIN 1 5.000000000000000e-02

        => C1:ASS-XARM_ETM_YAW_GAIN 1 1.500000000000000e-02

The purpose of this change is to avoid the oscillation when the dithering of X arm is running.

  11859   Mon Dec 7 11:25:10 2015 jamieUpdateCDSdaqd is mad
Quote:

A question to Jamie: although the new framebuilder prototype still had the same problem with trend writing, can it handle this higher testpoint/DQ channel load?

The new fb1 daqd was also crashing even without the trend writing enabled.  I'm not sure how much that's affected by the load, though, e.g. it might be able to handle the extra load fine but then die because of some other issue not related to the number of channels being acquired.

We should schedule some time this week to work on fb1 some more.

  11858   Mon Dec 7 11:17:51 2015 SteveUpdateVACnoisy RGA scan at day 433

 

Quote:

CC1 and CC2 are working again. Why did they start working  again ?

 

 

Attachment 1: 433dRGAscan.png
433dRGAscan.png
  11857   Mon Dec 7 11:11:25 2015 yutaroSummaryLSCround trip loss of X arm

On the day before yesterday and in this morning, I measured loss map of ETMX. I reported the method I used to change the beam spot on ETMX below.

Round trip loss was measured for 5 x 5 points. The result is below.

(unit: ppm)

455.4 +/- 21.1       437.1 +/- 21.8       482.3 +/- 21.8       461.6 +/- 22.5       507.9 +/- 20.1      
448.4 +/- 20.7       457.3 +/- 21.2       495.6 +/- 20.2       483.1 +/- 20.8       472.2 +/- 19.8      
436.9 +/- 19.3       444.6 +/- 19.7       483.0 +/- 19.5       474.9 +/- 20.9       498.3 +/- 18.7      
454.4 +/- 18.7       474.4 +/- 20.6       487.7 +/- 21.4       482.6 +/- 20.7       487.0 +/- 19.9      
443.7 +/- 18.6       469.9 +/- 20.2       482.8 +/- 18.7       480.9 +/- 19.5       486.1 +/- 19.2 

The correspondence between the loss shown above and the beam spot on ETMX is shown in the attached figure. In the figure, "up" and "right" indicate direction of shift of the beam spot when you watch it via the camera (ex. 455.4 ppm corresponds to the highest and rightest point in the view via the camera). 

This result is consistent withe previous result of 561.19 +/- 14.57 ppm ericq got with ASDC and reported in elog 10248 if the discussion I reported in 11819 is taken into account. Elog 11819 says in short that the strange behavior of ASDC could give us 60-70 ppm error.

The reason why the error is larger than that of the measurement for ETMY is that the noise of POX is larger than that of POY. But I am not sure to what extent the statistical error needs to be reduced.

How I shifted the beam spot on ETMX:   

Basically, the method was same as one used for Y arm. Different point is: for Y arm we have two steering mirrors TT1&2, but for X arm we have only one steering mirror BS. Then in order to shift incident beam so that the beam spot on ITMX does not change, I ran the dithering of X arm as well as that of Y arm and added offsets to both dither loops that caused same amount of shift on ETMX and ETMX. Thanks to the symmetry between X arm and Y arm, the dithering of Y arm ensured that the beam spot on ITMX was unchanged as well as that of ITMY. The idea of this method is schematically shown in Attachment 2. 

The calibration of how much the beam spot shifted is based on the results of elog 11846 . The offset was [-15,-7.5,0,7.5,15]x[-5,-2.5,0,2.5,5] for pitch and yaw, respectively.  

 

Attachment 1: image1-2.JPG
image1-2.JPG
Attachment 2: symmetry.png
symmetry.png
  11856   Mon Dec 7 10:45:21 2015 ericqUpdateCDSdaqd is mad

Since removing c1pem from the daqd master file, daqd has not crashed. I suppose we're running into the stability issue that motivated us to disable some of the other models (IOPs, RFM, etc.) during the RCG upgrade. 

A question to Jamie: although the new framebuilder prototype still had the same problem with trend writing, can it handle this higher testpoint/DQ channel load?

  11855   Mon Dec 7 10:40:09 2015 yutaroUpdateComputer Scripts / ProgramsAdded 1 line to UNFREEZE_DITHER.py

I added 1 line to one of the ASS scripts, UNFREEZE_DITHER.py like this:

L29>   ez.cawrite('C1:ASS-'+dof+'_GAIN', 0)   

The reason why I added this is: without this line, C1:ASS-'+dof+'_GAIN become larger that 1.0, which is nomial value, if you UNFREEZE DITHER when the dither is already running or C1:ASS-'+dof+'_GAIN is not 0.0.  

  11854   Mon Dec 7 00:45:28 2015 ericqUpdateCDSdaqd is mad

I glanced at the summary pages and noticed that, since Friday around when we first loaded up the new BLRMS parts, daqd has crashing very frequently (few times per hour). 

I'm going to comment out the c1pem lines from the daqd master file for tonight, and see if that helps. 

  11853   Sat Dec 5 21:57:32 2015 yutaroHowToCamerasWhen image capture does not work...

I don't know if just running "modprobe" will work or not, because I didn't try it...  When the same problem happens again, we can try just running "modprobe" first.

  11852   Sat Dec 5 21:28:33 2015 KojiHowToCamerasWhen image capture does not work...

Do we need "make" everytime? Do you mean just running "modprobe" didn't work?

  11851   Sat Dec 5 12:02:25 2015 yutaroHowToCamerasWhen image capture does not work...

Today image capture did not work again, though it had worked 3 days before. I also found that red indicator light on the front pannel of SENSORAY was not turned on, which had been turned on 3 days before (you can find SENSORAY on the floor near Pianosa). Possible reason that it did not work again was I restarted Pianosa last night. Anyway, it works now. Here I report what I did to make it work.

 

I ran thes commands in shell, following the instruction of the manual of SENSORAY 2253 (Page 5; link or you can find the manual in /users/sensoray; I put it there). 

> cd /users/sensoray/sdk_2253_1.2.2_linux

> make all

> sudo make install

> modprobe s2253

Then the red light got turned on, and image capture worked.

 

If you recieve an error like "No such file or directory: /dev/video0" at the beginning of the error message when you run image capture scripts from the medm screen, or if you notice that the red indicator light of SENSORAY is not on, this procedure could help you. 

  11850   Fri Dec 4 23:02:13 2015 yutaroUpdateLSCBeam on POX11 is possibly not centered well

[yutaro, Koji]

Now, the beam on POX11 PD is well centered and well focused.

We found out why POXDC had behaved as reported in elog 11839. There were a few reasons: the beam was not focused enough, hight of a mirror was not matched to the beam well, path of the light reflected by misaligned SRM was occasionally close to the path of POX beam.

Then, What we did is following:

- changed orientation of SRM slightly

- changed the hight of the mirror whose hight had not matched well, by changing the pedestal (hight of which mirror was changed is shown in Attachment 1.)

- put a lens with f=250 mm (where the lens is located is shown in Attachment 1.)

- refined alignment for the POX beam to hit on the center of POX11 PD.  

As a result, POX DC level behaved as shown in Attachment 2&3 when the orientation of ITMX was varied (Attachment 2: POX DC vs ITMX PIT, Attachment 3: POX DC vs ITMX YAW). 

You can see broad plateau when varied in both PIT and YAW directions, and the beam is at the center of the plateau if ITMX is aligned ideally.

 

 

Attachment 1: image1.JPG
image1.JPG
Attachment 2: 56.png
56.png
Attachment 3: 04.png
04.png
  11849   Fri Dec 4 18:20:36 2015 gautamUpdateCDSBLRMS for IMC setup

[ericq, gautam]

BLRMS filters have been set up for the coil outputs and shadow sensor signals. The signals are sent to the C1PEM model from C1MCS, where I use the library block mentioned in the previous elog to put the filters in place. Some preliminary observations:

  1. The entire operation seems to be computationally quite expensive - just for the 3 IMC mirrors, the average CPU time for C1PEM increased from ~50 usec (before any changes were made to C1PEM) to ~105 usec just as a result of installing 420 filter modules with no filter coefficients loaded (3 optics x 10 channels x 14 filter banks) to ~120 usec when all the BP and LP filters for the BLRMS blocks have been loaded and turned on (Attachment #1). Eric suggested that it may be computationally more efficient to do this without using the BLRMS library part - i.e. rather than having so many filter modules, do the RMS-ing using a piece of C code that essentially just implements the same SOS filters that FOTON generates, I will work on setting this up and checking if it makes a difference. The fact that just having empty filter modules in the model almost doubled the computation time suggests that this approach may help, but I have to think about how to implement some of the automatic checks that having a filter bank in place gives us, or if these are strictly necessary at all...
  2. While restarting the C1PEM model, we noticed that some of the optics were shaking - looking at the CPU timing signals for all the models on C1SUS revealed that both the C1SUS model and the C1MCS model were geting overclocked when C1PEM was killed (see the sharp spikes in the red and green traces in Attachment #2 - the Y scale in this plot is poor and doesnt put numbers to the overclocking, I will upload a better screenshot that Eric took once I find it). The cause is unknown.
  3. Yesterday, I noticed that when C1PEM was restarted, the states of the filter bank switches were not reverted to their states in the SDF tables. They are showing up as changes, but it is unclear why we have to manually revert them. I have also not yet added the states of the newly installed filters (BPs and LPs for the MC BLRMS blocks) to the SDF tables. 

Unrelated to this work: we cleaned up the correspondence between the accelerometer numbers and channels in the C1PEM model. Also, the 3 unused ADC blocks in C1PEM (ADC0, ADC1 and ADC2) are required and cannot be removed as the ADC blocks have to be numbered sequentially and the signals needed in C1PEM come from ADC3 (as we found out when we tried recompiling the model after deleting these blocks).

Attachment 1: c1pem_timing.png
c1pem_timing.png
Attachment 2: C1SUS_overclocked.png
C1SUS_overclocked.png
  11848   Fri Dec 4 13:12:41 2015 ericqUpdateCDSc1ioo Timing Overruns Solved

I had noticed for a while that the c1ioo frontend model had much higher variability than any of the other other 16k models, and would run longer than 60us multiple times an hour. This struck me as odd, since all it does is control the WFS loops. (You can see this on the Nov17 Summary page. (But somehow, the CDS tab seems broken since then, and I'm not sure why...))

This has happily now been solved! While poking around the model, I noticed that the MC2 transmission QPD data streams being sent over from c1mcs were using RFM blocks. This seemed weird to me, since I wasn't even aware that c1ioo had an RFM card. Since the c1sus and c1ioo frontends are both on the Dolphin network, I changed them to Dolphin blocks and voila! The cylce time now holds steady at 21usec. 


Update: I think I figured out the problem with the CDS summary pages. Looking at the .err files in /home/40m/public_html/summary/logs on the 40m LDAS account showed that C1:FEC-33_CPU_METER wasn't found in the frame files. Indeed, this channel was commented out in c1/chans/daq/C0EDCU.ini. I enabled it and restarted daqd. Hopefully the CDS tab will come back soon...

  11847   Fri Dec 4 12:33:52 2015 yutaroUpdateLSCBeam on POX11 is possibly not centered well

To focus POX beam on POX11 PD, I added an iris and a lens before POX11 PD as you can see in Attachment 1.

It seemed that the beam is well focused, but the behavior of POXDC has not changed, as shown in Attachments 2 & 3.    

Attachment 1: image1-3.JPG
image1-3.JPG
Attachment 2: 07.png
07.png
Attachment 3: 47.png
47.png
  11846   Fri Dec 4 10:18:33 2015 yutaroUpdateASSOffset in the dither loop of XARM vs beam spot shift on ETMX

As I did for YARM (elog 11779), I measured the relation between offsets added just after the demodulation of the dithering loop of XARM and beam spot shift on ETMX. Defferent from YARM, the beam spot on ITMX DOES change because only BS is used as a steering mirror (TT1&2 are used for the dithering of YARM). Instead, the beam spot on BS DOES NOT change.

This time, I measured by oplevs the angles of both ETMX and ITMX for each value of offset, and using these angles I calculated the shift of the beam spot on ETMX so that I got two independent estimations (one from ETMX oplev, and the other from ITMX oplev) as shown below. The calibration of the oplevs reported in elog 11831 is taken into account. 

The difference of two estimations comes from the error of calibration of oplevs and/or imperfect alignment, I think. 

Attachment 1: offset-angleETMXPIT.png
offset-angleETMXPIT.png
Attachment 2: offset-angleETMXYAW.png
offset-angleETMXYAW.png
ELOG V3.1.3-