model restarts logged for Thu 02/Apr/2015

no restarts reported

model restarts logged for Fri 03/Apr/2015
2015_04_03 10:11 h1iopseih23
2015_04_03 10:12 h1iopseih23
2015_04_03 10:13 h1hpiham2
2015_04_03 10:13 h1hpiham3
2015_04_03 10:13 h1isiham2
2015_04_03 10:13 h1isiham3
2015_04_03 10:46 h1hpiham2
2015_04_03 10:46 h1hpiham3
2015_04_03 10:46 h1iopseih23
2015_04_03 10:46 h1isiham2
2015_04_03 10:46 h1isiham3
2015_04_03 11:20 h1iopseih23
2015_04_03 11:21 h1iopseih23
2015_04_03 11:22 h1hpiham2
2015_04_03 11:22 h1hpiham3
2015_04_03 11:22 h1isiham2
2015_04_03 11:22 h1isiham3
2015_04_03 13:50 h1hpiham2
2015_04_03 13:50 h1hpiham3
2015_04_03 13:50 h1iopseih23
2015_04_03 13:50 h1isiham2
2015_04_03 13:50 h1isiham3
2015_04_03 18:42 h1fw0

one unexpected restart. Multiple restarts of h1seih23 for ADC and PCI issues.

This afternoon Elli, Kiwamu and I phased the AS A 36  in PRX, then again in DRMI.  We phased each quadrant to minimize the Q signal with the cavities locked, and the WFS centered, and then adjusted gain to get the same size signal on each quadrant ( the gain adjustments are no more than 40%).  This seemed to indicacte that the electronics for each qaudrant are working OK, so nothing needs to be done durring the HAM6 vent.  However, after this we tried exciting the angle of the SRM and saw that the signals are still highly coupled between pitch and Yaw

The glitches described in alog 17576 are here again tonight.  In addition to the kind of intermittent glitches described in that alog we have verry regular 4 second glitches in DARM control when locked on ALS.  This started around 22:38 local time (5:38 UTC on April 3rd).  These large glitches cause the half hertz motion of the ETMX suspension.  Dan and I are leaving the IFO locked on ALS to see if these go away on their own overnight as the ALS glitches have in the past.

ETMX is swinging in pitch at the half hertz resonance, this is rung up by the glitches.  Oplev damping is not an option because the ETMX optical lever laser is dying, as we have known for several weeks now.

Nairwita, Nutsinee

Attached below are the plots of EX CPS sensor vs. EX VEA temperature and EX roof temperature on March 27th and 28th. The more steady line seems to correlate with the roof temperature (out-door) somewhat while the more fluctuated line seems to correlate more with the VEA temperature. We weren't able to get the raw trend of the PEM so the resolution isn't too great. Judging from the data of March 27th CPS vs. VEA temperature, the temperature became steady around 06:00:00 while the bumbling line starting to settle around 08:00:00. Maybe this two-hour delay in response to the temperature can give us a clue of where the source of the bumbling line might be? 

Jim and Dave

we added a new frontend, x1seih23, to the DTS. I moved the HEPI and ISI models for ham2,3 from x1asc to the new FEC.

[Ed. Merilh, Jason Oberling, Doug Cook, Suresh D]

Doug replaced the diode laser at the HAM3 oplev this morning after it was fixed for reducing glitching (SL No. 197) in the optics lab 2.   We wanted to let it settle for a while and reach thermal equilitbrium before adjustting the power level.  We did that around 12:30PM and I checked the results around 4PM.  The laser is still settling down  as seen in the attached plots.  We plan to monitor it for another day. 

Scott L. Ed P. Chris S.

Yesterday the crew cleaned 52 meters of tube and 67 meters today to X-1-8 double doors. Results are posted here.

The extraordinary accomplishment of cleaning over 90 meters on 3-31 was very much appreciated, however I have asked the crew to consider a more reliable pace and not burn themselves out. I reminded them that we are only 20% complete with the overall task.

Monday will be spent relocating equipment, lights, and support vehicles. 

Measurements were carried out on the ETMX effective charge voltage over a period of 3.5 hours this morning. 

Firstly, some housekeeping, I svn'd up the charge scripts directory to obtain updates from LLO /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts/ and persevered local changes.

