All fixed now: 1. This morning we noticed that the slow voltage monitors indicated a failure. This was tracked to the +24V in EY being only at +22V. 2. Looking at the alarmed OK readbacks of the common mode boards, we noticed that the error flag indicated all was fine. This was due to a missing call to the error handler. 3. The DC power readbacks now have offset adjustment, transimpedance gain and optical response settings. However, due to a programming error, the save/restore of these settings was not working. 4. The RF power monitors of the demod and PFD boards always indicated relatively high LO readings. We tracked this to an error in the equation which is used to translate volts into dBm. 5. While looking at the LO input to the ALS demod board we noticed that the RF level was marginal at ~7dBm. The additional loss is due to the delay line phase shifter feeding the LO. However, there was a 2dB attenuator attached to the input of the delay line. Removing it gave us a nominal 9-10dBm. 6. Last Thursday we noticed that we don't have a timing system readback from the 24MHz RF source in EY. The first problem was a fiber module with the wrong model number in the fanout. 7. The second problem was that the RF source never synchronized to GPS. After trying everything we finally reprogrammed the FPGA PROM which resolved the issue. Not sure how this unit passed testing, but this almost certainly affects our cavity length measurement which needs to be repeated.
Jeff and myself: reverted h1susmc2 and h1suspr2 models back to early last week before the latest L1 models were tried.
The h1sush34 IOP WATCHDOG was disabled. This means that the DACKILL on h1sush34 cannot be triggered by bad MC2 or PR2 OSEM signals. This was interfering with commissioning of these optics while MC2 is in chamber and PR2 is chamber side. I will keep the workpermit for this variance open until the WATCHDOG is restored.
I tried to take the L1 latest l1susim model and convert it to H1. When I tried to run it spectacular things happened:
The new l1susim required a C-code file ATAN.c which I brought up from LLO.
I ended up reverting to my original h1susim model (itself a L1 copy done in June) and restarted all SUS and SEI models to clear the errors. I'll work with David Feldbaum on the new model at a time when losing PR2, MC2 and PSL data is not so disruptive.
MarkD EdP ScottL JimW HughR No real issues to report on this now our third (fifth or sixth if you count eLIGO + extract) ISI installation. We did use the crane to help roll the A-Frames w/I-Beams attached into the chamber. The balancing measurements & moves paid off as we cleared HEPI by a comfortable 1/2". All the tooling/fixtures are removed. We likely won't do much more with this installation except to plug cables into feedthrus and dress said cables. We will not payload table which means the Lockers remain unlocked but the suspended stage is clamped in position with the Shipping Braces. The Shipping Braces prevent the installation of 4 of the 15 bolts so the ISI is not completely bolted to the Support Tubes. This will be done when Installation decides this needs to be completed. A few photo attached for your pleasure.
H2 Maintenance:
Jamie, Bram and myself installed a new h2iscey model (changed internal filter names in ALS_END). This required a H2 DAQ restart.
I added the second TCS L0 ADC on the CDS OVERVIEW MEDM screen.
HAM5ISI Installation
The main activity of the day was the installation of the HAM5-ISI. Hugh & crew started rolling this assembly into HAM5 at 10:30 & they were mainly done before lunch. They were completely done by 2pm-ish.
Other Activities
For the afternoon, Vincent requested quiet time so he could run SEI measurements.
Maitenance:
The awgtpman program has been updated and the awgtpman process has been restarted for all running models on h1. The new awgtpman will output much less information in the log file it generates, hopefully retaining the information of use. Log files had been growing absurdly large, prompting the change.
The awgtpman program has been updated and the awgtpman process has been restarted for all running models on h2. The new awgtpman will output much less information in the log file it generates, hopefully retaining the information of use. Log files had been growing absurdly large, prompting the change.
Making another go at it now that Dave has bipassed the IOP watchdogs on h1sus34 (see Dave's work permit). I've reenabled the damping on PR2.
With high pressure in the area and a few fires in the area (Red Mountain nearby, and a huge one near Cle Elum, WA), wanted to check for particle levels on the site.
In the attached 48-hr trend, it shows that we had elevated dust levels observed mainly in the End Stations, with EY showing a huge explosion (almost 300K particles!). The high dust levels mainly occurred from 8pm-2am.
Last night, the ISIs HEPIs and SUSs at BSC6 and BSC8 tripped at the same moment. An earthquake seems to be the cause.
- Earthquake_Ground_Z_20120814.fig
- Earthquake_ETMY_20120814.fig
- Earthquake_ITMY_20120814.fig
This was a Magnitude 7.7 Earthquake off the coast of Russia in the Sea of Okhotsk. Looking at trends, it appears as though the SEI systems rode out the initial P-Wave, but the S-Wave did them all in.
The aLog has had a minor update. You will notice links between the LLO & LHO logbooks at the top of the page. Also there is a new 'links' tab which will be used for interesting links (including the RSS feed). The L-mails have been enhanced to include the log entries for those who prefer to follow things via email.
Last night I closed the damping loops on MC3 at 1028936901 MatLab GPS time for taking power spectra.
The ramp up/down function (launched from Commands) can be used to engage/disengage isolation filters on HEPI.
Attached are plots of dust counts > .5 microns in particles per cubic foot.
B. Bland, J. Bartlett, T. Sadecki, J. Kissel After noticing suspicious, what-appears-to-be, cross-coupling of Yaw (Y) modes (1.1 and 2.05 Hz) into the Transverse (T) driven transfer function of Garcia's a few days ago (see LHO aLOG 3769), Betsy and I plotted those results against other suspensions, just to confirm this is something unique to this suspension (remember, this guy has given us trouble after trouble already, see LHO aLOG 3714). The first attachment (allhstss_2012-08-13_X1SUSMC3_ALL_ZOOMED_TFs.pdf) shows this comparison between X1 SUS MC1 -- a phase 1b, metal mass, SUS; built by the same people, measured in the same place, in the same measurement phase. Doesn't show it (not thing common to this phase of an HSTSs life). L1 SUS MC2 -- a phase 3b, glass mass, SUS; built by different people, measured on an ISI in-chamber. Doesn't show it (not a location thing, not a glass mass vs. metal mass thing, not a "who assembled it thing). L1 SUS MC2 -- a phase 2b, glass mass, SUS; built originally by the same people, measured after glass swapping. Doesn't show it (not an "appears or goes away" through the phases thing). X1 SUS MC3 -- the latest measurement of concern, DAMPING LOOPS OFF. This shows the cross-coupling. X1 SUS MC3 -- the latest measurement of concern, DAMPING LOOPS ON. This does NOT show the cross-coupling. Given this comparison, we came up with three scenarios that we could image that would case Y to couple to T, and have any other cross coupling show up in other degrees of freedom. They're similar to what's shown for P to V coupling in G1100865 (pg 4): (1) The SD coil drive axis is mis-aligned with the SD magnet axis (though the axis are parallel to each other), creating a small lever arm causing the top mass to twist in Y when pushed in T (2) The SD magnet is cocked (in such a way that the whole flag-magnet assembly looks like a "z" shape), such that the SD coil driver axis non-parallel with the the SD magnet axis (but the flag is still aligned), creating a small Yaw force vector when driving in T (3) The TOP mass has its adjustment mass arranged very lop-sidedly (that's a word, right?), such that the T center of mass / Y moment of inertia is pushed forward or backward (i.e. in +/- L), which creates a small lever arm, twisting the mass, when forced along the mass center line, which is no longer in line with the CoM/MoI. As such, we recommended Bartlett to make a corresponding assessment of those features. He confirmed the mass distribution was in no way abnormal, so that rules out (3). He did readjust the the SD OSEM to center it a bit better. However, he only used the slop inherent to the BOSEM mounting; there really is no adjustment possible to the tablecloth -- its location is rigidly define by the cage -- so wasn't able to move it much. Not to mention, moving the tablecloth would affect the alignment of all other TOP OSEMs. After, he took a quick T to T (only) transfer function which is attached (and calibrated straight from DTT, woo!), 2012-08-13_1245_X1SUSMC3_M1_T-T_TF.pdf. It shows no improvement. That rules out option (1) (queue sad trombone). This doesn't rule out option (2) though... -------------------- Conclusions: - I'm not super concerned yet: - The cross-coupling goes away with damping loops closed (the normally-used configuration). - There are many more chances to attack this problem. - These two twins (MC1 and MC3) have been sitting in the staging building dragging there feet for a long time. SO -- given the absence of [further ideas/low-hanging solutions], Betsy and I've agreed that the best course forward is to just tackle this problem chamber-side, and let the assembly get on to more suspensions. I still would like to see spectra from this guy though, to show that his lower stage OSEMs are functional...
From LLO, I have enabled the damping and launched the first TF measurement on PR2 (chamberside, with glass).
Mark Barton and Jeff Bartlett Further to the PR2 flag repair on Friday ( https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=3813 ), we went in this morning and retracted and removed the repair jig. The magnet-standoff assembly stayed in place and looked good, so we set all OSEMs to half-light ready for testing.
Thomas tried to add a python script (with extension .py) to his LHO aLOG 3758, but was thwarted and needed to change the extension to .txt in order upload it. Please add this to the acceptable files.
I don't see why the log book should be rejecting any attachments based on extension at all. That doesn't make any sense. One should be able to attach anything they think is relevant to a report, regardless of file type. File name extensions aren't a particularly good way to determine a file type anyway.
I have added .py to LLO's logbook. This OSL software that we are using requires defining allowable attachment extensions and associating them with a not null mime type. I didn't write the code, or participate in the process that determined which software would be used.
Added at LHO as well.