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.

 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.

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.

 The spot was still off center on the quad display in the control room, so I re-recentered it today.

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.

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"

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

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.

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 - a₁ and a₂ 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.

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.

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.

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.

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?

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.

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

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!

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.

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!  

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
• ???

 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.

This is a good modification. We just need to check how the ALS scripts are affected.

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.

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.

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.

I have added a DQ block to the sus_single_control library part.  This means that all sus models will automatically generate DQ channels based on what is specified in this doc block:

#DAQ Channels

SUSPOS_IN1
SUSPIT_IN1
SUSYAW_IN1
SUSSIDE_IN1
ULSEN_OUT
URSEN_OUT
LRSEN_OUT
LLSEN_OUT
SDSEN_OUT
OLPIT_IN1
OLYAW_IN1
OLSUM_IN1

So for instance, for BS will have the following DQ channels:

C1:SUS-BS_SUSPOS_IN1_DQ
C1:SUS-BS_SUSPIT_IN1_DQ
...

etc.  The channels names modified by the activateDQ.py script after install are still modified appropriately.

This is now the place where we should be maintaining DQ channels.

 I turned the Yend laser back on....it hasn't turned itself off yet, but I'm watching it.  As long as we leave the shutter open, we can watch the C1:ALS-Y_REFL_DC value to see if there's light on the diode.

[Rana, Jenne]

We looked at the different outputs of the MC servo board to make sure they make some kind of sense.  As per my elog 6625, the names of the channels were wrong, but we wanted to confirm that we have something sensible.

Currently, OUT1 of the servo board is called "MC_F" and the SERVO out is called "MC_SERVO".  We looked at the spectrum of each, and the transfer function between them.

You can see that in addition to a 2kHz pole, MC_L also seems to have a 10-100 zero-pole pair.

Also, while cleaning things up in the models, I fixed the names of these MCL/MCF channels.  OUT1 is now called MC_L, and is connected to ADC0_0, and SERVO is called MC_F and is connected to ADC0_6.  Both MC_L and MC_F go to the RFM, and thence on to the OAF.  MC_L (which used to be mis-named MC_F) still goes both to the MCS model for actuation on MC2, and to the OAF for MC-OAF-ing.  Right now MC_F is unused in the OAF model, but we can change that later if we want.

Jamie and I were doing some locking, and we found that the Yarm green wasn't locking.  It would flash, but not really stay locked for more than a few seconds, and sometimes the green light would totally disappear.  If the end shutter is open, you can always see some green light on the arm transmission cameras.  So if the shutter is open but there is nothing on the camera, that means something is wrong.

I went down to the end, and indeed, sometimes the green light completely disappears from the end table.  At those times, the LED on the front of the laser goes off, then it comes back on, and the green light is back.  This also corresponds to the POWER display on the lcd on the laser driver going to ~0 (usually it reads ~680mW, but then it goes to ~40mW).  The laser stays off for 1-2 seconds, then comes back and stays on for 1-2 minutes, before turning off for a few seconds again.

