With apologies that this is so delayed, I have prepared updated jitter cleaning. Since we're already in Observing, and the IFO isn't yet all the way thermalized, I'll push these and see how they do sometime tomorrow.
To do this, I:
params['gps'] = 1395993819
# ER16. OM2 cold. Many hours into a lock.conda activate nonsens
python3 Jitter_TrainSubtraction.py
https://lhocds.ligo-wa.caltech.edu/exports/jenne.driggers/lho-online-cleaning/Jitter/plots/?C=M;O=D
and select the most recent "Jitter_subtracted_H_...... .html" file.cp Jitter_results_H_1395993819_1800_2024_04_01_16h30m24s.pickle Jitter_best.pickle
python3 Jitter_extractCoeffs.py
python3 Jitter_writeEPICS.py
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 147Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 8mph Gusts, 5mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.19 μm/s
QUICK SUMMARY:
IFO is in NLN and OBSERVING as of 23:00 UTC (45 min lock)
Other:
H1:PEM-CS_DUST_PSL101 Error: data set contains 'not-a-number' (NaN) entries
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 149Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
H1 Is currently Locked for 44 Min and Observing for 8 Min.
The Myster H0:CDS-VID_CAM_REQ Button was pushed by a button pusher.
In unrelate news:
Unknown Lockloss 21:22 https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1396041753
Relocked with out an Initial Alignment
The SQZ_FC Gaurdian got stuck for 10 minutes, Vicky jumped on TeamSpeak and helped us out.
Nominal_Low_Noise 22:24 UTC
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | OPS | LVEA | corner | YES | LVEA is Laser HAZARD !!!! Alog 76834 | 15:24 |
14:58 | PEM | Robert | LVEA/CtrlRm | N | Shaking Input arm injections | 16:00 |
16:02 | LSC | Camilla | CtrlRm | N | Retune the LSC FF. | 16:32 |
16:06 | PEM | Robert | EX | N | power on EX Shaker, not inject yet | 17:06 |
16:40 | FAC | Chris | EX | N | Cleaning up debris from the road way. | 18:40 |
17:10 | FAC | Karen | Optics Lab | N | Tecnical Cleaning | 19:10 |
17:14 | CDS | Dave, Erik | Remote | N | Troubleshooting Dolphin issues | 19:14 |
20:55 | PCAL | Francisco | PCAL Lab | Yes | Taking Pictures | 21:13 |
23:03 | PEM | Robert | LVEA & EX | Yes | Shutting Down movers and shakers. | 23:33 |
23:07 | HWC | Jenne W | EY | N | Running the Arms and Checking out the Wildlife. | 00:07 |
SUS SDF changes saved to Safe.snap.
IM
IM1,2,3,4 Pitch
IM1,2,3,4 Yaw
OMC, OFI, OM1, 2, 3
The other updated OPTICALIGN offset values as updated through my script 76606 . Very fast and easy to use if you are updating safe.snap to current values!
Please see Jeff's alog about these changes https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=76850
J. Kissel ECR E1700387 IIET 9392 WP 11743 Here, this week we tackle the last of the suspension types that need suspension watchdog upgrades after having finished the End Station, Corner BSC, and HAM Triple suspensions this past month (LHO:76269, LHO:76545, and LHO:76712, respectively). WP 11797 While doing so, I'm also going to address the OMC ASC routing bugs found in the h1susifoout top-level model and its OMCS_MASTER library part (which used to live in h1susomc.mdl), and fix those too. As such, I'm doing a linear combination of the following changes: (1) In library part, removed sending watchdog out to top level (2) In library part, removed ODC parts from DAMP and LOCK banks (3) In library part, removed never-usered software shutter system (4) In library part, upgraded watchdog trigger generator to actual functional RMS (5) At top level, removed USER DACKILL (6) At top level, removed wires to ground (i.e. things never used) at top-level for WD, SHUTTER, and ODC outputs and SHUTTER input (7) At top level, cleaned up receiving of ISC ASC signals (see discussion in LHO:76842) Below is the list of models, their respective library parts, and the optics in that model that this impacts, followed by a call out of which of the above changes happened h1susim HSSS_MASTER IM1, IM2, IM3, IM4 (1), (2), (4), (5), (6) h1sushtts HSSS_FF_MASTER RM1, RM2 (1), (2), (3), (4), (6) h1susifoout OMCS_MASTER OMC (1), (2), (4), (5), (6), (7) OFIS_MASTER OFI (1), (2), (4), (6) HSSS_MASTER OM1, OM2, OM3 (1), (2), (4), (5), (6) h1sussqzout HSSS_MASTER ZM4, ZM5, ZM6 (1), (2), (4), (5), (6) h1sussqzin HDDS_MASTER ZM1, ZM3 (1), (4) OPOS_MASTER OPO (1), (2), (4), (6) HSSS_MASTER ZM2 (1), (2), (4), (5), (6) I've test-compiled all of the above listed models, so they're ready for re-compile, install, and restart of the front-end process tomorrow morning. All model changes have been committed to the userapps repo, either under /opt/rtcds/userapps/release/sus/h1/models/ /opt/rtcds/userapps/release/sus/common/models/ where the above mentioned models live. Screenshots describing the changes will be posted in the comments.
To address the removal of the transverse, vertical, and roll possibility and removing the "bad route" of the L, P, and Y OMC ASC control, I've done the following: (1) At the top level of the h1susifoout model, I've removed the ingestion of the T, V, and R IPCs. These still get send out into the dolphin IPC fabric from the h1omc model, because I didn't want to mess with that model. This means that if someone ever tries to use the OMC-ASC_DOF2TT matrix elements for "SUS V, SUS R or SUS T", the output of those elements of that matrix will go into nothing, essentially terminated. See before vs. after screenshots of the bottom left corner of the h1susifoout.mdl top level IPC area. (2) I've modified the OMCS_MASTER model to completely delete the "OMC_M1_ASC" bank, and removed all simulink inputs that landed in that bank from the top level h1susifoout model, to the top level of the OMCS_MASTER model, to the M1 stage of the OMCS_MASTER. See before vs. after area surrounding the call to the OMCS_MASTER.mdl in the h1susifoout.mdl top level model, And then drilling down into the OMCS_MASTER library part, see (i) before and after, the top level of the OMCS_MASTER library part. (ii) before vs. after, the M1 stage of the OMCS_MASTER library part. (3) Because the OMC ASC alignment input channels are stored inthe frames at 256, I had to update the DAQ channel list to switch to using the M1_LOCK banks rather than the M1_ASC banks. Note, there are therefore 3 less channels stored in the frames. This is seen in (2)(i) before vs. after cited above. (4) While there, I also deleted other never-used / impossible to use infrastructure that I installed early on in the 2010s because it was easier to copy and past than to customize. Now that we've gone through 4 observing runs, and there's no hardware to support it, I'm deleting the infrastructure to clean things up (lest it gets copied forward again by some future me). This includes (a) The "LKIN" parts, which are originally designed for demodulating an angular dither signal in order to diagonalize angular drive. But, there are only two OSEMs for both pitch and yaw on the OMCS's OSEM configuration, so the "coil balancing" methods, using the lock-in just will not work, since we can't drive "pringle." DELETED. (b) Many other SUS that have right-cylinders for optics, which have a center of rotational actuation that we're trying to align to a geometric rotational center in order to minimize angle to length coupling by "dithering." Sometimes you might hear the gains applied to the actuation basis called the "A2L" gains. For the OMCS, the beam is coming in at the edge of a square breadboard that's suspended beneath the actuators, of which again, there're only two. This, like the LKIN system, the DITHER system just doesn't make any physical sense. Because of the reasons outlined in (a) and (b), the inputs to the M1 stage of the OMCS_MASTER library part have always been terminated. That means that the inputs from ISC don't even appear at the top level. So, I've ripped both of these out. This is seen in (2)(ii) before vs. after cited above.
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
While studying the improvement made by stray light modifications over the break (summary alog soon), I found that the coupling was minimized by changing ITMY R0 yaw offset from -300 to -250. We want to change the settings before my alog, hence this mini-alog.
I have set and saved that value of -250 for the IY reaction mass yaw offset in both the safe and observe SDF files. I did this right around when DRMI had just caught lock during this acquisition, so it seems fine (as we'd expect) for locking with this very slightly different offset. Attached are the safe and observe snap screenshots of my accepting the new value.
SDF Diff accepted.
H1:IOP-SEI_HAM6_DK_BYPASS_TIME
Since the camera servo offset was monitored by SDF in safe.snap, everytime we lose lock, the camera servo offset was set to the values in safe.snap which are kind of random. So I unmonitored the camera servo offset in safe.snap. This will make it easy to look back the camera servo offset in different locks.
TITLE: 04/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: SEISMON_ALERT
Wind: 8mph Gusts, 5mph 5min avg
Primary useism: 0.08 μm/s
Secondary useism: 0.24 μm/s
QUICK SUMMARY:
Some Commissioning was being done until the 16:23 UTC Dophin Crash.
Took all SUS to SAFE
Took all SEI to ISI_DAMPED_HEPI_OFFLINE
Took HAM1 HEPI to MASTERSWITCH_OFF
CDS started restarting DAQs at 16:53 UTC ish
The FC SUS kept trying to put itself into aligned everytime we went into prep for locking even though ISC_LOCK was in IDLE.
I then Manualed ISC_LOCK to IDLE then took SQZ_MAN to Down, then Paused SQZ_MAN and finally I took FC to SAFE for good.
17:33 UTC Took all the SUS back to Aligned.
Then took ISI's & HEPI's back to ISOLATED.
Then took SEI_ENV back to Calm
Started Initial_Alignment 17:53 UTC
Increase_Flashes ran for both arms
IA could not get passed Input align due to IMC unlocking issues seen on friday's Alog 76793
Once the Issue was Identified I took all sliders except for SQZ to 1395811454 ( tail end of the last Initial Alignment)
Y arm looked bad so I took Yarm sliders only to 1396030446 (Tail end of Increase Flashes) to get good Y arm Values in Green arms Manual.
INITIAL_Alignment started again and completed near 19:07 UTC.
NOMINAL_LOW NOISE has been reached 19:49 UTC.
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
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: 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.
TJ, Camilla, WP 11746, LLO did in LLO#14419
Using Matlab code from LLO#14419 with edit to parameter x = 4:1:26
Sheila, Jennie W
At around 21:49 UTC we used the step_45MHz.py in userapps/isc/h1/scripts to step the modulation depth in steps of 1dB down from 21dBm to 18dBm. This script adjusts the loop gains to compensate for a drop in power on the RF45 PDs.
Its also important to open the POP beam diverter to monitor what is happening to the RF 45 PD signals.
This is to check that the noise does not decrease with decreasing modulation depth which would imply that the modulator was imposing noise on the carrier through the ISS loop.
At around 22:18 UTC we put the modulation depth down by 3 dB we saw a 4% increase in the DARM broadband noise (measured the level at 2kHz with cursors) which is the green trace in the second image. The level of KAPPA C (shown in first image on bottom plot) only decreased by around 1% over this time, so we suspect some other cause other than a change in optical gain being responsible for this.
When we stepped the modulation depth up by 3dB (third image) we saw no change in the noise from the nominal state (purple trace on second image). Kappa C (bottom plot) looks almost the same as the nominal also.
In the fourth image it can be seen that f_C does not change much either.
After we did this test Daniel commented that we should check what the PCAL lines did as we stepped down and up the 45 MHz modulation depth.
To do this I used the spectra we took and measured the height of the 410.3 Hz line (PCAL Y) in DARM in m.
Our nominal level was 1.35370 e-19 m
The line height decreased by 1.1% when we decreased the modulation depth by 3dB. I think this is consistent with our optical gain decreasing by 1%. I am therefore not sure why lowering the mod depth causes a 4% increase in DARM.
The line height increased by 0.04 % when we increased the mnodulation depth by 3dB. I think this is consistent with us not seeing much decrease in the DARM noise when we increase the modulation depth.
Screenshot showing the issue - the SQZ_FC state "FIND_IR" had over run its execution time by like 10 minutes. I suspect what happened is that in FIND_IR's call to find_min(), the find_min() function called cdu.getdata(), which got stuck in the data grab and overran the time.
I manualed SQZ_FC to "GR_LOCKED", then set it back to being MANAGED by SQZ_MANAGER. Then it automatically went up to FDS without intervention.