Displaying reports 52421-52440 of 83273.Go to page Start 2618 2619 2620 2621 2622 2623 2624 2625 2626 End
Reports until 08:20, Tuesday 22 November 2016
H1 AOS
edmond.merilh@LIGO.ORG - posted 08:20, Tuesday 22 November 2016 (31716)
Wind and Gusts are pretty impressive as reported by lazy script!
TITLE: 11/22 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Nutsinee
CURRENT ENVIRONMENT:
    Wind: 4877934324797904257024mph Gusts, 8468635980551917568mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.21 μm/s 
QUICK SUMMARY:
H1 General (SEI)
edmond.merilh@LIGO.ORG - posted 08:16, Tuesday 22 November 2016 (31715)
BRS turned off at both ends

Kyle called to let me know he was going into VEA at EX and Gerardo and Richard are going in as well to do RGA work. As a pre-emptive move I disabled EY as well so as not to forgetlater if things get hectic.

H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 08:05, Tuesday 22 November 2016 (31714)
Ops Owl Shift Summary

TITLE: 11/22 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC

STATE of H1: Commissioning

INCOMING OPERATOR: Ed

SHIFT SUMMARY: Quiet shift. Couple of small earthquakes. Observed the entire shift. Went to commissioning for manintenance activities. 

LOG:

15:45 Ken drives to warehouse

15:35 Karen to EY

15:56 Kyle to EX

H1 CAL
aaron.viets@LIGO.ORG - posted 06:59, Tuesday 22 November 2016 (31712)
New GDS filters for LHO
I have made a filters file for LHO that includes the most recent updates to DARM model and the EPICS values (see aLOG https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31693 ). The filters were made using revision #3847 of the calibration SVN and can be found here:
aligocalibration/trunk/Runs/ER10/GDSFilters/H1GDS_1163857500.npz

Several plots are attached:
1) h(f) spectrum from CAL-CS and GDS 
2) Ratio of spectra (GDS / CAL-CS)
3) Residual correction filter
4) Control correction filter
Images attached to this report
Non-image files attached to this report
H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 01:21, Tuesday 22 November 2016 - last comment - 13:48, Tuesday 22 November 2016(31711)
LHO ER10 Actuation Uncertainty Budget
C. Cahillane

ER10 Actuation uncertainty budget for LHO based on the N/ct transfer function measurements from November 8, 9, 11, 12, and 18th.
To be clear, these measurements have the suspension models already divided out.  Additionally, we only take measurement points for UIM up to 30 Hz, and PUM up to 100 Hz, since these are the only regions they have any actuation authority.

We perform 4th order linear fits in the log(f) domain of the three actuation stages, UIM, PUM, and TST:

Fit = ( a_0 + a_1 * log(f+1) + a_2 * log(f+1)**2 + a_3 * log(f+1)**3 + a_4 * log(f+1)**4 ) * exp(i * 2*pi*f*a_5 + i * a_6)

The coefficients [a_0, ..., a_5] are the linear coefficients governing the magnitude of the fit.  
The coefficient a_5 is the time delay term, and a_6 is some phase offset.

I fit the magnitude in the log(f+1) domain because the data is taken with logarithmic frequency spacing, and this gives the MCMC more freedom to fit the more-uncertain low frequency data points while constraining itself in the bucket.  The plus one is so log(0 + 1) = 0 and not log(0) = -infinity, so at DC we don't explode our MCMC predicted results.
I fit the phase in the linear f domain because exp(i* 2*pi*f*time_delay) is the typical expression for a time delay, and this seemed to be a sufficient fit given our data.

There are two types of plots shown below: the corner plot and the measurement + fit + uncertainty results.  There is one such plot for each stage.

Plots 1, 2, and 3 are the UIM, PUM, and TST measurements + fit + uncertainty results.  The shapes represent the ER10 measurement sweeps, the green line is the MCMC MAP fit, and each individual grey line is a potential fit according to the MCMC.  The 1000 grey lines together form our uncertainty budget.

Plots 4, 5, and 6 are the UIM, PUM, and TST fit corner plots.  These show each parameter of the MCMC, its MAP value, and its 68% confidence interval in the title.  The PDF of each parameter is shown along the diagonal, while the bulk shows the covariance of each parameter with one another.  
The names of each parameter is slightly different from my equation above:

a_0 = H_{Stage}
a_1 = alpha
a_2 = beta
a_3 = gamma
a_4 = delta
a_5 = tau   (time delay)
a_6 = phi


In comparison with LHO aLOG 31344, the DC coefficient values found were:

H_UIM = 1.2 (+ 0.8 or - 0.7) * 10^-7
H_PUM = 6.8 (+ 1.5 or - 1.5) * 10^-10
H_TST = 4.0 (+ 0.2 or - 0.2) * 10^-12


However, 4th order fits may not be the best method of finding the DC coefficient, since even a small change in value on the 4th order coefficient can have a huge effect on the 0th order coefficient.  But for characterizing uncertainty in our actuation plant, this is the correct way since we don't in principle know the function we're fitting for.

Overall Uncertainty:

UIM Stage: < 3% magnitude and < 1 degree phase uncertainty
PUM Stage: < 2% magnitude and < 1 degree phase uncertainty 
TST Stage: < 2% magnitude and < 1 degree phase uncertainty

(All stages have their maximum uncertainty at low frequency.)

This level of uncertainty is exceptionally tiny, even with 4th order polynomial fits.  The great deal of measurements taken constrains the fit, lowering uncertainty drastically, especially in the bucket.  Once we can account for time dependence, we may be close to achieving 5% and 5 degrees, depending on the sensing function uncertainty, or becoming kappa-limited.
Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 13:48, Tuesday 22 November 2016 (31729)

Jeff, Darkhan, Kiwamu,

Looking at Craig's quad bode plots, we noticed that the data often showed large deviations in the data points at 38.3 Hz, especially in magnitude. We suspect that this is due to the fact that the DARM line at 37.3 Hz was not turned off during most of the measurements. While their separation is large and about 1 Hz, the DARM line can still influence our measurement because the integration time in the measurements was set to 1 sec which is not long enough to completely reject noise neighboring by 1 Hz. Out of 5 sets of the data that Craig processed, the Nov-18 data seems the only one which had the DARM line off. Indeed, the Nov-18 data shows a small deviation at 38.3 Hz.

A lesson we (re)learned today: Do not forget to turn off the calibration lines when running a swept sine measurement.

LHO General
corey.gray@LIGO.ORG - posted 00:02, Tuesday 22 November 2016 (31706)
Ops EVE Shift Transition

TITLE: 11/22 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY:

Earth was still ringing at beginning of shift, but eventually made headway with locking.  Transitioned to PEM injections for 2nd half of shift (until a lockloss).  It has been 30+min and H1 has shown no issues with ASC (i.e. recycling gain worry Sheila mentioned)...this current lock I did not pause at NOISE_TUNINGS just to see if we could make it without having to wait for any cooling.


LOG:

H1 PEM
robert.schofield@LIGO.ORG - posted 23:17, Monday 21 November 2016 (31710)
Today's PEM injections

Today we got a good start on PEM injections, injecting in the LVEA, PSL and the ebay, magnetic and acoustic injections. Tomorrow we plan to continue in the LVEA, more acoustic and magnetic and starting some shaker and possibly RF injections. Watch for cables on the floor if you go in the LVEA.

LHO General
corey.gray@LIGO.ORG - posted 21:51, Monday 21 November 2016 (31709)
EVE Shift Update
H1 AOS (Lockloss, OpsInfo)
sheila.dwyer@LIGO.ORG - posted 20:40, Monday 21 November 2016 (31707)
yaw instability at 1.88Hz

We seem to have a problem with our yaw ASC at 1.88 Hz.  In several of our recent long locks we have had motion at 1.88 Hz in several of our ASC loops, and this occasionally causes locklosses.  This caused a lockloss the first time we locked after todays earthquakes.

Keita looked at that lockloss, and saw that it shows up much more in ITMY than in the rest of the oplevs. 

In the lockloss plot, it looks like the SOFT loops are ringing up, but this might be misleading because the signals are more quiet than other ASC signals.

Operators:

Over the first half hour or so after we increase power, the recycling gain continues to increase.  It might be that we can only transition from POP WFS to REFL WFS after this has happened. 

If you need to relock tonight, you can try runing through the gaurdian as is.  If that doesn't work, I'd recomend waiting about a half hour at noise tunnings before switching over to REFL WFS and closing the beam diverters.

H1 INJ (DetChar, INJ)
evan.goetz@LIGO.ORG - posted 20:02, Monday 21 November 2016 (31705)
DetChar safety study HW injection
I made a DetChar safety study hardware injection using the Guardian infrastructure.

From the schedule file (rev 5233):
1163822000 H1 INJECT_DETCHAR_ACTIVE 0 1.0 detchar/detchar_03Oct2015_PCAL.txt

The injection was successful.

To make this happen, however, I had to manually change the "dev_mode" in INJ_TRANS.py from False to True since the interferometer intent bit was not set. I reverted this change after the injection was successful.

One minor note, from the Guardian log file, I got a warning, but I don't know if it is an issue:
2016-11-22T03:52:51.02490 Aborting Logging because SIStrLog call failed -1
H1 ISC (ISC)
jenne.driggers@LIGO.ORG - posted 18:18, Monday 21 November 2016 (31698)
Spot position comparisons

Our operators have been running A2L a lot lately, so I've started looking at the spot positions that we infer from those measurements. 

Sheila asked specifically for a comparison of our spot positions at DC readout versus NomLowNoise.  I took the times from Cheryl's alog 31630, and Nutsinee's alog 31647 and plot the spot positions in the first plot.  Yellow points are those from 19 Nov 2016, 00:30:00-00:01:00, and Purple are those from 19 Nov 2016 15:10:00-15:40:00.  The Xaxis is labeled with the interferometer state at the time, DC readout or NomLowNoise. I think that Sheila may have done some alignment work (alog 31628) in between these times, which is why they're not consistent between these two locks.  ITMY changes in a very different way between the two locks, but the rest of the optics and degrees of freedom at least move in the same way when we power-up, even if the start or stop positions aren't the same.

I have also plotted two times when our operators ran A2L several times over a single lock stretchalog 31560 is from 17 Nov, and alog 31678 is from 21 Nov.  The dates are in the figure names attached.  As we had seen during O1, if the IFO is left alone, the spots on the test masses do not change with time very significantly.  The Xaxes are hours from the first time A2L was run, back in October 2015, but you get the idea that each measurement is 60-90 minutes apart.  I've zoomed the scales pretty significantly here, so note the Yaxes.

Finally, the last 2 plots are our spot positions since ER10 began on ~14 Nov 2016, and just the last few days, since our last big alignment work on Friday night.  Once we stopped doing alignment work, we're becoming more consistent.

For Jeff: I also attach a .mat file with the spot positions in mm, along with the gps times of each measurement.  The data is in 4x2 cells at each time:

ITMX Pit ITMX Yaw
ITMY Pit ITMY Yaw
ETMX Pit ETMX Yaw
ETMY Pit ETMY Yaw
Images attached to this report
Non-image files attached to this report
LHO General
corey.gray@LIGO.ORG - posted 17:01, Monday 21 November 2016 (31703)
Ops EVE Shift Transition

TITLE: 11/22 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.15 μm/s
    Secondary useism: 0.17 μm/s
QUICK SUMMARY:

Jim handed over an H1 just as he was starting to lock after the earthquake.  

Making initial locking attempts (had to tweak the BS [in CHECK MICH FRINGES] & also PRM/BS in PRMI).  Made it to DRMI had now troubleshooting why we drop out of DRMI Lock after a few minutes.

Will check out A2L lines in DC Readout & then aim to get to NLN.

H1 CDS (SEI)
david.barker@LIGO.ORG - posted 16:29, Monday 21 November 2016 - last comment - 12:46, Friday 02 December 2016(31702)
status of seismon epics interface

I've been working on a prototype epics interface to the seismon system. It currently has several moving parts.

EPICS IOC

Runs on h1fescript0 as user controls (in a screen environment). Code is

/ligo/home/controls/seismon/epics_ioc/seismon_ioc.py

It is a simple epics database with no processing of signals.

EVENT Parser, EPICS writer

