Displaying reports 66621-66640 of 83394.Go to page Start 3328 3329 3330 3331 3332 3333 3334 3335 3336 End
Reports until 16:31, Thursday 12 March 2015
H1 CAL (CAL)
richard.savage@LIGO.ORG - posted 16:31, Thursday 12 March 2015 (17234)
Xend Pcal work

VolkerQ, RickS

Today we went to Xend and aligned the AOM.

The transmitter module is #1x.

We adjusted the max RF power delivered to the AOM to be 1.3 W.

The total power transmitter through the AOM was 1.44 W; power in the diffracted beam 1.13 W -> 78% diffraction efficiency (about right).

We installed the Polarizing Beam Splitter Cube downstream of the AOM.

Installed NE01A-B filter in front of OFS PD.  -> 9.0 V at max power.

Adjusted for Max modulation.

Power incident on the OFS PD 1.34 mW.

Power incicent on the Tx PD 6.75 mW.

s-pol light reflected from PBSC 10-15 mW

Closed OFS loop with offset at 4.5 V.

Adjusted bias on AOM driver to minimize AOM drive with loop locked.

LHO VE
kyle.ryan@LIGO.ORG - posted 16:27, Thursday 12 March 2015 (17233)
BSC3 annulus on ion pump -> Shut down and removed pump cart
HAM1/HAM2 annulus system still needs pump cart assistance for a few more days
LHO VE
bubba.gateley@LIGO.ORG - posted 16:11, Thursday 12 March 2015 (17232)
Beam Tube Washing
Scott L. Ed P. Chris S.

The cleaning crew was able to clean 49 meters from X-1-5 double doors towards the mid station.
Beam tube pressures continually monitored by control room operator during cleaning operations. 
H1 General
travis.sadecki@LIGO.ORG - posted 16:00, Thursday 12 March 2015 (17228)
OPS Shift Summary

Morning meeting:

Hugh working on isolation loops

SUS acceptance TFs

3IFO moving parts from LVEA to midstations

 

Time in PST

08:19 Richard and Fil to both end stations installing shutters

08:48 JoeD to LVEA checking fire extinguishers

08:51 Elli and Nutsinee to EY working on HWS

09:15 Mitchell to West Bay LVEA

09:15 Jodi/Gary to West Bay

09:24 Corey and Keita to ISCT1 for optics check, Corey to squeezer bay thereafter

09:30 Betsy to West Bay

09:32 Richard and Fil done at EX, Richard to Air Handler room EX and EY

09:53 Peter and Ed to H2 PSL enclosure

10:22 Mitch out

10:30 Jodi/Gary out

10:33 Mitch to West Bay

10:39 Richard to EY

10:40 Fil and Manny to MY

11:21 Richard done at EY

11:42 Elli and Nutsinee done at EY, going to EX

12:28 Peter out

12:42 Karen to Mid Y

12:42 Cris to Mid X

13:38 Karen out

13:45 Elli and Nutsinee back from EY

14:08 Fil to EX for shutter modification

14:08 Peter and Ed to H2 PSL enclosure

14:17 Elli and Nutsinee to EX

14:39 Fil back from EX

14:44 Rick to EX for PCal work

15:17 Daniel done at EY

15:56 Ed and Peter out

H1 SUS
betsy.weaver@LIGO.ORG - posted 15:53, Thursday 12 March 2015 - last comment - 13:40, Friday 13 March 2015(17229)
ETMy SDF cleanup leads to ETMy ESD cleanup

Due to all of the latest commissioning of ETMY, the SDF had accumulated 40+ differences.  With Jeff's help we remedied numerous line items via making the ETMy ESD banks look like the ETMx ones.  This cleared out Kiwamu's settings leftover from earlier measurements.  I've also moved the ESD calibration filters from the 4 ETMY L3 ESD OUTPUT banks to the L3 LOCKING BIAS bank to bring it in line with the ETMx settings.  I've edited the burt ETMy safe.snap to capture some of the other commissioning work.  THere are now only 20 SDF diffs which I will continue to track down.

Comments related to this report
betsy.weaver@LIGO.ORG - 15:54, Thursday 12 March 2015 (17230)

Screen snapshots before ETMy cleanup:

Images attached to this comment
betsy.weaver@LIGO.ORG - 15:55, Thursday 12 March 2015 (17231)

