Displaying reports 65321-65340 of 83122.Go to page Start 3263 3264 3265 3266 3267 3268 3269 3270 3271 End
Reports until 16:00, Wednesday 06 May 2015
H1 General
travis.sadecki@LIGO.ORG - posted 16:00, Wednesday 06 May 2015 (18280)
OPS Day Shift Summary

7:58 JimW taking ETMx ISI down to load new filters

8:55 Gerardo to valve out BSC1 aux cart

9:04 Gerardo done

9:17 Karen to MY, Cris to MX

9:49 Karen leaving MY

10:33 Cris back from MX

14:27 Richard to Mid ? with Simplex

14:57 Gerardo to LVEA to shutdown aux cart

H1 ISC
kiwamu.izumi@LIGO.ORG - posted 15:53, Wednesday 06 May 2015 (18219)
Alignment during the days when we were not able to lock

There were a few days in the last week where we could not get the interferometer fully locked for some alignment-related reason. I studied what was going on in this period and came up with a hypothesis.

 

According to my hypothesis, the followings must have happened:

These resulted in the dark days where we were unable to lock the interferometer.

 


[The unlockable days]

 

As shown in the above cartoon, we were unable to fully lock the interferometer between some time in the Tuesday 28th and Thursday 30th of April. I also noted alignment-related activities in the same viewgraph to see what kind of activity we did. It is shown that there was one activity right around the time when we started realizing difficulty in locking, namely removal of the software aperture mask on the ITMY green camera (alog 18108). Nonetheless, I don't think this triggered the unlockable days. As will be discussed in the later part of this alog, I believe that the cause is a large lateral shift of the spot on ITMX.

 

