Displaying reports 67521-67540 of 84562.Go to page Start 3373 3374 3375 3376 3377 3378 3379 3380 3381 End
Reports until 02:12, Friday 27 March 2015
H1 ISC (ISC)
lisa.barsotti@LIGO.ORG - posted 02:12, Friday 27 March 2015 - last comment - 12:17, Friday 27 March 2015(17504)
30 is the new 20!

Evan, Sheila, Dan, Lisa

We made it to 34 Mpc by managing to do at the same time all of the things we have tried before (low noise ESD on ETMY, low noise coil drivers for all the optics, POPAIR for vertex length DOF, more aggressive SRCL cut-off), plus some more ASC cut-offs. Implementing all of these things at the same time happened to be more challenging that expected because of a few problems that slowed us down today:

Some more details

Final IFO & Guardian state

We leave the interferometer locked at 34 Mpc, starting at March 27 9:00 UTC

Comments related to this report
evan.hall@LIGO.ORG - 02:17, Friday 27 March 2015 (17505)

Spectrum attached.

Images attached to this comment
fred.raab@LIGO.ORG - 07:41, Friday 27 March 2015 (17509)
Great work! I will update our slides for the quarterly briefing.
albert.lazzarini@LIGO.ORG - 08:40, Friday 27 March 2015 (17511)
Excellent progress!
david.reitze@LIGO.ORG - 08:47, Friday 27 March 2015 (17514)
Nice work.  Great headline, too.
hugh.radkins@LIGO.ORG - 09:38, Friday 27 March 2015 (17518)

Note that ISI Stage2 was a State3 trip meaning that the Damping Loops were still functional.  It would be nice to know when/why the stage tripped.  But I'd guess that the Guardian was set to fully isolated before the ~0700utc short lock and was untripped during the short lock, likely triggering during acquisition and then triggering again at the trip.  That is what I first thought.

See attached--It looks like the stage2 when isolated survived the IFO lock loss but not the MICH reacquisition.  This means, we can use the Guardian to transition the ISI between Isolated Damped and Fully Isolated with tripping nor requiring operator intervention.

This is a 50 minute stretch so the IFO lock Loss is only a couple minutes before the St2 WD trigger but there may be enough time to deisolate stage2.  Looking at a zoomed in full data, looks like a full 70+ seconds after lock loss based on this CAL_DELTAL channel.  The second lock loss had even more time so I don't think it is tied to the lock loss but more to the reacquisition.

Images attached to this comment
evan.hall@LIGO.ORG - 12:17, Friday 27 March 2015 (17530)

Noise budget attached, with new the anticipated ETMY ESD noise. We have many other traces to add here: intensity coupling, frequency coupling, auxiliary dofs, etc.

I believe the 10 W quantum noise and the DAC→ESD noise alone limit us to no more than 60 Mpc, although based on the previous performance of the ETMX ESD, the ESD trace here may be an overestimate.

Non-image files attached to this comment
H1 ISC
daniel.hoak@LIGO.ORG - posted 01:25, Friday 27 March 2015 - last comment - 08:46, Friday 27 March 2015(17502)
some new violin data

Evan & Sheila, Dan & Lisa

Tonight some new failure modes of the violin damping manifested themselves, and we found new ways to damp them.

On ITMY, the following modes and settings were identified:

Frequency (Hz) Filter (ITMY_L2_DAMP) Settings (phase, gain)
503.007 MODE3 +60deg, +200
503.119 MODE1 -60deg, -300
504.875 MODE4 0deg, +300

Note that in the earlier catalog the 504.875 line was mis-identified as an ETMX mode, and the 503.119 line was not paired with an optic.

Comments related to this report
david.reitze@LIGO.ORG - 08:46, Friday 27 March 2015 (17513)


		
		
H1 SUS
sheila.dwyer@LIGO.ORG - posted 00:57, Friday 27 March 2015 - last comment - 11:33, Friday 27 March 2015(17501)
EX PUM watchdog

Earlier in the evening we tripped the RMS watchdog on ETMX, and had to drive out the end station to power cycle the coil driver.  

This wasn't obvious from the control room.  Three things that would help are to 

1) add this to the OPS overview screen

2) add it to the SYS_DIAG gaurdian

3) add it to the SUS guardians

Comments related to this report
thomas.shaffer@LIGO.ORG - 11:33, Friday 27 March 2015 (17527)

They are now in SYS_DIAG.

