Displaying reports 63581-63600 of 83007.Go to page Start 3176 3177 3178 3179 3180 3181 3182 3183 3184 End
Reports until 12:03, Sunday 26 July 2015
H1 SEI (DetChar, PEM)
jeffrey.kissel@LIGO.ORG - posted 12:03, Sunday 26 July 2015 - last comment - 12:34, Sunday 26 July 2015(19944)
Bubba Roars Off on a Motor Cycle at 18:56 UTC
J. Kissel, B. Gateley

After finishing up working on a repair water system, Bubba said he was going to take off in a bit. He was worried about about making noise while driving away on his motorcycle, but I challenged him to let'er rip such that we can dispel aLIGO superstitions that are carry-overs of the ol' i/eLIGO seismic isolation system. 

He left from the shipping and receiving area (North East (-Y) of the output arm of the corner station), and I could hear his bike from the control room as he drive off. I saw no visible effects on the IFO from the figures of merit in here, and the IFO is running as fabulously as it has all morning.

@DetChar -- can you find anything? 

He drove off ~18:56 UTC (11:56 PDT).
Comments related to this report
andrew.lundgren@LIGO.ORG - 12:34, Sunday 26 July 2015 (19946)
I can definitely see it on the BS and LVEA mics, though it's a bit hard to hear. There's a lot of ambient noise - I don't know if they're near HVACs or cleanrooms, or if it's the way that the signal is conditioned, or my headphones just have bad lowrange.

I don't see anything in DARM (second plot). If anyone wants to try coherence or anything else more sophisticated, the motorcycle sounds peaks at 1121972165 and extends 15 seconds on a side, though I think maybe the engine is idling for a minute before that.
Images attached to this comment
LHO FMCS
bubba.gateley@LIGO.ORG - posted 11:50, Sunday 26 July 2015 (19941)
Bubba leaving site


			
			
LHO FMCS
bubba.gateley@LIGO.ORG - posted 09:45, Sunday 26 July 2015 (19938)
Repair frost free wall hydrant
Bubba on site to repair frost free wall hydrant on East wall of OSB.
H1 DetChar (CAL, DetChar, ISC, SEI, SYS)
jeffrey.kissel@LIGO.ORG - posted 09:24, Sunday 26 July 2015 - last comment - 12:16, Sunday 26 July 2015(19937)
6 Hours (so far!) Of Observation Ready Data
J. Kissel

I've come in to find the IFO still cruising along at full power and full sensitivity. With this kind of robustness, I think we might even be ready for and observation run! Nice work all!! Now we just need to refine the calibration...

For the record, the observation intent bit was turned ON at 
Jul 26 2015 10:13:35 UTC
Jul 26 2015 03:13:35 PDT
1121940832

Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:51, Sunday 26 July 2015 (19939)
I've heard two ETMY saturations announced while I've been here, the most recent one at ~17:24 UTC. I also see several large, 1 minute drops in the inspiral range over the course of this lock stretch. Suspecting that all of these gltiches are ETMY saturations, I've trended the saturation channel (H1:FEC-98_ACCUM_OVERFLOW) over the pas 10 hours (starting at 17:25:44) and I see that there are plenty.

Sadly, we *still* can't trend DMT channels in dataviewer (I would love it if someone told me I'm wrong), so I can't quickly put the inspiral range on the same trend plot to see if they're roughly coincident.

To aide in the offline study, I attach the channel map for each OSEM / ESD DAC channel from the Simulink front-end model. Recall you can find out where all of these OSEMs / QUADRANTs I mention are physically by looking at E1000617. Also recall, there are two EPICs channels for saturations one can look at for each DAC channel, the "instantaneous" and accumulative. The instantaneous channels are 
${IFO}:FEC-${DCUID}_DAC_OVERFLOW_${CARDNUM}_${CHANNELNUM}
${IFO}:FEC-${DCUID}_DAC_OVERFLOW_ACC_${CARDNUM}_${CHANNELNUM}

I cite the accumulative channels below.

H1:FEC-98_DAC_OVERFLOW_ACC_0_0 = M0/TOP F1
H1:FEC-98_DAC_OVERFLOW_ACC_0_1 = M0/TOP F2
H1:FEC-98_DAC_OVERFLOW_ACC_0_2 = M0/TOP F3
H1:FEC-98_DAC_OVERFLOW_ACC_0_3 = M0/TOP SD
H1:FEC-98_DAC_OVERFLOW_ACC_0_4 = M0/TOP LF
H1:FEC-98_DAC_OVERFLOW_ACC_0_5 = M0/TOP RT

H1:FEC-98_DAC_OVERFLOW_ACC_0_6 = R0/TOP LF
H1:FEC-98_DAC_OVERFLOW_ACC_0_7 = R0/TOP RT
H1:FEC-98_DAC_OVERFLOW_ACC_1_0 = R0/TOP F1
H1:FEC-98_DAC_OVERFLOW_ACC_1_1 = R0/TOP F2
H1:FEC-98_DAC_OVERFLOW_ACC_1_2 = R0/TOP F3
H1:FEC-98_DAC_OVERFLOW_ACC_1_3 = R0/TOP F4

H1:FEC-98_DAC_OVERFLOW_ACC_1_4 = L1/UIM UL
H1:FEC-98_DAC_OVERFLOW_ACC_1_5 = L1/UIM LL
H1:FEC-98_DAC_OVERFLOW_ACC_1_6 = L1/UIM UR
H1:FEC-98_DAC_OVERFLOW_ACC_1_7 = L1/UIM UR

H1:FEC-98_DAC_OVERFLOW_ACC_2_0 = L2/PUM UL
H1:FEC-98_DAC_OVERFLOW_ACC_2_1 = L2/PUM LL
H1:FEC-98_DAC_OVERFLOW_ACC_2_2 = L2/PUM UR
H1:FEC-98_DAC_OVERFLOW_ACC_2_3 = L2/PUM LR

H1:FEC-98_DAC_OVERFLOW_ACC_3_0  = L3/TST ESD Bias
H1:FEC-98_DAC_OVERFLOW_ACC_3_1  = L3/TST ESD UR
H1:FEC-98_DAC_OVERFLOW_ACC_3_2  = L3/TST ESD LR
H1:FEC-98_DAC_OVERFLOW_ACC_3_3  = L3/TST ESD UL
H1:FEC-98_DAC_OVERFLOW_ACC_3_1  = L3/TST ESD LL
(not the "odd" ordering of the TOP and ESD channels, which are different from "normal" OSEM stages.)
Images attached to this comment
andrew.lundgren@LIGO.ORG - 11:32, Sunday 26 July 2015 (19940)
I've written some gwpy code to find ADC/DAC overflows and turn them into DQ segments: github link. It needs gwpy and has to run on a cluster so it has access to the data. If you want to use it in the control room, and gwpy has been installed there, I can easily convert it to use NDS.

To use it on the cluster, do
source ~detchar/opt/gwpysoft/etc/gwpy-user-env.sh
python make_overflow_dq_triggers.py -i H1 -c H1-omc-lsc-etm.txt -s 1121940832 -e 'lalapps_tconvert now'

The config file is attached, as is the code.

The times when the ETMY L3 DACs overflowed in this lock are below. I can scan them to see how big of a glitch they made.

 1121942076.7500 1121942077.0000
 1121950991.2500 1121950991.3750
 1121951661.9375 1121951662.0625
 1121953931.1250 1121953931.2500
 1121955356.8125 1121955356.9375
 1121957517.1875 1121957517.3125
 1121963083.7500 1121963083.8750
 1121966658.3125 1121966658.6250
 1121969119.5625 1121969119.7500
Non-image files attached to this comment
andrew.lundgren@LIGO.ORG - 11:57, Sunday 26 July 2015 (19942)DetChar
I've made some Omega scans. Here's a link to the directory: LHO webserver

The SNRs of the resulting glitches range from 200 to 3000. The biggest of these are about as bad as the beamtube cleaning glitches. We plan to make some veto flags for overflows like this, but obviously it's best to fix them.
gabriele.vajente@LIGO.ORG - 12:00, Sunday 26 July 2015 (19943)DetChar, ISC

See below for the coherence report.

joseph.areeda@LIGO.ORG - 12:16, Sunday 26 July 2015 (19945)
Minute trends seem to have about a 2 hour delay getting to ldas.
Because of the difference in range of the 2 channels I had to make 2 plots but the drop in range does seem to coincide with the overflow.