[Optics' angle in the unlockable days]

I attach two trend plots which show angle of various optics. They are 10days trend. I drew two vertical lines in each plot for encmpassing the dark days. Looking at the two plots on the upper right corner of the first plot, one can clearly see that TRX or TRY did not reach a high value, meaning we could not lock. Also, it is very clear that we had a different alignment in this particular period.

Even though some optics exhibited different alignment in pitch, most of the optics indicate that the alignment in yaw changed significantly. Therefore I neglect any misalignment in pitch hereafter and concentrate on misalignment in yaw. 

 

[X arm alignment]

Since the Y arm behaves as a slave of the X arm from the point of view of the interferometer alignment, I assume that the Y arm alignment had been continueously adjusted properly so that the Michelson becomes dark and the beam spot on ETMY was adjusted to be at the center of it and so forth. In this way I limit the discussion to the X arm and PRC hereafter.

Here is a summary table of how much the relevant optics moved in yaw before and after the Tuesday 28th. The values were extracted from the two trend plots that I showed above.

   before Tuesday [urad]   after Tuesday [urad]  difference [urad]  sensor
ITMX -8 0  +8  oplev
ETMX 0

 -3 *2.74 (oplev calibration alog 18237) = -8.22

 - 8.22  oplev
TMSX -229 -235   - 6  witness sensor
PR3 271 275  + 4  alignment slider
PR2 3373 3398   + 25  witness sensor
PRM 420 540  + 120  witness sensor
IM4 -645 -569 + 76  witness sensor

Using the ITMX and ETMX angle differences, I estimated the difference in the spot position on ITMX and ETMX. I used the following matrix to compute the spot position:

The variables are defined as shown in the cartoon below.

Substituting the realistic values: L = 3994.5 m, ROC_itm = 1934m, ROC_etm = 2245 m, Psi_i = 8 urad and Psi_e = -8.22 urad, I obtain displacement of x_i = -4.7 cm and x_e = -1.8 cm. The beam axis should look like this:

Discussion of the DRMI part is held in the next section. Also, please note that in this analysis we can not estimate the absolute spot positions.

Displacement of 47 mm on ITMX is quite large. For example, one can compare it with the beam radius of the red light on ITMX which is about 53 mm. So it moved by almost half of the beam diamter.

Since we had nonideal behavior in PRC2 ASC loop, I am speculating that the large displacement on ITMX resulted in a clipping or something similar in PRC or Micheslon part and hence bad ASC signal.

According to error propagation, the spot position on the test masses are found to be very senstive to precision of the measured angles. For example, x_e would get an error of +/-1.2 cm if error of +/-0.5 urad is added on the ETMX angle. Nonetheless, I think the displacement of 47 mm on ITMX is believable as this is a relatively large number. On the other hand, the displacement of 18 mm on ETMX maybe fishy because of measurement error. Additionally, the green WFS servos must have steered the test masses such that the spot position on ETMX stays at the same position. Anyway, at this point it is unclear if ETMX actually moved by 18 mm.

One thing which makes me a bit suspicious about this caluclation is the angle of TMSX. As listed in the table, it moved by +6 urad. On the other hand, according to the analysis, the arm eigen axis obtained a rotation of about 16 urad which does not match the angle of TMSX by a factor of almost 3. I am not sure what this means.

[PRC alignment]

Doing a similar matrix approach in PRC, one can build a displacement-misalignment matrix as

where h_j is displacement and phi_j is misalignment. Subscript p stands for PRM, 2 for PR2, 3 for PR3 and i for ITMX. Subsitituting the difference in the measured angles as listed in the table, one can get

[hp h2 h3 hi] = [1.8 mm, -2.5 mm, 1.9 cm, -1.9cm]

which unfortunately contradicts what I said about the ITMX spot position. However, in principle, our initial alignment scheme should bring the PRC beam axis so as to match that of the arm cavity. Now, instead of simply substituting the measured values, I do a small tweak on PR3 angle. I add a magic number of 0.4 urad on top of the measured PR3 alignment. This results in displacements of:

[hp h2 h3 hi] = [-1.3 mm, 5.3 mm, -4.7 cm, 4.7 cm]

which agrees with the previous arm cavity discussion. I don't have any data to support this magical 0.4 urad on PR3, but I believe that it is not crazy to say that the calibration of the PR3 alignment slider has been off by 10 %. Anyway, if we believe in this result, this introduces a translation of 4.7 cm in the PR3-ITMX beam line as expected. Also the spot position on PRM did not move so mcuh as expected because it should be passively determined by the IMC pointing which I think is stable on a time scale of many days. Even though the spot on PR2 moved by 5.3 mm, I don't think this is big enough to let the beam hit the PR2 baffle to cause a clipping.

[Why the yaw alignment changed ?]

It is unclear why the yaw alignment changed so drastically during the period.

One might think that this was due to a wrong reference position on the ITMX green camera. However, according to the past alogs, there was no obvious activities associated with the ITMX green camera at around the time when we started having difficulty. Keita suggested me checking whether a limiter was on in some of ALS WFSs because it has been an issue which hindered the ALS WFS performance. Indeed both ALS_X_DOF2_P and _Y had a limiter on (see the attached conlog and trend), but the _Y_LIMIT value was set to 1e7 counts while _P_LIMIT was set to 10 counts, meaning Y_LIMIT was essentially not effective. This could cause some funny behavior in pitch, but it is still hard to believe that it introduced such a big offset in yaw.

Images attached to this report
LHO VE (VE)
gerardo.moreno@LIGO.ORG - posted 15:50, Wednesday 06 May 2015 (18282)
BSC1 Annulus Ion Pump Update

This morning I valved out the aux pump cart, 8:50 am, the cart continued to pump on the valve.

At 3:20 pm the aux cart was turned off, cable, hose and turbo decoupled from the valve.  Ion pump is on its own now, current is trending down, currently at 4.02 mA.

No change was noticed on the pressure of the BSC1 annulus system as the cart was removed.

The valve was blanked off.

H1 General
travis.sadecki@LIGO.ORG - posted 14:19, Wednesday 06 May 2015 (18279)
Morning meeting notes

SEI - working on ETMx ISI filters

CDS - working on chassis repairs

Facilities - exit gate repair ongoing

PSL - interlock investigation ongoing

mouse traps for EY being increased to mediate excretion issues

OSB painting continues

BSC1 ion pump aux cart to be valved out

LHO General (DetChar)
nathaniel.strauss@LIGO.ORG - posted 12:49, Wednesday 06 May 2015 (18277)
Wandering line at 1180 Hz and line at 1150 Hz
Andy Lundgren sent out an inquiry via email about lines at 1180 Hz and 1150 Hz. I looked for these lines in the coherence tool, and I didn't see any evidence of the 1180 Hz line, but I did find a very sharp line at 1150 Hz on the following channels:

H1:LSC-MCL_OUT_DQ
H1:LSC-MICH_OUT_DQ
H1:LSC-PRCL_OUT_DQ
H1:CAL-CS_CARM_DELTAF_DQ
H1:CAL-CS_IMC_DELTAF_DQ
H1:CAL-CS_MICH_DQ
H1:CAL-CS_PRCL_DQ
H1:CAL-CS_SRCL_DQ
H1:LSC-DARM_OUT_DQ
H1:LSC-REFL_SERVO_CTRL_OUT_DQ
H1:OAF-CAL_CARM_AO_DQ
H1:OAF-CAL_CARM_X_DQ
H1:OAF-CAL_MICH_DQ
H1:OAF-CAL_PRCL_DQ
H1:OAF-CAL_SRCL_DQ

If you want to look for yourself, you can find the full coherence tool output for the May 2 locks here:
https://ldas-jobs.ligo-wa.caltech.edu/~nathaniel.strauss/HIFOX/LineSearch/H1_COH_1114579968_1114784433_1000_webpage/
H1 CDS
hugh.radkins@LIGO.ORG - posted 12:03, Wednesday 06 May 2015 - last comment - 12:51, Wednesday 06 May 2015(18275)
Keeping SDF Green--CHANS NOT FOUND list

SDF Cleanup

If channels are removed from your model/code whatever, unless you take your system down to the safe state and makeSafeBackup to generate from scratch a new safe.snap (and most of us know the problem doing that causes,) the SDF system will go yellow for CHANS NOT FOUND.  Okay, maybe no big deal but green is better than yellow when scanning our configuration control tools and we should green these up at earliest opportunity.

There is a way to clear these out with having to take the system down to a 'safe' state for the new snap.

You can just go to the SDF TABLE and while there you might as well look at the CHANS NOT FOUND list and make sure they make sense (yes, we did remove those channels from the model, e.g.)

Then from that medm, open the SDF SAVE SCREEN

Insure the SAVE TABLE selection is TABLE TO FILE and the FILE OPTIONS SELECTION is OVERWRITE

Press SAVE FILE

This step overwrites the safe.snap file removing the not found channel records.  Little wierd though, on the SDF_RESTORE screen (available from the TABLE screen as well,) it does not show a Modified file detected message, but, it has updated the time, as if it had 'Restored' to that time.  But you will notice that your list of Not Found Channels have not cleared.  Maybe this is explicitly intentional or is maybe a trivial bug.

Now on the SDF_RESTORE screen, press LOAD TABLE, and, all the NOT FOUND channels should clear.

However, there may be remaining NOT FOUNDs that will crop back up:

If the NOT FOUND CHANNELs list contains fields as opposed to just records, that is H1:HPI-ETMX_GUARD_CADENCE.HIGH (field) versus H1:HPI-ETMX_GUARD_CADENCE (record), this process will not remove the field lines from the safe.snap.

Still need to test this (Barker is on it) but, maybe the next time the front end starts, these fields will again become a CHANS NOT FOUND and our green lite will revert to yellow.

This happens because the FE code reads the safe.snap and strips out the field lines and saves them in a safe_alarms.snap file in the target area.  Then when it saves the safe.snap, this field list is just tacked onto the end of the safe.snap record list.  So your safe.snap will always contain these non existent channel field lines.

The fix to this problem is the following, before doing the steps above, (you could did it after but you'd be saving & loading twice) go to the target area and remove the appropriate field lines from the safe_alarm.snap file (currently writable only by controls.)  Once these are gone, proceed as above in the SDF SAVE SCREEN.

Comments related to this report
jameson.rollins@LIGO.ORG - 12:13, Wednesday 06 May 2015 (18276)

For what it's worth, all of those old "...GUARD_CADENCE" channels should be completely purged from all models.  That is old deprecated guardian infrastructure.  I think it has all been purged at LLO, so maybe LHO just needs to update the affected models.

jeffrey.kissel@LIGO.ORG - 12:51, Wednesday 06 May 2015 (18278)GRD
@Jamie -- indeed -- we've updated the hepitemplate.mdl which has these old GUARD channels remove and compiled / installed the BSC HEPI models this past Tuesday (LHO aLOG 18223). So, Hugh is just documenting how to get rid of them the last known hold out -- the safe.snaps.

The integration issues that tracks the removal of these vestigial organs are here:
SEI II 922
SUS II 921

They've been marked closed for some reason -- I think it's because again and again we've thought we'd gotten rid of them all, but continue to find them lurking about.
H1 PSL (DetChar, PSL)
edmond.merilh@LIGO.ORG - posted 11:32, Wednesday 06 May 2015 (18274)
PSL DBB scans
Non-image files attached to this report
H1 PSL
edmond.merilh@LIGO.ORG - posted 10:21, Wednesday 06 May 2015 (18272)
PSL Weekly Report - Past 10 day Trends
Images attached to this report
H1 GRD
thomas.shaffer@LIGO.ORG - posted 09:23, Wednesday 06 May 2015 (18271)
IMC_LOCK guardian modification

After adding the OFFLINE state, alog 18081 , it was found that the offsets will cause drift in this state as well like in alog 17929 . So, after talking to Kiwamu, I changed it to disable the offsets in the OFFLINE state as well as in the FAULT state and removed it from the DOWN state. The offsets are still enabled in the LOCKED state as before.

LHO VE
bubba.gateley@LIGO.ORG - posted 07:48, Wednesday 06 May 2015 (18270)
Beam Tube Washing
Scott L. Ed P. Chris S.(Cris M.1/2 day)

5/4/15
Cleaned 21.3 meters ending at HNW-4-028. Removed lights and relocated all equipment to next section. Began vacuuming and spraying bleach/water solution.

5/5/15
Cleaned 73 meters ending 14.5 meters north of HNW-4-031.
Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 06:36, Wednesday 06 May 2015 - last comment - 10:52, Wednesday 06 May 2015(18264)
SRCL noise injection, back to a good range

Evan, Sheila

Tonight we have some evidence that the work on recylcing gain has helped us, Evan will attach the DARM spectrum. 

Restoring the green camera offsets to the ones used during the mini run means that we can again lock with a recycling gain of ~37.  These wrong references and the bad alignment that went with it has probably caused some of the frequent lock losses of the last two days, and headaches in turning on ASC in full lock. Hopefully we can leave all green references alone for at least a week and see that they really do bring us back to a good recycling gain consistently.   My comments from yesterday about trying to figure out what drifts in green should be ignored.

We did some injections of noise into SRCL with all of our boosts on (MICH L, SRCL, DHARD P+Y), and the AS_C to SRM+SR2 loop at a 4 Hz bandwidth.  38 W/W recycling gain.  UTC May 6 11:48-11:53 UTC, no SRCL FF but MICH FF was on.   The goal was to see how stationary the coupling is now.  

We also restored some of the ASC cut offs that were deleted during the recycling gain work, CHARD PIT +YAW, DHARD P+ Y (for DAHRD P we are only using one of the two cutoffs we had, a pair of complex poles at 12 Hz, we don't have enough phase to use the 8 Hz cut off anymore so we wil need to redesign it if we need it)

Other business

We think that some usefull next steps on the list are

Comments related to this report
evan.hall@LIGO.ORG - 06:51, Wednesday 06 May 2015 (18269)

Spectrum attached. We are touching the 10 W GWINC curve from 200 Hz to 4 kHz. We have been able to do this a few times before by maxing out the gain of the CARM loop, but that was not necessary tonight.

Also I'm attaching a trend of POP90 and REFL_A_LF during the lock. There is some slow (perhaps thermal) drift. I looked at the PR3 and SR3 oplevs in pitch. PR3 seems to have a faster transient, while SR3 has a similarly slow drift. I tried touching SR3 to compensate for this (around 12:05:00Z), but it seemed to make no difference.

Also attaching a DARM OLTF.

Images attached to this comment
Non-image files attached to this comment
gabriele.vajente@LIGO.ORG - 10:52, Wednesday 06 May 2015 (18273)DetChar, ISC

The SRCL coupling is much more stationary now. During the noise injection, the coherence between DARM and SRCL was good. The first plot shows the measured TF between SRCL_OUT and the calibrated CAL-DELTAL signal. 

I analyzed the data using the same technique explained in previous entries (17912, 17928, 18026). The second attachment shows that the coherence is stationary over time and the third attachment is an animation of the TF between SRCL_OUT and DARM over time. It's remarkably more stationary than before.

Finally, the last two attachments (4th and 5th) shows the time evolution of the transfer function at 30 Hz and 100 Hz. The residual variation of the TF is about 5%, which may very well be within the error of my estimaton.

Images attached to this comment
H1 CDS
sheila.dwyer@LIGO.ORG - posted 21:13, Tuesday 05 May 2015 - last comment - 22:33, Tuesday 05 May 2015(18265)
lockloss tool error

We don't seem to be ablke to use the lockloss tool tonight, I get this message.  I'm not sure if this is realted to  bug  834, or to some maintence activity today. 

 sheila.dwyer@opsws4:~/Desktop/Locklosses$ lockloss select

Traceback (most recent call last):
  File "/ligo/cds/userscripts/lockloss", line 288, in <module>
    args.func(args)
  File "/ligo/cds/userscripts/lockloss", line 199, in cmd_select
    selected = select_lockloss_time(index=args.index)
  File "/ligo/cds/userscripts/lockloss", line 106, in select_lockloss_time
    times = list(get_guard_lockloss_events())[::-1]
  File "/ligo/cds/userscripts/lockloss", line 93, in get_guard_lockloss_events
    time = parse_guard_timestring(line[0])
  File "/ligo/cds/userscripts/lockloss", line 76, in parse_guard_timestring
    return gpstime.strptime(string, format)
  File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
    (data_string, format))
ValueError: time data '2015-05-06T02:27:30.12109' does not match format '%Y-%m-%dT%H:%M:%S.%fZ'
Comments related to this report
jameson.rollins@LIGO.ORG - 22:17, Tuesday 05 May 2015 (18266)

This was the result of the guardian log time stamp change, which slightly changed the format of the time stamps in the logs.

It should be fixed now.

sheila.dwyer@LIGO.ORG - 22:33, Tuesday 05 May 2015 (18267)

thanks

H1 GRD
jameson.rollins@LIGO.ORG - posted 14:10, Tuesday 05 May 2015 - last comment - 15:30, Wednesday 06 May 2015(18252)
minor guardian upgrade this morning

During maintenance this morning we pushed a fairly minor guardian upgrade.  We are now running:

Primary bugfixes or new features:

The last two are to help debug some of the intermittent issues we've been seeing with node processes hanging for unknown reasons.

The node status indicators on the main GUARD_OVERVIEW screen also now have a couple of extra indicators lights, for STALLED state of node, and if there are any SPM diffs:

Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 15:30, Wednesday 06 May 2015 (18281)

Another new feature I forgot to mention is that guardian can now dump their internal setpoint table to a file.

This is triggered by writing a 1 ('True') to the SPM_SNAP channel for the node:

jameson.rollins@operator1:~ 0$ caput H1:GRD-SUS_ITMY_SPM_SNAP 1
Old : H1:GRD-SUS_ITMY_SPM_SNAP       False
New : H1:GRD-SUS_ITMY_SPM_SNAP       True
jameson.rollins@operator1:~ 0$ cat /ligo/cds/lho/h1/guardian/archive/SUS_ITMY/SUS_ITMY.spm
H1:SUS-ITMY_M0_TEST_P_SWSTAT IN,OT,DC
H1:SUS-ITMY_M0_TEST_Y_SWSTAT IN,OT,DC
H1:SUS-ITMY_R0_OPTICALIGN_Y_TRAMP 2.0
H1:SUS-ITMY_M0_OPTICALIGN_P_TRAMP 2.0
H1:SUS-ITMY_M0_TEST_P_TRAMP 2.0
H1:SUS-ITMY_M0_OPTICALIGN_Y_TRAMP 2.0
H1:SUS-ITMY_M0_TEST_Y_TRAMP 2.0
H1:SUS-ITMY_M0_OPTICALIGN_P_SWSTAT IN,OF,OT,DC
H1:SUS-ITMY_M0_OPTICALIGN_Y_SWSTAT IN,OF,OT,DC
H1:SUS-ITMY_R0_OPTICALIGN_P_TRAMP 2.0
jameson.rollins@operator1:~ 0$ 

A '.spm' file is written into the node archive directory (/ligo/cds/<site>/<ifo>/guardian/archive/<node>).  The .spm file is a space-separated list of channel/setpoint pairs.

NOTE: the setpoints are accumulate over the running of the node.  If the node has just been restarted (or the worker restarted after a STOP command has been issues) the setpoint table will be empty until the node passes through states where it actually writes to a channel.   The full set of setpoints will only be fully known once the node runs through all system state code paths.  Guardian has the ability to initialize the full set of setpoints for the node for a pre-defined set of channels, but we're not using that fascility yet.

The setpoint table is also written to the log when an SPM_SNAP is triggered, as is a full list of all PVs subscriptions currently active in the node:

2015-05-06T22:16:20.66686 SUS_ITMY W: PVs:
2015-05-06T22:16:20.66698 SUS_ITMY W:   H1:SUS-ITMY_DACKILL_STATE = 1.0
2015-05-06T22:16:20.66705 SUS_ITMY W:   H1:SUS-ITMY_L1_TEST_L_SW1R = 4.0
2015-05-06T22:16:20.66711 SUS_ITMY W:   H1:SUS-ITMY_L1_TEST_P_SW1R = 4.0
2015-05-06T22:16:20.66717 SUS_ITMY W:   H1:SUS-ITMY_L1_TEST_Y_SW1R = 4.0
2015-05-06T22:16:20.66723 SUS_ITMY W:   H1:SUS-ITMY_L1_WDMON_STATE = 1.0
2015-05-06T22:16:20.66728 SUS_ITMY W:   H1:SUS-ITMY_L2_TEST_L_SW1R = 4.0
2015-05-06T22:16:20.66734 SUS_ITMY W:   H1:SUS-ITMY_L2_TEST_P_SW1R = 4.0
2015-05-06T22:16:20.66740 SUS_ITMY W:   H1:SUS-ITMY_L2_TEST_Y_SW1R = 4.0
2015-05-06T22:16:20.66746 SUS_ITMY W:   H1:SUS-ITMY_L2_WDMON_STATE = 1.0
2015-05-06T22:16:20.66751 SUS_ITMY W:   H1:SUS-ITMY_L3_TEST_BIAS_SW1R = 4.0
2015-05-06T22:16:20.66757 SUS_ITMY W:   H1:SUS-ITMY_L3_TEST_L_SW1R = 4.0
2015-05-06T22:16:20.66763 SUS_ITMY W:   H1:SUS-ITMY_L3_TEST_P_SW1R = 4.0
2015-05-06T22:16:20.66768 SUS_ITMY W:   H1:SUS-ITMY_L3_TEST_Y_SW1R = 4.0
2015-05-06T22:16:20.66775 SUS_ITMY W:   H1:SUS-ITMY_M0_DAMP_L_SW2R = 1728.0
2015-05-06T22:16:20.66781 SUS_ITMY W:   H1:SUS-ITMY_M0_DAMP_P_SW2R = 1728.0
2015-05-06T22:16:20.66787 SUS_ITMY W:   H1:SUS-ITMY_M0_DAMP_R_SW2R = 1728.0
2015-05-06T22:16:20.66792 SUS_ITMY W:   H1:SUS-ITMY_M0_DAMP_T_SW2R = 1728.0
2015-05-06T22:16:20.66798 SUS_ITMY W:   H1:SUS-ITMY_M0_DAMP_V_SW2R = 1728.0
2015-05-06T22:16:20.66804 SUS_ITMY W:   H1:SUS-ITMY_M0_DAMP_Y_SW2R = 1728.0
2015-05-06T22:16:20.66810 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_SW1 = 0.0
2015-05-06T22:16:20.66816 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_SW1R = 12.0
2015-05-06T22:16:20.66821 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_SW2 = 0.0
2015-05-06T22:16:20.66827 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_SW2R = 1536.0
2015-05-06T22:16:20.66833 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_SWSTAT = 302080.0
2015-05-06T22:16:20.66839 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_TRAMP = 2.0
2015-05-06T22:16:20.66845 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_SW1 = 0.0
2015-05-06T22:16:20.66850 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_SW1R = 12.0
2015-05-06T22:16:20.66858 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_SW2 = 0.0
2015-05-06T22:16:20.66870 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_SW2R = 1536.0
2015-05-06T22:16:20.66880 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_SWSTAT = 302080.0
2015-05-06T22:16:20.66891 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_TRAMP = 2.0
2015-05-06T22:16:20.66903 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_L_SW1R = 4.0
2015-05-06T22:16:20.66913 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_SW1 = 0.0
2015-05-06T22:16:20.66923 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_SW1R = 4.0
2015-05-06T22:16:20.66933 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_SW2 = 0.0
2015-05-06T22:16:20.66940 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_SW2R = 1536.0
2015-05-06T22:16:20.66948 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_SWSTAT = 300032.0
2015-05-06T22:16:20.66955 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_TRAMP = 2.0
2015-05-06T22:16:20.66962 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_R_SW1R = 4.0
2015-05-06T22:16:20.66969 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_T_SW1R = 4.0
2015-05-06T22:16:20.66976 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_V_SW1R = 4.0
2015-05-06T22:16:20.66983 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_SW1 = 0.0
2015-05-06T22:16:20.66995 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_SW1R = 4.0
2015-05-06T22:16:20.66998 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_SW2 = 0.0
2015-05-06T22:16:20.67005 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_SW2R = 1536.0
2015-05-06T22:16:20.67013 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_SWSTAT = 300032.0
2015-05-06T22:16:20.67023 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_TRAMP = 2.0
2015-05-06T22:16:20.67027 SUS_ITMY W:   H1:SUS-ITMY_M0_WDMON_STATE = 1.0
2015-05-06T22:16:20.67037 SUS_ITMY W:   H1:SUS-ITMY_MASTERSWITCH = 1
2015-05-06T22:16:20.67044 SUS_ITMY W:   H1:SUS-ITMY_R0_DAMP_L_SW2R = 1728.0
2015-05-06T22:16:20.67048 SUS_ITMY W:   H1:SUS-ITMY_R0_DAMP_P_SW2R = 1728.0
2015-05-06T22:16:20.67055 SUS_ITMY W:   H1:SUS-ITMY_R0_DAMP_R_SW2R = 1728.0
2015-05-06T22:16:20.67062 SUS_ITMY W:   H1:SUS-ITMY_R0_DAMP_T_SW2R = 1728.0
2015-05-06T22:16:20.67070 SUS_ITMY W:   H1:SUS-ITMY_R0_DAMP_V_SW2R = 1728.0
2015-05-06T22:16:20.67077 SUS_ITMY W:   H1:SUS-ITMY_R0_DAMP_Y_SW2R = 1728.0
2015-05-06T22:16:20.67088 SUS_ITMY W:   H1:SUS-ITMY_R0_OPTICALIGN_P_SW1R = 12.0
2015-05-06T22:16:20.67172 SUS_ITMY W:   H1:SUS-ITMY_R0_OPTICALIGN_P_TRAMP = 2.0
2015-05-06T22:16:20.67187 SUS_ITMY W:   H1:SUS-ITMY_R0_OPTICALIGN_Y_SW1R = 12.0
2015-05-06T22:16:20.67198 SUS_ITMY W:   H1:SUS-ITMY_R0_OPTICALIGN_Y_TRAMP = 2.0
2015-05-06T22:16:20.67210 SUS_ITMY W:   H1:SUS-ITMY_R0_TEST_L_SW1R = 4.0
2015-05-06T22:16:20.67226 SUS_ITMY W:   H1:SUS-ITMY_R0_TEST_P_SW1R = 4.0
2015-05-06T22:16:20.67229 SUS_ITMY W:   H1:SUS-ITMY_R0_TEST_R_SW1R = 4.0
2015-05-06T22:16:20.67239 SUS_ITMY W:   H1:SUS-ITMY_R0_TEST_T_SW1R = 4.0
2015-05-06T22:16:20.67250 SUS_ITMY W:   H1:SUS-ITMY_R0_TEST_V_SW1R = 4.0
2015-05-06T22:16:20.67261 SUS_ITMY W:   H1:SUS-ITMY_R0_TEST_Y_SW1R = 4.0
2015-05-06T22:16:20.67275 SUS_ITMY W:   H1:SUS-ITMY_R0_WDMON_STATE = 1.0
2015-05-06T22:16:20.67287 SUS_ITMY W: SPMs:
2015-05-06T22:16:20.67316 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_SWSTAT = IN,OF,OT,DC
2015-05-06T22:16:20.67326 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_P_TRAMP = 2.0
2015-05-06T22:16:20.67353 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_SWSTAT = IN,OF,OT,DC
2015-05-06T22:16:20.67363 SUS_ITMY W:   H1:SUS-ITMY_M0_OPTICALIGN_Y_TRAMP = 2.0
2015-05-06T22:16:20.67393 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_SWSTAT = IN,OT,DC
2015-05-06T22:16:20.67397 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_P_TRAMP = 2.0
2015-05-06T22:16:20.67424 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_SWSTAT = IN,OT,DC
2015-05-06T22:16:20.67432 SUS_ITMY W:   H1:SUS-ITMY_M0_TEST_Y_TRAMP = 2.0
2015-05-06T22:16:20.67436 SUS_ITMY W:   H1:SUS-ITMY_R0_OPTICALIGN_P_TRAMP = 2.0
2015-05-06T22:16:20.67446 SUS_ITMY W:   H1:SUS-ITMY_R0_OPTICALIGN_Y_TRAMP = 2.0
2015-05-06T22:16:20.67455 SUS_ITMY W: 66 PVs, 10 SPMs
2015-05-06T22:16:20.67828 SUS_ITMY W: SPM snapshot: /ligo/cds/lho/h1/guardian/archive/SUS_ITMY/SUS_ITMY.spm

H1 AOS
jason.oberling@LIGO.ORG - posted 17:18, Wednesday 08 April 2015 - last comment - 05:16, Wednesday 06 May 2015(17760)
SR3 Optical Lever Laser Replacement

J. Oberling, S. Doravari

With the HAM6 activity closing out, we took advantage of the window and tweaked another laser and swapped it into SR3.  The SN of the new laser is 199.  This was installed in the SR3 optical lever so we will have data for a direct comparison between the stabilized diode laser here at LHO and the fiber-coupled HeNe in use as the LLO SR3 optical lever.  We will begin monitoring this laser tomorrow after it thermally stabilizes overnight so we can perform, if necessary, final tweaks to the laser power to finally stabilize the laser.

Comments related to this report
suresh.doravari@LIGO.ORG - 18:06, Wednesday 08 April 2015 (17762)

Just attaching images associated with this work.

1) SR3 Oplev laser currently installed is Sl. No. 199

2) The binary switch state for setting gain and whitening.  Currently there is just 3dB of gain and no whitening

3) power spectra of adc noise floor and sum signal to show that the signal is atleast ten times larger than the noise floor at all frequencies of interest

Images attached to this comment
evan.hall@LIGO.ORG - 05:16, Wednesday 06 May 2015 (18268)

It seems there is a discrepancy between the SR3 pitch slider and the SR3 oplev motion. I move the pitch slider by what I think is 0.5 µrad, and the oplev reports that SR3 moves by 0.2 µrad. Not sure about yaw.

Images attached to this comment
Displaying reports 65321-65340 of 83122.Go to page Start 3263 3264 3265 3266 3267 3268 3269 3270 3271 End