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.

Initial attempts to take undamped TFs on ITMX & ITMY exhibited rung up P & R modes (see LHO aLOG entry 14653). For the next attempt, fine tuning of excitation amplitudes was necessary to avoid ringing up these modes.

Phase 3b (in-vacuum) undamped TF measurements have been taken for ITMX & ITMY (QUAD) suspensions as follows:-  

- ITMX M0-M0 undamped results (2014-10-30_0700_H1SUSITMX_M0_ALL_TFs.pdf)
- ITMX R0-R0 undamped results (2014-10-30_0700_H1SUSITMX_R0_ALL_TFs.pdf)
- ITMY M0-M0 undamped results (2014-10-28_1200_H1SUSITMY_M0_ALL_TFs.pdf)
- ITMY R0-R0 undamped results (2014-10-28_1200_H1SUSITMY_R0_ALL_TFs.pdf)

ISI Status: ISI's damped and FULLY_ISOLATED via Guardian.

ITMX & ITMY undamped TFs above have been compared with other similar QUADs at the same phase of testing (allquads_2014-10-30_AllQUADS_Doff_Phase3b_ALL_ZOOMED_TFs.pdf). The plot key is as follows:-

Blue Trace = Model Prediction (fiber/thincp).
Orange Trace = L1 ITMX (fiber 2013−09−04), Phase 3b.
Black Trace = L1 ITMY (fiber 2013−09−05), Phase 3b.
Magenta Trace = H1 ITMY (fiber 2014−10−28), Phase 3b.
Cyan Trace = H1 ITMX (fiber 2014−10−30), Phase 3b.

Summary:

M0-M0, main chain TFs are a very good fit to the model, for all DOFs, with only some minor cross-couplings from P2V.

R0-R0, reaction chain TFs agree with the model predictions and are consistent with similar QUADs. The largest deviation from the model can be seen with the ~1.45 Hz P mode, a consequence of the harness routing stiffening the suspension, seen before. Some minor cross-couplings are also present: from P2L, P2R, and P2V only for ITMY. Damped TFs should be taken to verify that damping loops suppress these cross-couplings.

All data, scripts and plots have been committed to the sus svn as of this entry.

With approval from Jeff K, I am about to begin updating the EPICS settings controlling the ODC (state vector) for the SUS subsystem.
These changes include:

- Update bit strings to latest configuration, including OPLEV damping names
- Update bitmasks to not include LOCK state checks in ODC summary bits
- Update and commit safe.snap files to capture the above changes

These changes will not affect any EPICS settings not under the 'H1:SUS-{optic}_ODC' prefix.

no restarts reported

As an exercise to test out the OMC --> LSC signal path, I locked the simple Michelson using the OMC-DCPD_SUM signal.  With MICH locked on a dark fringe with a 35 count offset, I measured the DCPD-to-MICH transfer function.  The DCPD sum was a factor of ~4 smaller and off by 180deg at low frequency, so I loaded "-4" into the LSC input matrix (OMC DC --> MICH) and zeroed the ASAIR_RF45 element.  The lock was very smooth, with about 2x more gain than the vanilla MICH loop.  (I found the guardian-set gain the  MICH_DARK_LOCKED state was about 3x smaller than maybe it should have been, so I increased it from -500 to -1400 before the handoff.  After the handoff I reduced the gain to -700. The UGF with these settings was ~7.5Hz, roughly aligned with the peak of the phase bubble.)

Comparisons of the OLTF in both states (with the gain settings described above) are attached, so are noise spectra for the error and control signals.  In both plots the references are the RF lock, current signals are the DC lock.

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). 

Nic and I briefly entertained the idea of going out to the end stations to optimize the gain and whitening on the ETM oplevs, but decided (based on the attached spectra of the segments) that it was good enough for today's oplev work.