I calculated the time varying calibration parameters kappa_tst, kappa_pu, kappa_A, kappa_C and Cavity pole for the lock stretch beginning from September 1st using the new ER8 DARM model. All the data used for this analysis had guardian state vector greater than 600 (NOMINAL LOW NOISE). The plots are attached.

Details:

The equation used in this calculation are obtained from the T1500377 document which describes the time varying parameters in details.

For the displacement produced due to pcal, I used the following script to advance the pcal signal by 21 us (LHO alog 21320) , take out the AA filter and and dewhitened the signal.

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/S7/Common/MatlabTools/xpcalcorrectionER8.m.

I was not able to get kappa_tst closer to 1, which is the expected value of the all kappa's. However, the variation in Kappa_tst is within 1%  which is a good news. I am not sure where the problem is. I will look into it further. For the rest of the plots I assumed kappa_tst to be 1. This assumption only effects kappa_pu because it is the only factor that depends on kappa_tst.

Plots:

The first plot shows the real part of kappa_tst, kappa_pu and kappa_A. Kappa_pu and kappa_A are close to 1 and the variation of these parameters during this time is less than a 1%. kappa_tst under investigation.

The second plot is the imaginary part of the parameters in plot 1. All these values are expected to be 0 or closer to zero. Again, kappa-pu and kappa_A are indeed very close to zero but kappa_tst is not.

The third plot includes kappa_C (change in optical gain) and cavity pole.  Optical gain within a lock stretch seems to be very stable but it varies by few percent between locks. One particular stretch it varied by almost 20% (not sure why, could be commissioning activities). Also, there is evident of some transient at the beginning and end of the locks. Will try to sort the data by intent bit for future analysis.  The cavity pole shows some trend and variation between lock stretches but nothing crazy.

The script used to analyze this is committed to the svn:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Projects/PhotonCalibrator/drafts_tests/ER8_Data_Analysis/Scripts/plotCalparameterFromSLMData.m

Jeffrey K, Kiwamu I, Darkhan T

Summary

We implemented most of the analysis results from recent calibration measurements into the H1 DARM OLGTF model for ER8/O1 (see details below). Sensing, actuation and the digital filters' TF models that make up a DARM OLG TF model are used for calculating the interferometer strain h(t), tracking and possibly correcting temporal variations in the DARM parameters.

The comparison of the H1 DARM OLGTF model vs. a DARM OLGTF measurement taken on 2015-08-30 07:19:40 UTC gave a residual of about +/- 3% in magnitude and +/- 10 degrees in phase [~30, ~500] Hz.

The measurements of a DARM OLGTF and a PCALY to DARMTF that we used for estimating the parameters of the model were taken within the same lock stretch (LHO alog 21023). The sensing function obtained from combining both of these TF measurements gave a residual of under +/- 4% in magnitude and under +/- 8 degrees in phase when compared to the DARM OLGTF model in the frequency range of [~20, ~1100] Hz. We see an unresolved trend in the phase of the sensing function residual.

Details

This model is based on the earlier version of this script, that has been described in LHO alog 20819, however earlier model agreed with the DARM OLGTF measurements to a lesser degree: about +/-10% in magnitude and +/-5 degree in phase up to 200 Hz.

Below we list major improvements / changes to the DARM OLGTF model that were implemented since then (if one needs to track changes all the way from ER7 model, he/she can check LHO alog 20819 for the list of prevous changes).

• DC drive levels [N/ct] for each of the suspension stages are now calculated from a set of calibrated factors.
  • For UIM and PUM drivers the following factors were given in the parameter file: V_dac / dac_ct, V_ai / A_coil, N_sus / A_coil and an euler matrix factor;
  • For ESD driver the following factors were given: V_dac / dac_ct, alpha_NpV^2, low and high voltage gain (slope), esdBiasSign, an euler matrix factor.

• Now model supports correction for imperfect compensation of frequency dependencies of ESD and coil driver in the driver output filters.