ETMX was selected since it does not currently have low-pass filters installed on each quadrant. It was not necessary to re-align the ETMX optic, since the OpLev was already well centred. Linearization was bypassed (turned off) for the duration of these measurements. The ESD_UL_LL_UR_LR_charge_07-H1.py script was run to drive the ESD at 4 Hz with an amplitude of 130k counts. The script attempts to write a bias to H1:SUS-ETMX_L3_LOCK_BIAS_OFFSET, however, this is nominally turned OFF at LHO. Therefore, it will need to be engaged, and the bias in DAC counts residing in H1:SUS-ETMX_L3_LOCK_INBIAS set to zero. Also, the ramp time should be reduced from 10s to 5s for the duration of the charge measurements.

Data was processed using the ESD_UL_LL_UR_LR_analysis_07_H1.m script, charging and charge deviations from today’s measurement can be seen below (all times in UTC).

A significant negative effective voltage is observed on the lower quadrants, which are quite variable. Upper quadrants exhibit less charge and are more stable (similar to what was seen for LLO ETMY, before it was discharged) n.b. there is also a large discrepancy between the effective charge reported by OpLev Pitch and Yaw.

Previous automated charge measurements carried-out on ETMX by Brett after the most recent vent did not show as larger effective charge (see LHO aLOG entry 16057). Follow-up measurements, may help determine how the charge is evolving. The infrastructure is in place to help determine if any future discharging is successful.

Processed results, and analysis scripts have been committed to the sus svn, raw data files have not.

Today has been a rough day for the input HAM chambers. This morning we found that a channel went dead in expansion chassis (see Richards alog for the resolution), and troubleshooting involved a lot of restarts of SEIH23. This afternoon, after that problem was sorted, Evan found that the SEI MEDM screens for HAM2&3 were frozen. Dave and JimB should be posting a log about the resolution of that issue.

It would be very good if Detchar could at do some comparisons of the H3 IPS  on HAM3 HEPI with other sensors to see if the failure that took out this chamber this morning (killing commissioning efforts until ~now) gave us any warning. I attach some dataviewer trends of the IPS blend ins, and I can kind of convince myself that the horizontal loops all look a little noisier 18 hrs ago versus now. Not necessarily true, I haven't looked in any detail and I'm just guessing based on the max/min being noisier 18 hours ago.

All models on the h1seih23 computer stopped running.  A quick check showed that the I/O chassis appeared to be powered down, as no cards were reported from the I/O chassis with a lspci -v command.  We assumed the power supply had failed, so we removed the computer from the Dolphin network, stopped the models, and powered off the computer.  We then examined the I/O chassis only to find that it was powered up and appeared to be running OK.  

After examining the one-stop cable to make sure it was seated properly and showed no signs of having been kinked or otherwise damaged, the I/O chassis was powered down, then back up, and the computer restarted.  All models started normally with only a slight IRIG-B deviation into a negative value which quickly recovered.

Bottom line is we don't know what happened.

645 Jeff B. - LVEA CC stuff HAM6

713 Karen - LVEA

805 Jim W. - LVEA inspect HAM3

815 Jeff B. - Back

818 Jim W. - Back

840 Doug, Jason - LVEA prepping OpLev

909 Jim W. - LVEA more inspection

939 Doug, Jason  - Back

946 Sudarshan - LVEA

1002 SEI HAM2,3 FE model restart

1024 Suresh, Doug, Jason - Tweak HAM3 OpLev

1031 Richard - LVEA swapping ADC

1039 Jeff B. - LVEA

1039 Ed M. - LVEA

1047 Richard - Back

1047 Ed M. - Back

1048 Jeff B. - Back

1052 Sudarshan - Back

1112 Richard - LVEA replace ribbon cable

1122 Richard - back

1204 Doug, Jason, Ed M, Suresh - LVEA adjusting OpLev

1225 Sudarshan - LVEA

1229 Sudarshan - Back

1232 Doug, Jason, Ed M. - Back

1300 Suresh - Back

1340 - Restarting IO chasis for HAM2,3

This is posted early since I have to go to the airport

Last night, we again became unable to damp the roll modes (see previous experience in alog 17378) with the usual damping settings. After some random experiments, we became able to damp it with the usal damping settings for some reason. We have no idea why the mode occasionally behave in this way. Note that we use AS_WFS_A for damping them.

(The roll modes)

