Displaying reports 67361-67380 of 82985.Go to page Start 3365 3366 3367 3368 3369 3370 3371 3372 3373 End
Reports until 17:29, Tuesday 13 January 2015
H1 CDS
patrick.thomas@LIGO.ORG - posted 17:29, Tuesday 13 January 2015 - last comment - 17:31, Tuesday 13 January 2015(16054)
Conlog running again, had to remove ODC channels
Some of the ODC channels now appear to have string values with unrecognized characters. For example:

caget H1:PSL-ODC_FSS_BIT21
H1:PSL-ODC_FSS_BIT21           FSS Not Resonant (Loop 300370216d377177

I regenerated the channel list, searched it for channels with ODC in the name, added these to the exclude list, and regenerated the channel list again.
Comments related to this report
patrick.thomas@LIGO.ORG - 17:31, Tuesday 13 January 2015 (16055)
The alog didn't like the backlashes. Here it is with forward slashes in place of backslashes:

caget H1:PSL-ODC_FSS_BIT21
H1:PSL-ODC_FSS_BIT21           FSS Not Resonant (Loop /300/370/216d/377/177
H1 SEI (SEI)
sebastien.biscans@LIGO.ORG - posted 17:28, Tuesday 13 January 2015 (16053)
ETMY Z-RZ substraction: very encouraging preliminary results

(To know the whole story about the Z-RZ coupling, see DCC document #E1400432.)

I turned ON the substraction on ETMY-ISI ST1 with good results. If you look at the first attachement:

- Red curve -> nominal configuration (RZ loop OFF)

- Blue curve -> RZ loop ON. As expected, we amplified the RZ motion around 0.1Hz by turning the loop ON. The loop provides some isolation above 0.5Hz. Z doesn't change.

- Brown curve -> RZ loop ON + Substraction ON. We can see an improvement by almost a factor of 10 in the RZ spectrum around 0.1Hz. The substraction seems to work just fine.

 

As Ryan suggested, we also wanted to see if we can obtain similar results without the substraction. We do have Z sensor correction on HEPI, so we might be able to relax the actuation on Z (meaning higher blend) and still have reasonable performance in vertical. By relaxing Z, the couping with RZ should be reduce. Unfortunately, the Z motion seems to big for our need if we swich to higher blend  (see second attachement).

 

Last attachement shows different substraction configurations:

- Red curve: Substraction ON with a 90mHz blend on Z and Z sensor correction on HEPI

- Blue curve: Substraction ON with a 45mHz blend on Z and Z sensor correction on HEPI

- Brown curve: Substraction ON with a 90mHz blend on Z and Z sensor correction on ISI

 

Viewing those results, it seems that switching to a lower blend on Z might be a good idea.
For further analysis, we need to look at more sensors and the optical lever. We might want to look at the other chambers as well.

Images attached to this report
H1 SEI
brett.shapiro@LIGO.ORG - posted 16:56, Tuesday 13 January 2015 (16052)
Comparison of All H1 BSC-ISIs against Zach's model

The attached pdf compares Zach Patrick's BSC-ISI model against measurements of all H1 BSC-ISIs. Overall, the magnitudes are pretty good fits. Some of the TFs have right half plane zeros which throw the phase off. This will be a problem when trying to close loops around the model. Thus, I think we need to refit the model. I think this model was fit with frequency domain data in N4SID, but we now know that time domain is best (for good coherence). We also don't have any ground to stage motion fits, so we could add those in at that time.

I spent some hours trying to correct the right half plane zeros without success. My conclusion is that it is easy to fix in a SISO system by simply reflecting the right half plane zeros around the imaginary axis in the complex plane; but it is not feasible to do this with a MIMO system with dozens of poles and zeros. To do this you have to convert the state space to a zpk, which is fine. The problem is converting from zpk back to ss. For systems with multiple outputs, matlab does not have a numerically stable way to convert from zpk to ss. In fact it warns you about this in the comments to zp2ss.m. You could leave the model in zpk form, but it runs extremely slowly. Generally, state space is the best form for MIMO systems, since it permits the use of a lot of MIMO tools and analysis.

The model is located on the svn at

/ligo/svncommon/SeiSVN/seismic/BSC-ISI/Common/BSC_ISI_Model/N4SID_Model/L1BS/BuildFullL1BSmodel.m

 

To compare the model to data, run

 

/ligo/svncommon/SeiSVN/seismic/BSC-ISI/Common/BSC_ISI_Model/N4SID_Model/L1BS/CompareModel_to_data.m

Non-image files attached to this report
H1 SEI
filiberto.clara@LIGO.ORG - posted 16:56, Tuesday 13 January 2015 (16050)
HEPI Pier Pods - Installation of over-current protection boxes
Per work permit 5004, installed DC Power Breaker Switch Boxes D1400007 in-line with HEPI Pier Pods (D080520). The DC power breaker boxes were installed in the CER racks and provide over-current protection. Work was performed around noon and includes: HAM1-HAM6, BSC1, BSC2, BSC3, BSC9, BSC10.
LHO General
patrick.thomas@LIGO.ORG - posted 16:00, Tuesday 13 January 2015 (16036)
Ops Summary
Karen & Cris: Cleaning in the LVEA
Hugh: Starting work in MR for WP 4913

07:30 - 07:45 Jodi: Picking up 3IFO optics from mid Y
08:15 Jim B.: Stopping data concentrator. Building data concentrator version 2.9. Restarting DAQ to bring to version 2.9.
08:18 Jeff B. & Andres: Moving suspensions onto platform in LVEA. Going into bifurcated laser safe area.
08:20 Hugh: Retrieving parts from LVEA
08:49 Unifirst: Truck through gate
09:10 Karen: Cleaning at mid Y
09:13 Dave B. & Jim B.: Starting upgrade of frontends to RCG 2.9
09:31 Travis & Danny: Moving welding equipment in LVEA
10:03 Kyle: Checking access for WP 5005
10:11 Brian S. & Mitchel: Putting equipment in LVEA
10:26 Karen: Leaving mid Y
10:46 Travis & Danny: Entering LVEA
11:00 Cyrus: Firmware upgrade on OPS work station
11:04 Praxair: Truck through gate
11:05 Corey: 3IFO work at mid Y
11:10 Travis & Danny: Out of LVEA
11:30 - 11:50 Jodi & Jeremy: Surveying mid stations for 3IFO storage
12:00 Brian, Danny & Mitchel: Out of LVEA
12:04 Jeff B. & Andres: Out of LVEA
12:31 Dave B. & Jim B.: RCG upgrade complete
13:13 Corey: 3IFO work in squeezer bay
13:17 Filiberto & Sudarshan: Checking PSL power supplies
13:26 Kyle: Checking pump at end X
13:53 Richard: Turning on ESD at end X
14:08 Richard: Back from end X
14:12 Kyle: Back from end X
14:19 Jeremy & Brian: Loading equipment outside of LVEA
Jim B.: Updating GDS software WP 4997
15:00 Dale: Tour in control room
15:12 Jeff B. & Andres: Out of LVEA. Had been transferring suspensions into LTS container. Started around 13:30.
15:21 Keita: Going to squeezer area to talk to Corey
15:35 Ketia: Out of squeezer area
15:59 Corey: Out of squeezer area
H1 SEI
hugh.radkins@LIGO.ORG - posted 15:48, Tuesday 13 January 2015 - last comment - 16:22, Tuesday 13 January 2015(16049)
Corner Station HEPI Pumps now running on Actual Differential Pressure

Spent the morning getting all the cable runs sorted and the pressure sensors zero'd.  Switched databases so the servo would run on the differential pressure collected at BSC2 in the LVEA.  This will address a long standing Integration issue and work permit.  Still need to do similar at EndX before these items are fully resolved.  The EndY has been running on the differential for several weeks.

Couple issues here at the corner station: 1) As I was doing some final cable coiling etc this afternoon, I lost the controller signal to the South Pump Station.  I valved the PS out to stop the back spinning.  I'll restart this next Tuesday; I think I can restart it without harm but didn't want to risk it after being off all morning and commissioning now ongoing.

2) Pressure sensor 3 on Pump Station 3 (3rd from South) has an issue so the signal is actually coming from sensor #2.  The apparent 25psi differential pressure across the 3u filter is not true.

3) The medm still shows the Differential Pressure coming from the Main Supply Line Sensor, again it is really coming from BSC2.

