Displaying reports 66701-66720 of 83069.Go to page Start 3332 3333 3334 3335 3336 3337 3338 3339 3340 End
Reports until 00:59, Friday 20 February 2015
H1 ISC
sheila.dwyer@LIGO.ORG - posted 00:59, Friday 20 February 2015 - last comment - 09:43, Friday 20 February 2015(16825)
IR find is better, guardian and tidal locklosses, alingment work

Dan, Sheila, Evan, Jeff, Alexa

Tonight locked many times (on RF) but didn't stay locked verry long.  We found two new lockloss causes that were relatively easy to solve:

During one of our short locks early in he evening ,  we made an attempt to align the green to the arm cavities after the DHARD WFS had come on. For the X arm the only thing we needed to do to get a good build up was move the TMS, we saw the spot move on the ITMX green camera and updated the spot positions for the green WFS (248.3 for PITCH, and 354.8 for YAW).  For the Y arm we saw that moving TMS was not good enough, we needed to also adjust QPD offsets.  We lost the lock in the middle of this process.  Note: the recycling gain tonight was low, around 25, but we think that having the green co-alinged even for this low build up would be better than our original situation.

During the earth quake we have spent some time on the new COMM IR search state that evan wrote.  We modified it, it is now 100% successful, but it can take a couple of minutes (generally under 5).  This is still faster on average than having a human do it, and we can think about something else while this is working now.  

Images attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 01:04, Friday 20 February 2015 (16826)

Here are the plots that tell the tidal story.  The offset to the {X,Y}_COMM_ERR filter banks is supposed to be updated by the TIDAL_HACK Guardian; this provides the error signal which is controlled through the SUS and ultimately offloaded to HEPI.  This offset was turned off for the X-end on Tuesday, which is why the X_COMM_ERR output is zero.  At the same time the HACK Guardian, which takes the DC component of IMC_F and writes this to the COMM_ERR offsets, was turned off, which is why the output of Y_COMM_ERR is a nonzero constant.  The Y_COMM_CTRL filter bank was happily integrating this constant off to infinity whenever the arms were locked.  HEPI was still getting some input from the SUS drives but it was, as you might expect, not helpful.