ETMy screen snapshots now:

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 18:11, Thursday 12 March 2015 (17238)
To specify what Betsy means when she says "This cleared out Kiwamu's settings leftover from earlier measurements," we cleared out the EFF_CHARGE values in ESD linearization block, and changed the FORCE COEFFICIENT to match ETMX, at -124518.4 (see LHO aLOG 16798 and 16843). 

This force coefficient is -124518.4 [ct] (i.e. raw DAC counts, NOT LOCK drive counts), representative of the bias voltage of 9.5 [V] (referenced to [V] output from the DAC, NOT on the ESD), or an bias voltage on the ESD of 380 [V]. As the commissioning vanguard prefers DAC voltage, we've entered 9.5 "[V]" into the LOCK_INBIAS, and calibrated FM1 accordingly. This is exactly how EX is configured, as Betsy says.
kiwamu.izumi@LIGO.ORG - 13:40, Friday 13 March 2015 (17252)

Betsy, Jeff,

Thanks for cleaning up the mess and I am sorry that I did not alog the details. Regarding this configuration, I actually liked the ETMY configuration than ETMX because (1) the effective charge can be calibrated in Volts at the electrodes and (2) the bias voltage can be specified on the medm screen as the actual voltage at the electrode e.g. +380 V. We should decide which calibration convention we want to use. I will talk to you guys about this once I come back.

H1 ISC
daniel.sigg@LIGO.ORG - posted 15:35, Thursday 12 March 2015 (17227)
Shutter installed in EX/EY main green beam

New uniblitz shutters (VS35) are installed in the main green path of ISCTEX and ISCTEY. Jumpers were set to VS35. In EY the A channel seems broken and we are using the B channel for now. Procedure for making cables and setting jumpers have been added to the dcc and the wiki.

Removed the ALS_REFL_B PDs in both end stations. For EX the software limit needs to be removed, otherwise the PDH autolocker barks.

H1 General (CDS, DetChar, SUS)
ryan.fisher@LIGO.ORG - posted 14:30, Thursday 12 March 2015 - last comment - 19:48, Friday 13 March 2015(17224)
ODC Work Wednesday and Thursday Morning
Ryan F., TJ Massinger, Stefan

We edited the following models in the local copy of userapps without committing them.  We tested that all of these compiled successfully (and emailed CDS about some RCG bugs found when using GoTo and From parts in the models).  Screenshots demonstrating the changes are attached.  

We added a proper ODC channel (mostly still placeholders with no inputs or logic) for the following models to replace the current placeholders:
 h1pemey  
 h1pemex
 h1caley
 h1calex
 h1iscex
 h1iscey
  these last two require the changes to sys/common/models/ODC_MASTER_PARTS_V2.mdl
 h1alsex
 h1alsey

We also edited the h1omc model that was installed Tuesday to add checks on DCPD_A,B and PZT2_MON_AC error signals.
 h1omc
  requires changes to omc/common/models/omc.mdl

All of these models should be ready to be make-installed, restarted and committed to the SVN during the next maintenance period.

We also edited PSL_STATUS.adl locally to fix a white box (changed H1:PSL-ODC_CHANNEL_OUTPUT to H1:PSL-ODC_CHANNEL_OUTMON)

We created a new MEDM screen for ASC_ODC.adl and fixed some errors in the LSC_ODC.adl created by Duncan M.  These screens are not yet linked to any other MEDM screens.

We also committed a new safe.snap file for h1odcmaster.
Images attached to this report
Comments related to this report
ryan.fisher@LIGO.ORG - 19:48, Friday 13 March 2015 (17261)DetChar, IOO
I made some additional changes to the staged OMC changes:  These affect omc.mdl and omclsc.mdl.  The changes add EPICs outputs to display intermediate steps in the ODC_SUBSTATE calculations.  The added outputs are shown in the attached screenshots.  These changes have not been committed to SVN, but the h1omc.mdl model has been tested to successfully compile.  
Images attached to this comment
H1 GRD
jameson.rollins@LIGO.ORG - posted 11:19, Thursday 12 March 2015 - last comment - 14:40, Thursday 12 March 2015(17223)
purged USERAPPS/guardian directory from USERAPPS checkout

The top-level USERAPPS/guardian directory was purged from the CDS_USER_APPS SVN last week, as it was no longer used (it had been used only by the old now-defunct guardian implementation).  I did an "update" on this directory in our local checkout (/opt/rtcds/userapps/release), which purged most things from the directory.  I then removed the accumulated cruft and purged the entire directory.

