Displaying reports 57361-57380 of 83254.Go to page Start 2865 2866 2867 2868 2869 2870 2871 2872 2873 End
Reports until 08:46, Friday 15 April 2016
H1 General
edmond.merilh@LIGO.ORG - posted 08:46, Friday 15 April 2016 (26606)
Morning Meeting Minutes

SEI - HAM6-5 still locked - to be unlocked. Hugh doing PEM inventory

PSL - touching base on beam availability at lunch time

SUS - nothing reported
 
CDS- digital janitorial work. Richard pulling cables for annulus pumps
 
PEM - Robert may be working around STS2 at EX
H1 General
edmond.merilh@LIGO.ORG - posted 08:06, Friday 15 April 2016 (26605)
Shift Summary - Day Transition
TITLE: 04/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 4mph Gusts, 2mph 5min avg
    Primary useism: 0.23 μm/s
    Secondary useism: 0.31 μm/s 
QUICK SUMMARY:
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 07:00, Friday 15 April 2016 - last comment - 07:22, Friday 15 April 2016(26603)
Injection locking performance and power fluctuations
Attached are plots of the power fluctuations from the HPO and its PZT.  The fluctuations in the HPO
power seem to coincide with the variations in the PZT voltage.  Both have a period of about 70 minutes.
We may have to reduce the injection locking servo gain.

    Also attached is a plot of the free running power fluctuations transmitted by the pre-modecleaner
and the output of the HPO.
Images attached to this report
Comments related to this report
peter.king@LIGO.ORG - 07:22, Friday 15 April 2016 (26604)
The power fluctuations observed in the HPO output are not due to fluctuations in the NPRO
output but might be due to the front end laser.
Images attached to this comment
H1 General
edmond.merilh@LIGO.ORG - posted 06:23, Friday 15 April 2016 (26602)
Shift Summary - Day
TITLE: 04/14 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 24mph Gusts, 18mph 5min avg
    Primary useism: 0.32 μm/s
    Secondary useism: 0.66 μm/s 
QUICK SUMMARY: 

15:00 Observed activitiy in the PSL enclosure. - Peter

15:00 Snow Valley on site - headed down X arm.

15:10 John to EX to meet Snow Valley

15:15 Jeff B into LVEA

15:20 Krishna and Mike to EY 

15:22 Ops Dailty Checkk List tasks performed: Vidoe0 and Video5 FOM computers needed restart.

15:29 Jeff out of LVEA and goin to both ends

15:53 Jason into PSL

16:08 Gerardo to Y end to check on ION pump

16:18 Jeff Back

16:27 John back

16:39 Gerardo back

16:45 John to MY

17:00 Richard ou to LVEA for scope inventory

17:12 Krishna and Mike back

17:17 Krishna and Mike to EX

20:21 Jeff into PSL to connect dust meter

19:59 Jeff back

17:23 Richard out and heading to the out buildings

17:44 DAQ restart

18:34 Richard back

19:35 Jenne into the LVEA with two guests

19:47 Jeff into LVEA

19:54 Tour group into control room

 

 

 

note to self: press 'Post to Logbook' :)

H1 PSL (PSL)
peter.king@LIGO.ORG - posted 03:42, Friday 15 April 2016 - last comment - 06:19, Friday 15 April 2016(26599)
PSL work summary
In trying to engage the power stabilisation servo, we found that its behaviour was
somewhat erratic.  The servo would lock for brief periods of time before a low frequency
change would cause the servo to go out of lock.  Engaging the integrator, when possible,
did not prevent the low frequency fluctuation from knocking the servo out of lock.
Coincidentally the free running power fluctuations through the pre-modecleaner exhibited
large (~2-5%) fluctuations too.

    Thinking that these fluctuations were perhaps caused by diffraction effects associated
