I started it back up with the previous channel list. It looks like it must be a problem with one of the channels that Dave tried to add. The error it logged was:

Sep 30 14:23:51 h1conlog2 conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Out of range value for column 'value' at row 1: Error code: 1264: SQLState: 22003: Exiting.

This would seem to imply that the value for one of the process variables was out of the range of the data type in the database. I'll try to narrow it down tomorrow.

See the linearity results attached.

The Range Of Motion results is unable to check (with the current script) H1-, V1+, & V4+ due to current offset on the IPS.  This needs to be reworked.

Maintenance Day Summary of CDS code Status:

Model code with local modifications with respect to SVN repository:

Alexa, Kiwamu, Jim, Dave

h1ecatx1 EPICS channels froze at 11:04PDT. The EPICS IOC was stil running, but all data was frozen and white-invalid. We restarted the computer and Alexa restarted the EPICS IOCs for SYS and PLC[1-3].

The ISS second loop photodiodes are very well coherent with the IMC WFS B yaw signal, as visible in the first plot.

This WFS is used for both DOF1 and DOF2 of the IMC alignment. I added an offset to the DOF1 yaw error signal. This improved significantly the intensity noise at almost all frequencies, see the second plot.

The thrid plot is a spectogram of the intensity noise as a function of time. The bottom trace shows the IMC DOF1 error signal. It is clear that a mean value of 250 counts gives lower intensity noise. It is also clear that intensity noise is highly non stationary, even with a good IMC offset.

The fourth plot shows the same story, but this time intensity noise is characterized with a trace showing the band-limited RMS between 100 and 200 Hz. Using the best IMC alignment offset reduces the noise in the band by a factor ~10. The last plot is a zoom into the last minuts of the test. It is clear that the residual fluctuations of intensity noise are related to the residual angular motion of the IMC.

In summary, we can improve a lot the intensity noise at the output of the IMC by choosing a better alignment position, and by improving the accuracy of the angular control loops.

NOTE:  Today there is a tour of the Hanford site for LIGO staff from around lunch time - 5pm.

Day's Activities

• Observation Bit was found in Commissioning state over night
• 8:02:  Bubba heading to EX to grab a vacuum
• ---:  Richard investing Beckhoff/slow controls error in the LVEA
• ~9:00:  Chris vacuuming at EX (it had been a while, dust counts will elevate, Commissioners:  is this OK during the day???)
• 8:43:  Danny heading out to work on Quad (Betsy will follow)
• 9:13:  Pulling Cables from HAM3 to Beer Garden (per Aux Power work permit) [Filiberto]
• ~9:45-955:  Drive to EY for ISC EY power cycle of IO Chassis [David Barker]
• 9:20-9:50:  BSC2 inspect HEPI inspection.  May take down the ISI/HEPI [Hugh Radkins]
• 10:00:  Peter K checking cables at HAM2
• 10:15:  Sheila slow controls work
• 10:23:  Unifirst
• 10:38:  Paradise
• CP Overfill Alarms at CP4 (signifying a Praxair delivery)
• Had the Slow Control Computer close at EX (seems to be a recurring thing on Tuesdays so far)

Leaving for Tour at 11:30 (Jim W & Dave will help cover the afternoon)

This morning I reset Counters for following HEPI systems:  HAM2, HAM3, HAM4, BSC3(itmx), & BSC3 (BS).

Note:  BSC3 & HAM3 continue to have saturations though.

WP 4869

The user environment has been changed to set up the awgstream environment properly.

The CERN ROOT package has been replaced with a version that supports python.

The gds software (diaggui, foton, etc) has been updated to gds-2.16.12.2, which has a number of bug fixes and a few enhancements:

* python scripting capability for awg and foton have been added.
* Cut/paste added to the Calibration dialog box in diaggui (and foton).
* Long channel names are no longer ignored in the Calibration dialog box.
* Fix bug preventing diaggui from reliably making continuous measurements.
* Unsigned 32 bit integer data support for diaggui time series.
* Foton legacy write option has been removed.
* Fix foton bugs for file path option, add "-o " option for non-gui file processing.
* Fix foton bug which caused crashes when invoked from diaggui.

