Displaying reports 65941-65960 of 83091.Go to page Start 3294 3295 3296 3297 3298 3299 3300 3301 3302 End
Reports until 20:27, Wednesday 01 April 2015
H1 AOS
sheila.dwyer@LIGO.ORG - posted 20:27, Wednesday 01 April 2015 (17615)
XARM IR locking

Kiwamu, Sheila, Elli, TJ

This morning we had some difficulty with locking the X arm in IR for the inital alingment. We adjusted the gain, (to compensate for no longer changing the whitening gain), so the situation is back to what it used to be.  However, the loop doesn't seem like a verry good design.  Attached is a screen shot of the compensation filter and the measured open loop gain.  We tried to improve the phase right above the ugf by moving the pole at 100 Hz up to 300Hz , but this made the lock acquistion verry slow.  This is something that we need to come back to. 

Images attached to this report
H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 17:39, Wednesday 01 April 2015 - last comment - 12:45, Friday 10 April 2015(17620)
Pcal lines at higher frequencies switched between arms

Pcal lines running at 534.7 Hz (Xarm) and 540.7 Hz (Yarm) have been switched with one-another to cross check the calibration between the two arms. Now, the Xarm has a line at 540.7 Hz and Yarm as a line at 534.7 Hz. These will be switched back to its original position once we have a IFO locked data.This study is the continuation of what we reporrted in LHO alog 17582.

Comments related to this report
sudarshan.karki@LIGO.ORG - 12:45, Friday 10 April 2015 (17812)

The Pcal lines are switched back to its original position.

H1 ISC (PEM, SEI)
brian.lantz@LIGO.ORG - posted 16:33, Wednesday 01 April 2015 (17618)
septum plate damping "calculations"
I suggested that if the vibrations of the HAM5-HAM6 septum plate were causing scattered light noise (note that Robert suspects not) one could try to damp the vibration mode with one of the SUS vibration absorbers. Dennis asked how effective this might be, and I estimate that it would be no more than slightly effective. 
I estimate that vibration mode of the septum plate is around 110 Hz (with a large margin of error)
I estimate that 1 VA might put a lower bound on the Q of 100-200.

more notes and some matlab calc can be seen in the "Secret SEI Log"
https://alog.ligo-la.caltech.edu/SEI/index.php?callRep=712
( your ligo.org credentials will let you in)
H1 CDS
james.batch@LIGO.ORG - posted 16:30, Wednesday 01 April 2015 (17617)
Important awgtpman restart instructions for h1asc

A special version of awgtpman is used for the h1asc model running on h1asc0.  Because of this, the awgtpman process likely will not restart properly if the model is modified and restarted. 

If the h1asc model needs to be restarted, contact the CDS administrator staff or follow the instructions below:

1. Log on as controls to h1asc0:
me@opsws0:~$ ssh controls@h1asc0

2. Find the process ID of the currently running awgtpman for h1asc:

controls@h1asc0 ~ 0$ ps aux | grep awgtpman-2.9

3. The response should be similar to the following:

root     23365  0.1  3.1 280224 190864 ?     S  14:58   0:03 /opt/rtcds/lho/h1/target/gds/bin/awgtpman-2.9-asc-special -s h1asc -A -l /opt/rtcds/lho/h1/target/gds/awgtpman_logs/h1asc.log

4. The second field of the response is the process ID needed for the kill command, in this case 23365.  It changes each time the program runs.  Kill the process:

controls@h1asc0 ~ 0$ sudo kill -9 23365

Of course, you will use the real process ID, not the example ID shown here.

5. Restart the awgtpman for h1asc:

controls@h1asc0 ~ 0$ cd /opt/rtcds/lho/h1/target/gds/awgtpman_startup

controls@h1asc0 /opt/rtcds/lho/h1/target/gds/awgtpman_startup 0$ ./awgtpman_h1asc-new.cmd

6. There should be some text consisting of version strings that is output, and the AWG indicator on the overview screen for h1asc should turn green.

