Displaying reports 62641-62660 of 83146.Go to page Start 3129 3130 3131 3132 3133 3134 3135 3136 3137 End
Reports until 13:14, Monday 31 August 2015
H1 DetChar (SEI, SUS)
nutsinee.kijbunchoo@LIGO.ORG - posted 13:14, Monday 31 August 2015 (21054)
Site Anthropogenic Noise Injections Followups PartII

This is a follow-up on alog alog20541 and alog20717

I took some time to study Robert's noise injections in more details. The result attached below. Quick conclusion: Human jumps in the change room and car sudden breaks near 2k electronics building and high-bay seems to couple into DARM.

Non-image files attached to this report
H1 SEI (ISC)
hugh.radkins@LIGO.ORG - posted 12:29, Monday 31 August 2015 (21052)
Revisit Tidal Offset to HEPI Bleed down Rate reduction

re aLOG 20296, the bleed off of the tidal drive to the HEPIs tilts the platform enough to rile up the ISI T240s.  Looked at trends for the last 30 days; the bleed down rate changed from 2 to 1u/s on 6 August.

Since then there have been many lock losses where there was some tidal buildup to be bled off.  The diagonalization of the EndX HEPI must be pretty good and gives no indication of tilting the T240 much.  Unlike X, the HEPI for EndY shows some fairly substantial tilting as the build up is reduced.  See the attached for 15 minute plot of a recent Bleed off at EndY where the ~110um bleed off at 1u/s riled up the T240s more than half way to the trip point.

The EndY HEPI could use some diagonalization

Images attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 10:56, Monday 31 August 2015 (21051)
LHO HEPI Fluid Reservoirs Checked--Good

No indication that Accumulators need checking or charging.

Trends of Pump output pressures (attached) indicate no need to restart any pumps (no DC level changes pointing to cavitation.)  Yes those are actually pressures; I don't know why the trends of the L0 (corner station) don't show any more fluctuations like they do at the Ends...  No change at EndY, same daily and weekly glitches.

No further HEPI maintenance this week.

Images attached to this report
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 09:49, Monday 31 August 2015 (21050)
IR TRX and TRY QPD dark offset adjusted

Peforming some calibration measurements in the past weekend, I noticed that the red TRX and TRY QPDs had some dark offsets which were not quite cancelled. In this morning, since the interferometer was down, I adjusted the dark offset in each segment of all four qpds (ASC-X_TR_A and , and ASC-Y_TR_A and B). Subsequently I adjusted the LSC-TR offsets which receives the sum signals from these qpds -- the offsets are now zero as expected.

H1 SUS (CDS)
james.batch@LIGO.ORG - posted 09:17, Monday 31 August 2015 - last comment - 14:27, Monday 31 August 2015(21048)
Restarted models on h1sush2a to recalibrate DACs
At the request of Richard M and Nutsinee, I restarted the models on h1sush2a to force a recalibration of the 18bit DAC cards.  All cards reported successfull calibration.
Comments related to this report
evan.hall@LIGO.ORG - 14:27, Monday 31 August 2015 (21056)

The PRM/PR3 M1 OSEM problem is still present.

Images attached to this comment
H1 General
jim.warner@LIGO.ORG - posted 08:03, Monday 31 August 2015 (21047)
Shift Summary
9:00 Dan starts OMC measurements, IFO to commmissioning
11:45 Dan leaves, locking is pretty rough, not breaking at a consistent point, any where between DRMI and DC Readout. Make it to DC transition once, but guardian refuses to proceed, init takes ISC_LOCK to down
13:30 Bubba to LVEA around HAM1 out, 13:35
13:40 I start initial alignment
H1 ISC (ISC, SUS)
daniel.hoak@LIGO.ORG - posted 04:36, Monday 31 August 2015 (21046)
lockloss at 0923 UTC -- problem with SR3 is back?

Dan, Jim

The IFO was running smoothly in low-noise for almost four hours until a lockloss at 0923 UTC.  Immediately prior to the lockloss, Jim and I noticed some motion of the AS beam spot.  There were a few bursts of motion, a few minutes apart, and then we broke lock.

The first image is a 1-hour trend of the ASC-AS_C signals (channels 7 & 8).  There are some bursts of noise in ASC-AS_C_PIT, correlated with similar noise in the M3 witness sensors of the SRC optics.  SR3_WIT_P (channel 15) is the worst offender.  This is the error signal used for the cage servo.  The control signal is SR3_M2_TEST_P (channel 10), which has some excurions from the quiescent level at the time of the noise bursts.

