We flew the ergo arm to the south bay for Betsy. Disassembled the E module and moved to the north side of ham 4, started disassembly of the work platform that was around bsc 1 for install at bsc 2. Need to remove (with approval granted from Hugh) the horizontal hepi accuators on the south side of bsc 3 to allow installation of the work platform section between bsc 2 & 3. These will be unbolted and rolled down will still being secured with the current hepi bolts. (This same thing was done on bsc 2 for some clearance issues.) Also assisted Hugh/Eric with hepi install.
A month ago when we restarted the laser we noticed the frontend power monitor was reading only 6W. This was tracked down to a gain setting that was modified and not entered into the safe.snap file, so when we rebooted the computer frontends for the 2.6 code upgrade the incorrect gain value was entered. I've changed back to the correct setting and updated the safe.snap file, and we are now reading 31W.
[Kiwamu, Paul]
Just before the vent today we measured new noise spectra for the frequency and length feedback paths.
The 'whitening filters' in the IMC_X path (see Giacomo's LHO alog entry 5311) were not engaged. They were put in the model at LLO in an attempt to combat the digital noise in IMC_X above ~50Hz (see Anamaria's LLO alog entry 5821) but need to be taken account of when plotting the data.
We corrected the IMC_F frequency to length calibration to give the equivalent motion of MC2, instead of the equivalent round trip length change. This has now been edited in the filter bank for the IMC_X path; the FtoL filter has been changed to a DC gain of 5.8465e-14 (dX=df x lambda/(2FSR)).
Relevant paramters during the measurement:
Common mode gain 20dB
Common mode filters: Compensation and 1st Boost
Fast gain -2dB
Slow path bypassed offsets and filters
MC2 M3 lock gain -1000, engaged filters: 150:4 and CLP100
MC2 M2 lock gain 0.06, engaged filters: 0.01:0.1, 0.03:1, Stab8:2, 300:1 and ELF80
Damping filter: resg and Ellip50 (the filter in IMC_X path was switched to the wresg filter to reflect this change)
Jeff quite rightly pointed out that there are actually 2 more filter banks in the length path for the IMC which I didn't mention in the above post.
One of these is the H1:IMC_L bank, with the following 3 filters engaged and with Gain=1: antiWhite, roll3notch and bouncenotch.
The other bank is the H1:LSC-IMC bank, with 1 blank filter engaged with Gain=1. I'm not sure yet what the purpose of this bank is but would happy to know if someone else does! I'll try to get a signal flow chart up here soon, though it may be a little trickier from off-site.
I was revisiting this measurement and I thought it might be useful to add the PSL frequency noise requirement line for comparison (see attached).
The FMCS IOC needed a restart, presumably due to the failure of /ligo on Sat morning.
I burtrestored it to 2013/02/01/00:00.
I shut down the HEPAs in the ante room and in the laser room, shut down the 2 ACs (though I could not see their effect, so they could be left on) and set the makeup air at 30%. Overnight the temperature on the table increased by a couple to several degrees. The IMC was still locking, though very poorly. Paul tuned up the alignment of the IMC and the REFL_DC level returned to better than it had before the change (about 50 counts). The figure shows a comparison of IMC_F and the accelerometer at the top of the periscope in the two modes.
How much overpressure is in the PSL laser room when you run the makeup air at 30%? Do you see an effect from the makeup air at different speed? When I reduced it at LLO I did not see any difference in MC_F.
I saw 0.013" of water overpressure from the laser room to ante room.
[Adam M., Paul]
The IMC Guardian script can now be used to maintain the required state of the IMC.
This was achieved using the essentially the same scripts as in Livingston, but with some temporary local modifcations to account for the difference in the install state at the two sites (for example, ASC loops are not controlled by the guardian at LHO yet). The current state should be regarded as temporary, and if it's not required one can still of course lock the modecleaner in the way we have been doing up to now. (However, it may be useful for commissioning as we have already experienced the frustration of wondering where our signals have gone before realising the IMC was unlocked). The scripts can be found in /opt/rtcds/userapps/release/ioo/h1/scripts/imc
Some details:
Since we don't yet have a beam on MC2 trans QPD, we are using the MC_REFL_DC_OUTMON channel to verify the locked/unlocked state of the IMC. Currently, the threshold is set to 70 counts, because when aligned reasonably well the REFL_DC count is around 45. If the alignment state changes significantly, for example due to the change in PSL temperature or the upcoming vent, I recommend to lock manually first and realign to bring the locked REFL_DC counts back below 50 or so. If necessary, as an alternative the threshold can be changed in the imc_params.txt file. Of course if the laser power is changed significantly, the threshold should be adjusted.
The starting common mode gain is 0dB, which ramps up to 16dB upon lock acquisition. If there are problems to do with locking to bad modes, it may be necessary to reduce the starting gain. This can be edited on line 44 of the mcdown script. The locked gain can be edited on line 20 of the mcup script. Currently it takes two steps of 8dB from 0dB. If the starting gain is edited, this should also therefore be edited, or it could be rewritten to just make one step to the required gain.
Commencing Matlab TFs on PRM.
TFs completed apparently successfully by about 10:30 am Sunday 2/9: Undamped: ^/trunk/HSTS/H1/PRM/SAGM1/Data/2013-02-09-1044516432_H1SUSPRM_M1_0p01to50Hz_tf.mat Damped: ^/trunk/HSTS/H1/PRM/SAGM1/Data/2013-02-10-1044536209_H1SUSPRM_M1_0p01to50Hz_tf.mat Plots pending.
Totally pristine plots.
At midnight this morning the main control room NFS server suffered a scsi error and the /ligo file system went into read-only mode. This means you cannot modify or create files on the /ligo file system, which includes user home directories and the cds wiki pages. This is a known problem with this type of integrated computer and file server, and the only resource is to power cycle the machine, which cannot be performed remotely.
The immediate problem this causes is the hourly autoburt backups are not recording. I can reroute those to the h1boot file system temporarily until I can get to the site to reboot the server.
The problem occured at 4 mins past midnight, Sat 9 Feb.
cdsfs0 rebooted. File system is now available for writing. All Ubuntu workstations need to be rebooted to reconnect to the server, Mac OSX machines remount the file systems. I have restarted all the workstations in the control room.
Vincent was keen to test IPC between his new BSC2 ISI model and the BS SUS model, but the latter hadn't been created so I waded in and created it. I adapted the existing BSTST model and then compared it at the end with the L1 version - they were gratifyingly similar, except for the IPC stuff, which only exists in the H1 version so far. I got it running and updated the sitemap to point to it. I installed projection matrices, filters, and default gains and offsets, and created a safe.snap. Along the way I discovered that the SUS_CUST_BSFM_ADC_MONITOR.adl screen had been hardwired to L1, so I fixed that. I noticed a few anomalies that need further debugging: * The output fields on the SUS_CUST_BSFM_OVERVIEW.adl screen between the USER DACKILL and the IOP DACKILL (H1:FEC-31_DAC_OUTPUT_2_4 etc) are white. There's also whiteness in the H1CDSOVERVIEW.adl screen. * The M2LR OSEM is showing a non-zero, fluctuating value (≈±2500 counts) despite having no OSEM connected. * There's red in the Dolphin IPC bit on the H1CDSOVERVIEW.adl screen. Apart from all of that(!), very possibly when the physical suspension is connected up it will damp.
[Paul, Kiwamu, Keita, Dick, Rodica]
Today we measured the mode cleaner cavity length by modulating the EOM at 45 MHz and doing a sweep around this frequency. We measured the spectrum using an HP 43968 Spectrum Analyzer. The maximum source power was 19 dBm from a Mini-Circuits RF amplifyier with gain 19 dB. The bandwidth for the highest zoom on the peak was 300 Hz.
The frequency of the dip in the middle should correspond to the 5th FSR away from the carrier resonance. The calculated length is 9.09918 MHz +/- 100 Hz, only 291 Hz away from the design value of 9,099,471 Hz. This is equivalent to 1.05 mm difference from the design length.
We tried a full sweep over one FSR but we realized that the modulation away from resonance would be too small to give us any useful results, so we focused on the 45 MHz resonant peak. Attached is a plot of the data over a full FSR, that also shows a peak corresponding to the non-resonant polarization, and few other peaks possibly due to higer order modes.
Similar measurements at LLO are described in alog 4702.
Just to add some redundant information, the measured FSR of 9.09918MHz +-100Hz corresponds to:
half-roundtrip = 16.4736m+-0.2mm.
Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot requested from 5 PM Feb. 7 to 5 PM Feb 8. Also attached are plots of the modes to show when they were running/acquiring data. Data was taken from h1nds1. 1440.0 minutes of trend displayed
[Rodica, Kiwamu, Dick, Michael R., Keita, Paul]
Last night and today we finally managed to get what looked like a good measurement of the IMC pole response. Here is a brief description of the measurement setup:
Swept sine signal applied directly from the SRS785 to the AOM driver box inside the PSL. Frequency range was 1kHz to 100kHz, signal amplitude was 400mV pkpk. 1000 intergration cycles, and 101.56ms integration time. Measurement was a transfer function from the DCPD on the PSL installed recently (PDA55) to the DCPD on the IOT2L table (DET100A). ~200mW injected to modecleaner.
The PDA55 on the PSL table didn't give us an observable signal from the amplitude modulation previously when we tried on Wednesday. Rodica checked the Thorlabs recommendation for best linear performance, which states that the maximum intensity should be less than 10mW/cm^2. Even with a very low beam power we may have been exceeding this value due to the very small beam size. The PD was therefore moved to have a larger incident beam size.
We were struggling to get a decent signal on the SRS785 until Kiwamu suggested reducing the light power reaching the PDs to less than 1V. Once we brought the power down to less than 600mV, we were able to see a decent signals on the SRS785 and began taking TFs.
The first attached transfer function is directly from the PSL PD to the IOT2L PD. In the event that the response of both PDs is linear, this should just give the cavity response. However, we noticed that the phase dropped below -90deg on the TF, indicating the presence of another pole - likely that of one of the PDs. We therefore took a TF from the PSL PD to the IOT2L PD, with the IOT2L PD repositioned in the IMC REFL path and the cavity misaligned (as Giacomo did previously). This TF is the second attached plot, and shows the pole of the IOT2L PD. Finally, we then divided the first transfer function by the second to eliminate the different PD response, leaving us just with the cavity response. This transfer function, along with a fit, is shown in the third attached plot.
For now, I just fitted the phase of the pole measurement, which gave the result 8812.36 Hz for the cavity pole. I'll try a complex data fitting routine soon and post the result.
Puzzled by the fact that my previous measurement of the cavity pole didn't make much sense, I spent some time playing with differnt fitting algorithm and writing a simple rountine to fit complex valued functions. It didn't help with my data (there's apparently something I'm missing in the response of some of the compoenents...), but I got a chance to fit this measurement.
Of the attached figure, the two plots on the right don't need any explanation. The one on the left, intead, its a bit odd and needs some explanation (but I like it!). It is built by plotting the complex TF experimental data points and the LP filter fitting function both divided by the magnitude of the fitting function itself. The fitting parameters are obtained by minimizing the quantity:
abs( ( data(f) - fitfunt(f) ) / fitfunc(f) )^2
The reason for normalizing by the value of the fitted function is that, in this way, the points with very small magnitude have the same relative weight of the ones with large magnitude (analogous as fitting in dB scale with uniform weighting), that wouldn't be true otherwise. For the same reason I plotted the normalized quantitites instead of the normal ones, so it is easier to see how "relatively" far the fitting function is from the data, regardless fo their absolute magnitude.
The plot is actually a 3D plot seen from above (you can rotate it in the ".fig", obviously not in the ".png"), with the z axis being the log(frequency). log(frequency) also set the color of the points, so that when you look at the graph projected on a plane (i.e. from above) you can still somehow see the frequency dependence. If the fit is good, the fitted points and the measured ones should be close in both position on the plane AND color.
I excluded the points <2.5e3 Hz and >7e4 Hz from the plot for direct comparison with similar fits done at LLO. The result is definitely close to the expected cavity pole value (8.717 kHz), but I should point out that the choice of the fitting range could change this value by a couple hunderd Hz (for example it increases to about 8950 Hz if I include the entire range of data), so we should pay attention not to take this result to be more accurate that it actually is.
Following the install of OneStop cards in the IO Chassis for h1seib2 and h1susauxb123 I made the first release of the IOP models for these front ends.
h1iopseib2 and h1iopsusauxb123 models were started this morning.
I went through all the H1 IOP models this afternoon to clean them up, bring the comments up to date and add the SVN keywords $HeadURL$ and $Id$.
I then added the propset for these keywords and submitted to svn.
I'll schedule a rebuild and restart of all IOP models at some future maintenance time.
h1susauxh34 received a new OneStop card but is still showing a power supply problem.
I also cleaned up the LHO CDS Overview medm screen to remove systems we are not immediately installing (e.g. SUS ITMX) to remove misleading white blocks.
[Hugo, Rodica, Paul]
Today we were finding it impossible to lock the IMC again. When we looked at the SUS-MC2-M3_LOCK_L_OUT_DQ channel, the signal appeared to be always railing (on both sides). We have seen this before at times, due to very noisy seismic states (see e.g. entry 5145). However, even with what we expected to be a quiet siesmic and ISI state, we still found this signal railing at ±40,000 counts, making it impossible to lock using the length path. In the end, Hugo realised that when the model was recently updated, the limit on the MC2 M3 lock filters had reverted to its initial old value of 40k counts. Apparently at some point this was increased to 400k counts, but not saved in a safe.snap file. Hugo increased the limit back to this value and the mode cleaner began locking again.
We should update the safe.snap file so that any further reboots revert to the 400k counts limit.
You can make a new safe back up easily, by turning off all output (damping loops off, offset off, and master switch off), then running /opt/rtcds/userapps/release/cds/common/scripts/makeSafeBackup The usage is controls@opsws2:~ 0$ cd /opt/rtcds/userapps/release/cds/common/scripts controls@opsws2:scripts 0$ controls@opsws2:scripts 0$ ./makeSafeBackup Usage: First argument is subsystem name (i.e. sus, isi, hpi, isc, etc) Second argument is model name (without .mdl) (i.e. l1suspr3) controls@opsws2:scripts 0$ ./makeSafeBackup sus h1susmc2 controls@opsws2:scripts 0$ this updates the safe backup here, /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc2_safe.snap which you should then commit to the SVN with appropriate comments on what has changed. Also, I believe Mark has a matlab function that sets up the suspension in the right setting for the safe capture, and does the capture, if you prefer that.
Thanks Jeff, I have now done that (I hope succesfullly). I left all the gains, limits, etc. in the useful condition for locking, but turned off all the damping filters, lock filters, alignment offsets and master switch, and then committed the new safe.snap files to the svn.