Now that h1fw0 is stable, we are testing making h1fw1 stable by having it only write commissioning frames and not science frames. This is a temporary fix to support the current commissioning work where reliability is more important than redundency. The frequent restarts of h1fw1 (whose data is served by h1nds1 which is the default NDS) was causing commissioning issues due to data gaps and unavailability. Also note that we have not had any crashes of the framewriter OS or hardware, and so redundency is less of an issue outside of a science run.

After the 12:02 h1fw1 restart today it is now running the new configuration.

The current DAQ configuration is:

frame-writers 

nds-servers

* This is a mistake now that h1fw0 is not writing commissioning frames, needs a restart of h1nds0 to fix which could impact on Guardian nodes, so we are delaying this.

at approx 5pm Friday cdsfs1 (the backup server for cdsfs0 and h1boot) froze up. I was able to power cycle it remotely via IPMI. I'll check that it performs its periodic rsyncs of cdsfs0 and h1boot.

h1fw0 is now stable after the yesterday's configuration change (it is not writing commissioning frames, only science frames). The plot below shows the restarts for h1fw1 (green) and h1fw0 (red) for Friday and today. The blue square marks the time h1fw0 stopped writing commissioning frames. We will run in this configuration over the weekend to get more statistics.

Retook the SRCFF measurement. the data is in /ligo/home/controls/sballmer/20150724/FF
SrclFF20150724.xml & SRC_FFpath20150724.xml  (1st measurement)
SrclFF20150724v2.xml & SRC_FFpath20150724v2.xml (2nd measurement)

An initial fit produced a filter (FF4) that improved the performance at high frequency, but moo0.5 (the old moo, adjusted by a gain of 0.5) was still better at low frequencies. More fitting will be done during daytime. For now, guardian uses moo0.5.

Hannah, Evan, Stefan

The slightly strange sensing matrix from alog 19769 did not seem repeatable today, so we switched ASC_AS_A_RF36_I_YAW back to the settings from alog 19572:
H1:ASC-AS_A_RF36_I_MTRX_2_1    0
H1:ASC-AS_A_RF36_I_MTRX_2_2    0
H1:ASC-AS_A_RF36_I_MTRX_2_3    -2
H1:ASC-AS_A_RF36_I_MTRX_2_4    2

Instead we added some of H1:ASC-AS_B_RF36_I_YAW (with the same sign as in DRMI) to the input matrix. There wasn't much signal there, but the right kind of RF offset. The new sensing matrix is
            asc_intrix_yaw['SRC1', 'AS_B_RF36_I'] = 1.0 
            asc_intrix_yaw['SRC1', 'AS_B_RF36_Q'] = 0.0
            asc_intrix_yaw['SRC1', 'AS_A_RF36_I'] =-3.0 
            asc_intrix_yaw['SRC1', 'AS_A_RF36_Q'] = 0.0
This at least also makes some theoretical sense, so hopefully this will hold up longer.

Stefan, Evan

Summary

We temporarily switched back to the IFR as a sideband generation source, and then used it to drive the sidebands in frequency and amplitude. Then we looked at the coupling in OMC DCPD sum.

Details

We ran the spare LSC DAC channel (LSC-EXTRA_AO_2) into ISC patch cable R1 #11-4, which goes to ISC C4 #2-4. Then we sent this into the IFR's external modulation input.

First, we did the amplitude measurement. The IFR was set to dc-coupled AM with a nominal deviation of 10%. We drove 25 mV out of the DAC and watched the response in the OMC DCPD sum. The observed AM coupling is roughly flat from 300 Hz to 5 kHz, with a level of about 0.01 mA/RIN.

Next, we did the phase measurement. The IFR was set to dc-coupled FM with a nominal deviation of 1 Hz. We drove 100 mV out of the DAC and watched the response in the OMC DCPD sum. The observed FM coupling is roughly flat from from 300 Hz to 5 kHz, with a level of about 2×10⁻⁵ mA/Hz.

[An aside about the IFR actuation calibration: The IFR is designed so that in order to get 10% peak RIN, you must supply 1 V rms at the modulation port, which 1.41 V peak. Stupid stupid stupid. Anyway, I verified with an oscilloscope that the actuation coefficient was 0.068 RIN/V, which is close enough to the expected 0.071 RIN/V.

The same nuttiness applies to the frequency calibration: to get 10 Hz peak deviation, you must supply 1.41 V peak. However, Stefan and I measured this coefficient and found that it is really 3 Hz/V rather than 7.1 Hz/V. Measurement as follows:

• We beat the IFR and the OXCO against each other and looked at the mixed, low-passed output on a scope
• We adjusted the IFR frequency to match the OXCO as best we could.
• We applied 5 V dc from the DAC channel to the external input of the IFR, and measured the beat frequency (it was 14.8 Hz). This gives the acutation coefficient as 3.0 Hz/V.]

