- Quiet night in terms of locking.
- Most of the night dedicated to PEM injections.
- One lock loss due to injections (PEM).
- Relocking went pretty well, with the biggest thing being that I had to reset the EX ALS VCO (on the VCO screen).
- Transient injections are again enabled.
- Only ~9 hours of lock time during the 3 days
- Low glitch rate during lock time
- 60 Hz magnetic glitches showed up again at EY
- 2 interesting glitch types seen in evening of Sept 2:
- 90Hz lines in ASD-AS_A_RF45_Q_YAW_OUT_DQ (found by Hveto)
- some loud triggers in CBC BBH that looked like lots of vertical lines at around 100Hz.
- Full DQ page: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20150831
Eric, Cheryl Following advice from D Shoemaker et al., we have disabled the LIMIT on the HWINJ filter bank. The change was made at approximately GPS = 1125361473. The LLO LIMIT was turned off earlier today: https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=20249
J. Kissel More UIM driver spelunking uncovers a false alarm, but a definite bug in the QUAD front-end code. I found that the H1 SUS ETMY COILOUTF Bank (the bank that compensates for the analog coil driver electronics frequency response) for UIM / L1 stage has its last set of filters which compensated for the last stage of z:p = 10.5:1 [Hz] low pass were errantly OFF. Thinking that this might be the source of the frequency dependent descrepancy I've been whinning about for the past week in the measured UIM actuation strength (identified in LHO aLOGs 21015 and 21049), I made sure to conlog back to the state of the BIO request and filter banks during those measurements. Yup -- these compensation filters were OFF then too. BUT -- IT DOESN'T MATTER. (1) If there were a low-pass ON without an appropriate compensation filter, then we would see a *reduction* from 1/f^6 drive strength in the measurement starting at 1 [Hz]. We see an *increase* measured drive strength from 1/f^6 starting at ~50 [Hz]. (2) *If* there was a low-pass ON we would see a reduction in actuation strength. However, in State 1, there are NO low-pass filters ON (see T1100507 -- note that this document has NOT been updated to reflect the chage in zero frequency of the output impedance network). Further, because of the simLP3 / antiLP3 perfect compensation, which is what *would* be on if there were no bug, then there is no difference betweeen having both ON and both OFF. That means as long as the antiAcq filter was ON, and it was, then the driver response is compensated for correctly. We're in full lock so I can't further confirm this bug, but we should. Why hasn't the SDF caught this? Because the user requested H1:SUS-ETMY_BIO_*_STATEREQ is supposed to control these filter banks, so we've chosen to not monitor them in the SDF system. Perhaps we should change that decision. Or perhaps we should just fix the bug.
I have checked all front end code (model source, filter modules, safe.snap and guardian) which had local mods into svn. h1susitmy had a partial filter load; after verifying the filter changes had all been individually loaded, I performed a full load when the IFO was in commissioning.
To study the variation over time of the jitter peaks in the sensitivity, I computed the band-limited RMS of CAL-DELTAL_EXTERNAL between 300 and 400 Hz, for all the reasonably long lock stretches of the last three weeks. The attached plot shows the result: blue dots are the values over one second periods, while the orange traces are smoothed version over 10 minutes.
I was hoping to see some variation or trend during each lock, but apparently the amplitude of the peaks are quite constant, and it doesn't change much over each single lock. There are few exceptions: a couple of locks show very low values, but looking at them in more detail it looks like the entire sentivity was scled down, so I'm not sure if they are meaningful. Moreover, there are a couple of cases where the amplitude of the peaks suddendly decrease or increase, for example around GPS 1124092417 (Aug 20 2015 07:50 UTC) and 1124863017 (Aug 29 2015 05:55 UTC).
9/3 DAY Shift: 15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC
Locked @Nominal_Low_Noise for ~12hrs with a range ~65Mpc. Kept H1 in Observation Mode as much as possible (there were a few errant drops & then we stayed down for PEM Injections starting at around noon (PST). I went through the Operator Checklist & completed most of it. I am supposed to check the Visitor Checklist, and it looks fine. I hesitated to check the HEPI watchdog saturation counter, for fear it might add diffs to the SDF (might try it tomorrow).
Remember:
End of shift Control Room Activities:
Log of Activities:
DCS restarted the diff of the H1 science frames written by the two framewriters: Sep 03 2015 15:29:47 PDT
J. Kissel I got sick of trying to debug the high-frequency affects UIM driver (LHO aLOG 21142), so I've moved on to the more important ESD Driver for H1 SUS ETMY. Instead of fitting the results of the remote measurements of the driver with the monitor circuit (LHO aLOG 20846), I've gone back to the measurements originally taken just after the LVLN driver was installed (LHO aLOG 18579), and fit them more precisely than Evan used to inform the current compensation filter (LHO aLOG 18596). Below are the details. The messages: - Each of the quadrants are *differently* frequency dependent at the ~5% level ~ 5 [deg] level; since we desire higher precision than this, they cannot be modeled with the same set of poles and zeros for each quadrant. - In order to model this correctly, will have to - break out the quadrants in the actuation chain model, - de-compensate for the installed compensation filter, - use the fit poles and zeros from each quadrant, and - then sum the quadrants together (and divide by four as necessary) -------------- The answer: Here're the precise poles and zeros for each quadrant: Diff Receiver Summing Node LP1 LP2 Overall DC Gain Summary (one pole, [Hz]) (z:p) [Hz] (z:p) [Hz] (z:p) [Hz] [V/V] z [Hz]: p [Hz]: k [V/V] UL 24e3 3200:165 48.8:2.160 48.8:2.160 1.8868 (48.8 48.8 3200) : (2.16 2.16 165 24e3) : 1.8868 LL 23e3 3050:160 47.8:2.105 47.8:2.105 1.8868 (47.8 47.8 3050) : (2.105 2.105 160 23e3) : 1.8868 UR 24e3 3050:157 48.8:2.160 48.8:2.160 1.8868 (48.8 48.8 3050) : (2.16 2.16 157 24e3) : 1.8868 LR 24e3 3125:160 47.8:2.130 47.8:2.130 1.8868 (47.8 47.8 3125) : (2.13 2.13 160 23e3) : 1.8868 These poles and zeros result in a frequency dependent residal, which represents a systematic error in the fit. This systematic error is smaller that 1% and 1 [deg] over the entire frequency band for all quadrants (save for where we know the measurement is incoherent noise at ~30 and ~100 [Hz]). Rather than bothering to carry around the precise systematic error and figuring out how to propagate it correctly through the uncertainty analysis, we shall just represent this as this a statistical, 1-sigma, uncertainty of 1% and 1 [deg]. We used to call this being "conservative," but really it's a "perfect is the enemy of good enough" decision. Open the attachment for plots demonstrating the goodness of fit (pg 1) and comparison of each quadrant against the fit and other models (pg 2-5), and a comparison of the models when the LP filter is OFF (pg 6). The fitting process: There are four models that I show: "Spice", "Simple Circuit", "(Compensation Filter)^-1", and PZ fit. "Spice:" Rich had graciously provided us with a spice model of the entire driver with both the low-pass off and engaged: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/Spice/ LVLN_Driver_v8_PZ_Off.txt LVLN_Driver_v8_PZ_On.txt "Simple Circuit:" For my edification, to determine what parts of the box were determining which parts of the frequency response, I also did some simple analytical analysis of the driver accounting for all of the parts of the driver that contribute to the frequency response. "(Compensation Filter)^-1" These are the poles and zeroes currently used in the ESDOUTF bank, under the "antiAcq" and "antiLP" filters, a "good enough" compensation developed by Evan back when the driver was first installed. I had started off hoping, like we always hope, that one can compensate each quadrant of the ESD driver with the same set of poles and zeros, based on those pole and zero frequency derived from some simple RC analysis of circuit. Turns out this is not the case. The frequency-depednent residual between the Spice, Simple Circuit, and (Compensation Filter)^-1 models and each quadrants' measurement for the following models is upwards of 10% and 5 [deg], different for each quadrant. A such, I created the PZfit model, where each quadrant's residual is tuned to as small as possible using the same number of poles and zeros as in the simple circuit model. That results in the poles and zeros quoted above. --------- Analysis script lives here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/Electronics/model_LVLN_driver_20150902.m
(Peter Shawhan, Eric Thrane, Corey Gray) Using waveforms created by Chris Pankow, we have set up a schedule of burst hardware injections to occur once every 10000 seconds (~2.7 hours). The schedule runs from now through the end of ER8, but we intend to turn them off once we've obtained 10 coherent (successful at both sites) burst injections. This series is primarily intended to check the infrastructure, the low-latency analysis, and the EM follow-up alert generation machinery; we're not yet attempting to verify the calibration. The injections are all scheduled for GPS times 1000*n+500, i.e. the first one should happen at GPS 1125350500, the next one at 1125360500, etc. However, an injection will be automatically skipped if ANY of the following conditions is true: * The detector is not locked (L1:GRD-ISC_LOCK_OK==0) * We are not in Observing mode (L1:ODC-MASTER_CHANNEL_LATCH bit 0 is off) * There has been a GRB or SNEWS alert within the past hour (L1:CAL-INJ_EXTTRIG_ALERT_TIME is a GPS time less than an hour before the current time) * Injections are currently disabled by the operator (the Disable button on the TINJ / Transient Injection Control medm screen has been clicked, which sets L1:CAL-INJ_TINJ_ENABLE = 0) * Injections have been temporarily paused by the operator using the Pause button on the TINJ / Transient Injection Control medm screen (which sets L1:CAL-INJ_TINJ_PAUSE to a future GPS time when the pausing should end) So, it's anybody's guess how long it will take to obtain 10 coherent burst injections. To get this started at LHO, we needed to start the 'run_tinj' process on h1hwinj1, which hasn't been running since August 25. I talked with Corey, who asked that we not do any hardware (strain) injections right now because the PEM injection folks were about to start doing tests. However, we worked out that the injections can be disabled for now using the Disable button on the TINJ Control medm screen. LHO had an old version of the screen, but Dave updated it to the latest version which has the Disable button (along with Enable and Pause). Corey clicked Disable, and I double-checked that it's disabled by doing 'ezcaread H1:CAL-INJ_TINJ_ENABLE'. I then did "nohup run_tinj &" at about 12:44 PDT. So tinj is running now, but injections will be skipped until an operator clicks the Enable button on the TINJ Control medm screen. Please do that when the PEM injection folks have finished their work - thanks! There was one side effect that I didn't expect: when Corey clicked the Disable button, it took the detector out of observation mode. Corey said that looks like it was done by sdf, i.e. this status (injections disabled) is being considered nonstandard. I'm not sure if that is due to checking the value of L1:CAL-INJ_TINJ_ENABLE, or to some read-back bitmask value. We should follow up with Jamie to find out, and take the injection enable/disable out of the configuration check if possible. However, this isn't a problem right now because the PEM injection folks wanted to be out of observation mode anyway.
Vern told me that if it's sdf, I should contact Dave B and either he or Betsy should be able to look into it. So I emailed Dave.
I have modified h1calcs SDF to not monitor the operator hwinj enable/disable PV H1:CAL-INJ_TINJ_ENABLE. safe.snap checked into SVN r11560.
J. Kissel, D. Barker I had to look didn't I. Anamaria asked me what channel represents the IMC VCO frequency. The answer is H1:IMC-VCO_FREQUENCY, which is a Beckhoff-renamed version of the signal from the timing comparator, H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_5. However, to find this infomration out, I knew that the VCO frequencies are generated from the corner station timing comparator, so I opened up the timing screen. I found two things: (1) The Timing MASTER's status light was red. Dave informs me that this is because of the recent tests of the 9 and 45 MHz oscillators in the EE shop. They had stolen a sync signal from port 7 of the MASTER via fiber into the EE shop. This has since been disconnected, which made the monitor of the status channel H1:SYS-TIMING_C_MA_A_PORT_7_ERROR_FLAG go red. We've hit the monitor button, H1:SYS-TIMING_C_MA_A_PORT_7_ACTIVE and the status light has gone green. (2) In the corner A fanout, even though it's unrelated to the IMC VCO frequency, we noticed that whatever 5 MHz frequency is being measured on port 11, H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_ISIRIGB is blinking in and out. The last attechment shows the past hour, showing that this has been intermittently blinking in and out for long time. Screenshots of the timing screens also explain what we saw. ------------- For the record, all of this was done in "observation mode." Granted, all I did was turn on and off monitors, but I don't think we should go into observation mode if the timing master status light is red... I assume this is because Beckhoff as a whole has not been folded into the settings monitoring.
We don't really read back a 5 MHz signal. Unfortunately, unconnected frequency inputs sometimes flicker when their neighboring channels are beeing used. There should be 3 VCO frequencies as well as the main modulation frequency. There is no 40.6MHz channel neither. All RF sources have their own internal readback.
|
Injection |
Time of first injection, UTC |
Injection spacing |
Total number of injections |
Good channels for environmental signal |
|
|
Sept. 2 |
|
|
|
|
Truck braking by EY station parking area |
22:56:00 |
5s |
6 |
EY seismometers |
|
|
Sept. 3 |
|
|
|
|
OSB shipping roll up door actuation |
2:46:00 2:47:00 |
5s 5s |
6 6 |
vertex seismometer and/or output optics mic |
|
Loud Bach in control room (2s bursts of music) |
2:52:00 |
5s |
12 |
input optics mic |
|
Loud Underworld in control room (bass heavy) |
2:55:00 |
5s |
12 |
input optics mic |
|
Single bounces on exercise/seating ball in control room |
2:57:00 |
5s |
12 |
HAM2 seismometer, vertex seismometer |
|
Dropping large super ball from about 5 feet onto control room floor |
2:59:00 |
5s |
12 |
H1:PEM-CS_ACC_LVEAFLOOR_HAM1_Z
|
|
5 people jumping in synch in control room |
3:01:00 |
5s |
12 |
HAM2 seismometer, vertex seismometer |
I've attached the result.
Quick conclusion: Dropping large super ball and people jumping in control room coupled into DARM.
In case people wonder what's the super ball looks like, I've attached a photo as well.
No more super ball during observing run =(
After making a few "OBSERVE.snap" files for a few SDF nodes during the DAY shift, I tried taking the nodes back to their "safe.snap" files, but some of the nodes ended up having differences! Since we need to have ZERO differences to allow going to OBSERVATION Mode, I did what I could to make the differences as close to a "safe" state as possible. For the "safe" files which had differences, I looked used whatever .snap file which got us as close to GREEN as possible.
Here are the Nodes I worked on, the .snap file they are currently running, and a note about differences observed:
1. SUS-ITMX: safe & GOOD!——> but now has nutsinee differences!
2. SUS-ITMY: safe & GOOD!
3. SUS-ETMX *: safe_150902_124725 & (1) Diff: H1:SUS-ETMX_L2_DAMP_MODE1_GAIN ???, set point 0 & currently 50—>violin 1004.54Hz
4. ISI-ITMy: safe_150902_124924 & GOOD!
5. SUS-ETMY: safe_150902_151039 & GOOD!
6. HPIITMY **: safe_150810_115155 & (1) Diff (H1:HPI-ITMY_OUTF_H2_TRAMP?? , set point 60 & currently 5)—accept
7. ISIBS: safe_150902_151938 & GOOD!
8. HPIBS: safe & GOOD!
* The SUS-ETMx difference was a gain change Nutsinee made. She returned the gain to 0.
** The HPIITMY difference was a Time Ramp, so I ACCEPTED.
Dan found that one of the modes was rung up and switched the gain for ITMX L2 DAMP MODE1,7,8,9,10 back to 0. The changes can be accepted.
To damp ALL 8 frequencies of the ITMX first harmonics.
MODE1 damps 996.53
MODE7 damps 995.36
MODE8 damps 995.64
MODE9 damps 992.43, 992.79, 994.28, and 994.73
MODE10 damps 996.25
MODE1, 7, 8, 10 MUST stay on if MODE9 is on.
The damp settings have been added to the table.
997.7169 Hz and 998.6645 Hz identified.
Tonight while collecting OMC modescan data at high power (with DARM on AS45), we found that one of the ITMx modes was ringing up with these new damping filters. The frequency was 995.645 Hz. We were able to construct a narrowband filter for this mode (FM5 on ITMX Mode8) and damp it easily, with positive gain and no phase shift. Since we weren't sure which of the new filters rang up the mode, we zeroed all of the gains (for filter banks mode1, 7,8,9, and 10) and also commented them out of the guardian. We'll have to work out later today which filter was providing the signal that was 180deg out of phase.
MODE9 damps four frequencies with 180 deg but will ring up the other four which have 0deg. I contructed individual filters for them and 995.6447 was one of them. However, I only set MODE9 gain to 40 while the others have gains of 100 hoping that they will be damped faster than being rung up by MODE9. Not sure what's wrong but if anything gonna ring up 995.647 it's the MODE9 filter.
How high did it get rung up? I watched it for hours before letting Guardian turned it on but didn't see anything then.
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.
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
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
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
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:
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.
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:
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
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:
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
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?
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.
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
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).
J. Kissel, K. Izumi We've completed another round of the suite of actuation coefficient coefficient measurements today, very similar to what was done on Wednesday (see LHO aLOG 20940) with the same templates. There were some differences between the two days worth of measurements -- we don't expect these to have made a difference, but we've been living 1% accuracy and precision land for a week with no sleep, so we write them down anyways. They are: - We managed to get all of the full IFO transfer function measurements within the same lock stretch, unlike Wednesday. - We did Full IFO config measurements, ALS DIFF measurements, then Free-Swinging MICH (FSM) measurements, as opposed to Wednesday when we did DIFF, then Full, then FSM. - Because we got distracted with full-frequency range DARM OLG and PCAL to DARM TFs, and there were some problems with DIFF saturating, there were about ~4 hours between when the ETMX TF was taken in full lock and when it was taken in ALS DIFF. - On Wednesday, we ran ALS DIFF with ALS COMM OFF. Today we ran ALS DIFF with ALS COMM ON. - We missed a MICH OLG TF for the FSM. We may try to get away with checking if the power and PD normalization levels are the same -- if they are we may just use Wednesday's data. Otherwise it means we have to scrap all of today's FSM data. A "When will you have a number?" update: we are heavy into analyzing both of the data sets (ALS DIFF is done with the help of LHO aLOG 21001, tomorrow will be PCAL and FSM). A goal is to have a comparison between methods by Sunday. For a sneak peak on the analysis scripts for ALS DIFF (in case LLO wants to use them), check out /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/ALSDiff analyze_alsdiff_data_20150826.m analyze_alsdiff_data_20150828.m #NoSleepTilO1 The DTT files live here: (2) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/ 2015-08-28_H1SUSETMY_PCALYtoDARM_FullLock.xml (5) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/ALSDIFF/2015-08-28/ 2015-08-28_ALSDiff_ETMX_L3_HVHN.xml (6) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/ 2015-08-26_H1MICH_freeswingingdata.xml (7) Does not Exist (8) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/ 2015-08-28_H1SUSITMX_L2_State2_MICH.xml (9) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/ 2015-08-28_H1SUSITMX_L2_State2_XARM.xml (10) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FreeSwingMich/2015-08-28/ 2015-08-28_H1SUSETMX_L3_HVHN_XARM.xml (X) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/ 2015-08-28_H1SUSETMY_L3toDARM_LVLN_LPON_FullLock.xml (Y) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/ 2015-08-28_H1SUSETMY_L1toDARM_FullLock.xml 2015-08-28_H1SUSETMY_L2toDARM_FullLock.xml (Z) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-28/ 2015-08-28_H1SUSETMX_toDARM_FullLock.xml Wish us luck on tomorrow's measurement suite; hopefully it'll be the last time for while!
Just for booking purpose.
In addition to the measurements that Jeff posted, I have done a Pcal Y sweep and DARM open loop measurements in a frequency band of [7 800] Hz using Darkhan's template. The data can be found at:
aligocalibration/trunk/Runs/ER8/H1/Measurements/PCAL/2015-08-28_PCALY2DARMTF_7to800Hz.xml
aligocalibration/trunk/Runs/ER8/H1/Measurements/DARMOLGTFs/2015-08-28_H1_DARM_OLGTF_7to800Hz.xml
[TJ, Jenne]
TJ pointed out to me that the Cal Hardware Injection ODC bit is red, and I tracked down where it's coming from. The ODC is upset that the CAL-INJ_HARDWARE limiter was turned off. I don't think that this has been preventing us from going to Observing mode, since the limiter was turned off on Thursday, but if it does (particularly if some updates have been made during maintenence day that tie this bit into our "OK" status) I will turn the limiter back on until the ODC can be updated to know that the limit switch should be off.
I have sent EricT an email asking for him to help figure out the ODC part of this.
Just to be clear, there should be NO ODC CHECKS INVOLVED in the IFO READY bit. ODC is only used as transport of the bits, and none of the checks being done by ODC affect IFO READY. The only thing that should be going in to IFO READY now is the GRD IFO top node. In other words, this ODC issue should not have been preventing you from going to Observing mode.
Note, when the EXC bit in the CALCS CDS overview is in alarm, we tend to open the screen CAL_INJ_CONTROL to attempt to diagnose - This shows a big red light for some ODC Channel OK Latch, leading us to misdiagnose what is actually in alarm. We have 2 operational problems:
1) If generically, there is a red light on the CDS screen - where do you go? Normally, we follow the logical medm and are able to get to the bottom of the red status via logical nested reds. This is not the case for the CALCS screen - the CDS H1:FEC-117_STATE_WORD bit is RED on the H1CALCS line of the overview screen, yet this bit is nowhere on the CALCS screen.
So, where does the info come from for specifically the EXC bit of the H1CALCS state word, such that we can do something about it?
2) Someone should rework the CAL_INJ_CONTROL.adl so that it doesn't cause us to misdiagnose actual reds. Currently, the HARDWARE INJECTIONS are out of configuration (outstanding issue to still be sorted) and yet, there is NO INDICATION of that on the CAL_INJ_CONTROL screen... Also, the CW injection appears to be off, but there is no "red alarm" on the screen.
BTW, the HARDWARE INJ appear to be off. They dropped around 7pm local time last night (20 hours ago).