40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 202 of 341 Not logged in
ID Date Author Type Category Subject
7019   Tue Jul 24 15:17:10 2012 MashaUpdatePEMRMS Filters, PEM Sitemap

RMS Filters

How Den, Rana, and I chose RMS filters:

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

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

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

PEM Sitemap

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

StripTool

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

Attachment 1: GUR1Z0p3to1FilterCoherence.png
Attachment 2: GUR1Z3to10FilterCoherence.png
Attachment 3: GUR1Z3to10FilterSignal.png
7018   Tue Jul 24 12:06:41 2012 MashaUpdatePEMNew RMS channels, New C1PEM Overview

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

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

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

Attachment 1: NewRMSFrames.png
7017   Tue Jul 24 03:14:13 2012 JenneUpdateASSCalibration of MC ASS lockins

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

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

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

2.63 / (Lockin1noStep - Lockin1withStep) = calibration.

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

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

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

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

Lockin1 = 7.83

Lockin2 = 9.29

Lockin3 = 8.06

Lockin4 = 8.21

Lockin5 = 10.15

Lockin6 = 6.39

The old values were:

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

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

7016   Tue Jul 24 02:12:14 2012 MashaUpdatePEMBLRMS, MEDM, Triangulation

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

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

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

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

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

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

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

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

Attachment 1: Untitled.png
7014   Mon Jul 23 21:17:58 2012 LizUpdatePEMWeather Station Works!

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

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

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

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

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

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

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

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

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

1.  What else you would like to see included

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

3.  What the most helpful parts of the pages are

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

5.  Any other questions, comments, clarifications or suggestions

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

Thank you!

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

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

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

Of course this required a bunch of other little changes:

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

The above has been done.  Still todo:

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

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

 Quote: I added a subblock to the IOO model, and gave it a top_names of PSL, so the channels show up as C1:PSL-...... So far, there are just 2 channels acquired, C1:PSL-FSS_MIXER and C1:PSL-FSS_FAST, since those were already connected to the ADC.  Those signals are both on the DAQ OUT of the FSS board in the rack.  They are DQ channels now too.

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

After the change everthing worked and fb came back.

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

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

 Quote: The end sus models (c1scx and c1scy) both contain some ALS stuff.  This stuff could maybe be moved to their own models, but whatever. The stuff at X and Y were identical, but were code copies (BAD!).  I made a new library part for the ALS end controls: ${userapps}/isc/c1/model/ALS_END.mdl It contains just some filter modules for the ALS end laser control, and a monitor of the ALS end REFL PD DC. I also added a DQ block for the recorded channels (see screen shot). When I added this new part to c1scx and c1scy I made it so the channel names would be more sensible. Instead of "GCX" and "GCY", they are now "ALS-X" and "ALS-Y". They will now all show up under the ALS subsystem. 7008 Mon Jul 23 18:57:52 2012 JamieUpdateCDSc1scx and c1scy models recompiled and restarted After the changes listed in 7005 and 7007, I have rebuilt, installed, and restarted the c1scx and c1scy models. Everything seems to have come back up ok. Running into some daqd troubles because of a change to c1ioo, but will report on the new ALS channels when I can. 7007 Mon Jul 23 18:41:15 2012 JamieUpdateGreen LockingALS_END.mdl model added for end station green ALS channels The end sus models (c1scx and c1scy) both contain some ALS stuff. This stuff could maybe be moved to their own models, but whatever. The stuff at X and Y were identical, but were code copies (BAD!). I made a new library part for the ALS end controls:${userapps}/isc/c1/model/ALS_END.mdl

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

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

Attachment 1: alsend.png
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.

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.

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.

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

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

+

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.

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.

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.

6997   Fri Jul 20 17:11:50 2012 JamieUpdateCDSAll custom MEDM screens moved to cds_users_apps svn repo

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.

6996   Fri Jul 20 14:18:15 2012 DenUpdatePEMMCL, GUR calibration

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.

6995   Fri Jul 20 12:12:25 2012 ranaUpdatePSLPMC problems examined

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.

Attachment 1: Untitled.png
6994   Fri Jul 20 11:59:27 2012 ranaUpdateComputer Scripts / ProgramsCONLOG not running

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.

6993   Thu Jul 19 15:55:21 2012 ranaUpdateComputersused 'aptitude' to install software (TexLive) on rosalba

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


6992   Thu Jul 19 02:32:45 2012 JenneUpdateIOOWFS don't come on automatically??

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.

6991   Thu Jul 19 02:14:37 2012 JenneUpdateVIDEOMade a video gui

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.

6990   Wed Jul 18 15:38:05 2012 EricSummarySimulationsSURF Update

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.

6989   Wed Jul 18 14:25:44 2012 JenneUpdateIOOMC spot position measurements

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.

