Displaying reports 54401-54420 of 84731.Go to page Start 2717 2718 2719 2720 2721 2722 2723 2724 2725 End
Reports until 16:42, Thursday 03 November 2016
H1 CAL (DetChar, SUS)
jeffrey.kissel@LIGO.ORG - posted 16:42, Thursday 03 November 2016 - last comment - 22:07, Monday 07 November 2016(31179)
Increased Amplitude of H1SUSETMY L1/L2 Temporary Calibration Lines
J. Kissel, D. Tuyenbayev

We're still not getting the IFO duty cycle to get the desired uncertainty on the single-frequency actuation strength scale factor measurement of the UIM and PUM stage and we're running out of time, so I've increased the SNR of these temporary lines by another factor of ~3 over yesterday's increase (see LHO aLOG 31108).

Oscillator       Freq (Hz)      Old Amp (ct)   New Amp (ct)
ETMY UIM          33.7           180            500
ETMY PUM          34.7            81            300

Hopefully Robert's activities tonight won't impact the ~30 Hz region of the sensitivity, and we can turn things off soon.
Images attached to this report
Comments related to this report
darkhan.tuyenbayev@LIGO.ORG - 18:18, Thursday 03 November 2016 (31183)CAL

Jeff K, Darkahn T,

We calculated actuation strengths of L1 (UIM), L2 (PUM) and L3 (TST) actuation stages using calibration lines from 6 lock stretches in the last two days.

Preliminary results are given in the attached plots. Standard deviation on estimations of AU and AP are ~1.2% and for AT is ~0.4%.

Data points were taken at GPS times with HOFT_OK_BIT = 1 (segments are listed below).

# seg    start           stop            duration
0        1162123790.0    1162124750.0    960.000
1        1162124840.0    1162125190.0    350.000
2        1162125280.0    1162125480.0    200.000
3        1162127120.0    1162129210.0    2090.000
4        1162134280.0    1162137150.0    2870.000
5        1162162170.0    1162163370.0    1200.000

Increased line amplitudes will hopefully allow us to get AU and AP actuation strengths with subpercent 1-sigma error bounds.

Images attached to this comment
darkhan.tuyenbayev@LIGO.ORG - 09:04, Monday 07 November 2016 (31275)CAL

Jeff K, Greg M, Darkhan T,

After the L1 and L2 line amplitude increase it seems that we got better uncertainties in the esitamtions of the sus. stage actuation strengths.

This time we filtered the data using the IFO range channel, we used 50 MPC as a threshold. And from the remaining data we made historams of three different time intervals. We did not yet investiage why the noise levels of the lines are different at each of these intervals. The uncertainties for A{U,P,T} are given for the least noisy interval (blue data points).

Non-image files attached to this comment
darkhan.tuyenbayev@LIGO.ORG - 22:07, Monday 07 November 2016 (31302)CAL

Jeff K, Greg M, Darkhan T,

We calculated [N/ct] actuation force factors calculated from the ~35 Hz independent L1, L2 and L3 lines:

KU = 8.012-8 +/- 3.873-10 N/ct   ( std(KU) / |KU| = 0.0048 )

KP = 6.482-10 +/- 2.748-12 N/ct   ( std(KP) / |KP| = 0.0042 )

KT = 4.253-12 +/- 1.679-14 N/ct   ( std(KT) / |KT| = 0.0039 )

During a Nov. 4 lock stretch we got a factor of 3 improvement of the standard deviations compared to the previous day (blue data points vs. green).

In most recent 2 days we got more data with longer lock stretches, which can help us to better bound the uncertainties. Analysis of this data would require including an updated DARM digital filters, the IFO response changed on Nov. 5 (see LHO alog 31201) which can bias on our calculations if not taken into account.

The outliers were removed in a following way:

- Took >= 50 MPC data and removed data points that fall outside of 2-sigma std. deviation (some large outliers were not filtered by this step);

- one more time calculated std. and mean in the remaining data points and removed 2-sigma outliers (this step helped to remove large outliers).

- The mean and 2std. of these data points were shown with black solid line and dashed lines.

