This came up a couple of times this week, and Aidan and I just figured out how to do it, so for those that don't already know:
You can scale data in plotted in dataviewer by going to menu: Data->Transformations->Geometric transforms...
I ran the ITM RHs for twenty minutes at 2W total input power this morning to measure the resistance of the segements and the change in resistance vs time due to an increase in temperature of them. This is to confirm they are working as part of the acceptance testing.
The resistance of the RH segments was around the nominal value of 42 Ohms:
The relative resistance vs time is shown in the attached plot. There is some (~20%) variation between the different segements.
model restarts logged for Fri 06/Feb/2015
2015_02_06 01:15 h1nds1
unexpected restart of h1nds1, most probably caused by data request overload (this is the default nds). Frame writers continue to be stable (3.8 days)
Alastair, Aidan, Jamie, Dave:
To support this weekend's TCS guardian development, I have temporarily added two new EPICS channels to the alarm manager IOC on script0. Their permanent location will most probably be the h1tcscs front end model, we will schedule this install for Tuesday maintenance. The channels are:
Ryan, Lisa, Evan
We have been locked for more than 1 hour with CARM controlled by digital REFL9I (at 0 pm offset) and DARM controlled by ASAIR 45Q. The power buildup is 1100 times the single-arm buildup, giving an interferometer recycling gain of 33 W/W. The REFL_A_LF power is 1.35 ct, compared to 21 ct with the arms held off resonance. This means the interferometer visibility is about 94%.
The new element today was a higher-bandwidth DHARD pitch WFS loop. The loop time constant is a few seconds or so, and is fast enough to suppress the appearance of the microseism in ASAIR 45Q. Next steps are probably to close the analogous yaw loop. Ryan had to adjust ETM differential yaw by hand several times to keep the AS beam reasonably round. Also, Ryan had to add a DC-coupled oplev servo to ETMX L1 pitch in order to keep the optic from drifting.
Details will be posted later.
These are the plots with the transition to REFL 9I, and a trend of the 1 hour long lock (starting around Feb 7, 12.11 UTC). In the first plot, the power build up increase around 400 sec is due to the improvement of differential YAW alignment that Ryan did by hand. The lock loss happened right after a DARM loop measurement. The high wind of the afternoon was totally gone by the time we came back to the site after dinner.
Congratulations! and thanks for staying up all night once again.
Welcome news. Great job. Congratulations to everyone who has helped bring this about.
Awesome! Very pleased to see this result. Nice work everyone!
Congratulations from Delhi! Nice to see the stability of lock at this early stage. The entire team deserves credit for undaunted persistence through all the tricky issues. Y'all rock.
In my previous trends I plotted the wrong POP18 signal (before demodulation), here is the correct signal representative of the sideband power. Once the arm cavity power increases from ~ 500 to ~1000 single arm power, the sideband power decreases by ~20% in about 10 min.
During breaks in the locking action this week, I have tuned up the OMC alignment loops that use OM3 and the OMC suspension to align the beam into the cavity. These loops are now stable; I've measured the OLTFs and everything looks robust.
I also fixed the dither alignment loops, though a combination of adjusting (audio) demod phases, moving frequencies around to avoid peaks in the intensity noise, and lowpass filters to get rid of the high-frequency junk. These might need some attention later, we should change the dither frequencies to match L1.
The first plot attached is a figure of the noise suppression with the AS WFS DC centering and the OMC ASC turned on. Top panel is beam jitter on the AS WFS, lower panel is beam jitter into the OMC. References 0-4 are with no loops closed, 8-11 are with the AS WFS centering loops closed, and the current traces are after the OMC ASC loops are closed. The AS WFS centering is fairly high gain, something like 3Hz, we could turn this down. The OMC ASC loops are around 1-2Hz UGF, when the QPD signals are used. (The dither loops are much slower.)
Second plot attached is an example of an OMC ASC loop transfer function. The inversion of the OMCS plant leaves a broad peak, but there's plenty of phase margin.
Third plot attached is the new output matrix, there were a few sign errors in the picture from the earlier post.
I have updated the OMC safe.snap file with the new filters, gains, etc.
This evening I also checked the balance of the OMC DCPDs, using an excitation in the cavity length, and changing the DCPD_BALANCE slider to minimize the peak height in the nullstream channel. I found that an exact 50-50 split was the best choice. Might need to check this again with a variety of amplitudes and frequencies, the result is seems a little too perfect.
Since the wind has been bad all afternoon, we took the chance to look at the filters in the suspension offloading path known as tidal. I copied the plant inversion we are using for the UIM in DARM, with this we were able to puch the bandwidth up to about 0.03 Hz. We also raised the limit on this to about 10 um. With this change we went from being able to lock the arms with green for less than about a minute to being able to lock for about 5-10 minutes. Eventually the "tidal" feedback reaches the limit, and within a minute of that happening the VCO rails. We could increase the limit further to possibly hold things a few more minutes, but the wind is getting worse.
Attached is a screen shot showing the new arrangement of filters and gains for this.
If you are wondering what to do when you try to open Firefox and you get an error message which tells you "firefox is already running", but it is not, and you don't want to reboot your machine, here is the solution (from Dave & Jonathan): - cd /ligo/home/lisa.barsotti/.mozilla/firefox - rm lock - rm .parentlock
rm ~/.mozilla/firefox/{,.parent}lock
To help with this on the common login accounts (ops, controls), at LLO in eLIGO, we created a script to invoke Firefox to uses a per-workstation profile and deletes the lock files before starting, This works fine as long as you train users to invoke the script (on the desktop) instead of from the Gnome menu (or directly at the command line). The move to per-user logins has eased this problem a lot.
During ISI commissioning today the total number of channels being monitored by SDF which were changed exceeded 40. Hugh asked if I could give him the full list and the total number of changed channels.
Here is the procedure (h1isietmy is shown as an example)
On the H1ISIETMY_SDF_RESTORE.adl medm screen, in the yellow "save" section:
Set the "FILE TYPE SELECTION" to "EPICS DB AS SDF"
Ensure the the "FILE OPTIONS SELECTION" is set to "TIME NOW"
Press the Blue "SDF SAVE FILE" button, which will save the current settings as a time-stamped file (e.g. h1isietmy_sdf_150206_170209.snap)
In a terminal, type the following:
target
cd h1isietmy/h1isietmy/burt
listsdfdiffs.bsh
The output from this command is shown in the attached file
On Nov 7 I added smoothing to the terribly noisy channels generating the differential pressure. I revert these back to no smoothing.
The smoothing factor was 0.75 and is now 0; see the attached for how that affects the channels.
Smoothing (SMOO) parameters for the Supply and Return pressure channels of EY were restored to 0.75 Friday evening, 2014-02-06, late-ish in the evening. The EPICs subrecords are not recorded in the frames, so I can't give you an exact time.
J. Kissel ETMX UIM Driver's rocker switch tripped last night at 8:44:30 UTC (Feb 06 2015 00:44:30 PST), which cause all OSEM output on the L1 / UIM stage (and the sensor signals as well) to fail. I've turned on the rocker switch, and the stage appears functional. Other points: ------------- There is no smoking gun for this chassis power outage. There are not enough diagnostic tools in the frames to look at all possible suspects (power surge to the chassis [no power monitors], chassis overheating [no temperature sensors], an inconsequential component on say -- a monitor board -- smoking [only one of the four monitor signals for each channel are stored], too large a current request [the NOISEMON is stored, not the FASTIMON]). Output request of DAC (from any ISC) does not appear to coincide with trip, but difficult to tell with dataviewer. There is an Longitudinal request to drive really hard, but it's unclear whether it's a the cause of or a result of the driver's power being shut off. Output request is roughly 42 [mA] (according to FAST_I_MON) on all four coils leading up to trip, switch trips on 3 [A]. Even the sudden, very large output request does not cause any current larger than the 42 [mA] -- as reported by dataviewer / EPICs. Reqrettably, only the severely-high-passed-at-5-[Hz] noise monitor signals are stored in the frames, but I attach the time series of one of the coils anyways to indicate the exact time. It shows a nice smooth ramp down at the time of the chassis power down. Serial number of this box is S0900303. I attach pictures of the box after I'd turned it back on. When I first approached the box, the front "power" LED lights were OFF, and the rocker switch was in the opposite (powered off) position. I'm not sure if there is good way to make this power shut-down control-room visible. I did notice that all the coil driver monitor signals were frozen at -16 [ct], and that the OSEM sensor speed dials were zero for this stage and this stage alone, which is what immediately clued me in that it was a flaw with the entire coil-driver chassis or satellite amplifier. This last happened (according to collective analog CDS crew's memory) on H1 SUS ITMX UIM driver, some time ago, 19 November 2013. See LHO aLOG 8635.
What's going on here?
Adding more to Daniel's comment -- the problem in the screen shot he shows is ONLY a problem with the reported decimation filter output for the ETMX L1 LOCK L bank. He had repeated the same test on the ETMX L1 LOCK P bank, and saw no difference between the OUTPUT and OUT16. It's not an issue progressing forward because no one and nothing uses the decimation channel but for diagnostics, but it's this kinda of stuff that makes users immediately suspicious of the entire front end code as a whole (regardless of how serious the problem actually is) and demand "REBOOT! REBOOT!" without really identifying the specific problem. Again, all signs point to that this is UNRELATED to the coil driver switching off from a current overload. This being said -- I agree the decimation display problem with *this* filter bank *is* weird, and we'll try to debug further.
I have seen this too. Good to know its not just in my mind.
A couple more observations from bizarro land:
As indicated quickly by Daniel (LHO aLOG 16604), I restarted the front-end process for h1susetmy Tuesday morning, and saw no change in this behavior. Since this bug seems to be extremely low impact, we should toss it into the CDS bugzilla for exploration of the flaw offline on a test stand to see if we can reproduce the error and hopefully debug. Also -- just because we like to blame everything new, it might be worth a check to see if this bug appeared after the RCG 2.9 upgrade, or after Daniel's Tidal Servo installation (see LHO aLOG 15601, or from his new Integrator filter module (LHO aLOG 15560), which is installed and feeding to/through the UIM L filter bank.
Alexa, Kiwamu
In response to the commissioning alog from the last night (alog 16501), we spent an hour or two to study the DRMI lock acquisition with ETMs miasliged in this morning. The key item we checked this time was the BS limiter. We took a few lock acquisition samples with and without the BS limiter which was suggested by Ryan.
It seems that the limiter improved the locking time. We will tentatively keep the limiter on.
The alignment was adjusted initially so that we observed consistently high build up in each lock. We tried repeating the same test with the arm cavities aligned, but we ran into some aligment issues which prevented us from completing the test with the arm cavities aligned. Note that this limiter method is something we used to use in the past, but apparently we decided not to use it for some reason at some point.
(The test without the limiter)
time to lock [sec] | |
attempt #1 | 10 |
#2 | 120 |
#3 | 540 |
#4 |
270 |
(The test with the limiter)
time to lock [sec] | |
attempt #1 | 5 |
#2 | 120 |
#3 | 60 |
#4 | 80 |
#5 | 90 |
(The limiter)
The limiter resides in BS_M3_ISCINF_LIMIT and the value was set to 5x105 cnts.
This limiter was being engaged during lock aquisition and then turned off when lock was aquired during the MICH_DARK_LOCKED state of the LSC_CONFIGS gaurdian. However, none of this was translated over to the ISC_DRMI guardian. I have added this to the ISC_DRMI guardian now.
Attaches is a plot corresponding to the test that Kiwamu and Alexa did. Once the SWSTAT is around 46000, the limit on the BS correction was turned on at 500,000, and the DRMI started acquiring lock more frequently (examples of locking attempts with this limit OFF and ON are attached as well). Since this setting was not in the guardian managing the DRMI lock (and the MICH guardian used in the initial alignment sequence turns this off once lock is acquired), the BS correction limit was typically off, unless someone was intentionally turning this on (which I am pretty sure happened at some point in the past, as this limit is a known important variable for the locking sequence). How critical this BS limit is for lock acquisition it depends on the seismic input. So, even assuming comparable good alignment states, the easiest explanation for "DRMI lock sometime works, sometime it doesn't" is that even when the seismic noise is not outrageously bad and it is obviously recognized like a problem, it might still be higher than "normal" and make the locking more sensitive to gain settings, and marginal. Here is some (now old) systematic study that Den did sometime ago at LLO changing the locking thresholds, also known to be critical parameters. It would be good to do similar tests with arms off-resonant. I think Alexa and Kiwamu tried by they didn't have enough time today, we should keep this in mind and use any available "free" time to make the acquisition time as short as possible ( < 1 min). Also, it would be good if changes to whatever "nominal" settings were clearly highlighted and somewhat motivated, so we can try to make sense of what's happening.
Transformations are cumulative. In other words, if I select "Scale = 10.0" and hit "Accept" twice, the data is scaled by 100.