Displaying reports 54101-54120 of 84760.Go to page Start 2702 2703 2704 2705 2706 2707 2708 2709 2710 End
Reports until 16:32, Tuesday 15 November 2016
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 16:32, Tuesday 15 November 2016 (31517)
CDS maintenance summary, Tuesday 15th November 2016

WP6314 h1oaf0 stability

Richard, Fil, Daniel, Jim, Dave:

h1oaf0 has been stable since 12:46 Mon 14th PST, no further work was done on this system

WP6312 adding new MD5 DAQ epics channels to the DAQ

Dave:

A new H1EDCU_DAQ.ini file was generated and installed during a DAQ restart at 12:11PST.

WP6315 updated frame-cpp on frame writers

Jim, Jonathan, Dave

The new code (which has been running on h1fw2 for the past week) was installed on h1fw0. Jonathan has test code to look at frames written by fw0 (new) and fw1 (old) to check they are identical. We will test for several days before the decision to upgrade fw1 is made.

WP6318 bug fix in h1susauxb123 model

Jeff:

New code for h1susauxb123.mdl to fix a bug. No DAQ restart required.

WP6324 Extend Remote Access controls to 24/7

Jonathan:

The RACCESS system is now operational 24/7 for the duration of ER10 and O2.

Testing new Hardware Injection data injestion

Keith, Dave, Jim:

New configurations of h1hwinj1 and h1guardian0 permit hw-injection users on h1hwinj1 to svn check-out the injection waveforms and schedules such that the guardian INJ_TRANS node can perform these injections. We had a minor local modification to the INJ_TRANS.py file which was removed and the guardian node code was updated to the latest SVN version. We discovered a slight discrepancy between the code and the schedule file which was resolved. System is ready for injection team to test.

H1 CDS
david.barker@LIGO.ORG - posted 16:18, Tuesday 15 November 2016 (31515)
default file access permissions were different on the newer debian workstations

It was found that the default UMASK on the newer Debian workstations were different from the Ubuntu12/14 machines (022 on debian, 002 on ubuntu). This meant that the default file permissions for new files on debian were 644 (rw-r--r--) and therefore not group writable. We are changing the default umask for user-type accounts to be 002 on all machines (via  pam_umask), and I have appended a line to everyone's .bashrc file to set "umask 002" as an OS-agnostic method of ensuring correct permissions.

If you want to check if your account is setup correctly, first check your umask setting by  typing the umask command

david.barker@zotws2: umask
0002

As a further check, create a new file and verify the correct permissions (rw-rw-r--)

david.barker@zotws2: touch testfile
david.barker@zotws2: ls -al testfile
-rw-rw-r-- 1 david.barker controls 0 Nov 15 16:15 testfile
 

and finally verify you belong to the controls group as your secondary group

david.barker@zotws2: groups
david.barker controls
 

H1 CDS (ISC, VE)
filiberto.clara@LIGO.ORG - posted 16:13, Tuesday 15 November 2016 (31509)
CDS - Tuesday Actitvies

WP 6323

The following items were removed from temporary power supplies and connected to 24V DC rack power:

1. Baffle Photodiode Amplifier Units (ITMX/ITMY)
2. RGA unit next to HAM4
3. EtherCAT hub - CU1128

WP 6292

A safety system controls chassis was installed at each end station. As of now, units are not powered on.

H1 CDS
david.barker@LIGO.ORG - posted 16:08, Tuesday 15 November 2016 (31513)
Control Room Operators are now controlling remote CDS login at all times for the duration of ER10 and O2

WP6324 Fred, Michael, Vern, Keita, Jim, Dave, Jonathan

Now we are in ER10, all CDS remote access logins are controlled by the operators at all times. Prior to this, operator permissions were only required during business hours (8am-4pm Mon-Fri) as the system was being tested.

For Yubikey holders, if you wish to log into LHO CDS remotely you will need to contact the control room operator (phone 509 372 8202) and request an access-permit to be opened for you. During your discussion with the operator, please be sure to cover why access is required, which internal machines you expect to need and the duration of your work. The operator and run management will determine if your task requires a full work-permit. Most access-permits will have a maximum duration of a week.

