2pm local
Showed Ed Merilh how to fill CP3 from control room so he can do this on Friday for vacuum group (thanks, Ed!). Someone in vacuum should let Ed do this on Wed. while observing for practice on Friday. He is writing a wiki link for instructions.
Took about 30 sec. to overfill CP3 at 50% open on LLCV.
Just so people have something to cite, this last lock stretch ending on Nov 21 2016 ~22:11 UTC was caused by the 6.9 [mag] earthquake in Japan. Calibration group was just finishing up post-front-end-update measurements, and PEM team was just about to start their work. Looks like we're out for a few hours though, neither of them were the cause of the lockloss.
We had another incident of the kind of scattering that was investigated in 30790 and comments, and in 31267
We see peaks in DARM that are probably upconversion of the 6.1Hz tip tilt resonaonces.
Over the weekend I had turned off the cut off of DC1Y, which actuates on both RMs. I rengaged this and the loops still seem stable, but it didn't have a repeateable impact on the noise.
I've noticed in the last couple of long locks that Mode 7 on ETMY slowly rings up. I mentioned it in log 31000, Cheryl did in 31657. With Jenne's ok, I've increased the gain in Violin_mode_2 to -24, from -20 in ISC_LOCK and loaded the new code. Cheryl went all the way to -60 in her log, so we clearly have some head room. I'll watch over the rest of my shift to see if this seems stable, but it's working well so far.
model restarts logged for Thu 17/Nov/2016 - Sun 20/Nov/2016 No restarts reported.
DAQ - stable (running 6 days). fw0 has with older version of frame-cpp (will be updated 11/22/2016). No critical problems reported.
All vacuum pumps are running within specified pressure and temperature ranges. Made a small adjustment to the End-Y vacuum pressure. Closed FAMIS #7507.
Jess McIver, Laura Nuttall
The full DQ shift can be found on the detchar wiki. Here are the highlights:
* Two long, in excess of a day, lock stretches with ranges around 70 Mpc
* Range drops could be beam alignment drift
* Whistles appeared in the two short lock stretches on Friday. Spotted using hveto which found a good coincidence with POP 9
* Ran bruco on a lock stretch where the 1083 Hz Cal line was turned off to see if there are any coherences around 1080Hz glitchy region. Nothing particularly obvious
Separate alogs will follow about more follow up during this shift
J. Kissel, K. Izumi, D. Tuyenbayev We were just about to use a new sweep I took (with data attached) to update the front-end portion of the low-latency calibration pipeline during the ~30 hour lock stretch, but we were rudely interrupted by a 6.4 [mag] EQ in Argentina. Thus we have not yet updated the calibration. We will resume tomorrow morning when we are on site and can get a before and after change set of measurements. Things on the plate to update: (1) DC actuation strength, based on results from frequency-dependent sweeps of each actuation stage and the long-duration, single frequency measurements taken in the first few weeks of ER10. We expect the TST and UIM stage to receive updates on the level of a few percent. We expect this will increase the BNS range a bit. (2) The frequency dependence of all stages of the actuator. This is to account for optical lever damping, and newly included UIM violin mode resonances. We do not expect this to affect the BNS range. (3) Small adjustments to the inverse sensing function to get updated values for the optical gain (will likely be ~3% higher). We expect this to decrease the BNS range a bit. (4) EPICs records that store the DARM loop model at calibration line frequencies to match the reference measurement times. Unfortunately, its only after we make these updates will we be able to trust any of the time-dependent tracking system. All this being said, the current sensing function sweep (retaken today) sweep shows that the PCAL is discrepant with DELTAL external by 5% (though this changes with time as the TST actuation strength, optical gain, SRC detuning, and cavity pole change). However, we think we can reduce this systematic offset by making the above updates. The strange thing, is that the fit RSE cavity pole and SRC detuned spring freq are statistically different than what has been measured to-date. I'm worried this has to do with Shiela's finalizing the alignment configuration to get back onto REFL WFS (see LHO aLOG 31653). [Units] value(95% c.i.) Meas Date 2016 Nov 20 IFO Input Power [W] 29.1 SRC1 Loop Status ON Optical Gain x 1e6 [ct/m] 1.15 (0.002) DARM/RSE Cav. Pole Freq. [Hz] 353.5(6.0) Detuned SRC Optical Spring Freq. [Hz] 7.02 (0.3) Optical Spring Q-Factor (1/Q) [] 0.04 (0.01) Residual Time Delay [us] 2.4 (5.4) aLOG this aLOG Details: CalSVN repo root: [~] = /ligo/svncommon/CalSVN/aligocalibration/ Data lives here: [~]/trunk/Runs/ER10/H1/Measurements/ DARMOLGTFs/2016-11-20_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml PCAL/2016-11-20_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml Analysis produced by running: [~]/trunk/Runs/ER10/H1/Scripts/PCAL/fitDataToC_20161116.m Revision: 3815 on each of the measurement config files listed below. Model Config Files: [~]/trunk/Runs/ER10/Common/params/IFOindepParams.conf Revision: 3776 [~]/trunk/Runs/ER10/H1/params/H1params.conf Revision: 3811 [~]/trunk/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf Revision: 3800 Measurement Config Files: [~]/trunk/Runs/ER10/H1/params/2016-11-20/measurements_2016-11-20_sensing.conf Revision: 3821
WeeklyXtal - explanation of what's going on with HPO diode powers is here. Amp diode powers are tracking with humidity, as they do.
WeeklyLaser - everything looks ok. BOXHUM shows decrease.
WeeklyEnv - everything looks ok. Temps and Humidity show decrease.
WeeklyChiller - there is a direct correlation between the Xtal Chiller flow and the OSC Press 1&2. OSC HEADFLOWS all show marginal decreases except for HEAD4 which is either very stable or has a faulty readback?
Head 4 was part of the group of faulty flow sensors (FE flow, PowerMeter flow, and Head 4) that were causing our interlock trips. These were bypassed in the Beckhoff software (alogged by Peter here); the variables were forced so the readback from the sensors is being ignored. Due to time constraints between commissioning, readiness for ER10 and now transistioning to O2, these bypasses are being left in place until after O2. We still have active flow sensors to give us protection in the case of a real flow fault.
Everything else looks as expected.
Laser Status:
SysStat is good
Front End power is 34.539993463W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is GREEN
PMC:
It has been locked 4.0 days, 13.0 hr 15.0 minutes (should be days/weeks)
Reflected power is 12.7175809387 Watts and PowerSum = 74.0388560218 Watts.
FSS:
It has been locked for 0.0 days 8.0 h and 2.0 min (should be days/weeks)
TPD[V] = 3.54349908377V (min 0.9V)
ISS:
The diffracted power is around 5.1059646249% (should be 5-9%)
Last saturation event was 0.0 days 8.0 hours and 1.0 minutes ago (should be days/weeks)
Possible Issues:
(Be sure to look into these, as they will not be printed in the report)
PMC reflected power is high
On Thursday we (Sheila, Daniel & I) increased the Thresholds on the TIDAL RED TRIGGER when the very low value kept the ISC driving the HEPI too long. It would appear there was only one long lock stretch with these settings before Sheila reported that the tidal was not coming on, in some locks. Beam diverters?... When Nutsinee reverted the values of the RED TRIGGER Thresholds, things seemed to start working properly again. I don't pretend to understand this and it is pretty clear that reverting the values solved the problem. See attached four days trend, when lowering the THRESH_ON value started the TIDAL running (I did not zoom in but it looks correlated.) But also seen is the REDTRIG_INMON has dropped to 153000 from the previous 165000. If this level (Power?) change was enough to disable the 8000 count THRESH_ON setting, clearly something else must be in play. I need to understand the triggering better to really understand this. We don't want the ISI to trip as it can be several minutes for the T240s to settle and be ready for complete ISI isolation but obviously we need the TIDAL relief to engage.
It might be that the threshold wasn't exceeded, when it tried to engage REDLOCK. The fundamental problem is that neither the arm power nor the trigger thresholds are getting scaled with the power up, so the threshold needs to be set low enough to catch the lock at low power. Once you power up, the arm powers will then be far above threshold. Too much it seems. Probably best to figure out how to scale the NSUM value with the inverse of the input power. Alternatively, one could rewrite the trigger so that it scales automatically.
Opened FRS Ticket 6787. This has happened a few more times this evening.
TITLE: 11/21 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: Jim
SHIFT SUMMARY: One lockloss during the shift. There was a small earthquake in CA showed up on the seismic FOM around the same time (read 0.1 um/s). This amplitude of earthquake doesn't usually break the lock so I wonder if something else might have caused it. Had no issue relocking.
LOG:
9:28 Out of Observe to run a2l
9:36 a2l done. Back to Observe.
09:42 Lockloss
10:16 Arrived at NLN. Took time to damp bounce modes and ran a2l.
10:31 Observe
13:07 Out of Observe to run a2l
13:12 Observe
15:13 Out of Observe, ran a2l
15:18 back to Observe.
Dust alarm and Vacuum alarm (CP4) continues to beep. If your system is using the alarm handler please make sure the threshold is set right and only make it beeps when things are critical. Otherwise operators are just going to keep ignoring these alarms, including the ones that might actually be critical.
Checked the alarm level settings for all site dust monitors, and all are set correctly. Dust monitor alarms should be investigated and documented in the aLOG. Use some common sense when aLOGing an event, e.g. if you know Karen is cleaning at End-? and the alarm goes off no need to log. All unknown alarms should be logged.
State of H1: locked in NLN, PR3 on POP WFS, in Observe
Commissioners: Kiwamu, Darkhan
Activities:
Maybe this is known, but I didn't find an alog showing this feature of ITMY.
Plot 1: ITMY
OSEMs LF and RT have a peak at 0.55Hz throughout the long lock yesterday, T0 = 11/19, 16:00UTC, 750 averages
The peak in the LF and RT OSEMs seems to suggest the optic is swinging at 0.55Hz in pitch all the time, and that that swinging gets kicked up at lock loss.
Plot 2: ITMY, ITMX, ETMY, ETMX, OSEMs LF and RT, all optics
The peak at 0.55Hz in OSEMs LF and RT is unique to ITMY.
It's not really helpful, because we don't yet have a solution, but here's the aLOG where this problem has been explored: LHO aLOG 31404. I have no suggestions as of yet on how to fix it, other than re-designing the loops to add more gain (read: *any* gain) at this frequency. Hugh is studying how far back in time this problem has persisted (it's been a problem since at *least* Oct 28), in hopes to find some sort of coincident hardware/electronics activity to blame. But so far, no dice.
Jeff K, Sheila, Jenne, Evan
While we were having an EQ, we took a quick look at what is wrong with ITMY.
Since Cheryl pointed out that this motion is seen in LF and RT, we became suspicous of a problem with top mass V and R damping. Indeed, there was a "bounce" filter engaged in ITMY top mass V damping which must have been a mistake. Once we turned this off the OLTF of the vertical damping looks verry similar between ITMX and ITMY. With this filter on ITMY damping was garbage.
I accepted the change in SDF. We also noticed while doing this that the top mass actuator state for ITMX was 1, while the rest of the quads were in state 2, so we switched that. The large peak at 0.55 Hz that Cheryl aloged is gone now, and hopefully we won't have the problem with long long ringdowns on ITMY.
Jeff, Darkhan, Kiwamu,
This is a quick report; some more details will be reported tomorrow.
We started a preparation work to update the CAL CS front end model. We have created a new version of the matlab script that populates the actuator functions (21322). The new script can be found at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/CALCS/quack_eyresponse_into_calcs.m
We made some tunings to get the script running without making autoquack unhappy. We didn't update the actual foton filters for ETMY today although we made changes on the ITMY CALCS filters as tests. The attached is a first glance at the actuation functions in comparison to the O1 actuation functions. No surprise so far, except that the L3 stage had a different sign now. This will be followed up.
Here is a summary of the activities including yesterday's and today's.
We have ...
This means that we have completed the update of the new suspension filters in CALCS.
[The new CALCS actuator functions]
More explicitly, the suspensions are extracted from the tagged model,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/externals/SUSdynamModelTags/quadmodelproduction-rev8274_ssmake4pv2eMB5f_fiber-rev3601_h1etmy-rev7915_released-2016-11-11.mat
which is specified in H1's parameter file at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/H1params.conf
The DC values for the suspensions came a bit different than what Darkhan reported (31677) by a subpercent level. The matlab code reported the following values.
Ku = 8.1642e-08 N/ct
Kp = 6.8412e-10 N/ct
Kt = -4.3891e-12 N/ct
We will double check with Darkhan to see what actually affected these values even thought the discrepancies aren't significant.
[Adjustment for quacking the filters]
When running the matlab script
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/CALCS/quack_eyresponse_into_calcs.m
to update the actuator functions in CALCS, we ran into some problems for which we spent almost a day. This is a summary of what we encountered and how we mitigated.
Otherwise, we didn't change the code and therefore it did the processes that are describd in detail at 21322.
[Accuracy of the actuation functions in CALCS]
The first attachment is a plot showing the discrepancy between the desired and installed filters. UIM is the one who has the largest discrepancy in 10-100 Hz about a few % in magnitude and a few degrees in phase. Nevertheless, this shouldn't pose an issue for the resulting accuracy of DETAL_EXTERNAL as the UIM affects very weakly above 1 Hz due to the actuation authority. The second attached is another comparison plot showing the desired (full ss) and installed (discrete) filters. Finally the third attachment shows the installed susnorm filters which are forced to be flat at high frequencies.
[Copying the digital filter settings for ETMY]
This was done by running the existing code,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/CALCS/copySus2Cal.py
Darkhan, Kiwamu,
Taking a further look at the K values, we came to the conclusion that the discrepancies are due to rounding error of the N/A values written in H1params.conf. As described above, this will not cause appreciable effects at the precision level we usually talk about (~1 % level). We left them as they are.
It looks like we had another incident of the POP90 power changing, (circled in the striptool screenshot) similar to what Stefan described in 31181. Is this still a problem with the demod as RIchard found the first time? If its only an intermittent problem with the POPAIR 90 demod, we probably don't need to worry about fixing it before O2 because that is jiust a monitor and won't be used if we are able to close the beam diverters for the run.
Detchar question:
Did we have RF45 glitches around these times? The times are roughly 16:26, 16:30, 16:36 and 16:42 Nov 19th local time, which is 0:26, 0:30, ect Nov 20th UTC time.
We were able to fix some obvious problems with this but the problem with the shield was not changed as we did not test it after the fact. Though this problem should only appear if someone was in the rack. Would be interesting to see if anything is on 9,or 45MHz
I took at look at the auiliary channels we used to create DQ flags monitoring RF45 noise in O1, namely H1:LSC-MOD_RF45_AM_CTRL_OUT_DQ and H1:ASC-AS_B_RF36_I_YAW_OUT_DQ. I created BLRMS of these channels in the same way we did in O1 to threshold on. In all of these plots we see a steady BLRMS over 21 hours from 20th Nov 00:00 - 21:00 UTC, indicating that these channels do not see any form of RF45 noise we are used to:
* Plot 1 - BLRMS of H1:LSC-MOD_RF45_AM_CTRL_OUT_DQ between 10-100Hz in 60 seconds strides
* Plot 2 - BLRMS of H1:LSC-MOD_RF45_AM_CTRL_OUT_DQ between 10-100Hz in 1 second strides
* Plot 3 - BLRMS of H1:ASC-AS_B_RF36_I_YAW_OUT_DQ between 30-170Hz in 1 second strides
Hveto for this day indicated that H1:ASC-AS_A_RF45_Q_PIT_OUT_DQ was a good channel to veto noise with on Sunday. I therefore did a BLRMS of this channel:
* Plot 4 - BLRMS of H1:ASC-AS_A_RF45_Q_PIT_OUT_DQ between 5-100 Hz in 1 second strides
This channel does show excess noise at certain times of the day. If we were to threshold on this BLRMS using the 99.5% BLRMS value during this time period, we would capture the times Sheila mentions and also veto 8/10 top ten pycbc live triggers for this day.
Not conclusive that this noise is RF45 noise similar to what we saw in O1, investigating further...
Seemingly another incident: circa 2016-11-23 20:25:30 Z.
J. Kissel, D. Tuyenbayev Darkhan and I was able to get another round of calibration sweeps in last night, just after Sheila finished up her alignment test (LHO aLOG 31599). This set is at 31.92 W, with SRC1 Loops Closed -- and the second set of data with the anticipated O2 configuration. Datasets live here: Sensing Function: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs 2016-11-17_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL 2016-11-17_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml Actuation Functions 2016-11-17_H1SUSETMY_L1_iEXC2DARM.xml 2016-11-17_H1SUSETMY_L1_PCAL2DARM.xml 2016-11-17_H1SUSETMY_L2_iEXC2DARM.xml 2016-11-17_H1SUSETMY_L2_PCAL2DARM.xml 2016-11-17_H1SUSETMY_L3_iEXC2DARM.xml 2016-11-17_H1SUSETMY_L3_PCAL2DARM.xml I'd found that I'd stored the wrong channels in my new templates for the exploration of the UIM/L1 high frequency actuation on 2016-11-12 (LHO aLOG 31433), so I repeated those measurements as well storing the right channels this time: 2016-11-17_H1SUSETMY_L1_iEXC2DARM_HFDynamicsTest_100-250Hz.xml 2016-11-17_H1SUSETMY_L1_iEXC2DARM_HFDynamicsTest_250-350Hz.xml 2016-11-17_H1SUSETMY_L1_iEXC2DARM_HFDynamicsTest_300-500Hz.xml 2016-11-17_H1SUSETMY_L1_iEXC2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml 2016-11-17_H1SUSETMY_L1_PCAL2DARM_HFDynamicsTest_100-250Hz.xml 2016-11-17_H1SUSETMY_L1_PCAL2DARM_HFDynamicsTest_250-350Hz.xml 2016-11-17_H1SUSETMY_L1_PCAL2DARM_HFDynamicsTest_300-500Hz.xml 2016-11-17_H1SUSETMY_L1_PCAL2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml Analysis will be posted today (it's finished, we now just need to document it all), and we plan on updating the DARM model and front-end calibration by Monday.
The high-frequency dynamics measurements quoted in this aLOG have been analyzed. See results in LHO aLOG 31603.
J. Kissel, K. Izumi, D. Tuyenbayev,
Overview
Actuation strengths [N/ct] for all three stages have been calculated with MCMC method. In In this analysis we used data from last set of measurements taken on Nov 17 (see above), together with measurements from Nov 7, 8, 10 and 12 (see LHO alogs 31303, 31371, 31403, 31433). The calculated actuation coefficients are:
KU = 8.1648-8 N/ct
KP = 6.844-10 N/ct
KT = 4.395-12 N/ct
The H1DARM model parameters were updated using these values, particularty:
UIM_NpA = 1.739; [N/A]
PUM_NpA = 0.0334; [N/A]
TST_NpV2_y = 1.612e-10; [N/V^2]
We will double check the overall DARM loop model, with the updated sensing and actuation, by comparing it to DARM loop TF measurements.
Notice that TST actuation coef came out as a negative quantity, we believe that there is a "-1" missing in the model of this stage.
Details
For this analysis we took each actuation stage to DARM TF and PCALY to DARM TF measurements at the same frequency vector and used only data points with coherences above 0.9, we adopted a Matlab script used at LLO for this part of the analysis (see EvanG's LLO alog 29438). For each actuation stage i, the test point excitation to DARM TF is
iEXC2DARM = Ai,meas * C / (1 + G)
and PCALY to DARM is
PCALY2DARM = C / (1 + G)
The ratio of the two gives:
iEXC2DARM / PCALY2DARM = Ai,meas
Then we divided this my the model of the given stage without the N/ct coefficient, Ai,model / Ki,model = Fi,model, gives measurement of the frequency-independent N/ct coefficient:
Ai,meas / Fi,model = Ki,meas
Then, we used GWMCMC library (https://github.com/grinsted/gwmcmc) for fitting amplitude and phase of the N/ct coefficient for each stage (if the frequency dependent part of the model is correct, then the phase should be 0 deg). The log likelihood function used for fitting is
logLike = log( ∏( 1 / sqrt(2πσi2) exp( - (Ki,meas - Kfit)2/(2σi2) ) )
Fit results for magnitudes are given above and the phases are at the order of 10-3 deg.
The KU, KP and KT coefficients calculated from multiple-frequency transfer function measurements differ from earlier estimations from single line (LHO alog 31344) by 1.7%, 5.3% and 3.1% for UIM, PUM and TST stages. Possibly some unaccounted systematics in the frequency reponses of the DARM model near 35 Hz (the previous analysis was done with the DARM model for ER9).
Izumi K, Kissel J, Tuyenbayev D,
We used ER10 model to re-run an earlier actuation strength analysis using calibrartion line data from Nov 3 - Nov 8 (LHO alog 31344). The original analysis was done with the DARM model in which the positive N/ct sign was used for TST stage actuation, the correct KT sign must have been negative. Below we list the updated results from this single-line analysis, the values are taken from GPS time interval [1162369920 1162413500]:
KU = 8.613 × 10-8 ± 3.204 × 10-10 N/ct
KP = 6.802 × 10-10 ± 2.254 × 10-12 N/ct
KT = -4.341 × 10-12 ± 1.339 × 10-14 N/ct
Notice this analysis is used as an additional check of the multiple-frequency analysis (see above). The DARM model parameters for ER10/O2 will be based on the multiple-frequency analysis results (refined numbers and comparison results are coming soon).
Izumi K, Kissel J, Tuyenbayev D,
Overview
We calculated the actuation coefficients for the H1 DARM reference time model. For UIM (L1) and PUM (L2) stages the N/ct coefficients were fit based on actuation TF measurements on Nov 7, 8, 10, 12 and 15. These numbers have been reported earlier (see above). The TST actuation strength will have a trend over long time period due to charge accumulation, thus for TST stage it is better to estimate the coefficient based on measurements taken within a short period of time. Since we set the reference sensing function parameters based on measurements taken on Nov 12, for estimation of the TST (L3) stage actuation we decided to use measurements around that date, particularly measurements from Nov 10 and 12.
Contributions from each of the actuation stages to the overall DARM response drops as 1/f6, 1/f4 and 1/f2, for this reason MCMC (and LSQ) fitting were restricted to [0 10] Hz, [0 200] Hz and [0, 200] Hz for UIM, PUM and TST stages respectively.
Below are the resulting N/ct values, these values:
KU = 8.1648 × 10-8 N/ct (± 0.074% 1-σ)
KP = 6.844 × 10-10 N/ct (± 0.018% 1-σ)
KT = -4.389 × 10-12 N/ct (± 0.031% 1-σ)
And the H1DARM model were updated in the following way (only the N/V2 for TST stage is different from LHO alog 31649):
UIM_NpA = 1.739; % [N/A]
PUM_NpA = 0.0334; % [N/A]
TST_NpV2_y = 1.6097e-10; % [N/V^2]
New EPICS values used for DARM time-dependent parameters have been calculated with the updated H1 DARM model for ER10/O2 (see attachment 1).
Comparisons
MCMC and LSQ methods gave consistent results, fractional discrepancies between the two were at the order of 10-5 (LSQ fit was done only for magnitude).
Discrepancies between the new values and the ones currently installed in the CAL-CS front-end model are:
UIM: 0.05% (compared 8.1689 × 10-8 N/ct, the currently installed, old value)
PUM: 0.05% (compared to 6.8407 × 10-10 N/ct)
TST: 3.42% (compared to 4.239 × 10-12 N/ct)
Discrepancies between these values and an updated single-line analysis results (see LHO alog 31668 above) are 5.5% (UIM), 0.6% (PUM) and 1.4% (TST). A larger discrepancy between MCMC and the single-line analysis for UIM, we believe, is mostly due to 5-10% systematic errors in the UIM suspension model at ~36 Hz (see a residual plot attached to Kiwamu's LHO alog 31427).*
Although, the TST stage coefficient was calculated based on Nov 10th and 12th measurements, discrepancies between the values estimated for each of the 5 measurements (Nov 7 - 17), are within 0.5% (see attachment 2).
*Check out Jeff's LHO alog 31603 for more UIM HF investigations.
Details
TST stage fitting plots are attached below (see attachments 3 and 4). UIM and PUM fitting results did not change (see previous report above, LHO alog 31609).
The new EPICS values for DARM time-dependent parameters are committed to
${CalSVN}/Runs/ER10/H1/Scripts/CAL_EPICS/D20161120_H1_CAL_EPICS_VALUES.m
The up-to-date H1 DARM model parameters are commited to CalSVN:
${CalSVN}/Runs/ER10/Common/params/IFOindepParams.conf r3752
${CalSVN}/Runs/ER10/H1/params/H1params.conf r3826
${CalSVN}/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf r3786
DARM model scripts (SRC detuning TF was modified to include Q-factor at r3814):
${CalSVN}/Runs/O2/DARMmodel/* r3814
Actuation coefficient fitting script was uploaded to
${CalSVN}/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/fitActCoefs_Npct.m r3829
And the results are at
${CalSVN}/Runs/ER10/H1/Results/Actuation/2016-11-20_H1_SUSETMY_*.pdf