Sudarshan, Jim and Dave

We power cycled h1iscey as part of the investigation to fix some dodgy ADC channels, we were not successful.

sequence:

take h1iscey out of dolphin, stop models, power down CPU, power down IOChassis, power down PEM AA chassis.

power up AA, power up IOChassis, power up CPU.

Sudarshan, Gabriele

To try to reduce as much as possible the beam pointing sensitivity of the ISS photodiodes, we wrote a python script that reads the PD signals and demodulate them with the excitation sent to IM3. In this way we could send a 12 Hz, 1000 cts sinusoid in yaw and a 17 Hz, 1000 counts sinusoid in pitch, and look at time domain traces of the demodulated signals, as shown in the first attached plot. We moved a bit the picomotors, and we could improve quite a lot the situation. As shown in the second plot, right now we almost can't see the sinusoids in the PD signals, since they're below the noise background. Here are therefore upper limtis on the dP/P/dx:

The optimal position we found is not exactly with the QPD centered (both x and y are around 0.3). Maybe we could improve this, but for the moment we guess the situation is good enough.

Per the weekly Tues Maintenance task, the chiller was topped off to the MAX level mark (needed ~250ml to do this).  The stopper for the Chiller isn't ideal (seems a bit big and sheds a bit to make it seat in the inlet).  Last time the chiller was filled was on 9/15/14.

I measured the beam pointing sensitivity of all the eight ISS second loop diodes. The naming is the one corresponding to the new slow channel acquisition, we'll check tomorrow the correspondence to the PD1-8 signals. For some diodes, in pitch, I was not able to see any significant modulation

For those not familiar with the meaning of these numbers, the typical values measured for the ISS array before installation were between 1 and 30, depending on the array and on the diode. So the numbers I got are in general quite large.

This beam position on the PD is maybe not the best one, since we are not at the maximum power for all the diodes simultaneously. For each diode, it is possibile to find a beam position that gives maximum power. This also corresponds to undetectable coupling of beam motion to dP/P (at least at this level of excitation). However, the good position is different for each diode, and the non optimal one can have a significant loss of power and large coupling of beam motion to dP/P. The table above is representative of what we normally get.

Here is the procedure in details

1. Move the beam using the picomotors to center the QPD. Dither IM3 with an amplitude of 100 counts at 1 Hz in both pitch and yaw (H1:SUS-IM3_M1_OPTICALIGN_P_EXC and H1:SUS-IM3_M1_OPTICALIGN_Y_EXC), and measure the normalized signal on the QPD. I got 0.14 peak to peak in pitch and 0.22 peak to peak in yaw. The beam size on the QPD should be 250 um. The normalized signal should be given by sqrt(8/pi) * deltaX / w where deltaX is the beam motion on the QPD and w is the beam size. Therefore, 100 cts at 1 Hz of IM3 correspond to 22 um in pitch and 35 um in yaw of beam motion on the QPD. I assume that the motion on the photodiode is the same. 
2. With the dither on, I measured the mean value of each of the photodiode and the peak to peak oscillation at the dither frequency, separately in pitch and yaw. I had to move pitch of 300 counts (70 um beam motion on the diodes) and yaw of 100 counts (35 um of beam motion on the diodes). Larger amplitudes were giving weird signals.
3. From the photodiode signals I computed the dP/P and then the dP/P/x reported above

Comparable to other Level3s.

Weekly report of various things.

There are daily spikes in the H1 chiller and diode room relative humidity.  The spikes also occur in the chiller room temperature but not in the diode room,
or at least the ones in the diode room are not as large.

Relative power noise looks nominal.  Better than the reference measurement below 10 Hz and a factor of a few worse between 10 Hz and 4 kHz.  The ISS was locked at the time with a diffracted power of ~9%, REFSIGNAL -2.03 V, and output DC of 10.01 V on PDA, 10.19 V on PDB.  Gain slider on 10 dB.

Frequency noise is better than the reference measurement above ~500 Hz, worse below.  Otherwise the same as per previous weeks.

Beam pointing looks nominal.  All better than the reference measurement.