Comments related to this report
jameson.rollins@LIGO.ORG - 14:40, Thursday 12 March 2015 (17225)

The USERAPPS/guardian directory has been UNPURGED.

It turns out that at least the ISI "command scripts" were using the CaTools.pm perl module that was located at USERAPPS/guardian/CaTools.pm, and were therefore broken after the purge of the guardian directory.  I therefore checked out the directory from the version directly before the purge (r9933) (see below).  This got the ISI "comman scripts" working again.

I had sent multiple emails about this directory being purged, and received no response.  We need to figure out what is being used from here and transfer them somewhere else to be more properly maintained.

jameson.rollins@operator1:/opt/rtcds/userapps/release 0$ svn co -r9932  https://redoubt.ligo-wa.caltech.edu/svn/cds_user_apps/trunk/guardian
A    guardian/test.pl
A    guardian/simulator.pl
A    guardian/GuardTools.pm
A    guardian/guardManagerMakeMEDM
A    guardian/runManager
A    guardian/guardManagerMEDM
A    guardian/makeGuardian.pl
A    guardian/generate_alarms.pl
A    guardian/guardMakeMEDM
A    guardian/makeBurtPatch.pl
A    guardian/caswitch
A    guardian/guardExec
A    guardian/documentation
A    guardian/documentation/DirectoryStructure.graffle
A    guardian/documentation/DirectoryStructure.pdf
A    guardian/documentation/verify_TEMPLATE
A    guardian/documentation/ligodoc.cls
A    guardian/documentation/medm_FAIL.png
A    guardian/documentation/medm_BURT.png
A    guardian/documentation/guardian.pdf
A    guardian/documentation/verify_TRANSIT_TEMPLATE
A    guardian/documentation/goto_TEMPLATE
A    guardian/documentation/ISC_Common.png
A    guardian/documentation/medm_TIMEOUT.png
A    guardian/documentation/itmx_scripts.png
A    guardian/documentation/medm_GOOD.png
A    guardian/documentation/transit_TEMPLATE
A    guardian/documentation/Guard.png
A    guardian/documentation/guard_medm.png
A    guardian/documentation/guardian.tex
A    guardian/userHost.substitutions
A    guardian/makeBurtPatchSimple.pl
A    guardian/makeAllGuardians.pl
A    guardian/generateChannelList
A    guardian/CaTools.pm
A    guardian/runGuardian
A    guardian/test
A    guardian/test/gcd
A    guardian/test/restoreSnapshot.pl
A    guardian/test/watchAlarm.pl
A    guardian/test/watchValue.pl
A    guardian/test/defaultChannelList.req
A    guardian/test/cleanUp.pl
A    guardian/test/gxd
A    guardian/test/logs
A    guardian/test/logs/guardian.txt
A    guardian/test/readSnapshot.pl
A    guardian/test/makeSnapshot.pl
A    guardian/test/guardian.txt
A    guardian/test/caStep.pl
A    guardian/test/BURT.txt
A    guardian/test/gpd
A    guardian/test/autoBurt.req
A    guardian/python
A    guardian/python/README
A    guardian/script_templates
A    guardian/script_templates/transit_TEMPLATE
A    guardian/script_templates/verify_TEMPLATE
A    guardian/script_templates/goto_TEMPLATE
A    guardian/script_templates/verify_TRANSIT_TEMPLATE
A    guardian/gxd
A    guardian/dbGuardian.db
Checked out revision 9932.
jameson.rollins@operator1:/opt/rtcds/userapps/release 0$ 
H1 SEI
jim.warner@LIGO.ORG - posted 11:17, Thursday 12 March 2015 - last comment - 19:56, Thursday 12 March 2015(17222)
Change blend on BSC St2

After staring at the data I posted yesterday with JeffK, he suggested we try blending lower on the ISI in RZ. I saw that the blend filter we use on the HAM's was installed already on ETMX, so I decided to take advantage of this morning's non-commissioning period to make some measurements. The results are, um, good. See attached plots. Blue (st1) and green (st2) are the nominal configuration, red(st1) and brown(st2) are the different blend in the first plot, which is calibrated to rad/rthz. Second plot shows the CPS (low pass) part of the two blends, blue is the nominal, red is the new blend. I'm only attaching the RZ data, but every other degree of freedom shows improvement, which I only kind of understand, considering the ground motion was worse after I changed blends.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 19:56, Thursday 12 March 2015 (17241)
J. Kissel, J. Warner