So, it looks like something was kicking the SR3 OSEMs, and this got into the cage servo and broke the lock.  Since nothing feeds back to SR3 it must have been an internal problem.

The second plot is a 1-hour trend of the SR3 OSEMs.  M1_T2 stands out as a problem, and noise from this sensor would couple to pitch in the lower stage.  Channel 16 is the T2 VOLTMON; clearly T2 is having issues.  This is the same coil that Evan, Jeff and I had trouble with two weeks ago.  Since then, the SR3 coil driver was swapped.  The glitches don't have the same shape as the excusions back then.

Jim and I have been watching a dataviewer trend of the T2 voltmon and there are occasional large excusions that are correlated with the M3_WIT_P channel, so something is really moving.  We held the ouput from the cage servo and saw a few more glitches, so it must be coming in from the top stage damping.  We turned off the top stage damping and we *thought* we saw a few more, so it must be coming from the actuation electronics.  The problem is very intermittent and we're not totally confident in the diagnosis.

Btw the T1 voltmon is still busted.

Images attached to this report
H1 SYS (GRD, ISC, SYS)
sheila.dwyer@LIGO.ORG - posted 00:33, Monday 31 August 2015 (21044)
some preliminary ER8 pie charts

Vern asked for some of the pie charts I made for ER7 for the first weeks of ER8.  Here they are, based on data from 15:00 UTC August 17th to 15:00 UTC on the 28th, with about 40 minutes of missing data.

A few notes:

Our duty cycle is a bit worse than it was durring ER7, although there are several reasons we would expect it to have improved.  Some of the downtime can probably be explained by commsioning and calibration activities, althoug I haven't yet tried to take that into account.  It will be easier to get a clear picture of things once we start running undisturbed more. 

Images attached to this report
H1 General
travis.sadecki@LIGO.ORG - posted 00:00, Monday 31 August 2015 (21045)
OPS Eve shift summary

Windy for the first 2/3 of the shift, therefore not much success locking.  As the wind was dying down, the locking became quicker, but typically (but not limited to) losing it at SWITCH_TO_QPDS.   I have added instructions to the OPS wiki regarding turning on OMC DCPD whitening in NOMINAL_LOW_NOISE.

Activity log:

2:39 locked on DC readout for Sheila/Evan commissioning

3:24 lockloss at ENGAGE_ISS_2ND_LOOP

4:00 Dan shows up on site, starts looking into PRM and PR3 noise noted by Evan and Betsy

5:02 locked DC readout

5:11 locked NOMINAL_LOW_NOISE, Dan doing some OMC work

6:07 set to Undisturbed

H1 ISC (ISC)
daniel.hoak@LIGO.ORG - posted 23:19, Sunday 30 August 2015 (21042)
OMC alignment dither lines: high-frequency resonances in tip-tilts

Currently the OMC alignment dither lines are between 1675 and 1750Hz.  We'd like to move these lines above 2kHz to avoid polluting the analysis band of the CW searches.  Previously, when we moved the dither line frequencies from ~600Hz to ~1700Hz, we noticed there was a sign flip in the dither sensing matrix.  We expect the tip-tilt response to be flat at these high frequencies, so before moving the lines again I thought it was prudent to check what kind of resonance structure we were dealing with.

The attached plot shows transfer functions from OM1 pitch and yaw to OMC-DCPD_NORM while in full lock.  Overall the reponse of the tip-tilts is what we expect, but there are resonance features around 1900Hz and above 2.2kHz.  Also the phase changes smoothly by 180degrees between 500Hz and 1600Hz, so that explains the sign flip.  Note the dropout in coherence around the violin harmonics.  The range of the current dither frequencies is marked by the black dashed lines.

It looks like we can move the dither lines to just above 2kHz.  The phase will be a few tens of degrees different than the current frequencies, so the demod rotation phases will need to be changed.  The magnitude of the tip-tilt response is roughly the same, and anyways the current dither amplitudes are only a hundred counts, so we're well below saturation.  Should be a simple fix.

Images attached to this report
H1 SUS (CDS)
evan.hall@LIGO.ORG - posted 20:20, Sunday 30 August 2015 - last comment - 10:42, Wednesday 14 October 2015(21037)
PRM/PR3 top-stage OSEMs need attention

Betsy, Sheila, Travis, Evan

Something about the following coils appears to be unhealthy: PRM M1 RT&SD, PR3 M1 T1&T2. See attached OSEM sensor spectra.

