Displaying reports 69221-69240 of 84565.Go to page Start 3458 3459 3460 3461 3462 3463 3464 3465 3466 End
Reports until 17:21, Sunday 21 December 2014
H1 ISC
stefan.ballmer@LIGO.ORG - posted 17:21, Sunday 21 December 2014 - last comment - 17:36, Sunday 21 December 2014(15772)
SR3 YAW loop now at high bandwith too (SR3 pitch not yet)
Evan, Stefan

With the winds calming down again, we did some more SR3 alignment work:
- We noticed that for SCR1_Y AS B 36 I is still the best signal. It has
   - less "phase lag", presumably due to a reduced coupling to the BS. This allows us to do a high bandwith loop.
   - a small enough offset that servoing it to zero makes sense for reducing build-up fluctuations.
- Thus we closed the yaw loop with a UGF of 3.3Hz. Engaging it is in the Guardian.
- We tried to play the same game for the pitch loop, with less sucess.
   - all signals have some RF offset.
   - none of the signals seem to have low enough "phase lag" for a high BW loop. We should make sure this phase lag is not due to some broken whitening filter.
- Thus for now we left pitch in the configuration described in alog 15769.

Evan is now also updating the WFS relieve.

We will leave DRMI locked for the night.

Comments related to this report
evan.hall@LIGO.ORG - 17:36, Sunday 21 December 2014 (15773)

The DRMI guardian has a new version of the OFFLOAD_DRMI_ASC state. This uses the script offloadOpticAlign.py, which slowly bleeds off the M1 lock outputs of PRM, PR3, BS, SR2, SR3, SRM, and IM4 to their respective alignment sliders.

H1 AOS
robert.schofield@LIGO.ORG - posted 16:07, Sunday 21 December 2014 (15771)
PSL incursion associated with ISS instability

I went into the PSL to check out possibilities for redoing the top periscope piezo mirror mount, which I think is responsible for the 250 Hz peak in DARM at LLO (Link). The secondary purpose was to check the recovery time for a 10 minute incursion. The IMC did not loose lock but suffered intensity spikes beginning when I went in, and quickly dissapating so that they were gone by an hour after I left. The plots show MC2 TRANS and ISS_AOM_DRIVER_MON in an overview and a zoom into one of the intensity spikes. The zoom suggests ISS oscillations. The step in MC2 TRANS was when Evan, seeing the spikes, shut down the gaurdian. 

Robert, Evan

Non-image files attached to this report
H1 ISC
stefan.ballmer@LIGO.ORG - posted 20:03, Saturday 20 December 2014 - last comment - 20:07, Saturday 20 December 2014(15769)
more on DRMI ASC
Elli, Thomas, Stefan

- We found that the DRMI build-up fluctuations reported in alog 15765 were mostly due to a small offset in the WFS locking point for the SRC (feed back to SRM yesterday, switched to SR3 today).
- We fine-tweaked the input matrix mixing signals from AS36 A (orthogonal to the BS signal) and AS36 B (I&Q), such that we maximize the SR3 signal and get a good locking-point offset.
  The matrix is:
    AS A RF36I -0.45
    AS A RF36Q  0.89
    AS B RF36I  1.1
    AS B RF36Q -0.77
  This was found for pitch. Yaw was confirmed to be close, but wind prevented further fine-tuning. Using this significantly reduced the build-up fluctuations.

- Next we commissioned the a high BW loop for SR3. The filters are
    PIT: zpk([0.06+i*0.815;0.06-i*0.815;0.3+i*3.25;0.3-i*3.25],[0.3+i*2.87;0.3-i*2.87;11.1111+i*38.4258;11.1111-i*38.4258],1,"n")
    YAW: zpk([0.13+i*1.24;0.13-i*1.24;0.15+i*2.88;0.15-i*2.88],[0.15+i*2.48;0.15-i*2.48;11.1111+i*38.4258;11.1111-i*38.4258],1,"n")
  They were successfully tested up to a UGF of 6Hz using an optical lever. However, on the WFS we could not go that high because there was significant cross-talk from the other loops.
  Thomas will attach a measured transfer function.