During the process of exploring this better noise performance with ST2 RZ loops, he found that both the ETMs had been mistakenly running the high-blend-frequency, T750mHz, Z and RZ blend filters. This is why the performance in Z and RZ shown in LHO aLOG 17197 has a similar frequency dependence around 1 [Hz] as the 750 [mHz] blend that Jim shows in his second attachment, and why the performance in RZ isn't as good as expected. Recall that in this frequency region, assuming a single-stage-like system, if we're not limited by measurement noise (because we're using the GS13s to assess the performance), then we're limited by the ST2 CPS filtered by the displacement sensor blend (see T1300645, G1400134, or P1000103).

If one only saw Jim first plot, one might switch all BSC ISI ST2 platforms to the HAM, 01_28 blends. However 
(a) we later compared the 01_28 RZ performance (in brown) against the GS13 sensor noise, and the awesome double-notched out performance at 1 [Hz] is below the sensor noise -- the classic deceptive flaw of looking at an uncompensated in-loop sensor, 
(b) the HAM 01_28 blends have a really broad-band gain peaking of (a max of) ~1.5 between 30 and 500 [mHz], which translates to an order of magnitude (or more) more displacement below 0.1 [Hz] as shown in Jim's plot (we compared the ground motion in the two plots, and they're comparable, so it's not that there was an earthquake or high winds),
and 
(c) Jim ran out of time, so he hasn't added the 01_28 filters to every BSC yet.
In regards to (b), why does a displacement sensor filter gain peaking of 1.5 result in a factor 10 amplification and not just 1,5? As the good Dr. DeRosa says in SEI aLOG 645, 
"You always get MORE motion than the predicted gain peaking / amplification (below the microseism) because the tilt decoupling isn't perfect."

In lieu of switching everyone's Z and RZ to the 01_28 blends, Jim switched all of the platforms to the T250mHz blends. See attached for a comparison of all three options.

I think that the T250mHz will be the best compromise, because 
(a) The gain peaking is limited to a smaller region of 30 to 250 [mHz], and only maxes out at ~1.3,
(b) The notches in the HAM 01_28 blends are just digging us deep into the GS13 sensor noise floor. We will probably hit the GS13 noise floor with the T250mHz blends as well.

We'll check the performance overnight, especially with an *aligned* optical lever, and re-evaluate.
Non-image files attached to this comment
H1 GRD (SUS)
jameson.rollins@LIGO.ORG - posted 11:00, Thursday 12 March 2015 (17208)
Improvements to SUS guardian

I've made some improvements, and done a bit of cleanup, to the SUS guardian code.

Some of this was to clarify the SUS/ISC interface, after discussion with the ISC team.

To the main SUS.py (H1 is using a separate copy of this in sus/h1/guardian/SUS.py, so we should eventually merge these changes into the common SUS.py):

I then cleaned up the various ALIGNED_TO_PD* states that have been added to align optics to various baffle PDs.

All code has been committed, and SUS guardians have been restarted to pull in these changes.

H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 10:48, Thursday 12 March 2015 - last comment - 11:31, Thursday 12 March 2015(17219)
ETM HWS computers need updated .bashrc files

The ETM HWS computers currently have outdated .bashrc files that specify aliases and paths. I'm updating these.

 

Comments related to this report
aidan.brooks@LIGO.ORG - 11:31, Thursday 12 March 2015 (17220)

Some specifics:

H1HWSEY

The .bashrc file is the same as that on H1HWSMSR with the following modifications:

  1. Copied the old .bashrc to .bashrc.old.20150312
  2. Changed the environment variable name OPTIC_0 to ETMY_HWS
  3. Commented out OPTIC_1=ITMY_HWS environment variable
  4. Commented out PREFIX1=$IFO:TCS-$OPTIC1 environment variable
  5. Added 'stream_image_EY' alias: '/opt/Hartmann_Sensor_SVN/release/bin/stream_image_Y/distrib/stream_image_Y' (this file is called 'stream_image_Y' but that's just a name, the important thing is that it points to the first port on the capture card
  6. Commented out Run_HWS_ITMY and Run_HWS_ITMX aliases
  7. Added an alias: Run_HWS_H1ETMY='/opt/HWS/Run_HWS_Y/distrib/Run_HWS_Y'

The libraries for the MATLAB Runtime Environment are now properly identified in the path. I confirmed that stream_image_EY runs and displays the image from the camera. See the second attached image.

 

H1HWSEX

The .bashrc file is the same as that on H1HWSMSR with the following modifications:

  1. Copied the old .bashrc to .bashrc.old.20150312
  2. Changed the environment variable name OPTIC_0 to ETMX_HWS
  3. Commented out OPTIC_1=ITMY_HWS environment variable
  4. Commented out PREFIX1=$IFO:TCS-$OPTIC1 environment variable
  5. Added 'stream_image_EX' alias: '/opt/Hartmann_Sensor_SVN/release/bin/stream_image_Y/distrib/stream_image_Y' (this file is called 'stream_image_Y' but that's just a name, the important thing is that it points to the first port on the capture card)
  6. Commented out Run_HWS_ITMY and Run_HWS_ITMX aliases
  7. Added an alias: Run_HWS_H1ETMX='/opt/HWS/Run_HWS_Y/distrib/Run_HWS_Y' (this is not a mistake - the Run_HWS_Y code points to the first port on the capture card)

The libraries for the MATLAB Runtime Environment are now properly identified in the path. I confirmed that stream_image_EX runs and displays the image from the camera. See the first attached image.

Additionally on both:

  • I added the directory /home/controls/archived_images
  • I added the symbolic link to the latest version of the HWS code: /opt/HWS -> /opt/Hartmann_Sensor_SVN/release/HWS_v1.1.8/
  • I added the symbolic link to the framearchive directory: /home/controls/framearchive/ -> /data/ETM/

Note that when the HWS code stores data, it does so in the environment variable named FRAME_ARCHIVE_DIR which is defined by: export FRAME_ARCHIVE_DIR=/home/controls/framearchive/$HOSTNAME 

So, the files will be stored, ultimately in the following way:

HWS Data Directory
ITMX /data/ITM/h1hwsmsr/ITMX/
ITMY /data/ITM/h1hwsmsr/ITMY/
ETMX /data/ETM/h1hwsex/ETMX/
ETMY /data/ETM/h1hwsey/ETMY/
Images attached to this comment
H1 SUS
travis.sadecki@LIGO.ORG - posted 10:37, Thursday 12 March 2015 (17218)
SUS Driftmon updated

With all SUSes in their aligned states, I have updated the Driftmon threshold values.  This was mostly to address OM and RM values that have been ignored in the past.  I trended their alignments in Dataviewer and found them to be in their nominal state this morning.  The script to update these thresholds updates ALL SUSes, so the new values will reflect the latest in the constantly changing 'good' alignment of the IFO.

H1 SEI
hugh.radkins@LIGO.ORG - posted 10:32, Thursday 12 March 2015 (17217)
SEI SDFs Updated--almost all zero--HAM6 & BS GS13s Gains different than all the others

All SEI GS13s are now set in High Analog Gain without Whitening except HAM6 and BS (Stage2.)  This standard High Gain configuration is with both FM4 & 5 Off in the GS13 INF module, H1:ISI-HAM5_GS13INF_H1 for example.

For HAM6, because of the shutter hit to the ISI, the GS13s are run with Low Analog Gain without Whitening.  This configuration is with FM4 On and FM5 Off.

For BS, because of the hit to the ISI when the MICH acquires, we run the GS13s in the standard low Gain configuration of Analog Low Gain and Whitening.  This has both FM4 & 5 On.

These configurations are set in SDF.

H1 PSL (DetChar, PSL)
jason.oberling@LIGO.ORG - posted 10:29, Thursday 12 March 2015 (17216)
PSL DBB/ISS Scans

Here are the PSL DBB/ISS scans for this week.  No significant change from last week.

Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 01:05, Thursday 12 March 2015 - last comment - 14:45, Thursday 12 March 2015(17209)
Locking tonight

Today we have spent most of the day trying to lock. We have locked, but only after some diifictulties. 

Comments related to this report
stefan.ballmer@LIGO.ORG - 02:05, Thursday 12 March 2015 (17211)
As Sheila mentioned we had problems engaging the ASC in DRMI.

In particular, with today's initial alignment, for some reason, both POB_A and AS_C see pointing numbers between 0.2 and 0.46. When we engage the PRC1 loop (which uses POB_A), the control signal very quickly saturates the bottom stage of PRM, leading to a lock loss. The top mass relief loops are not fast enough this engagement. To a lesser extent the same is true for the SRC2 loop.

For now I implemented a Guardian section that copies the error signal into the offset (with opposite sign), engages all loops at nominal bandwidth, and starts a 5min slow offset ramp back to the nominal point.

We should do several things to mitigate this, probably in this order:
- 1) Find an initial alignment procedure that puts us closer to where we want to be, making the WFS turn-on transient less violent.
- 2) Commission a much higher bandwidth relief servo to the top mass.
- 2) Implement a saturable integrator in the ASC control filter bank - like we have in the tidal servo. This would make engaging the WFS trivial, and guarantee to avoid saturation.

