BOSEMs were hooked to the EE test stand today.  Signals look live but need calibration before interpretation.  Medm looks to have a nice set of appropriate filter banks for the QUAD controls, but interestingly, does not have a main.adl.  We're also looking to load or rebuild the medm's Brett created for LASTI which have easy to read voltage meters to aid in alignment.  AOSEMs are fresh from the oven and will be installed in the PenRe tomorrow.

The Sleeve was installed onto the QUAD for fit-check today.  It is cumbersome to man handle into place, so we should fiure out a better what to install it...  Clearance holes in the structures could be opened up a bit.

Attached are spectra of the Assy #1 GS-13's when the table was Locked & Unlocked.

Ran three different spectra for our Displacement Sensors.  Since we currently have an electronics issue with the operation of our Sensors (there's "electronic cross talk" between our mini-racks when they're both powered up---resulting in a ~0.35Hz oscillation seen by all sensors) we ran three different measurements in the following running states:

1)  Both mini-racks powered ON*
2)  Only Rack#1 (for H1V1H2V2) powered ON*
3)  Only Rack#2 (for H3V3) powered ON


* DTT BUG:  Although the plots for these measurements say there was only "1 Avg", they in fact were run at the required 10 Averages.  (When one saves References from a previous measurement, and makes a new plot of these References, the new plot posts the averages as "Avg1".  (If one already has the Reference plots made and one re-runs their "Now" measurement, the average value will change to whatever your "Now" measurement Average # is.

There will be a minor change to the aLOG tomorrow.  However the alog will not be restarted, so there should be no downtime.

A new color theme is being added, so that we will be able to differentiate between the sites.

LHO will get a blue theme, LLO will get the default green theme

This will be applied tomorrow during maintenance.

There will be no scheduled downtime for this change.

Jim and I just did a renaming of the computers on the DTS. dtsfe0 and dtsfe1 have swapped names. So now the server machine you ssh into is now dtsfe0 (the router's mapping table accordingly changed). dtsfe1 is now the first of the true front end machines.

Jim is using dtsfe1 for his seismic test stand clone. The original HDD was put aside, and a clone of seiteststand substituted. This frontend uses the top IOC chassis, which has the ADC, DAC and BIO cards necessary for the model.

Work continues to tune up the alignment of both the reaction and main chains of LHO Q1 (QUAD #1).  Height, Yaw, and Pitch are coupled for various adjustments, so it is an iterative process to get everything correct at the same time.  Yesterday, we discovered that during on of our "side shift" adjustments, we unseated a wire clamp on the UIM, so we had to do some minor dismantling and re-assembly to fix it.  In fact, the clamp was a bit munched on one edge, so the Class B file came in handy.

As Fabrice and Corey eluded to in the LSU SEI logs 1762,63, & 65, the H3 GS-13 was not right.  There was some statements that it was OK one week and then not the next.  I believe this initial observation was only in the Table-was-locked state.  Corey and Vincent may have mined some further data in that regard.  Regardless, the observation that it looked OK when the table was locked but not when unlocked made me think of the internal pod clamping hardware.  Never liked it and sure glad the BSC is different.  Anyway, I thought maybe the sensor had shifted a little bit in the Pod and the Mass was just seated and would see the un-damped world when locked.  But, when the table was unlocked, the stuck mass would have no 'power' in the low frequencies.  I'm sure it doesn't matter why I thought anything but...

So, we tilted the table such that the sensor would tilt down even lower, by adding a couple pounds, and observed no difference in the GS-13.  Then we shifted the weight to the other side so that the GS-13 would tilt up--same weight shift.  This time the time series looked good!  I think Corey took a spectrum to confirm.  We then swapped out that unit for the one spare Celine sent (thank you!) and it worked--without the tilting weight added of course.  I believe Fabrice is suggesting we do a similar tilt test to confirm we are in the center of the likely small 'level' range of the sensor.

JoeH has asked I send this unit back where he'll autopsy; so I can't offer any more info than that.

Reseated 10GbE card on h2daqfw1 (slot 5) which seems to have cleared up the bus timeout messages from dmesg.  That should be fixed, unless issues return.

I forgot to add in the previous report that disabling the option ROMs in the BIOS for all slots except 0 (the RAID controller), and removing the network cards from the boot list considerably improves the boot time.  Counting memory on startup is still slow, as is applying power for the first time (the iLOM controller must boot first in that case).  Will see if there is some setting for the iLOM that can get around this.

Have also finished installing the cards in the H1 DAQ x4270s, and installed Solaris 10 so they are also ready to go (minus user accounts, iLOM setup, etc.).  Did not see any glaring hardware issues.  These two machines are now re-boxed in the MSR.

This is simply a test of the add report page.  The author field is frozen now (mostly).

Just a quick reminder.  The logbook will be undergoing scheduled maintenance today from 10am-noon Pacific time.

If you have reports that will span that time gap, please save them as a draft or publish them before 10am.  You can finish them after noon (pacific).

 On Thursday July 1, I modified the DAQ .ini file located in '/opt/rtcds/geo/g1/chans/daq' named 'G1ISIHAM.ini'.  

This new file has added some needed channels to acquire data and write frame files on the test stand front end.  I re-loaded the DAQ and re-booted the framebuilder. The complete list of available DAQ channels that are currently writing frame files is attached. 

- We have completed the set of Local to Local measurements

- We have made a full of Modal to Modal measurements today

- The attached document shows the transfer functions and summarizes all the  parameters of data acquisition

- We start analyzing the results. At least two things catch attention and need to be checked: the resonance at 24Hz in the GS13, and the phase of the CPS at low frequencies.

- We are taking more data with a finer resolution and more averages.

- awgstream issues have been solved by the installation of the new version of awgtpman.

- about the get_data issue, Dave has created some spare space and installed the wiper script to prevent the disk from being full again.

- we run transfer functions this afternoon, everything went well. We have got a first complete set of transfer functions in the local basis. It is attached.

Few comments about these transfer functions:

- Low frequency data is noisy. We will increase the number of averages
- Transfer functions are going to be compared with HAM 6 measurements
- There is and undesired resonance at 24Hz


We are preparing a set of measurements in the general coordinate basis for tonight.

The /frames file system was 100% full, which means no new frames
were being written by the daq.

I have written a primitive script to just delete the oldest full frame
and second trend frame directories if /frames gets bigger than 95%.

The script runs as a cron job, as user controls on seiteststand


# Every hour run script to keep /frames from filling
# check /tmp/daq_wiper.log for its logs
0 * * * * /home/controls/crontabs/daq_wiper.pl

Corey is still having issues with his name not being pre-populated in the author field of an entry.  This does not happen all the time. He reports that it happened again last night/this morning.  One of the details that he gives is that it happened with a browser tab that had been open to the alog for a long period of time.  This may be an issue of the Shibboleth session timing out.  This may be a bad interaction of lazy binding (which allows us to do anonymous read-only access) and the alog.

If this is the case it would explain corey's issue.  There are ways to mitigate this, by extending the session length for Shibboleth, or making the alog more Shibboleth aware.

I will test this on gold, the test alog server.  There I have the freedom to make the session timeout very small without interfering with others.