Why this is important

When the model is changed, a new mapping file is generated called tpchn_h1asc.par.  This file provides the association between testpoint channel names such as H1:ASC-AS_A_RF36_I1_ERR which dataviewer and other programs use, and channel numbers such as 32114 which the h1asc model uses.  If awgtpman is not restarted when the h1asc model is restarted, the mapping between names and channel numbers will likely be incorrect, and you may not be able to use a testpoint, or you may get the wrong data for a testpoint. 

The awgtpman for h1asc is different because a bug in the awgtpman software restricts the number of testpoints that can be opened for the model to an artificially low number.  A special version of awgtpman for h1asc was created to work around the bug until it can be fixed in a more permanent fashion.

H1 General
thomas.shaffer@LIGO.ORG - posted 16:00, Wednesday 01 April 2015 (17607)
Operator Shift Summery

730 - Karen/Cris To LVEA

906 - Stuart A, Restart SUS models for ITMY and ITMX

907 - Elli, to LVEA to check around HAM1 and HAM6

925 - Sudarshan, to E. Bay

958 - Sudarshan back

1033 - Elli, to IOT2

1100 - Elli, back

1205 - Jim B, Restart H1Broadcast0

1211 - Ed, LVEA

1300 - Jodi, to Ymid

1330 - Jodi, back

LHO VE
bubba.gateley@LIGO.ORG - posted 15:58, Wednesday 01 April 2015 (17616)
Beam Tube Washing
Scott L. Ed P. Chris S.

This A-Log will cover yesterday and today. The crew had an exceptional day yesterday cleaning 90 meters, finishing the section to the single door between X-1-7 and X-1-8 double doors. I attribute this increased productivity to the growing awareness of the crew to looking at the sections that may not be as bad as some of the others and looking ahead to certain sections that need more attention than others. This morning John and I went and inspected some of the sections and found them to be very clean. Results are posted here.

 Kudos to the cleaning crew on a great day. The remainder of the day today was spent relocating equipment, lights and support vehicles.

John and I did see some roller skid marks on the tube and took some pictures, 1 posted here and more to follow tomorrow.
Images attached to this report
Non-image files attached to this report
H1 CDS
daniel.sigg@LIGO.ORG - posted 14:16, Wednesday 01 April 2015 (17612)
Medm screens for the EtherCAT system

Patrick T, Daniel S

This was a long time coming, but we finally have an automatic medm/adl generator for the EtherCAT system. For each data structure in TwinCAT, we generate 3 screens:

The attached screen shot shows a couple of examples for the x end station. The screen at the lower left is the overview screen accessible from the sitemap under the SYS button. The two screen at the top left are record and error screens for H1:ALS-X. All fields are substructures which link to other screens. The two screens to the right show the record and error screens for H1:ALS-X_REFL_LOCK. The fields represent mbbi, ao, ao, ao, (substructure link), bi, longin, bo, longout, and longout EPICS records in this order. The errors are individual messages with no further links. 

The generation is done in two steps:

For this to work Patrick had to modify how the error messages are stored in the TwinCAT code. We now have a constant array of strings containing them rather than hardcoded in the code. There is one of these for each structure type which gets written to a separate file with extension exp. This change should be transparent.

The updated code and scripts have been installed in the x end station. Screens are available for all stations, but for the vertex and y end they could be slightly out of synchronization until we upgrade them as well.

