Locked for 43.5 hours.
Briefly popped out of observing because a template was opened and the excitation bit then flipped, but no excitation was injected. This was quickly remedied and we were out of observing for only 43 seconds at 0411 UTC.
FAMIS 12878
Nothing out of the ordinary to note.
TITLE: 12/17 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 93Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 2mph Gusts, 0mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.64 μm/s
QUICK SUMMARY: 39.5 hour lock, useism is high and still growing.
Sheila pointed out that we're having a lot of scattered light for the microseism level we've got, and at the Commish meeting asked about our sensor correction / seismic configuration.
Since the CPS differential is designed to help at the wind and earthquake band, it makes some sacrifices of isolation performance in the microseism band. As a test, I've turned off the CPS differential system by ramping down the final output gain (H1:ISI-DIFF_CONTROL_BIT to zero, ramping down over 10 seconds), and we'll see if we see a bit less scattering.
I took the IFO out of observing for a few minutes to make the transition, accepted the SDF diff, and went back to observing. Note that I left the SEI_DIFF guardian in its nominal state which might make one think that it's on, but since the Run state does nothing but return True, it is not writing to that EPICS channel. I didn't want to edit the guardian's nominal state, which is why I've left it alone.
It's been a little over 2 hours, and the IFO seems to like having the CPS diff off, so I'll leave it off for now.
In the attached screenshot, the top row is the BNS range, 2nd row is the DIFF control bit showing when I turned off CPS diff. While we're still seeing glitches, they (with this limited amount of time) seem to be somewhat less frequent, and the range seems a little bit better. The third row is microseism BLRMS for the z-axis STS at each building, showing that the microseism has not decreased since turning off the CPS diff. The 4th row is X, Y, Z axis BLRMS in both the EX and EY stations for the wind and earthquake band, showing that we haven't had too much wind or very low frequency seismicity, which is where the CPS diff helps most anyway. Note for the seismic plots that these units are nm/sec, whereas they are displayed in um/sec on the control room wall.
Looking at the ETM ISIs, the current cps diff filter makes the microseismic table motion and above worse on Stage 1, this is fine most of the time, but not a good thing for us at the moment. The attached plot shows the ground and St1 motion before Jenne turned off the cps diff (cyan and brown) and immediately after (red and green). The effect on the BSCs is pretty dramatic One thing we could try is just making a state that doesn't engage the ETM cps diff. It doesn't seem to be a problem to impress this extra motion on the BS, it would be good to get some time to try engaging different parts and seeing what hurts us. It would also be good to see what the effect is when SEI_CONF is in the useism state (which I switched to a few hours ago, as the microseism has gone over 1 micron/s rms).
Turning off the CPS diff had a clear impact on the size of glitches apparent in omicron on the summary pages.
The attached plots is a stitch-together of 2 days of omicron plots from the summary pages, along with the same time period of data in ndscope for the BNS range, whether the CPS diff was on (high) or off (low), what state the SEI_CONF guardian was in (high=nominal WINDY, med-low = microseism state, low-off-plot = sensor correction off), and the ground STS BLRMS in the microseism band. I've included vertical bars at the locations where the CPS diff is turned off yesterday, where Jim changed the SEI_CONF state to microseism, and where Corey changed the SEI_CONF state to have no sensor correction, in preparation for maintenance day.
The glitches from about 20 Hz - 40 Hz seem to immediately drop away when I turned off CPS diff yesterday afternoon, but then they start to come back as the ground motion continues to get even worse. The microseism has gone down a bit, but it looks like the CPS diff got turned back on (not yet sure if that was a guardian thing, or an SDF accept thing), and JeffK pointed out that we were again seeing big glitches. I've again turned off CPS diff (all of it, not just ETMs, although that is an interesting suggestion by Jim that perhaps we should try sometime).
One might think at first glance that Jim's having put the SEI_CONF guardian into the microseism state increased glitches between 10-20 Hz, but I suspect that those are actually just coming from the increased microseism during that time. There's some subtle threshold, but when the microseism BLRMS fall below that level, those glitches fade away, even though the seismic configuration has not changed.
Laser Status:
Front End Power is 32.32W (should be around 30 W)
70W Output Power is 69.83W
Front End Watch is GREEN
70W Watch is GREEN
PMC:
It has been locked 5 days, 1 hr 13 minutes (should be days/weeks)
Reflected power = 11.41Watts
Transmitted power = 52.14Watts
PowerSum = 63.55Watts.
FSS:
It has been locked for 2 days 3 hr and 55 min (should be days/weeks)
TPD[V] = 3.925V (min 0.9V)
ISS:
The diffracted power is around 2.6%
Last saturation event was 1 days 16 hours and 40 minutes ago (should be days/weeks)
Possible Issues:
I've started my latest version of the Lock Loss Alert (see MEDM attached). New features:
Expanding on this comment:
ETMY violin mode damping of modes 18 and 20 was completed early on Friday, Dec. 13th (Pacific), alog 53875.
While snagging the measuring cup of the PSL to top of the TCS chillers, noticed that the PSL Crystal Chiller (one on top) was clearly in the middle of Max & Min. Went ahead and topped this chiller off. Added 200mL of water.
(The PSL Chiller FAMIS reminder will be on Thurs, so will probably not have to add too much. Jeff B. mentioned this low level could probably be due to air bubbles bleeding out post-chiller-work last week.)
Niko called me last night concerned about PT427 alarm. PT427 & PT527 (Y2-8 & X2-8 locations) are pressure gauges on ion pumps 250 meters from end stations on beam tube, and are powered by a solar powered battery pack that is known to lose charge in winter due to lack of sun and insufficient battery capacity. These gauges will likely alarm throughout the rest of the winter until more batteries are added. Red light next to gauge on VAC OVERVIEW MEDM screen indicates this mode of alarm.
Thought I'd toss in a photo of the overview pointing out the vacuum gauges for these solar ion pumps.
Thanks, Corey! The ion pumps have a 250 meter long high voltage cable that runs to the end stations so the pumps are powered by a remote controller located in mechanical rooms at end stations. The pressure gauges are powered by charged batteries local to equipment.
Addressed TCS Chillers (16:50-17:00utc):
Some plots are zoomed in to show occurences at the point of restart after the chiller failure/recovery. All in all, everything seems nominally ok. FSS TPD voltage has tapered off a bit to levels before the last remote alignment, it seems.
TITLE: 12/16 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 108Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:
LOG:
Nothing happened. Range seems slightly degraded with rising microseism.
TITLE: 12/15 Eve Shift 00:00 – 08:00 (16:00-00:00), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Quiet shift, nothing of note occurred
LOG:
Nothing to report
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:
