NikoL, RickS

Following up on the work we did at Yend last week (see this Link), Niko inspected the beam positions at the input aperture of the Rx sensor at Yend yesterday after completing calibration measurements at Xend.

He found that the Outer (lower) beam had again drifted to the right (see attached photo), this time by a few millimeters.  This likely did NOT impact the calibration because it did not appear to be clipping at the Rx sensor aperture.

Given that it was near the end of the Tuesday maintenance period, we did not have much time to improvise a potential fix.  But we end up trying a kind of "flying buttress" approach.  We used a second ThorLabs base and some 5-minute epoxy we found in the toolbox (it was WAY beyond its expiration date of 1/21/2013, but it was unopened, so we gave iit a try) - see second attached photo.  If this epoxy actually hardens, it should help stabilize the post holder.   If this is the source of the alignment drifts, this may help.

We also tightened the set screw that holds the 1" diameter beamsplitter in place in the Newport U100 mount.  Slight tightening of the set screw resulted in the beam at the Rx module moving by more than the 1" diameter of the power sensor aperture.  This might indicate that the optic was not seated properly to begin with.  Maybe this is the real source of the alignment woes at Yend. We did not want to risk removing and re-seating it yesterday, but may try that in the future if this problem persists.

We carefully aligned both beams to the center of the Rx power sensor aperture before leaving the end station (see last attached photo). 

To follow up with the measurements described in 47289, Craig added two MICH length lines, at 12.3 and 100.0 Hz. They were both on for the entire duration of a long lock stretch yesterday night. By demodulating both lines in H1:SUS-BS_M3_ISCINF_L_IN1_DQ and H1:LSC-DARM_IN1_DQ we can track the evolution of the MICH to DARM coupling over time. The reason to have two lines is that looking at the transfer functions plotted in 47289, one can see that the high and low frequency components change in a different way.

The plot attached shows the DARM / MICH transfer function at the two lines, as a function of time, in hours from 1235873679. The coupling changes over time both at 12.3 and 100.0 Hz.

At 12.3 Hz there is a monotonic change from 4.6e-10 to 4.5e-10, with a phase rotation of about 5 degrees. This trend settles after a hour or so.

At 100.0 Hz the evolution is more complex. There seems to be an initial trend similar to the 12.3 Hz trend (except that the phase seems to be increasing), but then there are large fluctuations in both amplitude and phase. It would be interesting to understand what was happening to the IFO during those excursions.

J. Kissel (with help from L. Sun, E. Goetz, L. McCuller, E. Bonillla, R. Kumar)

I've been processing the actuation function data from 2019-03-01 (see LHO aLOG 47206), and have some updates. Not were I want it, but since the heat is on I'll give a status update.

Recall from LHO aLOG 46806,
Steps to success:
    (i) Find out why ETMX L1 and L2 doesn't work, and fix it, such that we can go forward with full ETMX DARM actuation. 
        DONE (see fixes to UIM and PUM crossovers in LHO aLOGs  47164 and 46861)
    (ii) Measure the PUM and UIM coil drivers, and update the compensation. 
        DONE (see LHO aLOG 47167)
    (iii) Truly identify ETMX all 8 violin mode fundamentals and their harmonics to update the PUM dynamical model (needs IFO time), finish fitting the UIM transfer function data to update the UIM dynamical model (needs Kissel time)
    (iv) Remeasure all stages of ETMX with the full IFO 
        DONE (see LHO aLOG 47206)
    (v) Update the front-end calibration (including reference model parameters at calibration line frequencies such that time-dependent correction factors are accurate), and 
    (vi) confirm success with the full IFO (needs IFO time).

So, I'm currently working on (iii) [with the help of Edgard, Rahul, Borja (#TeamSUS) along with Lee and Lilli #TheFittingCrew] and this aLOG is reporting the progress on fitting the results from the 2019-03-01 measurements, i.e. (iv) [working with Evan #TeamPyDARM].

Check out the attached .pdfs from each stage below, which are the output of the following script, 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOActuationTFs/process_actuationmeas_20190301.py
after creating a new pyDARM model parameter file,
    ^/trunk/Runs/O3/H1/params/modelparams_H1_20190301.py

