Displaying reports 61361-61380 of 77278.Go to page Start 3065 3066 3067 3068 3069 3070 3071 3072 3073 End
Reports until 19:56, Thursday 29 January 2015
H1 ISC
sheila.dwyer@LIGO.ORG - posted 19:56, Thursday 29 January 2015 - last comment - 12:44, Friday 30 January 2015(16359)
getting closer

Evan, Alexa, Elli, Kiwamu, Rana, Keita, Sheila

We are getting closer.

Today it has been much more reliable and robust for us to get to the state where DARM is controlled on RF.  Differences from yesterday that have probably helped with this:

The ISC_LOCK guardian takes us to an offset in TR CARM of 20.  There we have been trying to transition to REFL9 I/TRY. We lowered the whitening gain of REFL9I which was saturating the ADC, we now have 0dB whitening gain and no whitening filters.  The steps that we have been doing that are not yet in guardian are:

At this point, some kind of oscillation has been starting which eventually blows the lock.  Some example times are 2:47:06 UTC and 3:13:01 UTC.  The attached striptool shows both of these events.  You can see the oscillation in POP18, AS 90, AS DC, and REFL DC.  As I've been writing I've been letting the guardian try to lock on its own, it has lost the lock twice in the REDUCE_CARM_OFFSET_MORE state, I think this is because the DIFF offset wasn't adjusted well.  I've extended the time that the servo runs before this step.  

I've left DRMI locked, with the arms misaligned for seismic people.  

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 21:13, Thursday 29 January 2015 (16360)DetChar, ISC, PSL, SEI, SYS
This DRMI lock stretch Sheila's left us began undisturbed starting ~04:05 UTC.

Here're some relevant conditions of the IFO.

DRMI is Guardian is in requested state DRMI_1F_OFFLOADED.
IM4, PR3, BS, and SR3 alignments must have been tweaked recently, as their alignments are not saved, according the Guardian.

Corner station WFS are OFF

ISS Second Loop is OFF

Wind is low, <5 [mph]
Seismic Env.:   
   Band Limit   [um/s] (12-hour trend)
   0.03 - 0.1  = 4e-1  (steady)
   0.1  - 0.3  = 2e-1  (on its way down)
   0.3  - 1.0  = 3e-2  (steady)
   1.0  - 3.0  = 1e-1  (Hanford is on shift and loud)
   3.0  - 10   = 3e-1  (steady)

Optical levers well centered (about ~5-7 [urad] off center in P&Y) for BS, ITMX, and PR3. ITMY and SR3 is a little further off centered (about 15-17 [urad] off center).
BS Optical Lever Damping in P and Y is ON, no other Optical Lever Damping is ON.

All corner station HEPIs are ON, position-sensor only, locked to the ground, ~4 [Hz] UGFs. ALL DOF isolation loops closed, including AC coupled HP and VP. BSC HEPIs have Z sensor correction ON.

Corner Station HEPI Pump Servo is ON.

All HAM-ISIs running ~30 [Hz] isolation loops, sensors blended with 01_28 filters (including HAM3!), sensor correction ON in X, Y, and Z. ALL DOF isolation loops closed. GS13s are in HIGH gain mode, with DeWhitening filters OFF.

All BSC-ISIs running ~30 [Hz] isolation loops, sensors blended with 
   ST1 X&Y 45mHz, Z 90mHz, RX&RY 250a*250b, RZ 750mHz
   ST2 X&Y 250mHz, Z, RX,RY,RZ T750mHz
ITMs: ST1 RZ isolation loops are NOT closed, all other DOFs are closed
      ST2 only X&Y isolation loops are closed
BS: ST1 RZ isolation loops are NOT closed, all other DOFs are closed
    All ST2 isolation loops are OFF
ITM GS13s are in HIGH gain mode, with DeWhitening filters OFF.

All relevant SUS happily damped.
Images attached to this comment
sheila.dwyer@LIGO.ORG - 09:59, Friday 30 January 2015 (16367)

Keita, Alexa, Sheila

The osciallation that was breaking the lock last night was at about 0.45 Hz, and shows up in all the quad oplev pitch signals.  It looks like the soft mode in both arms, but the oscialltion in the two arms are not in phase with each other.  There is some of this noise showing up in DARM, but not in the other LSC out channels, in the BS, PR3 or SR3 signals until after the lockloss

