Displaying reports 66901-66920 of 83317.Go to page Start 3342 3343 3344 3345 3346 3347 3348 3349 3350 End
Reports until 18:34, Monday 23 February 2015
H1 ISC
gabriele.vajente@LIGO.ORG - posted 18:34, Monday 23 February 2015 (16878)
Brute force coherence for Friday's good sensitivity lock

I ran my (now 3x faster) BruCo script using a lock stretch that Dan pointed to me, from last Friday (GPS time 1107840506 + 600 s). The report can be found at the following address:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1107840506/

Here is an excerpt, but yuo should definitely read the whole book:

The second bullet is indeed very strange since it seems that SRCL/PRCL contributes pretty much uniformly to the DARM background. It seems rather strange to me that sensing noie of SRCL/PRCL can couple up to those frequencies. One simple way to test it would be to add a band-stop filter at 1-2 kHz in PRCL and SRCL loops, and see if the coherence with DARM gets reduced. If not, it means that the same souce of noise contributes in a similar way to both RF signals (used for PRCL and SRCL) and DC signals at the AS port. I can imagine things like: high order modes and RF modulation amplitude noise...

Images attached to this report
H1 SUS (CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 18:17, Monday 23 February 2015 (16868)
Prep work for sending ASC to the QUADs, a.k.a. Spelunking to LLO and Checking Applicability to LHO
J. Kissel, S. Aston

As per ECR E1500090, Integration Issue 1015, and Work Permit 5069 we are preparing to copy LLO's infrastructure implementation of using AS_A_RF45_Q_PIT (i.e. the pitch signal calculated from the Q phase of the 45 [MHz] demodulated signal from the AS A WFS in HAM6, see D1200666 and T1100472) to damping the four QUAD's roll mode. 

However, we found ourselves asking many questions of the implementation, namely if blindly copying is the right thing to do, mostly because of it requiring Reflected Memory (RFM) IPC connections between the ASC model and QUAD models. We think the answer is the blindly copying is NOT the right thing to do. We think we have a better sensor that is more suitable to how the roll modes appear in the H1 ASC sensors, and we think we don't have enough IPC head room. See discussion below. 

Please tell us your thoughts on this. If we don't hear any push back by ~9a PT tomorrow morning, we're going forward with the changes to the scheme as decided below.


(1) Recently, LHO has pushed forward many different ways to *reduce* the number of ISC to ETM reflectec memory (RFM) communications:
    (a) We have split the ISC end-station models into two parts, an ALS and ISC model (LHO aLOG 16443)
    (b) We've moved the RFM connection for differential tidal control from being sent directly to the ETMs to being sent to the end-station ISC models first, and then sent to the SUS models via Dolphin PCIE. (T1400733)
    (c) Removed the SEI EX / EY computers from the RFM Loop (LHO aLOG 16775)
    (d) We will be (also tomorrow) re-distributing our corner-station LSC front end models to move the DARM path from the h1lsc.mdl to the h1omc.mdl (E1500041)
Indeed, even LLO -- though they've only found to have *intermittent* IPC errors -- is testing out a faster CPU for their LSC computer to decrease the clock cycle turn around time.
... so, for the two new ASC to ETM RFM connections that LLO has added, should we do the same thing at (2) and feed the RFM connections to the end-station ISC models, and then to the SUS via Dolphin PCIE?

Here is the current status of relevant IPC errors / clock-cycle turnaround time:
              Avg Clock Cycle   IPC Receiving   Channels                            Error Rate
             (CPU Max, [usec])    Errors?                                         [n errors/sec]
LLO  LSC           35               No    
     ASC           161              No
     ISCEX         27               No
     ISCEY         25               No
     [ALSEX]     [does not exist]  
     [ALSEY]     [does not exist]
     SUSETMX       50           Intermittent  L1:LSC-ETMX_[DARM_ERR,L_SUSETMX]         less than 1
     SUSETMY       49           Intermittent  L1:LSC-ETMY_[DARM_ERR,L_SUSETMX]         less than 1

LHO  LSC           36              Yes        H1:ALS-[X,Y]_ARM_RFM             X: 100 to 1000, Y: 1-10 
     ASC           160             Yes        H1:ALS-[X,Y]_REFL_SLOW_RFM                2048
     ISCEX         5               No
     ISCEY         5               No
     ALSEX         32              No
     ALSEY         31              No
     SUSETMX       48              Yes        H1:LSC-ETMX_[DARM_ERR,L_SUSETMX]    1 to 25, 5 to 40   
     SUSETMY       49              Yes        H1:LSC-ETMY_[DARM_ERR,L_SUSETMX]   10 to 120, 5 to 60
Reminders: 
- all of the above models are running at a sampling rate of 16384 [Hz], so they have 60 [usec] to complete their clock cycle
- all IPCs have a delay of 1 clock-cycle built in, but if all the computations do not complete, or just barely have enough time to complete, then the IPC misses the even the 1 clock-cycle and throws an error
- The RFM loops (there are separate loops for each end station) is now 
LSC -> SUSETM[X,Y] -> ISCE[X,Y] -> OAF -> ASC -> LSC
where the delay between the LSC and SUSETM[X,Y], as well as the ISCE[X,Y] and OAF, is the one-way four [km] light travel time through a glass fiber,
n * L / c = 1.5 * 3995 [m] / 3e8 [m/s] = 20 [usec]
and the delay between nodes in the same building is believed to be dt = 0.7 [usec]. This means from the LSC back to LSC delay is 
2 * n * L / c + 3 * dt = 2 * 1.5 * 3995 [m] / 3e8 [m/s] + 3 * 0.7e-6 [s] = 42 [usec].


(2) The roll coupling to specifically AS_RF45_Q_PIT is the *only* feedback sensor that's piped to the SUS. But the coupling is a dirt effect do to imperfections in the real system. What guarantee do we have that we'll have equal success with this and only this sensor? 
To help answer the question, I took a look at 5 of the more recent times when the IFO was fully locked on DC readout,
(a) 2015-02-12 07:35:56 UTC
(b) 2015-02-13 05:23:45 UTC
(c) 2015-02-21 01:53:30 UTC
(d) 2015-02-21 03:08:20 UTC, and there doesn't appear to be a pattern on where they appear. For example,
(e) 2015-02-23 09:14:31 UTC
in which the there are one of two roll modes visible in DARM: 13.18 [Hz] in (a) and (b), 13.81 [Hz] in (b), (c), (d), and (e). At these times, I've taken a 0.05 [Hz] resolution amplitude spectral density of DARM and *every* ASC channel, i.e.
AS A --  45 and 36, I and Q, PIT and YAW
AS B --  45 and 36, I and Q, PIT and YAW
REFL A --  45 and 9, I and Q, PIT and YAW
REFL B --  45 and 9, I and Q, PIT and YAW
TRX -- A and B, PIT and YAW
TRY -- A and B, PIT and YAW
POP -- A and B, PIT and YAW,
or 52 channels plus DARM, and compared the amplitude and coherence to DARM in these channels for the 5 times. For each lock stretch, when either the 13.18 [Hz] mode or the 13.81 [Hz] mode is visible, it has an amplitude of ~2e-8 [ct] in DARM. After staring at the plots for an hour or three, I've convinced myself (and Stuart) that in 4 out of the 5 lock stretches, either AS B RF45 Q PIT or YAW  is the sensor channel that sees both modes reliably *not* AS A RF 45 Q PIT. Further, observability does not preclude controllability, so it's not immediately clear which of the sensor signals will actually serve well for feedback. Finally, in the 5 lock stretches, only two of the four possible QUAD's highest roll modes have appeared. BUT I tested the hypothesis "does the lower frequency mode appear only in the TRs, and the higher in POP?" on the hunch that those two signals would be able to distinguish between an ETM roll mode or an ITM roll mode: again, I've convinced myself that the lower frequency mode (13.18 [Hz]) is only ever visible in POP -- implying its an ITM -- and the higher frequency mode is visible in the TRs -- implying it's an ETM. Maybe. 

Here's my point: if we want to be able to damp both of these modes, then just one ASC sensor isn't the right answer, and which sensor sees the mode the best is IFO dependent. 
Images attached to this report
H1 ISC
gabriele.vajente@LIGO.ORG - posted 17:36, Monday 23 February 2015 (16875)
We need an ASC loop for SRM

Comparisng two stretches of lock that Dan pointed to me (one from Friday, good stable  sensitivity, and one from last night, worse sensitivity), I find a clear non-stattonary behavior of the sensitivity, see the first two plots, which are spectrograms of ten minutes of data during each lock.

Analyzing last night's lock, I computed the band-limited RMS between 100 and 300 Hz and it indeed shows an almost regular oscillation at about 120-140 mHz. I compared this oscillation with few auxiliary channels, and found out good correlation with the SRM angular motion (third plot), and expecially with AS_RF36 WFS signals (fourth plot).

The last two plots show my usual least square fit of the BLRMS using a set of auxiliary channels:

In summary, I think we need to commission an angular control for the SRM, and it seems we have good signals from AS_RF36. The main motion is in pitch.

Images attached to this report
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:00, Monday 23 February 2015 (16873)
Daily Ops Summary

= Ops Summary =

== Morning Meeting ==

Visitors: Stuart, Gabriele, Ken, Myron. Welcome to Tumbleweed Land.

SEI (Hugh) Things seems okay. Platform survived the weekend.
SUS (Betsy) I can't hear you. Sorry :-(
ISC *silence*
CDS (Richard) Things are somewhat stable. Loading/unloading ldas racks.
Vacuum ...
 

== Activities ==

9:58 Elli and Dave to IOT2R

*Difficulty requesting MICH_DARK_LOCKED. The beam was too low and the PD wasn't picking up all the signal. Alexa adjusted SR2 - All is well (for now)*

10:49 Mitchell to Mid X
11:54 Mitchell back
12:36 Got an automated call from Hanford Emergency System saying the alarm will go off at some point...
12:40 Elli and Dave back
13:38 Myron and Ken to Mid X
15:04 Myron and Ken back

Jodi - The big truck that supposed to come move the racks is not coming today.
 

H1 PSL (PSL)
nutsinee.kijbunchoo@LIGO.ORG - posted 15:55, Monday 23 February 2015 (16872)
PSL Check
Laser Status: 
SysStat is good
Output power is 28.7 W (should be around 30 W)
FRONTEND WATCH is RED
HPO WATCH is RED

PMC:
It has been locked 1 day, 2 hr 34 minutes (should be days/weeks)
Reflected power is 2 Watts  and PowerSum = 24.4 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 0 h and 44 min (should be days/weeks)
Threshold on transmitted photo-detector PD = 0.70 V (should be 0.9V)

ISS:
The diffracted power is around 13.8% (should be 5-15%)
Last saturation event was 1 d 2 h and 4 minutes ago (should be days/weeks)
H1 PSL
edmond.merilh@LIGO.ORG - posted 15:50, Monday 23 February 2015 (16871)
PSL Chiller Water

Added 250mL of water.

H1 SEI
hugh.radkins@LIGO.ORG - posted 13:10, Monday 23 February 2015 (16870)
EndY HEPI Pump Alarm Levels opened to minimize nuisance alarms

As I logged Friday (16836,) I set the minor alarm point to +- 2psi but that is just too tight for the EndY where the pressure sensor channels are the most noisy (by 4 to 10x.)  I opened the non-alarm pressure to +-3psi.  Please note if these alarms continue.  The trends suggest that still might be just a tad too close.

H1 SEI (ISC)
hugh.radkins@LIGO.ORG - posted 12:16, Monday 23 February 2015 (16869)
HEPI trip on ETMX last night ~2210pst---ISC caused

Attached is 5 seconds of full data where the ISC sent a whole bunch (5e5nm) of LONG output to the HEPI all at once.  The fast channels (shown on HPI ISO X) triggered the HEPI watchdog and the slow channels never see a thing.  Why would ISC do such a thing?

Images attached to this report
H1 CDS
patrick.thomas@LIGO.ORG - posted 12:03, Monday 23 February 2015 (16867)
Conlog hard drives moved
Patrick T., Cyrus R.

The work described under permit 5066 is complete. No issues came up.
H1 SUS
betsy.weaver@LIGO.ORG - posted 11:52, Monday 23 February 2015 - last comment - 11:54, Monday 23 February 2015(16863)
Extra offsets on ETMx investigated

A late entry with data:  It doesn't look like the ETMx offsets that Keita (alog 16591) implemented in an attempt to decouple the large pitch of the main chain from the reaction chain was doing much.

Attached are Pitch transfer functions of the top, middle, and lower stages of the ETMx comparing various times when the large pitch bias and the Keita offsets were on and off.  Not much change in any of the configurations in any of the 3 stages of the ETMx.  Note, according to Jeff's alog 16824, the Keita offsets were all turned off last Thur night.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 11:54, Monday 23 February 2015 (16866)

Attached are TFs of the ETMx L1 and L2 stages showing the large pitch bias effect as seen by the OSEMs.

Images attached to this comment
H1 SEI
hugh.radkins@LIGO.ORG - posted 10:50, Monday 23 February 2015 (16862)
SEI Saturations: Where. Why?

After clearing all the SEI Overflows on the GDS_TP medms Friday, this morning some have and some don't report new overflows.  Where do this come from?

Okay--No Overflows reported over the weekend on:

HEPI: HAMs 2, 4 & 5, BSCs ITMY, ITMX, BS, ETMY; ISIs: HAMs 2, 4, 5, ITMY, ITMX, ETMY.

So that leaves Overflows did occur on:

HPIs HAMs 3, 6, & BSC ETMX and ISIs HAM3, HAM6, BS, & ETMX.

Okay so there is almost a complete pattern here.  The BS is the only platform that had overflows on the ISI but not on the HEPI.

So for the overflows, on the ISIs, HAM3, HAM6, ETMX and the BS have overflows on the GS13s, the L4Cs, and on the DACs.

For HEPI there are overflows on the ETMX DAC; but, strangely, while the GDS-TP Overflows (e.g.:H1:FEC-55_ACCUM_OVERFLOW) have non-zero numbers, non of the ADC or DAC accumulators show any totals on the HAM3 or HAM6 (e.g.:H1:FEC55_ADC_OVERFLOW_ACC_2_9)...

See the attached for the inconsistant circled numbers: there are overflow totals on the overflow but non on the ADCs or DAC to support where they originate.

So next, I'll try to put a reason for the Overflows: maay an earthquake or a trip (although I don't believe we had any trips.  HAM6 with the Fast Shutter may be the only platform with a valid reason for overflows.  And, why does the HAM3 and HAM6 HEPI overflows don't show from where they came.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:10, Monday 23 February 2015 (16861)
CDS model and DAQ restart report, Saturday and Sunday 21st,22nd February 2015

model restarts logged for Sat 21/Feb/2015

no restarts reported

model restarts logged for Sun 22/Feb/2015

2015_02_22 03:42 h1fw0

one unexpected restart.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 00:27, Monday 23 February 2015 - last comment - 01:36, Monday 23 February 2015(16859)
DHARD pitch loop unstable, op lev damping turned off on ETMs

Dan, Sheila

OP Lev Damping on ETMs

We have turned the op lev damping for the ETMs off completely after the interferometer is locked.  This is now in the gaurdian.  The attached spectra show the witness sensors with oplev damping on (dashed lines) and off (solid lines).  We knew these loops were not good, but this clearly shows it.  The bottom right plot shows the DHARD WFS error signal with the oplev damping on and off.  

DHARD WFS

The DHARD loop, which was designed based on measurements made at a carm offset of about 50 picometers with high op lev damping gain (see alog 16501 comment) , needs to be redesigned to take into account changes in the plant on resoannce and with the op lev damping off or reduced.  The attached plots show the change in the transfer function, the first one shows the open loop gain in the situation where the loop was designed, the transfer function on resonance, and a partial measurement of the TF with oplev damping gain reduced.  You can see this loop becomes unstable, which explains why we have had to reduce the gain several times in the last few weeks.  After turning off the op lev damping, we attempted to take some measurements which could be used to design a new loop, these are shown in the last screen shot and can be found in my directory under /Alingment/DHARD_WFS_NO_OPLEV_WHITE_NOISE.xml While the cohernce is not good at some frequencies, this should be better than what we have now.  

Attachments:

1) Spectra showing that op Lev damping was imposing noise, and is now off

