Displaying reports 55881-55900 of 83394.Go to page Start 2791 2792 2793 2794 2795 2796 2797 2798 2799 End
Reports until 14:38, Friday 08 July 2016
H1 ISC
edward.daw@LIGO.ORG - posted 14:38, Friday 08 July 2016 (28272)
Parametric Instability Doublet Control with IWAVE - cross-subtraction technique - Ed Daw, Tega Edo
Here are results on a study of using iwave to control closely spaced doublets of sinusoids. This study was conducted on test data at 16384Hz sampling rate, of 100 second duration. The dataset consisted of two sine waves at 27.8 and 27.9Hz, each of amplitude 1, on a background of Gaussian white noise of RMS 0.1. Two iwave configurations were used to try and subtract the two components. In both schemes, iwave was running with a tau parameter of 5 seconds and initial guess frequencies at exactly the line frequencies. Iwave was running in phaselocked mode. The loops on the lower and upper frequency lines were set to close 5 and 6 seconds into the dataset, respectively, although these time delays are unimportant; they could both have been set to zero just as well and I mention them for completeness.

CONFIGURATION 1: the raw data is injected into iwave1 set to track the lower frequency (27.8Hz). The D phase output of iwave1 is subtracted from the raw data, and the result is injected into iwave2, set to track the upper frequency (27.9Hz).  The D phase output of iwave2 is subtracted from the input to iwave2, and the difference is the final output. In other words, the two iwave filters are cascaded.

CONFIGURATION 2: the raw data minus the D phase output of iwave2, set to track the upper frequency line (27.9Hz) is used as the input for iwave1, set to track the lower frequency line (27.8Hz). The raw data minus the D phase output of iwave1 is used as the input for iwave2. In other words, for each iwave, the input is the result of the raw data with the D phase output of the other iwave subtracted. 

The first attached pdf shows the results of studies of the the two configurations; the first two pages are for configuration 1 and the pages 3 and 4 are for configuration 2. In each case, there are three plots - the extracted line amplitudes and frequencies (together on the same page), and amplitude spectral densities of the raw data, the data after the subtraction of the first line, and the the output data after both lines are subtracted. 

The 'cross-subtraction' technique is superior, having much better line attenuation and markedly less sidebands introduced. This is because iwave uses the product of the input data and the Q phase output to sense phase shifts, but when the input data is polluted by a close by line, this causes residual beats between this line and the q phase output in the phase measurement. You can see this on page 1, where both the inferred frequency of the line and its amplitude oscillate at the difference frequency between the two lines, which is 0.1Hz, or a 10 second beat. When each iwave input has the inferred line from iwave outputs on other loud lines removed before input, this distortion goes away. 

I have attached a schematic of the cross subtraction configuration, 2, as a second attached figure, in case the written description above is not clear enough. One detail is, the output of iwave2 which is then subtracted from the input data before injection into iwave1 must be derived from the previous sample of iwave2 output, and hence has to be phase shifted forward by one sample period to accurately subtract the line. This is easy to do using both the Q and the D phase outputs of iwave2, and the cos and sin of the phase shift per sample for the frequency of the line tracked by iwave2.
Non-image files attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 14:30, Friday 08 July 2016 (28281)
Manually over-filled CP3
1315 -1400 hrs. local -> To and from Y-mid (then X-mid, unrelated)

Opened exhaust check-valve bypass-valve.  Opened LLCV bypass-valve 1/2 turn -> LN2 @ exhaust in 55 seconds -> Restored valves to as found configuration.  

Next CP3 overfill to be Monday, July 11th.  
H1 GRD
jameson.rollins@LIGO.ORG - posted 12:15, Friday 08 July 2016 - last comment - 16:30, Friday 08 July 2016(28275)
IFO top node not monitoring some nodes

The IFO top node appears to be not monitoring some SEI BS and ALS nodes.  The IFO top node is reporting OK, even though multiple nodes are not reporting OK:

This is an indication of two issue:

The USERAPPS/h1/guardian/IFO_NODE_LIST.py that is in the SVN shows that those nodes should be managed, so my guess is that what's currently running has not been committed to the SVN.

Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 14:52, Friday 08 July 2016 (28283)

My advice would be to not focus too much on a potential O2 configuration, but focus instead right now on the ER9 configuration.  There's no problem in updating the NOMINAL states as needed.  They should be set to whatever is appropriate for ER9, and make sure they're all monitored by the top node.  We can then adjust things as needed for O2.