stefan.ballmer@LIGO.ORG - 14:45, Thursday 12 March 2015 (17226)
I also added limiters to the PRC1_P, PRC1_Y, SRC2_P and SRC2_Y filter modules:

- PRC1: 1e4 cts limit. This corresponds to a drive of
   - 53168cts to PRM M3 coils
   -  8741cts to PR2 M3 coils
   - 24221cts to SRM M3 coils
   -  3457cts to SR2 M3 coils
   -   809cts to IM4 coils

- SCR2: 1e3cts limit. This corresponds to a drive of
   - 40368cts to SRM M3 coils
   -  5762cts to SM2 M3 coils

This should under all circumstances leave us enough range for length control on the M3 coils.


In addition I added limiters to all involved to top stages angular controls:
H1:SUS-BS_M1_LOCK_P_LIMIT = 500
H1:SUS-BS_M1_LOCK_Y_LIMIT = 500
H1:SUS-IM4_M1_LOCK_P_LIMIT = 1000
H1:SUS-IM4_M1_LOCK_Y_LIMIT = 1000
H1:SUS-PR2_M1_LOCK_P_LIMIT = 1000
H1:SUS-PR2_M1_LOCK_Y_LIMIT = 1000
H1:SUS-PR3_M1_LOCK_P_LIMIT = 500
H1:SUS-PR3_M1_LOCK_Y_LIMIT = 500
H1:SUS-PRM_M1_LOCK_P_LIMIT = 1000
H1:SUS-PRM_M1_LOCK_Y_LIMIT = 1000
H1:SUS-SR2_M1_LOCK_P_LIMIT = 1000
H1:SUS-SR2_M1_LOCK_Y_LIMIT = 1000
H1:SUS-SR3_M1_LOCK_P_LIMIT = 500
H1:SUS-SR3_M1_LOCK_Y_LIMIT = 500
H1:SUS-SRM_M1_LOCK_P_LIMIT = 1000
H1:SUS-SRM_M1_LOCK_Y_LIMIT = 1000