with the corona aperture within the laser, a number coronia apertures were tried and their
effects on the beam were examined with a CCD camera.  Whilst looking at the beam profile of
both the oscillator and the front end, it was observed that the profile of the front end
laser was terrible.  Whilst the beam profile from the oscillator was good, it would change
at random intervals.  The front end (seed) beam was re-aligned and the overlap between the
seed beam and the oscillator output improved.

    Without re-doing the mode matching to the pre-modecleaner, the pre-modecleaner was locked.
Its transmitted power appeared more stable.  The power noise spectrum after the pre-modecleaner
appeared more stable too.  The power stabilisation servo was engaged and could be locked.
Its behaviour was noticeably better than previously.

    We could not engage the frequency stabilisation, for reasons unknown at the moment.  But
we will pursue this later this morning.





Jason, Peter
Comments related to this report
peter.king@LIGO.ORG - 06:18, Friday 15 April 2016 (26600)
Injection locking servo PZT monitor signal and mixer monitor signal spectra
as a result of the improved overlap between the seed beam and the oscillator
output.
Images attached to this comment
peter.king@LIGO.ORG - 06:19, Friday 15 April 2016 (26601)
Injection locking servo transfer function.
Images attached to this comment
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 18:52, Thursday 14 April 2016 (26597)
Ops EVE Shift Summary

All time in PT.

~17:30 Jason and Peter came out after spent all day in the PSL. No laser. No commissioners. I guess my shift ends early...

 

I also noticed some bright-than-usual scattered light on the PSL enclosure camera besides the laptop screen. It's probably nothing but just want to make note of it.

Images attached to this report
H1 PSL
nutsinee.kijbunchoo@LIGO.ORG - posted 18:41, Thursday 14 April 2016 (26598)
Weekly PSL Chiller Reservoir Top-Off

Added 150ml to chrystal chliller.

 

Close FAMIS #4146

H1 SEI (CDS, DetChar, PEM, SEI)
krishna.venkateswara@LIGO.ORG - posted 17:13, Thursday 14 April 2016 (26596)
BRS Progress Summary

Michael, Krishna

In this post, I'll try to summarize the work accomplished on the BRS-Y (2) and BRS-X (1) over the last few weeks.

1) BRS-Y:

The instrument including the box in the VEA and the Beckhoff computer/modules were installed (26242, 26265, 26276) . The tilt transfer function was measured and we then adjusted the center of mass to minmize 'd'. We then remeasured the transfer function to confirm that d was indeed small. This isn't particularly necessary for the goal of tilt-subtraction but does allow us to study the tilt from surface waves during an earthquake.

Tilt-subtraction for the ground seismometer has been shown to be very effective under 20-30 mph winds at both EY and EX in the 10 mHz to 1 Hz band. We have shown some modest improvements to ISI motion using sensor correction in the 'along-the-beam' direction in the 0.1-1 Hz band (as seen be ST1 T240)  without any increase to the total rms motion (as measured by the CPS). Both of these are local sensors and it would be interesting to test these configurations with the interferometer. There are also likely other ways to use the BRS signals which may prove more beneficial.

The C# and the Beckhoff PLC code for BRS-Y have been uploaded to svn under slowcontrols. This system is more robust than the one at EX and allows for greater CDS integration and control. Several of the BRS parameters (such as damping on/off, damping thresholds) can be controlled through EPICS commands. For example, typing " caput H1:ISI-GND_BRS_ETMY_USER 0" disables damping and " caput H1:ISI-GND_BRS_ETMY_USER 1" enables it.

We just discovered today that one of the two capacitive actuators was shorted internally and cannot be used. The damping is thus asymmetric and less strong. There are also other minor issues with it but it still meets its main goal of keeping the amplitude small.

The vcauum system is working well. The ion pump current is ~25 microamps, corresponding to a pressure of ~1.5 X 10^(-7) torr. The corresponding current for BRS-X is 14 microamps after ~two years.

The DC position of the beam-balance has been slowly settling with a very long time constant (~10 days). The attached plot shows the DRIFTMON channel over the last 16 days. The two main spikes followed by DC shifts were caused by us changing the DC position using a small moveable rod on the beam-balance. Based on the trend we expect it to drift down and then approach an equlirbrium value within the range of the autocollimator (+/-16k counts on the Y-axis).