This shows up on the ITMs, and we are not actuating on the ITMs.  This is strange, but one thing that we would like to try is using lower power. 

Images attached to this comment
H1 ISC
keita.kawabe@LIGO.ORG - posted 19:21, Thursday 29 January 2015 (16358)
First decent look at scattering

Summary:

Now that we have decent arm buildup, we can look at the baffle PDs with real S/N.

Y arm looks lossier than X, but we knew that.

The scattering seems to have distinct spatial pattern that is not rotationally symmetric around the mirror center axis. Probably because of localized scattering bodies.

The scattering pattern moves in time. Probably because of alignment fluctuation.

Wise people might want to help disentangling these and tell where the localized scattering bodies are and how much they are scattering.

Details:

First attachment shows 30pm CARM offset lock stretch from yesterday. At the end of the lock, TR_CARM offset reached 25, which translates to about 30pm.

If you just mask everything out except this 30pm period, after subtracting dark offset (obtained after lock loss) we obtain the following DC current table:

  PD1 mean (std) [uA] PD4 mean (std) [uA] E1+E4+I1+I4
EX 8.4 (0.3) 2.9 (0.1) 36.5 (0.9)
IX 17.5 (0.3) 7.7 (0.4)
EY 8.0 (0.5) 10.9 (1.4) 47.8 (1.9)
IY 16.5 (0.7) 12.3 (0.4)

The first thing you'll notice is that the Y arm seems to be somewhat lossier than X, which we already knew.

The second thing is that the scattering is not rotationally symmetric around the mirror center axis. If it is, PD1 and PD4 on the same baffle will see the same power. In reality, in X arm, IX PD1 receives the biggest power (17.5), EX PD4 the smallest (2.9), and the remaining two are both about half of the biggest guy. In Y arm, ITM baffle receives more power than ETM, and the biggest/smallest are much closer than X.

There should be some localized scattering source.

The second attachment is a scatter plot of various PD pairs. This in itself is pretty useless for anything except to show you that the fluctuations in some PD pairs are correlated, some positively and others negatively. It's also apparent that Y arm is moving much more than X. I didn't plot correlation between different arms because there's almost none.

Anyway, the scattering pattern is moving, dumping more or less power on these PDs.

I cannot disentangle these but wise people might be able to.

Images attached to this report
H1 CDS
sheila.dwyer@LIGO.ORG - posted 18:54, Thursday 29 January 2015 - last comment - 13:19, Friday 30 January 2015(16357)
guardian taking a long time to calculate paths, unexpected mode transition

 We have noticed that it is sometimes taking a verry long time for guardian to calculate paths (the ISC_LOCK guardian).  

We also just saw something more strange.  It seems that the ALS COMM guardian, which was managed by the ISC_LOCK guardian, became executed, although we are pretty sure no one in the control room did this. screen shot of the log is attached. 

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 12:57, Friday 30 January 2015 (16372)

The log files and conlog report the ALS_COMM out-of-managed-mode sequence is managed->pause->exec->pause->managed. Text file is attached.

Non-image files attached to this comment
david.barker@LIGO.ORG - 13:05, Friday 30 January 2015 (16373)

On the long times for ISC_LOCK to calculate paths, I see a log entry which suggests a transition request from LOCKING_ALS_DIFF to DARM_WFS (via LOCKING_ALS_COMM) took 12 seconds to calculate the path. Is the processing of the current state causing the delay? Log details attached.

Non-image files attached to this comment
jameson.rollins@LIGO.ORG - 13:19, Friday 30 January 2015 (16374)

Can you guys ellaborate on this claim of overly long path calculation time?  The log you post doesn't seem to support it.  From the log you posted:

2015-01-30T03:36:06.566Z ISC_LOCK [LOCKING_ALS_DIFF.run] USERMSG cleared
2015-01-30T03:36:15.586Z ISC_LOCK new request: DARM_WFS
2015-01-30T03:36:15.586Z ISC_LOCK calculating path: LOCKING_ALS_DIFF->DARM_WFS
2015-01-30T03:36:16.778Z ISC_LOCK [LOCKING_ALS_DIFF.run] USERMSG: node ALS_DIFF: NOTIFICATION
2015-01-30T03:36:27.308Z ISC_LOCK [LOCKING_ALS_DIFF.run] ALS_XARM: REQUEST => LOCKED_TRANSITION

