Displaying reports 57141-57160 of 83002.Go to page Start 2854 2855 2856 2857 2858 2859 2860 2861 2862 End
Reports until 15:17, Wednesday 13 April 2016
H1 ISC
keita.kawabe@LIGO.ORG - posted 15:17, Wednesday 13 April 2016 (26573)
ISCT6 back in place (Jim, Genne, Keita)

ISCT6 was put back in place and reconnected to the chamber. Lexan plates were put in a bag and put on top of the table.

Richard and Fil are cabling up the table.

H1 PEM (CDS)
james.batch@LIGO.ORG - posted 12:38, Wednesday 13 April 2016 - last comment - 12:44, Wednesday 13 April 2016(26571)
Restarted h0epics2 and IOC's
Restarted h0epics2 to apply patches and to clear a CPU that was stuck at 100% usage.  Restarted IOC's for

h0tidal
h0fmcs
h0video
h1weatherey
h1weathermy
h1weathercs
h1weathermx
h1weatherex

Comments related to this report
james.batch@LIGO.ORG - 12:44, Wednesday 13 April 2016 (26572)
As it turns out, the h0tidal IOC is using 100% of a CPU core.  We will leave it off while investigating what is going on.
H1 DAQ
david.barker@LIGO.ORG - posted 12:18, Wednesday 13 April 2016 (26570)
frame writer 0 down for LDAS disk move from LSB to warehouse

two DAQ changes:

Put the h1susetm[x,y]pi systems back into the DAQ and restarted at 12:05PDT.

Shutdown h1fw0 and h1ldasgw0 systems for Dan's move of the LSB Q-Logic switches and SATA-BOY raids from LSB to warehouse. WP5828.

Strangely, after the DAQ restart for the reconfiguration, h1fw1 did not kernel panic crash. First time in many restarts this has not happened. Only difference is that h1fw0 is powered down.

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 11:46, Wednesday 13 April 2016 - last comment - 12:00, Wednesday 13 April 2016(26568)
Tuesday Maintenance Summary

EY Vacuum Controls Upgrade

Richard, Patrick, Jim, Dave:

Main work was the upgrade of EY from the VME to the Beckhoff based systems. Work done so far: running minute trends were ported from old to new names. Main MEDM overview screen almost converted. Cell phone alarm texter was upgraded, we see a slow data connection at EY (FRS 5287).

Remaining items: cleanup of MEDM overview, migrate archived min trend files, get target autoBurt.req completed, alh configuration change.

DAQ

Jim, Dave:

Around 6pm the DAQ became very unstable with both framewriters crashing. As a quick fix we took out the h1susetm[x,y]pi systems out of the DAQ. The final DAQ restart was at 18:14PDT, and h1fw0 did restart itself at 18:52PDT. This was a clean restart (not a kernel panic crash which h1fw1 is experiencing) and the DAQ was stable since then.

ETM PI models

Ross, Tega, Dave

Work is ongoing for end station SUS PI models inclusion of the new IWAVE code. We will start with h1susetmxpi.

 

Comments related to this report
david.barker@LIGO.ORG - 12:00, Wednesday 13 April 2016 (26569)

This morning while the DAQ is running sans SUS-PI, I manually restarted daqd on h1fw1. Unfortunately it did panic crash on restart of daqd, the console gave a bit more information:

kernel panic - not syncing: Fatal exception in interrupt

paging request at 0000010000000000000

Shutting down cpus with NMI

 

H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 11:35, Wednesday 13 April 2016 - last comment - 09:12, Wednesday 27 April 2016(26566)
All of O1 LHO Statistical Uncertainty Spectrogram
C. Cahillane

I have produced statistical uncertainty spectrograms for all of O1.

For the most part the uncertainty doesn't change much over all of O1.  The biggest concern is a couple days around Nov 17th with large kappa variations.  Again, Jeff has suggested that I detrend all of the kappas to eliminate this spike in uncertainty.  

I believe that this is good evidence that the statistical uncertainty over all of O1 is fairly constant.  

For the LLO statistical uncertainty spectrograms, please see LLO aLOG 25652.
Non-image files attached to this report
Comments related to this report
craig.cahillane@LIGO.ORG - 09:12, Wednesday 27 April 2016 (26818)
C. Cahillane