According to Betsy, this high-frequency junk started around 2015-08-29 15:00:00 Z. On the control side, this junk dominates the rms of the PRM M1 LF drive (it is about 10000 ct).

Probably this is related to the problem that Kiwamu saw last night with PRM M1 DAMP L.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 20:34, Sunday 30 August 2015 (21038)

The first plot below is a trend of PRM DAMP L showing the start of the noise - the noise started in the middle of the lock stretch from Sat morning.  The second plot shows the 4 OSEM Sensors - it's hard to see it in any of the sensor trends, except PRM RT.

Images attached to this comment
betsy.weaver@LIGO.ORG - 20:46, Sunday 30 August 2015 (21039)

For Richard:  yes, all 4 of these noisy signals are on the same cable set and Sat box line.

daniel.hoak@LIGO.ORG - 23:02, Sunday 30 August 2015 (21041)ISC, SUS

It looks like this high-frequency noise is due to the shadow sensors.  We paused in LOCK_DRMI_1F with the PRM aligned, and turned off the top stage damping.  In this state there were no digital signals going to the coil driver (MASTER_OUTs were zero), and the NOISEMON and FAST_IMON readbacks were flat.  But the inputs from the RT and SD OSEMs had the high-frequency noise.  See attached spectra.  So, it doesn't look like it's a bad coil driver (this would have been three in as many weeks)...maybe it's an issue with the satellite box?

With the top stage damping enabled, the noise is large enough that it passes through the damping filters and shakes the M1 stage, but it's so high frequency that I don't think we are shaking the optic.  There's no sign of the noise peaks in the PRCL error signal.  No reason to think we can't run like this until Tuesday maintenance.

Images attached to this comment
carl.adams@LIGO.ORG - 10:42, Wednesday 14 October 2015 (22512)
We have seen this before at LLO back in July 2011:

https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=1262
H1 SEI (DetChar)
nairwita.mazumder@LIGO.ORG - posted 19:53, Sunday 30 August 2015 - last comment - 23:29, Wednesday 16 September 2015(21035)
Following up of the "Bumbling line" on ETMX seismic channels
Nairwita Mazumder, Rich Abbott

A few days back Jim noticed  (alog ) that the "Bumbling line" which varies over a large frequency range is again back on ETMX seismic channels . This was first noticed on March and disappeared before ER7 and again was seen from 4th August. One can see the lines at all the horizontal and vertical sensors on ETMX. 

I have attached a pdf containing some follow up work done during Rich's recent visit to LHO. The first plot in the pdf is the spectrogram of ETMX GS13 on 26th August. It can be seen that there are multiple wandering lines having a fixed offset.  We were suspecting that some magnetometers at the End X might be the culprit (as we could not find any correlation between temperature fluctuation  with the line ). 

The second and third plots are the spectrum of H1:PEM-EX_MAG_EBAY_SEIRACK_Z_DQ and H1:ISI-ETMX_ST2_BLND_Z_GS13_CUR_IN1_DQ for 2nd August and 26th August respectively. The red one is for 2nd August when the bumbling line could not be found and the blue one is the recent data (26th August). It is clear that the peaks appearing on  ISI-ETMX_ST2_BLND_Z_GS13 after 3rd August are correlated with the peaks of the spectrum (which also appeared around the same time) of SEIRACK magnetometer .

The plots on the second page shows the coherence between GS13 and the magnetometers in the VEA and SEIRACK. It looks like  the magnetometer on the SEI rack has stronger coherence with GS13 sensors than the magnetometer located at VEA .  I have marked two points (blue and red cross)  in the coherence plots to highlight two of the many peaks.
Non-image files attached to this report
Comments related to this report
rich.abbott@LIGO.ORG - 12:53, Monday 31 August 2015 (21053)
Adding to Nairwita's comments, the signal seen in the GS13 spectra is also present in the magnetometer data.  This being the case, it's most likely that the harmonic series points to an electromagnetic artifact associated with the HEPI pump variable frequency drive.  The fact that the same signature does not exist at the other end station (I assume this to be true, but have not verified) may point to an enhanced susceptibility in the X-end electronics for some reason.  No reason to panic much yet, but duly noted.
nairwita.mazumder@LIGO.ORG - 23:29, Wednesday 16 September 2015 (21602)SEI
I have attached the coherence plots computed between PEM-EX_MAG_SEIRACK and GS13 , ST1 CPS and ST2 CPS over the frequency range 0.4Hz-900Hz to check the following two points:
(1) If there exists any coherence between CPS and the Magnetometer at frequency above 256 Hz 
(2) What the low frequency  behavior is