Calibration team at LHO managed to take large number of measurements that were used for estimation of parameters of the actuation function, see LHO alogs 20846, 21023. Over the last two weeks calibration team analyzed these measurements (see LHO alogs 21015, 21142, 21189, 21232, 21283). As a result we adapted the DARM OLGTF model to be able to handle a set of zero-pole TFs that differ for each of the quadrants of the drivers. Implementing these helped to significantly reduce the residual between the model and the measurement.

• Kiwamu worked on analyzing DARM OLGTF and PCAL to DARM TF measurements to estimate parameters of the sensing function (see LHO alog 21023). By LISO fitting he found that the coupled-cavity pole frequency of the interferometer is around 330 Hz.

• OMC DCPD signal chain analysis showed that a zero-pole set of DCPD signal chain fitted to a measurement differ from the set used in the DARM model for ER7 (see LHO alog 21126). These additional poles were added into parameter files of the ER8 DARMOLGTF measurements.

We are planning to work more on looking for sources of inaccuracies of the DARM OLGTF model.

The development is underway on separating OMC DCPD frequency dependencies for two of the DCPDs. In the existing DARM OLGTF model it's assumed that both of the DCPDs have the same zeros and poles, which, according to LHO alog 21126, is not entirely true, and could potentially introduce systematic errors.

The model was uploaded to calibration SVN:

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER8.m (r1341)

The parameter file associated with the measurement from Aug 30 2015 07:19:40 UTC (GPS: 1124954397) is in the same directory:

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMparams_1124954397.m (r1339)

Plots produced by this model were committed to SVN into:

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Results/DARMOLGTFs/2015-09-08_H1DARM_*.pdf

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Results/DARMOLGTFs/2015-09-08_H1DARM_*.eps

Kiwamu, Hang, Nutsinee

After we made some modification to the new lockloss tool (the modification was made on my copy, not the original), we started to investigate the time of ETMY saturations with it. I randomly picked seven glitches out of twenty listed by the saturation alarm. Three glitches caused the range to drop no more than 50 Mpc, four caused the range to drop below 10 Mpc.

Range dropped below 10 Mpc

Range dropped no more than 50 Mpc

Most of the chosen glitches look pretty much the same (low frequency fluctuation, glitch, then ring down) and don't tell us anything, accept that all three small glitches happened within 30 mininutes after an earthquake. However, I find the plots from Sep 6 17:03:24 particularly interesting. PR3 M3 glitched ~3 seconds before ETMY. Kiwamu thought this might shade some light on the mysterious ETMY glitches.

One thing I noticed is that quite many times the ETMY saturations happened at least half a second before the saturation alarm caught them. Why is that?

As for the plots, the blue is the data of channel indicated, red shaded area is the RMS, and the low, mid, high band are defined as:
low: f>0.25 Hz
mid: 16 Hz < f < 128 Hz
high: f>128 Hz (until Nyquist frequency)

I have also attached the list of channels I've looked into (basically all ST1 and ST2 ISI and all the SUS MASTER OUT DQ channels). There are SO MANY MORE glitches to be analyzed. In case anyone interested in helping I saved the modified code in /ligo/home/nutsinee.kijbunchoo/Templates/locklosses/python

Evening Shift Summary
LVEA: Laser Hazard
IFO: UnLocked
Intent Bit: Commissioning  

All Times in UTC (PT)

23:00 (16:00) Take over from TJ
23:00 (16:00) Continue locking the IFO after maintenance window
02:01 (19:01) IFO locked at NOMINAL_LOW_NOISE, 22.9W, 65Mpc
02:06 (19:06) Set Observatory Mode to commissioning
02:56 (19:56) Add 125ml water to crystal chiller
05:31 (22:31) Switch to Calibration mode for Kiwamu
06:43 (23:43) Switch to Observation mode 
07:00 (00:00) Turn over to Travis


 Shift Summary & Observations:

- Commissioners/Ops working on relocking IFO until about 02:00.
- Set to commissioning mode – Commissioners working while LLO is down
- Set to Observation mode 06:43 – Wind low, range @ 67Mpc
- First half of the shift was spent recovering from maintenance and some commissioning work. After locking, commissioners continued to work on IFO. We have been locked since 02:00. Some glitches mostly due to commissioning/calibration work. 
- After clearing SDF, switched to Observing mode at 06:43 (23:43). 
   NOTE: The LVEA was not swept before going into Observing mode. The decision was not to risk knocking the IOF out of lock by walking around in the LVEA. The lights are on. Do not know what other noise sources are present at this time.        

