40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 225 of 339 Not logged in
ID Date Author Type Category Subject
6167   Wed Jan 4 05:02:58 2012 kiwamuUpdateLSCSidebands measurement at POP
Just a quick report:
I did the first attempt to measure the recycling gains of the sidebands in the DRMI configuration (sidebands resonant condition)
by looking at the output of the POP22/110 RFPD.
Because this time what I measured is some absolute values of the sidebands power,
it doesn't tell us anything quantitatively until we calibrate it or compare it with similar data.
So I need to measure the same things in some different configurations (e.g. PRMI, SRMI, etc.)
in order to extract some useful information from the measurement.

The attached picture is the display of a power spectrum analyzer looking at the output of the POP22/110 broadband RFPD
while the DRMI (in the sideband resonant condition) was kept locked.
You can see that 111 MHz (twice of 55 MHz) is prominent. Also there are several peaks at 11, 22, 44 and 66 MHz.
1297   Thu Feb 12 14:39:07 2009 ranaSummaryGeneralSilicon Beam Dump test
Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.

The pictures of the setup and the Silicon with the beam hitting it are here.

Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.

This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.
2752   Thu Apr 1 16:34:29 2010 HartmutUpdateGreen LockingSilicon PDs

just a few infos on Silicon PDs I looked up.

If you want to go beyond the 100MHz achievable with the device I worked on,

the one thing to improve is the opamp, where Steve is trying to find OPA657.

This is a FET with 1.6GHz BWP, minimum stable gain of 7, and 4.8nV/rt(Hz) noise.

Should be ok with 750-1000 Ohm transimpedance.

The other thing you might want to change is the PD

(although it might be the 1cm PD with high bias is as fast as smaller ones with lower bias).

There are two types of other Si diodes at the 40m right now (~3mm):

-Rana and I found a Centronic OSD 15-5T in the old equipment

-Frank gave me a Hamamatsu S1223-01 on a Thorlabs pre-amp device (could be taken out).

The Centronic OSD 15-5T has up to 80pF with 12 V bias according to the datasheet.

The Hamamatsu S1223-01 is stated with 20pF only, but stated to have a max. frequency resp. of 20MHz ('-3db point').

I dont know what this means, as the corner freq. of 10pF into 50Ohm is still 160MHz.

