We have had other difficulties locking today, with the CARM offset reduction. 

Last sunday, after the computer crash we had moved the VCO compensation filter in the TR CARM loop which used to be engaged when we transitioned to TR_CARM to later in the locking sequence, and we never understood why that was necessary.  Today we moved it back to earlier in the sequence and that has improved the stability of the TR CARM loop.  We also have been sometimes manually deceasing the gain in this path a bit to give us more stability through the CARM offset reduction.  We tried to put this into the guardian once, but that didn't work so we have removed it again.

Model has been restarted with new channels.

on h0epics, I started the following EPICS IOCs: dewpoint_sensor, dust[lvea, lab, ex, ey, dr], weather[ex, ey, mx, my]

J. Kissel

I've changed common PCAL MEDM screen to support the new FORCE_COEFF_CHECK_SW. Attached shows switch functionality ON vs OFF.

Changes committed to 
/opt/rtcds/userapps/release/cal/common/medm/
    PCAL_END_FORCE_COEFF.adl

J. Kissel

Modified MEDM screen for EPICs records addition of PCAL_LINE1 channels described above (EP19-23).

Changes committed to 
/opt/rtcds/userapps/release/cal/common/medm/
    CAL_CS_TDEP_EPICS_RECORDS.adl

Screenshot attached.

Would it be possible to add more detail to this? What is the metric you're using to determine the alignment?

The metric we are using is the amount of deflection we see on the AS_A and AS_B photodiodes (with the IFO in single bounce)

We are currently using the following method to align: 

• Make sure you are not clipping on the mirror apertures or baffles using the red alignment laser and can see the transmission of the red laser onto the SRM-HR baffle through the viewport adjacent to the Zn-Se viewport. 
• When scanning the back of the SRM with the CO2 you expect the CO2 to create a wedge as you get close enough to the ifo beam which corresponds to a strong deflection on the aforementioned PDs
• If given enough range, you should be able to pass the CO2 over the ifo beam which would correlate to the behavior shown in the figure attached (I use yaw as the example). 
• Fine tune alignment to achieve State B. 

Results:

• We have used this method to achieve good centering in pitch. 
• In yaw, we see the behavior in State A (in the figure) but we start clipping on the SRM-AR baffle before we can start to see State B and State C. 

Here's the analog electronics measurement setups for this data.

This time (unlike the 2016 attempt; see the last page of LHO:24725), we tried to cut corners by only driving the coil drivers with single-ended input directly from the SR785 -- so we can avoid having to characterize the details of the differential driver box that has been used previously. This failed, causing (what we believe to be saturations) of the coil driver electronics and wonky unphysical transfer functions. This is especially evident with the PUM driver's switchable "acquire" circuits engaged, and in the UIM driver after the second and third low-pass filters are in engaged. Finally, comparing against measurements taken with the coil driver monitor circuits (LHO:46854) it's dreadfully obvious.

More investigation is required as to what's going on, but sadly those investigations take time that we don't have.
I'm proceeding with attempting to fit a combination of the un-spoiled SR785 data and the less-complete-and-more-complicated monitor circuit data taken with DTT (again, LHO:46854).

The ESD driver measurements (at least) appear to be good enough to move forward, as indicated by the table of results above.

Using the data from Jeff and Rich's measurements, I have fitted the ESD driver electronics. However, I ran into problems when trying to fit the PUM and UIM measurements. The raw output of the transfer function measurements looks unfamiliar to previous measurements and has puzzled Jeff and Rich when I showed it to them.

1) Summary plots from ESD driver measurements and fits
2) Puzzling PUM driver measurements
3) Puzzling UIM driver measurements

Scripts for analysis of the data is located at:
$CALSVN/trunk/Common/Electronics/H1/Scripts/model_ETMX_*_20190203.m
and plots are found at:
$CALSVN/trunk/Common/Electronics/H1/Results/SUSElectronics/ETMX/[UIM,PUM,TST]/2019-02-03/