In other words, IFO should always be monitoring all nodes, and we should just adjust the NOMINAL state for each node to reflect whatever is the ideal IFO configuration at the moment.

jameson.rollins@LIGO.ORG - 12:23, Friday 08 July 2016 (28277)

I confirmed that the USERAPPS/sys/h1/guardian/IFO_NODE_LIST.py file has indeed been modified locally to remove monitoring of the SEI BS and ALS nodes, and that those changes have not been committed to the SVN.

jameson.rollins@LIGO.ORG - 12:31, Friday 08 July 2016 (28278)

Many guardian files have local modifications that have not been committed to the SVN:

jameson.rollins@operator1:~ 0$ guardlog list | xargs -l guardutil files 2>/dev/null | sort | uniq | xargs -l svn status
M       /opt/rtcds/userapps/release/als/common/guardian/ALS_COMM.py
M       /opt/rtcds/userapps/release/als/common/guardian/ALS_DIFF.py
M       /opt/rtcds/userapps/release/als/common/guardian/ALS_YARM.py
M       /opt/rtcds/userapps/release/ioo/common/guardian/IMC_LOCK.py
M       /opt/rtcds/userapps/release/isc/common/guardian/VIOLIN_DAMPER.py
M       /opt/rtcds/userapps/release/isc/h1/guardian/BOUNCE_ROLL.py
M       /opt/rtcds/userapps/release/isc/h1/guardian/ISC_DRMI.py
M       /opt/rtcds/userapps/release/isc/h1/guardian/ISC_library.py
M       /opt/rtcds/userapps/release/isc/h1/guardian/ISC_LOCK.py
M       /opt/rtcds/userapps/release/isc/h1/guardian/lscparams.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_BS_ST1_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_BS_ST1.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_BS_ST2.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ETMX_ST1_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ETMX_ST1.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ETMX_ST2.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ETMY_ST1_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ETMY_ST1.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ETMY_ST2.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_HAM2_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_HAM3_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_HAM4_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_HAM5_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_HAM6_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ITMX_ST1_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ITMX_ST1.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ITMX_ST2.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ITMY_ST1_CONF.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ITMY_ST1.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/ISI_ITMY_ST2.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/SEI_CONFIG/const.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/SEI_CONFIG/CS_states.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/SEI_CONFIG/HAM_states.py
M       /opt/rtcds/userapps/release/isi/h1/guardian/SEI_CONFIG/manager.py
M       /opt/rtcds/userapps/release/omc/common/guardian/OMC_LOCK.py
M       /opt/rtcds/userapps/release/sus/common/guardian/SUS_PI.py
M       /opt/rtcds/userapps/release/sys/common/guardian/IFO.py
M       /opt/rtcds/userapps/release/sys/h1/guardian/DIAG_MAIN.py
M       /opt/rtcds/userapps/release/sys/h1/guardian/IFO_NODE_LIST.py
jameson.rollins@operator1:~ 0$ 

jenne.driggers@LIGO.ORG - 14:15, Friday 08 July 2016 (28280)

The lack of monitoring some nodes was at my request.  These are nodes that currently are requested to be different from their true nominal state so that we can get diagnostic information (ALS nodes), or to avoid unneccessary potential locklosses (BS ISI node).  For O2, these will be placed back in their low noise nominal modes.  We removed them from the monitoring so that we would be able to set the Intent bit to Observe for the ER run.  Once ER9 is complete, we will uncomment the nodes so that they are back to being monitored.

We should indeed be better about checking things into the svn.

sheila.dwyer@LIGO.ORG - 16:30, Friday 08 July 2016 (28290)

I comitted these except for the isi ones

H1 General
vernon.sandberg@LIGO.ORG - posted 11:01, Friday 08 July 2016 - last comment - 15:07, Friday 08 July 2016(28273)
Return to 40 W Commissioning

We have operated for over 10 hours in "nominal low noise, observation, intent bit set" condition.  This was a temporary configuration to allow locking, after the laser diode box failure, for the purposes of testing ER9 pipelines. We are returning to 40W operation.  

Comments related to this report
keita.kawabe@LIGO.ORG - 15:07, Friday 08 July 2016 (28287)

(Cheryl, Sheila, Kiwamu, Haocun, Ross, Keita)

ISC_LOCK.py and lscparams.py were reverted so the target power is 40W and SOFT offsets are set correctly.

ISS offset was remeasured at 40W and set to -0.932693 (instead of the original -0.9826934814453125).