In any case there are faster 3mm types to start with, as for example Hamamatsu S3399 (~ 90), which is stated to have the corner at 100MHz with 50 Ohm load. For this type the stated capacity (20pF) looks consistent with ~100MHz corner into 50 Ohm. So probably you can get higher BW with this one using much smaller load, as in transimpedance stage. 7181 Tue Aug 14 16:33:51 2012 SashaUpdateComputer Scripts / ProgramsSimPlant indicator added I added an indicator to the watch dog screen so that a little "SP" icon appears whenever the SimPlant is on. Since we only have one simplant (ETMX), only ETMX has the simPlant indicator. However, since assymetry is ugly, I moved all of the OL icons over so that they're in a line and so that there is room for future SP icons. I also fixed the link to the Watchdogs on the main SUS screens (it was dead, but now it is ALIVE). 4394 Thu Mar 10 01:28:47 2011 joe, jamie, rana, chrisSummaryCDSSimSuspension ! Today was a banner day for Simulated Plants. Joe and Jamie have been working to get it all happening and this afternoon we started stuffing filters into the plant to make it act like the: We put in the following features so far: 1. Anti-Imaging filters (these are hacked to be approximate since the real ones are 7570 Hz LP filters and the SimAI only can have filters up to 8192 Hz). 2. Dewhitening filters (copied from the SimDW in the SUS-ETMY screens) 3. Coil Driver transimpedance (1 / 200 Ohms) 4. Magnet-coil force constant (0.016 N/A) 5. Conversion from Coil to DOF Basis 6. All DOFs of the mechanical model are represented as simple harmonic oscillators with Q~100 and f ~ measured free swinging peaks. 7. Signals/Noise can be injected either as force noise on the test mass or as displacement noise at the suspension point. 8. Conversion from DOF to Shadow Sensor basis. 9. Optical Levers (with whitening) 10. Shadow Sensors have 2V/mm readout gain and whitening filters before being digitized by the SimADC. We have also changed the switching logic for the SUS and SimETMs for the shadow sensor whitening. It used to be that either the hardware OR the software whitening was on. Now we have made it like all of the other whitening/antiwhitening in LIGO and the whitening/antiwhitening come on together. Joe and Jamie are going to propagate this to the other SUS. The hardware filter is a 30,100:3 (poles:zeros) whitening filter. The digital filter used to also be 30,100:3 with a DC gain = 1. I've changed the FM1 filter in the XXSEN filter banks into a 3:30 for the ETMY so that it now comes on and just compensates the hardware filter. This change should be propagated to all other SUS and the MEDM screens updated to show the new situation. After this change, we decided to calibrate the {UL,UR,LL,LR,SD}SEN channels into units of microns. To do this we have made an FM6 filter called 'cts2um' that accounts for the OSEM gain and the ADC conversion factors. These channels are now in units of microns without applying any calibration in the DTT or Dataviewer. The plot below shows the OSEM shadow sensor time series with all damping loops ON and a very rough version of seismic noise being injected in all 6 DOFs (note that the y-axis is microns and the x-axis is seconds). Next, Jamie is adding the angular calibrations (so that SUSPIT and SUSYAW are in rads) and Chris is making vectift quality seismic noise injectors. We also need to add coating thermal noise, suspension thermal noise, substrate thermal noise, ADC/DAC noise and a lot of MEDM screen indicators of what state we're in. I myself can't tell from the OSEM time series if its real or Sim. 7151 Sat Aug 11 01:10:26 2012 SashaUpdateSimulationsSim_Plant Working! Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise. P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS? Attachment 1: Plant_sen.jpg 7152 Sat Aug 11 18:05:49 2012 SashaUpdateSimulationsSim_Plant Working!  Quote: Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise. P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS? Developed some seismic noise. I adapted the seismic noise filters we used for the MC model way back when. They looked questionable to begin with, but I added some poles/zeroes to make it more accurate (see Attached). Attachment 1: seismic_noise1.jpg 7167 Mon Aug 13 23:06:08 2012 JenneUpdateSUSSimplant left on Simplant for ETMX was left on, so I didn't have control of ETMX. Not cool. The IFO should be left in it's 'regular' state (all optics restored to saved alignments, no simplant, LSC/ALS/ASS loops off) if you're not actively working on it. What this did point out, however, is that we need a big ol' indicator on the IFO_ALIGN / LSC / Watchdog / Overview screens to indicate that simplant is on for a particular optic, or whatever simplant might be controlling that takes away 'regular' control. I probably would have continued being frustrated and confused for a lot longer if Eric didn't mention that simplant could have been left on. Thanks Eric! Symptoms, which perhaps would have eventually pointed me to simplant, were that there was some weird moving beam on the AS camera that was flashing fabry-perot fringes, and the POX signal looked like junk. After some looking around, I noticed that ETMX, while it claimed to have all the damping loops on, and the oplev on, was swinging a lot (rms levels of 4 - 7, rather than the usual < 2 ). I said something out loud, and Eric suggested looking at Simplant. After putting Simplant back to Reality, things are back to normal. 3276 Fri Jul 23 14:26:01 2010 GopalUpdateOptic StacksSimple Frequency Response Measurements in COMSOL Over the past couple days, I discovered a simple, direct method for calculating frequency responses with a combination of COMSOL and any plotter such as Excel or MatLab. The simple case of rectangular prism of steel was analyzed using this method; details will be posted shortly on the COMSOL Wiki page. The frequency response matched theoretical reasoning: the bar acts as a simple mechanical low-pass filter, rapidly attenuating driving frequencies at the base beyond the first eigenmode. It therefore shouldn't be too difficult to extend this analysis to the MC1/MC3 stack. The many eigenfrequencies will produce a more complicated transfer function, and so more data points will be taken. The major shortcoming of this method involves dealing with the imaginary components of the eigenfrequencies. As of now, I haven't found a way of measuring the phase lag between the drive and the response. I also haven't found a way of changing the damping constants and therefore playing with phase components. 16718 Wed Mar 9 11:52:18 2022 YehonathanUpdateBHDSimplified BHD readout sketch on ITMY table I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached). 10 pts = 1 inch. This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table. Attachment 1: ITMY_Table_Sketch.drawio.pdf 16719 Wed Mar 9 12:57:52 2022 KojiUpdateBHDSimplified BHD readout sketch on ITMY table - BHD beams were already mixed in the chamber. So we don't need a BS on the table. (Probably there is no BS already) - We don't need to split each BHD beam. One PD per BHD beam is OK for now. - Check if the BHD paths have reasonable angles from the windows so that the beams do not hit the chamber wall. - We need the POY path. POY indeed goes to the BS table 16755 Mon Apr 4 15:49:06 2022 TegaUpdateOptical LeversSimplified sketch on BS table I have updated the BS table using feedback from Koji and Paco and the attached pdf document is the latest iteration. Attachment 1: BS_Table.drawio.pdf 16751 Fri Apr 1 14:26:50 2022 TegaUpdateOptical LeversSimplified sketch on MC table Here is an early sketch of the MC table.  Quote: I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached). 10 pts = 1 inch. This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table. Attachment 1: MC_Table.drawio.pdf 16752 Fri Apr 1 17:02:02 2022 KojiUpdateOptical LeversSimplified sketch on MC table We are supposed to have BS Oplev Beams. We don't like the shallow angle reflections (i.e. AOI>45deg). The laser is too big but I suspect the other components are too small. So it'd be check the actual size of the components including the optical mounts that are missing on the figure so far. 16753 Fri Apr 1 22:22:29 2022 KojiUpdateOptical LeversSimplified sketch on MC table Possibility to swap BS and ITMX tables: BS table, which Tega said MC table, is 2ft x 4ft. The ITMX table is 3ft x 5ft and only the central 2ft x 4ft area is used. The area around the BS table is the narrowest for the east arm. We need at least (2+delta) ft of the hallway width so that we can move the instrument. I'm not yet sure if the ITMX table can be placed there without precise investigation. 4388 Tue Mar 8 16:59:47 2011 josephbUpdateCDSSimulated Plant Work The screens for the simplified c1spx model have been updated. I re-introduced the suspension point information into the sensor output matrix so we can take into account the fact that as the entire supporting structure moves, the osems moves relative to the optic. Master screens for the noise filters (i.e. 60 Hz, suspension point motion, and optic noise) have been created. I have currently set the matrix values of the c1spx model to handle just longitudinal motion. I.e. Coils drive only in the POS degree of freedom and sensor read outs are also only in the POS degree of freedom. I've turned off all the noise inputs. I added a simple double pole at 1 Hz in the C1:SUP_ETMX_PL_F2P_0_0 filter bank. 16948 Sat Jun 25 22:18:41 2022 TomislavUpdateASCSimulation and reality comparisons In the attachment please find plots comparing controller output, local damping output, and error signals. Input noises of the simulation are seismic noise, osem noise, input power fluctuations, sensing noises of WFSs and QPD, and air turbulence noise for WFSs. There is also optical torque noise (radiation pressure effect). The procedure to get optical gains and sensing noises: Having the actuator response A rad/cnts @ 3 Hz. I was shaking MC1/2/3 in pitch with B cnts @ 3 Hz and getting WFS1/2 QPD signals of C cnts @ 3 Hz, which means WFS1/2 QPD optical gain is D cnts/rad = C / (A * B) cnts/rad. So, if WFS1/2 QPD IN1 has a noise spectrum (at higher freqs) of E cnts/rtHz, that corresponds to E/D rad/rtHz of sensing noise for WFS1/2 QPD. Actuator response [rad/cts] I was getting shaking mirrors at 3 Hz and measuring amplitudes of OSEM output (knowing the geometry of the mirror). I scaled it to DC. From here I was getting ct2tau_mc (knowing the mirror's moment of inertia, Q, and natural pitch frequencies). OSEM calibration factors [cts/rad] I was getting from the input matrix and geometry of the mirror. The flat noise at higher frequencies from the local damping and controller output channels is presumably quantization/loss of digits/numerical precision noise which I don't include in simulations for now?! Regarding air turbulence, in KAGRA it has been reported that air turbulence introduces phase fluctuations in laser fields that propagate in air. According to Kolmogorov’s theory, the PSD of phase fluctuations caused by air turbulence scales as ∝ L*V^(5/3)*f^(−8/3). Here, L is the optical path length and V is a constant wind speed. Since it is not obvious how can one estimate typical V in the beam paths I was taking this excess noise from the error signals data between 10 Hz and 50 Hz, extrapolated it taking into account ∝ f^(−8/3) (not for frequencies below 2 Hz, where I just put constant, since it would go too high). I expect that I won't be able to get a parameterized model that also predicts the absolute value. The slope is all I can hope to match, and this I already know. QPD chamber is much smaller (and better isolated?) and there is no this excess noise. Regarding other things in simulations (very briefly): beam-spots are calculated from angular motions, length change is calculated from beam-spots and angular motion, cavity power depends on length change and input power, and torque on the mirrors depends on beam-spots and cavity power. From other things, local-sensor basis conversion (and vice versa) is worth noting. Attachment 1: sens_output_comparison_23_6_new.png Attachment 2: contr_out_comparison_23_6_new.png Attachment 3: local_damp_out_comp_23_6_new.png 14667 Wed Jun 12 22:02:04 2019 MilindUpdateCamerasSimulation enhancements Today, Rana asked me to work on improving simulations based on the ideas we discussed last week. As of the previous elog the simulation accomodated only 1. Simulation of Gaussian beam spot. 2. Arbitrary motion. Today, I added the simulation of point scatterers. What? The image on the sensor (camera) is produced in roughly the following steps. 1. Motion of the Gaussian beam on the optic (X,Y coordinates) which is what has been simulated so far. 2. Reflection from the surface of the optic which can be modeled using knowledge of the BRDF has not been included as of this elog as I wish to do a little more reading before doing so. 3. Reflection from point scatterers (dust particles burnt into the optic surface by the laser and so forth) which are characterised as peaks (impulses) in the TIS vs position plot. The laser beam is incident nearly normally on the optic and this behaviour is independent of the angle of observation. This is what has been added to the simulation. How? 1. Increased the frame resolution to 720 x 480. 2. Defined an array of the same size and set values of at most "num_scatter" number of points at random positions to values determined randomly between 1 and "scatter_amp" + 1 where scatter_amp is non-negative. 3. Multiplied the resulting array by the resulting Gaussian beam. The motivation was to imitate the bright specks obtained on various camera feeds in the lab. Physically, this also implies normal incidence and normal observation which is not the real case at all. I shall add these features in a day or two. Herewith, in attachments #1, #2, #3 I am attaching videos obtained by varying scattering amplitude and number of scattering points in a vain attempt to reproduce this data. I shall work more on this simulation on Friday. Scripting stuff: 1. Previous elogs detail how to take gige images at various exposure times. I am still waiting on Kruthi to use the script. 2. Tomorrow I shall work on the scripting software to interact with the GigE and take video for a fixed duration etc. I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting. Neural network stuff: GANs for simulation: 1. Other than putting the physics into simulation i.e the first portion of this elog, GANs can be trained to generate images similar to the original data. I am unfamiliar with training GANs and the various tricks that are used specifically for them. I will do a bit of reading and make an update by Friday. As of now, the data I plan to use is this and I will train it using the GTX 1060 on my machine. Networks for beam tracking: 1. I will use the architectures suggested in this work with a few modifications. I will use MSE loss function, Adam optimizer and my local GPU for training. Attachment 1: simulated_motion0.mp4 Attachment 2: simulated_motion0.mp4 Attachment 3: simulated_motion0.mp4 14698 Tue Jun 25 23:52:37 2019 MilindUpdateCamerasSimulation enhancements Yesterday, Rana asked me to look at Hiro Yamamoto's docs on the DCC to improve the simulation. I'm performing a first pass (=> Just skimming through to see if they're relevant, I will go through them more carefully soon!) and putting up stuff here for future reference. @Kruthi's help much appreciated! 14714 Mon Jul 1 20:11:34 2019 MilindUpdateCamerasSimulation enhancements Today, I read a lot more about BRDF and modelling but could not make much headway regarding the implementation in the simulation. I've stopped for now and I'll take a crack at it tomorrow again.  Quote: Yesterday, Rana asked me to look at Hiro Yamamoto's docs on the DCC to improve the simulation. I'm performing a first pass (=> Just skimming through to see if they're relevant, I will go through them more carefully soon!) and putting up stuff here for future reference. @Kruthi's help much appreciated! 14635 Thu May 23 15:37:30 2019 MilindUpdateCamerasSimulation enhancements and performance of contour detection 1. Implemented image level noise for simulation. Added only uniform random noise. 2. Implemented addition of uniform random noise to any sinusoidal motion of beam spot. 3. Implemented motion along y axis according to data in "power_spectrum" file. 4. Impelemented simulation of random motion of beam spot in both x and y directions (done previously by Pooja, but a cleaner version). 5. Created a video file for 10s with motion of beam spot along the y direction as given by Attachment #1. This was created by mixing four sinusoids at different amplitudes (frequencies (0.1, 0.2, 0.4, 0.8) Hz Amplitudes as fractions of N = 64 (0.1 0.09 0.08 0.09). FPS = 10. Total number of frames = 100 for the sake of convenience. See Attachment #5. 6. Following this, I used the thresholding (threshold = 127, chosen arbitrarily), contour detection and centroid computation sequence (see Attachment #6 for results) to obtain the plot in Attachment 2 for the predicted motion of the y coordinate. As is evident, the centering and scale of values obtained are off and I still haven't figured out how to precisely convert from one to another. 7. Consequently, as a workaround, I simply normalised the values corresponding to each plot by subtracting the mean in each case and dividing the resulting series of values by their maximum. This resulted in the plots in Attachments 3 and 4 which show the normalised values of y coordinate variation and the error between the actual and predicted values between 0 and 1 respectively. Things yet to be done: Simulation: 1. I will implement the mean square error function to compute the relativer performance as conditions change. 2. I will add noise both to the image and to the motion (meaning introduce some randomness in the motion) to see how the performance, determined by both the curves such as the ones below and the mean square error, changes. 3. Following this, I will vary the standard deviation of the beam spot along X and Y directions and try to obtain beam spot motion similar to the video in Attachment #2 of elog post 14632. 4. Currently, I have made no effort to carefully tune the parameters associated with contour detection and threshold and have simply used the popular defaults. While this has worked admirably in the case of the simple simulated videos, I suspect much more tweaking will be needed before I can use this on real data. 5. It is an easy step to determine the performance of the algorithm for random, circular and other motions of the beam spot. However, I will defer this till later as I do not see any immediate value in this. 6. Determine noise threshold. In simulation or with real data: obtain a video where the beam spot is ideally motionless (easy to do with simulated data) and then apply the above approach to the video and study the resulting predicted motion. In simulation, I expect the predictions for a motionless beam spot video (without noise) to be constant. Therefore, I shall add some noise to the video and study the prediction of the algorithm. 7. NOTE: the above approach relies on some previous knowledge of what the video data will look like. This is useful in determining which contours to ignore, if any like the four bright regions at the corners in this video. Real data: 1. Obtaining real data and evaluate if the algorithm is succesful in determining contours which can be used to track the beam spot. 2. Once the kind of video feed this will be used on is decided, use the data generated from such a feed to determine what the best settings of hyperparameters are and detect the beam spot motion. 3. Synchronization of data stream regarding beam spot motion and video. 4. Determine the calibration: anglular motion of the optic to beam spot motion on the camera sensor to video to pixel mapping in the frames being processed. Other approaches: 1. Review work done by Gabriele with CNNs, implement it and then compare performance with the above method. Attachment 1: actual_motion.pdf Attachment 2: predicted_motion.pdf Attachment 3: normalised_comparison.pdf Attachment 4: residue_normalised.pdf Attachment 5: simulated_motion1.mp4 Attachment 6: elog_22may_contours.mp4 14638 Sat May 25 20:29:08 2019 MilindUpdateCamerasSimulation enhancements and performance of contour detection 1. I used the same motion as defined in the previous elog. I gradually added noise to the images. Noise added was uniform random noise - a 2 dimensinoal array of random numbers between 0 and a predetermined maximum (noise_amp). The previous elog provides the variation of the y coordinate. In this, I am also uploading the effect of noise on the error in the prediction of the x coordinate. As a reminder, the motion of the beam spot center was purely vertical. Attachement #1 is the error for noise_amp = 0, #2 for noise_amp = 20 and #3 for noise_amp = 40. While Attachment #3 does provide the impression of there being a large error, this is not really the case as without normalization, each peak corresponds to a deviation of one pixel about the central value, see Attachement #4 for reference. 2. While the error does increase marginally, adding noise has no significant effect on the prediction of the y coordinate of the centroid as Attachment #5 shows at noise_amp = 40. 3. I am currently running an experiment to obtain the variation of mean square error with different noise amplitudes and will put up the plots soon. Further, I shall vary the resolution of the image frames and the the standard deviation of the Gaussain beam with time and try to obtain simulations very close to the real data available and then determine the performance of the algorithm. 4. The following videos will serve as a quick reference for what the videos and detection look like at 1. noise_amp = 20 2. noise_amp = 40 5. I also performed a quick experiment to see how low the amplitude of motion could be before the algorithm falied to detect the motion and found it to occur at 2 orders of magnitude below the values used in the previous post. This is a line of thought I intend to pursue more carefully and I am looking into how opencv and python handle images with floats as coordinates and will provide more details about the previous trial soon. This should give us an idea of what the smallest motion of the beam spot that can be resolved is.  Quote: Implemented image level noise for simulation. Added only uniform random noise. Implemented addition of uniform random noise to any sinusoidal motion of beam spot. Implemented motion along y axis according to data in "power_spectrum" file. Impelemented simulation of random motion of beam spot in both x and y directions (done previously by Pooja, but a cleaner version). Created a video file for 10s with motion of beam spot along the y direction as given by Attachment #1. This was created by mixing four sinusoids at different amplitudes (frequencies (0.1, 0.2, 0.4, 0.8) Hz Amplitudes as fractions of N = 64 (0.1 0.09 0.08 0.09). FPS = 10. Total number of frames = 100 for the sake of convenience. See Attachment #5. Following this, I used the thresholding (threshold = 127, chosen arbitrarily), contour detection and centroid computation sequence (see Attachment #6 for results) to obtain the plot in Attachment 2 for the predicted motion of the y coordinate. As is evident, the centering and scale of values obtained are off and I still haven't figured out how to precisely convert from one to another. Consequently, as a workaround, I simply normalised the values corresponding to each plot by subtracting the mean in each case and dividing the resulting series of values by their maximum. This resulted in the plots in Attachments 3 and 4 which show the normalised values of y coordinate variation and the error between the actual and predicted values between 0 and 1 respectively. Things yet to be done: Simulation: I will implement the mean square error function to compute the relativer performance as conditions change. I will add noise both to the image and to the motion (meaning introduce some randomness in the motion) to see how the performance, determined by both the curves such as the ones below and the mean square error, changes. Following this, I will vary the standard deviation of the beam spot along X and Y directions and try to obtain beam spot motion similar to the video in Attachment #2 of elog post 14632. Currently, I have made no effort to carefully tune the parameters associated with contour detection and threshold and have simply used the popular defaults. While this has worked admirably in the case of the simple simulated videos, I suspect much more tweaking will be needed before I can use this on real data. It is an easy step to determine the performance of the algorithm for random, circular and other motions of the beam spot. However, I will defer this till later as I do not see any immediate value in this. Determine noise threshold. In simulation or with real data: obtain a video where the beam spot is ideally motionless (easy to do with simulated data) and then apply the above approach to the video and study the resulting predicted motion. In simulation, I expect the predictions for a motionless beam spot video (without noise) to be constant. Therefore, I shall add some noise to the video and study the prediction of the algorithm. NOTE: the above approach relies on some previous knowledge of what the video data will look like. This is useful in determining which contours to ignore, if any like the four bright regions at the corners in this video. Real data: Obtaining real data and evaluate if the algorithm is succesful in determining contours which can be used to track the beam spot. Once the kind of video feed this will be used on is decided, use the data generated from such a feed to determine what the best settings of hyperparameters are and detect the beam spot motion. Synchronization of data stream regarding beam spot motion and video. Determine the calibration: anglular motion of the optic to beam spot motion on the camera sensor to video to pixel mapping in the frames being processed. Other approaches: Review work done by Gabriele with CNNs, implement it and then compare performance with the above method. Attachment 1: residue_normalised_x.pdf Attachment 2: residue_normalised_x.pdf Attachment 3: residue_normalised_x.pdf Attachment 4: predicted_motion_x.pdf Attachment 5: normalised_comparison_y.pdf 9326 Fri Nov 1 17:01:46 2013 GabrieleSummaryLSCSimulation of REFL_3f signal when the arms come in I simulated how the 3f signal is affected by the resonance condition of the arms. To keep it simple, I only simulated a double cavity. The attached plot shows the result. In x there is the arm cavity detuning from resonance (in log scale to show what happens close to the 0 value). In the y axis there is the PRC detuning. So every vertical slice of the upper plot gives a PDH signal for a given arm detuning. The bottom plot shows the power build up inside the arm, which is dominated by the carrier. The 3f signal is not perturbed in any significant way by the arm resonance condition. This is good and what we expected. However, in this simulation I had to ensure that the 1f sidebands are not perfectly anti-resonant inside the arms. They are indeed quite far away from resonance. If the modulation frequency is chosen in order to make the 1f sidebands exactly ant-resonant, the 2f will be resonant. This screws up the signal: REFL_3f is made of two contributions of equal amplitude, one on the PRC sidebands resonance and the other on the PRC carrier resonance. When the arm tuning goes to zero, these two cancels out and there is no more PDH... However, this is a limit case, since the frequency show match perfectly. If the modulation frequency is few arm line widths away from perfect anti-resonance, we have no problem. 9327 Fri Nov 1 17:44:06 2013 KojiSummaryLSCSimulation of REFL_3f signal when the arms come in Yes, the resonance of the 2nd-order sidebands to the IFO screws up the 3f scheme. 2f (~22MHz) and 10f (~110MHz) are at x 5.6 and x 27.9 FSR from the carrier, so that's not the case. Could we also see how much gain fluctuation of the 3f signals we would experience when the arm comes into the resonance? 9337 Mon Nov 4 14:11:23 2013 GabrieleSummaryLSCSimulation of REFL_3f signal when the arms come in  Quote: Yes, the resonance of the 2nd-order sidebands to the IFO screws up the 3f scheme. 2f (~22MHz) and 10f (~110MHz) are at x 5.6 and x 27.9 FSR from the carrier, so that's not the case. Could we also see how much gain fluctuation of the 3f signals we would experience when the arm comes into the resonance? From the simulation there is no visible change in the gain. 16934 Tue Jun 21 18:41:46 2022 TomislavUpdateASCSimulation plot In the attachment please find a comparison of error signals of simulation and reality. For C1:IOO-WFS1/2_PIT_IN1 excess signal ('belly') between a few Hz up to 70-80 Hz might be caused by air turbulence (which is not included in the simulation). Attachment 1: sens_output_comparison.png 16930 Mon Jun 20 19:46:04 2022 TomislavUpdateASCSimulation plots In the attachment please find IMC ASC simulation plots. Let me know what you think, if you want some other plots, and if you need any clarification. Attachment 1: pit_mot_cl_MCs.png Attachment 2: loc_damp_cl_MCs.png Attachment 3: contr_output_cl_MCs.png Attachment 4: sens_output_cl_MCs.png Attachment 5: BS_motion_cl_MCs.png 11564 Thu Sep 3 02:12:08 2015 ranaUpdateCDSSimulink Webview updated Back in 2011, JoeB wrote some entries on how to automatically update the Simulink webview stuff. Somehow, the cron broke down over the years. I reran the matlab file by hand today and it worked fine, so now you can see the up to date models using the internet. https://nodus.ligo.caltech.edu:30889/FE/ 11567 Thu Sep 3 13:25:40 2015 ranaUpdateCDSSimulink Webview updated added the cron script for this to megatron to run at 8:44 AM each morning. Here's the new MegaCron attached :-()- ** it takes ~13 minutes to complete on megatron Attachment 1: crontab_150903.rtf MAILTO=ericq@caltech.edu # m h dom mon dow command #0 */1 * * * bash /home/controls/public_html/summary/bin/c1_summary_page.sh > /dev/null 2>&1 #15 5 * * * /ligo/apps/nds2/nds2-megatron/test-restart # MEDM Screen caps for the webpage 2,13,25,37,49 * * * * /cvs/cds/project/statScreen/bin/cronjob.sh # op340m transplants -ericq  ... 18 more lines ... 12727 Tue Jan 17 20:47:23 2017 ranaUpdateCDSSimulink Webview updated Seems like this stops working every ~2 years. Its been busted since early 2016 according to cron, so I fixed up the paths and restored some missing files and committed things to the SVN (with comments!) and now its working and grabbing the Web viewable versions of the front end models. Just need to restore its viewability and then the world can watch our models any time.  Quote: Back in 2011, JoeB wrote some entries on how to automatically update the Simulink webview stuff. Somehow, the cron broke down over the years. I reran the matlab file by hand today and it worked fine, so now you can see the up to date models using the internet. https://nodus.ligo.caltech.edu:30889/FE/ 8299 Fri Mar 15 02:14:27 2013 JenneUpdateCDSSimulink linking to wrong library part Jamie and I discovered a problem with Matlab/Simulink earlier today. In the end suspension models, there is a subblock (with top_names) for ALS stuff. Inside there, we use a library part called "ALS_END". When the model was created, it included the part ...../userapps/release/isc/c1/models/ALS_END.mdl . However, if you open up the c1scy diagram and look in the ALS block for this part, you see the part that is in ..../userapps/release/isc/common/models/ALS_END.mdl . Note the difference - the one we want is in the c1 directory, while the one that was created (by Jamie) for the LHO One Arm Test is in the common directory. If you compile the c1scy model, the RCG is using the correct library part, so the information regarding which part we want is still in there. However, if you delete the ALS_END part from the model, put the correct one in, save, close, then reopen the model, it once again displays the wrong model. The right click "go to library part" option brings you to the library part that is displayed, which is currently the wrong one. THIS IS BAD, since we could start modifying the wrong things. You do get a warning by Matlab about the file being "shadowed", so we should take heed when we see that warning, and make sure we are getting the file we want. We are currently running Matlab version 7.11.0.584, which is r2010b. Step 1 will be to update Matlab to the latest version, in hopes that this fixes things. We also should change the name of our c1 part, so that it does not have the same name as the one for the sites. This is not a great solution since we can't guarantee that we will never choose the same names as other sites, but it will at least fix this one case. Again, if you see the warning about "shadowed" filenames, pay attention. 16168 Fri May 28 17:32:48 2021 AnchalSummaryALSSingle Arm Actuation Calibration with IR ALS Beat I attempted a single arm actuation calibration using IR beatnote (in the directions of soCal idea for DARM calibration) ## Measurement and Inferences: • I sent 4 excitation signals at C1:SUS-ITM_LSC_EXC wit 30cts at 31Hz, 200cts at 197Hz, 600cts at 619Hz and 1000cts at 1069 Hz. • These were sent simultaneously using compose function in python awg. • The XARM was locked to mai laser and alignment was optimized with ASS. • The Xend Green laser was locked to XARM and alignment was optimized. • Sidenote: GTRX is now normalized to give 1 at near maximum power. • Green lasers can be locked with script instead of toggling. • Script can be called from sitemap->ALS->! Toggle Shutters->Lock X Green • Script is present at scripts/ALS/lockGreen.py. • C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ was measured for 60s. • Also, measured C1:LSC-XARM_OUT_DQ and C1:SUS-ITMX_LSC_OUT_DQ. • Attachment 1 shows the measured beatnote spectrum with excitations on in units of m/rtHz. • It also shows resdiual displacement contribution PSD of (output referred) XARM_OUT and ITMX_LSC_OUT to the same point in the state space model. • Note: that XARM_OUT and ITMX_LSC_OUT (excitation signal) get coherently added in reality and hence the beatnote spectrum at each excitation frequency is lower than both of them. • The remaining task is to figure out how to calculate the calibration constant for ITMX actuation from this information. • I need more time to understand the mixture of XARM_OUT and ITMX_LSC_OUT in the XARM length node in control loop. • Beatnote signal tells us the actual motion of the arm length, not how much ITMX would have actuated if the arm was not locked. • Attachment 2 has the A,B,C,D matrices for the full state space model used. These were fed to python controls package to get transfer functions from one point to another in this MIMO. • Note, that here I used the calibration of XARM_OUT we measured earlies in 16127. • On second thought, maybe I should first send excitation in ETMX_LSC_EXC. Then, I can just measure ETMX_LSC_OUT which includes XARM_OUT due to the lock and use that to get calibration of ETMX actuation directly. Attachment 1: SingleArmActCalwithIRALSBeat.pdf Attachment 2: stateSpaceModel.zip 16171 Tue Jun 1 16:55:32 2021 Anchal, PacoSummaryALSSingle Arm Actuation Calibration with IR ALS Beat Rana suggested in today's meeting to put in a notch filter in the XARM IR PDH loop to avoid suppressing the excitation line. We tried this today first with just one notch at 1069 Hz and then with an additional notch at 619 Hz and sent two simultaneous excitations. ## Measurement and Analysis: • We added notch filters with Q=10, depth=50dB, freq=619 Hz and 1069 Hz using foton in SUS-ETMX_LSC filter bank at FM10. • We sent excitation signals with amplitudes 600cts and 1000 cts for 619 Hz and 1069 Hz signals respectively. • We measured time series data of C1:SUS-ITMX_LSC_OUT_DQ and C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ for 60s. • Then, spectrum of both signals is measured with Hanning window using scipy.welch function with scaling set to 'spectrum', binwidth=1Hz. • The beatnote signal was converted into length units by multiplying it by 1064nm * 37.79m / c. • The ratio of the two spectrums at teh excitation frequency multiplies by excitation frequency squared gives us teh calibration constant in units of nm Hz^2/cts. • At 619 Hz, we got $\frac{5.01}{f^2}$nm/cts • At 1069 Hz, we got $\frac{5.64}{f^2}$nm/cts. • The calibration factor in use is from $\frac{7.32}{f^2}$ nm/cts from 13984. • So, the calibration factor from this methos is about 23% smaller than measured using freeswinging MICH in 13984. • One possiblity is that our notch filter is not as effective in avoiding suppresion of excitation. • We tried increasing the notch filter depths to 100 dB but got the same result within 2%. • We tried changing the position of notch filters. We put them in POX filter banks. Again the result did not change more than 2%. • The open loop gain of green PDH at 619 Hz and 1069 Hz must be large enough for our assumption of green laser perfectly following length motion to be true. The UGF of green laser is near 11 kHz. • The discrepancy could be due to outdated freeswinging MICH measurement that was done 3 years ago. Maybe we should learn how to do the ITMX calibration using this method and compare our own two measurements. Attachment 1: SingleArmActCalwithIRALSBeat-1306624785.pdf 16192 Tue Jun 8 11:40:53 2021 Anchal, PacoSummaryALSSingle Arm Actuation Calibration with IR ALS Beat We attempted to simulate "oscillator based realtime calibration noise monitoring" in offline analysis with python. This helped us in finding about a factor of sqrt(2) that we were missing earlier in 16171. we measured C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ when X-ARM was locked to main laser and Xend green laser was locked to XARM. An excitation signal of amplitude 600 was setn at 619 hz at C1:ITMX_LSC_EXC. ## Signal analysis flow: • The C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ is calibrated to give value of beatntoe frequency in Hz. But we are interested in the fluctuations of this value at the excitation frequency. So the beatnote signal is first high passed with 50 hz cut-off. This value can be reduced a lot more in realtime system. We only took 60s of data and had to remove first 2 seconds for removing transients so we didn't reduce this cut-off further. • The I and Q demodulated beatntoe signal is combined to get a complex beatnote signal amplitude at excitation frequency. • This signal is divided by cts amplitude of excitation and multiplied by square of excitation frequency to get calibration factor for ITMX in units of nm/cts/Hz^2. • The noise spectrum of absolute value of the calibration factor is plotted in attachment 1, along with its RMS. The calibration factor was detrended linearly so the the DC value was removed before taking the spectrum. • So Attachment 1 is the spectrum of noise in calibration factor when measured with this method. The shaded region is 15.865% - 84.135% percentile region around the solid median curves. We got a value of $\frac{7.3 \pm 3.9}{f^2}\, \frac{nm}{cts}$. The calibration factor in use is from $\frac{7.32}{f^2}$ nm/cts from 13984. Next steps could be to budget this noise while we setup some way of having this calibration factor generated in realitime using oscillators on a FE model. Calibrating actuation of a single optic in a single arm is easy, so this is a good test setup for getting a noise budget of this calibration method. Attachment 1: ITMX_Cal_Noise_Spectrum_1307143423.pdf 16242 Fri Jul 9 15:39:08 2021 AnchalSummaryALSSingle Arm Actuation Calibration with IR ALS Beat [Correction] I did this analysis again by just doing demodulation go 5s time segments of the 60s excitation signal. The major difference is that I was not summing up the sine-cosine multiplied signals, so the error associated was a lot more. If I simply multpy the whole beatnote signal with digital LO created at excitation frequency, divide it up in 12 segments of 5 s each, sum them up individually, then take the mean and standard deviation, I get the answer as: $\frac{6.88 \pm 0.05}{f^2} nm/cts$as opposed to $\frac{7.32 \pm 0.03}{f^2} nm/cts$that was calculated using MICH signal earlier by gautum in 13984. Attachment 1 shows the scatter plot for the complex calibration factors found for the 12 segments. My aim in the previous post was however to get a time series of the complex calibration factor from which I can take a noise spectral density measurement of the calibration. I'll still look into how I can do that. I'll have to add a low pass filter to integrate the signal. Then the noise spectrum up to the low pass pole frequency would be available. But what would this noise spectrum really mean? I still have to think a bit about it. I'll put another post soon. Quote: We attempted to simulate "oscillator based realtime calibration noise monitoring" in offline analysis with python. This helped us in finding about a factor of sqrt(2) that we were missing earlier in 16171. we measured C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ when X-ARM was locked to main laser and Xend green laser was locked to XARM. An excitation signal of amplitude 600 was setn at 619 hz at C1:ITMX_LSC_EXC. ## Signal analysis flow: • The C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ is calibrated to give value of beatntoe frequency in Hz. But we are interested in the fluctuations of this value at the excitation frequency. So the beatnote signal is first high passed with 50 hz cut-off. This value can be reduced a lot more in realtime system. We only took 60s of data and had to remove first 2 seconds for removing transients so we didn't reduce this cut-off further. • The I and Q demodulated beatntoe signal is combined to get a complex beatnote signal amplitude at excitation frequency. • This signal is divided by cts amplitude of excitation and multiplied by square of excitation frequency to get calibration factor for ITMX in units of nm/cts/Hz^2. • The noise spectrum of absolute value of the calibration factor is plotted in attachment 1, along with its RMS. The calibration factor was detrended linearly so the the DC value was removed before taking the spectrum. • So Attachment 1 is the spectrum of noise in calibration factor when measured with this method. The shaded region is 15.865% - 84.135% percentile region around the solid median curves. We got a value of $\frac{7.3 \pm 3.9}{f^2}\, \frac{nm}{cts}$. The calibration factor in use is from $\frac{7.32}{f^2}$ nm/cts from 13984. Next steps could be to budget this noise while we setup some way of having this calibration factor generated in realitime using oscillators on a FE model. Calibrating actuation of a single optic in a single arm is easy, so this is a good test setup for getting a noise budget of this calibration method. Attachment 1: ITMX_calibration_With_ALS_Beat.pdf 1757 Thu Jul 16 10:52:58 2009 ClaraUpdatePEMSingle Channel TRS-RNC Cable I made and tested a female-to-female TRS(audio)-RNC cable. It only has a single channel, so it won't work for stereo speakers or anything, but I should only need one speaker for testing the microphones. The tip of the plug is the signal, the sleeve is ground, and the ring is null. 1432 Thu Mar 26 04:09:38 2009 YoichiUpdateIOOSingle X arm lock spectra with different MC lock schemes The attached plots show MC_F, FSS_FAST_F and XARM IN/OUT spectra with different MC locking modes. The conventional locking means the FSS is used. The direct frequency lock is the new way. You can see that at low frequencies, the frequency actuator is working hard to suppress the MC pendulum motions. The X-arm also sees a lot of frequency noise at low frequencies because of this. The transmitted power of the X-arm fluctuates a lot making it difficult to align the mirrors. The zoomed plots show that the structures in the kHz band are also present in the case of the direct frequency lock, although the frequencies are somewhat different. Attachment 1: XarmSpectra.pdf Attachment 2: XarmSpectraZoom.pdf 11061 Tue Feb 24 18:54:26 2015 ericqUpdateASCSingle arm QPD ASC stability I've lowered the UGFs for the transmission QPD servos to ~1-2Hz, and made it just an integrator. I left the arms locked with the QPD servos on for a few hours during the daytime today, and they succesfully prevented the Y arm from losing power from alignment drift for ~4 hours. Turning the servo off caused TRY to drop to ~0.6 or so. The X arm was only held for 2 hours or so, because after some unlock/drift event the power was below the servo trigger threshold. However, after gently nudging ETMX to get the transmission above the threshold, the servo kicked in, and brought it right back to TRX=1.0 Unfortunately, daqd was dead for much of the day, so I don't have much data to show; the trend was inferred from the wall striptool. It is not proven that there aren't further issues that prevent this from working with higher / more dynamic arm powers, but this is at least a point in favor of it working. EDIT: Here's a screenshot of the wall StripTool. Brown is TRY, blue is TRX. The downturn at the very end is me deactivating the servos. There is no scientific justifcation for the 0.9 threshold. Really, I should look at the noise/SNR again, now that there is some ND filtering on the QPDs. Attachment 1: trend.png 15611 Mon Oct 5 00:37:19 2020 gautamUpdateBHDSingle bounce interferometer locked Summary: The simple interferometer, composed of a single bounce reflection from ITMY and the LO beam deilvered via fiber to the AS table, can be locked - i.e. the phase of the LO beam can be controlled such that the DC light level on the DCPDs after the two beams are interfered can be stabilized. This test allows us to confirm that various parts of the sensing and actuation chain (e.g. PI PZT for homodyne phase control, Trek amplifier etc etc) are working. I will post more quantitative analysis tomorrow. Optical configuration: • LO beam is a pickoff of the main PSL beam from just before it goes into the vacuum. The optical power arriving on each DCPD after the various beamsplitters, coupling loss etc is ~200 uW. • IFO beam is the single bounce reflection from ITMY. For this test, ETMY, ITMX and ETMY are misaligned. Optical power arriving on each DCPD is ~80uW. • The two beams are interfered on a 50-50 beamsplitter. The mode-matching efficiency was estimated to be ~50% which isn't stellar, but should be fine for this test. • So, at half-fringe, we expect the signal on each DCPD to be linearly proportional to the phase difference between the two fields, and so we can use that as an error signal. Servo topology: Attachment #2 shows the servo topology. • For a first attempt to close the feedback loop, we can consider the two blocks labelled "Sensing Chain" and "Actuation chain" to have a flat frequency response. While this isn't true, for a taget loop with ~100 Hz UGF, I think the approximation is reasonable. • From the peak-to-peak value (160 cts) of the DCPD signals when the homodyne phase is uncontrolled, I estimate a sensing response (at half-fringe) of approximately 0.3 ct/nm, since this corresponds to 532nm of relative phase between the two beams. • An inverting summing amplifier is used to map the +/- 2^15 ct DAC range to 0-125V on the PI PZT. Assuming the full stroke of the PZT is 10um per the datasheet, and that this voltage range drives half of the full stroke (this is just a guess since all the old PI PZT circuits were designed to work at 0-250 V), we get an actuation coefficient of 0.075 nm/ct. • Using these two numbers, we can then design a digital feedback loop that gives an open loop transfer function with ~100 Hz UGF, and sufficient stability margin. • From the earlier measurements, we have an estimate for the amount of phase fluctuations caused by (i) seismic disturbances and (ii) fiber phase noise. This is the quantity we wish to suppress, and the suppression factor will be 1/(1+L), where L is the open loop gain. • I didn't do this in any systematic way, but the loop in Attachment #3 seemed like a reasonable shape that would suppress the error signal RMS by ~10x, as shown in Attachment #4. So I decided to try this out. Other notes: 1. The idea of offloading the DC control voltage to the ITMY suspension seemed to work fine. 2. It also seems like the relative phase between the two beams doesn't drift by so large an amount in short time scales, at least at night/quiet seismic conditions. So it is possible to maintain the lock for several seconds without having to offload the DC signal to the suspensions. 3. I didn't bother adapting the FSS Slow PID script to do this offloading in an automated way, seemed like more trouble than was just doing it by hand. But we may want to automate this in the future. 4. I couldn't make a clean measurement of the loop transfer function using the usual IN1/IN2 method. Introducing a step offset at the error point, the servo is able to track it (I didn't fit the step response time, but it's not as if the loop bandwidth is <1 Hz or something). I have to compare the measured in-loop error signal ASD to the free-running one to get a feel for what the UGF is, I guess, to rule out a weird loop. 5. Update 1100 Oct 6 2020: I have now added measured, in-loop, error point spectra to Attachment #4. Looks like there might be significant sensing noise re-injection. • Initially, I forgot to turn the HEPA on the PSL down for the measurement. So I have the two traces to compare. Looks like with the HEPA turned up to full, there is more noise in the 50-200 Hz range. • The trace marked "highGain" was taken with an overall loop gain that was 3dB higher than the nominal value - I could see some oscillations start to appear, and in the spectrum, maybe the feature at ~150 Hz is evidence of some gain peaking? Conclusions: 1. The PI PZT seems to work just fine. 2. Need to look into the loop shape. I guess it's not reasonable to expect a UGF much higher than 100-200 Hz, because of the various delays in the system, but maybe the low frequency suppression can be made better. 3. What are the next steps?? What does this mean for the RF44 sensing scheme? Attachment 1: simpleHomodyne.png Attachment 2: singleBounceIFO.pdf Attachment 3: proposedController.pdf Attachment 4: freeRunningSuppressed.pdf 15612 Mon Oct 5 00:53:16 2020 KojiUpdateBHDSingle bounce interferometer locked 🤘🤘🤘 15290 Wed Apr 1 00:51:41 2020 gautamUpdateWienerSlightly improved MCL FF Summary: Retraining the MCL filters resulted in a slight improvement in the performance. Compared to no FF, the RMS in the 0.5-5 Hz range is reduced by approximately a factor of 3 Details: Attachment #1 shows my re-measurement of the MC2 position drive to MCL transfer function. • The measurement was made using DTT swept sine, with the amplitude enveloped appropriately to avoid knocking the IMC out of lock. • Coherence was >0.97 for all datapoints. • Fitting was done using Lee's IIRrational, with the weighting being the coherence. I think there are some features of the fitting I don't fully understand, but I wanted to try and do everything in python and for this simple fit, it came out nicely I think. Attachment #2 shows the IIR fits to the FIR filters calculated here • Again, IIRrational was used. • In the frequency band where subtraction is possible, the fit is good. • But there is definitely room for improvement in the way this is done, for now, I did quite a bit "by eye" and tweaked the order of the filter and the minimum number of excess poles relative to zeros to get the AC coupling, but it'd be nice to make all of this iterative and quantitative (e.g. by minimizing a cost function). • One nice feature of IIRrational is that it directly gives me a formatted string I can paste into foton. The order of these fits were 22, so I split them into two 19+3 order filters to be compatible with the realtime system before loading the coefficients (the overall gain was allocated to a single filter arbitrarily, with the other filter in the pair set to have unity gain in the zpk representation). Attachment #3 shows several MCL spectra. • Blue trace is the unsubtracted test dataset. • Red is the performance of the calculated FIR filter, but the filtering is done offline. • Gold is the performance of the IIR fit to the FIR filter, as shown in Attachment #2, applied offline to the test dataset. • Green is the calculated ASD of MCL from a ~1 hour stretch from earlier tonight, when I left the feedforward loop on. So this is an actual measurement of the online performacne of the filter. • Grey is the performance of the old filter loaded in the CDS system - the filtering is done using scipy, and the sos coefficients from the C1OAF.txt file. Conclusions + next steps 1. Retraining the filters has resulted in a slight improvement, especially at ~3 Hz. 2. More tests need to be done to confirm that noise isn't being reinjected in the frequency bands where subtraction isn't possible (e.g. using arm cavities as OOL sensors). 3. The online filter isn't quite as good as what we would expect from calculations (green trace is noisier than gold). Need to think about why this is. 4. Why can't we get more subtraction at 1 Hz? 5. Now that I have the infrastructure ready, I will attempt to revive the PRC angular FF loops, which was the whole point of this exercise. Attachment 1: MC2_act_calib.pdf Attachment 2: IIR_fit_to_FIR.pdf Attachment 3: FIRvIIR.pdf 12290 Tue Jul 12 09:18:12 2016 ericqUpdateGeneralSlippery substance mystery I found a note on Steve's desk that R. Abbott left yesterday afternoon about an unidentified slippery substance being present on the floor by cabinet S12, along the X arm. (Steve is away this week) Just now, I found no trace of the substance in the vicinity of that cabinent (which is one of the cabinets for clean objects). Maybe the janitor cleaned it already? 12291 Tue Jul 12 09:35:51 2016 JohannesUpdateGeneralSlippery substance mystery I've noticed the spot that Rich means before, too. I think you only notice this when you're wearing the shoe covers, not sneakers or crocs. I didn't see any 'substance', it seems more like the floor finish (wax?) seems to be more slippery in that area than others.  Quote: I found a note on Steve's desk that R. Abbott left yesterday afternoon about an unidentified slippery substance being present on the floor by cabinet S12, along the X arm. (Steve is away this week) Just now, I found no trace of the substance in the vicinity of that cabinent (which is one of the cabinets for clean objects). Maybe the janitor cleaned it already? 13443 Wed Nov 22 00:54:18 2017 johannesOmnistructureComputersSlow DAQ replacement computer progress I got the the SuperMicro 1U server box from Larry W on Monday and set it up in the CryoLab for initial testing. The processor is an Intel D525 dual core atom processor with 1.8 GHz (i386 architecture, no 64-bit support). The unit has a 250GB SSD and 4GB RAM. I installed Debian Jessie on it without any problems and compiled the most recent stable versions of EPICS base (3.15.5), asyn drivers (4-32), and modbus module (2-10-1). EPICS and asyn each took about 10 minutes, and modbus about 1 minute. I copied the database files and port driver definitions for the cryolab from cryoaux, whose modbus services I suspended, and initialized the EPICS modbus IOC on the SuperMicro machine instead. It's working flawlessly so far, but admittedly the box is not under heavy load in the cryolab, as the framebuilder there is logging only the 16 analog channels. I have recently worked out some kinks in the port driver and channel definitions, most importantly: • mosbus IOC initialization is performed automatically by systemd on reboot • If the IOC crashes or a system reboot is required the Acromag units freeze in their last current state. When the IOC is started a single read operation of all A/D registers is performed and the result taken as the initial value of the corresponding channel, causing no discontinuity in generated voltage EVER (except of course for the rare case when the Acromags themselves have to be restarted) Aaron and I set 12/4 as a tentative date when we will be ready to attempt a swap. Until then the cabling needs to be finished and a channel database file needs to be prepared. 13458 Wed Nov 29 21:40:30 2017 johannesOmnistructureComputersSlow DAQ replacement computer progress [Aaron, Johannes] We configured the AtomServer for the Martian network today. Hostname is c1auxex2, IP is 192.168.113.49. Remote access over SSH is enabled. There will be 6 acromag units served by c1auxex2.  Hostname Type IP Address c1auxex-xt1221a 1221 192.168.113.130 c1auxex-xt1221b 1221 192.168.113.131 c1auxex-xt1221c 1221 192.168.113.132 c1auxex-xt1541a 1541 192.168.113.133 c1auxex-xt1541b 1541 192.168.113.134 c1auxex-xt1111a 1111 192.168.113.135 Some hardware to assemble the Acromag box and adapter PCBs are still missing, and the wiring and channel definitions have to be finalized. The port driver initialization instructions and channel definitions are currently locally stored in /home/controls/modbusIOC/ but will eventually be migrated to a shared location, but we need to decide how exactly we want to set up this infrastructure. • Should the new machines have the same hostnames as the ones they're replacing? For the transition we simply named it c1auxex2. • Because the communication of the server machine with the DAQ modules is happening over TCP/IP and not some VME backplane bus we could consolidate machines, particularly in the vertex area. • It would be good to use the fact that these SuperMicro servers have 2+ ethernet ports to separate CDS EPICS traffic from the modbus traffic. That would also keep the 30+ IPs for the Acromag thingies off the Martian host tables. 13185 Thu Aug 10 14:25:52 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled I went into /opt/rtcds/caltech/c1/target/daqd, opened the master file, and uncommented the line with C0EDCU.ini (this is the file in which all the slow machine channels are defined). So now I am able to access, for example, the c1vac1 channels. The location of the master file is no longer in /opt/rtcds/caltech/c1/target/fb, but is in the above mentioned directory instead. This is part of the new daqd paradigm in which separate processes are handling the data transfer between FEs and FB, and the actual frame-writing. Jamie will explain this more when he summarizes the CDS revamp. It looks like trend data is also available for these newly enabled channels, but thus far, I've only checked second trends. I will update with a more exhaustive check later in the evening. So, the two major pending problems (that I can think of) are: 1. Inability to unload models cleanly 2. Inability of dataviewer (and cdsutils) to open testpoints. Apart from this, dataviewer frequently hangs on Donatella at startup. I used ipcs -a | grep 0x | awk '{printf( "-Q %s ",1 )}' | xargs ipcrm to remove all the extra messages in the dataviewer queue.