Koji suggested turning the laser off for an hour or so to see if letting it cool down helps (I just turned it off ~10min ago), otherwise we may have to ship it somewhere for repairs :( 

I've implemented online frequency domain filter and applied it to MC_F.

+

Magnitude of the filter output at 1 Hz is the same as MC_F. This means that it is not hard for FIR to match the resonance. The problem is with the phase. We can not match the resonance exactly. If the resonance is at f₀ and we match at f₀ +/- df then in the frequency range (f₀, f₀ +/- df) the phase is not matched for 180. I guess the filter does not diverge because df is small but also the filter can not account for this huge phase lag. We need to slightly change the simulated actuator TF and see how the filter will react.

As I've spent many hours trying to determine the error in my C code for online filter I decided to write about it to prevent people from doing it again.

I have a C function that was tested offline. I compiled and installed it on the front end machine without any errors. When I've restarted the model, it did not run.

I modified the function the following way

I've adjusted input parameters such that STATEMENT was always true. However the model either started or not depending on the code after if statement. It turned out that the model could not start because of the following lines

cosine[1] = 1.0 - 0.5*a*a + a*a*a*a/24 - a*a*a*a*a*a/720 + a*a*a*a*a*a*a*a/40320;
sine[1] = a - a*a*a/6 + a*a*a*a*a/120 - a*a*a*a*a*a*a/5040;

When I've split the sum into steps, the model began to run. I guess the conclusion is that we can not make too many arithmetical operations for one "=" . The most interesting thing is that these lines stood after true if-statement and should not be even executed. Possible explanation is that some compilers start to process code after if-statement during its slow comparison. In our case it could start and then broke down on these long expressions.

 PMC transmission is oscillating  in the range 0.5 - 0.85. PMC PZT voltage is 1-2 V.

FSS slow controls was -2.5 V. I adjusted it to 0 and PMC stabilized. PMC PZT voltage is 128, transmission is 0.845.

But most probably, slow control will drift again.

Since there are various ongoing requests for this from the sites, I have moved all of our custom MEDM screens into the cds_user_apps SVN repository.  This is what I did:

For each system in /opt/rtcds/caltech/c1/medm, I copied their "master" directory into the repo, and then linked it back in to the usual place, e.g.:

a=/opt/rtcds/caltech/c1/medm/${model}/master
b=/opt/rtcds/userapps/trunk/${system}/c1/medm/${model}
mv $a $b
ln -s $b $a

Before committing to the repo, I did a little bit of cleanup, to remove some binary files and other known superfluous stuff.  But I left most things there, since I don't know what is relevant or not.

Then committed everything to the repo.

I did a raw calibration of MCL and GUR. Accuracy is a factor of 2.

GUR path : 800 V/m/s => readout box (G~100) => ADC (0.7 mV/count)

MCL path : laser 1 MHz / V, cavity length ~ 25 m

I measured feedback signal before the laser with SR and avoided whitening filters for MC_F.

Jenne, Den, Rana

The PMC transmission has been varying a lot and the MC seems unstable. Superstitious people might blame this on the El-nino or the alignment with Sagitarius, but we are ostensibly scientists.

WE found that the PMC EPICS values had not been toggled since the reboot and so the RF phase and Amplitude were totally wrong (we should replace this with a fixed oscillator box as we did with FSS).

Also, the NPRO SLOW slider was at -2 V which made the mode going into the PMC funny (although the mode was OK this morning before I started playing with the PMC sliders).

Before adjustment, there was a strong correlation between the seismic motions and the PMC reflection. This means that the PMC gain was low and it couldn't stay locked. Now, after fixing the RF and upping the gain slider it looks more stable. Let's watch it for a few days to see if there's an improvement in the trends.

The 10-minute trend of the lat 400 days shows that nothing has changed much this year; its been equally bad for a long while.

WE tried to use the new conlog today and discovered that:

1) No one at the 40m uses conlog because they don't know that it ever ran and don't know how to use regexp.

2) It has not been running since the last time Megatron was rebooted (probably a power outage).

3) We could not get it to run using the instructions that Syracuse left in our wiki.

Emails are flying.

I used APTITUDE to install texlive-full on rosalba so that I could work on a paper. pdflatex was not found on pianosa, rosalba, megatron, etc. I used this command:

sudo aptitude install texlive-full

