Displaying reports 57461-57480 of 78016.Go to page Start 2870 2871 2872 2873 2874 2875 2876 2877 2878 End
Reports until 16:00, Tuesday 01 September 2015
LHO General
bubba.gateley@LIGO.ORG - posted 16:00, Tuesday 01 September 2015 (21106)
Maintenance day tasks
Craned 3IFO TCS chiller to west bay (because Jodi said it really needed to be over there).

I inspected the rigging in the LVEA while in there this morning. All good.

I checked the flow of nitrogen too all of the LTS containers in the LVEA. All have good flow rates.

Checked the electronics room air handler filters, they were O K however there was a fault on the system. One of the outdoor units of the split system had tripped a breaker. I reset the breaker and thermostat and cleared the fault. All units are functioning.

Report of lights not working in the OSB kitchen, found some burned out bulbs and some defective fixtures. New fixtures on order.

H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:43, Tuesday 01 September 2015 (21105)
DB & DES Cabinet Data
Attached are the plots for the temperature and relative humidity data from the month of August from the two dry boxes and the desiccant cabinet. All plots show normal operations for the past month. 
Non-image files attached to this report
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 15:36, Tuesday 01 September 2015 - last comment - 17:09, Thursday 30 June 2016(21101)
OMC DCPD signal chain,maybe missing 10-ish kHz pole in our model

In this morning, I checked the OMC DCPD electronics chain (for both A and B) by injecting known sine wave analog signal. This was one of those items that Keita suggested me a while ago.

According to the data, I am concluding that our calibration model needs to add another pole at 10-ish kHz for accurately simulating the OMC whitening circuits.

 


Method

The measurement method is straightforward -- it is a swept sine measurement in a manual way.

I had a function generator by the HAM6 electronics rack which drove a single-ended-to-differential convertor (D1000931, technically speaking this is a coil driver test box). Then the differential signal is sent to the input of the OMC DCPD whitening board (D1002559, S1101603) by some clipping technique. By the way, the actual cable for connecting the OMC DCPDs were unplugged during the measurement. The excitation amplitude was set to 2 Vp-p at the function generator which resulted in 2 Vp-p in both positive and negative paths at the input of the whitening board as expected accroding to the schematic of the coil driver test box.

I then recorded the data in IOP at the full sample rate using dataviewer for 1 sec for a selected excitation frequency (and for some reason, diaggui did not want to run and hence dataviewer this time). Keeping the same excitation amplitude, I manually stepped the freqyency from 8 kHz to 100 Hz. After every step, I saved the time series of the IOP so that I can make a transfer function later. In addition, I had an oscilloscope with me which kept monitoring the excitation ampitude at the input of the whitening board. The scope told me that the excitation ampltude stayed constant at 2.02 Vp-p in each channel throughtout the measurement. The OMC DCPD had

 

Analysis and result

To get a transfer function from the data that I took in time series, I decided to do a sine-wave fitting for each data chunk to get the amplitude information. I wrote a small matlab script to do it. It can be found at:

aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Matlab/OMC_DCPD_AnalogChain_TimeSeries.m

The script utilizes fminsearch and spits out the best fit amplitude for each frequency measurement. Additionally, it places uncertainty or error bar by taking the standard deviation of the residual. Note that this is not a standard way to place an error bar since it does not take the number of measurement points into consideration. According to the fit, the residuals were found to be usually a few counts which is much smaller than the amplitude of signals which was about 2000 counts. So it typically places 0.1% uncertainty after all.

The result is shown in the attached pdf. By the way the lower panel in the plot says, "residual", but it should read "(measured)/(model)" instead. It shows the measured transfer function together with the expected model transfer function for comparison. It is very obvious that the measurement suggests that our model is missing some high frequency pole. The model is merely made of the analog AA response which I have already measured and fitted. Adding some random pole, I could see an extra pole at around 10.7 kHz making the fitting much better. In fact, I sort of knew that there seemed to be a high frequency pole by some other measurements which I did not post. We probably need to add this high frequency pole in our calibration model.

Non-image files attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 19:28, Tuesday 01 September 2015 (21123)

I have measured and fitted the AA filter response for DCPD A and B (ch13 and ch14 of S1102788 respectively). I used the same coil driver test box to produce differential signal and measured the transfer functions with SR785. The results don't show any unexpected additional high frequency poles.

The plots are shown below in line. The fitting is good up to 10 kHz.

 

The fitting code can be found at:

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_AA_OMC_DCPD_A.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_AA_OMC_DCPD_B.fil

The analysis/plot code can be found at:

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/OMC_DCPD_AA_filters.py

The figures in both pdf and png formats are available at:

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_A.pdf

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_A.png

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_B.pdf

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_B.png

Images attached to this comment
Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 21:24, Tuesday 01 September 2015 (21124)

Independently of the above measurements, I have measured the entire signal chain of the OMC DCPD A and B by injecting random signals from the extra DAC output in LSC (a.k.a. LSC-EXTRA_AO2).

It also showed a high frequency pole at around 10.7 kHz which is consistent with the result from the manual swept sine described above.

 