Restarting the daqd processes on fb1 using Jamie's instructions from earlier in this thread works - but the mx_stream processes do not seem to come back automatically on c1lsc, c1sus and c1ioo (reasons unknown). I've made a copy of the mxstreamrestart.sh script with the new mxstream restart commands, called mxstreamrestart_debian.sh, which lives in /opt/rtcds/caltech/c1/scripts/cds. I've also modified the CDS overview MEDM screen such that the "mxstream restart" calls this modified script. For now, this requires you to enter the controls password for each machine. I don't know what is a secure way to do it otherwise, but I recall not having to do this in the past with the old mxstreamrestart.sh script.

13189   Fri Aug 11 00:10:03 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled

### Seems like something has failed after I did this - full frames are no longer on Aug 10 being written since ~2.30pm PDT. I found out when I tried to download some of the free-swinging MC1 data.

To clarify, I logged into fb1, and ran sudo systemctl restart daqd_*. The only change I made was to uncomment the line quoted below in the master file.

Looking at the log using systemctl, I see the following (I just tried restarting the daqd processes again):

Aug 11 00:00:31 fb1 daqd_fw[16149]: LDASUnexpected::unexpected: Caught unexpected exception      "This is a bug. Please log an LDAS problem report including this message. Aug 11 00:00:31 fb1 daqd_fw[16149]: daqd_fw: LDASUnexpected.cc:131: static void LDASTools::Error::LDASUnexpected::unexpected(): Assertion false' failed. Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service: main process exited, code=killed, status=6/ABRT Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state. Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service holdoff time over, scheduling restart. Aug 11 00:00:32 fb1 systemd[1]: Stopping Advanced LIGO RTS daqd frame writer... Aug 11 00:00:32 fb1 systemd[1]: Starting Advanced LIGO RTS daqd frame writer... Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service start request repeated too quickly, refusing to start. Aug 11 00:00:32 fb1 systemd[1]: Failed to start Advanced LIGO RTS daqd frame writer. Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state.