I have detrended the kappas and reproduced the above spectrograms without the massive spikes of uncertainty.
Non-image files attached to this comment
LHO VE
kyle.ryan@LIGO.ORG - posted 10:44, Wednesday 13 April 2016 (26565)
0930 hrs. local -> Moved pumping from HAM5 to HAM6
Path is clear to reconnect table to North door of HAM6
H1 ISC (CDS)
evan.hall@LIGO.ORG - posted 09:57, Wednesday 13 April 2016 (26548)
EY ESD voltage noise measurements

Fil, Richard, Craig, Evan

Summary

We measured the voltage noise on the EY ESD in the nominal low-noise configuration, close to the flange. The measured noise is too small to impact DARM.

Above 50 Hz, the noise of each quadrant electrode relative to the bias electrode is about 25 nV/Hz1/2. At the nominal bias (380 V), this implies a white force noise at the test mass of 1.4 fN/Hz1/2, which amounts to 6×10−23 m/Hz1/2 at 100 Hz.

Measurement details

Based on a design by Rai (T1600088), Richard built a passive box which picks off the voltages going to the ESD and ac couples them with 5 µF capacitors (see attached image). This enables us to pick off the bias voltage and a particular quadrant voltage, ac couple them, and then differentially amplify them with a dc-coupled SR560. The 5 µF works against the 100 MΩ impedance of the SR560 to give a high-pass corner of about 0.3 mHz. The SR560 gain was 100, with an input-referred voltage noise of 4–6 nV/Hz1/2 above 10 Hz.

We installed the passive box after the current-limiting resistor box, which sits in the cable tray close to the cable feedthrough on the BSC.

We took two kinds of measurements.

First, we had the ESD signal pass through the passive box and into the chamber to the reaction mass electrodes. The bias electrode was held at 380 V. We measured the ac-coupled signal differentially between the bias signal and a particular quadrant signal. This measures the voltage noise being applied to the electrodes. On each quadrant, we had a calibration line running at 35 Hz, with an amplitude of a few hundred DAC counts.

Second, we disconnected all five driver signals before they entered the passive box, but left the connections to the chamber alone. We again measured the ac-coupled differential signal between the bias and the quadrant (LR only). This measures the voltage noise between the electrodes.

Results

