In the modified code I set it to ignore a dust monitor once it encounters an error with it. This was to avoid slowing down the loop waiting to read disconnected dust monitors. It appears that it is encountering these types of errors at random. So dust monitors are being set to invalid and then being ignored after momentary errors. I'm not yet sure the best way to address this. In the mean time, if a dust monitor goes invalid at random, you can bring up the expert screen for it and hit start. This should start it running again.
Cheryl, Rodica
Over the past days we worked on trying to improve thermal lensing in the Faraday isolator by swapping the 3 mm thick DKDP crystal that slightly undercompensated (and also has much poor surface quality) with a 4 mm thick crystal. With the 4 mm crystal we measured the beam profile and estimated a focal length f=-43 m, which determines >98% mode matching. However, the beam quality starts getting altered at powers above ~50 W, and we could assign this to higher oreder modes introduced by phase distortion after a thicker DKDP. The pictures attached show the beam profile and intensity map at ~140 W. For the estimation of the focal length we only used the data from the less distorted axis (y-profile).
We have available 3.5 mm thickness for DKDP which we are planing to measure this afternoon. Meantime, we are finishing the isolation measurements for the FI with the 4 mm thick DKDP crystal. We needed to redo the alignment for the isolation beam and redump ghost beams, which changed after modifying the alignment on the IO path, now with the EOM out of the beam.
Today is day 2 of the EY conversion from H2 to H1. We are pretty much done, just a few mopping up tasks remain.
I redesigned the IOP SUS watchdog screens now that H1 has more of them, making the default screen an overview and creating a separate detailed screen per Seismic system which can be disabled by its attached SUS systems. So for example SEIH23 gets a screen, as does ETMY.
I tested the IOP watchdog at EY, and then Vern and Jim went out to EY just after lunch time and energized the EY coil drivers and removed their tags.
Jim booted the Hartmann Wavefront Sensor slow controls computer and renamed it h1hwsey giving it its new IP address. We are working with Aidan on getting the HWS EPICS channels renamed. Jim also relabeled the EY computers with their H1 names.
Jim converted most of the control room workstations to H1, including the main operator station. We are keeping two workstations as H2 machines for LVEA Test Stand work.
The Beckhoff slow controls computer h2ecatey was transitioned to h1ecatey by Patrick (name and IP change). He converted all the Beckhoff EPICS records' names from H2 to H1.
I redesigned the H1 MEDM sitemap to add the EY systems. Some linked screens still need to be converted to H1.
We did not get around to damping the EY optics, so for tonight I have manually tripped the IOP watchdogs to disable the DAC outputs.
At 14:31 local, we powered up the h1lscl0 front end and it mysteriously Dolphin glitched the H1 corner station front ends. All HAM SUS and HEPI systems crashed, but the ISI systems did not. The only systems which were being used at the time were SUS MC2 and PR2. We could not reproduce this error by repeating the power up the lsc front end, so we restarted all the crashed models.
Still to be done:
All the new H1 front end models, safe.snap EPICS files and MEDM changes were checked into SVN today.
Over the past few days, we've been checking the cabling between the IMC electronics on ISC R1 and the EtherCAT CM Chassis.
Note: When I refer to slot numbers, I am using the convention used in D1001460. The racks on the floor are numbered using the opposite convention. After discussing with Filiberto, I have decided to relabel these racks later this week.
The relevant changes are between the VCOs and on the Mode Cleaner Servo.
Cable ISC_28 was attached to 79.4 MHz PSL VCO in slots 23-24, and was moved to its correct location at the 79.4 MHz ALS VCO in slots 32-33. The 79.4 MHz PSL VCO is intended to be attached to cable ISC_2. This cable is the wrong gender and will be changed in the near future.
The mode cleaner servo had Cable ISC_6 in Controls 1, and Cable ISC_5 in Controls 2. The cable pull table did not make a distinction between Controls 1 and Controls 2 for this cabling. After checking the pinouts and cabling, I determined that cable ISC_5 needed to be in Controls 1, and cable ISC_6 needed to be in Controls 2. I made the change today.
After brewing the Left sliver of the MC3 optic (IMCF06) in acetone for a total of ~22 hours, the problematic prism finally came off. Today, I followed the coordinates in the gluing doc E1200211 and reglued it back on.
Because it looks (from my remote connection) like data from the H1 SUS PR2 (and H1 SUS MC2, probably more) has frozen, and anticipating a bootfest, I've taken (and svn committed) a new ${userapps}/sus/h1/burtfiles/pr2/h1suspr2_safe.snap to absorb all the new features and EPICs values I've been entering in. I've checked, and there is an approriate softlink in /opt/rtcds/lho/h1/target/h1suspr2/h1suspr2epics/burt/safe.snap and checked that it works by changing a few things, and restoring to it. The file was captured "by hand" using the command pr2 0$ burtrb -f /opt/rtcds/lho/h1/target/h1suspr2/h1suspr2epics/autoBurt.req > /opt/rtcds/userapps/release/sus/h1/burtfiles/pr2/h1suspr2_safe.snap ... but if LLO has a script for this, that'd be great to have ... (and as I was writing this entry, I saw that someone had rebooted H1 SUS PR2. *phew*).
Following a similar prescription as what Keiko's done at LLO (see e.g. LLO aLOG 4030), but now using the new infrastructure, I've installed a few gains, H1:SUS-PR2_M1_OPTICALIGN_P_GAIN 2.636 [drive cts/urad] H1:SUS-PR2_M1_OPTICALIGN_Y_GAIN 1.859 [drive cts/urad] into the new OPTICALIGN bank, which should now be responsible for aligning the optic. With this gain, the offsets H1:SUS-PR2_M1_OPTICALIGN_P_OFFSET (for Pitch) H1:SUS-PR2_M1_OPTICALIGN_Y_OFFSET (for Yaw) are then calibrated into [urad] of optic motion. This gain should be [applicable to / the same for] every HSTS. I attach some shots of the new screens demonstrating where these gains live (and showing off the new screens). ----------------------------- How the gain was calculated: It's along signal chain, but here goes (I use Yaw on an HSTS as an example): LF +--------+ +------+ +-----------+ +-----------+ +---------+ +->|COILOUTF|->| DAC |->|Coil Driver|->|Coil/Magnet|->|Lever Arm|->+ +-----------------+ +---------------+ +----------+ +--------+ | +[cts/ct]+ +[V/ct]+ +---[A/V]---+ +---[N/A]---+ +---[m]---+ | +-------------+ +------------------+ |OPTICALIGN OFFSET|->|OPTICALIGN GAIN|->|DRIVEALIGN|->|EUL2OSEM|->+ +->|HSTS M1 to M3|-->|Optic Displacement| +-----[urad]------+ +---[cts/urad]--+ +-[cts/ct]-+ +[cts/ct]+ | +--------+ +------+ +-----------+ +-----------+ +---------+ | +--[rad/N.m]--+ +------[urad]------+ +->|COILOUTF|->| DAC |->|Coil Driver|->|Coil/Magnet|->|Lever Arm|->+ RT +[cts/ct]+ +[V/ct]+ +---[A/V]---+ +---[N/A]---+ +---[m]---+ (see fullsignalchain.png if you browser sucks at ASCII art) Thankfully, because - we're only looking for the DC gain of this path, - the DRIVEALIGN matrix is an identity at this point - the EUL2OSEM matrix accounts for (divides out) the number of actuators (two in this case) and the lever arm between the OSEM and the center of rotation - the COILOUTFs are unity at DC then our calculation only involves this simplified chain: +-----------------+ +---------------+ +------+ +-----------+ +-----------+ +-------------+ +------------------+ |OPTICALIGN OFFSET|->|OPTICALIGN GAIN|->| DAC |--|Coil Driver|--|Coil/Magnet|->|HSTS M1 to M3|-->|Optic Displacement| +-----[urad]------+ +---[cts/urad]--+ +[V/ct]+ +---[A/V]---+ +-["N.m"/A]-+ +--[rad/N.m]--+ +------[urad]------+ (see reducedsignalchain.png if you browser sucks at ASCII art) which means the OPTICALIGN GAIN is: OPTICALIGN GAIN [cts/urad] = ( DAC [V/ct] * Coil Driver [A/V] * Coil/Magnet [N/A] * HSTS M1 to M3 [rad/N.m] * 1e6 [urad/rad] )^-1 = ( (20/2^18) * 0.011919 * 0.963 * 0.4332 (for Yaw) * 1e6 )^-1 = 1.850 [cts/urad] The only difference for pitch is that HSTS M1 to M3 [rad/N.m] = 0.6172 (for Pitch). The electronics gains of the signal chain were taken from T1000061 (the contents of which have been experimentally confirmed elsewhere), and the HSTS M1 to M3 coefficients were taken from the production model (e.g. see T1200404).
S. Aston, J. Kissel As with the QUAD (see LHO aLOG 4746), I have made mistakes in the OPTICALIGN gain calculation (shown above) in that, though the spelled out calculation is correct (with a "DC" compliance of 0.6172 [rad/N.m] (for Pitch), and 0.4332 [rad/N.m] (for Yaw)), the answer I call out has the values for Pitch and Yaw flipped. Even further, after double checking the DC compliance numbers using the HSTS model, I discovered that, for "DC," I used the value of the transfer function at 0.1 Hz. However, the transfer functions have not yet truly flattened by that point as the values at 0.01 Hz are: M1 P to M3 P: 0.609 [rad/N.m] M1 Y to M3 Y: 0.426 [rad/N.m] Sheesh. I clearly did these calculations far too quickly, or at least was far too hasty with my copy-and-pasting. Thanks to Stuart for catching them! So, redoing it slower, with the 0.01 Hz numbers for the "DC" compliance, the calculation should read: (FOR AN HSTS) OPTICALIGN GAIN [cts/urad] = ( DAC [V/ct] * Coil Driver [A/V] * Coil/Magnet [N/A] * HSTS M1 to M3 [rad/N.m] * 1e6 [urad/rad] )^-1 = ( (20/2^18) * 0.011919 * 0.963 * 0.609 (for Pitch) * 1e6 )^-1 = 1.8751 [cts/urad] (for Pitch) OPTICALIGN GAIN [cts/urad] = ( DAC [V/ct] * Coil Driver [A/V] * Coil/Magnet [N/A] * HSTS M1 to M3 [rad/N.m] * 1e6 [urad/rad] )^-1 = ( (20/2^18) * 0.011919 * 0.963 * 0.426 (for Yaw) * 1e6 )^-1 = 2.6806 [cts/urad] (for Yaw) As of this entry, I have corrected these gain values in H1 SUS PR2, saved a new h1suspr2_safe.snap, and committed it to the userapps repo, /opt/rtcds/userapps/release/sus/h1/burtfiles/pr2/h1suspr2_safe.snap
Mark B. As Travis points out in a comment, this is ITMy not ITMx. Title of post and references below changed. Preparing to take TFs on main chain of H1:ITMy (which is still wired up as H2:ITMy). I hope to start them imminently (16:40 pm, 10/30) and check progress from home tonight. Checked at 07:21 am (10/31), damped TFs seemed to have completed successfully. Started undamped TFs.
It is still ITMy, just moved from H2 to H1.
Mark B. Aborted undamped TFs to allow Travis to make yaw adjustment.
Dave, Jim and Vern
We started the transition of the LHO EY station from H2 to H1. At the end of day one we have all the networks and front end computers moved, and all the DAQ data transferred from the H2 DAQ to the H1 DAQ.
Here are the details.
Monday prep work, h1boot was configured to take the new systems (DHCP, boot services) and the main DNS was similarly changed. IOP models were copied from h2 to h1.
First thing this morning Vern and Jim went to EY and turned off all Coil Drivers and AI chassis for BSC6. These units were tagged out.
The two network switches at EY (sw-ey-h2fe, sw-ey-h2daq) were re-routed in the MSR to their equivalents (sw-msr-h1fe and sw-msr-h1daq).
The core switch and sw-msr-h1fe were reconfigured to route the OPSLAN.
We turned off all the computers in EY, including the slow controls h2hwsey and h2ecatey.
The frontends were then booted from h1boot, these are h1susb6, h1seib6, h1susauxb6, h1pemey, h1tcsey and h1pemauxey (note this one's name was changed from h1pemeyaux to fix problems caused by this name).
The H1 DAQ was reconfigured to add the new EY models.
The converted IOP models for these FEs were loaded and the Duotone signal used to verify that H1 DAQ was seeing the EY data.
We converted all the user models from H2 to H1. The full list is h1susetmy, h1sustmsy, h1hpietmy, h1isietmy, h1pemey, h1iscey, h1susauxb6, h1tcsetmy,h1pemauxey (note name change). We also converted all the safe.snap files from H2 to H2, putting those missing from SVN into the repo.
The site overview medm screens for both h2 and h1 were regenerated to show the EY move. The H2 DAQ was had the moved system removed from it.
H1 DAQ was reconfigured when it was found that the Dataconcentrator and NDS had insufficient RAM (6GB). We doubled the ram to 12GB on h1dc0, h1nds0 and h1nds1. The frame writers were not affected since they have 48GB of mem.
Jim power cycled all the frontends to change the IPMI IP addresses.
We disconnected the 8km RFM loop between EY and h2susb478.
Dolphin configuration was removed from h2boot and added to h1boot, but we found that node id 64 is not allowed, yet 68,72,76 are!
Outstanding work for tomorrow: slow controls computers (ecat and HWS), control workstations including the operator station, full test of the h1models including IOP Watchdog system, and then coil driver activation and BSC6 damping if all tests pass. default nds changed to h1. alarm handlers.
H1 Frame size for 32 second frame increased from 105MB to 161MB.
I've completed the installation of the H2 SUS PR2 ISI WIT and OFFLOAD path, such that the H1 HAM3-ISI GS13s are now projected into the H2 SUS PR2 Suspension point basis, and the H2 SUS PR2 M1 offload signal may be sent to the HAM3-ISI. Details of the design are discussed below. The following channels are now calibrated into (nano)meters or (nano)radians of motion at the H1 HAM3-ISI center of actuation and at the H1 SUS PR2 suspension point, respectively: H1:SUS-PR2_M1_ISIINF_${CARTDOF}_OUT_DQ H1:SUS-PR2_M1_ISIWIT_${EULERDOF}_DQ which are stored in the frames at 1024 Hz, where ${CARTDOF} = [X, Y, RZ, Z, RX, RY] and ${EULERDOF} = [L, T, V, R, P, Y]. I attach a couple of screenshots of the implementation in MEDM. The paths are shown at the top of the HSTS overview screen (shown in H1SUSPR2_SEISUSPaths_OverviewScreenShot.png). Clicking inside the ISIINF bank (shown in H1SUSPR2_SEISUSPaths_ISIINF.png), one sees the 4k to 16k AI filter in FM1, the conversion from ideal inertial sensor response to displacement lies in FM5, and additional gain-only filters have been installed into FMs 9 and 10, if the user so chooses to convert the displacement signal either from nanometers (nanoradians) to micrometers (microradians) in FM9 or from nanometers (nanoradians) to meters (radians) in FM10. Finally, I show the CART2EUL matrix for H1 SUS PR2 (see H1SUSPR2_SEISUSPaths_CART2EULMatrix.png), taken from /opt/rtcds/userapps/release/isc/common/projections/ISI2SUS_projection_file.mat computed as described in T1100617, and installed with /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/fill_matrix_values.m I also attach three sets of plots explaining the design: isiinf_tonmdesign_2012-10-30.pdf -- Here, I elucidate the thought process behind the design of the "to_nm" filter in FM5 of the ISIINF filter bank, breaking the filter down into its various parts / functions. - The GS13 signals, in the ISI's center-of-actuation, Cartesian basis (picked off from the input to the blend filters) arrives calibrated into an ideal inertial sensor response, which asymptotes to 1 [nm/s] at high-frequency (above ~1 [Hz]), and rolls off at low frequency as f^2. - The first step is to invert this response, shown by the "1 Hz Ideal Inertial Sensor Response to Velocity" in BLUE, leaving the signal in [nm/s] velocity units at all frequencies. This portion of the filter (in Matlab notation) is velcal = zpk(-2*pi*[pair(1,45)],-2*pi*[0,0],1) - Next, the signal is integrated once (i.e. the GREEN filter; convdisp = zpk([],-2*pi*[0],1)), to convert to [nm] displacement units, resulting in the CYAN filter, velcal*convdisp = zpk(-2*pi*[pair(1,45)],-2*pi*[0,0,0],1) Note: this is the filter that one typically uses to "finish" the calibration of the inertial sensor offline to compute an ASD of the signal. - Finally, because we still want to have a usable time series and not have a calibration filter with infinite step response, we roll off the calibration such that signal is low-passed/AC-coupled at 10 mHz, with the (RED) filter portion, rolloff = zpk(-2*pi*[0,0,0,0],-2*pi*[0.01,0.01,0.01,0.01],1) resulting in the final, MAGENTA, TOTAL filter, velcal * convdisp * rolloff = zpk(-2*pi*[0,0,0,0,pair(1,45)],-2*pi*[0,0,0,0.01,0.01,0.01,0.01],1) = zpk(-2*pi*[0,pair(1,45)],-2*pi*[0.01,0.01,0.01,0.01],1) which rises as f from DC, turns over at 10 mHz, falls as 1/f^3, crosses unity at 1/(2*pi*1), knees at 1 Hz to fall as 1/f out to high frequency, as expected. The corner frequency of 10 mHz was chosen for several reasons: (1) It's roughly equivalent to the corner frequency of the T240s on ST1 of the BSC-ISI (2) The GS-13 signals at these frequencies are dominated by sensor-noise. (3) We wanted to still accurately reproduce the magnitude/amplitude of the signal at the microseism. (4) We wanted the time series to be manageable during normal operation. BE AWARE Though the magnitude/amplitude of the signals calibrated in this fashion are accurately reproduced down to ~50 [mHz], the phase lags the real signal by the difference between MAGENTA and CYAN, which already lags 22.73 [deg] by 0.1 [Hz] and as much as 180 [deg] by 10 [mHz]. (Several different options were tossed about that would have potentially improved the phase reproduction (elliptic filters, butterworth filters, etc.) but we figured, for now, perfect is the enemy of good enough.) isiinf_filters_2012-10-30.pdf -- pgs 1-2 show the magnitude and phase of the as-implemented AA/AI filter (used as a 4k to 16k AI filter in the ISIINF banks to receive the GS13 signals, and as a 16k to 4k AA filter in the OFFLOAD banks to send the SUS offload signals out to the ISI). The filter's bump maxes out at 2.11 dB above unity around 1350 Hz, and has -79.38 dB isolation the 4096 Hz notch. The filter was implemented using the ZPK portion of the foton design suite, with Mag Phase Mag Phase poles = [pair(2*850, 55 ) pair(2*1048, 70 )]; zeros = [pair( 4096, 89.9) pair(2*4096, 89.9)]; The details of the design for the AA/AI filter can be found in the old SEI Log entry 1937. This filter was designed to have better phase loss and anti-imaging properties at f < 100 Hz than the "standard" CDS 4k AA/AI filter, with only 5.5 deg lost at 100 Hz (the standard has ~10 deg loss). Since Lantz determined this was better for what seismic typically does with these signals -- and it's what they use to up/down-sample their signals from the IOP -- I figured "why be different?" Lantz approves. pg 3-4 shows the magnitude and phase of the as-implemented "to_nm" filter, equivalent to velcal * convdisp * rolloff from above, but the design string in foton is subtly different because of Sigg's vs. Matlab's convention choices: zeros poles gain zpk([0;0.707+i*0.707;0.707-i*0.707];[0.01;0.01;0.01;0.01],1.59e7,"n") (note the gain of 1.59e7 = 1/(2*pi*(0.01)^4) to normalize the rolloff properly in foton's convention.) isiinf_H1SUSPR2_2012-10-30.pdf -- These plots show the ASD and Magnitude, Phase, and Coherence of the Transfer Function between exemplary channels: H1:ISI-HAM3_BLND_GS13X_IN1_DQ -- the inputs to the blend filters, fresh off of the ISI, calibrated in [nm/s] "offline" using DTT's calibrator with a filter identical to velcal above (scaled into [m/s] by a factor of 1e-9), and then displayed in (integrated to) displacement courtesy of DTT (which is identical to convdisp above). H1:SUS-PR2_ISIINF_X_OUT_DQ -- the output of the ISIINF, after AI filtering and calibrated "online" to [nm] (and then scaled to [m] by 1e-9 in DTT). H1:SUS-PR2_ISIWIT_L_DQ -- the final result of interest: the GS13s calibrated "online" and propogated through the CART2EUL matrix to the H1 SUS PR2 suspension point. This data was taken with the ISI active control loops completely OFF (no damping, no isolation, no nothing). Here, we see lots of fun things: (ASD) (a) Above the 10 mHz rolloff, once calibrated into the same units, the X signal is identical between the input to the blends (RED) in HAM-ISI land and the output of the ISIINFs (BLUE) in SUS land. Below the roll-off, the signals begin to diverge at ~50 mHz as expected. (b) The point of this whole shebang: The signal projected to the susp. point (GREEN) is different from simply assuming the X motion (BLUE) is what's input. Here, in L, we see significant contribution from both X and RY, most notably at the ~1 Hz RY resonance (a factor of two with the resonance undamped). I'm very interested to see what other degrees of freedom look like, and under different conditions of the ISI... (COH) (a) As expected the coherence between the signal in ISI land and the signal in SUS land drops, simply because of the roll off filter. (b) The coherence drops along the various cross-couplings between ISI Cartesian, center-of-actuation, basis and SUS Euler, suspension point, basis. (TF) (mag) This basically just reproduces the product of the calibration and AI filters in the bank as expected, but there are some interesting features where the cross-coupling is going on (pha) Same as mag. Note that L is 180 deg out of phase with X because -- you guessed it -- PR2 is pointed in the -X direction. In conclusion: This well-defined, in-the-same-basis, peaches-to-peaches, signal opens up a whole bunch of new possibilities for modeling the suspension's motion, least of all, for starters, it should certainly require a lot less (i.e. no) offline post processing for modelers, commissioners, and glitch hunters alike. Now that I've got the first-article filters in place, I've already got the SEI/SUS basis matrices (for every SUS that has a system's drawing), it should be very straight-forward to get the rest of the SUS up to speed. Stay tuned for new found understandings!
At Stanford we were wondering if this awesome new witness for the seismic inputs to the SUS could be used for feedforwarding between table motion and the SUS top mass. As long as the table motion is above the sensor noise, there should be useful signal that might be sent to SUS.
Replaced all drying tower check-valves and solenoid valves as well as solenoid valve coils -> most of these components were original (1997) and overdue for replacement -> original desiccant will be replaced too but is on back-order at this time
Today I continued poking at ITMy to address a couple of minor issues on our way to final alignment. First, I replaced a wonky flag mount for the R0 Side BOSEM (poor pressfit of magnetic disc not allowing flag magnet to seat squarely). I then adjusted the tablecloth to get it back to a more 'nominal' state where the BOSEM cams still have effective adjustment left. I then continued with the Test Mass pointing. I adjusted yaw of M0 by using some slop in the fixing screws for the suspension wire clamp at the Top Stage blades. I also adjusted some more pitch out using the UIM pitch adjusters. (Reminder at Betsy's request: The UIM pitch adjusters have an effect of ~200µRad per full turn of each adjuster.) The resulting measurement by IAS left ITM at:
Pitch: ~5µRad up
Yaw: ~1.04mRad CW (previously ~185µRad CCW)
Although I overshot, I now know that we have plenty of easy-to-use yaw adjustment at the wire clamp to fix the yaw error. This work will continue tomorrow. I then solicited Mark to run some quick TFs to check for rubbing before we get too carried away with fine alignment.
The west door was removed from the chamber this afternoon to allow the installation of the septum viewport.
Both the east and west doors were returned to the chamber to facilitate "dirty" work in the neighborhood.
For the 200W laser. RIck and I adjusted the modematching into the DBB PMC using ML1 and ML2 inside the DBB, reducing the 20-02 peak.
Note that there is a peak in the ISS_rpn plot just under 2kHz which does not appear when using the 35W laser.