While this was installing, I read a bunch of forums which claim that its better to bypass the apt-get and use the 
TexLive installer instead so that we can use its own package updater 'tlmgr'. Otherwise, the standard Ubuntu distributions
are years out of date (e.g. doesn't have RevTex 4.1).

The MC unlocked ~20 min ago, correlated with 2 consecutive earthquakes in Mexico.  The MC came back fine after a few minutes, but the WFS never engaged.  I turned them on by hand.  I think that Yuta mentioned once that he also had to turn the WFS on by hand.  There may be a problem in the unlock/relock catching that needs to be looked at, to make sure the WFS come back on automatically.

Also, someone (Masha and I) should look at the seismic BLRMS.  I have suspected for a few days that they're not telling us everything that we want to know.  Usually, if there's an earthquake close enough / big enough that it pops the MC out of lock, it is clear from the BLRMS that that's what happened, but right now it doesn't look like much of anything....just kind of flat for hours.

I learned a little bit of python scripting while looking at the videoswitch script, and I made a video medm screen. 

Each monitor has a dropdown menu for all the common cameras we use (medm only lets you put a limited # of lines on a dropdown menu...when we want to add things like OMCR or RCT, we'll need to add another dropdown set)

Each monitor also has a readback to tell you what is on the TV.  So far, the quads only say "QUAD#", not what the 4 components are. 

I put a set of epics inputs in the PEM model, under a subsystem with top-names VID to represent the different monitors.  The readbacks on the video screen look at these, with the names corresponding to the numbers listed in the videoswitch script.  The videoswitch script now does an ezcawrite to these epics inputs so that even if you change the monitors via command line, the screen stays updated.

For example, since MC2F's camera is plugged in to Input #1 of the video matrix, if you type "./videoswitch MON1 MC2F", the script will write a "1" to the channel "C1:VID-MON1", and the screen will show "MC2F" in the Mon1 cartoon.

This required a quick recompile of the PEM model, but not the framebuilder since these were just epics channels.

There is also a dropdown menu for "Presets", which right now only include my 2 arm locking settings.

All of the dropdowns just call an iteration of the videoswitch script.

Most of my work has been on continuing to develop the Simulink model of the differential arm length control loop.
I have filled in transfer functions for the digital components after looking up the configuration of filters and
gains on the control screens. Filters that were active at the time included 1:50 and 1000:10 on C1LSC_YARM and
C1LSC_POY11 with a gain of 0.1. Jamie also introduced me to foton so that I could obtain the transfer functions
for the necessary filters. I have also continued to work on obtaining the open loop gain and length response
function from the model. The majority of the work now is to refine what I've accomplished so far. Adding details
to the arm cavity and the optics is one potential area for improvement.

I have also spent some time looking at real-time calibration methods from GEO and a proposal for a similar system
on LIGO in P040057-x0 from the DCC. While the work for this project may follow a different path for a real-time
calibration, having a sense for what's been accomplished so far should be helpful in working on a new system.

The script ....../scripts/ASS/MC/mcassMCdecenter  takes ~17 minutes to run.  The biggest time sink is measuring a no-offset-added-to-coil-gains set, in between each measurement set with the coil gain offsets.  This is useful to confirm that the nominal place hasn't changed over the time of the measurement, but maybe we don't need it.  I'm leaving it for now, but if we want to make this faster, that's one of the first things to look at.

Today's measurement:

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[3.5716862287669224, 3.937869278443594, 2.9038058599576595, -6.511822708584913, -0.90364583591421999, 4.8221820002404279]

There doesn't seem to be any spot measurement stuff for any other optics, so I'm going to try to replicate the MC spot measuring script for the Michelson to start.

I have been working on substituting the internal geophones in the STACIS with accelerometers, and this week specifically I have been trying to modify the accelerometer signal so the STACIS PZTs respond properly.

The major problem was that the high signal amplitude caused the STACIS to oscillate uncontrollably, so I lowered all of the pots (for the z direction) and placed several BNC attenuators before the accelerometer signal enters the first amplifier board. The accelerometers now successfully provide feedback without making the STACIS unstable, as shown by this transfer function (the higher and flatter line is open loop, the lower is closed loop with accelerometers providing feedback):

The next step is to optimize the accelerometer feedback so it provides good isolation from 0.1 to 3 Hz, a span that the geophones introduced a lot of noise into. The accelerometers definitely don't introduce as much noise in that region, but don't seem to be doing much isolation either. I will also make some more quantitative plots of the platform motion (using the calibration value for the Wilcoxon accelerometers in the velocity setting with a gain of 1).

Some random discoveries I made this week which are relevant for STACIS testing:

1) Placing weight on the STACIS platform improves stability, but NOT if several blocks are placed on top of each other (they rub against each other, causing lots of vibrations).

2) The accelerometer that is providing feedback must be VERY securely fastened to the STACIS platform; even with three clamps there was extra motion that caused instability. Luckily, there's a convenient steel flange Steve showed me which has a hole that perfectly accommodates the accelerometer and doubles as a weight for the platform. Here is said flange, clamped to the STACIS platform with the accelerometer sitting in the center:

 3) Using the shaker next to the STACIS (all on one platform) improves coherence between the base and platform accelerometers above around 10 Hz, but does nothing lower than that, which unfortunately is the region I'm most concerned with.

