Displaying reports 69861-69880 of 84537.Go to page Start 3490 3491 3492 3493 3494 3495 3496 3497 3498 End
Reports until 16:00, Saturday 15 November 2014
H1 IOO
gabriele.vajente@LIGO.ORG - posted 16:00, Saturday 15 November 2014 (15088)
Light reflected back by PRM

[Sheila, Evan, Gabriele]

Since yesterday night the IMC has behaved in a strange way. It transitioned from a good state with high and stable IM4_TRANS power, to a bad state with lower and fluctuating power. The IMC remained for all the night in the bad state, and this morning it jumped back to the good one a couple of times. One interesting observation was that IM4_TRANS gets very unstable (30% fluctuations) but the power seen by the ISS second loop PDs is almost unchanged: same mean values and only slightly larger RMS. When transitioning from one state to the other, the MC mirrors are also slightly tilted, but is is cleraly an effect and not the cause of the transition.

We finally discovered that the bad state is triggered when the PRM mirror is aligned (see the plot). Apparently, there is some ghost / stray / scattered beam that reaches IM4 QPD when the PRM is aligned. In addition, this light also affects to some extent the IMC alignment signals, since the MC1, MC2 and MC3 mirrors are clearly moving after the PRM is re-aligned.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:01, Saturday 15 November 2014 (15086)
CDS model and DAQ restart report, Friday 14th November 2014

model restarts logged for Fri 14/Nov/2014
2014_11_14 20:41 h1fw0

one unexpected restart

H1 IOO
kiwamu.izumi@LIGO.ORG - posted 20:06, Friday 14 November 2014 - last comment - 10:30, Monday 17 November 2014(15081)
IM2 slipped in pitch by 60 urad

Keita, Kiwamu,

This is a follow up of the previous investigation for the input pointing issue (alog 15028). We are concluding that the IM2 is the one which messed up the input pointing the other day before the temperate issue hit us.

According to a back-of-envelop calculation, this well explains why we had to move IM4 by 88 urad in pitch to get back to good alignment (alog 15063). Also, from the OSEM spectra, there is no obvious indication of the mirror sticking to the cage or something. Therefore we don't think this is an issue.

Here are summary:

 


The attached is trend of various relevant signals:

 

Here is the spectra of the OSEMS before and after the slip. The bold curves are the ones taken on Nov 10 and the thin curves are the ones from today. All the spectra from today are consistenly lower at low frequencies supposedly due to different seismic level. Also we are having a small bump at around 2 Hz today for some unknown reason. In any case, we don't see an obivous indication of the mirror touching the cage or OSEMs. Therefore we are concluding that IM2 is still healthy. 

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 10:30, Monday 17 November 2014 (15100)

Hugh, Sheila

This doesn't seem to be the result of either Hugh's work last tuesday or stray light reflected off of PRM. 

This slip in IM2 happened about 5 and a half hours after hugh's work, and about 5 hours before PRM was realinged.

Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 19:33, Friday 14 November 2014 - last comment - 20:49, Friday 14 November 2014(15080)
Significant seismic activity beginning around 02:30:00 UTC

Potentially related to the M7.1 earthquake in Indonesia.

Even a simple MICH is continually thrown out of lock.

Comments related to this report
evan.hall@LIGO.ORG - 20:49, Friday 14 November 2014 (15082)

2 hours after the the initial flare up, and we still cannot lock. The ground motion at 0.03-0.1 Hz shows no sign of letting up.

H1 AOS
suresh.doravari@LIGO.ORG - posted 19:32, Friday 14 November 2014 (15079)
HAM2 Oplev laser swapped and improved.

[Doug, Suresh]

   We replaced the diode laser unit in HAM2 oplev yesterday ( Sl no 197 replace by Sl no 122-1 ) and observed it for the last 24 hours. It required several power adjustments before it reached glitch free operation.   However the power is still dropping and has not stabilised.  The laser may require the power to be reset to around 50000 counts if it drifts into a unstable region.

The power trend and spectrogram showing glitch free operation are attached.  As the unit 122-1 puts out much greater power than the 197 we had to readjust the analog gain.  The new switch state is also attached.

Images attached to this report
H1 IOO
kiwamu.izumi@LIGO.ORG - posted 19:10, Friday 14 November 2014 (15078)
IMC cavity axis rotated

Alexa, Keita, Evan, Kiwamu,

