40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 140 of 341  Not logged in ELOG logo
IDup Date Author Type Category Subject
  6998   Sat Jul 21 14:05:21 2012 DenUpdatePSLPMC problems examined

Quote:

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

 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.

fss_slowm.png

  6999   Sat Jul 21 14:48:33 2012 DenUpdateCDSRCG

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

void myFunction()
{
if(STATEMENT) return;
some code
}

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.

  7000   Sat Jul 21 18:04:02 2012 DenUpdateAdaptive Filteringfrequency domain filter

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

freq_af.png+

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 f0 and we match at f0 +/- df then in the frequency range (f0, f0 +/- 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.

  7001   Mon Jul 23 07:39:55 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:
Note: The Conlog install instructions that I started from were located here:
https://awiki.ligo-wa.caltech.edu/aLIGO/Conlog
  7002   Mon Jul 23 13:30:06 2012 JenneUpdateGreen LockingYarm ALS laser is funny / dying

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 :( 

  7003   Mon Jul 23 17:39:34 2012 JenneUpdateIOOMC_F vs. MC_L

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

 

Attachment 1: MCF_vs_MCL_23July2012.pdf
MCF_vs_MCL_23July2012.pdf
  7004   Mon Jul 23 18:01:30 2012 JenneUpdateGreen LockingYarm ALS laser is funny / dying

 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.

  7005   Mon Jul 23 18:16:13 2012 JamieUpdateSUSDQ block added to sus_single_control library parts

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.

  7006   Mon Jul 23 18:38:58 2012 JenneUpdatePSLPSL channels added to IOO model

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.

 

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

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

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

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

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

 

 

Attachment 1: alsend.png
alsend.png
  7008   Mon Jul 23 18:57:52 2012 JamieUpdateCDSc1scx and c1scy models recompiled and restarted

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

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

  7009   Mon Jul 23 19:00:26 2012 KojiUpdateGreen LockingALS_END.mdl model added for end station green ALS channels

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

Quote:

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

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

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

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

 

  7010   Mon Jul 23 19:13:12 2012 JenneUpdatePSLPSL channels added to IOO model

Quote:

I added a subblock to the IOO model, and gave it a top_names of PSL, so the channels show up as C1:PSL-......

So far, there are just 2 channels acquired, C1:PSL-FSS_MIXER and C1:PSL-FSS_FAST, since those were already connected to the ADC.  Those signals are both on the DAQ OUT of the FSS board in the rack.  They are DQ channels now too. 

 So there was a problem with the channel name C1:PSL-FSS_FAST, which conflicts with an existing slow channel.  This was causing daqd to fail to start (shockingly, with an appropriate error message!).  I renamed the channel to be C1:PSL-FSS_NPRO until we come up with something better.

After the change everthing worked and fb came back.

  7011   Mon Jul 23 19:50:43 2012 JamieUpdateCDSc1gcv model renamed to c1als

I decided to rename the c1gcv model to be c1als.  This is in an ongoing effort to rename all the ALS stuff as ALS, and get rid of the various GC{V,X,Y} named stuff.

Most of what was in the c1gcv model was already in a subsystem with and ALS top names, but there were a couple of channels that were outside of that that had funky names, namely the "GCV_GREEN" channels.  This fixes that, and make things more consistent and simple.

Of course this required a bunch of other little changes:

  • rename model in userapps svn
  • target/fb/master had to be modified to point to the new chans/daq/C1ALS.ini channel file and gds/param/tpchn_c1als.par testpoint file
  • rename RFM channels appropriately, and fix in receiver models (c1scx, c1scy, c1mcs)
  • move custom medm screens in userapps svn (isc/c1/medm/c1als), and link to it at medm/c1als/master
  • moved old medm/c1gcv directory into a subdirectory of medm/c1als
  • update all medm screens that point to c1gcv stuff (mostly just ALS screens)

The above has been done.  Still todo:

  • FIX SCRIPTS!  There are almost certainly scripts that point to GC{V,X,Y} channels.  Those will have to be fixed as we come across them.
  • Fix the c1sc{x,y}/master/C1SC{X,Y}_GC{X,Y}_SLOW.adl screens.  I need to figure out a more consistent place for those screens.
  • Fix the C1ALS_COMPACT screen
  • ???

 

  7012   Mon Jul 23 20:19:01 2012 LizUpdateComputer Scripts / ProgramsInput Needed (From everyone!)

The summary pages are now online (Daily Summary), and will eventually be found on the 40m Wiki page under "LOGS-Daily Summary". (Currently, the linked website is the former summary page site)

Currently, all of the IFO and Acoustic channels have placeholders (they are not showing the real data yet) and the Weather channels are not working, although the Weather Station in the interferometer room is working (I am looking into this - any theories as to why this is would be appreciated!!).

I am looking for advice on what else to include in these pages.  It would be fantastic if everyone could take a moment to look over what I have so far (especially the completed page from July 23, 2012) and give me their opinions on:

 

1.  What else you would like to see included

2.  Any specific applications to your area of work that I have overlooked

3.  What the most helpful parts of the pages are

4.  Any ways that I could make the existing pages more helpful

5.  Any other questions, comments, clarifications or suggestions

Finally, are the hourly subplots actually helpful?  It seems to me like they would be superfluous if the whole page were updating every 1-2 hours (as it theoretically eventually will).  These subplots can be seen on the July 24, 2012 page.

My email address is endavison@umail.ucsb.edu.

 Thank you!  

 

  7013   Mon Jul 23 20:34:38 2012 JamieOmnistructureComputersCHECK IN YOUR CHANGES TO THE SVN

I'm seeing LOTS OF STUFF NOT CHECKED INTO THE SVN!!!  both modified things that haven't been updated, and things that looked like they haven't been checked in at all.

Please check in your stuff to the SVN!  We need the record!

Look through EVERYTHING that you think you might have touched, or even care about, and make sure it's checked in.

  7014   Mon Jul 23 21:17:58 2012 LizUpdatePEMWeather Station Works!

Rana and I traced the cables that ran from c1pem1 to the Weather Station monitor.  We found that the flat blue cable that is plugged into c1pem1 was not connected to the black cable from the Weather Station.  We don't know why they are unplugged, but the Weather Station had been inactive since 2010.  Rana plugged them back in (they are now connected via a sketchy connector that had its pins askew) and now the channels are outputting correct data!  Everything else seems to be in good order and now I can use the data from the Weather Station for the summary pages!

  7015   Mon Jul 23 21:54:48 2012 ranaUpdatePEMWeather Station Works!

To get the code to run on c1pem1, we had to move the old target back into the /cvs/cds/caltech/target/ directory.  It is in /cvs/cds/caltech/target/c1pem1/.

JoeB had apparently moved it into some other area called 'oldfe' and this was why the weather station has not been running for years.    Joe is at LLO now, but he's not beyond our reach...

Once the code had been moved back I started it up. I also rebooted it from the telnet prompt to ensure that it worked on reboot. It did.

The cable issue that Liz mentions probably happened during the PSL table lifting and cable cleanup. It looks like someone yanked the ethernet cable out of its adapter and broke it...

Attachment 1: Untitled.png
Untitled.png
  7016   Tue Jul 24 02:12:14 2012 MashaUpdatePEMBLRMS, MEDM, Triangulation

Today I worked with the BLRMS channels, re-triangulated the seismometers (the STS is now on the very end of the Y-arm, while the GUR2 is on the X-arm - this GUR2 cable will need to be either extended or replaced - Jenne and I will look at parts tomorrow), and added 0.01 - 0.03 Hz and 0.03 - 0.1 Hz RMS channels (However, the MEDM files for these are not yet complete - I will finish these tomorrow) in order to be able to better see earthquakes. I also did some things for the neural network project, including beginning Simulink tutorials so that I can run my code by applying a force on a damped harmonic oscillator + white noise until it stops.

I will explain the methodology behind the new RMS filters tomorrow morning, when the seismometers have settled down and I can make coherence plots.

I'll post a better E-log tomorrow when it's not 2 in the morning.

  7017   Tue Jul 24 03:14:13 2012 JenneUpdateASSCalibration of MC ASS lockins

I wanted to check that the calibration of the MC ASS lockins was sensible, before trusting them forevermore.

To measure the calibration, I took a 30sec average of C1:IOO-MC_ASS_LOCKIN(1-6)_I_OUT with no misalignment. 

Then step MC1 pitch by 10% (add 0.1 to the coil output gains).  Remeasure the lockin outputs.

2.63 / (Lockin1noStep - Lockin1withStep) = calibration.

Repeat, with Lockin2 = MC2 pit, lockin3 = MC3 pit, and lockins 4-6 are MC1-3 yaw.

 

The number 2.63 comes from: half the side of the square between all 4 magnets.  Since our offsets are in pitch and yaw, we want the distance between the line connecting the lower magnets and the center line of the optic, and similar for yaw.  Presumably if all of the magnets are in the correct place, this number is the same for all magnets.  The optics are 3 inches in diameter.  I assume that the center of each magnet is 0.9mm from the edge of the optic, since the magnets and dumbbells are 1.9mm in diameter. Actually, I should probably assume that they're farther than that from the edge of the optic, since the edge of the dumbbell ~touches the edge of the flat surface, but there's the bevel which is ~1mm wide, looking normal to the surface of the optic.  Anyhow, what I haven't done yet (planned for tomorrow...) is to figure out how well we need to know all of these numbers.

We shouldn't care more than ~100um, since the spots on the optics move by about that much anyway.

For now, I get the following #'s for the calibration:

Lockin1 = 7.83

Lockin2 = 9.29

Lockin3 = 8.06

Lockin4 = 8.21

Lockin5 = 10.15

Lockin6 = 6.39

The old values were:

C1:IOO-MC_ASS_LOCKIN1_SIG_GAIN = 7
C1:IOO-MC_ASS_LOCKIN2_SIG_GAIN = 9.6
C1:IOO-MC_ASS_LOCKIN3_SIG_GAIN = 8.3
C1:IOO-MC_ASS_LOCKIN4_SIG_GAIN = 7.8
C1:IOO-MC_ASS_LOCKIN5_SIG_GAIN = 9.5
C1:IOO-MC_ASS_LOCKIN6_SIG_GAIN = 8.5

The new values measured tonight are pretty far from the old values, so perhaps it is in fact useful to re-calibrate the lockins every time we try to measure the spot positions?

  7018   Tue Jul 24 12:06:41 2012 MashaUpdatePEMNew RMS channels, New C1PEM Overview

As Jenne suggested last night, I changed the C1PEM overview in Epics. Previously, the C1PEM_OVERVIEW.adl screen had two separate visualizations, one for LP and one for BP for each channel. I changed the format so that there is only one frame per RMS channel, showing all of the input and output as before, but continuously, to demonstrate the actual RMS process.

First, the input is bandpass filtered, then multiplied by itself (squared), then lowpass filtered, and then square rooted to yield the final output. I have kept the previous files, but have applied this new format to all of the RMS ACC*, GUR1, GUR2, and STS1 channels. 

As Rana suggested yesterday, I made channels for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, and created filters for them, which I will work on some more now.

Attachment 1: NewRMSFrames.png
NewRMSFrames.png
  7019   Tue Jul 24 15:17:10 2012 MashaUpdatePEMRMS Filters, PEM Sitemap

RMS Filters

How Den, Rana, and I chose RMS filters:

- Because filter ring-down generates negative outputs, which then show up as NaN when the log is taken in StripTool, we decided to only use low-pass filters with real poles (using ZPK in Foton).

- The band-pass filters were chosen by looking at the dB drop from the cutoff frequencies to the next (usually aiming for 40 dB, or 99%), and checking that the BP_IN and BP_OUT had a coherence of 1 in the pass-band.

- The low-pass filters were chosen by finding the lowest filter order at which there was coherence of ~1 in the passband between the input signal to the filter and the filter output. The cutoff frequencies were chosen to be lower than the first passband frequency, in order to get rid of the cos(2*\omega*t)/2 terms that arise during the squaring of a signal of the form Asin(\omega*t) and to assure that only terms related to A^2/2 were kept. A plot of the 3-10 region is attached - in the Coherence plot, the coherence in ~1 in the 3 to 10 hZ region. Likewise,

PEM Sitemap

My previous post had digital zeros in two of the BLRMS channels. Jenne figured out that this was because the file Csqrt.c, which performs the square root operation in the root-mean square processing only accepted 5 inputs. I modified and committed the code so that it now accepts 7 inputs (for our 7 frequency bands) and returns 7 outputs. The new PEM sitemap seems to currently work.

StripTool

I have modified the StripTool file in order to show our new 0.01 Hz - 0.03 Hz and 0.03 Hz - 0.1 Hz channels.

Attachment 1: GUR1Z0p3to1FilterCoherence.png
GUR1Z0p3to1FilterCoherence.png
Attachment 2: GUR1Z3to10FilterCoherence.png
GUR1Z3to10FilterCoherence.png
Attachment 3: GUR1Z3to10FilterSignal.png
GUR1Z3to10FilterSignal.png
  7020   Tue Jul 24 18:33:12 2012 YaakovUpdateVIDEOCentering the MCR camera

Jenne and I centered the MCR camera on the AP table.

We moved the camera as far as it could go on its mount without shifting its screws, and adjusted the optic that the camera looks at for the rest of the way.

  7021   Tue Jul 24 21:16:55 2012 DenUpdatedigital noisequantization test

I'm trying to get some intuition how digital noise due to quantization shows up in iir filters. I decided to do tests in C using Python to calculate psd and visualize. I've implemented Direct Form 1, 2, "Biquad" and "Low Noise" forms of realization of second-order iir filter from Matt's presentation. There is a typo in the "Low Noise Form" scheme - a1 and a2 gains should be switched. Other then that schemes correctly implement 2 order iir. 

The input signal to each filter was a sine wave plus white noise with small amplitude x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ),  g << 1, f=1kHz. Sampling frequency was 16384 Hz. All 4 forms implemented 2 order low-pass butterworth filter with cut-off frequency 0.2 Hz

iir_2.png iir_8.png

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.

  7022   Wed Jul 25 10:31:33 2012 SashaSummarySimulationsSURF - Week 5 - Summary

This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again).