TST: MCMC Results 
    Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
    Gain = 4.734e-12 (N/ct)
    Force per actuator signal (current or voltage):
    Gain = 4.433e-11 (N/V**2)

    Actuator gain, H_c (N/ct)              | 4.734e-12 (+2.09e-15,-2.102e-15) or (+0.04415%,-0.0444%)
    Residual time delay, tau_A (usec)      | 10.79 (+0.7573,-0.76) or (+7.02%,-7.045%)


Comments: Except for the sign flaw in the "intermediate results" plot, I'm very happy with the state of the systematic error, I believe the MCMC fit, and I think we're ready push to front-end.

PUM: MCMC Results 
    Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
    Gain = 6.223e-10 (N/ct)
    Force per actuator signal (current or voltage):
    Gain = 0.03038 (N/A)

    Actuator gain, H_c (N/ct)              | 6.223e-10 (+3.339e-13,-3.33e-13) or (+0.05367%,-0.05352%)
    Residual time delay, tau_A (usec)      | 4.096 (+1.568,-1.571) or (+38.28%,-38.34%)


Comments: There's still something very fishy going on below 20Hz. I don't understand it, and this is under investigation by Evan and I.

UIM: MCMC Results 
    Force per count of longitudinal DAC request (just down stream of DRIVEALIGN bank):
    Gain = 7.498e-08 (N/ct)
    Force per actuator signal (current or voltage):
    Gain = 1.597 (N/A)

    Actuator gain, H_c (N/ct)                   | 7.498e-08 (+2.842e-11,-2.869e-11) or (+0.03791%,-0.03826%)
    Residual time delay, tau_A (usec)      | 57.81 (+1.218,-1.215) or (+2.107%,-2.101%)

Comments: the low frequency data (below 10Hz) is pretty un-informative, and this is where the UIM matters -- BUT I'm not sure we've ever got any better. I'm dividing out the high frequency dynamics of the OSEM bracketry and UIM to PUM violin modes based on old H1 ETMY data for now CSWG aLOG 11212, and that has significantly flattened out the systematic error, so we can now use all the data from 10 to 100 Hz for the fit of the actuation coefficient instead of what we did in O2 which was only use 3-5 points between 10 and 20 Hz. I'm working with Lee to get an updated fit on data that I took on 2019-01-25.

Finally, I show one of the plots from the latest output of 
    https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Common/pyDARM/darm_loop_critique.py
which, unlike the scripts from above is a function, which I called using the following command line,
    python3.6 darm_loop_critique.py --run=O3 --IFO=H1 --DARMmodelfile=modelparams_H1_20190301 --modelFunction=modelPars --outputfile=2019-03-01_critique

