Displaying reports 65041-65060 of 83002.Go to page Start 3249 3250 3251 3252 3253 3254 3255 3256 3257 End
Reports until 02:15, Friday 15 May 2015
H1 ISC
stefan.ballmer@LIGO.ORG - posted 02:15, Friday 15 May 2015 - last comment - 05:59, Saturday 16 May 2015(18442)
23W 57Mpc
Sheila, Evan, Stefan


- Reduced the whitening gain on both AS 36 ASC diodes. The new value is 24dB. We increase the input matrix values from 1 to 2 to compensate (for MICH and SRC1, i.e. the SRM loop).
- We tried to phase the AS_A_36 quadrants by wiggling SRM in yaw and pitch, maximizing the I signal. Not sure how meaningful that was though, because the actual signal we ended up using was Q.
- We switched the the sensor for SRC1_YAW (SRM) to 0.3*AS_A_36_Q + 0.3*AS_B_36I. This signal clearly reacted to our mysterious SRC cavity drifts, and had zero offset at the good locking point.
- We increased the power to 23W. This is the maximum power currently available. With this new SRM yaw sensor the 23W was very stable.
- The DARM offset was 14pm (or 1e-5 cts).
- This gave us a recycling gain of 38.
- Measured the open loop gain and verified the calibration.
- This configuration was stable for 1h.
- We took SRCL noise injections at: 8:46:15UTC and 8:59:40UTC (SRCL cut-off filter off and on)
- We took MICH noise injections at: 8:52:15UTC and 8:55:40UTC (SRCL cut-off filter on and off)
- Pushed the intent bit at 9:06:30 UTC.

- The inspiral range seems quite remarkably flat at 57 Mpc. A stron indication that we are now purley electronics noise limited at low frequencies.

To do tomorrow:
- Explore DARM offset: the new OMC code is ready to install, and will allow on-the-fly OMC offset tuning.
- Add the new ASC INMATRIX to Guardian.
- Add the new DARM offset to Guardian.
- Generate noise budget.
Comments related to this report
sheila.dwyer@LIGO.ORG - 02:21, Friday 15 May 2015 (18443)CAL, ISC

Attached is a new spectrum, before and after screenshots of the AS A 36 WFS phases, and 3 OLG measurements made at 3 different input powers.

Images attached to this comment
Non-image files attached to this comment
gabriela.gonzalez@LIGO.ORG - 04:36, Friday 15 May 2015 (18444)
Great progress, congratulations!!
evan.hall@LIGO.ORG - 04:51, Friday 15 May 2015 (18445)

I will take a closer look at the noise budget over the weekend, but it seems (roughly) that above 20 Hz we are currently limited by DAC→ESD noise and quantum noise. As usual, there is some uncertainty in coupling strength of the ESD to DARM, which may explain the discrepancy in the plot from 20 Hz to 100 Hz.

Non-image files attached to this comment
peter.fritschel@LIGO.ORG - 06:38, Friday 15 May 2015 (18446)

This is fantastic -- perfect timing for the low noise Electro-Static Driver installation next week!

albert.lazzarini@LIGO.ORG - 06:54, Friday 15 May 2015 (18447)
Excellent news! Well done. 
rainer.weiss@LIGO.ORG - 07:09, Friday 15 May 2015 (18448)
Looks like discharging and lower noise driver will do some good. Nice going.
david.reitze@LIGO.ORG - 12:00, Friday 15 May 2015 (18457)
Truly great progress. Nice work, LHO commissioning team!
fred.raab@LIGO.ORG - 14:33, Friday 15 May 2015 (18460)
Beautiful! Nice and stable as well! I was not able to change my slides for the invited LIGO talk at APS Northwest Section Meeting, but I did announce your success. Great timing too.
richard.oram@LIGO.ORG - 05:59, Saturday 16 May 2015 (18474)
Well done all at LHO. That's great progress.
H1 SUS (ISC, SUS)
sheila.dwyer@LIGO.ORG - posted 23:13, Thursday 14 May 2015 (18441)
some violin mode damping is restored

Tonight Dan went through some of the old violin mode damping settings, we have had all violin mode damping disabled for the past several weeks in the guardian since we improved the recycling gain.  Dan found that the old settings work for 6 of the modes, ITMY mode 3,5 and 6, ETMY mode 5, and ITMX mode 3 and 6. For ITMY mode 4 we need a sign flip in the gain.  All of the ones that Dan checked I put back into the gaurdian, some of which now have lower gain than before.  I also added ETMY roll mode damping back in the guardian.  