The path calculation happens at 3:36:15.586, followed by some usercode logging about changes to the ALS_XARM request, which presumably is a subordinate of  this ISC_LOCK node.

What makes you think that the ISC_LOCK is taking a long time to calculate a path?  My guess is that you're confusing the manager notification about changing subordinate request with a problem with the path calculation.  They're not related.

H1 SEI
hugh.radkins@LIGO.ORG - posted 17:20, Thursday 29 January 2015 - last comment - 08:21, Friday 30 January 2015(16356)
H1 HEPI Pump Servo Pressure Sensor Noise Further Studies

After looking at all the L4C plots, Krishna suggested we look at the IPS thinking that with the loops closed by the HEPI Platform servo which has lots of gain, it should suppress the IPS signal and the L4C coherence we are seeing was from something else...like the fluid moving the piping...  Seem reasonable although really?

However, see attached:  Same times as the L4C coherence I posted Tuesday.  I show HAM5 at the local position sensor (IPS.)   It is very clear the Horizontal IPS have great coherence from 0.5 down to .02 hz when the pressure sensor loop is closed.  The Vertical IPS coherence isn't nearly as strong but certainly present.  The output drive to the HAM5 Actuators is very small both horizontal and vertical.

I attach too the coherences from the End Stations.  The second attachment has ETMX in the left plots and the ETMY in the right plots.  Both pressure servo loops are closed but ETMX pressure signals do seem to be quieter (although not as quiet as I've seen the corner station's back before December) and the ETMX is servoing on the direct output pressure at the Pump Station.  Whereas, at the ETMY, we are servoing on the actual remote pressures at the BSC10 differenced in the epics database.  The signals at ETMY have always been very noisy and so when I switched ETMY to the differential mode, I added serious smoothing to the signals before differencing.

Looking at the the comparison of the ETMs there are distinctions but what causes what them is not clear.  The quieter EndX is evident in the amplitude and dispite the smoothing, the EndY has a much sharper and higher amplitude peak at 150mhz.  Don't ask me what's happening at 3.5hz...

The lower plots at interesting in that unlike at HAM5, there is no coherence with the vertical IPS on either platform but the horizontals are very coherent.  This coherence at ETMX is narrower in band though maybe somewhat more like the band at HAM5...related to the quieter pressure signal at ETMX or due the ETMY servoing on the difference rather than the direct supply pressure or the smoothing...?

Images attached to this report
Comments related to this report
richard.mittleman@LIGO.ORG - 08:21, Friday 30 January 2015 (16363)

I'm going to go out on a limb and say that we expect coherence in the local channels until we fix the pringle loops, which are essentially uncontrolled now.Why horizontal and vertical show different behavior i have no idea

H1 General
edmond.merilh@LIGO.ORG - posted 15:55, Thursday 29 January 2015 (16339)
Daily Ops Summary

08:00 Started my solo ALS alignment

08:30 Success! I wasn't really watching the time but I knew it took longer than 20 minutes.

08:30 Rich Abbott on site.

09:00 Locked ALS solo this morning!  Attempted solo DRMI lock. Not so successful but Kiwamu found that it wasn't my fault (nocturnal commissioning shenanigans)

09:30 R Abbott and Fil out to LVEA HAM6 to work on Fast Shutter. Gerardo is monitoring vaccuum during this activity.

09:52 McCarthy in/out LVEA to HAM6 - multiple times.

10:31 Gary out to LVEA to move ISS arrays from H2 enclosure to H2 building. Using Large airlock egress for this operation.

11:53 Krishna arrived. He wasn't mentioned as an upcoming guest. 

13:00 Locked DRMI for te first time with the help of Kiwamu.

13:53 Rabbot, Fil and Rich out of LVEA

H1 ISC (ISC)
rich.abbott@LIGO.ORG - posted 15:17, Thursday 29 January 2015 (16355)
Installed Fast Shutter Driver
Filiberto, Richard, Rich

Installed Fast Shutter Driver Chassis S1400582 into ISC Rack 5 at U-height 6.  The system performs well in terms of reliably blocking light upon receipt of a trigger input (1.92milliseconds to block).  The remote control signals are functional in terms of the hardware, but there is still a reboot of the Beckhoff system needed to load the necessary code.  We will do this tomorrow to avoid messing with commissioning.