After the recycling gain study (alog 17645) and ASC study (alog 17646), we fully locked the interferometer with DC readout and 10 W. We immediately noticed that the DARM spectrum was extremely noisy which turned to be high roll modes saturating the OMC DC PDs at the ADC. Looking at the frequency of the peak in the DARM spectrum, we could idenfity the mode -- it was at 13.8 Hz which is the one from ITMX. The peak height was as high as 10^-12 m/sqrtHz in the DARM spectrum with 0.1 Hz BW. We went back to ASQ in order to address the issue. The PSL power remained at 10 W. Evan tried different phases (e.g. +-60 deg) and even the negative sign in the damping gain, but none of them seemed to work. This is exactly the same situation as the one previously reported (alog 17378).

(Damping experiments)

- ITMX

Since I knew that it was mostly from ITMX, I first disabled the damping on ETMY in order to make the experiment straightforward. Then I narrowed the pass band on ITMX, which is nominally 1 Hz wide with a center frequency of 13.9 Hz, to 100 mHz passband with a center frequency of 13.8 Hz. They are 4th order butterworth filters. According to foton, this change causes an extra phase rotation of 30 deg, which I did not try to correct as this seemed small enough. Engaging the narrower butterworth, I was able to damp the mode with the same positive gain. This brought the peak height in the DARM spectrum to as low as 10^-14 m/sqrtHz.

- ETMY

I then moved onto ETMY to propagate the same modification. ETMY also had a 1 Hz bandpass 4th order butterworth with a center frequency of 13.9 Hz. I tried a 100 mHz passband with a center frequency of 14 Hz. This again caused a 30 deg phase shift, but I neglected it. After engaging the narrower bandpass on both ITMX and ETMY, however the modes slowly started growing up. I tried different phases and negative damping gain on ETMY, but none of them helped. I also tried several configurations -- e.g. disabling ETMY and keeping ITMX, disabling ITMX and running ETMY, and etc. But I did not succeed in damping the modes. Moreover they kept growing on a time scale of a couple minutes.

- Ending up with the same old configuraion

After all, I switched the bandpss filters back to the 1 Hz passband ones to see if I can damp them. Yes, I was able to damp them. The decay time was approximately on a time scale of a couple minutes. No extra phases or sign flips were needed. Unsatisfactory (✖╭╮✖)

Summary: H1:SUS-ETMX_M0_DAMP_L_IN1_DQ looks to have been saturating during the long lock and making glitches in DARM at 9Hz. 

In Detchar we're looking at the 2015-04-02 lock from ~8-13 UTC, which had good sensitivity and some amount of undisturbed time. The hveto page for that day has several interesting glitch classes. The first round winner is a series of glitches centered at around 9Hz and associated with the SUS ETM* L1/M1 L channels. These glitches seem to only show up in this high sensitivity lock and not the low sensitivity locks around it (perhaps higher RMS on M0 in low-noise configuration?). Checking the raw data, it appears that H1:SUS-ETMX_M0_DAMP_L_IN1_DQ is saturating.

• Figure 1 shows a time-frequency map of all glitches (black circles) and the glitches associated with this mechanism (red pluses).
• Loads of omega scans showing how these glitches show up in DARM and in the SUS channels can be found here. 
• Figure 2 shows a spectrogram of the SUS channel lined up with its timeseries. I think the wavy cutoff at the top of the timeseries indicates saturation somewhere a little bit of filtering away from this channel.
• Figure 3 shows the spectrogram of the SUS channel lined up with the spectrogram of DARM. The broad SUS glitches up to 10Hz correlate with DARM glitches at around 8-9Hz. 

Note: CIS says this channel is calibrated in um. I don't know whether this is a digital saturation or some physical thing - will consult a SUS expert. 

One mystery, to me, is why the glitches occur at GPS times ending in .000, .250, .500, and .750. This might be due to time domain clustering in our glitch algorithm. At first I thought it indicated a digital origin for the glitches, which turns out to have been a red herring. 

This is a follow up entry of LHO ALOG 17601.

A couple of days ago, the discrepancy of the response for DCPDA and DCPDB were found. This was basically caused by misadjusted filter modules for the anti-whitening filters. Some of them were using design values (like Z10:P1) and some others were just left as they had been imported from the LLO setup.

In order to correctly take the whitening transfer functions into account, the wiring of the in-vacuum and in-air connections were necessary to be tracked down. The 1st attachment shows the sufficiently detailed wiring chain for this task. Using the test data (links indicated in the diagram), we can reconstruct what the correct anti-whitening filters should be. The summary can be found below.