J. Kissel, K. Izumi

We haven't gotten these two measurements since the tail end of Calibration week, and we want to confirm that our model (that's under development) is still valid after 1.5 weeks, so we've taken new DARM OLG TFs and PCAL to DARM TFs. We'll analyze these in the next few days and confirm what we can determine from the calibration lines.

Data lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/
DARMOLGTFs/2015-09-08_H1_DARM_OLGTF_7to1200Hz.xml
PCAL/2015-09-08_PCALY2DARMTF_7to1200Hz.xml

For the record, this pair of measurements takes almost exactly 1 hour. However, to knock down the measurement time to that one hour, one needs to run the DARMOLGTF first, and start the PCAL TF once the DARM OLG TF hits the frequency points around 15 to 10 [Hz]. 

Note, calibration lines were turned OFF during these measurements. They're now back ON.

J. Kissel

I haven't analyzed the data yet, but in order to put a nail on the coffin of the UIM actuation model-to-measurement descrepancy, and to nail down the output impedance network, I've measured the transfer function of the H1 SUS ETMY's UIM driver today in analog with an SR785. Driving at the DAC input of the coil driver, and measuring the response across the output pins of the driver on a break out -- noteably including the the real BOSEM, not just using a 40 [ohm] resistor as a dummy OSEM. This was done in each state of the driver for all four channels. 

From what I saw on the screen while the measurements were on going, there is indeed a zero in the transfer function at around 100 [Hz]. Have a little bit of low-frequency-measurement-time to think about it, I think this is the non-neglible inductance of the giant BOSEM coil (Rc = 42.7 [Ohm], Lc = 11.9 [mH]). Will confirm and give more details one the analysis is complete.

This is not a priority, so I'll analyze the data in due time, but the data lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/Electronics/2015-09-08_H1SUSETMY_UIM_Driver/TFSR785_08-09-2015_*.txt
with a diary of which measurements are which here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/Electronics/2015-09-08_H1SUSETMY_UIM_Driver/MeasurementDiary_20150908.txt
(and attached for your convenience)

The config file for the usual GPIB function is here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/Electronics/2015-09-08_H1SUSETMY_UIM_Driver/TFSR785_UIMCoilDriver_Config.yml

- Took over from TJ at 23:00 (16:00). Commissioners/Ops working on relocking IFO until 02:00 (19:00).
- Set Obs Mode to commissioning – Commissioners working while LLO is down.
- After some initial locking problems, the IFO has been stable locked at 22.9W with approximately 65Mpc. The shift is running smoothly. 
- I added 125ml water the crystal chiller. 

I've been investigating the range drops associated with loud (SNR > 1000) glitches.

During ER7, these were thought to be due to particles falling through the beam (see alogs on "dust glitches" 20276, 20354, 20355, 20328, 20395, 20484).

In ER8, we are still seeing loud glitches associated with range drops, however now there are also saturations on SUS ETMY (see alogs 19939, 19947, 20071, 20612, and almost every Ops summary since August 17).

Every Omicron trigger with SNR > 1000 (and most of those with SNR 100 – 1000 as well) is simultaneous with a range drop and an ETMY saturation during the 92 hours from September 3 - 6.

By contrast, none of the SNR > 1000 triggers from June 9 - 11 are associated with ETMY saturations.

On the other hand, OmegaScans and timeseries plots of the ER7 and ER8 glitches look similar, suggesting that all the glitches may be related.

So, if there are two distinct glitch classes, the "dust glitches" appear to have stopped occurring.

Or, if all the glitches have the same cause, then something seems to have changed to make ETMY more sensitive to them.

Has anything in the control system changed in a way that could lead to larger signals appearing on the ETMs for the same ‘glitch stimulus’?

See plots attached, and PreO1WorstGlitches page for more details.