Again, I'll deal with issue 1) on Tuesday.  For issues 2) & 3) I'll rework the medm to correctly reflect reality.

Attached is the current medm.

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 16:22, Tuesday 13 January 2015 (16051)

Okay, adjusted the medm.  So the servo pressure appears to be coming from BSC2 which it is.  Also annotated the PS3 sensor issue.  I've also adjusted the database calc so the red Pressure NOT OK will go green, the next time I restart the process, next Tuesday.  Corrected medm attached.

Images attached to this comment
H1 SUS
jeffrey.bartlett@LIGO.ORG - posted 15:42, Tuesday 13 January 2015 (16048)
3IFO Storage Container #2
Jeff B & Andres R

   This morning we loaded the 4 3IFO Quad Upper Structures (Quad-6, Quad-7, Quad-8, & Quad-9) onto the HAM ISI storage container #2. No issues or problems were encountered during the load. We will load the 2 TMS telescopes and Elliptical Baffles into this container during the week as opportunity allows.  
H1 SYS
daniel.sigg@LIGO.ORG - posted 15:39, Tuesday 13 January 2015 (16047)
Timing comaparator/frequency counters

Version 3 (svn tag 97) FPGA code was loaded into all timing comparator/frequency counters. This addresses:

There can still be a problem with crosstalk between channels, especially at frequencies above 200 MHz and signals stronger than 0 dBm. This has only been seen in open channels with no input. Channels with an RF input signal don't seem to suffer from it.