This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite).

The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300).

In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously.

Attachment 1: Screen_Shot_2012-07-24_at_10.46.05_AM.png
Screen_Shot_2012-07-24_at_10.46.05_AM.png
Attachment 2: Screen_Shot_2012-07-24_at_10.45.43_AM.png
Screen_Shot_2012-07-24_at_10.45.43_AM.png
Attachment 3: Screen_Shot_2012-07-25_at_10.16.58_AM.png
Screen_Shot_2012-07-25_at_10.16.58_AM.png
Attachment 4: Screen_Shot_2012-07-25_at_10.25.27_AM.png
Screen_Shot_2012-07-25_at_10.25.27_AM.png
  7023   Wed Jul 25 11:22:39 2012 LizUpdateComputer Scripts / ProgramsWeek 6 update

This week, I made several modifications to the Summary page scripts, made preliminary Microphone BLRMS channels and, with Rana's help, got the Weather Station working again. 

I changed the spectrogram and spectrum options in the Summary Pages so that, given the sampling frequency (which is gathered by the program), the NFFT and overlap are calculated internally.  This is an improvement over user-entered values because it saves the time of having to know the sampling frequency for each desired plot.  In addition, I set up another .sh file that can generate summary pages for any given day.  Although this will probably not be useful in the final site, it is quite helpful now because I can go back and populate the pages.  The current summary pages file is called "c1_summary_page.sh" and the one that is set up to get a specific day is called "liz_c1_summary_page.sh".  I also made a few adjustments to the .css file for the webpage so that plots completely show up (they were getting cut off on the edges before) and are easier to see.  I also figured out that the minute and second trend options weren't working because the channel names have to be modified to CHANNEL.mean, CHANNEL.min and CHANNEL.max.  So that is all in working order now, although I'm not sure if I should just use the mean trends or look at all of them (the plots could get crowded if I choose to do this).  Another modification I made to the python summary page script was adding an option to have an image on one of the pages.  This was useful because I can now put requested MEDM screens up on the site.  The image option can be accessed if, in the configuration file, you use "image-" instead of "data-" for the first word of the section header.

