[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.

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

* After Besty's realignment of the MC3 BOSEMs we found that the mode cleaner was not aligned.  Deepak checked the top stage earthquake stops, and they all seemed to be fine.  After noticing that the RT BOSEM was mis-centered by ~4000 counts we decided to recenter it.  This brought the mode cleaner much closer to flashing, but we still had to make some small tweaks afterwards.  The moral of the story is that the meaning of the alignment numbers is rather sensitive to the BOSEM centering.  I guess this isn't terribly surprising because, as Jeff K. pointed out, the magnetic field of the BOSEMs is designed to roll off quickly outside of the opening.  

* We attempted to set the polarizaiton of the recycled MC Refl beam using the HWP as mentioned in yesterday's post, but ran into a confusing inability to do so. Hmm...

J. Kissel, B. Bland

Betsy took another crack at de-rubbing the TMSY this morning. Her words which I've paraphrased: "I definitely readjusted the stiffness of the cables between the optical table and top mass, and around the top mass. But that aside, it really does look totally free -- I softly bounced, rocked and rolled it and it's definitely has a good range of motion before hitting its stops."

Since, I've taken another set of transfer functions (see attached). It looks looks significantly better than previous measurements:
- Vertical Modes are no longer double-peaked
- The most prominent Roll feature between 0.65 and 0.8 Hz has changed shape to be less complicated, lower in frequency, and dare-I-say fewer modes
- Whatever high frequency noise that appeared in yesterday's Tranverse TF has gone away again
- The second L/P mode at 0.8 Hz has moved down to 0.75 Hz
- TFs in general are a little bit cleaner
But until we get a similarly detailed measurement under vacuum, or a model we can trust, I can't definitively say "we're good." But I certainly can be convinced that what noise that's left that we see is from air-currents and ambient noise. I'll let team-TMS make the final call.

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.

Finally, I also updated the HAMISI ODC screens to include the bit label read-back.

Note that the HAMISIs don't have the ODC code in the front end - this still needs to be one.


This concludes my round of medm screen updates. 

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.

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.