J. Kissel, [Corroborated by J. Wright and J. Driggers] WP 11797 While upgrading the OMCS_MASTER.mdl library part for the OMC Suspension (which now lives in the h1susifoout.mdl top-level model), I found two distressing things: (1) The OMC ASC signals that are sent from the h1omc.mdl model -- running at 2kHz -- are not anti-imaged at all before being sent to the OMC SUS DAC -- running at 16 kHz. So, we're sending unnecessary imaging noise to the SUS DAC. (2) The OMC ASC L, P, amd Y signals are being sent through a filter bank that does NOT past through the DRIVEALIN matrix, rendering 2019's attempt at diagonalization (LHO:47488) unused. These bugs have been long standing. I see it now as I touch the h1susifoout.mdl and the OMCS_MASTER library part for watchdog upgrades, but I'd previously identified the issue when - I was upgrading the front-end models for O4 (i.e. when the OMC SUS transitioned from the h1susomc.mdl to the h1susifoout.mdl) in 2021 (LHO:59652), and - When we were identifying which SUS models used the broken "TrueRMS" bloick -- there's a preceding note in the simulink model that suggests this has been around since 2015 or earlier. We can fix this tomorrow, with *only* a change to the h1susifoout.mdl and OMCS_MASTER.mdl models, and we're already doing that anyways for the SUS watchdog upgrade. Attached are several series of screenshots showing: (1) The signal path from the h1omc.mdl model where the OMC ASC control signals begin, to where they land in the OMC SUS driving in the EULER basis (again WITHOUT going through the DRIVEALIGN MATRIX) (2) MEDM Screens showing that in practice we only drive L, P, and Y (as one should for an ASC signal) and we don't use T, V, or R drive and likely never will. (3) The existing filters that will need to be copied over, and the DRIVEALIGN gain values that will likely need to be re-addressed -- since effectively we've NOT been using them. Note -- I checked on how this is done at LLO, and they *do* drive through the LOCK banks and DRIVALIGN banks (BUT they don't have any anti-imaging filters in pace either, even though their ISCINF FM1 banks are ON... whoops)... So, when we change the OMCS_MASTER library part, this won't affect them.
The ASC P and Y filters in play during nominal low noise are as follows: Bank Module Name Design String OMC_M1_ASC_P FM0 SUSinvert zpk([0.12+i*3.85;0.12-i*3.85;0.12+i*2.18;0.12-i*2.18],[0.3+i*1.75;0.3-i*1.75],1,"n") FM10 LP8 zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n") OMC_M1_ASC_Y FM0 FM1 zpk([0.033+i*0.54;0.033-i*0.54;0.25+i*3.95;0.25-i*3.95],[1.6;1.6],1,"n") FM10 LP8 zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n") These might be from 2015 -- the only aLOG I can find that even vaguely discusses these filters is LHO:16402. (Note, these are distinctly separate from the primary OMC ASC control filters that were simiplified by Dan Brown and Evan Hall in 2022; LHO:65861). Attached are bode plots of these two filters and their products for PITCH (in RED, on the left) and for YAW (in BLUE, on the right). Note, the FM0 plant inversion filters resolve to have notches at Notch Freq 1st (Hz) 2nd (Hz) P DOF 2.21 3.84 Y DOF 0.54 3.94 For comparison, I plotted the M1 [PIT,YAW] to M2 [PIT,YAW] transfer functions from the latest dynamical model from 2021 when I improved the damping loops (LHO:60049) and I get resonances at Notch Freq 1st (Hz) 2nd (Hz) P DOF 1.92 3.98 Y DOF 0.46 4.13 So ... maybe when we fix the infrastructrure, we should also update the plant inversion...
LHO aLOG 76856 describes the model prep for fixes made to the h1susifoout.mdl top level part and OMCS_MASTER.mdl library part in order to fix this bug.
J. Kissel, D. Barker, P. Fritschel Model changes described above in LHO:76856 now covered under (fast-track approved) ECR E2400116 and IIET Ticket 30863, escalated to such formality because the SUS-OMC_M1_ASC_[LTVRPY]_IN1 channels *were* in the GDS broadcaster frames which is under strict ECR control. They're now replaced by OMC_M1_LOCK_[LPY]_IN1 (i.e. three less channels because TVR don't exist). After making these changes, the impacted model and library have been committed to the userapps SVN under /opt/rtcds/userapps/release/sus/h1/models/h1susifoout.mdl rev 27374 /opt/rtcds/userapps/release/sus/common/models/OMCS_MASTER.mdl rev 27375
[Dave, E.J., Erik]
At about 16:25 UTC, the corner station had a timing glitch that put the IOPs on h1susb123, h1sush2a, h1sush34, h1sush56 and h1lsc0 into an error state.
The affected front ends had no error messages in the system logs..
The SUS IOPs all had long cycle times in the tens of milliseconds. These times are typical of a "dolphin" timing glitch, seen when someone powers on a computer attached to the dolphin network, but no system was powered on in this case.
h1lsc0 had a long cycle of only 3 milliseconds, too short for a "dolphin" glitch. Also, it's time_0 value, which reads the clock time at the start of each second was off by 17 milliseconds, though the duotone value was correct. (see attached screen shot).
There's no evidence anyone was in the CER or MSR at the time of the glitch.
The operator put the IFO into a safe state. Models on the affected systems were restarted.
During the restart, h1susb123 reset it's Ethernet adapter.
Mon Apr 01 10:08:10 2024 INFO: Fill completed in 8min 6secs
Jordan confirmed a good fill curbside
FAMIS 20022
The main chiller alarm was active last night, so this morning I added 100mL of water to stope the low-level alarm.
We plan on doing a remote PMC alignment tomorrow during maintenance to address the recent rise in PMC reflected power.
I saved an improved fit into FM6 as "04-01-24" but have not yet loaded coefficients. Plan to test it tomorrow.
Tested this new FM6 once IFO had been locked 12 hours. New FF looked better, plot attached. Leaving it on from 19:45UTC.
TITLE: 04/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 3mph Gusts, 2mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.30 μm/s
QUICK SUMMARY:
When I arrived H1 had been locked for 40 hours and observing since 4pm yesterday.
Robert has since requested to have commissioning time to do Input arm shake injections.
Incoming 5.5M Earthquake from off the western coast of Guatemala. Lets see if we survive this.
Dust mon Error:
H1:PEM-CS_DUST_PSL101 Error: data set contains 'not-a-number' (NaN) entries
TITLE: 04/01 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: None
SHIFT SUMMARY:
IFO is in NLN and OBSERVING as of 23:00 UTC (32 hr lock!)
Secondary microseism steadily increasing over last 12 hrs
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | ops | LVEA | corner | YES | LVEA is Laser HAZARD !!!! | 15:24 |
16:07 | PEM | Robert | LVEA | YES | Shaking injections on the Input arm | 23:03 |
IFO is in NLN and OBSERVING as of 23:00 UTC March 30th. (28 hr 3 min lock!)
Nothing else of note
Several viewport covers along the input arm of the LVEA are still off, so the LVEA should remain in the laser hazard state. I have, however, placed a temporary cover over each of the open viewports for the night.
TITLE: 03/31 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 20mph Gusts, 18mph 5min avg
Primary useism: 0.07 μm/s
Secondary useism: 0.34 μm/s
QUICK SUMMARY:
IFO is in NLN and OBSERVING (24 hr 13 min lock!)
Other:
H1:PEM-CS_DUST_PSL101 Error: data set contains 'not-a-number' (NaN) entries
TITLE: 03/31 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
LOG:
H1 now Locked for 24 hours , and Observing as of 23:00 UTC.
It's been really quiet day for Robert to do PEM injections all day.
SQZers requested a few minutes of SQZ_MANAGER taken to SCAN_SQZANG which happened at 21:23 UTC
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | ops | LVEA | corner | YES | LVEA is Laser HAZARD !!!! | 15:24 |
16:07 | PEM | Robert | LVEA | YES | Shaking injections on the Input arm | 23:03 |
Screenshot of the SCAN_SQZANG state (76776) - it scans SQZ CLF RF6 demod phase to scan the sqz angle, and optimizes squeezing at 350 Hz by minimizng the yellow BLRMS3.
Here it changed the CLF_RF6 demod phase by +19 degrees. That was a squeezing improvement of 1.4dB for 350 Hz yellow BLRMS 3, and improvement of about 3dB for the 1.7 kHz blue BLRMS 5.
TITLE: 03/31 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 20mph Gusts, 14mph 5min avg
Primary useism: 0.10 μm/s
Secondary useism: 0.31 μm/s
QUICK SUMMARY:
H1 has been Locked for 21 hours.
Comissioning all morning for PEM injections.
Survived numerous earthquakes, and wind gusting above 45MPH.
FAMIS 26237
Laser Status:
NPRO output power is 1.815W (nominal ~2W)
AMP1 output power is 67.19W (nominal ~70W)
AMP2 output power is 138.2W (nominal 135-140W)
NPRO watchdog is GREEN
AMP1 watchdog is GREEN
AMP2 watchdog is GREEN
PMC:
It has been locked 30 days, 18 hr 28 minutes
Reflected power = 17.13W
Transmitted power = 108.9W
PowerSum = 126.0W
FSS:
It has been locked for 0 days 19 hr and 0 min
TPD[V] = 0.8157V
ISS:
The diffracted power is around 2.4%
Last saturation event was 0 days 19 hours and 0 minutes ago
Possible Issues: None reported
Sun Mar 31 10:06:43 2024 INFO: Fill completed in 6min 39secs
TITLE: 03/31 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 6mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.28 μm/s
QUICK SUMMARY:
H1 is Currently Locked and and Observing for 16 hours.
The normal Teamspeak server (teamspeak.ligo.org) is back up and running today.
Dust monitor is not reporting back "OK":
H1:PEM-CS_DUST_PSL101 Error: data set contains 'not-a-number' (NaN) entries
TITLE: 03/31 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: None
SHIFT SUMMARY:
IFO is in NLN and OBSERVING as of 23:11 UTC (8 hr lock)
We survived a 5.7 earthquake from Tonga
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | ops | LVEA | corner | YES | LVEA is Laser HAZARD !!!! | 15:24 |
18:31 | PRCL | Elenna | Remote | N | PRCL investigations | 19:59 |
18:45 | PCAL | Dripta | Optics Lab | N | Getting LLO's Pelican case | 19:05 |
19:35 | PEM | Robert | LVEA | Yes | Shakin Input arm | 19:39 |
19:59 | PEM | Robert | CtrlRm | N | Shaking Input side | 20:59 |
20:17 | PEM | Robert | Ex | N | Turning on Equipment at EX | 20:33 |
21:13 | CAL | Tony | CtrlRm | N | Calibration sweeps. | 21:38 |
21:43 | LSC | Elenna | Remote | N | LSC Feed forward work | 21:45 |
23:03 | PEM | Robert | yes | yes | Turning Off amps | 23:18 |
Tonight it looks like squeezing is tuned in a different way than usual, resulting in worse high frequency noise.
But at 100 Hz now DARM is at the same level as O4a, so there's no "excess broadband noise" at 100 Hz in this configuration.
Attached a comparison of DARM now [brown], in O4a [blue] and in a couple of other times pre O4b [orange and purple]. Similar to 76501 and 76757
IFO is in NLN and OBSERVING as of 23:11 UTC (4 hr 2 min lock).
Nothing else of note
TITLE: 03/30 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
Teamspeak server is still: teamspeak3.ligo.org
Comissioners were trading times throught the day to do various comissioning tasks.
Lockloss 15:42 UTC https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1395848569
Likely caused by comissioning activities 76814. Please see lockloss screenshot 1, screenshot2, and screenshot 3 for future lockloss investigation references.
Relocking was quick 45 mminutes. NLN @ 16:27 UTC
Survived 2 Earthquakes:
16:34 UTC 5.8 Earthquake from Rat Islands Alaska https://earthquake.usgs.gov/earthquakes/eventpage/us7000m8yd/executive
17:03 5.3M Earthquake from Tonga https://earthquake.usgs.gov/earthquakes/eventpage/us7000m8yl/executive
Lockloss 21:42 https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1395870244
Likely caused by comissioning activities 76811. Please see lockloss screenshot 1, screenshot2, and screenshot 3 for future lockloss investigation references.
Relocking:
I had to Touch up X and Y arms, during Green arms. And pushed around the Beam splitter during Acquire PRMI a few times but otherwise started locking with out an Initial_alignment.
SDF Diff
Accepted the sdf Diffs for the LSC see pics:
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | ops | LVEA | corner | YES | LVEA is Laser HAZARD !!!! | 15:24 |
15:14 | PRCL | Elenna | remote | N | PRCL Injections & changing PRM L2A gains | 17:25 |
16:29 | PRCL | Elenna | Remote | N | PRCL Injections | 16:34 |
17:30 | PEM | Robert | CtrlRm | N | Shaking Injections on the input side | 18:29 |
18:31 | PRCL | Elenna | Remote | N | PRCL investigations | 19:59 |
18:45 | PCAL | Dripta | Optics Lab | N | Getting LLO's Pelican case | 19:05 |
19:35 | PEM | Robert | LVEA | Yes | Shakin Input arm | 19:39 |
19:59 | PEM | Robert | CtrlRm | N | Shaking Input side | 20:59 |
20:17 | PEM | Robert | Ex | N | Turning on Equipment at EX | 20:33 |
21:13 | CAL | Tony | CtrlRm | N | Calibration sweeps. | 21:38 |
21:43 | LSC | Elenna | Remote | N | LSC Feed forward work | 21:45 |
23:03 | PEM | Robert | LVEA | yes | Turning Off amps | 23:18 |
The Server we usually use for teamspeak is:
teamspeak.ligo.org , which I believe is a server hosted offsite, possibly at MIT, that is ping-able but teamspeak service is no longer working.
LLO's Operators Cannot Log in to this server either.
I reached out to Dave this morning about this, and he mentioned something right before he hung up to investigate that made me want look at the passwords page for another server name and password.
On the passwords pageI found another teamspeak server: teamspeak3.ligo.org . Which uses the same password as the old server!
I logged in and sent a link to Elenna to see if she could log in. Dave, Elenna, and I all met in there at effectively the same time and confirmed that it works.
Current issue with this is that there is not an LHO Control Room Channel, And I dont have the Credentials to make a permanent one.
I am Currently Hanging out in the LHO COMM/OPS MEETING ROOM.
If you have any questions about this please call the Operator at the LHO Control room @ (509) 372-8204
LLO has confirmed that they are also in this new Teamspeak server.
Ive been informed that Fred Donovan out at MIT, who manages that server, has corrected the teamspeak networking issue. We can now log back into the normal server: teamspeak.ligo.org, which has all of our normal channels. Thank you to Fred Donovan for finding & correcting the issue and David Shoemaker for reaching out to us know the issue is resolved.