Evan, Stefan

We kept having PREP_TR_CARM issues, and again tracked it down to moving dark offsets. now the guardian measures the offsets at the beginning of PREP_TR_CARM.

Let's see weather this finally eliminates those PREP_TR_CARM issues.

Morning Meeting:

- Richard, cosmic ray work continues, not in LVEA

- no SEI

- Apollo, beam tube cleaning ongoing today

- Gerardo, vacuum, High Bay area

- SUS, no work

- PSL, yesterday's work OK, no work today

- Commissioning, intensity noise, frequency noise

- Jim, Frame Writers work continues

I have installed and made RCG2.9.6 the default build environment. I have compiled all th H1 models (102 of them) using 2.9.6, there are no errors in the build. The IPC file was created from new, it is 6 channels smaller than the old file.

This was a make only, it was not installed. I have reverted the original IPC file in case models are restarted this weekend. I'll complete the make/make-install process next Tuesday prior to H1 upgrade to 2.9.6.

The morning around 17:42UTC, PR3 moved but there was no alignment slider or other requested alignment change.

Two plots show this:

Plot 1: 3 channels

• H1:SUS-PR3_M3_WIT_PMON - red
• H1:SUS-PR3_M3_OPLEV_PIT_OUTPUT - green
• H1:SUS-PR3_M1_OPTICALIGN_P_OFFSET - blue

- blue trace, alignment slider, 17:09 to 17:57(end of plot) no change

- red and green traces, pmon and oplev pitch, 17:42 optic takes a step

Plot 2: 9 optic alignment channels, ISI pmon, POPAIR, TEST, and IMC power

• H1:SUS-PR3_M3_OPLEV_PIT_OUTPUT
• H1:SUS-PR3_M3_WIT_PMON
• H1:SUS-PR3_M3_OLDAMP_P_INMON
• H1:SUS-PR3_M3_DITHER_P_INMON - no change
• H:SUS-PR3_M3_LOCK_P_INMON - no change
• H1:SUS-PR3_M2_OLDAMP_P_INMON
• H1:SUS-PR3_M2_DITHER_P_INMON - no change
• H1:SUS-PR3_M2_LOCK_P_INMON - no change
• H1:SUS-PR3_M1_DAMP_P_INMON
• H1:SUS-PR3_M1_OPTICALIGN_P_OFFSET
• H1:SUS-PR3_M1_DITHER_P_INMON - no change
• H1:SUS-PR3_M1_LOCK_P_INMON - no change
• H1:SUS-PR3_M1_ISIWIT_PMON - steady
• H1:LSC-POPAIR_A_LF_OUTPUT
• H1:SUS-PR3_M1_TEST_P_OUTPUT
• H1:IMC-PWR_IN_OUTPUT

- nothing that explains why the optic would move

Here is an update on the ongoing CDS investigations:

DAQ framewriter instability (FRS3379)

started around 14th July. We are testing reducing the disk loading of h1fw0 by only writing science frames (i.e. not also writing the larger commissioning frames). Four hours into this with no frame writer restart.

End Station SUS IOP glitching (FRS3375)

started when the end station sus computers were upgraded to the faster model (14th July). Its impact on ISI has been reduced with the installation of new ISI BSC models this week which do not watchdog trip on individual IPC errors. We will check on the BIOS settings of the SUS computers next Tuesday with LLO (requires LLO end station SUS power down). If there are any differences, LHO will be made the same as LLO. Reverting to the slower computers is an option.

Front End IOC freeze ups (FRS3279)

Not sure when this started as logging was not available, word-of-mouth suggests it became clearly noticable early in July. Monitoring of the problem has been installed. Investigation is continuing, its main impact is on Guardian nodes.

Chris S. 80% Joe D. 60%

7/20-7/24/15
The aluminum strips were installed on the upper joints of 124 meters of enclosure for a total of 1199 meters completed.

Ed P. Rodney H. Mark L.

7/22/15
The crew relocated the lights and generator after testing the previously cleaned sections, results posted in this entry. 

65 meters of tube cleaned ending 3.8 meters east of HSW-2-062.

7/23/15
76.2 meters of tube cleaned today ending at HSW-2-058. The cleaned sections were tested and the generator relocated. Test results also posted here.

7/24/15
The vacuum nozzle that we originally modified for a lower noise level has lost the Viton strips that were installed. I reinstalled thicker rubber strips and reinforced these with an aluminum backing strip. This was only tried for a few hours this afternoon so time will tell.

 We were able to clean 79 meters today ending at HSW-2-054. We began relocating the generator and lights.