This shows the relative contribution of each stage. to the overall actuator to give you a feel for what matters where (now that things have been updated to reflect Sheila's latest work with the PUM crossover).

Comments: 
    - Only the phase is shown, so take the plot with a grain of salt. 
    - In the calibration band (a bit larger than the detection band, between 5 and 5000 Hz), excitingly, the UIM is now *very* unimportant to get perfect. However, I'm interested to see how this plot shapes up once we've fixed the dynamical model (which is currently all this plot has to go on)
    - It is far more important to get both the PUM and the TST stage right.
    - We'll need to resolve this reported frequency-dependent systematic error in the PUM, since it's right in the phase/magnitude mixing region ("the crossover" implies the hand-off between stages only happens precisely at a single frequency. No bueno.)

So -- I continue my work on the PUM as priority.

We also need to retake a sensing function sweep suite, so I can compare the results against and open loop gain model.

Came in to see ALS-Y w/ no beam or really no flashes at all.  Saw a small step in the ETMy & ITMy after the last lock 4hrs ago, so quickly tried returning the optics to their oplev values to when we were locked...but did not see any flashes at all.

We are now going down for the DCPD work for the PSL (WP#8114) for about 30min.

The adapter box that interfaces between the DB9 of the RF photodiode and the DB15 of the TTFSS field box was
opened.  On the DB15 side, there is 1M in series with pins 5 and 13.  These reduce the nominal gain of the
RFPD DC monitor output from -1 to -0.01, which would explain the low number of counts observed.

    Otherwise the number of counts for ADC channel 6 is consistent for the input applied voltage.



  Richard / Peter

I wrote some python code to create cross-correlated DARM spectra over long, glitchy locks.
Stefan balanced the PDs recently, and we saw our correlated DARM noise was fairly high at high frequency.  Stefan supposed this was from glitches, but from this alog, this seems to not be the case.

The info we want from the cross-correlated DCPD spectrum is the correlated noise from the IFO.  We can average away the shot noise like 1/sqrt(N) where N = number of ASD averages.
The problem is we need many averages to integrate away the shot noise.  However, during these locks, we have frequent, strong ESD saturation glitches which spoil the spectrum.  
DTT is not able to "gate" the glitches, i.e. remove them from the timeseries.  This code solves this problem.

Attachment one shows a DARM ASD and DARM CSD between the OMC DCPDs during the lock last night.  I have 2000 averages with a binwidth of 0.2 Hz and 50% overlap, or 1.4 hours of data.  During this time there were 4 glitches which spoiled the spectra (the blue, purple, and green traces).  With gating we have the red and orange traces.
Attachment two shows a zoomed in gate function of one of these glitches.  The gate I apply is just a logistic function with the mean of the data added in.  The glitches are witnessed via the DARM BLRMS increasing to huge values, specifically H1:OAF-RANGE_RLP_3_OUT16 going above 100 counts.
Attachment three shows the DARM OMC DCPD data with and without the gate applied.  

Code lives in /ligo/home/craig.cahillane/Git/IFO/Crosscorrelations/scripts/gated_DCPD_CSDs.ipynb.  To run you'll have to run:
$ setupanaconda (or $ source /opt/rtcds/userapps/release/cds/h1/scripts/setup_anaconda if your .bashrc alias isn't set up)
$ source activate cragenv
$ jupyter notebook /ligo/home/craig.cahillane/Git/IFO/Crosscorrelations/scripts/gated_DCPD_CSDs.ipynb

Shoutouts to TJ Massinger for help with understanding gating.

In 46983 and 46083 Robert showed that the fan frequencies of the IO chassis at EX were showing up in DARM. After the work today that electrically isolated the EX ESD electronics from the rack it is installed in, it appears that this coupling has gone away.

• First figure: coherence between DARM and the differential ground monitor that Robert set up (between the beam tube and the ESD LNLV chassis). There are several peaks in the 260-290 Hz band that previously had high coherence, and now show no coherence. Also there was a peak at 73 Hz that had quite high coherence (0.9) which is also now not coherent.
• Second figure: DARM spectrum, showing that the 73 Hz peak has gone away, as well as a couple of peaks around 265 Hz. There is a new peak in the post-isolation data at 274 Hz; don't know what this is. Also the post-isolation spectrum is worse at low frequencies, but this seems to be some unrelated scattering shelf that we are currently trying to debug. The height of the 60 Hz peak is the same before and after the isolation. This particular spectrum shows higher sidebands around the 60 Hz, but that's because of the higher low frequency noise we have now; there was an earlier stretch of data where the sidebands were also the same as pre-isolation.

The EX ESD isolation seems to be a good move, and should be considered for the Y end as well.

Dan, Danny,

During the maintenance day we took a trip to EY to have a look at the HWS which has not been outputting any useful information. We took the plate off and noticed the beam was significantly pitched to the left. We recentered it and drove ETMY pitch and yaw with some sinusoidal signals and saw the equivalent in the HWS prism channels. We put the plate back on and have waited for a power up to check what we see. A video is attached. So it seems to be measuring the IFO beam absorption, it just has the wrong sign still. We're thinking of doing a small ETMY ring heater pulse to see how the HWS sees that. That should give the same result as all the other ring heaters.

When re-locking after maintence day today, we have what looks like large scattering shelves in DARM (starting around 2:03 UTC march 6th).  

Update: I accidentally increased the gain in the OMC ASC loops during maintence today, which caused large scattering shelves.  We can use this data to estimate scatter noise from the OMC for normal ASC drive levels. 

While looking for the cause of the large scattering shelves, we also found that turning off the cut-off filter for MICH P greatly reduced the scatter, and the 0.5Hz noise in our ASC signals.   After reducing the OMC ASC gains, we tried to engage the MICH P low pass again, which caused a large scattering shelf, and caused the ASC signals to ring up.  

The high gains were on in lock from about 2:30 UTC until about 9:05 UTC on March 6th.  The MICH P low pass was off from 8:13 UTC to 8:43 UTC, while the OMC ASC was still in high gain.  This would be a good time to use to estimate the ambient level of the scatter. 

TITLE: 03/05 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

Maintenance roughly ended just after noon.  There was single bounce work for Squeezer in the afternoon. 
Initial Alignment Notes:  Then an Initial Alignment was run---ALS X-arm was pretty misaligned, but Patrick was able to restore it after some aggressive slider moves (and had to wait quite a bit for ASC signals to converge before offloading).  SRC was fairly misaligned and this required tweaking SR2 pointing on the AS_C PD.  Once this was centered, Patrick was able to lock the SRC.

Locking Note:  IR was not found.  Diff Offset slider was moved to maximize TR-X_NORM (blue on StripTool), but it only made it to about 0.45.  Georgia suggested we get this value to 1.0 by taking the TRX_QPD_B_SUM's offset from -1.2 to 1.0.  This did the trick.  The offset was returned to -1.2.
LOG:

• Contractors:  Pest Control (w/ Chris), gardeners, toilets, paradise water
• 13:10 PSL work (Peter & Rick)
  • 16:40 
• 16:05-18:05 EX PCal Measurement (niko.kara.sharan)
• 16:15-17:31 EY & EX HEPI level check + Dust Monitor Pump check (Hugh, Jeff B)
• 16:26 SR3 oplev laser swap (Jason)
  • ~16:40 Jason going to PSL afterward for 
• 16:27 EY booster pump work (kyle)
  • Not completed
  • valving out the 
• 16:29....IMC locked & ISC guardian tried going to NLN!  (talked to PSL & PCal groups and they didn't do it, so taking IMC to DOWN!)
  • Took IMC to MANUAL--->OFFLINE
  • Pausing ISC_LOCK appeared to do the trick. 
• 16:40 EX ESD Power Suppy isolating (Richard, Fil, later joined by Ed, Rich)
• 16:53 Checking SEI guardian changes from last week....will be mindful to not interfere EX PCal work  (Jim)
• 17:32-18:59 EY HWS Troubleshooting (Danny, Dan)
  • Transitioned to Hazard
• 17:36 Heading to LVEA for parts (Gerardo)
• 17:39-17:49 Amber tour in control room
• 17:39 EX CP8 LN2 delivery
• 17:41 LVEA CP1 LN2 delivery
• 17:54 3IFO checks in LVEA (Bubba)
• 17:54 FAMIS tasks in LVEA (Chris)
• 18:14 Moving parts in lvea (jim, betsy)
• 18:18-18:38 EY Pcal Alignment check (niko)
• 18:36 DAQ/GDS work beginning (Dave, Jonathan, Greg)
• 19:30 HWS x Temp sensors (TJ)
• 20:08 EX Beckhoff restart
• 20:08 PSL crew done
• 20:13 Single Bounce measurements (Sheila, Nutsinee)
• 22:33-23:17  Gerardo to HAM1
• 22:37 Sqz work (sheila, nutsinee)
• Late afternoon:  Swapping GPS clocks at End stations (Dave)

Today, while doing some cabling for PSL Picomotors, I noticed that the clamping of hte PZT actuator doesn't look right (see attached photos).

It seems that the screws that apply the clamping force, thus constraining the PZT body between the upper vee and the lower vee (and compressing the viton damping cylinder in the process) were not sufficiently tightened.

The PZT actuator cylinder appears to be floating on top of the viton cylinder, lightly constrained by the upper vee, but not the lower one - there is an obvious 1-2 mm gap between the PZT cylinder and the lower vee, on both sides.

To aid the diagnosis of RF whistles (aka arches), I tried a matlab script that LLO has been using. It essentially just makes normalized spectrograms of channels that are good witnesses of the whistles. The attached plots are the outputs from running this script on data from last night's lock, around 10:00:00 UTC. The whistles/arches are clearly visible in the OMC PI (parametric instability) readout channel up to 32 kHz; they're also quite visible in IMC_F and PRCL (8 kHz and below). At this time the IMC VCO frequency was between 78.781 MHz and 78.794 MHz.

The script is 'look_for_arches.m', and is in:  /ligo/home/peter.fritschel/Whistles/

Filiberto, Ed, Richard, Rich A

ETM-X ESD drive system has been floated from any connection to ground.  After establishing that the whole system is floating WRT rack or building ground, we made a single connection to the beam tube as a reference point (see attached PDF diagram)

Summary of Actions:
I. For cable HI-SUS-ETMX-90 cut pin 8 (and unused pin is by accident) to remove a ground
in the D1100809 AA Chassis Interface Board (CH I to 6) input connection. The actual cut was made in the gender changer on the front panel D 15 monitor output of the HV AMP. This cable is the HV monitor read back for the HV Amplifier Box.
2. Removed all rack ground connections in remote DC power supplies.  The returns of all the DC outputs were previously connected to the rack/building ground
3. Connected the HV Amp & LV AMP to beam tube ground next to ESD rack.  This is the single ground point for the ESD system
4. Installed dielectric breaks between rack and HV ESD amps
5. Verified entire ESD system is floating, then deliberately grounded to beam tube
6. Lifted cable shield connection on cable H1-SUS-ESD-5 at the LV Driver PI input connector (D-I 5)
7. Lifted cable shield connection on cable H1-SUS-ESD-6 at AA input (LV Driver monitors D-9)
8. Restored ground voltage mon (PEM) between beam tube & top of LV ESD Amp
9. Transitioned back to permanent ESD DC supplies in remote DC racks
10. Swapped HV preamp back to the one that was originally installed in EX so the 3RD IFO unit can be
returned to the H2 building

I examined a DARM spectrum with 0.0005Hz frequency resolution and used this to identify new second order violin modes, and more precisely determine the locations of previously identified modes.  I have created both damping filters and monitor filters for the following violin modes:

ETMX mode 11: 1006.439Hz
ETMX mode 12: 1006.745Hz
ETMX mode 13: 1010.356Hz
ETMX mode 14: 1010.581Hz
ETMX mode 15: 1011.063Hz
ETMX mode 16: 1013.869Hz
ETMX mode 17: 1014.091Hz

ETMY mode 11: 1000.061Hz
ETMY mode 12: 1000.423Hz
ETMY mode 13: 1009.932Hz
ETMY mode 14: 1017.985Hz
ETMY mode 15: 1018.238Hz
ETMY mode 18: 1000.294Hz
ETMY mode 20: 1000.307Hz

ITMX mode 11: 995.177Hz
ITMX mode 12: 995.462Hz
ITMX mode 13: 998.083Hz
ITMX mode 14: 1001.843Hz
ITMX mode 15: 1001.940Hz
ITMX mode 16: 1002.859Hz
ITMX mode 17: 1003.120Hz
ITMX mode 19: 998.018Hz

ITMY mode 11: 991.641Hz
ITMY mode 12: 991.828Hz
ITMY mode 13: 994.801Hz
ITMY mode 14: 995.053Hz
ITMY mode 15: 997.618Hz
ITMY mode 16: 997.785Hz
ITMY mode 17: 998.967Hz

All of the damping filters are 0.1Hz wide, and all of the monitor filters are 0.02Hz wide.  I have updated these modes in lscparams.py, and included the filter settings which have successfully damped the violin modes.  There are a couple of damping filter settings which I have not tested as thoroughly as I would like to, and I have left these commented out in lscparams. There are also a couple of modes for which I, following Jenne's suggestion, left the maximum gain at a lower value than it could be set at, and included a higher value in a comment.

I've updated the violin mode wiki to reflect these changes.  The updated version can be found at: https://cdswiki.ligo-wa.caltech.edu/wiki/Violin_Mode_Table_v2 

There are 32 second order violin modes, and we still do not know the corresponding test mass for 3 of them.  These are at frequencies 998.825Hz, 1009.950Hz, and 1011.332Hz.  ETMX, ETMY, and ITMY each have on of these modes on them.  However, these 3 modes are relatively dormant, so are currently a low priority. 

We still have no consistently helpful settings for the damping filters on ETMY modes 18 and 20.  But I have had success with mode 20 at 90 degrees, gain=2, and mode 18 at either 30 or 60 degrees, gain=2.  Each of these settings seems to work individually, but not at the same time.  Creating narrower damping filters might be wise for these 2 modes.  We should exercise caution in damping ETMY modes 11 and 12, as these damping filters tend to very slowly drive up ETMY modes 18 and 20.

I have begun to update the medm SUS_CUST_VIOLIN_OVERVIEW.adl to include the 2nd order modes, to the right of the first order modes.

Attached is a spectrum of the violin modes before and after damping, taken during Friday's lock. A few modes remain undamped in the image because we lost lock before I did it.