On a sysadmin note, on cdsssh I have opened sshd_config up to all Yubikey owners now that this is not the principal access control filter.

LHO General
thomas.shaffer@LIGO.ORG - posted 16:01, Tuesday 15 November 2016 (31511)
Ops Day Shift Summary

TITLE: 11/15 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Maintenance Day. Nothing too crazy today, maintenance actually ended a bit after noon and we were able to almost lock at nominal. Commissioners are currently investigating some SRC1 issues that have been preventing us from having >30min locks.
LOG:
        See attached

Non-image files attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 15:59, Tuesday 15 November 2016 (31512)
Opened CP7's exhaust check-valve bypass-valve
I believe that all CP exhaust check-valve bypass-valves are now open?
LHO VE
kyle.ryan@LIGO.ORG - posted 14:57, Tuesday 15 November 2016 (31506)
Prepped PT180 for future bake out (ran West Crane)
Isolated PT180 while removing 2.75"CFF-NW40 adapter and installing turbo pump in its place.  Helium leak tested new joint and also the turbo vent valve.  Leaving the turbo isolated and under rough vacuum.  Decoupled fore line from turbo exhaust isolation valve.  Wrapped hardware in Aluminum foil but didn't have the preferred assortment of heat tape lengths to complete the job before maintenance time expired ;  Will still need 1 hour notice before baking can begin as the fore line will need to be connected and the correct length heat tapes still need to be added.

Why bake PT180 hardware?