The solution is as follows:
1.  250 VDC on Kepco Supply, this corresponds to 243 VDC on the internal energy storage capacitors and is visible on the front panel LCD display on the shutter driver.
2.  5.4 millisecond applied pulse width
3.  20 ohms series resistor

Here is the rule for using the shutter to prevent damage to photodiodes in HAM6:
We must not lock the interferometer at high power(>10 watts) without the HV READY indicating the shutter is charged, AND no FAULT condition.  Both these parameters are reported via the Beckhoff interface from the shutter driver.

Some not so obvious factoids about the shutter system:
1.  The shutter is triggered to fire by a trigger signal that falls from 5 to 0 volts indicating the light level on the trigger diode has exceeded the maximum allowable setpoint.  Right now, the shutter controller latches this low voltage state.  The shutter driver deliberately interprets a continuous low voltage input as evidence that the shutter controller is either unpowered, broken, or disconnected, and will report a fault condition after 5 seconds.
2.  The shutter driver needs about 10 seconds to recharge after firing during which time you can not trigger it to drive the shutter.  This is deliberate as firing the shutter with an arbitrary low voltage can cause the shutter to be damaged.
3.  If the output drive cable delivering the pulse to the shutter is disconnected anywhere in the chain, the shutter will go into a FAULT state and won't do anything until the FAULT state is fixed.  The shutter driver also generates a FAULT if any internal low voltage used in the shutter driver is out of spec by more than 10% from nominal.

The attached image shows a timing measurement made by measuring the applied current to the shutter coil (shown in yellow obtained by using a clamp-on current probe) and the DC light level (taken on a breakout board on AS WFS A DC Channel 1).  The time between the rising edge of the current pulse and the falling DC voltage level is about 1.92mSec
Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 14:38, Thursday 29 January 2015 (16353)
CDS model and DAQ restart report, Wednesday 28th January 2015

model restarts logged for Wed 28/Jan/2015
2015_01_28 11:22 h1broadcast0
2015_01_28 11:22 h1dc0
2015_01_28 11:22 h1fw0
2015_01_28 11:22 h1fw1

2015_01_28 11:22 h1lsc
2015_01_28 11:22 h1nds0
2015_01_28 11:22 h1nds1
2015_01_28 11:34 h1broadcast0
2015_01_28 11:34 h1dc0
2015_01_28 11:34 h1fw0
2015_01_28 11:34 h1fw1

2015_01_28 11:34 h1lsc
2015_01_28 11:34 h1nds0
2015_01_28 11:34 h1nds1

2015_01_28 13:43 h1fw0
2015_01_28 19:05 h1fw0
2015_01_28 20:02 h1fw1

lsc model changes with associated DAQ restarts. Three unexpected fw restarts. Conlog frequently changing channels report attached.

Non-image files attached to this report
H1 PSL (PSL)
sudarshan.karki@LIGO.ORG - posted 14:27, Thursday 29 January 2015 - last comment - 14:33, Friday 30 January 2015(16347)
ISS Second Loop

Summary:

I was able to close the ISS Second Loop few times this morning. The loop performance was on-par with what we achieved when we locked it last time. The picomotor closed to the ISS PD array was also moved to optimize the light on the ISS PDs and the QPD

Details:

Noticing that the ISS QPD pitch and yaw were off, I moved the picomotor closer to the ISS array to optimize the light on the PDs and the QPD. This work improved the light on half of the PDs by about 10-20% . This also improved the beam position on the QPD. Before and after readings are listed:

  Before (cts) After(cts)   Before (cts) After(cts)
PD1 4430 4460 PD5 4600 5400
PD2 4150 4900 PD6 4700 5000
PD3 4750 4800 PD7 5750 5780
PD4 5050 5300 PD8 5300 5380

 

  Before After
QPD_PIT 0.73 0.08
QPD_YAW 0.75 0.01
QPD_SUM 24400 24300

I was able to close the loop without kicking the IMC out of lock. This was not robust and the previously used script wouldnot work because the second loop output fluctuation was much bigger than that we used as threshold in the script. Rather changing the script, I would want to investigate why we are not able to obtain the same robustness that we previously had. The loop performance is on par with what we have achieved in the past. With the loop closed and boost and integrator on, RIN was about 2E-8/sqrt(Hz) at 10 Hz . The attached plot shows the loop performance at different configurations.