I also added a link to the final summary page website on the 40 meter wiki page (my summary page are currently located in the summary-test pages, but they will be moved over once they are more finalized).  I fleshed out the graphs on the summary pages as well, and have useful plots for the OSEM and OPLEV channels.  Instead of using the STS BLRMS channels, I have decided to use the GUR BLRMS channels that Masha made.  I ELOGged about my progress and asked for any advice or recommendations a few days ago (7012) and it would still be great if everyone could take a look at what I currently have up on the website and tell me what they think!  July 22 and 23 are the most finalized pages thus far, so are probably the best to look at.

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

 

This week, I also tried to fix the problems with the Weather Station, which had not been operational since 2010.  All of the channels on the weather station monitor seemed to be producing accurate data except the rain gauge, so I went on the roof of the Machine Shop to see if anything was blatantly wrong with it.  Other than a lot of dust and spiders, it was in working condition.  I plan on going up again to clean it because, in the manual, it is recommended that the rain collector be cleaned every one to two years...  I also cleared the "daily rain" option on the monitor and set all rain-related things to zero.  Rana and I then traced the cabled from c1pem1 to the weather station monitor, and found that thy were disconnected.  In fact, the connector was broken apart and the pins were bent.  After we reconnected them, the weather station was once again operational!  In order to prevent accidental disconnection in the future, it may be wise to secure this connection with cable ties.  It went out of order again briefly on Tuesday, but I reconnected it and now it is in much sturdier shape!

 

