Displaying reports 40501-40520 of 88906.Go to page Start 2022 2023 2024 2025 2026 2027 2028 2029 2030 End
Reports until 16:09, Thursday 13 June 2019
LHO General
thomas.shaffer@LIGO.ORG - posted 16:09, Thursday 13 June 2019 (49895)
Ops Eve Shit Transition

TITLE: 06/13 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 112Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    Wind: 22mph Gusts, 18mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY: Just received a GRB and we will stand down for 15min. The lock is over 24hrs old, it is breezy outside.

LHO General
corey.gray@LIGO.ORG - posted 16:02, Thursday 13 June 2019 (49886)
DAY Operator Summary

TITLE: 06/13 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

H1 has been locked ~26.25hrs; range has been trending a little down, but this could coincide with the the winds which started 6hrs ago.  Handed off request for TJ to find new locking point for TCSy CO2 laser.
LOG:

H1 ISC
jenne.driggers@LIGO.ORG - posted 15:40, Thursday 13 June 2019 - last comment - 17:29, Thursday 13 June 2019(49894)
New LSC feedforward, good for MICH, iffy for SRCL

[Laurence, Jenne]

We've recently imported V2 of Lee's IIRrational, and have been updating the feedforward fitting scripts to work with it (with lots of great support from Lee), and have applied it to feedforward measurements taken on Monday, after we'd thermalized at the new PSL power of 37W. 

Today we took a few minutes of pre-approved commissioning time to switch to the new MICH and SRCL feedforward filters.  The attached screenshot shows that the MICH filter is doing some good, however the SRCL filter is doing more harm than good.  I'd like to leave it on for a little while, but since we've got another pre-approved commissioning time once the Evening operator arrives to help the TCS CO2 laser, I'll likely revert the SRCL filter. 

In the attached plot, upper left shows LSC-DARM_OUT and the MICHFF and SRCLFF outputs that get sent to the ETMs to sum in with DARM.  References are all on the old 35W filters, current traces are the new filters.  You can see that there isn't much difference with the MICH output, but the SRCL output is much larger at low frequencies, and slightly larger at high frequencies. 

Upper right shows the difference in the calibrated Darm spectrum, that we've improved a bit between 10Hz - 15Hz, and above that any changes are quite subtle.  We've definitely degraded the spectrum below 9 Hz (the SRCL fit really, really wants to give a highish-Q peak there, to get the fit better above 10 Hz), which will contribute to upconversion around lines in the bucket.

Lower left shows the coherence between SRCL and DARM, and you can see that between 10-15 Hz, we've made an improvement, but both below and above that we have significantly hurt things, which is why I will revert the SRCL FF in 30 min or so.

Lower right, however, shows that the coherence between MICH and DARM is improved between 10-25 Hz, so that seems good. 

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 17:29, Thursday 13 June 2019 (49899)

The SRCL FF has been reverted for now.  We've lost that bit of improvement from 10-15Hz, but I think we don't want to be injecting as much noise as we were at lower freqs, so we'll keep working offline on a better version of the fit.