Measurement setup

  • Random noise excitation in LSC-EXTRA_AO2
  • Output of the LSC-EXTRA_AO2 at the ISC rack is connected to a spear RF patch panel and routed all the way to the HAM6 area.
  • In the HAM6 area, the excitation signal is split into two by a BNC tee and drives the A and B inputs (corresponding to ch4 and ch5 respectively) of the whitening board (D1002559, S1101603).
    • Note that this time the connections are made in a single-ended manner, so that it does not exctie the negative leg of the differential receiver in the whitening board.
  • I took a transfer function from the IOP channel of LSC-EXTRA_AO2 and that of OMC DCPD A and B in order to avoid confusion from IOP's up/down-sampling filters.

By the way, in the digital world particularly in the IOP world, LSC-EXTRA_AO2 is called DAC0_CH9, and DCPD A and B are called ADC0_CH12 and CH13 respectively.

AI filter for LSC-EXTRA_AO2 needed to be measured

Since this measurement automatically includes the AI filter for LSC-EXTRA_AO2, we need to subtract this transfer function out of the resultant measurement. So I measured and fitted it (ch10 of S1102761) by using the coil driver test box (D1000931) and a SR7850. Here is the result.

As shown in the plot above, the fitting is good up to 10 kHz. I did not see unexpected high frequency pole. The fitting code, data and results can be found at:

/aligocalibration/trunk/Runs/ER8/H1/Measurements/AAAI/LSC_EXTRA_AO_AI_v2.dat

/aligocalibration/trunk/Runs/ER8/H1/Scripts/AAAI/Liso/fit_AI_LSC_EXTRA_AO.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/AAAI/python/LSC_EXTRA_AO2_AIfilter.py

/aligocalibration/trunk/Runs/ER8/H1/Results/AAAI/2015-08-27_AI_LSC_EXTRA_AO.png

/aligocalibration/trunk/Runs/ER8/H1/Results/AAAI/2015-08-27_AI_LSC_EXTRA_AO.pdf

This fitting result is then used in the subsequent analysis as decribed below.

 

Results

First of all, I attach the measured transfer functions together with the fitting result.

As I noted in the above subsection, the measured transfer functions include

  • AI filter of LSC-EXTRA_AO2
  • AA filter of DCPD A or B
  • flat response of the whitening filters (as I set them to 0dB with no whitening stages engaged)

In my fitting model, I newly inserted a high frequency pole at around 11 kHz as an initial guess. Without this additional high-freq pole, the fitting would be miserable above 1 kHz similarily to the one shown in the above entry or alog 21101. As for the parameters of the AA and AI filters, I have used the fitted parameters and do not try to re-fit them in this anaysis. In other words, the fitting parameters in this analysis are:

  • high-freq pole at around 11 kHz
  • scale factor (which should be close to 0.5 because I am driving only one leg of the differential receiver)
  • delay presumably due to some computation cycle

The below are the raw output from LISO:

#Best parameter estimates:
#pole6:f =  10.7609523979k +- 1.226 (0.0114%)

#Best parameter estimates:
#pole6:f =  10.7183613550k +- 1.209 (0.0113%)

The upper one represetns the fitting result for DCPD A and the lower one for DCPD B. Both of them have a pole at around 10.7 kHz.

Some SVN info

As usual, the data, codes and resultant figures are saved in svn. They can be found at:

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/LSC_AO_OUT_to_OMC_DCPDs_RandNoise_0whitenings.xml

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH12_0whitening_tf.txt

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH13_0whitening_tf.txt

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH12_0whitening.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH13_0whitening.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/OMC_DCPD_AAandWhite.py

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_A_AAand0White.pdf

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_A_AAand0White.png

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand0White.pdf

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand0White.png

 

Next step

I will analyze equivalent data with one whitening stage engaged. This is more important because this is likely going to be the configuration we will run during O1.

Images attached to this comment
Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 23:00, Tuesday 01 September 2015 (21126)

I have measured the DCPD signal chain in the same fashion as the previous alog, but this time with the 1st whitening stage engaged.

Here is my conclusion:

  • The whitening board seems to consistently show a high frequency pole at around 11 kHz
  • The zero and pole location of the 1st whitening stage seem to be inaccurate by 12% at most
  • We should  re-measure the whitenig board in a wide frequency band

Measurement setup

The measurement setup is the same as the one in the previous alog shown above. I drove LSC-EXTRA_AO2 by random noise and took transfer functions from the IOP test point of LSC-EXTRA_AO2 to that of DCPD A and B. This time the 1st stage whitening filter is engaged with 0 dB gain.

Results

Here are the measured transfer functions with the fitting results.

LISO says:

#Best parameter estimates (for DCPD A):
#pole6:f =  10.8756718522k +- 1.275 (0.0117%)
#pole7:f =  10.3442465820 +- 4.165m (0.0403%)
#zero2:f =  992.1541013425m +- 2.461m (0.248%)
#factor =  500.1410089072m +- 1.112m (0.222%)

#Best parameter estimates (for DCPD B):
#pole6:f =  10.8295424180k +- 1.26 (0.0116%)
#pole7:f =  10.4145450914 +- 4.172m (0.0401%)
#zero2:f =  998.2444937993m +- 2.463m (0.247%)
#factor =  499.8306079302m +- 1.105m (0.221%)

 