Restarted DCS Disk2Disk and diffFrames which copies data from CDS to LDAS and checks for diffs between the science frames from the two framewriters. The restart was between 16:28 PDT and 17:19 PDT today (08 Sept. 2015). This was to fix a minor bug found in these scripts where they did not close a file used internally by the scripts to check its own run status. This change should have no impact on CDS.

I added 'H1:OMC-READOUT_ERR_GAIN' to the exclude list, since it sometimes generates 'nan' values and stops Conlog. I then regenerated the channel list and set Conlog to use it.

+ H1:OMC-FPGA_DTONE_GAIN
+ H1:OMC-FPGA_DTONE_LIMIT
+ H1:OMC-FPGA_DTONE_OFFSET
+ H1:OMC-FPGA_DTONE_RSET
+ H1:OMC-FPGA_DTONE_SW1S
+ H1:OMC-FPGA_DTONE_SW2S
+ H1:OMC-FPGA_DTONE_SWSTAT
+ H1:OMC-FPGA_DTONE_TRAMP
- H1:OMC-READOUT_ERR_GAIN
inserted 8 pv names
deleted 1 pv names

Collected OBSERVE.snap files for use in full observing configuration monitoring.

With the SDF happy (green) and Guardian Nominal (Robust Isolated) and green, I made an OBSERVE.snap file with SDF_SAVE screen

choosing EPICS DB TO FILE  & SAVE AS == OBSERVE

This saves the current values of all switches and maintains the monitor/not monitor bit into the target area, e.g.   /opt/rtcds/lho/h1/target/h1hpietmy/h1hpietmyepics/burt as OBSERVE.snap

This file is then copied to the svn: /opt/rtcds/userapps/release/hpi/h1/burtfiles as h1hpietmy_OBSERVE.snap and added/commited as needed.

The OBSERVE.snap in the target area is now deleted and a soft link is created for OBSERVE.snap to point to the svn copy:

ln -s /opt/rtcds/userapps/release/hpi/h1/burtfiles/h1hpietmy_OBSERVE.snap OBSERVE.snap

Finally, the SDF_RESTORE screen is used to select the OBSERVE.snap softlink and loaded with the LOAD TABLE button.

Now, for the HEPIs for example, the not monitored channels dealt with by the guardian will be a different value from the safe.snap but, the not monitored channels are still not monitored so the SDF remains green and happy.  And if the HEPI platform trips, it will still be happy and green because, the not monitored channels are still not monitored.

What's the use of all this you say?  Okay, I say, go to the SDF_TABLE screen and switch the MONITOR SELECT choice to ALL (vs MASK.)  Now, the not monitored channel bit flag is ignored and all records are monitored and differences (ISO filters when the platform is tripped for example) will show in the DIFF list until guardian has the platform back to nominal.

Notice too that the SDF_OVERVIEW has the pink light indicating monitor ALL is set.  This should stay this way unless Guardian is having trouble reisolating the platform and then the operator may want to reenable the bit mask to make more evident any switches that guardian isn't touching more apparent.

Tasks completed (Time in PST)

HAM1 Grouting (800-1220)

Crane TCS Chiller (-1220)

EX replace annulus ion pump (1012-1451)

Duotone Frame change (-1211)

CDS Frame Writers (831-1300)

UPS bypass repair (828-841)

PSL laser WD on Bechoff comuter (819-821)

PZT per LPF swap (1231-1321)

HWS alignment (1315-1409)

GDS channels added to DAQ (1300)

ETMX charge measurements (945-1033)

ETMY Coil Driver measurement (950-1150)

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).

We have large glitches when we switch the coil driver state for PRM in every example that I've looked at.  This causes locklosses, about 5 over the weekend.  

One thing that we can do to make this less painfull is to move the switch earlier in the locking process (for example, we can try doing this right after DRMI locks rather than waiting until DRMI on POP).  

A real solution might be to change the front end model so that we can switch each coil separately.   

We could try tuning the delay, as described for the LLO BS 16295

Kiwamu, Sheila, Evan

