40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 204 of 344 Not logged in
ID Date Author Type Category Subject
7056   Tue Jul 31 08:01:22 2012 steveUpdateVACcc1 switched

Quote:

 Quote: Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current.  We should replace them at the next vent. I'm buying 4 at $317ea We have two CC1 gauges at the pump spool. One is in vertical position and the spare is in horizontal. Today I switched the cable from vertical to horizontal CC1 This one is reading higher pressure. It is an old dirty gauge. It may trigger the RGA protection when it's reading goes above 1e-5 torr The real pressure is 2e-6 torr cc1h spikes closed VM1 last night. VM1 is opened. Attachment 1: cc1h1d.png 7055 Tue Jul 31 00:27:52 2012 DenUpdatePEMtrillium We have a Trillium for several days from Vladimir. I've put seismometer inside the foam box on linolium. I was not able to level the seismometer on granite as this Trillium does not have level screws. Does anybody know where they are? Readout box stands on the foam box as seismometer cable is short (~2 meters). Cables go to STS1 inputs (7-9) on ADC 3. 7054 Mon Jul 30 22:52:51 2012 YaakovUpdateSTACISGeophone calibration Tonight I looked at the signal from a geophone and accelerometer side by side, in order to see if they show the same ground motion and if the sensitivity factor I am using to convert from V to m/s is right. This is plotted below, along with the current estimates for accelerometer and geophone noise: From this it is pretty clear that at least one of the sensitivity factors (V/m/s) I am using is wrong (the noise levels are much lower than the ground motion, so they can't account for the difference). I suspect it is the geophone one, because Wilcoxon provided these sensitivities for each individual accelerometer, but I was just using the number I found in online specs for the geophones. The reason the online value is wrong is probably because of the value of the shunt resistor, a resistor that just goes across the top of the geophone (its purpose is to provide damping, by Lenz's Law). The specs assume a value of 380 Ohm, but I measured the one in the STACIS to be about 1.85 kOhm. Assuming the accelerometer signal is correct, I multiplied the geophone signal by different factors to try to get an idea of what the true calibration factor is, and found that a value of 0.25 (m/s)/V gives decent agreement at higher frequencies (below 10 Hz the sensitivity drops off, according to the online specs). This is shown below: Above, the geophone noise was recalculated with the new sensitivity and assuming that both geophones in the noise measurement had the same sensitivity. I took the transfer function of two geophones side by side to see if their gains were dramatically different; this plot is shown below. The coherence is only good for a small band, but looking at that band the gain is approximately unity, implying very roughly that the sensitivity of each is approximately the same. The lack of coherence is strange, and I'm not sure what the cause is. Even using the shaker near the geophones only improved the coherence slightly. Attachment 2: sensor_comp2.bmp 7053 Mon Jul 30 17:24:45 2012 YaakovUpdateSTACISRevised sensor noise plot; dead PZT The geophone noise in my last eLog was taken before any amplification of the signal, but what really matters is the noise after amplification, since it is this signal that the PZTs are driven by. The noise goes on to be amplified about 1000x before the geophone signal gets to the PZTs. To obtain a more relevant noise plot, I multiplied the geophone noise by 1,000, the approximate gain of the amplification stage for the geophones (called the "compensator board", the semicircular board that sits toward the top of the STACIS). Below is a plot () that shows the noise for the geophones after amplification and the accelerometer noise (with accelerometers set with a gain of 100x, their highest). The actual signal from both these sensors has the right magnitude to drive the PZTs (whereas it was much too small in my last plot, where I looked at the sensors before any gain)- this means that for these sensors, both of which are outputting signals that are ready to provide feedback to the STACIS, the accelerometer noise is significantly lower than the geophone noise. This is good news, because it means that there could be a real advantage to using the accelerometers instead of the geophones. In the process of investigating further advantages of the accelerometers, I believe I killed one of the horizontal PZTs in the spare STACIS (the eBay one). The story: I had that axis in closed loop, and I saw the STACIS shudder, heard a noise, and there was a faint acrid smell. I shut the STACIS off and took out the high voltage card at the base but couldn't find any visible signs of damage (like the current-limiting resistors which burn when a PZT shorts, acc. to old STACIS records). I then tried driving the PZTs with a sine wave, and there was no response in that axis (the other axes looked fine), which leads me to believe I either did unseen damage to the high voltage amplifier (for the y-axis) or killed the PZT itself. Attachment 1: sensor_noise.bmp 7052 Mon Jul 30 16:05:36 2012 DenUpdatedigital noisefilter checker We decided to write a script that will check online filters for digital noise. One method can be implemented using the following algorithm: • calculate filter output using single precision • calculate filter output using double precision and assume that it is precise • find digital noise at the output of the filter when single precision is used • extrapolate the result to the double precision filter dividing by 2D-S ~ 107, D - number of bits used in double precision mantissa, S - in single precision Restriction: Single precision filter internal variables must be checked for overflows. I applied this method to filtering a 1 Hz sine wave with a notch filter. Precise output should also be a 1 Hz wave => at other frequencies we see noise => digital noise spectrum should coincide with filter output. The plot shows the method worked out for this example. Using this method I estimated digital noise of butter("LowPass", 2, 0.001) applied to white noise. Sampling frequency was 16 kHz. 7051 Mon Jul 30 15:49:16 2012 steveUpdateVACcc1 switched  Quote: Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current. We should replace them at the next vent. I'm buying 4 at$317ea

We have two CC1 gauges at the pump spool. One is in vertical position and the spare is in horizontal. Today I switched the cable from vertical to horizontal CC1

This one is reading higher pressure. It is an old dirty gauge. It may trigger the RGA protection when it's reading goes above 1e-5 torr

The real pressure is 2e-6 torr

Attachment 1: cc1changedfVtH.png
7050   Mon Jul 30 14:24:25 2012 DenUpdatedigital noisebiquad key is working

 Quote: What is "DQF"?  Is that the biquad?  And what is the difference between DF1 and DF2?  Why don't you just write out the name, so it's more clear.

DQF - biquad form
DF1 - direct form 1
DF2 - direct form 2
LNF - low-noise form

The difference between them is described in Matt's slides G0900928-v1. I think, LNF coefficients are incorrect in the presentation

7049   Mon Jul 30 12:38:45 2012 JamieUpdateCDSMove to RCG 2.5 tag release

I moved the RCG to the advLigoRTS-2.5 tag:

controls@c1iscey ~ 0$ls -al /opt/rtcds/rtscore/release lrwxrwxrwx 1 controls 1001 19 Jul 30 12:02 /opt/rtcds/rtscore/release -> tags/advLigoRTS-2.5 controls@c1iscey ~ 0$

There are only very minor differences between what we were running on the the 2.5 branch.  I have NOT rebuilt all the models yet.

I was hoping that there was something in the tagged release that might fix this hard-crash-on-filter-load issue that we're seeing in the c1tst model.  It didn't.  Still have no idea what's going on there.

7048   Mon Jul 30 10:05:29 2012 JenneUpdatePSLPMC is still not fixed

 Quote: The PMC was locking right the way, but it's transmission would not go up.  Finally I get it back up by moving the "sticky" DC Gain slider up and down a few times.

The FSS was -2.9, and the PMC won't lock happily unless you bring this back to 0.  The symptom that this is happening is that the PMC reflection camera is totally saturated, but the PMC still looks like it's locked on 00.

7047   Mon Jul 30 09:00:18 2012 steveUpdatePSLPMC is still not fixed

The PMC was locking right the way, but it's transmission would not go up.  Finally I get it back up by moving the "sticky" DC Gain slider up and down a few times.

Attachment 1: pmcA.png
Attachment 2: pmcB.png
7046   Fri Jul 27 16:32:17 2012 JamieUpdateCDSRCG bug exposed by simple c1tst model

As Den mentioned in 7043, attempting to run the c1tst model was causing the entire c1iscey machine to crash.  Alex came over this morning and we spend a couple of hours trying to debug what was going on.

c1tst is the simplest possible model you can have: 1 ADC and 2 filter modules.  It compiles just fine, but when you tried to load it the machine would completely freeze.

We eventually tracked this down to a non-empty filter file for one of the filter modules.  It turns out that the model was crashing when it attempted to load the filter file.  Once we completely deleted all the filters in the module, the model would run.  But then if you added back a filter to the filter file and tried to "load coefficients", the model/machine would immediately crash again.

So it has something to do with the loading of the filter coefficients from the filter file.  We tried different filters and it didn't seem to make a difference.  Alex thought it might have something to do with zeros in some of the second-order sections, but that wasn't it either.

There's speculation that it might be related to a very similar bug that Joe reported at LLO a month ago: https://bugzilla.ligo-wa.caltech.edu/bugzilla/show_bug.cgi?id=398

Things we tried, none of which worked:

• adding a DAC
• turning on/off biquad
• disabling the float denormalization fix

This is a real mystery.  Alex and I are continuing to investigate.

7045   Fri Jul 27 14:30:49 2012 JamieUpdatedigital noisebiquad key is working

What is "DQF"?  Is that the biquad?  And what is the difference between DF1 and DF2?  Why don't you just write out the name, so it's more clear.

7044   Fri Jul 27 14:28:36 2012 steveUpdateVACcold cathode gauges

Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current.  We should replace them at the next vent. I'm buying 4 at $317ea Attachment 1: cc_gauges.png 7043 Fri Jul 27 14:27:14 2012 JamieUpdateCDSnew c1tst model for testing RCG code  Quote: I wanted to test biquad form in this model. I added biquad=1 flag to cdsParameters, compiled, installed and restarted it. After that c1iscey suspended. The same thing as we had several month ago controls@c1iscey /opt/rtcds/caltech/c1/target/c1tst/c1tstepics 0$ cat iocC1.log Starting iocInit iocRun: All initialization complete sh: iniChk.pl: command not found Failed to load DAQ configuration file

I have fixed the iniChk.pl issue (which actually fixed a separate model startup-on-boot issue that we had been having).  However, that is completely unrelated to the system freeze.  I'll discuss that in a separate post.

7042   Thu Jul 26 21:31:44 2012 DenUpdatedigital noiseonline biquad works

 Quote: Still I do not like huge (2n+1) harmonics in the output of the biquad filter, I do not get them in the simulations. They are absent in the time series as well. So this is not a psd-estimation effect.

Excitation generator created these harmonics. When I applied low-pass butterworth filter, I've got the result of online filtering close to simulations. On the second graph blue is biquad filter output spectrum, red corresponds to DF2. 1 Hz sin wave was filtered with a notch filter of Q=100, depth=300 at 1 Hz.

7041   Thu Jul 26 17:39:49 2012 DenUpdatedigital noisebiquad key is working

I've filtered a 1 Hz sin wave excitation with a notch filter inside c1sus and c1rfm models. The biquad key is switched on in the last one, c1sus uses DF2. The results are indeed different.

Still I do not like huge (2n+1) harmonics in the output of the biquad filter, I do not get them in the simulations. They are absent in the time series as well. So this is not a psd-estimation effect.

7040   Thu Jul 26 16:08:59 2012 YaakovUpdateSTACISNoise plot update

I have a tentative noise plot for the STACIS that includes accelerometer noise, geophone noise, and platform motion with the STACIS off. (Accelerometer noise was measured for the VEL and NONE setting, which are settings on the accelerometer box which make the accelerometer signal correspond to velocity and acceleration, respectively. ) I'm focusing on sensor noise because this is the variable I am looking at changing, and knowing how the sensor noise translates into STACIS platform motion is therefore important.

The accelerometer and geophone noise I determined as described in my last eLog (http://nodus.ligo.caltech.edu:8080/40m/7027) Along the way I found out several things of importance:

1) Horizontal geophones are ONLY horizontal geophones. This is obvious in retrospect, because the springs supporting the magnet inside must be oriented based on vertical/horizontal operation.

2) The geophones in the STACIS are GS-11D (geospace), with a sensitivity of 32 V/m/s (compared to about 3.9 V/m/s for the accelerometers in VEL setting).