Images attached to this report
Comments related to this report
sudarshan.karki@LIGO.ORG - 14:33, Friday 30 January 2015 (16378)

For people interested in what the loop performance was downstream. Here is a plot that shows the loop performance at IM4_TRANS and MC2_TRANS. The loop closing is still not robust because of too much noise at the second loop ouput but I am working on understanding it.

Images attached to this comment
H1 ISC
eleanor.king@LIGO.ORG - posted 12:47, Thursday 29 January 2015 (16345)
DHARD WFS

Kiwamu, Rana Elli

Last night we comissioned Dhard WFS.  We were engaging the DHard WFS (H1:ASC-DHARD_P and H1:ASC-DHARD_Y) after the DARM handover from DIFF to AS45 had taken place. 

The WFS use signals from AS_B_RF45_PIT and YAW, and we set  H1:ASC-AS_A_RF45_Q_YAW_GAIN and H1:ASC-AS_A_RF45_Q_PIT_GAIN to 1.

We were engaging the WFS with the following settings:  (This is in the guardian but hasn't been tested yet.)

        ezca['ASC-AS_B_RF45_WHITEN_GAIN'] =  3   (we changed this from 0 to 3dB)
        ezca['ASC-INMATRIX_P_8_6'] =  1
        ezca['ASC-INMATRIX_Y_8_6'] =  1
        ezca['ASC-DHARD_P_GAIN'] =  0.003
        ezca['ASC-DHARD_Y_GAIN'] =  0.003
        ezca['ASC-OUTMATRIX_P_7_8'] =  1
        ezca['ASC-OUTMATRIX_P_8_8'] =  -1
        ezca['ASC-OUTMATRIX_Y_7_8'] =  1
        ezca['ASC-OUTMATRIX_Y_8_8'] =  1
        ezca.switch('ASC-DHARD_P', 'FM1', 'FM2', 'FM3','FM6','FM7', 'ON')
        ezca.switch('ASC-DHARD_Y', 'FM1', 'FM2', 'FM3','FM6','FM7', 'ON')
        ezca.switch('ASC-DHARD_P', 'INPUT', 'ON')
        ezca.switch('ASC-DHARD_Y', 'INPUT', 'ON')

Where FM1 is 10dB gain, FM2 is 20dB gain, FM3 is z1p0 integrator, FM6 is an approximate inverse of the suspension response with a sneaky 1e-5 gain thrown in  (zpk([1],[50+i*86.6025;50-i*86.6025],1,"n")gain(1e-05)), FM7 is a 1Hz low pass filter.

H1 SEI
hugh.radkins@LIGO.ORG - posted 12:15, Thursday 29 January 2015 (16342)
H1 HEPI Pump Servo Pressure Sensor Noise

The pressure sensor noise is not a function of the cable run or the satellite amplifier.

See attached--60 days of sensors in PSI.  The channels are in order: 1) The low pressure return at BSC2, 2) the high pressure supply at BSC2,[these two signal are amplified at the BSC and then run ~120ft to the ADC,] 3) The 'CALC' difference of the previous two--this channel is what the servo controls, 4) the Main Supply line pressure after all the Pump Stations [In parallel,] 5 & 6) the final pressure on two Pump Stations before joining the Main Supply Line.

Again, the first two channels are the remote sensors traveling ~120ft to the ADC.  Channel 3 is the difference of the first two.  The last channels travel <20ft to the ADC.

I've zoomed the graphs to be all the same and the noise level on the far sensors is not more noisy than the close sensors.  Channel1, the return pressure signal in fact appears to be the least noisy.  I don't see the difference there to be too signiicant but maybe it is.

One thing that is clear is seen in channel 3.  Before the large shift to 70psi on 14 January, that calc record was servoing on the Main Supply Pressure, Channel 4.  Now that the Differential channel is actually a difference of two channels, its noise has increased.

Finally, the actual quieter nature of these channels is just seen at the beginning of the traces on Channel 3 4 & 5.  Before this time, the remote sensors from BSC2 were not available.  This shift in the noise occurred whilst I was connecting up  these channels.  Somehow at that time when I was shifting cables around to dress them, a cleaner environment was lost.  I have tried to put everything back to as it was, that is, reconnecting the unused terminal to the servo computer etc but no luck.  Maybe the ground is floating around or something but it isn't clear.