H1 SUS
sheila.dwyer@LIGO.ORG - posted 20:37, Thursday 14 May 2015 - last comment - 15:13, Saturday 16 May 2015(18440)
Summary of bounce and roll frequencies
 
  Bounce Roll  
ETMY 9.730 Hz 13.816 Hz 14854
ETMX 9.77    
ITMY  9.8135 13.934Hz 18395
ITMX   9.8469    15400

the remaining roll modes are at 13.89 and 13.98 Hz, but we don't know which is from ETMX and which is from ITMX

Comments related to this report
evan.hall@LIGO.ORG - 15:13, Saturday 16 May 2015 (18485)

The ITMY bounce mode is 9.83 Hz.

H1 ISC (CAL)
kiwamu.izumi@LIGO.ORG - posted 18:15, Thursday 14 May 2015 (18436)
A first result from cavity pole tracker

We had set up a DARM cavity pole tracker last night (alog 18401). The plot below shows a first result from the cavity pole tracker which showed very interesting results.

Punchlines

 


[Tracker setup]

We set up a lockin oscillator in the LSC front end model at 322.1 Hz (alog 18401). The excitation amplitude was set to 2 counts at the LSC DARM output. Through the LSC output matrix it excites ETMX and ETMY with outmatrix elements of +1 and -1 respectively. Since we use one ETM at a time for controlling DARM, this setup excites just one ETM by 2 counts. The audio demod phase was initially set to 0 deg so that we can double-check the phase rotation later on. The demodulation cos and sin gains are set to 1. In the I and Q demodulators, I put a 260 dB gain such that the outputs are human-readable. The low-passes are 0.1 Hz 4th order butterworth currently. The notch has been on all the time (alog 18401) so that the excitation is insensitive to the control loop.

[Calibration of the audio demodulation phase]

According to the DARM loop model, I was expecting a phase rotation of about +80 deg including the known time delay of 219 usec at the excitation frequency of 322.1 Hz. By the way, 219 usec is the total delay of the DARM open loop. However, for some reason, I measured the phase rotation to be -128.4 [deg]. The math I got this number is  phi = atan(measured Q phase / measured I phase). So something is not right. Due to this unknown phase rotation error, I ended up calibrating the audio demod phase using the information that the cavity pole was at 355 Hz at a particular time (alog 18420).

In the post-process, I rotated the demod phase by multiplying a rotation matrix to the I and Q signals such that the demodulated signals has the effect only from the DARM optical plant, or in other words, I subtracted the phase rotation which is not from the DARM plant. I had to rotate them by -86.2 deg in order to get 355 Hz for the data points at around May-15-2015 9:21:34 UTC which is the time when Jeff estimated the cavity pole to be 355 Hz. The advantage of doing this rotation business is that is makes the math easier. In this condition, in-phase signal should be

(in-phase) = G / (1 + (omega / omega_0)^2),

where G, omega and omega_0 are the optical gain, excitation frequency and cavity pole frequency, respectively. Similiarly, the Q phase is also easy;

(q-phase) = - (omega/omega_0) * G / (1 + (omega / omega_0)^2).

Taking the ratio of the two demodulated signal, one can obtain a clean quantity;

(in-phase / q-phase) =  - omega_0 / omega.

This essentially corresponds to doing some atan calculation to derive the phase angle. From this quantity, I computed the DARM cavity pole rfequency as a functin of time as shown in the above plot. I attach a second trend of some relevant channels in the same period.

Also, I changed the audio demod phase in the realtime system to -86.2 deg such that I don't have to do the same post data-massage.

Images attached to this report
H1 ISC
daniel.hoak@LIGO.ORG - posted 17:31, Thursday 14 May 2015 - last comment - 18:21, Thursday 14 May 2015(18437)
OMC READOUT path changed in common OMC model

Stefan, Dan

We have edited the common OMC model to enable the READOUT path that performs dynamic normalization as a function of DARM offset and input power.  The changes have been committed to the SVN.  The goal here is to allow changes to input power and DARM offset after we have switched to DC readout, so the power ramp-up and experiments to the DARM offset can be performed after we handoff to the OMC.

Essentially everything in the OMC-READOUT block has been modified, although the overall calculations still match those in T0900023 (except for corrections for the math errors found therein).  The changes are:

A screengrab of the new model block is attached.

We also edited h1omc.mdl to enable the power normalization inputs.  There are two power-related inputs to the linked omc.mdl library from h1omc.mdl, "TRX_IN" and "TRY_IN".  These inputs were grounded.  Instead of using the normalized arm powers (which is what we think was intended), we have routed the requested PSL power (PSL-POWER_SCALE, although this is called LSC-OMC_POWER_REQUEST in the top level of the model) to both inputs.  This channel was already available in the model, the arm powers weren't, we didn't want to add any IPC sender/receiver pairs today.

Models were rebuilt, restarted, and the DAQ was restarted as described by Dave.

One thing we forgot to add are some additional epics readbacks in between terms of the calculation, as sanity checks that everything is acting as we expect.  We'll edit the model later.

Images attached to this report
Comments related to this report
daniel.hoak@LIGO.ORG - 18:21, Thursday 14 May 2015 (18438)

As it turns out, Stefan discovered that the times-times-divide operator in the model was actually a times-times-times.  So, we've edited the model again to replace this part with a two-step multiply and divide.  (Is the times-times-divide used in any other models?  Does it work for them?)

Stung by model parts not working as we expect, we have also inserted a number of EPICS readbacks throughout the calculation.  A screenshot of the updates is attached.

The new model has been saved and compiled, to check for errors, but it has not been restarted.  A DAQ restart will be required.

Images attached to this comment
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 16:21, Thursday 14 May 2015 (18434)
OMC and DAQ restarts

Dan, Jim, Dave

Two OMC model changes were made. Both required a DAQ restart.

The first DAQ restart proceeded normally, the second did not complete. h1dc0 reported a bad master file in its log files. In fact it appears that around this time h1dc0 attempted to start three times, each time creating a running configuration with either missing or corrupted master files.

We logged into h1dc0 as root and restarted the daqd process manually. This time the master file was read correctly and the DAQ restarted normally. We are unsure of the original problem, possibly an NFS issue between h1dc0 and h1boot?

Note that on both DAQ startups today, the broadcaster was the last to start. Normally it is the first to start.

LHO General
corey.gray@LIGO.ORG - posted 16:00, Thursday 14 May 2015 - last comment - 15:33, Wednesday 20 May 2015(18428)
Ops DAY Summary

Day's Activities

H1 Operator Locking Notes For Today

Came in to find the Arms not locking on GREEN in the morning.  Alignment was OK, but when I tweaked up alignment and engaged WFS & this would drop the arm powers.  With Daniel & Ellie's help (& Evan's alog), saw that there were issues with the Pit/Yaw M0 Lock Filters for the ITMs.  So Inputs were disabled, Cleared Histories & turned off FM2 (+20dB) & FM3 ("empty") filters for ITMx & ITMy.  After this we were able to take the arms to "Locked_No_Slow", and then walked through the rest of Initial Alignment.

When we went to locking the full ifo, the first steps is "Check IR" via ISC Lock Guardian Node.  We had nice ALS arm powers, but when we got to the "Find IR" state, the arms would break lock and the MC would break lock (not sure of the order though).  I believe Sheila caught the issue here (she noticed Tidal issues and then some filters being turned OFF on the ETMs).

Comments related to this report
corey.gray@LIGO.ORG - 15:33, Wednesday 20 May 2015 (18536)

Additional Locking Notes I took last Thursday (perhaps moot by now?).

For Locking: 

  • Take H1 to "Resonance" via Guardian.
  • Once at Resonance, pause & observe AS_AIR video.
  • If there is a ~0.5Hz oscillation of two spots moving around, one could wait out oscillation or try tweaking PR2.
  • Don't stay in Resonance state too long because thermal effects can degrade alignment.  So you will want to engage ASC fairly soon.
H1 ISC (CAL, ISC)
gabriele.vajente@LIGO.ORG - posted 15:30, Thursday 14 May 2015 - last comment - 16:37, Thursday 14 May 2015(18432)
DARM pole frequency vs SRM tilt

Following up what reported by Jeff about the DARM pole frequency, the attached plot shows a simulation of the change in the pole frequency when the SRM is misligned. To move the pole down to 290 Hz we would need a misalignment of about 30 microradians. It seems a large misalignment to me, but at least in simulation it's not affecting much the error signals or the power buildups.

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 16:37, Thursday 14 May 2015 (18435)

