40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 54 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5215   Fri Aug 12 17:37:11 2011 JenneUpdateSUSETMY hopefully good again

[Jamie, Jenne]

We went in to have a look-see at ETMY since it looked stuck-ish.  Jamie noticed that the side magnet was pretty close to the teflon plates of the OSEM.  We rotated it a bit, and now its all better.  We also adjusted the OSEMs until their mid-ranges were happy.  The U's were a little low, and the L's were a little high, as if the optic were a bit pitched backward.  Anyhow, we checked that the table is level, and tweaked the OSEMs.  We're starting the free-swinging test now...

Excited all optics

Fri Aug 12 17:38:53 PDT 2011
997231148

  5216   Fri Aug 12 20:28:13 2011 JenneUpdateSUSETMY hopefully good again

Quote:

[Jamie, Jenne]

We went in to have a look-see at ETMY since it looked stuck-ish.  Jamie noticed that the side magnet was pretty close to the teflon plates of the OSEM.  We rotated it a bit, and now its all better.  We also adjusted the OSEMs until their mid-ranges were happy.  The U's were a little low, and the L's were a little high, as if the optic were a bit pitched backward.  Anyhow, we checked that the table is level, and tweaked the OSEMs.  We're starting the free-swinging test now...

Excited all optics

Fri Aug 12 17:38:53 PDT 2011
997231148

 Hmmm.  I'm no longer convinced that ETMY is healthy.  I think that when I gave it a kick, it's bouncing against something.  I can't fit the peaks to get the input matrix.  I guess step 1 is to try giving it a smaller kick for the free swinging spectra.  But if the owl shift folk feel like it, they might have a look-see.

  5232   Sun Aug 14 19:06:50 2011 JenneUpdateelogelog dead. Brought back to life

like the subject says...

  5237   Mon Aug 15 13:16:50 2011 JenneUpdateSUSRe: ETMY hopefully good again

Quote:

I guess the ETMY suspension is still fine. Their OSEM DC voltage and the free swinging spectra look healthy.

It could be a failure in the initial guess for fitting.

Quote from #5216

I'm no longer convinced that ETMY is healthy. I can't fit the peaks to get the input matrix.

 Turns out I was missing a critical step in the process...running makeSUSspectra.m  After I do that, everything is back under control, and ETMY looks fine. 

I'm almost done doing the peak-fitting and matrix inversion for all optics.

  5239   Mon Aug 15 14:10:56 2011 JenneUpdateSUSMonday SUS update

The moral of the story here is that none of the suspensions are overwhelmingly awesome, but most of them will be fine if we leave them as-is.

SUS DoF Plot Input Matrix "BADness" (1==good)
ITMX inMatDiag.png       pit     yaw     pos     side    butt
UL    0.438   1.019   1.050  -0.059   0.717 
UR    0.828  -0.981   1.128  -0.215  -0.956 
LR   -1.172  -1.201   0.950  -0.275   1.241 
LL   -1.562   0.799   0.872  -0.120  -1.087 
SD   -0.579  -0.847   2.539   1.000  -0.170 

 
4.68597
 
 ITMY  inMatDiag.png        pit     yaw     pos     side    butt
UL    1.157   0.185   1.188  -0.109   0.922 
UR    0.020  -1.815   0.745  -0.051  -0.970 
LR   -1.980  -0.090   0.812  -0.024   1.158 
LL   -0.843   1.910   1.255  -0.082  -0.949 
SD   -0.958   1.080   1.859   1.000   0.325  
4.82756
ETMX  inMatDiag.png        pit     yaw     pos     side    butt
UL    0.338   0.476   1.609   0.316   1.046  
UR    0.274  -1.524   1.796  -0.069  -1.180  
LR   -1.726  -1.565   0.391  -0.100   0.938  
LL   -1.662   0.435   0.204   0.286  -0.836  
SD    0.996  -2.629  -0.999   1.000  -0.111
 
 
 4.32072
 ETMY  inMatDiag.png        pit     yaw     pos     side    butt
UL    1.123   0.456   1.812   0.231   0.936 
UR   -0.198  -1.489   0.492  -0.096  -1.098 
LR   -2.000   0.055   0.188  -0.052   0.764 
LL   -0.679   2.000   1.508   0.275  -1.201 
SD    0.180  -0.591   3.355   1.000   0.200  
 10.643
 BS  inMatDiag.png        pit     yaw     pos     side    butt
UL    1.575   0.697   0.230   0.294   1.045 
UR    0.163  -1.303   1.829  -0.133  -0.958 
LR   -1.837  -0.308   1.770  -0.171   0.944 
LL   -0.425   1.692   0.171   0.257  -1.053 
SD    0.769   0.345  -3.380   1.000   0.058 
6.111
 
 PRM  inMatDiag.png        pit     yaw     pos     side    butt
UL    0.597   1.553   2.000  -0.469   1.229  
UR    1.304  -0.447   0.383  -0.043  -0.734  
LR   -0.696  -1.048  -0.277   0.109   0.687  
LL   -1.403   0.952   1.340  -0.317  -1.350  
SD    0.518  -1.125  -1.161   1.000   0.394  

 
 8.43363
SRM inMatDiag.png       pit     yaw     pos     side    butt
UL    0.831   1.039   1.153  -0.140   1.065 
UR    1.071  -0.961   1.104  -0.057  -1.061 
LR   -0.929  -0.946   0.847  -0.035   0.837 
LL   -1.169   1.054   0.896  -0.118  -1.037 
SD    0.193  -0.033   1.797   1.000   0.045 
 4.17396

 

  5250   Tue Aug 16 17:09:55 2011 JenneUpdateGeneraltoday's work to do