The result suggests that the high frequency pole (called pole6 in the fitting code) moved up by 1-2% from 10.7-ish kHz to 10.8-ish kHz in both DCPD A and B compared with the previous data without the whitening filter engaged. I don't have a good explanation for why they moved up. But the point is that the high frequency pole does exist in the whitening configuration that we want to run during O1. Therefore we should definitely include this pole in our calibration model. Additionally, the measurement done at Caltech also shows a reduction in the magnitude as frequency reaches the end of the measurement frequency band at around 6 kHz (S1101603). Therefore I start believing that this high frequency pole is real and do exist in the whitening boards. I guess this effect was not visible in my intemnsity transfer function measurement (alog 20851) because ASC-AS_C, which was my intensity reference, also uses the same whitening circuit (D1001530) as OMC DCPDs.

Another interesting thing is that LISO reports different poles and zeros for the actual whitening filters than the ones reported in DCC (S1101603, or see nice summary by Koji at alog 17647). The pole location seem to be almost the same at a few % level, but the location of zeros differ by more than 10%. This is not cool. This also makes me think that we should re-measure the whitenig filter response.

SVN info

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/LSC_AO_OUT_to_OMC_DCPDs_RandNoise_1whitenings.xml

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH12_1whitening_tf.txt

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH13_1whitening_tf.txt

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH12_1whitening.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH12_1whitening.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/OMC_DCPD_AAand1White.py

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_A_AAand1White.png

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand1White.pdf

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand1White.png

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand1White.pdf

Images attached to this comment
kiwamu.izumi@LIGO.ORG - 01:45, Wednesday 02 September 2015 (21131)

This should be a killer measurement for this long discussion which was triggered by the unexpected high frequency pole-ish behavior in the DCPD signal chain. I have measured the transfer function of the DCPD whitening filter using an SR785 tonight.

The current conclusions are that:

  • A measurement of the whitening filter tells that we need to have two poles at high frequencies-- one at around 18 kHz and the other ar around 14 kHz
    • ( In addition, another pole at 98 kHz gives us a better fitting )
  • The whitening zero-pole pairs need to be updated in the calibration model and perhaps in the OMC front end model in order to accurately compensate the filter response.

 


Motivation

There seemed to be one or perhaps multiple high frequency pole(s) at a frequency on the order of 10 kHz. We wanted to include them in the calibration model to be mroe accurately model the phase and time delay. Besides, independtly of the high frequency poles, we noticed that the whitening zero-pole pairs were not precisely at the frequencies specified in the DCC document of an early measurement (S1101603). These two things pushed us to re-measure the analog transfer function of the whitening filter, in particular the first stage which is the one we usually use in full lock.

Measurement

I again used the coil driver test box only for the reason that I wanted a single-ended-to-differential convertor. With an SR785, I performed a swept sine measurement for ch4 and ch5 which correpond to DCPD A and B respectively. The 1st stage of the whitening filter was engaged while the rest are disabled for both A and B whitening filters. The whitening gain was set to 0 dB for both A and B. These settings are nominal that we usually operate in full lock. The exctiation amplitude was 200 mVp-p in the positive and negative inputs which resulted in 2 Vp-p at highest at the positive and negative outputs. With a scope, I confirmed that there was an obvious distortion or saturation in the signal at the outputs.

Results

I fitted the measured data with four poles and one zero. See the fitting results shown below.

As shown in the plot, the fitting is good from 1 Hz to 10 kHz at 0.1% level in absolute amplitude and 0.02 deg level in the phase. Here are the raw output from LISO.

#Best parameter estimates (for DCPD A):
#pole0:f =  18.6402825833k +- 20.23 (0.109%)
#pole1:f =  14.5121291389k +- 12.5 (0.0861%)
#pole2:f =  98.9771014448k +- 60.89 (0.0615%)
#pole3:f =  10.2675781089 +- 660.2u (0.00643%)
#zero0:f =  973.9581771978m +- 151.1u (0.0155%)
#factor =  993.7495082788m +- 129.2u (0.013%)


#Best parameter estimates (for DCPD B):
#pole0:f =  18.4126906482k +- 21.61 (0.117%)
#pole1:f =  14.6312083283k +- 13.88 (0.0949%)
#pole2:f =  98.3231767285k +- 60.51 (0.0615%)
#pole3:f =  10.3405121747 +- 667u (0.00645%)
#zero0:f =  980.5696173840m +- 152.8u (0.0156%)
#factor =  993.4759822630m +- 129.8u (0.0131%)

 

In order to get a better fitting, I ended up adding three poles at high frequencies -- two of them seem to stay between 10 and 20 kHz while the third one tends to be at around 98 kHz. I did not need to have a delay at all because this is just an analog circuit.

SVN info

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-09-02/DCPD_A_1whitening.dat

/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-09-02/DCPD_B_1whitening.dat

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_whitening_1st_stage_DCPD_A.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_whitening_1st_stage_DCPD_B.fil

/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/whitening_1st_stage.py

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_A.pdf

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_A.png

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_B.pdf

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_B.png

