Displaying reports 46001-46020 of 88268.Go to page Start 2297 2298 2299 2300 2301 2302 2303 2304 2305 End
Reports until 15:58, Monday 20 August 2018
H1 ISC
jenne.driggers@LIGO.ORG - posted 15:58, Monday 20 August 2018 (43541)
DHARD Pit measured

We were concerned about the stability of the DHARD loops (seems like it wasn't them limiting our lock length after all), so I measured DHARD Pit since we were seeing pitch angular drift. 

Here is the measurement.  So far, we haven't modified the loop, but we do note that it is much lower bandwidth than it used to be.  This is okay as long as we have less motion to control, but we may find that we need to increase the bandwidth.

I upload a screenshot of the measurement in red, with 2 references from O2.  The .xml file is in our loop measurement svn place: /ligo/svncommon/IscSVN/iscmodeling/trunk/ALIGOH1/ASC_loops/Measurements/DHARD, and has been checked in.

Images attached to this report
H1 General
travis.sadecki@LIGO.ORG - posted 15:52, Monday 20 August 2018 (43537)
Ops Day Shift Summary

TITLE: 08/20 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:  Commissioners working on getting to DC Readout.  HWSY and CO2Y work throughout the day.
LOG:

See attached txt file.

 

Non-image files attached to this report
H1 TCS (AWC, TCS)
daniel.vander-hyde@LIGO.ORG - posted 15:09, Monday 20 August 2018 (43539)
ETMX Ring Heater test

TVo, Georgia, Danny

Attached are some results from the ring heater test that took place on August 15th 2018. Attached is some trend data and a contour plot that summarizes the results. The Hartmann trend data and contour plot looks pretty noisy. It was a bit tricky choosing a good starting time for the contour plot since green was on the Hartmann camera right before the measurement. Because of this, the trend data includes the ETMX green beam shutter state since it was shuttered right before turning on the ring heaters. More on the End X Hartmann soon. 

Images attached to this report
H1 SEI (DetChar, PEM, SEI)
jeffrey.kissel@LIGO.ORG - posted 14:21, Monday 20 August 2018 (43538)
Seismon Request -- Convert Peak Velocity to RMS Velocity in 30-100 mHz
J. Kissel, J. Warner

After Jim, Carlos, and Dave worked with Nikhil and Michael to get Seismon up and running again (see LHO aLOG 43486), we've been confused by the estimate of the peak surface velocity on-site. 

See attached trends: I compare the 30 - 100 mHz RMS ground velocity of seismometers on site against the EQ magnitude and predicted peak velocity as reported by seismon. One can see that the peak velocity is consistently reported orders of magnitude larger than what's seen on site, and for earthquakes of magnitude ~5 -- where seismon predicts we should see a peak velocity in the ~5 um/sec range on site -- they're just not at all visible in the 30 -100 mHz band. 

Of course, I know that peak velocity is not the same and RMS in the 30-100 mHz frequency band. Thus my request to team Seismon: can we create a prediction for the 30-100 mHz RMS velocity on site in addition to the peak velocity estimate? This would greatly facilitate control room operation.
Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 13:16, Monday 20 August 2018 (43535)
Valved-in CP2's small ion pump

This was done this morning. 

H1 CDS
patrick.thomas@LIGO.ORG - posted 12:34, Monday 20 August 2018 (43534)
h1ecaty1 IOC crashed, restarted
Screenshot of error attached.

Same as previous errors documented in FRS 8220.
Images attached to this report
H1 SQZ (SQZ)
nutsinee.kijbunchoo@LIGO.ORG - posted 12:16, Monday 20 August 2018 - last comment - 22:48, Tuesday 21 August 2018(43531)
CLF loop characterized and LO loop closed

Daniel, Terry, Haocun, Nutsinee

CLF

The furthest I can push the UGF was 6kHz. This gave us a gain margin of ~30deg. You can push to 8 but then gain margin drops to 10deg. 

 

 

LO

We closed the LO loop for the first time last Friday. Homodyne seemed to have a lot of RF gain. We were hitting it with no more than 200uW of optical power (CLF+LO combined) and it was already producing 6MHz harmonics straight out of the box. To get rid of the harmonics we are now hitting it with 157uW combined optical power (17uW CLF, 140uW LO). Homodyne RF characterization will be posted in a separate alog.

 

The UGF was around 2kHz with ~40deg phase margin. This cannot be pushed further because of the huge peak around 34kHz that's believed to be LO PZT. To see if current loop configuration is good enough we'll have to look at the noise spectrum out of the error signal when the HD is well balanced. Currently we seems to have a beam splitter that drifts over night in front of the HD.

 

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 22:48, Tuesday 21 August 2018 (43576)

Correction: "17uW CLF, 140uW LO" are power that went into EACH diode. To total power went to HD was actually 2x(140+13) uW

H1 ISC
jenne.driggers@LIGO.ORG - posted 11:57, Monday 20 August 2018 (43533)
LSC-REFL pico'ed

[Stefan, Gabriele, Hang, Jenne, Dick]

In order to relieve the RMs with the DC centering loops for REFL WFS turned on, Hang pico'ed to center on the REFL WFS yesterday (Sunday).  Unfortunately, we found that PRX was having difficulty locking this morning.  This perhaps makes sense in that the RMs also controlled the steering onto the LSC PD, but the picos do not.  We put oscillations onto the RMs and saw that the DC power on the LSC PD was changing dramatically, so we pico'ed the LSC PD to center.

To do this, we had closed the DC centering loops, then opened the loops (leaving the integrated values in place), and put oscillations in the RM1 TEST filter banks.  We made the oscillations large enough that we could see the edge of the LSC PD.  We pico'ed until the dip in power was roughly similar on both sides of the RM's oscillation.  We did this for both pitch and then yaw. 

Note that when we first did this, I had accidentally actuated on the LSC-POP picomotor.  I put the pico's counter value back to where it had been, although of course we won't be on the exact same spot on the LSC POP diode.  We watched that as I put the picomotor back, we didn't see any change in the DC amount of light on the diode, so we are at least not clipping. 

H1 ISC (ISC)
gabriele.vajente@LIGO.ORG - posted 10:09, Monday 20 August 2018 (43528)
AS centering loops

In summary, following the same method used for the REFL DC centering loops, I measured and optimized the AS_A and AS_B centering loops (DC3 and DC4). The loop design is the same used for the REFL WFS, with a bandwidth of about 5 Hz and it includes the additional low pass filter at 25 Hz.

Details

Output matrix diagonalization

Following the same procedure described in 43451, I measured the DC response of the DC3 and DC4 loops, by adding offsets to OM1 and OM2. The figure below shows the resulting diagonalized output matrix. The original matrix was close enough.

 

 

Plant transfer function measurements

Although there was no reason to expect the OM's to behave differently from the RM's, I measured again the plant transfer function, using the same procedure described in 43488. It turns out that the frequency dependence is quite similar to the RM's, but there is a large difference in the overall gain: the OM responses is about 50-100 times larger than the RM responses, in terms of QPD normalized signals over OM motion. Not surprising, since the optical path from the OM's to the AS WFS is different from the optical part from the RM's to the REFL WFS. The plot below shows all four OM responses.

 

Below the fit parameters

  Zeros [Hz] Poles [Hz] Gain at DC
DC3 pitch

  -0.1001 + 1.4090i
  -0.1001 - 1.4090i

  -0.1224 + 1.3754i
  -0.1224 - 1.3754i
  -0.1583 + 1.8176i
  -0.1583 - 1.8176i

4.1480
DC3 yaw  

  -0.1630 + 1.6067i
  -0.1630 - 1.6067i

4.6743
DC4 pitch

  -0.0881 + 1.3958i
  -0.0881 - 1.3958i

  -0.0952 + 1.3583i
  -0.0952 - 1.3583i
  -0.1937 + 1.7722i
  -0.1937 - 1.7722i

4.8371
DC4 yaw

 

  -0.1766 + 1.6754i
  -0.1766 - 1.6754i
4.8371

Loop design

I used exactly the same control filters that were described for DC1 and DC2 in 43488, the only difference being in the overall gain. Those filters also include the low pass at 25 Hz, described in 43501.

I measured the open loop transfer function of all four loops and found no surprises: the loop are stable for all low values of the gain. With a gain setting of -0.5 in the DC3 and DC4 filter banks, the UGF is about 5 Hz for all loops. I did not fine tune the gains to have exactly the same bandwidth. The differences are small.

 

The configuration of all filter banks and switches is shown in the file attached.

Boost

Just in case we need more low frequency gain in the centering (not sure why...), I experimented on a boost (complex pole at 0.3 Hz, complex zero at 1.8 Hz). With this boost on the loop is clearly no more stable for all values of low gains, but margins are still reasonable.

 

Images attached to this report
H1 PSL
edmond.merilh@LIGO.ORG - posted 09:39, Monday 20 August 2018 (43527)
PSL Weekly Report - 10 Day Trends FAMIS #10571
Images attached to this report
H1 SEI
travis.sadecki@LIGO.ORG - posted 08:43, Monday 20 August 2018 (43525)
HEPI Pump Trends

Pressures appear reasonable.

Images attached to this report
H1 PSL
travis.sadecki@LIGO.ORG - posted 08:26, Monday 20 August 2018 - last comment - 17:52, Tuesday 21 August 2018(43523)
PSL Weekly

Laser Status:
SysStat is good
Front End Power is -0.001465W (should be around 30 W)
HPO Output Power is 73.48W
Front End Watch is RED
HPO Watch is RED

PMC:
It has been locked 0 days, 4 hr 9 minutes (should be days/weeks)
Reflected power = 15.27Watts
Transmitted power = 41.38Watts
PowerSum = 56.64Watts.

FSS:
It has been locked for 0 days 11 hr and 29 min (should be days/weeks)
TPD[V] = 2.113V (min 0.9V)

ISS:
The diffracted power is around 3.2% (should be 3-5%)
Last saturation event was 1 days 18 hours and 52 minutes ago (should be days/weeks)

Possible Issues:
Front End Power is Low
LRA out of range, see SYSSTAT.adl

 

Comments related to this report
travis.sadecki@LIGO.ORG - 08:32, Monday 20 August 2018 (43524)

Someone from Team PSL should look into why the Front End Watch is red and the Front End Power is being reported as zero when it is actually not.

travis.sadecki@LIGO.ORG - 11:41, Monday 20 August 2018 (43532)

FRS ticket 11302 created.

edmond.merilh@LIGO.ORG - 16:08, Monday 20 August 2018 (43542)

The FE power was being reported by a power meter inside the HPO which is no longer included in the beam path. The new reading wil come from the pick-off that was installed at the output of the MOPA in conjunction with the 70W amplifier installation (channel for this TBA). I'm not sure about the FE watchdog showing RED. HPO WD needs to be changed to amplifier(or something) WD and LRA range is no longer of any use.  Also, I noticed that output power of the new amp is being reported as the HPO power (simple metadata change?). Everything else looks ok. I can look into this further and see about working on getting that MEDM screen/channels edited.

jason.oberling@LIGO.ORG - 17:52, Tuesday 21 August 2018 (43572)

The script used to create the above report needs to be updated (it's on my list to sit down with TJ and do this).  As Ed says, the FE power is being measured by a PD that is no longer in use; a new one has been installed and the channel exists (H1:PSL-AMP_PWR4 if I remember off the top of my head correctly).  The watchdog was red because it was OFF, so the report was functioning as intended here.  We also need some name changes for some of the items (HPO Output Power should be something like "70W Amp Output Power" and likewise for the watchdog), as well as an edit of the System Status check to match the changes for the 70W amplifier.

H1 ISC
stefan.ballmer@LIGO.ORG - posted 21:49, Sunday 19 August 2018 (43522)
SRM top mass relief ringing
Sheila, Hang, Stefan

We tracked the frequent lock-losses in CART_TO_ANALOG to SRM: the M3 to M1 relief filter was producing a lot of ringing around 20Hz when kicked. And it gets kicked by CARM transients during 1dB steps in CARM, feeding forward to SRC through the input matrix. We lowered the M1 gain from -0.02 to -0.01. (updated in Guardian) This reduced the transients enough that we no issues in CARM_TO_ANALOG anymore. We also successfully engage the 4kHz analog boost again, and left that as default in Guardian..

Next we locked the OMC, but needed to fix the OMC camera.
H1 AOS
daniel.vander-hyde@LIGO.ORG - posted 19:39, Sunday 19 August 2018 - last comment - 10:24, Monday 20 August 2018(43520)
HAM6 OMC TRANS cam not displaying image

Danny, Stefan, Hang

Went out to with Stefan realign the HAM6 OMC TRANS camera to better image the beam on the CCD. After Stefan left, Hang and I tried finishing up the job but the camera became unresponsive to medm. The camera started to run hot after a while so we believe the camera is suspect here and not the connection. To test this we carefully used the ISCT SHG TRANS connection to see if we could get any response from the HAM6 OMC TRANS cam. It still did not work. I reinstalled the camera back in its original place but I did not plug it back in (to avoid overheating). 

Comments related to this report
stefan.ballmer@LIGO.ORG - 10:24, Monday 20 August 2018 (43530)
- These cameras get pretty warm, so that part is normal.
- Video did no longer come up because the camera server on h1digivideo1 died. To restart:
   - ssh on to controls@h1digivideo1 (h1digivideo0 : CAM 01-10; h1digivideo1 : CAM 11-20; h1digivideo2 : CAM 21-30; etc)
   - the control commands can be found here: more /etc/monit/conf.d/h1digivideo1-cams 
   - in particular, to start CAM15: /etc/init.d/h1cam15 start
- The rest was some painful aligning of the hard-to-access camera inside the view port cover (with the lexan-shield in place).

Bottom line: the OMC_TRANS camera is operational again.
H1 CDS (DetChar)
robert.schofield@LIGO.ORG - posted 16:18, Sunday 19 August 2018 - last comment - 18:29, Monday 20 August 2018(43425)
Update on testing of new I/O chassis in H2 test stand

Summary: Previously we detected no contamination of ADC channels by fans or from magnetic fields from the on-board power supply, but saw drifting lines. After powering I/O and AA chassis with linear supplies, the drifting lines were much reduced. There are three remaining more subtle issues: 1) Coherence between blank ADC channels in a 0.94 Hz comb, produced by a flashing LED that indicates link state, 2) A 1.000 Hz comb in the duotone channel that is coherent with some blank ADC channels, 3) An occasional drifting line, that produces coherence between blank channels, suggesting a rouge oscillator in the AA or I/O chassis.

