Rich and I are trying to figure out what we can use the BRS for more than tilt subtraction of the ground seismometer. Today, we looked at coherence between the BRS and ISI rotational dofs and it doesn't look promising. To check this, we took the chamber to offline, so we could compare the ground rotation seen by the ISI to the motion measured by the BRS.  The first plot shows the coherence between the BRS and the ISI, and, sadly, there doesn't seem to be any in RX. Brown and pink are the coherence to the ISI's T240RX and CPSRX, light blue is the T240Y to the BRS RX.  The next plot shows what is working well, the tilt subtration from the Y ground STS. Red is the coherence between the BRS and the corrected STS signal, blue is the coherence between the BRS and the uncorrected STS signal, below .1hz the coherence pretty much disappears on the corrected signal until about 10mhz where the subtraction makes the STS signal worse, which we expect. The last attached plot shows the different spectra, calibrated into rad or m, as appropriate.  Not a whole else to add, other than the wind was moderate (~10mph) during this measurement, so we probably should expect more coherence with higher winds. Friday looks like a more "promising" forecast, with respect to winds.

J. Kissel, B. Weaver, T. Shaffer

I've
- measured a new charge data point for 2016-04-26.
- processed all measurements that had not been processed over the past few months of measurements
- fixed the NDS problems that Betsy and TJ had been having preventing them from plotting the trend of the effective bias voltage

As such, it has now become blatantly obvious that between the last time we intentionally flipped the bias voltage on both ESDs in order to mitigate charge accumulation (on Feb 15th; see LHO aLOG 25575) both ETM ESDs have had their settings reverted within a month of the flip, and are now continuing to charge in the wrong direction. Further, it looks like the ETMY ESD bias voltage was reduced by half (albiet still on the wrong direction) somewhat recently on Apr 14th. What's even more worrisome is that neither the ETMY LOCK gain nor DRIVALIGN gain -- which should be used to compensate for the strength change resulting from a reduced bias -- were changed when it was reduced. At least, it appears as though that as we've been commissioning ASC stuff for the past month or so, we haven't been transitioning to ETMY anyways, so it may not have mattered (*phew*) and also why it has gone relatively unnoticed.

As such,  we should re-flip the bias sign on both ETMs, to what we flipped them to on February and I recommend with flip EY back to the larger value of bias voltage, so that the opposing sign of charge accumulates and the net charge decays back towards zero faster. 

I've done a good bit of aLOG, snap file time-stamp, and EPICs records sleuthing and have conclude that the flips were unintentional settings loss, as a result of us having SAFE, DOWN and OBSERVE.snap files in concert with several h1susetm[x,y] model restarts that were unplanned or after-thoughts (namely the HWWD install LHO aLOG 25860; and PI model install LHO aLOG 26200). No one is to blame here, it's just a testament to how hard it is to track and control settings during heavy commissioning, especially when we need to make a decision on how many of the three of the SDF files need updating.

Kiwamu concisely summarizes the steps to flipping the bias in LHO aLOG 25575, and we'll work with the commissioning team to do so as soon as conceivably possible. However, what Kiwamu failed to mention is that we need to update the H1SUSETMX, H1SUSETMY, and H1CALCS SDF snap files, and do so in the SAFE, DOWN, and OBSERVE snap files.

Attached are the charge trends and a zoom of when the EY bias was reduced on Apr 14th.

Back by popular demand (and a working PSL), here are the past 7 day trends. There has been much work going on inside the enclosure so interpretation of these reports will be left entirely to the PSL team leads. Stay tunes for DBB scans for both low and high power coming to a control room near you!

WP 5839

Updated the version of dataviewer to dv-3.0, which addresses CDS bugzilla 832, fixing the previously non-functional "-r restorefile" command line option.  Users may now specify a previously saved XML file on the dataviewer command line.  

As an example the command 

dataviewer -r Initial_Alignment.xml 

starts dataviewer, and reads the file Initial_Alignment.xml after connecting with the NDS server.  No search path is used for the file, so either the xml file must reside in the current directory from which dataviewer is started, or a relative or full path must be specified for the file.

Jeff K., Patrick T.

15:06 UTC Turned off BRS sensor correction at end X and end Y for cleaning at end stations

 THE LVEA IS NOW LASER SAFE 

TITLE: 04/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: Commissioners doing their thing till about 1130 local. Leaving the IFO locked at INCREASE_POWER but only at 10W.
LOG: Nothing to report.
 

Jenne, Chris W, Sheila

Today we had some difficulty staying locked at 22 Watts, because of our SRC becoming misalinged (POP90 increasing gradually after power up until we break lock.)