Durring the calibration activities last week Kiwamu noticed that there was upconversion of the drive from ETMY.  Specifically when he drove in the L3 LOCK filter, he saw a second harmonic. When he drove each stage individually, through the test filter bank with a similar amplitide he saw no evidence for upconversion.  This suggests that the upconversion might come about by driving mutliple stages, or through the length 2 angle paths. 

We went back through the data and looked at the relative heights of the peaks.  We also calculated a ratio of the amplitude of the second harmonic to the square of the amplitude at the fundamental :
  ASD(2f) = alpha * (ASD(1f))^2

If we ignore other frequencies which could mix and only consider the second harmonics of DARM control, we would expect this upconversion to be something like a factor of 10 below our measured noise at 20 Hz, and near the measured noise at 10 Hz.

The next step is probably to identify which stages contribute to this upconversion, for example it seems probable that this is only noticeable for frequencies where L2 get a significant fraction of the DARM control signal. 

While Jeff and Darkhan have been trying to get the actuactor coefficients right for calibration, I worked on an orthogonal task which is to check out the latest optical gain of DARM.

Summary points are:

• They don't look crazy.
• However the magnitude at low frequencies seems too low. This is something we have been consistently suffereing from.

The plots below show the measured optical gain measured by Pcal Y with the loop suppression taken out by measuring the DARM supression within the same lock stretch. 

I used the data from Aug 28 and 29th (alog 21190 and alog 21023 respectively). The parameters were estimated by the fitting function of LISO. I have limited the frequency range of the fitting to be avove 30 Hz because the measurement does not seem to obey physics. I will metion this in the next paragraph. The cavity pole was at around 330 Hz which claims a bit lower frequency than what Evan indendently estimated from the nominal Pcal lines (alog 21210). Not sure why at this point.

One thing we have to pay attentin is a peculiar behavior of the magnitude at low frequencies -- they tend to respond lesser by 20-30 % at most while the phase does not show any evidence of extra poles or zeros. I think that this behavior has been consistently seen since ER7. For example, several DARM open loops from ER7 show very similar behavior (see open loop plots from alog 18769). Also, a recent DARM open loop measurement (see the plot from alog 20819). Keita suggested makeing another DARM open loop measurement with a smaller amplitude, for example by a factor of two at a cost of longer integation time in order to detemine whethre if this is associated with some kind of undesired nonlinearity, saturation or some sort.

Due to a crazy big offset of -0.5 in Y_TR_B_PIT (for SOFT modes sensing), Y IR QPDB is almost always railing a bit in 24W operation, and Y IR QPDA is not too far.

Next time IFO drops out of lock, somebody needs to lower the whitening gain by 3dB and set a new dark offset for each quadrant.

C. Cahillane, D. Tuyenbayev I have updated the strain uncertainty calculator to use Darkhan's latest ER8 model along with ER8 data.

The ER8 model: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER8.m

The ER8 params: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/DARMOLGTFs/H1DARMparams_1124597103.m

The ER8 uncertainty calc: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/S7/Common/MatlabTools/strainUncertaintyER8.m

Again, there are slight discrepancies between Plot 1 and Plot 7. To reiterate, Plot 1 uses the full O1 calibration method and real data, while Plot 7 uses the Inverse Response TF with no data:

Plot 1:

dh = DARM_ERR / C_true + A_true * DARM_CTRL

     ------------------------------------

     DARM_ERR / C_0 + A_0 * DARM_CTRL

Plot 7:

dh = (1 + G_true) / C_true

     ----------------------

        (1 + G_0) / C_0

This time, I believe the discrepancies are a result of the as-of-yet incomplete ER8 model.  I will rerun this test when Kiwamu, Jeff, and Darkhan have all finished updating the ER8 model.

Note that the ugly spikes in uncertainty have disappeared from Plots 1-6 (as opposed to aLOG 21065). 

This is because now I do not have to interpolate my DARM_ERR and DARM_CTRL FFT frequency vector thanks to Darkhan's clever ER8 model functions par.{A,C,D,G}.getFreqResp_total(freq) where freq is a frequency vector I define.  This is possible because each portion of the ER8 model is an LTI object.  Thanks Darkhan.