Tonight during the PI measurements we switched on the ETM ring heaters commonly to 2.5W. This made our arm-prc mode matching worse shown by a drop in the PRG.

During this time the ITMY HWS measured a reasonable drop in lensing, whereas ITMX did not, which has introduced a differential lensing. I'm not sure why ITMY has been so sensitive to this change. Currently we are down to about 45 and the arm power/RF18/PRG has become choppy looking, previously during large TCS changes when this has happened the choppiness has got worse and we lose lock more readily. However it looks like it might be leveling off around 45 now. Previously when dropping CO2Y power compared to CO2X I also a RF18 increase.

On Friday I did ISS injections at 3 different DARM offsets.  The change in the DARM noise for different DARM offsets can't be explained by these injections. 

The first attached plot shows the coupling from RIN on the ISS second loop (input beam) to mA on the DCPDs for the three different DARM offsets. At high frequencies the transfer functions from RIN to mA would be the same for different DARM offsets if the intensity noise was coupling through contrast defect light.  

The second attached plot shows intensity noise projections for all three DARM offsets.  I didn't correct the optical gain in the calibration for the 7.2 and 37.2 mA plots, so the calibration is off.  In any case, these projections are at least a factor of 10 below DARM.  This doesn't rule out intensity noise on the sidebands.  

For those who are interested the times of these injections are:

UTC times, December 8th 2018

20mA Injection:  7:55:12 quiet time: 7:49:44 

7.2 mA Injection: 7:59:26 UTC quiet time: 8:00:36

37.2 mA Injecton: 8:02:54 UTC quiet time: 8:04:25

Summary

This is an update on my previous activity on the characterization and subtraction of the non stationary SRCL coupling. See 45403 and 45508 for an introduction to the problem and methodology. In those elogs I developed a frequency domain method to compute how ASC signals modulated the SRCL to DARM noise coupling. In addition to that technique, I now have a parametric algorithm, that is capable of directly finding the optimal parameters to be used to implement stable and realizable time domain subtraction filters. For those of you familiar with Wiener filtering, this technique can be viewed as an IIR Wiener filter that also includes noise coupling modulations. More details on this technique are available in the DCC T1800525.

Here, instead of using the same data that I analyzed for 45403 and 45508, I used Rana's noise injection (45803 and 45792). In 45803 I derived the optimal filter to subtract the stationary coupling from SRCL_IN to CAL-DELTAL_EXTERNAL, using data without any noise injection. Here instead I used 150 seconds of data starting at GPS 1228458231 while there was a SRCL noise injection. My algorithm was tuned to use 16th order coupling transfer functions, and all ASC input signals as modulation sources.

First of all, the money plot. The blue trace is the CAL-DELTAL spectrum during the SRCL noise injection, while the purple line is a reference from a few minutes before that, when there was no injection. The red trace is the best subtraction we can obtain using only the static, linear transfer function from SRCL_OUT to CAL-DELTAL. The green trace instead is the level of subtraction we can achieve including all non-stationary contributions. It is quite close to the DARM noise floor. The SRCL noise coupling reduction we obtain here is somewhat lower than what I could obtain in 45508: my guess is that is due to the fact that the SRCL injection was not as strong as the one that I did, so there was not enough SNR to extract even lower modulated contributions.

Nevertheless, by including the non-stationary contribution we can gain a factor of a few subtraction at all frequencies.

More details below

The plot below shows the reconstructed coupling transfer functions. Each panel correspond to one noise source, i.e. SRCL_OUT multiplied by the ASC signal in the title (where '1' means just a constant signal equal to one, that is, the stationary channel). The noisy traces in the background are the frequency domain direct solutions, while the solid smooth traces are the 16th order transfer functions obtained with a special s-domain transfer function parametrization that enforces the pole stability (and causality). The blue traces are the absolute values (refer to the left y axis) and the orange traces are the phases (refer to the right y axis).

The contributions are sorted based on a ranking which computed what is the contribution of each modulation to the total noise subtraction, integrated between 10 and 400 Hz in this case. The numerical ranking of each ASC channel is reported below

Another way to look at this is to plot each contribution in a spectrum of DARM, as below:

h1omcpi and h1omc were changed and compiled but not installed (that's for Tuesday).

In h1omcpi, a decimation filter was put between the drumhead mode RMS (64kHz) and shared memory as the omc model works at 16kHz.

Alignment dither oscillators are common for deacon and normal dither. An input matrix is used for selecting the source of demod. This makes it cumbersome to switch between low frequency dither for deacon and high frequency dither for normal dither, but once deacon works it won't be an issue.

WP7995

WP7997: inverse ring heater filters added to h1tcscs, output sent to Beckhoff

WP7996: replace model ezca(read,write) parts with EPICS parts, CDS_CA_COPY guardian node handles data transfer

Danni, TJ, Dave:

h1tcscs model was changed to:

replace all existing EzCaRead parts with EpicsIn parts

add two filters for ITMY_RH_[UPPER,LOWER]_INVERSE_FILTER

send the output of the two new filters to EpicsOut parts

See attachment for simulink model details.

TJ created a new Guardian node called CDS_CA_COPY which will handle all EPICS Channel Access copies between front end models and slow controls IOCs.

The initial CDS_CA_COPY is just copying the input SET channels to h1tcscs. We will expand it to other copies later, including replacing the current camera_copy script.

The Guardian MEDM and the new H1CDS_CA_COPY_CUST.adl are shown in attachments. The latter is accessed via SITEMAP->CDS

TITLE: 12/10 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:

Able to get some time/experience with locking (notes below).  There were some model changes for TCS & Guardian (+ DAQ restart) to aid with overnight AMD measurements.

My Operator Locking Notes Today: 

• DRMI locking has been taking ~5min+ to lock.  If takes longer, lock PRMI (tweak BS & PRM).
• Take to DRMI_LOCKED_CHECK_ASC.
  • Good signs to look for when locking:  POP18 & RF90 large flashes on StripTool & ASAIR video has strong TEM00 flashes.
  • Can touch SRM while locking if its taking a while...this worked for me once
• For a locked DRMI:
  • Video:  ASAIR should be symmetric
  • StripTool:  POP18 (pink) & RF90 (green) should be flat & maximized.
  • If alignment needed, move SRM & PRM (Do this at CHECK_AS_SHUTTERS)
•  Have been taking to PREP_ASC_FOR_FULL_IFO.  If ASC signals look ok, then go to ENGAGE_DC_VIOLINS

LOG:

• Overnight crew working on AMD measurements (Terra & Seb)
• Morning crew of Jenne working on locking
• 16:41 Check of PSL Chillers (Jeff B)
• 17:30 LVEA & VEA Cleaning (Karen, Vanessa)
• 18:17 ETMx SUS model (for PI Modes) [JeffK, Dave]
• 19:05 Pfieffer at MY (JeffJ, Chandra escorting)
• 19:00-19:57 ISCT6 work (Nutsinee)
• 21:24 - 22:24 Pfieffer tour.  Note:  DRMI lockloss when group near HAM2 at entry & exit. (Chandra)
• 21:49 (& back out at 0:00) ISCT6 work (Nutsinee)

Patrick, Jenne

I have added filters for the second harmonic violin modes to the mode 11 - 17 filter banks for ITMX, ITMY, and ETMX, and the mode 11 - 15 filter banks for ETMY. I have also updated lscparams.py to set these, with the max gain for all of them set to 0 for now.

IM2 starts during 9 dec 2018 17:19:26, GPS  1228411184, and it continues to move  away from nominal until around 21:00, and recovers to a reasonable alignment 23:30:

MC1 also has a glitch, which in diaggui looks to start after IM2.

Attached Plots:

• entire IM2 event
• the start, showing IM2 and ISS second loop QPD, the QPD suggests it starts earlier than IM2
• close up of the start showing that at 0.62s into the plot, MC1 and IM2 are

The HAM & HEPI models are supposed to get an update similar to the one the BSCs got last week, but unfortunately the new code didn't include a path for the GND Z to HAM4 Y sensor correction that I put in last week. I have a workaround, but it's not as flexible as the set up we currently have. The current model uses a 9x6 sensing matrix that lets us route any DOF of the 3 corner STS2s to any X/Y/Z of the corner chambers just by changing an epics value, but the new update eliminates that sensing matrix. There is, however, an unused spare input which I luckily have opted to send the GND Z signal into all models, because it was easy. This spare signal used to just get grounded inside the sensor correction block, but now I would like to send this spare channel through a filter bank and sum it with the output of each of the new X/Y/Z sensor correction paths as shown in my attached screenshot. The GND_SPARE_DOF filter banks are the new stuff. This limits me to using whatever signal I send into the spare path at the top level of the model, and if that needs changed, it will require a model change.But so far, I only need the GND Z to HAM4 Y path. 

Seb, Terra

Thanks to Craig and Dan's dedicated locking efforts last night, we've measured a full suite of test mass mechanical mode Qs post all AMDs. Results here. We see reduction of Q for all modes above 9kHz; 15 kHz modes see reduction factors of at least factor of 10. Measurements done at 2 W input power for least parametric gain contribution and consistency with the few pre-AMD measurements we have.

Reminder that parametric gain R_m ~ Q_mP_arm where Q_m is quality factor of the mechanical mode, P_arm is the power in the arm cavity, R_m > 1 is unstable. In the attached table, we note pre-AMD Qs from what measurements I could find quickly from the last two years. The last column shows predicted Qs from sec 4.11 in Seb's thesis (note these differ from the predicted Q's in 38129 as the latter were before a change in the modeling of the epoxy layer realized after the results of the ETMX AMD test). I also attach the modeled max parametric gains at P_arm = 750 kW pre and post AMDs from Seb's thesis to give some context.