IMC_LOCK.py was changed to set this offset, and  also the final ISS 2nd loop gain was set back to 20dB for 40W  (instead of 24dB for 25W).

No change was made to TCS as nobody touched the TCS CO2 guardian yesterday.

IFO got back to the correct 40W nominal low noise state after the above change.

After this, SUS_PI was also changed (yesterday it was accidentally changed such that QPD and OMC-based damping were enabled for the same mode at the same time).

H1 General
cheryl.vorvick@LIGO.ORG - posted 09:34, Friday 08 July 2016 (28268)
H1 in Observe at 16:33UTC

H1 is in Observe at 25W.

H1 General
cheryl.vorvick@LIGO.ORG - posted 09:29, Friday 08 July 2016 - last comment - 09:56, Friday 08 July 2016(28267)
Morning Update:

State of H1: locked at 25W in ENGAGE_ISS_2ND_LOOP

Activities / Events:

Comments related to this report
cheryl.vorvick@LIGO.ORG - 09:56, Friday 08 July 2016 (28270)

Lockloss plots:

  • DHARD_P_OUT glitched 4 times in the last 18 seconds of the lock
  • DHARD_P_OUT rings up about 0.5 seconds before lock loss
Images attached to this comment
H1 General
vernon.sandberg@LIGO.ORG - posted 08:15, Friday 08 July 2016 (28265)
State of the IFO over the night

Upon my arrival (at 7:45 am PT) in the control room I found the IFO locked and in "Observation" mode with the intent bit set.  The Lock Clock showed 8:50 hours and counting.  The input power was 24.3 W.  Camera images looked stable and as expected. (Because the video5 computer had frozen! argh).  DARM ASD looked terrible, but not unreasonable for the operating condition of the IFO.  ISC_Lock Guardian was in Nominal Low Noise.

This is a better start of the day then we have had for awhile. This should allow the ER9 testing of the hwinj, cal, and data pipelines and, with the intent bit set, allow the analysis streams to test their readiness.

15:13 UTC (8:13 PT) - just lost lock. Morning activities?

H1 General
sheila.dwyer@LIGO.ORG - posted 01:07, Friday 08 July 2016 - last comment - 14:12, Friday 08 July 2016(28261)
Joint summary

Patrick, Sheila, Carl and Ross damping PIs

After Keita's ISS fixes we had a few hours of bad weather and earthquakes that contributed to dificulty locking.  Once things calmed down we locked and sat at several stages to see if the lock was stable, DC readout, 25 Watts, ISS 2nd loop engaged, and now we have made it to some kind of "nominal low noise" state.  Patrick hit the intent bit.  

There are several things wrong with this spectrum, some of which could be solved by going back to 40 Watts in the morning:

The last attached screenshot is just to show how many locking attempts everyone made in the last 14 hours. The range displayed by the DMT viewer in the control room seems to have a problem, it should be stable at some low range but on the DMT viewer it looks like we lost lock in the last half hour.  

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 01:38, Friday 08 July 2016 (28262)

Sheila's comment

There were several things which had to be done today because of the change to run ER9 at 25 Watts.  

  • Getting rid of soft loop offsets that were tuned to improve recycling gain at 40 Watts
  • setting ISS 2nd loop offsets
  • commenting out low noise ASC states
  • changing TCS CO2 guardians by hand

We should remember to undo these things as soon as we go back to 40 Watts.  According to Ross and Carl, there isn't a reason to think our PI situation has gotten worse than it was for the last 2 weeks where we had stable locks more than 4 hours long, but the PI damping would need to be babysat at 40 Watts.  Maybe an engineering run is a good time for detector engineers and operators to learn how to do this.  

There are several things that should be done if we want to continue the ER at 25 Watts with a reasonable sensitivity:

  • run A2L
  • make 25 Watt low noise hard loops
  • get CO2 powers set to something OK in the guardian

none of these are all that hard to do, but to me it seems like it would be more productive to try continuing the ER at 40 Watts, to see what we can learn about the IFO in a state that is more similar to the configuration we would like to run at for O2.  

keita.kawabe@LIGO.ORG - 10:20, Friday 08 July 2016 (28271)

DARM-ISS 2nd loop coherence doesn't change by increasing the ISS 2nd loop gain by 6dB. Jitter or whatever, ISS is imprinting noise onto intensity.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 12:18, Friday 08 July 2016 (28276)

Keita, this is something I think we saw in the past too:

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20394

nutsinee.kijbunchoo@LIGO.ORG - 14:12, Friday 08 July 2016 (28279)