A previous log noted that the new I/O chassis has much lower contamination from fans and power supply magnetic fields than previously tested I/O chassis, but that there were drifting intermodulation peaks, possibly associated with the 24V power from a Sorenson switching power supply ( https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=42907 ).

During the DetChar f2f, we powered the I/O chassis with a linear supply and found that the drifting peak features were mostly gone. I have since been looking into more subtle features in the blank channels of the I/O chassis. Figure 1 shows that the blank channel spectra are smoother (no evidence of drifting peaks) and the coherence between channels is significantly less than it was before replacement of the 24V switching supply (compare Figure 1 to https://alog.ligo-wa.caltech.edu/aLOG/uploads/42907_20180715170051_Figure4-CoherenceBetweenEmptyADCChannels.pdf ). But Figure 1 also shows that there are features associated with LED flashes.

The odd harmonic series in the magnetometer signal of Figure 1 appears more strongly in the magnetometer signal when the magnetometer is near to flashing LEDs (link indicators) on the ADNACO-R1BP1B board (photos are also included in Figure 1). The coherence at LED frequencies between the magnetometer and the blank ADC channels reaches 0.1. The blank ADC channels are coherent with each other at the LED frequencies even when there is no magnetometer  connected, so the signal on the blank channels isn’t cross talk, and is probably associated with the periodic load on the power supply.

Dave B. notes that if the system were working as expected, the link LEDs should not be flashing.

In addition to the near-1 Hz comb, there was also a 1.000 Hz comb. Figure 2 shows that a 1.000 Hz peak, appears strongly (1 count) in ADC channel 31 (the duotone channel), and less strongly in other ADC channels (coherence reaching 0.01).  The LED flash peak is also apparent at 0.94 Hz in Figure 2, though all ADC channels are blank. Both peaks have an associated comb, odd harmonics for the LED peak and all harmonics for the 1 Hz peak.

The second page in Figure 2 shows that the duotone signals are at about 10^4 times the size of the 1 count peak at 1 Hz. The direct cross talk of the 960 and 961 Hz lines in, say, channel 15, visible in the power spectrum plot of the second page of Figure 2 at about 4e-2 counts, does not seem large enough to produce the 1 Hz comb in channel 15 through the same 1e-4-scale non-linear mechanism.  It may be that the 1 Hz comb on other channels has a different source or mechanism. We might be able to modify the duotone, such as by avoiding the zero cross region, to further study this. Since search groups had problems  with1.000 Hz and near-1.000 Hz combs in DARM during O2, I think it is important to understand/eliminate these peaks.

A final issue was that, although drifting peaks were reduced when the I/O and the AA chassis were placed on linear supplies, I found drifting peaks (Figure 3) in a couple of many spectra. I suppose that this peak could be associated with some rouge oscillator in the chassis.

Dave Barker, Sumeet Kulkarni, Philippe Nguyen, Robert Schofield

 

Non-image files attached to this report
Comments related to this report
keith.thorne@LIGO.ORG - 16:26, Sunday 19 August 2018 (43518)
Rolf Bork noted in our meeting last week that we could work with the vendor to get modified firmware to ensure that LEDs do not blink during normal operation. These indicators are related to the PCIe bus speed of the host computer.  We have found that changing the PCIe riser card from 3-slot to 4-slot on the original front-end hardware drops the PCIe bus speed from 5 GT/s to 2.5 GT/s.  In switching to long-distance PCIe RFM, we remove the need for the 4-slot riser cards.
david.barker@LIGO.ORG - 13:40, Monday 20 August 2018 (43536)

There was a misunderstanding, the on-board LEDs indeed should be flashing to indicate our ADC/DAC/BIO cards are PCIe-1 version cards with a reduced data transfer rate of 2.5GT/s.

keith.thorne@LIGO.ORG - 18:29, Monday 20 August 2018 (43545)
Another reason to go for custom firmware on these boards. I confirmed this behavior with the two long-distance I/O chassis at LLO for PEM MID.  The LEDs do blink on the slots with the Gen1 adapters (ADC, DIO)
H1 SEI
sheila.dwyer@LIGO.ORG - posted 12:58, Sunday 19 August 2018 - last comment - 10:04, Monday 20 August 2018(43514)
Comparing Fiji EQ to Montana EQ July 6th 2017

Summary:

Last night's 8.2 in Fiji (at 0:49:00 UTC on August 19th 2018) is one of the larger EQ's we've had since the Montana EQ on July 6th 2017 6:35 UTC, on first glance it seems that the changes we made to protect our suspensions better after the Montana EQ were successful in reducing the amount of swinging that our quads did during this EQ. We will also want to make some charge measurements to make sure we didn't have any jumps in charge from hitting stops. 

Details:

Here is a comparison of ground velocity BLRMs: 

Frequency Montana (um/second) Fiji
30-100mHz 19 55
0.1-0.3 Hz 61 22
0.3 -1 Hz 20 24

After the Montana EQ we saw that our suspensions didn't return to the same positions for the same applied torque, and we had problems with charge on the optics. During the Montana EQ all of our ISI WD's tripped so that ISIs weren't damped, and all 4 quad suspensions also had their damping turned off by watchdogs.  Since that time we have made several changes to the watchdogs to better protect our suspensions:

In last night's EQ none of the quad suspensions tripped, while all the suspensions tripped and turned off top mass damping last July.   Looking at top mass pitch osem trends from last night, the peak to peak excursions were about a factor of 10 smaller than last July (300-600urad pp compared to 10mrad pp last July).  See the first attachment.  

For all the quad chambers, the ST1 trip was on the actuators and the stage 2 the first trip was on the CPSs.  Looking in more detail at ETMX (which seems similar to the others) The both ST1+ST2 watchdogs tripped within a second and did stay in state 2 (damping on, not checking for saturations) for 60 seconds before proceeded to state 3 as expected and described in T1700481.  The 60 second hold time was based on the Montana EQ (38919), and in this case it seems like 60 seconds was an adequate amount of time for the largest of the disturbances from the EQ to pass by.   Once both ST1+ ST2 watchdogs enter state3 where they begin to check for saturations again, the GS13s were still saturating and caused ST2 to go to state 4, full shutdown after about 7 seconds.  The shutdown of ST2 caused a kick to ST1, which saturated the L4Cs, and this caused the ST1 watchdogs to go to full shut down 2 seconds after ST2.  

We should also note that Stefan and T Vo pushed the VERY LARGE EQ button.  This button has been giving error messages lately, I don't know if it is really working. 

PS, I think I noticed a typo on the WD screen while looking at this, for ST1 where I think the monitor should be looking at  H1:ISI-ETMX_ST1_WD_L4C_SAT_COUNT it is looking at H1:ISI-ETMX_ST1_WD_MON_FIRSTTRIG

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 10:04, Monday 20 August 2018 (43529)

Thanks for looking at this Sheila but I think things are correct.  There are a few widgets on the WD screen in that area and they don't always stack up the same; so, when you middle mouse to get the channel name, you may not compare apples to apples.

The SAT_COUNT is the actual number of current saturations, the FirstTrig field you saw is compared bit wise to turn on the red light as appropriate.  I don't believe there is any problem in what is displayed but let me know if you see something of which I need be aware--thanks.

H1 SEI (DetChar, PEM)
hugh.radkins@LIGO.ORG - posted 08:47, Friday 17 August 2018 - last comment - 09:21, Monday 20 August 2018(43485)
Tenax Fabric on proto type Wind Fence--First look

Had a bit of breeze at my house last night so checking this morning shows indeed we had some breeze last evening that provided a consistent period for inspection.

Found about 20 minutes from 2210 to 2230 pdt where the direction settled down in a favorable direction around 90o; that is, from due west, normal to the fence upwind of the building.  The attached 20 minutes of full data show a few things:

* The roof top PEM anemometer, Ch 1 and Ch 3, the fence direction sensor are in agreement to within ~20o.  Maybe this needs correcting or possibly the building is influencing the flow direction.  This could be evaluated by looking at the difference in direction as a function of direction.

* The PEM roof-top wind speed, Ch 2, seems to be consistently higher than the fence free air speed, Ch 4.  This makes sense as the roof top sensor is maybe 20' higher and the building itself may be providing some velocity increase.

* Comparing Ch 4 & Ch 5, the fence free air sensor and the sensor just 10' upwind of the fence, you see a noisy maybe 10 or 15% reduction of velocity--subject to better analysis than my simple point-by-point division (shown in red on the plot with Ch 5.)

* Comparing Ch 5 & Ch 6, the upwind and downwind (of the fence) sensors, the downwind data is clearly smoother and a comfortable 50% reduced compared to the upwind channel.  Again, the red trace on the plot with Ch 6 is (1-Speed_4/Speed_2)

Clearly the Tenax fabric is effective and produces about a 50% velocity reduction, at this free-air speed.

Look forward to Elyssa's more thorough and detailed analyses as nice wind events present themselves.

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 09:21, Monday 20 August 2018 (43526)

I thought I had noticed, when looking at the trends for this above, that the sensor downwind of the fence had narrower MAX & MINs.  Looking at these again, I thought I was reaching as I could not see it clearly in the basic trends.  So, I subtracted the MIN from the MAX and plotted that, here, below.  Not sure if this is the best way to quantify this observation but it seems a bit informative.

In the attached you see the same span of time as the plot above with the difference between MAX & MIN for upwind (LR) and downwind (UR.)  Clearly with this measure, the down wind sensor (Speed_4) shows less range in velocity of the wind compared to that upwind.

Images attached to this comment
Displaying reports 46001-46020 of 88268.Go to page Start 2297 2298 2299 2300 2301 2302 2303 2304 2305 End