Last night, engaging the error point offset gave about 8 µrad of tilt in SRM yaw. Calibration of SRM M1 yaw is 2.7 ct of drive per microradian, according to the alignment sliders.

Non-image files attached to this comment
H1 CDS
james.batch@LIGO.ORG - posted 15:27, Thursday 14 May 2015 (18431)
Changed Matlab license server for Scientific Linux 6 and Ubuntu14 workstations
The license server for Matlab has been changed to the CDS network license server for Scientific Linux 6 and Ubuntu 14.04 workstations.  This should really only affect people working with the hardware injection computers, making more licenses available.
H1 CDS (DAQ, DCS)
david.barker@LIGO.ORG - posted 14:40, Thursday 14 May 2015 (18429)
h1fw0 unstable, h1ldasgw0 rebooted

Dan, Greg, Jim, Dave

Perhaps coincidentally, but since the LDAS tape robot was relocated late Tuesday h1fw0 has been unstable. Its log files suggest a slow disk system is causing the problems.

We were given permission to reboot the h1ldasgw0 Solaris QFS/NFS server, and Dan took the opportunity to upgrade this Solaris system (last upgrade 9/11/2014).

The only potential problem with unmounting the disk system from h1nds0 is with the SYS_DIAG Guardian node. It is performing regular NDS requests for the past 30 seconds of BRS data to determine if the data is not flatlined. Since this data should be served by the daqd process from memory, and not the nds process from disk, we are confident this will not cause any problems for the node.

Procedure is:

h1fw0: stop monit, stop daqd process (via telnet), un-mount h1ldasgw0

h1nds0: stop monit, stop nds process (via init.d script), un-mount h1ldasgw0

h1ldasgw0: perform upgrades, reboot, share QFS via NFS

h1fw0: mount h1ldasgw0, start monit (which in turn starts daqd)

h1nds0: mount h1ldasgw0, start nds process via init.d script, start monit.

This has not helped, h1fw0 has restarted twice since this was done.

H1 TCS (AOS, TCS)
nutsinee.kijbunchoo@LIGO.ORG - posted 12:21, Thursday 14 May 2015 - last comment - 08:50, Friday 15 May 2015(18427)
Return SLED beam centered on HWSX

Elli, Nutsinee

The return SLED beam is now centered on the ITMX HWS. The QPD1 sum reads 1.71 (mean) and the QPD2 sum reads 1.32 (mean). Green light was resonates in both arms during the time of the measurement.

The current position of the HWSX lower periscope mirror is X: -286 Y: -927 and the current position of the HWSX upper periscope mirror is X: 300 Y: -300.

The Hartmann plate is off at the moment.

Images attached to this report
Comments related to this report
aidan.brooks@LIGO.ORG - 08:50, Friday 15 May 2015 (18450)

The X- and Y- positions on detectors 1 and 2 are shown in the attached plots. Was there a change in internal alignment or a change in the green power in the last 60s?

Images attached to this comment
H1 PSL (DetChar, PSL)
jason.oberling@LIGO.ORG - posted 10:43, Thursday 14 May 2015 (18425)
PSL DBB/ISS Scans

Attached are this week's PSL DBB/ISS scans.