Images attached to this comment
Non-image files attached to this comment
koji.arai@LIGO.ORG - 02:32, Thursday 03 September 2015 (21168)

Are these above-Nyquist-freq poles the ones I've reported with LHO ALOG 17647?
If so, they are the high freq poles associated with the OMC DCPD in-vac preamps.
Since they exist above the Nyquist frequency (~8kHz), it is not straight forward to compensate them.

As they show up like a linear time delay at low freq, we decided to leave them uncompensated in April. (Refer Daniel S, Jeff K).
This corresponds to ~18us delay. I thought this was already accommodated in the DARM calibration model described in LHO ALOG 17951
and the following comments (particularly in LHO ALOG 18037). Were they dropped at some point?

kiwamu.izumi@LIGO.ORG - 07:12, Thursday 03 September 2015 (21171)

Koji,

No. They are not the ones in DCPDC's preamp. These poles are found in the whitening board by directly measuring it.

As for preamp's super-nyquist poles, they have been incorporated in our calibration model and  have been actually used in the upsampled FIR pipeline without approximating it as a time delay. So we did not drop the ones from the preamp.

kiwamu.izumi@LIGO.ORG - 12:16, Thursday 03 September 2015 (21184)

For double chek my conclusion written above, I went back to the original plot in alog 21101. With the newly discovered high frequency poles of the whitening board (alog 21131) included, the measurement agrees with the model with 1-ish % descrepancy up to 5 kHz in magnitude as shown in the attached plot.

This is good enough .

 

The code and figure:

 /aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Matlab/OMC_DCPD_AnalogChain_TimeSeries.m

/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-09-01_OMC_DCPDs_timeseries_analysis.pdf

Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 17:09, Thursday 30 June 2016 (28101)

The data for the whitening filters in the above entries are obsolete as of 30/6/2016.

The whitening chassis was replaced by a different unit on June 28th in 2016 (alog 28010). A new measurement was taken on June 30th in 2016 (alog 28087).

H1 SUS
betsy.weaver@LIGO.ORG - posted 15:30, Tuesday 01 September 2015 (21104)
TUESDAY MAINTENANCE STATUS

Pacific Time

7:30AM - Craning of 3IFO TCS chiller for some reason.

9AM   - SR3 Troubleshooting - couldn't "see" the problem early this morning, Richard swapped a bunch of stuff, don't really see it now, unconclusive

          - PSL chiller flow channel troubleshooting by Jason - fixed

          - OMC DC PD Measurement by Kiwamu

10AM - ODC Model update happened

          - DAQ down for FW2 build/start

          - Dust monitor plumbing in LVEA for 2 hours

          - Harmonic Generator power supply work for a while

 

11AM - Guardian restart for new nodes ala Jamie - these nodes will tie into the INTENT bit - call Jamie or Betsy if you get stuck and can't push the intent button

11:30  - Ran charge measurements on ETMX and ETMY SUS

 

DAQ restart stuff - ongoing, Dave says it didn't go weel, troubleshooting with multiple restarts this afternoon

Locking IFO ongoing with Corey/Kiwamu.

 

H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 15:14, Tuesday 01 September 2015 (21102)
Time Varying Calibration Parameters

GregM, RickS, DarkhanT, SudarshanK

We took a 10 hour long lock-stretch from ER8 and studied if there is a significant change in the time varying parameters, kappa_tst, kappa_pu, kappa_C, kappa_A and cavity pole which are described in details in DCC document T1500377. The plots of these parameters are attached below.

The real part of these parameters represents the actual change. There is no significant variation in these paramaetrs within this lock stretch. There is definitely some indiication that the variation is more during the first half hour of the lock and stabilizes after that. Essentially, these  numbers should be 1 (are set at 1 at some point in time) and the imaginary part of these parameters should  be zero or insignificant, however, the second plot doesnot show that. The reason might be because we are using the Calibration model form ER7 which is not the true representation of interferometer at which this data was taken plus we didnot account for time delays. However, we were only intrested in knowing the change in these parameters so this analysis was sufficient for that purpose.  We will do a more thorough study once we have the new calibration model ready.

We are also looking into how these parameters are changing over a long period of time (entire ER8). The analysis is ongoing and we will post the result soon.

Images attached to this report
H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 14:28, Tuesday 01 September 2015 (21096)
Pcal End-Station PD Readout Calibration

Summary

This is the data analyzed from last week's end-station Pcal readout calibration.  The new calibration factors will be used to compare with the old calibration factors. The calibration factor currently used will only be updated if there is a significant change. 

Details:

The calibration factors obtained from this particular measurement are tabulated below. The number in parenthesis is the weighted mean of our past calibrations that we have been using in our current calibration model. The new factors are comparable with the past measurements in most cases. 

  RxPD (N/V)  TxPD (N/V)
CAL-PCALX 1.062E-09 +/- 0.85% (1.053E-09) 1.317E-09 +/- 0.85% (1.322E-09)
CAL-PCALY 1.053E-09 +/- 0.65% (1.059E-09) 1.519E-09 +/- 0.65 % (1.520E-09)

