Today during Maintenance the HAM2 ISI was not fully isolated but in DAMPED to allow for work in the LVEA.  The IM1-4 optics were in SAFE, so no alignment bias and no damping.  This configuration closely mimicks an ISI / optic trip.

When it was time to restore the HAM2 ISI, and then redamp the IM1-4 optics, I observed the drift in pitch and yaw that I've observed after an ISI trip.

The difference between a typical ISI-IM-IMC recovery, and todays recovery is that we restored the ISI and IMs while the PSL beam was blocked at the shutter between the PSL and HAM1.

The drift in IMs today was no different than the drifts I've observed before.

There was a suggestion that heating from the IMC being restored, when the HAM2 and HAM3 ISIs and optics are restored, might be the source of the IM drift, however since I tracked the drift today and there was no IMC beam, I have to conclude the restoration of the IMC is not the source of the IM drift.

While tracking the drift, I exercised the pitch and yaw alignment biases for each IM by +/-100 counts to see if that would effect the drift.  I was testing the theory that the cause of the alignment shifts that I've tracked since last year might also be causing this recovery drift, but I cannot see that being true, since moving the alignment biases had no effect on the drift.

Here are the amounts each IM changed after being restored:

black: IM DOFs that did not show any significant drift (drift that is less than 1urad)

red: IM DOFs that did show significat drift (drift equal to or greater than 1urad)

Attached plots:

• 25 minutes of drift
• close up of the pitch and yaw alignment biases being exercised, showing the drift of was unchanged

omc_pi model change. WP5957

Kiwamu, Carl, Dave:

h1omcpi was modifed to read in the two new ADC channels. Two new 64kHz channels were added to the commissioning frame, 8 existing 2kHz channels were added to the science frame for permanent archival (H1:OMC-PI_DOWNCONV[1-4]_DEMOD_[I,Q]_OUT_DQ)

h1 SUS PI model changes

Ross, Carl, Dave:

new h1susitmpi,h1susetm[x,y]pi models were installed.

DAC card replacement in SUS B123 and H2A WP5954, WP5953

Richard, Fil, Dave, Jim

h1susb123 and h1sush2a were powered down. The first DAC card in each IO Chassis were replaced. The new DAC cards both pass the autocal. The ADCs were power cycled at the same time.

BSC ISI code change WP5961

Brian, Jim W, Jim, Dave

a new isi2stagemaster.mdl file were installed. All BSC ISI models were rebuilt and restarted. (h1isi[bs, itmx, itmy, etmx, etmy]). Part of this change was to remove the user model's DACKILL part. Since this part registers itelf with the IOP model on startup, the code change required a restart of all the models on h1seib[1,2,3,ex,ey] to resync the IOP with the DAC clients.

We also found that the HEPI watchdog reset button does not work on newer Ubuntu 14 machines. This was tracked to the perl script wd_dackill_reset.pl script requires the CAP5 module, not loaded on newer machines. Perhaps these old PERL scripts should be replaced with newer PYTHON scripts.

DAQ upgrades and new QFS server WP5964

Dan, Carlos  Jim, Dave:

Dan upgraded the QFS servers h1ldasgw0, h1ldasgw1 and h1dmtqfs0 Solaris machines. These were fully patched, and the QFS file sysem they control was file-system-checked.

Dan installed a new QFS server called h1ldasgw2. This is a Sun X2200, with redundent fiber channel ports which directly connect to the two Qlogic switches.

In the new configuration, h1ldasgw0 only exports /ldas-h1-frames to h1fw0 on the private LAN (no longer exports to h1nds0). h1ldasgw1 only exports /cds-h1-frames to h1fw1 on the private LAN (no longer exports to h1nds1). h1ldasgw2 NFS exports both /ldas-h1-frames and /cds-h1-frames to both nds machines in read-only mode.

The hope is that the frame writers will be more stable if their NFS/QFS server is not also serving NDS requests.

h1nds1's RAM was doubled from 24GB to 48GB by the insertion of 3*8GB SIMM cards harvested from x1work.

ASC new code

Jenne, Jim, Dave

new h1asc model was installed. We were surprised that an excitation was started immediately once the model got running. This looks like a script constantly running the excitation of H1:ASC-POP_X_PZT_YAW_EXC

Does anyone know what is doing this?

DAQ Restart

Daniel, Dave:

The DAQ was restarted to support all of the above model changes. Latest Beckhoff INI files were installed.

Tesing Scientific Linux 7.2 on LHO DMT WP5969

Dan:

Dan is upgrading h1dmt2 from SL6.5 to SL7.2 as a test bed for the new OS in preparation for a pre-ER9 upgrade.

cdswiki upgrade WP5956

Jonathan, Carlos:

work is underway to upgrade the cdswiki machine

Terminated and landed a new cable for PT100-A, old cable was 22 AWG, new one is 18 AWG.