2) BRS-X:

BRS-X was restarted from hibernation and works well for the most part.

The startup procedure for the code has been simplified. There are now two shortcuts on the BRS-X laptop's desktop screen - the one labelled "Damping ON" runs the software with damping enabled (DC subtraction is automated) and the other one runs with damping diabled and 2.5 V for the DAMP_CTRL channel, which can be used to reset the damper, if needed. A recurring problem with it is the damper turn-table vibrations causing the beam-balance to ring up. A new Beckhoff computer/modules and a GigE camera have been/will be ordered for it and we will develop a new smoother turn-table which will address these problems.

Images attached to this report
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 16:15, Thursday 14 April 2016 (26595)
Manually over-filled CP3 at 22:56 utc

1/2 open LLCV bypass valve, and the exhaust bypass valve fully open.

Flow was noted after 1 minute and 37 seconds, closed LLCV valve, and 3 minutes later the exhaust bypass valve was closed.

LHO VE (DCS, VE)
gerardo.moreno@LIGO.ORG - posted 16:13, Thursday 14 April 2016 (26594)
HAM6 CDS Signal Cable
Extended, routed and terminated CDS signal cable for HAM6 annulus ion pump controller.
H1 General
edmond.merilh@LIGO.ORG - posted 15:29, Thursday 14 April 2016 (26593)
Attached are7 day Pit, Yaw and Sum trends for H1 OpLevs - supplemental

Apparently, I missed this task in my queue. I "shot-the-gap" with these.

Reference FAMIS #4668 

Images attached to this report
H1 AOS (CDS, DAQ, PEM)
david.barker@LIGO.ORG - posted 10:54, Thursday 14 April 2016 (26590)
h1pemcs and daq restart to correct 16k channel

Mia culpa, I changed the name of the second spare PEM ADC channel at the corner station to H1:PEM-CS_ADC_4_27_16K_OUT_DQ but forgot to change the actual rate in the DAQ block. I corrected this, restarted h1pemcs and restarted the DAQ.

On the DAQ restart: mx_stream restarted needed on h1oaf0 and h1pemmx. h1fw1 kernel crashed on startup, needed power cycle.

LHO VE (CDS, VE)
patrick.thomas@LIGO.ORG - posted 09:59, Thursday 14 April 2016 (26589)
Set deadband for CP7 LLCV
Set H0:VAC-EY_CP7_LIC400_LLCV_POS_CTRL_PCT_DEAD_BAND to 0.5.
H1 General
edmond.merilh@LIGO.ORG - posted 09:45, Thursday 14 April 2016 (26588)
Shift Summary - Day Transition

Apologies for the late entry.

TITLE: 04/14 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 24mph Gusts, 18mph 5min avg
    Primary useism: 0.32 μm/s
    Secondary useism: 0.66 μm/s 
QUICK SUMMARY: 
All was quiet in the control room. LASER work in PSL ongoing. Snow Valley on site to clean chillers down X arm.
H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 01:15, Thursday 14 April 2016 (26580)
LHO Kappa Detrending and Uncertainties
C. Cahillane

Per Jeff's suggestion, I have detrended the calibration time-dependent kappas to get the true all of O1 uncertainty associated with the kappas.

This was done to eliminate the spikes in calibration uncertainty we would see from changes in the detector, such as ESD bias flips.

I detrended by finding the median kappa for a range of 100 kappas around a specified gpstime.  Then I would subtract the original kappa from the found median.  I then took the standard deviation over all of O1 from the detrended kappas.  These are the numbers reported in the histogram titles. 
From this method, we get sub-percent and sub-degree uncertainty, due to the massive numbers of kappas we have.  I think this is fine as long as we understand why the detector configuration changed at every kappa-jump.

To see the LLO kappa detrends, please see LLO aLOG 25677
Non-image files attached to this report
H1 ISC (ISC)
jenne.driggers@LIGO.ORG - posted 18:39, Wednesday 13 April 2016 - last comment - 11:29, Thursday 14 April 2016(26587)
ASC model changes