The RxPD at ENDX shows a difference of about ~1% from our currently used calibration. We think this is because there might be some beam clipping issue again that we have seen in the past in this particular unit. The drop in optical efficiency, seen in the attached report, and the trends of the RxPD signal both point in this direction. We don't have major calibration lines running in this unit( there is a high frequency (3KHZ ) line only). Additionally, we also have a TxPD readout that we can use if we show the clipping is happening on the way out, after reflecting off the testmass, which we think is the case. There are ways to check this and we are pursuing those cross-checks.

All the data and plots have been updated to the svn and more details about the intermediate factors used during the calculation, optical efficiency etc is attached with this alog. 

The summary page (T1500252) on DCC that  keeps track of these calibration factors has also been updated.

Non-image files attached to this report
H1 SUS (INS, SUS, SYS)
leonid.prokhorov@LIGO.ORG - posted 12:55, Tuesday 01 September 2015 (21097)
ESD actuation strength -
Leo, Jeff

We try to measure the force acting on the TM from the electrical field goes from ESD blades to the cage and other surrounding. It corresponds to F_3 in Livingston alog 16611 and gamma in LIGO-T1500467. Relation between force due to the ESD-to-Cage field and due to usual ESD differential field may be characterized by c/a (in terms of LLO Log, = gamma/alpha in DCC note).
The measurements was done on Aug, 17 and Aug, 25 , each of 4 charge measurement with additional measurement in script. The additional measurements was done with zero bias voltage and signal offset voltage = +/-4 V. The sine voltage in signal was multiplied by 0.5 against the charge measurements due to voltage should not not exceed the maximum value, while the charge measurements use the amplitude of the signal voltage close to the max.
Measurements was done with ESD_Night scripts with Gamma1 measurements and proceeded by ESD_analysis_gamma.m 

Results of c/a (=gamma/alpha):

ETMX 
Pitch	08/17	st. dev		08/25	st. dev
UL		0.32		0.03			0.30		0.04
LL		0.34		0.04			0.33		0.02
UR		0.31		0.02			0.31		0.03
LR		0.33		0.03			0.32		0.02
Yaw				
UL		0.31		0.03			0.31		0.04
LL		0.27		0.03			0.28		0.03
UR		0.30		0.04			0.31		0.03
LR		0.25		0.02			0.27		0.02
	
ETMY
Pitch	08/17	st. dev		08/25	st. dev
UL		0.32		0.01			0.33		0.01
LL		0.35		0.02			0.37		0.02
UR		0.34		0.02			0.32		0.02
LR		0.37		0.03			0.36		0.02
Yaw					
UL		0.32		0.01			0.33		0.01
LL		0.31		0.02			0.31		0.01
UR		0.34		0.03			0.33		0.02
LR		0.29		0.02			0.31		0.01
H1 SUS
richard.mccarthy@LIGO.ORG - posted 12:50, Tuesday 01 September 2015 - last comment - 17:02, Tuesday 01 September 2015(21095)
SR3 Suspension chain wholesale swap
In an ideal world we would have been able to systematically investigated each stage of the SR3 chain to find where the glitch was coming from.  But with the pressure of needing to get the system up and running I decided to replace all electronics and do a followup in the lab. So this morning we took down the SR3 Front end and installed a new DAC card.  Replace the coil driver SN100186 with SN 100192.  The AI chassis had been replaced last night.  So aside from cabling replacement the SR3 drive chain is new and after 10 minutes we do not see the glitches.  Of course I could go 10 min this morning and not see them.

Also there was a problem with the Voltage Monitor for T2.  This was in the IO chassis ADC interface so we replaced the ADC the ribbon cable and ADC interface card for the SUS Aux chassis.  This fixed problem.  
Comments related to this report
sheila.dwyer@LIGO.ORG - 16:50, Tuesday 01 September 2015 (21111)

This screenshot show the OPlev and witness sensor for SR3 pit.  The problem shows up clearly early monday morning, things got slightly better around 2 am last night for unknown reasons.  This morning after the electronics were swapped, the frames are bad, and now the problem seems to be fixed.  

The second screenshot is a lockloss from last night, in which you can see that before the lockloss, SR3 gets something like 1 urad of pitch in about half a second.  This is visible in both the witness sensor and the oplev although the calibrations don't agree.  We also had smaller glitches that weren't large enough to lock us out of lock, but we think that the large ones were happening about once every 20 minutes or more frequently.  

Images attached to this comment
jenne.driggers@LIGO.ORG - 17:02, Tuesday 01 September 2015 (21114)

Here's a different view of the same thing that Sheila just posted. 

I have 3 1-hour plots of SR3 M3 Wit Pit, all with the same y-axis scale:  (1) Aug 26th at some time when the Cage servo was running, (2) sometime last night, and (3) right now.  The "right now" plot shows the lock aquisition sequence, including the cage servo being engaged, which is why the DC value changes. 

The salient point is that last week, the M3 Wit Pit looked nice and clean.  Last night, even though there weren't huge glitches in the time that I chose, the optic was clearly moving around much more than normal.  Now, the data looks clean again.