3) The accelerometers have different V/m/s sensitivities. I noticed the voltage output of one was consistently higher than the other, leading to very high noise estimates, but then Jenne showed me the actual calibration factors of the individual accelerometers which differed by as much as 0.4 V/m/s (a few percent difference). Taking this into account made the noise plots much more reasonable, but variations in calibration could still create some error.

The accelerometer noise agrees fairly well with the specs on the Wilcoxon page (http://www.wilcoxon.com/prodpdf/731A-P31%2098079a1.pdf). The geophone noise seems surprisingly low; it is even better than the geophone below about 4 Hz.

To see how this noise translates into actual platform motion, I took PSDs of the STACIS while it was off, on with accelerometer feedback, and on with geophone feedback (the "off" PSD is in the above noise plot). Using this data I'm working on estimating a transfer function that shows how the sensor noise translates to motion so I can come up with a sensor noise budget.

This shows that the geophones are actually doing a better job of isolating than the accelerometers, which is not surprising if the noise plot is accurate and the geophones are actually lower noise. It must be noted, though, that the noise plot was for the horizontal geophones whereas the plot above is for the vertical axis which may have a different noise level. Also, the vertical have some extra isolation by being enclosed in a metal stack with rubber padding at its base.

The problem with the STACIS in the past was the differential motion it introduced. I think this might be because the horizontal isolation was not uniform for each chamber. This means that even what would be symmetric motion (no differential length change) would be translated to differential motion because one end is more fixed than the other. Having accelerometers or better-padded geophones (maybe like the vertical geophones) in the STACIS ought to help with this by making the horizontal isolation more consistent and thus reducing differential motion. So the key may not be the geophone noise as much as varying geophone sensitivities or variation in how well they're mounted in the STACIS. I can test this by swapping out the horizontal geophones with other spares, changing the tightness of the mount, and seeing if either of these changes the horizontal isolation significantly, since these are factors that may differ from unit to unit.

I will also compare horizontal closed loop response with geophone vs. accelerometer feedback to see if the geophones are only doing a good job in the above plot because of their extra padding (the vertical stack).

7039   Thu Jul 26 15:43:03 2012 ranaUpdateLSCmodelled ringdown

You cannot use the digital system for this. You hook up a scope to the transmitted light as well as the incoming light (after the MC, perhaps at IP_POS). Then you acquire the data from both places simultaneously using an ethernet equipped scope. The step response of the PDs used for this has to be calibrated separately.

7038   Thu Jul 26 13:10:51 2012 janoschUpdateLSCmodelled ringdown

We fitted shutter and ringdown functions to the ringdown data. It is not perfectly clear how the power change due to the shutter is handed over to the power change due to ringdown. The fit suggests that the ringdown starts at a later time, but this does not necessarily make sense. It could be that the slow power decrease when the shutter starts clipping the TEM00 beam is followed by the cavity, but then the power decrease becomes too fast when the shutter reaches the optical axis and the ringdown takes over. Also, the next measurement should be taken with adjusted DC offset.

7037   Thu Jul 26 12:10:28 2012 DenUpdateCDSnew c1tst model for testing RCG code

 Quote: I made a new model, c1tst, that we can use for debugging the FREQUENT RCG bugs that we keep encountering.  It's a bare model that runs on c1iscey.  Don't do any thing important in here, and don't leave it in some crappy state.  Clean if up when you're done.

I wanted to test biquad form in this model. I added biquad=1 flag to cdsParameters, compiled, installed and restarted it. After that c1iscey suspended.

The same thing as we had several month ago

controls@c1iscey /opt/rtcds/caltech/c1/target/c1tst/c1tstepics 0cat iocC1.log Starting iocInit iocRun: All initialization complete sh: iniChk.pl: command not found Failed to load DAQ configuration file 7036 Thu Jul 26 10:22:03 2012 DenUpdatedigital noisenotch, lowpass filters  Quote: If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed? And how about checking for filter noise in the situation we saw online? 4th order low pass at 1 Hz or 8 Hz. This is because when we plot signals with sampling frequencies 2k and 16k with the same BW, we actually create psd/coherence using different numbers of points in FFT calculations as NFFT ~ fs/bw, fs-sampling frequency. So we secretly used 8 times more fft points for 16k signal then for 2k signal. Following plots demonstrate this effect. The first plot shows transfer function and coherence for filtering of 16k signal with butter('LowPass',4,8) and 2k signal with butter('LowPass',4,1) when BW=0.1. There is a disturbance in coherence for 2k signal below 2 Hz. Now let's take BW=0.8 and plot transfer function and coherence for 16k signal. We can see the same effect of coherence disturbance. The similar effect takes place when we change the cut-off frequency. The following plots show transfer function and coherence of two pairs of 2kHz signals. 4 order butterworth low-pass filter was used. For the first pair cut-off frequency was 1 Hz, for the second 10 Hz. On the first plot BW=0.1 and there is a disturbance in coherence below 1 Hz. However on the second plot when BW=0.01, this effect is lost. I guess my goal is to figure out when these effects come from fft calculations and when from digital filter noise. 7035 Thu Jul 26 02:44:17 2012 JenneUpdateIOOCentering the MCR camera [Yaakov, Jenne] The short version: Rana and Koji pointed out to us that the MCR camera view was still not good. There were 2 problems: (1) Diagonal stripes through the beam spot. Yuta and I saw this a week or 2 before he left, but we were bad and didn't elog it, and didn't investigate. Bad grad students. (2) Clipping of the left side of the beam (as seen on the monitors). This wasn't noticed until Yaakov's earlier camera work, since the clipped part of the beam wasn't on the monitor. The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum. The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time. We picked the correct beam, and all is well again. We moved the 10% BS that splits the main beam into the (MC REFL PD) path and the (MCR camera + WFS) path. It looked like the transmission through there was close to the edge of the BS. We didn't think that this was causing the clipping that we saw on the camera (since when we stepped MC1 in Yaw, the beam spot had to move a lot before we saw any clipping), but it seemed like a good idea to make the beam not near the edge of the optic, especially since, being a 2" optic, there was plenty of room, and we were only using ~half of the optic. We didn't touch anything else in the WFS path, since that looks at the transmission through this BS, but we had to realign the beam onto MC REFL. The long version: (1) The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum. It looks like that's why the iris was there in the first place. When we found it this evening, the iris was totally open, so my current theory is that someone was on the AP table doing something, and accidentally bumped the handle for the iris, then left it completely open when they realized that they had touched it. I think Steve had been doing something on the AP table around then, but since Yuta and I didn't elog our observation (bad grad students!), I can't correlate it with any of Steve's elogs. We were not able to find exactly where this "glow" that the iris is used to obscure comes from, but we traced it as far as the viewport, so there's something going on inside. (2) The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time. We picked the correct beam, and all is well again. We spent a long time trying to figure out what was going on here. Eventually, we moved the camera around to different places (i.e. right before the MC REFL PD, with some ND filters, and then we used a window to pick off a piece of the beam right as it comes out of the vacuum before going through the iris, put some ND filters, then the camera). We thought that right before the MC REFL PD was also being clipped, indicating that the clipping was happening in the vacuum (since the only common things between the MC REFL PD path and the camera path are the iris, which we had removed completely, and a 2" 10% beam splitter. However, when we looked at a pickoff of the main beam before any beamsplitters, we didn't see any evidence of clipping. I think that when we had the camera by MC REFL, we could have been clipping on the ND filters that I had placed there. I didn't think to check that at the time, and it was kind of a pain to mush the camera into the space, so we didn't repeat that. Then we went back to the nominal MCR camera place to look around. We discovered that the Y1 which splits the camera path from the WFS path has a ghost beam which is clipping on the top right side (as you look at the face of the optic) of the optic, and this is the beam that was going to the camera (it's a Y1 since we only want a teensy bit of light to go to the camera, the rest goes to the WFS). There is another beam which is the main beam, going through the center of the optic, which is the one which also reflects and heads to the WFS. This is the beam which we should have on the camera. Yaakov put the camera back in it's usual place, and put the correct beam onto the center of the camera. We did a check to make sure that the main beam isn't clipping, and when I step MC1 yaw, the beam must move ~1.5mm before we start to see any clipping on the very edge of the beam. To see / measure this, we removed the optic which directs the beam to the camera, and taped an IR card to the inside of the black box. This is ~about the same distance as to the nominal camera position, which means that the beam would have to move by 1.5mm on the camera to see any clipping. The MC REFL PD is even farther from MC1 than our IR card, so the beam has to fall off the PD before we see the clipping. Thus, I'm not worried about any clipping for this main beam. Moral of the story, if you made it this far: There wasn't any clipping on any beams going to either the WFS or the MC REFL PD, only the beam going to the camera. 7034 Wed Jul 25 23:03:22 2012 ranaUpdatedigital noisenotch, lowpass filters If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed? And how about checking for filter noise in the situation we saw online? 4th order low pass at 1 Hz or 8 Hz. 7033 Wed Jul 25 22:16:36 2012 KojiUpdateLSCringdown measurement Is this the step response of the single pole low pass??? It should have an exponential decay, shouldn't it? So it should be easier to comprehend the result with a log scale for vertical axis... I think you need a fast shutter. It is not necessary to be an actual shutter but you can use faster thing which can shut the light. Like PMC or IMC actuators. Another point is that you may like to have a witness channel like the MC transmission to subtract other effect. 7032 Wed Jul 25 17:35:44 2012 LizUpdateComputer Scripts / ProgramsSummary Pages are in the right place! The summary pages can now be accessed from the "Daily Summary" link under LOGS on the 40 meter Wiki page. 7031 Wed Jul 25 16:55:01 2012 DenUpdatedigital noisenotch, lowpass filters Direct Form 2 is noisy in the first test. This is the one similar to Matt's in his presentation. Input signal was a sine wave at 1 Hz with small amplitude white noise x[n] = sin(2*pi*1*t[n]) + 1e-10 * random( [-1, 1] ). It was filtered with a notch filter: f=1Hz, Q=100, depth=210dB. SOS representation was calculated in Foton. Sampling frequency is 16kHz. DF2 output noise level is the same if I change white noise amplitude while DF1, BQF, LNF can follow it. Time series show quantization noise of DF2. I've plotted coherence of the signals relative to DF1, because non of the signals will be coherent to it at low frequencies due to fft calculations. In the second test the input was white noise x[n] = random( [-1, 1] ) It was filtered with a 2 order low-pass butterworth filter with cut-off frequency f = 0.25 Hz. SOS representation was calculated in Python. Sampling frequency is 16kHz. In this test all implementations work fine. I guess dtt works with single precision and for that reason we see disturbance in coherence when we do the same test online. 7030 Wed Jul 25 16:31:01 2012 JenneUpdateLSCYarm green locking to arm - PDH box saturating  Quote: ... it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only. When we sat down to align the Yarm to the green, the green light was happy to flash in the cavity, but wouldn't lock, even after Jan had tweaked the mirrors such that we were flashing the TEM00 mode. When we went down to the end to investigate, the Universal PDH box was saturating both negative and positive. Turning down the gain knob all the way to zero didn't change anything, so I put it back to 52.5. Curiously, when we unplugged the Servo OUT monitor cable (which was presumably going to the rack to be acquired), the saturation happened much less frequently. I think (but I need to look at the PDH box schematic) that that's just a monitor, so I don't know why that had to do with anything, but it was repeatable - plug cable in, almost constant saturation....unplug cable, almost no saturation. Also, even with the cable unplugged, the light wouldn't flash in the cavity. When I blocked the beam going to the green REFL PD (used for the PDH signal), the light would flash. Moral of the story - I'm confused. I'm going to look up the PDH box schematic before going back down there to investigate. 7029 Wed Jul 25 15:33:55 2012 janoschUpdateLSCringdown measurement We did our first ringdown measurement on the Y arm. First we tried to keep the arm locked in green during the ringdown, but for some reason it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only. For the measurement we had to change the LSC model to acquire the C1:LSC-TRY_OUT_DQ at higher sampling frequency. We changed the sampling frequencies of C1:LSC-{TRX,TRY}_OUT_DQ from 2048Hz to 16384Hz. The measurement was done at GPS 1027289507. The ringdown curve looks very clean, but there seem to be two time constants involved. The first half of the curve is influenced by the shutter speed, then curvature is changing sign and the ringdown is likely taking over. We will try to fit a curve to the ringdown part, but it would certainly be better to have a faster shutter and record a more complete ringdown. 7028 Wed Jul 25 14:35:45 2012 SashaSummarySimulationsSURF - Week 5 - Summary  Quote: This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again). This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite). The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300). In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously. Here's a screenshot of what's going on inside the cavity (Attachment 1). The PDH/mixer system outputs 0 for pretty much everything except really high numbers, which is the problem I'm trying to solve now. I assumed that the sidebands were anti-resonant, calculated reflection coefficient F(dL) = Z * 4pi * i/(lambda), where Z = (-r_1 + r_2*(r_1^2 + t_1^2)/(1 - r_1*r_3)), then calculated P_ref = 2*P_s - 4sqrt(P_c*P_s) * Im(F(dL)) * sin(12.5 MHz * t) (this is pictured in Attachment 2), then mixed it with a sin(12.5MHz * t) and low-passed it to get rid of everything but the DC term (this is pictured in Attachment 3), which is the term that then gets whitened/anti-aliased/passed through the loop. Attachment 1: Screen_Shot_2012-07-25_at_2.20.01_PM.png Attachment 2: Screen_Shot_2012-07-25_at_2.20.15_PM.png Attachment 3: Screen_Shot_2012-07-25_at_2.20.29_PM.png Attachment 4: Screen_Shot_2012-07-25_at_2.23.05_PM.png 7027 Wed Jul 25 12:00:21 2012 YaakovUpdateSTACISWeekly update The past few days I've been working on making a noise budget for the STACIS that incorporates all the different noises that might be contributing. The noises I am concentrating on are accelerometer noise, geophone noise, electrical noise, and ground noise. Noise from the PZT stacks themselves should be tiny according to various PZT spec sheets, but I haven't actually found a value for it (they all just say it's negligible), so I'll keep it in mind as a potential contributor. Here's how I am determining accelerometer noise: I take two vertical accelerometers side by side, sitting on a granite block and covered in a foam box, and take the time series of both. Then I take the difference of the time series and calculate the PSD of that, which with the calibration factor of the accelerometers (the V/m/s sensitivity) I am able to find the noise in m/s/rtHz. The noise agreed with the accelerometer specs I found at low frequencies but was higher than expected at high frequencies, so I'm still investigating. If I can't find an obvious problem with my measurements I'll try the three-corner hat method (as per Jenne's recommendation), which would allow me to determine the noises of the independent accelereometers. I tried a similar method for the geophone noise, but the value I came up with was actually higher than the accelerometer noise, which seems very fishy. I realized that the geophones were still connected to the STACIS circuitry when I took the measurements ,which was probably part of the problem. So this morning I disconnected the STACIS entirely and am looking at just the geophone signals which should give a more accurate noise estimate. Once I have all the noises characterized, the next step is seeing how those noises affect the closed loop performance of the STACIS. I've been working on a block model that incorporates the different noises and transfer functions involved, and when I have the noises characterized I can test a prediction about how a certain noise affects the platform motion. 7026 Wed Jul 25 11:41:00 2012 YaakovUpdateVIDEOCentering the MCR camera  Quote: Jenne and I centered the MCR camera on the AP table. We moved the camera as far as it could go on its mount without shifting its screws, and adjusted the optic that the camera looks at for the rest of the way. The spot was still off center on the quad display in the control room, so I re-recentered it today. 7025 Wed Jul 25 11:34:31 2012 EricSummarySimulationsSURF Update I am continuing work on simulating the DARM control loop. There is now a block for the length response function that allows one to recover the h(t) GW input to the model. However, in order to add this block I had to add some artificial poles to the length response function beacuse Simulink gave me errors when the transfer function had more zeros than poles. The artificial poles are at 10^6 Hz and higher, so that they should not affect the response function at the lower frequencies of interest. This approach appears a bit computationally unstable though because without changing any parameters and re-running the simulation, a different magnitude for h(t) would be calculated sometimes. A different method may be necessary to get this working more accurately . By looking through the C1LSC Simulink model and the C1LSC control screens, Jenne helped me determine which digital filters are active while the interferometer is locked . To do this, open the C1LSC control screen, then open the trigger matrix. Inside the trigger matrix window there is a button titled Filter Module Triggers which opens another window that indicates which filters are triggered for a given channel, and what values trigger them. For the y arm servo filters FM2, 3, 6, 7, 8 are triggered while in lock and FM4 and 5 are controlled manually; I am including all of these in the model now. I have changed the way I manipulate the output from the model for analysis, using Rana's advice. I also improved the plotting code, now using a custom Bode plot instead. Attached is a screenshot of the Simulink model as it currently stands, and an older implementation of the open loop gain . I am in the process of updating the servo filters now, and what is shown in the plot does not include all the filter modules for the servo filter. Attachment 1: DARM_control_loop_hendries.PNG Attachment 2: OLG_old_hendries2.png 7024 Wed Jul 25 11:25:27 2012 MashaUpdateGeneralSummary This week, I have been mainly working on my new neural network project, and working with the BLRMS channels. New Neural Network Project: Rana and I read a paper which demonstrated the use of a neural network to control an inverted pendulum. Since the test masses are, in simplest terms coupled harmonic oscillators with six degrees of freedom, we suspect something similar can be done. The logic behind trying to use a neural network as a control system lies in the fact that the actual motion of the test masses is a complicated function of many variables (including environment variables, such as temperature and seismic disturbance as well), and neural networks, at the core, are function approximators, which can approximate a function as a combination of polynomials (with error 0 in a closed interval) or of sigmoidal functions (which, in the papers I've read, seems to be possible in practice - the authors also reference some theoretical results regarding this). Thus, this network could, in theory take the displacement in the degrees of freedom of the OSEMS and generate the actuation force. However, there was the question of building a neural network which explicitly took the history of a time series into account, and not only implicitly in the neuron weights. Thus, I found recurrent neural networks, which, for some T (this will ultimately be related to the sampling frequency, or spectrum of the signal), has T hidden sub-layers which pass in the output of the T previous iterations. I have written Matlab code that generates, for a given T and neuron vector (the number of neurons in each of the T layers) a recurrent neural network (it still, like my old network, uses gradient descent and sigmoidal activation functions). However, I needed a system to run it on, so I began playing around with Simulink. I have never used this system before, so I took a bit of time doing the tutorials, but I currently have a damped, driven harmonic oscillator which accepts a force at each time step and outputs a displacement (taking into account the earlier forces). This afternoon, I think I will link it to my recurrent neural network, which can accept a displacement and output a force, and see what happens. These networks are notoriously slow to converge, but I could at least check to see that my code (and understanding of the algorithm) is correct. Should this work, I can also try hooking it up to Sasha's simulation, which is more complex than an oscillator with one degree of freedom. As Far as Seismic Things Go: I haven't worked with seismic noise itself very much this week, although the signals could be used as inputs to a neural network. I moved the STS1 and GUR1 cables, which I realized were crossed and thus stupidly placed (my fault) and now have STS1 on the very end of the Y arm (GUR1 is about 10 meters down the X arm, however, so Jenne and I will probably have to make a cable). I also found granite and foam, so at least the STS can be given a final position at the end of the arm. BLRMS: I added two new channels to the BRLMS, for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, so that we can better observe distant earthquakes. I also changed the MEDM screen for all of the ACC, GUR, and STS RMS channels (I think Liz is also using this for her MIC channels), combining the low pass and high pass filter screens into a screen demonstrating the complete RMS process, which squaring and square roots. I have also changed the RMS filters, and wrote an Elog about that process. The paper Rana and I read is Charles W. Anderson, Learning to Control and Inverted Pendulum Using Neural Networks A good paper of recurrent neural network basics is Mikael Boden, "A guide to recurrent neural networks and backpropagation" 7023 Wed Jul 25 11:22:39 2012 LizUpdateComputer Scripts / ProgramsWeek 6 update This week, I made several modifications to the Summary page scripts, made preliminary Microphone BLRMS channels and, with Rana's help, got the Weather Station working again. I changed the spectrogram and spectrum options in the Summary Pages so that, given the sampling frequency (which is gathered by the program), the NFFT and overlap are calculated internally. This is an improvement over user-entered values because it saves the time of having to know the sampling frequency for each desired plot. In addition, I set up another .sh file that can generate summary pages for any given day. Although this will probably not be useful in the final site, it is quite helpful now because I can go back and populate the pages. The current summary pages file is called "c1_summary_page.sh" and the one that is set up to get a specific day is called "liz_c1_summary_page.sh". I also made a few adjustments to the .css file for the webpage so that plots completely show up (they were getting cut off on the edges before) and are easier to see. I also figured out that the minute and second trend options weren't working because the channel names have to be modified to CHANNEL.mean, CHANNEL.min and CHANNEL.max. So that is all in working order now, although I'm not sure if I should just use the mean trends or look at all of them (the plots could get crowded if I choose to do this). Another modification I made to the python summary page script was adding an option to have an image on one of the pages. This was useful because I can now put requested MEDM screens up on the site. The image option can be accessed if, in the configuration file, you use "image-" instead of "data-" for the first word of the section header. I also added a link to the final summary page website on the 40 meter wiki page (my summary page are currently located in the summary-test pages, but they will be moved over once they are more finalized). I fleshed out the graphs on the summary pages as well, and have useful plots for the OSEM and OPLEV channels. Instead of using the STS BLRMS channels, I have decided to use the GUR BLRMS channels that Masha made. I ELOGged about my progress and asked for any advice or recommendations a few days ago (7012) and it would still be great if everyone could take a look at what I currently have up on the website and tell me what they think! July 22 and 23 are the most finalized pages thus far, so are probably the best to look at. https://nodus.ligo.caltech.edu:30889/40m-summary-test/archive_daily/20120723/ This week, I also tried to fix the problems with the Weather Station, which had not been operational since 2010. All of the channels on the weather station monitor seemed to be producing accurate data except the rain gauge, so I went on the roof of the Machine Shop to see if anything was blatantly wrong with it. Other than a lot of dust and spiders, it was in working condition. I plan on going up again to clean it because, in the manual, it is recommended that the rain collector be cleaned every one to two years... I also cleared the "daily rain" option on the monitor and set all rain-related things to zero. Rana and I then traced the cabled from c1pem1 to the weather station monitor, and found that thy were disconnected. In fact, the connector was broken apart and the pins were bent. After we reconnected them, the weather station was once again operational! In order to prevent accidental disconnection in the future, it may be wise to secure this connection with cable ties. It went out of order again briefly on Tuesday, but I reconnected it and now it is in much sturdier shape! The most recent thing that I have been doing in relation to my project has been making BLRMS channels for the MIC channels. With Jenne's assistance, I made the channels, compiled and ran the model on c1sus, made filters, and included the channels on the PEM MEDM screen . I have a few modifications to make and want to . One issue that I have come across is that the sampling rate for the PEM system is 2 kHz, and the audio frequencies range all the way up to 20 kHz. Because of this, I am only taking BLRMS data in the 1-1000 Hz range. This may be problematic because some of these channels may only show noise (For example, 1-3 and 3-10 Hz may be completely useless). The pictures below are of the main connections in the Weather Station. This first is the one that Rana and I connected (it is now better connected and looks like a small beige box), located near the beam-splitter chamber, and the second is the c1pem1 rack. For more information on the subject, there is a convenient wiki page: https://wiki-40m.ligo.caltech.edu/Weather_Station Attachment 1: P7230026.JPG Attachment 2: P7230031.JPG 7022 Wed Jul 25 10:31:33 2012 SashaSummarySimulationsSURF - Week 5 - Summary This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again). This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite). The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300). In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously. Attachment 1: Screen_Shot_2012-07-24_at_10.46.05_AM.png Attachment 2: Screen_Shot_2012-07-24_at_10.45.43_AM.png Attachment 3: Screen_Shot_2012-07-25_at_10.16.58_AM.png Attachment 4: Screen_Shot_2012-07-25_at_10.25.27_AM.png 7021 Tue Jul 24 21:16:55 2012 DenUpdatedigital noisequantization test I'm trying to get some intuition how digital noise due to quantization shows up in iir filters. I decided to do tests in C using Python to calculate psd and visualize. I've implemented Direct Form 1, 2, "Biquad" and "Low Noise" forms of realization of second-order iir filter from Matt's presentation. There is a typo in the "Low Noise Form" scheme - a1 and a2 gains should be switched. Other then that schemes correctly implement 2 order iir. The input signal to each filter was a sine wave plus white noise with small amplitude x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ), g << 1, f=1kHz. Sampling frequency was 16384 Hz. All 4 forms implemented 2 order low-pass butterworth filter with cut-off frequency 0.2 Hz For g=1e-2 all implementations work fine. For g=1e-8 when quantization noise increases, all implementations give a lot of noise at low frequencies. I did not notice any significant difference between any of these implementations. I'll try to do more tests to figure out any difference in noise between the forms. Quantization noise depends on the architecture of the processor, compiler and what not. But I do not think this can give a huge difference in results. We need to understand carefully digital noise during PSD estimation and all operations done at Matlab or Python. 7020 Tue Jul 24 18:33:12 2012 YaakovUpdateVIDEOCentering the MCR camera Jenne and I centered the MCR camera on the AP table. We moved the camera as far as it could go on its mount without shifting its screws, and adjusted the optic that the camera looks at for the rest of the way. 7019 Tue Jul 24 15:17:10 2012 MashaUpdatePEMRMS Filters, PEM Sitemap RMS Filters How Den, Rana, and I chose RMS filters: - Because filter ring-down generates negative outputs, which then show up as NaN when the log is taken in StripTool, we decided to only use low-pass filters with real poles (using ZPK in Foton). - The band-pass filters were chosen by looking at the dB drop from the cutoff frequencies to the next (usually aiming for 40 dB, or 99%), and checking that the BP_IN and BP_OUT had a coherence of 1 in the pass-band. - The low-pass filters were chosen by finding the lowest filter order at which there was coherence of ~1 in the passband between the input signal to the filter and the filter output. The cutoff frequencies were chosen to be lower than the first passband frequency, in order to get rid of the cos(2*\omega*t)/2 terms that arise during the squaring of a signal of the form Asin(\omega*t) and to assure that only terms related to A^2/2 were kept. A plot of the 3-10 region is attached - in the Coherence plot, the coherence in ~1 in the 3 to 10 hZ region. Likewise, PEM Sitemap My previous post had digital zeros in two of the BLRMS channels. Jenne figured out that this was because the file Csqrt.c, which performs the square root operation in the root-mean square processing only accepted 5 inputs. I modified and committed the code so that it now accepts 7 inputs (for our 7 frequency bands) and returns 7 outputs. The new PEM sitemap seems to currently work. StripTool I have modified the StripTool file in order to show our new 0.01 Hz - 0.03 Hz and 0.03 Hz - 0.1 Hz channels. Attachment 1: GUR1Z0p3to1FilterCoherence.png Attachment 2: GUR1Z3to10FilterCoherence.png Attachment 3: GUR1Z3to10FilterSignal.png 7018 Tue Jul 24 12:06:41 2012 MashaUpdatePEMNew RMS channels, New C1PEM Overview As Jenne suggested last night, I changed the C1PEM overview in Epics. Previously, the C1PEM_OVERVIEW.adl screen had two separate visualizations, one for LP and one for BP for each channel. I changed the format so that there is only one frame per RMS channel, showing all of the input and output as before, but continuously, to demonstrate the actual RMS process. First, the input is bandpass filtered, then multiplied by itself (squared), then lowpass filtered, and then square rooted to yield the final output. I have kept the previous files, but have applied this new format to all of the RMS ACC*, GUR1, GUR2, and STS1 channels. As Rana suggested yesterday, I made channels for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, and created filters for them, which I will work on some more now. Attachment 1: NewRMSFrames.png 7017 Tue Jul 24 03:14:13 2012 JenneUpdateASSCalibration of MC ASS lockins I wanted to check that the calibration of the MC ASS lockins was sensible, before trusting them forevermore. To measure the calibration, I took a 30sec average of C1:IOO-MC_ASS_LOCKIN(1-6)_I_OUT with no misalignment. Then step MC1 pitch by 10% (add 0.1 to the coil output gains). Remeasure the lockin outputs. 2.63 / (Lockin1noStep - Lockin1withStep) = calibration. Repeat, with Lockin2 = MC2 pit, lockin3 = MC3 pit, and lockins 4-6 are MC1-3 yaw. The number 2.63 comes from: half the side of the square between all 4 magnets. Since our offsets are in pitch and yaw, we want the distance between the line connecting the lower magnets and the center line of the optic, and similar for yaw. Presumably if all of the magnets are in the correct place, this number is the same for all magnets. The optics are 3 inches in diameter. I assume that the center of each magnet is 0.9mm from the edge of the optic, since the magnets and dumbbells are 1.9mm in diameter. Actually, I should probably assume that they're farther than that from the edge of the optic, since the edge of the dumbbell ~touches the edge of the flat surface, but there's the bevel which is ~1mm wide, looking normal to the surface of the optic. Anyhow, what I haven't done yet (planned for tomorrow...) is to figure out how well we need to know all of these numbers. We shouldn't care more than ~100um, since the spots on the optics move by about that much anyway. For now, I get the following #'s for the calibration: Lockin1 = 7.83 Lockin2 = 9.29 Lockin3 = 8.06 Lockin4 = 8.21 Lockin5 = 10.15 Lockin6 = 6.39 The old values were: C1:IOO-MC_ASS_LOCKIN1_SIG_GAIN = 7 C1:IOO-MC_ASS_LOCKIN2_SIG_GAIN = 9.6 C1:IOO-MC_ASS_LOCKIN3_SIG_GAIN = 8.3 C1:IOO-MC_ASS_LOCKIN4_SIG_GAIN = 7.8 C1:IOO-MC_ASS_LOCKIN5_SIG_GAIN = 9.5 C1:IOO-MC_ASS_LOCKIN6_SIG_GAIN = 8.5 The new values measured tonight are pretty far from the old values, so perhaps it is in fact useful to re-calibrate the lockins every time we try to measure the spot positions? 7016 Tue Jul 24 02:12:14 2012 MashaUpdatePEMBLRMS, MEDM, Triangulation Today I worked with the BLRMS channels, re-triangulated the seismometers (the STS is now on the very end of the Y-arm, while the GUR2 is on the X-arm - this GUR2 cable will need to be either extended or replaced - Jenne and I will look at parts tomorrow), and added 0.01 - 0.03 Hz and 0.03 - 0.1 Hz RMS channels (However, the MEDM files for these are not yet complete - I will finish these tomorrow) in order to be able to better see earthquakes. I also did some things for the neural network project, including beginning Simulink tutorials so that I can run my code by applying a force on a damped harmonic oscillator + white noise until it stops. I will explain the methodology behind the new RMS filters tomorrow morning, when the seismometers have settled down and I can make coherence plots. I'll post a better E-log tomorrow when it's not 2 in the morning. 7015 Mon Jul 23 21:54:48 2012 ranaUpdatePEMWeather Station Works! To get the code to run on c1pem1, we had to move the old target back into the /cvs/cds/caltech/target/ directory. It is in /cvs/cds/caltech/target/c1pem1/. JoeB had apparently moved it into some other area called 'oldfe' and this was why the weather station has not been running for years. Joe is at LLO now, but he's not beyond our reach... Once the code had been moved back I started it up. I also rebooted it from the telnet prompt to ensure that it worked on reboot. It did. The cable issue that Liz mentions probably happened during the PSL table lifting and cable cleanup. It looks like someone yanked the ethernet cable out of its adapter and broke it... Attachment 1: Untitled.png 7014 Mon Jul 23 21:17:58 2012 LizUpdatePEMWeather Station Works! Rana and I traced the cables that ran from c1pem1 to the Weather Station monitor. We found that the flat blue cable that is plugged into c1pem1 was not connected to the black cable from the Weather Station. We don't know why they are unplugged, but the Weather Station had been inactive since 2010. Rana plugged them back in (they are now connected via a sketchy connector that had its pins askew) and now the channels are outputting correct data! Everything else seems to be in good order and now I can use the data from the Weather Station for the summary pages! 7013 Mon Jul 23 20:34:38 2012 JamieOmnistructureComputersCHECK IN YOUR CHANGES TO THE SVN I'm seeing LOTS OF STUFF NOT CHECKED INTO THE SVN!!! both modified things that haven't been updated, and things that looked like they haven't been checked in at all. ### Please check in your stuff to the SVN! We need the record! Look through EVERYTHING that you think you might have touched, or even care about, and make sure it's checked in. 7012 Mon Jul 23 20:19:01 2012 LizUpdateComputer Scripts / ProgramsInput Needed (From everyone!) The summary pages are now online (Daily Summary), and will eventually be found on the 40m Wiki page under "LOGS-Daily Summary". (Currently, the linked website is the former summary page site) Currently, all of the IFO and Acoustic channels have placeholders (they are not showing the real data yet) and the Weather channels are not working, although the Weather Station in the interferometer room is working (I am looking into this - any theories as to why this is would be appreciated!!). I am looking for advice on what else to include in these pages. It would be fantastic if everyone could take a moment to look over what I have so far (especially the completed page from July 23, 2012) and give me their opinions on: 1. What else you would like to see included 2. Any specific applications to your area of work that I have overlooked 3. What the most helpful parts of the pages are 4. Any ways that I could make the existing pages more helpful 5. Any other questions, comments, clarifications or suggestions Finally, are the hourly subplots actually helpful? It seems to me like they would be superfluous if the whole page were updating every 1-2 hours (as it theoretically eventually will). These subplots can be seen on the July 24, 2012 page. My email address is endavison@umail.ucsb.edu. Thank you! 7011 Mon Jul 23 19:50:43 2012 JamieUpdateCDSc1gcv model renamed to c1als I decided to rename the c1gcv model to be c1als. This is in an ongoing effort to rename all the ALS stuff as ALS, and get rid of the various GC{V,X,Y} named stuff. Most of what was in the c1gcv model was already in a subsystem with and ALS top names, but there were a couple of channels that were outside of that that had funky names, namely the "GCV_GREEN" channels. This fixes that, and make things more consistent and simple. Of course this required a bunch of other little changes: • rename model in userapps svn • target/fb/master had to be modified to point to the new chans/daq/C1ALS.ini channel file and gds/param/tpchn_c1als.par testpoint file • rename RFM channels appropriately, and fix in receiver models (c1scx, c1scy, c1mcs) • move custom medm screens in userapps svn (isc/c1/medm/c1als), and link to it at medm/c1als/master • moved old medm/c1gcv directory into a subdirectory of medm/c1als • update all medm screens that point to c1gcv stuff (mostly just ALS screens) The above has been done. Still todo: • FIX SCRIPTS! There are almost certainly scripts that point to GC{V,X,Y} channels. Those will have to be fixed as we come across them. • Fix the c1sc{x,y}/master/C1SC{X,Y}_GC{X,Y}_SLOW.adl screens. I need to figure out a more consistent place for those screens. • Fix the C1ALS_COMPACT screen • ??? 7010 Mon Jul 23 19:13:12 2012 JenneUpdatePSLPSL channels added to IOO model  Quote: I added a subblock to the IOO model, and gave it a top_names of PSL, so the channels show up as C1:PSL-...... So far, there are just 2 channels acquired, C1:PSL-FSS_MIXER and C1:PSL-FSS_FAST, since those were already connected to the ADC. Those signals are both on the DAQ OUT of the FSS board in the rack. They are DQ channels now too. So there was a problem with the channel name C1:PSL-FSS_FAST, which conflicts with an existing slow channel. This was causing daqd to fail to start (shockingly, with an appropriate error message!). I renamed the channel to be C1:PSL-FSS_NPRO until we come up with something better. After the change everthing worked and fb came back. 7009 Mon Jul 23 19:00:26 2012 KojiUpdateGreen LockingALS_END.mdl model added for end station green ALS channels This is a good modification. We just need to check how the ALS scripts are affected.  Quote: The end sus models (c1scx and c1scy) both contain some ALS stuff. This stuff could maybe be moved to their own models, but whatever. The stuff at X and Y were identical, but were code copies (BAD!). I made a new library part for the ALS end controls:{userapps}/isc/c1/model/ALS_END.mdl It contains just some filter modules for the ALS end laser control, and a monitor of the ALS end REFL PD DC.  I also added a DQ block for the recorded channels (see screen shot). When I added this new part to c1scx and c1scy I made it so the channel names would be more sensible.  Instead of "GCX" and "GCY", they are now "ALS-X" and "ALS-Y".  They will now all show up under the ALS subsystem.

7008   Mon Jul 23 18:57:52 2012 JamieUpdateCDSc1scx and c1scy models recompiled and restarted

After the changes listed in 7005 and 7007, I have rebuilt, installed, and restarted the c1scx and c1scy models.  Everything seems to have come back up ok.

Running into some daqd troubles because of a change to c1ioo, but will report on the new ALS channels when I can.

7007   Mon Jul 23 18:41:15 2012 JamieUpdateGreen LockingALS_END.mdl model added for end station green ALS channels

The end sus models (c1scx and c1scy) both contain some ALS stuff.  This stuff could maybe be moved to their own models, but whatever.

The stuff at X and Y were identical, but were code copies (BAD!).  I made a new library part for the ALS end controls: \${userapps}/isc/c1/model/ALS_END.mdl

It contains just some filter modules for the ALS end laser control, and a monitor of the ALS end REFL PD DC.  I also added a DQ block for the recorded channels (see screen shot).

When I added this new part to c1scx and c1scy I made it so the channel names would be more sensible.  Instead of "GCX" and "GCY", they are now "ALS-X" and "ALS-Y".  They will now all show up under the ALS subsystem.

Attachment 1: alsend.png
ELOG V3.1.3-