I was perusing the lsc model and noticed that it looked terrible. The reason was that the lsc/common/models/lsc.mdl file has been saved with matlab-2015b and looks very bad when viewed with matlab-2012b (please see attached screen shots).

Currently CDS has standardized on matlab-2012b for all front end model files. I checked all the H1 files and found we have three model files which have been saved with 2015b (lsc,mdl, h1isietmx.mdl and h1isietmy.mdl). Having a file written by different versions of matlab also makes 'svn diff' essentially worthless due to the large number of format differences.

I'll convert the 2015 formatted files back to 2012 format. Perhaps adopting a later version of matlab for CDS is a topic for discussion with a larger audience.

The left plot is the 2015-format file viewed with 2015b, the right plot is the same file viewed with 2012b.

J. Kissel, C. Vorvick, S. Dwyer

After this morning's reboot of the entire corner station (LHO aLOG 29302) we had a little bit of trouble re-locking the mode cleaner. We eventually realized, once again, that upon reboot the EUL2OSEM matrix values for the bottom stage of the HSTSs (i.e. M3 of MC1, MC2, and MC3) are restored, but they don't get loaded because the load button is a momentary. 

We have solved this before by requesting that all of these matrices be loaded in the ISC_LOCK guardian (see, e.g. LHO aLOG 25208), but we're often in a situation where we're trying to recover the IMC much earlier that we ever run the ISC_LOCK DOWN state. 

As such, I've copied the load matrix lines from the ISC_LOCK guardian's down state, and stuck them in the IMC_LOCK guardian's DOWN state. This way as soon as we begin to play with the IMC, these M3 EUL2OSEM values will be loaded. 

The new IMC_LOCK guardian code has been both loaded into the running system and committed to the userapss repo here, 
/opt/rtcds/userapps/release/ioo/common/guardian

Plot shows OSEM IN goes to zero, pitch goes to zero, but the COILOUT drive and voltmon remain essentially unchanged from before and after the event at 11:15UTC.

I cannot change OSEM values with alignment slider or by removing all drive from the coils.

Plot 2 shows all of the IMs and MC1 and MC3. 

IM4 Trans oscillates after the event, then is quiet.

I have already mentioned the possibility of a broken wire, to explain this event.

Jim B., Patrick T.

WP 6118

The IOC code was updated to directly include the device support code in the build directory instead of linking to a separately built support library. The source code from libavl and c_string was also moved into the IOC build directory.
The IOC database was updated to add the humidity channels listed here: https://dcc.ligo.org/LIGO-L1600108

I ran into some build issues stemming from the fact that h0epics2 is running Ubuntu 10.04.4 and the repositories for it have been taken down. I instead compiled and started it on h0epics (Ubuntu 12.04.5), after Jim B. installed libcurl4-openssl-dev, make, g++ and libreadline.

I noticed that the H0:FMC-MILLIAMP_MAXVAL channel has not been set and has thus been defaulted to 0. This is used in the conversion from milliamps to percent for a number of records. As a result these records have had values of inf (divide by 0). I set H0:FMC-MILLIAMP_MAXVAL to 12.0. Perhaps this should be hardcoded in the database.

The added humidity channels are:
H0:FMC-CS_OSB_RM132_RH_PCT
H0:FMC-CS_OSB_RM161_RH_PCT
H0:FMC-CS_OSB_RM162_RH_PCT
H0:FMC-CS_OSB_RM163_RH_PCT
H0:FMC-CS_OSB_RM165_RH_PCT
H0:FMC-EX_DIS_RH_PCT
H0:FMC-EX_OSA_RH_PCT
H0:FMC-EX_SPACE_RH_PCT
H0:FMC-EY_DIS_RH_PCT
H0:FMC-EY_OSA_RH_PCT
H0:FMC-EY_SPACE_RH_PCT
H0:FMC-LVEA_AHU1_DIS_RH_PCT
H0:FMC-LVEA_AHU1_OSA_RH_PCT
H0:FMC-LVEA_AHU1_SPACE_RH_PCT
H0:FMC-LVEA_AHU2_DIS_RH_PCT
H0:FMC-LVEA_AHU2_OSA_RH_PCT
H0:FMC-LVEA_AHU2_SPACE_RH_PCT
H0:FMC-MX_DIS_RH_PCT
H0:FMC-MX_OSA_RH_PCT
H0:FMC-MX_SPACE_RH_PCT
H0:FMC-MY_DIS_RH_PCT
H0:FMC-MY_OSA_RH_PCT
H0:FMC-MY_SPACE_RH_PCT

These channels are not yet in the DAQ.

I burtrestored the IOC to earlier this morning to set the alarm levels.