The final reported mean values and standard deviations were taken from the blue data points ( GPS [1162252470, 1162271230] ), L1 and L2 data was least noisy during this period. This mean value and its std. were shown with blue solid and dashed lines.

Non-image files attached to this comment
H1 ISC
stefan.ballmer@LIGO.ORG - posted 16:36, Thursday 03 November 2016 - last comment - 12:05, Wednesday 09 November 2016(31176)
Frequency nboise at least a factor of 8 below the noise floor.

Evan, Stefan,

We re-measured the frequency noise coupling to DARM from the four sensors we have: REFL9 (in-loop), and POP9, REFL45, POP45 (all out-of-loop).

Plot 3 shows that transfer function in m/ct.  (For REFL 9, the calibration from Evan 1.5e-7W/ct, see e.g. 30286. We didn't calibrate the others in W yet.)

Plot 1 shows the projection of all 4 sensors to DARM. The fact that POP9 disagrees with the others - but is coherent with them (Plot2) suggests that what limits our sensing is not frequency noise.

Finally, Plot 4 shows the relative calibration of the four sensors for frequency noise.

The xml files are in

/ligo/home/controls/sballmer/20161103/FreqNoiseProjection.xml

/ligo/home/controls/sballmer/20161103/REFLPOPV2.xml

Also, for reference, the frequency noise injection was done between 21:36:50 and 22:02:50 UTC on Nov 03 2016.
 

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 12:05, Wednesday 09 November 2016 (31367)

Here is a frequency coupling TF calibrated into meters per hertz, using the above data.

The calibration uses the whitening gain (12 dB), the digital gain (0.36 ct/ct), the ADC gain (216 ct / 40 V), the demod gain and transimpedance (2600 V/W), and an assumed CARM plant with a dc gain of 13 mW/Hz and a pole at 0.63 Hz. The numbers for the plant come from OLTF budgeting from O1 (so these numbers are quite old and may have changed).

Images attached to this comment
H1 General
edmond.merilh@LIGO.ORG - posted 16:32, Thursday 03 November 2016 (31177)
Adjusted Fiber Polarization Y-Arm

Y arm was wrong polarization by 21%. I adjusted it down to 1%. I also tqweaked X-arm a little to ≈3%.

LHO General
patrick.thomas@LIGO.ORG - posted 16:04, Thursday 03 November 2016 (31175)
Ops Day Shift Summary
TITLE: 11/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Unknown
INCOMING OPERATOR: Ed
SHIFT SUMMARY: IFO is at NLN. Robert and Matt are taking measurements at end X. The SEI config at end X and end Y are on BLEND_Quite_250_SC_useism. Robert will call when he goes to end Y to have us turn off the optical lever damping there.
LOG:

16:07 UTC Robert to LVEA to setup for tests. May increase PSL makeup air, but not enough to keep from locking.
16:38 UTC Trouble keeping PRMI locked. Starting initial alignment.
? Robert back
16:51 UTC Betsy and Jason to mid stations
17:09 UTC Initial alignment done
17:10 UTC Peter to optics lab
17:18 UTC DRMI_LOCKED. Diffracted power is low (~.6). Adjusted reference signal to bring it back to ~4.
17:54 UTC Error message: 'POPA has a large offset. ENGAGE PRC1 by hand.' Stefan looked and said the offsets are not really large so he manually reran ENGAGE_ASC_PART2. The error message went away.
18:15 UTC Stopped at REDUCE_45_MODULATION_DEPTH. Diag messages saying waiting for soft loops to converge. H1:ASC-AS90_OVER_POP90_MON is oscillating wildly.
Stefan says the limits on the check to move on are not large enough, and it is safe to do so.
18:37 UTC NLN
18:45 UTC Stefan moving spot on PRM
19:05 UTC Lockloss (Stefan?). Diffracted power came up to ~7.
19:23 UTC Lockloss from ANALOG_CARM
19:48 UTC NLN
19:59 UTC Running a2l
cd /opt/rtcds/userapps/release/isc/common/scripts/decoup
./a2l_min_LHO.py

20:06 UTC Karen cleaning in H2 electronics room

./a2l_min_PR2.py
./a2l_min_PR3.py

~20:27 UTC Restarted lock clock. One of the two python scripts had crashed after losing connection to H1:GRD-ISC_LOCK_STATE_N.
20:39 UTC The trace for LLO on the DMT range plot just disappeared.
20:54 UTC Richard to CER mezzanine to look at some grounds
21:01 UTC Kyle to mid X
21:11 UTC Joe moving forklift a few feet from OSB wall
? Richard back
21:34 UTC Noises in control room from cleaning on roof.
21:58 UTC Cleaning on roof done.
22:00 UTC Kyle back from mid X
22:03 - 22:10 SEI at end X and end Y changed to BLEND_Quite_250_SC_useism
22:12 UTC Robert to end X
22:18 UTC Jim W. restarted SEI ETMY guardian node
H1 SUS
sheila.dwyer@LIGO.ORG - posted 14:35, Thursday 03 November 2016 - last comment - 20:51, Monday 07 November 2016(31172)
ETMX bias set in guardian to be negative in low noise

A while ago we saw that negative 400 volts reduced the 60 Hz line in DARM by a factor of 2.  (30778)

We just checked again and this is still true and now the guardian will set in the guardian state low noise etmy esd.  We are doing this using the gain in the bias filter bank so that the bias choosen to mitigate charge will still be use whenever we aren't locked. 

Comments related to this report
jeffrey.kissel@LIGO.ORG - 20:51, Monday 07 November 2016 (31301)CAL, DetChar, ISC, SUS
Tagging a few extra groups to make this entry more visible. The 60 Hz harmonics are still a factor of ~2 lower. Nice discovery!
LHO VE
kyle.ryan@LIGO.ORG - posted 13:58, Thursday 03 November 2016 - last comment - 16:26, Friday 04 November 2016(31170)
60 day trend of PT140
Attached is a 60 day trend of PT140 which is a one of the new Inficon BPG402s?  IP7 and IP8 have been a steady 5000 volts for this time period.  Is this a gauge thing?  I haven't been intimate with what Gerardo, John and Chandra have learned regarding the behavior of these new wide-range Bayard-Alpert/Pirani hybrids but this slope looks "not insignificant"
Non-image files attached to this report
Comments related to this report
chandra.romel@LIGO.ORG - 18:58, Thursday 03 November 2016 (31184)
That slope looks really fishy. Are both IPs fully pumping? What does HAM6 pressure look like (also hot cathode ion gauge)? Did PT 170 and 180 flatten out after degassing?
gerardo.moreno@LIGO.ORG - 13:50, Friday 04 November 2016 (31208)

We think that the pressure increase is due to temperature, see attached.  aLOG noting temperature change.

Images attached to this comment
gerardo.moreno@LIGO.ORG - 16:26, Friday 04 November 2016 (31215)SUS

Since we are talking temperature change in the LVEA, note the vertical change on some of the optics (BS and ITMs), other are affected as well.

Images attached to this comment
H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 13:39, Thursday 03 November 2016 (31171)
PCAL Calibration at Y End

TravisS, DarkhanT, Yuki, SudarshanK

Calibration measurements for Pcal Y End was completed on 2016/10/31 (before the working standard got damaged- alog 31077). The analysis shows that the calibartion is consistent with the past results. We will scrutnize the results in more detail during the Pcal Call next week.

Non-image files attached to this report
H1 CDS
patrick.thomas@LIGO.ORG - posted 13:34, Thursday 03 November 2016 - last comment - 13:35, Thursday 03 November 2016(31168)
Restarted lock clock
It appears to have crashed after losing connection to H1:GRD-ISC_LOCK_STATE_N (See attached screenshot).
Images attached to this report
Comments related to this report
patrick.thomas@LIGO.ORG - 13:35, Thursday 03 November 2016 (31169)
We were already locked when I restarted it, and it restarted at 0, so the measured time of this lock stretch will be wrong.
LHO General
patrick.thomas@LIGO.ORG - posted 13:23, Thursday 03 November 2016 - last comment - 16:36, Thursday 03 November 2016(31167)
Ops Day Mid Shift Summary
The fault in the fast shutter check appears to have been cleared for now. Unfortunately I am still not entirely certain of the mechanism by which it was resolved or if it will return.

We have been to NLN twice since. I believe Stefan broke the first lock moving the beam spot on PRM. We are currently on the second lock and I have just finished running the three a2l scripts. All three reported errors at the end:

cd /opt/rtcds/userapps/release/isc/common/scripts/decoup
./a2l_min_LHO.py

Traceback (most recent call last):
  File "./stop_osc_LHO.py", line 29, in 
    matrix.asc_ads_lo_pit[osc, optic]=0
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 300, in __setitem__
    self.put(row, col, value)
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 266, in put
    inds = list(self.__rc_iter(row, col))
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 151, in __rc_iter
    rs = [self.__rows[row]]
KeyError: 'OSC2'
a2l script done!

./a2l_min_PR2.py
Traceback (most recent call last):
  File "./stop_osc_LHO.py", line 29, in 
    matrix.asc_ads_lo_pit[osc, optic]=0
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 300, in __setitem__
    self.put(row, col, value)
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 266, in put
    inds = list(self.__rc_iter(row, col))
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 151, in __rc_iter
    rs = [self.__rows[row]]
KeyError: 'OSC2'
a2l script done!

a2l_min_PR3.py
Traceback (most recent call last):
  File "./stop_osc_LHO.py", line 29, in 
    matrix.asc_ads_lo_pit[osc, optic]=0
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 300, in __setitem__
    self.put(row, col, value)
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 266, in put
    inds = list(self.__rc_iter(row, col))
  File "/ligo/apps/linux-x86_64/cdsutils/lib/python2.7/site-packages/cdsutils/matrix.py", line 151, in __rc_iter
    rs = [self.__rows[row]]
KeyError: 'OSC2'
a2l script done!

The commissioners are in the Thursday commissioning meeting.
Comments related to this report
jenne.driggers@LIGO.ORG - 16:36, Thursday 03 November 2016 (31178)

Sorry about the a2l error message.  Everything gets set so it's okay before the thing that errored happens, but obviously you still shouldn't get errors. 

In the "stop everything" script we had the columns and rows of some matrices backwards - it ran fine for me now after fixing it, and I've checked it in.

H1 CDS (ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 12:54, Thursday 03 November 2016 - last comment - 09:18, Friday 04 November 2016(31165)
SDF Issues with SUSITMPI Model Upon Unplanned Restart Were the Cause of PI Problems; Now Resolved
J. Kissel, M. Evans, D. Barker, H. Radkins

A confusing bit of settings wrangling* after the unplanned corner station computer restarts on Tuesday (LHO aLOG 31075) in the SUSITMPI model meant that a large fraction of the EPICs records in the ITM PI system were wrong. As such, we believe this was the cause of battles with Mode 27's PI a few nights ago (LHO aLOG 31111).

In order to fix the problem, we used the hourly burt backups in
/ligo/cds/lho/h1/burt/yyyy/mm/dd/hh:mm/
to restore settings all settings to Monday (2016/10/31), before the computer restarts. 

Further, Matt performed a few spot checks on the system, and suspected it good.

*Settings wrangling:
There were several compounding problems with the SDF system which meant that 
(1) The front-end did not use the safe.snap file upon reboot, and restored bogus values
(2) The safe.snap file, which we'd thought had been kept up to date, had not been so since May.

Why?
(2) The safe.snap file for SUSITMPI used upon restart,
/opt/rtcds/lho/h1/target/h1susitmpi/h1susitmpiepics/burt/safe.snap,
is a softlink to
/opt/rtcds/userapps/release/sus/h1/burtfiles/h1susitmpi_safe.snap.
Unfortunately, *only* that model's safe.snap that had its permissions mistakenly set to a single user (coincidentally me, because I was the one who'd created the softlink from the target directory to the userapps repo.), and *not* the controls working group. That means Terra Hardwick, who had been custodian of the settings for this system, was not able to write to this file, and the settings to be restored upon computer reboot had not been updated since May 2016. Unfortunately, the only way to find out that this didn't work is to look in the log file, which lives in
/opt/rtcds/lho/h1/log/${modelname}/ioc.log
and none of us (save Dave) remember this file existed, let along looked at it before yesterday **.
There are other files made (as described in Hugh's LHO aLOG 31163), but those files are not used by the front-end upon reboot.

I've since fixed the permissions on this file, and we can now confirm that anyone can write to this file (i.e. accept & confirm DIFFs). We've also confirmed that there are no other safe.snap files that have their write permissions incorrectly restricted to a single user.

** Even worse, it looks like there's a bug in the log system -- even when we confirm that we have written to the file, the log reports a failure, e.g. 
    ***************************************************
    Wed Nov  2 16:39:10 2016 
    Save TABLE as SDF: /opt/rtcds/lho/h1/target/h1susitmpi/h1susitmpiepics/burt/safe_161102_163910.snap
    ***************************************************
    Wed Nov  2 16:39:10 2016
    ERROR Unable to set group-write on /opt/rtcds/lho/h1/target/h1susitmpi/h1susitmpiepics/burt/safe.snap - Operation not permitted
    ***************************************************
    Wed Nov  2 16:39:10 2016
    FAILED FILE SAVE /opt/rtcds/lho/h1/target/h1susitmpi/h1susitmpiepics/burt/safe.snap
    ***************************************************


(1) This is quite alarming. Dave has raised an FRS ticket (see LHO aLOG 6588) and fears it may be an RCG bug. I wish I could give you mode information on this, but I just don't know it.



In summary, we believe the issues with SUSITMPI have been resolved, but there's a good bit of scary stuff left in the SDF system. We'll be working with the CDS team to find a path forward.
Comments related to this report
keith.thorne@LIGO.ORG - 19:29, Thursday 03 November 2016 (31185)CDS
The LLO CDS system has scripts running that do regular checks on file permissions on the /opt/rtcds file system to try to catch these.  Please contact Michael Thomas for details.  We'll check that we are looking for this issue as well (and are acting when problems are found)
david.barker@LIGO.ORG - 09:18, Friday 04 November 2016 (31197)

I've opened FRS6596 to do the same snap file permissions checking as LLO.

H1 CDS
hugh.radkins@LIGO.ORG - posted 11:32, Thursday 03 November 2016 (31163)
SDF xx.snap file saving---What does it do?

More is said than is known and more is known than is true -- More likely added by other but may be of interest to all who use SDF

Not understanding what SDF was doing in certain situation led me to test a few things and report.

I looked in the HAM2 HEPI files as an example.  In the Front End Target area all files were owned by controls and writable by owner and group.  There were h1hpiham2_burt_date_time.snaps created by the FrontEnd when it cleanly shuts down.  There are also safe and OBSERVE date_time.snaps and the safe and OBSERVE.snap files that are sybolic links to the USERAPPS area.

In the USERAPPS/hpi/h1/burtfiles area there are all the h1hpi{chamber}_safe & OBSERVE.snap files.  The safe files are owned by controls and the OBSERVE files are owned by hugh.radkins; all files are writable by owner and group.

TESTS:

On the SDF TABLE medm, made a change(diff) and accepted and confirmed on that medm.  The file was updated in USERAPPS, AND, a dated snap owned by controls was created in the target area--not expected.

On the SDF_SAVE medm, selecting OVERWRITE and clicking SAVE FILE does the same thing--It does overwrite the USERAPPS snap file but it also unexpectedly creates a new dated snap in the target area.

On the SDF_SAVE medm, selecting TIME NOW and clicking SAVE FILE does what one would expect; it creates a new dated snap in the target area and does NOT update the USERAPPS snap file.

Now, I change the write permission on the {chamber}_OBSERVE.snap file in the USERAPPS area to OWNER (hugh) only.  Restart medm as controls.  When I accept and confirm a diff, it creates a new dated snap in the target area but fails to update the snap file in the USERAPPS area.  No notification of this was seen on the computer.

So if someone, logged in as themselves, attempts to accept and confirm changes with SDF, they will fail to update the USERAPPS snap file if:

*) they are not the owner and the file permissions are not group writable, or

*) they use the SDF_SAVE screen (rare for most commissioners maybe?) and do not change the FILE OPTIONS SELECTION to OVERWRITE.