I can be seen that the coherence between CPS and the magnetometer above ~25Hz is pretty low compared to GS13, but them have relatively high coherence with PEM-EX_MAG_SEIRACK near 20Hz .

Images attached to this comment
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:54, Sunday 30 August 2015 - last comment - 17:37, Sunday 30 August 2015(21026)
Day Ops Summary

(All time in UTC)

15:00 Take over from TJ. IFO not locked.

15:32 DRMI wouldn't lock after 10 mins. I was about to do the PRMI when I started seeing AS90 flashing. I gave it a few more minutes and it managed to lock.

          Lost lock at REDUCE_CARM_OFFSET soon after. Looks like ETMX was saturating. Wind speed ~20 mph.

15:45 Lockloss again at REDUCE_CARM_OFFSET. Turning ISI BSC WIndy blend filters on for BSC1,2,3.

18:23 Lockloss. Power outage. Guardian couldn't turn the ETMX ESD back on. We called Richard for help. See alog21030.

21:22 Switched the Windy blends off.

22:50 Begins the initial alignment after trouble relocking.

23:47 We're running into an issue with MICH_DARK_LOCKED. The beam would diverge away. I've tried setting the ALIGN_IFO to DOWN and waited a little bit before trying again. Didn't work. Sheila is working on it.

Comments related to this report
sheila.dwyer@LIGO.ORG - 17:37, Sunday 30 August 2015 (21034)

We looked into two of the locklosses that we had durring high winds.  (screen shots attached).  In both cases PRM was saturating or close to saturating before the lockloss.  Evan has increased the PRM and SRM offloading gains by a factor of 2.  

Images attached to this comment
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 04:21, Sunday 30 August 2015 - last comment - 09:26, Monday 31 August 2015(21023)
3rd round of calibration measurements for ETMY actuator scale factors

I have completed a set of measurements that is necessary for nailing down the ETMY actuation scale factors. This is a third round of the measurements in order to study repeatability and systematic errors. The measurement data can be found at the follwong places.

 


Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:26, Monday 31 August 2015 (21049)
J. Kissel, K. Izumi

I've process the results from the above aLOG using the same model I had used for LHO aLOGs 21015, just to get something out the door for review at today's calibration meeting. The results look encouragingly consistent with Wednesday's (LHO aLOG 20940) and Friday's (LHO aLOG 21005) results.

Again, the next steps are to
- functionalize the analysis scripts so we can easily process future measurements, 
- have those functions spit out their individual measurement results so they can be compared with each other (the comparison of which is another function to write), and
- make sure that all the scripts are using the output of the latest DARM model and parameter set, instead of recreating a naive model from the matlab QUAD's [m/N] and knowledge of the electronics chain.
- finish processing results from all the of the electronics chain measurements to identify if frequency-dependent systematics lie in there
- Update / refine the DARM model parameters to squash the frequency-dependendent residual to as small as possible, such that we can be confident in professing number with properly quantified 
uncertainty.

What has NOT been included in the naive actuation model:
- 16k IOP up-sampling filter
- Analog AA filter
- Any of the un- or poorly-compensated poles and zeros of the ESD drivers
- The recently found mis-match between expected and reality regarding the UIM driver's poles and zeros (LHo aLOG 20846)
I have a high degree of confidence that these are the reasons for the residual frequency dependence. In other words, these be resolved once I switch to using the full DARM model's actuation chain. That being said, suggestions are welcome as to what else the discrepancies might be.
Non-image files attached to this comment
H1 General
betsy.weaver@LIGO.ORG - posted 18:44, Saturday 29 August 2015 - last comment - 18:53, Sunday 30 August 2015(21014)
Cleanup on aisle SDF

Over the last ~5 days, nearly 100 SDF channels have gone into alarm.  We should probably link these to the INTENT bit, since many of these are actually real configuration control changes of the IFO, yet currently do not dictate any GO/NO GO of observation mode.  When connected to the intent bit, it will force commissioners and operators to address these changes in realtime, rather than let them stack up for me to reinvent every 5 days.

Since super-winds (and calibrations) have the IFO down, I've taken the opportunity to work on these - so far I've cleaned up:

- ETMX and ETMY L1 and L2 damping loop outputs enabled last Tuesday around the maintenance period - maybe the BURT pushed these buttons.  I  verified that the SAFE file sets the gain of the loop to be zero and the IN and OUTPUTS are ON.  Guardian then controls the gain.

 