Images attached to this report
H1 ISC
edward.daw@LIGO.ORG - posted 13:02, Wednesday 01 April 2015 (17613)
Breakout board to read out OMC DCPD installed
I installed a DSUB9 breakout board at the DSUB9 rear panel output from the output mode cleaner DC photodiode prewhitening amplifier board in rack ISC R5. This is to enable acquisition of broadband (initially 100kHz bandwidth) power spectral densities of the DC photodiode output. 
H1 General
jeffrey.bartlett@LIGO.ORG - posted 12:01, Wednesday 01 April 2015 (17611)
Temp/rH Trends for LTS Dry Box
   Posted below are the March temperature and relative humidity data from the Long Term Storage (LTS) Dry Boxes in the VPW. DB1 and DB4 are in use and partly loaded with parts. DB2 and DB3 were turned on on 03/31/15 and will be reported next month. 

   The trends look good, with mean rH at 0.23% and 0.27% and temperature at 71F for both boxes. The humidity spikes are incursions into the cabinets to add or remove parts. I am not sure what caused the almost 10 degree temperature drop in DB1 (not recorded in DB4) on 03/23/15, however there were no spikes in the rH during this time. Will investigate if a trend develops.    
Non-image files attached to this report
H1 General
thomas.shaffer@LIGO.ORG - posted 10:27, Wednesday 01 April 2015 (17608)
Morning Minutes

Next Tuesday is the HAM6 vent!

Aiden will be coming up next week to work on the ETM tables.

Tuesday maintenance 8-12 will continue even though 3IFO is done.

Safety Meeting:

H1 SUS (CDS)
stuart.aston@LIGO.ORG - posted 09:46, Wednesday 01 April 2015 (17609)
ITMX & ITMY models and DAQ process restarted
Before commissioning commenced this morning, I received the all clear to rebuild, install and restart the SUS ITMX & ITMY models that were modified last night to include DARM_CTRL signals (see LHO aLOG entry 17599).

- SDF snapshots were taken of both ITMs in SAFE state and checked into the svn
- BSC-ISIs were transitioned to OFFLINE state
- Models compiled, installed and restarted, with no issues
- ITMs WDs un-tripped and recovered to ALIGNED state
- BSC-ISIs WD'd un-tripped and recovered to FULLY_ISOLATED state

As, suspected, it was necessary to restart the DAQ process, which was carried-out courtesy of Jim B at approx 09:30am [PT], with no issues.
H1 ISC
evan.hall@LIGO.ORG - posted 02:28, Wednesday 01 April 2015 (17604)
Automating 35 Mpc

Sheila, Koji, Dan, Evan

Summary

Today we recovered a 35 Mpc lock and put the necessary steps in the Guardian.

Details

Bounce mode damping

For EY bounce mode damping, the DARM→EY element in the LSC output matrix is set to −1 and L3 ISCINF is enabled. Length feedback is entirely disabled on EY at this point. Then in the M0 DARM damping filter module, the +60° rotator and the bandpass are enabled, and the gain is −0.1.

Since this new damping feedback topology is not fully implemented on the ITMs, the DARM error signal is routed through LSC-YARM and into IX L3. In M0 DARM filter module, there is no phase rotation, only the bandpass at 9.7 Hz. I found that I needed to flip the sign of the gain compared to what we used to use; −80 seemed to damp the mode alright. Since this is a hack and likely will not be necessary 24 hours from now, it has not been put into the Guardian.

In both cases I have removed the 120 dB of gain from the bandpass FM and put it in a separate FM. This 120 dB is no longer sensible when using DARM control rather than DARM error.

Sheila has pointed out that any test mass which uses this damping scheme is ineligible to be used for feedfoward subtraction of other length DOFs, unless we come up with some workaround.

OMC ASC

As mentioned yesterday, we reverted the HAM6 centering scheme so that we could keep the interferometer ASC working.

Consequently, we now see scattering shelves in the DARM spectrum if the OMC ASC gain is set to 1. Setting it to 0.2 makes the DARM spectrum less painful to look at.

MICH coupling

Although tonight's campaign of noise coupling measurements was cut short by the PSL tripping, Koji and I managed to get a MICH→DARM transfer function with good coherence from 20 Hz to 400 Hz. The DTT files are attached.

For quiet data, one can look at 2015-04­-01 07:50:15 to 07:55:15.

Automation

Now that we have a reliable readback of the EY ESD state, the EX→EY transition has been reenabled in the Guardian.

The new final state is LSC_FF, which enables the MICH and SRCL feedforward and adds a cutoff to the SRCL loop.

