Displaying reports 62981-63000 of 77255.Go to page Start 3146 3147 3148 3149 3150 3151 3152 3153 3154 End
Reports until 12:20, Tuesday 28 October 2014
H1 CDS
cyrus.reed@LIGO.ORG - posted 12:20, Tuesday 28 October 2014 (14673)
CDS Workstation Patches
I've installed the latest packages on all of the CDS workstations.  Unfortunately, this came with an update to nslcd which broke LIGO.ORG authentication when it spammed the nslcd.conf file (fixed).  The /etc/apt/sources.list file on the workstations was also updated to point to the new mirror server (ubuntu-mirror).
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 11:56, Tuesday 28 October 2014 - last comment - 13:50, Tuesday 28 October 2014(14671)
Calibration of HWSY magnification via injection into ITMY YAW

I'm currently injecting a 50mHz, 2 micro-radian ampltiude sinusoid into ITMY YAW (via the top stage). HWSY is now within a few mm of the conjugate plane of ITMY. The HWS code is running and will measure the apparent tilt at the HWS from the injection oscillation. I will use this to calibrate the magnificiation of the HWSY optical system.

Comments related to this report
aidan.brooks@LIGO.ORG - 13:50, Tuesday 28 October 2014 (14679)

Injection stopped.

H1 CDS
patrick.thomas@LIGO.ORG - posted 11:18, Tuesday 28 October 2014 (14664)
Beckhoff work
Work done under permit 4917:

end X

quit IOC
C:/SlowControls: svn update
H1ECATX1: SYS, PLC3: 'Update from source'
C:/SlowControls/Target/H1ECATX1/PLC3/PLC3.pro: Project -> Rebuild all; Save
C:/SlowControls/Target/H1ECATX1/H1ECATX1.tsm: PLC3 -> Rescan Project; Actions -> Generate Mappings, Check Configuration; Save
Copy C:/SlowControls/Target/H1ECATX1/H1ECATX1.tsm to C:/SlowControls/Scripts/Configuration/H1ECATX1/SYS/H1ECatX1.tsm; svn commit
Copy C:/SlowControls/Target/H1ECATX1/PLC3/PLC3.pro to C:/SlowControls/TwinCAT/Source/Current/Interferometer/End/PLC3.pro; Export EXP. svn commit Plc3.pro and Plc3.exp
C:/SlowControls: svn update
H1ECATX1: SYS, PLC3: 'Stop', 'Update from source', 'Compile', 'Activate and run', 'Restart EPICS database'


end Y

quit IOC
C:/SlowControls: svn update
H1ECATY1: SYS, PLC3: 'Update from source'
C:/SlowControls/Target/H1ECATY1/H1ECATY1.tsm: PLC3 -> Rescan Project; Actions -> Generate Mappings, Check Configuration; Save
Copy C:/SlowControls/Target/H1ECATY1/H1ECATY1.tsm to C:/SlowControls/Scripts/Configuration/H1ECATY1/SYS/H1ECatY1.tsm; svn commit
C:/SlowControls: svn update
H1ECATY1: SYS, PLC3: 'Stop', 'Update from source', 'Compile', 'Activate and run', 'Restart EPICS database'


corner station

quit IOC
C:/SlowControls: svn udate
Conflict with file C:/SlowControls/TwinCAT/Source/Current/Interferometer/Corner/Plc1.pro
Copied working version out of way, updated to version in svn, made changes that were done in the working version, recommited
C:/SlowControls: svn udate
H1ECATC1: SYS, PLC1: 'Update from source'
C:/SlowControls/Target/H1ECATC1/H1ECATC1.tsm: PLC1 -> Rescan Project; Actions -> Generate Mappings, Check Configuration; Save
Copy C:/SlowControls/Target/H1ECATC1/H1ECATC1.tsm to C:/SlowControls/Scripts/Configuration/H1ECATC1/SYS/H1ECatC1.tsm; svn commit
C:/SlowControls: svn update
H1ECATC1: SYS, PLC1: 'Stop', 'Update from source', 'Compile', 'Activate and run', 'Restart EPICS database'


controls workstation

