Attached plots show that ETMY mode20 was effectively damped yesterday. I am currently damping ETMY mode18. Will post a power spectra showing mode18 peak height differnece, but for now, lunch.
Took these while at end-X today. Good for future talks on wind fences. This is the now complete fence! First image is standing -X, -Y of the EX building, looking roughly North NorthWest. Second is +X /-Y of the building, with a view panning from West South West to West.
Here is the complete EndY Fence from +Y.
As an update, the build is complete but the vendor is returning next week to address our punch list.
J. Kissel Today, I tried to characterize / confirm the systematic error in the calibration that has been observed in PCAL to h(t) during the first ~hours of a nominal low noise stretch. Many more details about the effect, and what's been observed to date in yesterday's LHO aLOG 53775. I've done so by driving clusters of new calibration lines at 4 new frequencies to measure the DARM Loop Suppression (1 / [1+G]), and surrounding them with PCAL X lines, in order to measure the loop-suppressed sensing function (i.e. the response function), ( C / [1+G] ). I left these lines on during the entire lock acquisition process beyond DC readout, and for ~1.5 hours in to a nominal low noise stretch, in order to track the change over the entire apparent evolution of the detuning / L2A2L effect. Here's why I say this was medium successful -- (G) == good news, (B) == bad news: (G1) I was able to find frequencies and tune amplitudes for the PCAL and DARM lines, such that we can easily repeat the test. (B1) *this* (start of the) NLN stretch had to be run with one less stage of whitening, because the ~18 Hz DARM line I put in was still too loud (I didn't want to change it mid power up, and only found out it was too loud after hitting nominal low noise) (B2) Because the line was close to saturating either the ESD DAC or the OMC DCPD's ADC, there were huge amounts of non-linear shoulders, which bled in to the ADS lines, which mean the spot position steering didn't go as well, or as fast as it normally does. We had to increase the ADS lines by a factor of 10, and reduce the ADS loop gains by a factor of ten. (B3) I had not checked this before starting the test, but essential channels for post processing, DARM1_IN2 and DARM1_EXC are not stored in the frames. So, I won't be able to truly plot the sensing funciton, C, alone -- only the loop suppressed sensing function, C / (1+G). (G2) But, at least with the new frequency points of PCALX, we should be able to at least corroborate what has been seen at 17.1 Hz PCALY line for the whole run. (B4) Likely, the 5.6 Hz, 7.4 Hz, and 9.1 Hz clusters of calibration lines are too loop suppressed, because G is too large by 5 Hz, so we'll only be measuring C/G = 1/(AD), which we know isn't changing. To truly expose the effects, we *need* the (1/[1+G]) measurement, as we do in the swept sign measurements. So -- because I sucked up ~2 hours of IFO time with this data set, I'm going to analyze it anyways, but I really hope to: (A) Modify the h1omc front-end model such that DARM1_EXC, and DARM1_EXC are stored in the frames, and (B) Redo the measurement with [i] the 18 Hz line reduced by a factor of 10. Time of data analysis start: Dec 11 2019 00:38:42 UTC Time of data analysis stop: Dec 11 2019 02:19:00 UTC (or when ever we're back in nominal low noise.) Exact frequencies used: 5.4375-5.625-5.8125, 7.250-7.74375-7.625, 8.90625-9.09375-9.28125, 18.7188-18.9062-19.0938 where they're listed as PCALX - DARM - PCALX frequency clusters, and they were chosen to be bin-centered for a 30sec (0.03 Hz BW) FFT, assuming 50% overlap with a hanning window.
As a close out test, I quickly reduced the 18 Hz cluster by lots, then turned ON the final stage of OMC whitening, reduced the ADS lines to normal, and increased the ADS gains to normal, and confirmed that all was well and happy. So, all the saturation problems and huge shoulders were all solved by just backing off on the amplitude the 18 Hz cluster. Thus, the next time we do this, we can run in a mouch more normal configuration. I attach the PCALX and DARM line settings after reducing the 18 Hz cluster. These are what should be used in the future -- after we get DARM1_IN2 and DARM1_EXC stored in the frames.
Today's RGA scan of HAM6 is attached. Richard and Carlos configured the unit so we can monitor remotely in control room. Computer sees device, but needs a firmware update before it will cooperate.
Total pressure at HAM6 is ~3e-7 Torr and SEM voltage set to 1000V.
HAM6 RGA is now functional via remote access! I left the device ON with cooling fan running. Firmware is also updated.
I installed version2.0 of lock_loss_alert today. The new features are:
The new OBSERVE alerts are to support remote IFO operations (e.g. operator delay due to bad weather) and to alert of commissioning activities.
Richard, Patrick, Carlos, Dave:
Following the installation of two new Pulizzi remote-power control units and their associated EPICS IOCs (Patrick), I have created a new Overview MEDM for the remote power control system. It is accessible from the CDS pulldown on the SITEMAP.adl (CDS Pulizzi Power Control). The Corner Station LVEA unit is not yet installed, its placeholder is shown.
This MEDM will serve as documentation as to which external units are power controlled by the 4 outlets.
TITLE: 12/11 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 5mph Gusts, 3mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.30 μm/s
QUICK SUMMARY: Relocking after Maintenance, so issues, being worked out
Ed, Gerardo
75ml was added to both TCS chillers. Thank you Gerardo for seeing to this for me.
TITLE: 12/11 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:
Re-Locking has been both impressive (no initial alignment after a record long lock) and daunting due to some anamalous rotation stage silliness. H1 made it past the laser power increases after a coule of attempts and was paused at LOWNOISE_LENGTH_CONTROL due to a barrage of SRM saturations and gain adjustments that are currenly in the care of the commissioners. Handing of to Cheryl.
LOG:
Vendors on site:
Chris down arms for tumbleweed checks
Filiberto working at end Stations:
Jeff K and Jenne:
Niko and Dripta
Patrick
Timesh/JeffK/Evan G
Hugh and Scott
TJ and Camilla
Jim and Camilla
Chandra
Gerardo
[J.Kissel, E.Goetz, T.Mistry]
During the Tuesday maintenance time, between the times 09:30 PDT to 11:15 PDT, we went to the X End to inspect the cables, apply relevant labels and remove unnecessary NCAL parts from the end station. The NCAL remain unplugged and fully powered off apart from the NCAL PC thus, there is no way a signal can be passed from the PC to the NCAL (see LHO alog 53689). This is because the NCAL PC is located in the same racks as the power supplied and other computer systems and we are confident that the NCAL PC contributions to noise (i.e. emf, acoustic, etc) is minimal or negligible compared to the other systems in the racks.
An updated cartoon of the as-installed wiring diagram can be found at D1900015-v5 and a PDF attached to this alog. Hopefully this diagram will aid in understanding the electronic configuration of the NCAL system. A more detailed system (pin-to-pin) diagram can be found at D1900499.
For channel names and other information, please see the NCAL wiki or the NCAL Document Tree (E1900309).
Please see the additions to the wiki instructions to check that the power to the coils has been turned off once the script has finished running.
WP 8491
The following cables were disconnected from the illuminator chassis at EY to help with noise hunting.
1. BSC lights
2. ISCTEY lights
3. TCS Sled Driver LED power
4. ISCTEY Fan Status Readback
The ALS noise eater was left plugged in.
In an effort to minimize noise sources we have installed a remote controlled power switch on the PEM amplifiers at the End station. They are controlled via a telnet session over ethernet. The script for the Tuesday injections should turn these on automatically. eyrpc and exrpc.
I updated /opt/rtcds/userapps/release/cds/h1/scripts/h1_pulizzi_power_control_ioc.py to take the ip address and channel name prefix as command line arguments. I restarted the IOC running in screen on h1fescript0 controlling the power to the ALS fiber polarization controller using ip address 10.105.0.12 and prefix H1:CDS-PULIZZI_ACPWRCTRL_MSR0_. I verified that I could still control the power to it using the medm screen for adjusting the fiber polarization. I started two new IOCs in screen on h1fescript0 for the newly installed remote power controls at end X and end Y: screen -S exrpc /opt/rtcds/userapps/release/cds/h1/scripts/h1_pulizzi_power_control_ioc.py 10.106.0.171 'H1:CDS-PULIZZI_ACPWRCTRL_EX0_' screen -S eyrpc /opt/rtcds/userapps/release/cds/h1/scripts/h1_pulizzi_power_control_ioc.py 10.106.0.172 'H1:CDS-PULIZZI_ACPWRCTRL_EY0_' I checked /opt/rtcds/userapps/release/sys/h1/scripts/PEM_weekly_magnetic_injection.py into svn. I then updated it to to turn on and off outlet 1 of the new remote power controls at end X and end Y. I have not tested this change or checked it into svn. https://cdswiki.ligo-wa.caltech.edu/wiki/cdsmsrpower0 https://cdswiki.ligo-wa.caltech.edu/wiki/PulizziRemotePowerControlEpics
Tested the changes to PEM_weekly_magnetic_injection.py. It may fail to turn the coils back off if it is cancelled with Ctrl-C. Checked the changes into svn.
I have turned off the fine adjust (H1:PSL-ROTATIONSTAGE_FINEADJUST) for the PSL rotation stage because it was causing a sudden change of power at the end of power changes. This was worse at high powers, and would change the power almost immediately by almost a watt (see alog53068). Wih this off, I turned the bootstrapping turned back on.
Searching for home the other week seemed to help slightly with reducing the size of this rot. stage "snap", and I'm sure getting a new calibration would also help, but the sudden change in the rot. stage is not desired. The fine adjust angle set in H1:PSL-ROTATIONSTAGE_ANGLE_ADJUST, doesn't seem to be accurate either. This is set to 0.005 deg, but looking at Sheila's alog linked above, it would move by ~0.8 deg. I added into the LASER_PWR node a call to make sure that this feature is off.
I also testing a timer to see if waiting a second longer between the initial call and the bootstrapping call would help anything. It didn't help with this rot. stage "snapping" at all when the fine adjust was on, and with the fine adjust off it didn't make a difference. So I left out a timer between the calls.
Attachment 1 - Fine adjust on. Small step in the encoder value seen at the end of the bootstrapping. This is a small step compared to Sheila's alog, but it still shows the sudden movement.
Attachment 2 - Fine Adjust off. No step seen at the end of the bootstrapping.
Well it happened again... (see attachment)
I added a 2 second pause between the initial power request and the bootstrapping. This seemed to work for the one attempt we've had.
Check of the HEPI pump fluid levels:
End-Y - Level is 8 14/16, which is a change of -1/16. Note this is 1/16 above trip level.
End-X - Level is 7 14/16, which is No change.
CS - Level is 6 5/16, which is a change of +1/16.
No new leaks noted on any the 6 pump skids.
Closing FAMIS #13492
Lowered the trip level about 3/16" giving us a bit of head room to prevent unwarranted trips.
At 16:21:18 UTC, H1 was intentionally unlocked for necessary maintenance. How long would it have lasted? We may never know! We held off to make an even 113 hrs and then a little more while waiting for those with more invasive work to prepare to start which resulted in a few seconds mor than 10 minutes. Way To GO!
Congratulations! That was well done.
In a nod to the saying "success has many parents", I made a quick log about riding through the earthquakes on Dec 6 so we can point to that as one of the many things done to improve the robust performance of the detectors.
Truly awesome! But why was lock intentionally broken? Was that really necessary? You should have just let it go while you went on with maintenance activities. Maybe it could have gone much longer!
In general, I see almost no reason why lock should ever be intentionally broken. If a maintenance activity breaks lock so be it, no probblem, more information on the various things that can cause lock loss. But if it doesn't, then that's great and we have even longer lock stretches.
Around 14:55 notice H1 range took a step down at 13:37.
Only obvious change was increase in 500-2000Hz bands via the BLRMS of DARM. This lead me to look at violin modes and sure enough we had a big line on DARM spectra around 1kHz. Looking at the Violin Mode medm Screen & DTT, it pointed toward:
ETMy's MODE 18 (as well as a rung up MODE 20).
Unfortunately, I could not find newer instructions for damping violin modes (I could have sworn Rahul had something new because I remember Ed going through a procedure where he manipulated the VIOLIN_DAMPING guardian node. The only Violin mode instructions I could find were the old ones Nutsinee wrote up.) So after searching old alogs & through wikis for a few minutes, I then decided to take action:
Given below are the new links (effective from April 2019).
https://cdswiki.ligo-wa.caltech.edu/wiki/Violin_Mode_Table_v2/
and for the pdf file
https://cdswiki.ligo-wa.caltech.edu/wiki/Violin_Mode_Table_v2?action=AttachFile&do=get&target=Violin_damping_v1.pdf
[Sudarshan, Jenne]
This afternoon we moved the ADS line at 22.347 Hz down to 22.147 Hz. All other ADS lines remain the same. This line was the most egregiously close to an interesting pulsar frequency.
Once the IFO relocked and the ADS alignment had converged, we opened the Yaw4 ETMX Yaw loop and changed its frequency. We made a new bandpass for the SIG filter bank, to bandpass at the new frequency. Sudarshan had calculated that we would only need to change the A2L gain by about 0.004, so we left it alone. We rephased by making I signal zero, which required increasing the phase by 5 degrees.
We then turned on the loop, and things seem stable and good. It's hard to really say, but maybe the range increased a teeny bit? We think that we have made these changes 'permanent' by editing the PREP_ASC_FOR_FULL_IFO guardian state, and accepted these values in both the safe and observe sdf files for the ASC.
During the last long lock, I had hand-selected the correct bandpass filter. However, the guardian selected the wrong bandpass for the new frequency. Since we've seen that having moved this line is okay, I just put the correct bandpass in the location that the old bandpass was, so that I didn't have to change guardian. (that place is FM6 in the demod SIG filter bank for ads yaw4). I have accepted this in the safe and observe snaps for the ASC.
Having this bandpass wrong seems to have misaligned the IFO (not surprising) enough that we had too much PRCL gain (the PRCL loop was oscillating on the high side of the phase bubble), but not enough that we had any other symptoms of poor alignment. Anyhow, next lock, having fixed the bandpass, there were no problems with the PRCL gain.