Images attached to this comment
H1 ISC
keita.kawabe@LIGO.ORG - posted 12:48, Tuesday 01 September 2015 - last comment - 17:28, Wednesday 02 September 2015(21094)
Harmonic generator testing (Filiberto, Keita)

We pulled both the power supply and the harmonic generator from the remote rack and tested them in the lab, together with spare supply and spare generator. We used a spare 9.1MHz source on the bench.

In the lab, regardless of the combinations (supply and generator), 45MHz thing was clean.

In the rack, we tested the original generator with spare and original supply, with 9.1MHz source coming from the distributor in the rack. In both of the cases there were huge 45+-2MHz-ish humps.

Evan reported in the past that using IFR at the rack didn't change the results, so we didn't bother to look at 9.1MHz source.

In all of these test cases both in the lab and rack, the only thing connected to the harmonic generator was power supply, 9.1MHz source and the network analyzer on 5x output. Everything else was terminated.

We also looked at the supply voltage in the lab. We opened the chassis and used clips to access gnd and +15V test points. Under the load, both of the units didn't show any huge high frequency noise. RMS voltage measured on the scope was about 1mV, which was dominated by some pickup (it got smaller when I hand held the chassis away from the 9.1MHz source). Fil also measured the spectrum and it was within the spec. And anyway, the harmonic generator didn't show any hump in the lab, so the power supply is pretty much exonerated.

Fil put the original units back in.

Comments related to this report
rich.abbott@LIGO.ORG - 13:17, Tuesday 01 September 2015 (21098)ISC
Do the other harmonic harmonic generator output spigots have excess sideband noise?
evan.hall@LIGO.ORG - 14:03, Tuesday 01 September 2015 (21100)

Rich, yes. I took measurements of some of the other ports of the HG in the CER a few days ago (measurements attached).

001.TXT: 45 MHz output

002.TXT: 27 MHz output

004.TXT: 135 MHz output

005.TXT: 90 MHz output

007.TXT: 36 MHz output

Non-image files attached to this comment
rich.abbott@LIGO.ORG - 16:48, Tuesday 01 September 2015 (21113)
There's a clue in the data files you attached.  Looking at the plot of the 45 MHz, you see side lobes at +/- 1MHz.  Looking at the plot of 90 MHz, and 135 MHz you see side lobes with the same offset frequency.  If the source of the pollution was coming into the input of the harmonic generator, then the peaks of the side lobes would scale with frequency.  Given that this is not the case, you are looking for something that effects each frequency directly.  In my opinion, that would most likely point to a power supply issue causing phase modulation of an amplifier common to each output spigot (based on the observation that the induced modulation is about the same in each channel and assuming that's the physical topology of the HG).  

There is 50dB of separation between the peak of the carriers and the side lobes, so you can produce a spectrum like that with a pretty small 1 MHz noise hump on a power supply rail.  I would be wanting to look at the HG power supply directly with an RF spectrum analyzer (be sure to AC couple the power supply to the spectrum analyzer or else you will need to buy a new spectrum analyzer, 1000pF would suffice)

I don't know exactly how you are measuring these noise peaks, but I guess it could also be something in the particular spectrum analyzer (if you are using a different analyzer in the shop for example).  Have you looked at a "clean" signal to be sure you don't see it on all observed signals with that particular analyzer?  Sorry if this is simplistic, you may well have already vetted this and wrote about it only to have me forget somewhere.

I now wish I had popped the top on the HG and its power supply.  I have been itching to do that for a while, but missed the opportunity while I was there this weekend.  I'd be super interested to see a photo of the insides if anyone felt like looking...
daniel.sigg@LIGO.ORG - 00:28, Wednesday 02 September 2015 (21129)

The power supply is a LIGO low noise unit boxed into a standard chassis. More details here. Possible points of investigations: power cable shielding, power decoupling at the generator side, grounding issues.

evan.hall@LIGO.ORG - 05:21, Wednesday 02 September 2015 (21132)

I went back and looked at the IFR data from a few days ago, and it seems that this may be a problem with the 9 MHz coming from the OCXO. The first attachment shows the output of the harmonic generator when powered from the IFR versus the OCXO. The IFR measurement still has peaks around the 45 MHz, but they are much smaller than with the OCXO.

As a check, Dan and I measured the spectrum directly out of the IFR and out of the OCXO (no distribution amplifier involved). In both cases, the spectrum on either side of 9.1 MHz looks pretty clean, but the OCXO has much worse noise between 0 and 2 MHz, and the shape qualitatively matches the peaks that are seen on the outputs of the harmonic generator.

We also did some related tests, like looking at the 45 MHz spectrum of the spare HG when powered from the 9 MHz distribution amplifier. This spectrum has the same huge peaks as the primary HG.

Keita and I looked at the noise from the ±15 V power supply, but we didn't see anything outrageous. As advised, we ac coupled the spectrum analyzer with 1 nF. The spectrum seemed to be roughly a few hundred nV/Hz1/2 out to a few megahertz, but we found it hard to get a clean measurement.

Non-image files attached to this comment
rich.abbott@LIGO.ORG - 10:52, Wednesday 02 September 2015 (21137)
I misspoke.  The offset frequency of PM or FM sidebands in a multiplied spectrum remains constant, but the sideband power scales with the multiplication factor.  

