J. Kissel, R. Schofield, K. Merfeld, M. Ball, A. Helmling-Cornell After Robert completed his studies, I glanced up and saw the spectrum had some terrible broadband noise, killing our range. And then it changed. Trends seem to show that it's been a part of this lock-stretch (including observation time) all along. Attached are DELTAL_EXTERNAL ASDs of the few times I looked up. Needs further investigation! All of Robert's test equipment is OFF. Looked at ETMX driver low pass state, it's ON, in the correct configuration. Now SDF differences with settings (or else we wouldn't have been able to go in to observation ready). No glitching in the BRS (wouldn't cause this kind of broadband noise anyways). The last lock loss from observation ready was sudden, with unknown cause... maybe something broke? Investigtion continues. We've launched a BRUCO, results soon to come...
It glitched again in the same manner at 00:32:12 UTC,
Since this looks like a force noise, and my spider-sense thinks this is some sort of electronics failure, I trended the coil current for the ETMX PUM and ETMX TST (i.e. the primary stages of the DARM actuator), and found nothing that didn't look the same is it did in the previous lock stretch. See attached.
Here are some dtt's of the broadband moise in the darm spectrum. I had a look at the spectrum during the unexplained range drop from Niko's alog 51400. These ones we're having now seem to be at a lower frequency.
Sheila to the rescue -- the ALS X shutter was open. (And the clue came from ALS X trying to lock, which changed the ALS X SERVO GAIN and knocked us out of observation intent...) Shutter is now closed and DELTAL_EXTERNAL is back to normal. Now investigating why the shutter didn't get closed during these sets of lock acquisitions............
PEM crews has wrapped up for the day.
Patrick, Jeff K, Sheila
After the lockloss this afternoon Patrick had two locklosses in a row in the state PREP_ASC_FOR_FULL_IFO. (1250631114 and 1250630221). The only thing that really was changing about the IFO state in PREP_ASC was that we were turning off the offsets in AS36 that are set after the DRMI ASC is run (with BS controlled by AS45) before we change to the AS36 sensors. These offsets were particularly large today.
After a seemingly unrelated lockloss at DHARD, we ran PREP_ASC manually leaving the offsets on, and manually turned them off after ENGAGE_ASC, which did make the POP18 + POP90 build ups worse but we were able to survive.
I've now moved the ramping off of these offsets toward the end of ENGAGE_ASC, so I am hoping that we can see fewer of these locklosses in PREP_ASC.
TITLE: 08/23 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 13mph Gusts, 10mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: PEM crew is working hence being in Commissioning mode despite having just reacquired lock.
J. Kissel There have been many times since we re-adjusted the initial alignment settings (last done Thursday Aug 15 2019; see LHO aLOG 51307), that the ALS EX and ALS EY front-end models show SDF differences at the 1e-17 - 1e-18 level. This is a result of the python scripts we use to set the initial alignment references -- in particular the transmon (TMS) green QPD offsets -- /opt/rtcds/userapps/trunk/als/h1/scripts/ setEndGreenQPDOffsets_XARM.py setEndGreenQPDOffsets_YARM.py not rounding before installing to any reasonable precision before writing the numbers to EPICs. As a quick fix, I manually rounded and entered the numbers in to the respective EPICs channels. Attached are screenshots of the SDF diffs after rounding, mostly to prove to you and me that I didn't make a typo in doing so (which would botch the initial/global alignment references -- a think I *definitely* don't want to do at 4p PDT on a Friday). The long term fix will be to edit the above scripts, but since we don't plan on updating the initial alignment references again any time soon, the quick fix should suffice until we get to editing the script.
J. Kissel, S. Dwyer The future is now! With the watchful eye of Sheila, I edited the above mentioned X and Y arm codes such that once the transmitted (green) Arm Power is above 0.9 [normalized counts], and the I phase outputs of the (green) WFS A and B are less than 10 [DAC counts], then (a) read the current offsets, (b) round the QPD offsets to a precision of 1e-6 (c) write those rounded offsets, and (d) break out of the while loop (a), (b), and (c) are all done in one line via the magic of ezca python bindings, and (d) is new -- the script used to just ask the user to CTRL+C out of the script. This code change is completely untested, and again we likely won't use it for another 3-6 months, but hopefully I've left enough breakcrumbs in - this aLOG, - the instructions that reference these scripts, LHO aLOG 50968, - the comments of the code, and - in the log of the svn commit that people will come find me when it doesn't work. Apologies in advance!
TITLE: 08/23 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC STATE of H1: Commissioning INCOMING OPERATOR: Travis SHIFT SUMMARY: Just relocked. Robert has started PEM commissioning work. Had trouble relocking past PREP_ASC_FOR_FULL_IFO. Sheila took the guardian to manual through this step and skipped some gains. This seemed to work, but not clear if coincidence. LOG: 15:55 - 16:08 UTC Richard to mid X 16:05 - 17:39 UTC Peter to optics lab 16:21 UTC Vanessa to mid X 18:28 UTC Beckhoff corner station error verbal alarm. Not sure what this referred to. 18:29 - 19:14 UTC Richard to mid X 20:05 - 20:36 UTC Peter to optics lab 20:48 UTC Lock loss 20:49 UTC Matt to LVEA 20:55 UTC Reloaded guardian nodes as requested by Sheila (alog 51465) Moved ETMY for green arm alignment 21:07 UTC Robert and Kara to LVEA Lock loss from PREP_ASC_FOR_FULL_IFO Lock loss from PREP_ASC_FOR_FULL_IFO Lock loss from DHARD_WFS 22:08 - 22:26 UTC Robert and company to LVEA 23:07 UTC Set observatory mode to commissioning for PEM work
Vacuum bake oven C is currently out of order. It appears the RGA isolation valve is leaky and needs to be replaced.
Betsy, Dave:
I have written a python programme which permits observatory staff to sign up to be notified when H1 loses lock. It has an EPICS interface, and is controlled and monitored by a MEDM screen (see attachment).
The MEDM is launched from the SITEMAP under the OPS button.
When H1 loses lock, a counter is started. If the counter exceeds the alert time (currently 2 minutes), alerts are sent to any selected clients. An email is always sent, and optionally a cell phone text message can also be sent if that option is turned on.
The system can be completely disabled with the master enable button.
The alerts will not be sent outside of the time window defined by the START and END settings (currently alarms sent between 8am and 11pm).
If you would like to be added to this system, please contact me.
From the attachment you can see I have tested it with Robert this afternoon.
As we replace the aging Mac Mini computers (MacOS) with Nuc computers (Debian9) our current snapshot script was generating a single png for both monitor images. This resulted in strange pairings, like the wind speed plot and the vacuum overview.
I rewrote the script today. It finds the number of monitors the computer has, and their layout. It then generates a PNG file per monitor, using the old MacOS standard naming of hostname-mon.png, e.g. nuc23-1 and nuc23-2.
I then revamped the CDS web page which lists the FOM thumbnails and links, because it was not complete, and did not have a logical layout.
As a test, I have grouped the images to be the same as their physical layout in the control room. Please email me if a different layout is preferred.
I'm also in the process of updating the FOM wiki page.
Jamie, Sheila,
Each time we run an initial alignment, it seems that we loose lock in the early stages of the CARM offset reduction in the the next locking attempt, although these steps are otherwise quite reliable, so it seems as though some setting is not being set correctly after initial alignment is run until the IFO looses lock once.
After we run initial alignment, we do run the down state of ISC_LOCK, which requests 'DOWN' from several of its subordinate guardians, however, since some of these guardians are already in the DOWN state making the request doesn't cause them to re-run their main states, where the settings get reset. (For a similar situation and a different solution see 49520 and comments). Yesterday I tried to look manually at the ALS_COMM and IMC_LOCK down states, but catch the problem with my first look. Patrick also tried to use SDF to find the probelm setting yesterday, 51452 but that didn't show us anything obviously wrong either.
On the phone Jamie told me that when the guardian code was changed so that re-requesting a state doesn't cause the state to be re-run (which was a change that solved problems with having code that isn't idempotent), he added a feature that would allow us to choose the old behavoir for certain states, by adding an edge from that state to itself. In that case if the guardian is in DOWN and gets a request for DOWN it will re-run its main state.
So, I've added paths from DOWN to DOWN in ALS_COM, ALS_DIFF, ISC_DRMI, IMC_LOCK, FAST_SHUTTER, and OMC_LOCK. IMC_LOCK doesn't get sent to DOWN in the DOWN state of ISC_LOCK, so that if the mode cleaner is already locked after initial alignment runs we don't unlock it, and I haven't changed that, I simply added the edge from DOWN to DOWN.
So, the next time that we have a chance, (when we are out of observing) I'd like to load all of these guardians. Then we can see if this will solve the problem of loosing lock on the first attempt after initial alignment.
Patrick loaded these changes after a lockloss, and didn't have guardian problems when relocking.
Request for operators: I am hoping that this might solve the problem of the IFO lossing lock in the early CARM reduction steps in the first locking attempt after each time we run initial alignment. I would appreciate if you would report relocking attempts over the weekend, including if you run initial alignment, and if on the first relocking attempt you make it to the CARM offset reduction do you survive those steps?
As a reminder, there is a spreadsheet which could be used to help us keep track of problems encountered when relocking:
https://docs.google.com/spreadsheets/d/1byXR-s2ATegciJCEjORb1FEZhZTp77j6DS-fZuvEY-8/edit#gid=0
In the first locking attempt after Tuesday maintence, initial alignment was run, and the interferometer was relocked without loosing lock, on the first attempt https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=51561 (Also confirmed by trending the guardian state at the times Jeff aloged)
This means that this solution has worked, and we shouldn't have these failed locking attempts after each initial alignment.
TITLE: 08/23 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 3mph Gusts, 0mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY: No issues.
TITLE: 08/23 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: 15.5 hours of observing.
Locked and observing for 13 hours @115Mpc.
TITLE: 08/23 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 6mph Gusts, 6mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: Calm environment, 7.5 hours lock.
S. Dwyer, J. Kissel We've repeated Monday's measurements (see LHO aLOG 51393) of the IFO's DARM Opto-mechanical Response (Sensing Function) Vs. SRCL Offset now at the "July" spot positions (where Monday's were at the "August" positions -- see attachments to LHO aLOG 51436 for what this means in terms of A2L gains). There is similar drastic impact on the sensing function. See attached: 2019-08-21_H1_100ctSRCLOffset_sensingFunction_referenceModel_vs_allMeasurements.pdf I'm again using the "No Spring" loop model, which has H_c Optical Gain 3.13e6 [ct/m] f_cc Cavity Pole Frequency 411 [Hz] and *no* optical spring from SRC detuning, in order to emphasize / better quantify the effects of either actual detuning or remaining L2A2L issues. In the July Spot positions, with a 100 ct SRCL offset, both of these effects are minimized, and the sensing function appears quite flat, where the other three configurations have interesting features. In fact, the cavity pole frequency also best matches the model at 411 Hz in the July positions and with a 100 ct offset, where the other configurations have lower frequency (the worst being 395 Hz from Monday's Aug positions and no SRCL offset [determined by "by-hand" fitting from LHO aLOG 51393]). Looking at the phase, my preliminary interpretation of these data are that (a) Changing the spot position moves the detuned spring frequency to lower frequency but keeps the detuning Q / amplitude level about the same, and (b) Adjusting the SRCL offset reduces "the amount" (the Q and amplitude) of detuning. I'm not yet ready to say this is definitively true, since -- in the beginning of O3 up to July 31, the low-frequency response was bouncing around from week to week (see LHO aLOG 50498), which may be a result of the L2A2L issues. Monday's measurement of Aug spot positions with 100ct SRCL offset show evidence of the "unphysical" phase turn-up and funky magnitude response, yet today's July spot positions, with no SRCL offset don't appear reproduce the unphysical issues -- when we would expect them to be quite similar to all previous O3 sensing function measurements before the spot move. More to come, I'm sure...
J. Kissel
In the above aLOG, I've compared all of the measurements to the same, no spring, low-frequency optical response model to emphasize how much it changes with spot position and srcl offset. We see that there is not only a spring-like effect, but also some (what we believe to be) parasitic L2A2L coupling of some unknown shape or form (especially evident in the requested 100ct SRCL Offset, August Spot position data).
We also know that our MCMC algorithm for fitting this data, for which we only give it the poles and zeros to model a spring (2 zeros at 0.0 Hz, and an arbitrary set of complex poles at frequency f_s with phase separation defined by Q), cannot accurately give us approximations for what at least the spring part is doing because it's getting confused by the parasitic L2A2L response.
However, in order to make progress on how much detuning we have, and how the requested 100 ct SRCL offset changes that detuning in physical units, we need *something*.
So -- I've noodled around with the optical plant parameters that we *do* have in order to make a "best" by-hand fit of the data. Here, "best" is based on minimizing the residual (ratio) between measurement and model, acknowledging that I will never be able to get an actually good fit, because I'm not using enough poles and zeros to cover the L2A2L effect. Also, acknowledge that my by-eye happiness is determining the uncertainty in the parameters, so we have no nice neat, multi-dimensional posterior distribution that exposes the (very real) covariance between the parameters.
Given those caveats, I attach the results.
Here's a table of the resulting fit parameters.
No Offset 100 ct SRCL Offset
Aug spots Jul Spots Aug Spots Jul Spots
optical gain, H_c [1e6 ct/m] 3.13 (0.01) 3.16 (0.01) 3.13 (0.01) 3.16 (0.01)
caviy pole frequency, f_cc [Hz] 395 (3) 405 (3) 409 (3) 415 (3)
optical spring frequency, f_s [Hz] 7.2 (0.5) 6.0 (0.5) 5.0 (1.0) 0.0 (1)
optical spring quality, Q [n.a.] 10 (5) 35 (5) 10 (5) 1.0 (1)
spring type [n.a.] pro pro anti? no?
measurement date [YYYY-MM-DD] 2019-08-19 2019-08-21 2019-08-19 2019-08-21
attachment page page 1 page 2 page 3 page 4
Again, in the 100ct SRCL offset data, there's not enough poles and zeros in the fit, and/or not a visible enough spring to really trust the spring-related assessment last two columns, and I thoroughly recommend we map out the parameter space better and develop a model (or get rid of) the supposed L2A2L coupling so we can really do a proper fit on this.
We can at least confidently say that Jul spot positions, with a requested 100 ct SRCL offset is best for the optical gain and cavity pole.
Back to NLN, Jenne and Jeff have updated ALS references, SDF diffs in attached screenshots.
JeffK noted that we don't have a good all in one place how-to on setting the initial alignment offsets. So, here's an attempt at it. This assumes that the QPDs are all close enough to center (or can be made to be so by moving TMS) that you do not need to use the picomotors. Using the picos requires more thought and care.
The attachment is my desktop when I'm doing this, so you can see all of the windows that I'm looking at.
Process for each arm (can be done in parallel since each arm is independant of the other for this work):
If you must pico, I'd recommend only pico-ing the IR QPDs since they're much easier to think about and independent of other beams. I'd start the green QPD setpoint scripts to make the green QPDs follow your movement. Then I'd make a small step in TMS alignment in the direction that will put the green QPD offsets closer to zero, and then pico the IR steering picos to get the IR QPDs closer to zero.
I've edited the code that sets the green QPD offsets (/opt/rtcds/userapps/trunk/als/h1/scripts/setEndGreenQPDOffsets_XARM.py and setEndGreenQPDOffsets_YARM.py) -- check out LHO aLOG 51476 for further commentary.
This procedure needs to be modified because we are now setting green references with our spots centered on the optics. We would like to center the IR on the IR QPDs once we have our spots in their final positions, however, not necessarily with the spots centered.
Since Craig added in the TMS servoing to center the IR QPD, we should still be able to follow this procedure at DC readout. At DC readout, in the current situation, we are servoing the spots to the centers of all 4 test masses at 2W input power. This is the position we want to set the initial alignment references to.
Later in the acquisition sequence the power is increased to 10W, and then the beam spots are moved to their final high power positions, then we further increase the power and continue on to NomLowNoise.
Before setting the green camera references, we should remember to check that the camera image is good and that any mask applied is appropriate. We can check this by opening up the digital camera screen and taking a snapshot, then finding the snapshot in /ligo/data/camera