Non-image files attached to this report
H1 PSL
evan.hall@LIGO.ORG - posted 01:32, Wednesday 01 April 2015 - last comment - 15:46, Wednesday 01 April 2015(17603)
Laser tripped

Koji, Evan

The NPRO shut off at around 08:11:00 UTC.

The interferometer was locked with no measurements or injections running.

Comments related to this report
richard.savage@LIGO.ORG - 15:46, Wednesday 01 April 2015 (17614)PSL

PSL restarted without issues at ~7:30 this morning.

It is not clear if the cause of the trip was an NPRO shutdown or a flow sensor glitch.  Investigation ongoing.

In the future, if the PSL drops out like this don't hesitate to call me at any time of day or night, any day of the week (home 509 627-1129, cell 509 539-4354).

I will either walk someone through the restart or come in myself and restart the system.  I prefer not to leave it down for longer than necessary.

H1 DetChar (ISC)
edward.daw@LIGO.ORG - posted 00:29, Wednesday 01 April 2015 - last comment - 17:03, Wednesday 01 April 2015(17602)
102kHz bandwidth amplitude spectral density from REFL-Q and IMC-I ports, Ed Daw, Evan Hall, Ross Kennedy, Jeff Kissel
With help from Evan Hall, Jeff Kissel and Ross Kennedy, got preliminary spectra from REFL-I and IMC-I, with the idea of identifying high frequency lines. A plot and some data are attached. Here are the frequencies of lines and clusters identified in these plots. They were taken with the SR785 box next to WHAM1, using the GPIB/ethernet bridge to the control room and Eric Quintero's readout scripts.

There are two attached figures, one with the two ASDs in separate planes, the other with them overlaid. Notice that the cavity length mode at around 36kHz is not in exactly the same place in the two channels, and neither is the first harmonic at around 70kHz. Other narrow peaks, however, do line up.

REFL-Q
Frequency ; ASD 
1. 2440Hz ; 21uVrms/rtHz 
2. 13.9kHz ; 16uVrms/rtHz
3. 34.4kHz ; 16uVrms/rtHz - broadband, bandwidth 1.2kHz
4. 40.4kHz ; 9.7uVrms/rtHz
5. 56.7kHz ; 13.0uVrms/rtHz
6. 60.9kHz ; 5.7uVrms/rtHz
7. 62.4kHz ; 7.4uVrms/rtHz
8. 65.6kHz ; 6.6uVrms/rtHz
9. 66.3kHz ; 6.3uVrms/rtHz
10. 70.2kHz ; 18.9uVrms/rtHz - broadband, bandwidth 3kHz 

IMC-I
Frequency ; ASD
1. 2453Hz ; 2uVrms/rtHz
2. 13.9kHz ; 16uVrms/rtHz
3. 38kHz ; 4uVrms/rtHz - broadband, bandwidth 1.2kHz, but does not line up with REFL-Q peak 3.
4. 40.6kHz ; 2.4uVrms/rtHz 
5. 56.5kHz ; 2.4uVrms/rtHz
6. 62.4kHz ; 2.4uVrms/rtHz
7. 65.6kHz ; 3.1uVrms/rtHz - double peak, just resolved.
8. 69.1kHz ; 3.1uVrms/rtHz
9. 76.6kHz ; 9.3uVrms/rtHz - broadband, bandwidth 3kHz, but does not line up with REFL-Q peak 10.
Images attached to this report
Non-image files attached to this report
Comments related to this report
edward.daw@LIGO.ORG - 07:29, Wednesday 01 April 2015 (17605)
If we want to monitor some or all of these lines, it wouldn't be such a difficult job to make a heterodyning circuit for the port in question, and feed the output to an additional DAQ channel.
edward.daw@LIGO.ORG - 17:03, Wednesday 01 April 2015 (17619)
Here's a linear scale plot of the same peaks measured in IMC-I and REFL-Q. 
Non-image files attached to this comment
H1 ISC
koji.arai@LIGO.ORG - posted 00:02, Wednesday 01 April 2015 (17601)
OMC DCPD Balance