H1 ISC (CAL, CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 15:14, Thursday 13 June 2019 (49893)
Channels Not Monitored and Not touched by Guardian -- SDF list Clean up for ISC
J. Kissel, S. Dwyer

Dave have recently found that there are a small collection of EPICs settings that are both NOT touched by Guardian and NOT monitored in the SDF system (see O3SDFReview in the CDS wiki). Today, during the commissioning period, Sheila and I reviewed and either monitored or justified why to leave them unmonitored for those channels in the ISC models. In summary -- we found most channels should either just be monitored and the remaining ARE touched by the guardian and there's a flaw in the script that determines whether the channels are touched by guardian. Where the latter is the case, we've indicated the guardian node, in which state its touched, and the line on which the channel is exercised.


h1lsc.txt
    BUG IN SCRIPT. THESE IS TOUCHED BY GUARDIAN.
        H1:LSC-TR_CARM_OFFSET        --- 1518 in ISC_LOCK (in CARM_ON_TR).
        H1:LSC-TR_X_QPD_B_SUM_OFFSET --- 1373 in ISC_LOCK (in PREP_TR_CARM)
        H1:LSC-TR_Y_QPD_B_SUM_OFFSET --- 1373 in ISC_LOCK (in PREP_TR_CARM)
        H1:LSC-XARM_OFFSET           --- 1482 in ISC_LOCK (in START_TR_CARM)

h1omc.txt
    BUG IN SCRIPT. THESE IS TOUCHED BY GUARDIAN.
        H1:OMC-READOUT_ERR_NULL_GAIN --- BUG IN SCRIPT. THIS IS TOUCHED BY GUARDIAN. 3185 in ISC_LOCK (DARM_to_DC_READOUT)
        H1:LSC-ARM_INPUT_MTRX_1_1    --- BUG IN SCRIPT. THIS IS TOUCHED BY GUARDIAN. 3083 in ISC_LOCK (PREP_DC_READOUT_TRANSITION)
        H1:OMC-READOUT_X0_OFFSET     --- BUG IN SCRIPT. THIS IS TOUCHED BY GUARDIAN. 2397, 2400, 2403, 2406 in ISC_LOCK (DARM_OFFSET)

    Now Monitored
        H1:OMC-READOUT_SIMPLE_NULL_TRAMP      (should not be changing during observe. should be monitored)
        H1:OMC-READOUT_SIMPLE_NULL_OFFSET          |
        H1:OMC-READOUT_SIMPLE_NULL_GAIN            |
        H1:OMC-READOUT_SIMPLE_NULL_LIMIT           |
        H1:OMC-READOUT_ERR_NULL_TRAMP              | 
        H1:OMC-READOUT_ERR_NULL_OFFSET             |
        H1:OMC-READOUT_ERR_NULL_LIMIT              |
    
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM02       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM03       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM04       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM05       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM06       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM07       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM08       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM09       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_FM10       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_INPT       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_OFFS       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_OUTP       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_LIMT       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_DECM       |
        H1:OMC-READOUT_SIMPLE_NULL_SW1S_HOLD       |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM01          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM02          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM03          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM04          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM05          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM06          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM07          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM08          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM09          |
        H1:OMC-READOUT_ERR_NULL_SW1S_FM10          |
        H1:OMC-READOUT_ERR_NULL_SW1S_INPT          |
        H1:OMC-READOUT_ERR_NULL_SW1S_OFFS          |
        H1:OMC-READOUT_ERR_NULL_SW1S_OUTP          |
        H1:OMC-READOUT_ERR_NULL_SW1S_LIMT          |
        H1:OMC-READOUT_ERR_NULL_SW1S_DECM          |
        H1:OMC-READOUT_ERR_NULL_SW1S_HOLD          V


h1alsey.txt
    Now monitored 
        H1:ALS-Y_QPD_A_PIT_OFFSET             (Offsets imperative for initial alignment, are only occasionally updated and should not be changing in observe)

h1alsex.txt
    Now monitored 
        H1:ALS-X_QPD_A_PIT_OFFSET             (Offsets imperative for initial alignment, are only occasionally updated and should not be changing in observe)
        H1:ALS-X_QPD_B_YAW_OFFSET             (Offsets imperative for initial alignment, are only occasionally updated and should not be changing in observe)

h1omcpi.txt
    Now Monitored
        H1:OMC-PI_DOWNCONV_DC3_SIG_SW1S_FM01  (unused and wouldn't affect anything if change, so monitor to make this check happy)
        H1:OMC-PI_DOWNCONV_DC3_INP_SW1S_FM01  (same as above) 

Also, we've come to the conclusion that everything in the no-longer-used h1susprocpi.txt model should be monitored. 
LHO General
corey.gray@LIGO.ORG - posted 12:02, Thursday 13 June 2019 (49890)
Mid Shift Status

H1 running on a lock just over 22hrs.  Had another TCSy laser drop out of Observing.  Winds are picking up slightly & temperature is hovering near 90degF.

H1 TCS (TCS)
corey.gray@LIGO.ORG - posted 11:44, Thursday 13 June 2019 - last comment - 11:13, Thursday 20 June 2019(49888)
H1 Dropped Out Of OBSERVING Due To Another TCS_ITMY_CO2 Guardian Node Not Being OK

18:31:36-18:32:58 Out of OBSERVING

Once again H1 was dropped out of OBSERVING (for ~82 secs) due to the another case of the laser unlocking (lasted ~6hrs since last occurence)  as mentioned in Jim's shifts.  Saw same symptoms as Jim:

Comments related to this report
aidan.brooks@LIGO.ORG - 11:50, Thursday 13 June 2019 (49889)

[Aidan]

TCS crew is looking into this.

aidan.brooks@LIGO.ORG - 13:10, Thursday 13 June 2019 (49891)

The issue of the TCS CO2 laser reacquiring lock is a known operational state. The instances in which it has occured in the last few years are summarized in the following table. Except for recently, it looks like it's occuring roughly once a month during observing.

Date aLOG Note
13-June-2019 49877 Several drops from OBSERVING
28-May-2019 49501 Manual set of lock-point
25-April-2019 48775 Dropped out of OBSERVING
29-Mar-2019 48017 Several drops from OBSERVING
6-Jan-2019 46251 CO2 lock-loss issue during commissioning
5-June-2018 42339 Restart of Guardian node
6-May-2017 36059 Dropped out of OBSERVING
4-April-2017 35329 Dropped out of OBSERVING
16-Mar-2017 34871 Dropped out of OBSERVING
3-Feb-2017 33875 Dropped out of OBSERVING
24-Jan-2017 33576 Dropped out of OBSERVING
18-Dec-2016 32700 Dropped out of OBSERVING
1-Dec-2016 32090 Dropped out of OBSERVING
12-Nov-2016 31440 Dropped out of OBSERVING
2-Feb-2016 25332 Finalizing initial installation
30-Jan-2016 25267 Initial installation

 

jason.oberling@LIGO.ORG - 11:13, Thursday 20 June 2019 (50085)

Now associated with FRS ticket 13095.

LHO General
corey.gray@LIGO.ORG - posted 08:19, Thursday 13 June 2019 (49885)
Transition to DAY Log

TITLE: 06/13 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    Wind: 6mph Gusts, 5mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.09 μm/s

Very quiet seismically for all bands.  Due for another hot day up to 96degF.
QUICK SUMMARY:

H1 has been locked 18.5hrs (Observing for 47min due to SQZ drop).  Running with a range at around 115Mpc.

H1 General
jim.warner@LIGO.ORG - posted 07:54, Thursday 13 June 2019 (49881)
Shift Summary

TITLE: 06/13 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: TCS guardians being annoying
LOG:

Multiple times ITMY TCS CO2 guardian relocked the laser, kicking us out of observe. Squeezer also lost lock once.

H1 General
jim.warner@LIGO.ORG - posted 01:54, Thursday 13 June 2019 - last comment - 13:36, Thursday 13 June 2019(49877)
TCS_ITMY_CO2 guardian just knocked us out of OBSERVE, again

Just like last night, ITMY TCS CO2 guardian just kicked us out of observe again. I don't see this node on the SDF overview, so I couldn't see what it was complaining about, but, once again, it resolved itself on its own.

Comments related to this report
jim.warner@LIGO.ORG - 05:22, Thursday 13 June 2019 (49878)

Stepped out to get a cup of coffee and when I came back, we were out of observe again. Not sure what happened, but I suspect that this happened again.

jim.warner@LIGO.ORG - 05:41, Thursday 13 June 2019 (49879)

And it just happened again. Finally found the node on the GRD overview (it's not on the SDF overview) and looking at the log, it looks like the laser is coming unlocked and the guardian has to change some PZT set point. If this is going to keep knocking us out of observe every twenty minutes, can we unmonitor the stuff the guardian is touching?

2019-06-13_12:38:33.009662Z TCS_ITMY_CO2 [LASER_UP.run] laser unlocked. jumping to find new locking point
2019-06-13_12:38:33.077630Z TCS_ITMY_CO2 JUMP target: FIND_LOCK_POINT
2019-06-13_12:38:33.078431Z TCS_ITMY_CO2 [LASER_UP.exit]
2019-06-13_12:38:33.129241Z TCS_ITMY_CO2 JUMP: LASER_UP->FIND_LOCK_POINT
2019-06-13_12:38:33.129853Z TCS_ITMY_CO2 calculating path: FIND_LOCK_POINT->LASER_UP
2019-06-13_12:38:33.129853Z TCS_ITMY_CO2 new target: LOCK_LASER
2019-06-13_12:38:33.130841Z TCS_ITMY_CO2 executing state: FIND_LOCK_POINT (-12)
2019-06-13_12:38:33.135027Z TCS_ITMY_CO2 [FIND_LOCK_POINT.enter]
2019-06-13_12:38:33.262513Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN_SW2 => 1024
2019-06-13_12:38:33.388425Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN => OFF: OUTPUT
2019-06-13_12:38:33.389545Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN_SW1 => 16
2019-06-13_12:38:33.641183Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN => OFF: FM1
2019-06-13_12:38:33.642014Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_CHILLER_SERVO_GAIN_SW1 => 20
2019-06-13_12:38:33.894316Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_CHILLER_SERVO_GAIN => OFF: INPUT, FM1
2019-06-13_12:38:34.146424Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT => ON: OFFSET, OUTPUT
2019-06-13_12:38:34.194611Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 3.5
2019-06-13_12:38:34.197203Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
2019-06-13_12:38:37.201594Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] done
2019-06-13_12:38:37.333333Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 7.0
2019-06-13_12:38:37.336119Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
2019-06-13_12:38:40.336862Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] done
2019-06-13_12:38:40.455196Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 10.5
2019-06-13_12:38:40.466286Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
2019-06-13_12:38:43.466342Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] done
2019-06-13_12:38:43.580825Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 14.0
2019-06-13_12:38:43.581786Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
 