We noticed that the input pointing degraded by some anomalously large amount during some locking activity. This was quite noticable. For example, the PRX build-up at ASAIR_A_LF dropped roughly from 4000 to 3000 counts.

After some detective work, we found that the MC1 and MC3 suspensions moved by roughly 100 urad in pitch. It was the DOF_3 loop in IMCAS that was pushing these suspensions pretty hard. Eventually we found that this was due to the MC2 trans picomotors which had been moved supposedly by some IMC/ISS activity. Since this configuration seems to give a higher cavity power in IMC, we are leaving as it is and fix the IM4 and PR2 angles to compensate it. The attached is 4 hour trend of various IMC-related signals. It is obvious that as the picomotors moved the suspension were also moved, resulting in a different pointing at the IM4 trans QPD.

Images attached to this report
H1 AOS
suresh.doravari@LIGO.ORG - posted 19:09, Friday 14 November 2014 (15077)
Diode laser 122-1 : HAM3 Oplev: performs well.

[Doug Cook, Suresh Doravari]

 

This is with reference to the  alog 14902 which described the 100% power drop outs in diode laser unit 199 .  Though I managed to stop it from those power drop outs, it turned out that the temperature servo is somehow broken in this laser.  The long duration trend below shows that the power never quite reaches a stable operating  point even after several days.   Consequently the laser does not stop glitching either.

 

 

We fixed unit 130-1 and plugged it  into HAM3 oplev.   This laser did not require any fiber port alignments.  We just adjusted the T setpoint to shift its stable operating power.  1.12V (unscaled temperature indicator) to 1.03V.

This unit is currently operating in HAM3 oplev for the past few days and its performance is good.  There have been no glitches since we plugged it in and chose an appropriate operating power.   The plot attached shows 6 hour stretches over 24 hours. 

The Pitch Sum and Yaw spectrogram shows that even though there are no glitches in the laser power output (Sum signal) the Pitch and Yaw signals show glitches.  Which indicates table motion or perhaps pier motion. This requires further investigation.

The spectra of HAM3 oplev is posted chiefly to show that the gain and whitening currently set are adequate to raise the signal above the ADC noise.

Images attached to this report
H1 CDS
cyrus.reed@LIGO.ORG - posted 17:01, Friday 14 November 2014 (15074)
Finished Compressing Autoburt Snapshots
I've finished compressing the autoburt snapshots.  This has reduced the space utilization on /ligo from a high of 81% down to 48%.  The rough compression ratio was about 10:1.  In each burt year directory with compressed archives there is now a CHECKSUMS.MD5 file with the md5 checksum of each archive which may be used to verify the integrity of the archive if needed.  Rsync backups of /ligo should now be somewhat more efficient as well with fewer files to compare looking for changes.
H1 PEM (PEM)
dale.ingram@LIGO.ORG - posted 16:49, Friday 14 November 2014 (15073)
Friday seismic forecast
Commissioners can expect Hanford hauling on swing shift tonight (Friday).  No hauling or ERDF activity is scheduled for the weekend.

Today's daytime 1-3Hz seismic trace suggested that there's some clumping of the trucks.  I saw this as I headed toward LHO on Stevens Drive this afternoon.  I was accompanied by three full trucks that were traveling within ~300 meters of each other.
H1 ISC
alexan.staley@LIGO.ORG - posted 16:40, Friday 14 November 2014 - last comment - 14:20, Saturday 15 November 2014(15072)
Recovering input alignment

Evan, Keita, Kiwamu, Alexa

It had appeared that the temperature in the LVEA had stablized (alog 15054) so we went about realigning in the IFO. Here is the original alignement we started with:

  PR3 IM4 PR2
Pitch -246.0 13350 1057.2
Yaw 88.0 -5056 2971.3

Here are the initial steps we took:

  1. Align/lock X and Y arm on green. Note: this required a big adjustment since the temperature had also drifted in the end station.
  2. Adjust PR3 to get COMM beatnote back to nominal of about 0dBm; I adjusted PR3 by +2.5urad in pitch, and +0.3urad in yaw
  3. Lock the IR to the X arm; this required an adjustment of PR2 in pitch by -34urad.
  4. Run the wfs feedback to IM4, PR2 to get full build of IR in the x-arm

