Richard called saying the laser was off when he entered the Control Room this morning.
According to the laser status screen, the laser tripped due to a crystal chiller flow rate
error, somewhere in the power meter circuit. Attached are two plots of the previous one day's
trend data.
The signal from head 2 is somewhat noisier than the signals for the 3 other heads. Looking
back even further it seems to have been that way for at least the 6 days. Unfortunately we do
not have enough diagnostics to pinpoint the location of the potential blockage and at this point
in time it is a bit of a waiting game unless time is scheduled for invasive maintenance.
After restarting the laser at ~06:30, things seem to have settled down by 06:40.
Attached is a plot of the high power oscillator's PZT voltage during the warm up time. During
the warm up, the injection locking broke lock once. Also attached is a trend plot of the PZT
voltage.
As another side note, I happened to notice that the FSS locked quite happily even though
the noise eater was off. This might be due to the reduced FAST gain.
Both shutters were open when the laser shut down.
I set up a magnetometer at EY near the ESD chassis in the VEA for a blip glitch study (see upcoming log from Paul). The plot shows the channel names (12 and 13 are the Y and Z axes) and very high coherence between the mag and DARM at odd harmonics of 1 Hz. This is one of the new combs that Ansel identified and so this channel may also be useful in seeing if it goes away during the reboots on Tuesday.
Carl, Evans, Stefan,
We had h1ecatx1 crash. A reboot didn't bring back the connection - we had to log in and manually start start.bat.
Then we ran into strange guardian behaviour, which was tracked down to epics channels having different values on h1guardian0 and operator machines.
In particular, on h1guardian0:
In [8]: ezca['ALS-Y_LOCK_ERROR_FLAG']
Out[8]: 1
while on operator 0 I get:
In [7]: ezca['ALS-Y_LOCK_ERROR_FLAG']
Out[7]: 0
Problem was with an epics gateway, which was stuck with the incorrect value. I restarted the gateway between the slowcontrols-lan and the fe-lan, guardian now connects directly to the h1ecaty1 Beckhoff IOC and is seeing the correct value.
Here is the diagnostics:
On the workstation nucws20, I did a 'caget -d 5' to return an integer value rather than the enumerated string
david.barker@nucws20: caget -d 5 H1:ALS-Y_LOCK_ERROR_FLAG
H1:ALS-Y_LOCK_ERROR_FLAG
Value: 0
Same command on h1guardian0
controls@h1guardian0:~ 0$ caget -d 5 H1:ALS-Y_LOCK_ERROR_FLAG
H1:ALS-Y_LOCK_ERROR_FLAG
Value: 1
More information can be obtained with the cainfo command
controls@h1guardian0:~ 0$ cainfo H1:ALS-Y_LOCK_ERROR_FLAG
H1:ALS-Y_LOCK_ERROR_FLAG
State: connected
Host: h1egw0.cds.ligo-wa.caltech.edu:42076
Access: read, write
Native data type: DBF_ENUM
Request type: DBR_ENUM
Element count: 1
CA.Client.Exception...............................................
Warning: "Identical process variable names on multiple servers"
Context: "Channel: "H1:ALS-Y_LOCK_ERROR_FLAG", Connecting to: h1egw0.cds.ligo-wa.caltech.edu:42076, Ignored: h1ecaty1.cds.ligo-wa.caltech.edu:5064"
Source File: ../cac.cpp line 1297
Current Time: Sat Jul 16 2016 19:56:42.065413401
..................................................................
After the errant gateway was restarted:
controls@h1guardian0:~ 0$ cainfo H1:ALS-Y_LOCK_ERROR_FLAG
H1:ALS-Y_LOCK_ERROR_FLAG
State: connected
Host: h1ecaty1.cds.ligo-wa.caltech.edu:5064
Access: read, write
Native data type: DBF_ENUM
Request type: DBR_ENUM
Element count: 1
controls@h1guardian0:~ 0$ caget -d 5 H1:ALS-Y_LOCK_ERROR_FLAG
H1:ALS-Y_LOCK_ERROR_FLAG
Value: 0
I've opened an FRS ticket for this, we should either remove having two options for guardian connection to remote IOCs or ensure only one connection is reliably used.
https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=5892
Matt, Stefan
The switching of coil drivers to low noise takes quite a long time with the current guardian code (20+ seconds per coil, with 20 coils, so over 400 seconds or about 7 minutes). This guardian state has recently been updated to make it more responsive (moved code to run, and used timer rather than sleep, see 28353), but this didn't make it any faster. I just changed the code to switch all of the optics together, rather than do them serially (see below). This should reduce the total time to ~90 seconds. The old function is still in ISC_LOCK.py as COIL_DRIVERS_SLOW.
We have not locked yet, so this code is untested.
=============================
def run(self): eul2osemTramp = 8 analogExtraSleep = 7 path = '/opt/rtcds/userapps/release/isc/h1/scripts/sus/' optics = ['PRM', 'PR2', 'SRM', 'SR2', 'BS'] # what optic? stage = ['M3', 'M3', 'M3', 'M3', 'M2'] # what stage are we switching? newState = [ 3, 3, 3, 3, 3 ] # what is our final coil state? opt_stage_state = zip(optics, stage, newState) # tuple of these coils = ['UL', 'UR', 'LL', 'LR'] coil = coils[self.coil_num] log(str(self.reset_counter)) if self.reset_counter == 0: # first step, set matrix values for opt, stg, state in opt_stage_state: log('-- Switching ' + opt + ' ' + coil) ezca.burtwb(path + opt.lower() + '_' + stg.lower() +'_out_' + coil.lower() + '.snap') time.sleep(0.1) ezca['SUS-' + opt + '_' + stg + '_EUL2OSEM_LOAD_MATRIX'] = 1 self.timer['mtrxRamp'] = eul2osemTramp self.reset_counter = 1 elif self.reset_counter == 1 and self.timer['mtrxRamp']: # second step, clear filters for opt, stg, state in opt_stage_state: ezca['SUS-' + opt + '_' + stg + '_COILOUTF_' + coil + '_RSET'] = 2 self.timer['extraSleep'] = analogExtraSleep self.reset_counter = 2 elif self.reset_counter == 2 and self.timer['extraSleep']: # third step, switch coil drivers for opt, stg, state in opt_stage_state: ezca['SUS-' + opt + '_BIO_' + stg + '_' + coil + '_STATEREQ'] = 1 # go to intermediate state time.sleep(0.1) ezca['SUS-' + opt + '_BIO_' + stg + '_' + coil + '_STATEREQ'] = state time.sleep(0.1) self.reset_counter = 3
< ... more run code ... >=============================
Matt, Stefan
In an attempt to find our missing power, we decided to look for a change in the light scattered from the TMs. The general idea was to use the camera images normalized to the input power, and see if the scattered light changed or increased faster than the arm power. (A change in scattering could indicate heating of the mirror surface by a small absorber which leads to deformation and increased scatter T1000154). This is similar to the OL test done earlier.
To investiage this and avoid camera saturation issues, I made a script to grab images of the TMs at a variety of exposure times (mexp.py). This script takes 5 snapshots of each TM with exposure times from 30 to 10000 (micro seconds?). I ran it during several power-up sequences to get images at 2W, 10W, 20W, 40W and 50W (all in /ligo/data/camera).
The accompanying matlab code loads these images and uses them to make a high dynamic range image (HDR) for each TM at each power level (see attached PNG for 40W images, and attached mat file for 2W and 40W data).
The overall conclusion is that the scattered light scales with the arm power. That is, there is no evidence of increased scatter loss at higher power.
(About the HDR image: these use a log-color scale. The ITMY scatter seems to be much larger than other optics. ITMX has a strange crecent shaped collection of scatters. The ETMs look like the usual stary night, though ETMY could use some focus adjustment.)
Quick Summary: Commissioning. Carl's working on PI, Stefan's working on PUM and RF45, and Matt's making pretty pictures. The goal tonight was to make sure ITM PI damping works. We locked at 40W for couple of hours.
- Added PUM coild driver switching to state 3 for 4 test masses into LOWNOISE_ESD_ETMY (at the end). It seems to take the transient.
- Down state switches back to state 2.
- Moved the pdList and pdSqList for the RF45 modulation depth lowering to the lscparams file.
- Updated the DOWN state to reset the gains of the PDs in pdList and pdSqList.
Optical lever sum sees the large angle scattering from the test mass it looks at (see T1600085 for details, but note that the trans impedance and whitening gain in that document are not confirmed by measurements). This is a tiny thing compared with the power of the OL beam itself, but the scattered light is visible if you subtract the background OL beam.
I looked at the time series of OL SUM for four test masses together with MC-PWR_IN_OUT16, ASC-X_TR_B_SUM_OUT16 and ASC-Y_TR_B_SUM_OUT16 between Jul 12 23:35:44 and Jul 13 1:4:44 2016 UTC.
The first attachment is the (OL SUM -background)/TRX (or TRY), rescaled such that they are 1 at 10W. I cannot see any huge increase in large angle scatter as the IFO moves to 40W for any of the test masses.
The second attachment shows you just how the raw-ish data looks like, this is after removing the OL beam offset and taking into account the whitening gain and trans impedance. There's some difference between ITMs and ETMs but note that ITM OLs are about 5 or 6 times farther away from ITMs than ETM OLs are from ETMs.
I removed the 300 Hz and 600 Hz stopband filters in DARM, along with the 950 Hz low-pass filter.
I increased the gain from 840 ct/ct to 1400 ct/ct, giving a UGF of 55 Hz. This seems to have improved the gain peaking situation around 10 Hz (see attachment).
The new settings have been added to the guardian (in the EY transition state), but have not been tested. The calibration has not been updated.
Tagging CAL Group. Evan Goetz has also been working on a better PUM roll-off. He'll be installing those improvements soon as well, and a full loop design comparison.
Since we spend a nontrivial amount of time commissioning at high powers (>20 W) with DARM controlled by EX, I moved the DARM gain increase so that it comes on once the PSL power reaches 20 W.
repost, somehow the original was erased during edit testing
The DAQ test stand timing components which includes the timing fanout, IRIG-B, and the powered-up I/O chassis have been reprogrammed to a version of the firmware which eliminates flahsing of LEDs when the components are sync'ed.
The wind direction part of the anemometers still seems to not be reading correctly. There was some discussion on the SEI call today that maybe it had started working, but a look at the DetChar page at https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20160714/pem/wind/ shows good info for wind speed, but nothing sensible for wind direction. I put some data into the SEI log about wind direction as seen at the Tri-cities airport. https://alog.ligo-la.caltech.edu/SEI/index.php?callRep=1035 The FAA and Jim agree that strong winds come from the southwest.
Speaking as an ex hang glider I don't think we will get reliable wind measurements unless the sensors are placed well above the buildings. Here is a quote from the World Meteorlogical Organization;
https://www.wmo.int/pages/prog/www/IMOP/publications/CIMO-Guide/Prelim-2014Ed/Prelim2014Ed_P-I_Ch-5.pdf
John W. is right that the wind direction at our roof weather stations is not what it would be on a weather mast far above land topography. The wind affecting the buildings is funneled by the buildings themselves as well as by the berms and other topography around them. Since we care more about the direction of the wind that is flowing over and around the buildings, than we do about the direction at altitude, I have not pushed to build weather masts as was done at LLO, but, of course, this means that the sensors do not read what masts read. Mast wind directions are available from Hanford weather services (http://www.hanford.gov/page.cfm/HMS/RealTimeMetData), station 9 is closest to the corner station and station 1 is closest to EY. But I think you have to contact them to get historical data.
To reflect that our roof weather station direction sensors are very local sensors and do not report what meteorologists think of as wind direction, for aLIGO we started using our own X, Y coordinates:
Wind travelling in +X direction (from corner station towards X end): 0 (degrees)
Wind travelling in the +Y direction (from the corner station toward EY): 270
Wind travelling in the -Y direction, EY to CS (approx. direction of typical storm): 90
Wind travelling in the -X direction, EX to CS (the other most common storm direction): 180
That being said, the wind direction system has not yet been installed. This is because all sensors were broken by the beginning of aLIGO, long past their life span. Paul Schale and I installed a new direction sensor at EX in summer of 2014 for BRS studies. I looked back at the data, and for some reason it starts in April of 2015, but from then on the data is good. The channel is: H1:PEM-EX_WIND_WEATHER_DEG. I just now went up on the roof and made sure that it was still functioning with directions as given above. However, even this new sensor has problems typical of the Davis system: it sometimes produces huge values, I believe when the brushes loose contact around 0 degrees.
Let me say that for most studies, I am inclined to use proxies that are closer to what we care about than wind direction at one particular location on the roof. Thus for studies of how the BRS performs under different wind tilt conditions, such as dominant tilt direction, I suggest using the 0.03 to 0.08 Hz seismic band of uncorrected seismometers. This gives both tilt axes so that the performance can be compared when most of the tilt is in the Y direction or in the X direction (we only have real tilt sensors (BRS) at EX and EY for the beam axis direction, hence the need for a proxy). Of course earthquake spikes must be filtered out. This is how Dipongkar did his year long study of tilt behavior (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=17574, https://wiki.ligo.org/viewauth/DetChar/WindInducedTilt). Included in this study are plots showing how well this seismometer band correlates with the tilt as measured by the BRS.
For the person installing the new anemometer/wind direction sensors (Hugh is considering taking this big job on), in order to get the direction system above, align the bar in the Y-direction with the anemometer towards Rattlesnake mountain. Use a CDS laptop displaying the weather screens for fine adjustment.
Robert
We are hoping to have the the units replaced in time for O2. This will be the 3rd exchange on 2 buildings and the 4th on the rest.
Kiwamu, Stefan
Using the pr2spotmove script (see alog 28420), we moved the spot on PR2 in lock by almost 1 milimeter.
Conclusions:
- The carrier recycling gain desn't care about the PR2 spot positon.
- The POP beam from PR2 to the invacuum POP diode is fairly close to the edge of the visibility aperture. This might be an issue for LSC aux noise.
Details:
- To be able to explore the full range of motion, we had to switch back to the REFL B WFS for PRC2 / PR3 control. We BTW verified that this WFS also works at 40W (and during the power increase).
- With that, the move-limiting aperture is the path from PR2 to POP. We can move until the POP_A loses the beam. The pitch and yaw min/nominal/max values for PR3 alignment angles are
Pitch value / delta:
min: -302.95 / -4.6urad
nom: -298.35 / 0urad
max: -275.35 / +23urad
Yaw value / delta:
min: 257.45 / -16urad
nom: 273.45 / 0urad
max: 281.45 / +8urad
Notice how close to the edge we are in pitch - this could be a factor for PRCL/SRCL/MICH auxiliary length noise and scatter coupling. We have to revisit this in low-noise.
- The 27.6urad move in pitch (24urad in yaw) peak-to-peak move corresponds to 0.9mm (0.8 mm) for the PR2 spot position. Note though that for the beam in transmission of PR2 that corresponds to several spot sizes of motion. (The virtual beam waist behind PR2 is 114u, i.e. we moved the spot more than 7 beam waists. As a result the beam completly left the POPAIR camera view.)
Here is the theoretical matrix for this move (note that signs will vary for pitch and yaw):
PR2/PR3=-9.041812537326308*t3;
PRM/PR3=1.824484077268346*t3;
IM4/PR3=0.964764706304192*t3;
This was calculated with the following data (in meters):
RPRM=-11;
RPR2=-4.555;
RPR3=36.0;
RITM=1939;
LPRM=16.6128;
LPR2=16.1551;
LPR3=24.88797;
LARM=3994.5;
LIM4=0.413;
LIM3=1.17;
n=1.45;
f=-RITM/(n-1); # thin lens approximation
fm=-RPRM/(n-1); # thin lens approximation