### Oddly, I am able to access second trends for the same channels from the past which will be useful for the MC1 debugging). Not sure whats going on.

The live data grabbing using cdsutils still seems to be working though - so I've kicked MC1 again, and am grabbing 2 hours of data live on Pianosa.

 Quote: I went into /opt/rtcds/caltech/c1/target/daqd, opened the master file, and uncommented the line with C0EDCU.ini (this is the file in which all the slow machine channels are defined). So now I am able to access, for example, the c1vac1 channels. The location of the master file is no longer in /opt/rtcds/caltech/c1/target/fb, but is in the above mentioned directory instead. This is part of the new daqd paradigm in which separate processes are handling the data transfer between FEs and FB, and the actual frame-writing. Jamie will explain this more when he summarizes the CDS revamp. It looks like trend data is also available for these newly enabled channels, but thus far, I've only checked second trends. I will update with a more exhaustive check later in the evening. So, the two major pending problems (that I can think of) are: Inability to unload models cleanly Inability of dataviewer (and cdsutils) to open testpoints. Apart from this, dataviewer frequently hangs on Donatella at startup. I used ipcs -a | grep 0x | awk '{printf( "-Q %s ", \$1 )}' | xargs ipcrm to remove all the extra messages in the dataviewer queue. Restarting the daqd processes on fb1 using Jamie's instructions from earlier in this thread works - but the mx_stream processes do not seem to come back automatically on c1lsc, c1sus and c1ioo (reasons unknown). I've made a copy of the mxstreamrestart.sh script with the new mxstream restart commands, called mxstreamrestart_debian.sh, which lives in /opt/rtcds/caltech/c1/scripts/cds. I've also modified the CDS overview MEDM screen such that the "mxstream restart" calls this modified script. For now, this requires you to enter the controls password for each machine. I don't know what is a secure way to do it otherwise, but I recall not having to do this in the past with the old mxstreamrestart.sh script.