At this point, we noticed that the WFS had brought IM4 to a bad alignment. Keita has measured the PR2 baffle clearance (alog 15063); and IM4 was not within range in YAW. So we basically started from scratch, and did the following:

  1. X,Y arm locked on green
  2.  X arm locked on IR
  3. Run wfs to keep IR build up at a maximum and adjust PR3 until IM4 was at a good position. I had to adjust PR3 by +2.5 urad in pitch, and -76.1 urad in yaw.
  4. Adjust HAM 3 pico's to get the green beams on ISCT1; i.e. to restore our usual values for ALS-Y, ALS-X_TR_A_LF_OUT  ~ 1 cnt each
  5. Adjust the DIFF and COMM beatnote on ISCT1. Evan had to move the BS in the DIFF path because the X-arm was almost completely off the BS (he will post more about this).

Now we have the following:

  PR3 IM4 PR2
Pitch -243.5 12694.7 926.2
Yaw 13.9 -5052.5 2312.2

 

  ALS X Camera ALS Y Camera
X pos 393.1 267.8
Y pos 250 289

COMM beatnote: 6dBm, DIFF beanote: -1.6dBm. When I get a chance again I will take a snap shot of the ALS camera images, but for reference these image is a bit clipped for both beams; however the transmission is good and the beatnotes are good so it's just the image.

 

Apparently, the end station temperatures are still drifting. This will affect the DIFF beatnote. Unfortunatly if EX drifts a lot we will need to re-do this input alignment again ...

Comments related to this report
alexan.staley@LIGO.ORG - 20:49, Friday 14 November 2014 (15083)

We this alighment we achieved a build up of around 210 for PRMI after we ran the inital alignment procedure. We are pretty content with this for now. As Evan aloged we couldn't keep going because of an earthquake.

As a reminder, Nic was in the middle of aligning POPAIR on ISCT1 when the earthquake hit, so we need to finish this next time we lock PRMI.

Also, as a note, we have left SR3 in the old configuration and Kiwamu has aligned ASAIR and the camera on ISCT6 for this old configuration.

evan.hall@LIGO.ORG - 22:06, Friday 14 November 2014 (15084)

In regard to the work on ISCT1: I touched up the beat note power onto the COMM diode; it was relatively straightforward. I also did DIFF, but it was much more touchy. Also, the mount for the DIFF interference BS is not oriented correctly; when the beams are passing through the clear aperture of the optic, the TRY beam is clipping on one of the mount knobs. The BS mount needs to be rotated to resolve this.

evan.hall@LIGO.ORG - 14:20, Saturday 15 November 2014 (15087)

With PRMI locked, I have gone onto ISCT1 and realigned the beam onto POPAIR_B.

LHO General
patrick.thomas@LIGO.ORG - posted 16:04, Friday 14 November 2014 (15068)
Ops Summary
08:22 Ken to end X to move AC receptacles (WP 4945)
08:45 Jeff B. and Andres to end stations to pack up tooling
08:52 Karen to end Y to clean
09:00 Chris done cleaning in LVEA
09:01 Aaron and Filiberto to end Y to pull PEM cables
12:05 Karen done
12:06 Jeff and Andres done
12:13 Aaron and Filiberto done
13:07 Bubba to inspect end station mechanical rooms
15:01 Cyrus to mid X to test phone
15:03 Suresh to adjust optical lever by HAM3
16:02 Suresh done
H1 CDS (ISC)
david.barker@LIGO.ORG - posted 13:28, Friday 14 November 2014 - last comment - 22:55, Friday 14 November 2014(15067)
investigation into strange LSC ramped mux matrix behavior last weekend

Alexa, Nic, Jim, Dave

Alexa reported strange LSC-PD_DOF_MTRX input ramped mux matrix behavior last weekend. Symptoms were: new element values were taken immediately without loading, ramping continued indefinitely. The current theory is that a rogue script is setting H1:LSC-PD_DOF_MTRX_LOAD_MATRIX to 1 frequently. On monday this channel was added to conlog, and conlog reported that during monday afternoon and early evening this EPICS channel was being set to 1 several times a second. We also discovered that the DAQ trends were not showing this high frequency activity, this underreporting is under investigation (only seen in the LOAD channel, all other matrix channels trend correctly).

At 11/10 20:19PST monday evening the rogue loader stopped running and has not restarted since. Initial scans of guardian and home account directories have not found any script which would be loading the matrix frequently. Guardian logs its PV settings and these are seen at very low rates (max 100 per day). We may have to wait for the problem to reappear in order to track it down further. Investigation is continuing.