PT180, PT170 and PT140 are new-to-us Inficon BPG402 Bayard-Alpert wide range gauges that we installed this past spring.  As mentioned by others in previous entries, these three have a positive slope over time which is not reflected in our older cold-cathode gauges which sample the same vacuum volume(s) but at different locations,  Degassing of the new gauge's filaments haven't helped.  The theory now is that this gauge behavior is the result of "wet" components used in the gauges assemblies [(2) new uhv valves, (1) new 1 1/2" CFF Tee and (1) new BPG402 gauge.  

Attached is the graph showing the pressure accumulation, we hope to repeat this accumulation following the bake for comparison:
Non-image files attached to this report
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 13:52, Tuesday 15 November 2016 - last comment - 15:11, Tuesday 15 November 2016(31504)
New Sensing Funciton Data Set; Calibration Lines turned Back ON
J. Kissel

Travis was able to grab a PCAL2DARM/DARMOLGTF sensing function transfer function set last night (see LHO aLOG 31485) -- for convenience I reiterate the location here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/
PCAL/2016-11-15_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml
DARMOLGTFs/2016-11-15_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml
and attach a screen shot. The data has been committed to the CalSVN.

It looks like the DARM cavity pole was low during this lock stretch, but otherwise the optical gain is ~5% low as we've seen in the last of measurement at 30 [W].

We'll get one more of these at 30 [w] for processing and get on with the analysis. Apologies for the delay in analyzing this data -- I'm really struggling for person power beyond me, given the current poor duty cycle and my needs to be the recovery team as well (Kiwamu's in Canada, Evan's helping out LLO).
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:11, Tuesday 15 November 2016 (31508)
I've re-read Travis's entry (LHO aLOG 31485) and found were not running SRC1 loops during the lock stretch in which this measurement was taken. The suspicion is that SRC1 alignment loops are going unstable, so turning them off would improve the duty cycle. That investigation is on-going. 
However, with the SRC1 degree of freedom uncontrolled, as we have found from 50 [W] experience, the DARM coupled cavity pole frequency drops and moves around much more, among other things. That's why we see the increased frequency-dependent discrepancy in the PCAL 2 DELTAL_EXTERNAL transfer function.

Unfortunately -- assuming we can figure out what's wrong with the SRC loops and fix it -- this means measurement won't be representative of the O2 configuration. We'll do what we can to salvage it, but ideally, we'd like to take it again.

In Summary:
SRC1 P&Y Loops OFF
Input Power Mean: 30.7 [W]
Images attached to this comment
H1 SUS
betsy.weaver@LIGO.ORG - posted 13:20, Tuesday 15 November 2016 - last comment - 13:39, Tuesday 15 November 2016(31501)
Weekly ~TUES ETM charge measurements taken

Due to PCAL and OPLEV work at End Y this morning, I was only able to take the SUS ETMX charge measurements.  Attached are plots of both ETMX and ETMY since they are kind of like salt and pepper shakers and are always together, however only the ETMX has added points.

 

We have not made any sign changes in the last 20 days, yet there is a small turn over in the ETMX long trend apparent in the data points from today.  Not sure why this is...

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 13:39, Tuesday 15 November 2016 (31502)

Shiela's bias change in full lock (written in Guardian) started on ~Nov 4th (alog 31172) which is the likely cause of the charge turn over this week.  This automated bias change takes the nominal +1.000 gain and switches it to -1.000 (see attached trends of the last 20 days).

Images attached to this comment
H1 TCS
betsy.weaver@LIGO.ORG - posted 13:04, Tuesday 15 November 2016 - last comment - 13:41, Tuesday 15 November 2016(31500)
TCSY Chiller filling status

For the record, we have not added any water to the TCSY chiller for a week, and the indicator only shows a small drop in the level during this week.  Looks like we finally have the system topped off.

Comments related to this report
betsy.weaver@LIGO.ORG - 13:41, Tuesday 15 November 2016 (31503)

In total, we have added 15.6L since Sept 30, 2016.  Just prior to the start of these cumulative additions, there was a 6L fill (alog 30041) at the time of the dry-chiller event.  So, we've addede a total of 21.6L to the full circulatory system, noted for next time!

H1 CDS (GRD, INJ)
jeffrey.kissel@LIGO.ORG - posted 12:48, Tuesday 15 November 2016 (31497)
CAL-CS INJ Channels RE-Re-Not-Monitored
J. Kissel

I've found several hardware injection channels AGAIN monitored in the SDF system. Why do these channels keep getting monitored??

This has happened two weeks ago (LHO aLOG 31141), after originally not monitoring them several moons ago (LHO aLOG 21154).
Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 12:43, Tuesday 15 November 2016 - last comment - 13:01, Tuesday 15 November 2016(31496)
exttrig alerts of GRB and Supernovae is operational

The EXTTRIG MEDM screen was apparently not working correctly on first glance. The last query time was updating correctly, but the last event was from Nov 6th and there have been many events since that time.

Upon investigation, it turns out that the system is behaving correctly. Here is the sequence:

the epics channels exttrig uses are served by the h1calcs model. This runs on h1oaf0, which has been restarted many time over the past week. Each time the h1calcs model is restarted, two things happen:

  1. the EXTTRIG epics channels are restored from the safe.snap file, which has the Nov 6th event data recorded
  2. the EXTTRIG script crashes (due to lost connection with its EPICS channels) and is restarted by monit. On restart, if no events have occured in the past 10 hours, the event info is not updated and the Nov 6th data stands.

For the record, here is the startup sequence of the code on h1fescript0:

process is controlled by monit. Its file is /etc/monit/conf.d/monit_ext_alert.  It monitors a process whose PID is stored in the file /var/log/ext_alert/ext_alert.pid.

If the process needs to be started/restarted, monit executes (as root) the file /etc/init.d/ext_alert. This in turn, using the start-stop-daemon runs the script /home/exttrig/run_ext_alert.sh, and this runs the script /opt/rtcds/userapps/release/cal/common/scripts/ext_alert.py with the appropriate arguments.

We are investigating this morning's Tuesday test events were not  recorded. These are T-events in gracedb with a label of H1OPS. The run_ext_alert.sh script was not calling ext_alert.py with the '--test' argument to query for test events. We turned on the gracedb-query of test events in /home/exttrig/run_ext_alert.sh and got this morning's test event on startup. Duncan pointed out that there are many non-ops test events per day so this will generate many false positives.

Comments related to this report
david.barker@LIGO.ORG - 13:01, Tuesday 15 November 2016 (31499)

On Duncan's recommendation we turned off the reporting of test events.

By the way, it looks like today's SNEWS external test event at 09:00PST did not get posted to Gracedb?

H1 AOS (SEI, SUS)
edmond.merilh@LIGO.ORG - posted 10:32, Tuesday 15 November 2016 - last comment - 14:04, Tuesday 15 November 2016(31491)
ETMY OpLev centered

...as per WP6316. ≈ -1.6 µrad offset in YAW due to 'kick' when the positioner is turned on/off. Multiple attempts to offset made no difference.

Comments related to this report
jason.oberling@LIGO.ORG - 10:35, Tuesday 15 November 2016 (31492)

I also centered the BS oplev, using a different picomotor controller from the EE shop (see LHO alog 31333 for details on BS oplev centering issues).  This closes WP 6316.

edmond.merilh@LIGO.ORG - 14:04, Tuesday 15 November 2016 (31505)

I noticed that YAW had changed to ≈2.8µrad after I returned to the corner. PCal work began immediately after I left the alignment. I noticed the change in position and re-centered after the PCal work was completed. During the PCal work, the PCal shutter was open and closed so that I could observe any action on the alignment. There didn't seem to be any affect with the shutter in either of it's positions. After a brief period of time it seems that PIT has drifted to ≈ -1.8. This seems to be an inherent issue thoughout most of the OpLev system.

H1 CAL (ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 02:00, Saturday 12 November 2016 - last comment - 15:51, Tuesday 15 November 2016(31433)
Third Round of ER10 Calibration Measurements Complete -- Now at 30 W IFO Input Power
J. Kissel

Getting one more round of calibration reference measurements for ER10/O2. The decision was made to run ER10 / O2 at 30 [W] (as opposed to the 25 [W] we'd been running all week), so I've made sure to get another round of transfer functions. 

In addition I've made a bunch more probing measurements of the L1 / UIM stage above 100 Hz, so that we can create an empirical model of the UIM actuator expanding on what was done in LHO aLOG 24917. Again, here, it's not that the UIM plays a big role in the response function at these frequencies, it's that the deviations at high frequency limit our ability to obtain a clean estimate of the actuation strength. Templates all listed below, analysis will come later.

Sensing Function Data:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/DARMOLGTFs/
2016-11-12_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/PCAL/
2016-11-12_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml
We may take a few more of these, just because the IFO input power has changed. Yes, a 25 [W] to 30 [W] is a small change in optical gain, but we want to be sure if detuning comes into play by 30 [W], and also if the cavity pole changes. I've also been told to expect further DC alignment changes before the weekend's out which may also play a role in these kinds of sensing function parameter changes.

Actuation Function Data:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-12/
2016-11-12_H1SUSETMY_L1_iEXC2DARM.xml
2016-11-12_H1SUSETMY_L1_PCAL2DARM.xml
2016-11-12_H1SUSETMY_L2_iEXC2DARM.xml
2016-11-12_H1SUSETMY_L2_PCAL2DARM.xml
2016-11-12_H1SUSETMY_L3_iEXC2DARM.xml
2016-11-12_H1SUSETMY_L3_PCAL2DARM.xml
This should complete the three suites of measurements we usually do for the actuators. Given the preliminary analysis from Kiwamu (LHO aLOG 31427), I don't see a need for more data here.

Also, I gathered some undisturbed time in between the sensing function measurements and actuation function measurements between 2016-11-12 06:08 UTC and 06:30 UTC so these can be used to convert / compare back against 25 [W] lock stretches. Maybe. Recall the previous two attempts at these measurements to bordered by lock losses caused by the OAF computer crashing, so there may not be a lot of time then against which to compare.

Detailed High-frequency L1/ UIM Actuation Function Data:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-12/
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_100-250Hz.xml
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_250-350Hz.xml
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_300-500Hz.xml
2016-11-12_L1_iEXC2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_100-250Hz.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_250-350Hz.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_300-500Hz.xml
2016-11-12_L1_PCAL2DARM_HFDynamicsTest_90-400Hz_SweptSine.xml
The *not* labeled SweptSine are broad band injections. The idea is to export the data, filter it by coherence (0.95 should be good enough) and then take the ratio. The broad band TFs are better for characterizing the resonances. The hope is we can stitch all of these data sets together to form one sweeping meta-transfer function that completely maps out the UIM, in detail, out to ~500 Hz. 
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:51, Tuesday 15 November 2016 (31510)
I add a few details relevant to the optical plant regarding the lock stretch in which the sensing function measurements were taken:
SRC1 loops (P&Y) are ON
Input Power Mean: 29.5 [W]
Images attached to this comment
H1 SUS (DetChar, ISC, Lockloss, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 17:29, Thursday 10 November 2016 - last comment - 15:35, Tuesday 15 November 2016(31404)
Investigating H1 SUS ITMY's Excessive Ring Down Time
J. Kissel, H. Radkins

I'm continuing to investigate why ITMY's pitch mode (at 0.55 Hz) continues to ring much longer than the other QUAD's upon lockloss (see and example attached as 2016-11-08_2151UTC_ITMY_Oplev_Bad_TimeSeries.png). 

Today, I grabbed the open loop gain transfer functions of the M0 DAMP L, the M0 DAMP P, and the L2 OLDAMP P local damping loops on both H1 SUS ETMY and H1 SUS ITMY, to show that the identical settings are producing identical results for QUADs that are essentially physically identical. 

Indeed, the open loop gain transfer functions of both suspensions look the same.

We don't have too many lock loss data points yet since I made the change, but I did discover that the digital output limiter of all QUAD's L2 OLDAMP P bank were different (one as low as 5000, and one as high as 500000, and ITMY was in the middle at 10000). So, I've made all the limits the same, at 40000, in hopes that the problem is with the square-wave that ITMY gets sent during a lock loss. This change is NOT accepted in the SDF, because I'm unsure if it matters yet.

Still unclear what is going on here...

Hugh's taking a look at these same optical lever signals after every lock loss for the past month. Preliminary results show that this behavior is intermittent, but has definitely gotten worse in the past week or two. We hope he can trace this back to some event like a maintenance day to better try to address the problem.
Images attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 15:35, Tuesday 15 November 2016 (31507)Lockloss, SUS

All of the BSCs have AC coupled loops installed on St2 for RX/RY (somewhat detailed in my post 28907 for ETMX), maybe it would be helpful to try turning this on for ITMY? The GS-13s see a lot of this motion. Attached trend has both ITMs oplevs and GS-13 pitch for each ISI ST2. ITMY St2 clearly gets more kick, just like the ITMY optic. Second attached plot are some spectra of  the ITMY GS13s, red is just before this lockloss and pink is during the lock loss.  Green is the ST2 RX motion during a quiet time this morning, showing where the ac couple loop gets suppression. Most of the motion comes from .46 hz SUS resonance, and the AC loop doesn't do anything there, but the 2 and 3.5 hz motion should be suppressed some. The attached PDF shows some design plots for the ITMY loops from my work on this in August.

Images attached to this comment
Non-image files attached to this comment
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 16:48, Thursday 10 November 2016 - last comment - 16:39, Tuesday 15 November 2016(31403)
Second Round of ER10 Calibration Measurements Complete
J. Kissel

Though it's been a struggle between all of the H1OAF computer crashing, I've managed to squeak out one more round of calibration measurements today. The data's location is below; analysis to come.

The data lives here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/
(1a) DARMOLGTFs/2016-11-10_H1_DARM_OLGTF_4to1200Hz_fasttemplate.xml
(1b) PCAL/2016-11-10_H1_PCAL2DARMTF_4to1200Hz_fasttemplate.xml

(2)
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L1_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L1_PCAL2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L2_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L2_PCAL2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L3_iEXC2DARM.xml
FullIFOActuatorTFs/2016-11-10/2016-11-10_H1SUSETMY_L3_PCAL2DARM.xml
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:39, Tuesday 15 November 2016 (31518)
SRC1 loops (P&Y) are ON
Input Power Mean: 24.8 [W]
Images attached to this comment
H1 ISC
sheila.dwyer@LIGO.ORG - posted 00:35, Sunday 16 October 2016 - last comment - 13:18, Tuesday 15 November 2016(30549)
Another look at frequency noise

Evan, Sheila, Jenne

The overall message: looking at refl control and IMC control signals leads to different conculsion about our frequency noise, but we can slightly improve our DARM noise at high frequencies by engaging an additional boost in the IMC. The sensing noise should be large enough to see on the DBB, so it would be helpful to get the DBB running again.  

IMC control signal suggests a lot of excess IMC sensing noise:

Yesterday afternoon Evan and I looked again at the frequency noise as seen in IMC control signal.  The attached screenshot shows the IMCF spectrum with and without CARM locked.  

We think that when the mode cleaner is locked the IMC control signal should be the sum of:

Once CARM is locked, it will be the sum of:

Between 100Hz and 1kHz, the noise stays in the same with and without CARM locked, so this noise should be either laser noise or ref cav sensor noise imposed by the laser.  The noise which goes away when we lock CARM should be IMC sensing noise or VCO noise.  Since there isn't any frequency where locking CARM increases the noise in IMCF, this measurement gives us an upper limit on the REFL9 sensing noise.  

We think that the IMC shot noise should be abot 15uHz/rt Hz, the ref cav shot noise should be about 0.4mHz/rt Hz, and the shot noise on refl 9 should be about 5uHz/rt Hz at 1kHz, increasing as f.  The second attached png shows the measurements for IMC with and without the mode cleaner locked, the estimated levels of shot noise we would expect to see in there and in maroon an estimate of the where the IMC loop noise should appear when CARM is locked.  If you believe that and make a projection to the light blue and maroon traces are IMC sensor noise and make a projection to Watts on refl 9, then to DARM using the measurements posted here, I predict a noise in DARM of around 1-2e-21 m/rt Hz at 100 Hz.  There are several things that don't quite make sense, the projection doesn't agree with the measured REFL9 spectrum or Evan's estimate of the REFL 9 spectrum using the refl control signal (those things don't agree with each other either).  

The refl control signal tells a different story:

Tonight, Jenne and I tried engaging boosts in both the IMC and CARM.  The third attached screenshot shows that the refl control signal was reduced when we added a boost to the IMC, both peaks at around 1 kHz and the higher frequency noise.  This means that at these frequencies the frequency noise is not limited by sensing noise from REFL or the IMC, which contradicts the conclusion above.  Not suprisingly, it looks like the peak at 280Hz is sensing noise from the IMC or REFL.  In any case, we saw a small improvement in DARM at high frequencies by using the IMC boost, so we should probably make this a regular part of our locking sequence.  Boosting the CARM loop (using the 40Hz/4kHz filter) didn't change anything in DARM.  

Edit:

I've done a quick calibration of the REFL control signal by wathcing the IMC PDH signal at the point where the REFL AO path gets summed in.  We have about 2.4Vpp there (at 2Watts, with 16 dB of gain), using the IMC cavity pole of 8812Hz, Alexa's quick PDH calibration in 7054, -24 dB AO path gain, and 0.00061Volts/count, REFL control has about 0.1413 Hz/count.  I've added this to the front end filter for REFL control. Now we can plot the IMC and refl control signals together.  At 1kHz, we expect a supression of about 200 without the IMC boost on, so the noise at 1kHz makes sense as laser frequency noise or ref cav sensing noise. 

Images attached to this report
Non-image files attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 13:18, Tuesday 15 November 2016 (31498)

Daniel and I had another look at the calibration of REFL control, and sorted out some factors of 2. 

Just to be clear:  I measured the IMC ODH signal at out1 with 2 Watts into the IMC and the loop disengaged.  We get 2.4V pp for the error signal, measured after 15dB IN1 gain. The attached matlab script has a simple model of the IMC loop without taking into account the FSS gain, with the gain at the point where the AO signal is added is 3.67kHz/Volt. However, when we transition to analog CARM, we reduce the fast gain by 6dB and add 6dB gain to the in1 gain slider, so in full lock the calibration is 1.86kHz/Voltat the summation point.  This will have to be updated if we change the IMC IN1 gain in full lock other than scaling it for input power changes. 

The calibration is now in the refl control filter:

anti whitening:  Two zeros at 100Hz, two poles at 10 Hz, DC gain of -6dB.  This previously had a DC gain of 0dB, which was not correct because the input is differential. 

cnts2Volts: 6.1e-4

-24dB of AO gain (this will have to be updated if we change this)

imcV2Hz: 1836 Hz/V at the point where the IMC error signal is summed with REFL control.  (probably too many digits here)

Non-image files attached to this comment
Displaying reports 54101-54120 of 84760.Go to page Start 2702 2703 2704 2705 2706 2707 2708 2709 2710 End