- Accepted a few pages of offset changes, and the extra AS_B_RF45_AWHITEN_SET2 due to Evan/Stefan running the dark offsets script/commissioning last Thur night (alog 20976).  I'll wait for them to comment that the 1st attached SDF diffs are 1) their intended gain changes as it's vague in their alog, and 2) if they are ready to keep/accept them.

 

- Since SDF couldn't write the very small ~ 10e-19 CALCS epics values to the SAFE.snap file (commissioned AUG 11 alog 20452), I wrote them in by hand and then hit LOAD TABLE on the CALCS SDF.  All of the values cleared, since now they match the very small values loaded in their respective medms.  I've committed the CALCS safe.snap to svn.

 

- ALS X and Y - I need someone to point me to an alog regarding why the ALS_WFS_DOF_3 gains changed on both X and Y in the middle of the night on Thur night (2am Fri - see second SDF diff attachment.)

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 17:23, Sunday 30 August 2015 (21033)

Today, Evan pointed out that the DARK OFFSETs script sets these gains of the ASC loops to 1.0, but then does not reset the gains back to their nominal settings.  This was surprising to Evan, so he is reworking the script.  We have reverted the first 16 gain changes in the attached ASC SDF screen because of this.

Then, the next 4 gain setting diffs (ASC-AS_B_RF45) were from commissioning by Sheila/etal (20961), so we've ACCEPTED those in SDF.

evan.hall@LIGO.ORG - 18:53, Sunday 30 August 2015 (21036)

The existing script was, to put it mildly, not suitable for use as a control room tool. As Betsy says, it simply wrote a gain of 1 to every segment of every AS WFS. In fact, it did this twice: once inside a for loop, and then again immedately afterward (using a string of 32 caput commands). Moreover, there is no reason for such a script to touch the segment gains at all.

This script (along with the analogous REFL script) was summarily overwritten with a new python script: userapps/asc/common/scripts/dark_offsets/WFS_offset_AS. Usage is given in the first few lines as a comment.

H1 SEI (CDS, PEM)
evan.hall@LIGO.ORG - posted 16:06, Friday 28 August 2015 - last comment - 21:08, Sunday 30 August 2015(20997)
DMT viewer template for STS BLRMS

Jeff, Evan

There is now a new DMT viewer template for viewing the BLRMS of the corner and end-station STSs. It is userapps/isc/h1/scripts/Seismic_FOM_STS.xml.

This is meant to replace the Guralp DMT viewer template.

Right now it only displays the lowest two BLRMS (0.03 to 0.1 Hz and 0.1 to 0.3 Hz).

[As an aside, the frequency bands implied by the channel names in DMT viewer don't seem to match up with the front-end channels. For example, the front-end EX-X channels are named as follows:

H1:ISI-GND_STS_ETMX_X_BLRMS_100M_300M
H1:ISI-GND_STS_ETMX_X_BLRMS_10_30
H1:ISI-GND_STS_ETMX_X_BLRMS_1_3
H1:ISI-GND_STS_ETMX_X_BLRMS_300M_1
H1:ISI-GND_STS_ETMX_X_BLRMS_30_100
H1:ISI-GND_STS_ETMX_X_BLRMS_30M_100M
H1:ISI-GND_STS_ETMX_X_BLRMS_3_10

while the DMT channels are named as follows:

H1:ISI-GND_STS_ETMX_X_DQ_0p03-0p1Hz_48h
H1:ISI-GND_STS_ETMX_X_DQ_0p1-0p2Hz_48h
H1:ISI-GND_STS_ETMX_X_DQ_0p2-0p35Hz_48h
H1:ISI-GND_STS_ETMX_X_DQ_0p35-1Hz_48h
H1:ISI-GND_STS_ETMX_X_DQ_1-3Hz_48h

Are these BLRMS distinct from what's being computed in the frontend?]

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 21:29, Friday 28 August 2015 (21002)

What was wrong with the old plot?

evan.hall@LIGO.ORG - 22:09, Friday 28 August 2015 (21003)

The STS is more sensitive than the Güralp in the frequency band where we typically watch for earthquakes (30 mHz to 100 mHz).

daniel.sigg@LIGO.ORG - 21:08, Sunday 30 August 2015 (21040)

Looks like we should keep the old plot then, since everyoe already knows it.

Displaying reports 62641-62660 of 83146.Go to page Start 3129 3130 3131 3132 3133 3134 3135 3136 3137 End