6988   Wed Jul 18 13:53:34 2012 YaakovUpdateSTACISWeekly update

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.

6987   Wed Jul 18 11:05:40 2012 MashaUpdatePEMSTS Coherene

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

6986   Wed Jul 18 10:08:01 2012 LizUpdateComputer Scripts / ProgramsWeek 5 update/progress

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.

6985   Wed Jul 18 09:53:20 2012 SashaSummarySimulationsSURF - Week 4 - Summary

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.

Attachment 1: Screen_Shot_2012-07-18_at_9.50.26_AM.png
6984   Wed Jul 18 09:44:13 2012 MashaSummaryGeneralWeek Summary

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.

6983   Wed Jul 18 09:09:51 2012 MashaUpdatePEMStreckeisen

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.

Attachment 1: Screenshot.png
Attachment 2: Screenshot-1.png
6982   Wed Jul 18 00:36:22 2012 JenneUpdateIOOWFS oscillating

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.

Attachment 1: Yarm_oscillating_1Hz_while_WFS_crazy_full_17July2012.pdf
Attachment 2: Yarm_oscillating_1Hz_while_WFS_crazy_17July2012.pdf
6981   Tue Jul 17 18:00:58 2012 MashaUpdatePEMSTS

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.

Attachment 1: Screenshot.png
6980   Tue Jul 17 11:28:29 2012 JenneUpdateASSNames of DoF filters in ASS wrong

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.

6979   Tue Jul 17 02:17:50 2012 JenneUpdateASCASS gains wrong?
I was checking on the ASS system, and I think that the gains on some of the loops may not be correct. An old symptom was that the commands in the script were not being executed when we changed over to Ubuntu. Now it seems that each command is working fine, but the loops are pushing the optics more out of alignment than anything. I flipped the sign on some of the loops and it helped, others it didn't. I need to measure some transfer functions and meditate on what they should look like. It will be really nice to have the alignment system working again.
6978   Mon Jul 16 16:41:49 2012 JenneUpdatePSLPMC locked in funny place - PSL laser temp changed

The PMC was unlocked earlier this morning, for ~20min, presumably from the rocks next door.  I relocked it.

Then, a few min ago, the PMC suddenly decided that it wouldn't lock with a transmission greater than ~0.7 .  I found that the laser temp adjust on the FSS screen was at -1.9ish.  I put it back to zero, and now the PMC locks happily again.  I think we got into a PSL mode-hopping temperature region on accident.

6977   Mon Jul 16 11:50:56 2012 MashaUpdatePEMSTS-1

It seems that the STS-1 ADC channels had the same mismatch issue as the GUR-2 channels. The PEM_MONITOR has STS_1 listed as channels 6, 7, 8 (+1 on the actual ADC) whereas it was plugged into channels 13, 14, 15 (+1 on the actual ADC as well) with nothing in channels 6, 7, 8. Thus, I moved the cables and reset STS_1. The readout, however, is still only a magnitude of ~10 counts (I checked, however, that this is indeed the readout when the seismometer is plugged in vs. when it is unplugged), but hopefully it will stabilize during the day, as did GUR 2.

6976   Sun Jul 15 16:25:15 2012 ranaUpdateLSCPRMI LSC is making PRM motion worse

As stephanie did a few years ago, the idea should be to match the damping between the DRMI optics so as to minimize the differential motion. No notching is necessary. Read her SURF report about the IMC.

6975   Fri Jul 13 19:48:56 2012 JenneUpdateEnvironmentRocks - very loud

I assume it's the rock tumbler, although it could be something else, but the MC has had trouble staying locked yesterday and today (yesterday Yaakov and I went over there and they were doing stuff almost constantly - it's super loud over there), and today even the PMC has fallen out of lock twice.  I just relocked it again, since it went out of lock just after Journal club started.

Anyhow, I think this will be good data for Masha, and then also for the Masha+Yaakov triangulation project.

6974   Fri Jul 13 15:49:38 2012 yutaBureaucracyGeneral40m Priority Action Items

These are all priority action items need to be done before I come back (in mid-September).
BE PREPARED FOR THE FULL LOCK!

NEXT VENT:
- Prepare and install tip-tilts -JAMIE
- Adjust IP-ANG -JAMIE, JENNE, KOJI
- Make sure there's no clipping. Start from MC centering -JAMIE, JENNE, KOJI