WP6120

Daniel, Keita, Jim, Dave:

We installed a spare Dolphin card into the h1psl0 front end computer. The sequence was:

1. change h1ioppsl0 model to add the pciRfm=1 flag
2. edit h1psliss model to add two dolphin receivers and process this data
3. edit h1lsc model to pickoff TR_[X,Y] and send as two new dolphin channels
4. edit dolphin manager's node configuration and restart on h1boot
5. h1psl0: kill models, power down, install Dolphin card, connect to switch, power up.
6. On power up of h1psl0 the MSR Dolphin fabric glitched (as we suspected) which stopped all SUS, SEI and ISC models in the corner station.
7. h1ioppsl0 IRIG-B drifted negative, we waited until it became good before we could check the new Dolphin IPC was functioning correctly.
8. we restarted the sender (h1lsc0), but the dolphin was not working. After scratching my head a bit, I realised I had not loaded the new h1lsc model. Once I did this, all was working correctly.
9. restarted all models on all MSR front ends which are on dolphin
10. restarted the DAQ to resync to the new h1psliss model

We found that the PSL-OPC shutter still closed, investigating this offline.

I checked that the received data on the two new dolphin channels were correct, and they are.

I noticed that the channels are called TR_[X,Y]_NORM but they are picked off before the NORM filter modules in the LSC model, so perhaps not normalized or incorrectly named.

Running a Worden experiment:

-CP4 at 88% full
-Set LLCV to nominal in manual mode (41% open)
-Increase LLCV by 5% (43% open) and leave it at this value
-Monitor increase in fill
-Allow fill to exceed 100% and monitor exhaust flow meter (expect a sharp increase in flow when liquid starts to hit warm exhaust)
-After this sharp increase, reduce LLCV by 10% to below nominal (<41%)
-Hope that no LN2 reaches the flow meter this time (when flow approaches 100% I will monitor while sitting next to exhaust to be ready to open bypass exhaust valve and remove flow meter with LN2 gloves on)

**THIS WILL GENERATE CP4 ALARM ON PUMP LEVEL**

DIAG_MAIN was reporting that IM2 P and Y were out of normal range, and after trending them I saw that they were WAY out of range (Normal for H1:SUS_IM2_M1_DAMP_P_INMON is 603 and -205 for Y). The values now are at P = 0 and Y=-19. The trend shows a sudden move at around 11:15UTC (4:15PST), when no one was here and the IFO was unlocked. The most recent lockloss before that was at 8:03UTC. The suspension has been aligned with no trips since the 18th, and HAM2 has been Isolated since the 19th, no trips.

The other IM's also seem to show signs of movenment then, but nothing as extreme as IM2. 1&3 seemed to get noisy after 11:15. (see attachment)

What could have caused this move?

Chandra, Kyle

Attached are scans following the most recent bake of the Vertex RGA. The pressure in the Vertex at the time of these scans was 3.4 x 10-9 torr as indicated by the nearest CC gauge.  The bake out of this RGA was resumed following these scans.

[Jenne, Terra]

We've been pretty frustratingly plagued by the CSOFT / dPdTheta instability today.  Earlier today with Sheila, we were able to use the offsets from yesterday, but then later in the evening those offsets make things unstable when we go up in power.  I'm starting to wonder if an initial alignment needs to be done, since the green arm powers (measured at LockingArmsGreen, or anything early in the sequence) have been decreasing with each lock.  Maybe that will help? 

Sheila migrated the Soft offsets into the trans QPDs, so the IFO now aligns to that placewhen the soft loops come on.  Also, the POPA offsets are engaged during ASC_Part2, so the IFO is aligned to yesterday's place.  However, with this alignment at 2W, we cannot engage the roll mode damping.  The last few hours we've been skipping over EngageRollModeDamping, and I've commented out the final roll mode gain setting that used to happen in DC readout.  We don't seem to usually have much of a problem just leaving the damping off, but we can turn it on once we're at at least a semi-high power (maybe 20+ W?). 

Since we kept being troubled by the CSOFT instability, we went back to trying new offsets.  We think there's a little more that could be done, but we have a place where the recycling gain stays fairly constant as we power up.  The recycling gain looks terrible at 2W (30ish), but then only decays to 28ish.  This is in comparison with the usual decay to 22ish.  Also with this alignment, when we're at high power, the green arm transmissions are both high.  This seems like something that we want, since we think that the green and red beams are pretty well co-aligned after the Soft loops come on, so hopefully this means that we're closer to finding a place that maintains the alignment of the IFO from 2W to 50W. 

