Displaying reports 20181-20200 of 87736.Go to page Start 1006 1007 1008 1009 1010 1011 1012 1013 1014 End
Reports until 15:30, Monday 15 May 2023
H1 CAL
louis.dartez@LIGO.ORG - posted 15:30, Monday 15 May 2023 (69561)
new calib ready to be pushed
J. Kissel, L. Dartez

On Friday we generated a new calibration report in anticipation of updating the LHO calibration, a process discussed in LHO:69563. The report can viewed at https://ldas-jobs.ligo-wa.caltech.edu/~cal/archive/H1/reports/20230510T062635Z/H1_calibration_report_20230510T062635Z.pdf. You can view all of the report's contents by removing the file stub at the end of path (or by clicking here). 

In short, we believe we're ready to update the calibration for LHO to reflect several changes to the sensing function that have been implemented over the past few weeks* (LHO:69402, 69359, 69358, 69487, 69478).



Before generating this report, we carried out various "checks" and preparation steps to improve our confidence in the estimated calibration parameters.


Process measurements taken with a fully thermalized IFO
=======================================================

We pruned the sensing function measurements we had in the can** to ensure that only measurements taken with a thermalized IFO were processed. Measurements (especially those of the sensing function) taken while the IFO is still thermalizing, during which the sensing function is in a constant state of flux, will result in inconsistent GPR results and throw off our estimation of the optical gain, coupled cavity pole frequency, quality factor, and spring frequency. I moved the "unthermalized" measurements into a new directory titled "unthermalized" within the measurements directory. This is not an optimal part of the workflow we would like to support going into O4 so it'll need to be addressed down the road. The thermalization state was checked by inspecting H1:ASC-Y_PWR_CIRC_OUT16 and H1:ASC-X_PWR_CIRC_OUT16 in ndscope.

GPR frequency range
===================

We moved the lower limit of the GPR fit range down to 5Hz to include the low frequency content (<10Hz). Doing so resulted in much more sensible GPR output at low frequencies. We are using the same GPR kernel as in O3 (LHO 55012).


Confirm optical gain calculation
================================

We confirmed that the estimated optical gain almost exactly matches the old optical gain value * KappaC. 


Coupled Cavity Pole Frequency Estimation
========================================

We noticed that Fcc is off by ~4Hz. We're not sure why at this point but we're not too concerned; the Fcc Kappa TDCF will take care of this discrepancy for us in the front end.


Reports included in the current epoch.
======================================

20230504T055052Z epoch epoch-sensing epoch-actuation
20230505T012609Z 
20230505T174611Z 
20230505T200419Z 
20230506T182203Z epoch-sensing
20230508T180014Z 
20230509T070754Z 
20230510T062635Z 


======
* assuming that the ongoing attempts to suppress the ~4Hz bumps in DARM do not affect the sensing function

** All (LHO) calibration measurements made by pyDARM are stored in /ligo/groups/cal/H1/measurements/.
H1 General (OpsInfo, SEI)
anthony.sanchez@LIGO.ORG - posted 15:09, Monday 15 May 2023 - last comment - 15:57, Monday 15 May 2023(69605)
I pushed Jims Fence Work Button

