Following Hugh's clean up of the VAC screen from yesterday, I went through the exercise of editing the Alarm Handler file for dust.alhConfig (located at /optrtcds/userapps/release/cds/h1/alarmfiles).  It actually wasn't that painful.

So now we have NO open (i.e. constantly ON) alarms for the Alarm Handlers (yay!), and should address any audio alarms and new & real.

For the DUST alarm handler, I commented out the following:

• H1:PEM-CS_DUST_LAB3*
• H1:PEM-CS_DUST_LVEA14*
• H1:PEM-EX_DUST_VEA1*
• H1:PEM-EY_DUST_VEA1*

We can add any new ones fairly easily.  For instructions on alarm handler editting, go here.

Gerardo performed a regen on the YEND non-evaporable getter(NEG) pump yesterday. The plot attached shows a 25% reduction in pressure in the end station pressure.

The last regen was performed in July prior to O1. Impressive performance for such a small package.

As I was doing my usual morning rounds, I discovered one of our main fire pumps running, apparently ran overnight pumping a large amount of water into the desert. I shut the pump down.
Richard had the HFD onsite yesterday so they were probably testing something that initiated the fire pump start. Someone should be informed when HFD completes their work and is ready to leave the site. This is not the first time this has happened.

I also found the door left open on the grey storage container located out by the water tank, again, apparently overnight. I checked for critters and did not see any large ones but could be some small ones trying to find a new home. I closed the door. If you remove things from the containers, PLEASE close the door when you are finished. If you are not able to close the door, contact me and I will be happy to close them for you. 

I'm not sure if the ESD changes today (alog 25468) are at fault, or if something else has changed today, but I cannot lock ALS Diff using the nominal loop. 

In order to lock ALS Diff, I have included a gain of 0.001 in the DARM2 filter bank (usually just has gain of 1, no filters yet).  Also, I have commented out the line in the Diff guardian that turns on DARM1 filters 2 and 3 (an integrator and resG respectively).  I can turn the DARM2 gain up to 0.002 or 0.004 most of the time, but at 0.006 the DARM loop starts to ring up over 2-3 seconds until we saturate the ETMX L3 coils.  Even at the very lowest teensy-tiny gain, I can't turn on either the integrator or the resG. 

There is so very little gain here that I can't measure the DARM loop in the 10-100 Hz band. 

Unsurprisingly, this means that Diff is too noisy to hold the Yarm anywhere in particular, so I can't move on with the locking sequence (with the thought that it would all be okay if I could get far enough to transfer to RF DARM). 

I am reverting my changes (uncommenting line 228 in ALS diff guardian and gain to 1 for DARM2 bank).

I'm calling it a night since I'm running low on ideas.

Also, Kiwamu straightened me out about the DARM filter module screen situation - the auto-generated screens live in the OMC folder.  He'll fix the overview screen tomorrow.

All time in UTC

1:20 6.3M earthquake in Chile prevented us from relocking

1:57 Robert to EY working on seismometers.

2:17 Robert done

2:22 Begins initial alignment

So far Jenne and I have been having trouble with locking ALS. Lockloss everytime the ifo tries to lock ALS DIFF (ALS COMM seems fine). We also coulnd't open the LSC DARM filter modules (DARM1 and DARM2). The files seems to have been removed (Jenne is about to recreate them). Seismic has come down to its nominal. Useism is hanging out near 50th percentile. Wind below 5mph. We know it's not environment issue.

Related: 20148

I remeasured the intensity-to-DARM coupling by injecting into the ISS inner loop error point. The outer loop was not engaged.

The coupling is 0.2 mA/RIN at 100 Hz, or (after accounting for the loop and the optical gain) 4×10⁻¹⁴ m/RIN. This is consistent with Kiwamu's previous measurement.

Related to alog 25449. I have updated the ISC rack screen as shown in the attached.

The message:

Even if the excess low frequency noise on AS45Q when we are locked on DC readout is due to real DARM offset fluctuations, these are not large enough to cause any significant noise in band.

More details:

One of the ideas which has been suggested is that there may be some kind of lock point error in our DARM loop, which is modulating the DARM offset and causing noise through upconversion.  We see some excess noise in AS45Q compared to the DCPDs at frequencies below 1Hz, this could be a because of some lock point errors on either AS45 or the DCPDs.  

