Attached shows the DC sum of AS_C QPD (normalized by the maximum measured) VS the YAW offset of PR2. I haven't touched PIT.

Green vertical line is where we're at now.

After doing the scan represented by red crosses, I took another set of scan (blue circles) to see how the measurement fluctuates, and it seems like it didn't change much (which is good).

No further analysis yet.

08:00 LVEA is LASER HAZARD

08:15 Checked PSL status

08:37 Karen @end-Y - report of water leaking over light fixture in mechanical room and also under roll-up door.

08:45 Alistair and Eric out to LVEA/LASER tables

08:49 Jeff out of LVEA

08:50 Karen leaving end-Y

09:10 Took Seismic, safely, offline so that Jeff could updat SUS models

09:13 reset watchdog accumulators. note:  all involved chambers were able to be reset using reset all except for HAM3. rest WD only was the only way to reset. 

09:21 request from Jody for LASER safe.

09:25 Keita will transition LVEA to LASER safe

09:43 Dave B doing DAQ restart #1

09:50 Krishna back from installing thermometers for BRS @ end-X. ws there since 7:45.

09:56 Keita reports that due to the fact that the TCS team has their tables open the LVEA will remain LASER HAZARD.

11:34 Kyle going to Y-end to take pictures

11:58 Kyle leaving Y-end

12:02 Alistair and Eric out of LVEA

12:06 Betsy and Travis to align Quad in W Bay for about 2 hours.

13:15 Jim out to CER to reset an STS

13:20 Andres out to W Bay

13:28 Andres out of LVEA

13:30 Alistair et al to the H2 PSL enclosure. Approval was given by commisioners.

13:55 Betsy and Travis out of LVEA

15:08 Eric, Gerardo and Alistair out of the H2 PSL/LVEA

16:00 Gerardo out to LVEA to adjust cameras for commissioners

Jeff & Hugh

I attempted to correct the Local <--> Cartesian matrices and load generic HEPI controllers for the position loops.  Long story short, lots of watch dog trips, open loop TFs.  Plant must have changed...actually, routine error in the Matlab process of controller development was giving different matrices (not the correct ones) to the controller calculator.  So to the calculator the plant was different than what the new matrices were giving the controllers.  Hence instability.

I reverted the foton file and burt restored to 0510pst.  It isolated first time.  But why does it look like the alignment changed?  ISI servos back all dofs to the reference location but HEPI only restores the RZ reference location.  So how do we get an apparent yaw, based on PR3 alignment etc?  Maybe the other dofs that are servo'd but not restored to the reference cross couple into yaw?  Maybe...

But, we are servoing in the cartesian basis, what is happening in the local basis?  Remember, HEPI has four horizontal actuators and can distort or pringle the platform.  So, even though we servo the RZ back to 'zero', what are the four corners of the HEPI platform doing?

Based on the raw IPS counts(see first attachment with 3 days of the horizontal IPS trends) the platform yaws 1.6urads, this is using the correct matrices.  What I don't understand is that with just sign errors in the rotational dofs, why isn't this still zero?  The system has servo'd the RZ back to its reference of 20905nrads.  Are there multiple minima in the local IPS space to satisfy the cartesian servos?  When I do the same exercize using the current (incorrect matrices,) I get a yaw of 470nrads.  It should be zero but maybe this is within the error of my picking values from the data viewer trends.  When Jeff and I do a similar exercise using the changes in the output drives to the Actuators, we get 300nrads.  To do this we just looked at E1300828 and used the H1's displacement from 5000cts drive as the calibration.  This may not be valid for all actuators and again picking before and after data points from the data viewer trends certainly has slop.

So, even though the cartesian RZ has servo'd back to its place, the individual corners of the HEPI are not in the same place implying disortion.  Is this distortion enough to impact the Optics' pointing?

Alexa, Sheila, Keita

We had a look at the ETMY length 2 angle coupling this morning. 

L1 Stage:

We started with L1, Alexa first measured the response of the oplevs to a length drive at a single low frqeuency (0.1 Hz, 500000 amp) and high frequency (5.47Hz, 2000 amp).  She drove at L1_LOCK_L with the nominal filters engaged. Meanwhile in the drive align matrix the P2P filters were left on, but the L2P filters were turned off. She found that the gains of the existing filters at low and high frequencies seemed OK.  Then we had a look at the impulse response, which is the first screen shot attached. For the impulse response we turned off all the LOCK_L filters.

The pink trace is with no L2P at all, while the blue trace is FM8 that we installed (alog 14323),  which was clearly not very good. The FM1, FM2 filters are much better, which is something Arnuad had configured in alog 11832. The roll off FM3 was added to reduce DAC saturation. Keita also created a better roll off (FM4), which rolls of closer to 40Hz instead of ~1Hz, and falls off more steeply. For reference the new FM4 filter is ellip("LowPass", 5, 0.2, 40, 30). The difference is sort of minimal, but we will leave that as our new configuration. The gain of this new configuration at 0.01Hz and 4.57Hz is still ok based on Alexa's measurement.

M0  Stage:

We then looked at M0 stage. Alexa drove M0_LOCK_L at 0.01Hz, 50,000 amp with the nominal filters on. The drive align matrix had P2P left on, but the L2P filters turned off. A better gain would be 0.05, the gain for the filters enaged was closer to 0 for this. There was no coherence at high frequency. We then looked at the impulse reponse again, with the LOCK_L filters off. The second attachment shows the results.

Second attachement: The pink trace shows our nominal configuration (FM1, FM2 on for L2P and FM1 on for L2Y with a gain of -1). This was clearly better than with nothing on. We also tried various other configurations and the legacy filters, but these were significantly worse (and not worth plotting).

L3 Stage:

Finally, we took an impulse response of L3 stage. No filters have been comissioned for this stage, and the L 2 angle coupling probably changes with the ESD charge; however, we wanted to confirm there was no crazy impulse. Third attachement: The red trace has no DAC saturations and shows that the impulse response is rather small, which is good.

Conclusion:

M0, L3 drive align matrices are left as they are. We changed L2 L2P filters: FM1, FM2, FM4 ON and FM8 OFF, gain -1. See the fourth attachement for the final configuration.

Sheila and Dave

to clear up the white blocks on the GUARD_OVERVIEW screen and the issues raised by checkGuardianNodesAgainstMedmScreen we did the following:

Started the guardian nodes: IFO_ALIGN, IAS_INPUT, IAS_PRC, IAS_MICH, IAS_SRC, IAS_XARM, IAS_YARM (some scripts needed edits to fix names)

Destroyed the IAS_TEST node

The only outstanding issue from checkGuardianNodesAgainstMedmScreen is the lack of a PSL guardian node (work is ongoing)

