jeffrey.kissel@LIGO.ORG - posted 18:34, Friday 09 December 2022 - last comment - 13:02, Tuesday 13 December 2022(66284)
Long round of Sweeps Complete (First Round at ~60W); First test of simuLines.py to speed up Sweeps
J. Kissel, V. Bossilkov, L. Dartez This afternoon, I took over the IFO in order to support testing of "Vlad's Laser Light Show," aka simuLines.py, aka "multi sine, simultaneous excitation," first described in LHO:66084. This is one calibration group's R&D efforts to be able to characterize the IFO's sensing, actuation, and response functions more quickly -- the idea being that one gets the high SNR of a swept sine transfer function, but instead of sweeping in series, all measurements are done simultaneously all at once -- but scattering the same frequency vector for each of the 5 transfer functions as a function of time, so that at any one time they don't overlap and are "reasonably far away" from each other. However, in order to confirm that one doesn't lose coherence or transfer function fidelity when running all these lines at the same time (due to, say, interactions, non-linearities, side-bands, glitches, saturations, etc.), this meant taking the 20-minute frequency vector and performing each sweep individually "by hand" in DTT (thus 8 * 20 minutes + a few mistakes = 4 hours later...). Vlad was helping me in the morning get things going, fixing a few minor bugs and fulfilling some quick easy feature requests, but it otherwise ran "straight outta the box," which is great. I had to fix a few more things when I finally ran it for real after all the sweeps, and I'm not sure it saved the output file I was expecting. But -- it ran to completion -- and it certainly was a laser light show of interactions, non-linearities, side-bands, glitches, saturations! Hopefully we can recover the data from the frames and re-process if indeed the processed data was not saved. If that fails, at least we have a new set of sweeps! The light show started 2022-12-10 01:12:57 UTC and the last excitation frequency was driven at 2022-12-10 01:32:11 UTC, tumbling to the finish line with several broken pipes, clocking in at almost exactly 20 minutes. I attach a log of what was spit out to the command line during the simulines run for Vlad's benefit. For an understanding of what the IFO was doing, a screenshot of Tony's helpful "capture the state of the IFO w.r.t. to the DARM loop and calibration" screen during the measurements. I also attach a trend of this lock stretch's - ISC_LOCK state (600 is Nominal Low Noise aka NLN, 700 is NLN_CAL_MEAS where all calibration and alignment dither lines are OFF to save actuator range for the loud drives needed to get good SNR for the calibration measurements) - the calibration-line computed relative optical gain, "kappa_C" (only available when calibration lines are ON, hence only when in NLN, or state number 600) - the calibration-line computed DARM coupled cavity pole frequency, "f_cc" (only available when [... as above]) - the X and Y arm cavity power Calibration measurements started at 22:00 UTC, after achieving the final value for power into the IFO (61-ish [W] into the PSL, 57-ish [W] into the PRM) at 20:00 UTC. What's striking to me is how much and how long it takes for the arm power to settle into equilibrium: arm powers are initially reported as ~335 [kW] and stabilize at 385 [kW] -- a 50 [kW] gain in power! It's also quite note worthy that kappa_C is 4% low -- at 0.96, and f_cc is low at 430 Hz. The drop in kappa_C is consistent with the optical gain increase due to that much more power on the beam splitter (see logic thread in LHO:56118; I'll do the math quantitatively when I've had more sleep) I'm surprised at how low the cavity pole frequency has become, but hearing from Dan Brown this past Thursday, I don't think he's quite finished with tuning TCS for this level of power. Lots more details to come after we analyze all this data. Leaving the IFO in the UNDISTURBED configuration starting at 2022-12-10 01:58 UTC
Images attached to this report
Non-image files attached to this report
Comments related to this report
Location and file names of sweeps and broadband injections taken today --
(in chronological order of drive start time; all date-times are UTC)
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
2022-12-09_2200UTC_H1_PCALY2DARMTF_BB_3min.xml: 2022-12-09 22:00:10
2022-12-09_2206UTC_H1_DARM_OLGTF_LF_SS_5to1100Hz_20min.xml: 2022-12-09 22:06:15
2022-12-09_2206UTC_H1_PCAL2DARMTF_LF_SS_5to1100Hz_10min.xml: 2022-12-09 22:24:02
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOActuationTFs/
2022-12-09_H1SUSETMX_L3_iEXC2DARM_20min.xml: 2022-12-09 22:50:17
2022-12-09_H1SUSETMX_L3_PCAL2DARM_20min.xml: 2022-12-09 23:08:29
2022-12-09_H1SUSETMX_L2_iEXC2DARM_20min.xml: 2022-12-09 23:50:08
2022-12-09_H1SUSETMX_L2_PCAL2DARM_20min.xml: 2022-12-10 00:07:45
2022-12-09_H1SUSETMX_L1_iEXC2DARM_20min.xml: 2022-12-10 00:33:06
2022-12-09_H1SUSETMX_L1_PCAL2DARM_20min.xml: 2022-12-10 00:50:34
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
2022-12-10_0134UTC_H1_PCALY2DARMTF_BB_3min.xml: 2022-12-10 01:34:14
I *don't* recommend that we switch to these templates permanently -- the collection takes WAY too long. I'm grateful that we didn't have an earthquake or lose lock for other reasons during all this!
All of the above files have been committed to there above respective locations in the CalSVN.
@Tony Sanchez -- the ndscope template for the trends of optical gain, cavity pole frequency, and arm powers lives here:
/ligo/home/jeffrey.kissel/2022-12-09/
2022-12-09_OpticalPlant_vs_TDCFs.yaml
Replay of H1:CAL-DELTAL_EXTERNAL_DQ during simuLines Excitation To emphasize why I refer to the excitation sequence that's driven during the 2022-12-10 01:12 UTC run of simuLines.py as "Vlad's Laser Light Show," I've posted a movie of H1:CAL-DELTAL_EXTERNAL_DQ during the excitation to G2202186 (200 Mb, so can't post directly to the aLOG). Over the course of the excitation, can see the entire gamut of things we typically don't like under normal circumstances, - Mysterious excess broadband colored noise - Glitches, - Harmonics of the drive frequency - Sidebands on the drive frequency - Wire violin-mode ring-ups (thankfully no lasting impact because they're low Q) But, with all that mess happening, we *didn't* - lose lock, - saturate any actuators, at least :: from first glance, :: knowing the excitation amplitude is the same as "normal" templates, and :: not hearing the audio alarm during the excitation - ring up any monolithic glass fiber violin modes So that means we can happily continue to refine such excitations without worry of major chunks of IFO time lost. Now the question is: with all the excess noise during the excitation, will the *transfer functions* (the linear components at each frequency analyzed) still have good enough coherence, and/or do we see any difference between the reported TF magnitude and phase whether excited (a) in series, one-by-one, and (b) pseudo-simultaneously. Again, head to G2202186 to watch the show! For future reference, to make this movie, I - had a nomachine setup going, logged in to the site control room via opslogin0 - Tested out the replay of data from the past using the standard ${userapps}/isc/h1/scripts/H1_DARM_FOM.xml template typically displayed on the front-wall - I used my mac laptop - I opened QuickTime Player - From the QuickTime App menu list along the top of the OS screen, selected "File > New Screen Recording" - Moved the little recording window on to the second, external monitor screen I had the nomachine session maximized on - Hit the record button - Clicked on the screen I wished to record - Clicked within the nomachine session to regain control - Clicked "start" on the DTT template - watched the show - From the mac app tool bar along the bottom (er, at least, that's where I have it set to be), right clicked on the QuickTime App icon, and hit "Stop Screen Recording." - The resulting movie popped up immediately, so from the QuickTime menu list, I hit "File > Save..." and saved the file. There continues to be more to come!
Looking at the attached log (main aLog), I can see what went wrong.
The main thread died because of an invalid channel name in the beginning. Probably the L1 exciton channel that I got wrong. Twice.
So when the driving threads finished their work, and tried to hand the time stamps back to the main thread for processing, there were 5 errors at the end, because the main thread no longer existed. No wonder no data got saved.
I'll add a further error catching to prevent this.