Displaying reports 77321-77340 of 77364.Go to page Start 3863 3864 3865 3866 3867 3868 End
Reports until 12:23, Thursday 01 July 2010
X1 SEI
david.barker@LIGO.ORG - posted 12:23, Thursday 01 July 2010 (54)
seiteststand DAQ /frames file system full
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

X1 SEI
hugh.radkins@LIGO.ORG - posted 11:24, Thursday 01 July 2010 (52)
MicroSense CapPosSens Probe details from factory.
This would apply to all probes as in HAM, BSC etc.

We found the MicroSense did not report the standoffs and when asked were surprised it was not 2mm.  They do record them but don't list the number on the calibration sheet.  I'm asking for them all but to-date only have a few that they told me.  One was listed as 2.259mm (89mil) and four of the seven were greater than 2.16mm!  They will 'mess' with them if they are too far below the nominal and I don't know all the numbers yet.  This was a source of much of our confusion when we were jigging these in to get a noise spectra.  Eric ended up using 6 10mil shims on the test jig to get the outputs near zero.

Bottom line here is I wanted to post an email explanation given by MicroSense showing why our gaps are not exactly 2mm.  Sounds like we could specify that if we think it is needed but apparently we did not do so.

From Roy Mallory 1 July 2010:

Hi Hugh,

We calibrate to achieve a particular scale factor and to minimize
linearity error, but don't attempt to tweak the standoff.  The nominal
standoff is determined by design parameters, but a number of things, like
component tolerances, can cause it to be slightly different from unit to
unit.  It's also tricky to measure and define.  For example, is the
standoff the shortest line from the center of the probe to the target?  Is
it the distance between the point on the target and the point on the probe
that will first contact if the two are translated until they touch?  If
the probe and target aren't perfectly parallel, the standoff will be
affected, but is that the standoff to report?

What we do--mostly because it's simple--is to run the probe and target
together until they touch.  The target, which is the back side of a
mirror, is held to its mover by a light magnetic force.  The front side of
the mirror is monitored by an interferometer.  We note the
interferometer's reading with the mirror resting against the probe face,
and then move the mirror until the cap gage is at the center of its range,
noting the amount the interferometer reading has changed.

This method will be affected by parallelism, by any nonflatness in the
probe, and by any mote of dust on the probe or mirror.  Our gages do have
a front-panel zero control that allows the standoff to be adjusted,
however most of our customers want incremental accuracy and aren't overly
concerned about absolute standoff.  Does the LIGO application require some
particular accuracy in standoff?  If so, we can adjust the zero control at
the time of calibration to achieve your desired standoff.

Roy
X1 SEI
fabrice.matichard@LIGO.ORG - posted 11:16, Thursday 01 July 2010 - last comment - 11:41, Thursday 01 July 2010(51)
new awg to man verion - Problems with get_data
1) Alex has installed the latest code last night to get the new version of awgtpman going. We hope this solves the drive issue we were having. I did several quick tests (1 mn long). Everything seemed to be working fine.

2) I have started longer measurements (6 loops of 12 mn each). And I have been having issues with get_data.

I have increased the number of attempts to 25. It helps but doesn't solve the issue. The run ends up to crash. I copied the error message below.


------------------------------------------------
WARNING: attempt #24 to get drive failed
  wait 3 sec and try again
Getting data from nds0:8088...
Data received!
 
WARNING: attempt #25 to get drive failed
  wait 3 sec and try again
 
ERROR: unable to get data for this drive segment after multiple tries!
  giving up
  the data FRD has the correct frequency vector, but
  The DATA and DATA QUALITY frds for this segment
  will all BE SET TO ZERO
Comments related to this report
fabrice.matichard@LIGO.ORG - 11:41, Thursday 01 July 2010 (53)
It looks like we have been having two type of issues:

1- several attempts are sometimes necessary to get the data. That's what I was seeing during the quick tests.

2- The second issue is that the disk got full during the long test. Dave is fixing it.

We should be back to system identification shortly.





Logbook Admin Bug
jonathan.hanks@LIGO.ORG - posted 08:58, Thursday 01 July 2010 - last comment - 15:00, Thursday 01 July 2010(50)
Corey's Author name troubles
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.
Comments related to this report
jonathan.hanks@LIGO.ORG - 14:28, Thursday 01 July 2010 (55)
At 3:00pm Pacific time 1 July 2010 I will restart the Shibboleth daemon
on the alog.  This is an attempt to address the issues the have been
seen by Corey Gray regarding an author field not being filled out.