Dave, Joe B, Keith T [WP #4929]

End Stations: I built and installed the end stations cal models (PCAL) h1calex and h1caley. The main change is that the PCAL part is now a common library link.

OAF Front End: The core assignments for the h1calcs, h1pemcs, h1tcscs  and h1odcmaster were modified to match with the L1 settings:

the recompile of h1tcscs initially failed due to an outstanding merge issue with TCS_MASTER.mdl. I reverted this file back to the last stable version and the rebuild proceeded.

the compile of h1calcs failed due to missing IPC channels from the LSC model. I have abandoned this install for today and will see if I can complete it next Tuesday (11/11) if permission to change LSC is granted. This keeps the WP open.

The calibration team, which proposes to dither DARM with four pairs (suspensions, pcal) of lines per IFO from below 20 Hz up to above 2 kHz, has asked what frequencies to avoid, in order not to interfere with future targeted searches in aLIGO data for known pulsars. 

Unfortunately (or fortunately, depending on your perspective), the band to avoid at low frequencies is substantial, depending on how far away from a known pulsar one tries to stay. If one stays at least 1 Hz away from every pulsar for which the spindown limit can be beaten at its spin frequency (* see below) or twice its spin frequency, then here are the bands that are safe in that respect:

Non-vetoed bands for veto half-band = 1.000000 (one or two times pulsar frequency)
    33.42-  37.32 Hz (   3.91 Hz)
    42.88-  49.58 Hz (   6.71 Hz)
    51.59-  54.69 Hz (   3.11 Hz)
    57.22-  58.30 Hz (   1.09 Hz)
    60.31-  60.93 Hz (   0.63 Hz)
    62.94-  63.12 Hz (   0.19 Hz)
    65.13-  81.32 Hz (  16.20 Hz)
    83.33-  87.10 Hz (   3.78 Hz)
    89.11- 122.87 Hz (  33.77 Hz)
   124.88- 159.80 Hz (  34.93 Hz)
   161.81- 172.68 Hz (  10.88 Hz)
   174.69- 201.79 Hz (  27.11 Hz)
   203.80- 320.61 Hz ( 116.82 Hz)
   322.62- 346.37 Hz (  23.76 Hz)
   348.38-2000.00 Hz (1651.63 Hz)

In other words, there is no safe frequency below 33.42 Hz. The above bands are defined by vetoing 0.01-Hz bands within 1 Hz of a pulsar with a spindown limit (based on energy conservation) that is higher than the sensitivity obtainable with a 1-year coherent integration of full-aLIGO-sensitivity H1 and L1 IFOs (using the zero-detuned high-power strain noise curve).

Traditionally, targeted searches have looked at only twice the known spin frequency of the star under the assumption that the gravitational waves come from a quadrupole deformation (non-zero ellipticity). In at least one alternative scenario, however, one could detect GWs at the spin frequency itself, and future targeted searches will consider both 1*F and 2*F. How to define the spindown limit for a 1*F emission is not as straightforward, though, as for 2*F emission. In deriving the safe bands above, I have simply taken the spindown limit to be the same as for 2*F. From one perspective, that assumption is absurdly optimistic because we expect the 1*F emission to be weaker than 2*F, but from the perspective of attributing the entire spindown of the star to 1*F emission, the 1*F spindown spidwn limit should be even higher than the 2*F limit.

Given my uneasiness about how seriously to take the 1*F spindown limits, here are the corresponding safe bands when only 2*F emission is considered:

Non-vetoed bands for veto half-band = 1.000000 (two times pulsar frequency)
    33.42-  37.32 Hz (   3.91 Hz)
    42.88-  49.58 Hz (   6.71 Hz)
    51.59-  54.69 Hz (   3.11 Hz)
    57.22-  58.30 Hz (   1.09 Hz)
    60.31-  63.12 Hz (   2.82 Hz)
    65.13-  81.32 Hz (  16.20 Hz)
    83.33-  87.10 Hz (   3.78 Hz)
    89.11- 122.87 Hz (  33.77 Hz)
   124.88- 320.61 Hz ( 195.74 Hz)
   322.62- 346.37 Hz (  23.76 Hz)
   348.38-2000.00 Hz (1651.63 Hz)

Attached are plain text files and plots corresponding to veto-half-bands of 0.01 Hz, 0.10 Hz, 0.50 Hz and 1.00 Hz, along with the Matlab script used to produce them. The spindown limits were computed using parameters taken from the Australia Telescope National Facility (ATNF) pulsar catalog, using all pulsars with a rotation frequency of at least 5 Hz and with measured frequencies (Hz), non-zero measured frequency derivatives (Hz/s), distances (kpc) and epochs (MJD). See the Matlab script for details. The pulsar frequencies used here take into account the spindown and epoch of its measurement and apply to July 1, 2015.

The default veto half-band of 1 Hz used above may be too conservative, but the worry is that upconversion from a strong dither may pollute the frequency where the pulsar sits. The iLIGO Crab pulsar upper limits were appreciably degraded by their nearness to 60 Hz (several tenths of a Hz away) and motors, etc. running just below 60 Hz. Fortunately the Crab has spun down a little further from 60 Hz since the end of aLIGO, with an expected 2*F of 59.3 Hz next July (not including Doppler modulations of +/-6 mHz and a 2nd-order spindown correction of +30 mHz). 

These veto bands have been derived on the assumption that dither frequencies chosen now will be used throughout the first several observing runs. If, on the other hand, the low dither frequencies were to be used only temporarily, one could rerun the Matlab script with a different assumed noise curve and perhaps a shorter assumed observation time, e.g., 3 months for O1, and find other safe bands. 

Attachments:
* Four sets of plots showing pulsar veto bands of 0.01, 0.10, 0.50 and 1.0 Hz half-widths, where magenta bands mark pulsars with an accessible 1*F spindown limit, green bands mark pulsars with an accessible 2*F spindown limit, and black bands mark pulsars where a 1*F or 2*F spindown limit is not accessible. The blue curve shows the 1-year 2-IFO sensitivity for the zero-detuned, high-power configuration.
* Four text files with details on spindown-accessible pulsars and the resulting non-vetoed safe bands
* pulsar_gaps.m - script to generate plots and text files
* contiguous.m - utility script downloaded from Mathworks
* Text file with ATNF catalog output read in by the Matlab script

A kindly reminder to please use the reservation system to provide an overview of which systems are being worked on.

There are three commands (please use the -h option to get online help):

make_reservation.py      To make a reservation

modify_reservation.py    To change the time of an existing reservation or delete it

display_reservation.py   To turn your terminal into a updating display of existing reservations (no arguments accepted)

added 156 channels
removed 36 channels

J. Kissel, J. Warner, E. Merilh, H. Radkins

While taking down and bringing up the HAM2, HAM5, BS, and TM ISI + HPIs this morning to upgrade suspension front-end code (see LHO aLOG 14830), we had the following troubles with platforms:

(1) The Rogue Excitation Monitor for HAM5 ISI could not be naively reset, and was caught in a trip-loop.
     - First of all, it's frustrating that there in no MEDM screen indication that the MASTERSWITCH must be ON in order to reset the rogue excitation monitor, so myself / Jim / Ed spent a few minutes clicking all the watchdog reset buttons hoping that there was some special order, until Hugh informed (reminded?) us that the master switch needed to be on
     - Second, I'm not 100% confident why, but after enacting the "correct order" of reset by turning on MASTERSWITCH, reset Rogue WD, reset all to untrip the DACKILL, the MASTERSWITCH would turn itself OFF again before the three-second counter/delay of the rogue excitation was finished, therefore re-tripping thinking the MASTERSWITCH never was turned ON. I'm 90% confident this happened because the MASTERSWITCH would "turn itself off" because the SEI manager demanded that the MASTERSWITCH be OFF because it was still in the OFFLINE state.
     Why do we have the SEI Manager controlling the MASTERSWITCH, but the ISI module controlling everything else?

(2) There are no monitor signals on the MEDM overview screen to indicate what is currently causing the Rogue Excitation Watchdog to fire. This proved solving the above problem initially difficult -- I had to open the model to find out the logic (especially the hard-coded "100 [ct]" threshold), the three-second delay, open the CDMON channels in dataviewer, find they were low, and then go for figuring out the MASTERSWITCH trick. We should (a) added epics monitors on the three *inputs* rogue excitation monitor, and (b) create a sub-screen for the rogue excitation that reveals the details of this monitor.

(3) The BSC-ISI overview screens have the SEI Manager guardians on the overview screen. The BSC-HPI overview has the HPI module guardian. The HAM-ISIs and HAM-HPIs have their individual module guardians on the overview screen. This resulted confusion when trying to quickly bring the platforms back from offline -- I'd gone to the HAM-ISI overview after just finishing the BSCs, and out-of-habit assumed the guardian drop-down menu was the manager and was surprised why it wasn't doing anything for me. Arnaud informs me that this is because the overview screen mods were first made at LLO, where they're not using HEPI and therefore don't need a manager. Since not-using-HEPI is a deviation from aLIGO baseline, I argue that we should fix this by creating the SEI manager for the HAMs, and just temporarily create a managed configuration that doesn't use HEPI -- instead of having the confusing user interface for the HAMs.

(4) The SEI manager for ITMY seems to *not* automatically turn on the MASTERSWITCH. Is this automatic operation consistent between chambers? Between HAM managers and BSC managers?

(5) HAM3-HPI's L4C saturation counter in watchdog wouldn't reset with a RESET ALL or RESET above the current trigger but, but RESET WD ONLY worked. We can confirm that every other chamber behaves as expected, i.e. any of the three methods reset the counter. What's different about HAM3? Is this reset a python script that is uniquely defined per chamber or something?

We (Gary Davis-CBC PM Intern, Bubba and myself) started bright and early this morning. Our major task for the day was to get as much of the staging work required for SUS transfers completed as possible: the commissioners are particularly concerned about crane work. By noon, we had the following components in position between the Y Manifold and the H2 output arm: an iLIGO BSC cleanroom, a garbing cleanroom, and the storage container. The meat locker was removed to expose the HXTS that have been stored there.The appropriate pallet jack was craned over the beam tube and used to get the OMC out of the old laser enclosure. The OFI transport device (stainless steel topped work table) was staged.

The Technical Cleaning team started first cleaning at ~10:30. The clean room was turned on about 11:15. 

Tomorrow morning (starting at 7-ish), we will remove the storage container lid and crane the cleanroom into place over the container. That will complete the crane work until it is time to move the cleanroom out of the way so the lid can be put back on the storage container. 

The fire department was on site to test Fire Hydrant L11 by the LSB parking lot. This hydrant was fixed but not officially tested so the guys were out to close this out.  The fire pump was running from 1030 until 1100 this morning.

K . Venkateswara

I installed two temperature sensors, one on the BRS vacuum can and one on the ground T240 at EX. They are temporarily being read on the PEM_Tiltmeter_T and PEM_Tiltmeter_Y channels respectively.

H1:PEM-EX_TILT_VEA_FLOOR_T_MON   =   BRS temperature sensor

H1:PEM-EX_TILT_VEA_FLOOR_Y_MON   =   GND_T240 temperature sensor

The temperature sensors consist of a 10k-ohm thermistor bridge powered by a 9V battery each. There is no amplification, so the calibration should be ~ 1/2 * beta / (10k) * 9V = 0.2 Volts / Kelvin , where beta value for the 10k thermistor is roughly 450 ohms/Kelvin.

J. Kissel, J. Warner, E. Merilh

I've updated the QUAD_MASTER.mdl, BSFM_MASTER.mdl, and HLTS_MASTER.mdl front-end library parts to obtain the changes Stuart has installed (see LLO aLOG 15437) in order complete ECRs E1400295 and E1400434, which have been tracked with II 969 -- "Changing Optical Lever DAQ Channels," and II 921 -- "Removal of old Guardian Parts," respectively, (governed by Work Permit #4932). This affects all core optics with optical levers, i.e. 
H1SUSPR3, H1SUSSR3, H1SUSBS, H1SUSITMX, H1SUSITMY, H1SUSETMX, H1SUSETMY.

This should close out the above mentioned ECRs and Integration Issues. Thanks to Jim and Ed for their help.

In doing so, we had to 
- svn up /opt/rtcds/userapps/release/sus/common/models/
- Request all affected SUS guardians to SAFE
- Capture new safe.snaps for all affected SUS (not necessary, but seems to be good practice)
- Request all affected SEI guardians to OFFLINE
- Recompile the model / front-end code,
      make [h1suspr3, h1sussr3, h1susbs, h1susitmx, h1susitmy, h1susetmx, h1susetmy]
- Reinstall the model / front-end code,
      make install-[h1suspr3, h1sussr3, h1susbs, h1susitmx, h1susitmy, h1susetmx, h1susetmy]
- Restart the model / front-end code,
      ssh [h1sush2a, h1sush56, h1susb123, h1susex, h1susey]
      start[h1suspr3, h1sussr3, h1susbs, h1susitmx, h1susitmy, h1susetmx, h1susetmy]
- Request all affected SUS guardians to ALIGNED
- Request all affected SEI guardians to FULLY_ISOLATED / HIGH_ISOLATED*

Bringing back up the SEI platforms was more challenging than expected, but I'll write a separate aLOG on that since it'll be focused on SEI issues.

Beam tube modeling gives higher frequency resonances than are measured, suggesting that the fixed supports are more compliant than in the model. I had accelerometers and shakers nearby so I could easily measure the displacement with height. Figure 1 shows the quasi-static displacement with height for a 5 Hz injection (below the resonances). The results suggest that the insulation may be the softest part of the spring: most of the increase in displacement with height happens across the insulation and the piece that rests on it, as if the piece were rocking on the insulation.

Robert, Fabrice

Nic, Jeff, Dave

Last Tuesday the h1lsc model was compiled against RCG2.8.5 (modification to IPC DARM to the SUS models). My bad, I forgot we had downgraded this model to RCG2.8.3 on 09 September 2014 to fix the channel shifting of slow data in the DAQ (alog link below)

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=13835

The problem was rediscovered by Nic yesterday, as the saying goes, its deja vue all over again.

I recompiled h1lsc against RCG2.8.3 this morning. At Jeff's request I updated the safe.snap file before restarting. The INI file was modified by the recompile. There were 12 testpoints open at the restart, and they remained open after the model got going again. I manually cleared them.

A DAQ restart was made soon after, which also resynced the modified SUS models.

I tested the slow channels were fixed by comparing some slow channels on StripTool (channel access client) against the same channels on dataviewer (nds client).

Added 75ml of water to the chiller.

Alexa, Evan, Sheila, Jeff, Nic, Lisa

The plan for tonight was to try again the CARM offset reduction with the DRMI locked on 3f as it was done  a few nights ago . 

However, sadly, we couldn't really stably lock the arms on green by engaging ALS DIFF (feed-back to the ETMs). 

Nothing was (at least intentionally) changed with respect to the "nominal" configuration which has worked in the past. 

In the process of collecting and analyzing several lock losses, we identified the following list of problems/action items:

 * L2P for ETMY is significantly worse than for ETMX, we should fix this: as soon as the differential feed-back to the ETMs is engaged, the ETMY green light fluctuates consistently with PIT fluctuations as seen by the optical lever. This effect was really bad in the afternoon (30% power fluctuations; it got somehow better later in the evening); 

 * ringing up of the 13 Hz ETMY roll mode (again, see Kiwamu's entry): Nic tried to damp this mode by using optical lever PIT as error signal and pushing on L2 PIT, but that didn't work. We will try tomorrow to use the  LLO strategy  by using ALS DIFF;

 * at least once we lose lock because of a 3Hz oscillation in the ESD drive (we should remeasure the cross over L1/L3).

While trying to debug the ALS, we did some work on the DRMI to investigate the tricky demod phase business (see  Evan's entry). 

The difficulties with H1 DRMI locking, and with getting H1 to full lock, prompt me to survey the top level configuration differences between H1 and L1.

Some other comparisons that should be made (not in the table) are:

• In loop LSC error signals in DRMI, locked using 3-f
• In loop WFS signals in DRMI
• ALS COMM and DIFF spectra
• Light levels on all PDs used during lock acquisition

At this point we don't know which of these differences, if any, are significant for the lock acquision. Please post comments to this entry if you have some ideas on this, or if there are other known differences that we should be looking at.