keita.kawabe@LIGO.ORG - 07:55, Thursday 13 June 2019 (49883)

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=49865

Don't unmonitor as TCS glitch has a direct impact on DARM (though I don't know if that could be above or close to the noise floor). Right thing to do is to fix it. I sent an email to Aidan.

david.barker@LIGO.ORG - 13:36, Thursday 13 June 2019 (49892)

Just to reiterate Corey's point, this is not a SDF issue. The SDF diffs for the h1tcscs model has been zero the whole time, and the channels which are being changed by guardian are not being monitored by SDF. Remember that the SDF screen shows models, the GRD screen shows nodes.

LHO General
thomas.shaffer@LIGO.ORG - posted 00:03, Thursday 13 June 2019 (49873)
Ops Eve Shit Summary

TITLE: 06/13 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Quiet shift after commissioning.
LOG:

H1 ISC (ISC)
georgia.mansell@LIGO.ORG - posted 21:49, Wednesday 12 June 2019 - last comment - 16:38, Thursday 13 June 2019(49875)
Some output jitter investigation

Sheila, Georgia

Today while LLO was commissioning we took some time to look into output jitter. The end goal is to have a projection of OMC ASC to DARM for the noise budget, following similar methods to Koji or Carl

Today we only mostly ran excitations to the POS_Y loop, with various offsets and excitation levels. We also did a couple of excitations to the POS_X loop.