CO2 related comment:

  • CO2 Nominal state of the guardian gets turned on during Coil Driver state. If you have skipped Coil Driver (which you did according to the alog) then CO2 power guardian stays at pre-heating. This can be changed easily.
  • CO2 power at its Nominal state is calculated based in PSL input. There might be a message complaining that the CO2 setting is not nominal (since we used to operate at 20W) but the output CO2 power should be correct at 40W.
H1 ISC (ISC, SUS)
carl.blair@LIGO.ORG - posted 00:08, Friday 08 July 2016 - last comment - 14:59, Friday 08 July 2016(28259)
Summary 47.5kHz Instabilities
[Ross, Carl]
This is a summary of what we know about the 47.5kHz instabilities at present.
 
There are two modes whose aplitudes rise significantly during most locks, they appear in the 65536kSa/sec HF OMC transmission signals at approximately 18038Hz and 18056Hz.  
 
As reported in alog28088 they appear to be super-nyquist ETMY modes that are aliased from 47497Hz and  47480Hz.  
 
They caused lockloss several times when we had increased the ETMY ring heater in an attempt to split the15042Hz ETMX and ETMY modes that are problematic to damp.  They have also caused several lock losses over the last day.  However there has been a large transient in amplitude for several weeks.  Currently when we survive these modes it is by fast thermal transient through a large parametric gain regime.  If the transient is fast enough we do not spend enough time in the transient for the mode amplitude to grow to a level to unlock the interferometer.  Example amplitude transients can be found here.
 
The phase of the arm transmission QPDs quadrants relative to the OMC transmission signal was measured for the 18038 Hz mode to be ETMX_A UL 21.7 deg, LL -171deg, UR -129deg and LR 83deg and ETMY_A UL 67 deg, LL -141deg, UR -129deg and LR 66 deg indicating a 'pringle' type optical mode.  For reference the 15542Hz vertical mode phase is ETMY UL -178 deg, LL 33deg, UR -163deg and LR 6.5 deg.  The pringle shape is the expected shape of a HG11 which has a resonance at approximately 47500Hz in a single arm cavity. 
 
The Q has been estimated as 5.7 million from a ring down time constant of 38.3 sec.  This was done at 40W and the parametric gain was not estimated so this number is an upper limit.
 
My simulations of the test mass do not show me any very likely culprit resonant modes in a 1kHz band around the observed resonance frequency, many would interact with significant beam decentering but Marie's measurements do not indicate any particular ETMY decentering (to explain only seeing ETMY instabilities).  It appears the ears interact significantly at these frequencies. See the mode shape animations with and without ears.  The most likely in the group of modes in these animations appears to be the 47942Hz without ears.  With ears all modes look like they need some decentering to get significant overlap.  However there is a suspicious mode at 43kHz (separate image).  I am not confident in the simulation at these frequencies, we need more high frequency mode identification to increase confidence in the model.
 
The mode has now been excited and damped and the damping setting have been put into the SUS_PI guardian.  The current damping settings use the OMC HF signal down-converted on 17300Hz transmitted to the end station then up-converted.  The signal then passes through a 10Hz wide band-pass filter -30deg phase and -3000 control gain driving the LL quadrant.  The phase response of the 10Hz wide bandpass may not be adequate as this mode is likely to shift more than 1 Hz in the thermal transient, while the filters response is approximately 60 degrees per Hz.  The filter used is a normalised combination of cheby2, butter and a notch to reduce the phase gradient.
A narrow filter was compared to a wide filter when doing the phase optimisation.  There are 2 lines within +/-5Hz.  These lines beat and the result is a reduction the 'effective damping strength'.  The two plots show the phase optimisation with the narrow filter and the broad filter.  The optimums were found to be 150 deg (broad) and +90deg (narrow).  In this case the cost of the beat signal is a factor of ## reduction in the effective drive strength.
 
A narrow filter (2Hz) was compared to a wide (10Hz) filter when doing the phase optimisation.  There are 2 lines within +/-5Hz.  These lines are removed by the narrow filter but not by the wide filter, resulting in a reduction of the 'effective damping strength'.  The two last plots show the phase optimisation with the narrow filter and the broad filter.  The optimums were found to be 150 deg (wide) and +90deg (narrow).  In this case the cost of the beat signal is a factor of 2 reduction in the effective drive strength going from a damping time constant of 4.4 seconds (narrow) to 9 seconds (wide) at the optimum damping phase (with the same control gain and filter normalisation on resonance).
 