I took the transfer function between H1:OMC-DCPD_A_OUT and H1:OMC_DCPD_B_OUT while the IFO was still at RF Readout.

The balance of the PD at DC is actually very good (delta<0.5%) but they are not well matched between 10-100Hz.
The difference is as much as 20%. The noise at high frequency is due to shotnoise between two PDs.

This could be caused by a mismatch between the V2cnt filters in the filter modules and the actual preamplifier filters in the vacuum chamber.
I'll look into this issue in the daytime as I don't want to screw up the overall calibration for DARM.

Images attached to this report
H1 SUS (CDS, DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 21:08, Tuesday 31 March 2015 - last comment - 07:39, Wednesday 01 April 2015(17597)
All BSC SUS 18-bit DACs have been Recalibrated to (Hopefully) Alleviate Major-Carry Transition Glitching
J. Kissel, D. Barker, J. Batch, J. Warner, S. Aston

Advised by J. Smith that LHO is suffering from Major-Carry transition glitching (LHO aLOG 17555), we've taken advantage of the front-end model restart chaos to re-calibrate the BSC SUS 18-bit DACs -- i.e. taken all front-end "user" processes (i.e. the SUS code) offline, and restarted the IOP process for the h1susex, h1susey, and h1susb123 front end computers / I/O chassis, which runs each chassis' DAC cards through their auto-calibration procedure. Those front ends include DACs for H1SUSETMX, H1SUSTMSX, H1SUSETMY, H1SUSTMSY, H1SUSITMX, H1SUSITMY and H1SUSBS.

Sadly, I realize while writing this entry, and after rereading Josh's entry (LHO aLOG 17555), that he says that it's the -2^16 transitions that are most of the glitches. Indeed, I even got an email I got from P. Fritschel today, en passant, reminding me that J. Betz and he have shown that the recalibration procedure does not reduce the -2^16 [ct] transition glitching (see G1401269). Hurumph.

Anyways, the re-calibration will at least help with the drift in glitchiness of the other two transitions ( 0 and +2^16 , potentially seen in, e.g. 16354).

I attach procedural notes that I gathered during the restart process (I learned quite a bit!)

P.S. There may be a "danger" that auto calibration of the 8th DAC (or DAC cardNum 7 if you count from zero) on the h1susb123, which house the control for the PUM on ITMX and ITMY, as the h1susb123 dmesg reports that the AUTOCAL failed for this DAC:
[6643729.576353] h1iopsusb123: 18-bit dac card on bus 36; device 4
[6643729.576367] h1iopsusb123: pci0 = 0xdfefe000
[6643729.576391] h1iopsusb123: dac pci2 = 0xdfefc000
[6643729.576398] h1iopsusb123: DAC I/O address=0xdfefc000  0xffffc90011b08000
[6643729.576403] h1iopsusb123: DAC BCR = 0x40000
[6643729.576427] h1iopsusb123: DAC BCR after init = 0x20040000
[6643729.576432] h1iopsusb123: DAC OUTPUT CONFIG = 0xff
[6643734.724703] h1iopsusb123: DAC AUTOCAL FAILED in 5133 milliseconds 
[6643734.724712] h1iopsusb123: DAC OUTPUT CONFIG after init = 0x102ff with BCR = 0x40000
[6643734.724719] h1iopsusb123: set_8111_prefetch: subsys=0x8111; vendor=0x10b5
I've confirmed that for every other DAC card (5 in EX, 5 in EY, and the other 7 on B123) we re-calibrated today, the dmesg claims success.
Non-image files attached to this report
Comments related to this report
joseph.betzwieser@LIGO.ORG - 07:39, Wednesday 01 April 2015 (17606)
Its actually worse even than the lower crossing not going away.  There's evidence that over time the glitches grow back, and after time the reset isn't as effective on some channels.

I refer you to LLO alog 16376
H1 DetChar (ISC)
sheila.dwyer@LIGO.ORG - posted 22:39, Monday 30 March 2015 - last comment - 23:33, Tuesday 31 March 2015(17576)
ALS glitches again

Sheila, Ed, Ross, Evan

This morning we had another incident where we seemed to have glitches in the channel H1:ALS-Y_REFL_CTRL_OUT_DQ that could have been the cause of ALS locklosses, similar to what was described in alog 15242 and alog 15402.  Some screenshots are attached.  There is a distinctive pattern in the REFL CTRL signal, and the error signal (ALS-Y_REFL_ERR_OUT_DQ) has a large glitch, as well as the transmitted green light (ALS-C_TRY_A_LF_OUT_DQ).  Today these things were happening only every 10-15 minutes, but that is often enough to prevent locking.  As before this problem went away after a while, without us doing anything to fix it.  Several screen shots are attached. These glitches sometimes show up in the X arm, but that could be because the DIFF control imposes them on the X arm even if the originate in the Y arm.  The glitches still happen when we had tidal off, and COMM unlocked, so I would not think that there was anyway a glitch that originated in the X arm could have been imposed on the Y arm.  There are no coincident gliches in the Optical levers or in the Fiber control or error signals. 

It would be good to know how often these glitches happen, how intermitent the problem has been over the last several months, and how often they coincide with a lockloss.  Ed and Ross started to look into this, and started a script to identify these glitches in a way that is easier than looking though a time series.  I made an attempt to use omega scan on ligodvweb, but I ran into trouble producing a plot.  

I am wondering if anyone from Detchar has tools that could be helpful (and maybe used from the control room?) in finding times when these glitches have happened.  

Images attached to this report
Comments related to this report
andrew.lundgren@LIGO.ORG - 07:37, Tuesday 31 March 2015 (17579)
We don't currently have glitch-finding algorithms running on those channels, but we'll start running them today and also produce results for the last week. In the meantime, just looking at one event, it looks like a BRMS from 50 to 100 Hz on ALS-Y_REFL_CTRL_OUT_DQ would do a good enough job of finding these.
edward.daw@LIGO.ORG - 14:16, Tuesday 31 March 2015 (17584)
The primitive code for finding these ALS glitches is attached; it uses the MATLAB frontend to NDS2 to get the data, and in this data it searches the H1:ALS-Y_REFL_ERR_OUT_DQ channel for the following: a data sample that exceeds 20000 counts, followed in less than 500 bins (30ms) by at least one sample that is lower than -20000 counts. This is a crude bipolar burst search of the channel, and it seems to find ALS glitches with high efficiency. There seem to be three classes of ALS glitches - 1) streams of large glitches that occur far from IFO locks, where the ALS servo is just not working very well/ hopping between spatial modes, 2) smaller glitches coincident with losses of lock 3) other smaller glitches whilst locked that are not coincident with loss of lock. I have also attached 4 pdfs. Attachments are explained below:
1. findalsglitch.m - a glitch search code that downloads and searches a predetermined amount of full rate data from ALS-Y_REFL_ERR_OUT_DQ
2. rangealsglitch.m - a code that calls findalsglitch.m multiple times, after breaking a predetermined data stretch into manageable chunks.
3. A pdf of a stream of large glitches in ALS occuring when the machine is out of lock
4. A pdf of a small ALS glitch during a lock stretch where the IFO did not lose lock coincident with the glitch.
5. A pdf of a small ALS glitch during a lock stretch coincident with an IFO loss of lock.
6. A zoomed in version of 5 showing the shape of the glitch in detail. 
Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 23:33, Tuesday 31 March 2015 (17600)

Here is one more example of this kind of glitch, I think this is an example of the Y arm ALS glitch causing a lockloss. 

Images attached to this comment
Displaying reports 65941-65960 of 83091.Go to page Start 3294 3295 3296 3297 3298 3299 3300 3301 3302 End