Based on Corey and Jeff's work last week and with Dave B's help I have made changes to the alarm handler with regard to ETMY and ITMY.

Corey had modified some of the  IOP watchdog MEDM screens to provide a more useful display; for the quads he had changed the old arbitrary "OSEM1-OSEM6" to the more useful "F1, F2, F3, SD, LF, RT ". I have made similar changes to the alarm handler so the operator can quickly tell which OSEM is in alarm state. I used the map data Corey posted in the CDS wiki.

I modified

/opt/rtcds/userapps/release/cds/h1/alarmfiles/h1cds_iop_sus_watchdog_etmy.alhConfig

and

/opt/rtcds/userapps/release/cds/h1/alarmfiles/h1cds_iop_sus_watchdog_itmy.alhConfig

to show the correct OSEM name on both the group field and in the guidance popup. The channel name will still show "OSEM#", however. I updated the changes in the SVN.

Did another hands on touch/look at HAM3.  Touched every connection and detect nothing.  Fluid level unchanged at the Mezzinine reservoir.  Still running steady at 26psi & ~97% max speed.  All's well.

[Chris W., Sheila D., Kiwamu I.]
This is a report from yesterday.

We completed the alignment works which were associated with the TMSY. We accomplished three missions : (1) balancing of the TMSY optical table, (2) alignment of the infrared QPD path on TMSY and (3) alignment of the infrared beam extraction path through a viewport.

TMSY optical table balancing
The optical table (the bottom mass) of the TMSY was re-balanced by shifting the position of an existing small weight, which was attached on the bottom side of the table. A picture of the weight is attached below. The motivation of this mission was to correct a big pitch misalignment which was found after Betsy released tension of the cables [1]. Since the misalignment was largely in pitch according to our observation on the last Thursday, we shifted the existing weight by 2 inch from the original point away from ETMY. This adjustment nicely recovered the alignment. The static pitch offset of the BOSEMs to obtain retro-reflection from ETMY is within a reasonable actuation range. Thus we conclude that we succeeded in re-obtaining the table balance.




