H1 lost lock, and relocked with the old ETMY violin mode damping gains, which, after 10 hours, were ringing up modes 18 and 20.
I currently have the ETMY violin mode gains to these values:
I changed lscparams to use the above gains if H1 loses lock
Plots attached show the damping done tonight.
I still have to land the ground wires to the pressure switches and solenoid valve but otherwise am ready to test this out on Monday. When enabled, this modification should reduce the CS instrument air compressor duty cycle significantly.
I noticed that the MEDM RED/YELLOW/GREEN field associated with CP4's dewar level had changed today from the nominal RED (CP4 is empty - decommissioned) to YELLOW and 1.3% full up from the nominal ~0% full -> I think that this is a bogus indication and should be ignored.
Last week, I asked operators to begin using a new online survey to record lock acquisition attempts, rather than type out their attempts and manual interventions in the alog. We've now had 4 locklosses / reacquisitions since then, so we're starting to get some data (thank you Operators!). The point of this survey is to get information regarding manual interventions required, to help us identify where we need to work on the interferometer's relocking automation. Operators have been giving us this information in their alogs (again, thank you!), but this online form should streamline responses and hopefully save everyone time.
The online google form outputs to a google sheets spreadsheet that everyone (who has ligo.org credentials) can look at. I'm starting to put some digestion of the data on other tabs in that sheets document; I'm hopeful that we'll be able to get some useful information out of the digested data, rather than every person having to individually read through the entirety of the spreadsheet, but that component is still a work in progress.
Everyone is welcome to click through the survey. However, if you are not actively filling it out for a lockloss, please choose the name "Test / DeleteMe" so that if the response gets submitted, we can excise that row. Also, please feel free to look at the results spreadsheet. However, note that the spreadsheet is not archived, so please do not edit the responses (so that we don't lose any).
The form and spreadsheet should be accessible to everyone with ligo.org credentials.
Form: https://tinyurl.com/LHO-Lock-Acq-Questionnaire (hover for the actual link; I made a tinyurl that is easier to type)
Results: https://tinyurl.com/LHO-Lock-Acq-Responses (again, hover for the actual link)
Attached is a flow chart (also laminated at the operator station) describing the flow of the survey, as well as screenshots of some of the questions. Note that there have been some updates to the questions and text since I made this pdf, as a result of excellent feedback from operators, but the gist of them should be similar.
J.Kissel, T.Mistry
Here are some 'Money Plots' for the NCAL Sweep that was taken on the 04-Dec-2019.
Figure 1 :: A move/animation of the sweep as seen in the control room DARM spectrum.
Figure 2 :: ASD of the DARM plot with labelled frequencies from 5 to 600Hz.
Figure 3 :: ASD of the DARM plot with tagged frequencies from 5 to 40Hz.
Figure 4 :: Spectrogram of the NCAL Sweep from 0 to 50 Hz.
Figure 5 :: Spectrogram of the NCAL Sweep from 0 to 1000 Hz.
Figure 6 :: IWAVE line tracking of the Optical encoder as the NCAL changes velocity.
All the figures are also available in DCC G1902340.
An interesting feature to see is that when the NCAL is settling to a new frequency, making what appears to be sidebands. This is due to the NCAL slightly overshooting the requested frequency before settling down to the desired velocity. This is an expected results as a result of the NCAL motor behaviour due to the internal motor parameters. It is possible to configure the motor parameters to reduce the overshoot however, the current implementation is a trade off between time taken to accelerate to a given frequency and the stresses on the motor.
Below is a timeline of the NCAL sweep. The values in red are not visable due to the lack of SNR at low frequency. A longer intergration time would be required to see the lines below 5Hz.
NOTE: to create a movie and upload it to the alog I did the following onn the LHO control room machines:
ffmpeg -i out.ogv MyFile.mp4
J. Kissel These Dec 4th 2019 measurements were run from 1259535305 to 1259539158 (Dec 04 2019 22:54:47 UTC to Dec 04 2019 23:59:00 UTC). Any and all O3 C01 systematic error estimates for any observation-ready hour are now available on the CIT cluster in a standard location that the GW data analysis teams use (they weren?t back in Apr 2020 when I produced the plot on page 32 of the Review of the First Results, G2000532). For Hanford, they live in https://ldas-jobs.ligo.caltech.edu/~cal/uncertainty/O3C01/H1/ So we want the file that?s the nearest in time to the time frame of 1259535305 to 1259539158 (which was *out* of observation ready time). During the whole time the detector was out of observation ready mode, the IFO was locked, happy, and stable as one can see from the summary pages, https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20191204/ Also from the summary pages, one can see that the time-dependent correction factors remained the same before vs. after the observation ready stretch, https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20191204/cal/time_varying_factors/ We went back in to observation ready mode right *after* the NCAL injections, so actually the nearest time *after* the injections will be the best. That's the file https://ldas-jobs.ligo.caltech.edu/~cal/uncertainty/O3C01/H1/2020-06-12_O3_LHO_GPSTime_1259540100_C01_RelativeResponseUncertainty_FinalResults.txt at 1259540100, or Dec 05 2019 00:14:42 UTC, 942 seconds later, or 16 minutes later. (Ignore the date at the beginning of the file name: that?s a reflection of when the file was created, not a reflection of the time for which the systematic error budget applies. That?s indicated by the GPS time in the file name). This shall be the h(f) systematic error we use to compare against in the forthcoming NCAL paper.
J. Kissel The spot positions for this measurement, determined by the P2L and Y2L decoupling gains which were 4.3 and 3.6 respectively for this entire lock stretch on Dec 04 2019, are 15.7 mm in -Vertical, and 13.2 mm in +Transverse. See further discussion of how these numbers are determined in LHO aLOG 58023 (i.e the NCAL's swan song on Sep 03 2020, which had the exact same spot positions).
TITLE: 12/14 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 107Mpc
INCOMING OPERATOR: Niko
SHIFT SUMMARY:
LOG:
Ops Shift Transition: 12/13/2019, Eve Shift 00:00–08:00 (16:00-00:00) - UTC (PT)
State of H1: Locked
Intent Bit: Observing
Weather: 0-10 mph wind
Primary 0.03 – 0.1Hz: 0.01 um/s
Secondary 0.1 – 0.3Hz: 1.0 um/s
Outgoing Operator: Ed
Quick Summary: Locked and Observing for 8.5 hours. Microseism still high
TITLE: 12/13 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Camilla
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 8mph Gusts, 5mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.74 μm/s
QUICK SUMMARY:
oops! forgot to post.
18:57 Returned INJ_TRANS Guardian node back to INJECT_SUCCESS following the mornings Superevent activity.
TITLE: 12/13 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 112Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Lockloss, cause unknown.
LOG:
Cheryl's violin settings for ETMY seemed to work well all night, but I have not yet reset them, that could be done using Cheryl's alog 53875.
Remain locked and observing through this high microseism, where secondary useism: 0.92 μm/s
On December 3rd I moved the HAM2 East door camera to a new port, and pointed the camera to look at AOE2, the beam dump for Calcite Wedge 2's forward rejected beam, the steering mirror for that beam, and the HWP baffle in the IO FI.
The camera view is rotated counterclockwise by 90 degrees, so the top of the image is to the right in HAM2. The focus is a bit farther back than intended, with the best focus being on the IO FI HWP baffle aperature, near the top of the image (to the right of AOE2).
Using HAM2 coordinates, the first component fromt the left is the IO beam dump. This has a beam coming from the left, and hitting the outside of the beam dump. The beam dump frame, that holds the SiC plates, is illuminated on the left and along the top, and here is where one can see the best example of the changing illumination from IR light. Inside the beam dump, on the right, there is a beam which appears to e hitting the right of the beam dump, on the inside, which appears to be dumped directly on the metal side plate.
From center and to th right, is the back of AOE2. The metal frame is visible, and the aperture in the front SiC baffle is surrounded by IR light.
To the far right one can see most of the IO FI HWP baffle aperture, meaning that the top and sides of the aperture are clear, but the bottom of the aperture is not, and that is because it's blocked by the steering mirror that sends the forward rejected beam to the beam dump.
Attached images were taken from both the East door and top viewport, and show AOE2, and the input to the IO FI, including CW1.
Attachment document shows both visible and the IR images from the East door.
In the previous images, it's possible that PRM was misaligned while I was taking photos, so some of the beams seen on baffles could be a result of that misalignment.
TITLE: 12/13 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: Camilla
SHIFT SUMMARY: locked in Observed all shift
LOG:
TITLE: 12/13 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 16mph Gusts, 12mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.84 μm/s
QUICK SUMMARY: We have some high sustained winds ~20mph and raised microseism. Otherwise all fine, locked 15h35m.
I damped ETMY violin modes 18, 20, and 12, and all are below 1e-5.
H1 has been in Observe for 7 hours, useism is above 0.5um/s and steady, winds have spiked to 40mph, currently between 5mph and 20mph.
Following up from the last alog.
With the UIM dyanamics filter ready I propagated it through a set of new tagged sus models. I made a set of three to help make an informed decision on how to treat the new UIM dynamics - the complication being that there appears to be dynamics around the violin modes. I have split off a second tagsusdynamicalmodel.m so I don't interfere with livingston using the file.
I have created the following files using /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel_h1.m
/ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/
quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10093_h1etmx_options-rev10093_released-2019-12-12.mat quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10090_h1etmx_options-rev10090_released-2019-12-12_noUIMdyn.mat quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10093_h1etmx_options-rev10093_released-2019-12-12_noviolins.mat
And from these I have generated the following files using /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/matlab_scripts/export_AAAI_SUS.m:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/matlab_scripts/
H1susdata_O3_new.mat H1susdata_O3_new_noUIMdyn.mat H1susdata_O3_new_noviolins.mat
Using these I can compare before are afters, namely:
In the case when I plotted against no violins, the MATLAB removes the highest most zero in the UIM dynamics, making the TF look like its going down more than it should be (an effective extra 1/f term). This is a problem in the current workflow that takes the tagged model and splits it up into low frequency terms and the violin terms, where I'd need to add a separate operation that takes the tagged model that has no violin modes to split off these dynamics. Looks like I will have to rethink.
Also the low frequency features are being changed by a bit - seems even matlab has its limits of tolerance when it comes to how many poles and zeros it can play with at a time.
I think a better approach is to have the dynamics added into the "H1susdata_O3" matrix directly by export_AAAI_SUS.m, and make no changes to the tagged susmodels as they stand. At the end of the day I am always drawing from the same file into which I have saved my dynamics... I can just do that later down the line even for the foton file.
Looks like how I've treated my raw data for the higher frequencies (near the violin modes) is incorrect. It seems the violin mode part of the TF is conflating with my data in part of the processing.
When I was doing fitting, I was dividing out a TF that had no violin modes (as was my intention), but "umodelUIM_afterLock_freqresp" was being divided out instead in a pyDARM function
I'll be dividing out more correctly, removing any data >200 Hz and refitting now.
After following through:
Things look pretty good, however,
Vlad, Jeff
We investigated the source of this apparent blip at around 0.5Hz, and traced it down to Matlab doing funny things when converting from SS to ZPK model. In fact, we got different results for every input for each of the latest 4 Matlab versions we have available (actually 2016b and 2017b gave identically bad results).
I have made a number of plots which I hope will convince people that we should, and importantly *can*, migrate this step to python.
I have put up a whole lot of plots which have one consistent aspect: the SS model response never changes. The most plots worth highlighting are are:
TITLE: 12/13 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 34Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 8mph Gusts, 4mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.76 μm/s
QUICK SUMMARY: H1 is locked in Observe, useism is on the high side, and we've had some spikes in wind up to 20mph is the last hour.