Restarting the Shibboleth daemon may require you to hit the login button
again.  However it should not damage any posts you are working on.
However please save your posts to a draft just in case.

I will be extending the Shibboleth session time to a large value.  What is happening with Corey is that his Shibboleth session is expiring after 24hrs.  However the alog still has enough information to identify him, so the posts are allowed, but the author name drops out.  This change can be done very quickly, without requiring new code to be written, so we will try this first.

Scott Koranda and myself are curious about how this will work out, ie will having a SP session that is much longer than the IdP session cause any problems.  Interesting times.
jonathan.hanks@LIGO.ORG - 15:00, Thursday 01 July 2010 (56)
The Shibboleth daemon has been restarted.  This is a test entry.

I realize I restart the wrong config value, the shib daemon was restarted around 3:30 with the proper settings.

If you see a case where the author name is not filled out.  Please fill it in with your ligo.org name (including the @LIGO.ORG) and post (or save to draft) the entry you were working on.  Then logout and log back in.  This problem should not present itself again.  Sorry for the hastle.
X1 SEI
corey.gray@LIGO.ORG - posted 04:31, Thursday 01 July 2010 - last comment - 11:38, Friday 16 July 2010(49)
Watchdog Woes Leading To: Reboot Of Front End & Matrices Re-Entry
Tonight, I had hopes of starting one of Fabrice's transfer functions overnight.  Unfortunately, I was not able to because I was never able to clear the Watchdog.  As for what seemed to be causing the trips, for the most part, the H1&V1 Actuators would immediately rail to 32k.  This would cause two things:  an Actuator WD trip & an H1/V1 Geophone WD trip.  Additionally the Actuator would remain in RED in the "First Trig" state.  I tried various tricks with gains, and turning off input/outputs to no avail.  Looked at the rack and nothing was amiss.

Reboot of seiteststand
At this point, I performed a reboot of the frontend.  It was straightforward and there were no issues, but it didn't change the situation.

Matrices Re-filled
All of our filter bank paths are fairly simple (no filters engaged and gains of 1 all around).  Oddities I found were in some of the matrices.  In the CONT2ACT matrix there was a 1 in a place there wasn't supposed to be a 1 and one of the matrix elements had a sign different from what it should be as well (see attached image of cont2act matrix).  Because of this I decided I might as well run the scripts to fill the matrices.

One more note:  the DispAlign matrix was also empty.  So, I put 1's down the diagonal of this guy as well.

Matrix Set-Up Scripts
Jeff Kissel has some bash scripts which fill the HAM-ISI matrices (they are the ones used to fill the HAM6 ISI for both sites).  Since Dave copied over the epics bin area to the seiteststand, we were now able to run bash scripts (as well as use commands such as "caput" & "caget").  Nic helped me edit the scripts to make them work (among some location-dependent changes, commented out the --noprofile --norc values at the beginning of the script.  I ran the scripts for the following matrices:  Disp2Cen, Geo2Cen, & Cont2Act.

After all of this, I was still not able to clear the Watchdog (or run our measurement).  I've attached a snapshot of the Watchdog.  Notice the "First Trig" of the Actuators (and how the Actuator Monitors are all 0).  As soon as I click RESET, these monitors would show H1/V1 rail to 32k.  
Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 11:38, Friday 16 July 2010 (76)
Just thought I'd add the location of these bash matrix scripts (Disp2Cen, Geo2Cen, & Cont2Act).  They are located at:

/opt/svncommon/seisvn/seismic/HAM-ISI/X1/Scripts/
X1 SEI
fabrice.matichard@LIGO.ORG - posted 08:53, Wednesday 30 June 2010 (47)
Awg issue
We are having troubles with the drive generated by awg. For some period of times it goes "weird". It can trip the watchdogs as illustrated on the attached document. 

On this example:
- the drive is good at the beginning
- then it starts doing unwanted high frequency stuff
- then it does other unwanted "oscillations" at frequencies coinciding sufficiently with the HAM-ISI resonance to trip the watch dogs. This is preventing us from completing our measurements.
Non-image files attached to this report
Logbook Admin Feature Requests
david.barker@LIGO.ORG - posted 08:36, Wednesday 30 June 2010 - last comment - 09:20, Wednesday 30 June 2010(46)
David Shoemaker's additional feature list
cut-paste from David's email 03:07 30/6/2010

1) Threads, displayed as a tree format so that you can follow threads, with the 
tree organized either alphabetically or by date (and with filters for author, 
entry age, etc.), one could follow what has been written in a recent thread 
about the system they are working on and then add another entry to that thread. 
No need for users to type a matching keyword, since the "Add Entry To This 
Thread" does that automatically. One would like to be able to title a thread -- 
this could just be the first entry title, but it would be useful to be able to 
edit that to cover the thread content and to make it easier to search for

