Tue20Jun2023
LOC TIME HOSTNAME     MODEL/REBOOT
10:14:46 h1lsc0       h1lsc       <<< First h1lsc restart, additional DAQ channel

10:16:07 h1daqdc0     [DAQ] <<< First DAQ restart for LSC
10:16:20 h1daqfw0     [DAQ]
10:16:20 h1daqtw0     [DAQ]
10:16:21 h1daqnds0    [DAQ]
10:16:29 h1daqgds0    [DAQ]
10:17:04 h1daqgds0    [DAQ]  <<< gds0 required 2nd restart
10:22:29 h1daqdc1     [DAQ]
10:22:40 h1daqfw1     [DAQ]
10:22:40 h1daqtw1     [DAQ]
10:22:42 h1daqnds1    [DAQ]
10:22:52 h1daqgds1    [DAQ]
10:23:24 h1daqgds1    [DAQ] <<< gds1 required 2nd restart

11:05:54 h1lsc0       h1lsc       <<< second restart of LSC for minor model change, this restart failed (see below)
11:11:45 h1lsc0       h1lsc       <<< after another round of make/install, this LSC restart succeeded.

11:31:53 h1daqdc0     [DAQ] <<< Second DAQ restart to add SEISMON and HPIPUMPCTRLEY channels to EDD
11:32:05 h1daqfw0     [DAQ]
11:32:05 h1daqnds0    [DAQ]
11:32:05 h1daqtw0     [DAQ]
11:32:13 h1daqgds0    [DAQ]
11:32:30 h1susauxb123 h1edc[DAQ] <<< EDC restart
11:35:03 h1daqdc1     [DAQ]
11:35:15 h1daqfw1     [DAQ]
11:35:16 h1daqtw1     [DAQ]
11:35:18 h1daqnds1    [DAQ]
11:35:26 h1daqgds1    [DAQ]
11:36:30 h1daqgds1    [DAQ] <<< 2nd gds1 restart
 
 

The second start of h1lsc (no DAQ change, only a minor model change) failed. The GDS_TP screen had incorrect information, it reported an INI file change even though there was none, and some counters had nonsensical values (e.g. billions of DAQ channels) amost as if counters had been replaced with pointers.

The build/install/stop/start procedure was the same for this restart as the previous and the following restarts. That is to say this was not a super fast restart with an increased possibilty of cached files visible from the NFS server.

After another round of build/installs this model started normally. Why this happened remains a mystery.

DAQ CHANGES

The following channels were REMOVED FROM THE FRAME

 H1:HPI-PUMP_EY_BSCRET_PRESS 4 16
< H1:HPI-PUMP_EY_BSCSUP_PRESS 4 16
< H1:HPI-PUMP_EY_CONTROL_VOUT 4 16
< H1:HPI-PUMP_EY_DIFF_PRESS 4 16
< H1:HPI-PUMP_EY_HEARTBEAT 4 16
< H1:HPI-PUMP_EY_HEARTBEAT_OUT 4 16
< H1:HPI-PUMP_EY_LEVEL_ALARM 4 16
< H1:HPI-PUMP_EY_LEVEL_ALARM_OUT 4 16
< H1:HPI-PUMP_EY_LEVEL_SWITCH_ALARM 4 16
< H1:HPI-PUMP_EY_MODE 4 16
< H1:HPI-PUMP_EY_OUT_TWEAK 4 16
< H1:HPI-PUMP_EY_OUT_TWEAKOUT 4 16
< H1:HPI-PUMP_EY_PID 4 16
< H1:HPI-PUMP_EY_PRESSURE_OK 4 16
< H1:HPI-PUMP_EY_PRESSURE_OK_OUT 4 16
< H1:HPI-PUMP_EY_PS_PRESS1 4 16
< H1:HPI-PUMP_EY_PS_PRESS2 4 16
< H1:HPI-PUMP_EY_PS_PRESS3 4 16
< H1:HPI-PUMP_EY_PS_PRESS4 4 16
< H1:HPI-PUMP_EY_SP_TWEAK 4 16
< H1:HPI-PUMP_EY_SP_TWEAKOUT 4 16
< H1:HPI-PUMP_EY_TWEAKSIZE 4 16
 