The fit results for the ETMX ESD driver electronics is given below.
Quadrant                   Low pass [z;p] (Hz)                             Summing node [z;p] (Hz)
-----------------------------------------------------------------------------------------------------------------------
UL        [13.871+/-0.721, 15.668+/-0.748; 2.186, 2.186]       [129.736e3+/-2.818e3; 3.213e3+/-15.78, 31.549e3+/-381.9]
LL        [13.666+/-0.817, 15.570+/-0.850; 2.163, 2.163]       [90.736e3+/-694; 3.177e3+/-7.088, 26.699e3+/-145.6]
UR        [14.9049, 14.9054; 2.2222, 2.2223]                   [93.521e3+/-729; 3.279e3+/-7.534, 26.617e3+/-146.2]
LR        [13.335+/-0.486, 15.861+/-0.513; 2.157, 2.157]       [131.520e3+/-2.867; 3.238e3+/-15.9, 31.618e3+/-380.8]

Note above that the UR quadrant fit looked odd when looking purely at magnitude residuals. We saw that there was about a 1% offset in the band of primary interest (1 Hz - 1 kHz) above ~30 Hz which we attribute to the fact that LISO is attempting to minimize the fit error on both magnitude and phase simultaneously. When fitting purely on magnitude, the discrepancy is greatly reduced, at the cost of a slightly larger wiggle on the phase error (still less than a degree).

These have not yet been installed into the SUS output filter banks, but should be done so at the next opportunity.

We will ruminate on the PUM and UIM measurements and attempt to repeat these, again, at the next opportunity.

We found a filter that wasn't supposed to be on (an anti-whitening for a build-in whitening filter inside a PD, which OPO refl doesn't have). Fixed the mW2V gain (now 40) and the UGF of the intensity loop is now 100Hz. It no longer glitch when we turn the loop on. We also found that the whitening filter was turned off, which worked for the analog setup we used to have.

Noting R3 mode frequencies for each QUAD measured from the TFs (n.b. most recent L1 TF data is taken in 2018 and most recent H1 data was from taken in 2014):

L1 ITMX = 3.32 Hz
L1 ITMY = 3.32 Hz
L1 ETMX = 3.188 Hz
L1 ETMY = 3.195 Hz

H1 ITMX = 3.32 Hz
H1 ITMY = 3.31 Hz
H1 ETMX = 3.01 Hz
H1 ETMY =  No TF Data

Some simulation work related to this measurement.

From galaxy, I find that LHO's ITMX (ITM07) has a reflectivity of R_ITMX = 1.50%, while LHO's ITMY (ITM11) has a reflectivity of 1.42%. So there's quite an imbalance there.

I set up a simple simulation, using only the TEM00 mode, so without including any mismatch. Each arm has about 92 ppm of total round trip losses, following Craig's estimate. The first plot below shows some powers as a function of the two ITM reflectivities. 

The red dot represent the nominal condition, which gives, for 1 W input power