As a note, we used a pigtail cable with a HD DB15 connector.

Evan G., Darkhan T., Travis S.

Both end station PCals were calibrated today during the maintenance period.  Stay tuned for results.

Surveyed all eight CP LLCV stems for loctite blue 242 application. CPs 2, 4, 5 now have loctite and were re-zeroed (CP5 has broader range). The others' stems were so tight that I couldn't loosen, so I assumed they don't need loctite.

NOTE:  CP 2 & 5 stems were starting to unthread from the actuator coupling nut again, prior to loctite application. 

*Nominal value for IM4 YAW updated to reflect current H1 alignment.

J. Kissel

I've added the new PI models' SDF lights to the SDF overview screen, as well as including which snap file is loaded onto the SDF overview. I've also done a bit of rearranging. 
/opt/rtcds/userapps/release/sys/h1/medm/SDF_OVERVIEW.adl
has been committed to the svn repo.

Attached is a screen shot of the new hotness.

SR2 Top Satellite Box OSEM Photodiode Oscilloscope Traces

The oscilloscope traces attached show a comparison of the time domain signals between SR2 Top OSEM Photodiode A and SR2 OSEM Photodiode B, as seen from connector J2 "Analog Rack". (We use the satellite box signal and connector naming conventions as shown on D1400098-v1.)  OSEM Photodiode A was from the SR2 Top OSEM, the suspect channel.  In the images, the upper trace, labeled "1", is from OSEM Photodiode B, satellite box connector J2 pin 2.  The lower trace, labeled "2", is from OSEM Photodiode A, satellite box connector J2 pin 1, the noisey channel under investigation.

Two x10 probes were used.  The vertical scale factors for images 1 and 2 are 0.200 V/div.  The vertical scale factor for image 3 is 0.050 V/div.

Image 1 shows the satellite box as found, all cables connected. Photodiode A shows significantly more noise.

Image 2 shows the photodiode signals with the "Vacuum Tank" cable, connector J1, disconnected. All quiet.

Image 3 shows the photodiode signals with the "Vacuum Tank" cable reconnected to J1.  Both photodiode signals now have the same amplitudes. (Note the more sensitive scale factor for image 3.)

An intermitant? A poorly seated connector? Pickup from the SEI CPS 25kHz?  Betsy reported that the noise spectrum did not change!

(Richard M, Fil C, Ed M, Daniel S)

ECR E1600192.

Split Whitening Chassis S/N S1101627:

• On the interface chassis remove R7, R8, R9 and R10, R17 and R18 (disconnects in-vac cables and Z-switch).
• On the interface chassis jumper 220 pF capacitors on J3 between pins 1-3, 9-11, 2-4 and 10-12 (adds one pole of high pass at 7.2 kHz).
• On the 2nd whitening board remove C37, C38 and C39 (removes both poles of low pass).

AA Chassis S/N S1102788 & S1202201:

• On channels 15 and 16 remove C1, C6 and C9 (two poles of 10 kHz low pass).
• On channels 15 and 16 remove C7 (one pole of 10 kHz low pass).
• The twin-T notch was left in. It is fairly wide and attenuates ~17 dB at 50 kHz.

The attached plots show the transfer functions of

1. whitening chassis: OMC DCPD_A: same as before
2. whitening chassis: OMC PI DCPD_A: modified
3. whitening chassis: OMC DCPD_B: same as before
4. whitening chassis: OMC PI DCPD_B: modified
5. AA chassis: channel 15
6. AA chassis: channel 16

The OMC DCPDs have proven to be useful for monitoring the test mass acoustic modes around 15 kHz, but there is a lot of low-pass filtering in the readout chain that render them less useful for monitoring higher frequency acoustic modes. This is now being changed with modifications to the electronics that will provide separate, faster channels for PI monitoring:

• In-vacuum pre-amp: this has 2 poles at 16 kHz (these will remain, since in HAM6)
• Whitening board: 1 pole at 14 kHz; 1 pole at 18 kHz. These will be eliminated in the new chain.
• Anti-alias filter: 3rd order Butterworth low-pass at 10 kHz. These will be eliminated in the new chain.

The attached plot shows the magnitude response of the low-pass filtering in the previous case, and with the poles removed from the whitening and AA channels. It is no wonder that no PI modes have been seen above the 15-16 kHz grouping, as there is 40 dB of relative attenuation already at 25 kHz.

I also attach a 1kHz - 10 MHz transfer function of the in-vacuum DCPD readout that Koji measured at Caltech:

https://nodus.ligo.caltech.edu:8081/OMC_Lab/235

The infrasound mics have already been upgraded at LLO but today I removed the sensors at LHO.  I removed the sensors from the microphones in the CS, at EX, and at EY.  This meant unscrewing the bottom of the instrument box and pulling out some of the equipment.  As far as I could tell everything went as planned and the equipment will now be sent away for upgrades.