I realized what the ADC channel mismatch was, and apologize for plotting a terrible coherence in log scale. The channels are now properly matched (there is decent coherence between GUR1_X/STS_X, etc.).

Over the past week, I have been focusing on the issues I brought up in my last ELOG,  6956.  I spent quite a while attempting to modify the script and create my own spectrogram function within the existing code.  I also checked out the channels on the PSL table for the PSL health page and produced a spectrogram plot of the PMC reflected, transmitted, and input powers, the PZT Voltage and the laser output power.  When I was entering these channels into the configuration script, I came across an issue with the way the python script parses this.  If there were spaces between the channel names (for example: C1:PSL-PMC_INPUT_DC, C1:PSL-PMC_RFPDDC... etc) the program would not recognize the channels.  I made some alterations to the parsing script such that all white spaces at the beginning and end of the channels were stripped and the program could find them.

 The next thing that I worked on was attempting to see if the microphone channels were actually stopping the program or just taking an extraordinarily long time.  I tried running the program with shorter time samples and that seemed to work quite well!  However, I had to leave it running overnight in order to finish.  I am sure that this difference comes from the fact that the microphone channels are fast channels.  I would like to somehow make it run more quickly, and am thinking about how best to do this.

I finally got my spectrogram function to work after quite a bit of trouble.  There were issues with mismatched data and limit sets that I discovered came from times when only a few frames (one or two) were in one block.  I added some code to  ignore small data blocks  like those and the program works very well now!  It seems like the best way to get the right limits is to let the program automatically set the limits (they are nicely log-scaled and everything) but there are some issues that produce questionable results.  I spent a while adding a colormap option to the script so that the spectrogram colors can be adjusted!  This mostly took so long because, on Monday night, some strange things were happening with the PMC that made the program fail (zeros were being output, which caused an uproar in the logarithmic data limits).  I was incredibly worried about this and thought that I had somehow messed up the script (this happened in the middle of when I was tinkering with the cmap option) so I undid all of my work!  It was only when I realized it was still going on and Masha and Jenne were talking about the PMC issues that I figured out that it was an external issue.  I then went in and set manual limits so that a blank spectrogram and redid everything.

The spectrogram is not operational and the colormap can be customized.  I need to fix the problem with the autoscaled axes (perhaps adding a lower bound?) so that the program does not crash when there is an issue.

Yesterday, I spoke with Rana about what my next step should be.  He advised me to look at ELOGs from Steve (6678) and Koji (6675) about what they wanted to see on the site.  These gave me a good map of what is needed on the site and where I will go next.

I need to find out what is going on with the weather channels and figure out how to calibrate the microphones.  I will also be making sure there are correct units on all of the plots and figure out how to take only a short section of data for the microphone channels.  I have already modified the tab template so that it is similar to Koji's ELOG idea and will be making further changes to the layout of the summary pages themselves.  I will also be working on having the right plots up consistently on the site.

This past week, I've been working on moving forward with the basic cavity model I developed last week (for future reference, that model was FP_3, and I am now working on FP_4) and refining the suspensions. I added three degrees of freedom to my simulation (such that it now consists of yaw, pitch, displacement, and side-to-side motion) and am attempting to integrate them with the OSEMS. I have also added mechanical damping for all degrees of freedom, and am adding electric damping and feedback. Concerning that, are all of the degrees of freedom locally damped in addition to being actuated on by the control system? Or does the control system do all of the damping itself? The first is the way I'm working on setting it up, but can easily change this if needed.

The next iteration of FP (FP_5) will replace my complicated OSEM --> Degrees of Freedom and vice versa system with the matrix system (see the poster Jenne and Jamie made, "Advanced Suspension Diagnostic Procedure"), as well as adding bounce/roll, yaw/y coupling, various non-damping filters as needed (i.e. the a2f filters), and noise sources. However, I'll only move on to that once I'm sure I have FP_4 working reasonably well. For now at least, the inputs/outputs look fine, and some of the DOF show resonance peaks. I'll become more concerned about where these resonance peaks actually are once I add damping.

