I reset the dark offsets for all LSC and ASC PDs. The ASC diodes already had scripts in ..../userapps/asc/common/scripts/dark_offset/, so I copied the style of those into an LSC script that now lives in ..../userapps/isc/common/scripts/dark_offset/.
I also created a bash script that will call each of those scripts in succession - it's natively in the isc folder, but linked in the asc folder: all_offsets_LSCandASC.
Looks like a number of seismometers are out of shape, especially the corner station ground STS, 6 volts seems pretty bad relative to the 2 volt spec.
Averaging Mass Centering channels for 10 [sec] ...
2017-01-03 12:04:38.352808
There are 2 STS proof masses out of range ( > 2.0 [V] )!
STS B DOF Y/V = -6.441 [V]
STS B DOF Z/W = 4.384 [V]
All other proof masses are within range ( < 2.0 [V] ):
STS A DOF X/U = -0.486 [V]
STS A DOF Y/V = 0.035 [V]
STS A DOF Z/W = -0.568 [V]
STS B DOF X/U = 0.986 [V]
STS C DOF X/U = -0.0 [V]
STS C DOF Y/V = -0.0 [V]
STS C DOF Z/W = -0.0 [V]
STS EX DOF X/U = -0.089 [V]
STS EX DOF Y/V = 0.557 [V]
STS EX DOF Z/W = 0.126 [V]
STS EY DOF X/U = 0.168 [V]
STS EY DOF Y/V = 0.084 [V]
STS EY DOF Z/W = 0.464 [V]
Assessment complete.
jim.warner@opsws0:~ 0$ t240_center
Averaging Mass Centering channels for 10 [sec] ...
2017-01-03 12:16:41.356637
There are 12 T240 proof masses out of range ( > 0.3 [V] )!
ETMY T240 3 DOF Z/W = 0.405 [V]
ITMX T240 1 DOF X/U = -0.589 [V]
ITMX T240 1 DOF Y/V = 0.355 [V]
ITMX T240 1 DOF Z/W = 0.31 [V]
ITMX T240 2 DOF X/U = 0.346 [V]
ITMX T240 2 DOF Y/V = 0.35 [V]
ITMX T240 2 DOF Z/W = 0.358 [V]
ITMX T240 3 DOF X/U = -0.573 [V]
ITMY T240 2 DOF Z/W = 0.306 [V]
ITMY T240 3 DOF Z/W = -1.025 [V]
BS T240 1 DOF Z/W = 0.423 [V]
BS T240 2 DOF Y/V = 0.393 [V]
All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 1 DOF X/U = 0.136 [V]
ETMX T240 1 DOF Y/V = 0.099 [V]
ETMX T240 1 DOF Z/W = 0.157 [V]
ETMX T240 2 DOF X/U = -0.137 [V]
ETMX T240 2 DOF Y/V = -0.252 [V]
ETMX T240 2 DOF Z/W = 0.039 [V]
ETMX T240 3 DOF X/U = 0.091 [V]
ETMX T240 3 DOF Y/V = 0.075 [V]
ETMX T240 3 DOF Z/W = 0.085 [V]
ETMY T240 1 DOF X/U = 0.046 [V]
ETMY T240 1 DOF Y/V = -0.065 [V]
ETMY T240 1 DOF Z/W = -0.099 [V]
ETMY T240 2 DOF X/U = 0.256 [V]
ETMY T240 2 DOF Y/V = -0.135 [V]
ETMY T240 2 DOF Z/W = 0.038 [V]
ETMY T240 3 DOF X/U = -0.108 [V]
ETMY T240 3 DOF Y/V = 0.049 [V]
ITMX T240 3 DOF Y/V = 0.281 [V]
ITMX T240 3 DOF Z/W = 0.262 [V]
ITMY T240 1 DOF X/U = 0.228 [V]
ITMY T240 1 DOF Y/V = 0.153 [V]
ITMY T240 1 DOF Z/W = 0.19 [V]
ITMY T240 2 DOF X/U = 0.092 [V]
ITMY T240 2 DOF Y/V = 0.272 [V]
ITMY T240 3 DOF X/U = -0.111 [V]
ITMY T240 3 DOF Y/V = 0.265 [V]
BS T240 1 DOF X/U = 0.031 [V]
BS T240 1 DOF Y/V = 0.13 [V]
BS T240 2 DOF X/U = 0.231 [V]
BS T240 2 DOF Z/W = 0.218 [V]
BS T240 3 DOF X/U = 0.253 [V]
BS T240 3 DOF Y/V = 0.073 [V]
BS T240 3 DOF Z/W = 0.092 [V]
Assessment complete.
[Evan G, Alex U, Aaron V] I have produced new filters for Hanford that incorporate the correction Evan made to the Pcal to DARM transfer function. (see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=32907) The filters can be found in the calibration SVN at this location: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/GDSFilters/H1GDS_1167485844.npz The filters were produced using this Matlab script in SVN revision 4029: ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/TDfilters/H1_run_td_filters_1167485844.m The parameters files used (all in revision 4029) were: ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/Common/params/IFOindepParams.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/H1params.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/params/H1_TDparams_1167485844.conf ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Scripts/CAL_EPICS/D20161122_H1_CAL_EPICS_VALUES.m The first two plots (png files) are spectrum comparisons between CALCS and GDS. All the same options were used that are currently being used on the online calibration, including application of time-dependent corrections. The last pdf file shows kappas computed by SLM, GDS, and CALCS. It appears that Evan's correction has resolved the discrepancy we were seeing in kappa_tst and kappa_pu between GDS and CALCS. Compare the data from the summary pages from the same time period: https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20161207/cal/time_varying_factors/ However, SLM tool data does not agree at this time.
The gpstime package leap seconds data base file was out of date, and user/group owned by a non-controls account. Updated the file and changed permissions on the gpstime directory to allow updates.
J. Oberling, P. King (from Pasadena)
Checked on the PSL this morning, all was fine except we lost ~10 W of power over the break (before the break we were at ~160 W, this morning we were at ~150 W) and the NPRO noise eater needed to be reset. Everything looked as expected, so the power loss is most likely due to natural decay of the HPO pump diodes. I increased the HPO diode currents to recover our lost power; the currents were changed from 50.5 A to 51.0 A for each HPO diode box. I then tweaked the pump diode temperatures, see the table below for a summary of the changes (remember that each HPO diode box has 7 individual laser diodes). The PSL is now outputting ~166.5 W from the HPO box itself (the internal power reading is ~212 W).
|
|
Diode Box 1 | Diode Box 2 | Diode Box 3 | Diode Box 4 | ||||
| Old | New | Old | New | Old | New | Old | New | |
| D1 | 26.0 | 25.5 | 20.5 | 20.0 | 22.5 | 22.0 | 25.0 | 24.5 |
| D2 | 26.5 | 26.0 | 20.0 | 19.5 | 26.5 | 26.0 | 22.5 | 22.0 |
| D3 | 28.5 | 28.0 | 21.0 | 20.5 | 26.5 | 26.0 | 24.0 | 23.5 |
| D4 | 25.0 | 24.5 | 19.0 | 18.5 | 23.5 | 23.0 | 22.5 | 22.0 |
| D5 | 27.0 | 26.5 | 19.0 | 18.5 | 27.5 | 27.0 | 24.5 | 24.0 |
| D6 | 26.5 | 26.0 | 19.5 | 19.0 | 22.0 | 21.5 | 24.5 | 24.0 |
| D7 | 24.0 | 23.5 | 20.0 | 19.5 | 23.0 | 22.5 | 24.5 | 24.0 |
With the ISS off this gives 80 W incident on the PMC, which is the desired incident power for the PMC; the PMC was outputting ~65 W. I then did a quick tweak of the beam alignment into the PMC, only tweaking the horizontal alignment (vertical looked fine), which improved the PMC transmitted power to ~67 W (ISS still off). With the ISS turned back on the PMC is outputting 64.7 W, which is where it was set at the start of O2. Also with the ISS on, the FSS RefCav TPD is reading ~3.6 V, so no adjustment is necessary there. The H1 PSL is ready for the resumption of O2.
Laser Status:
SysStat is good
Front End Power is 34.18W (should be around 30 W)
Front End Watch is GREEN
HPO Watch is GREEN
PMC:
It has been locked 0.0 days, 20.0 hr 28.0 minutes (should be days/weeks)
Reflected power is 13.29Watts and PowerSum = 80.42Watts.
---->There is a note that this PMC Reflected power is high, but that was for O1 (for O2 we are fine).
FSS:
It has been locked for 0.0 days 1.0 hr and 5.0 min (should be days/weeks)
TPD[V] = 3.673V (min 0.9V)
ISS:
The diffracted power is around 2.6% (should be 3-5%)
Last saturation event was 0.0 days 0.0 hours and 0.0 minutes ago (should be days/weeks)
THis closes FAMIS 7419.
HAM2 Yaw is now off-scale around -30 (but don't think Jason wants to monitor this anymore...so perhaps it should be removed from procedures/templates/scripts?).
Everything else looked fine.
This closes FAMIS 4708.
J. Kissel I've restored PCALX and PCALY's excitations (including calibration lines on Y and CW hardware injections on X) from the shut down. All systems are go, OFS looks stable.
J. Kissel ALS Fiber PLL's rejected/wrong polarization looks nice and low. The wrong polarization has swung up and down over the past 6 days, but never over ~20%. This is expected since the long-term drift is not controlled, and temperatures of the site have been dynamic. Currently hovering at a very acceptable ~7 / 4 % for X / Y, respectively. Trend attached.
J. Oberling, C. Gray, J. Kissel Ran through a cursory check of the TCS system: - TCS lasers look healthy, transmitted power applied to the ITMs looks stable over 6 day trend - DIAG_MAIN reports no problems with TCS chillers - Ring heaters all cooking at their nominal power - HWS X Code has stopped running (but this has been under development, and unfortunately expected)
J. Kissel, C. Gray We've used the chamber managers to bring all SEI systems back to nominal -- HAMs to ISOLATED, ITMs and ETMs to FULLY_ISOLATED, and BS to ISOLATED_DAMPED. Before turning on sensor correction, I checked that the end-station BRS signals looked sane, and they do. BRS X damping is still OFF, but the amplitude of the raw tilt signal looks within +/- 100 [ct], which is acceptable. Once isolated, I used the ISI_CONFIG manager to bring all platforms to their respective WINDY configuration, as per nominal. All chambers are now running smoothly as expected, with there BLRMS blinky-light matrices almost entire green, with a little yellow sprinkled here and there (again, as expected).
J. Kissel, J. Warner
BRS X Damping restored. This is doable remotely, by requesting
caput H1:ISI-GND_BRS_ETMX_USER 1
this changes the displace of this channel on the BRS overview screen from "DISABLED" to "ENABLED." However, if the rotational velocity of the BRS X signal (H1:ISI-GND_BRS_ETMX_VEL) is within +/- 800 [ct] [as is the case currently], the damping will not turn on, and the status bit (H1:ISI-GND_BRS_ETMX_DAMPBIT) will continue to report that damping is OFF.
J. Kissel, B. Gateley As we begin to bring things back up today, following the restart checklist from the OPS Wiki, I've taken a trend of the past 6 days of VEA temperatures. All looks pretty stable, within 1 [deg C] over the course of the trend. Attached are trends in [deg C] and [deg F] for the relavent channels. One thing to note: the entire LVEA average channels, H0:FMC-LVEA_AVTEMP_DEGC H0:FMC-LVEA_AVTEMP_DEGF shows a significant drop (see last attachment), because it's an average of *all* LVEA temperature zones, including the H2 PSL area, which has indeed dropped by ~1-2 [deg C] in the past few days. However, Bubba took a look at the metrics on the FMP windowes machine, and suggests all looks as well as he expected. We both don't know which zones are averaged in either system, so we think that the zones near the H1 PSL (Zone 5), BSC 1,2,3 (Zone 1A), and in the output arm (Zone 4) are better metrics for H1 (and correspond better to the FMP system's channels), H0:FMC-CS_LVEA_ZONE5_DEGC (or DEGF) H0:FMC-CS_LVEA_ZONE1A_DEGC (or DEGF) H0:FMC-CS_LVEA_ZONE4_DEGC (or DEGF)
TITLE: 01/03 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
Summary: Calibration measurements utilizing Pcal to DARM transfer functions can be impacted by non-unity gain when making corrections for the modeled frequency response of the AA filtering. At LHO, the ER10/O2 model had an analog AA transfer function with non-unity gain based on the LTI measurements from ER8 (at LLO, the LTI model for ER10/O2 was normalized to 1). The analog AA model at LHO has a gain of ~0.99. Below we detail the impact on sensing function and actuation coefficients. In summary, the sensing function gain is ~1% larger than originally modeled, and the actuation coefficients are ~1% smaller. This would imply that the inspiral range is ~1% higher than currently predicted. This new understanding means that the analysis code needs to be re-run for the optical response parameters and actuation coefficients. The front-end calibration will need to be updated, and, finally, the GDS pipeline needs new filters generated and installed. Details: The calibration of the Pcal channels (ex: H1:CAL-PCALX_RX_PD_DQ) determines the watts reflecting from the ETM per count of the channel at DC. Whatever gain of the analog AA, this is already accounted for in this calibration procedure. This gain is implicitly accounted for when the value of the calibration is installed in the front-end filter module. A Pcal to DARM transfer function was previously understood as follows (note that PD calib., susnorm, m/N coeff are taken care of in the front end and (1+G)*(1/f^2) are taken care of in analyzing the measurements): DARM (IFO opt. resp.) (OMC DCPD TF) (AA(a) freq. resp.) (AA(a) gain) (AA(d) TF) ---- = ---------------------------------------------------------------------------------------------- PCAL (PD calib.) (AA(a) freq. resp.) (AA(a) gain) (AA(d) TF) (susnorm) (m/N coeff.) (1 + G) (1/f^2) where AA(a) is the analog AA, AA(d) is the digital AA, and "freq. resp." means the normalized transfer function, and G is the open loop gain. In the above (incorrect) understanding, the AA(a) and AA(d) terms cancel. The reason this is incorrect is that the AA(a) gain has an inverse in the PD calibration factor. So the real (correct) Pcal to DARM transfer function is: DARM (IFO opt. resp.) (OMC DCPD TF) (AA(a) freq. resp.) (AA(a) gain) (AA(d) TF) ---- = --------------------------------------------------------------------------------- . PCAL (PD calib.) (AA(a) freq. resp.) (AA(d) TF) (susnorm) (m/N coeff.) (1 + G) (1/f^2) Thus, to isolate the IFO optical response, we need to divide out the modeled AA(a) gain. Since the gain is ~0.99, then the gain of the optical response should go up by ~1%. The above equations are laid out in a graphical subway map schematic in G1501518-v14. The actuation coefficients will also be impacted by this, although the coefficients will be multiplied by the AA(a) gain so that the overall DARM OLG remains unchanged. I have pushed the changes to the DARM model code and scripts that account for this. Specifically: computeSensing.m (r4025) create_partial_td_filters.m (r4026) create_full_td_filters.m (r4027) fitDataToC_20161116.m (r4028). Re-running analysis of optical response parameters requires re-running the fitDataToC_20161116.m script first (with printing data to file), then running the fitCTF_mcmc.m script. Re-running analysis of actuator coefficients requires re-running actuatorCoefficients_Npct.m (with printing data to file), then re-running fitActCoefs_Npct.m. Hopefully this takes care of everything. Unfortunately, I cannot verify these changes with Matlab because I have no way of running Matlab offsite (need a network license). :(
For reference to the full paths, these files live at:
{CALSVN}/trunk/Runs/O2/DARMmodel/src/computeSensing.m
{CALSVN}/trunk/Runs/O2/TDfilter/create_partial_td_filters.m
{CALSVN}/trunk/Runs/O2/TDfilter/create_full_td_filters.m
{CALSVN}/trunk/Runs/ER10/H1/Scripts/PCAL/fitDataToC_20161116.m
{CALSVN}/trunk/Runs/ER10/H1/Scripts/PCAL/fitCTF_mcmc.m
{CALSVN}/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/actuatorCoefficients_Npct.m
{CALSVN}/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/fitActCoefs_Npct.m
1530 - hrs. local -> Kyle on site for daily inspection Found main entrance to OSB not locked -> I locked it. Noticed snow completely covering/blocking solar panels which charge the BT ion pump gauge batteries -> Took no action but lamented not not opting for the 24/7 diesel generators ;). Manually overfilled CP3 and CP4 (I have a problem - I know that now). Noticed that the red lamp which indicates the presence of 120VAC at the VPW outside water storage tank (DI water storage?) was not illuminated -> I investigated and confirmed that 120VAC was not present at the local heat trace thermistor? RTD? box(es). Also noticed that the GFCI receptacle which is on the same circuit and is used to supply trace heat to the line from the tank to the building penetration was tripped -> I reset it but the red lamp did not come on -> I measured 120VAC the GFCI receptacle after resetting it but still no red lamp. I opted not to start the WP process tonight but texted Bubba. Noticed vacuum gauge alarms still waiting for acknowledgment on the Operator's alarm computer but these are stale and left over from the PT-343 and PT-310 issues of a few days ago. Just took a call in the CR from Terry G. asking me to send out an LHO-all email that Hanford has announced a 2 hour delay to tomorrow's start of work day -> I'll send out an email now. 1915 hours local -> Kyle leaving site now
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 26 seconds. LLCV set back to 16.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 82 seconds. LLCV set back to 35.0% open.
I did not get the text message at the start of today's fill
Doh! Today I learned what that message on my cell phone meant - "Airplane Mode"! Wow! I had lots of messages, including the this one!
TITLE: 11/17 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Travis
SHIFT SUMMARY:
Shift started with Alignment work, then ASC work.
LOG:
To Do:
Run Sheila's ASC measurement (30min) after we are locked for atleast a couple hours.
Initial Alignment Notes:
INPUT_ALIGN: Xarm IR flashes were up to 0.6, but it wouldn't lock. Tweaked on IM4 & PR2 a bit while looking at Xarm & ASAIR video, but didn't get anywhere. Also doubled & quadrupled XARM gain to no avail. Sheila did some work on filters and quadrupled gain and then this seemed to do the trick.
MICH_DARK_LOCKED: The spot did not look dark (saturated) and look really misaligned. Took it DOWN a few times. Sheila noticed that the exposure was high. After lowering it, had a spot to work with...but it still looked different from previous alignments. Moved on after centering.
SRC_ALIGN: Looked misaligned here. Took it DOWN a few times. Sheila showed me how to fix alignment by misaligning SRM & using SR2 to center the beam on the AS_C Photodetector. This did the trick & then went back to locking.
For the SRC_ALIGN Locking note above, just wanted to mention that ALIGN_IFO was set to DOWN & then SRM MISALIGNED to center SR3.
For last lock, and the one that Ed just got, we've had SDF diffs due to not rounding in one of the pre-existing dark offset scripts (the one that does the end station QPDs). The diffs were of the order 1e-16, so were just accepted so that we can Observe. I have modified (although not run, since we just locked) the script such that we have rounding. This should prevent the problem in the future. Next time we lose lock and I'm around, I'll try to remember to hand-round those values so that we don't keep getting non-useful SDF diffs.
Also, Ed might write about this in his shift summary, but it seems like the ASAIR_LF offset was set a little wrong. Sheila and Ed took the IMC to offline and hand-set that offset, and we were able to get through the PRX_Locked state of initial alignment. (The wrong dark offset was causing the output to not meet the guardian's threshold of whether the cavity was locked or not, even though it was locked).