Total meters of Y-Arm tube cleaned = 907.  

I update the script for the 'Night' OPLEV charge measurements. 
If you are the last person who leaving the LHO in the night - please, run it!
It works for ~ 2.5 hours.

Instructions:
1. Set ISC_Lock state to DOWN
2. Set both ETMs to "ALIGNED" state
3. Run the scripts: scripts directory is /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts
run the python files: ./ESD_Night_ETMX.py and the second script in another terminal: ./ESD_Night_ETMY.py
4. If you need to break it - use Ctrl-C, script restore settings even in this case.

If it works, it:
a) In first ~ 30 seconds sets the channels and can warn about troubles with ESD or Alignment. If you see the warning - check this system and press ENTER.
b) Aligns the optical levers
c) During the measurements it should once a second print "Receiving data for GPS second: 1234567" 
c) After all the measurements it restore all the settings back.

If you need to stop the script while you have no access to that machine or don't know who start it and at which machine - just change the requested Lockstate. Script checks if the requested state is DOWN once a 30 seconds and stops if the state is changed. 

If something was wrong the script was stopped but settings are not restored - you can use  ./ESD Restore_Settings.py . 

Just in case: scripts modify follow settings:
1. L3 Lock:
   Bias Voltage - 0
   Offset - green light
   Ramp time - 5s
2. ESD linearization:    Bypass - ON  (on ETMY it is already ON)
3. For ETMY:   turn on Hi-voltage driver.

David logged about the SUS IOP glitches generating IPC errors to SEI Tuesday.  These sometimes (too often) would trip the ISI.  SEI has a solution already for the HAM ISIs which Jim detailed in 19842 where we added it to the BSC ISI.

Attached is a duplicate of David's plot from Tuesday.  This is 14 days and clearly the ISI TRIP FLAG (UpperLeft) which became very active after the SUS computer upgrade is now back to quietly sitting at zero.  The trip flag doesn't always register when a glitch from the SUS occurs(UpperRight and LowerLeft) but things do look better now.  A repeat of this in a few more days will prove it pretty convincingly.  The ISI has had a few trips since the model change but not from the SUS.

The writing of full frames has been halted on h1fw0 for testing of frame writer stability.  This does not affect science frame writing, which is still being written by both h1fw0 and h1fw1.

Kiwamu, Hang

We did an estimation of the beam position on test masses based on the a2l gains that gave us best decoupling.

The result was shown in the first image attached. The blue line indicated the boundary of L3 and the red spot the position of the beam on the test mass. It seemed that the beams were <~1 cm off center.

===================================================================================================================================

In case that you are interested in how we obtain the results:

The basic idea is to excite the pitch (yaw) motion of L2 stage, and let this excitation go through both

1): the L2->L3 P2P (Y2Y) path, and

2): L2->L2 P2L, and then L2->L3 L2L and L2P.

The ratio of L3's L over L3's P will then give us the vertical position of the beam on test masses. See the second picture for a graphic representation.

===================================================================================================================================

The code to re-run this analysis is available at:

/opt/rtcds/userapps/release/isc/h1/scripts/a2l

You can do the analysis by entering

./run_GrabBeamSpot.sh

in the command line

There was a question yesterday about the blends we are running on the the BSC-ISIs. I'm attaching plots of the Quite90/250 and Windy90/250 blends. Pages 1-3 are the 90mhz X/Y blends, 3-6 are the 250 RX/RY blends. The Quite blends are what we are running currently on St1 in XYZ (90) and RX/RY (250), and there is some evidence that we can run them during windy times as well. The Windy blends are kind of untested, and don't currently run on the end station ISIs, I don't know why and I haven't had much of a chance to look into it. The end ISIs will switch to the Windy blends, but trip after a few seconds. Pages 3 and 6 at least show that the filters as installed on ETMY are properly complementary, ETMX is the same.

I turned on the 530-545 notch in FM7 of ETMY L3 LOCK, and switched to ETMY with the ESD low pass on.  As the alogs of Evan and Rana suggested, by notching the pcal lines in the drive to ETMY we can engage the low pass and still have a rms of about 3000 counts on the ESD. (screen shot of ETMY drives attached). 

The resulting DARM spectrum seems slightly better at around 50-80 Hz.  Things are worse below 20 Hz because I increased the gain of DHARD YAW.  We can see if we are at least stable at high power with this increased gain for DHARD, and then worry about the 20 Hz noise.  

We had one of the huge glitches that we have been calling beam tube glitches, at around 8:15 UTC July 24th, even though no-one is cleaning the beam tubes. I've hit the intent bit and an leaving the IFO locked.  

There is currently a descrepancy of about 25 Mpc between the range displayed in the control room and the range on the summary pages.