Comments related to this report
jameson.rollins@LIGO.ORG - 14:36, Friday 14 November 2014 (15069)

This reeks of bad guardian programming to me.  I would put money on one of the ISC nodes writing a one to that LOAD_MATRIX channel every cycle.   Look for that channel name in whatever guardian node is actuating on that matrix, or just grep for it in all ISC nodes.

alexan.staley@LIGO.ORG - 17:07, Friday 14 November 2014 (15075)

Jamie, we had seen this behavior with all the ISC guardians set to "DOWN" and/or paused. I don't see any guardian that loads the matrix in the "DOWN" state.

H1 SUS
keita.kawabe@LIGO.ORG - posted 09:32, Friday 14 November 2014 - last comment - 11:59, Friday 14 November 2014(15056)
IM4 was found tripped in the morning.

It tripped at Nov 14 2014 03:48:32 UTC, which is 19:48:32 local time yesterday.

Comments related to this report
kiwamu.izumi@LIGO.ORG - 11:59, Friday 14 November 2014 (15066)

Probably it was me shaking the HAM2 ISI for checking the PR3 performance. Good catch !

H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 23:31, Thursday 13 November 2014 - last comment - 22:51, Monday 17 November 2014(15049)
Potentially New H1 SUS ETMY UIM (L1) L2P Filter Design
J. Kissel