Other things to note:

Images attached to this report
Comments related to this report
georgia.mansell@LIGO.ORG - 16:38, Thursday 13 June 2019 (49898)

I had a look at DARM with and without the large offset in POS_Y, using the online time-dependent-correction-factor corrected channel (in the above alog the 3rd attachment is instead just using CAL-DELTAL_EXTERNAL).

The top plot of the attachment shows DARM with and without this offset, and with and without an excitation. The optical gain reduction with the alignment offset is obvious above 60 Hz, however I do not see any extra jitter coupling. I also plotted the coherence between one of the QPD channels and DARM (all the QPD channels looked very similar), and don't see anything there.

If I understand correctly: Adding the alignment offset increased our excitation coupling by a factor of 2, so given that we don't see extra jitter coupling with the offset our ambient noise is at least a factor of 2 below DARM.

Note: we were limited to offsets between -1 and 6 in the POS_Y degree of freedom: going outside these bounds saturated the OMC suspension.

Images attached to this comment
H1 General
thomas.shaffer@LIGO.ORG - posted 21:18, Wednesday 12 June 2019 (49874)
Ops Mid Shift Report

Lock length 11hrs, Observing for 4hrs.

Calm environment.

LHO General
thomas.shaffer@LIGO.ORG - posted 16:04, Wednesday 12 June 2019 - last comment - 08:22, Thursday 13 June 2019(49861)
Ops Eve Shit Transition