13192   Fri Aug 11 11:14:24 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled

I commented out the line pertaining to C0EDCU again, now full frames are being written again.

I am not sure what the failure mode is here - In the master file, there is a line that says the EDCU list "*MUST* COME *AFTER* ALL OTHER FAST INI DEFINITIONS" which it does. But there are a bunch of lines that are testpoint lists after this EDCU line. I wonder if that is the problem?

Quote:

### Seems like something has failed after I did this - full frames are no longer on Aug 10 being written since ~2.30pm PDT. I found out when I tried to download some of the free-swinging MC1 data.

13197   Fri Aug 11 18:53:35 2017 gautamUpdateCDSSlow EPICS channels -> Frames re-enabled
Quote:

### Seems like something has failed after I did this - full frames are no longer on Aug 10 being written since ~2.30pm PDT. I found out when I tried to download some of the free-swinging MC1 data.

To clarify, I logged into fb1, and ran sudo systemctl restart daqd_*. The only change I made was to uncomment the line quoted below in the master file.

Looking at the log using systemctl, I see the following (I just tried restarting the daqd processes again):

Aug 11 00:00:31 fb1 daqd_fw[16149]: LDASUnexpected::unexpected: Caught unexpected exception      "This is a bug. Please log an LDAS problem report including this message. Aug 11 00:00:31 fb1 daqd_fw[16149]: daqd_fw: LDASUnexpected.cc:131: static void LDASTools::Error::LDASUnexpected::unexpected(): Assertion false' failed. Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service: main process exited, code=killed, status=6/ABRT Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state. Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service holdoff time over, scheduling restart. Aug 11 00:00:32 fb1 systemd[1]: Stopping Advanced LIGO RTS daqd frame writer... Aug 11 00:00:32 fb1 systemd[1]: Starting Advanced LIGO RTS daqd frame writer... Aug 11 00:00:32 fb1 systemd[1]: daqd_fw.service start request repeated too quickly, refusing to start. Aug 11 00:00:32 fb1 systemd[1]: Failed to start Advanced LIGO RTS daqd frame writer. Aug 11 00:00:32 fb1 systemd[1]: Unit daqd_fw.service entered failed state.

