TITLE: 05/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 2mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.09 μm/s
QUICK SUMMARY:
H1's been locked 21.25+hrs. There was a notable drop in range of 20Mpc over the last 3hrs and it's fairly coincident with a similar environmental 3-30Hz (larger in 3-10Hz band) seismic increase seen primarily at the corner station (and to a smaller extent at the EX/EY buildings) over the same time of the H1 range drop. Winds have been normal during this time.
Commissioning is planned again from 9-noon this morning.
nuc33's SQZ dtt crashed 2nd day in a row.
TITLE: 05/16 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Observing for the entire shift. Locked for almost 15 hours.
Jenne, Sheila
This morning we accepted SDF diffs for A2L gains at the end of the commissoning time, as Jenne had been working on and ran the new A2L script (first screenshot). After going back to observing, the CHARD P coherence with DARM was still high, so after the calibration measurements I took a few minutes to manually tune P2L for the ETMs only (second screenshot).
We need to reduce the DHARD rms to make our SRCL to darm coupling more stationary, (77729 77666) I ran a noise injection to measure the DHARD P loop this morning.
Elenna measured the hard loops and compared them to a model while we had 430kW in the arms in 69597, today's measurement is with 375kW. I used a template I found in userapps/h1/asc/templates/DHARD/DHARD_P_broadband_excitation.xml, which I think is the one that Elenna tuned in 69597.
Attached is a very simple script that uses dttxml to get the transfer function data from an xml file, getting the IN2/exc/IN1/exc unbiased transfer function. I also plotted uncertainties based on 10506, calculating an uncertainty for magnitude and phase from in1/exc and in2/exc separately and adding them in quadrature (this is not the correct way to add these uncertainties).
It seems like we have room to add a boost to this loop.
For modeling purposes, here's a fit to the DHARD_P plant obtained from this measurement, after factoring out the current controller.
Z = [-0.37656602]
P = [-0.00292406 +0.j ,-0.11496697 +6.49363092j,
-0.11496697 -6.49363092j,-0.19955184+16.53674456j,
-0.19955184-16.53674456j]
K = 2176.925725327256
Here's a possible design for a boost to improve suppression in the region below 0.7 Hz
zpk([-2.723526385480632+i*3.098947495963098;-2.723526385480632-i*3.098947495963098],[-0.6734376457906343+i*2.23044514115136;-0.6734376457906343-i*2.23044514115136],0.9990715840784479)
I have saved this new boost as GVboost in DHARD P FM8, but I haven't yet loaded the filter file.
We got a notification that the WAP was on in the LVEA, EX, EY at 1700PT (0000UTC). Trending the H1:CDS-WAP_{LVEA,EX,EY}_STATUS channel they transition from state 2 (off) to state 0 for ~5 seconds. This last happened on April 20th, again at exactly 1700PT. CDS was looking into this, but I don't think we know yet if the wireless actually came on or not.
Closes FAMIS 25991 last checked in alog 77785.
Things of note:
ETMY_ST1 has a notably different trace shape for channels, Y_ST1_CPSINF_V1, EY_ST1_CPSINF_V2, EY_ST1_CPSINF_V3:
Other than this, measurements look comparable to last week's check. PDF Attached.
TITLE: 05/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
Straightforward shift with about half of it for Commissioning, Calibration measurement, and a relock. The relock was mostly automated but ALSx did start with low power (0.45) again.
LOG:
TITLE: 05/15 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 17mph Gusts, 12mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.09 μm/s
QUICK SUMMARY: Locked for 6 hours, calm environment at the moment.
After coordinating with LLO & notifying Virgo, went with running the Wednesday Calibration Measurements (broadband [~5min] + simullines [~23min]) at ~ 21:10UTC.
Logistical Notes In Intersite Coordinating: At 2007utc (107pmPDT) contacted LLO Control Room via Teamspeak and JoeB/Anamaria wanted another hour so they could also have atleast 3hrs of thermalization. So will connect with LLO at 2110utc to coordinate our down time for our Wednesday calibration measurement. Then contacted the Virgo control room via teamspeak to give them a heads up for possible down time at 2110utc.
Measurement NOTES:
[Sheila, Jenne]
We did a first quick test of moving the spot on PR2 during our commssioning time this morning. Our biggest conclusion is that 'wow, we need to move a lot if we're going to center on PR2'. Since it was late in the commissioning window, and I had already broken lock once today when shaking HAM3 (alog 77851), we didn't shake HAM3 while doing these moves. That's something that we'd like to do at some point, to hopefully see that the effect in DARM is lower when the spot on PR2 is closer to center.
Sheila manual-ed the ISC_LOCK guardian to the PR2_spot_move state. This state watches how much PR3's slider moves, and moves the PRM and PR2 sliders to compensate that move. In the first attachment of the slider values for the 3 PRC optics, you can see that PRM and PR2 sliders are following along when Sheila moves the PR3 slider. We didn't see very much response in the ASC loops when we made a step, which means that these 'following along' scales for the PRM and PR2 sliders are still quite good, even though we haven't used this guardian state in several years. First we went a small amount one way, then we went a larger amount the other direction in yaw.
The second attachment is the top mass OSEM witness of the moves, and the third attachment is our cabity buildups. The x-axes of all these plots / screenshots are set to be the same. The bigger yaw movement (almost 3.6 urad in PR3 yaw) a little after -1h clearly shows a bump up in arm circulating power, that then goes away when PR3 is moved back to its nominal position. This bump is clear in the arm circulating powers, even though the IFO was still thermalizing. Interestingly, I don't see a similar bump in POP_LF, the amount of power circulating in the PRC.
While PR3 was at it's extremal yaw position for today, I did a rough Y2L optimization for PR2 with step sizes of 0.05, and found that a Y2L value of -7.40 was about the best I could do to minimize the peak (30 Hz, 1 ct using the ADS oscillator) in PRCL_OUT. After Sheila put PR3 back to its nominal position, I re-checked, and found a Y2L value of -7.50 was the best. This means that we moved the spot on PR2 by about 0.2 mm (out of the 15 mm we think we need to move) closer to center, when we changed the PR3 yaw alignment by 3.5 urad. I'll note that I did not have the 30 Hz notches in the quads' ISCINF pit and yaw filter banks engaged, but I'm not fully sure that those are helpful here (if they are important, we should add them to all of the other optics, not just the quads).
Just as a double check of whether we really should need to move PR3 that far: If I assume the distance between PR2 and PR3 is 1/3 of the PRC length 55m, my lever arm for a very naiive spot movement calculation is about 18m. At 18 meters away, a 3.5 urad angle change will move a beam 6.3e-5 m, or 0.06 mm. So, this very naiive estimate gives a smaller beam spot motion on PR2 for a given PR3 move than we measure using A2L, but it confirms that indeed we probably didn't make a very dramatic move on PR2 today.
H1 just completed a block of Commissioning time and is back to Observing. H1 is currently about 2hrs into thermalizing, so may try to coordinate a Calibration break with LLO (& give a heads up to Virgo).
Wed May 15 10:14:42 2024 INFO: Fill completed in 14min 38secs
Gerardo confirmed a good fill curbside.
I was working on shaking the HAM3 ISI to see the effect of potential clipping on the PR2 scraper baffle (with the idea that we were then going to move the spot on PR2 and see how DARM changed), but I was saturating the H3 actuator and the ISI's watchdog timed out and tripped off.
I had just increased the excitation by a factor of 2, to 10 counts going to H1:ISI-HAM3_ISO_Y_EXC, and that last factor of 2 is what started saturating the actuator. Since we were able to see some subtle effects in DARM with 5 counts, we'll try using that when we next get locked. We may be interested in a conversation with SEI folks about whether it is safe to override the actuator saturation watchdog during this type of test, in order to more clearly see the effect in DARM, but we'll save that for another day.
Sheila pointed out that it would be useful if verbal alarms would tell us when we are saturating a seismic actuator (similar to how it tells us if we are saturating a suspension).
Attached are screenshots of the amount of motion above ambient, as well as that this last factor of 2 increase in actuation is what caused the saturation monitor to start accumulating, as well as of the excitation settings. This DTT template is a copy of what was in the Noise Budget git space for HAM5, with the exception that the noise budget excitation value is 0.6 counts, and I wasn't really seeing an effect in DARM until I got to 5 counts.
Here's also the HAM3 watchdog plot, again showing that it was my actuation that caused the trip.
There is also the suspoint drive infrastructure that we've added to all of the ISI models, allowing you to drive the euler basis motion for a particular suspensions top stage suspension point. Not sure if that will help for this measurement or not. For each ISI there are filter modules called ISI-CHAMBER_SUSPOINT_DRIVE_L/T/V/R/P/Y, giving the necessary testpoints, EXC channels for those fms are stored in the daq at 2048. You will need to populate the downstream eul2cart epics matrix to get the correct translation to the ISI cartesian drives. Output from the eul2cart matrix is then summed into the error point of the cart basis isolation loops. The matl code for writing the coefficients is really simple, for PR2, on HAM3 it would be:
addpath /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/
cd /opt/rtcds/userapps/release/isc/common/projections
load('ISI2SUS_projection_file.mat')
sus={'pr2'}
for ii =1:length(sus)
fill_matrix_values(['H1:ISI-', upper(ISI2SUSprojections.h1.(sus{ii}).chamber), '_SUSPOINT_EUL2CART'],ISI2SUSprojections.h1.(sus{ii}).EUL2CART)
pause(.1)
end
This might fail on a couple of the coefficients, so it might be a good idea to run a couple times. Also, there's only 1 6-dof matrix per ISI, so if drives on multiple suspensions are needed on one table, you will need to populate the matrix for each suspension. Probably also best to zero out all of the matrix elements first, then write with the above code.
TITLE: 05/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 6mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY:
Walked in to h1 locking PRMI (there was a lockloss 25min earlier (at 1405utc).
I believe Commissioning is in the morning today (along with a calibration measurement), but H1 will be thermalizing the next few hours.
Green arm x power is looking back to normal-ish with power closer to 1.0.
(Also there was box with a bat in it outside the entry to the Control Room.)
TITLE: 05/15 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: One lock loss with an easy relock. On the first lock I had to step out of Observing to do a sqz scan, this helped our range. Currently locked for 2.5 hours.
LOG:
Seemed very sudden, there was only a very minor wiggle in DARM msec before the lockloss.
Observing 0528 UTC.
I had no issues with ALSX power, it got up near 1 almost immediately. ALSY needed ETMY to be adjusted by 0.1urads for it to catch even though it had flashes near one...annoying. Other than that it was all auto.