edmond.merilh@LIGO.ORG - posted 10:47, Wednesday 23 November 2016 (31779)
NLN - manually from NOISE_TUNINGS
18:45UTC
18:45UTC
SEI - Working on getting seismon running. Everything else is ok at this time.
SUS - didn't get charge measurement on Tue. Will try to get this week. FIlter fix, fixed the ITMY issue. SDF updated. (re: causing 20 minute ringdown after locklosses)
CDS electronics - reverted NDS2 software client back to previous version, agaon. Should hold us through 02.
PSL - nothing
VAC - wants to do BSC experiment in corner station. Maybe start bake of PT180
CDS - ane installed and seems to be functional, again. PEM work in vault.
Hardware detection test was done last night successfully. things that did not work: people could not log onto LDAS.LIGO.WA mostly successful mat do it again before '02. In the future, in the case of an alert, immediately stop any injections
Keita wil be investigating unused ADC channels at End Stations
REMINDER - to be cautious around siesmometers when doing maintenance work. (i.e. infrasound mic incident)
18:16 UTC lockloss at CLOSE_BEAM_DIVERTERS. This also tripped HAM 6 ISI. Going to stop at NOISE_TUNINGS and perhaps move manually to NLN?
Here's the transition summary a little late.
Frequently I find that SRC will not lock properly. I then misalign SRM and look at the spot centering on te ASC_QPD to check the alignment of SR2. Usually I find that it's been driven off diagonally in one direction or the other making it difficult for the loops to align and converge SRM into the cavity. After re-centering I will re-align SRM and re-request SRC_ALIGN and it should lock and converge properly. Maybe some hand alignment will be necessary.
Not sure why sequence stuck at FIND_IR. X-arm power not reaching maximum potential. I re-centered as per oplevs because I noticed that after the las op lev align the ITM and ETM seemed a bit off-axis in it's alignment. I got the power back to acceptable range and tweaked TMS a µrad or two and letting WFS 'cook' for a while. Curious as to why there was 'FIND_IR" levels of IR in X arm while doing ALS align?
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
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.
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
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.
Just a minor note---the QPD one looks at is the AS_C QPD. (i.e. Anti-Symmetric port "C" QPD & not the ASC QPD).