A narrow filter was compared to a wide filter when doing the phase optimisation.  There are 2 lines within +/-5Hz.  These lines beat and the result is a reduction the 'effective damping strength'.  The two plots show the phase optimisation with the narrow filter and the broad filter. [Ross, Carl]
This is a summary of what we know about the 47kHz instabilities at present.
 
There are two modes whose alpitudes rise significantly during most locks, they appear in the 65536kSa/sec HF OMC transmission signals at approximately 18038Hz and 18056Hz.  
 
As reported in alog @@@ they appear to be super-nyquist modes that are aliased from 47333 47333.  
 
They caused the interferometer to unlock several times when we had increased the ETMY ring heater in an attempt to split the 15042Hz ETMX and ETMY modes that are problematic to damp.  They have also caused several lock losses over the last day where the interferometer was being locked from a cold state.  Currently when we survive these modes it is by fast thermal tranisent through a large parametric gain regime.  If the transient is fast enough we do not spend enough time in the transient for the mode amplitude to grow to a level to unlock the interferometer.
 
The phase of the arm transmission QPDs relative to the OMC transmission signal was measured for the 18039 Hz mode to be ETMX UL 21.7 deg, LL -171deg, UR -129deg and LR 83deg and ETMY UL 67 deg, LL -141deg, UR -129deg and LR 66 deg indicating a 'pringle' type optical mode.  For reference the 15542Hz vertical mode phase is ETMY UL -178 deg, LL 33deg, UR -163deg and LR 6.5 deg.  The pringle shapes is the expected shape of a HG11, which has a resonance at approximately 47500Hz in a single arm cavity. 
 
The Q has been estimated as 5.7 million from a ring down time constant of 38.3 sec.  This was done at 40W and the parametric gain was not estimated.
 
My simulations of the test mass do not show me any very likely culprit resonant modes in a 1kHz band around the observed resonance frequency.  It appears the ears interact significantly at these frequencies. See the mode shape animations with and without ears.  The most likely in the group of modes in tha animation appears to be the 47942Hz.  However there is a suspicious mode at 43kHz.  I am not confident in the COMSOL simulation at these frequencies, we need more high frequency mode identification to increase confidence in the model.
 
The mode has now been excited and damped and the damping setting have been put into the SUS_PI guardian.  The current damping settings use the OMC HF signal downconverted on 17300 transmitted to the end station then upconverted.  The signal then passes through a 10Hz wide bandpass filter -30deg phase and -3000 control gain driving the LL quadrant.  The phase response of the 10Hz wide bandpass may not be adequate as this mode is likely to shift more than 1 Hz in the thermal transient, while the filters response is approximately 60 degrees per Hz.  The filter used is a normalised combination of cheby2, butter and a notch to reduce the phase gradient.
 
A narrow filter was compared to a wide filter when doing the phase optimisation.  There are 2 lines within +/-5Hz.  These lines beat and the result is a reduction the 'effective damping strength'.  The two plots show the phase optimisation with the narrow filter and the broad filter. 
Images attached to this report
Comments related to this report
carl.blair@LIGO.ORG - 03:32, Friday 08 July 2016 (28263)

The phase of the 18040Hz mode flipped during this lock stretch.  The damping has been switched to the arm transmission QPDs gain 10,000 phase + 60 deg.
The 18056Hz mode also became unstable and was succesffully damped with settings in SUS_PI guardian.

The ETMX 15541.8Hz mode and ETMY 15542.6Hz modes that have been difficult to damp were damped well tonight with the arm tranmssion QPD signals.  The rational was that the arm transmission QPD's differentiate the arm the mode is in to some extent reducing the beat effect.  These settings are in the SUS_PI guardian.  The revert comment out the ETM QPD gain settings and uncomment the OMC gain settings for these modes.

edward.daw@LIGO.ORG - 14:59, Friday 08 July 2016 (28285)
Carl - I'm wondering if the width and apparent double nature of each mode could be due to the same mode being excited in 
the coating-bearing mass and in the reaction mass - could the reaction mass body modes be getting rung up as well? Just a thought.
Might be nonsense.
H1 AOS
sheila.dwyer@LIGO.ORG - posted 23:05, Thursday 07 July 2016 - last comment - 09:48, Friday 08 July 2016(28260)
ETMY oplev is still bad

There has been something wrong with the ETMY oplev for quite a while now, it says that the optic is moving a lot more than the other test masses, swinging around by more than half a micro radian.  This must be false, and needs some investigation.  

Images attached to this report
Comments related to this report
jason.oberling@LIGO.ORG - 09:48, Friday 08 July 2016 (28269)

Looking at the SUM out of the oplev at 2 different times, it seems like there may be an issue with the laser.  The first attachment shows the ETMy SUM signal from a period in April while the second shows the same signal at the start of July (y axis is counts, and the scale is the same between the two pictures).  As can be seen the SUM signal is noisier now that it was back in April.  This could be what is causing the issue Sheila reports above.  We can swap the laser at the next available opportunity to see if this fixes the problem.

Images attached to this comment
H1 CDS (CDS, GRD, Lockloss)
sheila.dwyer@LIGO.ORG - posted 18:57, Thursday 07 July 2016 - last comment - 09:24, Friday 08 July 2016(28255)
DRMI triggering lockloss

The lockloss from the state REFL_POP_WFS which happened at 23:56:29  UTC July 07 2016 is very similar to what is described in alog 26840 and comments.  I've attached the guardian logs for both ISC_DRMI and ISC_LOCK, and a plot of the lockloss.  

The first thing that happens is that the ISC_LOCK gaurdian starts to transition our front end triggering for the LSC from POP18 to POPLF, by lowering the thresholds, sleeping 0.1 seconds, and then setting the trigger matrix elements to 0.  

2016-07-07_23:56:12.133470Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-MICH_FM_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.137560Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-PRCL_FM_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.138100Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_TRIG_THRESH_ON => -100
2016-07-07_23:56:12.138900Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.142360Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_FM_TRIG_THRESH_ON => -100
2016-07-07_23:56:12.146050Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_FM_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.150410Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-MCL_TRIG_THRESH_ON => -100
2016-07-07_23:56:12.152560Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-MCL_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.254650Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-TRIG_MTRX_2_2 => 0
2016-07-07_23:56:12.255230Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-TRIG_MTRX_3_2 => 0
2016-07-07_23:56:12.261690Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-TRIG_MTRX_4_2 => 0
2016-07-07_23:56:12.137560Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-PRCL_FM_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.138100Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_TRIG_THRESH_ON => -100
2016-07-07_23:56:12.138900Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.142360Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_FM_TRIG_THRESH_ON => -100
2016-07-07_23:56:12.146050Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-SRCL_FM_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.150410Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-MCL_TRIG_THRESH_ON => -100
2016-07-07_23:56:12.152560Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-MCL_TRIG_THRESH_OFF => -100
2016-07-07_23:56:12.254650Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-TRIG_MTRX_2_2 => 0
2016-07-07_23:56:12.255230Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-TRIG_MTRX_3_2 => 0
2016-07-07_23:56:12.261690Z ISC_LOCK [DRMI_ON_POP.main] ezca: H1:LSC-TRIG_MTRX_4_2 => 0
 
 after this the ISC_LOCK guardian has a 0.1 second sleep while before restting the matrix elements.  Durring this sleep, the ISC_DRMI guardian logs that SRCL was triggered off, although it seems like it should not have been according to the logic in the model and the values plotted in the attached screenshot. This is mystery number 1.  
 
 2016-07-07_23:56:12.263190Z ISC_DRMI [DRMI_3F_LOCKED.run] DRMI TRIGGERED NOT LOCKED:
2016-07-07_23:56:12.263210Z ISC_DRMI [DRMI_3F_LOCKED.run] LSC-MICH_TRIG_MON = 1.0
2016-07-07_23:56:12.263220Z ISC_DRMI [DRMI_3F_LOCKED.run] LSC-PRCL_TRIG_MON = 1.0
2016-07-07_23:56:12.263220Z ISC_DRMI [DRMI_3F_LOCKED.run] LSC-SRCL_TRIG_MON = 0.0
2016-07-07_23:56:12.263230Z ISC_DRMI [DRMI_3F_LOCKED.run] DRMI not Locked
2016-07-07_23:56:12.324180Z ISC_DRMI state returned jump target: LOCK_DRMI_1F
2016-07-07_23:56:12.324390Z ISC_DRMI [DRMI_3F_LOCKED.exit]
2016-07-07_23:56:12.324880Z ISC_DRMI STALLED
2016-07-07_23:56:12.386490Z ISC_DRMI JUMP: DRMI_3F_LOCKED->LOCK_DRMI_1F
2016-07-07_23:56:12.390010Z ISC_DRMI calculating path: LOCK_DRMI_1F->DRMI_3F_LOCKED
2016-07-07_23:56:12.390590Z ISC_DRMI new target: DRMI_LOCK_WAIT
2016-07-07_23:56:12.391260Z ISC_DRMI executing state: LOCK_DRMI_1F (30)
2016-07-07_23:56:12.391420Z ISC_DRMI [LOCK_DRMI_1F.enter]
 
In the attached screenshot, you can see that LSC-SRCL_TRIG_MON is never 0 according to the recorded data, but as Dave confirmed to us last time this happened, the recorded data is not necessarily the same as the data that the guardian recieves.  However, the channel SUS-SRM_M3_LOCK_L_IN1_DQ is recorded at 2 kHz and should have been 0 if LSC-SRCL was not triggered, and we don't see anything like that happening in the screenshot.  So was the SRCL trigger actually off, or is it possible that the epics data received by guardian thought it was triggered off when it was actually on.  If SRCL was really triggered off, this could potentially cause locklosses.  
 
After thinking that DRMI lost lock, the ISC_DRMI guardian makes a jump transition, and gets stalled as expected.  But why does it continue on to try relocking DRMI (which is what ultimately caused the lockloss)?  I don't think we are unstalling nodes anywhere in this state of ISC_LOCK, so it must be that the expected behavoir of a stalled node is to run the jump state and not continue after that?  
 
Evan and I extended the sleep between steps of the triggering transition to 0.2 seconds rather than 0.1 but since I don't understand why this happened, I'm not sure that will fix the problem.  We can create an IDLE state of the DRMI guardian which will not check for locklosses, that would prevent this bug from causing locklosses but doesn't address the more disturbing problems.  Hopefully someone can help us understand why the data recieved by the guardian doesn't seem to agree with what we expect to happen based on the triger logic, or what the recorded data (even the fast data) seems to indicate happened. 
 
 
Images attached to this report
Non-image files attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 09:24, Friday 08 July 2016 (28266)
After thinking that DRMI lost lock, the ISC_DRMI guardian makes a jump transition, and gets stalled as expected.  But why does it continue on to try relocking DRMI (which is what ultimately caused the lockloss)?  I don't think we are unstalling nodes anywhere in this state of ISC_LOCK, so it must be that the expected behavoir of a stalled node is to run the jump state and not continue after that?

Yes, the expected behavior is that the target state of a jump transition of a managed node will be executed normally after the transition.  The stall just prevents the system from following any standard transtions after the state returns true.  Nothing prevents jump transitions, though.

If you don't want the system to do anything after a jump I would suggest inserting a do-nothing state in between.

LHO VE
kyle.ryan@LIGO.ORG - posted 15:25, Thursday 07 July 2016 - last comment - 14:32, Friday 08 July 2016(28248)
Ran rotating vacuum pumps at X-mid
Started and ran the purge-air skid, Turbo, QDP80 and newly added scroll pump.  Tested the functionality of the Turbo's Safety Valve with the control cable connected to the scroll pump's relay box - demonstrating that the Safety Valve closes upon the loss of scroll pump motor AC and thus mimicking the "QDP80 Running" 
signal.

Note: The purge-air skid has developed some problems from lack of use over these past few years, namely the radiator fan never came on while running the compressors, the drying tower never cycled and the low pressure alarm never sounded.  These features worked fine when last this unit was run.  Now they don't.  Also, the Turbo spun-up normally even with the locally mounted scroll pump running (new vibration source) but tripped into EMERGENCY OPERATION upon BRAKING and when at ~1/3 NORMAL rpm.  This behavior is seen on other Turbos (XBM for example) and might be an age related issue?  

I am leaving the Turbo energized overnight to ensure that the rotor is completely stopped.  I will de-energize it tomorrow.  
Comments related to this report
kyle.ryan@LIGO.ORG - 14:32, Friday 08 July 2016 (28282)
Friday, July 8th ~1345 hrs. local -> De-energized MTP controller
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 11:36, Tuesday 05 July 2016 - last comment - 14:16, Friday 08 July 2016(28150)
Fit of sensing function completed

With the measured sensing function (28123) in hand, we did an MCMC-based numerical fitting for the sensing function (see E. Hall, T1500553).

The fitting results are


[New sensing function form]

As reported by Evan (27675), it seems that the extra roll off in the DARM response at low frequencies are due to an SRC detuning (or something equivalent). While such detuning should be suppressed by some control loop ideally, we decided to include the detuning-induced functional form in addition to the ordinary single-pole response. We use the following approximated form for the DARM response

S(f) = H / (1 + i f / fc ) * exp( -2 * pi * f * tau) * f^2/(f^2 + fs^2)

where H, fc, tau and fs are the optical gain, DARM cavity pole, time delay and spring frequency. Some details of the derivation will be reported later. Apparently, we now have an additional quantity (i.e., fs) to fit.

Note that since H1 seems to be in (unintentionally) an anti-spring detuning, fs should be a real number whereas it should be an imaginary number for a pro-spring case. Obviously, Q is set to infinity for simplicity.

[MCMC-based numerical fitting]

Following the work by Evan (T1500553), we adapted his code to include the spring frequency as well. In short, it is a Bayesian analysis to obtain posteriors for the parameters that we want to estimate. We gave a simple set of priors as follows for this particular analysis.

The quad plot below shows the fitting result. The estimated parameters are obtained by taking the mean values of the resutling probability distribution. As usual, the two plots on the left hand side show a bode plot of the measured and fitted data. The two plots on the right hand side show the residual of the fit. As shown in the residuals, there are several points which are as big as 20% in magnitude and 6 deg in phase below 10 Hz. Otherwise, the residual data points seem to be within 10-ish % and 4 deg. The code is attached in pdf format.

EDIT: I am attaching the actual code as well.

Images attached to this report
Non-image files attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 15:15, Tuesday 05 July 2016 (28170)

A detailed derivation of the new functional form can be found at https://dcc.ligo.org/LIGO-T1600278

kiwamu.izumi@LIGO.ORG - 16:03, Tuesday 05 July 2016 (28171)

EvanG noticed that we have unintentionally included high frequency poles in the previous analysis (28157). So we made the same fitting for the data with all the high frequency poles removed.

Here are the fitting results for the latest data:

  • Optical gain = 9.070764e+05 +/- 8.071988e+02 [cnts/m]
  • Cavity pole = 3.287361e+02 +/- 5.692504e-01 [Hz]
  • Time delay = 5.554816e+00 +/- 3.424867e-01 [usec]
  • Spring frequency = 9.831483e+00 +/- 5.434934e-02 [Hz]

Since the bode plot looks very similar to the one posted above, I skip showing it here. Observe that the time delay is now smaller than it was because we now don't have the high frequency poles.

craig.cahillane@LIGO.ORG - 14:16, Friday 08 July 2016 (28274)CAL
C. Cahillane, K. Izumi

I have added in a new term to our sensing function fit, an optical spring Q factor to gain back phase information.

From the functional form f^2/(f^2 + f_s^2) we only get a magnitude correction from detuning, but we also expect detuning to slightly affect phase in the sensing function response.

This can be clearly seen in lower right subplot Figure 1 of this comment, where Kiwamu originally plotted the full RSE sensing function.  Here we see that when we have 1 degree of detuning we also have +1.5 degree phase difference at 10 Hz when compared to the sensing function without detuning. 

In the phase residual plot in the original post you can see this phase loss in the actual ER9 sensing measurement.  

In order to try and gain back some of this phase information, we have added in an additional term to the detuning function:

    f^2                        f^2
-----------    ===>  -----------------------
f^2 + f_s^2          f^2 + f_s^2 - i*f*f_s/Q

This adds another parameter to our fit, but lets us get back phase information lost to detuning.

**********

Figure 2 shows Kiwamu's original fit parameters posted above in red alongside my new results in green.
I argue that including the optical spring Q factor has improved the phase fit significantly.  
Quantitatively, here are the phase Χ-Square values:

With Optical Spring Q Χ-Square    = 85.104
Without Optical Spring Q Χ-Square = 819.28

**********

I have modified Kiwamu's SensingFunction.ipynb into a SensingFunctionSimulation.ipynb which fits to both phase and magnitude of the sensing function.  SensingFunctionSimulation.ipynb is attached as a zipped file in this aLOG and is also in a Git repo called RadiationPressureDARM owned by Kiwamu.

Fit parameters:

Optical gain = 9.124805e+05 +/- 8.152381e+02 [cnts/m]
Cavity pole = 3.234361e+02 +/- 5.545748e-01 [Hz]
Time delay = 5.460838e+00 +/- 3.475198e-01 [usec]
Spring frequency = 9.975837e+00 +/- 5.477828e-02 [Hz]
Spring Inverse Q = 1.369124e-01 +/- 3.522990e-03

(I choose to parametrize using inverse Q = Q^{-1} because Q^{-1} can be zero.)
Images attached to this comment
Non-image files attached to this comment
Displaying reports 55881-55900 of 83394.Go to page Start 2791 2792 2793 2794 2795 2796 2797 2798 2799 End