Due to a timing system interruption at the master fanout, the suspension and seismic test stands needed to be restarted. Models were restarted, but no BURT restore was performed.
After the relief of the UIM blade clamp screws, I've taken a new set of data. The results look MUCH better, but I believe there's still some but of interference some where, as all degrees of freedom (on both chains) the data is dreadfully noisy, with almost no coherence below 1Hz. I don't believe this remaining running is a show stopper, but we should be on the look out. Three like data sets: For M0 H2 SUS ITMY M0 (2012-01-10) -- Post-cartridge installed Phase 3b approved monolithic fiber chain (should be the same between an ITM and an ETM) H2 SUS ETMY M0 (2012-02-13) -- Yesterday's data, with UIM blade spring bolts rubbing against the top mass, between chains. H2 SUS ETMY M0 (2012-02-14) -- Today's data, with the UIM rubbing relieved. For R0 H2 SUS ETMY R0 (2011-11-22) -- Phase 1b approved metal erm chain (should be the same roughly the same between glass and metal) H2 SUS ETMY R0 (2012-02-13) -- Yesterday's data, with UIM blade spring bolts rubbing against the top mass, between chains. H2 SUS ETMY R0 (2012-02-14) -- Today's data, with the UIM rubbing relieved.
Stainless steel helicoils that were incorrectly used for ISC cables were all replaced by Nitronic 60 helicoils.
Cleared the path to the VEA.
Thought that we'd move the cube and the clean room to the area between the roll up doors, but realized that we won't have a place to bunny up tomorrow.
Attached are plots of dust counts > .5 microns.
Kyle, iGerardo Removed 6" roughing port gate valve and associated plumbing from YBM pump port -> Installed 8" CF Class A blank (borrowed from H2 input mode cleaner pump port) on YBM roughing pump port -> Installed new (but unbaked) 8" CF blank at location of borrowed Class A blank -> Labeled unbaked flange so as to be replaced before exposing to vacuum.
I have updated the h2iscey model with the latest changes from T1100472v2. It looks like the channel mapping hasn't changed since the last time I updated it, but I tweaked the subsystem input channel naming to make it clearer where the ADC channels are going from the top level.
NOTE: model not compiled or installed.
Randy, Slim, Scott & Ed pulled the HAM5 North door and connected up the iLIGO HAM Support Table to the Support Tubes. This is to hold their relative positions while the exterior HEPI Support Structure is built up. This table (like all the others in the HAMs) will be removed when Chamber cleaning commences. This one along with another one or two of the units still residing in the H1 HAMs will have to be kept clean for this same purpose.
Since it's clearly frustrating that we can't move forward with the H2 SUS TMSY installation, I wanted to show what's going on with the TOP to TOP transfer functions of H2 SUS ETMY, (Main Chain [M0] data I took this morning) so people understand why I'm holding up the show. I don't have an answer yet, but these are the plots at which I'm staring to try and glean what's going on -- suggestions are welcome!~ I'm still taking data on the reaction chain -- will post when I have that data. The first attachment (allquads_120213*.pdf) is MAGENTA, is current (2012-02-13), "first light" monolithic ETMY data, compared against - BLUE A model of the monolithic main chain (fiber). - ORANGE H2 SUS ITMY's "first light" data (2011-11-19) -- Mated w/ BSC-ISI, First Monolithic Results (Fully Laced), M0 F1 poorly aligned/ratty. M0 R and M0 V not measured because of bad M0 RT. - BLACK H2 SUS ITMY's latest and greatest (2012-01-10), phase 3a approved, in-air, post-cartridge install data. The second attachment shows only the current data, but in more detail (and with regrettably more busy plots), specifically cross coupling and OSEM basis response to the EULER drive.
Here's the R0 transfer function results (same color coding as above). With this data, Brett and I have managed to convince ourselves the the two chains are coupled in some way. After phone conversation with M. Barton, B. Bland, T. Sadecki, B. Shapiro, and myself, our best guess is that because the reaction chain UIM stage is "pretty severely rolled, and too high by millimeters," that the UIM flags are the coupling point. Another possibility is that the Top Blades' clamp bolts (those that secure the blade to the launching clamp) are interfering -- the top plates of the top mass overlap, or perhaps more accurately: where there's a cut-out in the Main Chain plate that exposes the Main chain's blade spring bolts, the Reaction chain's top plate overlaps that cutout. This hypothesis is supported by comparing the main chain and reaction chain TFs -- you'll see that modes have bifurcated in similar ways, and even some of the high frequency modes (e.g. in V and R) have bifurcated at the same frequency, but in exactly opposite amplitudes in each chain's set of TFs -- implying that were seeing the same physical mode in both chains, which are slightly different in frequency because of the two different chain types, show up in each other's dynamics. Betsy and Travis are down at the end station now investigating, where one of the first things they will do is try to lock up the reaction mass such that it is entirely free of the main chain, and we will then remeasure the main hoping to confirm our hypothesis. Then (of course) the next step is to figure out the why the reaction chain is so screwy....
Found it. The R0 UIM Left Blade Clamp screws were grounding on the bottom of the M0 UIM left top Plate. The roll of this chain just bit us again... We're going to drop the left side of R0, giving up some barrel-barrel centering (adding sideshift to the ERM) of the test mass to ERM. As well, the height of the ERM may go a bit low. Recall, we had worked towards "fixing" sideshift, height, and roll. Looks like "fixing" was the wrong thing to do.
For the record, we removed 2mm of shims at the left Top Stage Blade tip, lowering the left side of the R0 chain. There is 1mm left.
Preliminary Results look encouraging!
Attached is a quick before vs. after comparison between the two degrees of freedom that should be most decoupled -- Vertical and Yaw -- for both chains. Both show signs of significant improvement. take the measurements with a grain of salt -- flags are not yet centered, and there's ~half the averages than is normal ('cause we wanted the info faster).
Betsy and Travis are cleaning up now (re-aligning lower stage flags, etc.), and then I'll begin a full suite of measurements when they're finished (either tonight, or early tomorrow morning).
The source of the interference between the chains is the screw head touching the underside of the plate near background.
After dropping the left side of the reaction chain by 2mm, you can now see a gap above the reaction chain screw heads and below the horizontal plate of the main chain UIM.
Eric James and I installed and performed preliminary tests on the ITMY optical lever on Tuesday, Feb. 7. Alignment was straightforward, and the return beam was bright enough to see without difficulty. We did have some clearance issues with the receiver breadboard, which did not clear the beam tube. We added some 2-inch spacers to offset the breadboard from the pylon (to clear the bellows) and removed about an inch from the corner to ensure the board would clear the main tube. Electronics went well, thanks to help from Thomas Vo, Dave Barker, who established a preliminary medm screen to read out the oplev signal.
Rolf, Alex, Dave.
We upgraded LHO from RCG-2.3.1 to RCG-2.4.1 today. All systems were burtrestored using the supplied safe.snap files, or from the autoburt of 9am this morning. H2 systems were not activated beyond doing the burt restores (watchdogs left tripped, etc.).
The problem of some cores running long was investigated. All front ends were configured to new advanced bios settings. This appears to have fixed the run-long problem, we will continue to check this over the weekend.
Discovered H2 SUS ETMY had not been BURT restored after this upgrade. The BURT file, using /opt/rtcds/userapps/release/sus/burtfiles/etmy/h2susetmy_safe.snap (NOTE THE CHANGE OF LOCATION OF CDS USERAPPS REPO!!) gave a red, "NOT OK!" message upon restore, but from the looks of the error log and looking over the system, I think it's an issue with BURT file formatting upgrade, not that anything got improperly restored. After the restore, I can comfirm that the DAQ is functional -- I'm taking first set of Transfer Functions after upgrade now, I can (1) open DTT, (2) use it to send out excitations, (3) read back (in the present) _DQ channels. From prior discussions with D. Barker, R. Bork, and M. Landry, I'm 80% confident that h2susetmy's *was not* changed in this upgrade, where h2susitmy and h2susfmy's models were. I mention this because I was worried that the BIO (Binary Input/Output; completely different from the bios the Dave mentions above) would have lost its functionality -- therefore inhibiting drive (that pesky "test/coil" switch). Will provide more details in later aLOGs when I know more.
In BSC8, I'd found the H2 SUS FMY also needed a BURT restore. I've restored this suspension using
${userapps}/release/sus/h2/burtfiles/fmy/h2susfmy_safe.snap
However, because we've upgraded our Binary I/O interface in the RCG 2.4 version of the Simulink masters models,
${userapps}/branches/branch-2.4/sus/common/models/QUAD_MASTER.mdl
${userapps}/branches/branch-2.4/sus/common/models/BSFM_MASTER.mdl
which is what was used to compile both H2 SUS ITMY (a QUAD) and H2 SUS FMY (a BSFM) (but NOT YET H2 SUS ETMY), and that upgrade includes the need for new MEDM screens, found in
${userapps}/branches/branch-2.4/sus/common/medm/${optic}/SUS_CUST_${OPTIC}_BIO.adl
we need to make changes to
/opt/rtcds/lho/h2/medm/SITEMAP.adl,
which is where the generic screens' hard coded variables live.
I have updated the paths for ITMY and FMY (both in the call to the OVERVIEW screen, as well as in the SUSDIR variable), but it still doesn't call the right screen. Unfortunately, without the right variables sent to the screen, opening the screen by itself just shows white channels -- a feature of the generic screens.
Debugging is in progress...
H2 SUS ITMY is now functional: the trick was that the
${userapps}/branch-2.4/sus/common/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl
MEDM screen's link to the
${userapps}/branch-2.4/sus/common/medm/quad/SUS_CUST_QUAD_BIO.adl
was hard-coded to
/opt/rtcds/$(site)/$(ifo)/userapps/release/sus/common/medm/quad/SUS_CUST_QUAD_BIO.adl.
Once I corrected the button link, I was able to pull up the correct version of that screen, and change the coil driver State (H2:SUS-ITMY_BIO_M0_STATEREQ set to 1.0), and enable the coils (H2:SUS-ITMY_BIO_M0_CTENABLE set to 1.0). The attached TF shows that actuation works, and the dynamics haven't changed.
One would expect that H2 SUS FMY has the same problem, but when I fixed his overview,
${userapps}/branch-2.4/sus/common/medm/bsfm/SUS_CUST_BSFM_OVERVIEW.adl
the *new* channels came up white, implying that they don't exist, or are broken in some way. I'm still waiting here from Dave whether he compiled FMY with the RCG2.4 version of the BSFM_MASTER.
Could .fig, .mat and .m be added to the supported (matlab scripts, data and figures) be added to the list of files which can be up loaded?
I have added .m, .mat, and .fig to the list of allowed attachment types. Please note that the graphics library that the aLOG uses to create thumbnails does not support .fig files, so it cannot yet display the .fig files. I have requested that LLO update their logbooks as well.