I have added SRM, SR2 and SR3 to the ADS (alignment dither system) part of the ASC.  All necessary IPCs were already there, they were just grounded.  Now we can send the dither signal to the SR mirrors, and also actuate on them with the demodulated signal if we so choose.  We'd like to use this (at least looking at the demodulated sigal) to help us find the correct operating point for the SRC ASC signals.

While I was doing that, I also added the ability to blend the DHARD error signals, in case we decide to do that after we try CHARD error signal blending.

MEDM screens for the DHARD blending are done, although I have not yet completed the screen modifications for the ADS.

Comments related to this report
jenne.driggers@LIGO.ORG - 11:29, Thursday 14 April 2016 (26592)

The rest of the medm screens are now done.

H1 ISC (TCS)
kiwamu.izumi@LIGO.ORG - posted 02:38, Sunday 03 April 2016 - last comment - 11:10, Thursday 14 April 2016(26409)
DARM cavity pole reaching 362 Hz

Related alogs 26264. 26245

I did some follow-up tests today to understand the behavior of the DARM cavity pole. I put an offset in some ASC error points to see how they affect the DARM cavity pole without changing the CO2 settings.

I conlude that the SRC1 ASC loop is nominally locked on a non-optimal point (when PSL is 2 W) and it can easily and drastically changes the cavity pole. The highest cavity pole I could get today was 362 +/- a few Hz by manually optimizing the SRC alignment.


[The tests]

This time I did not change the TCS CO2 settings at all. In order to make a fair comparison against the past TCS measurements (26264, 26245), I let the PSL stay at 2 W. The interferometer was fully locked with the DC readout, and the ASC loops were all engaged. The TCS settings are as follows, TCSX = 350 mW, TCSY = 100 mW. I put an offset in the error point of each of some ASC loops at a time. I did so for SRC1, SRC2, CSOFT, DSOFT and PRC1. Additionally, I have moved around IM3 and SR3 which were not under control of ASC. All the tests are for the PIT degrees of freedom and I did not do for the YAWs. During the tests, I had an excitation line on the ETMX suspension at 331.9 Hz with a notch in the DARM loop in order to monitor the cavity pole. Before any of the tests, the DARM cavity pole was confirmed to be at 338 Hz by running a Pcal swept sine measurement.

The results are summarized below:

The QPD loops -- namely CSOFT, DSOFT, PRC1 and SRC2 loops -- showed almost no impact on the cavity pole. The SOFTs and PRC1 tended to quickly degrade the power recycling gain rather than the cavity pole. I then further investigated SRC1 as written below.

 

[Optimizing SRC alignment]

I then focused on SRC1 which controlled SRM using AS36. I switched off the SRC1 servo and started manually aligning it in order to maximize the cavity pole. By touching PIT and YAW by roughly 10 urads for both, I was able to reach a cavity pole of 362 Hz. As I aligned it by hand, I saw POP90 decreasing and POP18 increasing as expected -- these indicate a better alignment of SRC. However, strangely AS90 dropped a little bit by a few %. I don't know why. At the same time, I saw the fluctuation of POP90 became smaller on the StrioTool in the middle screen on control room's wall.

In order to double check the measured cavity pole from the excitation line, I ran another Pcal swept sine measurement. I confirmed that the DARM cavity pole was indeed at 362 Hz. The attached is the measured DARM sensing function with the loop suppression taken out. The unit of the magnitude is in [cnts @ DARM IN1 / meters]. I used liso to fit the measurement as usual using a weighted least square method. 

By the way, in order to keep the cavity pole at its highest during the swept sine measurements, I servoed SRM to the manually adjusted operating point by running a hacky dither loop using awg, lockin demodulators and ezcaservos. I have used POP90 as a sensor signal for them. The two loops seemingly had ugf of about 0.1 Hz according to 1/e settling time. A screenshot of the dither loop setting is attached.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 02:58, Sunday 03 April 2016 (26410)