H1 PEM (DetChar, ISC, PEM)
sheila.dwyer@LIGO.ORG - posted 21:54, Thursday 26 March 2015 - last comment - 18:49, Friday 27 March 2015(17499)
Coherence with PEM accelerometers

Here is a plot of coherences with some PEM accelerometers.  We have been thinking that the noise around 200-250 Hz was due to the PSL periscope PZT, based on coherences like the one in the lower left plot.  However, there is suscpicously similar coherence between the ISCT6 accelerometer and DARM.  Indeed, the coherence between these two accelerometers is high in this frequency range, suggesting that some cross talk could be the dominant signal in these accelerometers.

The right two panels show that the accelerometers which have coherence with DARM around 13 Hz and 16 Hz are also coherent with each other, but not nearly as much.  

Images attached to this report
Comments related to this report
sudarshan.karki@LIGO.ORG - 18:49, Friday 27 March 2015 (17542)

There is some cabling work that needed to be completed on this particular channel (ISCT6_ACC). Hope to bring it online on Monday.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 19:58, Thursday 26 March 2015 (17497)
Where our megaparsecs are

The first plot here shows the range integrand for LLO's 65 Mpc lock on March 6th, our March 16th 15 Mpc lock and Monday's 28 Mpc lock.  The second plot shows the cumulative range difference as a function of frequency between these locks.

The green line on the second plot shows that the 12 Mpc we gained between March 16th and is mainly due to the improvements from 20-100 Mpc, (mainly due to ESD low passes and decreased MICH contamination of DARM).  

The blue line shows where we need to improve to catch up with LLO in inspiral range  There are 25 Mpc to be had in the 20-40 Hz region.  

These plots are made using an old script by Grant Meadors,  and data that Dan managed to get for LLO.  

Non-image files attached to this report
H1 SUS (CDS, ISC, SUS)
evan.hall@LIGO.ORG - posted 18:18, Thursday 26 March 2015 - last comment - 07:00, Friday 27 March 2015(17496)
ETMY ESD driver tripping repeatedly

Rich A., Lisa, Sheila, Jeff, Evan

The EY ESD driver has tripped twice today, apparently in the same failure mode as described previously. Each time we have had to drive down to the end station to reactivate it.

The supplies are set at ±430 V, each with a 75 mA current limit. When the driver is active, it draws 23 mA dc from the positive supply and 20 mA dc from the negative supply. When tripped, it draws 3 mA dc from each supply.

Comments related to this report
sheila.dwyer@LIGO.ORG - 00:55, Friday 27 March 2015 (17500)

This seems to happen every time we loose lock if we have transitioned to ETMY.  We are getting plenty of excerise tonight going back and forth to the end station.  

If anyone has any ideas about how to make this easier to reset or to prevent it from happening, that would save us some fuel.  

kiwamu.izumi@LIGO.ORG - 07:00, Friday 27 March 2015 (17508)

Why don't we set a digital limiter ? For example, see LLO alog:

https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=14472

