This thing has been leaking for awhile but just hasn't made it on to the task priority list. Either Bubba, myself of Gerardo will try to fix this on the next Maintenance Day.
TITLE: 11/23 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ed
SHIFT SUMMARY: First half of the shift Sheila was moving around optics and eventually gained 10 Mpc. Then we took H1 to Observe to be ready for the scheduled injections. Sheila took out SDF from the intention bit condition so SDF differences will not prevent us from going to Observe. INJ_TRANS Guardian had some issues. Whatever the issue was, hitting INIT seems to have fixed it.
LOG:
11:59 Went to Observe to get ready for the scheduled hardware injection. a2l was still running the last couple of lines.
13:35 Gamma Ray burst. Since it's still an Engineering Run I assume the scheduled injection takes priority. Ignored the GRB.
15:18 Lockloss
I hit load and cleared the error. But I have no idea about the state of the injection since it didn't happen the first time. Looks like it will try again at GPS 1163938117?
And looks like another error.
I hit init. Seems like it's going to try the next one at 1163938617.
Alright I'm seeing some malicious noise in DARM now. I think the injection finally came through.
Looks like only the first two injections (1169397617 and 1163938117) didn't happen.
Looking at the error message, it appears that the injection "failed" as opposed to being skipped: https://dcc.ligo.org/DocDB/0113/T1400349/013/hwinjections.pdf (p11) • CAL-PINJX TINJ OUTCOME. Set as follows: – 1 = success – -1 = skipped because interferometer is not operating normally – -2 = skipped due to GRB alert – -3 = skipped due to operator override (pause OR override) – -4 = injection failed – -5 = skipped due to detector not being locked – -6 = skipped due to intent bit off (but detector locked) In previous experience, injections have failed when AWG has been unable to access a test point. Sometimes, this error is fixed by rebooting the awg computer. I'm not sure why it went away this time.
We are back at the low recycling gain alingment, because the noise is clearly better.
I tried with Annamaria to move soft offsets to the ETM positions at 30 Watts back to the positions we start with at 2Watts, this didn't result in the best recycling gain. Then I tried randomly moving the spot on each ETM, this didn't get a recycling gain better than 32. Eventaully I went back to trying the PRC spot positions, which improved both the jitter noise and the low frequency noise that showed up in the last 24 hours. Since clearly this is better (green vs yelllow in attachment, was fairly repeatable), I reset the POP positions and AS36 matrix to work for this alingment.
I am not sure if we can switch to REFL WFS with this low recycling gain (30), and won't try now so that we don't risk unlocking before the hardware injections.
The next things I would try would be to check soft yaw loops and MICH Y ASC for the instabilty at 1.88Hz, and try changing the refl input matrix based on the measurement in 31628, to see if we can switch to REFL WFS in this alignment.
Today we made a couple of magnetic injections at the corner station and, at least for now, finished acoustic and magnetic injections at EY.
We have been locked for roughly 3+ Hours. Most of this time has been in the COMMISSIONING state for an injection test at the beginning of the lock, and then PEM Injection work at EY since then (BRS EY is OFF!).
The Range for H1 has been noticeably lower today vs. last night (hovering at 60Mpc tonight vs. 75 Mpc last night).
The useism has been climbing over the last 8-10hrs.
I'm not sure if there were plans in place for adding SDF to the intent bit, but I just added it now so that we can get into practice and iron out any further rounding problems.
In preparation, Terra and I added the PI models to the scripts that automatically switch to observe in nominal low noise and safe in down. I also edited the script that changes models to down so that now it will change them to safe. We have made down and safe softlinks to the same file for most models, and some of the PI models don't have down.snaps while all models have safe.snaps. We originally started using down becuase some of the models (suspensions) needed to be restored with different settings after a computer reboot than they need in the down state. This isn't true anymore for suspensions, so there isn't really any point to having down.snaps any more as far as I can see.
I also edited the adjustDamperGain in ISC_library, which actually is used in the VIOLIN_MODE_DAMPING state, to round values to avoid excessive precision problems in SDF. This uses the cdsutils.getdata function that caused some problems in the OMC guardian earlier today.
We may still have some diffs come up because of excessive precison in some of our guardian code. If that happens, if the operator can take a screenshot of any diffs that come up that would be helpful so we can sort out what else needs to be fixed or not monitored.
I put DIAG_SDF back in the excluded guardian list, there are still several things which might be set inconsistently by the guardian, and we want to go to observe for some hardware injections.
From Sheila's request, I ran BruCo on two times,
Nov. 22, 7:30:00, https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/ER10-O2A/H1/Nov22/H1-OMC-DCPD-1163835017-600/
Nov. 22, 13:26:24, https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/ER10-O2A/H1/Nov22/H1-OMC-DCPD-1163856401-600/
From quick view on the results, ASC CHARD looks concerns around under ~25Hz.
I've attached a screen shot of the DARM spectrum at the two times Young-min ran BRUCO for, the red trace is the worse time (13:26:24) while the yellow trace is the better time.
It looks like in the better of these two times (7:30 UTC) there was broad coherence between DARM and PCAL Y sensors; this is something I haven't seen before in BRUCO. Was something wrong with the optical follower servo last light? for example: CAL-PCALY_OFS_PD_OUT_DQ
At both times, we have broad coherence with jitter sensors at around 0.1.
It seems most likely that the board obvious noise from 50-120 Hz in the spectrum is some non linear coupling. This seems similar to the noise that is making our range low after maintence today.
There are a few more channels which I think could be added to the excluded channel list:
SUS-ETMY_L2_FASTIMON_UL_OUT_DQ
SUS-ETMY_L2_FASTIMON_UR_OUT_DQ
SUS-ETMY_L2_FASTIMON_LR_OUT_DQ
At Reed Essick's request, I have scheduled DetChar safety study hardware injections for tonight starting at 4:00 PST Nov 23 2016. These are listed in schedule_1163473217.txt (SVN rev 5235): 1163937617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163938117 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163938617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163939117 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163939617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163940117 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163940617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163941117 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163941617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163942117 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163942617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163943117 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163943617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163944117 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt 1163944617 H1 INJECT_DETCHAR_ACTIVE 1 1.0 detchar/detchar_03Oct2015_PCAL.txt These are spaced 500 seconds apart and H1 needs to be in observation intent for the hardware injections to go through. We have coordinated this so as not to interfere with PEM injections. The "roaming" 5001.3 Hz Pcal calibration line has to be turned off for this test, and since I am leaving for the night, it was turned off at 4:12 Nov 23 2016 UTC. We will turn it back on in the morning (apologies Sudarshan!).
I turned back on the 5001.3 Hz "roaming" calibration line (LHO aLOG 31738, it was turned off for the HW injection test, aLOG 31747) at 03:25 UTC but this did not drop H1 from observation intent. Is this the intended behavior? Perhaps it should have dropped us!
Line turned off again at 04:12 UTC for DetChar safety hardware injections
The oscillator part of Pcal set-up is not quite an 'EXC' signal and hence I think it is not recognized as an injection. However if you use the SWEPT_SINE part, it will drop from observation intent. One can set-up SDF control to monitor those channels and any difference in SDF could be made to drop IFO from observation intent. Currently the SDF is circumvented to set the observation intent bit, which I think will be fixed for O2.
I've scheduled a coherent bbh injection for 3:00 UTC as part of the end-to-end test.
The schedule file (schedule_1163473217.txt) was modified and checked into the svn (https://daqsvn.ligo-la.caltech.edu/svn/injection/hwinj/Details/inj_trans/). I logged into each site's hardware injection machine (l1hwinj1 and h1hwinj1) and checked out the updated schedule file (/usr/local/home/hinj/Details/inj_trans). I then reloaded the INJ_TRANS guardian at each site. At LHO EvanG checked that the guardian was ok, he had to change the request to INJECT_SUCCESS (i forgot to check this).
Here is the new line in the schedule file:
1163905217 H1L1 INJECT_CBC_ACTIVE 1 1.0 Inspiral/{ifo}/coherentbbh7_1126259455_{ifo}.out
Each IFO will need to be in observation intent mode for the injection to go through.
The injections were injected. The section of the INJ_TRANS log that covers the injection is in the attached text file.
End-to-end test:
Hardware injection was successfully performed on H1 and L1 at the same time at around 03:00:07 UTC, analysis pipelines picked it up and we heard multiple audible alarms.
Operator went through site response (L1500117) and acknowledged alarms as they came in. I and fellows got on teamspeak EM channel with EM and detchar representatives.
Also see LLO alog: https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=29750
J. Kissel for S. Karki I've moved the roaming calibration line to its highest frequency we intend to go, and it's also the last super-long duration we need. We may run through the lower frequency points again, given that (a) they need much less data, and (b) those data points were taken at various input powers that will likely confuse/complicate the analysis. Below is the current schedule status. Current Schedule Status: Frequency Planned Amplitude Planned Duration Actual Amplitude Start Time Stop Time Achieved Duration (Hz) (ct) (hh:mm) (ct) (UTC) (UTC) (hh:mm) --------------------------------------------------------------------------------------------------------------------------------------------------------- 1001.3 35k 02:00 39322.0 Nov 11 2016 21:37:50 UTC Nov 12 2016 03:28:21 UTC ~several hours @ 25 W 1501.3 35k 02:00 39322.0 Oct 24 2016 15:26:57 UTC Oct 31 2016 15:44:29 UTC ~week @ 25 W 2001.3 35k 02:00 39322.0 Oct 17 2016 21:22:03 UTC Oct 24 2016 15:26:57 UTC several days (at both 50W and 25 W) 2501.3 35k 05:00 39322.0 Oct 12 2016 03:20:41 UTC Oct 17 2016 21:22:03 UTC days @ 50 W 3001.3 35k 05:00 39322.0 Oct 06 2016 18:39:26 UTC Oct 12 2016 03:20:41 UTC days @ 50 W 3501.3 35k 05:00 39322.0 Jul 06 2016 18:56:13 UTC Oct 06 2016 18:39:26 UTC months @ 50 W 4001.3 40k 10:00 39322.0 Nov 12 2016 03:28:21 UTC Nov 16 2016 22:17:29 UTC days @ 30 W (see LHO aLOG 31546 for caveats) 4301.3 40k 10:00 39322.0 Nov 16 2016 22:17:29 UTC Nov 18 2016 17:08:49 UTC days @ 30 W 4501.3 40k 10:00 39322.0 Nov 18 2016 17:08:49 UTC Nov 20 2016 16:54:32 UTC days @ 30 W (see LHO aLOG 31610 for caveats) 4801.3 40k 10:00 39222.0 Nov 20 2016 16:54:32 UTC Nov 22 2016 23:56:06 UTC days @ 30 W 5001.3 40k 10:00 39222.0 Nov 22 2016 23:56:06 UTC
Before the HW injection test, we turned off this line (before entering observation intent). I turned it back on at Nov 23 2016 03:25 UTC, but this did not drop us out of observation intent.
This line was again turned off at 4:12 Nov 23 2016 UTC so that DetChar safety study can be made late tonight.
The analysis of sensing function at frequency above 1 kHz obtained from the roaming lines listed in the alog above is attached. These lines were run at different times than the low frequency sweep (below 1 kHz) taken on Nov 18 and included in this plot. So, the lines above 1 kHz will need to be compensated for the time varying parameters to make accurate comparison and has not been done for this plot.
One way of compensating the changes are by applying kappas calculated using the SLM Tool (or GDS). The other way of doing it is comparing each individual line with 1083.7 Hz (which is always on) line at time t (time at which each line is running) and time t0 (time of low freqeuncy sweep).
Sensing Function [ct] /[m] = (DARM_ERRR/TxPD) f= hf, t * (TxPD/DARM_ERR) f = 1083.7, t * (DARM_ERRR/TxPD) f= 1083.7, t0
Both methods are essentially same but I will use the second method and the plot with the correct compensation applied to come soon.
Jeff K, Kiwamu I, Darkhan T,
Overview
The CAL-CS EPICS records for tracking temporal variations of the DARM parameters have been updated at 2016-11-21 22:03:46 UTC. These values are identical to the ones in LHO alog 31677 from yesterday, i.e. D20161120_H1_CAL_EPICS_VALUES.m and D20161121_H1_CAL_EPICS_VALUES.m are identical.
New values have been accepted in SDF_OVERVIEW.
Details
Following DARM paramemter files were used to calculate these values:
${CalSVN}/Runs/ER10/Common/params/IFOindepParams.conf r3752
${CalSVN}/Runs/ER10/H1/params/H1params.conf r3826
${CalSVN}/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf r3786
And the DARM model scripts from
${CalSVN}/Runs/O2/DARMmodel/* r3814
The *.m file with EP1-9 values and the verbose output are attached to this report. All of the files have been committed to CalSVN at
ER10/H1/Scripts/CAL_EPICS/
D20161121_H1_CAL_EPICS_VALUES.m
20161121_H1_CAL_EPICS_VALUES.txt
20161121_H1_CAL_EPICS_verbose.log
Shivaraj K, Jeffrey K, Aaron V, Darkhan T,
Updated DARM time-dependence EPICS
We have updated the EPICS values used for DARM time-dependent parameter calculations (DCC T1500377). We added a previously (Nov 21) missing delay in the DARM_ERR signal due to one computational cycle delay, comes from the fact that the signal is transferred from the OMC front-end model to CAL-CS. The *.m file with EP1-9 values and the verbose log are attached to this alog.
The new values were updated in the front-end and were accepted in SDF_OVERVIEW.
Location in the SVN:
${CalSVN}/Runs/ER10/H1/Scripts/CAL_EPICS/
D20161122_H1_CAL_EPICS_VALUES.m
20161122_H1_CAL_EPICS_verbose.log
20161122_H1_CAL_EPICS_VALUES.txt
Corrections to be applied to the channels in GDS and SLM (CalMon) when calculating "kappas"
All of the necessary corrections, except for Pcal RX PD channel corrections have been incorporated in the EPICS values, i.e. when calculating kappas with the method from T1500377, except for the Pcal Rx PD the rest of the channels must be used without applying any additional corrections. The Pcal RX PD channels from the frames must be corrected for the freq. dep. part of the free mass response (two poles at 1 Hz), analog AI, digital AI (IOP) and the time delay of the CAL-EY channels w.r.t. [V] from the PD (this piece was measured to be zero). One of the ways to get the correction TF is to extract it from the Matlab DARM model, an example of extracing this correction TF for Hanford can be found at (the resulting TF is attached):
${CalSVN}/Runs/ER10/H1/Scripts/PCAL/examplePcalCorrExtraction.m
LLO analog AA/AI models have been updated for ER10/O2, while at LHO they did not change since the O1 run. So it is important to calculate the site-specific Pcal corrections using the most up-to-date DARM reference-time parameters.
Corrections to be applied to the CAL-CS demodulators
Since "kappa" calculations in CAL-CS are not done using the Pcal Rx PD channels written into frames, but rather with the PCALY_RX_PD signal that gets transmitted from the CALEY model to CAL-CS, the Pcal Rx PD data seen by CAL-CS has an additional one computational cycle delay. This means that the phases and amplitudes in the front-end demodulators must be adjusted with PcallCorr * (one_cycle_advance_phase).
Pcal calibration line demodulator phases have been adjusted in the CAL-CS front-end model.
PCAL_LINE1 (36.7 Hz line) demodulator phase was set to -1.87 deg (old value was -2.40 deg)
PCAL_LINE2 (331.9 Hz line) demodulator phase was set to -16.95 deg (old value was -19.9 deg)
The phases were calculated according to the instructions given above and taking into account that two poles at 1 Hz (free-mass response) are applied separately in a Foton filter.
The script for calculating the phases was committed to
${CalSVN}/Runs/ER10/H1/Scripts/PCAL/getPcalCorrForCALCSdemod.m
The new values have been accepted in SDF_OVERVIEW.
After updating the phases we have got about 25 minutes of data before we lost the lock. κPU, κT, κC, in this interval were within 1% of their reference-time values (1.0) and fC was within 3% of its reference-time value (346.7 Hz).
I compared both of Pcal correction factors for LHO used by the GDS pipeline to the transfer function produced by the example script. These are computed at two line frequencies: 36.7 Hz and 331.9 Hz. As seen in the plot, they agree quite precisely. I also checked that the numerical values produced by this script at the line frequencies were identical to those used in the GDS pipeline.
The pcalcorrection factor used for SLM Tool and computed by the exapmple script are in good agreement as well.
During ER10, in case we receive ANY EM alert in Nominal Low Noise (NLN) state with the intent bit set while L1 is also running, please immediately cancel all future transient hardware injections.
Also see L1500117. Call me if necessary.