In the SDF screenshot, the POP_A offsets in the setpoint are what Sheila and Terra found last night, while the current values are the place that we like best so far tonight.  The setpoint offsets for the soft loops aren't meaningful, but the current values are the ones that we like from tonight, which are on top of last night's offsets (which have already been put into the QPDs and accepted in SDF). 

Attached also is a screenshot showing two striptools (and a bunch of other stuff that's basically ignorable).  Right around -100 minutes is the inital power-up and corresponding power recycling gain drop.  You can see that as we move offsets around, we're obviously changing the red and green arm powers, as well as the recycling gain.  Note though the time around -15 min where both green arm transmissions (blue and teal) are high, and the PRC gain is high.  Xarm green seems most strongly affected by Pop_A_pit, while Yarm green seems most strongly affected by DSOFT. 

To help maintain these locks, we were increasing the ISS 3rd loop gain from -1 to -10.  Also, we increased the SOFT Yaw gains from 3 to 7, and the Soft Pit gains from 0.5 to 0.7.  This seemed to ameliorate most instabilities, although we still are sometimes struggling to hold the lock - I think it's perhaps an indicator of needing an initial alignment.

H1 Commissioning

Jenne, Terra, & Sheila were at the helm for H1 higher power work.

MEDM work

Made a corrections to the sitemap (IFO Common Mode Servo on pull-down), and to the Digital Video Overview (added name for POP Air camera at the CAM30 postion).

Stranger Things Happening Around Gate Tonight

Happened to catch a vehicle rolling on site around 9:45 (it turned toward the LSB, turned around, & lingered before leaving).  The other oddity here was this car illuminated another vehicle as it approached.  This vehicle was at the gate with lights off.  Monitored the care for about 30min, called out to the Gate phone, and then three of us went to investigate.  There were about 4-6people, and they were looking at the stars.  They said they had talked to someone on the phone about coming out to watch the sky. 

Upon returning to the OSB, we checked the external front door lock to make sure it hadn't been unlocked (luckily it was locked).  The group eventually left (so they were here for atleast an hour.  

Gerardo, Chandra

On Tuesday, Aug. 23rd, we adjusted potentiometer on PT-140a (pirani) again - this time CCW 11 turns. Since Gerardo terminated cables for AIPs, gauge voltage has changed again and needs to be adjusted again so CC does not keep tripping due to set point interlock.

Summary:
Repeating the Pcal timing signals measurements made at LHO (aLOG 28942) and LLO (aLOG 27207) with more test point channels in the 65k IOP model, we now have a more complete picture of the Pcal timing signals and where there are time delays.

Bottom line: 61 usec delay from user model (16 kHz) to IOP model (65 kHz); no delay from IOP model to user model; 7.5 usec zero-order-hold delay in the DAC; and 61 usec delay in the DAC or the ADC or a combination of the two. Unfortunately, we cannot determine from these measurements on which of the ADC or DAC has the delay.

Details:
I turned off the nominal high frequency Pcal x-arm excitation and the CW injections for the duration of this measurement. I injected a 960 Hz sine wave, 5000 counts amplitude in H1:CAL-PCALX_SWEPT_SINE_EXC. Then I made transfer function measurements from H1:IOP-ISC_EX_ADC_DT_OUT to H1:CAL-PCALX_DAC_FILT_DTONE_IN1, H1:IOP-ISC_EX_MADC0_TP_CH30 to H1:CAL-PCALX_DAC_NONFILT_DTONE_IN1, and H1:CAL-PCALX_SWEPT_SINE_OUT to H1:CAL-PCALX_TX_PD_VOLTS_IN1, as well as points in between (see attached diagram, and plots)

The measurements match the expectation, except there is one confusing point: the transfer function H1:IOP-ISC_EX_MADC0_TP_CH30 to H1:CAL-PCALX_DAC_NONFILT_DTONE_IN1 does not see the 7.5 usec zero-order-hold DAC delay. Why?

There is a 61 usec delay from just after the digital AI and just before the digital AA (after accounting for the known phase loss by the DAC zero-order-hold, and the analog AI and AA filters). From these measurements, we cannot determine if the delay is in the ADC or DAC or a combination of both. For now, we have timing documentation such as LIGO-G-1501195 to suggest that there are 3 IOP clock cycles delay in the DAC and 1 IOP clock cycle delay at the ADC.

It is important to note that there is no delay in the channels measured in the user model acquired by the ADC. In addition, the measurements show that there is a 61 usec delay when going from the user model to the IOP model.

All this being said, I'm still a little confused from various other timing measurements. See, for example, LLO aLOG 22227 and LHO aLOG 22117. I'll need a little time to digest this and try to reconcile the different results.