The PRM was pointing totally the wrong way, so there was no light on the oplev PD.  I restored the PRM, turned the gains back to (0.15, -0.3) as per Yuta's elog 6952, and it seems just fine to me.

I want to check the data from last night / the weekend to see when the mispointing happened, but dataviewer can't connect to the fb, since Jamie is still working his magic.  I'm pretty sure I restored all of the optics after Eric finished playing with MICH Friday night, but it's possible that I forgot one, I suppose.  If it wasn't me, then I'm curious when it happened.

When the network / fb went bad this afternoon, I had been working on the ASS model, shortening the names of the filter banks to fix the problem from elog 7092.  I wanted to finish working on that, so the ASS model is now rebuilt with slightly shorter names in the filterbanks (which fixes the problem of the filter banks not working).

------------------------------------------------------------

I mentioned this to Jamie the other day, but here's the error that you get when the GoTo/From tags aren't working:

>>rtcds make c1ass
### building c1ass...
Cleaning c1ass...
Done
Parsing the model c1ass...
IPC 9 8 is C1:LSC-ASS_LSC
IPC 9 8 is ISHME
IPC 10 9 is C1:RFM-LSC_TRX
IPC 10 9 is IPCIE
IPC 11 10 is C1:RFM-LSC_TRY
IPC 11 10 is IPCIE

INPUT XARM_LSC_in is NOT connected

INPUT YARM_LSC_in is NOT connected

***ERROR: Found total of ** 2 ** INPUT parts not connected

make[1]: *** [c1ass] Error 255
make: *** [c1ass] Error 1

I don't know why these tags weren't working, but there was a GoTo tag on the output of the LSC shmem block, and then Froms on each of the XARM_LSC_in and YARM_LSC_in.  The other day I played around with a bunch of different things (grounding inputs, terminating outputs, whatever), but finally replacing the tags with identical ones freshly taken from CDS_PARTS made it happy. 

I wrote new setup, on and off scripts for the arm ass.  They take the arm as an argument, so it's the same script for both arms.  Scripts are in ...../scripts/ASS/ , and have been checked in to the 40m svn.

So far the on script doesn't really do anything, since I haven't chosen values for the CLKGAINs of the lockins.  The old values were 30 for lockins 12, 14, 27, 29 and 250 for lockins 7, 9, 22, 24.  Unfortunately, I have no memory of which lockin means what in the old numbered system.  I'll have to look that up somehow.  Or, just dither the optics using some value and look at the spectrum to see the resulting SNR and just pick something that gives me reasonable SNR.

I modified the ASS model slightly:

* Added an overall gain to the ASS_DOF2 library part, between the matrix and the servo inputs so we can do soft startups.  Self - remember that the main ASS screen needs to be modified to reflect this!

* Rearranged the order that the demodulated signals go into the matrix.  I hadn't paid attention, and the old ordering had the transmission (TRX/TRY) demod signals interleaved with the LSC demod signals.  I've changed it to be all the TR signals, then all the LSC signals.  I think this makes more sense, since we will use these inputs separately, so now they're on different halves of the matrix.

Alex is apparently working on daqd (remotely).  I'll report back when I find out more.

So daqd's problem was apparently the bad/non-running c1sup model.  The c1sup model, which I reported on attempting to get running in 7097, was not running because there were no available CPUs on the c1sus FE machine.  This was due to my stupid undercounting of the number of CPUs.  Anyway, for reasons I don't understand, this was causing daqd to segfault.  Removing c1sup from c1sus "fixed" the problem.

Alex agreed that daqd should definitely not be segfaulting in this circumstance.  It's still unclear exactly what daqd was looking at that was causing it to crash.

I'm going to move c1sup to c1iscex, which has a lot of spare CPUs.

I spoke too soon.  It's still segfaulting, but at a different place. Alex and I are looking into it.

But another mystery solved is the cause of all the network slowness: the daqd core dump.  When daqd segfaults it dumps it's core, which can typically be >4G, to /opt/rtcds/caltech/c1/target/fb/core.  This is of course an NFS mount from linux1, so it's dumping 4G on the network, which not surprisingly clogs the network.

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.

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.

 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

 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.

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/

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

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

Tue Aug 07 23:26:06 2012 

 All optics except MC2 and ETMX are crazy

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)

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

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.

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/

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.

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.

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.

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.

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.

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.

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.

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

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?

 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. 

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

 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!

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.

 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.

 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. 

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.

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.

 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.

 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.

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.

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

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.

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

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

 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.

 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!

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.

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.

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";