9.1MHz carrier (W) with sinusoidal sideband (Wm) before multiplication:
COS[W*t + A*SIN(Wm*t)]

Derivative of argument for angular Frequency:
W + A*Wm*COS(Wm*t)

After frequency multiplication of factor N:
N*W + N*A*Wm*COS(Wm*t)

Sideband frequency unchanged, power scaled by N

That being said, the sideband power is not scaling by N in the data I saw posted.  The carrier could still be amplitude modulated, but I don't see how it could be phase or frequency modulated.  Sorry for my earlier flawed theory on frequency multiplication.

If someone would please figure this out, I could do a much better job of warping theory to fit observation.

Conclusion:  There might be AM being induced on either on the 9.1MHz carrier, or somewhere inside the harmonic generator - for what little that does to help.

daniel.sigg@LIGO.ORG - 12:51, Wednesday 02 September 2015 (21144)

The direct RF spectrum of the 9.1MHz shows no side lopes at 1-2MHz offset. This describes the total power including both AM and FM sidebands. Odd harmonics generators are typically squaring up the fundamental and then filter out the desired frequency. So, they should be first order insensitive to AM.

rich.abbott@LIGO.ORG - 17:28, Wednesday 02 September 2015 (21159)
You are right about the limiting Daniel.  Evan saw sidebands on the OCXO input too.  I attach a plot of the 45.5, 91, and 135 MHz spectra frequency shifted for relative comparison (Data taken from earlier post).
Non-image files attached to this comment
H1 PSL
jason.oberling@LIGO.ORG - posted 12:21, Tuesday 01 September 2015 (21092)
PSL Diode Chiller Flow Rate Channel Frozen - Now Fixed

J. Oberling, P. King

The investigation

Today we investigated what appeared to be frozen PSL channel: H1:PSL-OSC_DCHILFLOW.  Upon entering the laser diode room and comparing the data on the PSL Beckhoff computer's CHIL screen for the diode chiller to the front panel of the chiller itself, we found that all of the channels were not reading properly (flow rate, temp set point, actual temp, conductivity).  These data are read into the Beckhoff computer via RS-232 connections; the flow rate is read into the PSL Interlock Control Box, and the rest of the data are read directly into the Beckhoff computer via an add-in PCI RS-232 card.  Digging into the Beckhoff code it appeared that the Beckhoff data channels were not properly reading in the data from the diode chiller.

What we think happened

Back in May we performed several tests of the interlock system for the chillers to see how they behaved when certain cables were unplugged.  See Peter's alog here, under "The Evidence," point e where he talks about opening and closing the interlock switch.  We unplugged the cables to open the interlock and plugged them back in to close.  When this was performed, we did not restart the PSL Beckhoff PC; we should have, as RS-232 is not hot-swappable.  Therefore the channels for the diode chiller got stuck (interestingly enough the crystal chiller's channels have all been fine, and we performed the same test with it).

The solution

To fix this, we restarted the PSL Beckhoff PC.  We first called the control room to inform them of our intentions, since restarting the PC shuts the PSL down.  They put the IFO in a safe configuration (in this case they simply unlocked the IMC) and we shut the laser down and restarted the Beckhoff PC.  Everything came back on just fine, the PSL fired right up without issue.  Looking again at the CHIL screen the diode chiller data now matches that shown on the front panel of the diode chiller.  Problem solved!

One caveat

While we are now reading data on H1:PSL-OSC_DCHILFLOW, we do not trust the actual reported flow rate.  The same holds true for the crystal chiller, H1:PSL-OSC_XCHILFLOW.  Back in May we replaced the turbine style flow sensors in the PSL chillers with vortex style flow sensors (no moving parts in the new sensors).  With the sensor change we also had to change the flow sensor calibration, a number we received from LZH, who had tested these flow sensors (we went from ~550 pules/liter to 970 pulses/liter).  Upon this change the flow rate on the crystal chiller "dropped" from ~18 lpm to 9.7 lpm, a change of almost a factor of 2.  There was no associated drop in the HPO laser head flow rates (each of the 4 laser heads has its own flow sensor), therefore we do not trust this calibration number and therefore do not trust the flow rate being reported by the chillers.  That being said, we can still use the reported flow rate to monitor if there is a change in flow and as an indicator that something might be wrong.  The flow rate should not change, and if it does then something is not working correctly regardless of the flow rate being output by the chillers.  We do, however, trust the flow rates being reported by the HPO laser head flow sensors and by the water cooled power meter flow sensors.  To fix this, we will take the next opportunity when we have to swap out the running chillers for the spare chillers.  Before putting the spare chiller into operation, we will hook up an external flow meter on its own water circuit (this is before hooking the chiller up to the PSL water circuit), measure the flow of the chiller and adjust the pulses/liter calibration number until the chiller reports the same flow rate as the external flow meter.

H1 DAQ (CDS)
james.batch@LIGO.ORG - posted 11:25, Tuesday 01 September 2015 (21090)
Repurposed h1fw1, reconfigured h1fw2 to write to real /frames
The h1fw1 computer is now only writing raw minute files to it's locally attached SSD RAID file system.  