The most recent thing that I have been doing in relation to my project has been making BLRMS channels for the MIC channels.  With Jenne's assistance, I made the channels, compiled and ran the model on c1sus, made filters, and included the channels on the PEM MEDM screen .  I have a few modifications to make and want to .  One issue that I have come across is that the sampling rate for the PEM system is 2 kHz, and the audio frequencies range all the way up to 20 kHz.  Because of this, I am only taking BLRMS data in the 1-1000 Hz range.  This may be problematic because some of these channels may only show noise (For example, 1-3 and 3-10 Hz may be completely useless).

 

The pictures below are of the main connections in the Weather Station.  This first is the one that Rana and I connected (it is now better connected and looks like a small beige box), located near the beam-splitter chamber, and the second is the c1pem1 rack.  For more information on the subject, there is a convenient wiki page: https://wiki-40m.ligo.caltech.edu/Weather_Station

Attachment 1: P7230026.JPG
P7230026.JPG
Attachment 2: P7230031.JPG
P7230031.JPG
  7024   Wed Jul 25 11:25:27 2012 MashaUpdateGeneralSummary

This week, I have been mainly working on my new neural network project, and working with the BLRMS channels.

New Neural Network Project:

Rana and I read a paper which demonstrated the use of a neural network to control an inverted pendulum. Since the test masses are, in simplest terms coupled harmonic oscillators with six degrees of freedom, we suspect something similar can be done. The logic behind trying to use a neural network as a control system lies in the fact that the actual motion of the test masses is a complicated function of many variables (including environment variables, such as temperature and seismic disturbance as well), and neural networks, at the core, are function approximators, which can approximate a function as a combination of polynomials (with error 0 in a closed interval) or of sigmoidal functions (which, in the papers I've read, seems to be possible in practice - the authors also reference some theoretical results regarding this). Thus, this network could, in theory take the displacement in the degrees of freedom of the OSEMS and generate the actuation force.

However, there was the question of building a neural network which explicitly took the history of a time series into account, and not only implicitly in the neuron weights. Thus, I found recurrent neural networks, which, for some T (this will ultimately be related to the sampling frequency, or spectrum of the signal),  has T hidden sub-layers which pass in the output of the T previous iterations.

I have written Matlab code that generates, for a given T and neuron vector (the number of neurons in each of the T layers) a recurrent neural network (it still, like my old network, uses gradient descent and sigmoidal activation functions). However, I needed a system to run it on, so I began playing around with Simulink. I have never used this system before, so I took a bit of time doing the tutorials, but I currently have a damped, driven harmonic oscillator which accepts a force at each time step and outputs a displacement (taking into account the earlier forces). This afternoon, I think I will link it to my recurrent neural network, which can accept a displacement and output a force, and see what happens. These networks are notoriously slow to converge, but I could at least check to see that my code (and understanding of the algorithm) is correct. Should this work, I can also try hooking it up to Sasha's simulation, which is more complex than an oscillator with one degree of freedom.

As Far as Seismic Things Go:

I haven't worked with seismic noise itself very much this week, although the signals could be used as inputs to a neural network. I moved the STS1 and GUR1 cables, which I realized were crossed and thus stupidly placed (my fault) and now have STS1 on the very end of the Y arm (GUR1 is about 10 meters down the X arm, however, so Jenne and I will probably have to make a cable). I also found granite and foam, so at least the STS can be given a final position at the end of the arm.

BLRMS:

I added two new channels to the BRLMS, for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, so that we can better observe distant earthquakes. I also changed the MEDM screen for all of the ACC, GUR, and STS RMS channels (I think Liz is also using this for her MIC channels), combining the low pass and high pass filter screens into a screen demonstrating the complete RMS process, which squaring and square roots. I have also changed the RMS filters, and wrote an Elog about that process.

The paper Rana and I read is Charles W. Anderson, Learning to Control and Inverted Pendulum Using Neural Networks

A good paper of recurrent neural network basics is Mikael Boden, "A guide to recurrent neural networks and backpropagation"

 


 

 

  7025   Wed Jul 25 11:34:31 2012 EricSummarySimulationsSURF Update

I am continuing work on simulating the DARM control loop. There is now a block for the length response
function
that allows one to recover the h(t) GW input to the model. However, in order to add this
block I had to add some artificial poles to the length response function beacuse Simulink gave me errors
when the transfer function had more zeros than poles. The artificial poles are at 10^6 Hz and higher, so
that they should not affect the response function at the lower frequencies of interest. This approach
appears a bit computationally unstable though because without changing any parameters and re-running
the simulation, a different magnitude for h(t) would be calculated sometimes. A different method may be
necessary to get this working more accurately
.

By looking through the C1LSC Simulink model and the C1LSC control screens, Jenne helped me determine
which digital filters are active while the interferometer is locked
. To do this, open the C1LSC control
screen, then open the trigger matrix. Inside the trigger matrix window there is a button titled Filter
Module Triggers which opens another window that indicates which filters are triggered for a given channel,
and what values trigger them. For the y arm servo filters FM2, 3, 6, 7, 8 are triggered while in lock and
FM4 and 5 are controlled manually; I am including all of these in the model now. 

I have changed the way I manipulate the output from the model for analysis, using Rana's advice. I also
improved the plotting code, now using a custom Bode plot instead.

Attached is a screenshot of the Simulink model as it currently stands, and an older implementation of the
open loop gain
. I am in the process of updating the servo filters now, and what is shown in the plot does
not include all the filter modules for the servo filter.

 

 

Attachment 1: DARM_control_loop_hendries.PNG
DARM_control_loop_hendries.PNG
Attachment 2: OLG_old_hendries2.png
OLG_old_hendries2.png
  7026   Wed Jul 25 11:41:00 2012 YaakovUpdateVIDEOCentering the MCR camera

Quote:

Jenne and I centered the MCR camera on the AP table.

We moved the camera as far as it could go on its mount without shifting its screws, and adjusted the optic that the camera looks at for the rest of the way.

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

  7027   Wed Jul 25 12:00:21 2012 YaakovUpdateSTACISWeekly update

The past few days I've been working on making a noise budget for the STACIS that incorporates all the different noises that might be contributing.

The noises I am concentrating on are accelerometer noise, geophone noise, electrical noise, and ground noise. Noise from the PZT stacks themselves should be tiny according to various PZT spec sheets, but I haven't actually found a value for it (they all just say it's negligible), so I'll keep it in mind as a potential contributor.