### Oddly, I am able to access second trends for the same channels from the past which will be useful for the MC1 debugging). Not sure whats going on.

The live data grabbing using cdsutils still seems to be working though - so I've kicked MC1 again, and am grabbing 2 hours of data live on Pianosa.

So we tried this again with a fresh build of daqd_fw, and it still fails.  The error message is pointing to an underlying bug in the framecpp library ("LDASTools"), which may be tricky to solve.  I'm rustling the appropriate bushes...

8957   Thu Aug 1 21:28:09 2013 gautamUpdateCDSSlow channels set-up in ALS

The following slow channels have been added and are now being recorded by FB.

C1:ALS-X_OVEN_TEMP

C1:ALS-Y_OVEN_TEMP

C1:ALS-BEATX_FREQ

C1:ALS-BEATY_FREQ

Details:

In order to integrate the data collected by the Raspberry-Pi from the Y-end doubling oven temperature controller and also the data from the frequency counter which will be hooked up to monitor the beat frequency, Koji helped me set up some slow EPICS record channels (in ALS as we felt this was most appropriate). The procedure for setting up slow channels was as follows (virtually identical to what is detailed in this elog:

1. Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
2. Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/als.db).
3. Restart framebuilder.
4. Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

I will now integrate these channels into my scripts, and make some simple MEDM screens.

ELOG V3.1.3-