We spent some time investigating signals for SRM control by opening the SRM loop and alinging by hand to minimize POP90.  The error point of our old loop is far from ideal.  We tried a dither and demodulated POP90, but this is a very noisy signal.

Jenne looked at the AS90 dark offsets, which have not been moving around as much lately, and set the gains in DRMI so that 90 and DC centering agreed.  We tried introducing offsets into the DC centering loops to zero the 90MHz signals, but this did not bring the 36 signals to zero.  

Eventually we found a combination of AS36I A and B that seem to cross zero when the SRM is well aligned, and have put that into the guardian:        

For your amusement. PSL now has a working rotation stage graphics. This should also work at LLO. Same goes for the CO2 rotation stages. At the moment PSL angle indicator turns once every 3 degrees while CO2 should turn once every 4-6 degrees.

Summary:

Filter configuration for ISS 1st loop to generate RIN channels (H1:PSL-ISS_PDA_REL_OUTPUT and PDB) doesn't look good. It seems as though we're somehow chosen to use inferior of the two filters in place both for  "CALI_AC" and "CALI_DC", assuming that D1001998-V2 (PD circuit diagram) and D1001985-V2 (ISS circuit diagram) are correct.

I made somewhat better filter for "CALI_AC". For "Cali_DC" probably it's good enough to use the one we're not using. I loaded the coefficients for the new file for H1PSLISS from H1PSLISS_GDS_TP MEDM screen.

This doesn't affect the loop because these channels are not in the feedback loop, but making these filters right makes it easier for different RIN channels to be compared.

Details:

Reading D1001998-V2, D1001985-V2, T0900630, analog part of the monitor output for PSL-ISS_PDA and PSL-ISS_PDB ADC have analog z, p and k of [0.0723;2700;0.0707] Hz, [3.3607;130;3.12;2300] Hz, and 0.2, they're all in the PD box (ISS box is just the pass through as far as these outputs are concerned). These are DC coupled.

After they are received in the front end model, the signal is first converted to volts but not dewhitened by PSL-ISS_PDA, and then distributed to PSL-ISS_PDA_CALI_DC and PSL-ISS_PDA_CALI_AC. In DC the signal is low-passed, and in AC it's dewhitened and high-passed, and AC is devided by DC to give RIN (first attachment).

In CALI_DC path, there are two filters FM1 and FM2, only FM1 is used (second attachment left). I also plotted the inverse of the analog whitening transfer function including the DC gain in the same attachment. FM1 looks like a strange  dewhite, nothing wrong with that, but I don't see any reason to prefer FM1 over FM2. Just use FM2.

In CALI_AC path, there are also two filters FM3 and FM4 (second attachment right). Compared with the inverse of the analog, it seems like the one in use (FM3) underestimates the RIN by 18dB at 1kHz. FM4 looks better but it's DC coupled. I made a new filter (green) and put it in FM5.

It's kind of odd that we're keeping DC gain factor in two different parts (CALI_DC and CAL_AC) instead of upstream. However, moving this gain into upstream affects PDASTAT thing (see the first attachment again), so I'll not fix this.

Changed the web view of vacuum MEDM screens to use the new Beckhoff MEDM screen for Mid Y in place of the old screen.

Laser Status:
SysStat is good
Front End power is 30.32 W (should be around 30 W)
Frontend Watch is GREEN
HPO Watch is GREEN

PMC:
It has been locked 1.0 day(s) 21.0 hour(s) and 31.0 minute(s) (should be days/weeks)
Reflected power is 15.98 W and PowerSum is 120.3 W

FSS:
It has been locked 0.0 day(s) 2.0 hour(s) and 13.0 minute(s) (should be days/weeks)
TPD[V] = 3.935 V (minimum 0.9 V)

ISS:
The diffracted power is around 29.4% (should be 5-9%)
Last saturation event was 0.0 day(s) 2.0 hour(s) and 14.0 minute(s) ago (should be days/weeks)

