STS-2 - end of X arm

GUR 2 - isolation box

TRILLIUM - 1Y3 (DC power supply uses 1Y3 AC power, please do not close the door completely)

GUR 1 - end of Y arm

Now we have several "triangular seismic antennas". Different configurations can be chosen to compare the results.

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).

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?

 Using Guralp, STS-2 and Trillium I compared Gur and STS-2 self-noise assuming that Trillium noise is not worse then STS-2 noise.

Interesting that STS-2 (or Trillium if its noise is worse) noise is not too much better then Guralp noise.

Today I worked on locking the Michelson. Here's what I did:

1. Open Data Viewer and Restore Settings /users/Templates/JenneLockingDataviewer/MICH.xml. This opens the C1:LSC-ASDC_OUT and C1:LSC-AS55_Q_ERR plots.

2. Check the LSC screen to verify that the path between the Servo Filter Modules and the SUS Ctrls are outlined in green. If not turn on the OUT button within the Filter Servo Modules, enable LSC mode, and turn on the SUS Ctrls for the BS.

3. Misalign all optics other than BS and one of ITMX and ITMY. The ITMY was already well-aligned from my work on locking the YARM, so I actually chose to misalign ITMY at first.

4. Restore BS and ITMX. Use the AS camera on the video screen as your guide when aligning ITMX.

5. Adjust pitch and yaw of ITMX until a bright, circular spot appears near the middle of the AS camera.

6. Now restore ITMY and adjust pitch and yaw until a second circular spot appears on the AS camera.

7. Adjust both ITMX and ITMY until both bright spots occupy the same location. If the spots remain bright when they are in the same location you are locking onto a bright fringe actually, and need to flip the sign of the gain on the MICH servo filter modules. I had to do this today in fact, as discussed in ELOG 7145.

8. If the sign is correct, the two beams should interfere destructively and the formerly bright spots will form a comparatively dark spot. The shape of the spot will likely be two bright lobes separated by a dark middle.

9. C1:LSC-ASDC_OUT should be a roughly flat signal, and the goal now is to minimize the magnitude of this signal. The smaller this signal, the darker the AS camera should look. Decent target values for C1:LSC-ASDC_OUT are around 0.10 to 0.05.

Once I did this, I made measurements by exciting C1:SUS-ITMY_LSC_EXC and measuring with C1:LSC-AS55_Q_ERR. I ran a logarithmic swept sine response from 1 to 1000 Hz again, with an envelope amplitude dependence. Again I looked at the measured transfer function and coherence. I was able to get good coherence, but it was somewhat erratic in that it dipped low at high frequency multiple times.

I hope you're not all tired of the STACIs noise budgets, because I have another one! Here, the main difference is my modeling of the geophone sensitivity according to a predicted physical model for the system (just a damped oscillator) instead of trying to fit it to the accelerometer motion signal with more arbitrary functions.

The result of this calibration is shown below (accel and geo signals taken for 5 minutes at the same time, in granite and foam):

The m/s/V sensitivity function I am using is g*[(w^2-2idww(0)-w(0)^2)/w^2], where g (the high freq. m/s/V sensitivity) was 2.5*10^-5 and d (damping) was set to 2.

Now, the recalculated noise plot looks like this:

The accel. specs I took from the Wilcoxon spec sheet, and the geo specs I found in https://dcc.ligo.org/public/0028/T950046/000/T950046-00.pdf, a LIGO document about the STACIS. The geo noise was measured for the STACIS geo and their pre-amp, while I was using the SR560 as the pre-amp. If anything, my noise should be lower, since the SR560 noise spec is lower than what I estimated for the STACIS geophone pre-amp, so I'm not sure about that order of magnitude difference between the experimental and expected geo noise. A sign that my noise values are at least reasonable is that the geophone noise flattens out above the geophone's resonant frequency (4.5 Hz), as Jan pointed out it should.

The sensor noise (either accel. or geo.) is the dominating signal below 1 Hz in the STACIS platform measurement, which then limits the closed loop performance at those frequencies. Since the noises I am finding are looking reasonable, I think it's fair to definitively state that accelerometers will not significantly help at low frequencies (there may be at most a factor of 2 lower noise below 1 Hz for the accel., but I need more data to say for sure).

The plan right now is to concentrate on using the STACIS as actuators, perhaps with seismometers on the ground and a feedforward signal sent into the high voltage amplifier.