I'm not sure if DMT now has access to H1:DMT-SNSH_EFFECTIVE_RANGE_MPC but that data is available via NDS2
Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 03:05, Sunday 26 July 2015 - last comment - 00:48, Wednesday 12 August 2015(19935)
Some things not in the guardian
Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 00:48, Wednesday 12 August 2015 (20460)

I think that evan meant to say he increased the gain for CHARD by 20 dB by engaging FM1

H1 ISC
evan.hall@LIGO.ORG - posted 02:25, Sunday 26 July 2015 (19934)
cHard pitch OLTF

This one is interesting.

Based on step response it has a time constant of something like 15 to 20 s.

Images attached to this report
Non-image files attached to this report
H1 CAL (CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 23:48, Saturday 25 July 2015 (19932)
Updated and New MEDM Screens for Time-Dependent Tracking with Front-End Calibration; Updates Ready for LLO
J. Kissel

I've updated the CAL-CS MEDM screens to go with the front-end model clean up of the time dependence tracking in the DARM calibration installed on Thursday (see LHO aLOG 19875). In addition, I've *created* an MEDM screen for what's currently implemented for PCAL vs. DARM calibration line demodulation, even though at LHO we can't yet ship PCAL information back to the corner station because of RFM IPC errors (see LHO aLOG 18671). 

See attached screenshots.

For Joe: Here's what you need to update on Tuesday:
/opt/rtcds/userapps/release/cal/common/models/
Sending        models/CAL_CS_MASTER.mdl
Sending        models/CAL_GAMMA_CALC_MASTER.mdl
Sending        models/CAL_GAMMA_PCAL_MASTER.mdl

/opt/rtcds/userapps/release/cds/common/medm/
Adding         DEMOD.adl

/opt/rtcds/userapps/release/cal/common/medm/
Deleting       medm/CAL_CS_GAMMA_LINE_OVERVIEW.adl
Sending        medm/CAL_CS_OVERVIEW.adl
Adding         medm/CAL_CS_TDEP_DARM_DEMOD_OVERVIEW.adl
Sending        medm/CAL_CS_TDEP_OVERVIEW.adl
Adding         medm/CAL_CS_TDEP_PCAL_DEMOD_OVERVIEW.adl

VERY IMPORTANT: I've rearranged the inputs to the CAL_CS_MASTER model such that there isn't the constantly annoying spaghetti soup of wires going from the IPC parts into the library part. So, you'll need to reconnect all of the IPCs at the top-level model, accounting for the rearrangement.

Sadly, looking through this PCAL and DARM demod infrastucture which produces the time-dependence formerly known as gamma(t), documented in T1500206 and T1500121 is now sorely out of date with how we intend to compensate things in O1 with the low-latency pipeline (for which the documentation is not complete, but lives in T1500377). It makes me wish we had kept the idea of performing the time-dependent calculations in a separate front-end model, such that we could play around with it during the science run without it affecting the time-independent calibration. *sigh* hindsight is 50/50, right?
Images attached to this report
H1 ISC (DetChar, ISC)
gabriele.vajente@LIGO.ORG - posted 23:02, Saturday 25 July 2015 (19931)
Brute force coherence

Nice night lock, here is the report from BruCo:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1121900417/

An excerpt. As usual, the selection of channels might not be the most representative of the real noise couplings, but should give some good hints.

Images attached to this report
H1 ISC (CAL)
evan.hall@LIGO.ORG - posted 21:17, Saturday 25 July 2015 (19929)
Tuned DARM OLTF template

Jeff, Evan

Here is a DARM OLTF DTT xml with drive levels that are appropriate for use when the EY ESD LVLN LPF on.

Above 500 Hz, it is hard to get coherence. In this region, we have tuned the drive envelope so that the DAC for each ESD quadrant is putting out somewhere between 10 000 ct pk and 50 000 ct pk.

The current integration time (and number of points) as saved in the file is meant for a long, slow, precise measurement, and it will take about 25 minutes to run. For commissionning purposes, it is prudent to reduce the number of points and the integration time.

Images attached to this report
Non-image files attached to this report
H1 TCS
nutsinee.kijbunchoo@LIGO.ORG - posted 21:06, Saturday 25 July 2015 - last comment - 16:39, Sunday 26 July 2015(19930)
HWS ITMY code running

Came in to find the interferometer has been locked for 5 hours and the ITMY HWS camera, frame grabber, and SLED beam has been on. Since they don't seem to bother anyone I decided to leave them on and run the ITMY HWS code. The number on ITMY HWS medm screen are constantly changing but in the terminal I kept getting "LHD File Not Written". The .mat files are not being updated constantly so I'm not sure how to tell if the code is actually working. The files are in /home/controls/temp/HWSY_July25

 

ETM HWS cameras were also on. I just turned them off.

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 16:39, Sunday 26 July 2015 (19951)

Jeff pointed out that I should leave an instruction on how to kill the code since I left it running on the Ops computer. About 30 minutes after lock loss go to the terminal that has the TCS code running (the only terminal that refreshes itself every second or so), simply kill it by Ctrl+C. Do it repeatedly until the code is killed. I'd wait 30 minutes to allow the spherical power to decrese all the way to the bottom. This way I know the code was actually working and the data make sense.  

H1 ISC
evan.hall@LIGO.ORG - posted 16:51, Saturday 25 July 2015 - last comment - 20:19, Wednesday 30 September 2015(19895)
REFL9Q dark noise

Summary

Attached is the dark noise of REFL9Q, along with an estimate of the shot noise and a conversion of these noises into equivalent frequency noise in CARM.

The dark noise appears to be slightly below the shot noise level.

Details

I took the TNC that goes directly into the common-mode board and put it into an SR785. Also attached is the noise with the input of the SR785 terminated.

I also have tried to estimate how this compares to the shot noise on the diode. In full lock at 24 W, we see 3.6 mW of dc light on the PD (according to the calibrated REFL_A_LF channel). Off resonance and at 2.0 W, we have 13.6 mW of dc light. So the CARM visibility is about 98%.

The shot noise ASD (in W/rtHz) and the CARM optical plant (in W/Hz) are both given in Sigg's frequency response document. With a modulation index of 0.22 rad and an incident power of 24 W, the shot noise is 9.4×10−10 W/rtHz, the CARM optical gain is 11 W/Hz, and the CARM pole is 0.36 Hz. [Edit: I was missing some HAM1 attentuation when first calculating the shot noise level. Out of lock, the amount of power on REFL A should be 24 W × 0.1 × 0.5 × 0.5 × 0.5 = 300 mW. That gives a predicted shot noise level of 7.7×10−11 W/rtHz, assuming a sideband amplitude reflectivity of 0.44. On the other hand, from the measured in-lock power we can calulate 2(hνP)1/2 = 5.2×10−11 W/rtHz for P = 3.6 mW. This includes the factor of sqrt(2) from the frequency folding but does not include the slight cyclostationary enhancement in the noise from the sidebands (although this latter effect is not enough to explain the discrepancy).] Additionally, I use Kiwamu's measurement of overall REFL9 response (4.7×106 ct/W) in order to get the conversion from optical rf beat note power into demodulated voltage (2900 V/W). These numbers are enough to convert the demodulated dark noise of REFL9Q (and the shot noise) into an equivalent frequency noise. At 1 kHz, the shot noise is about 10 nHz/rtHz; as a phase noise this is 10 prad/rtHz (which is smaller than Stefan's estimate of 80 prad/rtHz). The dark noise, meanwhile, is about 5 nHz/rtHz.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 17:11, Monday 27 July 2015 (19967)

Hang, Evan

We measured the input-referred voltage noise of the summing node and common-mode boards.

  • We terminated the input of the SNB that receives REFL9Q (INA2). INA1 was disabled. On the CMB, IN1 was enabled with -22 dB, and IN2 was disabled. The 40 Hz / 4 kHz boost was engaged. The fast gain was 7 dB.
  • We measured the noise at the output of the CMB fast output.
  • We then took the TF from SNB INA2 to CMB fast out. This is sufficient to get the input referred noise.

According to this estimate, the CARM loop is not shot noise limited; rather, at 1 kHz the noise is about a factor of 3 in ASD above shot noise.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 10:03, Wednesday 30 September 2015 (22104)

I looked back at the CARM sensing noise data I took (on 12 Aug) using the new gain distribution: 0 dB SNB gain, −13 dB CMB common gain, 0 dB CMB fast gain, and 107 ct/ct digital MCL gain.

[For comparison, the old CARM gain distribution was 0 dB SNB gain, −20 dB CMB common gain, 7 dB CMB fast gain, and 240 ct/ct digital MCL gain.]

☞ For those looking for a message in this alog: something about the current frequency noise budgeting doesn't hang together. The projection based on the CARM sensing noise and the measured CARM-to-DARM coupling TF suggests a CARM-induced DCPD sum noise which is higher than what can be supported by coherence measurements.

☞ Second attachment: As expected, the noise (referred to the input of the SNB) is lower; at 40 Hz, it is about 350 nV/Hz1/2. However, we are not really shot-noise (or dark-noise) limited anywhere.

☞ Third attachment: I am also including the CARM-to-DARM coupling TF from a few weeks ago. This TF was taken by injecting into the CARM excitation point and measuring the response in OMC DCPD sum, using the old CARM gain distribution. Then I referred this TF to the SNB input by multiplying by the SNB gain (0 dB), the CMB common gain (−20 dB), and the CMB common boost (40 Hz pole, 4 kHz zero, ac gain of 1).

This gives a coupling which is flat at 1.0×10−2 mA/V, transitioning to 1/f2 around 250 Hz. Or, to say it in some more meaningful units:

  • Assuming a REFL9Q demodulation coefficient of 2900 V/W, this implies a flat power coupling of 3.4×10−6 mA/W above 250 Hz, rising like 1/f2 below that.
  • Assuming a CARM optical gain of 13 W/Hz and an optical pole of 0.48 Hz, this implies a 1/f frequency coupling above 250 Hz, a 1/f3 coupling below 250 Hz, and an overall magnitude of 6.2×10−5 mA/Hz at 1 kHz.
  • Stated in terms of phase coupling (Stefan's favorite), the magnitude of the CARM optical plant is 6.2 W/rad above the cavity pole, which implies a flat phase coupling of 6.2×10−2 mA/rad above 250 Hz, rising like 1/f2 below that.

☞ Synthesis of the above: based on the measurements described above, at 40 Hz we expect a coupling into the DCPD sum of 350 nV/Hz1/2 × 0.4 mA/V = 1.4×10−7 mA/Hz1/2, which is very close to the overall DCPD sum noise of 3.2×10−7 mA/Hz1/2.

But what is wrong with this picture? If 1.4/3.2 = 44 % of the DCPD sum noise comes from CARM sensing noise, we should expect a coherence of 0.442 = 0.19 between the DCPD sum and the CARM error point.

☞ First attachment: The coherence between the CARM error point and the DCPD sum is <0.01 around 40 Hz. Now, it is almost certainly the case that not all of the CARM error point noise is captured by LSC-REFL_SERVO_ERR, since this channel is picked off in the middle of the CMB rather than the end. Conservatively, if we suppose that LSC-REFL_SERVO_ERR contains only dark noise and shot noise, this amounts to 180 nV/Hz1/2 of noise at 40 Hz referred to the SNB error point, or 0.72×10−7 mA/Hz1/2 referred to the DCPD sum. This would imply a coherence of 0.05 or so.

☞ What is going on here?: Four possibilities I can think of are:

  • I've overestimated the sensing noise.
  • I've overestimated the CARM-to-DARM coupling TF.
  • I've made an algebra mistake somewhere.
  • LSC-REFL_SERVO_ERR is corrupted by noise that is not in the CARM loop.

☞ A word about noise budgeting: In my noise budget, there was a bug in my interpolating code for the CARM-to-DARM TF, making the projection too low below 100 Hz. With the corrected TF, the projected CARM noise is much higher and begins to explain the mystery noise from 30 to 150 Hz. However, given that the above measurements don't really hang together, this is highly speculative.

Images attached to this comment
Non-image files attached to this comment
evan.hall@LIGO.ORG - 20:19, Wednesday 30 September 2015 (22134)

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes through some unity-gain op-amps and then directly into the ADC. So I don't think we have much chance of seeing the 180 nV/Hz1/2 of shot/dark noise above the 4 µV/Hz1/2 of the ADC.

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes a gain of 200 V/V and then directly into the ADC. So the 180 nV/Hz1/2 of shot/dark noise appears as 36 µV/Hz1/2 at the ADC. But as Daniel pointed out, this should be heavily suppressed by the loop. For comparison, the ADC's voltage noise is 4 µV/Hz1/2.

For the sake of curiosity, I'm attaching the latest noise budget with the corrected CARM-to-DARM coupling TF. However, I note again that this level of frequency noise coupling is not supported by the required amount of coherence in any of our digitally acquired channels. Additionally, this level of frequency noise coupling is not seen at Livingston, although they've done a better job of TCS tuning than we have. I would not be surprised to find out that this coupling is somehow an overestimate.

Non-image files attached to this comment
H1 CAL (AOS)
jeffrey.kissel@LIGO.ORG - posted 15:42, Saturday 25 July 2015 (19926)
ESD Calibration Lines Truned Back ON
J. Kissel, S. Ballmer

The ESD / DARM calibration lines have been OFF since the CAL-CS front-end model changes this past Thursday (LHO aLOG 19875), because the channel names that generate them have changed. I've used LHO aLOG 19792 to restart them with the newly high SNR.

As Stefan mentions in LHO aLOG 19925, I turned this back on just before the current lock stretch's undisturbed bit was engaged.

For the record, the new channels are
H1:CAL-CS_TDEP_ESD_LINE1_DEMOD_OSC_FREQ       34.7 [Hz] 
H1:CAL-CS_TDEP_ESD_LINE1_DEMOD_OSC_CLKGAIN    0.22 [ct]

H1:CAL-CS_TDEP_ESD_LINE2_DEMOD_OSC_FREQ       538.1 [Hz]
H1:CAL-CS_TDEP_ESD_LINE2_DEMOD_OSC_CLKGAIN    2.4 [ct]
I've overwritten the current EPICs database to the SDF safe.snap, and loaded in the new table to initialize all of the newly named channels. A large fraction of them are now not monitored (417 out of 1188), but I've at least gone through the ESD LINE CLKGAIN and FREQs to make sure they're monitored. I would monitor more, but I don't want to sort on substring (see LHO aLOG 19650).
H1 ISC (ISC)
stefan.ballmer@LIGO.ORG - posted 15:30, Saturday 25 July 2015 - last comment - 20:38, Saturday 25 July 2015(19925)
Nice reference lock with 35mph winds.
Stefan, Jeff,

Starting at 22:24:00 UTC (Jul 25 2015) we left the interferometer undisturbed (H1:ODC-OPERATOR_OBSERVATION_READY was set).

For detChar purposes: 
- All cal lines are on. Our (questionable) calibration reports 60Mpc, but hopefully we ca revise that later.
- The winds are hauling with peak gust up to 38mph, but to interferometer seems remarkable indifferent about that.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:48, Saturday 25 July 2015 (19927)DetChar, SEI, SYS
Adding DetChar, SEI, and SYS Tags and an ASD.

For the record, the reference trace is 10 AVGs and the Live trace is 25 AVGs. Not sure why we're using this crazy weird template that doesn't display the number of averages, but I'll pick another battle.
Images attached to this comment
evan.hall@LIGO.ORG - 20:38, Saturday 25 July 2015 (19928)

Intent bit was turned off around 2015-07-26 02:24:00 Z in order to save the lock from 1 Hz pitch instability. I turned up the dHard pitch gain by a factor of 2.

1 hour of dHard pitch error signal is attached. The gain was turned up near the end.

Images attached to this comment
H1 CDS
evan.hall@LIGO.ORG - posted 23:41, Wednesday 22 July 2015 - last comment - 01:42, Sunday 26 July 2015(19857)
DTT rampdown abort not working?

I was running an ASC OLTF swept-sine template with a request for a 10 s rampdown time.

From the EXCMON of the drive channel, it seems that this rampdown did not happen. Rather, the excitatation continued at full strength for about 10 s and then cut off abruptly.

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 01:42, Sunday 26 July 2015 (19933)

Yes, it appears this feature is broken, at least in swept sine mode.

I pushed the abort button around 06:20:00 Z (around the 10 second mark in the attachment). The excitation continues at full strength until the last second. Then, as far as I can tell, there is some slightly different waveform being written to the excitation channel for about a second. Then the excitation stops abruptly, causing a lockloss.

Images attached to this comment
Displaying reports 63581-63600 of 83007.Go to page Start 3176 3177 3178 3179 3180 3181 3182 3183 3184 End