Jim has a Fence Work Button. So when Folks go out to work on the Wind Fence us Operators can push this button.
And when they are done we can push the Nominal button under it.
I pushed the Nominal button now that wind fence work is no longer happening.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:57, Monday 15 May 2023 (69608)CSWG, DetChar, OpsInfo, SEI
For the record (even though we won't need this feature after this week, since EY wind fence work is wrapping up; see LHO:69599), 
this "script" (which is really command line calls from medm) is leaving sensor correction *ON* at EY, but reconfiguring it to only use the ground T240 alone (aka the ground "STS" configuration), rather than the combination of the ground BRS and T240 (aka the ground "Super Sensor" or "SS" configuration). 

For a description of the origin of this process and filters, see LHO:69162.
See LHO:69269 for the introduction of this button.


caput H1:ISI-ETMY_ST1_SENSCOR_Y_NEXT_CHAN 4      ## Engages "Bad Stuff" filter on the common mode sensor correction signal, in the Y direction, received from the corner station
                                                 ## switches from "NORM_FILT1" to "NORM_FILT4" bank using the new sensor correction filter fader interface.
                                                 ## Find this filter from sitemap > ISI ETMY overview screen > "Gnd -> St1 SENSOCOR" button > "Filter Selection" button 

caput H1:GRD-ISI_ETMY_ST1_SC_OP PAUSE            ## Pauses the sensor correction guardian so it doesn't interfere with this out-of-nominal configuration
                                                 ## Find this guardian's MEDM either from the same ISI ETMY overview screen, or the sitemap > SEI > ISI SENSCOR CONFIG screen

caput H1:SEI-EQ_CM_EY_MTRX_SETTING_1_2 0         ## sets the use of the ground super sensor, "SS" element to zero, setting up to turn that configuration OFF
caput H1:SEI-EQ_CM_EY_MTRX_SETTING_1_1 1         ## sets the use of the ground T240 alone, "STS" element to one, setting up to turn that configuration ON
caput H1:SEI-EQ_CM_EY_MTRX_LOAD_MATRIX 1         ## hits the LOAD MATRIX button to hit GO on a 30 second ramp to switch the configurations as directed above.
                                                 ## Find this MEDM screen from sitemap > "Eq Common Mode Overview" > "CM Matrix"


So, if anyone in DetChar or SEI is interested in trending when we were vs when we were not in this configuration over the past few months, you can trend the above listed channels (probably the matrix elements are the most decisive).

H1 PSL
anthony.sanchez@LIGO.ORG - posted 14:57, Monday 15 May 2023 (69604)
PSLweekly!

FAMIS 21440 PSLweekly


Laser Status:
    NPRO output power is 1.833W (nominal ~2W)
    AMP1 output power is 68.54W (nominal ~70W)
    AMP2 output power is 135.2W (nominal 135-140W)
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN

PMC:
    It has been locked 6 days, 1 hr 55 minutes
    Reflected power = 15.79W
    Transmitted power = 110.0W
    PowerSum = 125.8W

FSS:
    It has been locked for 0 days 0 hr and 1 min
    TPD[V] = 0.8171V

ISS:
    The diffracted power is around 2.5%
    Last saturation event was 0 days 0 hours and 44 minutes ago


Possible Issues:
    PMC reflected power is high -- I spoke to Jason about this issue and he has been aware of it. Ryan and him will Change that in the code, eventually.

 

H1 CAL (CAL, DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 14:54, Monday 15 May 2023 (69593)
3D Bode Plots of SRC Detuned Optical Spring During Thermalization
J. Kissel

Executive Summary: here are some cool time-frequency ways to look at how the sensing function evolves during thermalization. No new information on the cause, and no conclusion about what to do -- only hints at patterns and identification that more work and data is required to create the "even though the details are inconsistent from lock to lock, we could get away with doing this simply thing" solution that everyone wants.



Picking up from LHO:69478, where we last left off characterizing sensing function during thermalization -- we were left craving more from the bode plots of the sensing function as it evolved in time. We identified that, right after power up, we're actually *over* correcting for SRC detuning with the fixed SRCL offset that "re-tunes" the SRC after everything's thermalized. 

So the natural follow-up question -- given that we're adjusting the SQZ subsystem and PRCL loop gains during thermalization with the THERMALIZATION guardian node (see, e.g. LHO:69441 and LHO:68948) -- can we do something similar with the SRCL offset? 

In order to answer that question, we need to understand the time evolution of the thermalization better than heat-map 2D bode plots shown as the feature plots LHO:69478. Namely, one might expect that the evolution is (natural logarithm, base e) exponential, given the shape of the time evolution we typically see from the arm power. 

Here, I present a collection of plots of that same data that I'm calling "3D Bode Plots." Here, I repeat the info about each thermalization segment, and show the plot 3D bode collection associated with it:
Period  UTC Start             UTC Stop    GPS Start      GPS Stop     Segment             3D Bode Plot collection
        YYYY-MM-DD                                                    Duration (hours)
(A)     2023-05-09 01:15:00   04:30:00    1367630118     1367641818   3.25 (3h 15m)       sensingFunctionResidual_meas_over_model_wTDCFs_1367630178-1367641698.pdf
(B)     2023-05-10 08:41:00   10:12:00    1367743278     1367748738   1.51 (1h 30m)       sensingFunctionResidual_meas_over_model_wTDCFs_1367743338-1367748618.pdf

(C)     2023-05-10 11:19:00   14:00:00    1367762418     1367752758   2.68 (2h 40m)       sensingFunctionResidual_meas_over_model_wTDCFs_1367752818-1367762298.pdf


For each segment, I show 4 pages of the "normalized sensing function," i.e. ratio of 
    - the measured sensing function (from the 8.9 to 24 Hz pairs of calibration lines, continuously driven by the CAL_AWG_LINES guardian) to 
    - the modeled sensing function (which has *no* detuning, but is corrected for changes in optical gain and cavity pole from the 410.3 Hz calibration line informed TDCF):
in various different ways.
    :: Page 1: A replica of what you've seen as the feature plot in LHO:69478 -- a two-panel, 2D bode plot of the sensing function, where the "heat map" coloration indicates the 2 minute steps in time.

    :: Page 2: The first of the 3D bode plots, showing four panels. 
        In the left two panels, I show essentially the same bode plot as Page 1 -- the frequency axis "forward" and the transfer function magnitude / phase on the vertical axis -- but enhanced in a third, where the dimension "into the page" is time (in minutes). So, X axis is frequency (in Hz), Y axis is time, and Z axis is the sensing function transfer function ratio's magnitude (upper, in [ct/m / ct/m]) and phase (lower in [deg]). With this view, you can actually resolve the 2-minute time steps that we didn't see in the first page.
        In the right two panels, it's the exact same 3D Bode plot, just with the vertical, Z axis (transfer function magnitude and phase) zoomed in to the range that we typically care about for calibration, between 1.0 to 1.25 and -5 to 30 deg, i.e. from 0 to 25% systematic error in the sensing function. With that zoom, we can quantitatively read off the sensing function's systematic error *after* thermalization, and compare against thermalized data.

    :: Page 3: The second of the 3D bode plots, also showing the same four panels, but yawed by 90-ish degrees such that now the Y, time, axis is "forward." It's with this view that we can actually see the time evolution of the detuning clearly.

    :: Page 4: The third and final 3D bode plot, where the axes are rotated/showed with the same yaw as page 3, but with the time axis displayed as the natural logarithm of time (in "ln(min)"). with this view, one can eye-ball which regions of the time evolution is "exponential" and which are not. Just so you don't have to calculate it yourself, 
        ln(min)    min    approx hours
        2      7.5     ~1/8    
        3     20.1     ~1/3
        4     54.6     ~1 
        5    148.4     ~2.5
        



What I conclude from these collections of plots thus far :
    (1) The later parts of the data segments, between "20-25 minutes after achieving final input power" and "thermalized," where to-date we think it's "just" the substrate of the ITMs thermalizing, these data seem to suggest that the thermal process it isn't necessarily exponential, but it seems close. 

    (2) The earlier parts of data segments, between "just after achieving final power" and "20-25 minutes after achieving final input power" is confusing. My suspicion is that there's two things that are confused in these first 30 minutes (i.e. at around ):
        (i) The data is noisy / less coherent. The landing at NOMINAL_LOW_NOISE is not a soft landing. Shutters are closing, whitening is getting switched, laser noise suppression is getting adjusted, etc -- all within 30 seconds of the declaration of "nominal low noise," so the DARM sensitivity is full of transients and glitches (at least according to the 10 sec, 3x rolling average, ASD on the front wall). So would guess *at least* the first 2 minute data point is spoiled by this non-stationary noise.
        (ii) We know there are several different time-scales of thermalization in play -- point absorbers, front-surfaces of optics, and the last-and-longest the substrates of the test masses. All are thermal processes, each with their own exponential time-scales all intermixing. We've learned from O3 that most of the shorter time scale heating is in equilibrium by ~30 minutes in. So my guess is that we see the transition to a single "clean" "exponential" of the test mass substrate by 30 minutes. ("clean" in quotes because it's only one process, and "exponential" because of point (1) above that the evolution is not quite exponential.

    (3) I need to synchronize the time axes between the three data sets to be really quantitative about it -- other than it being a "pro" spring, where the magnitude has a sharp feature with high quality factor -- the evolution of "the spring" is not consistent during the early parts of the thermalization.



Things I really want next as a result of this study:
    (a) more, lower, frequency points. At the current level of detuning at the start of the thermalization, I suspect the 8.9 Hz data point is at the upper-frequency edge of the detuned optical spring frequency. However, given that there are other sensing function response features in play, I'd love to see more data below 8.9 Hz to really resolve "the whole spring" response. Especially because the phase seems to be doing an entirely different thing for each of the three data sets during the first 30 to 60 minutes. The standard sensing function sweeps takes data all the way down to 5.6 Hz, so that'd be a good place to start. There was no magic to these three frequency points, they were arbitrarily chosen, as documented in LHO:68947, because 
        (i) they were the four data points I could tune with a DTT template, and
        (ii) that was the limit of PCALY lines I could drive, at the amplitude chosen, and still have the other more critical PCALY lines going.
    (b) synchronizing the thermalization period to a point in time these three test cases were just the first couple of data sets that I had started this study. The length of segment was chosen, and start time of plotting was chosen only be what data was available. At this point, with how the data is displayed, and the few number of data points, it's still difficult to assess whether the thermalization behavior is consistent. This should be doable by finding the time, say, at which the arm cavity power surpassed a given power, or the moment the guardian declares that the PSL power has hit 76 W or something. Now need for new data here, just more sophisticated offline analysis.
    (c) more data sets. These should be in the can already, but the data is clearly disobeying the "three makes a pattern" rule.
    (d) *If* we decide to leave the IFO as is, and decide *against* "actively" tune the SRCL offset with the THERMALIZATION guardian, (again because running out of time before the run) then we must make a decision on how we want to incorporate this time-dependent, sensing function systematic error into the overall modeled response function systematic error. In O3, we "just" used GPR fitting because that's what infrastructure we had available to us at the time. It's a blunt weapon, and honestly, for the O3 IFO -- who's thermalization period lasted only 1 hour -- we figured "good enough." But now that
        (i) the systematic error as a result of this detuning is so large (at the 11.575 Hz data point, greater than 20% in magnitude and 15 degrees in phase for over an hour), and
        (ii) the detuning causes the "we don't have any detuning" model to be greater than 10% and 10 deg for more that 2.5 hours, and thus spanning several time periods of modeled, response function systematic error estimates used for data analysis
    I think we'll have to figure out more sophisticated logic for accounting for this error as a function of time than what we used in O3 ... which was "just" "look for the first hour of a NLN segment that had recently come from low input laser power, and apply *the* single, O3 model of that sensing function systematic error transfer function to the overall budget."




Stay tuned while I fulfill my own requests.
Non-image files attached to this report
H1 CAL
louis.dartez@LIGO.ORG - posted 13:56, Monday 15 May 2023 (69563)
Calibration Process for O4

Background

Updating the calibration for the IFO is done via a process that the Calibration group often refers to as "pushing a new calibration". This process entails the following discrete steps:
  • Based on a curated set of measurements, estimate the optical gain (Hc), coupled cavity pole frequency (Fcc), and [UIM, PUM, TST] actuation strengths as free parameters.*
  • Populate the pyDARM parameter model set (a.k.a. "the ini file") with the free parameters in the previous item. pyDARM uses these parameters to model IFO.
  • Calculate the values of various DARM model transfer functions evaluated at calibration line frequencies and caput them into their corresponding EPICS channels. The Calibration group often narrowly refers to these channels as the "TDCF EPICS records channels".
  • Encode the free parameters (Hc, Fcc, Q, Fs, HAUIM, HAPUM, HATST) as Foton ZPK design strings and install them in their respective CAL-CS filterbanks in /opt/rtcds/userapps/release/cal/[h,l]1/filterfiles/[H,L]1CALCS.txt. **
  • Manually export the sensing and actuation foton filters that need to be compensated for (removed) downstream as transfer function text files and update their paths in the pyDARM parameter model set. (LHO:47948) ***
  • Generate FIR filters to be applied by GDS pipeline
  • Copy the now updated pyDARM parameter model set, GDS FIR filters, and "Foton exports" to a place where the GDS and uncertainty pipelines can access them and their associated files.****
  • Restart the GDS pipeline.
  • Point the hourly uncertainty calculation to the latest GPR fits.

pyDARM Report System

Over the past several months the Calibration group has been working on building and putting into place the infrastructure needed to purge the "pushing a new calibration" exercise of its manual and most time consuming processes. Working out of a pyDARM branch called "cmd-dev", we are in the final stages of getting everything into place for O4. The new infrastructure is based upon a "report generation" system. pyDARM will now handle taking calibration measurements, processing them to estimate the free parameters, and everything (LHO:67594, LHO:69229, LHO:68267, LHO:67061) listed above except for the last two items. We are pending a full write-up that lists all of the new commands and their features. You can view the latest pyDARM report directory for LHO at https://ldas-jobs.ligo-wa.caltech.edu/~cal/archive/H1/reports/20230510T062635Z/. The report itself, which members of the calibration and commissioning groups will use to determine whether to update the calibration, will be stored as [H,L]1_calibration_report_[report timestamp].pdf (e.g. H1_calibration_report_20230510T062635Z.pdf).

Update regarding foton exports

Most recently implemented is the capability to automatically call Foton and generate the "foton export" files as each report is generated. The resultant foton export file is now placed within each report directory as [H,L]1CALCS_InverseSensingFunction_Foton_tf.txt. ===== * At present, we also estimate residual delays associated with the optical gain (H_c) and the actuation strengths (H_A). However, these delays are not currently used once they are estimated and are typically simply thrown away or stored and forgotten about. ** Of these, the most "critical" are often the sensing function parameters (Hc, Fcc, Q, Fs) because the sensing function changes on time scales that are much shorter than those of the actuation stages. *** This is necessary because there are differences in how Foton and python generate transfer functions from zpk designs, especially at high frequencies. So in order to properly compensate for these filters as they are applied we export them as computed by Foton and carry these text files around for downstream processes to import and divide them out. **** For O4, this will be at ldas-jobs.ligo-[wa,la].caltech.edu/~cal/archive/[H1,L1]/reports/.
H1 SUS (SUS)
rahul.kumar@LIGO.ORG - posted 13:43, Monday 15 May 2023 - last comment - 12:55, Tuesday 16 May 2023(69600)
New damping settings for ITMY mode 05/06

The nominal settings for ITMY mode05/06 has stopped working past few IFO locks and both the modes are gradually growing. The nominal setting had a -30 deg phase filter engaged with a gain of -0.01. I tried flipping the sign but the mode was still growing. Hence I switched off FM2 (-30 deg phase filter) and applied a positive gain, which looks to be working (during the last lock) - see screenshot of the ndscope which shows both the modes damping down slowly (both narrow and broad band monitor filters). Given below are the setting which I will try in the next lock and if everything goes fine then I will make the changes in lscparams and accept them in the SDF.Observe file.

IY05/06 FM1 + FM10, Gain +0.01

Also, for IY07 someone found the mode to be growing with -60deg phase filter engaged (I see a comment on lscparams). I tested it this morning and found it to working fine with the -60degree phase filter. I will keep an eye on this mode but at the moment I am going with the following filters and gain,

IY07: FM1+FM2+FM10 Gain +0.1

Images attached to this report
Comments related to this report
rahul.kumar@LIGO.ORG - 15:58, Monday 15 May 2023 (69609)

Accepted the changes for IY07 on SDF.OBSERVE, screenshot is attached below.

Images attached to this comment
elenna.capote@LIGO.ORG - 00:50, Tuesday 16 May 2023 (69626)

I can confirm that the new IY05/06 settings work well for multiple locks. They can be guardianized!

rahul.kumar@LIGO.ORG - 12:55, Tuesday 16 May 2023 (69649)

I have confirmed the above settings in the lscparam.

Attaching a plot from last night (6 hours of damping went fine).

Images attached to this comment
H1 General
mitchell.robinson@LIGO.ORG - posted 13:38, Monday 15 May 2023 - last comment - 15:29, Monday 15 May 2023(69599)
EY Wind fence

Today the final horizontal panel cable has been strung! There are a few things to wrap up before this project is complete. There are three vertical cables yet to lace. Once complete the tails can be trimmed and taped up to reduce potential damage to the panel. Time pending one guide wire needs to be replaced, as well as addressing one area approximately 10' on the original panel where the hog rings have failed.

As you can see the wildlife is very determined and ambitious. The nesting material in the photo was placed between Friday afternoon and Monday morning of last week. There have been other attempts since. This will stop once the final vertical cable is laced, as there will be no room for a nest between the panel and the pole.

The process of installing the panels can be seen in the pictures. The panel was pulled up via four ropes to the 5th cable and attached with carabiners for support. Then the horizontal cable was laced. This process was repeated, pulling the remaining half of the panel up to the 7th cable and secured.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:29, Monday 15 May 2023 (69606)CSWG, DetChar, EPO, FMP, ISC, OpsInfo, SEI, SYS
Nice! The EY Wind Fence is back in business! 

Thanks teams Facilities and DetEng!

Tagging a few other interested teams.
LHO FMCS (PEM)
corey.gray@LIGO.ORG - posted 12:29, Monday 15 May 2023 (69596)
HVAC Fan Vibrometers FAMIS Check (FAMIS 23806)

Corner station & out-building fans look good.  Closing FAMIS 23806.

H1 SEI (SEI)
corey.gray@LIGO.ORG - posted 12:21, Monday 15 May 2023 (69595)
HEPI Pump Pressure (FAMIS #21762)

Attached are trends for 45 days of HEPI pressure signals.  Only item worth a note is:  EY has a jump in pressure just over a month ago.

Images attached to this report
H1 ISC (GRD, OpsInfo)
elenna.capote@LIGO.ORG - posted 11:30, Monday 15 May 2023 - last comment - 15:33, Monday 15 May 2023(69594)
LSC POP A RF45 whitening gain set incorrectly

When we got to full lock today, there was excess low frequency noise around 30 Hz. The noise was from the LSC, and we quickly realized that the whitening gain for LSC POP A RF45 was set to 21 dB, but the antiwhitening gain was set to -15 dB. When going to full lock, those numbers should be 15 dB and -15 dB respectively. However, when performing initial alignment, those numbers should be 21 dB and -21 dB.

I trended the guardian state numbers, and this is what occurred:

Tony (operator on shift) ran an initial alignment. He tells me he took ISC_LOCK to down (which holds in Prep for Locking) and selected the INIT ALIGN guardian by hand. Once initial alignment completed, he proceeded to move to locking.

This means that the initial alignment guardian correctly set the whitening and antiwhitening gains to 21 dB and -21 dB (lines 728-730 of ALIGN_IFO.py). However, the Prep for Locking state never reran, so the gains were not properly reset to 15 dB and -15 dB (lines 410-414 in ISC_LOCK.py). However, we did run through SDF Revert, which resets the anti-whitening gain to -15 dB, because that filter bank is SDFed.

My understanding of the "proper" way to run initial alignment is to take ISC_LOCK to the initial alignment state, which will automatically run the init align guardian. Then, the guardian state path forward will correctly move through the states like prep for locking and ensure this error does not occur.

As a reminder, we need the whitening gains to be 15 dB and -15 dB because of the higher SRCL offset we are running with.

We (Jenne and I) have also learned you cannot changing analog whitening gains in lock, as it causes an immediate lockloss (something that Daniel Sigg told us wouldn't work, right after we tried it).

I'm tagging Opsinfo and GRD so the relevant people know of this error mode.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:33, Monday 15 May 2023 (69607)GRD, ISC, OpsInfo
One can find the initial attempt at coding up the transition between (+21 dB analog, -21 dB digital) and (+15 dB analog, -15 dB digital) whitening gain states in LHO:69507. 

Apologies for leaving loop holes around to be stepped in!
H1 SUS (CAL)
jenne.driggers@LIGO.ORG - posted 22:09, Sunday 14 May 2023 - last comment - 10:07, Monday 15 May 2023(69580)
Reverting some Cal SDFs, accepting a violin

I've reverted EX cal line amplitudes, as RyanS and Ibrahim have done several times over the last few days. Calibrators, please have a look and change guardian to set these to the values you want.

I've also accepted FM4 of ITMY Mode 9 being off, since that's what guardian seems to have done.  Rahul, please have a look.

Images attached to this report
Comments related to this report
rahul.kumar@LIGO.ORG - 08:42, Monday 15 May 2023 (69587)

I will un-monitor IY mode 9 from the SDF since we don't use this filter bank.

jeffrey.kissel@LIGO.ORG - 10:07, Monday 15 May 2023 (69590)CAL, GRD, ISC, OpsInfo
J. Kissel

Ah! Right! Forgot that NOMINAL_LOW_NOISE has these gains hard-coded in place such that when we return from NLN_CAL_MEAS they get turned back on. And even worse, this is hidden in lines 261 thru 263 of the ISC_GEN_STATES.py code that the ISC_LOCK.py guardian calls around its line 244. Here's the changed code in ISC_GEN_STATES.py:
259            #make sure cal lines are on
260            for g in ['CLK','SIN','COS']:
261                ezca['SUS-ETMX_L3_CAL_LINE_%sGAIN'%(g)] = 0.3
262                ezca['SUS-ETMX_L2_CAL_LINE_%sGAIN'%(g)] = 50
263                ezca['SUS-ETMX_L1_CAL_LINE_%sGAIN'%(g)] = 35

(lines 262 and 263 had been set to the former PUM and UIM gains of L2 = 35 and L1 = 20, respectively.)

The fixed ISC_LOCK guardian has been reloaded as of 2023-05-15 16:55:18 UTC.
H1 CAL (CAL, DetChar, ISC, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 15:32, Friday 12 May 2023 - last comment - 10:09, Monday 15 May 2023(69555)
Calibration Line Changes -- Increased amplitudes of H1 SUS ETMX UIM (L1) and PUM (L2) 15.6 and 16.4 Hz Actuator Kappa Lines
J. Kissel, J. Rollins

We're putting the final touches on the estimate of the uncertainty on the calibrated data stream, and have found that my factors of 3x and 4x reduction of the low frequency calibration line heights on 2023-03-30 (LHO:68289) were a little but too much of a reduction given the current status of ER15 noise, which we assume will be representative of early O4 noise. We intend for the uncertainty in the transfer function for each of the calibration lines to be less than 0.5%*** (as computed by sqrt( (1 - C) / (2 N C) ) -- where N = 13 averages using an "FFT Length," i.e. a DEMOD low pass filter with time constant of 10 sec). We've found that the uncertainty is regularly 0.8 to 1.0%, and not because of glitches in the detector noise.

As such, I've increased the amplitude of the H1 SUS ETMX UIM (L1) and PUM (L2) 15.6 and 16.4 Hz Calibration Lines,
                                         O3-era      Mar 30      May 12       May/Mar ratio       May / O3 ratio
    H1:SUS-ETMX_L1_CAL_LINE_CLKGAIN       75.0        20.0        35.0          1.75x                0.46x
    H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN      120.0        35.0        50.0          1.43x                0.41x

Attachment 3 shows how the uncertainty has improved over time with this increase in amplitude compared against 0.005, or 0.5%.

The first two attachments show what needs changing, and their acceptance in the SDF system.

*** 0.5% is, as with a lot of how the uncertainty on the time-dependent correction factors, an arbitrary threshold. The threshold was set in O3 as "when the uncertainty in the TDCFs is larger that 0.5%, then it's starting to 'substantially' impact / dominate the overall response function uncertianty, i.e. the overall uncertainty in the calibrated data stream." Where 'substantially' is defined by thinking about what the uncertainty in the calibration is at ~20 Hz == in O3 this was around 5% == so a factor of ten less than that is 0.5%. Also, since no one likes a "measurement" or "statistical" uncertainty to "dominate" an uncertainty budget (can you hear folks asking "wait, why don't you just integrate for longer?"), we increase the amplitude of these lines.

Here's the latest list of calibration lines:
Freq (Hz)   Actuator               Purpose                      Channel that defines Freq             Since O3
15.6        ETMX UIM (L1) SUS      \kappa_UIM excitation        H1:SUS-ETMY_L1_CAL_LINE_FREQ          Amplitude Change; THIS ALOG previously changed Apr 2023 (LHO:68289)
16.4        ETMX PUM (L2) SUS      \kappa_PUM excitation        H1:SUS-ETMY_L2_CAL_LINE_FREQ          Amplitude Change; THIS ALOG previously changed Apr 2023 (LHO:68289)
17.1        PCALY                  actuator kappa reference     H1:CAL-PCALY_PCALOSC1_OSC_FREQ        Amplitude Change on Apr 2023 (LHO:68289)
17.6        ETMX TST (L3) SUS      \kappa_TST excitation        H1:SUS-ETMY_L3_CAL_LINE_FREQ          Amplitude Change on Apr 2023 (LHO:68289)
33.43       PCALX                  Systematic error lines       H1:CAL-PCALX_PCALOSC4_OSC_FREQ        New since Jul 2022 (LHO:64214, LHO:66268)
53.67         |                        |                        H1:CAL-PCALX_PCALOSC5_OSC_FREQ        Frequency Change on Apr 2023 (LHO:68289)
77.73         |                        |                        H1:CAL-PCALX_PCALOSC6_OSC_FREQ        New since Jul 2022 (LHO:64214, LHO:66268)
102.13        |                        |                        H1:CAL-PCALX_PCALOSC7_OSC_FREQ           |
283.91        V                        V                        H1:CAL-PCALX_PCALOSC8_OSC_FREQ           V
284.01      PCALY                  PCALXY comparison            H1:CAL-PCALY_PCALOSC4_OSC_FREQ        Moved from PCALX 410.2 to PCALY 284.01 LHO:69354
410.3       PCALY                  f_cc and kappa_C             H1:CAL-PCALY_PCALOSC2_OSC_FREQ        No Change
1083.7      PCALY                  f_cc and kappa_C monitor     H1:CAL-PCALY_PCALOSC3_OSC_FREQ        No Change
n*500+1.3   PCALX                  Systematic error lines       H1:CAL-PCALX_PCALOSC1_OSC_FREQ        No Change (n=[2,3,4,5,6,7,8])
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:09, Monday 15 May 2023 (69591)CAL, ISC
I've modified the NOMINAL_LOW_NOISE state generator in ISC_GEN_STATES.py such that NOMINAL_LOW_NOISE in the ISC_LOCK guardian sets these L1 and L2 ETMX CLKGAINs correctly. (See LHO:69590).
H1 SEI (OpsInfo)
jim.warner@LIGO.ORG - posted 16:25, Tuesday 02 May 2023 - last comment - 15:58, Monday 15 May 2023(69269)
Buttons on ISI_CONFIG screen for wind fence work transition

I've added 2 buttons to the ISI_CONFIG screen to manage the sensor correction during the fence work. Under the SEI WD SCREEN button there is a red button that says "Fence Work" and a green button that says "Nominal".  The red button pauses the EY St1 senscor guardian, switches the filter I posted in 69162  and takes the BRSY out of the earthquake mode. The green button reverts all that. 

So, before Mitch and Randy head to EY operators should hit the "Fence Work" button. When they are done for the day, revert with the green button. Hopefully we can get rid of these transitions in a couple weeks.

Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 08:16, Wednesday 03 May 2023 (69282)OpsInfo, SEI

I hit the Wind Fence button this morning.  This dropped us out of OBSERVING due to SEI channel values changing seen by SDF.

Since this is a temporary situation (repairing the wind fence), to get us back into OBSERVING, had us STOP MONITORING the (4) involved channels (see screenshot).

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 15:58, Monday 15 May 2023 (69610)DetChar, SEI
See LHO:69608 for a description of what's happening when this button is button is pushed.
H1 SEI
jim.warner@LIGO.ORG - posted 15:31, Friday 28 April 2023 - last comment - 16:02, Monday 15 May 2023(69162)
New sensor correction for EY during fence work

Last week, during the wind fence work, the operators had been manually changing the stage of the sensor correction, BRS subtraction of the STS and asking fence work to pause while the IFO relocked. This week, I came up with a new sensor correction filter that has allowed us to work on the fence without turning sensor correction off at EY.

First plot is a time series showing the ETMY STS (top trace) and ETMY STS- BRSY (bottom) supersensor. The STS alone sees some extra noise, but it's not bad. The supersensor however sees a lot of extra signal from the BRS getting rung up. 

Second plot are the asds for these time series. All of the extra signal for this time is mostly contained below .1 hz. Signal above that is still good.

Third plot compares the nominal filter and the filter we've been running during fence work. Top plot shows the filter magnitudes in nm/nm (I'm leaving out the integrator needed to actually use the filter), the new 1/2hz filter has much more roll-off below .1hz bottom shows (1 - filter(in nm)), which is an estimate of the subtraction we should get with these filters. The nominal filter does a better job with the microseism, which was the focus when I designed it, but that is not the problem we have right now.

Fourth plot shows the timeseries output of each filter for the STS-BRSY signal from the first plot. At low frequency the CPS signal is dominated by the sensor correction. The new filters output is something like 10-20x smaller for the kicks coming from the BRS. I haven't done a real detailed comparison of the table motion yet, but we've been able to both lock and work on the fence running the new filter.

So far to run this, we've been pausing the ETMY_ST1_SC guardian and manually selecting the filter "Bad_stuff" for the Y direction on the ETMY St1 sensor correction. I've been waiting to see how long it will take to string up the rest of the fence before trying to add new guardian states to automate the transition.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:02, Monday 15 May 2023 (69611)DetChar, OpsInfo
This switch over to different filters and sensor correction filter was eventually coded up into an MEDM screen button. See LHO:69608 for description of the details of that process.
H1 DetChar
gabriele.vajente@LIGO.ORG - posted 15:17, Friday 28 April 2023 - last comment - 14:30, Monday 15 May 2023(69164)
More hunting for 4.05 Hz bump origin

Unfotunately turning off the cosmic ray power supply did not remove the intermittent 4.05 Hz bumps in DARM, even though all the CS signals that showed a large peak at 4.06 Hz are now clean.

Looking again at all the signals that contain a peak around 4.05 Hz, we now have

          H1:PEM-CS_MAG_LVEA_VERTEX_Z_DQ 4.050 Hz
               H1:PEM-EX_ADC_0_08_OUT_DQ 4.040 Hz
               H1:PEM-EX_ADC_0_09_OUT_DQ 4.040 Hz
          H1:PEM-EX_LOWFMIC_VEA_FLOOR_DQ 4.040 Hz
         H1:PEM-EX_MAG_EBAY_SUSRACK_Y_DQ 4.040 Hz
         H1:PEM-EX_MAG_EBAY_SUSRACK_Z_DQ 4.040 Hz
             H1:PEM-EX_MIC_EBAY_RACKS_DQ 4.040 Hz
      H1:PEM-EX_TEMPERATURE_BSC9_ETMX_DQ 4.040 Hz
       H1:PEM-EX_VMON_ETMX_ESDPOWER18_DQ 4.040 Hz
               H1:PEM-EY_ADC_0_14_OUT_DQ 4.040 Hz
         H1:PEM-EY_MAG_EBAY_SEIRACK_X_DQ 4.040 Hz
         H1:PEM-EY_MAG_EBAY_SEIRACK_Y_DQ 4.040 Hz
         H1:PEM-EY_MAG_EBAY_SEIRACK_Z_DQ 4.040 Hz
         H1:PEM-EY_MAG_EBAY_SUSRACK_X_DQ 4.040 Hz
         H1:PEM-EY_MAG_EBAY_SUSRACK_Y_DQ 4.040 Hz

Attached plots shows spectra and time series. Although the frequency of all peaks is very close, EX signals are only coherent among themselves, and not with EY signals, and the other way around too. So it looks like at both end stations there is a source of 4.04 Hz that is local. Maybe a clue? Still, we don't have evidence that those sources are related to the DARM noise.

Images attached to this report
Comments related to this report
derek.davis@LIGO.ORG - 17:29, Friday 05 May 2023 (69363)DetChar

To help track down the source of these lines, I've been investigating the time this feature appeared in these channels. The two channels that were the first to have this feature are H1:PEM-EX_LOWFMIC_VEA_FLOOR_DQ and H1:PEM-EY_ADC_0_14_OUT_DQ, which both have had a 4 Hz line present since October 2019. The exact time of appearance for each is:

  • H1:PEM-EX_LOWFMIC_VEA_FLOOR_DQ : 2019-10-15 22:06:00 (plot 1)
  • H1:PEM-EY_ADC_0_14_OUT_DQ : 2019-10-23 18:07:00 (plot 2)

The attached spectrograms show the lines appearing at the above times. I have also includes plots of the channel spectra (plot 3 and plot 4) that show the 4 Hz line before/after these times, as well as a recent time (2023-05-03 22:00:00).

Looking through the alogs posted on these days, there may be an association to install work for BRS heaters. The related EX work (alog 52494) was on 2019-10-15, and the EY work (alog 52542) was on 2019-10-23. The time on both days roughly lines up with when the lines appeared.

The full day shift reports for these days are alogs 52495 and 52656. SInce these days were during the O3a-O3b commissioning break, there are a number of other activities that could be related.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 11:02, Monday 08 May 2023 (69404)

I checked several spectragras from the summary pages during the last month of O3. There was no sign of the 4 Hz bumps.

gabriele.vajente@LIGO.ORG - 11:25, Monday 08 May 2023 (69406)

Looking back at spectrograms since the restart, the first evidence I could find of the 4 Hz bumps is on January 31, 2023. I could not find any sign of the 4 Hz bumps in any lock stretch before that time

Images attached to this comment
evan.hall@LIGO.ORG - 08:26, Monday 15 May 2023 (69585)ISC, PEM

Under Robert's suggestion that this might have resulted from some alignment change of the beam at EX (LHO:69578), the ISC_LOCK guardian archives show the following A2L gain changes in January 2023:

  • 13 Jan 2023: IX Y2L changed from +1.7 to +2.1 (commit 69c3a530)
  • 26 Jan 2023: IY Y2L changed from −1.3 to −1.7 (commit de0e26b4)

The issue with trying to blame the 13 Jan gain change is that there were subsequent long locks with high sensitivity around 30 Hz that did not show the bumps.

Since January, there was also a retuning of the IY P2L/Y2L (commit 463245ed, see LHO:69082).

evan.hall@LIGO.ORG - 12:57, Monday 15 May 2023 (69598)

Some more clues — seems like the ground motion at EX from 3 Hz to 30 Hz experienced a step increase on January 25 and has not settled back down since then. The Güralps and STSs agree on this point, but as for what the ground motion was like in the fall of 2022 they seem to diverge.

Looking at the summary pages in fall of 2022 it seems like the bumps were intermittently present in DARM, e.g.: https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20220902/#gallery-6

Images attached to this comment
andrew.lundgren@LIGO.ORG - 14:30, Monday 15 May 2023 (69603)DetChar, PEM
The increase in ground motion corresponds to turning on FAN1 at each of the end stations. Betsy points to alog 67055 indicating this work, and the change can be seen on the fan vibrometers (first attached plot). There is a peak at 22.5 Hz that pops up, and a broad increase in noise which includes the 4 Hz region, though not so strongly (attachment 2).
Images attached to this comment
Displaying reports 20181-20200 of 87736.Go to page Start 1006 1007 1008 1009 1010 1011 1012 1013 1014 End