The CER and EX units were swapped with units which had a proper heatsink installed for the 5 V regulator. The following units were modified:

Serial Location Heatsink Code
S1107952 CER installed 3
S1201886 EX installed 3
S1201222 EY installed 3
S1201227 shop (MSR)   3
S1201224 shop (spare)   3
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 15:18, Tuesday 13 January 2015 - last comment - 19:13, Tuesday 13 January 2015(16045)
IMC REFL Path Falls Again After RCG 2.9 Upgrade
J. Kissel, S. Dwyer, D. Sigg, E. Hall, N. Mavalvala

After performing all of the usual alignment position checks (SUS, SEI, MC TRANs QPD, IM4 TRANS QPD), after the RCG 2.9 upgrade (see LHO aLOG 16040) we've confirmed that the IMC REFL path has jumped down in pitch again as it has done several times in the past after major computer reboots or SEI/SUS events (see Integration Issue 854, LHO aLOGs 10335, 11481, and 15650). 

We didn't preserve camera views prior to the reboot, and I didn't get the chance to capture an UNLOCKED camera view in which the REFL path was similarly low, but I attach the misaligned views after the RCG, then SEI and SUS recovery before realigning the path, and the realigned views after Evan, Sheila, and Nergis have realigned the whole path. We've also confirmed that the MC WS are running happily now as well.

Note that the IMC REFL L RFPD and trigger PD are on different image planes and lens focal points than the MC WFSA and MC WFSB and MC REFL GIGE Camera (see D0902284), so it's to be expected that they're differently affected by a misalignment of the MC REFL path. In other words, the IMC LSC path is much less sensitive to misalignments than the IMC ASC path (which contains the MC REFL GIGE Camera View).

Finally, for future reference, I attach a screenshot of all of the relevant camera views and screens I can for the IMCASC and surrounding sensors, with 2015-01-13_H1IMC_Status_ScreensandCamera.png
Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 19:13, Tuesday 13 January 2015 (16058)

We added an iris to the IMC refl path on IOT2L, in front of the calcite polarizer, in the hopes that we can use this next time to recover the alignment.  

Keita, Brett and I also noticed that HAM2 HEPI moved between before and after the bootfest, as can be seen both on the oplevs and the IPSs. (RY, which is pitch, was different by about 15 urad before and after the bootfest) We have restored HAM2 RY, but I didn't finish checking this for the rest of the chambers since the schnupp crew want the michelson locked for now.  In the morning we will have to go through the rest of the chambers and redo the alignment procedure. 

This isn't a big enough shift to explain why we had to realign on IOT2L earlier, but restoring this did bring the IM4 trans QPD back to almost the same position it was at before the bootfest.  

Images attached to this comment
H1 CDS
james.batch@LIGO.ORG - posted 15:12, Tuesday 13 January 2015 (16046)
Install updated version of GDS tools
WP 4997

The gds tools have been updated to branch/gds-2.16.12.4.  This includes two bug fixes:

Bugzilla 288 - add ramp down of excitation to swept sine response measurement. (diaggui)

Bugzilla 778 - Make filter module lists iterable in Python (foton)

This affects only Ubuntu workstations.

The update of nds2-client software mentioned in the work permit will not take place until a bug is fixed affecting collection of trend data from NDS1 servers.
H1 SEI
fabrice.matichard@LIGO.ORG - posted 13:14, Tuesday 13 January 2015 (16044)
HAM Sensor Correction

We are not yet satisfied with the HAMs sensor correction performance.  The first plot attached is the detchar plot form Jan 6. Ignoring HAM3 (see all logs related to HAM3), only HAM6 shows the blend notches at 1Hz and 1.5Hz. Also the ISI units seem to be only slightly lower than the ground at low frequency.

