JeffreyK, Darkhan

To test new GDS pipeline that estimates DARM parameters kappa_{tst}, kappa_{p/u}, kappa_C and f_c we've updated reference values that were calculated from ER7 model (see LHO alog #20291 for earlier values).

New values entered for ESD line at 35.9 Hz are

H1:CAL-CS_TDEP_ESD_LINE1_REF_C_REAL 1.2896e+06
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_IMAG -189585
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_NOCAVPOLE_REAL 1.30877e+06
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_NOCAVPOLE_IMAG -59171.7
H1:CAL-CS_TDEP_ESD_LINE1_REF_D_REAL 8.8387e+09
H1:CAL-CS_TDEP_ESD_LINE1_REF_D_IMAG 1.12814e+10
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_TST_REAL -4.38814e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_TST_IMAG -3.39859e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_PUM_REAL -2.61782e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_PUM_IMAG 4.21051e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_UIM_REAL -5.14962e-21
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_UIM_IMAG -2.34929e-21
H1:CAL-CS_TDEP_ESD_LINE1_REF_OLG_REAL -1.05327
H1:CAL-CS_TDEP_ESD_LINE1_REF_OLG_IMAG -0.791652

for PCALY line at 36.7 Hz:

H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_REAL 1.28869e+06
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_IMAG -193725
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_NOCAVPOLE_REAL 1.30872e+06
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_NOCAVPOLE_IMAG -60499.8
H1:CAL-CS_TDEP_PCALY_LINE1_REF_D_REAL 8.99945e+09
H1:CAL-CS_TDEP_PCALY_LINE1_REF_D_IMAG 1.15726e+10
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_TST_REAL -4.2798e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_TST_IMAG -3.22538e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_PUM_REAL -2.41611e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_PUM_IMAG 4.01322e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_UIM_REAL -4.53934e-21
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_UIM_IMAG -1.9945e-21
H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_REAL -1.03047
H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_IMAG -0.772912

for DARM line at 37.3 Hz:

H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_IMAG -0.772912
H1:CAL-CS_TDEP_DARM_LINE1_REF_C_IMAG -196826
H1:CAL-CS_TDEP_DARM_LINE1_REF_C_NOCAVPOLE_REAL 1.30868e+06
H1:CAL-CS_TDEP_DARM_LINE1_REF_C_NOCAVPOLE_IMAG -61495.8
H1:CAL-CS_TDEP_DARM_LINE1_REF_D_REAL 9.12151e+09
H1:CAL-CS_TDEP_DARM_LINE1_REF_D_IMAG 1.17888e+10
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_TST_REAL -4.19953e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_TST_IMAG -3.10345e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_PUM_REAL -2.2773e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_PUM_IMAG 3.87215e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_UIM_REAL -4.13563e-21
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_UIM_IMAG -1.76881e-21
H1:CAL-CS_TDEP_DARM_LINE1_REF_OLG_REAL -1.01416
H1:CAL-CS_TDEP_DARM_LINE1_REF_OLG_IMAG -0.759088
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_INV_REAL -1.12869e+16
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_INV_IMAG -1.91871e+16

for PCALY line at 331.9 Hz:

H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_REAL 373718
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_IMAG -890155
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_REAL 1.20595e+06
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_IMAG -540755
H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_REAL 7.75468e+10
H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_IMAG -8.57657e+09
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_TST_REAL -9.24752e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_TST_IMAG -1.86072e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_PUM_REAL 1.11411e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_PUM_IMAG 1.83559e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_UIM_REAL -2.19997e-26
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_UIM_IMAG -3.04968e-27
H1:CAL-CS_TDEP_PCALY_LINE2_REF_OLG_REAL -0.0175432
H1:CAL-CS_TDEP_PCALY_LINE2_REF_OLG_IMAG 0.0586971

kappa_tst correction factor (- 1 / A_0^tst(f_tst)) * (C_0(f_pcal) / (1 + G_0(f_pcal))) * (C_0(f_tst) / (1 + G_0(f_tst)))^{-1} is

H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_REAL 1.425e+16
H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_IMAG -1.17617e+16

and A(f_ctrl) correction factor (C_0(f_pcal) / (1 + G_0(f_pcal))) * (C_0(f_ctrl) / (1 + G_0(f_ctrl)))^{-1} is