Okay--gotta meeting, forgive the errors and omissions.

H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 07:32, Thursday 03 November 2016 (31161)
Owl Shift Summary

TITLE: 11/03 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC

STATE of H1: Broken?

INCOMING OPERATOR: Patrick

SHIFT SUMMARY: Earlier during the night we had issue with instability during Engage_SRC_Part2 (addressed by Sheila -- see alog31158). Later the IFO kept losing lock at Increase_Power. Since lockloss tool doesn't work I couldn't pull up the log prior to locklosses. Visually from the control signals and error signals nothing was going unstable. The lock just dropped as the power increased about the same place everytime. After the third lockloss Guardian complained about fast shutter. The test failed and I couldn't move on with the locking sequence. Richard went out to the rack and mentioned that he didn't get a good voltage reading when the shutter was opened but got okay reading when the shutter was closed. We checked GS13 to make sure that it saw the shutter motion and it did. However, the SYS channels that supposed to report shutter state and voltage didn't see anything (maybe this is why the shutter test failed?). So to my understanding the shutter is somewhat functioning. Anyway, right now it seems like the ISC_LOCK guardian is stall because of the FAST_SHUTTER guardian. I was able to make it all the way to DRMI_ASC_OFFLOAD before it refuses to move on.

 

Ops Info: On an unrelated note, violin modes have been coming back high every time after locklosses. At one point it saturated OMC DCPD. So be mindful before moving on pass DC_READOUT_TRANSITION.