- We left the feed-back on SR3 (the guardian sets this up), but with maybe 10 times lower BW.

- We also noticed that the high BW WFS cause more violent lock losses. We thus put (generous) limiters to all the top stages.

Unfortunately the winds are at 60mph again, so we won't leave it locked tonight.

Comments related to this report
thomas.vo@LIGO.ORG - 20:07, Saturday 20 December 2014 (15770)

Pit and Yaw TFs for high bandwidth filters mentioned above.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 08:49, Saturday 20 December 2014 (15767)
reconfigured conlog to remove noisy Y TUNEOFS channel

I have reconfigured conlog to remove the constantly noisy H1:ALS-Y_VCO_TUNEOFS and the 2 disconnected channels. Details are:

 

+ H1:ALS-X_WFS_AUTOC_SWITCH

+ H1:ALS-Y_WFS_AUTOC_SWITCH

- H1:ALS-X_WFS_AUTOC_SWTCH

- H1:ALS-Y_VCO_TUNEOFS

- H1:ALS-Y_WFS_AUTOC_SWTCH

inserted 2 pv names

deleted 3 pv names

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:22, Saturday 20 December 2014 (15766)
CDS model and DAQ restart report, Friday 19th December 2014

model restarts logged for Fri 19/Dec/2014
2014_12_19 11:28 h1fw1
2014_12_19 14:48 h1hpiham3
2014_12_19 14:49 h1isiham3

h1fw1 unexpected restart, SEI HAM3 restarted to see if it would fix a problem. Conlog frequently changing channels report attached.

Non-image files attached to this report
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 00:51, Saturday 20 December 2014 - last comment - 19:45, Saturday 20 December 2014(15763)
more DRMI alignment

Stefan, Kiwamu,

We did some more ASC optimizations tonight in DRMI. We are leaving the DRMI locked overnight to see what drfits on a time scale of hours.

 


Here is a list of what we did:

All the modifications and new loops are coded in not only in the ISC_DRMI guardian but also ISC_DOF guardian so that they do not mess up the initial alignment WFSing.

Comments related to this report
stefan.ballmer@LIGO.ORG - 00:57, Saturday 20 December 2014 (15765)
Here are two plots of POP18 & POP90, and POP90 & AS90.

The RIN fluctuations are:
POP18: 2.2% peak-to-peak
POP90:   8% peak-to-peak
AS90:  0.8% peak-to-peak
Images attached to this comment
thomas.vo@LIGO.ORG - 19:45, Saturday 20 December 2014 (15768)

Lock lost at 1103105129 ~ 2014-12-20-10-04 UTC

Attached are some trends leading up to the loss of lock, it lasted for about 2 hours.

 

It looks like something could have rung up the input to th WFS servo loops and this caused some instability,  I've attached some trends that show the in/outs of the ASC WFs at tthe time of unloking but it's hard to tell who's the culprit exactly.

Images attached to this comment
H1 ISC
daniel.hoak@LIGO.ORG - posted 19:48, Friday 19 December 2014 (15762)
some OMC alignment work

Last night I tried a new loop topology for the OMC alignment servos, using the inputs to the OMC SUS that were added to the model a few weeks ago.

The idea here is to diagonalize the DC alignment in HAM6, using OM1 and OM2 for the centering on the AS WFS, and use OM3 and the OMC SUS for the centering into the OMC.

I measured the sensing matrix for OM3,OMCS {P,Y} --> OMC-ASC ANG,POS {X,Y}, took the inverse, and used this for the output matrix (DOF2TT).  This kind of worked; I was able to close all four loops and engage the AS WFS DC centering in parallel.  But the centering on the OMC wasn't very stable, and turning on the integrators caused an instability in the yaw loops.  I think the problem is that we're using loops designed for the tip-tilts to actuate on a 2-stage suspension; a better approach is to invert the OMC SUS --> OMC QPD transfer function and put this into the OMCSUS ASC filter banks.  But, my earlier fear that the OMCSUS actuation was too weak doesn't appear to be true.  This scheme should work once we account for the complications in the OMC SUS transfer function.