Additions:

294 slow channels were added to the frame (see tar for listing)

1 fast channel was added to the frame

> H1:LSC-REFL_RIN_DQ 4 16384
 

Tar of maintenance files

Tagging OpsInfo as well, both since they'll likely change the ring heaters, and they're also instrumental in violin mode tuning.

Here are 2 plots when the interferometer is locked. The ISS second loop sensors see about 60mW of light, whereas for this time LSC-REFL_A/B see about 8mW each.

The first plot shows a large excess in REFL power fluctuations below ~200Hz. EVen the flat part 300Hz shows some excess. It should be about 70% of the 16mW measurements, but shows a very similar level. Looking at the coherence between REFL_A and B indicates that this is a real signal and not noise.

The second plot shows relative intensity noise. To get the curves calibrated correctly one should match the peak near 4.5kHz since this seems rela intensit noise from the laser. (There is a factor of 0.3 in the calibrations of the RIN of REFL_A/B to acocunt for the interferometer reflectivity at DC. This factor should be 1 when the interferometer isn;t locked.)

Here is comparison between early in the lock and after 4 hours.

The hump in the reflected power is clearly getting larger as time progresses, and is its coherence with PRCL. The input power as measured by the ISS second loop outer sensor doesn't have a large correlection with the reflected power (some is expected due to the shot noise of the inner sensor).

Q1: Why is PRCL coherent with the power in reflection? If theer is a couplinh, shouldn't it be at least second order?

Q2: What's the flat noise above 300Hz that we see in the reflection power?

Here is the power trend during this lock.

And these are the plots more than 7 hours into a 60W lock. The REFL PD now seems to be shot noise limited above 100Hz.

Here is a comparison between the noise measured in reflection at 75W and 60W and against the dark noise. Some observations:

1. The power in reflection reduced about 2.5, much more than the scaled input powers.
2. The noise also scaled down more than just shot noise, indicating that there was additional noise at 75W (also seen in the coherence).
3. The measured noise at 60W is only a factor of 1.8 above dark noise, somewhat marginal.
4. If we subtract the dark noise from the measured noise we are a factor of 1,5 above ADC noise.
5. Assuming this is all shot noise, the shot noise limited power becomes 2.8mW.

The outer loop RIN is always reported about 8% higher than the innner loop one. This is not real. In the PSL ISS model of the second loop ISS both detector values are divided by the DC value of the inner loop detector. Since the outer loop detector sees about 8% more light, the RIN in the outer loop detector is overestimated by this amount. To get a better value multiply by 0.922. With this correction both RIN spectra agree with each other.

A better calibration of the REFL/ISS PDs measured with 10W input and all TMs misaligned.

Here is a 60W trend for completness.

Quick links as an add-on to the documentation:
Chassis assembly drawing which Daniel cites: D1102079
Actually sub-assembly board drawing to which "R20" exists: D1102060 -- see page 3.