They are large enough that we shoul never run into them under normal operations, but small enough to avoid "astronomical" kicks on lock-loss. 
H1 ISC
alexan.staley@LIGO.ORG - posted 20:30, Wednesday 11 March 2015 - last comment - 11:11, Thursday 12 March 2015(17207)
PRELIMINARY NB Model Report

Chris, Alexa

Loop Gains

The first two attachments show the OLTFs of the various length DOFs. In these plots, the model is the blue trace and the red trace is measured data. The DARM TF agrees pretty well. The PRCL and SRCL loops appear to have a gain missing. The CARM and MICH model loops are not correct. 

Noise Budget Overview (***Rough Estimates***)

The fourth attachment depicts the noise budget produced by the model for the 8W lock on March 04, 2015 15:30 UTC. This roughly agrees with the conclusions Evan has made with his NB (LHO#17101). At high frequencies we are dominated by shot noise. At around 300 Hz we suspect intensity noise (or maybe beam jitter), as Gabriele noticed. From 30-100 Hz we are limited by DAC noise. And below 10 Hz we see some angular fluctuations. 

Noise Budget Details

Images attached to this report
Comments related to this report
christopher.wipf@LIGO.ORG - 01:41, Thursday 12 March 2015 (17210)

The modeled MICH loop gain is looking better now. There were some aggressive BSFM plant inversion filters that weren't being linearized accurately in Simulink. This was fixed by using numerical TFs for them. The shape is still off above 60 Hz, but that's probably due to the filter change from alog 17148.

I put in sign flips as needed to ensure an even number of them are present in each OLTF. There remains some 10 dB of mystery gain to be hunted for in the DRMI loops.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 11:11, Thursday 12 March 2015 (17221)ISC, TCS

The larger coupling of intensity noise is something that was seen in Livingston as well (13767) and turned out ot be due to the ITM lenses (14091 and 14736). 

Displaying reports 66621-66640 of 83394.Go to page Start 3328 3329 3330 3331 3332 3333 3334 3335 3336 End