The first attached plot shows the two signals with and without a DARM boost and resonant gain that Evan tried out a few weeks ago.  You can see that boosting the DARM loop reduced both signals at frequencies where they agree, from about 7-2 Hz.  At lower frequencies boosting the DARM loop reduced the DCPD spectrum, but has no impact on AS45, the out of loop sensor.  From this we can say that one of the sensors has some kind of lock point error at these frquencies, but we don't know which it is.  

If we assume that the AS45Q sees the true DARM motion and the DCPDs have lock point errors, this could cause upconversion in DARM by modulating the DARM offset.  One idea would be to blend the two sensors, but we can also get an idea if this comes close to the DARM noise anywhere by looking at our data.  

I low passed the AS45 data at 5Hz, and added it to the DCPD residual to get an estimate of what the DARM fluctuations are if the AS45 noise is real (blue and green lines in second attachment). Then I repeated the estimate up upconversion due to DC readout from 25053

The projected noise (pink curve) doesn't come close to DARM except at a narrow line at the calibration line.  So it seems like we wouldn't expect to learn much by blending AS45 and DCPDs for DARM control.  

Upgrade end station SUS front end computers with faster models [WP5728]

Robert, Carlos, Hugh, Dave, Jim:

The front end computers h1susex and h1susey were upgraded to the faster models. A brand new IRIG-B card which was installed in h1susey did not function correctly, and the card from the old computer was used instead. At both end stations the swap caused the other machines on the Dolphin fabric to hang, and therefore all models on h1seie[x,y] and h1isce[x,y] were restarted. The IRIG-B time on h1iopsusey dipped below zero for a short time (giving bad DAQ data and IPC receive errors). On h1iopsusex there was no IRIG-B time slew.

Hugh investigated the ISI payload watchdog as we tried to get SEI to ride through the SUS outage. We found several interesting things about this watchdog, and the main message was that it is not possible to bypass this watchdog before the sus mode is stopped. Turns out this was moot anyhow, since when the sus computer was powered back up the Dolphin fabric was disrupted.

All models were set back to OBSERVE sdf reference. The PEM ADC spare channels which were activated yesterday for Robert went back to their inactive SAFE state, using OBSESRVE state and REVERT I re-activated these.

With the faster computer and the original 2.6 kernel comes the periodic timing and adc errors on the sus machines. Since these errors usually latch on until a DIAG_RESET is issued, I am running a script on opsws16 which presses the DIAG_RESET button every minute on h1iopsuse[x,y] and h1susetm[x,y]. This will permit trending of these errors.

New PSL ISS model

Dave, Kiwamu:

Kiwamu installed his latest h1psliss model, this required a DAQ restart

New Beckhoff corner station PLC2 code

Daniel, Dave, Patrick:

Patrick installed new h1ecatc1plc2 code. I updated the DAQ INI and autoburt.req files. This required a DAQ restart

DAQ restart

Jim, Dave:

We restarted the DAQ once today for the above changes. The restart was clean. One interesting note is that h1fw0 started sufficiently before h1fw1 that it wrote our a full frame before h1fw1 got going.

Conlog

Dave, Jim, Patrick

After the autoburt .req file was regenerated, Patrick rescan the conlog channels. On restart he found that LAB DUST channels were missing. Jim tracked it down to a crashed IOC and restarted it.

SVN code cleanup

Dave:

I ran my ''check_h1_files_svn_status'' and committed all outstanding modifications. This resulted in updates for: front end mdl file (h1psliss), many filter files, many SAFE SDF snap files, many OBSERVE SDF snap files, many Guardian python scripts.

Partial filter loads full loaded

Dave:

I performed a full filter load on the two models which were running with possible partial loads: h1psliss, h1susitmy

Under WP #5710

I applied another modification on the PSL ISS front end model as planned in alog 25316.

I tested the automatic engagement and adjusted the parameters so that it locks smoothly. The IMC_LOCK guardian code is updated to incorporate this new automation and has been tested multiple times.

I have not tested the engagement as part of the full locking sequence.

[The change in the h1psliss model]

As shown in the above attached screenshot, I added two functions last time (see alog 25316). Today, I have refined the automatic reference adjuster a bit by placing signal conditioning filters and etc. The above screenshot shows the final configuration I have implemented.