Further, see the second plot.  Here is 65 days of the differential pressure and the output of the servo driving the motor speed.  This VOUT would be flatlined when the servo is not on.  My clear recollection of this 'quiet' period is that the VOUT might change 1 digit every few seconds, not several counts every second.

Images attached to this report
H1 CDS
daniel.sigg@LIGO.ORG - posted 12:13, Thursday 29 January 2015 (16343)
New shutter code for AS

New code was loaded into h1ecatc1 which required a restart of the associated plcs.

H1 ISC
kiwamu.izumi@LIGO.ORG - posted 11:12, Thursday 29 January 2015 - last comment - 11:26, Thursday 29 January 2015(16340)
some maintenance in initial alignment

Ed and Kiwamu,

In the morning of today and yesterday, we went through all the initial aligment steps. In the course of the process, we found that there were a few settings that were hidden and not set correctly. So we made a couplle of modifications on the guardians and filter in order to automate them:

The attached screenshot shows the current good settings in order to go through the alignment sequence. This configuration should be automatically achieved by the guardians.

Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 11:26, Thursday 29 January 2015 (16341)

Some additional notes:

We found two failure modes which we did not get a chance to fix the guardians. I will have a close look at them tomorrow morning or next week.

  • ISC_DRMI for some reason did not set the PSL power back to the nominal of 10 W even though we requested the DOWN state.
  • When locking PRX, LSC_CONFIGS got stuck in LOCKING_PRX even though ASAIR_A_LF exceeded the threshould value.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 01:47, Thursday 29 January 2015 - last comment - 09:08, Friday 30 January 2015(16335)
CARM at ~30 pm

Kiwamu, Elli, Alexa, Evan, Rana, Daniel, Sheila

Today we were able to reach CARM offsets around 30 pm.  

We transitioned DARM to AS45Q, at a CARM offset where sqrt(TRX+TRY) was -7, we then normalized the signal by sqrt(TRX) (with a factor of 0.23).  One important step in getting there was to implement the ezca servo that adjusts the ALS DIFF offset to bring AS45Q into the linear range.  We are now using that both at a CARM offset of 1 (in SQRT TRX+TRY), and after we transition to the QPDs.  We then change the DARM loww pass filter from a 33Hz low pass to a 80 Hz low pass, to get better phase margin since we are no longer saturating the ESD with ALS noise.  We did this transition several times sucessfully.  As Rana mentioned in alog 16334, we installed an ND1 filter on ASAIR A.  Since this we haven't transitioned to RF DARM again (for reasons that seem to be unrelated to the ND filter), so we will need to check the gain before we transition again. 