cd /ligo/cds/lho/h1/burt/2014/10/28/06:10
burtwb -f h1ecatx1plc3epics.snap
burtwb -f h1ecaty1plc3epics.snap
burtwb -f h1ecatc1plc1epics.snap
H1 SEI (SEI)
richard.mccarthy@LIGO.ORG - posted 11:13, Tuesday 28 October 2014 (14670)
H1 BSC3 (ITMx) L4C offset repair
per Work Permit Number: 4912

A -4300 count offset observed on L4C channel.  Looked like losing one leg of the differential input.
After narrowing down the offset to the I/O chassis by moving input cables and the ADC cables around and checking the AA chassis.  We swapped the ADC board with no change in offset.  We then swapped the ADC interface board and cable this fixed the problem.  I have thrown out the cable and will test the board in the test stand.  
H1 SYS
jameson.rollins@LIGO.ORG - posted 10:44, Tuesday 28 October 2014 - last comment - 19:33, Tuesday 28 October 2014(14660)
guardian/cdsutils upgrades

I upgraded the guardian core and cdsutils (python ezca) installs:

I restarted most of the nodes, except for the following:

jameson.rollins@opsws2:~/src/cdsutils/trunk 0$ guardctrl list | grep -v 1095
node         s k m vers  state                                    message
----         - - - ----  -----                                    -------
ALS_COMM     o - -    -  -                                        -
H1ECATC1PLC2 *   E 1076  INIT                                     
H1ECATX1PLC2 *   E 1076  INIT                                     
H1ECATY1PLC2 *   E 1076  INIT                                     
H1ISCEX      *   E 1076  INIT                                     
H1ISCEY      *   E 1076  INIT                                     
H1LSC        *   E 1076  INIT                                     
H1LSCAUX     *   E 1076  INIT                                     
HPI_HAM2     * * M 1083  ROBUST_ISOLATED                          
IAS_INPUT    o - -    -  -                                        -
IAS_MICH     o - -    -  -                                        -
IAS_PRC      o - -    -  -                                        -
IAS_SRC      o - -    -  -                                        -
IAS_TEST     o - -    -  -                                        -
IAS_XARM     o - -    -  -                                        -
IAS_YARM     o - -    -  -                                        -
IFO_ALIGN    o - -    -  -                                        -
ISC_LOCK     o - -    -  -                                        -                            
ISI_HAM2     *   P 1083  WATCHDOG_TRIPPED_FULL_SHUTDOWN           WATCHDOG TRIP: FULL_SHUTDOWN (4)                       
LSC          *   E 1076  INIT                                     
LSC_PRMI_VAR_FINESSE *   E 1083  DOWN                                     MISALIGN PRM
LSC_PRX      *   P 1083  FAULT                                    check LSC input matrix, ITMY not MISALIGNED
LSC_PRY      *   P 1080  FAULT                                    PRM not ALIGNED, ITMX not MISALIGNED
SEI_HAM2     *   P 1083  ISOLATED                                   
SUS_MC1      * * E 1080  ALIGNED                                  
SUS_MC3      * * E 1080  ALIGNED                                  
SUS_PR3      * * E 1080  ALIGNED                                  
SUS_PRM      * * M 1083  ALIGNED  

The non-running nodes (s='o') had various errors on restart, so I shut them down until they can be fixed.  I shut down all the IAS nodes since I was told they're not in use.  The HAM2 nodes were not restarted because Hugh was in the middle of doing some SEI work on HAM2.  The nodes starting with "H1" are the "CSDEF" nodes (not sure what the status of those is).  I'll restart these nodes when I'm sure it's ok.

I noticed that there are a couple of "hidden" nodes, that are not listed in the Guardian overview screen:

H1ECATC1PLC2 *   E 1076  INIT                                     
H1ECATX1PLC2 *   E 1076  INIT                                     
H1ECATY1PLC2 *   E 1076  INIT                                     
H1ISCEX      *   E 1076  INIT                                     
H1ISCEY      *   E 1076  INIT                                     
H1LSC        *   E 1076  INIT                                     
H1LSCAUX     *   E 1076  INIT   LSC          *   E 1076  INIT                                     
LSC_PRMI_VAR_FINESSE *   E 1083  DOWN                                     MISALIGN PRM
LSC_PRX      *   P 1083  FAULT                                    check LSC input matrix, ITMY not MISALIGNED
LSC_PRY      *   P 1080  FAULT                                    PRM not ALIGNED, ITMX not MISALIGNED