The h1fw2 computer is writing science and commissioning frames to the /cds-h1-frames file system through the h1ldasgw1 computer.  We will monitor the performance of this configuration and if it works reliably we will change the computer names to reflect their new usage.  

This should have no effect on h1nds1, other than the gap in data that occurred during the reconfiguration and restart of the frame and trend writers.
H1 CDS (CDS)
jonathan.hanks@LIGO.ORG - posted 11:11, Tuesday 01 September 2015 - last comment - 12:17, Tuesday 01 September 2015(21089)
Making the DMT to EPICS bridge permanent.

I am starting work on WP 5471 which will move the DMT to EPICS IOC from a test install to a perminant fixture.  Dave will then configure the EDCU to capture the channel in the frames.   There will be some interruptions on H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC and H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC_GPS.

This is follow up work on previsous work listed in the alog at: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20925

Comments related to this report
jonathan.hanks@LIGO.ORG - 12:17, Tuesday 01 September 2015 (21091)

The work has been completed.  The IOC is installed in h1fescript0.  It will start at system boot.  Dave has put the daq changes in such that it will be captured in the frames after the daq restart.

H1 GRD
jameson.rollins@LIGO.ORG - posted 09:39, Tuesday 01 September 2015 - last comment - 15:13, Tuesday 01 September 2015(21088)
Three new guardian DIAG nodes added: CRIT, SDF, EXC

I have added the following three guardian DIAG nodes:

DAQ restart required to acquire new channel names.

These nodes will all be folded under the IFO top node, but have not yet.  Waiting for go ahead from ops...

I'm also in the process of updating the GUARD_OVERVIEW screen to add these new nodes.  I will post when that screen has been updated.

Comments related to this report
betsy.weaver@LIGO.ORG - 15:13, Tuesday 01 September 2015 (21103)

In discussion, we are proceeding with tying this into the READY bit.  Expect an alog from Jamie - but be aware that you may need to look further at some things if you cannot hit the INTENT bit.  For example, all SDF must be clean (not red) now.  You may need to consult the on-call commissioner if you cannot interpret and address any red SDF differences before going into observation mode.  We have some time before the start of O1, so we'll be troubleshooting this if needed this and next week.

H1 SEI (SEI, SUS)
sheila.dwyer@LIGO.ORG - posted 05:04, Tuesday 01 September 2015 (21085)
three BS ISI trips

At least twice it was just stage 2.  Is something going wrong with the ISI?  or is this a side effect of the SR3 problems, which could cause the MICH ASC to get a kick?

H1 SUS (INJ, ISC, SUS)
jenne.driggers@LIGO.ORG - posted 01:12, Tuesday 01 September 2015 - last comment - 12:38, Tuesday 01 September 2015(21081)
The saga of SR3 glitches continues...

[Sheila, Anamaria, Jenne, Cheryl, Dan, Evan.  Richard via phone]

SR3 glitches are still causing us grief.  This is a continuation of the story started last night (alog 21046), and worked on earlier in the day (alog 21062).  After some heroic efforts, we have determined that we cannot lock in this state. 

To prove to ourselves that indeed it was a problem with the analog actuation chain we investigated turning different pieces of the analog electronics off.  The first attached Dataviewer screenshot shows the NOISEMON channels of the SR3 M1 stage throughout this investigation.  When the local damping is on, we cannot see the glitches very clearly in the noisemon channels - but we do see them in the voltmon channels (The second attached screenshot shows that the T2 voltmon channel does in fact see the glitches, so it's not a broken monitor).  When the local damping is off, we only see the glitches in the noisemon channels. 

Since we do not see the glitches when the AI chassis is powered off, we infer that the noise is not generated in the coil driver board.  (Note that we also borrowed a triple top coil driver chassis from the H2 storage racks, S1100192, but did not swap it in since we don't think the noise is coming from there).  We have not, however, determined whether the noise is coming from the AI board (probably not, since it's still there after a swap?) or the DAC. 

We tried a few times to lock the IFO after the AI board swap, but we were continually losing lock before the CARM reduction is complete.  Lockloss investigations showed that the problem for most of these was SR3 motion. 

At this point, we have determined that we need more expert brains to have a look at the analog electronics.  The owl operator shift has been cancelled, since there will be no more full IFO locking happening until this problem is resolved. 

Images attached to this report
Comments related to this report
richard.mccarthy@LIGO.ORG - 07:41, Tuesday 01 September 2015 (21086)
Looking at the noisemons for a 5 hour stretch when I knew no one was on site.  See attached.
Non-image files attached to this comment
rich.abbott@LIGO.ORG - 12:38, Tuesday 01 September 2015 (21093)ISC, SUS
I would like to help here, but I am not 100% sure I follow the picture.  After the AI swap (which seemed logical to me), you saw no more glitches (presumably in the noise monitors for those channels?).  Then the story gets hazy.  You once more tried to lock and still see SR3 motion as a lockloss initiator.  What exactly is left that you suspect is causing inadvertent motion in SR3?
Displaying reports 57461-57480 of 78016.Go to page Start 2870 2871 2872 2873 2874 2875 2876 2877 2878 End