First plot is today, we lost lock because IMC_F (lower left corner) was railing at the limit of the VCO, something like >2000 counts (calibrated to kHz, so that's the 2MHz VCO range).

Second plot is the 2-hour lock from last week, when the IMC_F output was small and steady.  The low-frequency signal was being offloaded to HEPI, the COMM_ERR outputs were nonzero.

Images attached to this comment
jameson.rollins@LIGO.ORG - 09:43, Friday 20 February 2015 (16828)

It looks like the TIDAL_HACK guardian module does not define an initial request, meaning that it will come up with REQUEST = NONE, and the system won't leave the INIT state.  This is why the TIDAL_HACK node wasn't doing anything after the recent guardian restarts.

I suggest setting:

request = 'COPY_AND_PASTE'

in that module, so that when the node restarts it always goes back into the appropriate state.

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 ISC (DetChar, SEI)
jeffrey.kissel@LIGO.ORG - posted 22:46, Thursday 19 February 2015 (16823)
6.3M Earthquake in Japan takes IFO down (SEI systems survive!)
J. Kissel, S. Dwyer, D. Hoak

We were cruising along trying to align green beams to a red lock when an earthquake in Japan killed the lock. 
Interesting notes:
- There have been two EQs in the past 16 hours,
2015-02-19 13:18 UTC in Vanuatu, 6.4 M
2015-02-20 04:25 UTC in Japan, 6.3 M
- Attached is a band-limited RMS velocity of the 0.03 to 0.1 [Hz] band over the past 24 hours. This shows that, on site, the Japanese earthquake hit harder, almost 2/3rds more amplitude than the slightly stronger (at epicenter) Vanuatu quake.
- The SEI systems, HEPI and ISIs rode out the EQs without a problem. In fact, looking at the BLRMS colored performance matrices of all the ISIs, the only non-green blocks are the very lowest band, (0.03 - 0.1 [Hz]) that have gone orange (indicating the displacement is between a factor of 100-1000 larger than requirement in this frequency band). 

@DetChar -- it would be great to get ASDs and time series of lots of sensors during these two quakes and compare them against each other and "quiet" time. Note this would note just be a pull of the summary pages, 'cause I want a few averages, just around the EQ time.
(1) Check the arm length stabilization control signals: H1:ALS-[X/Y]_REFL_CTRL_OUT_DQ, roughly pre-calibrated [um] (the calibration may be off by a factor of two, and there's a minus sign between the two arms). Note that they also saturate near the limit of their range
(2) Check the GND STSs' (a) time series to *see* if they saturate, and (b) their ASDs (in displacement, preferably) to see how loud all frequency bands get. H1:ISI-GND_[ETMX,ETMY,ITMY,HAM2,HAM5]_[X,Y,Z]_DQ -- should be calibrated into 1 [nm/s] (only above ~10 [mHz], so be careful when looking at 30 [mHz] data)
(3) Check the Beam rotation sensor: H1:ISI-GND_BRS_ETMX_RY_OUT_DQ -- should be calibrated into [rad]. Good also down to ~10 [mHz]
(4) BSC ISI T240s
(5) HAM ISI GS13s
Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 16:04, Thursday 19 February 2015 (16820)
Ops Day Shift Summary
LVEA: Laser Hazard
Observation Bit: Commissioning  

07:15 Cris – Cleaning in the LVEA
08:00 - Cannot login to CR terminals – CDSFS0 had crashed. Ryan rebooted computer 
08:00 Jamie – Restarting Guardian to pick up new patches
08:15 Corey – 3IFO work in H2 Squeezer Bay 
08:18 Elli & Dave – Working around HAM6 
08:20 Filiberto – Working on PR3 OpLev
08:30 Betsy – Running TFs on SRM and SR2
08:40 Andres – In LVEA looking for tooling
08:45 Andres – Out of the LVEA
09:00 Kyle – Looking for the bolts for the HAM1 door – Prep for pump down
09:45* Kyle – Out of the LVEA
09:55 Jodi – Working at Mid-Y on 3IFO stuff
10:00* Dave & Elli – Out of the LVEA
10:00* Filiberto – Out of the LVEA
10:30* Corey out of the LVEA
12:13 Vending provider on site to stock machines
13:48 Apollo – On site to work on CDS AC units
15:35 Kyle – Going to End-X to recover tools for the HAM1 vacuum work
H1 SEI
jim.warner@LIGO.ORG - posted 15:44, Thursday 19 February 2015 (16818)
BSC feedforward issue found and fixed

I had noticed on the Detchar pages that ITMY had been doing a lot better between 1 and 10 hz than the other BSCs, so I started poking around in filters to see what was wrong. The FF filters were all the same and isolation loops all looked roughly similar. On Hugo's suggestion I looked at the L4C blend in on HEPI and the FF in on the ISI. The signals should have been exactly the same, but the ISI showed less signal at 1hz by a factor of  ~2 (first image, HEPI is red, ISI FF is blue). The only filters applied on both platforms a that point are a calibration filter and a symmetrization filter. On HEPI (second image), the calibration is just a gain (red trace), the symmetrization is a notch filter that smooths the L4C response(blue). On the ISI (third image), the calibration filter is a notch filter (red again), and the symmetrization filter is mostly flat filter that tunes the calibration filter slightly (blue trace). Either approach is fine, as the product of the cal and sym filters stays the same, (green taces on both pictures). Unfortunately, the ISI HEPI FF L4C cal and sym filters were not loaded in a consistent manner on most chambers (ITMY was done correctly, so FF worked there!). Basically the other chambers were using the blue trace on the first plot with the red filter on the second plot. This effectively cut the FF L4C signal in the region we needed it most. I've now loaded right, consistent set of filters from HEPI on the ISI FF path, so we should see a good improvement on most of the chambers in the 1-10hz region. One dof for ETMX is shown in my fourth image, blue before, red is after, I'll try to get a more complete comparison tomorrow morning. I haven't finished the doing gain matching on these chambers yet for the FF path, whcih should improve this a little more.

Images attached to this report
H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:38, Thursday 19 February 2015 (16819)
Reset Dust Monitor Alarm Levels
   I reset the dust monitor counts alarm levels to reflect the US Fed 209E cleanroom standards, as defined in T1400024. 

   For Clean-1000 (General room monitoring of LVEA and VEAs) 
       0.3 minor 2000, major 3000
       0.5 minor 750, major 1000

   For Clean-100 (Open chambers, cleanrooms with Class-A, etc.)
       0.3 minor 250, major 300
       0.5 minor 75, major 100

   The dust monitor alarm have been set to these levels. I will monitor over the next couple of weeks to see if these levels need to be adjusted.  
H1 SYS
daniel.sigg@LIGO.ORG - posted 14:59, Thursday 19 February 2015 (16817)
Commissioning calendar

In general, the 3rd ifo work can go ahead all day Tuesday and Thursday; all other days should be off completely.

Today: Concentrating on initial alignment

Friday: Schnupp length measurement (morning); Locking and alignment (afternoon)

Saturday: Schnupp length measurement

Monday: Locking and alignment

Tuesday: LSC/OMC model split; 3rd ifo work (all day)

Wednesday: Locking and alignment

Thursday: SRC length measurement; Locking and alignment; 3rd ifo work (all day)

Friday: Locking and robustness

H1 SEI
hugh.radkins@LIGO.ORG - posted 14:36, Thursday 19 February 2015 (16816)
End Stations HEPI Pump Servos switched to 1 Second SCAN & new PID Parameters--EndY still noisier than EndX

This morning at ~0025utc 19 Feb, the End Station HEPI Pump Servos were restarted with the Scan Rate reduced from 0.1 second to 1 second.  Also, the database has JeffK's 10mHz PID parameters--see 16782.  Also, EndY had the SMOO parameter but that has never been in the database, so any restart requires those to be replaced manually.  The smoothing has NOT been reloaded.

See the attached as I going to say that while things are better at both stations, EndY remains noisier than EndX and this is evident in amplitude of the Pressure data and the control signal going to the VFD.  The 24 hour plot attached clearly shows the time things were switched 23 hours ago.  But whereas Ex Pressure got quieter, EndY's got noisier, likely from the Smoothing going away.  Because the pressure signal is noisier at EndY, the drive to the VFD is larger than it is at EndX.  I predict that if there is measurable coherence with platform sensors, it will be larger at EndY.

Images attached to this report
H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 14:18, Thursday 19 February 2015 (16815)
Pcal line at 36.7 Hz and 540.7 Hz at LHO ENDY

The Pcal calibration line for the LHO END Y is set at 36.7 Hz (40 cts excitation amplitude) and 540.7 Hz (23500 cts excitation amplitude) both producing an SNR of about 20. These frequencies are in line with the agreed upon frequencies as reported in LLO alog #15870
 

H1 SUS
betsy.weaver@LIGO.ORG - posted 11:34, Thursday 19 February 2015 (16808)
SUS GRD Set Point Monitors enabled

This morning, Jamie enabled the Guardian SPM on all suspensions. There will be a new yellow bar across the bottom of the GRD screens which may point to settings that have been switched and are discrepant from what the current guardian state says they should be. The system is a work in progress so for now you can ignore this indicator while we learn what comes up in the monitor. To disable the monitoring, set ca_monitor = FALSE in the GRD of choice. Note, while we were working on this the ETMy guardian node completely froze and Jamie had to completely restart it.

H1 SUS
betsy.weaver@LIGO.ORG - posted 10:10, Thursday 19 February 2015 - last comment - 10:36, Thursday 19 February 2015(16811)
SR2 not super healthy at current IFO alignment
While taking acceptance review TFs over the last 2 days, I noticed that the SR2 Pitch TF does not look healthy when the IFO alignment bias is enabled.  (Note, acceptance TFs are usually taken with all bias offsets disabled.)  

Likely the large pitch bias plus the TF excitation is causing an earthquake stop to brush the suspension somewhere.  The first attachment is the Pitch TF taken with the full IFO requested bias enabled (P=2789, Y=759), the second attachment is with a lower Pitch bias but the same Yaw bias (P=2589, Y=759).  This could be be headache for commissioners.  I mapped out that for reduced Pitch bias between ~1500 and ~2600 the TF looks healthy.  I did not map out exactly where between ~2600-2789 it goes bad.  Indeed, the TF at the aligned state looks to have both Pitch and Yaw motion when viewed on the AS Air camera.  The bad TF seems to happen when the beam is somewhere off the top of the camera view.  Probably too close for comfort.
Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 10:21, Thursday 19 February 2015 (16812)
On the plus side, I checked the the SRM Pitch TF which is healthy at it's nominal IFO alignment setting.

The PR2 has a pretty high Yaw bias enabled (Y = 4311) so should probably be checked.

The rest (MCs, PR3, PRM, and SR3) have smaller bias offsets under 2000 so I wouldn't suspect a problem with them.
betsy.weaver@LIGO.ORG - 10:36, Thursday 19 February 2015 (16814)
Kiwamu and I checked that there is no DAQ saturation happening during the SR2 TF.  Darn.
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:29, Thursday 19 February 2015 (16807)
CDS model and DAQ restart report, Wednesday 18th February 2015

model restarts logged for Wed 18/Feb/2015
2015_02_18 14:27 h1fw1
2015_02_18 16:17 h1broadcast0
2015_02_18 20:22 h1fw1

two unexpected restarts. DAQ broadcaster restart to add channels for DMT. Conlog frequently changing channels report attached.

Non-image files attached to this report
H1 ISC
alexan.staley@LIGO.ORG - posted 23:54, Wednesday 18 February 2015 - last comment - 00:40, Thursday 19 February 2015(16805)
OMC DC DARM OLTF

Alexa, Evan, Dan

 

With the IFO locked on DC readout at 2.8W we measured a DARM OLTF for Kiwamu's calibration. The ESD linearization was OFF. The template can be found under: /ligo/home/alexan.staley/Public/DARM/. I have attached the txt file of the TF.

Images attached to this report
Non-image files attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 00:40, Thursday 19 February 2015 (16806)

We locked on DC readout at 7:43 UTC on Feb 18, 2015; however I was running a TF the entire time and caused the lockloss. So this isn't worth anyone looking into locklosses or coherences. Tonight we were also able to increase the input power to 7.8W without any trouble while on RF DARM. We did NOT transition to DC readout at this higher power because we noticed that the 13.8 Hz roll mode was rather large; when we tried damping this we ended up blowing the lock. More damping to be done... 

H1 SUS (DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 21:58, Wednesday 18 February 2015 (16803)
Top Mass Vertical and Roll Damping on the QUADs
J. Kissel, D. Hoak

We needed some more damping of the highest vertical and roll modes of the QUADs this evening using DARM as the sensor and the Top Mass (M0) as the actuator. We re-used the same parameters for ETMY vertical at 9.7305 [Hz] (see LHO aLOG 16673). We also tried commissioning some ITMX and ETMX vertical damping toying around with similar filters and gains but were ... inconsistently unsuccessful: I explored the gain and phase parameter space but was either unable to convincingly change the amplitude of the mode, or it broke the lock. 

We did however pioneer roll damping at 13.81 [Hz] on ETMY. It took us a while to find a sensor (besides DARM) that could help us identify which test mass was rolling -- but L2-stage OSEMs saw ETMY's roll mode loud and clear. Dan designed the filters to have similar affect as the vertical, 9.7 [Hz] filters with a relatively wide band pass surrounding 13.9 [Hz] in FM4, and two trial filters that add or subtract 60 degrees of phase at the 13.9 [Hz] in FM1 and FM2 respectively:
FM1  "+60deg"  zpk([0],[3.26459+i*18.5144;3.26459-i*18.5144],1,"n")gain(0.0523988)
FM2  "-60deg"  zpk([0],[1.75001+i*10.3531;1.75001-i*10.3531],1,"n")gain(0.0911865)
FM4  "bp13.9"  butter("BandPass", 4, 13.3, 14.5)gain(120, "dB")
These have been loaded into every QUAD's H1:SUS-?TM?_M0_DARM_DAMP_R bank, but only ETMY's R banks have been commissioned to the point that damping is successful and repeatable (which is the same for V as well).

We found that, for ETMY, the +60 deg filter (FM1), (and FM4, obviously), plus a negative gain (we can get as high as -200 or -300), reduces the amplitude of the mode within a minute or two while in the "DARM WFS" ISC_LOCK state, with CARM and TR CARM, DARM is on AS AIR. Also, we could only get any action with the TOP MASS coil drivers in State 1 (LP OFF, or in its highest range mode). 

----------
Directions to commission further test masses' loops:
- Check that the TOP mass coil driver is in high-range mode -- preferably *before* you're locked, so you can switch it if you're not (I broke the AS AIR, RF DARM lock when transitioning ETMY's M0 drivers from State 2 to State 1).
- Try to identify *which* test mass' mode has rung up. Vertical modes appear in M0 OSEMs if rung up particularly bad, and so far I've been able to see roll modes in L2 OSEMs.
- Start with only the band pass filter (FM4) on, and gradually increase the gain (with a 5 or 10 [sec] ramp) in the positive direction until you either get close to saturating the DAC, or you start seeing amplitude change on the mode in question. Start with a gain of 1.0, and increase by factors of 2 to 5, depending on how above you are from the normal LF and RT output signals, how close you are to DAC saturation, and how bold you feel today.
    - If you don't see any change, rotate the phase by 60 degs (i.e. turn on FM1), and increase the gain. Rinse and repeat until you see some action (+120 [deg] = negative gain, and FM2 on, +180 [deg] is negative gain, with no FM1 or FM2 on, etc. etc.)
    - If you see an amplitude increase, then flip the sign of your gain.
    - If you see an amplitude decrease, and its slow, try rotating an additional 60 [deg].
    - If you see an amplitude decrease, and it's fast, then you've won!
Notes:
- The definition of "slow" vs. "fast" is that "fast" is that the amplitude noticeably decreases between each average of a 0.1 [Hz] resolution, 70% overlap, 3 exponential overlap, log-scale ASD. "Slow" means you can see it decreasing, but you don't have the patience to wiat for another 30 minutes while it decreases enough that you're happy.
- We've had only a few data points, but we've found that ETMY vertical damping signs between using ALS DIFF for DARM, and any red on DARM. This may just have been that particularly bad day though.
Images attached to this report
Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 21:32, Wednesday 18 February 2015 (16802)
attempt at adjusting Y arm alingment

Alexa, Keita, Sheila,Elli

This morning we tried to improve the co-alingment of the green and red beams in the Y arm. We ended up adding some offsets to the Y transmon green QPDs, screen shot attached.  Elli took some photos using the pcal camera to make estimates of how centered we are on the ETMs. 

FIrst we tried to recover the alignment that we had last week durring the 8 Watt lock.  Keita noticed that the Y arm QPDs had moved significantly since that time.  We tried alingning the both TMSs using first the BOSEMs, then the baffle PD pointing.  With the WFS running to align the red to the X arm, we tried to move the test masses to restore the old positions on the QPDs.  This resulted in a very bad green alingment, we could have tried to recover this using QPD offsets and transmon pointing, but this didn't make a lot of sense so we didn't do it.  Instead we just tried to make sure the two beams were both aligned in the Y arm when the input pointing was alinged to the X arm, and MICH was well aligned.  We improved the situation compared to last night, but the co-alignment is still not great.  

Images attached to this report
H1 CAL (ISC, SUS)
kiwamu.izumi@LIGO.ORG - posted 17:49, Wednesday 18 February 2015 - last comment - 22:03, Wednesday 18 February 2015(16798)
ESD linearization increases the actuator response gain from that of non-linearized case

As mentioned in the previous alog (alog 16780), I suspected that the linearization in the ESD may not be behaving as expected.

We have been assuming that the ESD linearization does not change the actuator gain from the non-linearized case, but this turned out to be wrong according to a measurement (and analytical calculation).

It seems that either fixing this behavior in the actual system or correctly incorporating the linerization in the suspension model would reduce the discrepancy between the model and measured ESD response to a level of several 10 %.

On the other hand, I got another mystery where I am unable to explain the amount of change between the linearized and nonlinearized cases. The work continues.

 


(A single frequency measurement)

I did a quick measurement in this morning, comparing the linearized and non-linearized cases on ETMY (which was the only available ETM in this morning with the green light locked). I drove ETMY ESD at 2.261 Hz with an amplitude of 300000 cnts at L3_LOCK_L_EXC. The amplitude is set close to saturation at the DAC in order to get highest signal-to-noise ratio. The bias voltage was set to 9.5 V. There were no filters between the excitation point and the DAC. The L2P and L2Y were disabled. The oplev damping was active at the L2 stage only in pitch. The force coefficient was set to -180000 cnts in order to be identical to ETMX.

I used the green PDH control signal to monitor the displacment on the test mass. Also, since I used the green PDH signal instead of the IR locking signal this time, I was not able to get great SNR at 13 Hz which is the ferquency I have been using.

(Results)

The attachment shown below is the result.

As I switched the linerization on, the peak height at the excitation frequency increased by a factor of roughly 1.65. In addition, the 2nd harmonic peak decreased as the linearization is supposed to eliminate the nonlinear terms. The residual in the 2nd harmonic could be due to some charge on the test mass.

If this is true in ETMX as well, this will reduce the discrepancy between the suspension model and measurement down to 25% (which was previously reported to be discrepancy of a factor of 2.07 in alog 16780).

 

(Analytical calculation does not match the measurement)

On the other hand, according to my math (see the second attachment), the linerization was expected to increases the response only by a factor of 1.45 instead of 1.65. Although the difference between the two is only 13%, this still makes me think that something is not right as this calculation is relatively straightforward. Just for reference, I also attach the liearization simulink model that we use on ETMs.

If my math is correct, in order for the ESD to have the same actuator response gain, the absolute value of the force coefficient has to be the same as the bias counts at the DAC. Since we use bias voltage of 9.5 V (or 125418.4 cnts), the force coefficient should be -124518.4 cnts as well, but it was set to -1800000 cnts in reality. Since the response gain is proportional to the force coefficient, this should give us an extra increment of 1800000/124518.4 = 1.45 in the gain. I have no idea why the measurement differs from the expected.

I will repeat the measurement at some point soon when I get a chance.

Images attached to this report
Comments related to this report
rainer.weiss@LIGO.ORG - 22:03, Wednesday 18 February 2015 (16804)
The charge on the test mass is probably affecting your calibration. It would be useful
to measure the charge on all 4 of the test masses using the optical levers and excitation
of the quadrants independently. Look at Stuart Aston's and/or Borja's log entries at LLO and LHO. Also, the charge will be variable as long as the ion pumps are open to the vacuum system.
H1 SUS
keita.kawabe@LIGO.ORG - posted 17:27, Wednesday 18 February 2015 - last comment - 10:23, Thursday 19 February 2015(16801)
PR3 oplev was dead during/after the maintenance

PR3 oplev died at about Feb 17 2015 20:00:00 UTC, that's about noon local time.

The commissioners had to stop using PR3 oplev for some ASC purpose yesterday evening.

Images attached to this report
Comments related to this report
filiberto.clara@LIGO.ORG - 10:23, Thursday 19 February 2015 (16813)
I thought I had powered-on all Op Lever Whitening Chassis after my work on Tuesday. I went out this morning and powered unit back on.
Displaying reports 66701-66720 of 83069.Go to page Start 3332 3333 3334 3335 3336 3337 3338 3339 3340 End