WP 5954

All of the 18bit DAC cards in h1susb123 and h1sush2a now successfully pass the autocal on both power up and restart of the IOP models.  Results shown below:

h1susb123 - power up
[   61.694760] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   67.057232] h1iopsusb123: DAC AUTOCAL SUCCESS in 5340 milliseconds
[   72.850938] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   78.213461] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   85.247010] h1iopsusb123: DAC AUTOCAL SUCCESS in 6571 milliseconds
[   90.610149] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   95.973497] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  101.336018] h1iopsusb123: DAC AUTOCAL SUCCESS in 5340 milliseconds
h1susb123 - IOP model restart
[  911.921930] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[  917.282286] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  923.070351] h1iopsusb123: DAC AUTOCAL SUCCESS in 5341 milliseconds
[  928.430617] h1iopsusb123: DAC AUTOCAL SUCCESS in 5344 milliseconds
[  935.453979] h1iopsusb123: DAC AUTOCAL SUCCESS in 6576 milliseconds
[  940.814416] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  946.174750] h1iopsusb123: DAC AUTOCAL SUCCESS in 5345 milliseconds
[  951.535191] h1iopsusb123: DAC AUTOCAL SUCCESS in 5341 milliseconds

h1sush2a - power up
[   48.086815] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   53.450158] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   60.479701] h1iopsush2a: DAC AUTOCAL SUCCESS in 6576 milliseconds
[   65.843077] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   71.640028] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   77.001396] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   82.364713] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
h1sush2a - IOP model restart
[ 1252.909059] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1258.269410] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1265.292831] h1iopsush2a: DAC AUTOCAL SUCCESS in 6572 milliseconds
[ 1270.653176] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1276.441059] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1281.801414] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[ 1287.161817] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds

Last week, Rana was inquiring about how locklosses affect oplev sums. 

Took a random sample of locklosses from O1 and came up with fairly consistent results for after a lockloss, so here's the nitty gritty:

• HAM oplevs sums don't change
• ETM sums drop ~3%
• ITM sums drop ~1%  (which is small compared to overall DC drift of the sum value)

Attached is an example of a lockloss from Nov.

We adjusted the pressure on the pwrmtr water circuit from its nominal 5 bar to 4.5 bar.  The flow rate to the
laser heads decreased somewhat.  Put the pressure back to ~5 bar to set the flow rate in the circuit to be
over 1.25 l/min.

    In doing so, the other flow rates seemed to behave as expected.  We will monitoring the flow rates and
pressures over the the next few days to see if anything settles out/down.






Jeff, Peter

I have set the level setpoint to 90% to exercise the new PID control.

Daniel, Ross, Carl, Kiwamu,

WP#: 5957

We made two modifications on the h1omspi, h1susetmxpi and h1susetmypi models as follows.

• We added all the I and Q down sampled channels to science frame at 2 kHz.
• We added two new OMC DCPD signals which don't get attenuated by two 10 kHz poles of the whitening circuits.

We are ready for tomorrow's model restart during the maintenance period.

[I and Q signals to science frame]

Since all the I and Q down sampled signals have been already recorded in commissioning frame, we just added a star symbol to each channel name in the DQ text field in the simulink models. In total, 24 channels (8 channels from each model) will newly go to science frame at 2 kHz.

[New DCPD signals]

We decided to do a quick hack on the OMC whitening board so that we don't suffer from the two 10 kHz poles (technically, 14 and 18 kHz from the differential receiver stage, see alog 21131) to obtain a better signal to noise ratio. Some more details of this quick hack will be reported by Daniel and Stefan later. In the mean time, we have edited the h1omcpi model so that it is capable of handling these two signals. In the first attachment it shows the two new ADC inputs (adc_0_14 and adc_0_15) which then go to a subblock called PI_DCPD. One can choose whether the normal DCPD is used for the PI error signal or the new signals by the two choice blocks that are behind the PI_DCPD block.

Once we become able to damp the PI modes using the new DCPD signals, we should get rid of the old DCPD signals. But for commissioning purpose, we are leaving the normal DCPDs available for now.

Also, we added these two new signals to commissioning frame at the full sampling rate at 64 kHz. So, in total, we now have four 64 kHz DQ channels, which should be reduced to 2 or 1 channels as we complete the commissioning at some point in future. The new DQ channels have the names as PI_DCPD_64KHZ_A(B)HF. Note that in order to save the test points for the normal DCPD signals, we pulled them out of a subblock and placed them at the top level as seen in the first attachment.

In the PI_DCPD subblock, we have placed controlled-IIR-fitlers so that they can be synchronized with the analog board settings as have been done in the LSC and ASC models. See the second attachment.

All the changes are checked into the SVN repo. We made sure that they compiled without errrors.