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.
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.
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/
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.
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)
Added "bug" task to the "Logbook Admin" section. Seems that putting the "B" word in the title causes it to be displayed differently?
OK, mystery solved. I put the PRE tag with brackets in the title and it was parsed as such.
email author if any log created by that author is commented on.
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.
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 1983Also copied the epics bin area from CDS to the /opt/apps/epics binary directory, but StripTool does not work.
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 1983So 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.
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.
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.
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).
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, 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)
Removed entries for awg and tp from /opt/rtcds/geo/g1/target/gds/param/diag_T.conf file as general cleanup. The lines were unneeded for description of awg and tp services, the awg and tp services are established and registered with diagconfd when awgtpman is started from the startup_g1x01.cmd and startup_g1isiham.cmd scripts. Any awg or tp entries in the diag_T.conf file would be at best duplicates.
The H2 DAQ rack is a new style (beige) rack located in the MSR nearest the hallway. It has two Sun X4270 computers, which will be the H2 DAQ frame writers/QFS masters. Cyrus is working on installing sol10 on these systems. He will also test the DAQ networking switches and spare units using this rack. We encountered a problem with the rack mount KVM switch in this rack, the internal power connector to the PCB is flakey. The flatscreen monitor signals this with a "cable not connected" error and powers itself down.
Both machines are loaded with Sol 10. h2daqfw1 had some bus errors from one of the PCIe cards on first boot, which I'll have to investigate more closely when I return from vacation after the Jul 4 holiday. Re-seating cards may help if the issue persists. Also still to do is add non-root accounts to h2daqfw0/1, configure iLOM, configure the switches in the rack (verifying first that we actually have the correct switches installed), basic network throughput tests, etc. A current stab at a (test) IP numbering scheme is as follows: 172.17.0.1/24: h2daq test stand 172.17.0.1/28: Routers, switches, gateways 172.17.0.17/28: DAQ Servers Currently assigned: 172.17.0.1: (Reserved for default route(r), not installed) 172.17.0.18: h2daqfw0 172.17.0.19: h2daqfw1
Today, dtt was used to obtain spectra for the LHO HAM ISI Assy #1 located at the SEI Test Stand. This measurement was run with the dial indicators disconnected. Two measurements were run: The first one ("T1") had H1V1H2V2 Displancement Sensors & ALL GS13's. The second measurement ("T2"), had H3V3 Displacement Sensors. Two measurements were needed because of the ~0.3Hz noise seen between both Displacement Sensor "mini-racks". One blaring feature (see attached spectra) is the H3 GS13---something looks amiss with it. Checked the rack for anything obviously wrong, but all HAM Interface Chasis looked fine. Vincent suggested putting a 300count vertical offset on the H3 Actuator, and this clearly showed something wrong with this GS13 (see attached screenshot).
The screenshot I tried attaching above didn't seem to work (it was a .tiff screen shot from a Mac & was treated as a quicktime file when I tried clicking it from the log). Attached here is a .jpg version of the same file. Hopefully this works.
I am attaching a Power Spectrum from last week. It looks like H3 was fine. Also, looking at the time series, it seems that there is some signal, but much lower (about two order of magnitudes on the power spectrum). Could it be a BIO filter improperly switched?
Are Fabrice's spectra with the table locked, and Corey's without? The high-frequency (>10 Hz) structure has changed dramatically on *all* the sensors between those two spetra. If these two spectra were taken with the table in the exact same state, then this might be another clue...
(Vincent L., Richard M., Corey G.) There is no BIO for the SEI Test Stand. And yes, it should be noted that the spectra from Fabrice's post was from a couple weeks ago. It was a quick one we ran with the SYSTEM LOCKED (we were performing a quick check to investigate the 0.3Hz signal on the Displacement Sensor Mini-Racks). So, it was wrong for me to say everything looked good from that spectra--I had assumed assumed the ISI was un-locked. Last Friday, we performed a few more checks on the GS13. The most telltale check was a cable swap. From the "feedthrough interface", the GS13 Horiz/Vert cable runs to the H/V location. Here is a connection to a plug which splits into two separate cables--one goes to the Horiz GS13 & the other goes to the Vert GS13. We unplugged the H3/V3 cable here, and ran it to the H1/V1 cable. Dataviewer showed that the problem stayed with the H3-GS13 (i.e. H1 was now ugly). Therefore something is wrong with H3 GS13. Reconnected cables to their original configuration. As another check, we locked up the Table and ran another power spectrum [attached]. Sure enough, we had similar results to what we saw a couple of weeks ago (i.e. Fabrice's post)---where all the spectra, for the most part, look similar. Thinking their may be a mounting issue, or something wrong with the mechanical structure of the GS13 inside, we will take a look for any rubbing in the area of H3/V3. We'll then take off the H3 door, and perform some checks on H3 (while watching with DV & quick spectra).