The second plot attached shows HAM 4,5 and 6 with the sensor correction off and in high blend. The ground and the ISI should have similar amplitude. The third plot show the data that I grabbed from Jan 9th 2am to 3am, and recalibrated. I do find that ground and ISI have very similar amplitude, so we need to double check the automated plots.

Then, the fourth plot shows the transfer function between the ground instrument and the ISI. I averaged the transfer functions between 0.1Hz and 0.4Hz and got the following numbers. That doesn't match with the numbers that Sebastien posted. So I must be forgetting a number in one of the input filter banks, or there is an error in the script used to match the gains.

 

  HAM4 HAM5 HAM6
X 0.945 1.001 1.035
Y 0.929 0.991 1.027
Z 0.918 1.039 1.103
Images attached to this report
H1 CDS
cyrus.reed@LIGO.ORG - posted 11:33, Tuesday 13 January 2015 (16043)
CDS Workstation Patches
I've run the latest patch sets against all of the workstations.  They should be rebooted when convenient to load the new kernel.

I have also patched and rebooted the vacuum boot server, vxboot, and the nameservers, ns0 and ns1.  vxboot did not have NTP installed (an oversight), so I did that as well.
H1 CDS
patrick.thomas@LIGO.ORG - posted 10:19, Tuesday 13 January 2015 (16041)
Conlog crashed
Conlog has gone down with the following error:

Jan 13 10:05:14 h1conlog2 conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Incorrect string value: 'xE0x0F=xE0xFF' for column 'value' at row 1: Error code: 1366: SQLState: HY000: Exiting.
Jan 13 10:05:15 h1conlog2 conlog: ../conlog.cpp: 331: process_cas: Exception: boost: mutex lock failed in pthread_mutex_lock: Invalid argument Exiting.
Jan 13 10:05:15 h1conlog2 conlog: ../conlog.cpp: 230: main: ca_poll returned 48. Exiting.
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 09:44, Tuesday 13 January 2015 (16040)
H1 upgrade to RCG2.9

Dave, Jim:

we are starting the upgrade of all H1 front end computers to RCG2.9. All systems will be put into their safe state and restarted. We are coordinating the restart order with commissioning staff.

H1 PSL (DetChar)
edmond.merilh@LIGO.ORG - posted 09:32, Tuesday 13 January 2015 (16039)
PSL Weekly Report

PSL Weeklies. Also Chiller water level is GOOD.

Images attached to this report
H1 DAQ (CDS)
james.batch@LIGO.ORG - posted 08:40, Tuesday 13 January 2015 (16038)
Dataviewer updated to 2.9.1
As part of the transition to RCG-2.9, dataviewer has been updated to 2.9.1. The new dataviewer reads the revised nds1 protocol and fixed bugzilla 728 to allow proper display of unsigned integer trend data.
H1 DAQ (CDS)
james.batch@LIGO.ORG - posted 08:28, Tuesday 13 January 2015 (16037)
Install new DAQ software, restart DAQ
The DAQ software has been updated to 2.9 on h1dc0, h1fw0, h1fw1, h1nds0, h1nds1, and h1broadcast0.  The DAQ was restarted to get the new software running on the named computers.  
H1 SEI (DetChar, SUS, SYS)
jeffrey.kissel@LIGO.ORG - posted 17:39, Monday 12 January 2015 - last comment - 10:34, Tuesday 13 January 2015(16028)
H1 SUS ETMX Rings Up, Triggers Software Watchdog, Trips SEI System
J. Kissel, S. Biscans, D. Barker, J. Batch

*Sigh* there's always a fire. Today's fire was that just before Dave and Jim went at EX to swap ADC cards (see LHO aLOG 16023), they'd asked Seb to turn off SEI ETMX. Once they looked, they found that the IOP Software Watchdog had tripped on the SEI system. 

In summary, there is a nasty but slow instability between the ST2 Y isolation loop and the QUAD T, RX, and RZ motion. We've never seen it before because we rarely, if ever, run the QUAD without damping and the ISI in fully isolated for more than an hour or so to take transfer functions. However, the independent software watchdog did exactly what it what it was supposed to do, and prevented extended shaking of the suspension caused by ISI instabilities. As Vern suggests, perhaps I awoke a daemon by jokingly invoking quotes from the Poltergeist last night, but it looks like we're well protected against daemon attacks.

Here's the story.

05:25 UTC           - Jeff requests SEI_ETMX Manager guardian to go to Fully Isolated (Remember this configuration includes *no ST1 RZ isolation*, and *no ST2 Z, RX, RY, or RZ* see SEI aLOG 658)
05:28 UTC-5:35 UTC  - Jeff takes transfer functions of SUS ETMX (see LHO aLOG 16012), and *leaves* M0 damping loops OFF.