I took the transfer function of the high voltage board itself (no pre-amp included) by driving the PZTs with a swept sine and measuring the accelerometer response (which I am now fairly confident is calibrated correctly). The input point was the signal IN on the extender board, but with the geophones disconnected from the pre-amp.

I took the coherence at just a few single frequencies (you can't do coherence measurements in swept sine mode on the SR785) to make sure I was really driving the PZTs, and it was near 1 (998, 999.9, etc) at the frequencies at which I drove. Without the extra notches at 1 Hz (which may be real, it's coherent there too), it looks like a 2-pole high pass filter (goes from -180 to 180 deg, approx. an f^2 dependence). This transfer function should be taken into account by the feedforward algorithm.

The current plan is to make a box with a switch that allows geophone feedback and/or external signals into the high voltage amplifier. It would act sort of like the extender card, except more compact so it could fit into the STACIS. It also would have the advantage of not having to reroute the power, since those lines from the pre-amp could all still be connected (see eLog 7118: http://nodus.ligo.caltech.edu:8080/40m/7118).

Alex also modified RCG script to generate -O in the Makefile for c1pem model:

controls@pianosa:/opt/rtcds/rtscore/release/src/epics/util 127$ svn diff
feCodeGen.pl 
Index: feCodeGen.pl
===================================================================
--- feCodeGen.pl (revision 2999)
+++ feCodeGen.pl (working copy)
@@ -3183,7 +3183,12 @@
print OUTM "\n";
}
print OUTM "ALL \+= user_mmap \$(TARGET_RTL)\n";
+# do not optimize c1pem
+if ($skeleton eq "c1pem") {
+print OUTM "EXTRA_CFLAGS += -O -w -I../../include\n";
+} else {
print OUTM "EXTRA_CFLAGS += -O3 -w -I../../include\n";
+}
print OUTM "EXTRA_CFLAGS += -I/opt/gm/include\n";
print OUTM "EXTRA_CFLAGS += -I/opt/mx/include\n";

Den and I installed a module in the c1pem model which has a feedforward neural network to classify seismic disturbance (10 means quiet, 20 truck, 30 earthquake). There is a channel SEIS_CLASS which should specify the class of the seismic signal. The code works for signals sampled at 256 Hz, so an anti-aliasing filter must be installed in order to decimate from the 2048 model.

The models were compiling slowly, so Alex removed the archiving feature (gzip and tar were taking a lot of time).

Den and I also had trouble with a simple for loop in our model, so we talked to Alex who noted that the -O3 compiler unravels for loops in a buggy way. Thus, we have compiled c1pem using the -O compiler.

PS: the Trilium seismometer now has legs.

I'm working on locking the Michelson now in order to put an excitation on one of the input test masses and measure the resulting error signal at the anti-symmetric port. I aligned the beams from ITMX and ITMY by looking at the AS camera with the video screens, but the fringes were not destructively interfering. Jenne advised that I look at the gain on the MICH servo filter modules in the LSC screen. We flipped the sign on the gain (it was 0.120 and it is now -0.120) and the fringes destructively interfered as desired after this change.

For purposes of documentation, I locked the YARM earlier in the morning before moving on to the Michelson. The purpose of this was to put another excitation on C1:SUS-ETMY_LSC_EXC and then measure the error signal on C1:LSC-POY11_I_ERR.

 The PD saturates the oscilloscope just by switching on the power; with no real signal at all. But Steve helped locating a PD that is not being used at the AP table. So I will check it and replace the current one if it works!

 The issue you're seeing here is stalled mx_stream processes on the front ends.  On the troublesome front ends you can log in and restart the mx_streams with the "mxstreamrestart" command.

Can you explain more what "broken/bad" means?  Is there no signal?  Is it noisy?  Glitch?  etc.

I've been trying to get the simPlant model to work, and my main method of testing is switching between the real ETMX and the simulated ETMX and comparing the resulting power spectrum (the closer the two are, the more our simulation works). While the simPlant is on, ETMX is NOT BEING DAMPED. I started this ~Wednesday, and the testing will continue today, then hopefully we'll get a similiar simPlant up for ITMX (at which point, testing will continue for both ITMX and ETMX).

TL;DR: ETMX is not being continuously damped, XARM will likely be exhibiting some wonky behavior next week.

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

I forgot to post this last night, but I locked the YARM again yesterday and misaligned the other optics. I took measurements on ITMY and ETMY with DTT again as well. At the end of the day I aligned the rest of the optics before I left.