Here's how I am determining accelerometer noise: I take two vertical accelerometers side by side, sitting on a granite block and covered in a foam box, and take the time series of both. Then I take the difference of the time series and calculate the PSD of that, which with the calibration factor of the accelerometers (the V/m/s sensitivity) I am able to find the noise in m/s/rtHz. The noise agreed with the accelerometer specs I found at low frequencies but was higher than expected at high frequencies, so I'm still investigating. If I can't find an obvious problem with my measurements I'll try the three-corner hat method (as per Jenne's recommendation), which would allow me to determine the noises of the independent accelereometers.

I tried a similar method for the geophone noise, but the value I came up with was actually higher than the accelerometer noise, which seems very fishy. I realized that the geophones were still connected to the STACIS circuitry when I took the measurements ,which was probably part of the problem. So this morning I disconnected the STACIS entirely and am looking at just the geophone signals which should give a more accurate noise estimate.

Once I have all the noises characterized, the next step is seeing how those noises affect the closed loop performance of the STACIS. I've been working on a block model that incorporates the different noises and transfer functions involved, and when I have the noises characterized I can test a prediction about how a certain noise affects the platform motion.

 

  7028   Wed Jul 25 14:35:45 2012 SashaSummarySimulationsSURF - Week 5 - Summary

Quote:

This week I've been working on refining my simulation and getting it ready to be plugged into the control system. In particular, I've added a first attempt at a PDH control system, matrix conversion from OSEMs to DOF and back, and all necessary DAC/ADC/AA/AI/whitening/dewhitening filters. Most of these work well, but the whitening filters have been giving me trouble. At one point, they were amplifying the signal instead of flatting it out, such that my simulation started outputting NaN (again).

This was wholeheartedly depressing, but switching out the whitening filters for flat ones seemed to make the problem go away, but brought another problem to light. The output to input ratio is minuscule (as in 10^-300/10^243, see Attachment 3 for the resulting bode plot between a force on the suspension pt in the x-direction and my two outputs - error signal and length signal, which is pretty much what you would expect it to be). I suspect that its related to the whitening filter problem (perhaps the dewhitening filter is flattening the signal instead of amplifying?). If that is the case, then switching the whitening/dewhitening filters ought to work. I'll try today and see what happens. The white/dewhite filters together result in a total gain of 1, which is a good fundamental test, but could mean absolutely nothing (i.e. they could both be wrong!). Judging from the fact that we want to flatten out low frequency signal when it goes through the whitening filter, the filters don't look switched (see Attachment 4 for a bode plot of white and dewhite).

The only other source of problems (given that the suspensions/local damping have been debugged extensively throughout this process - though they could bug out in conjunction with the cavity controls?) is the PDH system. However, separating each of the components showed that the error signal generated is not absurd (I haven't tested whether it makes sense or not, but at any rate it doesn't result in an output on the order of 10^-300).

In summary, I've made progress this week, but there is still far to go. Attachment 1 is my simulation from last week, Attachment 2 is my simulation from this week. A talk with Jamie about the "big picture" behind my project helped tremendously.

 Here's a screenshot of what's going on inside the cavity (Attachment 1). The PDH/mixer system outputs 0 for pretty much everything except really high numbers, which is the problem I'm trying to solve now. I assumed that the sidebands were anti-resonant, calculated reflection coefficient F(dL) = Z * 4pi * i/(lambda), where Z = (-r_1 + r_2*(r_1^2 + t_1^2)/(1 - r_1*r_3)), then calculated P_ref = 2*P_s - 4sqrt(P_c*P_s) * Im(F(dL)) * sin(12.5 MHz * t) (this is pictured in Attachment 2), then mixed it with a sin(12.5MHz * t) and low-passed it to get rid of everything but the DC term (this is pictured in Attachment 3), which is the term that then gets whitened/anti-aliased/passed through the loop.

 

Attachment 1: Screen_Shot_2012-07-25_at_2.20.01_PM.png
Screen_Shot_2012-07-25_at_2.20.01_PM.png
Attachment 2: Screen_Shot_2012-07-25_at_2.20.15_PM.png
Screen_Shot_2012-07-25_at_2.20.15_PM.png
Attachment 3: Screen_Shot_2012-07-25_at_2.20.29_PM.png
Screen_Shot_2012-07-25_at_2.20.29_PM.png
Attachment 4: Screen_Shot_2012-07-25_at_2.23.05_PM.png
Screen_Shot_2012-07-25_at_2.23.05_PM.png
  7029   Wed Jul 25 15:33:55 2012 janoschUpdateLSCringdown measurement

We did our first ringdown measurement on the Y arm. First we tried to keep the arm locked in green during the ringdown, but for some reason it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only.

For the measurement we had to change the LSC model to acquire the C1:LSC-TRY_OUT_DQ at higher sampling frequency. We changed the sampling frequencies of C1:LSC-{TRX,TRY}_OUT_DQ from 2048Hz to 16384Hz.

The measurement was done at GPS 1027289507. The ringdown curve looks very clean, but there seem to be two time constants involved. The first half of the curve is influenced by the shutter speed, then curvature is changing sign and the ringdown is likely taking over. We will try to fit a curve to the ringdown part, but it would certainly be better to have a faster shutter and record a more complete ringdown.

Rindown1.png

 

  7030   Wed Jul 25 16:31:01 2012 JenneUpdateLSCYarm green locking to arm - PDH box saturating

Quote:

... it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only. 

 When we sat down to align the Yarm to the green, the green light was happy to flash in the cavity, but wouldn't lock, even after Jan had tweaked the mirrors such that we were flashing the TEM00 mode.  When we went down to the end to investigate, the Universal PDH box was saturating both negative and positive.  Turning down the gain knob all the way to zero didn't change anything, so I put it back to 52.5.  Curiously, when we unplugged the Servo OUT monitor cable (which was presumably going to the rack to be acquired), the saturation happened much less frequently.  I think (but I need to look at the PDH box schematic) that that's just a monitor, so I don't know why that had to do with anything, but it was repeatable - plug cable in, almost constant saturation....unplug cable, almost no saturation.

Also, even with the cable unplugged, the light wouldn't flash in the cavity.  When I blocked the beam going to the green REFL PD (used for the PDH signal), the light would flash.

Moral of the story - I'm confused.  I'm going to look up the PDH box schematic before going back down there to investigate.

  7031   Wed Jul 25 16:55:01 2012 DenUpdatedigital noisenotch, lowpass filters

 Direct Form 2 is noisy in the first test. This is the one similar to Matt's in his presentation. Input signal was a sine wave at 1 Hz with small amplitude white noise x[n] = sin(2*pi*1*t[n]) + 1e-10 * random( [-1, 1] ). It was filtered with a notch filter: f=1Hz, Q=100, depth=210dB. SOS representation was calculated in Foton. Sampling frequency is 16kHz.

iir_psd.png        iir_time.png   iir_coh.png

DF2 output noise level is the same if I change white noise amplitude while DF1, BQF, LNF can follow it. Time series show quantization noise of DF2. I've plotted coherence of the signals relative to DF1, because non of the signals will be coherent to it at low frequencies due to fft calculations.  

In the second test the input was white noise  x[n] = random( [-1, 1] ) It was filtered with a 2 order low-pass butterworth filter with cut-off frequency f = 0.25 Hz. SOS representation was calculated in Python. Sampling frequency is 16kHz.

iir_psd_lowpass.png         iir_time_lowpass.png      iir_coh_lowpass2.png

In this test all implementations work fine. I guess dtt works with single precision and for that reason we see disturbance in coherence when we do the same test online.

  7032   Wed Jul 25 17:35:44 2012 LizUpdateComputer Scripts / ProgramsSummary Pages are in the right place!

The summary pages can now be accessed from the "Daily Summary" link under LOGS on the 40 meter Wiki page.

  7033   Wed Jul 25 22:16:36 2012 KojiUpdateLSCringdown measurement

Is this the step response of the single pole low pass???
It should have an exponential decay, shouldn't it? So it should be easier to comprehend the result with a log scale for vertical axis...

I think you need a fast shutter. It is not necessary to be an actual shutter but you can use faster thing
which can shut the light. Like PMC or IMC actuators.

Another point is that you may like to have a witness channel like the MC transmission to subtract other effect.

  7034   Wed Jul 25 23:03:22 2012 ranaUpdatedigital noisenotch, lowpass filters

If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed?

And how about checking for filter noise in the situation we saw online? 4th order low pass at 1 Hz or 8 Hz.

  7035   Thu Jul 26 02:44:17 2012 JenneUpdateIOOCentering the MCR camera

[Yaakov, Jenne]

The short version:

Rana and Koji pointed out to us that the MCR camera view was still not good.  There were 2 problems:

(1) Diagonal stripes through the beam spot.  Yuta and I saw this a week or 2 before he left, but we were bad and didn't elog it, and didn't investigate.  Bad grad students.

(2) Clipping of the left side of the beam (as seen on the monitors).  This wasn't noticed until Yaakov's earlier camera work, since the clipped part of the beam wasn't on the monitor.

The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum. 

The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again.

We moved the 10% BS that splits the main beam into the (MC REFL PD) path and the (MCR camera + WFS) path.  It looked like the transmission through there was close to the edge of the BS.  We didn't think that this was causing the clipping that we saw on the camera (since when we stepped MC1 in Yaw, the beam spot had to move a lot before we saw any clipping), but it seemed like a good idea to make the beam not near the edge of the optic, especially since, being a 2" optic, there was plenty of room, and we were only using ~half of the optic.  We didn't touch anything else in the WFS path, since that looks at the transmission through this BS, but we had to realign the beam onto MC REFL.

The long version:

(1)  The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum.  It looks like that's why the iris was there in the first place.  When we found it this evening, the iris was totally open, so my current theory is that someone was on the AP table doing something, and accidentally bumped the handle for the iris, then left it completely open when they realized that they had touched it.  I think Steve had been doing something on the AP table around then, but since Yuta and I didn't elog our observation (bad grad students!), I can't correlate it with any of Steve's elogs. We were not able to find exactly where this "glow" that the iris is used to obscure comes from, but we traced it as far as the viewport, so there's something going on inside.

(2)  The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again. 

We spent a long time trying to figure out what was going on here.  Eventually, we moved the camera around to different places (i.e. right before the MC REFL PD, with some ND filters, and then we used a window to pick off a piece of the beam right as it comes out of the vacuum before going through the iris, put some ND filters, then the camera).  We thought that right before the MC REFL PD was also being clipped, indicating that the clipping was happening in the vacuum (since the only common things between the MC REFL PD path and the camera path are the iris, which we had removed completely, and a 2" 10% beam splitter.  However, when we looked at a pickoff of the main beam before any beamsplitters, we didn't see any evidence of clipping.  I think that when we had the camera by MC REFL, we could have been clipping on the ND filters that I had placed there.  I didn't think to check that at the time, and it was kind of a pain to mush the camera into the space, so we didn't repeat that.  Then we went back to the nominal MCR camera place to look around.  We discovered that the Y1 which splits the camera path from the WFS path has a ghost beam which is clipping on the top right side (as you look at the face of the optic) of the optic, and this is the beam that was going to the camera (it's a Y1 since we only want a teensy bit of light to go to the camera, the rest goes to the WFS).  There is another beam which is the main beam, going through the center of the optic, which is the one which also reflects and heads to the WFS.  This is the beam which we should have on the camera.  Yaakov put the camera back in it's usual place, and put the correct beam onto the center of the camera.  We did a check to make sure that the main beam isn't clipping, and when I step MC1 yaw, the beam must move ~1.5mm before we start to see any clipping on the very edge of the beam.  To see / measure this, we removed the optic which directs the beam to the camera, and taped an IR card to the inside of the black box.  This is ~about the same distance as to the nominal camera position, which means that the beam would have to move by 1.5mm on the camera to see any clipping.  The MC REFL PD is even farther from MC1 than our IR card, so the beam has to fall off the PD before we see the clipping.  Thus, I'm not worried about any clipping for this main beam.  Moral of the story, if you made it this far:  There wasn't any clipping on any beams going to either the WFS or the MC REFL PD, only the beam going to the camera.

  7036   Thu Jul 26 10:22:03 2012 DenUpdatedigital noisenotch, lowpass filters

Quote:

If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed?

And how about checking for filter noise in the situation we saw online? 4th order low pass at 1 Hz or 8 Hz.

 This is because when we plot signals with sampling frequencies 2k and 16k with the same BW, we actually create psd/coherence using different numbers of points in FFT calculations as NFFT ~ fs/bw, fs-sampling frequency. So we secretly used 8 times more fft points for 16k signal then for 2k signal. Following plots demonstrate this effect. The first plot shows transfer function and coherence for filtering of 16k signal with butter('LowPass',4,8) and 2k signal with butter('LowPass',4,1)  when BW=0.1. There is a disturbance in coherence for 2k signal below 2 Hz. Now let's take BW=0.8 and plot transfer function and coherence for 16k signal. We can see the same effect of coherence disturbance.

same_bw.png    16384_bw0p8.png

The similar effect takes place when we change the cut-off frequency. The following plots show transfer function and coherence of two pairs of 2kHz signals. 4 order butterworth low-pass filter was used. For the first pair cut-off frequency was 1 Hz, for the second 10 Hz.  On the first plot BW=0.1 and there is a disturbance in coherence below 1 Hz. However on the second plot when BW=0.01, this effect is lost.

corners_bw0p1.png     corners_bw0p01.png

I guess my goal is to figure out when these effects come from fft calculations and when from digital filter noise.

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

Quote:

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

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

The same thing as we had several month ago

controls@c1iscey /opt/rtcds/caltech/c1/target/c1tst/c1tstepics 0$ cat iocC1.log

Starting iocInit
iocRun: All initialization complete
sh: iniChk.pl: command not found
Failed to load DAQ configuration file

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

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

Ringdown.png

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

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

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

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

stacy_noise.bmp

stacy_noise.fig

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

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

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

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

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

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

feedbacks.bmp

feedbacks.fig

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

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

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

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

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

df2_bqf.png    df2_bqf_spec.png

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

iir_time_notch.pngiir_psd_notch.png

 

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

Quote:

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

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

df2_bqf_lp.png    df2_bqf_lp_spec.png

  7043   Fri Jul 27 14:27:14 2012 JamieUpdateCDSnew c1tst model for testing RCG code

Quote:

 

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

The same thing as we had several month ago

controls@c1iscey /opt/rtcds/caltech/c1/target/c1tst/c1tstepics 0$ cat iocC1.log

Starting iocInit
iocRun: All initialization complete
sh: iniChk.pl: command not found
Failed to load DAQ configuration file

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

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

Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current.  We should replace them at the next vent. I'm buying 4 at $317ea

 

Attachment 1: cc_gauges.png
cc_gauges.png
  7045   Fri Jul 27 14:30:49 2012 JamieUpdatedigital noisebiquad key is working

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

  7046   Fri Jul 27 16:32:17 2012 JamieUpdateCDSRCG bug exposed by simple c1tst model

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

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

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

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

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

Things we tried, none of which worked:

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

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

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

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

Attachment 1: pmcA.png
pmcA.png
Attachment 2: pmcB.png
pmcB.png
ELOG V3.1.3-