J. Kissel, S. Dwyer, D. Barker, J. Driggers, E. Hall Some of the way through recovery (there will be a LONG aLOG to come; we're not yet fully covered), but we changed some hardware and the source of the problem hasn't been aLOGged yet, so I wanted to get this one in there separately. Here's the story: - We get to ALS COMM and DIFF steps up the lock acquisition sequence. Part of the automated sequence is to search for the right COMM and DIFF VCO frequency for IR resonance. - This process failed, because the channels used to track the VCO frequency, H1:ALS-C_COMM_VCO_FREQUENCY and H1:ALS-C_DIFF_VCO_FREQUENCY, were dead, reading identically zero. - These channels are copies of channels produced by the timing fanout / timing comparator system, H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_1 and H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_2, which are renamed by the ALS Beckhoff code to something more human readable. - Note the "PORT_11" part of the fanout / comparator channel name. This represents the port number of the timing fanout from which the comparator gets its timing reference. The ALS Beckhoff code, which is common to both observatories, has the PORT 11 hard-coded into it's PLC to define the channel renaming. - After calling Dave, we found out that the timing comparator's reference signal had been moved from port 11 (12 on the front panel of the chassis) to port 15 (16 on the front panel) when the new 9.1 MHz oscillator was installed this morning. The new 9.1 MHz oscillator's reference was put in PORT 11. Because the port user changed from a comparator to a RF source, the timing fanout / comparator's channels and infrastructure totally changed, not to mention the signal that now populates those channels. - We looked at LLO's timing MEDM screens to see that unlike LHO, they've left the timing comparator plugged into PORT 11, and stacked additional RF sources beyond it, instead of what was intended this morning, which was to keep all the RF sources together, and push the comparator off to the end. Again, because this is hard-coded into the Beckhoff PLC, and changing the PLC and rebooting the Beckhoff system ALWAYS causes more problems than its worth, we elected to revert the timing cables. - We've moved the comparator's fiber back to PORT 11 (port 12 on the front panel), and put the 9.1 MHz into PORT 12 (port 13 on the front panel). - It took some clicking of theses port numbers on the MEDM screen for the comparator and the 9.1 MHz to show all green (indeed, the 9.1 MHz took a little bit longer, because the OXCO had to resync, but it had been syncing all day, so it only took ~10 seconds). - Once the comparator signal was restored, the ALS channels made sense again, and we instantly moved past that step in the lock acquisition sequence. Lesson learned? - Everything depends on something else, and every change you make to the IFO matters, even if you don't think it does. - Please aLOG everything you do. EVERYTHING. Granted, even if you had, we probably wouldn't have put two and two together until calling Dave, but still. If we've changed the 9.1 MHz frequency reference, the main RF source for locking the IFO, it should be in the aLOG.
Fil, Evan, Sheila, Patrick, Jenne, Jeff, Kiwamu (Dave on phone)
We now use the new OCXO for the interferometer controls.
Since we had a trouble reading out the frequency counter outputs, we made a quick hack on two fibers for the night.
The new OCXO was installed in the rack in the electronics room by Fil this morning. The synchronization PLL worked fine as advertised by Daniel (alog 18855). I disconnected the old IFR function generator from the main modulation path and connected the OCXO to the input of the entire chain as a new RF source. I attenuated the output of the OCXO such that it meets the standard rf level of 10 dBm at the input of the next rf device (i.e. an rf distribution amplifier). So far it seems to be behaving good -- we could fully lock the interferometer with the new OCXO. Just for a record, the mechanical switches on the front panel has been configured to 9100230 Hz. We left the old IFR mounted and powered up in the rack. Currently the OCXO box is not rigidly mounted. Fil is going to nicely mount it hopefully during the next maintenance period. The OCXO is connected to channel 12 of the corner A fan out through fiber.
We had a trouble locking ALS comm because the frequency counter was reading zero Hz. This was also true for the rest of two VCOs -- IMC VCO and ALS DIFF VCO. But, since only ALS comm needs to read out the frequency through the counter during the locking sequence, we did not realize this issue until we started attempting full lock. Jeff spoke to Dave on phone and it turned out that there is a conflict between the actual fiber assignment and the Beckoff channel assignment in the corner A fan out because we physically changed the fiber assignment today. According to Dave, the swap was only between channels 11 and 15 (correct me if I am wrong). We decided to make a hack on the hardware side rather than updating the Beckoff code for tonight. We swapped fibers of channels 11 and 15 such that the ALS and IMC VCOs can read the data out of the usual fan out channel. This solution seem to have solved the issue for now. As of now, channel 11 is connected to the timing comparator and 15 is connected to an unused 80 MHz rf source.
I wrote the script for the OPLEV charge measurements which sets most of the settings and easy-to-use. It works for ~ 2.5 hours. If you are the last person who leaving the LHO in the night - please, run it! Instructions: 1. Set ISC_Lock state to DOWN 2. Set both ETMs to "ALIGNED" state 3. Align Optical levers (pitch and yaw) for both arms to 0 +/-.5 urad 4. Run the scripts: scripts directory is /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts run the python files: ./ESD_Night_ETMX.py and the second script in another terminal: ./ESD_Night_ETMY.py If it works, it: a) In first ~ 30 seconds sets the channels and can warn about troubles with ESD or Alignment. If it happens - check this system and pressb) During the measurements it should once a second print "Receiving data for GPS second: 1234567" c) After all the measurements it should restore all the settings back. If it gives the errors but still receive some data - let it work. If it obviously not work, you can try to run it again. If it does not help - please, restore all settings running ./ESD Restore_Settings.py . Due to it is first try, today I will be very thankful if you'll check after running the scripts : 1. L3 Lock: Bias Voltage - 0 Offset - green light Ramp time - 5s 2. ESD linearization: Bypass - ON 3. For ETMY: turned on Hi-voltage driver. Just in case: scripts modify only this settings.
1. Script was updated to align the optical levers. If you did not align it - script will do it between (a) and (b), i.e. in first minutes. Measurements begin when OPLEV are aligned. 2. If you need to stop the charge measurements, there are two ways. 1.(preferable) Press 'Enter' - it will stop the script not later then in 12 minutes, when all the biases and quadrants will be done for this circle. It will restore all the settings 2. You can break it using Ctrl-C immediately but then you will need to restore ESD settings using ./ESD_Restore_Settings.py or do it manually. Using the second way you also loose and need to manually restore the optical levers offsets for ETMs. Note: Main charge measurement scripts set all the settings back to where they find it. If you break it and use ESD_Restore_settings.py - it will set all values to "standard". (!) We are talking about change the sign of ESD bias voltage on ETMX. Using ESD_Restore_settings.py will change it to today's value.
Cheryl and I installed damping on the saftey cover (see photo) which was responsible for the 300 Hz peak in DARM. I also tuned the resonance of the top mirror to take advantage of the lower level at 300 Hz. Details after we relock.
One problem that took a while to deal with as a part of IFO recovery was the lack of good .snap values for the OPTICALIGN slider values. I am told that part of this is that the values in the safe.snap files are not updated very often. In particular, they had not been updated since before some of the suspensions were mechanically realigned to center the slider values, so the computer reboots this morning put the optics in very bad places. (We had to hand-trend each slider value and type the values in.)
As a solution, I have created a new .req file that includes all of the OPTICALIGN values from the IFO_Align screen. The .req file (and the corresponding .snap file) lives in /opt/rtcds/userapps/release/sus/h1/burtfiles/OptAlignBurt.req . I have also written scripts to capture new .snap files, and restore the .snap file. The idea is that the capture script be run just before maintenence begins, and the restore script be run at the end of maintenence.
To run the capture script, in a terminal paste the following:
/opt/rtcds/userapps/release/sus/h1/scripts/CaptureOptAlignBurt.sh
To run the restore script, in a terminal paste the following:
/opt/rtcds/userapps/release/sus/h1/scripts/RestoreOptAlignBurt.sh
----------------
As a side note, the slider values for ITMX, ITMY, ETMX and ETMY have been accepted in the SDF system (made to be monitored, accepted, then un-monitored), so computer reboots should keep us closer, even if we forget to run the above scripts. We should do the same with the other major suspended optics.
Recall that we started writing the IFO ALignment slider values to an hourly burt such that we can easily grab-n-restore best alignment values - see alog 18799 from June 2.
The hourly burts are at:
/ligo/cds/lho/h1/burt/2015
under the appropriate date /h1ifoalignepics.snap
'Sorry that no one in the CR recalled this info from last month for you yesterday...
Sudarshan, Jeff K.
The ESD calibration line at 538.1 Hz is moved up to 540.5 Hz, 0.2 Hz away from the Pcal Line at Yend (540.7 Hz) to estimate the ESD actuation strength. This is a temporary arrangment and the ESD line will be moved back to its original position next week after we have some locked data to analyze. The SDF table is updated accordingly.
The ESD line is switched back to its original position at 538.1 Hz. SDF table is updated accordingly.
For SDF tables which have many items and therefore are being paged, we found that selecting the "Sort on Substring" option crashes the EPICS process with the segfault error 4. This was the cause of the restarts of h1susetmy, h1susitmy, h1susitmx, h1isiham6 and h1odcmaster this afternoon. Some of these restarts were to verify the error. Initial testing on the DTS against RCG-trunk is not showing the error. FRS ticket 3330 has been opened.
Plots of the PSL chiller 60 day trends. Most look normal, except the crystal chiller conductivity. It is getting close to the upper limit. Will need to monitor this and replace the Di filter cartridge in the future.
I can only assume that I spaced this out when I pulled the previous STS2-B out to go to the EndX last Tuesday and replaced it with the previous STS2-A unit. If anyone else actually uncovered the igloo, please let me know so I don't have to alert my doctor. So, the ITMY STS2-B unit which is not used for any SEI function, was not ideally thermally insolated from mid-morning 7 July until late morning 14 July.
All fifty (50) Accumulators were checked for charge today. No Accumulator needed charging. Only three accumulators showed a decrease in pressure since the last charge check on 21 April, see T1500280. These were small decreases (few psi) and likely reflect loss from gauge pulloff (does the uncertainy principle apply?) The acceptable range of 60-93% of operating pressure is quite broad and the lowest reading today was at 80%.
Given these results, and, the reservoir-fluid-level-indication of Accumulator charge which can be checked with the system pumping, this invasive, must have system off accumulator pressure check could be done just quarterly. As long as the weekly check of reservoir fluid levels show no decrease, the accumulators can be assumed to be adaquately charged. If a weekly check of the reservoir fluid indicates a volume loss, then the accumulators could be checked.
good to hear that the accumulators are holding well. I like your plan -Brian
Added 1962 channels. Removed 192 channels.
h1susetmy epics process died after running for a few hours, here is the dmesg output
[12094.731546] h1susetmyepics[17317]: segfault at 5a5c8c0 ip 00007f0fb70f2814 sp 00007fff81a06540 error 4 in libc-2.10.1.so[7f0fb7077000+14c000]
[12095.732645] h1susetmyepics used greatest stack depth: 2984 bytes left
Error 4 = The cause was a user-mode read resulting in no page being found (also known as null pointer dereference)
It should not be on during data taking.
Also added warnings for when the cameras and the frame grabbers are on.
I've commented out the HWS and frame grabber on warnings because we want to use them during commissioning. We should uncomment this for the science run though.
After bringing the IMC down this morning, we had trouble getting the IMC back up. The alignment was bad enough after recovering the seismic and sus that the wfs would walk out of alignment. Keita recovered the alignment by ramping the WFS gain down (on IMC_WFS_MASTER screen (under the IOO dropdown), lower left, it's nominally .1) and moving MC1 and MC2 to maximize the power on MC2_TRANS_SUM and minimize IMC_REFL_DC_OUT, while watching them in dataviewer. He then tweaked MC2 to center MC2_TRANS P and Y to near 0 (~.001) on the PD (on the IMC_CUST_OVERVIEW, top right, on the little pd graphic right of MC2). The gain on the WFS was then ramped up to some small number (I think ~.004? maybe .04) and the IMC watched to make sure it didn't go unstable. When it looked stable, the gain on the WFS was ramped back up to .1.
We wasted a bunch of time trying to retrieve earlier alignments, clearing wfs histories and moving the PZT (a strange land where pitch is yaw and yaw is pitch), before Keita decided to just do the realignment by hand.
Note that the manual alignment was done after everything was brought back to old numbers (MC1, MC2, MC3 using witness BOSEMs, PZT offset using the output of the PZT before the maintenance). Even though the PZT change was not huge (as seen in the MC REFL position), I cannot claim that the change was nothing.
Also, at first I was confused by the fact that the MC trans camera looks as if the beam is split (01 mode) even though MC is locked to 00. Kiwamu told me that the only way to make sure is to look at IFO cameras like IFO REFL and AS.
PSL FSS oscillation precluding IMC locking
It appears that FSS oscillation was wreaking havoc with the ISS and this was the cause of the IMC not locking.
Reducing the FSS Common gain to zero then bringing it back up to 26 dB stopped the oscillation, as seen on the "PZT MON (FAST)" trend display on the PSL FSS screen.
It the display shows a black region (rail to rail oscillation), then the FSS is oscillating. In the nominal state, it should just show a think black horizontal line.
The FSS was tuned up this morning and is now operating as designed ~ 500 kHz UGF, 60 deg phase margin, no features (peaks) up to 5 MHz. However, it may not be as robust against kicks from the IMC as it uses the FSS as its frequency actuator.
We did not take time this mornining to investigate the stability of the FAST/Pockels Cell crossover. I was somewhat surprised to see the FAST gain at 5 dB. It may be that the crossover is not stable.
We used to run the FAST gain at 15 dB. Seems that it was turned down to 5 dB on April 15, 2015.
Next opportunity will check the crossover by looking at the mixer monitor noise spectrum in the 1-50 kHz frequency range as we adjust the fast gain - optimize the tradeoff between FAST gain and noise peaking at the crossover.
JimW is generating a request to TJ to add an alarm for the FSS range to the Guardian.
FSS oscillation was fixed while I was tweaking the MC2 trans position. Before that, IMC locked to the correct mode but the IMC WFS ran away.
So it seems like the alignment thing was a red herring.
The FSS went into oscillation again, after talking with RIck on the phone we turned the common gain down from 26dB to 23dB.
[Matt, Jenne, Evan, Sheila] There is an enormous peak in the DARM spectrum at 4735 Hz. Shown in the DTT printout below is the IOP channel for the OMC DC PD (H1:IOP-LSC0_MADC0_TP_CH12), from 1 kHz to 25 kHz, and this 4.7 kHz peak is dominating by about 2 orders of magnitude. We wonder if this is perhaps an acoustic internal mode of one of the test masses, although we are having trouble finding a listing of such modes. Does anyone know where we can find a listing of test mass acoustic modes? Or, alternatively, does anyone have any thoughts on what this mode might be?
Sort of unsatisfying (because they're not the real deal, or their incomplete) FEA results for the test mass body modes can be found here: http://www.ligo.caltech.edu/~coyne/AL/COC/AL_COC.htm (Only for a right cylinder) and here T1400738 (only shows the modes which are likely to be parametrically unstable). A quick glance through the above doesn't show anything at or near that frequency (including abs(16384 - FEA results)). I've yet to see FEA analysis of non-test-mass optics, but I've been told that Ed Daw and/or Norna/Calum's summer students on working on it. The best I've seen on that is the ancient 2004 document for the Beam Splitter, T040232 which is where we colloquialy get the frequency of the beam splitter's butterfly mode, which was done by eyeballing the current beam splitter's parameter location Figure 2. (But, the modeled dimensions are wrong, and the wording is confusing on whether the listed frequencies are from the model with flats or not.)
It appears to be a 10th order violin mode on EY.
It is damped with a 1 Hz wide butterworth (unity gain in the passband), a +100 dB filter, and a gain of -30. No rotation needed.
Jeff
As you notes there is some data in the links you already included and we have started to fill in the blanks. Refer to https://dcc.ligo.org/T1500376-v1. When we talk I (we) can complete.
Calum
For reference, with a combination of Slawek's (T1400738) and Calum's (T1500376) FEA models, and Calum's video of the test mass internal mode shapes (T1500376), we expect to find the drumhead mode around 8029 Hz, the x-polarized butterfly mode around 5821 Hz, and the +-polarized butterfly mode around 5935 Hz (using Slawek's values for the mode frequencies). The next two modes (at 8102 Hz and 8156 Hz) do not involve distortion of the test mass face in the direction of the beamline.
Matt, Sheila, Eli
At some point today the bounce mode on EX got excited enough that we could see it in the PUM OSEMs as pitch motion. The RMS of the observed "pitch" was about 3 nrad, and the line in DARM was about 1e-13 m. Assuming that OSEM misalignent is providing the roll to observed pitch motion, and that this misalignment is of order 1 degree, the estimated roll motion was about 3e-7 rad.
This gives an order of magnitude estimate of the Roll to DARM coupling of 3e-7 m / rad.
Assuming a 10cm lever arm, this give a dimentionless coupling of 3e-6. Compared to the bounce to DARM coupling, which is order 1e-3, the roll coupling is tiny, which means that the roll motion is HUGE (since they both look about the same in DARM).
My 24 hours have passed, but the first sentence should read "At some point today the roll mode on EX..."
Suppose that the beam is at (X, Y)=R(cos(theta), sin(theta)) on the mirror where R=0 is the center of roll rotation and theta=0 is the horizontal line crossing the center. Though the COG is somewhat lower than the mirror center due to wedge, R should be more or less equal to the radial distance of the beam from the center of the mirror.
Mirror thickness at this position is
T(R, theta) ~ -R*sin(theta)*w + T0
where T0 is the thickness at the center and w is the wedge in radians that is about 0.08deg=1.4mrad for all ITMs and ETMs.
Roll changes the thickness by adding some small angle d_theta to theta: dT=-R*cos(theta)*w*d_theta=-X*w*d_theta.
When the rolling plane is in the middle of the front and the back surface, the light see the half of the total thickness change, so the roll-to-length coupling coefficient should be
length/roll ~ |dT/d_theta /2| = X*w/2
= (X/5mm) * 3.5E-6 [m/rad].
For Matt's estimate of 3E-7 m/rad to hold true, the horizontal centering should be 0.5mm or so, which is pretty good but not outrageously so.
What this probably means is that Matt's estimate about the roll angle was reasonable, as in it cannot be off by that much. A factor of something, not orders of magnitude.
[edit on Jul 15] However, if the roll plane is parallel to the local gravity, the above doesn't hold true.
In this case, w/2 is replaced by the angle between the local gravity and LIGO global vertical: 8urad for LHO EX, 639urad for EY, -619urad for IX and 12urad for IY (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14876):
length/roll(EX)~ X*8urad = (X/5mm) * 4e-8 [m/rad],
length/roll(EY)~ X*619urad = (X/5mm) * 3E-6 [m/rad].
For EX and IY, that's two orders of magnitude smaller than what I showed yesterday, though EY and IX it didn't change.
It seems that we need a suspension model to find out the actual rotation plane.