The c1lsc and c1sus screens are red in the front-end status. I restarted the frame builder, and hit the "global diag reset" button, but to no avail. Yesterday, the only thing Den and I did to c1sus was install a new c1pem model. I got rid of the changes and switched to the old one (I ran rtcds build, install, restart), but the status is still the same.

Koji pointed out that I was being silly, and rather than actually misaligning the optics (by, say, changing their IFO Align sliders) I was changing the location of the actuation node by changing the coil output gains.  Now I see nice signals at the I_OUT of each of the demodulators (so far I've only looked at the YARM).

I've measured and inverted the matrix by taking the nominal values of the demodulator outputs when the optics are all by-hand optimally aligned, then one-by-one misaligning an optic's angle (pitch or yaw), and looking at the demod outputs that result.  Repeat with each misalignment DoF for each of the 4 rows of the matrix.  Then I set the pit/yaw coupling elements of the matrix to zero.  Then invert the matrix, put it in, and see what happens.  So far, the yaw DoFs converged to zero, but the pitch ones didn't.  I'll play with it more and think some more tomorrow.

The elog was not responding. I attempted to restart it by running .../start-elog.csh, but this didn't work (even after the usual ~2 times it needs).

Somehow pkill did not kill the daemon, so I kill -9'd it and that did the trick. I ran the start script once more and it came back online.

 Here's the same plots in pdf format now. I originally posted them as jpg because I couldn't open the resulting pdf from DTT on rosalba, but I could open the jpg. I'll look into overlaying the measured and modeled curves as well.

 Okay! Attached are two power spectra. The first is a power spectrum of reality, the second is a power spectrum of the simPlant. Its looking much better (as in, no longer obviously white noise!), but there seems to be a gain problem somewhere (and it doesn't have seismic noise). I'll see if I can fix the first problem then move on to trying to find the seismic noise filters.

As the subject states, all screens are working (including the noise screens), so we can keep track of everything in our model! :D I figured out that I was just getting nonsense (i.e. white noise) out of the sim plant cause the filter matrix (TM_RESP) that controlled the response of the optics to a force (i.e. outputted the position of the optic DOF given a force on that DOF and a force on the suspension point) was empty, so it was just passing on whatever values it got based on the coefficients of the matrix without DOING anything to them. In effect, all we had was a feedback loop without any mechanics.

I've been working on getting the mechanics of the suspensions into a filter/transfer function form; I added something resembling that into foton and turned the resulting filter on using the shiny new MEDM screens. However, the transfer functions are a tad wonky (particularly the one for pitch), so I shall continue working on them. It had a dramatic effect on the power spectrum (i.e. it looks a lot more like it should), but it still looks weird.

Still haven't found the e-log Jamie and Rana referred me to, concerning the injection of seismic noise into the simulation. I'm not terribly worried though, and will continue looking in the morning. Worst case scenario, I'll use the filters Masha made at the beginning of the summer.

Masha and I ate some of Jamie's popcorn. It was good.

That's a good point, but I suspect that you end up with the in-phase (0deg) as the response of the IFO is immediate compared with the dithering frequency
as long as the whitening/dewhitening are properly compensated in the digital realm.

 The cavity is actually "locked" as soon as the feedback loop is successfully closed.  One easy-to-spot symptom of this is that, as you mentioned elsewhere in your post, TRY is a ~constant non-zero, rather than spikey (or just zero).  Once you've maximized TRY, you've got the cavity locked, and the alignment optimized.

We didn't get to this part of "The Talk" about the birds, the bees, and the DTTs, but we'll probably need to look into increasing the amplitude of the excitation by a little bit at low frequency.  DTT has this capability, if you know where to look for it.

It would be great to see the model and your measurement overlayed on the same plot - they're easier to compare that way.  You can export the data from DTT to a text file pretty easily, then import it into Matlab and plot away.  Can you check and maybe repost your measured plots?  I think they might have gotten attached as text files rather than images.  At least I can't open them. 

 Cavity started out aligned pretty well, but not 100%.  Transmission was ~0.8 . Perhaps this was part of the problem.

I realize now that you mention it, it was totally amateur hour of me to only look at the lockin outputs on StripTool (plus POY and TRY on Dataviewer), and not look at TRY on DTT...or any spectra at all.  Not so intelligent.  I could see some fluctuation of TRY on Dataviewer that corresponded to me turning on the oscillators, as well as the spot wiggling on the camera view of ETMYT a teeny bit.

When applying a 10% misalignment to ETMY Pit (by adding 0.1 to the Pit components of the output matrix, as is done in the MC spot position calibration), I could see that there was a small jump in the StripTool trace, but it was much smaller than the ambient fluctuations of the output. 

I just looked back and realized that I must have forgotten to add my screenshot, but it's saved on a desktop on Rossa.  It would be better if I had attached the data, but from that you see that the average of the lockin output signal didn't change very much in the last several minutes of the measurement, but the fluctuations (no misalignment offsets) are pretty big, maybe ~10% or 15% the size of the signal.  Then when I added the misalignment to one mirror (ETMY PIT), there is a very small jump in the lockin signal, but it is much, much smaller than the size of the ambient fluctuations.  Perhaps a long average would result in a "real" value, but by looking by eye, I can't see a discernible difference in the average value of the lockin outputs.

My plan is to do as you say, dithering all 4 optics, and misaligning a single optic's single DoF (Pit or Yaw), and seeing how that misalignment affected each of the sensors (the lockin outputs).  Then put that DoF back to nominal, and misalign a different DoF, rinse and repeat.

Okay, so this is a little stream-of-consciousness-y, and you're going to think I'm really dumb, but I just realized that I haven't set the phase of the lockin demodulators yet.  So I think I need to dither the optics, and go through each of the sensors, and adjust the phase until the peak in TRY in DTT is maximized for the I phase, and minimized for the Q phase (since we use the I-output).  Bah.  Bad Jenne.

Today I spent time locking the YARM in order to calibrate the arm cavity. Here's what I did:

1. Misalign all optics other than the beam splitter, ITMY, ETMY and PZT2

2. Restore BS, ITMY, ETMY, and PZT2

3. Open Dataviewer and run /users/Templates/JenneLockingDataviewer/Yarm.xml from the Restore Settings. This opens the signals C1:LSC-POY11_I_ERR (the Pound-Drever-Hall error signal for this measurement) and C1:LSC-TRY_OUT (the light transmitted through ETMY) in the plot window.

4. Adjust ITMY and ETMY pitch and yaw using the video screens looking at AS and ETMYT as a first, rough guide. It can be helpful at first to increase the gain on the YARM servo filter module in the C1LSC control screen to about 0.3 and decrease it back down to 0.1 as the beam becomes better aligned. You know when to decrease this gain when fuzzy, small oscillations appear on the C1:LSC-TRY_OUT signal. If the mode cleaner is locked you should see a bright spot on the AS camera.

5. Tinker with pitch and yaw while looking at the AS screen until you see a reasonably good circular spot without other fringes extending from a bright center.

6. The overall goal is to maximize C1:LSC-TRY_OUT because the power transmitted through EMTY is proportional to the power within the cavity. A decent target value is 0.85 and today I was able to get it to just over 0.80 at best. At first there will probably be small spikes in C1:LSC-TRY_OUT. You want to adjust pitch and yaw until the deviation in the signal from zero is no longer just a spike, but a sustained, flat signal above zero. By this time there should be light showing up on the ETMYT camera as well.

7. Once that happens, continue to successively adjust ITMY and ETMY doing the pitch adjustments on both first, and then the yaw adjustments, or vice versa. You can also tweak the PZT2 pitch and yaw. Once you've got C1:LSC-TRY_OUT as large as possible, you've locked the cavity.

I saved the pitch and yaw settings I ended up with for ITMY, ETMY, BS and PZT2 in the IFO_ALIGN screen. Before the end of the day I think Jenne restored the rest of the previously misaligned optics because they were restored when I got back from dinner.

I also worked on calibrating the YARM. I opened up DTT using C1:LSC-POY11_I_ERR as the measurement channel and C1:SUS-ITMY_LSC_EXC as the excitation channel. I ran a logarithmic swept sine response measurement with 100 points and an amplitude of 25. The mode cleaner kept losing its lock all day, and if this happened while making this measurement I tried to pause the sweep as quickly as possible. I analyzed the the transfer function and the coherence function that the sweep produced, and thought that some of the odd behavior was due to losing the lock and getting back to a slightly different locked state when resuming the measurement. The measured transfer function and coherence plots are attached below. Both the transfer function and the coherence look good above roughly 30 Hz, but do not look correct at low frequencies. There's also a roll-off in the measured transfer function around 200 Hz, while in the model the magnitude of the transfer function drops only after the corner frequency of the cavity, around several kHz. I have attached a plot of the roughly analogous transfer function from the DARM control loop model (the gains are very large due to the large arm cavity gain and the ADC conversion factor of 2^16/(20 V) ). The measured and the modeled transfer functions are slightly different in that the model does not include the individual mirrors, while the excitation was imposed on ITMY for the measurement.

The next steps are to figure out what's happening in DTT with the transfer function and coherence at low frequencies, and to understand the differences between the model and the measurement.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 To ease the pain of hunting files, optical layout ACAD files have been moved to a new directory 40M_Optical Layout in the repository. Relevant files from directories Upgrade12 and upgrade 08 will be moved to "40M_Optical Layout" very soon and eventually these old directories will be removed. 

From the log, I couldn't understand what has been done.

The procedure we should perform is

1. Dither total 4 dofs of the two mirrors with different frequencies. Some fluctuation of TRY is even visible in dataviewer.
2. The cavity is aligned at the beginning. These 4 peaks in TRY in DTT is small or invisible. Some 2nd harmonics are visible.
3. Misalign one of the dofs. Some peaks get bigger.
4. Correspoding lockin output becomes bigger.

Then you can start measuring the sensing matrix. At which part did the attempt fail?

I turned on the ASS, without closing the loops, to try to measure the sensing matrix. 

The Yarm was locked (Eric did a nice job earlier - he'll ELOG ABOUT IT before he goes home!), and I used an LO CLKGAIN of 300 on all of the TRY Lockins.  Then I put on and took away a 10% offset in pitch, but it's almost impossible to see the difference. 

The attached is a truly awful screenshot, but you can kind of see what's going on.  The big steps are me increasing the LO gain, but around "0" on the x-axis I changed the pitch offset from 10% away to nominal.  Since there are such big oscillations, the change is basically non-existent.  Grrrr. I'll look at it again tomorrow, since I have an exiting bike ride home ahead of me....

Jan and I wanted to measure the ringdown at the IMC. Since the QPD at the MC trans is not fast enough for ringdown measurements, we decided to install a pickoff to include a faster PD while not disturbing much of the current MC trans configuration. The initial configuration had very little space to accommodate the pickoff. So the collimating lens along with the QPD were moved 2 inches closer to the incoming beam. A 50-50 BS was put in front of the QPD and the steering mirror was moved behind to reflect MC trans output to the new PD. The current configuration is shown below with the MC autolocker threshold mentioned in Jenne's elog

The hunt for a faster PD wasn't satisfactory and we found a couple of PDs that were good for measurements actually didn't work after installing them. The one currently installed is also not satisfactorily fast enough for ringdown measurements. We'll hunt for faster PDs at Bridge tomorrow and replace PDA400. Also the IMC unlocked from time to time....may be we were noisy and didn't master the 'interferometer walk' very well.

Jan and Manasa are going to elog about their work later, but it involved putting a BS/window/some kind of pick off in front of the MC Trans QPD, so the total light on the MC Trans QPD is now ~16000 rather than ~26000 counts.  I changed the threshold in the MC autolocker to 5000, so now the MC Trans PD must see at least 5000 counts before the autolocker will engage the boosts, WFS, etc.  Actually, this threshold I believe should have been some several thousand value, but when I went in there, it was set to 500 counts, for low power MC mode during a vent.  It had never gotten put back after the vent to some higher, nominal value.

Hey, the pages got significantly nicer than before. I will continue to give you comments if I find anything.

So far: There are many 10^-100 in logarithmic plots. Once they are removed, we should be able to see the seismic excitation during these recent earth quakes?

Incidentally, where the script is located? "./" isn't the absolute path description.

This week I spent most of my time learning about how the interferometer is calibrated and working on the calibration itself. I also looked more into the Pound-Drever-Hall technique.

Continuing work on the free-swinging Michelson measurements, I changed the signal that I was using to C1:LSC-ASDC_OUT_DQ. This is a proper power signal so that the peak-to-peak amplitude of this error signal can be directly read off the graph. The motivation to measure this amplitude is that it must be known in order to calibrate the actuation of the input and end test masses.

Next I looked into using DTT to make some measurements. I ran the Michelson restore script in the IFO Configure screen to adjust the optics to be near alignment. Then I tweaked the precise settings in the IFO Align screen of pitch and yaw for the ITMX, ITMY, and BS. The goal with this was to minimize the magnitude of the C1:LSC-ASDC_OUT_DQ signal. After it was well-aligned, back in DTT I sent in a sine wave excitation and used a Triggered Time Response measurement to see the output. As a first test I put the excitation signal in the ASDC channel and I was able to plot the resulting OUT signal in DTT. The amplitude was different than I input due to gains between the excitation and the point of measurement, but this can easily be accounted for by adjusting the amplitude in DTT accordingly.

The next step is to work on measurements of a single arm cavity, introducing excitations there and measuring the response.

As Rana pointed out (http://nodus.ligo.caltech.edu:8080/40m/7112), the geophone/accelerometer noise lines from my last eLog (http://nodus.ligo.caltech.edu:8080/40m/7109) were dominated by ADC noise. I checked this today by terminating the ADC channels with 50 Ohm terminators and measuring the noise. The ADC noise line is included on the plot below, and it is clearly dominating the sensor noise data.

I set the accelerometer gain to 100, and will hook up the geophones to the SR560 pre-amp today- this should put both signals above the ADC noise, and I can calculate the sensor noises without the ADC noise being significant.

I have also begun to make some progress in understanding the pre-amp circuitry, and I will post a schematic when I've sketched it all.

Another issue that seems increasingly relevant to me is the power supply to the high voltage amplifier. It appears to go into the high voltage board from the power supply, then into the geophone pre-amp, then back into the high voltage board (see block diagram below). I tested this by inputting a signal after the pre-amp, with the geophones disconnected- the signal only drives the PZT if the pre-amp is plugged in, so the power that returns from the pre-amp must be powering some chips on the high voltage amplifier.

Power flow through the STACIS :

This is somewhat inconvenient, because it means if I want to provide external feedback (with accelerometers, for example) or actuation (such as feedforward), which I want to input after the geophone pre-amp, the pre-amp still needs to be plugged in for the high voltage amplifier to work and drive the PZTs.  I am cataloging all of the pins on the high voltage amplifier and pre-amp so I can figure out how to reroute the power and cut out the geophone pre-amp entirely if necessary. I'll include a pin diagram with the pre-amp circuit sketch.

The main thing that I did this week was write a C block that, given static weights, would classify seismic signals (into one of three categories - Earthquake, Truck, Quiet). I have successfully debugged the C block so that it works without segmentation faults, etc, and have made various versions - one that uses a recurrent neural network, and one that uses a time-delayed input vector (rather than keeping recurrent weights). I've timed my code, and it works very fast (to the point where clock() differences in <time.h> are 0.000000 seconds per iteration). This is good news, because it means that operations can be performed in real-time, whether we are sampling at 2048 Hz, or, as Rana suggested, 256 Hz (currently, my weights are for 256 Hz, and I can decimate the incoming signal which is at 2048 Hz right now).

In order to optimize my code, since at the core it involves a lot of matrix multiplications, I considered how the data is actually stored in the computer, and attempted to minimize pointer movement. Suppose you have an array in C of the form A[num_row][num_col] - the way this array is actually stored on the stack or heap is row_1 / row_2 / row_3 / ... / row_num_row, so it makes sense to move across a matrix from left to right and then down (as though reading on a page). Likewise, there's no efficient algorithm for matrix multiplication which is less that O(N^2) (I think), so it's essentially impossible to avoid double for loops (however, the way I process the matricies, as mentioned before, minimizes this time).

The code is also fast because, rather than using an actual e^-u operation for the sigmoidal activation function, it uses a parametrized hyperbola - this arithmetic operations are the only ones that occur, and this is much faster than exponentiation (which I believe is just computer by Taylor series in the C math library..)

The weight vectors for this block are static (since they're made from training data where the signal type is already known). I am not currently satisfied with the performance of the block on data read from a file, so I am retraining my network. I realized that what is currently happening is that, given a time-dependent desired output vector, the network first trains to output a "quiet" vector, then a "disturbance" vector, and then retrains again to output a "quiet vector" and completely forgets how to classify disturbance. Currently, I am trying to get around this problem by shifting my earthquake data time-series, so that when I train in batch (on all of my data), there is probably an earthquake at all time points, so that the network does not only train on "quiet" at certain iterations. Likewise, I realized that I should perform several epochs (not just one) on the data - I tried this last night, and training performance MSE decreased by a factor of 1 per iteration (when on average, it's about 40, and 20 at best).

After I input the static weight vectors (which shouldn't take long since my code is very generalized), the C block can be added to the c1pem frame, and a channel can be made for the seismic disturbance class. I've made sure to keep with all of the C block rules when writing my code (both in terms of function input/output, and in terms of not using any C libraries).

As for neural networks for control, I talked to Denis about the controller block, and he realized that we should, instead of adding noises, at first attempt to use a reference plant with a lower Q pendulum and a real plant with a higher Q pendulum (since we want pendulum motion to be damped). I've tried training the controller block several times, but each time so far the plant pendulum has started oscillating greatly. My current guess at fixing this is training more.

Also, Jenne and I made a cable for Guralp 1 (I soldered, she explained how to do it), and it seems to work well, as mentioned in my previous E-log. Hopefully it can be used to permanently keep the seismometer all the way down the arm.

This week, I brought my c1lsp model online and fixed up some the medm screens for c1spx. Along the way, I ran into a few interesting problems (and learned a bit about bash scripting and emacs! :D). The screens for the main TM_RESP matrix are not generating automatically, and the medm screens don't want to link to the channels, for some reason. I don't have this problem with the other matrices (i.e. C2DOF and SEN_OUT), so I think it has something to do with TM_RESP being a filter matrix (which the others are not). In addition, the noise overview medm screens for c1spx are practically nonexistent - someone just copied the file for the SUS-ETMX screens into the master directory for c1spx, so they need a complete overhaul. I am willing to do this, but Jamie told me to focus my attentions elsewhere.

So I went back to noise generation. I've been using Matlab to figure out how to recreate the various noise sources (laser amplitude noise, local oscillator phase/amplitude noise, and 60 Hz/ADC. Frequency noise will be added some time this week and seismic noise should be already covered in Jamie's suspension model) in my c1lsp model. I'm doing it the way the RCG does it - by applying a filter to white noise. I'm generating white noise by just using a random number generator and pwelch-ing it to get the power spectral density.

For the filters themselves, I picked z, p, k such that it shaped the white noise PSD to look like the PSD of the noise in question. This was fairly straightforward once I figured out how zeroes and poles affected PSD. Once I'd picked zpk, I applied a bilinear transform to get a discrete zpk out, then converted to a second order section to make computation faster. I then applied that to the white noise (matlab has a convenient "sosfilt" function) and pwelch-ed/graphed it to get the result.

Attached is my attempt at filtering white noise to look like 60 Hz. noise. I can't seem to find a way to pick z and p such that the peak is more narrow (i.e. other than having two complex conjugated poles at 60 Hz.). I took the spectrum of 60 Hz. noise from a terminated ADC channel (Masha kindly let me borrow one of her GURALP channels).

EDIT: I also remembered that I've been looking for how to get a good power spectrum for the rest of the noises. Jenne referred me to Kiwamu's work on this, and I'm mostly going off elog #6133. If you have any other good elogs/data on noises, please feel free to send them my way.

I then measured the PSD of the sensors on the real suspended optics and a PSD of the suspension model. It looks like the OSEMs on the suspension model are only reading white noise, which probably means a lost connection somewhere (Attachment 2 is what the model SHOULD produce, Attachment 3 is what the model ACTUALLY produces). I perused Jamie's model, but couldn't find anything. Not sure where else to check, but I'll continue thinking about it/trying to fix it.

Over the past week, I have been working on my progress report and finalizing the summary pages.  I have a few more things to address in the pages (such as starting at 6 AM, including spectrograms where necessary and generating plots for the days more than ~a week ago) but they are mostly finalized.  I added all of the existing acoustic and seismic channels so the PEM page is up to date.  The microphone plots include information about the transfer factor that I found on their information sheet (http://www.primomic.com/).  If there are any plots that are missing or need editing, please let me know!

I also modified the c1_summary_page.sh script to run either the daily plots or current updating plots by taking in an argument in the command line.  It can be run ./c1_summary_page.sh 2012/07/27
 or ./c1_summary_page.sh now to generate the current day's pages.  (Essentially, I combined the two scripts I had been running separately.)  I have been commenting my code so it is more easily understandable and have been working on writing a file that explains how to run the code and the main alterations I made.  The most exciting thing that has taken place this week is that  the script went from taking ~6 hours to run to taking less than 5 minutes.  This was done by using minute trends for all of the channels and limiting the spectrum plot data.

The summary pages for each day now contain only the most essential plots that give a good overview of the state of the interferometer and its environment instead of every plot that is created for that day.

I am waiting for Duncan to send me some spectrogram updates he has made that downsample the timeseries data before plotting the spectrogram.  This will make it run much more quickly and introduce a more viable spectrogram option.

Today's Summary Pages can be accessed by the link on the wiki page or at:

https://nodus.ligo.caltech.edu:30889/40m-summary/archive_daily/20120808/

There were another couple of earthquakes at about 9:30am and 9:50am local.

All but MC2 were off the watchdogs.  I damped and realigned everything and everything looks ok now.

[Sasha, Masha, Liz, Eric]

A bunch of surfs in the lab just noticed that ETMX is going crazy (laser is shifting everywhere) due to a 4.5 EQ that just hit LA. The optic is already shut down according to the watchdogs.

Looks like you're just measuring the ADC noise. You should add ADC noise to your plot. To compare the geophones with the accelerometers, you have to correct for the preamp gain and plot them both in the same units.

To get above the ADC noise you can use an SR560 preamp. (AC Coupled, G = 100)

 All optics except MC2 and ETMX are crazy

 Just felt an EQ. Impulse moved some vertical blinds by several mm.

Tue Aug 07 23:26:06 2012 

Yesterday I plugged the geophone and accelerometer output into the ADC, rather than the SR785, so I could collect for longer and take more data at once.

As per Rana's suggestion, I am also now taking the geophone output after the first op-amp in the circuitry following the geophone (a low-noise op-amp, OPA227). It acts as a buffer so I'm not just measuring other local noise sources (which explains why the geophone noise curve sort of matched the SR785 noise curve in my old plots).

With these changes, I remeasured the accelerometer and geophone noises as well as collected an ASD of a geophone sitting on the STACIS in open loop operation. I also looked up the noise specs for the various op-amps in the geophone pre-amp and high voltage board; everything I found, I added in quadrature to come up with an approximate op-amp noise value for the STACIS. All of this is plotted below:

I left the y-axis in V/rtHz instead of converting it to m/s/rtHz so that the op-amp noise could be compared to the other noises. All sensor data was taken with the sensors horizontal (noise data taken in granite and foam).

The accelerometer and geophone noise still appear to be similar, and the op-amp noise, at least according to specs, is low compared to the other noises. This implies there's not much to gain from switching the geophones with accelerometers nor with swapping out the op-amps for lower-noise components (unless the ones I couldn't find specs for were high-noise, though it seems like mainly low-noise components were used). 

Please check the summary pages out at the link below and let me know if there are any modifications I should make!  All existing pages are up to date and contain all of the pages I have.

Questions, comments, and suggestions will be appreciated! Contact me at endavison@umail.ucsb.edu

https://nodus.ligo.caltech.edu:30889/40m-summary/

 Good. The power density and max power are not important (especially since you don't define a quantitative way to spec them). We ONLY care about the transmission.

 Sanwiched wall as shown: 1" clear acrylic, 2 layers of 0.004" thick "window tint", 1 layer of  0.007" thermashield and  0.125" yellow acrylic

Visibility: 70 %,    Transmission of 1064 nm  2-3 % at 0-50 degrees incident  power density 0.7 W/mm2

Max power 100 mW

Apparently the last problem was because of root-owned frame directories that daqd was trying to write to.  During debugging Alex had run daqd as root, but it's supposed to run as controls.  All the /frame directories are supposed to be owned by controls.  When daqd was run as root, it created new frame directories owned by root, which controls couldn't write to when I restarted daqd the proper way.  Once we chown'd the directories daqd started running again.

Alex also put in a "fix" for the core dump problem.  He touched an empty core file owned by root:

-rw-r--r-- 1 root root 0 Aug  7 14:38 /opt/rtcds/caltech/c1/target/fb/core

This will prevent any dying daqd process owned by controls from dumping it's core at that location.  Personally I think this is a horribly hacky "solution" that doesn't actually fix any of the issues that were causing the segfaults to begin with, but it might prevent some of the network slow down we see when the core does dump.  It's mostly just masking the problem, though, so I'm tempted to remove it so we all feel the pain when daqd starts shitting all over the network again.

Previously, medmrun didn't accept arguments to pass along to the script it was going to run.  Jamie has graciously taken a moment from fixing the computer disaster to help me update the medmrun script.

Now the ASS scripts are call-able from the screen.