2) Swept sine measurements showing that DHARD PIT becomes unstable as we go on resonance and reduce Op Lev gains. 

3) swept sine measurements of DHARD Pit plants on resonance and with reduced op lev gain 

4) noise injection measurements of DHARD plant with op lev damping off.  

Images attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 01:36, Monday 23 February 2015 (16860)

Other locking notes from tonight:

 - The ETMY violin modes were higher tonight than Friday by a factor of several.  I made +/-60deg filters in the ETMY_L2_DAMP_MODE2 filter bank and toyed with the gain and phases.  With a gain of 500k and no phase shift the peak height decreased by ~20% in half an hour.  So, perhaps some progress.

 - On Friday there was some coherence above 100Hz with the OMC ASC loops while the dither was on, I installed some more aggressive butterworth rolloff filters into the dither error signal filter banks.  Also I added some poles and zeros to the POSX filter bank to counteract a somewhat poor job of plant inversion for this d.o.f.  Tonight the dither alignment was robust, but the IFO itself was quite noisy, so it's not clear whether this was a measureable improvement over Friday.

 - Progress was made on the OMC autolocker code.  The challenge here is that there is no high-frequency readback of PZT2, only the DC monitor channel is recorded at >16Hz.  There is some lag between the PZT2 output and the DC monitor readback, so while the code can find the mode (by sweeping the cavity), the voltage it expects the mode to be at isn't the same as the PZT slider value.  This needs some work, more fast DQ channels in the OMC model would be helpful.