To check if modes at 23kHz are aliased, we checked the frequency shift over a 4 hour lock and all but one look to be not aliased (they slightly increased in freq along with drumhead modes). 

We have a few anomalies/poor fits that we'll try to remeasure in the next few nights. 

D. Barker, S. Biscans, T. Hardwick, J. Kissel
WP 7994

Terra and Sebastien discovered that when we upgraded the SUS ETMX I/O chassis to use a 20-bit DAC (LHO aLOG 44905), and upgraded the h1iopsusex and h1susetmx models accordingly (LHO aLOG 44918), we forgot to upgrade the front-end model for parametric instability (PI) drive, i.e. h1susetmxpi, in order to recognize it.

This was a quick and easy change to the front-end model (see before vs. after screenshots below, plus the electronics wiring snippet from D1400177), which we installed immediately this morning. No DAC restart was needed, nor did it impact the IFO.

After the install, Terra and Seb have equally quickly confirmed that the drive system is now functional.

The updated simulink model has been committed to the userapps repo:
    /opt/rtcds/userapps/release/sus/h1/models/h1susetmxpi.mdl

I was skeptical about the SRCL noise in the noise budget, so I checked it again. I think it is pretty close.

Its a simple method, but should be accurate. SRCL_FF left on in the Guardian set state in NLN.

1. Turn on broadband noise excitation in SRCL2_EXC with AwgGui.
2. Adjust calibration of SRCL_OUT in DTT until the SRCL_OUT trace matches DARM.
3. turn off excitation to see how the ambient SRCL compares to DARM.

From this exercise I get the attached plot. Looks like its very close in the 40-90 Hz band. Options:

1. better low pass filtering; Downside: this is hard and will make the loop more unstable.
2. lower the SRCL gain: could be fine, but we don't yet know what the allowed SRCL error signal fluctuations are. i.e., how much can the SRC length fluctuate before it goes nonlinear or ruins the WFS signals?
3. improve the sensing noise: more power, more modulation depth, less electronics noise. Do we have a SRCL noise budget?

Since everybody went to the holiday party tonight, I left the interferometer in low noise. After guardian was done, I punched up the input power to 25W (without reducing the DARM offset, i.e. letting the OMC current grow to 25mA), and then increased the DARM offset by another 9% (~30mA). Finally, I blindly increased the SRCLFF by 9% (punching in 1.09 in the gain), and left it there.

Looks like the machine sat there stably at 90Mpc for the whole holiday party... Merry Christmas!

Summary:

We were able to lock the squeezing angle using the 3MHz signal from the OMC DCPD's, and we have caused a few lockloses.  We have found that our locking scheme is introducing a lot of noise, so our next step is to lock the OPO length to the laser frequency.  

Locklosses:

In our first attempt we used the interferometer locked at 2W DC readout to look for the LO error signal.  We caused a lockloss then, and so we then changed to working with the interferometer locked on RF and the OMC locked.  We caused a couple of other locklosses this afternoon, one when the interferometer was locked on RF and the OPO became unlocked with the beam diverter open.  After this we added closing the beam diverter to the OPO guardian DOWN state, and the state CHECK_EOM (which we enter when the TTFSS EOM is railed).  