Quote:

  + Rotate the SRM tower to get the SRMI fringes on the AS CCD camera.

        => This is because the required amount of the YAW correction on SRM is currently beyond the range of the DC bias.

 Kiwamu aligned things for me, and I rotated the SRM tower so that the reflected beam was pretty much totally overlapping the incident beam.  The SRC was aligned to make sure things were good.  Now the DC bias for SRM Yaw is ~1.4, so we're totally good. 

To rotate SRM, Jamie had the idea of using 2 screws so I could push the tower on one side, and back off the screw an equal amount on the other side and push the tower to be touching both screws again, to ensure that I was rotating about the center of the tower and wasn't introducing any Pos action. 

While I was at it, I also moved the OSEM connector tower back to its normal place on the table, so it's not in the way of oplev beams.  It had been moved previously to accommodate ITMY near the door.

  5256   Wed Aug 17 15:55:01 2011 JenneUpdateGeneralin-vac work : the end is near

Quote:

We will pump down the chambers on Thursday Friday morning.

 All hands on deck at 9am Thursday for drag wiping and doors.  We'll do the 5 doors first (including drag wiping), then put on the access connector last.  Steve will then begin pumping early Friday morning.

  5257   Wed Aug 17 17:51:54 2011 JenneUpdateTreasurePrepared for drag wiping

While waiting for the IFO team to align things (there were already ~5 people working on a ~1 person job...), I got all of our supplies prepped for drag wiping in the morning. 

The syringes are still on the flow bench down the Xarm.  I put fresh alcohol from unopened spectrometer-grade bottles into our alcohol drag wiping bottles.

The ITMs already had rails for marking their position in place from the last time we drag wiped.  I placed marker-rails for both ETMs.

  5280   Tue Aug 23 00:55:13 2011 JenneUpdateGeneralIFO ready for doors

[Kiwamu, Jenne]

After the IFO was aligned in air one final time, we tapped on a few OSEMs until we were happy with all of the centering of all of the optics' OSEMs.  All are within 0.05 of their halfway values, with the exception of one each on MC1 and MC3, one of which is within 0.06, and the other 0.08.  Because of the realignment pain of dealing with MC OSEMs, we elected to leave these alone.  Also, since we obviously didn't open the MC2 tank, we don't know how they are, although the numbers look reasonable. 

Also, we took photos (to be posted on Picasa in a day or two) of all the main IFO magnet-in-OSEM centering, as best we could.  SRM, BS, PRM all caused trouble, due to their tight optical layouts.  We got what we could.  Various people have been looking at these for the past 2 weeks, and I think they're all fine, even if we didn't get stellar photos.

We are now prepared for pumping.  For real this time.

 

  5281   Tue Aug 23 01:05:40 2011 JenneUpdateTreasureAll Hands on Deck, 9am!

We will begin drag wiping and putting on doors at 9am tomorrow (Tuesday). 

We need to get started on time so that we can finish at least the 4 test masses before lunch (if possible). 

We will have a ~2 hour break for LIGOX + Valera's talk.

 

I propose the following teams:

(Team 1: 2 people, one clean, one dirty) Open light doors, clamp EQ stops, move optic close to door.  ETMX, ITMX, ITMY, ETMY

(Team 2: K&J) Drag wipe optic, and put back against rails. Follow Team 1 around.

(Team 3 = Team 1, redux: 2 people, one clean, one dirty) Put earthquake stops at correct 2mm distance. Follow Team 2 around.

(Team 4: 3 people, Steve + 2) Close doors.  Follow Team 3 around.

Later, we'll do BS door and Access Connector.  BS, SRM, PRM already have the EQ stops at proper distances.

 

  5289   Tue Aug 23 16:23:33 2011 JenneUpdateVACAccess connector in place

[Steve, Bob, Jamie, Kiwamu, Valera, Jenne]

The access connector is now in place, in preparation for pump-down.  Tomorrow (hopefully) we will do all the other doors.

 

  5299   Wed Aug 24 17:05:11 2011 JenneUpdateSUSBroken UL magnet on ITMX

Quote:

The ITMX tower was shipped into the Bob's clean room to put the magnet back on. 

 Repair work is delayed.  I need the "pickle pickers" that hold the magnet+dumbbell in the gluing fixture, for gluing them to the optic.  Here at the 40m we have a full set of SOS gluing supplies, except for pickle pickers.  We had borrowed Betsy's from Hanford for about a year, but a few months ago I returned all of the supplies we had borrowed.  Betsy said she would find them in her lab, and overnight them to us.  Since the problem occurred so late in the day, they won't get shipped until tomorrow (Thursday), and won't arrive until Friday.

I also can't find our magnet-to-dumbbell gluing fixture, so I asked her to send us her one of those, as well. 

I have 2 options for fixing ITMX.  I'll write down the pros and cons for each, and we can make a decision over the next ~36 hours.

OPTIONS:

(#1) Remove dumbbell from optic.  Reglue magnet to dumbbell. Reglue magnet+dumbbell to optic.

(#2) Carefully clean dumbbell and magnet, without breaking dumbbell off of optic.  Glue magnet to dumbbell.

PROS:

(#1) Guarantee that magnet and dumbbell are axially aligned.

(#2) Takes only 1 day of glue curing time.

CONS:

(#1) Takes 2 days of glue curing time. (one for magnet to dumbbell, one for set to optic.)

(#2) Could have slight mismatch in axis of dumbbell and magnet.  Could accidentally drop a bit of acetone onto dumbbell-to-optic glue, which forces us into option 1, since this might destroy the integrity of the glue joint (this would take only the 2 days already required for option 1, it wouldn't force us to take 2+1=3 days).

  5301   Thu Aug 25 13:10:42 2011 JenneUpdateSUSDrag wiping

As we have seen in the past, both of the ITMs were more dusty than the ETMs, presumably because we have the vertex open much more often than the ends.  Kiwamu and I wiped all of the optics until we could no longer see any dust particles within a ~1.5 inch diameter area around the center. 

Since we have ITMX out for magnet gluing, I'll probably drag wipe both front and back surfaces before putting it back in the suspension cage.  All of the optics have clear dust on the AR surfaces, but we can't get to that surface while the optics are suspended.  For the ETMs this isn't too big of a deal, but it does concern me a bit for the ITMs and other transmissive optics we have.  I don't think it's bad enough yet though to warrant removing optics from suspensions just to wipe them.

  5302   Thu Aug 25 15:20:03 2011 JenneUpdateSUSBroken UL magnet on ITMX

Dmass just reminded me that the usual procedure is to bake the optics after the last gluing, before putting them into the chambers.  Does anyone have opinions on this? 

On the one hand, it's probably safer to do a vacuum bake, just to be sure.  On the other hand, even if we could use one of the ovens immediately, it's a 48 hour bake, plus cool down time.  But they're working on aLIGO cables, and might not have an oven for us for a while.  Thoughts?

  5308   Fri Aug 26 15:30:36 2011 JenneUpdateSUSITMX magnet reglued
The ITMX UL magnet has been reglued.

I *very carefully* using the corner of a cleaned razor blade dropped single drops of acetone onto the top of the dumbbell, and scratched off the residual glue. I didn't want to get even a sprinkle of acetone on the dumbbell-glass junction, and I managed to avoid it. Also, the dumbbell never broke off of the glass (something I've never been able to achieve before), so all I had to do was glue the magnet back onto the dumbbell.

I also scratched the glue from the magnet, after soaking in acetone. I made sure to keep track of which way the magnet had been glued by putting it in the pickle picker that I received from Betsy before getting rid of the glue. I specifically did not compare the polarity of this magnet to the others still glued, because I have seen that in the past break magnets from dumbbells. They can't really handle sideways forces. But since it's glued the same way that it was, it should be fine.

I then aligned the optic in the gluing fixture. I test-fit the pickle picker with magnet, to ensure that the axes of the dumbbell and magnet were aligned as closely as possible. I adjusted the optic to make this axial alignment as perfect as I could see with my eye. Unfortunately the fixture doesn't allow a whole lot of viewing angles of the magnet-dumbbell joint, so we'll see how well I did after I remove it from the fixture.

I put a little dab of epoxy on the end of the magnet, spread it around so it coated the whole surface, and glued it on.

I'll come in tomorrow (Saturday) to check on it, and take it out of the fixture. If it's going to break coming out of the fixture, which I hope won't happen, but has happened before, then I want to be able to fix it again asap.
  5310   Fri Aug 26 16:17:31 2011 JenneUpdateGeneraldrawer cabinet moves in

Quote:

Jamie and Shuresh moved in Jenne's 11 drawers cabinet and relocated old note book boxes on the inside of the vac tube.

 Barring other chores for next Wednesday, we're going to spend Wednesday afternoon populating the new cabinet with all of the optics hardware: posts, forks, dogs, everything!  It's going to be so organized and awesome!!

  5311   Sat Aug 27 14:33:04 2011 JenneUpdateSUSITMX magnet status

As I feared, since I couldn't see the magnet-to-dumbbell joint from all angles, they ended up being off by ~1/3 of a magnet diameter. 

Because I don't want to deal with finding another failed glue joint tomorrow, I removed the magnet and dumbbell from the optic, and broke the manget off of the dumbbell.  As with yesterday, I kept track of which end of the magnet had been glued to the dumbbell. 

I got a new dumbbell, removed all the glue from the magnet, and reglued them together, in the fixture that ensures they are well aligned. 

Tomorrow I will come in and glue the magnet dumbbell assembly to the ITM.

  5314   Sun Aug 28 20:15:11 2011 JenneUpdateSUSITMX magnet status

Quote:

Tomorrow I will come in and glue the magnet dumbbell assembly to the ITM.

 Glued.

Tomorrow afternoon I'll remove the optic from the fixture, and put it in the oven.

  5330   Wed Aug 31 16:18:25 2011 JenneUpdateGeneralNew Optics Drawers

[Kiwamu, Manuel, Jenne]

The new optics storage drawers have been populated with optics.  Each drawer is labelled.  Harsh punishments will be inflicted on anyone found disobeying the new scheme.

  5342   Tue Sep 6 11:21:33 2011 JenneUpdateSUSITMX rehung (Friday)

[Jenne, Katrin, Jamie]

I'm a bad kid, and forgot to elog my Friday morning work...

Bob gave me back ITMX after a 48hour bake at 80C + clean RGA scan Friday morning after coffee and doughnuts.  Katrin helped me put it back in the suspension wire. 

While I was leveling the optic (making sure the scribe lines on each side of the optic are at the same height off the table), Katrin cut some new viton for replacement EQ stops.  The optic was missing one lower earthquake stop (the one that Jamie noticed last week), and somehow one other rubber piece came out of the EQ stop on another lower screw while we were re-suspending the optic.  We put the new stops in, and then checked the balance of the test mass.

The oplev is still the HeNe laser that is leveled to the level optical table in the cleanroom.  The lever arm is ~1.5 meters, and over that distance the reflected beam was pointed "up" in pitch by ~1.5mm, which is less than one beam diameter of the HeNe.  This is well within our ability to correct using the OSEMs.

We then locked the test mass, and installed it in the chamber.  I approximately did the half-voltage centering of the OSEMs, leaving the fine-tuning to Kiwamu for after lunch. 

  5343   Tue Sep 6 11:27:19 2011 JenneUpdateGeneralAfternoon pre-pumpdown todo list

These are the things that I can think of that we need to do before we can close up:

* Take a close look at both ITMs' OSEMs, and ensure that the magnets aren't too close to either plate in the OSEMs.  Both have had funny business over the past week.

* Do a free swinging test on both ITMs.  (ITMY may not need it, if we haven't touched it since the last free swinging test, but it can't hurt to take the data)

* Confirm that POX is exiting the chamber.

* Is there anything else???

 

Our goal is to finish this work by tonight, so that we can close doors and start pumping tomorrow.

  5346   Tue Sep 6 17:56:12 2011 JenneUpdateSUSfree swinging test on ITMX

Quote:

Tue Sep  6 17:48:02 PDT 2011
999391697

 Kiwamu excited ITMY (which Suresh had already started).  I just kicked ITMX:

Tue Sep  6 17:55:21 PDT 2011
999392136

  5347   Tue Sep 6 17:56:53 2011 JenneUpdateIOOFree Swing ITMY started

Quote:

Free swing of ITMY started at

Tue Sep  6 17:41:43 PDT 2011

 

 I think Kiwamu accidentally restarted this kick at 17:48:02 PDT.

  5349   Tue Sep 6 21:33:21 2011 JenneUpdateSUSDiagonalizability of ITMX and ITMY is acceptable

[Rana and Kiwamu on ITMX, Jenne and Suresh on ITMY, Zombie/brains meeting on accepting the matricies]

 

Optic Spectra Matrix "Badness"
ITMX ITMX.png       pit     yaw     pos     side    butt
UL    0.584   0.641   1.396  -0.578   0.558 
UR    0.755  -1.359   0.120  -0.286   0.262 
LR   -1.245  -0.139   0.604  -0.388   0.511 
LL   -1.416   1.861   1.880  -0.681  -2.669 
SD   -0.753   0.492   3.263   1.000  -1.523 
 5.85983
ITMY  ITMY.png           pit     yaw     pos     side    butt
UL    1.000   0.572   1.134  -0.059   0.951  
UR    0.578  -1.428   0.916  -0.032  -1.024  
LR   -1.422  -0.531   0.866  -0.009   1.086  
LL   -1.000   1.469   1.084  -0.036  -0.939  
SD   -0.662   0.822   1.498   1.000   0.265  
4.47727
 

 OSEMs were tweaked.  We have decided that both ITMs are okay in terms of their diagonalization.  ITMY isn't stellar when you look at the spectra, but it's kind of close enough.  Certainly the matrix looks fine.

Aside from checking on POX, I think we're now ready to close up.  Check back later tonight for a final decision announced on the elog.

  5353   Wed Sep 7 00:44:51 2011 JenneUpdateSUSFreeswing all

I just started a freeswing all, as a final check before we pump:


Wed Sep  7 00:43:21 PDT 2011
999416616

Wed Sep  7 00:43:32 PDT 2011
WATCHDOGS WILL BE RESET 5 HOURS AFTER THIS TIME
sleeping for 5 hours...

Jamie: Please do a quickie analysis (at least for the ITMs) before helping Steve with the heavy doors.

I closed the PSL shutter.

Both ITM chambers were checked for tools, so there should be nothing left to do but put the heavy doors on, and begin pumping.

  5354   Wed Sep 7 00:47:51 2011 JenneUpdateVACPUMP is a GO!

Steve and Jamie:  After Jamie checks the ITM free swingings, please put on the ITM heavy doors and start the pump!  For real this time!!! Yeah!

  5382   Sat Sep 10 19:45:29 2011 JenneUpdateLSCY Arm work

Quote:

 * ITMY OL: Also the optical layout seems strange: there are two copies of the laser beam going into the chamber (??).

* The ETMY OL beam was coming out but clipping on the mount for the ETMY OL HeNe. This indicates a failure on our part to do the ETMY closeout alignment properly.

 The 2nd beam from this laser is for the SRM's OpLev, so that shouldn't be changed.

For better or worse, we didn't do anything to the ETM OpLevs, because they don't have any in-vac steering optics.  We did however go through and check on all the corner OpLevs.

  5402   Wed Sep 14 01:21:17 2011 JenneUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

[Jenne, Mirko, with supervision from Jamie]

We are starting to create the new OAF model, so that it works with the new CDS system. 

I created (and did an "svn add" for) a new c1oaf.mdl, in the same place as the current c1lsc.mdl . Since the oaf will kind of be working with ISC things, I decided to put it in that folder.  So far this new OAF model just has SHMEM/PCIE memory sharing things to get info from the LSC and PEM models.  The OAF model has dcuid=22 (the same as in the old system), and lives on the LSC machine with specific_cpu=4.  This is the CPU number that Yoichi was going to use, but he ended up putting his FF stuff directly into the LSC model for delay reasons.

I modified the c1rfm.mdl to take seismometer and accelerometer info from the PEM model, and give it to the "rfm" via shmem, and then using PCIE (dolphin) to get the channel to the OAF model.

I modified the c1lsc model to have shmem outputs that go from the degrees of freedom to the OAF, and shmem inputs from the OAF's output to sum into the DoFs, just like Yoichi's FF stuff.  I also removed the old OAF_OUT, because it would only allow me to select one DoF at a time, and I will eventually want the ability to do multiple amounts of OAFing at the same time.  Hopefully.

All of the above changes have been svn'ed with nice log messages into the cds svn.

I have not yet modified the PEM model to give the seis/acc information to the RFM model.

I will need to acquire the PSL's PZT input as a representation of the mode cleaner's length if I want to apply the OAF to the MC to recreate past work.

  5421   Thu Sep 15 18:12:21 2011 JenneUpdateSUSfree swinging test in vacuum condition

Quote:

All the optcs were excited

Sat Sep 10 02:14:11 PDT 2011
999681266

 

 

Optic The Plot Input Matrix BADness
ITMX  ITMX.png       pit     yaw     pos     side    butt
UL    0.601   0.680   1.260  -1.009   0.223 
UR    0.769  -1.254  -0.175  -0.179   0.581 
LR   -1.231   0.065   0.566  -0.480   0.252 
LL   -1.399   2.000   2.000  -1.310  -2.944 
SD   -0.580   0.868   2.451   1.000  -1.597 

 
7.95029
ITMY  ITMY.png       pit     yaw     pos     side    butt
UL    1.067   0.485   1.145  -0.195   0.929 
UR    0.548  -1.515   0.949  -0.142  -1.059 
LR   -1.452  -0.478   0.855  -0.101   1.051 
LL   -0.933   1.522   1.051  -0.153  -0.962 
SD   -0.530   0.903   2.115   1.000   0.142 
3.93939
ETMX ETMX.png       pit     yaw     pos     side    butt
UL    0.842   1.547   1.588  -0.018   1.026 
UR    0.126  -0.453   1.843   0.499  -1.173 
LR   -1.874  -0.428   0.412   0.511   0.934 
LL   -1.158   1.572   0.157  -0.006  -0.867 
SD    1.834   3.513  -0.763   1.000  -0.133
5.39825
ETMY ETMY.png       pit     yaw     pos     side    butt
UL   -0.344   1.280   1.425  -0.024   0.903 
UR    1.038  -0.720   1.484  -0.056  -1.161 
LR   -0.618  -1.445   0.575  -0.040   0.753 
LL   -2.000   0.555   0.516  -0.007  -1.184 
SD   -0.047  -0.038   0.986   1.000   0.083 
4.15747
BS  BS.png       pit     yaw     pos     side    butt
UL    1.549   0.655   0.393   0.263   0.997 
UR    0.192  -1.345   1.701  -0.063  -0.949 
LR   -1.808  -0.206   1.607  -0.085   0.952 
LL   -0.451   1.794   0.299   0.241  -1.101 
SD    0.724   0.293  -3.454   1.000   0.037 
5.66432
PRM  PRM.png       pit     yaw     pos     side    butt
UL    0.697   1.427   1.782  -0.337   0.934 
UR    1.294  -0.573   0.660  -0.068  -0.943 
LR   -0.706  -1.027   0.218   0.016   0.867 
LL   -1.303   0.973   1.340  -0.254  -1.257 
SD    0.369  -0.448  -0.496   1.000   0.456 
5.1026
SRM   Can't invert....need to fix the peak-finding.  
MC1  MC1.png       pit     yaw     pos     side    butt
UL    0.872   0.986   0.160   0.054   0.000 
UR    0.176  -0.752   0.917   0.018   0.000 
LR   -1.824  -2.000   1.840   0.002   3.999 
LL   -1.128  -0.262   1.083   0.038  -0.000 
SD    0.041   0.036  -0.193   1.000  -0.001 
5.31462
MC2  MC2.png       pit     yaw     pos     side    butt
UL    1.042   0.767   0.980   0.131   0.928 
UR    0.577  -1.233   1.076  -0.134  -0.905 
LR   -1.423  -0.640   1.020  -0.146   1.050 
LL   -0.958   1.360   0.924   0.120  -1.117 
SD   -0.073  -0.164  -0.702   1.000  -0.056 
4.07827
MC3  MC3.png       pit     yaw     pos     side    butt
UL    1.595   0.363   1.152   0.166   1.107 
UR    0.025  -1.629   1.135   0.197  -0.994 
LR   -1.975   0.008   0.848   0.105   0.904 
LL   -0.405   2.000   0.865   0.074  -0.995 
SD   -0.433   0.400  -1.624   1.000   0.022 
3.64881

 

  5438   Fri Sep 16 17:16:15 2011 JenneUpdateSUSInput matrix diagonalization: Fail!

[Jenne, Anamaria]

I put the new matricies in from the free swinging test for the: ITMX, ITMY, ETMX, ETMY, PRM, BS

Some of the optics damped okay, but ETMX and BS were not good at all.  ETMX was ringing up when I turned on the damping.  BS wasn't, but when I gave it a kick, it wouldn't damp.  No good.

I tried ITMY, and it was totally fine, with nice damping Qs of ~5.  So, I don't know what's going on. 

Anamaria is trying a new 4x4 matrix-inverter, so we can look at the inversion of just the face osems.  We'll see how it goes. 

Since things were crappy, I did a BURT restore, so things are as they were earlier this morning.

  5456   Mon Sep 19 11:49:32 2011 JenneHowToGeneralPlan for this week: SUS inversion

Quote:

  + Inversion and installation of the SUS input matrices (Jenne)

 It turns out that this is complicated, since there are so many people working with the IFO this week.  What I would like to do is put in the new input matricies, and then do a free swinging test, to see if the suspensions are really diagonalized in the way that we want them to be.  I can't do this during the day, since it will interfere with Paul's OpLev work.  And at "night", I can't, since we'll be doing locking.  So, this may be a late-night task.  I'll write a script this afternoon that will put in all of the new input matricies, and then run the freeswing and the restore watchdogs scripts.  Whomever is the last one to leave for the night can run the combo script.

EDIT:  As of this time (~11:45am), ITMY has its new input matrix.

  5461   Mon Sep 19 15:41:48 2011 JenneUpdateSUSSUS diag stuff... just so I remember what I'm doing

The following optics were kicked:
ETMX
Mon Sep 19 15:39:44 PDT 2011
1000507199

  5471   Mon Sep 19 22:47:44 2011 JenneUpdateSUSSUS diag stuff... just so I remember what I'm doing

 The last person out tonight should run the following scripts:

In Matlab: 

/opt/rtcds/caltech/c1/scripts/SUS/peakFit/writeMultiSUSinmat.m

In command line:

/opt/rtcds/caltech/c1/scripts/SUS/freeswing all

 

Then in the morning, someone should do a BURT restore to early today (to get the default matricies back), and also restore the watchdogs.

Thanks!
 

  5476   Tue Sep 20 04:12:26 2011 JenneUpdateSUSJenne's Scripts started

Quote:

I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.

 Thanks!  I'll give them a little more time, then restore things.

  5477   Tue Sep 20 09:44:44 2011 JenneUpdateSUSJenne's Scripts started

Quote:

Quote:

I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.

 Thanks!  I'll give them a little more time, then restore things.

 I began restoring the optics at ~9:30am, so I have a full 6 hours of data, in case I need that much to separate the Pos/Side modes on some of the optics.  They are all damping again with their original matricies.

  5479   Tue Sep 20 14:53:13 2011 JenneUpdateSUSJenne's Scripts started

Quote:

Quote:

Quote:

I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.

 Thanks!  I'll give them a little more time, then restore things.

 I began restoring the optics at ~9:30am, so I have a full 6 hours of data, in case I need that much to separate the Pos/Side modes on some of the optics.  They are all damping again with their original matricies.

 So, clearly this was a kind of dumb idea.  There is nothing mechanical going on between our sensor inputs and our Pit/Pos/Yaw/Side DoF filter banks.  It's just math.  On the other hand, we now have a 3rd set of in-vac free swinging data, so I can (after all the suspensions are working) have a look at the drift in matrix elements over time.

In other news, after some meditation, and fitzing with DoF gain values, all of the IFO optics except for SRM now have their new input matricies, and are damping pretty nicely.  I need to go through and do an "eyeball" check to make sure that everything has a Q of ~5ish.  So far, I've kicked the optics, and watched that they damped fairly quickly, but I don't have a guesstimate of the Q's for each optic, for each DoF.

So, still to do:

Use another set of data and invert the SRM matrix DONE

Plug in the MC matricies, make sure they're okay. DONE

Check the Q's for all optics, all DoFs. 

  5480   Tue Sep 20 15:23:16 2011 JenneUpdateSUSfree swinging test in vacuum condition

This is using data for the SRM from: 20 Sept 2011 03:20:00 PDT = 1000549215

You can see that there are still some funny peaks between Pit and Yaw, but I finnessed the peak-finding, and I was able to fit all of the correct peaks, and invert the matrix:

 SRM now has its new matrix, and is damping happily.

Optic The Plot Matrix Badness
SRM SRM.png                pit     yaw     pos     side    butt
UL    0.877   0.983   1.105  -0.288   1.092 
UR    1.010  -1.017   1.123  -0.145  -1.055 
LR   -0.990  -1.002   0.895  -0.091   0.848 
LL   -1.123   0.998   0.877  -0.234  -1.006 
SD    0.089   0.064   3.752   1.000  -0.009
 4.4076

 

 

  5485   Tue Sep 20 16:45:09 2011 JenneUpdateSUSSUS diag stuff... just so I remember what I'm doing

Has the Q been checked?  Still in progress...

Optic POS PIT YAW SIDE
ITMX  done  done done done
ITMY  done  done  fine??  done
ETMX  done  done  done  done
ETMY  done  done  done  done
BS  done  done  done  done
PRM done done done done
SRM done done done done
MC1        
MC2        
MC3        

 So, update as of 6:17pm:  I have tuned the damping gains for all IFO optics.  Everything is good, except for ITMY Yaw.  It's probably fine, the optic damps okay, but it doesn't look like a nice clean ringdown.  I haven't taken the time to go back and look at it again.

I have to go to a dinner, but later (probably in the morning, so I don't disturb evening locking) I'll check the MC Qs.

  5548   Mon Sep 26 17:49:21 2011 JenneUpdateComputersWe now have BURT restore for slow channels

Koji and Suresh found that there have not been any autoburt snapshots taken of slow channels since ~December 13th 2010.  Not good!

We have found an elog from Joe talking about autoburt changes from that day:  elog 4046

Joe pointed all of the autoburt stuff to the new directory system, so it now decides to take a snapshot of every system in the *new* target directory.  This means, since all of the aux things were left in the *old* target directory that none of them were getting snapshots taken.  I have added the old target path back to the autoburt cron file so that every hour it will search through both old and new target directories and take snapshots of everything in both. 

So, the systems which will now once again have autoburt snapshots taken are the following:

c1aux

c1auxex

c1auxey

c1dcuepics

c1iool0

c1iscaux

c1iscaux2

c1iscepics

c1losepics

c1omcepics

c1psl

c1susaux

c1vac1

c1vac2

 

I moved some old stuff (and especially things which would conflict with the new stuff) to the old target directory/oldfe/ :  c1ass, c1assepics, c1susvme1, c1susvme2, c1sosvme, c1iovme.

The following systems don't have an autoburt.req file, so don't get snapshots:  c0daqawg, c1daqctrl, c1dcu1, c1iscex, c1iscey.  If any of these need autoburts, we should create them.

All the new systems in the new target directory still have their autoburts working.

The first test of this will be in a few minutes, at 18:07:00 Pacific during the regular cron job.  Hopefully nothing crashes....

  5550   Mon Sep 26 18:59:11 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

  5552   Mon Sep 26 22:40:41 2011 JenneUpdateComputersWe now have BURT restore for slow channels
[Jenne, Koji]

After much Perl-learning and a few iterations, we have fixed the burt restore script, so that it actually does the slow channels. We have so far had one successful run, at 22:25, and the regular cron job should start doing the slow channels as of 23:07.
  5556   Tue Sep 27 11:43:59 2011 JenneUpdateelogElog has been dying a lot lately...

WTF?

  5557   Tue Sep 27 11:52:33 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

 

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

 Suresh makes a fine point.  I think the channel between c1ioo and c1mcs should always have had to go through the c1rfm model.  I don't know why it wasn't.  Anyhow, I have changed things so that there is one signal passing from c1ioo to c1rfm, and that signal is split in two, and goes to both c1oaf and c1mcs.  The naming convention I used last night is the one I kept:  C1:IOO-RFM_MCL goes from c1ioo to c1rfm, and then C1:RFM-OAF_MCL goes from c1rfm to c1oaf, and C1:RFM-MCS_MCL goes from c1rfm to c1mcs. 

We can't compile until Mirko and I figure out what to do with the OAF model though.  Mirko, Den and I were looking at the c1oaf model, to make sure it is ready to compile, and I'm not sure that it is.  And we need everything with common channel names to be compiled at the same time, so I can't compile any of the models today, until we get this figured out.

The problem is thus:  The old TOP_XFCODE that mevans wrote back in 2008 takes in a certain number of inputs, calculates the new filter coefficients, and spits out the filtered signals.  Back in those days, we only ever gave the adaptive system one control (target) signal at a time.  Now, we want to be able to do multiple, if we so desire.  I don't know exactly how to do this yet.  Either we need to modify the code to make it a super-code, or we can have one copy of the code for each control signal (MC_F, XARM, YARM, DARM, MICH, etc...).  Do we want to have one code adapt everything at once, and have a giant MIMO system, or do we want to have many SISO-like systems in parallel (SISO-like, because each one would take in one control signal, and many seismometer signals, and output many filtered seis signals, but it wouldn't be combining control signals together)? 

Either one of these options could be waaay to computationally tough for the computer.  The old computer was basically railed when we had one adaptive block, with one control signal and 7 seismometers.  7 was the max number of auxiliary channels we could use.  So, how much faster are the new computers?? Do we need to have one OAF per DoF that we want to filter? 

  5558   Tue Sep 27 15:33:03 2011 JenneUpdateComputersMaking models, wreaking havoc

[Jenne, Mirko, Den]

We have entered into an adventure in model compiling.  What follows is a stream-of-consciousness report of what the hell we're doing, so Jamie can figure it out and fix it if everything goes to hell.

Note that for the first part of things, we have used a new version of the Adaptive XFCODE, which Mirko and Den modified last night to be able to handle multiple control signal inputs.  

On c1lsc, make uninstall-daq-c1oaf, make clean-c1oaf, make c1oaf.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:RFM_OAF_MCL

On c1sus, make uninstall-daq-c1sus, make clean-c1sus, make c1sus.  (This was an accident.  I should have been making c1rfm.  Oops.)  Then make install-c1sus.  It looks like this automatically did make install-daq-c1sus and make install-screens-c1sus, so I'm not doing those. 

On c1sus, make uninstall-daq-c1rfm, make clean-c1rfm, make c1rfm.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:IOO-RFM_MCL


On c1ioo, make uninstall-daq-c1ioo, make clean-c1ioo, make c1ioo.  No errors.

On c1lsc, make c1oaf.  Here's some of the ouptut, with some of the error stuff:

: warning: ISO C90 forbids mixed declarations and code
/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2954: warning: ISO C90 forbids mixed declarations and code
make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.34.1-cs'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf'
make: *** [c1oaf] Error 2

Again on c1lsc, make clean-c1oaf, make c1oaf.  Here are some things:

Warning:  variable "sysnum" is used but not declared.

In file included from build/c1oafepics/c1oaf.i:38:
src/include/fmReadCoeff.h:4:1: warning: "NO_FM10GEN_C_CODE" redefined
<command-line>: warning: this is the location of the previous definition

build/c1oafepics/c1oaf.i:5156: warning: passing argument 2 of 'strcpy' discards qualifiers from pointer target type
/usr/include/string.h:127: note: expected 'const char * __restrict__' but argument is of type 'volatile char *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../../include/drv/inputFilterModule1.h:5: note: expected 'double *' but argument is of type 'long unsigned int *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2780: warning: ISO C90 forbids mixed declarations and code

make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[1]: *** [default] Error 2
make: *** [c1oaf] Error 2

Again, on c1lsc, make clean-c1oaf, make c1oaf.  More errors, pretty similar.  Then we changed the name of the adaptive filtering code, so maybe it will work now?  We had called the block "TOP_XFCODE", but that was the name of the old .c code.  The block used to be called "XFCODE", in a subsystem "TOP".  So now we named the .c code "ADAPT_XFCODE" since the block is "XFCODE", and the subsystem is "TOP".

Again, on c1lsc, make clean-c1oaf, make c1oaf.  Errors, they look the same.

Mirko is now modifying c1oaf.mdl to look more like the old version, with only one control signal input, so that we can use the old XFCODE that has been around for years.

First, we completely took out the .c code entirely.  Now the c1oaf.mdl is just signals and matricies, no c-code is called.  We did make clean-c1oaf, make c1oaf, and pretty much all of the same errors are present.
 

We took out the buses, and did make clean-c1oaf, make c1oaf, and we got a whole lot of warnings, but no "Error 2"'s.  This seems good.  We're going to try replacing those buses with Muxes, and see how that goes.

Now we're going to try to install the c1oaf, because maybe all the errors and shit we're seeing is just useless crap, and there aren't actually problems...here we go!

That seemed to work, and the c1oaf model on the GDS status screen seems happy.  Numbers are moving around, which is my only current diagnostic.

Okay, now Mirko is going back to the full, new c1oaf, but replacing the Buses with Muxes. 

Did a make clean-c1oaf, make c1oaf, got errors again.

Once again removed the .c code.  Just put in a matrix instead. Did make clean-c1oaf, make c1oaf.  No errors. 

Den did a reorganization of the .c code, and we put it back in to the simulink model.  Trying again the making stuff.  Fail..Basically the same errors as before.

Next up:  Putting in .c-code, but something which basically does nothing.  Just defines all the outs as zeros.  Make stuff.  Still had problems, same errors.  Grrrr, argh. 

Found the RCG manual:  T080135-v4.  In it, when talking about including c-code, it had an example of totally simple code.  We tried out their version of simple code, and it worked.  No errors!  Now to figure out what is same and different between our simple code and theirs.

 PUT THE RIGHT STUFF in the Block Properties for the c-code, including name of the .c file, and path to the .c file.  This is critical!!  Now we can make some of our simple versions work, but not all.  We're slowly increasing complexity of our c-code...

 At some point in the last hour, I tried a make install-c1oaf, and then checked the screens, and they all had bad white boxes.  So even though the model seemed to compile (at one point), the channels and screens aren't happy yet.  But that's really a project for after the code compiles happily.

Okay, some progress was made to get the c-code running, and compiling, but it's not all there yet.  We're putting in a simple, useless version of the c-code so we can try compiling everything else.

Everything is compiled, installed, there are no red lights on the GDS_STATUS screen.  All seems okay for locking for tonight.

 

  5560   Wed Sep 28 00:06:21 2011 JenneUpdateSUSWatchdog rearmed

Quote:

I came to the control room and found the PMC and IMC were unlocked. ==> Relocked
I found the watch dogs of the vertex suspensions are tripped.

I checked the data for the past 6 hours and found they are independent events.
The unlock of the MCs occured 4 hours ago and the watchdogs tripped 2 hours ago.

The suspension damping was restored at around 7:50PM PDT.

 Oops, I should have noticed all of those things.  Several hours of computer-battle exhausted me.  Thanks Koji.

  5564   Wed Sep 28 13:30:01 2011 JenneUpdatePSLPMC was unlocked

Relocked the PMC.  MC came back immediately.

  5565   Wed Sep 28 14:15:40 2011 JenneUpdateComputersEdits to c1pem, c1oaf

[Mirko, Jenne]

Mirko edited c1pem to have some new BLRMS channels.

I added a master Enable switch to the c1oaf.

Both were compiled, and restarted.  fb rebooted.  All looks okay (hopefully)

  5571   Wed Sep 28 22:25:25 2011 JenneUpdateComputersTorturing control computers. Fine again now

Quote:

[Mirko, Jenne]

We tried to run an extended version of Matt's LMS adaptive filter c-code. We got the extension to compile separately in gcc first. Then after some tweaking of the code we could make-install c1oaf with the c-code.

This killed c1lsc (the FE computer running c1oaf). Not responding to ssh or even pings. We replaced the bad c-code with harmless code, then reset c1lsc via the hardware button. While looking for c1lsc we discovered the problem with c1iscy network card (see previous entry).

After c1lsc reboot, restart of the FB, and a BURT restore not ok yet

 We had lots of trouble damping the Vertex Suspensions after this craziness.  A symptom was that even if all of the damping servos on an optic were OFF, and I turned the watchdog on (LSC is disabled, so no OAF siganls, no LSC signals), there were signals going to the coils. 

We did a reboot of the c1sus computer, did another BURT restore, and the optics started damping happily.   Burt restore, at least for c1susepics and c1mcsepics, seems to not be happening automatically.  I thought it was supposed to happen when the model was restarted?

Things now appear to be normal again.

  5572   Wed Sep 28 22:30:01 2011 JenneUpdateAdaptive FilteringOAF is disabled

I am leaving the OAF disabled, so there should be nothing that goes to the suspensions from the OAF. 

Disabled for the OAF means all the outputs are multiplied by 0 just before the signals are sent back over to the LSC system to be summed in and sent to the suspensions.  So 0 times anything should mean that the OAF isn't injecting signals.

In other news, while Mirko was trying to figure out the c-code, I began making a new OAF screen.  It is still in progress, but it's in c1oaf/master/C1OAF_OVERVIEW.adl  If you open it up, you can see for yourself that the OAF is disabled.  (Eventually I'll put an enable/disable button on the LSC screen also, but that hasn't happened yet.)

  5575   Thu Sep 29 11:25:55 2011 JenneUpdateAdaptive FilteringTried new c-code, Fail.

[Mirko, Jenne]

Mirko edited the c-code to use Den's stuff that he put in the elog last night.  We then tried to compile and install, but it crashed c1lsc again.  We reverted to the simple, working c-code, pushed the physical reset button on c1lsc, and things started getting better.  The suspensions had the same problem as last night...we had to do a soft shutdown of c1sus to get things better again. 

I did a by-hand burt restore for all of the models on c1lsc and c1sus, since the auto burt restore isn't working.

ELOG V3.1.3-