H1:CAL-CS_TDEP_REF_CLGRATIO_CTRL_REAL 1.425e+16
H1:CAL-CS_TDEP_REF_CLGRATIO_CTRL_IMAG -1.17617e+16

Most of these new values have been accepted in SDF_OVERVIEW table. Some of the values (that are very small) show difference in SDF even after "accept"+"confirm".

Notice that in the A_TST, A_PUM, A_UIM for ESD line (at frequency f_tst) include time delays due to IOP error checking (3 IOP cycles) + IOP computation (1 * IOP cycle) + zero order hold delay (0.5 * IOP cycle), but does not include 1 SUS computation cycle time delay (that was included into respective quantities for other cal lines). This means that when calculating kappa_{tst} in GDS pipeline (see eq. 9 in T1500377-v6), there is no need to account for time delay when using X_tst signal. Other values C, OLG and (G used for CLGRATIO calculations) include full time delays associated with sensing and actuation.

Eric and Jim Batch

Eric wrote to Jim on Aug 10:

The ability to access EPICS channels appears to have disappeared at LHO when connected to h1hwinj:

[hinj@h1hwinj1 eric.thrane]$ ezcaread H1:CAL-INJ_TINJ_STATE
channel H1:CAL-INJ_TINJ_STATE not accessible

However, the same command works fine from cdsssh:

eric.thrane@cdsssh:~$ ezcaread H1:CAL-INJ_TINJ_STATE
H1:CAL-INJ_TINJ_STATE = 1

This problem appears to have occurred after ER7 since we would have seen errors during transient injections otherwise. Your assistance would be greatly appreciated.

Jim wrote back on Aug 11:

The problem has been resolved.  An update turned on some rather restrictive network filtering.

Charge measurements was done on both ETMs.
It is the first measurements after changing the bias sign on ETMY (changed Aug, 10 (alog 20410), history and motivation in 20387).
Results are in attachment. Too early to discuss the new tendencies.

V. Sandberg & R. McCarthy

The SUS-TMSX OSEM Satellite Box was driving a ~2kHz oscillation on its DC power line again. (See https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20428) This time we replaced the satellite box.  Verified that H1:SUS-TMSX_M1_OSEMINF_RT_IN1 and H1:SUS-TMSX_M1_OSEMINF_SD_IN1 were behaving themselves.  Work was done during the interval 18:00 - 18:45 UTC (11:00am - 11:45am PDT).