PRG = 42.3
REFL = 17 mW (carrier only, TEM00, perfect matching)
AS = 0.9 mW (carrier only, TEM00m, perfect matching, nominal DARM offset of 1.2e-11 m
XARM = 5536 W
YARM = 5848 W
X/Y = 0.946 [more power in Y arm than X arm]

So there is more power in the Y arm than in the X arm, as one would expect since ITMY has higher reflectivity, so that the Y arm has higher finesse.

I also tried to reproduce more closely Craig's SRCL dither measurement. So in simulation, I computed the transfer function from SRCL motion to the RIN as measured in transmission of both arms. The plot below shows the simulated transfer functions RIN_ARM / SRCL for X and Y:

The numerical values are

RIN_X / SRCL_z = 1.088e6 /m
RIN_Y / SRCL_z = 1.034e6 /m

so (RIN_X / SRCL_z ) / (RIN_Y / SRCL_z) = 1.052. This is the ratio of powers, since the simulated transfer functions from SRCL to powers are equal for both X and Y, so the transfer functions to RIN are scaled by the inverse of the power. 

Craig's measurement is actually the transfer function DARM / RIN while injecting on SRCL. In simulation, I used the AS port power as a proxy for DARM and computed the transfer functions TF(AS_DC / SRCL) and TF(RIN / SRCL). Then the equivalent of Craig's DARM / X and DARM / Y should be, at 30 Hz,

TF(AS_DC /  SRCL) / TF(RIN_X / SRCL) = 98.4 W
TF(AS_DC /  SRCL) / TF(RIN_Y / SRCL) = 103.6 W

and the frequency dependency is shown in the plot below (1/f^2 as expected).

So the equivalent of Craig's ratio (DARM / Y) / (DARM / X) should be 

[ TF(AS_DC /  SRCL) / TF(RIN_Y / SRCL) ] / [ TF(AS_DC /  SRCL) / TF(RIN_X / SRCL) ] = 103.6 / 98.4 = 1.053

which is greater than one as in Craig's measurement, but corresponds to the ratio POWER_Y / POWER_X. 

So the conclusion from my simulation is that the ITM different reflectivities gives a ratio of TF (as measured by Craig) greater than 1, which corresponds to higher power in the Y arm than in the X arm (the opposite of what Craig's concluded...)

I didn't know that the ITMs were not the same reflectivity.  This is absolutely mind-blowing information.
I reported higher arm power in the Y arm before, from the HEPI measurement.  
The RIN/SRCL TF corresponds to Equation 12 here.  It is not dependent on the arm power at all, but rather the optical response γ of each arm to the SRCL dither.
Also, the DARM/RIN TF in Equations 20 and 21 also indicate that DARM/RIN = 4*Parm/(m c ω2), so I made a mistake last night.

Good that the measurement and the prediction agree that there is more power in Y than in X.

Now we have to figure out why the measurement gives 8% imbalance while from the ITM reflectivities we only get 5%.

Updated simulation: 

1. added higher order modes (n+m<=10), measured test mass radii of curvature
2. locked DARM to have an AS power that corresponds to 20 mA at 26 W input power (1.25 mW on the OMC transmission for 1 W input)

No change in the conclusions. Same imbalance of the arm powers as before (about 5%) 

Adding the substrate lenses do not change significantly the power imbalance. 

ITMX: static lens -310km, thermal lens +770km
ITMY: static lens +570kn, thermal lens +350km

Follow up to the discussion at today's commissioning call.

I computed the transfer function from laser relative intensity noise at the IFO input (called rin below) to DARM (calibrated in meters). 

The input power is 26 W, and the round trip losses are adjusted to get a recycling gain of about 42. In the blue trace below, the two ITMs have the same reflectivity, equal to the nominal value of 1.4%. In the orange trace the two ITMs have different reflectivities, ITMX = 1.50% and ITMY = 1.42%, from the measured values from galaxy. This is the same configuration used in the other simulations, that gives a 5% power imbalance. 

The dashed green curve is a simple radiation pressure model according to the equation below:

where RIN_arm / RIN_input is basically the double cavity pole (since input RIN is filtered by this transfer function. I used the simulated result), Delta P is the DC power difference in the arms ( Y - X = 7.7 kW) and m is the mirror mass. This matches quite well the low frequency simulation.

Using the simulated transfer function I can see what level of RIN at the IFO input would limit the sensitivity. It turns out that one needs a RIN of about 5e-6 (W/W)/rHz. 

I found a mistake in my previous RIN simulation (many thanks to Matt Evans for spotting the inconsistency). Here's the correct results and plots.

Follow up to the discussion at today's commissioning call.

I computed the transfer function from laser relative intensity noise at the IFO input (called rin below) to DARM (calibrated in meters). 

The input power is 26 W, and the round trip losses are adjusted to get a recycling gain of about 42. In the blue trace below, the two ITMs have the same reflectivity, equal to the nominal value of 1.4%. In the orange trace the two ITMs have different reflectivities, ITMX = 1.50% and ITMY = 1.42%, from the measured values from galaxy. This is the same configuration used in the other simulations, that gives a 5% power imbalance. 

The dashed green curve is a simple radiation pressure model according to the equation below:

where RIN_arm / RIN_input is basically the double cavity pole 0.6Hz/fr (since input RIN is filtered by this transfer function), Delta P is the DC power difference in the arms ( Y - X = 7.7 kW) and m is the mirror mass. This matches quite well the low frequency simulation.

Using the simulated transfer function I can see what level of RIN at the IFO input would limit the sensitivity. It turns out that one needs a RIN of about 2e-7 (W/W)/rHz. 

Doesn't this 2e-7 /rtHz RIN seem dangerously close to the measured value at 30Hz?

The intensity noise projection in the noise budget is made by injecting into the ISS second loop.  It shows that the intensity noise is not close to DARM.  45828

Following models were changed to remove ODC completely and compiled but not installed. Deferred to another opportunity.

h1ascimc (1 IPC sender (PCIE) and an entire ODC block were removed, doesn't use the library, one less fast channel on the frame)

h1pslpmc (1 sender (SHMEM) as well as an entire ODC block was removed from h1 model, ODC-related things were purged from the library, no change in fast channels)

p1psliss (2 receivers (SHMEM) for FSS and PMC as well as two ODC blocks were removed from h1 model, ODC-related things were purged from the library, one less fast channel on the frame)

h1pslfss (1 sender (SHMEM) as well as an ODC block were removed from h1 model, ODC-related things were purged from the library,  no change in fast channels)

h1tcscs (1 sender (SHMEM) as well as an ODC block were removed from h1 model, ODC-related things were purged from the library, one less fast channel on the frame)

h1iscex (done by Jamie, no change in fast channels)

h1alsex (1 sender (SHMEM) as well as an ODC block were removed from h1 model, doesn't use library, one less fast channel on the frame)

h1alsey (1 sender (SHMEM) as well as an ODC block were removed from h1 model, doesn't use library, one less fast channel on the frame)

h1lsc (1 sender (PCIE) and an ODC block are removed from the h1 model, doesn't use library, one less fast channel on the frame)

h1omc (1 sender (PCIE) as well as an ODC block were removed from h1 model, ODC-related things were purged from the library, one less fast channel on the frame)

h1pemex (1 sender (SHMEM) as well as an ODC block were removed from h1 model, doesn't use library, no change in fast channels)

h1pemey (1 sender (SHMEM) as well as an ODC block were removed from h1 model, doesn't use library, no change in fast channels)

all SEI models at the end stations (done by JeffK)

Following models are yet to be changed.

all sus models (TBD by JeffK)

Update on Jan 22

During the maintenance on Jan22, the following models without ODC were installed.

h1lsc, h1ascimc, h1omc, h1iscex, h1alsex, h1alsey, h1tcscs, h1pemex, h1pemey.

(h1asc was updated and installed for something unrelated to ODC.)

Remaining frontends that are yet to be replaced with new ones without ODC:

All SUS (models are yet to be changed/compiled).

All end station SEI (models are ready).

h1pslpmc, h1pslfss, h1psliss (models are ready).

Remaining frontends that will be changed again after new HW injection infrastructure is confirmed to work by transient injection group(s):

h1calex (model is yet to be done, PINJX will be completely removed).

h1odcmaster itself (this will be retired).

Update Feb/04/2019

All SUS models were modified to remove ODC, compiled successfully, but not installed. These are:

h1susetmx, h1susetmy, h1susitmx, h1susitmy, h1susbs, h1suspr3, h1suspr2, h1susprm, h1sussr3, h1sussr2, h1sussrm, h1susmc1, h1susmc2, h1susmc3, h1susomc, h1susopo, h1susim (and h1sustmsx and tmsy and h1sushtts on Feb/05/2019)

One PCIE IPC sender and one fast channel were removed per each model, as well as many EPICS channels. One new EPICS channel (ODCCHAN_PLACEHOLDER) was added per each model.

Library parts (QUAD_MASTER, QUAD_ITM_MASTER, BSFM_MASTER, HSTS_MASTER, HLTS_MASTER, OMCS_MASTER, OPOS_MASTER) are still compatible with old models, so if you want to compile any of old sus models with the new library you can. In that case ODC IPC will be plugged to zero.

Attached are typical before/after view of the library parts.

Boo. I just assumed that MC1, MC2 and MC3 all use HSTS_MASTER library part, but MC2 actually uses MC_MASTER part. I only edited HSTS_MASTER and individual model (h1susmc1, 2, 3).

As a result, ODC was not completely removed out of h1susmc2. This is going to be fixed in the next opportunity.

Keita and Rahul

Keita showed me how to make changes to the front end model of SUS. We made changes to MC_MASTER library parts to remove ODC. We complied h1susmc2 successfully, however we didn't install it.