2) searching across the installations (certainly LLO and LHO) is needed. I think 
it would be neat to be able to search the Virgo Cascina installation as well -- 
that is a question of international politics, I suspect. We would need a 
pull-down list to know which one(s) were being searched, and would want to be 
able to identify several or all.

3) reduced Recent Author list for searches, and autocompletion on author names, 
ideally making reference to the recent author list to order options

4) can an individual's input and search settings be remembered for the next 
login from that individual? Hugh works on SEI at LHO -- would be a nice way to 
get things on the right foot. Could be a big thing software wise, but would 
reduce a lot of the effort in getting going.

5) notifications: ability to put in aliases here (maybe trivial, could be 
maintained elsewhere), but would allow subsystems and the team to be notified 
for certain entries

SNS has these 'features'; are there some we want to plan to integrate?

   1.

      BulletIntegrates with work orders -- if nothing else, having all work
      orders appear as logbook entries would be quite valuable, I think.

   2.

      BulletGroup notification, daily orders and required readings

   3.

      BulletUser bookmarked entries

Also, one can filter at the view page by ordered posting time, author, or 
priority, a nice feature.

Their initial data message entry keyword/category input looks like this.



I think something like this would be very good for us; sounds like a database 
dimensionality question, though, so to be resolved soon if so. Breaking things 
down into more columns seems attractive.

entry types: Progress (default), Problem, Repair, Maintenance, Status

Categories:
Safety (might want to impose notification to all recent authors, or all authors, 
or something for this entry?)
QA
SYS
IOO
PSL
SUS
SEI
COC
AOS
ISC
DAQ
DCS
FMP
INS

Location: L1, H1, H2, LHO, LLO, MIT, CIT, Other

Priority: Urgent, high, normal (default)
Comments related to this report
david.shoemaker@LIGO.ORG - 09:20, Wednesday 30 June 2010 (48)
Snapshot from SNS log
Images attached to this comment
Logbook Admin Bug
david.barker@LIGO.ORG - posted 18:01, Tuesday 29 June 2010 - last comment - 18:48, Tuesday 29 June 2010(40)
BUG: why is this title displayed like this
Added "bug" task to the "Logbook Admin" section. Seems that putting
the "B" word in the title causes it to be displayed differently?
Comments related to this report
david.barker@LIGO.ORG - 18:02, Tuesday 29 June 2010 (41)
OK, mystery solved. I put the PRE tag with brackets in the title and
it was parsed as such.
david.barker@LIGO.ORG - 18:48, Tuesday 29 June 2010 (44)
email author if any log created by that author is commented on.
Logbook Admin General
david.barker@LIGO.ORG - posted 17:55, Tuesday 29 June 2010 (39)
BUG:
 HTML tag is not WYSIWYG
			
			
When using the PRE html tag to preserve the formatting of a block of text,
additional lines are added to the text.
X1 SEI
david.barker@LIGO.ORG - posted 16:50, Tuesday 29 June 2010 - last comment - 16:50, Tuesday 29 June 2010(37)
rebooted front end
DB and CG.

killed g1hamisi and g1x01, then rebooted the frontend computer
to clean up its memory [boot performed at 13:50]

DAQD would not run because it needed awgtpman present, so changed daqdrc
to allow running with no awgtpman (otherwise just kept spawning).

Started g1x01 and g1isiham, burt restores worked ok.