I've measured new transfer functions necessary redesign of the H1SUSETMY UIM (L1) DRIVEALIGN frequency-dependent decoupling filters for L2P and L2Y. For the impatient, the last page of the last attachement shows a comparison between the proposed new design and the old, currently installed / in-use design. I have *not* installed this filter because I'd like to discuss the results with commissioners tomorrow morning (and it'll take me some time to resurrect quack to get these installed). In fact, this may argue for us to indeed just copy over ETMX's filter.

Details:
-----------------------------------------
I attach the measurement results (see 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf), but the raw templates can be found here:

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/Results/Data/
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise_ReactionChainTest.xml
2014-11-13_H1SUSETMY_L1_L2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_P2PY_WhiteNoise.xml
2014-11-13_H1SUSETMY_L1_Y2PY_WhiteNoise.xml

Not that I drove through the TEST filter banks (instead of having to turn off all the existing filters in the LOCK and DRIVEALIGN banks), and made sure that optical lever damping was OFF, and local damping was the LLO design as described in LHO aLOG 14959.

I focus this entry solely on L2P, but the data exists for an L2Y filter if ever needed. in the first four pages, Pink curves are the current measurement, and black curves are what were used in the original design of the previous filter by Arnaud (see LHO aLOG 11832). The encouraging fact is that the data supports exactly what we'd model from the change in damping loop filter design (see green traces on pg 5 of first attachement to LHO aLOG 14959). As an aside -- just because Betsy made me think of it while chasing down slider values -- what effect does reaction chain alignment have on these off-diagonal, lower-stage transfer functions? One might guess that if the L2P cross-coupling isn't something fundamental but a result of dirt alignment affects between the coils on the reaction chain and the magnets on the main, then one would see a change in the L2P transfer function with different alignments of the reaction chain. The good news is that is doesn't have any effect -- see the last page of 2014-11-13_H1SUSETMY_L1_drivealignfilters_rawdata.pdf. I compare the same transfer function for 4 different reaction chain alignments. They still have the old dead-reckoned calibration factors installed, so we know they're not exactly [urads] but close enough for the scale of these offsets used; they use up about 1/2 the DAC range.

As far as the design goes, I used the same transfer function fitting routine and filter generation software suite that (I think) Arnaud used, namely the function
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/FilterDesign/Scripts/Length2Angle_decoupling.m 
which is essentially a wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/happyVectfit.m 
which Keita's wrapper around the function,
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/vectfit3.m
All tweaking of input parameters to the fitting routine, and plots were made using the overarching script
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/SAGL1/design_H1SUSETMY_L1_L2P_20141113.m

Notable key additions to the design software -- a computation of the final filter's impulse response, as well as a comparison to the previous design.

As I know Arnaud had struggled, I struggled to find a fit with which I was really happy, namely because we all *know* that the L2P transfer function should fall off as some large power of frequency (again, see the models of these TFs on pg 5 of LHO aLOG 14959), but I can't find a set of parameters happyVectFit / vectfit3.m that allows for such a roll-off at high frequency. Indeed, the height of the final flat part of the L2P fit transfer function directly determines the high-frequency gain of the decoupling filter, and directly impacts the impulse response time. I settled on a filter that does a poor job at reproducing the > 2 [Hz] behavior of the L2P measurement, BUT I think it's OK because
(a) the small magnitude of the high-frequency causes a significant drop in impulse response time, and
(b) At the UIM, we're typically driving below 2 [Hz] -- especially if the crossover remains at 0.9 [Hz] as quoted in LHO aLOG 15025, so the accuracy of inversion is not so critical. Though I didn't find any design aLOGs, this seems to have been the philosophy behind the ETMX UIM L2P filter because it ends up looking strikingly similar.
I should say also that having to tune the uncertainty tolerance, the order (i.e. number of poles) in the filter, the tolerance for when to throw out adjacent poles and zeros, the frequency range over which to fit -- all free parameters into happyVectFit.m -- as one has to do to get what one wants in the end really destroys the advantage of automating the fitting process. If only there was a better way...
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:55, Friday 14 November 2014 (15076)ISC, SEI
I've installed the filter into H1:SUS-ETMY_L1_DRIVEALIGN_L2P filter bank, in FMs 5&6 via autoquack. 

HOWEVER
(1) I have not tested the filter performance with transfer functions or step response
(2) I've split the L2P and (invP2P * rolloff) into two filter banks. Even with the rolloff, the (invP2P * rolloff) filter has more zeros than poles, so foton has added a whole bunch of high-frequency poles to compensate. Though the *total* filter's -- L2P * (invP2P * rolloff) --  number of poles is equal to the number of zeros, I think the high-dynamic range, zero pole, cancellation between the two filters isn't working out. This is resulting in a HUGE calculated impulse response, which may or may not be real.
(3) This is my first time using quack to install Matlab filters into foton in a *really* long time, so I'm nervous of its functionality.

I attach a series of comparisons with ETMX's filter. The bode plot, in the frequency band we care about (pgs 1 and 2) seems reasonable. Both ETMX and ETMY have some high-frequency garbage in their impulse response, but the overall amplitude of the impulse response in ETMY is many orders of magnitude larger than that of ETMX (!!!). Further, taking the transfer function out well beyond the Nyquist frequency, we see that they behave significantly differently at the Nyquist frequency (~7 [kHz]).

As such, I'm still entirely unsure that this new filter gunna work, and may require further tweaking.

Anyways, these are installed in 
FM5 "UIM_L2P"
FM6 "UIM_invP2P"
and should be turned on TOGETHER, with no other filters engaged in the module, if one would like to be bold and try it over the weekend.

P.S. in case you've forgotten, when you autoquack in a filter who's name has a space in it, and you try to load the new filter coefficients, Foton will hate you. You will, at least, get a nasty-gram on the GDS_TP screen's filter message, ${IFO}:FEC-${DCUID}_MSG saying "bad filter coeff definition on line 259 in .txt," pointing you to the exact line of the problem. So with Jim's confirmation that "Oh yeah, you DEFINITELY don't wanna do that." I changed spaces to underscores and all worked fine.
Non-image files attached to this comment
nicolas.smith@LIGO.ORG - 22:51, Monday 17 November 2014 (15117)

These filters did indeed run away and saturate the DAC. (The EPICS values were even showing “-Inf,” I’d never seen that before). I don’t think we can get away with more zeros than poles in a filter module, even if they are compensated by some other module.

I took the two filters (FM6 and 7) and viewed them in the foton “Multiple” mode, then I took the output in the “Alternate” box of foton and copied that into FM10.

When I tried this, instead of a huge mess I got a nice step response according to foton, and the frequency response was the same as the two original filters. As seen below (new is red, old is blue):

foton
However, stupid foton wouldn’t save the filter (but gave no error message). In the end, I had to take this “Alternate” output and split it up into two filters, being careful that each had more poles than zeros. This allowed me to save the foton file and load the filters into the frontend. I tested that the impulse response behaved nicely by putting an offset into the filter bank.

The two filters are in FM5 and FM10. Their names reflect my frustration.

Images attached to this comment
Displaying reports 69861-69880 of 84537.Go to page Start 3490 3491 3492 3493 3494 3495 3496 3497 3498 End