The concept is that when the second loop is open we set the reference coarsely using the manual slider (i.e. REF_SIGNAL_ANA). Then a fine tuning is done by feeding SECONDLOOP_SIGNAL (shown as a green tag) to the reference point. This will let the second loop operating point close enough to close the loop. Once the loop is closed, one can then optimize the diffraction power at the AOM by feeding the diffracted power back to the reference of the second loop. This choice can be done by a mtrix.

[The screen]

The latest screen now looks like this.

Regenerated NEG pump with the aid of an aux cart.
Valved out NEG from Y-End, then started regeneration of NEG pump ~18:30 utc.
2 hours later heating was complete, waited for temperature to drop down, valved in NEG pump to Y-End volume at 23:48 utc @ 34 deg C.
 

Dewhitening filters for LVESDAMON were made and coefficients were loaded to H1SUSAUXEX and H1SUSAUXEY.

For the moment it's a simple zpk([40;40;965;965],[2;2],1,"n").

Modified the ETM LVLN ESD Drivers (ECR E1500341):

1. Changed C32 in the monitoring amplifier from 1uF to 10nF to put the pole frequency at 4.244kHz
2. Changed C36 in the summing node from 1uF to 0.047uF to increase the dynamic range

EY Unit SN S1500066
EX Unit SN S1500073

Replaced the ESD AI chassis in SUS-C1 (EX/EY). New AI Chassis contains the PI Band Pass Filter D1500177. Cable H1:SUS_ESD-05 had to be re-terminated with a DB9 male connector to accommodate new AI front panel interface.
 
EY Old D1100815 Unit SN S1103824
EY New D1500177 Unit SN S1500300

EX Old D1100815 Unit SN S1103820
EX New D1500177 Unit SN S1500299

The charge measurements for ETMX went well, but not great for ETMY. The measurement will loop through 5 times and we had almost finished the 2nd time when the SEI WD tripped and forced me to exit the running script, but I am not sure how good the data will be before the trip anyway. There wasn't enough time to run them again, so I tried to put back all of the settings differences, but I'm not 100% I did that correctly. I took screenshots, trended channels, and tried to mirror restored settings seen from the ending of the ETMX script. Hopefully it is all back where it should be.

I will post the plots in a few minutes from another computer.

Summary

Varying the DARM offset by a factor of 2 has no effect on the unexplained noise above 70 Hz.

Details

Nominally we run with 20 mA of DCPD sum current, which (with an optical gain of 3.2 mA/pm) corresponds to a DARM offset of 13 pm. I took quiet data (15 minutes at a time) with sum currents varying from 10 to 40 mA, which corresponds to DARM offsets from 9 to 18 pm.

Thanks to the automatic gain scaling that Dan and Stefan installed before O1, no manual gain adjustment is needed either for the DARM loop or the calibrated freerunning channels. At each offset, I remeasured the DARM OLTF just to be sure.

I did not adjust the SRCL feedforward during this test, and indeed the coherence below 70 Hz between DARM and the SRCL control signal is increased at DARM offsets other than 13 pm. At 40 mA sum current, the coherence is >0.3 from 25 to 40 Hz. Therefore, the excess noise below 70 Hz during this test is due almost certainly to the SRCL feedforward becoming mistuned.

On Wednesday TJ and I tripped the ISI several times executing the HAM3 ISI GS13 gain switch in various ways.  I have several examples to look at but here is a comparison of one trip to a successfull switch of the gains using the SEI COMMAND perl script.

The first attachment has 20 seconds of the trip example next to the switch that does not trip.  It looks like there isn't anything different going on before the two cases: There are larger swings in X & Y in both and the other DOFs all look fairly similar too.  There is a larger glitch 5+ seconds before the trip in Z but that seems to be settled by the switch/trip time; these would be related to Reference Position ISO servoing.

In the second attachment, again side by side are the two cases zoomed in a bit closer (10 sec.)  The two stage switch by the perl script is evident with the gain switch doing more glitching and the whitening stage doing nothing.  There is a delay of the sensors wrt to the switching by the guardian which seems weird but I'm not looking at outputs from the filter bank as we have no DQ channels here...  These channels are the inputs to the blend bank after transforming to cartesian basis.   Again, nothing stands out as to why there is a problem with the guardian script.  We (TJ & I) did adjust the guardian code to separate the FMs switching like the perl script does but it still tripped the ISI.

The third attachment is a close zoom in on the ISI trip switch.  It is what it is...  Given that the Y and RZ are the dofs that ultimately go big, I'll suspect the horizontals but I could be fooled.