Displaying reports 39081-39100 of 89038.Go to page Start 1951 1952 1953 1954 1955 1956 1957 1958 1959 End
Reports until 17:24, Friday 23 August 2019
H1 DetChar (DetChar, ISC, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 17:24, Friday 23 August 2019 - last comment - 18:02, Friday 23 August 2019(51479)
Unknown Time Dependent Broadband Noise in DARM
J. Kissel, R. Schofield, K. Merfeld, M. Ball, A. Helmling-Cornell

After Robert completed his studies, I glanced up and saw the spectrum had some terrible broadband noise, killing our range. And then it changed. Trends seem to show that it's been a part of this lock-stretch (including observation time) all along.
Attached are DELTAL_EXTERNAL ASDs of the few times I looked up.

Needs further investigation!

All of Robert's test equipment is OFF. 
Looked at ETMX driver low pass state, it's ON, in the correct configuration.
Now SDF differences with settings (or else we wouldn't have been able to go in to observation ready).
No glitching in the BRS (wouldn't cause this kind of broadband noise anyways).

The last lock loss from observation ready was sudden, with unknown cause... maybe something broke?

Investigtion continues. We've launched a BRUCO, results soon to come...
Images attached to this report
Comments related to this report
adrian.helmling-cornell@LIGO.ORG - 17:41, Friday 23 August 2019 (51480)

It glitched again in the same manner at 00:32:12 UTC,

jeffrey.kissel@LIGO.ORG - 17:50, Friday 23 August 2019 (51481)
Since this looks like a force noise, and my spider-sense thinks this is some sort of electronics failure, I trended the coil current for the ETMX PUM and ETMX TST (i.e. the primary stages of the DARM actuator), and found nothing that didn't look the same is it did in the previous lock stretch. See attached.
Images attached to this comment
kara.merfeld@LIGO.ORG - 17:58, Friday 23 August 2019 (51482)
Here are some dtt's of the broadband moise in the darm spectrum.  I had a look at the spectrum during the unexplained range drop from Niko's alog 51400.  These ones we're having now seem to be at a lower frequency.
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 18:02, Friday 23 August 2019 (51485)
Sheila to the rescue -- the ALS X shutter was open. (And the clue came from ALS X trying to lock, which changed the ALS X SERVO GAIN and knocked us out of observation intent...)

Shutter is now closed and DELTAL_EXTERNAL is back to normal.

Now investigating why the shutter didn't get closed during these sets of lock acquisitions............
H1 General
travis.sadecki@LIGO.ORG - posted 16:52, Friday 23 August 2019 (51478)
Observing at 23:51 UTC

PEM crews has wrapped up for the day.

H1 OpsInfo
sheila.dwyer@LIGO.ORG - posted 16:23, Friday 23 August 2019 (51474)
moving AS36 offset ramp off

Patrick, Jeff K, Sheila

After the lockloss this afternoon Patrick had two locklosses in a row in the state PREP_ASC_FOR_FULL_IFO.  (1250631114 and 1250630221).  The only thing that really was changing about the IFO state in PREP_ASC was that we were turning off the offsets in AS36 that are set after the DRMI ASC is run (with BS controlled by AS45) before we change to the AS36 sensors.  These offsets were particularly large today. 

After a seemingly unrelated lockloss at DHARD, we ran PREP_ASC manually leaving the offsets on, and manually turned them off after ENGAGE_ASC, which did make the POP18 + POP90 build ups worse but we were able to survive. 

I've now moved the ramping off of these offsets toward the end of ENGAGE_ASC, so I am hoping that we can see fewer of these locklosses in PREP_ASC. 

H1 General
travis.sadecki@LIGO.ORG - posted 16:19, Friday 23 August 2019 (51475)
Ops Eve Shift Transition

TITLE: 08/23 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 13mph Gusts, 10mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:  PEM crew is working hence being in Commissioning mode despite having just reacquired lock.

H1 ISC (GRD, ISC, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 16:17, Friday 23 August 2019 - last comment - 16:49, Friday 23 August 2019(51472)
Re-occuring ALS EX / EY SDF DIFF Caused by Floating Point Precision Comparisons. Fixed By Rounding Values to 1e-6 Precision
J. Kissel

There have been many times since we re-adjusted the initial alignment settings (last done Thursday Aug 15 2019; see LHO aLOG 51307), that the ALS EX and ALS EY front-end models show SDF differences at the 1e-17 - 1e-18 level. This is a result of the python scripts we use to set the initial alignment references -- in particular the transmon (TMS) green QPD offsets --

    /opt/rtcds/userapps/trunk/als/h1/scripts/
        setEndGreenQPDOffsets_XARM.py
        setEndGreenQPDOffsets_YARM.py
    
not rounding before installing to any reasonable precision before writing the numbers to EPICs.

As a quick fix, I manually rounded and entered the numbers in to the respective EPICs channels. Attached are screenshots of the SDF diffs after rounding, mostly to prove to you and me that I didn't make a typo in doing so (which would botch the initial/global alignment references -- a think I *definitely* don't want to do at 4p PDT on a Friday).

The long term fix will be to edit the above scripts, but since we don't plan on updating the initial alignment references again any time soon, the quick fix should suffice until we get to editing the script.
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:49, Friday 23 August 2019 (51476)ISC, OpsInfo
J. Kissel, S. Dwyer

The future is now! With the watchful eye of Sheila, I edited the above mentioned X and Y arm codes such that once the transmitted (green) Arm Power is above 0.9 [normalized counts], and the I phase outputs of the (green) WFS A and B are less than 10 [DAC counts], then
 (a) read the current offsets,
 (b) round the QPD offsets to a precision of 1e-6
 (c) write those rounded offsets, and
 (d) break out of the while loop

(a), (b), and (c) are all done in one line via the magic of ezca python bindings, and (d) is new -- the script used to just ask the user to CTRL+C out of the script.

This code change is completely untested, and again we likely won't use it for another 3-6 months, but hopefully I've left enough breakcrumbs in 
 - this aLOG,
 - the instructions that reference these scripts, LHO aLOG 50968,
 - the comments of the code, and 
 - in the log of the svn commit 
that people will come find me when it doesn't work. Apologies in advance!
LHO General
patrick.thomas@LIGO.ORG - posted 16:15, Friday 23 August 2019 (51473)
Ops Day Shift Summary
TITLE: 08/23 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Travis
SHIFT SUMMARY: Just relocked. Robert has started PEM commissioning work. Had trouble relocking past PREP_ASC_FOR_FULL_IFO. Sheila took the guardian to manual through this step and skipped some gains. This seemed to work, but not clear if coincidence.
LOG:

15:55 - 16:08 UTC Richard to mid X
16:05 - 17:39 UTC Peter to optics lab
16:21 UTC Vanessa to mid X
18:28 UTC Beckhoff corner station error verbal alarm. Not sure what this referred to.
18:29 - 19:14 UTC Richard to mid X
20:05 - 20:36 UTC Peter to optics lab
20:48 UTC Lock loss
20:49 UTC Matt to LVEA
20:55 UTC Reloaded guardian nodes as requested by Sheila (alog 51465)
Moved ETMY for green arm alignment
21:07 UTC Robert and Kara to LVEA
Lock loss from PREP_ASC_FOR_FULL_IFO
Lock loss from PREP_ASC_FOR_FULL_IFO
Lock loss from DHARD_WFS
22:08 - 22:26 UTC Robert and company to LVEA
23:07 UTC Set observatory mode to commissioning for PEM work
LHO VE
chandra.romel@LIGO.ORG - posted 15:43, Friday 23 August 2019 (51470)
VBOC down

Vacuum bake oven C is currently out of order. It appears the RGA isolation valve is leaky and needs to be replaced.

H1 CDS
david.barker@LIGO.ORG - posted 14:56, Friday 23 August 2019 (51468)
Introducing Lock Loss Alert Subscription Service

Betsy, Dave:

I have written a python programme which permits observatory staff to sign up to be notified when H1 loses lock. It has an EPICS interface, and is controlled and monitored by a MEDM screen (see attachment).

The MEDM is launched from the SITEMAP under the OPS button.

When H1 loses lock, a counter is started. If the counter exceeds the alert time (currently 2 minutes), alerts are sent to any selected clients. An email is always sent, and optionally a cell phone text message can also be sent if that option is turned on.

The system can be completely disabled with the master enable button.

The alerts will not be sent outside of the time window defined by the START and END settings (currently alarms sent between 8am and 11pm).

If you would like to be added to this system, please contact me.

From the attachment you can see I have tested it with Robert this afternoon.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 14:45, Friday 23 August 2019 - last comment - 14:59, Friday 23 August 2019(51467)
Updated Figure Of Merit Image Snapshots

As we replace the aging Mac Mini computers (MacOS) with Nuc computers (Debian9) our current snapshot script was generating a single png for both monitor images. This resulted in strange pairings, like the wind speed plot and the vacuum overview.

I rewrote the script today. It finds the number of monitors the computer has, and their layout. It then generates a PNG file per monitor, using the old MacOS standard naming of hostname-mon.png, e.g. nuc23-1 and nuc23-2.

I then revamped the CDS web page which lists the FOM thumbnails and links, because it was not complete, and did not have a logical layout.

As a test, I have grouped the images to be the same as their physical layout in the control room. Please email me if a different layout is preferred.

ControlRoomScreens

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 14:59, Friday 23 August 2019 (51469)

I'm also in the process of updating the FOM wiki page.

H1 GRD (GRD, Lockloss)
sheila.dwyer@LIGO.ORG - posted 11:42, Friday 23 August 2019 - last comment - 17:27, Wednesday 28 August 2019(51465)
making sure DOWN gets run for subordinate guardians

Jamie, Sheila,

Each time we run an initial alignment, it seems that we loose lock in the early stages of the CARM offset reduction in the the next locking attempt, although these steps are otherwise quite reliable, so it seems as though some setting is not being set correctly after initial alignment is run until the IFO looses lock once. 

After we run initial alignment, we do run the down state of ISC_LOCK, which requests 'DOWN' from several of its subordinate guardians, however, since some of these guardians are already in the DOWN state making the request doesn't cause them to re-run their main states, where the settings get reset.  (For a similar situation and a different solution see 49520 and comments). Yesterday I tried to look manually at the ALS_COMM and IMC_LOCK down states, but catch the problem with my first look.  Patrick also tried to use SDF to find the probelm setting yesterday, 51452 but that didn't show us anything obviously wrong either.

On the phone Jamie told me that when the guardian code was changed so that re-requesting a state doesn't cause the state to be re-run (which was a change that solved problems with having code that isn't idempotent), he added a feature that would allow us to choose the old behavoir for certain states, by adding an edge from that state to itself.  In that case if the guardian is in DOWN and gets a request for DOWN it will re-run its main state. 

So, I've added paths from DOWN to DOWN in ALS_COM, ALS_DIFF, ISC_DRMI, IMC_LOCK, FAST_SHUTTER, and OMC_LOCK.  IMC_LOCK doesn't get sent to DOWN in the DOWN state of ISC_LOCK, so that if the mode cleaner is already locked after initial alignment runs we don't unlock it, and I haven't changed that, I simply added the edge from DOWN to DOWN. 

So, the next time that we have a chance, (when we are out of observing) I'd like to load all of these guardians.  Then we can see if this will solve the problem of loosing lock on the first attempt after initial alignment. 

Comments related to this report
sheila.dwyer@LIGO.ORG - 15:44, Friday 23 August 2019 (51471)OpsInfo

Patrick loaded these changes after a lockloss, and didn't have guardian problems when relocking.  

Request for operators:  I am hoping that this might solve the problem of the IFO lossing lock in the early CARM reduction steps in the first locking attempt after each time we run initial alignment.  I would appreciate if you would report relocking attempts over the weekend, including if you run initial alignment, and if on the first relocking attempt you make it to the CARM offset reduction do you survive those steps?

As a reminder, there is a spreadsheet which could be used to help us keep track of problems encountered when relocking:

https://docs.google.com/spreadsheets/d/1byXR-s2ATegciJCEjORb1FEZhZTp77j6DS-fZuvEY-8/edit#gid=0

sheila.dwyer@LIGO.ORG - 17:27, Wednesday 28 August 2019 (51591)

In the first locking attempt after Tuesday maintence, initial alignment was run, and the interferometer was relocked without loosing lock, on the first attempt https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=51561 (Also confirmed by trending the guardian state at the times Jeff aloged)

This means that this solution has worked, and we shouldn't have these failed locking attempts after each initial alignment. 

LHO General
patrick.thomas@LIGO.ORG - posted 08:04, Friday 23 August 2019 (51464)
Ops Day Shift Transition
TITLE: 08/23 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 3mph Gusts, 0mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.12 μm/s 
QUICK SUMMARY: No issues.
LHO General
thomas.shaffer@LIGO.ORG - posted 07:53, Friday 23 August 2019 (51463)
Ops Owl Shift Summary

TITLE: 08/23 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: 15.5 hours of observing.

H1 General
thomas.shaffer@LIGO.ORG - posted 05:42, Friday 23 August 2019 (51462)
Mid-shift Report

Locked and observing for 13 hours @115Mpc.

LHO General
thomas.shaffer@LIGO.ORG - posted 00:13, Friday 23 August 2019 (51461)
Ops Owl Shift Transition

TITLE: 08/23 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 6mph Gusts, 6mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY: Calm environment, 7.5 hours lock.

H1 ISC (CAL, ISC)
jeffrey.kissel@LIGO.ORG - posted 11:37, Wednesday 21 August 2019 - last comment - 14:45, Friday 23 August 2019(51440)
IFO's DARM Opto-mechanical Response (Sensing Function) Vs. Spot Position and SRCL Offset
S. Dwyer, J. Kissel

We've repeated Monday's measurements (see LHO aLOG 51393) of the IFO's DARM Opto-mechanical Response (Sensing Function) Vs. SRCL Offset now at the "July" spot positions (where Monday's were at the "August" positions -- see attachments to LHO aLOG 51436 for what this means in terms of A2L gains).

There is similar drastic impact on the sensing function. 

See attached: 2019-08-21_H1_100ctSRCLOffset_sensingFunction_referenceModel_vs_allMeasurements.pdf
I'm again using the "No Spring" loop model, which has 
      H_c   Optical Gain              3.13e6 [ct/m]
      f_cc  Cavity Pole Frequency     411 [Hz]
and *no* optical spring from SRC detuning, in order to emphasize / better quantify the effects of either actual detuning or remaining L2A2L issues.

In the July Spot positions, with a 100 ct SRCL offset, both of these effects are minimized, and the sensing function appears quite flat, where the other three configurations have interesting features. In fact, the cavity pole frequency also best matches the model at 411 Hz in the July positions and with a 100 ct offset, where the other configurations have lower frequency (the worst being 395 Hz from Monday's Aug positions and no SRCL offset [determined by "by-hand" fitting from LHO aLOG 51393]). 

Looking at the phase, my preliminary interpretation of these data are that 
    (a) Changing the spot position moves the detuned spring frequency to lower frequency but keeps the detuning Q / amplitude level about the same, and
    (b) Adjusting the SRCL offset reduces "the amount" (the Q and amplitude) of detuning.

I'm not yet ready to say this is definitively true, since -- in the beginning of O3 up to July 31, the low-frequency response was bouncing around from week to week (see LHO aLOG 50498), which may be a result of the L2A2L issues. Monday's measurement of Aug spot positions with 100ct SRCL offset show evidence of the "unphysical" phase turn-up and funky magnitude response, yet today's July spot positions, with no SRCL offset don't appear reproduce the unphysical issues -- when we would expect them to be quite similar to all previous O3 sensing function measurements before the spot move.

More to come, I'm sure...
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 14:45, Friday 23 August 2019 (51466)CAL, ISC
J. Kissel

In the above aLOG, I've compared all of the measurements to the same, no spring, low-frequency optical response model to emphasize how much it changes with spot position and srcl offset. We see that there is not only a spring-like effect, but also some (what we believe to be) parasitic L2A2L coupling of some unknown shape or form (especially evident in the requested 100ct SRCL Offset, August Spot position data).

We also know that our MCMC algorithm for fitting this data, for which we only give it the poles and zeros to model a spring (2 zeros at 0.0 Hz, and an arbitrary set of complex poles at frequency f_s with phase separation defined by Q), cannot accurately give us approximations for what at least the spring part is doing because it's getting confused by the parasitic L2A2L response.

However, in order to make progress on how much detuning we have, and how the requested 100 ct SRCL offset changes that detuning in physical units, we need *something*.

So -- I've noodled around with the optical plant parameters that we *do* have in order to make a "best" by-hand fit of the data. Here, "best" is based on minimizing the residual (ratio) between measurement and model, acknowledging that I will never be able to get an actually good fit, because I'm not using enough poles and zeros to cover the L2A2L effect. Also, acknowledge that my by-eye happiness is determining the uncertainty in the parameters, so we have no nice neat, multi-dimensional posterior distribution that exposes the (very real) covariance between the parameters.

Given those caveats, I attach the results.

Here's a table of the resulting fit parameters.
                                                                 No Offset                    100 ct SRCL Offset
                                                         Aug spots       Jul Spots        Aug Spots      Jul Spots
    optical gain, H_c               [1e6 ct/m]           3.13 (0.01)     3.16 (0.01)      3.13 (0.01)    3.16 (0.01)
    caviy pole frequency, f_cc      [Hz]                 395  (3)        405  (3)         409  (3)       415  (3)
    optical spring frequency, f_s   [Hz]                 7.2  (0.5)      6.0  (0.5)       5.0  (1.0)     0.0  (1)
    optical spring quality, Q       [n.a.]               10   (5)        35   (5)         10   (5)       1.0  (1)
    spring type                     [n.a.]               pro             pro              anti?          no?
    measurement date                [YYYY-MM-DD]         2019-08-19      2019-08-21       2019-08-19     2019-08-21
    attachment page                 page 1               page 2          page 3           page 4

Again, in the 100ct SRCL offset data, there's not enough poles and zeros in the fit, and/or not a visible enough spring to really trust the spring-related assessment last two columns, and I thoroughly recommend we map out the parameter space better and develop a model (or get rid of) the supposed L2A2L coupling so we can really do a proper fit on this.

We can at least confidently say that Jul spot positions, with a requested 100 ct SRCL offset is best for the optical gain and cavity pole.
Non-image files attached to this comment
H1 General
jim.warner@LIGO.ORG - posted 15:08, Thursday 01 August 2019 - last comment - 14:31, Thursday 30 June 2022(50967)
ALS SDF diffs after updating initial alignment references

Back to NLN, Jenne and Jeff have updated ALS references, SDF diffs in attached screenshots.

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 16:28, Thursday 01 August 2019 (50968)

JeffK noted that we don't have a good all in one place how-to on setting the initial alignment offsets.  So, here's an attempt at it.  This assumes that the QPDs are all close enough to center (or can be made to be so by moving TMS) that you do not need to use the picomotors.  Using the picos requires more thought and care.

The attachment is my desktop when I'm doing this, so you can see all of the windows that I'm looking at. 

  • ndscopes:
    • bottom left: reacquire lock 'scope from my Locking screen
    • bottom middle: ADS 'scope from my Locking screen
    • right side: New template in ..../jenne.driggers/Templates/Scope/green_wfs_setpoints.yml
  • medm screens:
    • sitemap, just because I always have the sitemap open
    • ALS camera setpoint screens, from each ALS end overview screen, then CAM ITM PIT green button.
    • tiny A2L screen: these are the A2L spot position gains from each test mass's PUM stage.  You can pull them each open individually from each SUS, or get this compact screen from my Locking screen, near the top right.
    • Compact QPD screen for the 4 IR transmon QPDs, to make sure that we're not falling off the IR QPDs.  Get this from my Locking screen, "ASC Pointing" button.
    • Green QPD offset sliders, get from either of the ALS end overview screens.
    • Sliders for the 2 TMSs.
  • Terminal windows:
    • One running setEndGreenQPDOffsets_XARM.py
    • One running setEndGreenQPDOffsets_YARM.py

Process for each arm (can be done in parallel since each arm is independant of the other for this work):

  • Ensure IFO is at 2W with all ASC engaged and converged (DC readout is a good spot for this).  Make sure that the ADS error signals are close to zero.
  • Ensure green shutters are open (sitemap -> LSC -> Shutters, then "Open" on the two shutters in the second from right column)
  • Ensure that the green laser is locked on the TEM00 mode to the cavity.
    • If it is not, you can noodle around the green QPD offset sliders.  Since these are in-loop with the pointing PZTs on the ALS in-air table, this effectively changes the pointing of the green laser into the vacuum, and into the cavity.
  • Run the setEndGreenQPDOffsets_[X,Y]ARM.py script, which will adjust the green QPD offset sliders to adjust the green laser input pointing to match the arm cavity (the metric in the script is zeroing the ALS WFS signals on the bottom row of the right-most ndscope). 
    • Watch the QPD offsets to make sure they aren't moving the spots too close to the edges of the QPDs.  Top two rows of the rightmost ndscope have Ylims set to +/-1, so it should be easy to tell when you're getting too close.  The third row is the sum of light on the QPDs, so you know that if that starts dropping you're getting too close to the edge.  We've been operating at offsets of more than 0.8 for all of O3, so while that's not great, it's not unacceptable (since these are unused in Observation mode).
  • Slowly move the TMS (steps of 0.1 urad seem fine with the standard 2 sec ramp) to get the beam closer to center on the IR QPDs.  Hopefully the green offset script will be pulling the green offsets closer to center, if they were close to their edges.  If they don't, you should stop here and reconsider things.  You may need to use the picos. 
  • Once you've got the TMS moved to center the IR QPDs and the script has converged such that the green wfs signals are close to zero, you should set the camera offsets.
  • Now, you're done and you should ensure that your new setpoints are saved in the down and observe SDF snapshots of the ALS end stations.

If you must pico, I'd recommend only pico-ing the IR QPDs since they're much easier to think about and independent of other beams.  I'd start the green QPD setpoint scripts to make the green QPDs follow your movement.  Then I'd make a small step in TMS alignment in the direction that will put the green QPD offsets closer to zero, and then pico the IR steering picos to get the IR QPDs closer to zero.

 

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 16:51, Friday 23 August 2019 (51477)ISC, OpsInfo
I've edited the code that sets the green QPD offsets (/opt/rtcds/userapps/trunk/als/h1/scripts/setEndGreenQPDOffsets_XARM.py and setEndGreenQPDOffsets_YARM.py) -- check out LHO aLOG 51476 for further commentary.
sheila.dwyer@LIGO.ORG - 17:59, Monday 18 November 2019 (53335)

This procedure needs to be modified because we are now setting green references with our spots centered on the optics.  We would like to center the IR on the IR QPDs once we have our spots in their final positions, however, not necessarily with the spots centered.

jenne.driggers@LIGO.ORG - 19:02, Wednesday 29 January 2020 (54800)

Since Craig added in the TMS servoing to center the IR QPD, we should still be able to follow this procedure at DC readout.  At DC readout, in the current situation, we are servoing the spots to the centers of all 4 test masses at 2W input power.  This is the position we want to set the initial alignment references to. 

Later in the acquisition sequence the power is increased to 10W, and then the beam spots are moved to their final high power positions, then we further increase the power and continue on to NomLowNoise.

sheila.dwyer@LIGO.ORG - 14:31, Thursday 30 June 2022 (63785)

Before setting the green camera references, we should remember to check that the camera image is good and that any mask applied is appropriate.  We can check this by opening up the digital camera screen and taking a snapshot, then finding the snapshot in /ligo/data/camera

 

Displaying reports 39081-39100 of 89038.Go to page Start 1951 1952 1953 1954 1955 1956 1957 1958 1959 End