Non-image files attached to this report
H1 CAL (DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 10:09, Thursday 14 May 2015 (18420)
DARM Coupled Cavity Pole -- No Clear Correlation with IFO Parameters
J. Kissel

I've compared many different IFO parameters which we suspected might contribute to the change in DARM Coupled Cavity Pole (DCCP) Frequency against the most recent 11 measurements,
Meas Num    Date                          DCCP Freq
    [ 2]    'Apr 02 2015 08:34:20 UTC'    [320]
    [ 3]    'Apr 06 2015 23:45:13 UTC'    [320]
    [ 4]    'Apr 13 2015 04:15:43 UTC'    [290]
    [ 5]    'Apr 13 2015 06:49:40 UTC'    [290]
    [ 6]    'Apr 15 2015 07:53:56 UTC'    [290]
    [ 7]    'May 01 2015 18:52:59 UTC'    [355]
    [ 8]    'May 02 2015 20:35:54 UTC'    [355]
    [ 9]    'May 06 2015 11:37:31 UTC'    [270]
    [10]    'May 07 2015 07:08:12 UTC'    [260]
    [11]    'May 11 2015 15:50:43 UTC'    [303]
    [12]    'May 14 2015 09:21:34 UTC'    [355] << -- This one is new, it was put under my pillow by the DCCP fairies last night
And they're summarized in the following attached plots. 

The message -- still no clear correlation between any of these parameters and the DCCP frequency.

Details:
For each measurement data, I gather the following collections of EPICS channels for the duration of the measurement, and take the mean to represent the value of the parameter during the measurement:
_RCGs.pdf : 
Transmitted ARM Power (for carrier recycling gain), POPAIR 18 I (for 9[MHz] power recycling gain), POPAIR 90 I (for 45 [MHz] sideband SRC "reflectivity"), ASAIR 90 I (for 45 [MHz] sideband "DRMI" recycling gain)
_ITMCTRL.pdf  : 
ITM Alignment control (Using the DSOFT and CSOFT filter banks) and ITM optical levers
_Oplev(Pit/Yaw).pdf  : 
Pitch and Yaw of all other core opic optical levers
_IFOPWR.pdf  : 
Pre-PSL-periscope IOO BBPD (for power into the IMC), MC2TRANS (for MC1 to MC2 intracavity power), IM4TRANS (for power into PRM)
_FF.pdf  : 
MICH and SRCL FF subtraction gains and output (to indicate whether they were in use)
_TCS.pdf  : 
ETMX Ring Heater Power, ITMX CO2 Laser POWER
Virtually all of these parameters were stable over the course of them measurement, so I'm comfortable with using the mean as representative. The only which were not are the optical levers (no surprise), so I show them with an error bar that is the std deviation over the duration. For all of these, the error bar is much smaller than the variation between measurements, so I still think they're a good representation of the alignment. Not great, thought -- this drift could still be a result of the optical lever drifting and not the actual optic alignment change, so take it with a grain of salt.

The remaining attachments are the time series of data during each measurement, so you can just for yourself if you believe that taking the mean is representative.

Specific parameters that *don't* apparently have a correlation that we expected to reveal something:
POP90 -- (look at _RCGs.pdf, bottom left panel) 
Remember, our intuition says this is a proxy for the effective "reflectivity" of the SRC, and because the SRC is a signal extraction cavity (i.e. over coupled), the lest reflection the better. The three measurements where we had a highest cavity pole frequency at 355 [Hz] (two during the minirun, and one last night) had a POP90 value of 16.02, 16, and 12.28 [uw/W], which is inconsistent, BUT, one could argue that the other measurements where the cavity pole was lower, POP90 was higher -- except for measurement 11 which is slightly lower than 16, and has a DCCP frequency of 303. Further, when the DCCP frequency stays the same, the POP90 value is varying -- take the first three measurements -- DCCP frequency of 320, 320, and 290 [Hz] against POP90 value of 16.64, 18.26, and 21.11 [uw/W]. Not a consistent story here.

Carrier Power Recycling Gain -- (look at _RCGs.pdf, middle left panel) 
This one's a little confusing because Elli/Sheila has renormalized the end-station QPDs to the red single arm power at measurement 9, and the power recycling gain improved two measurements before they did so (see measurements 7 and 8). However, it's still clear where the consistent improvement in recycling gain happened -- between measurement 6 and 7 (the renormalization only results in an ~5% change in reported value for those two measurements, as opposed to the 25% increase in gain). All this taken into account, the "high" recycling gain period sees the entire range of DCCP frequencies from 355 to as low as 260 [Hz].

ITM pitch and Yaw -- (look at _ITMCTRL.pdf) 
No clear correlation between DCCP frequency and the state of ITM alignment. In fact -- as I mentioned the other day, this gift from the DCCP fairies (measurement 12) is the only measurement in which the ITMs were under control, and the alignment to which the DSOFT and CSOFT loops steered the optic which acheieved a high recycling gain seems no more remarkable than when it was high during the mini-run.

PR3/SR3 alignment -- (look at _Oplev(Pit/Yaw).pdf) 
I know the scale is a little rough here (the optical levers were probably centered between measurement 2 and 3), but I've zoomed in the .png, and I still don;'t see a correlation.

Input power -- (look at _IFOPWR.pdf)
no correlation here: consistent power for the past 4 measurements, in consistent DCCP frequency.

MICH/SRCL -- (look at _FF.pdf)
there is a distinct similarity here -- whenever the SRCL FF is OFF, the DCCP is high. I'm not sure what drives the commissioning vanguard to have this on or off, but maybe there's a clue there, given that we're having so much trouble with the stationarity of the SRCL to DARM coupling as well.

TCS -- (look at _TCS.pdf)
no correlation here, but last night's measurement did have a significant change in ITMX CO2 laser power... I'll have to have a conversation with the team about this, 'cause I don't see anything in the log about it

So ... yeah ... no strong conclusions in any direction ... yet. Maybe folks can make better sense of the data than I can...
Images attached to this report
Non-image files attached to this report
H1 PSL (DetChar, PSL)
jason.oberling@LIGO.ORG - posted 09:56, Thursday 14 May 2015 (18424)
PSL Weekly Report - Past 10 Days Trends

Images attached to this report
H1 ISC
evan.hall@LIGO.ORG - posted 06:59, Thursday 14 May 2015 - last comment - 16:09, Thursday 14 May 2015(18419)
SRM WFS loop offset

Stefan, Evan

Summary

Adding an offset to the error point of the ASB36I→SRM yaw loop reduces the SRCL→DARM coupling by 10 dB. It seemingly has the added benefit of fixing the slow drift in POP90.

Details

SRM yaw loop offsets

After several days of trying to do SRCL feedforward on a moving target, we decided to try attacking the SRCL→DARM coupling itself.

We started by applying offsets to the dETM loops, since Gabriele's simulation seemed to indicate that this could cause an increase in the high-frequency coupling. We applied offsets of several hundred counts (both signs) to dETM pitch and yaw, and then injected broadband noise in SRCL. We saw a reshaping of the noise (see attachments), but no overall improvement.

Then we moved on to offsets in the SRM WFS yaw loop. Here we saw a more promising improvement with a positive offset at the error point (see attachment). In the end we found that an offset of 2100 ct works best in terms of reducing the coupling at high frequencies. This also seems to coincide with minimal power in POP90.

POP90 stabilization

With this yaw offset engaged, it seems that the drift in POP90 mostly went away when the SRM yaw offset was engaged around 09:14:00 (attachment). There is still some drifting, but the timescale is much longer. Perhaps we are closer to optimal coupling of the 45 MHz sidebands into the SRC. This particular lock lasted for about 2.5 hours (it broke for unrelated reasons) and showed no sign of the POP90/ASB36I instability that we've seen this past week.

DARM offset and calibration

For some additional reduction in SRCL coupling, we tried locking with a smaller DARM offset (14 pm, not 7 pm as I said before) and then updated the calibration (FM10 in the sensing inversion of CAL-CS). However, I have reverted these changes. This means that in general you should not believe the recorded inspiral range for most of the night.

Guardian changes, other configuration changes

If LSC_FF is requested, the Guardian will proceed from DC_READOUT to LOWNOISE_ESD_ETMY to LSC_FF. If desired, one can make a pit stop at COIL_DRIVERS before going through LSC_FF.

I had wanted to add some Guardian code that steps down the TRX/TRY QPD whitening gains by 6 dB before the ASC comes on (and then adjusts digital gains accordingly), since the QPDs will saturate when powering up beyond 10 W. But it seems this makes the ITM loops unstable somehow. So I've left some commented-out code in DRMI_ON_POP and in the DOWN state.

In the ITM M0 lock filters, I moved the integrators from FM2 to FM4 and stuck +20 dB gains in FM2. Now we have some room to adjust the offloading speed.

Non-image files attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 09:35, Thursday 14 May 2015 (18421)

Having the +20dB gain in the ITM offloading does not work with the green WFS. Turned them off.

gabriele.vajente@LIGO.ORG - 09:51, Thursday 14 May 2015 (18423)

For reference, here are the simulation results for misalignments of dETMs and SRM. A reduction of 20 dB of coupling at high frequency should correspond to 2-3 urad misalignment.

Morevoer, the shape of the noise at 2100 cts offset seems very close to a flat 1/f^2 we would expect for an ideal IFO.

Images attached to this comment
keita.kawabe@LIGO.ORG - 11:58, Thursday 14 May 2015 (18426)

Somehow ASC-SRC1_Y offset fixed the SR3 PIT though SR3 is uncontrolled.

Doesn't make sense.

Anyway, we knew that SRM was moving in YAW though the cause was not clear. https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18366

In the first attachment, SR3 moved in PIT (red frame), SR2 moved in PIT (and YAW) (blue) due to ASC control, and SRM moved in YAW (green) also due to ASC, and everything just kept drifting away.

In the second attachement, initially everybody was moving in the same way as the first attachment, but as soon as Evan applied an offset to ASC-SRC1_Y (pink), things jumped and then stopped moving. Even the uncontrolled SR3 stopped moving.

Images attached to this comment
evan.hall@LIGO.ORG - 16:09, Thursday 14 May 2015 (18433)

Here are two DARM OLTF measurements from last night. The reference traces were taken with no offset in the AS36I loop. The current traces were taken with 2100 ct offset on.

Non-image files attached to this comment
H1 ISC (CAL, ISC)
sudarshan.karki@LIGO.ORG - posted 14:54, Monday 11 May 2015 - last comment - 19:23, Thursday 14 May 2015(18361)
Cavity Pole monitoring using Pcal Lines

SudarshanK, DarkhanT

We introduced two Pcal lines at 240 Hz and 310 Hz on photon calibrator at Y end.  The Pcal lines are about a factor of 10 above the DARM sensitivity at those frequencies. We will look into any changes in the amplitude and phase of these lines to determine the the position of cavity pole frequency. The cavity-pole has been observed at frequencies listed in  alog LHO #18360.

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 16:24, Monday 11 May 2015 (18364)

Since the pole frequency is at about 300 Hz, it would be useful to have a high frequency line, for example at about 1 kHz. This will allow a better reconstruction of the pole frequency.

peter.fritschel@LIGO.ORG - 19:46, Monday 11 May 2015 (18367)

If you haven't already, I recommend also putting a notch in the DARM loop at 310 Hz. That way any phase change that occurs at 310 Hz in DARM should be a direct measurement of changes in the sensing phase (which would presumably come from a chang in cavity pole). I probably would have gone a little higher with the 2nd line, closer to 400 Hz. Why did you choose what you did?

sudarshan.karki@LIGO.ORG - 22:51, Monday 11 May 2015 (18369)CAL, ISC

Gabriele, We also have a permanent Pcal line at around 540 Hz. We thought it should be enough. Is there any advantage of going close to1 KHz?

Peter, I will have to talk to Jeff about putting a notch on the DARM loop, I am not sure how to go about it. Regarding the choice of 240 Hz and 310 Hz, knowing we already had one line at around 540 Hz we picked a pair of line between one of the non-vetoed frequency band of pulsars. We could easily shift the second line to 400 Hz. 

jameson.rollins@LIGO.ORG - 11:20, Tuesday 12 May 2015 (18376)

Larry Price did an analysis of just this situation, i.e. at what frequencies should you measure the transfer function to most optimally extract the features in the frequency response.  His analysis showed that the most optimal place is at the feature itself.  In other words, the best place to put your calibration line to most efficiently measure the cavity pole is at the expected cavity pole frequency.  See: LIGO-G1400084

evan.hall@LIGO.ORG - 04:15, Wednesday 13 May 2015 (18401)CAL

In light of this optimal, Fisher-matrix-based approach, Kiwamu and I have installed a notch in DARM at 322.1 Hz (actually an 80 dB elliptic bandstop from 321 Hz to 323 Hz). The goal is to inject a calibration line digitally into DARM control, so that we can use an LSC lock-in to demodulate the line.

We have set up LSC oscillator #3 to take OMC DC and demodulate it at 322 Hz. Both I and Q have 4th order butterworth low-pass filters. The lock-in output drives ETMX and ETMY differentially. The lock-in drive is currently 0 ct. It has not been set yet.

christopher.wipf@LIGO.ORG - 14:04, Wednesday 13 May 2015 (18411)

Better check the assumptions here. Doesn't Larry's result assume an open-loop measurement, white actuator strength, and white measurement noise (none of which holds in this case)?

kiwamu.izumi@LIGO.ORG - 19:23, Thursday 14 May 2015 (18439)

Chris,

Thank you for pointing it out. We also noticed that the assumptions were not quite valid in our case. On the other hand, Larry's analysis still gives us a good idea of what frequency we should excite. According to his Fisher matrix analysis, the measured transfer coefficient exhibits a maximum response to change in the cavity pole frequency when the excitation is at the exact pole frequency. This led us to a frequency at around 322 Hz. If you take the spectral shape of sensor noise (or DARM residual) and the actuator transfer function into account, probably a slight lower frequency than the current choice may be better, but since we wanted to have a notch in DARM far from the UGF, we chose it to be close to the cavity pole.

H1 AOS (ISC)
eleanor.king@LIGO.ORG - posted 16:19, Friday 19 December 2014 - last comment - 14:58, Thursday 14 May 2015(15758)
PRM high bandwidth filters

Thomas, Stefan, Jeff, Kiwamu, Elli

Continuing along the same line as yesterday's work on PR3 (alog 15727), we have designed high-bandwidth (<10Hz) actuation filters for the PRM.  These filters are applied to H1ASC-PRC1P and H1ASC-PRC1Y in the central part of the ASC WFS servo.

The filters added to ASC WFS central are called 'PRM^-1' and are:
H1:ASC-PRC1_P:   zpk([0.2+i+0.9;0.2-i*0.9;0.05+i*3.41;0.05-i*3.41],
                [0;0.2+i*2.75;0.2-i*2.75;0.125+i*9.99922;0.125-i*9.99922],1,"n")
H1:ASC-PRC1_Y:     zpk([0.04+i*1.08;0.04-i*1.08;0.1+i*2.08;0.1-i*2.08;0.05+i*3.43;0.05-i*3.43],
                [0;0.15+i*1.8;0.15-i*1.8;0.05+i*3.3;0.05-i*3.3],1,"n")
Some old unused filters were also removed.


Low-pass filters called 'RLP17' were added to the PRM M3 locking filters in pitch and yaw:
H1:SUS-PRM_M3_LOCK_P:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")
H1:SUS-PRM_M3_LOCK_y:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")

Comments related to this report
thomas.vo@LIGO.ORG - 18:27, Friday 19 December 2014 (15760)
After getting the hang of creating some of these filters and we werestrongly encouraged to write a detailed proceudre:
 
1. Create a white noise, M3 to M3 transfer function using the templates located in /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM3/Data, you can actually use any bottom stage sensor that is available, OSEMs or OptLevs but on PRM, we're only let with the OSEM option.
 
2. The idea is to use the transfer function and then add zeros and poles using the calibration feature in DTT to roughly get a filter than will give you the damped motion you're looking for with the correct phase without waiting for measurements to run everytime you're changing the Q or freq of the pole/zero:
We start by finding the frequency of the lowest resonance and then this will give us an idea of the complex portion and then we eyeball a Q depending on the original transfer function's Q.  By shifting the complex portion of the zero, we attempt to get the correct phase and dither by hand until we roughly supress the resonance with 30-35 degrees phase margin.  We move on with the same procedure for the higher frequency measurements, creating poles and zeros when necessary.  Attached is a before and after look at the transfer function.
 
3. Now that we have the right idea for the ZPK values, we can create a filter module in the ASC WFS Servo Control.  For PRM the correct filter is h1ASC-PRC1 and so we just copied the new filter values into foton and then test by first locking PRMI and then ramping the gain slowly and watching if the DAC saturates or the PRMI breaks lock.  If it doesn't break lock we can tell that our loops are unconditionally stable and then retake OL transfer functions with the new filters in place to see if we're adding any new noise.  Then you're pretty much done.​
Non-image files attached to this comment
stefan.ballmer@LIGO.ORG - 00:44, Saturday 20 December 2014 (15764)
I had to sighly correct the filters to make them stable. Attached is what we now have running.

The filters are:
PITCH: zpk(  [0.1+i*1.02;0.1-i*1.02;0.12+i*3.35;0.12-i*3.35],  [0.12+i*2.75;0.12-i*2.75;11.1111+i*38.4258;11.1111-i*38.4258]  ,1,"n")
YAW:   zpk(  [0.015+i*1.09;0.015-i*1.09;0.03+i*2.05;0.03-i*2.05;0.02+i*3.43;0.02-i*3.43],  [0.05+i*1.75;0.05-i*1.75;0.02+i*3.25;0.02-i*3.25;11.1111+i*38.4258;11.1111-i*38.4258],1,"n")

Images attached to this comment
betsy.weaver@LIGO.ORG - 14:58, Thursday 14 May 2015 (18430)

Note, commissioners (Kiwamu/Evan) report that they turned these filters off ~April 21st, 2015 since they were no longer needed.  Filters now off are PRM M3 LOCK P and Y FM9 (RLP17).  SDF has been updated.

Displaying reports 65041-65060 of 83002.Go to page Start 3249 3250 3251 3252 3253 3254 3255 3256 3257 End