Infrared QPD path alignment
This time the issue of the highly transmissive BS at 532 nm [2] was mitigated by introducing a half wave plate to rotate the polarization of the green light such that the reflectivity of the HR surface increases somewhat. Thanks to the half wave plate, which was placed on the launching path on the EY in-air table, the HR beam became barely visible (although Sheila wasn't able to see the spot while I was somehow.) The infrared path on the QPD sled had been about 1.5 mm off in horizontal translation, so we tweaked two steering mirrors which are the ones right before the sled. The path is adjusted with a precision of less than 1 mm by simply looking at the beam spot on the QPDs. A difficulty was to identify the right beam spot as there are lots of ghost beams in the path because the optics are not intended for green light.

Infrared extraction path alignment
This adjustment was much easier than the last alignment missions because the green light was very visible. After we confirmed that the beam hit the center of every optic, we steered the last launching mirror to let the beam go through the bottom middle viewport. The beam was adjusted such that it goes through the center of the viewport glass with a precision of about 5 mm.

Note :
We increased the laser power to make the beam more visible. This needs to be decreased to the point where it used to be.
The half wave plate is still in the path. This needs to be removed.

[1] LHO alog 5810 "Another Round of TMSY De-rubbing"
[2] LHO alog 5774 "50-50 IR beam splitter is a good AR for green"
 

[Deepak N., Rodica M., Chris M.]

Tonights Work:
It turns out that the MC Refl beam is elliptically polarized (we may want to add a polarizer on IOT2L to correct this).  To fix this we used a TFP after the MC Refl periscope.  We then returned to the activity of the prior night which was to use the Faraday as a reference to set the polarization for IM1 so that we could measure the transmissivity.   These values are below.  Note that the values measured for IM4 may change slightly with the final alignment, but IM1 is in the final state.  





Optic
Incident
Transmitted
Trasnmissivity


IM1
151 +- 2 mW
78.5 +- 0.5 uW
520 +- 10 ppm


IM4
165.4 +- 1 mW
389 +- 5 uW
2350 +- 50 ppm


ROM LH1 (BS behind IM4)
389 +- 5 uW
29.4 +- 0.2 uW
7.56 +- 0.15 %



Alignment offsets on the IOO suspensions as of today:


Suspension
Pitch (MC in urad/ IM in cnts)
Yaw (MC in urad/ IM in cnts)


MC1
-46
-3750


MC2
65
137


MC3
320
-4300


IM1
1030
-900


IM2
-700
-520


IM3
3250
-500


IM4
-3250
4250



What is left to do next week:
* Align IM3 and IM4 to PRM/PR2 (this requires IAS to be finished/have irises placed)
* Use a HWP in the Faraday to screw up the polarization and check that PRM retro-reflects.  
* Align the forward rejection beam from the Faraday. 
* Check the placement of the ellipse shaped baffle between the Faraday and IM4 (this also needs to pass the parking beam).
* Check the placement of the MC3 AR baffle.
* Align the IFO Refl beam into HAM 1.
* Align auxiliary beams behind IM4 using the viewport replicator.
* Measure transmissivity of IM4 and the beamsplitters in the paths behind it.
* Check the alignment of MC2 Trans with a red beam.
* Check that MC Refl and IM1 Trans makes it through the viewports using the viewport replicator.
* Assist with aligning the optics behind PR2 using Keita's documented procedure (if time permits).  
* Replace/ remove all temporary things noted in list below.
* Drink beer.

Temporary things:
* Irises near MC1, MC2, and MC3.
* Irises near IM1 and IM2.
* Replace HWP and set the polarization.
* MC3 AR baffle.
* Two mirrors for MC Refl reclamation.
* IAS irises.
* Beamblocks.
* Baffles moved for IAS alignment.
* Tools.
* Replace hard aperture clamps.

Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot requested from March 15 01:00 UTC to March 16 00:00 UTC. Also attached are plots of the modes to show when they were running/acquiring data.

Data was taken from h1nds1.

mode:
120 seconds worth of data was unavailable on this server
1380.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=13-03-15-01-00-00; Length=82800 (s)
No data output.

status:
120 seconds worth of data was unavailable on this server
1380.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=13-03-15-01-00-00; Length=82800 (s)
No data output.

> .3 microns
120 seconds worth of data was unavailable on this server
1380.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=13-03-15-01-00-00; Length=82800 (s)
No data output.

> .5 microns
T0=13-03-15-01-00-00; Length=82800 (s)
120 seconds worth of data was unavailable on this server
1380.0 minutes of trend displayed

Safe.snap files were updated for HAM2 and HAM3 ISIs, so they comply with the latest model/screen updates.

The new safe.snap files are commited under the SVN:
HAM2-ISI - r3992
HAM3-ISI - r3993

Pictures of the state of the ISIs, at the snap, are attached.

I updated the safe.snaps for the IOP models in the corner station (the non-test stand ones). Main changes are in handling the alarm levels of channels associated with the software watchogs.

When I tried to burt restore the h1iopsusquadtst safe.snap settings, the epics process for this front end crashed. This is reproducible, so I'll stop the upgrade for today and fix this on monday.

Was poking around H1 SUS ITMY to try and assess SUS sensor noise, and found that ITMY needed some infrastructure TLC similar the HAM SUS. 
- CART2EUL and EUL2CART matrices were still using H2 values, so I've updated them
- OSEMINF to_um calibration in FM5 was old, stale, and off. It's now correct, fresh, and ON.
- Stuck from_um anti-calibration filters is the DAMP filter banks such that we can use the same loops.
 
I've since captured a new safe.snap, and committed both the new filter file and h1susitmy_safe.snap to the userapps repo.

Today, I swapped the sketchy top mass blade tip EQ stops on MC1 (or, better known as the one near the center of the table).  IO will readjust this suspension to continue alignment.

Betsy, Travis, Jason

Indeed, things went too well earlier in the week.  This morning we spent a few hours diagnosing why the beam was low on the PR3 after transiting through the PLX (although the PLX assy was level and the incoming IAS beam was verified to be at the correct height).  We finally resolved to pitch the PLX in order to center the beam on the PR3 center and move on.  We then spent many hours this afternoon walking the PR3 pitch everywhere but onto the nominal alignment.  After pouring through some documentation on the HLTS, we discovered the correct knob to turn (not called out well in documentation, and was not obvious to us QUAD-centric folk).  Just as we were back on track, we *ehem* had a bump of the IAS equipment, so we decided to quit and cut our losses.  Long story short, now that Jason will be with us at LHO next week, we will finish up in ~a few hours Monday morning, bright-eyed-and-bushy-tailed.  Sorry, IO, we need one more day!

Day's Activities:

Code change for HAM-ISI 2 & 3.  Required re-starting model and DAQ around 10am (Barker, Warner)

Photon Calibrator "dirty" Alignment (Daveloza, Rodruck, Savage)

ISCT1 craned into place by Apollo (west side of HAM1)

Betsy/Travis worked mainly in HAM2

Cyrus doing rackwork in out-buildings

Tour in Control Room around 12:30pm

Crew working on baffle in West Bay cleanroom

RO Alarm toward the end of the day

Dust Alarms:

• #8 (cleanroom over HAM1) had a few MAJOR alarms in the morning (but no one was in the cleanroom)
• #4 (BS Test Stand) INVALID Alarm
• --several LAB INVALID Alarms

We noticed a strange 0x2000 daq status of the h1isiham3 which should not be the case (models were restarted, then the DAQ). So to be safe I have just restarted the h1isiham2,3 models again. I cleared the Dolphin IPC errors this raises on the suspension systems in ham2,3.

BTW, the safe.snap files for h1isiham2,3 are out of date and generate many errors when ran manually.

This morning I asked the question: 

"Who is OSEM[*] in the Alarm Handlder??"     (  *  can be 1-6 in the Alarm Handler)

Dr. Kissel handed over a crumpled Post-It note which decrypted the OSEM mystery.  Currently, to understand what a SUS alarm means, one needs this Post It note because the Alarm handler names SUS Watchdog channels as OSEM1, OSEM2, ...OSEM6 (which isn't really useful since the SUS Expert screens don't use the OSEM names; they use F1, F2, F3, Left, Right, Side).  I posted the Post It notes to the CDS SUS wiki.  [As for the actual alarm in question, it was related to OSEM5&6 (Left & Right) "Centering"; and this is most likely due to not being pumped down].

I did actually do something here.  Jeff showed me the IOP Watchdog screen, and how some of the custom medm screens on here have been changed from using "OSEM" to "useful" names.  But we noticed some sub-screens weren't updated (namely EY BSC6).  So, I updated this screen from the OPS Station.  Here are steps taken:

• Open Terminal
• Since we were logged in as ops, we had to log  in as controls with graphical capabilities to make medm changes to custom screens
  • ssh -X controls@operator0
• cd /opt/rtcds/userappsrelease/cds/h1/medm
• Open medm screen you want to edit
  • medm H1CDS_SOFTWARE_SUS_WATCHDOGS_EY.adl &       | this is screen I changed |
• Make changes to screen (here I changed the OSEM names to actual names)
• Save (on medm)
• Back on Terminal, one will want to commit this modified file to SVN
• Check SVN status & then commit
  • svn st
  • svn commit -m "changed names for OSEMs" H1CDS_SOFTWARE_SUS_WATCHDOGS_EY.adl
    • To commit one will need to login with your ligo.org account
• End

(I also changed names on the H1CDS_SOFTWARE_SUS_WATCHDOGS_TST.adl screen as well)

I added temperature/relative humidity sensors to the dust monitors in the optics lab, vacuum prep lab and bake oven room.

We restarted the h1isiham2 and h1isiham3 models. The new models have ODC parts added. The DAQ was restarted.

This closes out WP3768

Re 5807 I did another hands on inspection of all the welded and threaded joints at HAM3 and find no indication of fluid.  The servo is still running at 26psi and the reservoir fluid level has not dropped.  We will run at substantially higher pressure once the Actuators are introduced to the system but I do believe we are OK here.  I'll continue to monitor this closely.

Each ODC channel has a Summary Bit that is used to indicate whether each system is in a nominally good operating state.  This bit is generated by checking that the necessary bits in the ODC channel are ON, as specified by the subsystem commissioners.  With the input from Jeff Kissel and Sebastien Biscans, we have set all of the EPICS variables needed to correctly populate the Summary bits for all active ODC channels in H1.  The EPICS variable Bitmasks are decimal numbers that correspond to a bitmask, where for each bit in the ODC channel that should be on when the system it is characterizing is in a good working state.  Here is an example:
H1:SUS-BS_ODC_COMBINE_ODC_BITMASK = 126
In binary, this is 0111 1110, which indicates that bits 6, 5, 4, 3, 2, and 1 should all be ON when the SUS-BS is operating nominally.  If you are curious what those bits mean, you can do the following:

controls@opsws1:~ 0$ caget H1:SUS-BS_ODC_BIT1
H1:SUS-BS_ODC_BIT1             Master Switch ON/OFF Status
controls@opsws1:~ 0$ caget H1:SUS-BS_ODC_BIT2
H1:SUS-BS_ODC_BIT2             DACKILL Status

These BITMASK EPICS records were set using scripts located in /ligo/home/ryan.fisher, and attached to this entry (with modified file extensions so the alog will post them).

With this completed, the EPICS description strings for the bits set and the MEDM screens reworked, we believe we have most of the active SUS and SEI subsystem ODC channels operational.  

The remaining systems for which ODCs need to be implemented under SUS and SEI are: the HAUX (HAM-Auxilliary) front ends and the HAM-ISI front ends.  The latter should be implemented with the next update from the cds_user_app svn (anticipated Mar 15).

We will be generating new safe.snap files specifically for the updated ODC EPICS settings for all models and sending them to CDS-announce for incorporation into the SVN and live systems.

Ryan Fisher, Stefan Ballmer

We have set the EPICS records for the labels that describe the ODC bits for the SUS and ISI models currently running in H1.*  The labels provide a short description of what every bit in each ODC channel represents, for each ODC channel.  The higher order bits in the ODC channels that do not have labels are currently unused, but may be used in the future.

These records were set using scripts located in /ligo/home/ryan.fisher, and attached to this entry.  

* Excluding H1:SUS-TMSY_ODC_BIT* for now.

I walked about 300 meters of Y1 this week and took some photos of the beam tube insulation.

Between ports 2 and 3 (a distance of 250m) I counted 35 holes in the insulation. Virtually all of these holes were at taped joints between insulation wraps. These joints occur every 4 feet.

So of 800 taped joints I saw 35 which were violated by rodents. There may have been a few more on the backside of the tube. The photos in this report show some of the holes, some of the "good" taped joints, and some views of the uninsulated bellows regions.

Seems like the problem we had when using a green beam reflected off of a 50-50 IR beam splitter was because of the fact that 50-50 surface for 1064nm works as a very good AR for 532nm.

The BS in question is this: https://dcc.ligo.org/LIGO-E1000671-v1

Corey used a fiber coupled green laser as the source, placed a PBS cube for 532nm to ensure that the P-pol light is transmitted, and used a HWP for 532nm to change the polarization.

There are two beams in reflection, one from 50-50 IR BS surface and one from the back surface. There is one beam spot in transmission, because the 50-50 IR BS surface is very small. Anyway:

On TMS ISC table (and in the arms) the green light has S-polarization, and according to Corey's measurement we're totally screwed.

Now that we know about this, we could either align the red QPD path assuming that there is an invisible beam next to a visible beam at a known distance, or we could place a HWP on the ALS table and inject a wrong polarized beam to see if we get anything.

Corey will write a one-page document and add it to E1000671.