We made it to low noise a couple of times, but the pitch motion at the AS port was so bad that the DC lock was not very stable.

H1 SEI (CDS, DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 17:22, Sunday 22 February 2015 (16857)
'Final' Change to End Station HEPI Pump Servos has Less Success at Improving Chamber Noise Performance
J. Kissel

While reducing the EPICs sampling rate, and adjusting the servo PID parameters has killed most coupling to the SEI systems at the end stations, in the DOFs that it does remain, there is still a significant amount of coherence. The table below summarizes the remaining coupling:
               Freq        Coherence
EX Z  L4Cs   0.2 - 1 [Hz]     ~0.7
      T240s  30-150 [mHz]     ~0.85
             0.2 - 1 [Hz]     ~0.7  
   
   RZ L4Cs   (none -- sensor noise limited)
      T240s  40-150 [mHz]     ~0.7

   HP L4Cs   30-180 [mHz]     ~0.85
             0.2-0.8 [Hz]     ~0.85
      T240s  (no such sensor)

EY Z  L4Cs   70-150 [mHz]     ~0.6
             0.2-0.9 [Hz]     ~0.9
      T240s  60-150 [mHz]     ~0.8
             200-450 [mHz]    ~0.9
             0.5-0.9 [Hz]     ~0.85

   HP L4Cs   20-700 [mHz]    ~0.9  
      T240s  (no such sensor)
Indeed the coupling looks strikingly like what's left over in the Beam Splitter. I wonder -- since the differential pressure is being measured by sensors right on BSC2 if the measurement of coherence is better than with the rest of the tanks in the corner. In other words, if you measure the differential pressure noise at the tank where your sensors are, you may get a better measurement of the noise coupling.

The pump pressure noise (or the ADC noise) is significantly larger in amplitude at both end stations, and it even appears as though EY isn't getting any suppression at all. Further, because the "SMOO" low-pass filter has been removed, the noise above 100 [mHz] is larger than before. Looking at the HP ASDs, you can see a clear, order of magnitude reduction in the resulting noise in the platform, but at least EY still looks largely dominated by the pump pressure noise between 0.01 and 1 [Hz]. 

Looks like there's still some commissioning to do on these end station servos. Booooo.
We'll have measure the voltage input noise on the pressure sensors like we've done with the corner station sensor, to make sure this isn't real pressure noise, and if it isn't -- this gives warrant to accelerate the development of an alternative readout system with lower noise. Further, we'll have to see why EY isn't getting any suppression at all.
Images attached to this report
Non-image files attached to this report
H1 PSL
eleanor.king@LIGO.ORG - posted 15:48, Sunday 22 February 2015 (16855)
PSL watchdog trip and recovery

Dave, Jeff, Rick, Alexa, Sheila, Elli

This morning we discovered the PSL watchdog had tripped last night aroun 9.40 UTC.  Sheila says this was not a flow error, but we don't know what caused the trip.  To recover the PSL we did the following steps:

...

-With Rick's help over the phone, we restarted PSL at 12.15 in the fiber room.  We then set about waiting an hour for the laser temperature to settle before we turned the PSL watcdogs back on.

-During this hour, we observed an oscillation build up in IMC-MC2_TRANS_SUM_OUTPUT trace.  This built up to  oscillations between 300-990 counts with a 30 sec period over the hour (see picture).  IMC_PWR_IN_OUT16 also oscillating, suggesting a problem downstream of the IMC. (We eventually fixed this by changing the H1:PSL-ISS_REFSIGNAL so that the diffracted power was around 8%.)

-We noticed BS ISI tripped at 6.41 PST and Ham3 ISI triped at 12.06 PT, so we reset these watchdogs..  Big Earthquake at 6am PST which caused the BS trip.

-At this point we turned off IMC WFS by switching H1:IMC-WFS_GAIN from 0.1 to 0, and took the IMC lock guardian from locked to down, and turned off Input 1 on IMC servo board.  We cleared the history of the IMC_ASC MC1,MC2,MC3 and PZT loops.  As it later turned out, clearing the PZT history was not helpful as clearing this hstory removed a necessary alignment offset.

-We looked at the ISS.  Diffracted pw in % ( H1:PSL-ISS_DIFFRACTION_AVG) was also spiking in a saw-toothed wave shape (see picture).  We turned off autolock and IMC input power settled down.  We reduced H1:PSL-ISS_REFSIGNAL from -2.11V to -2.07V, untill the H1:PSL-ISS_DIFFRACTION_AVG was around 8%.  Before this change the diffracted power was getting close to 0%.  This changed fixed the strange oscillations we were seeing in IMC-MC2_TRANS_SUM.

-Once the ISS was behaving again, we re-locked theIMC and turned the IMC WFS back on.  Because we had cleared the PZT history, turning on the WFS did not bring us back to full IMC power buildup.  The beams on WFS-A and WFS-B were not centered, again because the IMC PZT mirror was not correctly aligned.  We adjusted PZT H1:IMC-PZT_PIT_OFFSET ( from 2650 to 3535) and H1:IMC-PZT_YAW_OFFSET (from 5774 to 5970) to compensate for the history we cleared.   This brought the IMC-IM2_TRANS power back up to its expected value, and WFS-A and WFS_B were again centered.

...

At the end of all this, we think we have recovered the PSL and IMC alignments to where we were at the start.

 

Images attached to this report
H1 AOS
david.ottaway@LIGO.ORG - posted 00:24, Sunday 22 February 2015 - last comment - 16:42, Sunday 22 February 2015(16851)
Schnupp Asymetry Measurement
Ellie, Evan and Dave
It has been noticed that the H1 Inteferometer has a tendency to spatial mode-hope between TEMOO and TEMO1 modes whilst L1 does not have this tendency. We have been setting up to characterize the SRC cavity length and Gouy phase to see whether it differs from the design settings.

To do this we set-up the auxillary laser and improved the focusing of the light onto the high speed 1611 diode of ISCT6 on the OMC_REFl_Air periscope. As a first step we repeated the previous measurement describe in AlOG 16084 with considerably higher signal to noise. 

With a bright Michelson lock we observed the reflection maximum on the either side of the Michelson. By eyeballing this data we can see that these occurred at -790+/-10 MHz and 905 +/- 10 MHz. Assuming that these are difference because of an offset in lock. The Michelson Reflection Dip is peaked at 847 MHz +/- 7 MHz.
This corresponds to a Schnupp Asymetry = 8.9 cm +/- 1mm. A more rigorous analysis of this data will follow.


Non-image files attached to this report
Comments related to this report
eleanor.king@LIGO.ORG - 08:02, Sunday 22 February 2015 (16853)

Here is a simple parabolic fit to the data, which sets the Schnupp asymmetry to 8.7cm (with an error of +/- 0.2mm.  This error is calculated using error propagation of least-squares fitting with cross-correlation terms included, but it  seems likely this statistical analysis underrepresenting the true error.)  The upper- and lower- zero crossings are at 806MHz and 917MHz.  Last December we measured Scnipp asymmetry at 9.05cm.

Improvements to this could be made by:  -Measureing cable loss/frequency response (the beat note on IOT2R is fed to ISCT6 with a looong cable),  -Correcting for photodiode frequency response curve,  -Checking if auxiliary laser power has a frequency dependence.

Non-image files attached to this comment
eleanor.king@LIGO.ORG - 16:42, Sunday 22 February 2015 (16856)

We have removed the 1611 photodiode frequency response from the data and refitted the beat-note minima.  We calculate a revised Schnupp asymmetry of 8.9cm (with an error of 0.1mm, which was calculated using least squares fitting error propagation with cross-correlation terms included).

Non-image files attached to this comment
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 23:15, Thursday 19 February 2015 - last comment - 11:49, Monday 23 February 2015(16824)
New H1 SUS ETM safe.snaps, Removed Optical Lever Damping Toggling from SUS.py Guardian Code
J. Kissel, S. Dwyer

During the earthquake we captured new safe.snaps  for the ETMs. Note that in doing so, I brought the SUSs to "safe" by hand, then requested the guardian to go to "SAFE", and vice versa brought the sus to "ALIGNED" via guardian, then restored everything that the guardian didn't touch -- all because I finally wanted to compare what my impression of what the guardian should be doing is different from what the guardian currently does after months of neglect from me, and commissioning by others. Most notably, it DOES NOT touch any part of the locking filters, and it DID turn on BOTH degrees of freedom of optical lever damping. For the record, the safe I gathered, I turned OFF ALL euler basis output switches: LOCK, DITHER, DAMP, OL DAMP, DARM DAMP, etc. Further, I've turned OFF the large offsets installed by Keita reference in LHo aLOG 16591. Those offsets, and all the expected LOCK filter banks and optical lever Pitch damping has been turned back ON. I've committed the new safe.snap the the userapps repo.

Currently, we want optical lever damping to be either under human control or ISC guardian control, so we have commented out the lines in the INIT and ENGAGE_DAMPING states with call the function susobj.olDampOutputSwitchWrite to turn the levers ON. I've commited SUS.py to the userapps repo.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 11:49, Monday 23 February 2015 (16865)
J. Kissel, B. Weaver

The above log is a unclear regarding Keita's offsets. 

I had turned the offsets in M0 DRIVEALIGN L2L, L2P, and L2Y, as well as the R0 TEST L OFF while capturing the safe.snap and have LEFT them OFF since. Repeat: the M0 DRIVEALIGN L2L, L2P, and L2Y, as well as the R0 TEST L are now OFF and should remain OFF because they have proven to be ineffective (Betsy's posting an aLOG with the proof shortly).
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 14:02, Wednesday 11 February 2015 - last comment - 17:52, Sunday 22 February 2015(16654)
All RHs running within specifications. Passed installation acceptance testing

The attached PDFs show the resistance measurements for all RHs and the relative resistance vs time for the RHs as 1W is applied to each segment. All segments are operating within nominal parameters.

The resistances for the segments are:

Segment Resistance (Ohms)
ITMX UPPER 44.0
ITMX LOWER 42.4
ITMY UPPER 40.7
ITMY LOWER 42.5
ETMX UPPER 41.9
ETMX LOWER 41.0
ETMY UPPER 42.2
ETMY LOWER 43.6
Non-image files attached to this report
Comments related to this report
aidan.brooks@LIGO.ORG - 19:30, Wednesday 11 February 2015 (16672)

Just for reference, here is the transient thermal lens in ITMX, as measured by the HWS, from this morning's 2W RH test (~1800s of applied power).

Images attached to this comment
aidan.brooks@LIGO.ORG - 17:52, Sunday 22 February 2015 (16858)

A follow-up. The data from the RTD temperature sensors for each RH is plotted in the attaced PDF. 

The ETMY and ITMX RH RTDs are non-responsive.

Non-image files attached to this comment
Displaying reports 66901-66920 of 83317.Go to page Start 3342 3343 3344 3345 3346 3347 3348 3349 3350 End