Apologie: I failed to follow my own rules and neglected to notify the operator on duty before we left and changed out the satellite box at End X.  Shame and humiliation duly noted.  :-(  Fortunately, no damage was done.

We made a state a week or so ago that offloads the ASC in full lock to the alingment sliders.  This offloads the top mass of every optic that we control with ASC (except PR3) to the alignment sliders.  We are not offloading PR3 since it moves so much due to wire heating.  

We've tried this a few times and it works and we are able to relock afterwards, so I've added it to the main guardian path, ater the transition to DC readout.  

Kyle, Gerardo 

Today we replaced the decomposing vibration isolators, vented the y-mid turbo and removed the motor electrical feed through flange that had the 10-5 torr*L/sec leak -> The O-ring was dirty with lots of particulate but otherwise typical -> We cleaned the sealing surfaces of the mating flanges and installed a new O-ring that we had "slathered" with Krytox - > Pumped volume with QDP80 for 90 minutes followed by full spin up and spin-down of the turbo -> we then isolated the turbo volume from the foreline and observed the pressure rate of rise -> it appears that we reduced the leak but it is not clear if the pressure rise observed is due to a reduced air leak, wet surface out gassing or a combination of both -> the observed pressure after 24 hours will help answer this

h1susex re-install original computer WP5430

Dave, Carlos, Jim:

The original h1susex front end computer was re-installed at EX to fix the glitching seen with the newer faster computers. The script which was clearing the EX glitch errors has been stopped, any FEC errors will now latch on until cleared by the operator.

h1tcscs model change WP5422

Duncan, Nutsinee, Dave:

The new L1 TCS model was installed on h1tcscs. A new TCS_MASTER.mdl was used. The h1tcscs.mdl file was modified to: add the ez_ca_read parts to get TCS CO2 and Ring Heater channels from the Beckhoff computers (corner and end stations) into the model; add new inputs to the CO2 parts for RH input; add ODC output from the CO2 parts; add new ODC block; add SHMEM ODC sender (to be injested by h1odcmaster model).

I discovered that there is a naming mis-match in the Beckhoff Ring Heater channels in the corner station slow controls system. There is no mismatch in the end station Beckhoff systems. I modified h1tcscs use use the H1 names.

Conlog channel reconfiguration

Dave:

After the TCS, CAL and ASC model changes I rescanned the channel lists for Conlog. It still showed a disconnection for the Guardian LSC_CONFIG node, which I tracked down to a very out-of-date autoBurt.req file for h1guardian0 target. I updated the autoBurt.req file and reconfigured Conlog, it is now happy.

H1LSCAUX filter coeff load

Dave:

The h1lscaux model was reporting a modified filter file. I took a look and could not see any difference between the current file and the archived file. I pushed the coeff-load button to clear this.

DAQ Restart

Dave:

After the TCS, CAL and ASC model changes, the DAQ was restarted. There were no GDS frame broadcaster changes made today (ECR is pending).

This morning, the ASC system was found to be blasting signals out after the model change because the inputs and output switches in the main loops were still ON even though all of the Guardians were set to DOWN for maintenance day.  So, I set the SDF to capture that the h1ascsafe.snap should restore the INPUT switches to OFF, then the Guardian will turn them on when appropriate later.  I watched the guardian turn them on during transition, just now, so all is good.

The AA chassis D1500176 with PI band Pass filter was installed at EX/EY this morning.
Units were installed in rack SUS-C2 slot U21. Units installed:

S1500143 - EY
S1500144 - EX

 
Filiberto Clara

I checked the LTS containers in the LVEA today, I increased the flow to the SUS cluster and included a recent dew point plot.

Chris Soike assisted me with the annual lubrication of the axial vane supply fans today.

Elli, Alastair, Nutsinee

The CO2X IR temperature sensor doesn't behave like it should. I turned the variable resistor while pointing the sensor out to the room until it tripped, turn it back a quater turn to untrip it, put my hand infront of it and it didn't trip. Then I tried 1/8th of a turn (still required a quarter turn from the tripping point to untrip the alarm), still couldn't trip it. Eventually I turned the resistor so close to the tripping point and still was not able to trip it with my hand. We didn't have this problem with the CO2Y IR sensor we installed last week. We are suspecting bad sensor and now looking for a spare. Hope to try again next Tuesday (given the spare sensor is found). The sensor mount has been installed on the viewport.

New ASC model was installed.

SDF showed more than 6000 channels that are not available in the frame. These were either deleted in this model uptate (entire Initial Alignment System, some Alignment Dither System signals etc.) or obsolete channels from long time ago (e.g. all ASC-ALS signals that were moved to ALS model a long time ago).

Betsy made a new snapshot and we confired everything in SDF for new channels.

Note that the ASC MEDM screen is NOT updated. Functionality of the new model is exactly the same as before (new things introduced at LLO are terminated at the top level at LHO except new dither system).

A few SDF bugs for the next upgrade please:

1)  Today, in SDF I needed to UNMONITOR 2000 channels on H1 LSCAUX.  However the SELECT ALL - MON button at the top of the column of 40-per-page does not let you mass-select channels from the the FULL TABLE view.  You can only mass-select from the DIFF table.  However, if there are no diffs on the channels, they don't show up.  Likely this is because the FULL LIST is a mixed bag of monitored and unmonitored channels.  Maybe we need to add a MONITORED table to the drop down options?

2)  Sometimes channels get moved into the CHANS NOT MON list with or without a setpoint.  (See attached.)  Probably not a big deal, but annoyingly inconsistent.  Today, I moved many of the channels shown in the attached picture to the not mon list and only some of them have a setpoint.

While looking at a few big glitches, I noticed that many have a curious post-glitch feature around 300Hz.  The post-glitch ring seems to match the periscope frequencies we usually see noise at... could this be a hint as to the source of some of our glitches?  Maybe this was fixed last night, maybe not.