After making this transition, Elli, Kiwamu and Rana worked on the DHARD WFS, which we turned on to reduce the fuctuations in AS DC.  This allowed us to go to CARM offsets -25 in sqrt(TRX+TRY), which is about half of the total power we expect in the arms.  If you assume that the recyling gain is 30 (we don't really know) it is something like 30 pm.  In Refl DC we saw the power drop by about 20%.  We saw that the linearized REFL 9 I signal had turned over, and that without linearization the signal had reached the peak.  We made a few attempts to transition, and we were able to turn down the gain of the TR CARM signal to 50% of the nominal and turn the REFL 9 signal to what we think the nominal gain should be (-100 in the input matrix).  We lost the lock when we turned off the TR CARM signal.  Our next plan was to leave the TR CARM engaged with reduced gain, and keep reducing the CARM offset.  

However, we have been having a hard time locking in the last few hours.  We think that it might help to try transitioning to DARM to RF a little sooner, so that we could use WFS.  

The sequence that was working earlier this afternoon is in guardian up to the RF DARM transition, although this might need to be re-worked.  We have added but not tested a state for the DHARD WFS. 

Attached is a screenshot of our striptool durring the sequence, which was all handled by the guardian this time.  

Images attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 02:06, Thursday 29 January 2015 (16336)

As we were about to leave we had a nice stable lock. We were able to transition to RF DARM again at -7.0 cts CARM offset after having adjusted for the ND filters. We now have a +20dB filter in ASAIR_RF45Q, and the input matrix is now 25. We turned on FM4(z4^2:p1^2) in DARM loop which significantly helped the DARM noise. We then proceeded to adjust the CARM offset to -20 cnts. At this point we transitioned TR_RELF9 to 100% with TR CARM at 50%. We were able to reduce the CARM offset to zero, but this only lasted for about a second or so. We never fully turned off TR CARM,  but we think it has a zero slope here since we are at zero offset. More tomorrow when we are awake ....  

 

Lock loss time: 09:58:40 UTC Jan 29th

gabriela.gonzalez@LIGO.ORG - 05:28, Thursday 29 January 2015 (16337)
Great work!
lisa.barsotti@LIGO.ORG - 10:59, Thursday 29 January 2015 (16338)ISC
Assuming I am looking at the right lock attempt, (data attached starting at 09:48:00 UTC) it seems that REFL DC is only ~30% less than at the beginning of the sequence when you transition to RF. There should be room to get closer. 

P.S: For comparison, trend of powers with "lossy" arms is here. The build up in the arms for same relative REFL DC power was about a factor of 3 lower (by eye numbers).
Non-image files attached to this comment
evan.hall@LIGO.ORG - 18:50, Thursday 29 January 2015 (16344)

Daniel and Rana have mentioned that optical torques may become significant as we come in to resonance.

Summary

For 10 mm of miscentering and 46 kW of circulating arm power (at 0 pm of CARM offset), we get a torque of 3×10−6 N m. I estimate the stiffness constants of each pendulum to be 4.9 N m for pitch and 6.5 N m for yaw (a better estimate could be made using the actual suspension models). This means that the static misalignments induced by the radiation torque could be as large as 1 μrad. The attached code computes the torsional stiffnesses of the pendula.

Details

  • For 8 W incident on the IFO with the PRM misaligned, we expect 0.12 W incident on each arm. Assuming an arm gain of 283 W/W, that gives 34 W of circulating power.
  • From LHO#15390, with the IFO locked we expect a buildup of 1350 W/W compared to the PRM-misaligned single-arm case. That gives 46 kW of optical power.
  • The torsional stiffness of the pendulum can be found by computing the moment of inertia of the test mass for pitch and yaw rotations. Combined with modeled torsional frequencies, the stiffness is given approximately by κ = ω2 I.

As a next step, we might also consider the stiffness of the optical springs using, e.g., eqs. 31 in the paper by Sidles and Sigg. At 46 kW of circulating power, we get 15 N m for the major mode and −0.6 N m for the minor mode.

[Edit: Also, Kiwamu has pointed out an error in the expression for the moment of inertia for the test masses. This has been fixed in this entry and in the attached code.]

Non-image files attached to this comment
evan.hall@LIGO.ORG - 14:37, Thursday 29 January 2015 (16352)

Here are some oplev trends from last night's final lock attempt.

The drop in the buildup of POP18 seems correlated with a drift in ETMX pitch (0.3 μrad), and to a lesser extent BS pitch (0.2 μrad), SR3 pitch (0.4 μrad) and ITMY pitch (0.2 μrad). There may also be some drift in PR3 yaw and pitch (≈0.1 μrad). All of these drifts happen on time scales much slower than the change in TRX buildup, which supports the idea that these are thermal drifts induced, e.g., by wire heating.

Non-image files attached to this comment
eleanor.king@LIGO.ORG - 14:25, Thursday 29 January 2015 (16351)

For the record here are some lock loss times from last night:

 

Early in the evening we were trying to transition DARM from ALS_DIFF to ASAIR_A_RF45_Q and the lock dropped at the following times:

Jan 28 20:46:40 UTC, Jan 28 21:06:32 UTC, Jan 28 21:06:17 UTC, Jan 28 22:55:00 UTC.

Speculating from the lock loss plots, we think that DARM noise causes a big spike in light leaking out of the AS port.  This causes the power on the  LSC-TR_X/Y_QPDs controlling CARM to fluctatue enough that CARM drops lock.  Running the ASAIR centering servo should help minimise big spikes at ASAIR_A_LF.  Once we were able to transition DARM to RF this type of lock loss stopped happening.

-----------------------

Here are some lock losses from after the transition DARM to RF.  The cause of these lock losses remained unclear.  MICH, PRCL and SRCL were ringing up signals at various frequencies (4Hz-20Hz) but this changed from lock loss to lock loss.  Again there are big spikes in ASAIR_A_LF right before the lock loss.  ETMy alignment needed frequent touching up.

Jan 29 00:28:31 UTC, Jan 29 00:49:41 UTC, Jan 29 05:34:23 UTC. 


--------------------

Later in the evening we were having  a hard time locking.  Again we were loosing lock before DARM transition to RF.  Again there are big spikes in ASAIR_A_LF, probably caused by DARM motion.

Jan 29 07:35:25 UTC, Jan 29 07:35:25 UTC, Jan 29 08:24:26 UTC, Jan 29 08:40:40 UTC

sheila.dwyer@LIGO.ORG - 14:51, Thursday 29 January 2015 (16354)

Here is a screen shot of the CARM offset reduction from earlier in the evening, when the alingment must hve been slightly better.  Although we didn't reduce the CARM offset, and were locked on TR CARM, we had a recylcing gain of about 10.2.  Also, some of the signal from POP18 and POP90 is rotated into the Q phase as CARM offset is reduced.  

Images attached to this comment
lisa.barsotti@LIGO.ORG - 09:08, Friday 30 January 2015 (16366)ISC
Peter, Matt, Lisa

For the records, we had this theory that if the f_1 was tuned such as to make the 2f_1 resonant in the arms, the beat between the 2f_1 and the carrier in the recycling cavity could be responsible for the decay in POP18. 
Looking in the L1/H1 logs and MEDM screens, we arrived at the conclusion that in H1, given the arm length of 3994.4704 m and f_1  = 9.100230 MHz, the offset from resonance for the 2f_1 should be 380 Hz.  
In L1 the offset for the 2f_1 from resonance is 500 Hz (reported here), as nominal.
H1 General (CDS)
rana.adhikari@LIGO.ORG - posted 17:56, Wednesday 28 January 2015 - last comment - 13:23, Thursday 29 January 2015(16333)
Auto-Scale for Big plots with Dataviewer: CDS Bug #377

To get bigger plots in dataviewer (i.e. getting the plot window to auto-scale) for both playback and 'real-time' plots, you can now just set up an option in your GRACE environment:

1) In your user directory make a directory called .grace:      mkdir .grace