TITLE: 06/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    Wind: 10mph Gusts, 6mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY: Commissioning efforts currently ongoing. Calm environment should help.

Comments related to this report
thomas.shaffer@LIGO.ORG - 16:15, Wednesday 12 June 2019 (49864)

PT524 is still in error, this is a known issue.

corey.gray@LIGO.ORG - 08:22, Thursday 13 June 2019 (49887)

Noticing that I did not post my DAY Shift Summary, so here it is (thought I'd just hop onto TJ's EVE transition):

TITLE: 06/12 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

First 90min of shift was for Beckhoff recovery.  Then it was fairly normal business afterwards.
LOG:

  • 13:20 Lockloss & Corner station beckhoff goes down
    • 16:35 Fil & Patrick return after swapping in new hardware (i.e. chassis).  Now checking to see how things look.
    • 16:41 Got the "OK to go" from Patrick & Fil
    • 16:44 - 18:20 Locking & getting back to OBSERVING (see earlier alogs for specifics)
  • 14:55 Cleanroom garb (Jeff)
  • 16:29 Filling PSL chiller (Corey)
  • 16:44 PNNL Intern tour (Jeff B)
  • 19:52 H2 Elec Room 3IFO work (Fil)
  • 19:55 H2 Elec Room work (Patrick)
  • 20:00 Out of OBSERVING for:  Weekly Wed Calibration measurement (Jeff K, Corey)
    • Instructions for these measurements are here.
  • 20:08-20:37 Optics Lab clean-up (Travis, Betsy)
  • 20:52 Put new CDS Overview on video2 with updated Beckhoff/Slow Controls area.
  • 20:57 Switched to COMMISSIONING (for Sheila/Georgia)
H1 SUS (PSL)
edmond.merilh@LIGO.ORG - posted 10:20, Tuesday 11 June 2019 - last comment - 08:00, Thursday 13 June 2019(49808)
OpLev Centering - Weekly FAMIS #11325

OpLev centering was done on both ETMS and ITMX. I'm experimenting with compensating the alignments of these to the degrees that they are driven by the loops during an extended NLN lock. I was able to do EX at NLN and get a good 0/0. Unlocked/Aligned I compensated EY with +2u rad in P and +4u rad in Y. ITMX was compensated with +3u rad in P and nothing in Y. Below is a shot of the positions in NLN.

Images attached to this report
Comments related to this report
edmond.merilh@LIGO.ORG - 11:55, Tuesday 11 June 2019 (49813)

So the final settings mentioned in the initial log seem to be relatively accurate. I'm curious to see if these spots move closer to center with alignment convergence.

Images attached to this comment
edmond.merilh@LIGO.ORG - 08:00, Thursday 13 June 2019 (49884)

Looks like my compensatory alignments worked to my favor. After an 18+ hr lock all but one are reasonably well centered.  EY is off but this doesn't surprise me much.

Images attached to this comment
Displaying reports 40501-40520 of 88906.Go to page Start 2022 2023 2024 2025 2026 2027 2028 2029 2030 End