~Two more 5.2mag aftershocks this morning on the Southern East Pacific Rise near Easter Island~ 

08:00 Morning checklist: Reset ALH; vacuum system looks ok - HAM6 cold cathode pressure reporting 10^-7;  CDS/DAQ - everything looks normal.

08:30 Morning meeting

08:42 Krishna to X-End to do some BRS testing/tweaking

09:20 Krishna back from X-End

09:50 Keita to End Y to align green WFS. He will be using ETMY/ITMY/BS/PR3

10:14 Dale into the control room with a tour group

12:04 Jason to End X to align OpLev

12:30 Adjusted ISS Diffracted power to ~9.5% by reducing the refsignal voltage from -2.01 to -2.05

12:37 Jason back from End X

14:45 Sudarshan into LVEA, crawling under HAM2

12:48 Keita back into control room from End Y

12:50 Sudarshan back from crawling

J. Kissel, K. Venkatewara

Jeff K. designed a model to use the GND_Supersensor (tilt-corrected STS) to do sensor correction on Stage 1.

To get the supersensor, we take the GND_STS and add the Tilt signal from BRS converted to velocity units by multiplying g/w. To further correct for the small amount of acceleration present in BRS, we further add a factor of F * V_STS * g/w^2 where F = M * d  /  I  (M=Mass of beam-balance, d = Center of mass offset, I = Moment of Inertia)

Jim and I will try to implement and test this next week when not interefering with commissioning activity.

J. Kissel, K. Venkateswara

We realized we had the wrong factor of 1/2 as described in alog entry 13448.  1/2 [V_sing / V_diff] was not needed/

The filters have been changed to account for the new calibration factor which is:

3.5e-6 [rad/pixel] * 1 [pixels/V_sing] * 1/2 [V_sing / V_diff] * 40/2^16 [V_diff/ct] * 1e9 [nrad/rad] =  2.1362 [nrad/ct]

At ~12:34PT I adjusted the diffracted power in the ISS to ~9.5% as instructed by Rick Savage. The refsignal is currently set to -2.05V.

J. Kissel

I've arrived at numbers for refining the calibration of the ETM OPTICALIGN alignment offset sliders, using the same method as was used for the ITMs and BS (see LHO aLOGs 14265 and 14321, respectively). The new slider gains should be 
EX P =  15.344 [ct/urad]
   Y =  44.044 [ct/urad]
EY P =  19.341 [ct/urad]
   Y =  51.013 [ct/urad]
which are comparable to the ITMs' calibration, as expected.

I have not installed these new gains, nor have I corrected the saved alignment offsets since it will be too disruptive to commissioning. These can be installed at anyone's convenience, but I'll install them in week if know one's gotten around to it. 
The to-do list:
- Record current OPTICALIGN OUT values (in [ct]), to confirm you get the same answer after updates
- Install above calibration gains
- Restore to ALIGNED via guardian, enter in predicted offset values (in [urad]) below (adjust, if necessary, to get the previously recorded output value in [ct])
- Save ALIGNED value using pull-down menu in IFO_ALIGN MEDM screen
- Restore to MISALIGNED via guardian, enter in predicted offset values (in [urad]) below (adjust, if necessary, to get the previously recorded output value in [ct])
- Save MISALIGNED value using pull-down menu in IFO_ALIGN MEDM screen
- svn commit the updated aligned and misaligned .snap files in the ${userapps}/release/sus/h1/burtfiles/ directory
- IF AMBITIOUS (and commissioning team gives you some time) -- perform refinement of optical lever calibration with these new values, as was done with the ITMs and BS (see LHO aLOGs 14312 and 14387).

Details
-----------
The current alignment offset slider calibrations for both EX and EY are
23.219 [ct/"urad"]
51.689 [ct/"urad"]
and currect stored alignment offsets are
                  P       Y    ["urad"]
EX Aligned     274.1    63.9
   Misaligned  240.0   102.0

EY Aligned      83.4   -64.8
   Misaligned   62.0   -7.72

The ETM alignment slider values to hit the center of the ITM baffle PDs are
         P     Y     ["urad"]