We should be very careful about these.  If they're being used, they should be on the overview.  If they're not being used, they should be shut down.  Do not leave running nodes off of the overview screen

Comments related to this report
jameson.rollins@LIGO.ORG - 10:47, Tuesday 28 October 2014 (14668)

I should note that a bug was fixed in the cdsutils avg function.  The standard deviation calculations were bogus, off by some unknown but large factor.  This new version fixes that issue so that the standard deviation calculations returned with the "stdev" option are now correct.

jameson.rollins@LIGO.ORG - 10:54, Tuesday 28 October 2014 (14669)
sheila.dwyer@LIGO.ORG - 19:33, Tuesday 28 October 2014 (14692)

We have reverted the cdsutils to cdsutils-329 (the version installed here since september), we did this by changing the link in /ligo/apps/linux-x86_64

The guardians were failing when they called the new avg function, we tried using the new cds utils function from the command line but it doesn't seem to be working. 

H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 10:38, Tuesday 28 October 2014 (14667)
ITMY YAW injection for HWS imaging

I'm currently injecting a 50mHz, 3 urad amplitude signal into the ITMY YAW to help align the HWS probe beam.

H1 SUS (ISC)
brett.shapiro@LIGO.ORG - posted 10:20, Tuesday 28 October 2014 (14665)
HSTS model M3 pitch to length coupling

Posting some notes retroactively from an email conversation with Rana last month.

Based on https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14057, Rana was curious of whether the HSTS model can predict the PR2 M3 stage angle to length coupling down to the mm/rad level. My response was the following:

"The existing models don’t appear to be good enough. See the attached figure of M3 long-pitch coupling. The blue is the generic HSTS model. The black is a (very thorough) fit of the model to H1SR2 I made earlier this year, 10124  You’ll note that these models differ by quite a bit more than 0.001 m/rad.

This plot was made by plotting the TF ratio of (M3 L to L [m/N]) / (M3 L to P [rad/N]).
 
You should have better luck if we simply replace the HSTS model with the fit to H1SR2. The second attached figure compares top mass P to P measurements of a few suspensions, and all seem to agree with this sus better than the generic model.
 
However, the errors on mode freqs between HSTSs are still on the order of 1%. Playing with some parameters in the model indicates that this corresponds to a DC error on the M3 m/rad at least as big as the 0.001 m/rad level. So we would basically have to make really good fits of the model to each sus to predict the coupling to that level.
 
Also, the diagonlization on the M3 OSEM actuators would have to be really good [to not generate additional spurious coupling].
 
If you are interested in yaw to length as well, the model doesn’t predict anything useful at all for that."
 
Rana then suggested an alterntive to fitting many models, "that as long as the mechanical TF is stable, we can always use this as a relative reference; once we find a good global alignment, this is a a good technique to recover the alignment."
 
 
If we go the route of fitting models for each sus, the best bet will be to use the good H1SR2 fit as a starting point, since this fit incorprates data from double and single hang tests. Then, update the model for each sus based on its measured top mass to top mass resonance frequencies.
Images attached to this report
H1 DAQ (CDS)
james.batch@LIGO.ORG - posted 10:15, Tuesday 28 October 2014 (14666)
h1nds1, h1fw1 down
The daqd processes that write frames and provide NDS data have been shut down for modification of the file system for frame storage.  The default NDS server has been changed to h1nds0.  
H1 DAQ (CDS)
james.batch@LIGO.ORG - posted 09:32, Tuesday 28 October 2014 (14663)
Changed default NDS server
I have changed the default NDS server to be h1nds0 in preparation for expansion of the h1fw1 file system, WP 4916.  This will affect all new logins, shells, and processes that use the NDS.  Existing processes that use h1nds1 will probably stop working well when the h1nds1 server is shut down.
H1 SEI
hugh.radkins@LIGO.ORG - posted 09:10, Tuesday 28 October 2014 (14661)
WHAM2 ISI has new controller--so-so performance; Guardian Issues Remain