The attached plot shows the results of the two measurements for LR. For the configuration with the driver connected, we also checked the other three quadrants and the spectra looked almost identical. We also briefly tried injecting band-limited white noise from 0.8 to 8 Hz, just to see if exercising the DAC had an effect on the noise floor above 50 Hz (it didn't).

We would like to take measurements on EX in its low-noise configuration, as well as with the driver disconnected.

Images attached to this report
Non-image files attached to this report
LHO VE
chandra.romel@LIGO.ORG - posted 09:26, Wednesday 13 April 2016 (26564)
IP5 PS
IP-5 power supply was giving a polarity error since Friday. Suspect this was due to receptacle activities at rack last Friday. Reprogrammed PS for "spare" pump with LIGO specific parameters. One channel fired up. The other gave an "over temperature" error. Waited many minutes, raised voltage from default stepping 3000V to 5000V on fixed V setting. Second channel started to work again (external fan is blowing on it). We are ordering more Gamma PSs as these old Varians are failing at a fast rate.

H1 General
bubba.gateley@LIGO.ORG - posted 07:11, Wednesday 13 April 2016 (26563)
Beam Tube Cleaning
The beam tube cleaning was completed last week. I am at LLO now and will post the final test results when I return next week.
H1 PSL
peter.king@LIGO.ORG - posted 05:54, Wednesday 13 April 2016 - last comment - 06:08, Wednesday 13 April 2016(26561)
Changed FSS Autolocker settings
As a test I changed the FSS autolocker settings.

MIN [K] from -0.2000 to -0.0150
MAX [K] from 0.0000 to 0.0100

A fringe occurred when the NPRO crystal temperature was somewhere between -0.0130 and -0.0140.
I reduced the autolocker temperature search ramp range so that hopefully the autolocker won't
spend so much time hunting for the fringe.  Engaging the autolocker did not knock the FSS out
of lock.

It might be that over time the NPRO crystal temperature will exceed -0.0150, in which case the
autolocker settings may need to be changed.
Comments related to this report
peter.king@LIGO.ORG - 06:08, Wednesday 13 April 2016 (26562)
Attached is a plot of the NPRO crystal temperature for when the FSS was locked.  So it might be that the
minimum temperature can be set to -0.035 in case the autolocker cannot find the fringe with the current
(ie modified) settings.

/* standard disclaimer */
Past performance is not an indicator of future results.
Images attached to this comment
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 05:01, Wednesday 13 April 2016 (26560)
PSL Work
Continuing PSL work ...

The pre-modecleaner transmission photodiode (D1002929 #69 S1107860) was swapped out for
another monitoring photodiode (D1002164 #62 S1107854).  The latter having its transimpedance
gain reduced from 20k to 3.3k.  This fixed the problem with the pre-modecleaner transmission
signal that is observed on the MEDM screen.  The calibration is correct to within one or
two watts.

In getting the power stabilisation up and running again it was noted that the amount of
diffracted light from the acousto-optic modulator was at most 1%.  Far less than what is
required.  Either the alignment for the AOM is off, which is quite likely, or the modulation
signal to drive the AOM driver is insufficient.

A plot of the measured AOM driver output versus modulation input is attached.  With the
0.457V from the power stabilisation servo, 24.6 dBm (320mW) was measured.  This may be
insufficient for the AOM which has an operational RF power of 2.8W (34.5 dBm).



Jason, Peter
Images attached to this report
H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 00:28, Wednesday 13 April 2016 (26559)
LHO O1 Calibration Movies
C. Cahillane

I made a "calibration movie", or a gif of the entire O1 calibration for C01 and C02.
The darkest line is the current systematic error, and the dashed lines are the current uncertainty.  
Kiwamu made the helpful suggestion that I leave a trace of previous calibrations.  Previous calibrations are the light lines left behind from the dark trace.

You can imagine these movies as a trace over the spectrograms from LHO aLOG 26535.

I like this visualization of the high-frequency dither we see in our calibration.  Also this gives a good impression of how much our cavity pole affects us in the C02 calibration movie, since the cavity pole is the only time-dependent parameter not corrected for in C02.

For the LLO Calibration Movies, please see LLO aLOG 25647
Images attached to this report
H1 SEI
michael.ross@LIGO.ORG - posted 21:20, Tuesday 12 April 2016 (26558)
BRS Software Upgrades
Krishna, Michael

The winds have yet to pick up so we spent the past two days working on software upgrades. 

At ETMY, we integrated our previous PLC code into Daniel's template which will bring our code closer to standards. There was an error in the PlcInfoFB structure which we didn't know how to fix so we commented out the call in the main program. Also, the previous state initialization was re-initializing our variables on every loop so we disabled that function as well. Besides those two errors, the program runs as expected.

At ETMX, we upgraded the C# code to closely match the version we use at ETMY. The most substantial change is in the pattern to angle algorithm. The angle used to be calculated from the average difference of the collection of peak pairs which involved fitting each peak to a Gaussian. The new algorithm involves calculating the cross correlation of the patterns with respect to pixel shifts of the main pattern which is then fitted to a Gaussian. These changes reduce the computation required for each frame while also decreasing outside dependencies. We hope this new version will remove the bug which caused the previous code to crash periodically.
H1 IOO (IOO)
cheryl.vorvick@LIGO.ORG - posted 17:07, Tuesday 12 April 2016 (26556)
IO IMs (IM1-4) aligned but damping is off

gathering free-swinging data overnight per WP5824

damping will be re-engaged tomorrow morning

LHO VE
filiberto.clara@LIGO.ORG - posted 16:59, Tuesday 12 April 2016 - last comment - 19:00, Tuesday 12 April 2016(26555)
EY - New Vacuum Control Sytem Installed WP 5822
Richard, Patrick, Filiberto

Beckhoff based vacuum control chassis and computer were installed at EY. Sorted out some issues with internal wiring for the 4-20ma inputs (LN2 gauges) inside the beckhoff chassis. Installed shorting plugs for the LN2 control valve watchdog. PT425, PT426, and PT427 guages were connected to the end Y vacuum chassis. We are still trying to sort out some issues with the readback signal for ion pump II411.
Comments related to this report
patrick.thomas@LIGO.ORG - 19:00, Tuesday 12 April 2016 (26557)
I have updated the control room alarm handler. I have also put the CP7 LLCV on PID control. It appears to be recovering well.
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 57141-57160 of 83002.Go to page Start 2854 2855 2856 2857 2858 2859 2860 2861 2862 End