EX PD1 261.4  79.75
   PD4 285.2  49.1
delta  23.8   30.65  
claimed displacement = 2*delta
       47.6   61.3

EY PD1  70.5   -83.5
   PD4 100.5   -48.0
delta   30.0    35.5  
claimed displacement = 2*delta
        60.0    71.0
where the factor of two to calculate the displacement is from the single-bounce, optical lever effect.

We know from D1200313 and D1200296 the ITMX and ITMY (respectively) PDs 1 and 4 are 11.329 [inches] = 0.287757 [m] apart vertically, and 11.313 [inches] = 0.28735 [m] horizontally on both ITM baffles, implying an angular displacement -- over the L = 3994.5 [m] arm lengths -- of
P   0.287757 [m] / 3994.5 [m] = 72.03 [urad]
Y   0.28735 [m]  / 3994.5 [m] = 71.94 [urad]

which means the correction factor for the OPTICALIGN gain is
EX P  47.6  ["urad"] / 72.03 [urad] = 0.661 ["urad"/urad]
EX Y  61.3  ["urad"] / 71.94 [urad] = 0.852
EY P  60.0  ["urad"] / 72.03 [urad] = 0.833
EY Y  71.0  ["urad"] / 71.94 [urad] = 0.987
or

EX P = 1.5132 [urad/"urad"]               
EX Y = 1.1736             
EY P =  1.2005
EY Y = 1.0132

which are corrections comparable to the ITMs (good sanity check, since they have the same actuation chain, and used the same offset calibrations prior to the refinement).
So the new alignment slider calibation gains should be
       Old Cal               Correction            New Cal
EX P 23.219 [ct/"urad"] * 0.661 ["urad"/urad] =  15.344 [ct/urad]
   Y 51.689 [ct/"urad"] * 0.852 ["urad"/urad] =  44.044 [ct/urad]
EY P 23.219 [ct/"urad"] * 0.833 ["urad"/urad] =  19.341 [ct/urad]
   Y 51.689 [ct/"urad"] * 0.987 ["urad"/urad] =  51.013 [ct/urad]
and the predicted alignment offsets that need be installed are
    old offsets ["urad"] * correction factor [urad / "urad"] = new offsets [urad]

                 P       Y    [urad]
EX Aligned     414.77    74.993
   Misaligned  363.17    119.71

EY Aligned      100.12  -65.655
   Misaligned   -77.792   -7.822 
   

Keita, Sheila, Kiwamu,

Keita pointed out yesterday that there was a strange lock loss event of the DRMI in which the guardian seemed to have switched the state to a unlocked state even though the  PRC and SRC build-up were still sufficiently high. This is now understood and fixed.