A python script parses the data file produced by seismon_info and sends the data to EPICS. It also handles the count-down timer for future seismic events.

This runs on h1hwinj2 as user controls. Code is

/ligo/home/controls/seismon/bin/seismon_channel_access_client

MEDM

A new MEDM called H!SEISMON_CUST.adl is linked to the SITEMAP via the SEI pulldown (called SEISMON). Snapshot attached.

The countdown for the P,S,R waves are color coded for the arrival time of the seismic wave

ORANGE   more than 2 mins away

YELLOW  between 1 and 2 minutes away

RED  less than 1 minute away

GREY in the past

If the system freezes and the GPS time becomes older than 1 minute, a RED rectangle will show to report the error.

Images attached to this report
Comments related to this report
sebastien.biscans@LIGO.ORG - 12:46, Friday 02 December 2016 (32110)

Just noticed this post, this is great.

Let us know if you run in any bug/trouble with the code.

H1 CAL (DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 16:23, Monday 21 November 2016 - last comment - 17:06, Monday 21 November 2016(31693)
CAL-CS Front-End (and therefore GDS Low-Latency) DARM/DELTAL_EXTERNAL Time-Independent Calibration Updated for O2
J. Kissel, D. Tuyenbayev, K. Izumi, E. Goetz, C. Cahillane

We have successfully updated the calibration in the front-end calibration. This means the static, frequency-dependent part of the low-latency calibration pipeline is ready to go for O2. Many thanks to all who've helped get this together in such short time.

Kiwamu has updated the actuation side: see LHO aLOG 31687
I have updated the sensing side: see this aLOG below.
Darkhan has updated the EPICs records that store the model at calibration line frequencies: see LHO aLOG 31696
These changes have been accepted in the CAL-CS SDF system.

I always hate saying this statement because it comes without an uncertainty estimate and boils down a time-dependent, frequency dependent answer to a pair of numbers -- and DELTAL_EXTERNAL is limited by the accuracy of the front-end -- but I know people like to hear it, and it's a good, simple benchmark to hit:
The resulting agreement between mean values of a swept-sine transfer function between the low-latency pipeline output, CAL-DELTAL_EXTERNAL and PCAL is roughly 2% and 2 [deg] for almost all frequency points between 10 Hz and 1.2 kHz.

I was minutes away from finishing a broad-band PCAL injection so we can compare the output with the GDS pipeline to get the full answer, when the 6.9 [mag] Japanese EQ hit (see LHO aLOG 31694). We'll get this during the next lock stretch.


We will be working on the uncertainty budget of the next coming days (but expect us to take a Thanksgiving break). We expect the time-independent, statisical uncertainty to improve beyond that of O1 but because they haven't happened yet, we can't make claims about the systematic errors that arise from uncorrected for time-dependence. This is especially true if the evidence for a changing SRC detuning spring frequency holds (see discussion in LHO aLOGs 31665 and 31667).

%%%%%%%%%%%%%%%
Details:
%%%%%%%%%%%%%%%
Actuation Function
Again, see Kiwamu's aLOG for details on the updates to the actuation function: LHO aLOG 31687.

Sensing Function
I've updated the front-end's inverse sensing function to the parameters that are now used as the O2 reference measurements:
                                 [Units]  value(95% c.i.)
Meas Date                 2016            Nov 12
IFO Input Power                  [W]      29.5
SRC1 Loop Status                          ON   

Optical Gain              x 1e6  [ct/m]   1.153 (0.003)   => Inv. Optical Gain = 8.673e-7 (2.255e-09) [m/ct]
DARM/RSE Cav. Pole Freq.         [Hz]     346.7 (4.1)
Detuned SRC Optical Spring Freq. [Hz]     7.389 (0.3)     
Optical Spring Q-Factor (1/Q)    []       0.0454 (0.01)   => Q = 22.015 (4.84)
Residual Time Delay              [us]     2.3  (3.4)      => consistent w/ zero, so not included
 
aLOG                                      LHO 31433

The front-end implementation in foton is as follows:
    Bank: H1:CAL-CS_DARM_ERR
        Module  Name           Design String
        FM2     O2SRD2N        zpk([346.7;7.2231;-7.5587],[0.1;0.1;7000],1,"n")gain(5458.55)
        FM3     O2Gain         gain(8.673e-7)
The bank is screen captured and attached, just in case SDF dies.

Explanation for each component in the FM2 / O2SRCD2N filter:
    - 346.7 Hz zero is the inverse of the darm coupled cavity pole, as fit in LHO aLOG 31433.
    - 7.2231 and -7.5587 Hz zeros represent in inverse of the detuned optical spring. Because of the limitations of foton and the need for anti-spring-like response, we must convert the two positive zero frequencies and Q into a positive and negative zero (i.e. one in the real, one in the imaginary plane):

                f^2                (2*pi*i)^2               f^2
    ---------------------------- =  ---------- * ---------------------------
    f^2 - i*(f*f_s/Q) + (f_s)^2    (2*pi*i)^2    f^2 - i (f*f_s/Q) + (f_s)^2

                                        (s = 2*pi*i*f  ; c_s = 2*pi*f_s)

                                             s^2
                                 = ------------------------
                                   s^2 + s*(c_s)/Q - (c_s)^2
          Zeros are the roots of
                            >> 0 = s^2 + s*(c_s)/Q - (c_s)^2
                             
                                          1  (    (c_s)          { ( (c_s) )^2                     }
                            >> s_{+/-} = --- ( -  ----- +/- sqrt { ( ----- )   - 4 (1) (- (c_s)^2) }
                                          2  (      Q            { (   Q   )                       }

                                          1  (   2*pi*f_s          { ( 2*pi*f_s )^2                 }
                            >> f_{+/-} = ----(-  -------- +/- sqrt { ( -------- )   + 4(2*pi*f_s)^2 }
                                         4*pi(      Q              { (    Q     )                   }

                                         f_s              
                            >> f_{+/-} = --- ( -1 +/- sqrt { 1 + 4 Q^2 } )
                                         2 Q           
      For f_s = 7.389 Hz and Q = 22.015, that means the positive and negative zeros are at 7.2231;-7.5587 Hz, as shown in the design string.
    - The poles at [0.1;0.1;7000] are to artificially roll off the inverse response -- these are the same as they were in ER9. Remember the 7000 Hz pole distorts the response enough that this needs to be corrected for in the GDS pipeline. 

This CAL-CS design is not perfect. I've exported the design back into matlab and compared it against the model using 
      /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/CALCS/compare_model_v_CALCS_sensing.m

and I attach the discrepancy. The discrepancy at high-frequency should be the same, since we've used the 7000 Hz pole to roll off the darm coupled cavity zero as in O1. The low frequency could use some correction. The DARM UGF is now around 65 Hz, where this sensing function discrepancy starts to matter. There, the phase discrepancy is 0.52 [deg] @ 65 Hz, and works its way up to 3.6 [deg] at 10 Hz. Thus, we don't expect too much impact at all, but it needs to be quantified. I'll discuss with the GDS team to see if such a correction filter is worth it or possible.

All of the above actuation and sensing function parameters have been built into the matlab DARM loop model. From here on out, we'll be using the relative, time-dependent correction to make corrections to the model such that they match any new measurements.
Images attached to this report
Non-image files attached to this report
Comments related to this report
michael.landry@LIGO.ORG - 17:06, Monday 21 November 2016 (31704)

Nicely done Team Calibration!

LHO FMCS
bubba.gateley@LIGO.ORG - posted 15:45, Monday 21 November 2016 (31700)
Control room temps
While investigating the Control Room temperature swings, I discovered the return air damper for AHU-3 completely closed. I have the damper open to the normal operating position now and temperatures should stabilize in all areas serviced by AHU-3. 
This situation appeared to be caused by a problem with the pneumatic actuator for that damper which will soon be replaced with an electric actuator.
LHO VE
chandra.romel@LIGO.ORG - posted 14:35, Monday 21 November 2016 (31697)
RGA filaments OFF

I turned both corner and EY RGA filamets OFF so that Robert and AnnaMaria can do noise tests at their convenience by powering off RGAs by unplugging unit at electronics body.

RGAs that are powered on:

BSC5 (EX) - this one cannot be controlled remotely yet but I think the electronics unit (i.e. fan) is still powered on. The filament should be OFF. There is an LED light on electronics unit that indicates if filament is ON/OFF.

BSC6 (EY)

OMC tube next to HAM4 (LVEA)

H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 14:34, Monday 21 November 2016 - last comment - 23:34, Tuesday 22 November 2016(31696)
Updated EPICS records for DARM time-dependent parameters (param. set for ER10/O2)

Jeff K, Kiwamu I, Darkhan T,

Overview

The CAL-CS EPICS records for tracking temporal variations of the DARM parameters have been updated at 2016-11-21 22:03:46 UTC. These values are identical to the ones in LHO alog 31677 from yesterday, i.e. D20161120_H1_CAL_EPICS_VALUES.m and D20161121_H1_CAL_EPICS_VALUES.m are identical.

New values have been accepted in SDF_OVERVIEW.

Details

Following DARM paramemter files were used to calculate these values:

${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

And the DARM model scripts from

${CalSVN}/Runs/O2/DARMmodel/*  r3814

The *.m file with EP1-9 values and the verbose output are attached to this report. All of the files have been committed to CalSVN at

ER10/H1/Scripts/CAL_EPICS/

D20161121_H1_CAL_EPICS_VALUES.m
20161121_H1_CAL_EPICS_VALUES.txt
20161121_H1_CAL_EPICS_verbose.log

Images attached to this report
Non-image files attached to this report
Comments related to this report
darkhan.tuyenbayev@LIGO.ORG - 17:09, Tuesday 22 November 2016 (31736)CAL

Shivaraj K, Jeffrey K, Aaron V, Darkhan T,

Updated DARM time-dependence EPICS

We have updated the EPICS values used for DARM time-dependent parameter calculations (DCC T1500377). We added a previously (Nov 21) missing delay in the DARM_ERR signal due to one computational cycle delay, comes from the fact that the signal is transferred from the OMC front-end model to CAL-CS. The *.m file with EP1-9 values and the verbose log are attached to this alog.

The new values were updated in the front-end and were accepted in SDF_OVERVIEW.

Location in the SVN:

${CalSVN}/Runs/ER10/H1/Scripts/CAL_EPICS/

D20161122_H1_CAL_EPICS_VALUES.m
20161122_H1_CAL_EPICS_verbose.log
20161122_H1_CAL_EPICS_VALUES.txt

Corrections to be applied to the channels in GDS and SLM (CalMon) when calculating "kappas"

All of the necessary corrections, except for Pcal RX PD channel corrections have been incorporated in the EPICS values, i.e. when calculating kappas with the method from T1500377, except for the Pcal Rx PD the rest of the channels must be used without applying any additional corrections. The Pcal RX PD channels from the frames must be corrected for the freq. dep. part of the free mass response (two poles at 1 Hz), analog AI, digital AI (IOP) and the time delay of the CAL-EY channels w.r.t. [V] from the PD (this piece was measured to be zero). One of the ways to get the correction TF is to extract it from the Matlab DARM model, an example of extracing this correction TF for Hanford can be found at (the resulting TF is attached):

${CalSVN}/Runs/ER10/H1/Scripts/PCAL/examplePcalCorrExtraction.m

LLO analog AA/AI models have been updated for ER10/O2, while at LHO they did not change since the O1 run. So it is important to calculate the site-specific Pcal corrections using the most up-to-date DARM reference-time parameters.

Corrections to be applied to the CAL-CS demodulators

Since "kappa" calculations in CAL-CS are not done using the Pcal Rx PD channels written into frames, but rather with the PCALY_RX_PD signal that gets transmitted from the CALEY model to CAL-CS, the Pcal Rx PD data seen by CAL-CS has an additional one computational cycle delay. This means that the phases and amplitudes in the front-end demodulators must be adjusted with PcallCorr * (one_cycle_advance_phase).

Images attached to this comment
Non-image files attached to this comment
darkhan.tuyenbayev@LIGO.ORG - 18:35, Tuesday 22 November 2016 (31748)CAL

Pcal calibration line demodulator phases have been adjusted in the CAL-CS front-end model.

PCAL_LINE1 (36.7 Hz line) demodulator phase was set to -1.87 deg (old value was -2.40 deg)

PCAL_LINE2 (331.9 Hz line) demodulator phase was set to -16.95 deg (old value was -19.9 deg)

The phases were calculated according to the instructions given above and taking into account that two poles at 1 Hz (free-mass response) are applied separately in a Foton filter.

The script for calculating the phases was committed to

${CalSVN}/Runs/ER10/H1/Scripts/PCAL/getPcalCorrForCALCSdemod.m

The new values have been accepted in SDF_OVERVIEW.

After updating the phases we have got about 25 minutes of data before we lost the lock. κPU, κT, κC, in this interval were within 1% of their reference-time values (1.0) and fC was within 3% of its reference-time value (346.7 Hz).

Images attached to this comment
aaron.viets@LIGO.ORG - 19:16, Tuesday 22 November 2016 (31751)
I compared both of Pcal correction factors for LHO used by the GDS pipeline to the transfer function produced by the example script. These are computed at two line frequencies: 36.7 Hz and 331.9 Hz. As seen in the plot, they agree quite precisely. I also checked that the numerical values produced by this script at the line frequencies were identical to those used in the GDS pipeline.
Non-image files attached to this comment
sudarshan.karki@LIGO.ORG - 23:34, Tuesday 22 November 2016 (31763)

The pcalcorrection factor used for SLM Tool and computed by the exapmple script are in good agreement as well.

Non-image files attached to this comment
H1 SUS (SUS)
cheryl.vorvick@LIGO.ORG - posted 23:48, Sunday 20 November 2016 - last comment - 16:03, Monday 21 November 2016(31675)
ITMY appears to be swinging in pitch at 0.55Hz thoughout H1 locks

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.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:21, Monday 21 November 2016 (31680)OpsInfo
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.
sheila.dwyer@LIGO.ORG - 16:03, Monday 21 November 2016 (31701)OpsInfo

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. 

Images attached to this comment
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 18:52, Sunday 20 November 2016 - last comment - 15:27, Monday 21 November 2016(31671)
Preparation work for updating CALCS with ER10/O2 model

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.

Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 12:51, Monday 21 November 2016 (31687)

Here is a summary of the activities including yesterday's and today's.

We have ...

  • Adopted some matlab scripts as reported above and also below.
  • Made the actual changes on the foton file namely H1CALCS.txt
  • Loaded the new filters this morning at Nov. 21 18:24 UTC

This means that we have completed the update of the new suspension filters in CALCS.


[The new  CALCS actuator functions]

  • It now uses the latest suspension tag model that Jeff updated 10 days ago (31432).
    • The latest includes the oplev damping.
    • Also, as shown in the attached screenshot in the above entry, the latest have slight difference around 1 Hz and some difference above 100 Hz.

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.

  • Issue 1: too many SOS sections in the TST stage
    • The TST stage ended up with too many SOS sections when using the latest tag model.
    • We relaxed the tolerance for minreal from 6e-5 to 1e-3 as a mitigation.
  • Issue 2: violins not compatible with biquad form
    • Depending on the cut off frequency for excluding fine structures, quackcheck often reported a 0-gain error.
    • It turned out that this happens when the SOS filter coefficients don't have a b0i. We could not come up with a good mitigation.
    • We decided to set the cut off frequencies individually so that we can let all of them survive. The good values we found were: UIM cutoff = 1600 Hz and PUM cutoff = 2000 Hz.
  • Issue 3: autoquack occasionally runs into a steady failure mode
    • Autoquack occasionally enters a situation where it keeps reporting BAD filter implementation for some reason.
    • We empirically found that we can get out of the situation by manually installing a simple and fake zpk filter once (e.g. zpk([], [], 19, "n") or similar ) at the filter module having the issue.
  • Issue 4: c2d and minreal return some bad filters
    • c2d and minreal occasionally returned filters that are bad for quack (such as the number of zeros exceeding the number of poles).
    • This, for some reason, can be mitigated by running the script again.

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

Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 15:27, Monday 21 November 2016 (31699)

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.

Displaying reports 52421-52440 of 83273.Go to page Start 2618 2619 2620 2621 2622 2623 2624 2625 2626 End