Probably interestinmg to take a look at ASC_ASA/B_36/90/DC, and see, if there is a better combintion available.

jenne.driggers@LIGO.ORG - 11:39, Friday 08 April 2016 (26497)

It occurs to me that we might try putting some offsets into the centering loops for the SRC WFS.  Can we find a pointing location where the AS36 signals give us an optimal alignment for the SRC? 

On a somewhat parallel thought, Evan and I wonder if we could set offsets in the SRC1 loops after choosing an alignment based on some dither lines?  Maybe we don't want always-on dither lines, but we could use them to help us figure out what our optimal alignment is.

kiwamu.izumi@LIGO.ORG - 13:34, Wednesday 13 April 2016 (26567)

Here are some more data.

In this plot, full lock was achieved at some point between 0 and 500 sec. A small change in the SRM alignment offsets are due to the DRMI guardian completing the ASC offload to the top mass before decreasing the CARM offset. The measurement of the cavity pole and optical gain is valid only after 500 sec or so.

As I mentioned in the last ISC call, the cavity pole frequency and optical gain are anti-correlated -- one goes up and the other goes down.

The below shows a summary of my manual SRM alignment.

  Before  After  Difference (after - before)
SRM PIT -727 urad  -737 urad  -10 urad
SRM YAW  908 urad  901 urad  -7 urad

As I wrote in the original entry, I steered SRM PIT and YAW by -10 and -7 urad respectively.

 

Also I attach a screen shot of trends showing the 2f RF signals during the same period.

As the cavity pole increases the POP90 consistently decreases. This is what we expected because SRC sucks more light into it. POP18 also increased at the beginning which is good. However it decreased slightly after I aligned SRM yaw for some reason. The most outrageous one is AS90. As the cavity pole increased, the AS90 kept decreasing. I have no idea why.

Images attached to this comment
kiwamu.izumi@LIGO.ORG - 18:40, Wednesday 13 April 2016 (26583)

Conclusion (again): it is the SRC alignment that changes the cavity pole.

[SRM and SR2 alignments]

I completely forgot about the SRC2 loop which controls the pointing of the output beam on to ASC_AS_C. This loop was active during my measurement silently correcting SR2 and SRM as I manually moved SRM. So I checked the witness sensors to see how much they actually moved instead of looking at my adjustment of the SRM alignment.

As you can see, SRM actually moved to the opposite direction in its angles due to the SRC2 loop counteracting on my adjustment. In total they have moved by the amounts listed in the table below.

   before  after  difference (after-before)
SRM pit  -105 urad  -95 urad  10 urad
SRM yaw  873 urad  876 urad  3 urad
SR2 pit  2603 urad  2600 urad  -3 urad
SR2 yaw  790 urad  791 urad  1 urad

 

[A finesse simulation also suggests that the cavity pole is a strong function of SRs' alignment]

With the above misalignment values in hand, I then ran a finesse simulation to see if I can reproduce a similar result. Indeed, I could change the cavity pole from an optimum of 366 Hz to 344 Hz in the simulation (while my measurement was from 360-ish Hz to 345-ish Hz). The attached is a simulated DARM response with and without these misalignment.

Because I was too lazy to fit out the effect of the time delay and next FSR peak, I simply searched for a frequency point where the phase rotates by 45 deg as a cavity pole frequency. This probably makes the absolute calibration of the cavity pole somewhat inaccurate, but the difference between the two cavity pole frequencies should be moreorless accurate.

Also I attach the finesse code in pdf format.

Images attached to this comment
Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 11:10, Thursday 14 April 2016 (26591)

Addendum:

In the finesse simulation, the DARM response showed some difference at low frequencies between the two results. So I re-ran the same code and extended the frequency range to 0.1 Hz. It is seemingly due to a radiation pressure effect. I don't have a good explanation why it changed by SRs' alignment.

Images attached to this comment
Displaying reports 57361-57380 of 83254.Go to page Start 2865 2866 2867 2868 2869 2870 2871 2872 2873 End