Several special calibration lines have been running for the past couple of weeks so that the calibration group can assess how IFO thermalization impacts the response function (see LHO aLOG 69284). We observe the coupled-cavity pole frequency and optical gain evolving over the first ~2 h of lock when the IFO is "cold" and still thermalizing to normal high-power operations as measured by the calibration lines.

These additional lines, together with the standard set of calibration lines, have been processed offline to measure the transfer function of PCAL / DARM_IN1 = ( 1 + G) / C = R, and DARM_EXC / DARM_IN1 = (1 + G) so that we can actively track the changing response function (R) and the sensing function, derived from the combination of the measurements to isolate C [(DARM_EXC/DARM_IN1) x (DARM_IN1/PCAL)]. The DARM_EXC lines are placed close in frequency to additional PCALY lines so that is is straightforward to remove the effect of the closed servo loop.

At present the script to do this is still in "draft" form (see merge request), but we expect further improvements to analysis, plotting, and general robustness for future use cases.

I downloaded this script to my home directory (~evan.goetz/lscrepos), activated Louis' environment (conda activate cds-pydarm-test), and ran:
$ python process_sensing_darm_comb.py -i H1 -s 'may 2 2023 11:00:00' -e 'may 2 2023 11:30:00' --pydarm_ini=/ligo/groups/cal/H1/ifo/pydarm_H1.ini --pydarm_unc_ini=/ligo/groups/cal/H1/ifo/pydarm_uncertainty_H1.ini

This queries for the data and saves it so that re-running the script does not require re-querying for the data. It processes the data to determine R(t,f) and C(t,f). Attached is an initial series of plots showing the evolution from the start of the analysis period (data points in blue) to the end of the analysis period (data points in yellow). The pyDARM modeled values are shown in blue lines for comparison. This initial measurement shows the sensing function evolving from a pro-spring response to nearly no spring over the course of 30 minutes.

Future work should be to go back and run this program on all of the lock stretches for at least the last few days. Going back to the initial locks may not prove as useful because the front-end TDCF values were not correct, owing to incorrect "reference transfer function" EPICS records. Nevertheless, we can collect a few more of these "thermalization" measurements over the next several lock stretches will help inform the additional uncertainty needed for start of lock stretches.

TITLE: 05/03 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 8mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY: Just got to NLN. After ADS has converged Jeff will take us to NLN_CAL_MEAS to run some calibration measurements.

Dust monitors, VAC, CDS, SEI, SUS Okay. Violins are a little high. 

TITLE: 05/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
SHIFT SUMMARY:

nuc30's large TV screens flickered off a few times in the afternoon (with the bottom one being "off" for on the order of a minute before coming back).  This is the first time I've seen this.  (Have seen nuc29's screens flicker off before, but only for a second or so.)

LOCKING Notes:

• Received H1 in Observing and locked almost 14hrs & then a lockloss at 2141
• LOCK#1:  2143-
  • ALSx was misaligned for green X-arm.  Took a while for INCREASE FLASHES to lock up green X-arm.
  • Held at CHECK IR for automation work by TJ.
  • And finally made it to NLN (after the violins died down)---no interractions were needed!

LOG:

• LOCKING:
  • Received H1 in Observing and locked almost 14hrs.
  • 2141  LOCKLOSS!
• 1455-2139 EY Wind Fence work with large equipment (randy,mitch)
  • 1743 Tyler joining "briefly"
  • 1951 Chris joining
• 1456 EY SEI's Sensor Correction transitioned to "FENCE WORK"
• 1456 Out of Observing due to SDF change from Fence Work transition
  • 1510 Unmonitored channels & back to OBSERVING.
• 1622-1623 Out of Observing for AWG CAL LINES guardian change (jeff)
• 1628-1642 Driving over X-arm bridge to check spigot (tyler)
• 1700-1732 Cleaning of Filter Cavity End Station Receiving/Mechanical room--not the room where HAM8 is since we are OBSERVING (kim,cindy)
• 1715 EY Mechanical Room trip to drop parts off (travis)
• 1738 Visit to MY/EY/EX to pick up supplies (kim,cindy)
• 1742 Visit to non-VEA areas of end stations to check on power supply inventory (fil)
• 1855 Out of Observing for COMMISSIOING Time
  • TJ LOAD-ed ISC_LOCK & IFO guardians
  • 2141  LOCKLOSS!
  • TJ did some FIND IR automation work
• 2147-2212 Filter Cavity dead accelerometer check (adrian, fil)
• 2209 Unloading PCal equipment at Receiving to go in PCal Lab (rick)
• 2222 Checking cabling for wire coil in Cleaning Room (adjacent to CER) [fil]
• 2230 Power supply inventory at CER (marc)

Adrian, Fil

We confirmed that the H1:PEM-FCES_ACC_HAM8_FC2_Y_DQ accelerometer channel is marked as disconnected on LIGOcam was unplugged at the sensor - evidently we still haven't decided where to place it. We exchanged the 2-channel signal conditioning box for the FCES microphone above the FCES PEM rack for a 1-channel box. This swap was conducted from May 3, 21:57-22:07 UTC. We set the CCLD to on, the gain to 10x (from 1x) and the filter to 20A for consistency with other boxes.

We just had a lockloss after 20.5 hours of lock that appears to be from the ASC, specifically CSOFT P. The oscillation was at about 0.45 Hz and the ring up occurred within the last two minutes of lock. The oscillation appears in other ASC signals, such as INP1, DHARD, and MICH.

I am suprised to see this kind of lockloss so long into the lock, so I am not exactly sure what action to take. I have increased the DSOFT P and CSOFT P gain to give more bandwidth to the loops. I also think we should try to get an OLG of CSOFT P at this higher power (the last OLG was taken at 60W, 67539). OLGs of all arm ASC loops at 430 kW of power would be ideal, but take time.

Austin, Betsy, Karla, Rahul

We have finished bonding fused sillica Ears to ETM12 using Hydroxide Catalysis Bonding (HCB) technique, please see pictures attached below for reference. The ear-test mass bond layer has few air bubbles within our tolerance (less than 50 sq mm of the total bond area). We can confirm that the position of both the ears on the two flat surface of the mirror are within the required +-0.1mm.

ETM12 (also see galaxy page for details on the optic) is a our spare test mass mirror between the two sites. The details of the ear and test mass mirror is given below,

- Ear s/n 30077403-04 (Q2300015) is bonded to the flat side S3.

- Ear s/n 30077403-05 (Q2300016) is bonded to the flat side S4.

Both the ears were 22.3 grams heavy (measured using a calibrated scale in a clean room).

The fiducial line measurements on the optic was performed at CIT and the details are posted in E2200356_v1.

I have uploaded the latest version V27 of Jig settings calculation on the DCC.

We still need to measure the total weight of the optic and apply First contact to clean the HR side.

Attached is the 3-month trend for the SUS HWWDs.  

ETMx had the least amount of bit switches (as noted in previous quarters), but since it had atleast 1 switch in the quarter (compared to many for ETMy), NO ACTION REQUIRED.

DriptaB, RickS

Following up on setting the Pcal XY comparison factor at 1.0027 (see LHO aLog 69240), we look at 12 hours from the long lock stretch last night: 07:00:00 UTC to 17:00:00 on 5/3/2023.  The attached plot shows the BNS range and output of the Pcal XY comparison channel in minute trends during this interval.

Using DTT as described in LHO aLog 69240, we can calculate the XY comparison factor.  The results are:

start time = 05/03/2023, 07:00 UTC  --> 3 hop (1.0003, or three hundredths of a percent (hop) above  unity)
start time = 05/03/2023, 08:00 UTC  --> 5 hop
start time = 05/03/2023, 09:00 UTC  --> 11 hop
start time = 05/03/2023, 10:00 UTC  --> 10 hop
start time = 05/03/2023, 11:00 UTC  --> 12 hop
start time = 05/03/2023, 12:00 UTC  --> 7 hop
start time = 05/03/2023, 13:00 UTC  --> 14 hop
start time = 05/03/2023, 14:00 UTC  --> 9 hop
start time = 05/03/2023, 15:00 UTC  --> 3 hop
start time = 05/03/2023, 16:00 UTC  --> 2 hop
start time = 05/03/2023, 17:00 UTC  --> 5 hop

The mean of the calculated coefficients is 7.4 hop with a standard deviation of 4 hop.

This seems to indicate that the chi_XY factor is closer to 1.0034 (27 hop already in the correction factors plus the residudual 7 hop measured during this lock stretch.

Though this seems to be an offset between the way we calculate this using DTT and how we are calculating it in the front-end code.  As the lower trace in the attached plot shows, the calculated factor is now clearly varying about 1.0, where the values calculated using DTT are offset by about 1.0007 (7 hop).

On Monday we noticed a very large spike in DARM. This ended up being as a result of a truck delivery that occurred midday. It appears that the additional gournd motion from the truck rung up bounce modes of some of the mirrors (HSTS and HLTS bounce modes are located around 27-28 Hz). Once the truck left, the peak and excess noise in DARM calmed back down. However, this reminded me of previous times we saw a large, nonstationary peak in DARM around this frequency. When investigating what was causing this peak, I noticed that the mirrors in the PRC seemed to be the most affected by the truck motion. This was strange to me, as the HSTS all have similar bounce modes, and the truck delivery occurred closest to the asymmetric port (closest to SRC mirrors).

It turns out that during this time of excess ground motion, the mirrors most effected were the mirrors in HAM2: PRM, PR3, MC1 and MC3. I made this plot showing the top mass L, T, and V optic motion (damping loop error point) of the mirrors in HAM2. I made a similar plot for HSTS optics in HAM3, 4, and 5. Mirrors in HAM3 (MC2, PR2) saw excess motion too, as well as mirrors in HAM4 and HAM5 (SR2, SRM, SR3). However, the excess motion of the mirrors in HAM2 was about a factor of 10 above the noise floor, compared to perhaps a factor of 2 for the mirrors in other HAMs.

I made a plot of the ISI motion at this time as well. HAM2 and HAM3 have the most motion, HAM5 slightly less, and HAM4 motion is about a factor 10 lower. This reminds me of times in the past when Jim has told me that the isolation in HAM4 and HAM5 is much better than HAM2 and HAM3. I also know that Jim has been working on improving the isolation (via feedforward) of HAM2.

There have been a few alogs in the past noticing a large 27 or 28 Hz peak in DARM (66692, 67952). Georgia did some work to suggest that it was the PR3 bounce mode, possible rung up by a motor in the LVEA. Gabriele noticed a similar peak. It it worth looking at if we can mitigate whatever it is ringing up the bounce modes of the triple mirror suspensions, especially the ones in HAM2. Sometimes the peak is accompanied by extra broadband noise around the peak. I am tagging PEM, SUS, and SEI in this alog so we can look at if there is something locally (like the motor Georgia mentions) that rings up these bounce mode, while in parallel we can try to improve the HAM2 isolation.

The GPS time around when we noticed the massive peak in DARM was 1367008818 and lasted about 10 minutes.

Wed May 03 13:17:41 2023 INFO: Fill completed in 2min 41secs

Gerardo confirmed a good fill curbside.

J. Kissel

After all the infrastructure work over the past two weeks (see list below), we've finalized the live computation of the systematic error in calibration in the front-end. 

We've still got a lot of work to do in terms of validation, but you can see results here:
    - MEDM Screen Snippet -- this shows the numbers that are conveniently shown on the CAL CS TDEP screen (sitemap > CAL CS > DARM calib > pink "CAL LINE MONITORS" block)
    - ndscope trend -- this shows the trend of these numbers of a ~30 minute time window around ~17:00 UTC.
    - png and pdf of one snap-shot in time (i.e. informed by one 2-minute answer of the "calibration systematic error" calculated on a ~2 minute cadence), but shown as the traditional bode plot.

Here, we define the "calibration" as H1:CAL-DELTAL_EXTERNAL * (GDS / CALCS) corrections, i.e. the "DARM loop transfer function values at calibration line" (GDS/CALCS) correction at each calibration frequency for H1:CAL-DELTAL_EXTERNAL are 
    (GDS/CALCS) = (1/C_CORR) * ( (1 + G) / (1 + G * - angle(C_CORR * A_CORR) / (A_CORR * C_CORR)) )

as defined in T1900169. Similarly, the PCAL channels, H1:CAL-CS_TDEP_REF_PCAL_DQ (which is currently PCALY RX PD), and  PCAL X RX PD (which unfortunately NOT stored as an independent test point, or stored in the frames) are corrected at each calibration line frequency as 
    (PCAL [m]) / (PCAL_CALCS) = (arm sign) * (1/f^2) * (analog 65 kHz AA) * (digital 65kHz - 16kHz AA) * (corner-to-end, one 16 kHz clock cycle advance)


Some other important notes: 
    - the front-end *does not* use or need a whitening filter, the front-end (GDS/CALCS) correction does *not* need to account for the whitening filter that's applied to H1:CAL-DELTAL_EXTERNAL before creating H1:CAL-DELTAL_EXTERNAL_DQ. 
    - this systematic error measurement does not need to be corrected for time-dependent correction factors -- its measuring their impact live. The (GDS/CALCS) correction is only weakly dependent on TDCFs (see LHO:66062), so all the correction factors to the front-end computed answers are time-independent.
    - The uncertainty for each of these data points is the quadrature sum of 
        :: 0.28% 1-sigma, or 0.0028 radians [relative uncertainty], from G2300471 -- the "fundamental" uncertainty in our model of how much displacement PCAL causes, as it currently stands, and
        :: the measurement-, coherence-based, sqrt( (1-C) / (2 N C)) uncertainty.
      As such, the loud lines (e.g. 17.1, 410.2, and 410.3 Hz) are limited by the PCAL model's uncertainty, and the quieter lines are limited by the measurement noise. These should be the only uncertainties in this measurement -- drive the known PCAL displacement, and see what you measure out of DELTAL_EXTERNAL * (GDS/CALCS). *Maybe* you could argue that the (GDS/CALCS) corrections have some uncertainty, we'll have to think about that.
    - Here, in the bode plot, note that I've displayed DELTA L [m] / PCAL [m] -- which is the inverse of what we typically show when we show the modeled systematic error, PCAL [m] / DELTA L [m].

The list of "lost of work to do":
    - (potentially) tune the amplitude of PCAL lines (especially the PCALX) in order to get "satisfactory" uncertainty on the estimate of the systematic error. (Note, that also means figuring out what "satisfactory" *is*.)
    - Put this on the same plot as a "traditionally measured, offline processed" broad-band and swept-sine measurement of the same thing at a time *near* this calculation, e.g. those from LHO:66079.
    - Put this on the same plot as the "traditional *modeled* estimate of the systematic error," which is derived from MCMC fits, GPR fits of the residual, and time-dependent correction factors.
    - Figure out a nice way use animated plots to display a "3 dimensional" bode plot of these answer as a function of time
    - Compare against GDS processed values of the same thing (still working on figure out ways to store that answer for comparison).

And in the grand scheme of things, once this is validated, and we're confident in the uncertainty of the measured systematic error, *then* we can figure out how to alarm on these values when something significant changes in the calibration.

[1] Front-end code changes last Tuesday, LHO:68961, and yesterday LHO:69226
[2] MEDM screen updates to the graphical user interface for improved clarity and usage LHO:68999 and LHO:69263
[3] Understanding and populating the EPICs records that are "DARM loop model parameter values at calibration line frequencies" LHO:69061 and LHO:69159
[4] Understanding, LHO:69175, then synchronizing the demod low-pass corner frequencies with the FFT LENGTH and Number of Averages used to compute the measurement-, coherence-based uncertainty LHO:69265.

J. Kissel

Perusing the operations log from last night (LHO:69274), I noticed last night that Camilla has accepted the H1:CAL-PCALY_DARM_GAIN set at 1.0 in the h1caley SDF snap, which restores the PCALY "thermalization" line amplitudes to their original value (from LHO:68947) of 
                                   _FREQ     _SINGAIN
    H1:CAL-PCALY_PCALOSC4_OSC      8.925     3000
    H1:CAL-PCALY_PCALOSC5_OSC     11.575     1000
    H1:CAL-PCALY_PCALOSC6_OSC     15.275     120
    H1:CAL-PCALY_PCALOSC7_OSC     24.500     80

However, a few days ago we noticed that PCALY was regularly saturating its Optical Follower Servo (OFS), so I took a quick and dirty way out of reducing the gain of the filter bank that all these PCAL lines go through, H1:CAL-PCALY_DARM_GAIN, from 1.0 to 0.9 (aLOGged "sneakily" as a comment, in LHO:69160).

While I accepted this lower 0.9 gain in the SDF system at the time, I hadn't edited CAL_AWG_LINES to restore it to 0.9 in between cycles of LINES_ON vs IDLE. Thus, when ISC_LOCK cycled from, say, NOMINAL_LOW_NOISE to NLN_CAL_MEAS back to NOMINAL_LOW_NOISE, and request CAL_AWG_LINES to go from LINES_ON to IDLE back to LINES_ON, the gain would pop back up to 1.0. In the rush to get back into observing, then, folks -- through no fault of their own other than not getting the memo -- would blindly accept 1.0 (as Camilla did last night), and I'd come in the next day and reduce it to 0.9.

I've now just reduced the amplitude of these lines by 10% in the CAL_AWG_LINES code, to 
                                   _FREQ     _SINGAIN
    H1:CAL-PCALY_PCALOSC4_OSC      8.925     2700
    H1:CAL-PCALY_PCALOSC5_OSC     11.575     900
    H1:CAL-PCALY_PCALOSC6_OSC     15.275     108
    H1:CAL-PCALY_PCALOSC7_OSC     24.500     72
such that the H1:CAL-PCALY_DARM_GAIN can always remain at 1.0, as is *still* coded to be set in the transition and now matches the SDF system.

I guess, really, this gain should also be not monitored by the SDF system (as is typical for "guardian controled EPICs records"), but these lines are temporary engineering run lines anyways so eventually we'll want to *re* monitor, and SDF control the gain, so for now I'll leave it as is.

This change took us out of observing at 2023-05-03 16:22 UTC, and we were back in observing by 2023-05-03 16:23 UTC.

The MICH, PRCL and SRCL in-loop error signals have a fairly flat spectrum above 10 Hz, I assume mostly dominated by sensing noise, and they accumulate all their RMS below 10 Hz, mostly in the region between 0.5 and 5 Hz. I looked at the origin of the "motion" sensed by LSC error signals, by running a coherence analysis (BruCo) on them: MICH, PRCL, SRCL. I used one hour of data and run high resolution FFTs with a bin width of 50 mHz.

PRCL

Most of the RMS is between 2 and 5 Hz. There is coherence with 

• PRM M1 damping loops below 1 Hz: L, P and Y, with P being the only damping loop with some coherence above 3 Hz. I assume this could be real PRM motion below a few Hz
• PR2 M1 damping, mostly Y (especially at 3.4 Hz) but also P and L
• PR3 M1 damping seems to contribute most to the 4-9 Hz region: L and Y
• CHARD_Y is coherent between 4 and 8 Hz, and again between 15 and 50 Hz. It's not clear which way the coherence goes: this might well be PRCL control pulliting CHARD, since we know that CHARD is noisier when we do a PRCL injection.

Incidentally, there is still a significant 3.47 Hz peak, even with the corrrected offload for PRM. This is mostly coherent with PR2 Y damping

One interesting note: PRCL is highly coherent with LSC-REFL_A_LF_OUT between 4 Hz and 200 Hz: why do we see coherence between PRCL motion and power fluctuations in reflection?
Do we have a PRCL longitudinal offset? Coherence with POP_A_LF is lower, so this might be due to higher order modes. We didn;t have light on the POPAIR diodes, so we cannot see if there is coherence with the sideband powers, that could be another source of the coherence with REFL_A_LF.

In summary, I think that improving PRM and PR2 local damping, and/or improving the angle to length coupling of the M1 stages could reduce the amount of low frequency noise in PRCL. We should also investigate why PR2 damping shows a 3.47 Hz peak.

SRCL

The SRCL loop has lower suppression than PRCL, so there is more RMS being accumulated below 1 Hz or so. There is coherence with

• SRM M1 damping below 2 Hz: P, Y, L. Coherence is high at the very large 1 Hz peak, so probably this is real motion of the SRC
• SR2 M1 damping: P is the largest contribution to the noise between 3 and 9 Hz
• There's coherence with SRC2, below 5 Hz and at a peak at 8.8 Hz. Not clear which way the coherence goes, from SRCL to SRC2 or from SRC2 to SRCL

SRCL is also coherent with power fluctuatiion in reflection, for example LSC-REFL_A_RIN, mostly bewteen 10 and 30 Hz, and lower than PRCL. This could be due to SRCL being contaminated by PRCL motion due to a non perfect sensing matrix decoupling.

Improving SR2 P damping and angle to length decoupling of the M1 stage should reduce the SRCL noise below 10 Hz.

MICH

MICH accumulates RMS bewteen 0.1 and 5 Hz. There is coherence with

• BS M1 damping as expected: L below 1 Hz, P and Y at lower frequencies
• ASC DC4_Y loop betweeen 2 and 5 Hz, P at lower frequencies
• ASC MICH_Y contributes a bit betwen 5 and 10 Hz
• DHARD_Y is a contributor below 10 Hz
• Not sure what this means, but there is coherence with SQZ-ASC_POS_Y between 1 and 5 Hz. Similar with other SQZ signals such as SQZ-ASC_ANG_Y
• MICH is coherent with SRCL and PRCL, probably again due to imperfect sensing matrix diagonalization

The 32 Hz peak shows coherence with many signals: ASC-OMC_A_PIT, ASC-AS_A_RF45_I_SUM.
Maybe the most interesting is PEM-CS_ACC_PSL_TABLE2_Z: this is coherent also at the 40.1 Hz peak and at the peaks at 98.3 Hz and 103.6 Hz. Similar coherence with PEM-CS_ACC_PSL_TABLE1_Z

The peaks at 98.3 and 103.6 Hz are coherent with ISI-BS_SUSPOINT_BS_EUL_P and many more ISI-BS signals: is it some real motion of the ISI? This is also coherent around 32.2 Hz, which seems to be a smaller secondary peak near the larger 32.3 Hz peak.

The CDS Data Acquisition System lookback times have recently been extended when we upgraded to the new Linux file systems with their 150TB RAIDs.

Both h1daqnds0 and h1daqnds1 are now running at nominal disk usage, with a wiper script maintaining the required amount of free disk space.

The lookback times for h1daqnds0 and h1daqnds1 can be obtained by running the lookback command. Note that control room users can ignore the minute_trend line, this refers to GWF framed minute_trends which are only used by LDAS for archival. CDS minute trends have no limits on their lookbacks (trends go back to the channel's creation date).

The wiper is currently configured to maintain 84 days (3 months) of second_trends, 28 days of minute_trends, and the rest is given to full framed data (currently about 2 months worth)

Each line shows the lookback time in days and the oldest file's GPS time along with its corresponding local time.

david.barker@opslogin0: lookback 
DAQ0
2023-05-03 08:10 PDT
        full 57d 1362168064 [2023-03-06 12:00 PST]
second_trend 84d 1359850200 [2023-02-07 16:09 PST]
minute_trend 28d 1364691600 [2023-04-04 17:59 PDT]
 
DAQ1
2023-05-03 08:13 PDT
        full 57d 1362174848 [2023-03-06 13:53 PST]
second_trend 84d 1359850200 [2023-02-07 16:09 PST]
minute_trend 28d 1364691600 [2023-04-04 17:59 PDT]
 

TITLE: 05/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 136Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 7mph Gusts, 6mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.15 μm/s
QUICK SUMMARY:

Currently in OBSERVING with the Lock Clock approaching 14hrs.  There have been no alarms. 

Randy just came in to let me know they are going to be moving large equipment for Fence Work, so I transitioned EY's SEI Sensor Correction state to accommodate this work.  This is a new button Jim made yesterday (alog69269).  This bumped us out of OBSERVING.  I have attached a screenshot showing this new button (its on ISI_CONFIG.adl and says "! Fence Work" in red) & this pops up the blue window which shows the channels involved with this changed state:

Old : H1:ISI-ETMY_ST1_SENSCOR_Y_NEXT_CHAN 1
New : H1:ISI-ETMY_ST1_SENSCOR_Y_NEXT_CHAN 4

This also gives the SEI_CONF node the following note:  "ISI_ETMY_ST1_SC: not EXEC"

Looking at 4 recent locklosses, I can't see the reason we lost lock. I investigated using the command line 'lockloss select' and web lockloss tool.

Ryan's 05/01 loclkoss was during work hours (i.e. people around) there is a couple of wobbles in H1:LSC-DARM_IN1 before the lockloss: leftmost plot in attached. I can't see anything similar in the others.

You can see in the attached plot with the IMC that the IMC looses lock ~200ms after AS_A, this means these locklosses are not the "TOGETHER" type we saw (I think exclusively) in O3b: G2201762. 

05/01 17:59UTC 1366999182 Ryan's Monday lockloss.

05/02 09:41UTC 1367055714 After my shift last night

05/02 14:34UTC 1367073283 Before Maintenance began

05/03 00:15UTC 1367108148 This evening

TITLE: 05/03 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 138MPc
SHIFT SUMMARY: Locked most of the shift. We've had DARM spring measurements (alog69261), and Louis runnning a Caibration Suite.
LOG:

Had increased PSL dust counts with the main room alarming but 500nm counts remained below 50. Plot attached, tagging PSL. Expect this was due to LVEA work today and some 20mph winds.

Lock #1. Initial alignment by Corey. Reached NLN at 23:32UTC, lost lock at 00:15UTC,

• SQZ: Initialized the new SQZ-LASER_RFAM filter channels (created in todays h1sqz model changes). sdf screenshot
• SQZ: Accepted ZM3 alignment offsets, sdf screenshot
• CAL: Accepted a lot of CAL sdf diffs, Louis looked over these. sdf screenshot
• ASC: Accepted CAM_PIT2 and PIT3_GAIN and then after asking Naoki, sneekly while in Observing reverted to be +/-300. inital sdf screenshot, then final sdf screenshot.     .                                                                                                                                                                           

I've added 2 buttons to the ISI_CONFIG screen to manage the sensor correction during the fence work. Under the SEI WD SCREEN button there is a red button that says "Fence Work" and a green button that says "Nominal".  The red button pauses the EY St1 senscor guardian, switches the filter I posted in 69162  and takes the BRSY out of the earthquake mode. The green button reverts all that. 

So, before Mitch and Randy head to EY operators should hit the "Fence Work" button. When they are done for the day, revert with the green button. Hopefully we can get rid of these transitions in a couple weeks.