After successfully locking the squeezer angle, we transitioned to DC readout.  When we attempted to close the beam diverter we lost lock, which we also don't understand.  

We have been injecting ~10uW of CLF (measured on SQZT6), which gives us about 10 dBm of RF on the 3MHz demod.  We are wondering if this is too much and might be part of our lockloss problems.  We tried reducing it by a factor of 2.  

Locking:

Nutsinee will post details of the squeezing angle lock configuration that we used tonight, even though we don't plan to keep using this scheme. 

The basic steps:

• allow the laser temperature servo to bring the beatnote close to the correct frequency. (OPO guardian in down state)
• Lock the squeezer laser to the OPO using the TTFSS (OPO guardian to OPO_LOCKED_CLF)
• Lock the CLF using it's guardian.  
• We then could see that the frequency of the 3 MHz sidebands were not quite right.  We wrote an epics servo, which zeros the difference between the squeezer vs PSL sample (ref cavity) beatnote and twice the IMC VCO frequency, using the timing system frequency readbacks (which update once per second).  This is currently in the guardian called SQZ_PLL in a state called CHECK_BEATNOTE_2, but it will be moved somewhere else and given a more descriptive name.  This can hold us within 100kHz of the correct frequency.  
• We sent the 3MHz signal to both the OPO PZT and the additive offset of the TTFSS.  The additive offset was needed because of a large peak in the noise at around 1 kHz, which is similar to what was seen with the homodyne locking.  Because our locking scheme where the laser follows the OPO (rather than the other way around) introduces a lot of noise, especially at high frequencies, we have a lot of phase noise which means that we need a bandwidth higher than we can get with the PZT only to lock the squeezing angle.  For this reason we introduce an offset in the OPO PDH locking, which allowed us to lock but is obviously terrible. 
• Injecting squeezing in the IFO with this situation resulted in adding a lot of noise.  (See first attachment)

Uncontrolled squeezing:

• The interesting thing is that when we left the beam diverter open but blocked the CLF field and let the squeezing angle rotate, it actually rotates slowly and the large added noise is gone. The second attachment shows the same reference as the first, but with two traces captured with 4 exponential averages at 1Hz, 75% overlap, one showing close to the highest noise that we saw and one showing close to the lowest noise that we saw.  This seems like squeezing and anti-squeezing based on how flat the noise is, but there are two things that are surprising.  While it might be possible that this isn't anti-squeezing at all, it continued for more than 10 minutes without drifting away.  (We were sitting with CLF blocked and the beam diverter open from 4:45 to 4:55, with the OPO locked and the slow servo keeping it's frequency approximately correct.)
  • The level of anti-squeezing seems too high.  Looking between 1100Hz and 11400 Hz, this is almost 17dB of anti-squeezing.  Nutsinee measured the non linear gain to be 3.6, so with our expected total efficiency of 80%, we would expect at most 8dB of anti-squeezing.  (I know, this sounds like I am making a factor of 2 mistake, but I don't think I am.  I'm attaching the dtt file and my script in case anyone wants to double check.)  You might think that the extra noise we see is just some additional noise that we are adding with the squeezer other than anti-squeezing, but at times the noise level drifts down to just a few dB above shot noise. 
  • This squeezing angle is rotating slowly.  With a nonlinear gain of 3.7 and the efficiency of 80%, this would mean that over the 2 seconds of the low noise measurement the squeezing angle only rotated by about 610 mrad, which would be about 100nm of path length change.   We should compare this with the calibrated squeezing angle error signal which Nutsinee will post, but it seems strange that we needed 10's of kHz bandwidth to lock the squeezing angle with  such a slowly drifting system.  

Ryan, Carlos, Jonathan

At 18:56 UTC today, while following up on a note from LLO aLOG #41844 , one of the processes on the core router responsible for maintaining connectivity with our Internet providers encountered a segmentation fault. Carlos and Jonathan were called and they connected to the console to debug with me. The routing process was restarted and reconnected to our providers at 19:10 UTC. I believe this is directly related to the connectivity issues that Keith logged Friday night / Saturday morning and am checking for updates that may be related to the routing process crash issue.