Displaying reports 63341-63360 of 83224.Go to page Start 3164 3165 3166 3167 3168 3169 3170 3171 3172 End
Reports until 09:43, Tuesday 11 August 2015
H1 SUS (CDS)
james.batch@LIGO.ORG - posted 09:43, Tuesday 11 August 2015 (20422)
Replace h1susex computer with original
The "fast" h1susex computer has been replaced with the original h1susex computer.  This should eliminate the IOP model timing glitches that would occasionally cause IPC errors across other models.
H1 GRD
thomas.shaffer@LIGO.ORG - posted 09:40, Tuesday 11 August 2015 (20421)
Destroyed not used ISI_ETMX_ST1_CONF GRD node

I started this node a month or so ago to test and to see what configuration we might use it in. With the code freeze upon us, it seems as though this will not be used and is just sitting in the background. No need for that. I did the following:

>> guardctrl destroy ISI_ETMX_ST1_CONF

I then double checked that the node was no longer in the node list.

H1 CAL
jeffrey.kissel@LIGO.ORG - posted 09:12, Tuesday 11 August 2015 (20417)
CAL-CS Front End Model Bug ''Fix'' Complete
J. Kissel, D. Tuyenbayev

We've installed a few new writeable EPICs records for the following channels, in order to circumvent the issues we've found with EPICs / FE computational precision problems in the new CAL-CS front-end model infrastructure to accommodate tracking of slow, time-dependent parameters in the IFO calibration in the GDS calibration pipeline. See LHO aLOG 20386 for ID of precision bugs.

Attached are screenshots of the changed library parts, which have now been committed to the userapps svn.

In summary, 
(1) the channel names which should be used have not changed, they're now merely EPICs writeable records as opposed to calculated records. The calculated channels still exist (they've not been removed so we can continue to debug ), but have been renamed.

Channels that are now EPICS Writes                       Former Calc Record's New Name                                 Term in T1500377
$(IFO):CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_$(REAL,IMAG)    $(IFO):CAL-CS_TDEP_CALC_INVA_CLGRATIO_TST_$(REAL,IMAG)        - (1 / A_{0}^{tst})|f_tst *  C_{0} / (1 + G_{0})|f_pcal * (1 + G_{0}) / C_{0}|f_tst     
                                                                                                                       This is the constant part of Eq. 9
$(IFO):CAL-CS_TDEP_REF_CLGRATIO_CTRL_$(REAL,IMAG)        $(IFO):CAL-CS_TDEP_CALC_CLGRATIO_CTRL_$(REAL,IMAG)            C_{0} / (1 + G_{0})|f_pcal * (1 + G_{0}) / C_{0} |f_ctrl
                                                                                                                       This is the constant part of Eq. 11
$(IFO):CAL-CS_TDEP_REF_A_USUM_INV_$(REAL,IMAG)           $(IFO):CAL-CS_TDEP_CALC_A_USUM_INV_$(REAL,IMAG)               1 / A_{0}^{pu}
                                                                                                                       This is the constant part of Eq. 12