e-Traveler information on the serial numbers of these aLIGO LSC RFPD Interface chassis (not the of the board that's actually changed)
    S1200450
    S1200452

Work permits for the changes:
    WP 11272 -- electronics change
    WP 11273 -- front-end model changes

Measurement results that were possible as a result of these changes: LHO:70611.

My interpretation of verbal conversation with Daniel on 2023-06-22 about those measurement results: "Improving the electronics didn't seem to help making the measurement better, but I'm not going to revert it 'cause its doesn't matter whether it's in or not. #somewords #somewords L1 doesn't care about this. (a) This is a standard whitening chassis used for almost all ISC PDs, so we're not going to change the generic drawing, and (b) other than the OMC DCPDs [which have their own whitening design], most ISC PDs are not shot noise limited, so this change wouldn't help them."

Or something.

The above e-travelers on this particular whitening are therefore the sustained documentation about this deviation from design.

The following Beckhoff electronics were installed:

Mechanical Room

1. CX2040 Beckhoff computer
2. EL3602-0010 (QTY 2)
3. EL3164
4. EL4104
5. EL1094
6. EL9011 (bus end plate)

VEA

1. EK1101
2. EL3602-0010
3. EL9011 (bus end plate)

A 12U open frame rack was mounted on the HEPI cage. The Beckhoff computer and terminals were mounted to the frame rack via a Din rail kit.

The EK1101 coupler and EL3602-0010 in the VEA were installed half rack between BSC10 and BSC6. Same rack that houses the BRS Heater Beckhoff modules.

The old HEPI Pump Servo Chassis in mechanical room and both HEPI Preamps (next to BSC10) were left installed and powered off. Old units will be removed after new system runs for a few weeks.

Under LSC controls, I claimed that we should revert the PRCL loop design, however Gabriele reminded me that the new PRCL design has better suppression, see alog 68817. We should keep this new design, but we should still determine how/if we need to change the gain to ensure the loop UGF is around 30 Hz.

Under LSC feedforward, I forgot to mention that we did not run with PRCL feedforward at 60W, so we can turn that back off at 60W.

I have also recovered the old MICH FF filter that was in FM9, called "May_d". At 60W, we will need to engage FM6-9. labeled May a-d.

We will need to update the violin mode threshhold checker. The counts value for the DARM offset was hard coded, and will be different at 60W. This value will only need to change if we change the DARM offset.

Tagging a lot of the teams who will either need to be involved in these changes, or at least be impacted by these changes when/while we revert.

J. Kissel, J. Driggers, N. Aritomi, S. Dwyer

Just FYI I brought up the open question in Elenna's aLOG about 
    DARM offset: 20 mA, not sure if we want to revert this value

The quick consensus (without agreeing to write it in stone) is that we "plan" to *not* revert the DARM offset, leaving us with 40 mA of current on the DCPDs, as has been the case since May 05 2023 (see LHO:69358).

J. Kissel, J. Driggers, S. Dwyer

Regarding the following setting suggestions in this bullet point,
    SRCL offset: we had been running with an offset of -175. 
    This was also with the previous LSC-POP_RF45 whitening at 21 dB. 
    We could revert the whitening change as well if we think it's better 
    for noise considerations

The plan is to *definitely* go to the -175 ct SRCL offset, however -- upon discussion this morning -- we've decided *not* to revert the reduction in POP A RF45 whitening gain from +21 dB to +15 dB. Said with all positives to avoid confusion, we'll continue to reduce the gain to +15 dB rather than revert to +21 dB.

We think
    - the extra ADC range head room is nice, 
    - the sacrifice in SRCL / PRCL sensing noise is minimal, and/or has minimal impact***
    - for now, today, when we power down, we want to change as little as is need to achieve stability, rather than revert absolutely everything.

***One may find the assessment of the noise impact in LHO:69350.

I forgot to include this in this alog, but the CSOFT P gain should probably be reduced to 20 again. This was a change made late last week.

FRS28295 opened for h1cam15 not responding issue.

Erik and Jonathan unplugged and plugged in the cam15 cable at the switch during a lock loss (about 1pm localtime).  No change on the camera.  Next step is sending someone to the camera itself, likely with a spare.

Connected to camera via laptop, no response. Camera will need to be replaced but requires laser hazard. Camera not required for relocking. Working with commissioners to find time to replace/align camera. Patrick T. will update serial number and mac address of new camera.

WP11274 including laser hazards submitted:
https://services2.ligo-la.caltech.edu/LHO/workpermits/view.php?permit_id=11274