Jim, Greg, Mitchell, & Jason (IAS) We got the Risers & Support Table into the Chamber Tuesday (Corey). Wednesday we stayed pretty quiet. Thursday we torqued the Support Table to Support Tube bolts and then surveyed the Support Table for vertical. It was level to +-0.1mm but low 0.8mm. Today we pulled the East door and IAS gave us horizontal moves. This afternoon we moved the dial indicators from HAM2 to HAM1, floated the system and moved the position and adjusted the elevation (based on the DIs).) We have a little more adjustment in horizontal now but ran out of time so we locked up the HEPI stops after adjusting the F-Clamp position where needed. Next week we'll do a couple more tweaks and be ready for IAS to do another check. We'll then lock up HEPI again and attempt a stress relieve on the Springs. Finally we'll get back to building the isolation stacks and installing the Optical Table.
A newly-found RCG bug has been submitted as Bugzilla bug #415 to document recent findings in SUS that indicate three different file-name structures are created by the latest RCG code (2.5.1) to generate the generic MEDM screens. In the local directory, '/opt/rtcds/lho/h2/medm/', the RCG-generated MEDMs are written and sorted based on the individual model's name. As an example, the directory for the H2 SUS ITMY ('/opt/rtcds/lho/h2/medm/h2susitmy/') generic MEDMs contains file-names of generally two structures: 1.) H2SUS_ITMY_* and 2.) H2SUSITMY_ITMY_* A third structure was recently discovered: 3.) H2SUSITMY_* (Note the difference between (2.) and (3.) is the second "*ITMY*" is missing.) This third structure seems to only apply to the ADC, DAC, GDS, BIO, and ALARM MEDMs.
Daniel suggested that the mystery noise that comes and goes might be a parasitic interference in the fiber.
This morning, before anybody started any noisy activities, I went into the optics lab and gently tapped the fiber that is hanging from the ceiling panel of the clean room, from 8:13 AM (15:13:00 07/Sep/2012 UTC) for 30 seconds.
Attached is the short time spectra taken at various times before, during and after the tapping period, and sure enough, only the trace with tapping (blue) shows a very high noise in the right frequency band while everything else looks the same.
If you're interested in the data file, find the file name in the screen shot.
Note that "everything else" is still somewhat noisier than the black reference taken on 22/Aug.
I'm turning the WFS loops off (@ 7:20:00 UTC).
Alberto recentered the beam on WFS, I tweaked the alignment of the cavity, and WFS still didn't work (this time its running off in YAW).
I remeasured the sensing matrix, which didn't change much from what Daniel measured:
WFSAPIT = 0.047*POS -5.66*ANG
WFSBPIT = 0.906*POS - 3.760*ANG
WFSAYAW = 0.086*POS + 2.379*ANG
WFSBYAW = -0.293*POS + 3.302*ANG
Note that the coherence for WFSA against POS injection was poor both for PIT and YAW, but everything else had an excellent coherence.
Inverting these, PIT input matrix is [-0.759, 1.143; -0.183, 0.009]
YAW input matrix is [3.366, -2.425; 0.299, 0.088]
But of course it still didn't work, everything was running off in YAW.
Since, unsurprisingly, POS YAW feedback was the bad guy, I enabled POS_PIT, ANG_PIT and ANG_YAW, centered the wfs using picos, lowered the gain for POS_YAW, enabled all four DOFs, disabled the input, recentered, enabled, recentered, and at some point it stopped running away. I set the gain of POS_YAW to the same value as ANG_YAW and it still worked.
UGF of all DOFs are supposedly 50mHz with the filter gain of -5. I think we can go higher, but sadly the cavity power is hashier with WFS enabled, even with this low gain. But at low frequency it is certainly doing its job (I can push TMs and WFS automatically brings them back).
I leave it with WFS on for tonight.
Note: At some point I started isolating ISIs and tripped HEPI and ISI, and put ISI back to damped without isolation.
Note2: To make it easier for people to look at angle data later, WFS sensing matrix data also contains the TFs from POS and ANG excitation to ETM and ITM oplev. See the snapshot to find the location of the file in the title bar.
Note3: The reason why I seem to have done this at 0.04736b4 Hz is because of DTT quirk. I told dtt to make a sweep from 0.1Hz to 0.09Hz with one data point, and somehow dtt decided to do it at 0.047something, or maybe it did measure at 0.1Hz but displayed as if everything was done at that frequency.
Joe G, Cheryl, Rodica On Tuesday, Joe G and I assembled a temporary half waveplate to align the polarization of the forward transmitted beam parallel to the table (p-pol). We used a pick-off mirror (borrowed ALS_M3) to direct the low power s-pol beam away from the main beam to be monitored properly. We started measuring the power ratios between the two transmitted beams to check the rotation of the polarization after the FI. Continued the alignment work with Cheryl on Wednesday when we noticed contamination of the crystals due to metal particles and glove marks. We removed the first calcite polarizer and the TGG and TGG+QR holders and transfered them to the Optics Lab to be cleaned under the flow bench. We applied First Contact on the calcite wedge while still in its mount, and also on the quartz rotator which was successfully removed from its holder. However, the two TGG crystals could not be removed, the single piece being held too tight in place by the clamps of the holder, while in the other holder the metal parts were stuck together, possibly the threads of the assembly got crossed. We have been engaging the clean and bake crew (Jodi and Joe) into finding a solution to clean these crystals in their holders and we have some new ideas to try tomorrow.
Most of the day, Vincent was taking data including the calibrated spectra of the cavity length.
Attached are plots of dust counts > .5 microns in particles per cubic foot. Also attached is a plot of the mode of the dust monitor at end X (H0:PEM-EX_DST1_MODE) to shown approximately when it was reconnected.
OAT: Quiet requirement all day!
The dust monitor at end X had been turned off. The dust monitor and the weather station at end X were restarted. This involved power cycling the weather station and the Comtrol box. The Comtrol box was moved to the upper shelf in the rack.
Scott, Mark L. and I spent time preparing for ICC at BSC9. Scott and Mark dealt with cleanroom location, assembly, and repair issues. They also moved the flam cabinet from the emergency exit air-lock into the VEA. I cleaned up from the iLIGO optics de-install, organized garbing and staging materials, packed up unneeded items, etc. Two large staging tables were returned to the corner station so they could be used for work at HAM1 and HAM4.
Bubba took measurements and confirmed that the cleanroom from HAM4 can be put into the space remaining around HAM3. John, Bubba, and Mark H. have agreed on a method for the pick and placement. We will attempt this dance tomorrow AM unless otherwise directed.
[Michael R, Richard M, Alberto]
Richard and his contractor brough a PC/PC fiber into the PSL enclosure. Since Richard's fiber has a PC connector and the collimator's pigtail has an APC connector, we had to use an adapter made of a fiber with APC and PC ends.
Mark B and Jeff B. We stumbled across a nasty bug in the Matlab script plotHSTS_dtttfs.m. We were trying to generate plots for PRM data from 9/5/12 at 1900, but the script was failing to write the expected files. Eventually we realized it was writing files with "1300" for the time. This was because there was a line fileInfo = dir([dataDir '*' meas.yyyymmdd '*tf.txt']); which was intended to look for all files in the Data directory matching the date/time pattern specified in the settings at the top of the script. Unfortunately it omitted any reference to the time, which meant the subsequent search would always find the first dataset for the day. We changed it to match the equivalent HLTS script which has fileInfo = dir([dataDir '*' meas.yyyymmdd '_' meas.hhmm '*tf.txt']); and committed it as r3308. As far as past data goes, no raw data will have been corrupted. We _think_ all PDFs and any diagnoses and approvals based on them should be valid - even if data for some particular excitation DOF was read from a file with the wrong time, the resulting PDFs should have same time in their names, so the names would match the contents. However what was displayed in Matlab figure windows would sometimes have been old data if there was more than data set for the requested day. Also, a corrupt .mat file could conceivably have been generated if a partial data set was taken in the morning (e.g., only 3 excitation DOFs) and a full one in the afternoon.
[Michael R., Alberto]
We temporarily borrowed the 1064 Farady that was purchased by Bram for the ISCT1 table (ALS vertex) to install it before the fiber collimator on the PSL table.
After this addition, the power coupled into the fiber went down to 2.1 mW (was 3 mW) due to the induced beam shift. Unfortunately the current setup of the steering mirrors doesn't let us displace the beam by much: one fo the steering mirrors is out of hand reach and it's close to a high power beam.
We're still coupling more power from the PSL than ifrom the ALS refcav. So it should be okay, unless we're going to lose more than .5 mW downstream when we'll connect the new fiber going to the optics lab..
35W beam
From initial alignment data, we know the following:
Positive offset in PIT (H2:SUS-ETMY_M0_OFFSET_P and H2:SUS-ITMY_M0_OFFSET_P) will tilt the mirros such that the reflected beam off of the mirrors will go down.
Positive offset in YAW will tilt the mirrors such that the reflected beam off of the mirrors will go toward the inside of L.
That is, the upper stage of ITM looks like the mirror image of the ETM. Why is this the case? I thought that they are identical.
Also, I think oplev sign is somehow wrong. It's not consistent with initial alignment data.
FYI, the sign of the things in initial alignment was figured out by:
First using baffle diodes to figure out the sign of the TMS to figure out the TMS sign, and make the first beam hit the center of the ITM.
Then using ETMY cage and CCD camera, make the reflected beam from the ITM hit the cage bars to figure out the sign of ITM.
Then move offset of ETMY so that the beam comes back to the table, then move TMS and repeat, to see if ETMY sign is the same as TMS (it is).
As you can see, there is not much ambiguity there.
Attached is the oplev and upper stage offset. (Jumps not caused by the offset are from HEPI.)
For positive SUS offset, the following is true for Oplev:
| Positive PIT offset | Positive YAW offset | |
| ETMY | Oplev goes negative | Oplev goes positive |
| ITMY | Oplev goes positive | Oplev goes positive |
From this, oplev seems to think that positive PIT offset moves ETMY down but ITMY up, and positive YAW offset rotates both ETM and ITM in the same direction.
Mark Barton I did some followup on this issue and it looks as if the F2 and F3 OSEMs may be swapped on ITMy. See attached plots which have Keita's channels (divided up into separate plots for ETMy and ITMy), plus additional ones of interest, including the M0F1, M0F2, M0F3, L1UL and L1LR sensors, the estimated P and Y from the OSEM2EUL blocks at M0 and L1, and the requested drives to the M0F1, M0F2 and M0F3 coils before magnet sign correction. I also zoomed in on a 3 hour period from 12-09-06-02-00 to better show the events of interest. With ETMy, everything is as expected. The pitch OL reads negative for positive pitch offset but this is as designed - the OL is trying to be a measure of beam height and positive SUS pitch is down. (Yaw is left=positive viewing the QPD from the optic, which is the same convention as for SUS.) With ITMy, everything internal to SUS to do with pitch is as expected, but the OL does not have the expected opposite sign. In yaw, the M0 and L1 Y channels have opposite sign and the yaw OL agrees with M0 yaw. This would be consistent with the F2 and F3 OSEMs on the ITMy being swapped. A further data point in favour of this is that the signs in the ITMy COILOUTF block are the opposite of expected from E1000617 (F2 should be opposite F1 and F3, and is for ETMy, but it's F3 that's opposite for ITMy). This was earlier put down to a magnet swap, but the comparison with the L1 level suggests it's actually the OSEMs that are swapped. This wouldn't be a hard mistake to make because the convention in E1000617 is a bit confusing: both M0 and R0 face OSEMs are labelled F1 F2 F3 as viewed from the _back_ (i.e. the reaction chain side), so the M0 OSEMs are F1 F3 F2 from the side you would work on them from. As far as OL's are concerned, things are consistent with both ITMy OL channels being flipped, as if the QPD were upside down.
Mark B. Thomas V. We buzzed out the the QPD with a laser pointer on ITMy and found that the QPD is upside down from what the MEDM screen on the SUS quadrants are indicating. The segments of the QPD are laid out as such: +-------+ | 2 | 4 | ^ |---+---| | This way up | 3 | 1 | | +---+---+ I believe the error came from a miscommunication in the exchange of information between SUS and OptLevs. I had originally mapped out the quadrants on 07/24/2012 according to ALOG 3573 using the MEDM screens. I wasn't aware that the top level ITMY SUS QUAD model had been re-ordering the signals as such (as described in Jeff K's ALOG 3613): Analog Signal ADC Channel SEG# 1 1_0 SEG2 2 1_1 SEG1 3 1_2 SEG4 4 1_3 SEG3 According to ALOG 3613, Jeff had re-ordered ADC Channel and SEG# to 1:1 as it makes the most sense to be that way! I think this sequence of events led to us being confused on why the signals look like they're upside down since the diagonals of the signals are switched. This fix explains why Keita's original entry shows that the OptLevs look "backwards" in some sense. For future reference, I'll try to be more clear on what I'm measuring when mapping out the orientation of the optical lever QPD, as well as run tests with the suspension offsets in pitch and yaw to make sure they coincide with each other. This will be added to the Optical Lever Installation Procedure (E1200063).
Foton GUI quietly discarded (some of?) notch filter definitions and replaced them with a flat gain of 1.
This is easily reproduced by first opening e.g. /opt/rtcds/lho/h2/chans/filter_archive/h2iscey/H2ISCEY_120828_143926.txt and saving it to some other file, e.g. test.txt, and take a diff (attached).
Probably because of this bug, all WFS notches are gone from current H2ISCEY filter file.
This is extremely worrisome.
It's not notches, it's zero ramp time.
bugzilla report of this:
https://bugzilla.ligo-wa.caltech.edu/bugzilla/show_bug.cgi?id=414
Jim Batch already found the cause of this (ramp time was zero for the filter), and is working on a future workaround. In the mean time, if you select "ramp" switching, don't forget to set the ramp time manually to something non-zero.