Images attached to this report
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 05:27, Thursday 03 November 2016 - last comment - 06:00, Thursday 03 November 2016(31159)
Locklosses at Increase Power

There were no sign of anything going unstable. It's just dropped. I tried engaing the new PRC1 filter that Sheila removed from the Guardian as IFO goes to high power but it's still causing instability at that point.

Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 06:00, Thursday 03 November 2016 (31160)

Guardian won't move on, got a message telling me to check fast shutter trigger. The "Fast Shutter Plot" button doesn't work so I manually made some plots following alog29689 (at least one DQ channel didn't exist so I picked something close). It seems to me like the shutter did not close during the last lockloss at Increase Power. I couldn't find an alog explaining how to clear this message and make Guardian move on again. I found an instruction on how to test fast shutter on H1 Troubleshooting page. Follow the instruction by selecting LOW_ARM_POWER on LOCKLOSS_SHUTTER_CHECK guardian (had to be done manually, there's no path from SHUTTER_FAIL to LOW_ARM_POWER). Then I selected TEST_SHUTTER on FAST_SHUTTER Guardian. And got a message "Fast shutter failed tests! Do not power up!!"

I think I broke the interferometer =(

Images attached to this comment
H1 ISC
jenne.driggers@LIGO.ORG - posted 01:55, Thursday 03 November 2016 - last comment - 14:48, Thursday 03 November 2016(31157)
New a2l scripts for PR2 and PR3

I have made scripts that we can run that will adjust the a2l gains for PR2 and PR3.  These use the same a2l engine that the test mass script does, it just sets the settings for PR2 and PR3.  They can be found in the same location (just checked in): .../userapps/isc/common/scripts/decoup/a2l_min_PR*.py, where * is either 2 or 3. 

Each script has been run tonight, so we now have non-zero a2l elements for both those mirrors.

Comments related to this report
sheila.dwyer@LIGO.ORG - 03:27, Thursday 03 November 2016 (31158)

Nutsinne is having trouble relocking, with instabilities around 3.5 Hz that ring up when she engages PRC1 ASC.  We removed both the new offset from POP A pit and the new a2l from PR3, hoping that this will help. 

Stefan's offset for POP A was -0.05, Jenne's a2l coefficients were PR3_M3_DRIVEALIGN P2L 0.85 and Y2L 1.85

The problem was the new cut offs added to the PRC1 loop tonight, they seemed fine at low noise but aren't stable when the loops forst come on.  We have just removed them from the gaurdain for now.  

jenne.driggers@LIGO.ORG - 14:48, Thursday 03 November 2016 (31173)

Hmmm, odd.  Anyhow, the cutoffs now come on in LowNoiseASC rather than earlier.

H1 ISC
daniel.sigg@LIGO.ORG - posted 13:11, Wednesday 02 November 2016 - last comment - 12:55, Thursday 03 November 2016(31138)
IMC readbacks

Matt Daniel Fil (WP 6294)

The MCL and MCF readbacks have a 10/100 Hz Sallen-Key whitening stage which amplifies the high frequency spectrum to get above ADC noise. Since a while we have observed a 20-50 mHz/√Hz flat noise level in the these spectra when we are locked with the IMC only. Looking with the oscilloscope we estimated about 10m V signal between 100 kHz and 1 MHz, before the whitening. This seems too much for the AA board, so we included additional low pass filters in the readbacks with cut-offs around 15 kHz. A 15/150 kHz pole-zero was added to the Sallen-Key, and another 15 kHz pole was added to the output stage.

In detail (common mode board, IMC, s/n 1102626):

The attached spectra now show a frequency noise level which is compatible with the one observed in full lock. The coherence is also improved. The ADC noise is not too far away in regions with reduced coherence.

Non-image files attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 16:12, Wednesday 02 November 2016 (31142)

Here is a comparison between MCF fully locked and 2W IMC only (REF traces). The changes are much smaller now, indicating that MCF sees frequency noise from the laser.

evan.hall@LIGO.ORG - 12:55, Thursday 03 November 2016 (31166)

The IMC shot noise limit here should be about 1 mHz/Hz1/2, assuming 0.3 mW of light (mostly carrier) on the PD with the IMC locked, 5 mW of light on the PD with the IMC unlocked, and a modulation depth of 0.01 rad.

Non-image files attached to this comment
H1 DetChar (SEI)
hugh.radkins@LIGO.ORG - posted 12:00, Monday 31 October 2016 - last comment - 12:28, Thursday 03 November 2016(31031)
Terramon--Question for the designers

On the attached snap of the Terramon window, the second event is a largesh EQ in Middle East.  The EQ distance to H1 is 1000km shorter than the distance to L1 but the computed site velocity is 1/2 at H1 versus L1.  Is this one of those cases where the waves arrive first from opposite directions and so the crust encountered is different for the travelling surface waves?  Interesting info I'm sure everyone wants to know.  I see a similar descrepency for the G1 and V1 velocities but those waves are certainly travelling on the same direction.  Maybe it is just the local site geology being taken into account?  HunterG?  Thanks-H

Images attached to this report
Comments related to this report
hunter.gabbard@LIGO.ORG - 12:28, Thursday 03 November 2016 (31164)

Hey Hugh! 

Apologies for the late response. I'm going to paraphrase what Michael Coughlin told me in a recent discussion.

We have historically attributed the different behavior to the sites themselves rather than to any particular selection effect from LHO and LLOs location relative to most EQs. Amplitude as a function of EQ direction dependence would be interesting to look at, as we essentially fit it away by only taking distance into account. Might be a good summer project for someone.

--Hunter 

LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 15:13, Tuesday 25 October 2016 - last comment - 10:25, Thursday 03 November 2016(30860)
Y-End RGA Powered On

(Carlos, Richard, Gerardo)

Y-End RGA is ON.

Comments related to this report
kyle.ryan@LIGO.ORG - 11:11, Wednesday 26 October 2016 (30893)
By "on" I assume that the electronics are energized (i.e. the fan is running) but not the filament?
chandra.romel@LIGO.ORG - 10:25, Thursday 03 November 2016 (31162)
That is correct, Kyle.
Displaying reports 54401-54420 of 84731.Go to page Start 2717 2718 2719 2720 2721 2722 2723 2724 2725 End