It seems like there are some PI modes that we are no longer damping that are slightly run up according to the dtt. I also wonder if the peaks at around 13000hz are modes that we had not had issues with before, or maybe something else entirely? I don't see any mention of them on the PI medm and they are currently the highest. I will try to damp some of the other ones if they get any higher.
The attached shows the PI dtt just after reaching low noise.
Well I think things are stable now. I ended up flipping the sign for the both the phase and gain on mode 27. Mode 26 also came up and changing the phase got it to, very slowly, go down. I took some screen shots of the dtt template at 20min, 26min, and 32min into the lock. The modes that the Striptools said were ringing up, didnt necessarily agree with the dtt. I dont remember how much the modes can shift in frequency, but it seems like some of them were off by a couple of hz.
A couple things:
Please any operator contact me at any time if help/explanations/etc is needed.
For the couple hz off thing, I was mainly refering to the frequencies listed on the medm above the modes. I'm not sure how accurate these are suppose to be, but like mode 27 says 18041, and the dtt was saying that 18038 seemed to be more rung up (see second attached). I didn't remember how much they shifted, and I did not look at the actual filters themselves at the time.
I was able to make it work (on the second try) with just changing phase and gain so I didn't look into it too much after that. But, yes, following your instructions and changing the BP would have been next on the list.
In alog32385 you mention that you will put a reference trace to show what is normal and what is not. I would love this because I looked at the dtt picture that is on the wiki and saw that it was much different. Either way, it was a good learnign process for me since I have only ever had to change phases for PI modes.
PI mode 27. I damped mode 28 then, thinking that I defeated it, went to get a cup of water. When I returned, mode 27 was quickly rising and I got it to level out but couldn't damp it before it broke.
Back to Observing at 11:45
Another lockloss at 12:10 due to PI mode 27. I couldn't seem to get it to go down. I could get it to almost level out, but never bring it down. I did not try changing the gain, I will next time.
Observing again at 13:07. Range says 79Mpc!
It was very sudden. There was no indication form any of the FOMs that anything was, and the environment looks good. There may be the smallest bump on the BLRMS, but nothing that ever should have dropped it. SR3 lockloss template attached, doesn't seem to be the cause (I zoomed in this time unlike before). Also attached the generic lockloss plots, which I can't tell if any of it is out of the norm. Myabe MICH was a bit more active a few seconds before it dropped, but it does sometimes seem to do that normally.
IMC is having trouble staying locked, I should stop writing here and get back to that.
Back to Observing @ 10:45
TITLE: 12/08 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 75.5915Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
Wind: 11mph Gusts, 7mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.24 μm/s
QUICK SUMMARY: Travis delivers a locked IFO again after recovering from an earthquake in China. LLO is currently down. Snow expected in the morning sp be safe driving in.
TITLE: 12/08 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 78.082Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Locked for most of the shift with ~1.5 hour downtime due to EQ.
LOG:
See previous logs for pertinent events.
No issues with IA or relocking. Here we go again.
The DQ report for December 1 - 4 is online and can be found here. It's being posted slightly later than normal due to some techincal issues.
Quick Summary:
IFO alignment looks pretty bad which is to be expected after such a long lock stretch. Running through IA now.
Most likely due to 5.9 EQ in China.
This lock was 28 hours and 44 minutes.
After JeffB reset the dust monitor alarm level today, the PSL has been intermittently alarming throughout my shift. Being unable to access the PSL, in addition to being in Observing, I am unsure of what action I can take to investigate this further.
Still locked in Observing. ~28 hours.
Added 50 mL H2O to Xtal chiller. Filters look clean. Completes FAMIS 6500.
Evan G., Jeff K. Today we identified the H1 parameter file used for the reference model calibration had an incorrect parameter set for loading the inverse sensing function Foton transfer function file. The old file was from pre-ER9 and was when the instrument was running at 50 W. Since we have a different reference sensing function, this file needs to be updated and replaced. This parameter and associated file is only used in the GDS pipeline. Therefore, the EPICS records and front-end do not need to be updated. Unfortunately, this change means that the GDS pipeline filters will need to be regenerated. The updated file is stored at: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/Foton/2016-12-07_H1CALCS_InverseSensingFunction_Foton_SRCD-2N_Gain_tf.txt The parameter file has been updated to include this. The reference model parameter files should now be: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/Common/params/IFOindepParams.conf (rev3829) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/H1params.conf (rev3922) /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf (rev3855) The first attached figure is a comparison of the old inverse sensing function / correct reference inverse sensing function. The low-frequency change is because running at 30 W vs 50 W causes ~2-3 Hz shift in the detuned SRC spring frequency. The mid and high frequency change is because the coupled-cavity pole frequency is different by ~5 Hz and there is a small change in the overall gain, ~5% Fortunately, we expect the inspiral range computed from GDS to increase. This is because the correct inverse sensing function is smaller than the old inverse sensing function. Since the calibration works as DeltaL = (1/C)*d_err + A*d_ctrl, then with a smaller, correct (1/C), we expect that the displacement noise to be smaller than with the old, incorrect, and too large (1/C). We expect that this may correct some of the discrepancy observed between the GDS pipeline and front-end calibration as shown by the inspiral range (second attached figure). However, we do not think that all the discrepancies will be corrected between the GDS pipeline and the front-end calibration (see third attached figure).
J. Kissel (B. Weaver, S. Dwyer) FRS Ticket 6852 It was recently identified that a Dec 05 lock loss looked suspiciously cpoincident with a glitch in the H1 SUS SR3 M1 T1 and LF OSEMs (see LHO aLOG 32220). The same OSEMs were suspected in a subsequent Dec 06 lock loss (LHO aLOG 32251), and thus an FRS ticket was filed (FRS Ticket 6852), but was later deemed too confusing to draw conclusions (see brief mention of it in LHO aLOG 32279). Betsy then went back to find the minute trends of the SR3 OSEM noise appeared suddenly louder after the Dec 05 glitch/lock loss in a 5 day trend surrounding the glitch (split into LHO aLOGs 32280 and 32281). In this aLOG, I investigate further by zooming into 10 minutes surrounding the Dec 05 glitch. I attach three plots: - A 10 minute trend of second trends for the suspect channels, both in terms of uncalibrated EPICs records (the same that Betsy chose to use in her aLOG) and in calibrated fast channels (stored at 256 Hz). The EPICs records show a similar sudden increase in amplitude of max and min trends, but the calibrated fast channels do not. T1 shows a much larger increase in max/min noise than LF. - A full-data time-series of the same to channels in the same two formats. Same thing here regarding the sudden increase in noise in T1 INMON, but only a brief glitch in LF's INMON. Again, no such obvious change in behavior on the fast channels. Interestingly, it looks like there's smaller glitch in T1's fast channel 107 [sec] earlier. - An amplitude spectral density of the calibrated fast channel before and after the glitch happens (15:57 UTC vs 16:06 UTC, 0.04 Hz BW ASD). There's no obvious difference between these spectra. This points to either the excess noise showing up in the INMONs is at higher than ~100 Hz, or the EPICs records are just reporting bogus information. Because I'm suspicious of the apparently incredibly low microseism, I also attach BLRMS of the microseism on the ground and on the ISI around this time. Indeed, the GS13s seem to confirm that the RMS velocity is somewhere around 5 [nm/s], which is roughly equivalent to ~5 [nm] at 0.15 Hz, which in the right ballpark of what the OSEMs report of 2-4 e-3 [um] or 2-4 [nm] or 2-4 [nm/s]. In conclusion -- still no evidence for anything more than a one-time glitch, and there is now little-to-no evidence for permanently different noise behavior after the glitch. We need to wait for more occurances of this issue with obvious evidence before we go for making any change to the instrument.
This is something that I think has definitely happened twice:
In the example from Dec 5th, it is clear that there is a glitch in T1 and LF, on Dec 6th it is not clear which osem to blame, but it is clear that SR3 moves before the lockloss (see this plot). We don't send any ISC feedback to SR3, and I already checked that the cage servo isn't glitching in either case, so this is most likely a problem that comes from the top mass damping.
As a benchmark against which to compare upcoming O2 data, I have compiled a list of narrow lines seen in the H1 DARM spectrum up to 2000 Hz, using 107 hours of ER10 FScan 30-minute SFTs. There are no big surprises relative to the lines and combs Ansel and I have reported on previously from ER9 and later data, but below are some observations. Attached figures show selected band spectra, and a zipped attachment contains a much larger set of bands. Also attached for reference is a plaintext list of combs, isolated lines, PEM-associated lines. etc. In the attached spectra, the red curve is the ER10 data, and the black curve is the full-O1 data. The label annotations are keyed to the height of the red curve, but in some cases, those labels refer to lines in the O1 data that are not (yet) visible in accumulated current data. For the most part, lines seen in O1 that don't show up in ER10 nonetheless remain for now in the lines list and still have labels on the graphs that end up in the red fuzz. If they fail to emerge in O2 data, they will be deleted from future line lists. Observations:
Here is a plot of the violin mode harmonics around 1kHz, comparing the amplitudes today to the amplitudes right after the damping efforts of Nov 30th.
We don't actively damp these by default, only when someone manually engages damping do they get damped. Durring the first part of ER10 ISI trips caused by tidal problems were ringing them up, but that problem is fixed now and most modes are ringing down. ETMX modes (between 1003 and 1006Hz) have increased in amplitude since the 30th.
The largest peak here is the pair on ETMY that Keith points out, we have settings that work to damp both of these modes using the mode9 filter bank on ETMY, and it would not be difficult to turn this damping on automatically in the guardian.
Our question for Keith and detchar is is this (the current spectrum) good enough? Or should we continue to try to add automatic damping for some of these modes?
Automatically damping the violin modes would reduce up-conversion contamination at the starts of lock stretches, making more data usable for CW searches. Even small excess powers in narrow bins leads to unnecessary outliers in analysis that waste computing and manpower. Unless there is a downside to such damping, it seems warranted. thanks, Keith