Mode scan looks nominal.  Higher order mode count slightly higher than last week, 55 cf. 56.  Higher order mode power slightly higher too, 4.7% cf. 4.6%.  Nothing to worry about.

ISS relative power noise looks good.  The out of loop measurement (PDB) is flat from 3 Hz to ~100 Hz, at ~1.3E-8.  Rising to ~2E-8 at 1 kHz.

Now with added "damped" plots.  Note, the damping loops on the electronics test stand are hodge podge and so damping was poor for some regions of many loops.  As well, like I mentioned in earlier logs, the coherence of this in-air QUAD is poor at lower frequencies.  I spent some time trying to work out better excitation filtering/boosting but to no avail.  Damping works on both M0 and R0 chains of Q6.

QUAD 06 (Q6) Phase 1B transfer function plots are attached.   We had a hard time obtaining good coherence in the Transverse TF, so it is a bit hashy.  Will try again.  

Most notably is that, like Q8, the second pitch mode frequency is unexpectedly pushed upward on the main chain.  Recall, we never found the mechanism to fix it on Q8.  Interestingly, both the Q8 and Q6 assemblies are of the same batch of wires and are fresh builds, but by 2 different assembly teams, and on 2 different solid stack/test stand units.  Q8 is an ETM type of QUAD while Q6 is an ITM QUAD, but both main chains have the same pendulum parameters - both are detailed in the 'wireloop' model.

The Q6 data is plotted as QUADTST.

J. Kissel

I was warned that -- though all the GND STS channels are mapped from the instrument to the frames correctly now (see LHO aLOG 14072) -- what actually gets fed into the sensor correction filter banks is a total mess in the corner station. I've scoured the front-end simulink models, toggled some switches at the racks in the EE bay, and stomped on the ground near the STSs themselves trying to map it out, and all I can say is WOW do I agree. I'll work with the SEI and CDS groups to clean up.

Here're the facts, as they stand now, in order of my discovery:
(1) In reality, we want the following seismometer-location-to-channel map for all 17 digital instances of the signals in the corner (6 HAM HPIs, 5 HAM ISIs, 3 BSC HPIs, 3 BSC HPIs):
       Just +X of HAM2    => STS A
       In the Beer Garden => STS B
       Just +Y of HAM5    => STS C
as determined by D1002704, revised due to Integration Issue 45, and DCN E1400111.
(2) I've confirmed that the above mapping is correct for ITMY (the "master" front-end model responsible for storing these STSs and "GND" channels in the frames) by performing my finest hill-billy hoe-down near the respective STS, and watching the ISI-GND channels on a CDS laptop. 
(3) Because of the STS-2 analog distribution chassis, and that the SEI BSC wiring diagram (D0901301), and SEI HAM wiring diagrams (D1101584, D1101576, and D1000298) were written before the ABC convention was established and not addressed in E1400111, there're 17-choose-3 = 680 possible combinations, and I'm pretty sure we used all of them.

Front end models:
(4) ALL HAM-ISIs use the library part, ${userapps}/release/isi/common/models/isihammaster.mdl. There is another library, isiham236master.mdl, that looks deceiving in the same directory, but it's unused according to the tar balls of source code for what's actually running on the IFO. This should be removed from the repo.
(5a) The HAM-ISIs  are reasonably consistent, in that, 
       ADC_0 or ADC_2 Channels 24-26 => STS A XYZ
       ADC_0 or ADC_2 Channels 28-30 => STS B XYZ
       ADC_1 or ADC_3 Channels 24-26 => STS C XYZ
where it's ADC_0/1 on the "first" HAM-ISI in the I/O chassis, and ADC_2/3 on the "second" HAM-ISI (HAM2, HAM4, and HAM6 are the "firsts," HAM3 and HAM5 are the "seconds."). 
(5b) EXCEPT HAM2, who has ADC_0 channels 24-26 mapped into BOTH STS A and STS B. 
(6) Because of an RCG "feature" even though different ADC *card* numbers are used between the seconds and firsts, the block name is always ADC 0 or ADC 1. 
(7) The HAM-HPIs all use the same library part, ${userapps}/release/hpi/common/models.
(8a) HPIs HAM2-5 have GND STSs hooked up, also, reasonably consistent in that they all use
       ADC_0 or ADC_2 Channels 24-26 => STS A XYZ