Attached is a screenshot my work in progress. Only one of the suspensions has a basic feedback/damping loop going (as a prototype). It looks complicated now, but will simplify dramatically once I have damping worked out. Pink inputs are noises (will probably replace those with noise generators in FP_5) and green inputs are the OSEMS. The red output is the displacement of the cavity from resonance. The blue boxes are suspensions.

This week, I continued to work with my Artificial Neural Network. Specifically, I implemented a 3-hidden layer sigmoidal, gradient-descent supervised network, with 3 neurons in the final output layer, since I have introduced a new class, trucks. I have overcome my past data limitation, since I observed that there is a multitude of trucks that comes between 9 and 10 am, and thus I have observed a bunch of trucks after the fact (their seismic patterns are rather distinct, and thus there could prove to be a very large supply of this data - I have gathered data on the past 50 days so far, and have gathered 60+ truck patterns).

With 3 classes, the two-layer network converges in ~200 epochs, while the 3-layer network takes around ~1200 (and more time per iteration). Since the error gradients in the stochastic gradient descent are recursively calculated, the only real time limitation in the algorithm is just lots of multiplication of weight / input vectors, lots of computation of sigmoidal functions, and lots of data I/O (actually, since the sigmoidal function is technically an exponentiation to a decimal power and a division, I would be curious to know if theory or Matlab has any clever ways of computing this faster that can be easily implemented - I will look into this today). Thus, the networks take a long time to train. I'm currently looking at optimizing the number of layers / number of neurons, but this will be a background process for at least several days, if not the next week. In the greater scope of things, however, training time isn't really a problem, since the actual running of the algorithm requires only one pass through the network, and the network should be as well-trained as possible. However, due to the fact that I am only here until the end of August, it would be nice to speed things up.

As far as other classifications, I can simulate signals either by dropping the copper block from the Stacis experiment, or by applying transfer functions to general seismic noise. However, I would like more real data on noise sources, but the only other one plausible to LIGO that I can currently think of (cars don't show up very well) is the LA Metro. Perhaps I will take a day to clock trains as they come in (since the schedule is imprecise) and see if there is any visible seismic pattern.

I also, with the help of Yaakov, Jenne, and Den, now have three working, triangulated seismometers, which can now begin taking triangulation data (the rock tumblers are still working, so there should be opportunities to do this), both to find hot-spots as Rana suggested, and to measure the velocity and test out my algorithm, as Den suggested.

The Streckeisen is currently plugged into ADC channels 13, 14, and 15 (corresponding to STS-3 in the channels). The X, Y, and Z components are correct. The signals is zeroed (it's been so for at least the past 10 hours), the coherence with GUR1 looks decent, and the signal looks similar to the GUR1 signal.

I was trying to lock and look at the ASS for the Yarm, but the transmitted power was oscillating very near 1Hz.  Eventually I looked at the mode cleaner, and it was also moving around at a similar frequency.  I took spectra of the ETMY SUS damping feedback signals, and they (POS, PIT, YAW) saw this 1Hz motion too (see attached plots...same data, one is a zoom around 1Hz).

As a first place to start, I turned off the WFS, which immediately stopped the MC oscillation.  Turning the WFS back on, the oscillation didn't come back.  I'm not sure what happened to make the WFS bad, but I perhaps had the ASS dither lines on (I've had them on and off, so I'm not sure), although turning off the dither lines didn't make the WFS any better.

As an aside, the MC refl with the WFS off was ~1.5, rather than the ~0.5 with the WFS on, which means that the PSL beam and the MC axis are not well matched.

Den and investigated the STS-1 problem (which is currently plugged into ADC channels 13, 14, and 15, which correspond to the STS-3 channels in dtt). It turns out that I had plugged in the power to the monitor in the host box rather than the remote. The X, Y, and Z readout is currently approaching a mean of zero, and I will let it continue to do so overnight (pressing auto-zero as necessary). Attached is a plot of the coherence with GUR 1, and the time-domain signals.

The names of the DoF filters in the ASS loop were wrong.  The filters themselves were correct (low pass filters at super low freq, for the Lock-in), but the names were backward.

Our convention is to name filters "poles:zeros", but they had been "z:p".  The names of FM1 in all the DoF filter banks are now fixed.