Mem usage at this time is (free -m):
[controls@seiteststand ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:          7986       2406       5579          0         82       1062
-/+ buffers/cache:       1262       6724
Swap:         1983          0       1983

Also copied the epics bin area from CDS to the /opt/apps/epics binary directory, but StripTool does not work.
Comments related to this report
corey.gray@LIGO.ORG - 15:22, Tuesday 29 June 2010 (38)
After the reboot noted above, Fabrice and I started a fresh Matlab from the iMac at the SEI Test Stand.  After this, I checked the memory usage, and had the following:
[controls@seiteststand ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:          7986       4303       3682          0         97       2615
-/+ buffers/cache:       1590       6395
Swap:         1983          0       1983
So here, matlab has been running for ~10 min. I ran this command immediately after opening and the "free memory" was 4400 and then 4000. It seems to be leveling out at 3400 as we are now running a measurement in matlab.
Logbook Admin General
jonathan.hanks@LIGO.ORG - posted 09:12, Tuesday 29 June 2010 - last comment - 11:34, Tuesday 29 June 2010(35)
Logbook Maintenance
This messages was sent to cds-software and lsc-sei.

I will be updating the aLOG this morning during the maintenance period.
 I will be working on the system starting at 11am Pacific.  It is
expected that I will be done by 11:30am Pacific.

This update will be a minor one which brings the code into a state where
it is portable between LLO & LHO in anticipation of LLO using this
software.  I will begin adding requested features next week.

If you are working on a log entry and are not ready to submit it by that
time, please save it as a draft (Click the 'save to draft' button).
Your entry will be stored and you will be able to finish editing it later.
Comments related to this report
jonathan.hanks@LIGO.ORG - 11:34, Tuesday 29 June 2010 (36)
I have concluded my updates.  The following was updated:

 * The login code is no longer hardwired with the server name (portability fix)
 * Increased spacing between reports to improve readability
 * Removed the 'Logged in as' text to help all the controls fit better in the upper portion of the screen
 * Made some modifications to the css and html to layout the quick keyword and task search a little better
 * Added a self referential link to each log entry
 * Updated the login logic to again display user and password entry boxes when not doing apache (Shibboleth/LIGO.ORG in our case) authentication (portability/bootstrap fix)
 * Updated some minor bits of apache configuration to ensure all http requests are properly redirected to https

I had hoped to address Corey's author name issues, however Corey and I were unable to reproduce the problem today.

In the next set up updates I hope to have a more comprehensive fix in place.  Also I will work with Dave Barker to add another color scheme so that LLO & LHO can be differentiated easily.
H2 General
corey.gray@LIGO.ORG - posted 11:43, Monday 28 June 2010 - last comment - 13:40, Monday 28 June 2010(31)
Swapping H3 GS-13 From Assy #1
It has been shown there have been issues with our H3 GS-13.  Before pulling out the GS-13, the ISI table was visually checked for mechanical shorts (none were found).  As another system/pod check, the ISI table was tilted in a couple of different states(by placing weight on table) such that the pod would be angled "down" & angled "up".

H3 is unique in that it is the GS13 whose axis is perpendicular to the Support Tubes (vs. H1 & H2 who are symmetrically angled wrt the Support Tubes).  For our set up, the "crane-Southern" Support Tube is the side where the "TOP & unfixed" end of the H3 GS13 is.  The "crane-northern" end of the GS13 is where the "BOTTOM & bolted-down" end of the GS13 is.  Because of this geometry, it was easy to put weight on the table such that we tilt the TOP or BOTTOM of the GS13.

With the TOP tilted down, we did not notice any change in the H3 performance (we were looking at DataViewer, the signal looked noisy, and would only show big seismic bumps and then quickly damp that out, and return to the noisy state).  

With the BOTTOM tilted down, H3's performance totally changed---for the better.  H3's signal looked like its fellow H1 & H2.  A Power Spectrum confirmed that H3 looked like the other GS13s when the BOTTOM was tilted down.  The attachment's top plot shows the GS13s with the ISI weight down on the Northern end of the table.  The bottom plot shows a balanced & unlocked ISI from last week (where we had an ugly H3).

After this, we decided to swap this GS13 for our one & only extra Horizontal GS13.  For documentation, there is a Serial Number on the base flanges for these guys.  

Original/old H3 GS13 is S/N 046
New H3 GS13 is S/N 068

Will post performance of our new H3 after the swap is made (not a trivial or quick task).
Non-image files attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 12:02, Monday 28 June 2010 (33)
Entry above was made by Corey Gray (When I'm logged in, not sure why I have to enter the "author name" every time I do something here).
corey.gray@LIGO.ORG - 13:40, Monday 28 June 2010 (34)
[Corey, Hugh, Jim, Mitchell]

Back in business!

After about 90minutes we had a new H3 ready to go.  Like I said it wasn't trivial.  It took 3 people garbed up inside working for 90minutes.  There are also tons of bolts which had to be dealt with--always scary because one always has the fear of possibly galling a bolt.

But yes, once the GS13 was securely installed, one could clearly see that its signal on Dataviewer was much better (and more like H1 & H2).

The table is probably not ideally level (due to the swap work), but went ahead and ran a high-resolution power spectrum [attached], and the results clearly point out a better looking H3.

As for the old H3 GS13--
* When was it last tested?  (right before it was sent up?)
* What should we do with this GS13?  (send to LLO?)
* Do we have any more spares?  (we just have one Vertical spare now)
Non-image files attached to this comment
Displaying reports 77321-77340 of 77364.Go to page Start 3863 3864 3865 3866 3867 3868 End