2) Change to that directory:                                   cd .grace

3) Copy my gracerc file into your directory:                   cp /ligo/home/rana.adhikari/.grace/gracerc.user .

Now, when you restart dataviewer, you will have autoscaling.

BTW, this is described somewhat in CDS Bugzilla #377 from Tobin Fricke, Jim Batch, & Keith Thorne.

Comments related to this report
james.batch@LIGO.ORG - 12:56, Thursday 29 January 2015 (16346)
Note that the Realtime display suffers a bit when the "PAGE LAYOUT FREE" option is used to autoscale the plot windows.  As the attached screen shot shows, you no longer get the full plot in the window.  It takes some inconvenient fiddling to get the full plot displayed.
Images attached to this comment
rana.adhikari@LIGO.ORG - 13:23, Thursday 29 January 2015 (16348)

true enough - this is usually fixed by hitting stop and then start after first resizing the window. It usually undoes the cutoff plots, but sometimes it just leaves it bad...

H1 ISC
jim.warner@LIGO.ORG - posted 13:27, Wednesday 28 January 2015 - last comment - 13:39, Thursday 29 January 2015(16327)
Pop 18 trend showing window for last nights lock

Looks like lock was from about 9:14 UTC to 16:09 UTC. For posterity.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:39, Thursday 29 January 2015 (16349)DetChar, ISC, SEI, SUS
Also for posterity:
- This is a DRMI lock stretch.
- IMC WFS DOF4 is OFF
- No corner station WFS engaged. 
- ISS second loop is *OFF*. 
- 10 [W] input reqested. 
- SEI was in the most recent nominal configuration -- 
    HPI Pump Servo ON, 
    Sensor Correction to ISI XY and HEPI Z, 
    (no ST0-1 Feed Forward yet), 
    Using 01_28 blends on the HAM ISIs, 
    "45 [mHz]" X&Y, LLO blends on BSC ISIs.

Great for offline, data-mining studies of
- Gain Problems with STS2B
- HAM3 0.6 [Hz] feature
- Coherence with HPI Pump Pressure.
- DAC major-carry transition glitches.
- Cavity performance with respect to SEI performance.
- Lock Loss statistics

Among other things...
Displaying reports 61361-61380 of 77278.Go to page Start 3065 3066 3067 3068 3069 3070 3071 3072 3073 End