We found out that this was due to our bad coding in the guardian. The "WFS_CENTERING" state had a unwated command (I don't exactly know what part was it) which brings the state to "DOWN" immediately. So every time when we requested the "WFS_CENTERING", it then shut down the lock. Sheila edited the code and now it does not show a funny lock loss any more.

The attached is time series from a second example of the funny lock loss. You can see that PRCL cut its input at t = 1.2 sec even though POP_RF18 and AS_RF90 were high. This was actually initiated by our request for the guardian to go to "WFS_CENTERING". Then it immediately transitioned to a wrong state DOWN, which shuts all the LSC control loops. Of course, this resulted in lock loss.

K. Venkateswara

I did another test to make sure the BRS damping works as expected. The attached pdf shows the results of the test. I disturbed the BRS by walking in its vicinity at t=200 seconds and the amplitude gets rung up. The turn-table starts damping it and it switches off after ~1000s.

DriftMonitor:

The channel H1:ISI-GND_BRS_DRIFTMON monitors the position of the beam-balance mirror pattern on the CCD camera. It was scaled to go roughly from +/-16k counts. But it looks like on the positive side it happens a bit earlier than that, roughly 14.5k counts. The second attachment (DriftMonOlder.png) shows the DriftMon output from August-September. It looks like it had already hit the edge on Sept. 4th. The code still works if the pattern goes over the edge but it can appear noisy if there is a partial pattern, so ideally we want to keep it in the working range.

The current DriftMon position is shown in the third file (DriftMonCurrent.png) after I completed the damper installation. It seems to be trending logarithmically towards -10k which is a bit lower than ideal but still in range. Adjustment of the position are not trivial and there are large drifts after each adjustment which are not always easy to predict, so adjustments should be avoided unless necessary. I will monitor it over time and if needed make further adjustments.

The setup script for the userapps directory has been modified to add paths for the new calibration subsystem, cal.  The environment variables USERAPPS_LIB_PATH, USERAPPS_MEDM_PATH, and USERAPPS_SCRIPTS_PATH have been modified, and environment variables CAL_SRC and CAL_IFO_SRC have been added.

This change is effective for new logins or new shells.

model restarts logged for Thu 09/Oct/2014
2014_10_09 08:51 h1fw1
2014_10_09 10:23 h1fw1
2014_10_09 13:12 h1fw1
2014_10_09 21:41 h1fw0

all unexpected restarts

In attendance: Sudarshan, Bubba, Vern. Keita Jason, Patrick, Krishna, Jeff, Hugh, Jim, Kissel, Gerardo, Fil, Aaron, Christina, Dick, Travis & Greg.

SEI- Nothing new to report. Going to wait and see what happens when the waves created by yesterday's 6.8 quake start hitting the west coast

SUS- Working on OpLev slider calibration

PSL- working on ISS outer loop

BRS- seems to be working. Maybe test/tweak one more time

Commish- Robust locking DRMI. ASC helping greatly.

3IFO- ongoing

Facilities- beam tube cleaning is ongoing

BSC2 Test Stand was shut down on Wed the 8th!

The setup script for the userapps directory has been modified to add paths for the new calibration subsystem, cal.  The environment variables USERAPPS_LIB_PATH, USERAPPS_MEDM_PATH, and USERAPPS_SCRIPTS_PATH have been modified, and environment variables CAL_SRC and CAL_IFO_SRC have been added.

This change is effective for new logins or new shells.

Kiwamu, Sheila

• We have 4 asc loops working for DRMI now, which seems to greatly help with the stability by bringing us to a good alingment.
• DRMI was locked on 3F, and is quite stable
• We have been able to lock ALS COMM +DIFF and DRMI on 1F, but not for long.
• All of this was at 10W

DRMI ASC helps stability

We have REFL A 9I going to PRM with a gain of 1e-3 in yaw, 1e-4 in pitch, and AS A 45 Q to the BS with a gain of -5e-5 in pitch and 1e-3 in yaw.   We looked at using REFL 45 I to feedback to the SRM, but the refl B signals have a large offset, and the refl A signals don't seem sensitve to motion of the SRM. We checked the phasing of the rel 45 wfs, (it was already good) and set the dark offsets, but this didn't help.  The four loops that we do have are working well, in the attached screen shot the loops come on at about -30 seconds, and bring us to a good build up.  After this, DRMI is stable and we have none of the mode hopping problems that have been plauging us,and preventing us from locking most of the day today.  Since taking that screen shot I've edited the guardian to bring the ASC on faster, because sometimes we loose the lock due to mode hopping problems before the asc comes on.  The slowest part is the AS WFS centering servo.  These asc loops are all in the gaurdian, as well as offloading, but the user has to decide when they have done their job and manually request offloading for now.

Stable 3F DRMI

After getting the drmi stable, on 1F, we moved it to 3F to confirm that it is stable after the improvements Kiwamu made last night.  That was easy, the gaurdian did it right away without any problems.  It was locked on 3F and left alone for a half hour with no disturbance, from 5:21:25 Sept 10 UTC to 5:51:07.  This is in the middle of almost 2 hours of locked DRMI.
 

DRMI+ALS

After this we attempted to lock DRMI with the arms controlled by ALS.  We had some sucess locking ALS without the ezca servo, (and slow feedback from the end station PDH).  but the slow feedback needs some work (it misalings the arms).  Kiwmau decreased the ALS DIFF gain from 0.8 to 0.5, (already in the gaurdian) which helps prevent saturations, and lets diff lock stably.  We were able to lock both COMM +DIFF+ find the IR resonances, offset the COMM VCO by 500 Hz (which is only 250 Hz in IR) and align PRM and SRM.  We couldn't engage the ASC like this.  We locked DRMI serveral times like this, but it quickly drops because of the mode hopping problem. 

I'm testing a new commissioning reservation system I wrote this afternoon using python. This is a file based system replacing the old EPICS system. The main reason for the change is that the old EPICS system developed problems related to updates and required a lot of maintenance. It was also awkward to configure and restrictive in what it could do.

The reservation file is /opt/rtcds/lho/h1/cds/reservations.txt

There are three python scripts:

make_reservation.py is available to all users, it allows you to create your reservation

display_reservations.py script loops every second and shows the currently open reservations

decrement_reservations.py script is ran as a cronjob every minute, it decrements the time-to-live of each reservation and deletes them when they expire.

I have a display running on the left control room TV closest to the projector screen.

Here is the usage document for the make_reservation.py script

controls@opsws6:~ 0$ make_reservation.py -h

usage: make_reservation.py [-h] system name task contact length

create a reservation for a system

positional arguments:

  system      the system you are reserving, e.g. model/daq

  name        your name

  task        description of your task

  contact     your contact info (location, phone num)

  length      length of time (d:hh:mm)

optional arguments:

  -h, --help  show this help message and exit

If you need to use spaces, surround the string with quotes. There are no limitations on string contents. Here is an example reservation

      make_reservation.py "PEM and DAQ" david.barker "update PEM models, restart DAQ" "phone 255" 0:2:0

J. Kissel

I happened to have the H1 ISI ETMY overview screen open and noticed a blinking red light in the bottom corner alarming that the pod pressures are low, indicative of a potential leak. Jim informed me that Gerardo had noticed this earlier as well (both interactions verbal, no aLOG). Further investigations reveal that, though the sensors indicate a slow leak over the past 5 months on all three L4Cs; the leak rate is ~0.25e-6 [torr-Liter/sec] (see attached 2014-10-09_H1ISIETMY_L4CPod_LeakRate.pdf) -- a rate that is 1/4th of what has been deemed acceptable (see T0900192). Indeed, for further comfort -- though Brian's original guess (see G1000561, pg 15) says that the pod pressure sensors might only be able to sense 5e-6 [torr.Liter/sec] - level leaks -- it appears that we are indeed at least a factor of 8 more sensitive than that. 

Though I don't understand it well enough to make adjustments, the action item is to 
(a) adjust the threshold to represent 1e-6 [torr.Liter/sec] (if we're still OK with that number). and 
(b) have @DetChar or @Operators make a similar study on the rest of the chambers across the project to ensure that the rest of the pods aren't leaking any worse than these L4Cs.

Note that this ETMY is the second oldest ISI (save the LASTI ISI) in the project, as it was installed just after ITMY for the H2 OAT.

Details / Logical Path / Figures
--------------------------------------
On the MEDM pod-pressure screen (accessible in the bottom right corner of the overview), Corner 1 L4C and Corner 2 and 3 T240 are blinking around 96-97, 100-101, and 100-100 [kPa] respectively, which directly correspond to the blinking alarm light. So, I trended them over the past 300 days. I quickly found that the signals have been non-flat, and in fact going down in pressure, indicative that the in-air pods were leaking air out to the in-vacuum chamber. I focused on the L4Cs, because they appeared to be the worst offender. After identifying that the major features in the 300-day minute trend time series: 
-- We begin to see data ~1/4 of the way into the time series, right when Hugh and Richard are cabling up the ISI ETMY, now moved into BSC10 on Feb 25 2014 (see 10360),
-- The hump that starts at ~1/3 of the time axis is the beginning of the chamber closeout, where kyle turns on the roughing pumps on March 28 (see LHO aLOG 11076), and 
-- Shark-fin feature 3/4 through the time axis which corresponds to Rai's charge dissipation experiments on Aug 06 (see LHO aLOG LHO aLOG 13274,
I believe that the sensors are indicating a real pressure signal, and not some electronics drift as Brian had worried in G1000561. Interestingly, the *differential* pressure does not show a trend, implying that all six L4C pods are leaking at roughly the same rate.

To quantify the leak rate, I grabbed the average of one hour of minute-trend data on the first of every month over the linear ramp down the of the pressure for all three L4C pods (i.e. from May 01 2014 to Oct 01 2014):

                Pod 1  Pod 2  Pod 3
pressure_kPa = [97.423 98.956 98.86;...   % May
                97.358 98.910 98.771;...  % Jun
                97.288 98.820 98.710;...  % Jul
                97.199 98.734 98.573;...  % Aug
                97.110 98.665 98.526;...  % Sep
                97.026 98.568 98.369];    % Oct
(At this point, I'm just *hoping* the pressure sensors are correctly calibrated, but we know that 1 [atm] = ~750 [torr] = ~ 100 [kPa], so it seems legit.)

Taking the matrix of 6 months by 3 pods, I converted to torr,
torr_per_kPa = 7.5;  % [torr/kPa]
pressure_torr = pressure_kPa * torr_per_kPa; % [torr]
and assuming the volume enclosed in the pod is volume_L4C = 0.9 [Liter], as Brian assumed in G1000561, and taking time = 1 [month] = 2.62974e6 [sec], the leak rate over each month is
leakRate(iMonth,iPod) = (pressure_torr(iMonth,iPod) - pressure_torr(iMonth+1,iPod))*volume_L4C/time;
(manipulating the P1* V - L* T = P2 * V equation on pg 15 of G1000561). I attach the .m file to make the calculation, if the above isn't clear enough to write your own.
It's a rather noisy calculation from month-to-month that could be refined, but it gets the message across -- the leak rate is roughly 0.25e-6 [torr.Liter/sec], a factor of 4 smaller than deemed acceptable. If one puts on your trusty pair of astronomy goggles, you could argue that the leak rate is increasing, but I would refine the quantification of the leaks before I made such claims.

Finally, I checked the GS13s and T240s to make sure they're leaking less, and indeed they are.

I also post a copy of the simulink bit logic that creates the warning bit -- it's gunna take me some time to verify it all -- but the goal will be to change the "ABS REF", "DEV REF", and "DEV REL" such that we don't alarm unnecessarily, as we've done here. 

re my 14373 entry, I figured I could correct these to the T1000388 even though there is a "Check the signs" Note in the doc as Fabrice says we'll just change the signs in the sym filters.

The matrix had correct elements in the primary transformations; only some of the cross coupling elements were variant.  I went ahead and ran the populate matrices medm script.  It crashed as it tried to load CPSALIGN values which are not in the data file.  Makes me wonder how the GS13 & CART2ACT values got loaded before...  So, I moved the CPSALIGN load section to the end and ran the script again.  I then confirmed all the matrices complied with the T1000388--all good.  Then confirmed the ISI still isolated--yes.

Then with the ISI just damped and HEPI not isolating( no Pos loops,) I drove HEPI in Z with a random noise signal band passed between .1 and 1 hz.  Monitoring the HEPI L4Cs and the ISI Stage0 L4Cs, see attached, it appears that the vertical sensors are out of phase.  So it seems we need that sign change in the SYM filters.

Made and committed safe.snap file.

Commissioners wanted the machine back before I could do other dof measurements, maybe I can do them with passive TFs.  Either way, later.

Jason, Sheila

There have been some glitches on the ETMX oplev, which don't seem to correspond to motion of the optic, the attached screen shot shows an example.  I think that I have seen glitches like this that were much larger in amplitude, but am not sure. 

One question for detchar is if they have a tool that can search for glitches like these, and give us some information about how often they are happening, how large they are, and maybe monitor to see if they are happening on other op levs. 

Another issue is that sometimes the lasers fail, which is often foretold by a several seconds oscillation in the oplev sum.  Can detchar set up some kind of monitoring for that?

Of course the real question is how can we fix it......