Terminating PEM power supply cables at mezzanine Searches ongoing for 3IFO optical lever equipment Possible camera work Digging continues for trench to VPW Tumbleweed bailing on the X arm Safety meeting held. John pointed out that there is a web page outlining requirements for visiting scientists (www.ligo-wa.caltech.edu/professional.html).
model restarts logged for Tue 02/Dec/2014
2014_12_02 10:48 h1fw0
2014_12_02 10:58 h1hpietmx
2014_12_02 11:02 h1susetmx
2014_12_02 11:08 h1iscex
2014_12_02 11:16 h1hpietmy
2014_12_02 11:20 h1hpietmy
2014_12_02 11:23 h1susetmy
2014_12_02 11:38 h1iscey
2014_12_02 11:39 h1iscey
2014_12_02 11:42 h1fw0
2014_12_02 11:42 h1iscey
2014_12_02 11:46 h1iscey
2014_12_02 11:47 h1iscex
2014_12_02 12:02 h1asc
2014_12_02 12:05 h1asc
2014_12_02 12:07 h1iscey
2014_12_02 12:08 h1broadcast0
2014_12_02 12:08 h1dc0
2014_12_02 12:08 h1fw0
2014_12_02 12:08 h1fw1
2014_12_02 12:08 h1nds0
2014_12_02 12:08 h1nds1
2014_12_02 12:35 h1omc
2014_12_02 12:36 h1susomc
2014_12_02 12:38 h1broadcast0
2014_12_02 12:38 h1dc0
2014_12_02 12:38 h1fw0
2014_12_02 12:38 h1fw1
2014_12_02 12:38 h1nds0
2014_12_02 12:38 h1nds1
2014_12_02 12:46 h1fw0
2014_12_02 13:31 h1omc
2014_12_02 13:45 h1fw0
2014_12_02 16:03 h1fw0
2014_12_02 16:47 h1fw0
2014_12_02 18:54 h1fw0
2014_12_02 19:45 h1fw0
2014_12_02 20:43 h1fw0
Maintenance day. h1fw0 restarts due to file backups (purple). Model restarts and associated DAQ restarts. Conlog frequently changing channel report attached.
Alexa, Kiwamu, Lisa Most of the day was lost in ALS land. We manage to start locking at 2am. Our success was pretty well correlated with Kiwamu changing the Y end VCO offset slider from -0.263 to -5.526 such as the X VCO goes away from the negative railing point when DIFF is locked. This was done because, even if the HEPI relief was on, we were seeing that at least some of the ALS lock losses were due to the X VCO railing (to be investigated). After that, we worked on ASC during the CARM offset reduction. So far we have been using AS_B_45Q for DHARD until CARM offset = -12, then we were opening it because we suspected that this signal was flipping sign when reducing the CARM offset further. Tonight we indeed established that by measuring the response to ETMX steps by comparing CARM offset -8 and -13. At the same time we checked the AS_A_45Q response, which is still sensitive to DHARD but it does not change sign. After measuring the relative gains, we transitioned from AS_B to AS_A at -13 CARM offset, and then we kept the loop closed while reducing the offset down to -16. Some parameters: - AS_A input matrix elements are +2e-6 for both P and Y (ugf ~50mHz). - We also reduced the SRCL gain by a factor of 2 (from -30 to -15) at CARM offset -15, and that reduced the broad gain peaking we were seeing in the SRCL spectrum at 70 Hz (we didn't really make any measurement). We are not updating the Guardian, as this needs further testing. Data: Dec 3, 11.15 UTC locking start, lost lock at 11.56 UTC while transitioning to -16
The guardian has now been updated to reflect what we found last night.
Dave O, Ellie, Sheila
Tonight we had some difficulty with ALS DIFF lossing lock. We have plotted a few of these, and each of the times that we have looked at (about 4) the ALS_C_DIFF_A_DEMOD_RFMON drops significantly (12dB) about 0.3 seconds before anything else changes. We checked that the BS is not moving (no oplev glitches) at these times. This was a bit confusing.
Ellie also found one of the glitches similar to what we saw in alog 15242. However, the drop in RFMON came before this glitch. Previously we saw that these glitches were present even without DIFF locked.
Here is a collection of lock loss times (there were many more)
3:15:39 UTC DEC 3
3:19:30
3:42:50
3:52:48
5:53:46
7:26:33
Lisa, Evan
For good measure, here are some more lock losses. The latter two are with DRMI engaged.
As requested by Paul, I had a look at some signals of the DRMI to see how much we gained in terms of the recycling gains by the recent TCSX engagement.
In brief, POP_RF18 increased by 8% and ASAIR_RF90 increased by 19% which is good. Naively speaking, the recycling gain for the 9 MHz SB increased by the same factor of 8 % by engaging TCSX. Also, note that the 45 MHz SB used to have a recycling gain of 21 before we started the unclipping effort (see alog 14532).
Below shows a table for side-by-side comparison. Note that the TCSed data is the ones from this after noon, at which point the ASC loop was not optimum for SRC.
| with TCSX (2014-12-02 22:30:14 UTC) in cnts | without TCSX (2014-11-24 2:44:01 UTC) in cnts | ratio (with/without) | |
| POPAIR_A_LF | 1100 | 1000 | 15% |
| POPAIR_B_LF | 600 | 570 | 9 % |
| POPAIR_B_RF18_I | 370 | 355 | 8 % |
| POPAIR_B_RF90_I | 115 | 100 | 20 % |
| ASAIR_A_LF | 9700 | 9400 | 7 % |
| ASAIR_B_LF | 3300 | 3100 | 10 % |
| ASAIR_B_RF90_I | 7200 | 6300 | 19 % |
| IMC_MC2_TRANS_SUM | 777 | 811 | - |
Kiwamu, Dave, Dan, Alexa, Sheila, Elli, Evan
We have been having trouble keeping ALS DIFF locked for the past few hours. Alexa finally figured out there was a large 10 Hz peak in DIFF error spectrum and the ESD drives.
We thought it might be either the ETMX or ETMY 9.8 Hz bounce modes, since these have previously given us trouble (LHO#15118, LHO#15247). However, by looking at oplev spectra, we determined it was actually ITMX and the frequency was 9.84 Hz.
So we copied over Matt’s ETMX damping filters (pass9.8, which has the sharp gain, and phase9.8, which allows us to adjust the phase) and adjusted the frequency to 9.84 Hz. Then I turned off the oplev filters and engaged pass9.8, and played with the gain (originally −0.05) until I got damping (the necessary gain was 300). The mode was originally a factor of 5–10 above the ITMX pitch oplev noise floor, and after 10 minutes we were able to push it into the noise floor. The use of phase9.8 was not necessary.
I have restored the ITMX pitch damping, along with a 9.84 Hz elliptic stopband filter stop9.84 which is modeled after an ETMX L1 filter.
Attached is a fine-resolution spectrum of the ITM OpLev pitch signals. ITMX bounce mode = 9.8469 Hz, ITMY = 9.8315 Hz. Probably ITMY will be a problem someday, too.
The bounce mode peaks are very narrow - only about 2mHz wide. One theory (from Dave) is that there might be two modes very close to one another, and only one of them couples to the oplev feedback; the other stores energy and makes the mode difficult to damp. The list of suspension resonances says that the z2 and z3 modes are both around this frequency, but doesn't say if we expect them to be within 2mHz of each other.
The phase9.8 filter was designed to be used with the standard OpLev damping to prevent excitation of the bounce mode, not with the Pass9.8 (used with the 0:50 filter to damp the mode after it gets excited).
ITMX is supposed to be as bad as ETMY.
ETMY > ITMX >>>>>>>> ITMY > ETMX, in terms of bounce-to-length coupling.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14876
I want to clarify something Dan wrote. There is only one vertical resonance at ~ 9 Hz in the quad - it is the highest of the four vertical resonances, called modev4 in the list of resonances which can be seen at e.g. https://awiki.ligo-wa.caltech.edu/aLIGO/Suspensions/OpsManual/QUAD/Models/20140304TMproductionTM The reference to z2 and z3 describes the dominant motion in that mode i.e. which masses are moving and in which directions in that mode. The highest vertical resonance involves the penultimate and test masses moving out of phase with each other in vertical - hence the z2 ( which is PUM vertical motion) and z3 (test mass vertical motion). The numbering is historical from our original MATLAB models, based on extending a triple model- masses are 0,1,2,3 from top to bottom.
Sheila, Alexa
We noticed that the HEPI tidal feedback to the ETMs was not working. We found that the ISC MON outputs were off, the ISCINF_LONG offsets were off. In addition the ETMY ISCINF gain was zero and the ETMX ISCINF gain was 1000; the nominal gains should be 1. This is now in the guardian.
We are trying to make sense of what we see during the CARM offset reduction. We believe that we are at a lower CARM offset than we estimated given our power build up. When our power build up is ~120 (wrt single arm, as measured by the TR QPD - Sheila is checking the normalization), REFL_DC is already at ~50% of its max power, and it looks like REFL_9I is indeed already within its linear range. However, at that point we should already be close to ~500 x single arm power (or half of the total build up, nominally 1000 x single arm). POP_DC shows only a modest factor of 2.5 increase with respect to only sidebands in the recycling cavity, it should be higher than that. This would explain while we couldn't further increase the CARM offset, as the TR signals are becoming flat, and why we couldn't keep using the same AS WFS signal in loop, as it is changing sign at low CARM offset ( see Dan's model ). We will try to figure out why this is happening (are we simply misaligned? low carrier recycling gain? loss in the arms?...). The positive message is that there is no point in trying to further reduce the CARM offset in this state..so we are done with that. Kiwamu posted these simulation plots as a comparison, and LLO log 12765 is an example of the LLO sequence.
ASC model (ASC_MASTER.mdl) and the end station ALS model (ALS_END.mdl) were modified and installed as a test to accomodate the TMS actuation and the ITM camera sensing in ASC.
Now ALS WFS DOF3 (which is used for ITM camera) goes to the ASC, and the ASC output matrix can act on TMS.
Relevant MEDM screes were updated.
h1guardian reboot: Dave, Patrick
At 10:06 PST I rebooted the h1guardian0 machine to test that all the nodes started automatically. The reboot proceded normally and all the guardian nodes did start automatically, SUSMC1 node was slightly delayed relative to all the other nodes. For reasons currently unknown the restart crashed the conlog master. Patrick restarted the conlog.
Model Changes: Keita, Daniel, Dan H, Dave
The following models were restarted with new code: h1susetmx, h1iscex, h1hpietmx, h1susetmy, h1iscey, h1hpietmy, h1asc, h1omc, h1susomc
Frame Writer Minute Trends Offload: Jim
h1fw0 has been busy over the past day copying its raw minute trends from the SSD array to HDD. Many restarts of h1fw0 are attributed to this loading.
h1susetmx snap files: Dave
For reasons unknown many old snap and log files in the directory target/h1susetmx/h1susetmxepics/burt/ were deleted between 10:00 and 11:00 PST this morning. This included the safe.snap symbolic link. Therefore the 11am restart of h1susetmx did not burt restore to its safe.snap, rather to the snap file created at the shutdown time. I restored the safe.snap link. Investigation continuing.
Partial loaded Filter Module Files: Dave
The following systems were discovered to have partially loaded filter files, I performed a "load all coefficients" on: h1psliss, h1susprm, h1sussrm, h1oaf, h1lsc, h1omc. The model h1asc took care of itself after it was restarted.
SVN local mods: Dave
The following front end source files have local modifications:
lsc/common/models/lscals.mdl Tue Mar 11 21:57:37 2014 M
lsc/h1/models/h1lsc.mdl Mon Oct 27 15:40:01 2014 M
omc/common/models/omc.mdl Tue Dec 2 13:16:29 2014 M
omc/h1/models/h1omc.mdl Tue Dec 2 12:32:27 2014 M
psl/common/models/psldbb.mdl Fri Jan 10 19:19:47 2014 M
psl/common/models/pslfss.mdl Fri Nov 21 14:12:02 2014 M
psl/common/models/psliss.mdl Tue Nov 18 11:47:45 2014 M
psl/common/models/pslpmc.mdl Fri Nov 21 14:13:54 2014 M
psl/h1/models/h1pslfss.mdl Wed Sep 17 14:54:45 2014 M
psl/h1/models/h1psliss.mdl Fri Nov 21 14:16:00 2014 M
sus/h1/models/h1susomc.mdl Tue Dec 2 12:32:25 2014 M
the following guardian files have local modifications:
M common/guardian/ALS_DIFF.py
M common/guardian/ALS_COMM.py
M common/guardian/ALS_ARM.py
M common/guardian/IMC_LOCK.py
M h1/guardian/lscparams.py
M h1/guardian/ISC_DRMI.py
M common/guardian/LSC_PRMIsb.py
M common/guardian/LSC_CARM.py
M h1/guardian/lsclib/prxy/carrierlock.py
M h1/guardian/lsclib/pdOffsetNull/pdOffsetNull.py
M h1/guardian/lsclib/prmi/sidebandlock.py
MM h1/guardian/LSC.py
M common/guardian/OMC_LOCK.py
M h1/guardian/omcparams.py
M common/guardian/SUS.py
M common/guardian/susconst.py
M common/guardian/SUS_TMS.py
M common/guardian/SUS_BS.py
M h1/guardian/SUS.py
M common/guardian/ifolib/CameraInterface.py
M h1/guardian/H1ECATX1PLC2.py
M h1/guardian/H1ISCEX.py
M h1/guardian/CSD_LoadDatabase.cmd
DMT Broadcaster: Dave
Checked all DMT channels are in the DAQ. Found to my chagrin that two channels were duplicated in the broadcaster list. H1:PEM-EX_MIC_VEA_MINUSX_DQ and H1:PEM-EX_MIC_VEA_PLUSX_DQ. I have removed the duplication which will be applied on the next DAQ restart.
Alexa, Sheila, Dan, Dave O.
Stefan had reported that the original SRM ASC wfs had been oscillating post TCS work (alog 15343). For SRM we had used AS_A_RF36_I as the error signal with a gain of P, Y = 0.3, 1.2. We compared this with REFL_B_RF45_Q error signal, which at one point Livingston had been using, and found this actually appeared to be a better signal. We were able to close the yaw loop with a gain of 4. I did not see any oscillations with this loop closed for about 10 minutes; and it appeared to bring the build up back whenever I misaligned SRM. We tried closing the pitch loop, but have not suceeded yet. We tried a gain of -4 and 4, which caused the loop to oscillate. I reduced the gain of -1, and did not see oscillations, but was not able to recover the build up with an SRM alignment.
For now, we decided to move on and try locking. There is still more work to be done in closing this loop. I will not update the guardian yet.
Alexa, Dan, Sheila
We found the BS ISI ST2 watchdog was tripping when the DRMI was acquiring lock; big transients in the MICH control signal would show up in the ST2 GS13s and saturate the inputs. After some dataviewer'ing, we found that these transients are always there, but today they were large enough to hit the watchdog threshold. We suspected the GS13 gains had changed, and conlog said that yesterday the 'Gain' filter (FM4) on the BS ISI GS13INF filter banks was turned on. (We suspect that someone turned these off during the SEI work today?) We turned them back on; the problem seems to be fixed.
None of the other BSC chambers have these filters on, but it looks like we need them for the BS, for now.
We tripped the ISI even while DRMI was locking (and luckily did not break the lock). We compared the length signal to the BS between today and yesterday, and concluded the LSC signals were not very different and were not the culprit.
Note that these GS13INF gain filters are compensating for an analog switchable gain. I agree that if the GS13s are in "high gain" mode, i.e. with FM4 OFF, then they will saturate more easily. But, if you want to change the gains to "low gain" mode (with FM4 ON), you shouldn't just turn off the compensation filter. You need to use the command scripts (the dark beige button on the lower 1/3rd on the left of the overview screen -- then hit "GS13 HI / LO" button as you like, again on bottom 1/3rd of screen, but on the left) such that both the analog gain and the digital compensation are switched simultaneously. Good luck and god speed.
Here are two plots showing the ideal behavior of some DC signals and REFL9 signal during reduction of the CARM offset. They are computed by optickle with the designed optical parameters except for the modulation depths which are now 0.17 rad and 0.3 rad for 9 and 45 MHz modulations respectively.
Attachment 1:
A plot of some DC signals as a function of the CARM offset. TRX (show in red) is normalized by the single arm power. It reaches 1350 with zero CARM offset, indicating that the recycling gain is about 41. REFL_DC (shown in cyan) is normalized such that it is unity when the CARM has a large offset. The same normalization is applied to POP_DC (shown in brown) as well. The black curve is derived simply by sqrt(normalized TRX + normalized TRY).
Attachment 2:
A plot of REFL_DC, AS_DC and REFL9 demodulated signals as a function of the CARM offset. AS_DC is in mW while REFL_DC is in Watts. The demod signals are in an arbitrary unit.
PDFs attached.