A screenshot of the output matrix from ANG,POS --> OM3, OMCS is attached.  You can see that the OMCS is 1000x weaker than the tip-tilt.  For now I have reverted to the old configuration, which uses OM1 and OM2.

After I reverted back I noticed that the dither loops had developed an instability!  They were stable as recently as 10 days ago, according to conlog nothing had changed.  We'll need to investigate the dither alignment chain in the new year.

Images attached to this report
H1 AOS
paul.fulda@LIGO.ORG - posted 19:40, Friday 19 December 2014 (15761)
PRC aux laser measurement: preliminary results from HOM sweeps

[Mackenzie, Eleanor, Paul]

This afternoon we got the PLL aux laser measurement up and running, and fortunately this happened to coincide with a locked DRMI. 

We were initially able to observe the FSR dips, as we had seen them previously. We decided since we had the benefit of a locked DRMI we would try adding the clipping objects in the aux laser input path, and also in front of the REFL AIR B diode that was used to detect the beat note between the aux laser reflected from the PRM and the PSL beam reflected from the PRM. 

We observed new features in the transfer function, which are likely candidates for higher-order mode resonances. Attached are two preliminary plots of sweeps close to two FSR HG00 resonances.

A very quick calculation of the PRC one-way Gouy phase from these data is as follows:

HG00 peak resonance frequency - HG10 peak resonance frequency = 0.3MHz.

Fraction of FSR = 0.3/2.6 = 0.1154.

Convert to degrees one way Gouy phase: 0.1154*180 = 20.77degrees.

With the ITMs that are currently installed, we expect a one-way Gouy phase in the PRC of about 18 degrees (with no ITM thermal lensing). Design value accounting for thermal lens in ITMs from 18W input power and 0.5ppm absorption on the ITM HR surface is 25 degrees. 

Worth noting is that the DRMI was locked during this measurement, not the PRMI. It's not clear to me yet how this affects the results – maybe not much. Also, evidence for the additional peaks really being due to HOMs is the repeated resonance a further 3MHz away from the HG00 resonance, which I expect is the HG11+HG20+HG02 mode resonance. More precise analysis and measurements to follow. 

Non-image files attached to this report
H1 SEI (ISC, SYS)
jeffrey.kissel@LIGO.ORG - posted 16:29, Friday 19 December 2014 - last comment - 18:17, Sunday 11 January 2015(15756)
Bad GS13 Gain Guardian Switching vs Watchdog Loop
J. Kissel, K. Venkateswara, K. Izumi, J. Warner

While Kiwamu was trying to lock the Michelson, several things went wrong, but it uncovered a flaw in the new gain switching of the GS13s that has been implemented in the Guardian (see LHO aLOG 15537. Here's what happened.
(1) Kiwamu incorrectly brought up the BSC ISI in "fully isolated," which turns on stage 2 isolation loops, and switches the GS13s to high-gain mode.
(2) As expected, while trying to acquire MICH lock, impulses sent to the SUS BS kick the cage as well, which is attached to the BS ISI ST2, and trips the ST2 on the GS13s watchdog.
(3) We then reset the watchdog, and switched to "isolated damped," and this triggered the new guardian feature to *start* switching the GS13s back to low gain, but with MICH still trying to lock, impulses would still trip the watchdog before guardian had the chance to switch *all* of the GS13s gains. 
(4) This, trigger-happy watchdog resetting, and guardian half transitioning, caused a nasty loop of guardian sloshing the GS13 gains back and forth between high and low, which, with MICH impulses, continued to trip the watchdog.

I attach a plot of one of the WD trip, which clearly shows that the V3 GS13 had failed to have its gain switched to low. 

We should 
(a) look the new code to make sure there isn't a bad loophole regarding the GS13 gain switching when transitioning from "fully isolated" to "isolated damped"
(b) look for ways to increase the switching speed, or add a pause / check that the switch has occured on all GS13s before proceeding with the transition
(c) remember that these are physical, several thousand pound systems -- if you have to reset watchdogs repeatedly something is wrong and you don't know why, don't just blindly continue to mash the reset button, figure out what's wrong, or do what Kiwamu did and ask an expert!

#justwait
Images attached to this report
Comments related to this report
hugo.paris@LIGO.ORG - 09:40, Friday 09 January 2015 (15961)

The GAIN and DWT filters' switching mode is set to zero-crossing, with a time-out of 2s (see attachement). Even though Guardian engages the filters properly, they don’t actually switch until a certain time, causing MICH to start acquiring lock before the ISI is ready for it.

This could be solved by selecting the immediately switch mode for the GS13 GAIN and DWT filters. But, after discussing it with Jeff yesterday it turned out that he recalled switching gains with the ISO on, which would be way less stable without zero-crossing.

I modified the SEI guardian to add a 3s wait at the end of the gain switch sequence to give the filters the time they need to switch with the current zero-crossing configuration, before allowing MICH to start acquiring lock.

This fix should be tried next time we start acquiring lock on MICH.

Non-image files attached to this comment
hugo.paris@LIGO.ORG - 18:17, Sunday 11 January 2015 (16007)

Jeff, Hugo,

The SEI guardian patch I made was tested today. Jeff locked MICH while SEI_BS was in the ISOLATED_DAMPED state (GS13 in low-gain). Once MICH was locked, we switched SEI_BS to FULLY_ISOLATED (GS13s in High Gian, and ST2 Iolation loops turned on). The ISI did not trip, and MICH remained locked.

In order to make sure that this was ra reliable fix, we went ahead and switched the state of the SEI_BS node back and forth between ISOLATED_DAMPED and FULLY_ISOLATED a couple times. Once again, the ISI did not trip, and MICH remained locked.

Time series of the state of the SEI_BS Guardian node, versus the MICH error signal, are attached

 

The updated  code was commited under the SVN:
/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/util.py     -r9543

 

Note: Jamie gave me good feedback on how to improve this new code. The goal here was to make sure it works. I will optimize it once I am back at Stanford.

Images attached to this comment
H1 AOS (ISC)
eleanor.king@LIGO.ORG - posted 16:19, Friday 19 December 2014 - last comment - 14:58, Thursday 14 May 2015(15758)
PRM high bandwidth filters

Thomas, Stefan, Jeff, Kiwamu, Elli

Continuing along the same line as yesterday's work on PR3 (alog 15727), we have designed high-bandwidth (<10Hz) actuation filters for the PRM.  These filters are applied to H1ASC-PRC1P and H1ASC-PRC1Y in the central part of the ASC WFS servo.

The filters added to ASC WFS central are called 'PRM^-1' and are:
H1:ASC-PRC1_P:   zpk([0.2+i+0.9;0.2-i*0.9;0.05+i*3.41;0.05-i*3.41],
                [0;0.2+i*2.75;0.2-i*2.75;0.125+i*9.99922;0.125-i*9.99922],1,"n")
H1:ASC-PRC1_Y:     zpk([0.04+i*1.08;0.04-i*1.08;0.1+i*2.08;0.1-i*2.08;0.05+i*3.43;0.05-i*3.43],
                [0;0.15+i*1.8;0.15-i*1.8;0.05+i*3.3;0.05-i*3.3],1,"n")
Some old unused filters were also removed.


Low-pass filters called 'RLP17' were added to the PRM M3 locking filters in pitch and yaw:
H1:SUS-PRM_M3_LOCK_P:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")
H1:SUS-PRM_M3_LOCK_y:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")

Comments related to this report
thomas.vo@LIGO.ORG - 18:27, Friday 19 December 2014 (15760)
After getting the hang of creating some of these filters and we werestrongly encouraged to write a detailed proceudre:
 
1. Create a white noise, M3 to M3 transfer function using the templates located in /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM3/Data, you can actually use any bottom stage sensor that is available, OSEMs or OptLevs but on PRM, we're only let with the OSEM option.
 
2. The idea is to use the transfer function and then add zeros and poles using the calibration feature in DTT to roughly get a filter than will give you the damped motion you're looking for with the correct phase without waiting for measurements to run everytime you're changing the Q or freq of the pole/zero:
We start by finding the frequency of the lowest resonance and then this will give us an idea of the complex portion and then we eyeball a Q depending on the original transfer function's Q.  By shifting the complex portion of the zero, we attempt to get the correct phase and dither by hand until we roughly supress the resonance with 30-35 degrees phase margin.  We move on with the same procedure for the higher frequency measurements, creating poles and zeros when necessary.  Attached is a before and after look at the transfer function.
 
3. Now that we have the right idea for the ZPK values, we can create a filter module in the ASC WFS Servo Control.  For PRM the correct filter is h1ASC-PRC1 and so we just copied the new filter values into foton and then test by first locking PRMI and then ramping the gain slowly and watching if the DAC saturates or the PRMI breaks lock.  If it doesn't break lock we can tell that our loops are unconditionally stable and then retake OL transfer functions with the new filters in place to see if we're adding any new noise.  Then you're pretty much done.​
Non-image files attached to this comment
stefan.ballmer@LIGO.ORG - 00:44, Saturday 20 December 2014 (15764)
I had to sighly correct the filters to make them stable. Attached is what we now have running.

The filters are:
PITCH: zpk(  [0.1+i*1.02;0.1-i*1.02;0.12+i*3.35;0.12-i*3.35],  [0.12+i*2.75;0.12-i*2.75;11.1111+i*38.4258;11.1111-i*38.4258]  ,1,"n")
YAW:   zpk(  [0.015+i*1.09;0.015-i*1.09;0.03+i*2.05;0.03-i*2.05;0.02+i*3.43;0.02-i*3.43],  [0.05+i*1.75;0.05-i*1.75;0.02+i*3.25;0.02-i*3.25;11.1111+i*38.4258;11.1111-i*38.4258],1,"n")

Images attached to this comment
betsy.weaver@LIGO.ORG - 14:58, Thursday 14 May 2015 (18430)

Note, commissioners (Kiwamu/Evan) report that they turned these filters off ~April 21st, 2015 since they were no longer needed.  Filters now off are PRM M3 LOCK P and Y FM9 (RLP17).  SDF has been updated.

H1 CDS
david.barker@LIGO.ORG - posted 16:06, Friday 19 December 2014 (15755)
restart of h1isiham3 and h1hpiham3

Fabrice, Hugh, Dave:

we restarted the models h1isiham3 and h1hpiham3 as part of the seismic investigation of this chamber. No new filters, code or daq configuration were applied, this was a simple restart.

LHO VE
kyle.ryan@LIGO.ORG - posted 16:00, Friday 19 December 2014 (15754)
Halted pumping of Y-end -> Will resume Monday


			
			
H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:59, Friday 19 December 2014 (15753)
Ops Shift Summary
LVEA: Laser Hazard
Observation Bit: Commissioning  

08:00 Cris – Delivering garb to End-X
08:40 Doug – OpLev work at HAM4
08:51 Kyle & Gerardo – Roughing BSC10
09:00 Betsy, Travis, & Rick – At End-X
09:10 Fabrice – BS & HAM3 Testing
09:13 Filiberto & Aaron – PEM cabling work in the Beer Garden
09:30 Karen – Going to End-Y
09:55 Kyle & Gerardo – Back from End-Y
10:18 Jim – Going to End-X to unlock HEPI & ISI
10:30 Shutdown dust monitor at HAM1
10:36 Karen – Back from End-Y
10:40 Dale – High School tour in control room
11:19 Dave – Going to End-Y to adjust cameras
11:21 Jim – Back from End-X
11:45 Betsy, Travis, & Rick – Back from End-X
12:50 Jim – Going to End-X to unlock HEPI
12:52 Filiberto – PEM and cabling work in Beer Garden and along spool arms
13:50 Dave – At End-X to adjust cameras
14:02 Kyle, Gerardo, & Bubba – End-X Install West door, connect pump cart and pump annulus
14:05 Dave – Back from End-X
14:44 Filiberto – Out of the LVEA
14:47 Dave – Restarting HAM3 models
15:28 Rick – Taking Mike R. and friend on tour of LVEA
15:40 Kyle, Gerardo, & Bubba – Finished with BSC9 door install, started pumping annulus 
H1 SEI (SEI)
fabrice.matichard@LIGO.ORG - posted 15:52, Friday 19 December 2014 - last comment - 15:42, Monday 05 January 2015(15751)
More HAM3 Investigation

Jim, Hugh, Krishna, Jeff, Fabrice:

 

We keep investigating the sensor corrction issue on HAM3. What we found yesterday is that it depends on which blends are engaged. We can't explain why yet. We did additional tests today:

- we turned off all CPSs of all HAM-ISI and BSC-ISI in the corner station. No change.

- we checked the jumpers of all HAM3 CPS boards. All good.

- we tried to apply large offset in case it would reduce some kind of cable touching/rubbing (+/-400 um in HEPI Z, and +/-400 um in ISI X,Y, Z). No change.

 

Finally, we tried to do the Z sensor correction to HEPI. In the plot attached:

- Red curves is HAM3 ISI isolated, no sensor correction

- Green Curve, we turn ON the sensor correction in X and Y to the HAM-ISI

- Blue Curve, we also turn on Z sensor correction to ISI. The 0.6 HZ peak shows up. For some reason it also reduces X at the microseism.

- Brown, we do the Z sensor correction to HEPI instada of ISI. The peak is still there in the CPS, but not in the GS13. It's unclear why.

 

The last configuration looks good from the GS13s,  but it's unclear yet how good it is for the cavity. More info on that is coming.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:21, Friday 19 December 2014 (15759)DetChar
One more thing that Fabrice forgot to mention in this recap:
   - they restarted the front-end processes for H1ISI and HPI HAM3 (see 15755) -- and also saw no change.

Perhaps during a future maintenance day, we can hard-reboot the entire chassis.

Some further speculation / questions: 
- That we *don't* see the feature in the GS13s when we're in low-frequency blend when we feed Z sensor correction to HPI (but we still see the feature in the CPS) rules out the GS13s as the source of the problem.
- The 0.6 [Hz] feature is modifiable by changing the RX / RY blend filters -- higher blend frequency means less 0.6 [Hz] feature. RX/RY implies it's a differential vertical noise, in that one of two of the three CPS are causing the problem. 
- Higher blend means more CPS is being used. Wouldn't you think that if the problem is in the CPS, then using more of them would make the problem worse?
- Could it be some subtle, small electronics cross-talk between the STS and the CPS that goes into oscillation? 
- We're grasping at straws. This stinks.

@DetChar -- I know it's impossible to figure out the state of the ISIs offline, but can you track this chamber over time and see at least how long we've seen a 0.6 [Hz] feature? 
It might take Keith Riles type *days* worth of averaging to find it...
It would be also good take Keith Riles type high-resolution ASDs to find out how sharp the feature is, and to quantify how the heck 1.12 [Hz] is related to 0.6 [Hz]...
jim.warner@LIGO.ORG - 15:42, Monday 05 January 2015 (15875)

In case detchar people are curious about the configuration of this chamber over break, when I came in this morning I found the ISI in what we thought was the good state in December. That is, X&Y sensor correction on the ISI, Z on HEPI and normal blends, isolation loops. I doubt anyone changed the configuration since the 19th of December.

Displaying reports 69221-69240 of 84565.Go to page Start 3458 3459 3460 3461 3462 3463 3464 3465 3466 End