ASS/A2L:
- Make ASS and A2L work -JENNE, JAMIE
- Better MC spot position measurement script(see the last sentence in elog #6892) -JENNE
- Daily beam spot measurements for IFO, just like MC -JENNE
- ASS for green using PZT steering mirrors on end table -JENNE
- Modeling of phase tracking ALS -JAMIE

ALS:
- PZT mounts for PSL and ALS beams -JENNE, KOJI
- Add temperature sensors for end lasers to CDS slow channels -JENNE
- Put green trans camera, GTRY PD, and GTRX PD on PSL table -JENNE
- Better beat box; include comparators, frequency dividers, and whitening filters -JAMIE, KOJI
- Adjust servo gain/filters of end green PDH lock (reduce frequency noise) -JENNE
- Add on/off switch, gain adjuster, etc to CDS for end green PDH lock -JENNE, JAMIE

PRC:
- Find why and reduce 3 Hz motion -JENNE
- Simulation of PRMI with clipping -YUTA
- Alignment tolerance of PRMI -YUTA

6973   Fri Jul 13 13:02:52 2012 Masha, YaakovUpdatePEMGUR2 Fixed

Yaakov and I investigated the GUR 2 problem. It turns out that the ADC channels that GUR 2 was plugged into, ADC channels 6 through 8 (on the actual ADC they are C7 through C9), did not correspond to the channels labelled "GUR 2" in the PEM, ADC channels 3 through 5. We modified them so that GUR 2 is now plugged into ADC channels 3 through 5 (on the ADC it's +1).

Before we discovered that this was the problem, we attempted to take the cover off of GUR 1 to check the gains, and discovered a stripped Allen screw on the side by the "Vertical" pot, which we removed.

Now the GUR 2 readout looks good, and we will give it more time to settle down before we take data.

6972   Thu Jul 12 23:15:34 2012 yutaUpdateLSCPRMI LSC is making PRM motion worse

It looks like PRMI LSC is making PRM motion (and BS motion) at ~3Hz worse.
I concluded this from measuring feedback signal of suspension servo and LSC servo.

Mechanism:
1. BS and PRM moves alot at ~3 Hz.
2. LSC senses fake signal at ~3Hz from beam spot motion on PD
3. LSC feedback this motion to position of PRM
4. Suspension damping servo try to cancel this because ~3 Hz motion is not actual length signal

Calculation:
x:   Orignal longitudinal motion of PRM
n_L: Sensing noise in LSC (including ITM motion, fake ~3Hz motion)
n_S: Sensing noise in suspension damping (OSEM sesor noise, fake ~3Hz motion)
G_L: Openloop transfer function of PRCL LSC
G_S: Openloop transfer function of suspension damping (PRM SUSPOS)
H:   LSC sensor transferfunction (PDH signal on REFL_33_I)
F_S: Filter for suspension damping
A:   Actuator transfer function (PRM OSEM coils)

Since G_L >> G_S and G_L >> 1 for below 100Hz (see elogs #6950 and #6967), feedback signal of LSC and suspensiton damping can be written as

f_L = x - A*F_S*n_S - (1+G_S)/H*n_L
f_S = 1/G_L*x - A*F_S*n_S - G_S/H*n_L

So, basically, LSC supresses PRM motion but puts n_L to PRM. Suspension servo try to surpress n_L, which was not there when LSC is off.

Measurement:
1. Below left is uncalibrated spectra of

Red:  suspension damping feedback to PRM/BS when PRMI is locked
Blue: LSC feeed back to PRM/BS when PRMI is locked
Pink: suspension damping feedback to PRM/BS when PRMI is not locked

As you can see, PRM suspension damping feed back increases at ~ 1.5-3 Hz because of LSC. This is the same for BS at ~1 Hz and ~3 Hz.

2. Above right is same spectra for ITMX/ITMY. There's no change in suspension damping feedback. This means, radiation pressure coupling or something is not related in this issue. LSC servo is not engaged for ITMs.

3. Below is oplev spectra for PRM/BS

Red:  Oplev pitch error signal of PRM/BS when PRMI is locked
Blue: Oplev yaw error signal of PRM/BS to PRM/BS when PRMI is locked
Pink:  Oplev pitch error signal of PRM/BS when PRMI is not locked
Cyan: Oplev yaw error signal of PRM/BS to PRM/BS when PRMI is not locked

You can see the increase in pitch/yaw motion at ~ 1.5-3 Hz for PRM, and ~1Hz/~3Hz for BS. They are consistent with measurement of feedback spectra.

By the way:

I adjusted oplev servo gains for ITMX. They were crazy this evening. They now have UGF ~ 2.5 Hz.

C1:SUS-ITMX_OLPIT_GAIN = 1.0 (was 2.6)
C1:SUS-ITMX_OLYAW_GAIN = -0.5 (was -1.6)

Next questions:
- Can we notch ~3 Hz feedback so that LSC doesn't feedback this motion?
- Why ~3 Hz motion is high for BS/PRM? Too much load on BS chamber stack?
- Can we reduce ~3 Hz motion?
- If BS chamber stack is bad, PR3 might have ~3 Hz motion, too. Does this make PRMI beam spot motion crazy?