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 132Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 7mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY:
Taking over from Austin
TITLE: 06/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 133Mpc
SHIFT SUMMARY:
- Lock #1:
- Lock #2:
- Had issues with ALS locking, so redoing an IA, during which it seems the X beatnote was poor again, so I reset the crystal frquency to get the beatnote to ~39 MHz, that seemed to have fixed the issue, rest of IA went fine
- Lock #3:
- Leaving H1 to Ryan C. in observing
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 00:31 | PCAL | Tony | PCAL Lab | N | Prep for PCAL measurement | 00:43 |
LOCKLOSS @ 4:35, not seeing a whole lot of ASC movement, but am seeing some motion in LSC loops - scope attached
Following a lockloss, H1 has now been locked and in observing for ~1:30, all appears nominal.
The Following features have been removed from the Vacuum screen on nuc22 found at /opt/rtcds/userapps/release/cds/h1/scripts/fom_startup/nuc22/H0_VAC_SITE_OVERVIEW_CUSTOM.ui and H0_VAC_SITE_OVERVIEW_CUSTOM.adl upon the request of Gerardo.
Neg pumps pressure transducers at the corner station: PT-191, PT-192, and PT-193.
Neg pumps pressure transducers at the Y-End station: PT-426 and PT-428.
Neg pump pressure transducer at the X-End station: PT-526.
The corner station "CP1 IP" and "CP2 IP".
The old versions still exist and have been renamed with an .adl.old file extension. For the MEDM screen that Sitemap uses the file lives here /opt/rtcds/userapps/release/vacuum/h0/medm/Target/H0_VAC_SITE_OVERVIEW_CUSTOM.adl
LOCKLOSS @ 0:07, had a SRM saturation right before the lockloss. Seeing some movement in INP1 P - scope attached
We have had several locklosses recently that can probably be attributed to a CSOFT P ring up. Starting on 6/8, I looked through all the locklosses and found 6 in total that had a CSOFT P ringup with the oscillation at 0.45 Hz. Some of these have already been noted in various alogs (shout out to Camilla for pointing them out here 70267).
CSOFT P locklosses:
6/8 2:45 UTC
6/8 6:53 UTC
6/10 6:53 UTC
6/10 19:50 UTC
6/11 21:45 UTC
6/12 12:12 UTC
The operating power for each of these locks seems to be about 430 kW in the X arm and 432 kW in the Y arm +/- 1 or 2 kW which is pretty standard, so it does not appear to be power related (at least lock to lock). The TMS servo signals also look stable and we are staying well centered on the TMS B QPDs and are not very far off center in the A QPDs.
Each of these locks have a different durations ranging from 2 to 9 hours, and there have been several other locks in this period where the locklosses are not attributed to ASC. Whatever the problem is, it does not appear to be consistent from lock to lock
We haven't had ASC problems for a while. These are some main differences from our known-to-be-stable configuration that could affect the ASC: ring heater change on EX, 1 W drop in input power, new input alignment from PR3 move.
One thing we could try is increasing the loop gain slightly and seeing if these locklosses persist. Right now the EPICs gain is set to 20. I have been able to increase this gain by up to 3 dB in the past without issues.
TITLE: 06/12 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 133Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 14mph Gusts, 11mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY:
- IFO is locked and in observing as of 12:41
- CDS/SEI/DMs ok
TITLE: 06/12 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 133Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 12mph Gusts, 10mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY:
Lockloss at 16:13 UTC
Started trying to immediatley relock.
Lockloss at ACQUIRE_DRMI_1F 16:29 UTC.
Starting Initial_Alignment 16:30 UTC.
Initial Alignment went smoothly.
Relocking went smoothly as well.
Arrived at NOMINAL_LOW_NOISE at 17:33 UTC.
Had a Strange SDF Diff H1:ISC-RF_Y_AMP71M_OUTPUTMON Dr. it was 20.5 and is now 19.5. Dr.Sigg Accepted it.
OBSERVING Reached at 17:46 UTC
Unlocked Due someone Clicking an MEDM button they though was a safe button to click, but it was not.
See alog https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=70375
Reached NOMINAL_LOW_NOISE at 21:40 UTC
Shelia, & Brina did an excitation test for the gain frequency before the IFO was taken to Observing mode.
Observing 22:06 UTC
Current IFO Status: NOMINAL_LOW_NOISE & OBSERVING
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 16:17 | FAC | Kim | Mid X | N | Technical Cleaning | 17:30 |
| 16:44 | FAC | Karen | MidY | N | Technical Cleaning | 17:27 |
| 18:06 | FAC | Karen | optic lab | N | Technical Cleaning | 18:20 |
| 21:27 | VAC | Gerardo | MIDX | N | Checking on a Vacuum pump | 21:57 |
Earlier Lockloss from unknown cause.
Lockloss from NLN:
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1370621620
I tried trending a number of channels back that seemed like they had a large magnitude or interesting abbiration, But when compairing them to live IFO channels they seem to be channels that usually have larger magnitudes.
Even after the Analysis finished there isn't an well defined reason for the lockloss that is obvious to me.
Since we are keeping track of the changes to PRCL, the lockloss today (6/12) at 2:02 UTC might be due to PRCL. There is an oscillation in all three LSC loops around 13 Hz right before lockloss.
While we were locked observing, I was digging through LSC screens trying to look for PD sum channels to trend for some lock loss investigations. Not knowing these screens well, I accidentally switched the LSC_CUST_TRPD screen from the QPD B SUM pd to the Inair PD. This didn't go well, and I didn't get the PD overview I was hoping for. I modfied the screen a little bit to try to make this a little more clear to neophytes. The only working link to a separate screen is now orange and I added a "PD select:" label to the buttons I clicked.
(Although the word "stabilized" is used loosely.)
Now that temperatures have seemed to settle in, attached* is a longer trend of the PR3, BS, and SR3 showing their new positions at these new LVEA temperatures. Note, this is a follow-on from Kissel's historical alog summary of the HVAC temperature changes 70284.
Recall that there were a few HVAC fan/setting changes with subsequent issues, failures, adjustments, and fire alarm testing interuptions which spanned the last month and rolled past just Tuesday maint periods. The PR3, BS, and SR3 seem to have slewed to new positions starting at the last LVEA temp change ~May 25th and have now settled in.
* V_INMON is the vertical channel for these suspensions - if the V channel shows change, it likely means that Pitch and or Yaw have also changed (PR3 pitch is shown to demonstarte). I confirmed this with previous plots, but chose to only plot this version since V tells the main story of epochs.
* Only 1 LVEA temp plot is shown for ease of viewing, but I checked via erlier versions of the plot that this zone temp change of over 1.5deg F is typical for what has been observed in the LVEA on other sensors.
We are still sorting new/old noise sources and any other such fallout from this new IFO alignment position.
Lockloss @ 14:14 UTC from a magnitude 5.8 earthquake from New Zealand. This lockloss happened at the same time as seismic configuration moved to EARTHQUAKE.
Holding in DOWN for ground motion to settle, then will start relocking.
Just a note that the lockloss tool did not log this as an earthquake lockloss. The buildups are very clearly oscillating at low frequency in the last few minutes leading up to the lockloss, and the seismic FOM shows increased ground motion. I am not sure what triggers an earthquake tag in the lockloss tool but I figured it would be useful to know that the tool did not properly classify this one.
Following up on EJ's alog, I have extended the code to check if the unresponsive filter is under local control by the model. I ran it this afternoon while H1 was in observe, running in 'nice' mode so as to not hammer the frontends with CA requests (delays between requests).
If we disregard locally controlled filters, the number of unresponsive filters is reduced to 3 (see attached). The top one runs on h1lsc, the other two on h1lscaux.
Here is the full list, with locally controlled filters marked with *
Total numer of filtermodules = 13367
num unresponsive 14
h1lsc {'LSC-EXTRA_AI_2': 'FM2 '}
h1lscaux {'LSC-LOCKIN_1_DEMOD_9_I': 'FM1 ',
'LSC-LOCKIN_1_DEMOD_9_Q': 'FM1 '}
h1sqz {'SQZ-RLF_VCXO_SERVO': 'FM2* '}
h1alsex {'LSC-X_ARM_DRIVE': 'FM3* FM5* '}
h1alsey {'LSC-Y_ARM_DRIVE': 'FM3* FM5* '}
h1sussqzin {'SUS-ZM1_M2_COILOUTF_LL': 'FM1* FM6* ',
'SUS-ZM1_M2_COILOUTF_LR': 'FM1* FM6* ',
'SUS-ZM1_M2_COILOUTF_UL': 'FM1* FM6* ',
'SUS-ZM1_M2_COILOUTF_UR': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_LL': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_LR': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_UL': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_UR': 'FM1* FM6* '}
Turned thses filters off:
h1lsc {'LSC-EXTRA_AI_2': 'FM2 '}
h1lscaux {'LSC-LOCKIN_1_DEMOD_9_I': 'FM1 ',
'LSC-LOCKIN_1_DEMOD_9_Q': 'FM1 '}
Added gain of 1 filters to:
h1sqz {'SQZ-RLF_VCXO_SERVO': 'FM2* '}
h1sussqzin {'SUS-ZM1_M2_COILOUTF_LL': 'FM1* FM6* ',
'SUS-ZM1_M2_COILOUTF_LR': 'FM1* FM6* ',
'SUS-ZM1_M2_COILOUTF_UL': 'FM1* FM6* ',
'SUS-ZM1_M2_COILOUTF_UR': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_LL': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_LR': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_UL': 'FM1* FM6* ',
'SUS-ZM3_M2_COILOUTF_UR': 'FM1* FM6* '}
This should have no effect on anything.
Remove the controls from these filter modules:
h1alsex {'LSC-X_ARM_DRIVE': 'FM3* FM5* '}
h1alsey {'LSC-Y_ARM_DRIVE': 'FM3* FM5* '}
Turned these filters off after a model restart.
J. Kissel, S. Koehlenbeck, B. Lantz Sina and I are putting together material to help motivate an SPI installation some time in the future (see most recent material in G2300655 and G2300846), and one of the open questions is whether we can demonstrate (via model, or extrapolated measurement) that the P & Y input to, say, PR3 would be better after linking the platforms together in PITCH & YAW than the local table PITCH (RY) & YAW (RZ). This aLOG shows the first attempt at demonstrating this with data, sticking with PR3, and thus the HAM2 - HAM3 ISI system. Executive Summary: This initial look shows great promise for an SPI's ability to improve HAM2 and HAM3 platform motion across the 0.01 to 10 Hz frequency band -- differential X (longitudinal), as well as differential Y and Z converted to pitch and yaw motion, is factors of 2 to 200 better than local X (longitudinal), RY (pitch), and RZ (yaw). The key concepts here are - As it's *always* worth repeating, the input to the suspension point is different from table motion, and the optic motion is different that optic motion, *especially* when it comes to cross-coupling between degrees of freedom, like suspension point Longitudinal and optic Pitch, or platform X / RZ vs. optic Yaw. Even within the ISI, there's a good amount of cross coupling between RX/RY tilt DOFs and Y/X translation degrees of freedom, so using the SPI to improve ISI RY could improve ISI Y, which benefits PR3 suspoint L, with benefits PR3 optic P. So the motivation for an SPI, via looking at only one diagonal DOF at once will never make a clear argument for "we need an SPI!" So, we're doing an incomplete job if we look at only one DOF at once and say "improvements in this one DOF will clearing improve that one DOF." We'll only really know the true quantified benefit once we install one and see. But it's still interesting to look at the data in this way to get a feel for if it makes sense to even try. - The SPI may be used for different frequency regions for different purposes. PR3, for example, may not be limited by residual seismic motion at some frequencies for some degrees of freedom. We just need to be conscious of this when make sweeping statements like "PR3 is completely dominated by OSEM noise, you won't see any improvement unless we improve the local sensors on the top mass of PR3 -- so why should we spend energy on an SPI?" because that sweeping statement is true at 10 Hz, but not true below ~3 Hz, and an improvement below 3 Hz might be benefit to the IFO in subtle ways like "we can reduce the bandwidth of the ASC loops, which means the ASC sensor noise doesn't couple into DARM at 10-15 Hz." - In modern parlance, when we say an "SPI" we really mean a 3 DOF collection of sensors rather than "just" a 1 DOF seismic platform interferometer: :: SPI L :: a longitudinal sensor -- the interferometer part, which uses an asymmetric michelson IFO (short arm stays local to the launching platform, and the long arm spans the 16 m distance between the two platforms) to determine the relative distance between the platforms. :: SPI P :: an "optical lever" like pitch sensor measuring differential pitch of the platform (expected to be dominated by the difference between local Zs rather than local pitch RYs) :: SPI Y :: an "optical lever" like yaw sensor, measuring differential yaw of the platform (expected to me dominated by the difference between local Ys, rather than differential yaw RZs) - Fundamentally, why an SPI wins in P and Y is the lever arm of sensing. The local sensing of pitch (RX / RY) or yaw (RZ) is the difference or sum of inertial sensors across the width of the table, a lever arm of ~1 [m]. One the other hand, if we can tie pitch/RY or yaw/RZ one platform (say HAM2) to the other (HAM3), but using the lever arm *between* the platforms -- L = ~16 [m] -- and this is *better* than the local interial sensing, we improve both local platform's motion by something like sqrt(2) / L. The details of of the improvement depend on a lot of things, and we'll get there, but at least conceptually, this is the promised improvement. - Another point to emphasize is that *we don't yet know the optimal controls topology and/or frequency region that these 3 DOFs will be used.* Depending on the results, it may be interesting to compare the local inertial sensors to the SPI sensors, or the local CPS to the SPI sensors. What frequency region we blend in the SPI vs. the local platform's inertial and displacement sensor array is still unclear. So the plots below compare both against the SPI. You'll see that the differential signals are better in some frequency regions and worse in others. This is all still to be understood and schemed upon, so my commentary below should be treated as "first impressions." - Remember that depending on the frequency band, the CPS or GS13s are "in loop," forming the error signal for the feedback loops, which have UGFs of around 30 Hz. I indicate a "CPS Rolloff Frequency" with vertical lines on all the plots -- where the vertical line is set at the frequency above which the CPS contribution to the super sensor is less than 1.0. (Note, this is different from what has traditionally been referred to as "the blend frequency," which is instead a center point of equal contributions of GS13 and CPS. Because - gain peaking is involved at that "blend frequency" cross-over point, - that gain peaking can be large and/or span across a lot of frequency space, - GS13 blend filters are not easy to plot because of the embedded inertial sensor calibration and - AFAIK, no one's plotted them in their easy-to-digest complementary form recently, I chose the more straight-forward, easily findable, "when does the CPS contribution to the feedback loop start to roll off" frequency. These frequencies are close, of course, but not the same.) - I'm concocting "differential motion" between the HAM3 and HAM2 platforms by coherently subtracting one platform's DOF from the other platform's corresponding DOF. Since the data is recorded and synchronized by the CDS system, one simply needs to download the two platform's data over the same time period and subtract one time series from the other and it's a "differential motion coherent subtraction." - Of course, sensor noise is always of concern when doing differential measurements. As best I can, I use the estimates of the GS13 and CPS sensor noise from our old friend SEI_sensor_noise.m (T0900450), and I (a) Assume every colocated sensor of a given type has identical noise (b) Scale them to the appropriate cartesian degree of freedom, assuming all sensors are incoherent, by taking the quadrature sum of the given sensor type's input matrix from /ligo/svncommon/SeiSVN/seismic/HAM-ISI/Common/Basis_Change_Matrices/aLIGO_HAM_ISI_2_3.mat (c) Look at the results, find where the *Z* DOF is limited by sensor noise the real data, and scale every type's sensor noise in (a) by a single scalar fudge factor to match the real data (d) For differential sensor noise between the 2 platforms, I then multiply that DOF's sensor noise by a factor of sqrt(2). What motivating data I'll show and why (I) SPI Longitudinal (the "interferometer" part of the SPI) would measure the differential distance between the HAM2 and HAM3 in X. So, to motivate the benefit of SPI L we'll compare an individual platform's X motion against the differential X, (HAM3 X - HAM2 X). (II) SPI Pitch (one "optical lever" part of the SPI) would primarily measure the differential Z (vertical) motion between HAM2 and HAM3 in Z. So, to motivate the benefit of SPI P we'll compare an individual platform's RY motion against the differential X, (HAM3 Z - HAM2 Z) *divided by the lever arm between the platforms, L.* (III) SPI Yaw (the other "optical lever" part of the SPI) would primarily measure the differntial Y (transverse) motion between HAM2 and HAM3. So, to motivate the benefit of the SPI Y, we'll compare an individual platform's RZ motion against the differential Y (HAM3 Y - HAM2 Y) *divided by the lever arm between platforms, L.* OK, Now to the data. For starter's I grabbed *one* 3 hours of data starting at -- last night, 2023-06-09 at 09:30 UTC (02:30a PDT, GPS 1370338218). The wind is low (< 10 mph), the microseism is around 0.1 [um/s], no earthquakes, and the IFO is locked, observing, in nominal low noise busy detecting gravitational waves. Note, that the RZ loops include Jim's new-and-improve blend filters that improve the local RZ performance by factors of 5 to 10 between 2 - 20 HZ. LOCALX_vs_DIFFX shows the performance metric comparisons for SPI L. - The differential GS13 signal is about the same as the HAM3 local sensor for most of the frequency band. There's *some* areas below 0.5 Hz where the differential X GS13 would be better, but out of the nominal frequency region where the GS13 is used in loop. - Below 7 Hz, the differential CPS is better than the local CPS by factor ranging from 2 to 20. - Below the "CPS rolloff frequency" for this DOF, 0.34 Hz, and SPI measuring this same differential motion (without being limited by its own sensor noise) would improve things over each local CPS by a factors of 2 to 5. Promising! LOCALRY_vs_DIFFZoverL shows the performance metric comparisons for SPI P. - Here, we see a HUGE difference in performance between the local sensors and platform-to-platform differential sensors. - Assuming that the SPI optical lever has sensor noise below this level of rotation, would should be able to get a huge amount of improvement, and we'd have our pick of which sensor to use where, since both local CPS RY and GS13 RY sensors are MUCH worse than differential Z. - The only place where the differential motion is comparable (note -- comparable, not worse!) is in the ~10 Hz region where differential HEPI pier motion between the two platforms is, well, different. *Very* promising! LOCALRZ_vs_DIFFYoverL - Similar to the SPI P plots there's lots of frequency regions where SPI Y, informed by differential HAM3 - HAM2 Y would be better than local RZ. However, this DOF is probably the most confusing, because we know that each local table Y is limited in the 0.07 to 5 Hz region by local RX tilt (from local RX sensor noise across the ~1 [m] lever arm). So differential Y is limited by RX tilt, where differential Z is not in anyway limited by tilt. So we don't expect to get *as much* benefit out of an SPI Y, but we'd definitely still get some if the chambers are left as is. However, we also know that the ISI local RX sensor noise can be improved by installing better CPS sensors, like we've done for the HAM7 HAM8 systems. So, the story is a little longer here, but still... *Very* promising! Next on the to-do list: (1) Gather HAM3-HAM2 data at different environmental times, to see whether any of the above conclusions from this one data set change. (2) Compare this differential GS13 and CPS data against Sina's projections for sensor noise (3) Use this (and other data we gather) data to try to concoct a control strategy (4) Use that control strategy to estimate the improved platform and suspension performance in various scenarios including (i) If we also improve the HAM-ISIs to use fine vertical CPS sensors (i) If we also improve PR3's top mass sensing noise (5) Present this kind of progress to the systems group
A few more plots that show the sanity checks I made that went into the plots presented above:
- HAM23_SPIMotivation_Z_CPS_ts.pdf Demonstrating that differential HAM3 Z - HAM2 Z is just the two time series subtracted, and there's no funny business going on in the time series data I used during this 3 hour time stretch.
- HAM23_SPIMotivation_Z_GS13CPS_noise_and_cal_check.pdf Demonstrating that the calibration of the data all makes sense, as well as the projections and fudge factors of ~0.5 and 1.2 on the sensor noise are legit.
- HAM23_SPIMotivation_Z_vs_DIFFZ_GS13.pdf showing GS13 inertial motion alone for both HAM2 and HAM3 compared to sensor noises.
- HAM23_SPIMotivation_Z_vs_DIFFZ_CPS.pdf showing CPS ground-to-platform relative motion alone for both HAM2 and HAM3 compared to sensor noises.
The raw data for this aLOG has been downloaded and saved to
/ligo/svncommon/SeiSVN/seismic/Common/Data/
2023-06-09_0930UTC_HAM23_timeseries.mat
The script to make the plots from that data lives in
/ligo/svncommon/SeiSVN/seismic/Common/SPI/Scripts/
plot_spi_motivation_20230609.m
A quick screenshot to show where I got the "CPS Rolloff Frequency" for each of the blend filters For the X, Y, and Z blend filter, which are all the "comp_250" filter, the CPS rolloff frequency is 0.34 Hz. For the RX and RY blend filters, which are the "many_notches" filter, the CPS rolloff frequency is 0.60 Hz. For the new RZ blend filter, called the "fc_yaw_filt_lp", the CPS rolloff frequency is at 0.34 Hz. As a bonus, included in the screenshot is a reminder of what the CPS2CART and GS132CART matrices look like for sensor noise projection.
Quick comment on the Noise projection plot
SEI_sensor_noise includes the local to cartesian-basis noise correction factors (added in 2021)
see SEI log 1786, or the help the SEI_sensor_noise
For Example.
>> freq = logspace(-1,2, 1000);
>> cps_noise_1mm = SEI_sensor_noise('ADE_1mm', freq);
>> proj = SEI_sensor_noise('projections');
>> stg1_cps_x_noise = proj.bsc.stg1.cps.x * cps_noise_1mm;
Regarding the influence of CPS DIFF on these results
J. Kissel, A. Pele, J. Warner
Arnaud reminded that CPS DIFF exists -- and asks the legit question "is CPS DIFF on, confusing your results and conclusions?"
In short: Yes, (HAM3-HAM2) CPS diff is ON, and influencing platform motion between 1.5 mHz and 0.48 Hz.
I then got a kitchen download from Jim, which I now convey here backed up with plots and MEDM screen screenshots. In general, CPS DIFF is really tough to find. You can find the "overview" that starts with
sitemap > ISI SENSCOR CONFIG > (upper right corner) Yellow Button "ISI DIFF" > CPS DIFF MTRX
This brings up the "start" of CPS DIFF -- the 2023-06-12_ISICPSDIFF.png screen, which ingests calibrated local CPS signals (prior to their corner-station sensor correction from the ITMY T240 in the biergarten), and "simply" subtracts them. One can see that for the corner station HAMs, there are only the two pairs subtracted and only in the IFO's longitudinal direction: (HAM3 - HAM2) X and (HAM4 - HAM5) Y.
In these cases, HAM3 is the "leader" and HAM2 is the "follower," and similarly, HAM4 is the leader, and HAM5 is follower.
Following the HAM3-HAM2 signal, that differential CPS signal is then fed into a single filter bank, H1:ISI-DIFF_HAM3_CPSX (see screenshot).
That filter module in use in that HAM3 bank is "better60mHz," which is a band-pass
- "active" (magnitude greater than 10%) between 0.0015 - 0.48 Hz,
- "focused" (magnitude greater than 90%) 0.022 - 0.088 Hz.
- "centered" (phase is 0 deg) on 0.034 Hz
See the response of this filter in 2023-06-12_ISICPSDIFF_HAM3-HAM2_better60mHz_Filter.png.
The output of that filter bank output is feed into a "soft limiter" that limits the signal to less than 10000 [nm] = 10 [um]. (see 2023-06-12_ISICPSDIFF_SmoothLimiter.png)
The typical counts coming out of our band-limiter is low 10s [nm] oscillating around 0 [nm], which maximum minute of the trends being at most 100-150 [nm], so *plenty* of head room. So, in short, the soft limiter it's doing anything.
The output of the soft limiter goes into the "leader" ISI's SUSINF "suspension input filter" H1:ISI-HAM3_SUSINF_X bank (see 2023-06-12_ISIHAM3_SUSINF.png), which again is the longitudinal direction of the IFO across HAM3-HAM2.
Finally, this output is summed into the *output* of the blend filters, i.e. the super sensor error signal for the X DOF's isolation filters.
2023-06-12_0930UTC_ISICPSDIFF_HAM3-HAM2_ControlSignal_3hrMinuteTrend.png shows the minute trend of the HAM3-HAM2 CPS DIFF band-limited control signal for the 3 hour stretch on 2023-06-09 09:30 UTC that I took the data in the main aLOG. 2023-06-12_0930UTC_ISICPSDIFF_HAM3-HAM2_ControlSignal_ASD.png shows the amplitude spectral density compared against CPS X DIFF = sqrt(2) * HAM "1 mm" ADE CPS X sensor noise (using the handy feature of SEI_sensor_noise Brian reminds me of above -- thanks Brian!).
This amplitude spectral density is consistent with the shape and amplitude of the (HAM3-HAM2) offline concocted ASD differential signal above 2023-04-13_0000UTC_HAM23_SPIMotivation_spiprcl_LOCALX_vs_DIFFX.pdf.
I attribute the difference in shape due to different averaging, windowing, and % overlap, and FFT parameters, so don't look too closely. This needs to be done more carefully offline, and I will eventually.
So,
- (HAM3-HAM2) CPS DIFF is *already* doing the same job that I describe that a future SPI L "the ifo part" connecting HAM3-HAM2 would do.
- Deciding which would do it *better* and/or which we should use in which frequency region is a question of which will have better sensor noise.
- Both should be a part of the discussion.
- CPS DIFF does *not* play a role in any of the material / data / plots discussing SPI P and SPI Y, since HAM3-HAM2 Z (for P) and HAM3-HAM2 Y (for Y) do not have any CPS DIFF.
Note, the plan to improve the "the HAM2 HAM3 CPS" won't impact this assessment; at the moment, we're only considering upgrading the *vertical* CPS sensors on the HAMs.
This has been kind of hard to pick out, but it definitely seems like the IFO is less robust now against earthquakes that it was before increasing power over 60W in the IMC. Basically since then, we haven't been able to stay in NLN for any earthquakes over ~.5um/s, as measured by the peakmon eq witness channel.
Attached plot shows peakmon vs lock state trends since Feb 10 this year. The blue trace is the peakmon ground velocity minute trend, each green point indicates where the IFO was still locked 2 minutes after a local maximum ground velocity (found using the matlab peakfinder routine with some prominence and time separation requirements). The two marked points indicate where IMC power was increased above 60W (X=79730 minutes after Feb 10th) and the start of the run (X=148255 minutes after Feb10). Before power up we had multiple locks survive multipe 500nm/s eqs, a few around 1micron/s and one at almost 3micron/s. After the power up, the IFO doesn't ride out any eqs over 500nm/s and we basically not survived any notable eqs since the start of the run.
This is further reinforced by TJs alog from earlier today, when SEI_CS transitioning knocked us out of OBSERVE. Unless SEI_CS got dropped off the exclude recently, I suspect we never noticed because we were losing lock before the seismic system switched.
There have been no changes to the SEI eq controls. I looked at the small eq Camilla noted this morning and didn't see anything suspicious in the seismic systems, but I'll keep digging.
I will also add that this ~.5micron/s eq-band velocities are a level that the primary microseism can hit for a week or two at a time during the winter. Conditions that were already challenging for us in prior runs.
Another possible culprit from around the time of April 7: removing 12 dB of low-frequency (< 1 Hz) gain from the Michelson loop to try to reduce the amount of sensor noise reinjection in the GW band (LHO:68432).
It would be a relatively simple test to (1) increase the EPICS gain of the loop by 3 dB to place the UGF back around 10 Hz, and then (2) re-engage the 4:1 Hz boost (LSC-MICH2 FM3). If the noise increase in DARM is acceptably low, perhaps you could run like this for a week to see if the duty cycle improves.
If this extra gain helps during EQs, it could also be made part of the EQ guardian response.
Brina, Sheila,
We ran some excitations while locked, need to review plots (will come back to alog to update info)
I looked again at DARM at 60W vs. 75W, comparing sqz and no-sqz for both. Each DTT trace uses 8 seconds, 50% overlap, 100 averages.
Lighter colors. 60W times used from 68251, w/15dB generated sqz.
Darker colors. 76W times from 6/4, ~3 hours into lock (semi-thermalized, past fast initial thermalization).
See the summary page with this time window-- comparing red vs. black in this screenshot, I don't see obvious + excess noise with the squeezer on below 50Hz, when we are past fast initial thermalization.
Re: "fast initial SQZ thermalization" -- For reference, see the V-shape in blue that DARM takes with the fast 0.5-1 hour SQZ thermalization from a cold IFO (even unlocked for just 1-2 hours). Notably, in the first 0.5-1 hour, esp if the IFO was cold, the fast-thermalizing-SQZ (blue) exceeds the no-sqz noise (red) both below 50 Hz, and above 1kHz. I think this is related to the rapidly thermalizing SRCL detuning, which rotates squeezing across the band for the first 0.5-1 hour. To fix this SRCL detuning problem for sqz misrotation, I think we'd need to thermalize the SRCL offset; it wouldn't be sufficient to thermalize the sqz angle. If we have to pick an angle, we should pick the sqz angle that optimizes the bucket noise ~100 Hz; this is the most stationary as SRCL thermalizes. I think for calibration, Jeff sees this too as wildness in the rapidly thermalizing sensing function at the start of locks. This effect seems more prominent from an cold IFO, as it seems more muted of a V-shape when IFO relocks quickly (not much down/cold time).
Note the excess noise 20-50 Hz in the 60W vs. 75W configuration. Brina is now looking into understanding the calibration status and LSC coherences for these sqz and no-sqz times.
Here is are a few plots comparing the LSC coherences from MICH, PRCL, and SRCLbetween these times with/without the SQZ, it seems that the SQZ/noSQZ plots for the same days look similar in some regions, but there is more coherence in the 76 W dates.
(just updated the image to match the range from the DARM plots and updated the H1 live to a recent time today (06/09/23)).
Additional screenshot including DARM 76W at 20mA here, no-sqz = dark green ; fds = purple. Looks like these DARM times were taken during a contrast defect scan, seen by squeezer too.
Couldn't edit my previous comment to update the image so here are the updated coherence plots.
I took some recent times at 60W and 76W and made some power trend plots of the first three hours of the lock. The 60W time is from a long lock around March 29th, and the 76W time is from a long lock around April 29th. Unfortunately the time for the April 29th lock we had the POP beam diverter closed, so we are missing the sideband trend during thermalization.
I found a shorter lock at 76W on April 20th where the POP beam diverter was open. Trends attached.
I have attached another set up plots, this time adding in a 60W lock trend from early January.
One major effect we have considered when looking at these plots is the trend of the 9 MHz sideband as the IFO thermalizes. If you look at the first plot in both the main alog and the two comments, the bottom right corner has two plots showing the POPAIR RF18 and RF90 trends, effectively the 9 and 45 MHz buildups. When we lose our 9 MHz sideband, PRCL becomes unstable. Currently, the thermalization guardian works to correct exactly this, by increasing the PRCL digital gain to maintain a ~30 Hz UGF. We have mainly seen this as an issue with operating at 75 W. However, these power trends are showing us that the 9 MHz loss is present at 60W too, and Evan and Dan held the IFO at 25W a few months ago and demonstrated that this loss occurs even at low power.
The new plot I have added is an interesting comparison. On the POPAIR RF18 plot, you see that the blue trace- 76W lock from April 20, shows that we power up and then lose significant 9 MHz power. The red trace shows something similar from Jan 6 in a 60W lock. We also see this loss in a March 60W lock. I included the red trace to compare with the green trace because in the green trace we stopped at 25W for long enough to lose some 9 MHz, and then continued up in power. The green trace is also after we have improved the mode matching with new ring heater settings. It appears that build-up wise, our current situation is very similar to where we were in January.
However, this is further proof that we see 9 MHz loss no matter which operating power. I will look for more locks to compare and see if the difference between the red and green traces at 60W is a result of the TCS change. One thing to note in particular is that the ring heater changes reduces the build ups, so from January in red to March in green, we reduced the power recycling gain at 60W.