Over the next two+ hours, the maximum ISI ST2 Y RX RZ displacement begins to ring up, most prominently at exactly 0.46 [Hz], the first Transverse Mode of the QUAD's main chain. (Note that the first L Mode at 0.43 [Hz], the first R mode at 0.92 [Hz] are also rung up as well, but not at the same amplitude). There is some, very slow, parasitic, positive feedback cross coupling between the free ST1 ISI RZ, or ST2 Z, RX, RY, and/or RZ and the QUAD's first T / R mode that leaks into the ST2 ISI's Y DOF loop that *is* closed, and slowly but surely rings up the ST1/ST2 Y/RX/RZ motion, and eventually rings up the whole system into instability.
The QUAD's watchdogs DO NOT trip, because the M0 and L2 watchdog has been spuriously set to 80 000 [ct]. Even if they did, the SUS all actuation on the SUS is already OFF, so it would have made no difference. Only if ALL FOUR SUS USER watchdogs tripped (M0, R0, L1, and L2), would it have triggered the SUS USER DACKILL, and sent a "PAYLOAD BAD" flag to the ISI, tripping its USER watchdog.
However, the SUS Independent Software Watchdog (IOP watchdog or SWWD), which also watches the RMS of the Main Chain begins sees this increase in RMS.

07:49 UTC           - The ETMX SWWD begins to register that the QUAD's "OSEM4," i.s. Main Chain LF, a Vertical Sensor, is surpassing the 110 [mV] RMS threshold, originally defined by Jeff during the Hardware Watchdog testing (see LHO aLOG 12496. As stated there, this is roughly 10 +/- 5 [um] or [urad] peak-to-peak thoughout the ISI/ QUAD system. Note that the LF sensor is seeing MUCH more RMS than any other sensor, but RT and SD are the next biggest contenders, implying some sort of Roll / Transverse / RX / Y - ey kind of motion.
08:00 UTC          - The SWWD's ETMX / QUAD watchdog is now constantly above threshold (State 3)
08:05 UTC          - The SWWD ETMX / QUAD watchdog sends a warning to the SEI ETMX watchdog indicating things are getting serious (SUS WD goes to State 4, SEI WD goes to State 3), and shuts down the SUS DACs, tripping the all SUS IOP's DACKILL (for TMSX, ETMX M0, and ETMX R0).
08:08 UTC          - The ISI's ST2 USER watchdog trips on the Actuators, but going only to State 3. This turns off ST2 X&Y, and the SWWD OSEM RMS begins to decline. << -- This points the finger at an ST2 X & Y instability (but ONLY when M0 is free).
08:09 UTC          - The SWWD's SEI watchdog get the final 1 minute warning that the SEI DACs are about to be shut down (SEI WD goes to State 4)
08:10 UTC          - The SWWD shuts down the SEI DACs, tripping the SEI IOP DACKILL (State 0). This sends both stages of the ISI to their USER WD State 4: full isolation shutdown.


I attach a whole bunch of plots I needed to back up this story. 

However, in addition to data mining, I *did* re-create the chamber configuration and take a standard SUS transverse transfer function, but gathered all of the ST1 T240s and ST2 GS13s as response channels, and plotted the transfer functions and coherence between M0 T and ISI Y RX and RZ -- 2015-01-12_2355_H1ETMX_WhiteNoise_tf.pdf
There's a lot of interesting information in there, but most importantly, there's a very coherent, transfer function at 0.46 [Hz] for all stages and all DOFs, with a magnitude of
       Y/T [m/m]      RX / T     RZ / T
ST1     2.3e-4        1.3e-4     0.014
ST2      0.16          0.018     0.033     


Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:34, Tuesday 13 January 2015 (16042)DetChar
The SEI Team:

Action Items from this event:

- Hook the SUS IOP watchdog's warning flag up (when the SUS IOP watchdog switches to State 4) to the ISI USER watchdog, to smoothly ramp down the isolation loops *before* the SEI DACs are shut down. This will also enhance /increase the warning signs / notifications / alarms, by default. 
  (highest priority)
- Reduce the M0 threshold SUS USER WD 
  (would not have affected the outcome of this event, but it should be reduced just the same)
- Find out exact what the instability was 
  (this will be time consuming both for the IFO and man-power, so we will likely *not* do this.)
Displaying reports 67361-67380 of 82985.Go to page Start 3365 3366 3367 3368 3369 3370 3371 3372 3373 End