New controllers developed with the ISI under vacuum and the HEPI Position loops closed.  Frankly, I have to say they don't seem to be any better and in fact they aren't as good.  Of course it is Tuesday Maintenance but the Ground motion plots don't seem especially worse so, I don't know.  I've switched from the 01_28 to the 100mHz blends.  We'll see if that makes a difference.

Attached is this morning 8am with the new controllers and new matrices loaded yesterday with 01_28 blends.  The second attachment is yesterday at 7am with the old matrices (wrong cartesian basis signs X Y RX & RY) and the old controllers with I believe the 100mHz blends.

Images attached to this report
H1 PEM (DAQ)
james.batch@LIGO.ORG - posted 08:07, Tuesday 28 October 2014 (14658)
Mid X PEM data stream restored
Apparently the restart of the DAQ at ~7:30 PDT killed the mx_stream process on the h1pemmx computer.  No data was recorded for PEM-MX, including the vault, until the mx_stream was restarted at 7:54.
H1 CDS (SUS)
stuart.aston@LIGO.ORG - posted 07:56, Tuesday 28 October 2014 - last comment - 09:17, Thursday 30 October 2014(14657)
QUAD Model Updates Complete (WP#4915)
[Jeff K, Stuart A]

Following work yesterday preparing QUAD model updates (see LHO aLOG entry 14645), we convened early this morning to rebuild, install and restart models. 

A detailed log of our activities follows:-

- Bring down the IMC to DOWN state via Guardian (no change to LSC model)
- Bring down QUADs to SAFE state via Guardian
- Bring down SEI to OFFLINE state via Guardian  
- Capture new safe BURT snapshots for h1lsc, h1susetmx, h1susetmy, h1susitmx and h1susitmx
- Made all QUADs
- Installed all QUADs
- Restarted all QUADs
- Svn-up updated QUAD MEDM screens
- Untripped all Watchdogs
- Restore QUAD alignments
- Restore SEIs to FULLY_ISOLATED via Guardian 
- Restore IMC to LOCKED via Guardian
- DAQ process restart at 14:29 (UTC)
- Update other SUS MEDM screens (see LLO aLOG entry 15004) 
- Cleaned errant IPC issues with diag reset on GDS TP screen
- Committed new safe BURT snapshots to svn

Summary of benefits:

This now makes damping of violin, bounce and roll modes possible via the the L2 (PUM) stage of all QUADs using DARM error. Other benefits include: ESD linearization, providing infrastructure for remote ESD activation and deactivation. Also, old Guardian infrastructure has been removed from the model and MEDM screen, with new Guardian embedded mini control-panel replacing them in the QUAD Overview MEDM screen (as well as for other Suspensions too)

This closes-out WP#4915.
Images attached to this report
Comments related to this report
stuart.aston@LIGO.ORG - 08:14, Tuesday 28 October 2014 (14659)
We also updated the h1susauxex and h1susauxey models to provide analog and digital monitoring of the ESD Driver, as has been carried out at LLO (see LLO aLOG entry 12688).
Images attached to this comment
stuart.aston@LIGO.ORG - 09:17, Thursday 30 October 2014 (14726)
The updated local top level SUS QUAD and SUS AUX models have been committed to the svn:-

/opt/rtcds/userapps/release/sus/h1/models/
M        h1susetmx.mdl
M        h1susetmy.mdl
M        h1susitmx.mdl
M        h1susitmy.mdl
M        h1susauxex.mdl
M        h1susauxey.mdl
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 06:46, Tuesday 28 October 2014 (14656)
HWS work in LVEA

I've started some early morning HWS work in the LVEA.

H1 ISC (ISC)
daniel.hoak@LIGO.ORG - posted 23:33, Monday 27 October 2014 (14655)
Linear regression of DRMI signals

Inspired by Gabriele's fitting code for the nonstationary noise in DARM at L1 (for example, here), I tried performing a least-squares linear regression on the SPOP and SASY signals from Friday's long DRMI lock.  The motivation is to correlate the lower-frequency behavior of the DRMI to something that we can tune up in the ASC or SUS; this is distinct from Gabriele's code in that it doesn't consider the BLRMS in particular frequency bands (since I don't think we care too much about the noise in AS90 at 30Hz at the moment), and it looks over long timescales (which requires a lot of patience if you want to do it in DTT).

At the moment the code isn't as sophisticated as Gabriele's, for example it doesn't look at the square of the channels to find second-order couplings, and the channel ranking is sometimes a little suspicious.  But, it's in python.  :-)

For Friday's lock, the channel that best explains the time-evolution of ASAIR_B_RF90 is the BS optical lever in yaw; this is demonstrated in the first plot with 30 seconds of data.  The fit in that plot only includes a first-order polynomial fit of BS_M2_OLDAMP_IN1 to the data, it's not perfect but it catches the low-frequency motion pretty well.  (This may already be academic, since the BS OL was tuned over the weekend.)

The second plot is a 30-second fit using 24 channels in the regression; things that were included are the LSC error signals, the ASC error signals (AS_A_RF36_I_PIT_OUT_DQ and so on), the BS, PR3, and SR3 optical levers (again, BS Yaw was the winner), and some ASC DC signals.  The fit isn't great but it kind of captures the excursions.  The third plot is 300 seconds of data.

I also looked at POP18, this signal was correlated to the ASC-PRC1 error signal, REFL_A_RF9_I_{YAW,PIT}.  The fourth plot shows a fit to 30 seconds of data, the fifth plot is one hour of data.  Note that even though the fit coefficients are fixed values (not changing in time), the residuals are consistent over long timescales.

In all plots, the data we're fitting to is the black line, the fit result is the colored dashed line.  The x axis is in seconds.

Images attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 23:25, Monday 27 October 2014 - last comment - 12:23, Tuesday 28 October 2014(14654)
DRMI 3F

Alexa, Sheila, Rana, Evan, Dan, Kiwamu

Today we worked on getting DRMI locked on 3F.  It took us a while to get through the inital alingment sequence for various reasons, but once we did, and sorted out the WFS DC centering (Evan and Rana made some improvements to the AS A centering loop, Dan pointed out that the output matrix was mixed up), we were able to use the ASC to bring the DRMI to a reasonable build up (POP18 at 200 cnts). 

We then looked at the demod phase of our 3F sensors.  We tuned both 135 and 27 to miniminize the Q signal, first exciting PRM then SRM.

The best demod phases in degrees:

  PRM SRM
27 85.5 101.8
135 -25

65

We left 27 at 85.8 (we started at 84.8) and 135 at 65 (we started at 63).  We thendouble checked the relative gain between 3F and 1F signals, they are the same as previously, and we were able to transition to 3F.  (durring all of this DRMI was nice and stable, locking for up to an hour before we knocked it out with an excitation of some sort).

Since this we have made a few attempts to bring the arms in, we redid our entire inital alingment process, and after that realingned the DIFF and COMM beat notes (they haven't been realingned since the pico motor in HAM3 was moved last week).  We got about 3dBm in both beatnotes. 

Once we had the arms (off resonance by 1 kHz in green), we were able to lock DRMI quickly, but the build up was low.  When the ASC came on, it did improve the build up but as the build up got better, we started to mode hop.  This was repeated a few times.  By offsetting SRCL by -800 counts, we were able to avoid this mode hopping. 

We have now rung up the roll mode at 13 Hz on ETMY. 

Comments related to this report
kiwamu.izumi@LIGO.ORG - 12:23, Tuesday 28 October 2014 (14672)

some additional info for the roll mode:

(Developing the roll mode)

In a first half an hour or so, the roll mode was not excited and therefore we could close the ALS DIFF loop relatively easily. However at some point, we saw the roll mode slowly developing on a time scale of roughly 5 or 10 minutes which eventually killed the DIFF loop supposedly due to saturation in ETM DACs. After this incident, we were never able to stably lock the DIFF loop. The loop did not stay locked for a minute. I then waited for an hour while leaving ETMY untouched with a hope that the mode settles down in the meantime. But it did not. I still had a difficulty closing the loop.

(ETMY ESD is bad)

Before we started working on the DIFF loop, we briefly checked whether the ESDs are functional or not by injecting a line in pitch at 2.13 Hz. The ETMX ESD looked fine, but the ETMY ESD was pretty bad. Even though I shook the mirror vertically in pitch, oplev showed the motion which was mostly dominated by a yaw motion. The yaw motion was bigger than the pitch one by more than a factor of 5. Apparently the situation is different from how we used to be a couple of weeks ago (see alog 14415). I did not try exciting it in the yaw direction this time. I believe that the ESD is the cause for ringing up the roll mode.

(Some efforts did not help)

I tried two things in order to mitigate the issue. But neither worked.

  • Inserted a notch filter at 13 Hz in the L1 stage to avoid actuation at this particular frequency. I could have tried the same notch filter in the ESD stage, but I was afraied of loosing some phase margin at the UGF which must be as high as 10 Hz.
  • Reduced the DIFF loop UGF by a factor of 2 with a hope that the phase of the closed loop changes at 13 Hz and hence some change in the coupling to the roll mode.
H1 SUS
stuart.aston@LIGO.ORG - posted 17:57, Monday 27 October 2014 (14653)
ITMX & ITMY (QUAD) M0-M0 Phase 3b TFs - show rung up P & R modes
Initial attempts to take Phase 3b M0-M0 undamped TF acceptance measurements for both ITM (QUADs) this morning showed rung up P & R modes cross-coupling into other DOFs. Both ISI's were damped and FULLY_ISOLATED via Guardian. Measurements were as follows:-

- M0-M0 undamped results (2014-10-27_0800_H1SUSITMX_M0_ALL_TFs.pdf)
- M0-M0 undamped results (2014-10-27_0800_H1SUSITMY_M0_ALL_TFs.pdf)

Measurements from above have been compared with each other and the model (allquads_2014-10-27_H1SUSITMs_Doff_Phase3b_ALLM0_ZOOMED_TFs.pdf).

All data, scripts and plots have been committed to the sus svn as of this entry.

TFs will need to be repeated at the next opportunity.
Non-image files attached to this report
H1 SEI (CDS, DetChar)
krishna.venkateswara@LIGO.ORG - posted 19:14, Tuesday 21 October 2014 - last comment - 17:36, Monday 27 October 2014(14570)
ETMX Stage 1 sensor correction: Improved attempt

J. Kissel, J. Warner, K. Venkateswara

Based on Rich's and Jeff's SEI log entry 586 and 594, we made a second attempt at sensor correction on ETMX along X and Z on stage 1, which seems to be working better. To judge the performance I have plotted the stage 1 T240 output and also the Oplev Pitch and Yaw output. We used a slighlty modified version of Rich's sensor correction filter described in the above log.

To establish baseline, the first plot shows the Stage 1 T240_X motin (green), the ground STS (blue) and the tilt-subtracted ground super-sensor (red) with no sensor correction applied. I've also shown the coherence between some sensors and the Oplev motion. All degrees of freedom had Ryan's LLO blend filters.

The next file (SensCorrectOnBRSOff) shows the sensor correction turned on for X and Z on stage 1, but with normal gnd_STS, not the tilt-corrected super sensor.

The final file (SensCorrectOnBRSOn) shows the sensor correction with the tilt-subtracted super-sensor for X. Note that the ground motion (blue) is not the same during these data sets, but the relative differences between the lines are important.

Some comments:

1. Based on these plots, it looks like turning sensor correction On, even without tilt-subtraction, improves performance at 0.1-0.5 Hz by factors of 2-5. It's effect below 0.1 Hz is not clear - there may be small tilt amplification. Switching to the tilt-corrected super-sensor slightly improves performance below 0.1 Hz by factors of 2 ish. It is probable that we are limited by tilt-reinjection from the low X blend.

2. We are probably limited by the L4C sensor noise between 0.5 to 1 Hz. By improving the L4C blend, we may be able to get another factor of 2ish at these frequencies.

3. The Oplev motion doesnt show much improvement despite better X performance. The pitch is very sensitive to and probably limited by the RY blend.

 

Sensor correction for X and Z has been left on overnight, since it may help. It is easy to turn off from the ISI medm screen, if it is affecting performance.

edit: I added the Stage 1 Z performance to the plots. The sensor correction appears to improve z performance by ~10 at the microseism. But there may be more pitch motion at ~10 mHz. Not sure what is causing that.

Tomorrow, we will try HEPI sensor correction which may or may not be better.

edit: I have added another file also showing the Stage 1 RY motion (converted to displacement units), which shows good coherence with X motion confirming tilt-reinjection in X.

Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 20:06, Tuesday 21 October 2014 (14574)
J. Warner, K. Venkateswara, H. Paris, J. Kissel

Just to add some modeling sauce to Krishna's statements, I attach modeled performance plots comparing Rich's aggressive IIR sensor correction filter (from LHO aLOG 586) against Krishna and Jim's even more aggressive IIR sensor correction filter (from 14561). As Krishna says, we're getting better and better performance out of lowering the corner frequency of the sensor correction filter, made possible with the tilt-corrected ground sensor (despite his modest claims that it's not doing much).

Indeed, as we continue to improve the residual ground motion subtraction, we get more evidence as suspected from my modeled performance in SEI aLOG 594, that we are limited by L4C sensor noise from ~0.3 [Hz] to 1 [Hz] (and re-injected RY noise between 0.1 and 0.3 [Hz]). At this point, I have no definitive proof other than a similar shape of the 0.3 [Hz] to 1 [Hz] noise to the model and how it evolves with the latest changes in sensor correction -- but with the improved subtraction, its in some sense "exposing" the L4C noise by removing the limiting residual ground motion.
Check pages 1 through 5 for comparisons of the FIR filters, and modeled performance using the Ryan DeRosa blends.

Suspecting we can improve the L4C noise limitation by adjusting the T240 / L4C inertial sensor blend cross-over, I asked Hugo and and Jim for some information on how that cross-over is defined in the generic control scripts (knowing full well that Ryan would have chosen something different). In response, they pointed me to Brian Lantz's code for generating this crossover,
${SeiSVN}/seismic/Common/MatlabTools/blend_T240_L4C_111012.m
In this function, Brian uses the knowledge of the T240 and L4C sensor noises to "optimize" the cross-over. Assuming this cross-over is better, I
(1) Reconstructed the inertial sensor half of Ryan's psuedo-complementary blend filters by adding the existing T240 and L4C filters (grabbed directly from foton using readFilterzpk.m, since there's no matlab representation of these filters)
(2) Grabbed Brian's T240 and L4C complementary pair from blend_T240_L4C_111012.m
(3) Multiplied Brian's T240/L4C pair by Ryan's inertial sensor blend, such that total inertial sensor blend remains pseudo-complementary to Ryan's displacement sensor blend.
(4) Ran through the same model, comparing Ryan's inertial cross-over vs. Brian's inertial cross-over.

Blamo! -- if we are indeed limited by L4C noise (confirmed only by eye at this point) -- we can improve the noise from 0.3 to 1 [Hz] by another factor of a few. The filter comparison and modeled improvement is shown on pages 6-8 of the attached. 

We'll figure out how to actually implement this in foton tomorrow (gulp), so we can demonstrate this live.

Plots are and model are produced by
${SeiSVN}/seismic/BSC-ISI/Common/Sensor_Correction_Design_BSC_ISI/design_sensorcorrection_IIR_20141021.m
Non-image files attached to this comment
krishna.venkateswara@LIGO.ORG - 17:36, Monday 27 October 2014 (14652)

K. Venkateswara

I had a calibration error in the above plots. I've corrected it and attached the following files:

ST1SCoff.pdf  =  Stage 1 X sensor correction off.

ST1SCBRSoff.pdf  =  Stage 1 X sensor correction with just GND_STS, BRS not used.

ST1SCBRSon.pdf  =  Stage 1 X sensor correction with tilt-subtracted ground sensor.

SCCompare.pdf  =  Comparison of the three configurations. As ground motion was different during these measurements, this is not a good judge of performance below 0.1 Hz, but is useful above 0.1 Hz.

Non-image files attached to this comment
Displaying reports 62981-63000 of 77255.Go to page Start 3146 3147 3148 3149 3150 3151 3152 3153 3154 End