H1 CAL (CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 16:53, Thursday 26 March 2015 (17494)
h1calcs, h1omc models restarted, MEDM screens updated to add diagnostic new channels for calibration lines, and OMC SDF turned ON
J. Kissel
Completes WP #5118

I've compiled, installed, restarted, and restored the changes to the h1calcs.mdl and h1omc.mdl front end models that were described in LHO aLOG 17472. This required a DAQ / h1dc0 / frame-builder restart, which I performed at 09:02 PDT (16:02 UTC).

I attach screenshots of further improved MEDM screens for the CAL CS and LSC that employ the new channels.

I've also turned on the OMC SDF system, and committed the new SDF file "safe.snap" to the userapps repo, under
/opt/rtcds/userapps/release/omc/h1/burtfiles/h1omc_safe.snap. It currently has 28 channels not monitored, the only one of which I delibrately turned off was H1:OMC-PZT2_SW2S, which had its output flickering on and off because of the front-end / guardian triggering which toggles the output. The rest appear to be ODC strings that I guess, by default, aren't monitored. 

Note that this SDF system covers a lot of the LSC stuff too, and it looks like the majority of channels that are different from this morning (when I turned on the SDF, when the ISC_LOCK and OMC_LOCK manager were DOWN) are Guardian changed variables. When the IFO was fully locked in the DC readout, and the vanguard was in the process of transitioning to low-noise ETMY control, there were only 20 channels in the DIFF list. I leave it to the commissioning vanguard to remove these channels from the list at leisure. This will be much easier / convenient to do once we get the RCG 2.9.1 upgrade to the SDF system.
Images attached to this report
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:23, Thursday 26 March 2015 (17495)
Daily Ops Summary

= Morning Meeting =

SEI: BRS rung up

SUS: Sorry I couldn't hear

Richard: Shutter control needs work

Facility: Sorry, I couldn't hear again

3IFO: Moving things next Tuesday. Will be noisy.

Jeff: Rebotting calibration front end model

Sudarshan: PCal calibration

Lots of work permits...

 

= Activities =

Some times early in the morning: Karen and Cris to LVEA

7:00 Richard to EY

7:37 Richard back

8:19 Karen opening exit doors (LVEA)

8:41 Jim B to EY. Installing TCT

8:45 Fil to EY replace shutter box

        Sudarshan and Rick to EX - PCal work

        Jim to EX (stopped BRS damp)

8:52 Matt and Jason to H1 PSL ante room

5:56 Kyle to EY

9:00 both Jim came back

9:06 Jeff done with model changing

9:12 Matt and Jason back

9:19 Betsy and Travisto West Bay (3IFO stuff)

9:34 Kyle out of EY, to EX

9:39 Fil back

10:02 Kyle back

10:05 Andreas drop a bag at LVEA

10:18 Andreas back

10:30 Richard to LVEA 2k area (3IFO)

          Jodi to LVEA 

11:29 Jodi let Gary in, supervised.

12:00 Daniel and Sheila to EY

12:40 Corey to squeezer bay

13:46 Jodi back

13:51 Dan and Eli to EY

13:54 Rick and Sudarshan leaving EX

14:40 Dan and Eli back

          Corey back

 

Happy 3IFO day

H1 AOS
thomas.shaffer@LIGO.ORG - posted 16:09, Thursday 26 March 2015 (17493)
Guard Overview shuffled around a bit

I took out ISC_DOF since it is no longer being used. Since this left a hole, I slid up the SYS_DIAG mini.

Screenshot attached.

Images attached to this report
H1 ISC (ISC)
lisa.barsotti@LIGO.ORG - posted 14:30, Thursday 26 March 2015 (17490)
Last night lock

A couple of plots from last night. We had an incredibly stable ~4h lock with 20 Mpc range. All the "standard" alignment loops were enaged (the only uncontrolled DOFs are comm/diff ITMs).

Recall that in this lock DARM was controlled by actuating on high noise ESD on ETMX.

Images attached to this report
H1 AOS (ISC)
eleanor.king@LIGO.ORG - posted 14:22, Thursday 26 March 2015 - last comment - 15:50, Thursday 26 March 2015(17489)
EX ring heater power supply is turned off.

Dan, Elli.   EX ring heater power supply is turned off.  Alll other ring heater power supplies are still on  There is a coherence measured between EX magnetometer and DARM at 55Hz (see Gabriele's alog 17423), so we are checking whether turning off the ring heater power supply removes this line.

Comments related to this report
eleanor.king@LIGO.ORG - 15:50, Thursday 26 March 2015 (17492)

The 55MHz line didn't disappear, so we have turned off ITM ring heater power supplies also.

H1 SEI
jim.warner@LIGO.ORG - posted 14:00, Thursday 26 March 2015 - last comment - 15:13, Thursday 26 March 2015(17488)
Improved BSC blends

I've continued my work on improving BSC St2 blends, I think I have something fairly Hippocratic.  I moved the St2 ellips down to 1.5 Hz and added a pole at 10 Hz. This affects the St2 CPS phase (~24 degrees at the blend frequency) but this doesn't seem to negatively affect the performance. I've talked to the commissioners about trying this during a lock, I think I can install and turn the new filters on without breaking anything.

First plot shows my modifications. Red is stock, green is the "old" again, blue is my current.

Second plot shows the performance. Pink is ground before, green is ground after, blue is before, dashed and solid are CPS and GS13 respectively, red is after. Does pretty good between 1 and 20 hz, doesn't seem to do any worse below 1 hz. I think all of the differences below 1  hz can be attributed to the ground.

Images attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 15:13, Thursday 26 March 2015 (17491)

Jeff suggested I check LLO' blends to see if they had made a similar change, and it turns out they have. A nice demonstration of convergent evolution. Attached plots show the comparisons. The LLO blend has more gain peaking, but keeps closer phase up to the blend frequency and has more high frequency roll off. My elliptics dont afftect the gain peaking, but don't roll off as fast around 10 hz, but at that point my performance plots show we are already hitting GS13 noise.

Images attached to this comment
H1 SEI (ISC)
hugh.radkins@LIGO.ORG - posted 11:00, Thursday 26 March 2015 - last comment - 02:00, Friday 27 March 2015(17482)
IFO Lock Loss (McCarthy ESD EndY?) Leads to EndX HEPI/ISI Watchdog Trip, Why? Guardian, PLL Logic?

Sheila, Hugh

IFO lost lock ~1426utc, Richard suspects it was his testing of the ESD.  Almost 45 minutes later, the ISCINF_LONG stepped to its rail, LIMIT set to 250000nm.  And I mean stepped, ~1 second or less.  This of course put a bit much demand on the HEPI loop.  It spiked its output and pretty much instantly tripped the watchdog on the Actuator followed by the ISI shortly thereafter.  The HEPI and ISI reisolated normally.

 

The first attached plot shows the lock loss.  This 30 minute trend has the DARM OUT with the ISCMON_X_INMON quickly going to zero and the HEPI Outputs moving in response.  No problems here, HEPI does fine.  You also see the arm or something grab again as you can see the Tidal drive to the HEPI start again but this only lasted for a couple minutes.

The second plot attached zooms out to 2 hours, with the IFO lock loss seen on the ISCMON on the left.  ~45 minutes later the DARM steps, this time stepping the ISCMON and tripping HEPI and about 8 seconds later, the ISI (not shown.)

In the third attachment, Sheila dug around in LSC/ALS space and put together some trends showing the spike into HEPI originating when the ALS-X_LOCK_STATE steps from level 2 to 6 (PLL Lock to Red Lock.)  This is unrealistic as the Lock state dropped from Red Lock just ~90 seconds earlier.  Notice the TIDAL_CTRL_INMON steadily growing (DARM not Cleared.)

Sheila is looking deeper into the Guardian feeling it may have failed to do something it possibly should have to prevent the DARM OUT from going to the rail and the unreasonable rapid transitions of the ALS LOCK STATE.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 02:00, Friday 27 March 2015 (17503)

There were two things in place that should have prevented this but didn't.

  •  First of  all the guardian should have noticed that the lock was lost and gone to the down state, which clears the DARM drive to the ETM, so that the input to the tidal on ETMX sus should be zero, and therefore the input to HEPI tidal should have been zero.   The guardian was in the state DRMI_ON_POP, which had a typo from some efforts to incorporate new functionality.  I assume that the guardian didn't go to down because it would have been in error with this typo.
  • Second, the logic in the end station state machine in beckhoff should turn off the tidal feedback when the arm is not locked.  It did this, which is why HEPI didn't trip right away despite the guardian problem.  However, the new Red Lcoked state can be entered when there is just a flash of red in the arms, without passing through the other states, which it should not be doing.  This can be fixed, hopefully on tuesday.  
H1 SEI
jim.warner@LIGO.ORG - posted 10:26, Thursday 26 March 2015 (17487)
BRS mass damper damping turned off

In the continuing saga of the Ring Up of the BRS, I've turned off the damper. I turned it on yesterday thinking that 2 days was sufficient rest for the BRS to settle down, but Krisha reports that it probably needs more like 4-5 days, given current levels of excitement. It would be best if people avoided the end station, as the BRS is now completely uncontrolled.

The damper is controlled by a line of code that sets the variable TestData (or some variation of capitalization thereof). The normal line sets this equal to 2.5 - outvelocity. To disable there is a line immediately below that is commented out that sets TestData to just a constant (2.5). Uncomment this line and restart the code. Done.

H1 SUS (DetChar)
richard.mccarthy@LIGO.ORG - posted 07:47, Thursday 26 March 2015 - last comment - 19:52, Thursday 26 March 2015(17479)
ETMY ESD drive
Loss of lock probably due to my work at EY on ESD drive.  

Following up on last nights report I went down to EY to investigate problems with the ESD.
Much to my surprise aside from the unit being in the off state I could not find a problem.  The HV supplies were on and at nominal current draw for no drive (3.2mA).  Went in to check the ESD Chassis and all the lights were green. The only indication of a problem was the main indicating light for the unit showed it to be in the off state.  I had disabled all of the DAC inputs to the driver so I turned it on.  Went over to computer and enabled outputs and immediately saw a response on the OpLev.  I am not sure what interlock could have shut the unit down but further investigation is warranted.  I have left the unit on for now.  please keep me Richard McCarthy informed if this or more problems arise.

Comments related to this report
rainer.weiss@LIGO.ORG - 19:52, Thursday 26 March 2015 (17498)
When I was characterizing the ESD several years ago I noticed that the
microprocessor that controls the device would turn off the system when a spike
in either + or - direction on the 430 volts input occurs. You might want to check
the tolerance on the input voltage of both the positive and negative input voltages.
H1 DetChar (ISC)
laura.nuttall@LIGO.ORG - posted 08:49, Wednesday 25 March 2015 - last comment - 10:10, Thursday 26 March 2015(17452)
Arches seen in DARM

Laura, Josh, Andy, Joe, Detchar

We took a look at the 28 Mpc lock on 24th March to see if there was any evidence of arches that we have seen previously at LLO (for example LLO alog 17090).

The first attachement shows a histogram of the rate of glitches (omicron triggers) binned by the value of IMC-F at the same time. The plot looks pretty Gaussian, except for a few bins specifically between IMC-F values of -37.5 to -41.7 and -45.8 and -50. Between these values we see evidence of arches in DARM. The second attachment is a pdf file showing the arches in DARM lining up with values of IMC-F in the second bin. Here are links to many spectograms confirming the arches in the IMC-F bins outlined (spectrograms for IMC-F bin -37.5 to -41.7 / spectrograms for IMC-F bin -45.8 to -50). Each spectrogram time corresponds to a glitch as seen by omicron.

LLO has dramatically reduced the effect of these arches, see LLO alog 17191.

Also the value IMC-F has when these arches appear in DARM seems to drift, i.e. there does not appear to be a specific value of IMC-F which produces the arches (this is evident in the second attachement). This is not what we have seen at LLO, does anyone know what could be causing this?

Images attached to this report
Non-image files attached to this report
Comments related to this report
andrew.lundgren@LIGO.ORG - 09:53, Wednesday 25 March 2015 (17457)
Andy, Laura, DMac

Here's a look at one of the whistles, and the putative cause as an RF beatnote with IMC-F. The idea is that the IMC VCO is beating against another (nearly) fixed RF oscillator, and that's what we see in DARM. In that case, the frequency track should look like the difference between IMC-F (calibrated in kHz) with some fixed value.

In fact, the whistle clearly seems to match half of the frequency difference (black trace) rather than the full difference (red trace). Perhaps this hints at the type of coupling? Here, the fixed value is about -46.9 kHz (relative to whatever IMC-F's reference is), but we think this drifts during the lock. We can look in detail at some more of these, and find out.
Images attached to this comment
daniel.sigg@LIGO.ORG - 11:47, Wednesday 25 March 2015 (17462)

Why not use the frequency readbacks of the oscillators and VCOs rather than the somewhat arbitrary IMC_F? The radbacks are only once per second, but they can still tell you which units are close in frequency.

andrew.lundgren@LIGO.ORG - 13:20, Wednesday 25 March 2015 (17463)
I'd be happy to look at the readbacks, as long as they are recorded and available offsite. Can tell me what the channel names are?
daniel.hoak@LIGO.ORG - 14:04, Wednesday 25 March 2015 (17465)

I put some notes about these channels in the summary of the ISC F2F last fall.  ("RF crosstalk" section)

The channel names and labels are in the attached code.  There, I look at the time around the event that Andy sent around to the DetChar mailing list yesterday.  It's not totally obvious what VCO is beating against the PSL VCO, the closest one is ALS COMM, but it's about 400kHz away at the time of the glitch.

The first plot shows the value of all the corner station VCOs in the ten minutes around the glitch, the second plot is a zoom around the PSL VCO frequency.

Non-image files attached to this comment
andrew.lundgren@LIGO.ORG - 10:10, Thursday 26 March 2015 (17485)
It seems like H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_5, which Dan has labeled as the PSL readback, is the best candidate. This seems to be roughly equal to (1/2)*IMC-F + 79.225 MHz, delayed by one second (i.e. I can line those two things up and they overlap). Is the one second delay due to some loop or is it just a quirk of the recording system?

The whistles occur whenever this readback crosses 79.2 MHz, which is the fixed fiber AOM frequency from the talk referenced in Dan's notes from above.
Displaying reports 67521-67540 of 84562.Go to page Start 3373 3374 3375 3376 3377 3378 3379 3380 3381 End