[Trivia for Rich: DCPD1 (Transmission side of the OMC BS) is connected to HEAD2, and DCPD2 (Relfection side of the OMC BS) is connected to HEAD1. This is because of twisted D1300369. This cable has J2 for HEAD2 and J3 for HEAD1. This twist exists in LLO and LHO consistently, as far as I know]

=======
Characteristics of the DCPD electronics chain
Complex poles/zeros are expressed by f0 and Q

DCPD A
(DCPD at the transmission side of the OMC DCPD BS)
- Preamp D060572 SN005
Transimpedance: Z_LO = 100.2, Z_HI = 400.0
Voltage amplification ZPK: zeros: 7.094, 7.094, (204.44 k, 0.426), poles: 73.131, 83.167, 13.71k, 17.80k, gain: 1.984

- Whitening filter D1002559 S1101603
(This document defines the gain not at the DC but at a high frequency. The gain below is defined as a DC gain.)
CH5 Whitening
Filter 1: zero 0.87, pole 10.07, DC gain 10.36/(10.07/0.87)
Filter 2: zero 0.88, pole 10.15, DC gain 10.36/(10.15/0.88)
Filter 3: zero 0.88, pole 10.20, DC gain 10.36/(10.20/0.88)
Gain: “0dB”: -0.051dB (nominal), “3dB”: 2.944dB, “6dB”: 5.963dB, “12dB”: 11.84dB, “24dB”: 24.04dB

DCPD B
(DCPD at the reflection side of the OMC DCPD BS)
- Preamp D060572 SN004
Transimpedance: Z_LO = 100.8, Z_HI = 400.9
Voltage amplification ZPK: zeros: 7.689, 7.689, (203.90 k, 0.429), poles: 78.912, 90.642, 13.69k, 17.80k, gain: 1.983

- Whitening filter D1002559 S1101603
CH6 Whitening
Filter 1: zero 0.88, pole 10.13, DC gain 10.41/(10.13/0.88)
Filter 2: zero 0.87, pole   9.96, DC gain 10.40/(  9.96/0.87)
Filter 3: zero 0.88, pole 10.15, DC gain 10.41/(10.15/0.88)
Gain: “0dB”: -0.012dB (nominal), “3dB”: 2.982dB, “6dB”: 6.007dB, “12dB”: 11.87dB, “24dB”: 24.04dB

=======

Now we put these transfer functions into the model and check if we can reproduce the observed relative difference (Attachment 2). In deed, the measurement is well explained by the model below 30Hz where the measurement S/N was good. As we saw in the previous entry, the difference of the DCPDA and DCPDB after the whtening compensation is 20% max. Note that further inspection revealed that this 20% difference is, in fact, mostly coming from the difference of the preamp transfer functions rather than the miscompensation.

So this was the relative calibration between DCPDA and DCPDB. How is the compensation performance of each one? The 3rd attachment shows how much of current we get at the output as H1:OMC-DCPD_A_OUT, H1:OMC-DCPD_B_OUT, and H1:OMC-DCPD_SUM_OUT, if we give 1mA of photocurrent to DCPD_A, DCPD_B, or both (half and half). Ideally, this should be the unity. The plot shows how they have not been adjusted. For the our main GW channel we take sum of two DCPDs. The individual deviations were averaged and thus the sum channel has max 10% deviation from the ideal compensation. This shows up in the GW channel.

=======

So let’s implement correct compensation. Basically we can place the inverse filter of the each filters. The preamplifier, however, includes some poles and zeros whose frequency are higher than the nyquist frequency. Here we just ignore them and assess how the impact is.

The result is shown as the 4th attachment. Upto 1kHz, the gain error is less than 1%. This increases to 5% above 3kHz.  The phase error is 7deg at 1kHz. This increases to 20deg above 3kHz. These are the effect of the ignored pole/zeros. Note that these are static error. In fact, the phase error is quite linear to the frequency. Thus this behaves as a time delay of ~18.5us. Since the phase delay at 100Hz is small, the impact to the DARM feedback servo is minimal. For the feedforward subtraction, however, this might cause some limitation of the subtraction performance. In practice, we measure the coupling transfer function in order to adjust the subtraction, in any case. Therefore this delay would not be a serious problem.

The filter bank to implement the new compensation was already configured. The filter file is attached as foton_DCPDfilters.txt.