all piped into STS A, with STS B and STSC terminated. Again, the "firsts" use ADC0, and the "seconds" use ADC 2. 
(8b) EXCEPT HAMs 1 & 6 have all STS inputs terminated.
(9) The BSC ISIs and the BSC-HEPIs are consistent, but consistently bonkers.
       BSC1 ITMY ADC_3   23-25 => STS A
                         26-28 => STS B
                         29-31 => STS C
       BSC2 BS   ADC_3   29-31 => STS A
                         23-25 => STS B
                         26-28 => STS C
       BSC3 ITMX ADC_3   26-28 => STS A
                         29-31 => STS B
                         23-25 => STS C
That's right -- the channels have been cyclically rotated between BSC chambers.

Electronics Chain:
To test out which STS chassis maps to which GNDSTSINF (for ISIs) or STSINF (for HPIs), just in case the STS distribution chassis had been used to rectify the front-end badness, I toggled the period switch on the front of each of the three chassis, in consecutive order, and followed which channels showed the characteristic flip to (more) AC coupled signal (1 [sec] period) and then drove off into tilt land after switching back to the low-frequency mode (120 [sec] period). Since I didn't want to disconnect any cables, and couldn't simultaneously look at all the channels needed with the tiny laptop while zydeco dancing, all I could determine which which *rack* affected which GNDSTSINf or STSINF channel.
(10) BSC 1 (ITMY) ISI and HPI on-board sensors are read out in rack SEI-C4, BSC2 (BS) ISI and HPI are read out in rack SEI-C5, and BSC3 (ITMX) ISI and HPI are read out by rack SEI-C6. As such, I'll refer to the STS chassis that I switch as C4, C5, and C6, after the rack in which they're mounted, since I was unable to determine which was HAM2 (STS A), Beer Garden (STS B), or HAM5 (STS C).
(11) For the BSC-ISIs, the matrix of channels affected by the switching is as follows:
          ITMY     BS      ITMX
     C4     A       A       A
     C5     B       B       B
     C6 (bonkers)   C       C
This indicates that, even though the ADC to model mapping is some crazy, cyclic thing, the cables from the STS distribution chassis have been arranged such that what goes into the ADC is "normal." The ITMY STS C channel doesn't make any sense to me. It didn't respond to any of the period-switch toggles, but still showed live tilt-full signals. Need to debug that one.
(12) For the BSC-HPIs, it's different:
          ITMY     BS      ITMX  
     C4    A        B       C
     C5    B        C       A
     C6    C        A       B
This indicates, that the cabling matches the crazy-bonkers front-end mapping.
(13) For the HAM-ISIs, it's different:
           HAM2     HAM3     HAM4     HAM5     HAM6
     C4    A&B       A      (dead)   (dead)      A
     C5 (no change)  B      (dead)   (dead)      B
     C6     C        C      (dead)   (dead) (no change)
HAM2 is weird, but is consistent with the model layout described in (5b). HAMs 4 and 5 are receiving only ADC noise -- maybe this means the channels aren't hooked up? I didn't check.
(14) And finally, the HAM-HEPIs, they're the worst off:
           HAM1     HAM2     HAM3      HAM4      HAM5     HAM6
     C4   (n/c)      A        B       (dead)    (dead)    (n/c)
     C5   (n/c)     (n/c)    (n/c)    (n/c)      (n/c)    (n/c)
     C6   (n/c)     (n/c)    (n/c)    (n/c)      (n/c)    (n/c)
where "n/c" is not connected in the front-end model as described in (7a). Still no help as to why HAM4 and HAM5 are reading out ADC noise.
And that's the anti-climactic end of the list. We've got some work to do!

Step-one will be to update the SEI wiring diagrams to clearly define how each STS gets into each front-end via an ADC channel list. Next, change the top-level front end models to match the convention in the drawings. Third, change the cabling at the racks around so we get the expected behavior. At the moment, although it's don't in an icky way, the BSC-ISIs are our best case.