15:05 UTC Jeff B. to cleaning area to put away garb
15:11 UTC Jeff B. done
15:14 UTC Film crew on site
15:49 UTC Starting initial alignment
16:03 UTC Kyle to HAM 11 and HAM 12 to look at pumps
~16:30 UTC Richard and Filiberto starting Beckhoff vacuum upgrade at mid Y
Finished initial alignment
17:16 UTC Restarted video2 (MEDM screens updating very infrequently)
17:26 UTC Kyle back
18:02 UTC Richard and Filiberto done with Beckhoff vacuum upgrade at mid Y
Nutsinee turning on HWS X,Y
19:07 UTC DAQ restart for mid Y Beckhoff vacuum channels
19:35 UTC Received phone call for Hanford monthly alert test
19:47 UTC Film crew driving down an arm to record footage
20:18 UTC Sheila restarting ASC model (WP 5840)
20:27 UTC DAQ restart for SUSETMXPI and ASC model changes
20:36 UTC Travis and Betsy to LVEA to retrieve equipment
20:47 UTC Travis and Betsy back
20:51 UTC Film crew done recording beam tube footage
20:57 UTC Guardian node testing (WP 5841)
21:21 UTC Film crew to roof
21:22 UTC Gerardo to CP3 to overfill
21:51 UTC Gerardo done

The attachment shows the frequency control signal (IMC-F) and the transmitted intensity (IM4 trans) before and after turning on the HPO. 2 W into the modecleaner, with the interferometer unlocked.

Although Sheila's most recent DARM spectrum shows coherence with both frequency and intensity noise on the laser, I would hazard a guess that the frequency noise is not really the issue here, since it is only a factor of (at most) a few worse than before.

I did a set of tests with the guardian node. The codebase is in a state that should be ready for Jamie and I to set it up tomorrow on the guardian script machine. Going forward things to do are:
 * Update docstrings
 * Install glue, gracedb, and grid credentials on guardian machine
 * Plan out how to run the gracedb process and get robot certificate
 * Do series of injections with guardian node on guardian machine - test full injection pathway, test killing active injection, test reloading schedule, test multiple injections in a row, etc.

Below I outline the tests I did.

How to do command line tests with guardian daemon

Can now do the following tests on the command line at a LHO workstation:
 * To test reading schedule and finding the next injection: guardian INJ WAIT_FOR_NEXT_INJECT
 * To test gracedb event creation: guardian INJ CREATE_GRACEDB_EVENT
 * To test awg and inject a signal from schedule into the detector: guardian INJ CREATE_AWG_STREAM INJECT_CBC_ACTIVE
 * To test schedule validation script: PYTHONPATH=/opt/rtcds/userapps/release/cal/common/guardian:${PYTHONPATH}; python guardian_inj_schedule_validation.py --ifo H1 --schedule /opt/rtcds/userapps/release/cal/common/guardian/schedule/schedule_1148558052.txt --min-cadence 300

NOTE: You will need glue and gracedb python packages to run some of these tests, and these packages are not system-installed on workstations in the control room. And for gracedb upload testing you need the grid credential tools which are not on LHO workstations. And for gracedb upload test you need to make sure dev_mode is False.

Test injections

Injections from last night are in aLog 26749.

Today I continued with some more development tests. Injections that are constant amplitude of 1e-26 for 1 second duration into H1:CAL-PINJX_TRANSIENT_EXC; start time of the injections are:
 * 1145554100
 * 1145555100
 * 1145555700
 * 1145560262

(i) Call to awg works and injection goes into INJ-PINJX_TRANSIENT_EXC.

(ii) Injections logged correctly and meta-data is propagating through infrastructure to inform the searches. Can see the hardware injection tests done with the guardian node on the detchar summary pages. The first three not logged with a injection type, eg. BURST, because in initial tests just wanted to correctly use the awg module. Can see thereafter the injections were flagged with a type in ODC and this propagates to the low-latency frames for the online searches and the segment database for the offline searches. Can see attached plots for ODC segments and segment database segments.

(iii) Destroying a node with an open stream that has trasmitted data to the front end does not perform the injection.

(iv) The gracedb upload functions have already been tested. Today I re-checked the functions and here is an example gracedb event that was uploaded T235981. Adding messages to the event log on gracedb was also tested again, notice the "This is a test." message on the T235981 gracedb page.

(v) Schedule validation script updated and tested.

Codebase developments

Some more changes:
 * There is now a dev_mode in the code to run the tests mentioned in the section above. At the moment this does two things (i) ignores to check if the detector is locked, (ii) ignores gracedb for now until we get the robot certificate sorted out, and (ii) waits in the INJECT_CBC_ACTIVE state instead of the AWG_STREAM_OPEN_PREINJECT state because we need to avoid jump transitions for the command line test above.
 * Schedule validation script works again (https://redoubt.ligo-wa.caltech.edu/svn/cds_user_apps/trunk/cal/common/scripts/guardian_inj_schedule_validation.py).

One thing of note is that guardian does not allow subprocesses to be created by states so the subprocess managment that I had written will not work with guardian. So right now once the injection starts the code will wait for the injection to finish, this is just the implementation in the awg package (see awg.ArbitraryStream.close); it can only be killed by stopping the node.