For the remaining list of channels needed (none of whom's names have changed) see LHO aLOG 20361.

In consequential changes:
(2) I've fixed the mistake in the flags to compute $(IFO):CAL-CS_TDEP_CALC_INVA_CLGRATIO_TST_$(REAL,IMAG), even though we now won't use this channel. (see ID of this bug in LHO aLOG 20365)
(3) I've also added the missing minus sign to the comments.


For LLO to update, one only needs to update the following common library parts:
/opt/rtcds/userapps/release/cal/common/models/
CAL_CS_MASTER.mdl
CAL_GAMMA_CALC_MASTER.mdl
and recompile. MEDM screen updates will come later today.
Images attached to this report
H1 DetChar (DetChar, ISC)
joshua.smith@LIGO.ORG - posted 09:00, Tuesday 11 August 2015 - last comment - 11:36, Tuesday 11 August 2015(20418)
Excess noise in ASC X_TR NSUM channels since ER7
In following up the beam tube glitch injections, we by chance noticed that the amplitude spectrum of the NSUM of the ASC photodiodes at end X have changed significantly since ER7. In particular, through July and August there is now a set of peaks at 9 and 10.2Hz and broadband noise in ASC-X_TR that was not there in ER7. We don't see any significant changes in the corresponding Y_TR channels. 
 
The UTC times for the following four plots are: 
2015-08-08 14:00:00 (Blue) ("now")
2015-08-02 10:00:00 (Red)
2015-08-01 11:00:00 (Green)
2015-07-31 07:30:00 (Yellow)
2015-06-11 14:00:00 (Purple) ("ER7")
 
Fig 1: ASD of X_TR_A_NSUM. (excess noise above 5 Hz)
Fig 2: ASD of X_TR_B_NSUM. (excess noise above 5 Hz)
Fig 3: ASD of Y_TR_A_NSUM. (no major changes)
Fig 3: ASD of Y_TR_A_NSUM. (no major changes)
 
We note that this additional noise should be above the feedback frequency and indeed we see no increased coherence in DARM now, w/r/t ER7, except at 1.7Hz.
 
Fig 4: TR Coherence w/ DARM ER7 time. 
Fig 5: TR Coherence w/ DARM now time. 
 
We thought the most likely explanation would be poor alignment on the TR X ASC diode, coupling beam pointing noise into “fake” intensity noise. However, we don’t see anything obviously wrong with the DC values from the segments now. 
 
Fig 6: Timeseries of TR segments ER7 time. (More light on 1 and 4) 
Fig 7: Timeseries TR segments now time. (More light on 3 and 4) 
 
We didn’t see this as a DQ problem anywhere, but wanted to report it in case it indicates some problem we haven’t thought of.  
Images attached to this report
Comments related to this report
matthew.evans@LIGO.ORG - 09:48, Tuesday 11 August 2015 (20423)

This was seen before, and may be related to broken electronics.

andrew.lundgren@LIGO.ORG - 11:09, Tuesday 11 August 2015 (20427)DetChar
The excess noise is visible also on August 1, the first lock after Vern's percussive maintenance. So either the high frequency noise in the OSEMs came back a day later, or it wasn't related. The channels that have the 1821 Hz and harmonics are only recorded at 256 Hz, so I can't check whether the OSEM problem was there or not on Aug 1.
Images attached to this comment
keita.kawabe@LIGO.ORG - 11:36, Tuesday 11 August 2015 (20428)

FYI the same coils were oscillating this morning. Satellite box will be replaced.

H1 CAL
jeffrey.kissel@LIGO.ORG - posted 08:14, Tuesday 11 August 2015 (20414)
CAL CS EPICS Records which will be lost upon Reboot Today because of SDF Precision Bugs
J. Kissel

Attached is a screenshot of the values installed on Sunday will be lost because of SDF precision issues.
Images attached to this report
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 08:05, Tuesday 11 August 2015 - last comment - 08:12, Tuesday 11 August 2015(20411)
ISS optoisolator replacement
Both HPCL-2231 optoisolators were replaced.

After re-inserting the servo card, I checked that the laser was on and that the NPRO noise eater was still happy.  The laser MEDM screen indicated both.  When I pulled up the ISS screen the power on the photodiodes was zero.  I checked the PMC screen and it indicated that there was no laser power incident on the PMC.  A closer look at the laser screen indicated that the low power shutter in the laser had closed.  Resetting the external shutter request from the laser MEDM screen restored the light.

After locking the ISS servo, everything seems okay as far as the laser goes.
Comments related to this report
peter.king@LIGO.ORG - 08:12, Tuesday 11 August 2015 (20413)
Board affected is S/N S1107804.
H1 ISC (CDS, PSL, SEI, SUS)
jeffrey.kissel@LIGO.ORG - posted 08:03, Tuesday 11 August 2015 (20410)
Maintenance Day Prep
J. Kissel, B. Weaver, C. Vorvick

- ISC_LOCK guardian to DOWN, set in PAUSED
- IMC_LOCK set to OFFLINE
- ALIGN_IFO set to PAUSED

- SEI_ETMY to OFFLINE and SUS_ETMX to SAFE for prepping SUS EX reversion to slow front end computer.

-Cleared ETMX SDF warnings about new violin mode damping configuration, initialized new RMSLP and L3_CAL_LINE channels and set to monitored

- Accepted ETMY BIAS sign flip and corresponding DRIVEALIGN gain sign flip.

- Accepted ALS Y PZT2 YAW MISALIGN BIAS to be 11200 (from 11500)

- Reverted SUS BS LOCK L OFFSET (and TRAMP) to 0 and 10 (respectively) from 10000 and 30 (respectively).

- Accepted SUS ITMY violin mode damping settings, and that the output is OFF for ITMY OLDAMP P.

- Accepted SUS ITMX optical lever Y damping GAIN to be 0.0 (from -111). 

NOTE: ITM Optical Lever P Damping is totally inconsistent. We've found that ITMX P is ON (gain and output switch) yet ITMY Y is on OFF (gain -300 output is OFF).
We tested TJ's modifcations to the SUS guardian by exercising the SAFE state, which turns OFF the outputs. By design, the outputs should be turned back ON in the DAMPED state. Will speak with TJ.
H1 IOO (DetChar, INJ)
matthew.evans@LIGO.ORG - posted 08:01, Tuesday 11 August 2015 - last comment - 14:14, Tuesday 11 August 2015(20409)
Periscope PZT Glitches?

While looking at a few big glitches, I noticed that many have a curious post-glitch feature around 300Hz.  The post-glitch ring seems to match the periscope frequencies we usually see noise at... could this be a hint as to the source of some of our glitches?  Maybe this was fixed last night, maybe not.

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 14:14, Tuesday 11 August 2015 (20434)DetChar

Looking at all the glitches previously indentified, it runs out that only 17 out of 151 show an excitation of the periscope peaks, as found by Matt. Here are the times:

          1117617558.82
          1117690781.51
          1117713007.28
          1117754567.25
          1117873501.47
          1117888336.85
          1118320556.34
          1118336224.73
          1121762741.96
          1121942076.77
          1121966658.37
          1121986392.35
          1121991554.23
          1122466633.18
          1122474562.14
          1122479776.82
          1122484101.65

H1 General
cheryl.vorvick@LIGO.ORG - posted 07:58, Tuesday 11 August 2015 (20408)
Owl Summary:

Alignment and locking issues aloged earlier.

IFO did make it to low noise about 6 hours ago.

Relocking about 45 minutes had trouble with Guardian that we hadn't had any issues with all night - not sure why.  At JeffK's suggestions I commented out the offending section of code.  Code is attached as a screenshot.

IFO handed off to Mantenance activities.

----------Maintanance Activities ------

7:00 - Richard and Ken, roof

7:37 - Bubba and Chris, LVEA fan maintenance

7:41 - PeterK, ISS

7:42 - Richard and Ken, Electronic's Room

7:59 - Richard/Ken DONE

7:59 - PeterK Done

Images attached to this report
H1 ISC
evan.hall@LIGO.ORG - posted 04:43, Tuesday 11 August 2015 - last comment - 11:09, Tuesday 11 August 2015(20404)
The 0.43 Hz pitch instability that just won't die

Cheryl, Evan

The 0.43 Hz pitch instability strikes again. I had to turn up the dHard pitch gain from 10 to 20 in order to prevent a runaway. Back into the guardian it goes!

It takes tens of minutes to ring up, and even after tweaking loops, it never exactly rings down (the fuzz in the attached striptool is almost all from this 0.43 Hz feature).

Images attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 05:54, Tuesday 11 August 2015 (20405)

Attached are error and control signals for the arm pitch loops at several different powers: 10.4 W (blue), 15.2 W (yellow), and 19.8 W (green).

Images attached to this comment
richard.mittleman@LIGO.ORG - 06:30, Tuesday 11 August 2015 (20406)

Is it strong enough to show up in the suspension OSEMS?

matthew.evans@LIGO.ORG - 07:41, Tuesday 11 August 2015 (20407)

Are the OPLEVs still on?  They suppress the ASC gain below 1Hz, and might be the cause of instability.

betsy.weaver@LIGO.ORG - 08:06, Tuesday 11 August 2015 (20412)
betsy.weaver@LIGO.ORG - 08:25, Tuesday 11 August 2015 (20415)

A trend of the oplev PIT loop buttons over the last 12 hours show the:

ITMY OL damping OFF

ITMX OL damping ON

SR3 OL damping ON

PR3 OL damping OFF

ETMX OL damping OFF

ETMY OL damping OFF

All above YAW loops OFF.

 

BS OL PIT and YAW damping ON.

sheila.dwyer@LIGO.ORG - 11:09, Tuesday 11 August 2015 (20426)

THe sttached screenshot is from the few minutes before Evan turned up the DHARD PIT gain last night.  You can see that there is an oscillation in the Y arm only, and it seems to be soft.  The same oscillation shows up in MICH but it is much smaller.  

As Betsy pointed out, ITMX oplev damping was on last night, while ITMY oplev damping was on.  Both ITM oplev loops are currently turned on in the INCREASE power state of the ISC_LOCK gaurdian, which still seems to be necessary for stability.  Based on OLG measurements of DHARD, the Oplevs should not impact the stability of DHARD.  However, we haven't been able to get good measurements of CHARD since rephasing the REFL WFS and hopefully getting a reasonable amount of gain from these loops.  (just because of other activities).  

Hopefully we can spend some time on CHARD today, which may shed light on why we need the ITM oplevs and hopefully reduce the large optical gain fluctuations we have. 

Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 04:07, Tuesday 11 August 2015 (20403)
Sum and null of OMC DCPDs closer together

This is a report by Jenne.

[Sheila, Jenne, Cheryl, Evan]

We have (finally) recovered from the input pointing adventures of the day. 

In the end, I think all we did was some hand alignment to get the ASC error signals small-ish, so that the loops could take over without pulling down the power buildups.  We are now able to go all the way through the guardian states automatically.

This is the first low-noise lock since the EOM driver was replaced earlier today with the new box that can suppress amplitude noise of the sideband (20392).  From Lisa's log post (20131), we see that a useful comparison is the OMC DCPD Null stream with the Sum.  In the plot below, the dotted line references are from August 1st, when we still had the old 45 MHz driver. The solid lines are from tonight.  The null stream is the same then and now, (as it should be), but the sum has come down significantly. This means that our OMC DCPD is now closer to the shot noise limit, since we have better suppressed this RFAM noise.

[Edit: It's true that the coherent excess in the DCPD sum has been decreased, but there is still a broadband excess everywhere from 400 Hz to 7 kHz, and we still see broadband coherence between DCPDs A and B with AS C. See second attachment (the IOP channel is AS C segment 1). Might be worthwhile to try varying the modulation index. —Evan]

Images attached to this report
H1 ISC
daniel.sigg@LIGO.ORG - posted 21:07, Monday 10 August 2015 - last comment - 08:46, Tuesday 11 August 2015(20392)
45MHz EOM Driver Installed

(Evan, Kiwamu. Daniel)

We installed the 45.5MHz EOM driver in the PSL room. It is located below the PSL table and replaces the RF amplifier at the same location. The drive power has been adjusted to be the same as before at 23.2dBm. This is now controlled remotly through medm.

Calibration:

The RF phase shift was compensated by cable length to within 1°.

The RF phase has a slightl dependence on the RF level. At 45.5MHz with 23dBm output level the phase advance of the entire chassis is 121°. The relative phase shift at 17dBm is +4.8° (advance), +8° at 13dBm, and 12.8° at 5dBm—or –0.8°/dBm.

The attached plot shows the RF AM RIN in dBc/Hz for both the in-loop and out-of-loop sensor (double-sided). At 100Hz with 23dBm output we are achieving-170dBc/Hz.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 22:15, Monday 10 August 2015 (20400)

We kept track of the RF phase shift by keeping the interferometer in a freeswinging Michelson configuration while watching the time series of AS45I and AS45Q. Before the swap, we had arctan[Q/I] = arctan[42.0(3)/10.3(3)] = 76.2(4)°. After the swap, we found that the signals had shifted by +144°. [Note that just watching the freeswinging I and Q time series only determines the phase shift modulo 180°. We locked the Michelson and found that instead of the expected dark fringe lock, we got a bright fringe lock—indicating that the phase shift must lie somewhere between +90° and +270°.]

Then we experimented with adding extra cable length between the 45 MHz distribution spigot and the EOM driver. In the end Kiwamu and Daniel made a 150 cm LMR 195 cable, which brought the phase of AS45 back to arctan[41.8(6)/10.1(4)] = 76.4(6)°.

betsy.weaver@LIGO.ORG - 08:46, Tuesday 11 August 2015 (20416)

I assume the following SDF setting changes are related to this work, so I have accepted them into the LSC safe.snap for future restores.

Images attached to this comment
H1 CAL (SUS)
kiwamu.izumi@LIGO.ORG - posted 22:06, Friday 07 August 2015 - last comment - 09:25, Tuesday 11 August 2015(20334)
Pcal now uses sus dynamical models
The Pcal RX and TX photodetectors now have filters which simulate the suspension dynamical response in order to convert the signals into displacements. The filters are installed and enabled.
Since each signal chain is whitened, one needs to apply two poles at 1 Hz with a gain of 1 when using these signals.
 
[Background]
Traditionally Pcal uses a free-mass approximation for the suspension responses which is a simple 1/f^2. This can introduce undesired inaccuracy at low frequencies. Even though we know the accuracy is not too terrible at around 30 Hz, where the lowest frequency Pcal lines are, we decided to replace the old 1/f^2 approximation with the dynamical suspension model.
 
[Tagging suspension models]
Prior to the update of the filters, we take this opportunity to tag our suspension models. As usual, I used Jeff's code to create tags. The scripts is in:
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel.m @rv7754
 
Also, I updated h1etmx.m which is a parameter file dedicated for creating the h1etmx suspension model. I only updated the fundamental violin mode. I confirmed that the mass was correct since this is critical for Pcal. As for h1etmy.m, it was already good from the beginning. The mass is correct and the violin modes are specified up to 8th harmonics. So I did not update it.
The tagged models are now in SVN:
 
[Script does all at once]
I wrote a matlab script which picks up the tagged suspension models and subsequently quack them into the Pcal TX and RX PD filters. For convenience, the suspension responses are divided into three pieces -- normalized suspension response, zpk([], [1,1], 1, "n") and DC gain in [m/N]. Combining all three makes the complete suspension response. The normalized suspension response has a gain of 1 at DC (technically speaking at 10 mHz) and all the zeros and poles except for two poles at 1 Hz. The two-pole filters are intentionally turned off in order to whiten the whole signal chain. Therefore one has to apply the two poles when calibrating the signals. The attached is a screen shot of how they look in the medm screens.
The script can be found at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Scripts/Pcal/quad_response.m
 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Scripts/PcThe Pcal RX and TX photodetectors now have filters which simulates the suspension dynamical response in order to convert the signals into displacements. The filters are installed and enabled.
Since each signal chain is whitened, one needs to apply two poles at 1 Hz with a gain of 1 when using these signals.
 
[Backgrounds]
Traditionally Pcal uses a free-mass approximation for the suspension responses which is a simple 1/f^2. This can introduce undesired inaccuracy at low frequencies. Even though we know the accuracy is not too terrible at around 30 Hz, where the lowest frequency Pcal lines are, we decided to replace the old 1/f^2 approximation with the dynamical suspension model.
 
[Tagging suspension models]
Prior to the update of the filters, we take this oportunity to tag our suspension models. As usual, I used Jeff's code to create tags. The scripts is in:
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel.m @rv7754
 
Also, I updated h1etmx.m which is a paramter file dedicated for creating the h1etmx suspension model. I only updated the fundamental violin mode. I confirmed that the mass was correct since this is critical for Pcal. As for h1etmy.m, it was already good from the beginning. The mass is correct and the violine modes are specificed up to 8th harmonics. So I did not update it.
The tagged models are now in SVN:
quadmodelproduction-rev7652_ssmake4pv2eMB5f_fiber-rev3601_h1etmx-rev7641_released-2015-08-07.mat
quadmodelproduction-rev7652_ssmake4pv2eMB5f_fiber-rev3601_h1etmy-rev7640_released-2015-08-07.mat
 
[Script does all at once]
I wrote a matlab script which picks up the tagged suspension models and subsequently quack them into the Pcal TX and RX PD filters. For convenience, the suspension responses are divided into three pieces -- normalized suspension response, zpk([], [1,1], 1, "n") and DC gain in [m/N]. Combining all three makes the complete suspension response. The normalized suspension response has a gain of 1 at DC (technically speaking at 10 mHz) and all the zeros and poles except for two poles at 1 Hz. The two-pole filters are intentionally turned off in order to whiten the whole signal chain. Therefore one has to apply the two poles when calibrating the signals. The attached is a screen shot of how they look in the medm screens.
The can be found at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Scripts/Pc
Images attached to this report
Comments related to this report
sudarshan.karki@LIGO.ORG - 14:13, Sunday 09 August 2015 (20362)

Prior to this change,  photodiodes (TX and Rx PD) calibartion coeffcient were reported in metres/Volt *(1/f^2). Now with the suspension model in place, we have calibrated the photodiodes in terms of Force Coefficient (N/V). The filter banks, as shown in the attachement above, now reflect these new N/V calibration factors. Appropriate changes have been made to the DCC document  (T1500252) as well.

kiwamu.izumi@LIGO.ORG - 09:25, Tuesday 11 August 2015 (20420)

This is an additional note about the quack function -- when I was using quack, I had a difficulty in quacking an state-space suspension model into a foton filter. See the detail below.

In matlab, I had been using something like:

quad.d = minreal( zpk( c2d(quad.ss, smaplingTime, 'tustin' ), tolerance )
 
where quad.ss is a state-space representation of the quad suspension response, and samplingTime in this case is 1/16384 sec. The reason why I used the minreal function is that otherwise it would come with too many number of poles and zeros which exceeded the number of poles and zeros that foton can handle. I tried adjusting the tolerance of minreal in order to reduce the number of poles and zeros, but it was extremely difficult because it ended up with either too many poles/zeros or too few poles and zeros.
 
Instead, I tried the following command which at the end worked fine:
quad.d = c2d( minreal( zpk(plant.ss), tolerance ), samplingTime, 'tustin');
 
The combination of the functions are exactly the same, but the ordering is different. It does minreal before c2d. This allowed me for having a reasonable number of poles and zeros.
Displaying reports 63341-63360 of 83224.Go to page Start 3164 3165 3166 3167 3168 3169 3170 3171 3172 End