40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 147 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  9567   Wed Jan 22 18:17:46 2014 JenneUpdateCDSfb timing was off

Since this morning, the fb's timing has been off.  Steve pointed it out to me earlier today, but I didn't have a chance to look at it until now. 

This was different from the more common problem of the mx stream needing to be restarted - that causes 3 red blocks per core, on all cores on a computer, but it doesn't have to be every computer.  This was only one red block per core in the CDS FE status screen, but it was on every core on every computer. 

The error message, when you click into the details of a single core, was 0x4000.  I elog searched for that, and found elog 6920, which says that this is a timing issue with the frame builder.  Since Jamie had already set things on nodus' config correctly, all I did was reconnect the fb to the ntp: 

fb$ sudo /etc/init.d/ntp-client restart

As in elog 6920, the daqd stopped, then restarted itself, and cleared the error message. It looks like everything is good again.

I suspect (without proof) that this may have to do with the campus network being down this morning, so the computers couldn't sync up with the outside world.

  9566   Wed Jan 22 16:36:45 2014 ericqUpdateElectronicsRF distribution box power button fail

Quote:

Rana, Gabriele and I are trying to measure the FSR of the PRC (elog about that later), and we turned off the power to the RF generation box so that we could switch cables at the EOM combiner.  However, as in elog 9101, the power button won't latch when we try to turn the power back on.  All 3 of us tried, to no avail.  For our measurement, poor Gabriele is standing holding the button pushed in, so that we can have some RF sidebands. 

Tomorrow, we'll have to pull the RF generation box, and put in a better switch.

I replaced the stupid broken fancy button with a simple sturdy switch. I had to file out the hole in the chassis a bit, but the switch is pressed in tightly and securely. I put the box back in the rack, but the power cable was coming directly from the power supplies with no fuses. The box was drawing ~.9 and 1.5 Amps from two supplies, so I put 2A fuses on both. Plugged everything back in, and the mode cleaner locks, so it looks like all is well.

RXA: When its so close, I prefer to size it up by 1 step. Please change to 5A fuses. Otherwise, we may blow them from power glitches.

Q: 5A fuses have been swapped in

  9565   Wed Jan 22 15:24:11 2014 SteveSummaryVACRga scan after reboot

Quote:

[Jenne, Steve]

Steve noticed that the RGA was not logging data and that not all the correct connection lights were on, and he wasn't able to run the "RGAset.py" script (in ...../scripts/RGA/) that sets up the proper parameters. 

I looked, and the computer was not mounting the file system.  I did a remote shutdown, then Steve went in and pushed the power button to turn the machine back on.  After it booted up, it was able to talk to the file system, so I started ..../scripts/RGA/RGAset.py .  The first 2 times I ran the script, it reported errors, but the 3rd time, it reported no communication errors.  So, now that the computer can again talk to the file system, it should be able to run the cronjob, which is set to take data at 4am every day.  Steve will check in the morning to confirm that the data is there.  (The last data that's logged is 22Dec2013, 4am, which is right around when Koji reported and then fixed the file system).

 

 

 We are venting tomorrow. This give us an opportunity to fix sick vacuum controller computer. Jamie volunteered.

Remember to rough down cryo and ion pump volumes. Their pressure can be at 1 Torr range after years of accumulated outgassing.  Without total valve controls it is dangerous to have these air pockets. Some of their  gate valves can be leaking and that would explane the slower pumpdown speed. 

 

Attachment 1: Rgascan169dwarmingup.png
Rgascan169dwarmingup.png
Attachment 2: BlankMedmMustBeFixed.png
BlankMedmMustBeFixed.png
  9564   Wed Jan 22 09:05:42 2014 GabrieleConfigurationLSCREFL11 back

 Yesterday night I plugged back the REFL11 RF cable into the corresponding demodulation board.

  9563   Tue Jan 21 19:41:59 2014 JenneUpdateElectronicsRF distribution box power button fail

Rana, Gabriele and I are trying to measure the FSR of the PRC (elog about that later), and we turned off the power to the RF generation box so that we could switch cables at the EOM combiner.  However, as in elog 9101, the power button won't latch when we try to turn the power back on.  All 3 of us tried, to no avail.  For our measurement, poor Gabriele is standing holding the button pushed in, so that we can have some RF sidebands. 

Tomorrow, we'll have to pull the RF generation box, and put in a better switch.

  9562   Tue Jan 21 17:26:59 2014 JenneSummaryVACRebooted RGA computer and reset RGA settings

[Jenne, Steve]

Steve noticed that the RGA was not logging data and that not all the correct connection lights were on, and he wasn't able to run the "RGAset.py" script (in ...../scripts/RGA/) that sets up the proper parameters. 

I looked, and the computer was not mounting the file system.  I did a remote shutdown, then Steve went in and pushed the power button to turn the machine back on.  After it booted up, it was able to talk to the file system, so I started ..../scripts/RGA/RGAset.py .  The first 2 times I ran the script, it reported errors, but the 3rd time, it reported no communication errors.  So, now that the computer can again talk to the file system, it should be able to run the cronjob, which is set to take data at 4am every day.  Steve will check in the morning to confirm that the data is there.  (The last data that's logged is 22Dec2013, 4am, which is right around when Koji reported and then fixed the file system).

 

 

  9561   Fri Jan 17 11:44:25 2014 GabrieleSummaryLSCMore length measurements, more confusion

 I analyzed the data taken yesterday. 

The AS11 data in PRMI configuration is very bad, while the AS55 seems good enough:

results_as11.pdfresults_as55.pdf

The phase differences are 

AS11 = 21 +- 18 degrees (almost useless due to the large error)

AS55 = 11.0 +- 0.4 degrees

The AS55 phase difference is not the same measured in the last trial, but about half of it. The new length estimates are:

AS11 = 3.2 +- 2.8 cm

AS55 = 0.47 +- 0.01 cm

We can probably forget about the AS11 measurement, but the AS55 result is different from the previous estimate... Maybe this is due to the fact that Eric adjusted the PRCL offset, but then we're going in the wrong direction....

  9560   Thu Jan 16 21:38:13 2014 ericqUpdateLSCRepeat of PRC length measurement

[ericq,Jenne]

Since we don't have agreement between the measurements we made the other day and the earlier estimations, I wanted to repeat the demodulation angle measurement. We had to do a few things to keep the PRMI locked, since in the last few days, it hasn't been stable enough.

The mode cleaner had been very fussy lately; the WFS were pushing in a way that caused fast oscillations of the transmission and reflection powers. I turned off the servos, manually aligned the mode cleaner to transmission of about 15k and refl of about .4, centered the beams on the WFS QPDs, and turned the loops back on. Things were much stable after that. Also, Jenne noticed that the PMC loop had walked the laser PZT temperature to a bad place, and fixed it.

After aligning the carrier locked PRMI, the last piece needed to get things stable enough for sideband locking was turning off the angular damping on the PRM suspension screen (this was turned back on when we were done). Waiting until evening noise levels probably helped too. We used a 1000 count MICH excitation in the PRMI case, and recorded data for about a minute in one degree steps around the demodulation phase that looked to put the excitation entirely within the Q of the PD. Also, we notched out the excitation frequency in the MICH servo bank for today's measurement; I think it's outside of the loop bandwidth anyways, but it's good to be sure. 

Jenne and I pondered a bit whether changing the AS55 demodulation phase while it (AS55 Q) is being used as the MICH control signal introduces subtleties that we haven't anticipated, but couldn't come up with anything concrete. Changing the angle from the what maximizes the Q just looks like a slight change in MICH gain, and shouldn't affect the phase of the excitation signal on the PD...

In any case, the data have been recorded, and the results will follow soon. 

  9559   Thu Jan 16 08:19:29 2014 SteveUpdatePEM4.4 and 3.8M local earth quakes


It looks like there was a 4.4 magnitude earthquake near Fontana, CA around 1:30am today.  This tripped all of the suspension watchdogs, which Q has just now re-enabled. 

   Earth quake shake down yesterday Atm1

Atm2, today's shake

Attachment 1: local4.4eq.png
local4.4eq.png
Attachment 2: local3.8eq.png
local3.8eq.png
  9558   Wed Jan 15 18:42:57 2014 JenneUpdateASCPOP ASC QPD offline for a few hours this afternoon

I was in the lab, near the south end of the ITMX oplev table, looking for something, and I bumped the POP ASC QPD's power supply.  I thought that it was fine, but did not adequately check it.  When EricQ asked me just now about why the PRC is so wobbly today, I checked, and the power for the QPD wasn't properly connected (it's kind of a crappy connector, that if you nudge, contacts or loses contact).  Anyhow, I restored power to the QPD, and the PRC looks a little more stable now.  My fault for not checking more carefully, and my apologies to Q and Gabriele for their frustrations this afternoon.

  9557   Wed Jan 15 18:18:15 2014 GabrieleSummaryLSCPRC length measurement analysis

 I analyzed the data we took yesterday, both using AS11 and AS55. For each value of the phase I estimated the Q/P ratio using a demodulation code. Then I used a linear regression fit to estimate the zero crossing point.

Here are the plots of the data points with the fits:

experimental_data_as11.pdfexperimental_data_as55.pdf

The measurements a re more noisy in the PRMI configuration, as expected since we had a lot of angular motion. Also, the AS11 data is more noisy. However, the estimated phase differences between PRMI and MICH configurations are:

  • AS11 = -10.9 +- 1.0 degrees
  • AS55 = -21.1 +- 0.4 degrees

The simulation already described in slogs 9539 and 9541 provides the calibration in terms of PRC length. Here are the curves

simulation_phase_difference.pdf

The corresponding length errors are

  • AS11 = 1.44 +- 0.13 cm
  • AS55 = 0.59 +- 0.01 cm

The two results are not consistent one with the other and they are both not consistent with the previous estimate of 4 cm based on the 55MHz sideband peak splitting.

I don't know the reason for this incongruence. I checked the simulation, repeating it with Optickle and I got the same results. So I'm confident that the simulation is not completely wrong.

I also tried to understand which parameters of the IFO can affect the result. The following ones have no impact

  • Beam matching
  • ITM curvatures
  • Schnupp asymmetry
  • Distance PR-BS
  • ITM and PRM misalignments

The only parameters that could affect the curves are offsets in MICH and PRCL locking point. We should check if this is happening. A first quick look (with EricQ) seems to indicate that we indeed have an offset in PRCL. However, tonight the PRMI is not locking stably on the sidebands. 

If possibile, we will repeat the measurement later on tonight, checking first the PRCL offset.

 

  9556   Wed Jan 15 13:05:30 2014 JenneUpdatePEM4.4 EQ in Fontana, CA

It looks like there was a 4.4 magnitude earthquake near Fontana, CA around 1:30am today.  This tripped all of the suspension watchdogs, which Q has just now re-enabled. 

  9555   Tue Jan 14 19:10:51 2014 GabrieleSummaryLSCPRC length measurement

 [EricQ, Gabriele]

We could carry out the measurement of PRC length. The AS110 photodiode was plugged into REFL11. So REFL11 is giving us the AS11 signal. Here is the procedure.

  1. Lock MICH.
  2. Add a line in MICH (amplitude 20000 counts)
  3. Tune AS11 demod phase to have the line in I.
  4. Change the demod phase by steps of 1 degree around the rough optimum, taking one minute of data at each point
  5. Lock PRMI on sidebands
  6. Add a line in MICH (amplitude 500 counts)
  7. Tune AS11 demod phase to have the line in I.
  8. Change the demod phase by steps of 1 degree around the rough optimum, taking one minute of data at each point

We repeated the same measurement also using AS55, with the same procedure.

Roughly, the phase difference for AS11 was 11 degrees and for AS55 it was 23 degrees. A more detailed analysis and a calibration in terms of PRC length will follow.

  9554   Tue Jan 14 19:05:48 2014 GabrieleSummaryLSCPRMI locked on sideband

[Gabriele, EricQ] 

Finally, we managed to lock PRMI on sidebands:

  • MICH locked on AS55_Q with gain -10. Demod phase of AS55=18
  • PRCL locked on REFL55_I with gain -0.04. Demod phase of REFL55=88
  • Triggering on POP110_I at 50/10
  • Filter "1:5" of MICH engaged, this improved a lot the stability

 

  9553   Tue Jan 14 10:34:57 2014 SteveUpdatePSLgreen transmission measurment

GariLyn is using our green light on the west side of the PSL table. The green PDA36As were moved and the HEPA turned up to 60V

Attachment 1: greenPickUp.jpg
greenPickUp.jpg
  9552   Tue Jan 14 10:12:12 2014 SteveUpdatePSLlaser drift monitor set up idea

Quote:

this locationQuote:

Quote:

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

 IOO pointing is drifting in pitch. I'd like to use a QPD instead of the paper target to see if the Innolite output is stable. The idea is to move temporarily IOO-QPD_POS to  this location

 I do like to move IOO-QPD_POS temporarily to see that the feedback has anything to do with with the pointing.

Attachment 1: bad4thday.png
bad4thday.png
  9551   Mon Jan 13 19:31:04 2014 GabrieleSummaryLSCPRMI locking

[Gabriele, EricQ]

We wanted to try the PRC length measurement,but we ended up spending all the afternoon to lock the PRMI on sidebands. Here are some results

  • Lock of PRM on carrier is easy with MICH on AS55_Q and PRCL on REFL55_I. The optimal gains to avoid correction gain peaking are MICH=-5 and PRCL=0.012. The alignment today was must more stable over time than on Friday
  • We wanted to move MICH on REFL55_Q. After a few trials we discovered that REFL55_Q is not seeing any MICH signal at all. This is quite strange and we don't understand this.
  • Locking PRMI on carrier using REFL165_I and Q was difficult. We thought that was due to a RF amplifier installed in December. We tried to remove it, but since this did not help, we put it back
  • We could lock PRMI on carrier and sidebands using REFL11 signals. The optimal demodulation phase is 155. Lock on carrier was achieved with gains MICH=5, PRCL=0.7. Lock on sidebands with MICH gain=-10 and PRCL gain=-0.3. The MICH correction is very high and exciting a tone at few hundreds Hz. Maybe a violin mode of the ITMs?
  • Finally we could tune the REFL165 phase to 118.5 and lock on carrier. The lock was not very stable. Gain are: lock on carrier MICH=-0.5, PRCL=0.05. The error signal has a very big offset: to get a dark fringe we had to add a MICH offset of 500 counts. We also had to engage the CLP400 filter to avoid saturating ITMs corrections with MICH.
  9550   Mon Jan 13 16:50:55 2014 SteveUpdateVACMaglev controller needs service

Quote:

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

 The Osaka TG390MCAB maglev turbo pump's controller TC010M has passed the 40,000 hrs of operation. This triggered the " alarm" LED  warning light to come on. 

It is normal maintenance.  Maglev TP-1 is running perfectly.  Osaka will send us a loaner-controller that we can use while they do the std maintenance.

I'm thinking of ~ February to do this.

  9549   Mon Jan 13 11:08:48 2014 SteveUpdatePSL3 good days of IOO pointing

 Three good days of IOO pointing: Friday, Sat and Sun    What was changed?  May be the clamping on Friday?

IOO vertical changes recovering as tempeture. IP is clipping at plastic enclosure of ETMY

 

NOTE: ANTS at the PSL optical table.  I will mop with chemicals tomorrow if we see more.

 

Attachment 1: 3gdPSLpointing.png
3gdPSLpointing.png
  9548   Sun Jan 12 09:57:24 2014 GabrieleSummaryLSCEffect of PRC length mismatch on error signals

Quote:

 

 Its very doubtful that the MC yaw drift matters for the IFO. That's just a qualitative correlation; the numbers don't hang together.

 Then there must be something else slowly drifting. It was very clear that the good alignment of the IFO was every time lost after few minutes...

  9547   Fri Jan 10 15:33:02 2014 SteveUpdatePSLlaser drift monitor set up idea

this locationQuote:

Quote:

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

 IOO pointing is drifting in pitch. I'd like to use a QPD instead of the paper target to see if the Innolite output is stable. The idea is to move temporarily IOO-QPD_POS to  this location

Attachment 1: 2daysDrift.png
2daysDrift.png
  9546   Fri Jan 10 15:31:07 2014 ranaSummaryLSCEffect of PRC length mismatch on error signals

 

 Its very doubtful that the MC yaw drift matters for the IFO. That's just a qualitative correlation; the numbers don't hang together.

  9545   Fri Jan 10 10:28:03 2014 SteveUpdatePSLPSL pointing changes

 

I looked at IOO QPDs again. QPD_POS was clamped by one screw. Dog clamp was added on the unclamped side.

QPD_ANG chassis has no isolation to optical table..._POS has.  QPD_ANG  base was tightened also.

Both QPDs moved a little bit but I did not centered them.  The spot sizes are 2-3 mm  They should be smaller.

How ever, we still can not explane the pitch movement of the IOO beam

 

Razor beam dumps were labeled at the AP table.

 

The 40m roof was cleaned from leafs this morning.

 

 

Attachment 1: clamped.png
clamped.png
  9544   Thu Jan 9 17:58:31 2014 ericqSummaryLSCEffect of PRC length mismatch on error signals

[ericq, Gabriele, Manasa]

 We wanted to perform the PRC length measurement today with an AS11 signal, but such a signal didn't exist. So, we have temporarily connected the AS110 PD signal (which is some Thorlabs PD, and not a resonant one) into the REFL11 demod board. 

We then proceeded with the goal of locking the PRC with REFL165. A few parameters that were changed along the way as we aligned and locked things:

  • the XARM gain was increased from 0.4 to 0.5 to help it acquire lock
  • the MICH gain was decreased from -10 to -5 since there was some gain peaking in its servo output
  • the REFL165 demodulation phase was changed from 155 to 122, to place a PRCL excitation entirely within I (we did this while locked on the carrier)

Sadly, in the end, we couldn't lock the PRC on a sideband in a stable manner. The alignment would drift faster than we could optimize the alignment and gains for the PRC. I.e. we would lock the PRC on the carrier, align PRM (and maybe touch ITMX) to maximize POPDC, switch to sideband locking, try to lock, and things would start looking misaligned. Switching back to carrier locking, the beam spots on REFL (for example) would have moved.

Manasa noted the MC_TRANS_Y has been substantially drifting along with small drift in MC_TRANS_P as well. So we need to fix the source of the mode cleaner beam drifting if we want to make this measurement. 

  9543   Thu Jan 9 17:21:45 2014 ranaUpdateGeneralIFO plan, IPANG telescope

Quote:

For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I

Can you please explain this? I don't understand what exactly is the issue or 'great idea'.

I think we should be OK with just a single lens in the vacuum. But what we need is the ray tracing analysis to show what the effect will be on the IPANG readout.

  9542   Thu Jan 9 10:34:58 2014 SteveUpdatePSLPSL pointing changes in pitch

  IOO QPDs tested in dark, lighted and open PSL enclosure. The created temperature change 0.03 C has  effect on monitoring  in pitch.

 

 Atm1,  all lights off 10 min, PSL enclosure lights on  10 min, all lights off 15 min, open  door # 11 at north east corner of enclosure ( HEPA filters are running at 30V ) for 10 min, closed-dark enclosure 15 min

              dark 10, lighted 10, dark 15, open-dark 10 and closed-dark 15 minutes

 

Atm2, Pitch drift of 24 hours does not recover

Attachment 1: Lfnfdnc.png
Lfnfdnc.png
Attachment 2: 24hPSLpointing.png
24hPSLpointing.png
  9541   Wed Jan 8 19:05:30 2014 GabrieleSummaryLSCEffect of PRC length mismatch on error signals

 [Gabriele, EricQ]


Actually it is difficult to see any laser frequency line in the dark fringe signal, since the Schnupp asymmetry is small. It is much better to use a differential MICH excitation which gives a better signal at the dark port.

We repeated the simulation explained before. We can use both the AS55 or the AS11 signals, bout the first one has a limited linear range and the expected 4cm value is very close to saturation.

as11.pngas55.png

  9540   Wed Jan 8 17:53:26 2014 manasaUpdateGeneralIFO plan, IPANG telescope

For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I have put down a solution where we use a pair of lenses; one of which will be mounted in-vacuum in the ETMY chamber and the other on the endtable.
This way we will also allow have some freedom to configure the layout out-of vacuum in case the need arises. The layout will look something like in the cartoon:
IPANG_layout.png

I also made a choice of using longer focal length lenses (CVI 2" lenses f =1 m). Below is the beam path summary for IPANG telescope. I have used the waist diameter at the ITM for propagation. The endtable is roughly at 41.2m. The QPD will be placed in front of the waist (w0=47um).
IPANG.png 

  9539   Wed Jan 8 16:08:52 2014 ericqSummaryLSCEffect of PRC length mismatch on error signals

 [ericq,Gabriele]

So, we want an relatively quick measurement of the PRC length error (with sign!) at the order of .5 centimeter or so. Rana suggested the "demodulation phase method," i.e. lock the simple Michelson, measure what demodulation phase brings the 1F signal entirely within the phase quadrature, then lock the PRMI and measure the demodulation phase again. This tells you something about the length of the PRC. 

Gabriele and I worked through a simulation using MIST to determine how to actually do this. We simulated the case of injecting a line at 1kHz in the laser frequency via the laser's PZT and looking at the transfer function of the 1kHz signal to the I and Q at the 1F AS demodulated signal when locked. (Michelson locked on the dark fringe, PRC locked on 11MHz sideband) With the I and Q in hand, we can measure some demodulation phase angle that would bring everything into I. 

When the PRC length is in the ideal location, the demodulation phases in the two cases are the just about the same. Sweeping the length of the PRC around the ideal length gives us a monotonic function in the difference in the demodulation phases:

phaseVlength.pdf

So, with this simulation, we should be able to calibrate a measured difference in demod phase into the length error of the cavity! We will proceed and report...

  9538   Wed Jan 8 13:46:39 2014 JenneUpdateGeneralIFO plan, PRM baffle

Quote:

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Steve may actually be onto something with the clamps that he had made a year and a half ago.  These clamps hold the glass, and then clamp to the base of the suspension cage.  Not the table, but the base of the suspension cage. The drawings are in elog 6344.  I'm not sure that the 1/4-20 holes in the clamp things are exactly where we'll want them, but we should be able to just dog it down to the base of the suspension.  I need to check this, but it may be even easier than tieing the glass to the cage.

Also, something to think about is that the earthquake stop screws extend backwards farther than the OSEMs.  I'm not sure anymore if we have shorter 1/4-20 earthquake stops around (if we do, they should be in the cleanroom shelves), but if we can't swap those out, they'll limit how close we can get to the OSEMs. 

Here's an overhead photo from 6 Sept 2012:

PRMcage_6Sept2012.JPG

  9537   Wed Jan 8 13:01:48 2014 GabrieleSummaryLSCEffect of PRC length mismatch on error signals

I ran a simulation of a double cavity with a PRC length mismatched w.r.t. the modulation frequency. I summarized the results in the attached PDF. I think it would be important to have a cross check of the results.

In brief:

A mismatch between PRC length and modulation frequency do have an effect on error signals

Multiple zeros appear in REFL_3f/PRCL that can be removed by careful tuning of the demodulation phase (however, the shape of the signal makes difficult to understand which phase is good…)

No visible effect on REFL_1f/CARM

But a large PRCL signal appears in REFL_1f_I, which is used to control CARM. This is not good.

A mismatch of the order of 0.5 cm has a small effect.

 

 

 

 

 

Attachment 1: REFL_vs_PRClength.pdf
REFL_vs_PRClength.pdf REFL_vs_PRClength.pdf REFL_vs_PRClength.pdf REFL_vs_PRClength.pdf REFL_vs_PRClength.pdf REFL_vs_PRClength.pdf REFL_vs_PRClength.pdf REFL_vs_PRClength.pdf
  9536   Tue Jan 7 23:53:35 2014 JamieUpdateCDSdaqd can't connect to c1vac1, c1vac2

dadq is logging the following error messages to it's log related to the fact that it can't connect to c1vac1 and c1vac2:

CAC: Unable to connect because "Connection timed out"
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1vac2.martian:5064"
    Source File: ../cac.cpp line 1127
    Current Time: Tue Jan 07 2014 23:50:53.355609430
..................................................................
CAC: Unable to connect because "Connection timed out"
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1vac1.martian:5064"
    Source File: ../cac.cpp line 1127
    Current Time: Tue Jan 07 2014 23:50:53.356568469
..................................................................

 Not sure if this is related to the full /frames issue that we've been seeing.

  9535   Tue Jan 7 23:50:27 2014 jamieUpdateCDS/frames space cleared up, daqd stabilized

The wiper script is done and deleted a whole bunch of stuff to clean up some space:

controls@fb ~ 0$ /opt/rtcds/caltech/c1/target/fb/wiper.pl --delete

Tue Jan  7 23:09:21 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385927520k
/frames/trend/second 125729084k
/frames/full 12552144324k
/frames/trend/minute 2311404k
Combined 13066112332k or 12759875m or 12460Gb

/frames size 13460088620k at 97.07%
/frames above keep value of 95.00%
Frame area size is 12401156668k
/frames/full size 12552144324k keep 11781098835k
/frames/trend/second size 125729084k keep 24802313k
/frames/trend/minute size 2311404k keep 620057k
Deleting some full frames to free 771045488k
- /frames/full/10685/C-R-1068567600-16.gwf
- /frames/full/10685/C-R-1068567616-16.gwf
...
controls@fb ~ 0$ df -h /frames
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   12T  826G  94% /frames
controls@fb ~ 0$
So it cleaned up 826G of space.  It looks like the fb is stabilized for the moment.  On site folks should confirm...

 

asdfasdfsadf sadf asdf

  9534   Tue Jan 7 23:24:41 2014 JenneUpdateGeneralIFO plan, list o' things to do

It seems that the most important short-term task we have right now is to figure out what our PRC length is, and what our tolerance from nominal is.  Gabriele and EricQ are going to work on that tomorrow.  If our PRC is of a length that we can't do anything useful for full IFO locking, we need to open up and fix it sooner rather than later.

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Other, lower-priority things that we should do eventually:

* Steve, please find another razor beam dump for the WFS reflections - Rana and I used one of the ones that was there for reflection off the 2 inch lens in the MC refl path (replacing the aluminum dump that has been there for ages).  We also need to label all of our razor dumps with their purpose, with a label on top, so we remember not to remove dumps that are actually in use.

* At some point, we should change the one remaining steering mirror in the main PSL path that is aluminum, to a steel Polaris ("Polanski" or "Polish") mount.  For now, we should just make sure we have one handy.  Hopefully this will help reduce the PMC transmission drift that we see.

* Steve, in the morning sometime this week, can you please do a test of the drift of the IOO QPDs?  We'd like to see a trend that is maybe 30 or 60 minutes long of the QPD signals.  First 10 minutes, all lights in IFO room off.  Then, 10 minutes with the lights in the PSL on.  Then, the rest of the time the PSL lights off.  We want to see if these are hot enough to be causing a big temperature change in the PSL box, which may then be causing some optics to drift.

* QPD code in the simulink models (trans QPDs, but also OpLevs, and anywhere else we do normalization) needs to have anti-divide-by-zero protection.  I'll take care of this, it should be a quick copy of what we have elsewhere in the simulink code.

* Note to self for the future, instead of doing a dither alignment for the ASS for the arms, we can use the IP POS and IP ANG, as well as end transmission QPD signals.  However, for now, the ASS is working just fine.

* We want to go back to the idea of putting a lens into the in-vac IP ANG path, to avoid the clipping that Manasa and I were seeing tonight.  We want something of order 2inch diameter, 1meter focal length.  The material doesn't matter, but we do want it AR coated for 1064nm on both sides.  We also need to make sure that we could use a fixed 2 inch in-vac mirror mount, or something, to hold this lens.  If that won't work, we need to come up with another plan.  Manasa is working on thinking about precisely what lens we want to buy for a nice guoy phase telescope for IPANG, so we'll buy a lens after she puts her conclusions in the elog.

* An idea for the MC spots plot that Rana had was to plot the beam tilt and translation, rather than the raw spot positions on the mirrors.  The point of this would be to make it easier to see what the output beam from the MC looks like.  For MC pointing, we should also think about what our actual tolerances are.  The biggest thing is that we need to get through the Faraday without being too close to any edge, and also the REFL beam needs to come back through without clipping.  For now, we're just visually checking that the POP beam and the REFL beam both look unclipped since we don't have access to good camera views of either side of the Faraday.

  9533   Tue Jan 7 23:13:47 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

It actually looks like the wiper script has been running fine.  There is a log from Tuesday morning:

controls@fb ~ 0$ cat /opt/rtcds/caltech/c1/target/fb/wiper.log

Tue Jan  7 06:00:02 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385289132k
/frames/trend/second 100891124k
/frames/full 12269554048k
/frames/trend/minute 1906772k
Combined 12757641076k or 12458633m or 12166Gb

/frames size 13460088620k at 94.78%
/frames is below keep value of 95.00%
Will not delete any files
df reported usage 97.72%
controls@fb ~ 0$

So now I'm wondering if something else has been filling up the frames today.  Has anything changed today that might cause more data than usual to be written to frames?

I'm manually running the wiper script now to clear up some /frames.  Hopefully that will solve the problem temporarily.

  9532   Tue Jan 7 23:09:10 2014 manasaUpdateIOOMC aligned

Quote:

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good. 

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

 The last 4 hour trend for WFS error signals show some amount of drift. We should still look at the long term trend to solve the issue.

Attachment 1: WFSdrift.png
WFSdrift.png
  9531   Tue Jan 7 23:08:01 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

The daqd process is segfaulting and restarting itself every 30 seconds or so.  It's pretty frustrating. 

Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.  

Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem.  Jamie, please help us

The problem is not exactly the same as what's described in 7105, but the symptoms are so similar I assumed they must have a similar source.

And sure enough, /frames is completely full:

controls@fb /opt/rtcds/caltech/c1/target/fb 0$ df -h /frames/
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   13T     0 100% /frames
controls@fb /opt/rtcds/caltech/c1/target/fb 0$

So the problem in both cases was that it couldn't write out the frames.  Unfortunately daqd is apparently too stupid to give us a reasonable error message about what's going on.

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

  9530   Tue Jan 7 22:44:45 2014 JenneUpdateCDSdaqd on fb is segfaulting every ~30 seconds

The daqd process is segfaulting and restarting itself every 30 seconds or so.  It's pretty frustrating. 

Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.  

Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem.  Jamie, please help us!

Here is a screen dump from the "dtail":

Every 1.0s: dmesg | tail -50                                                                                                                         Tue Jan  7 22:43:23 2014

[   33.498691]  [<ffffffff8104a063>] kthread+0x7a/0x82
[   33.498695]  [<ffffffff81003654>] kernel_thread_helper+0x4/0x10
[   33.498698]  [<ffffffff81049fe9>] ? kthread+0x0/0x82
[   33.498701]  [<ffffffff81003650>] ? kernel_thread_helper+0x0/0x10
[   33.498703] ---[ end trace 6236defa99b3e091 ]---
[   33.498705] mx INFO: Board 0: allocated MSI IRQ 67
[   33.498713] mx INFO: CPU0: PAT = 0x7010600070106
[   33.498715] mx INFO: CPU0: new PAT = 0x1010600070106
[   33.498718] mx INFO: Board 0: Using PAT index 6
[   33.499101] eth0: no IPv6 routers present
[   33.531013] mx INFO: Board 0: device 8, rev 0, 1 ports and 2096896 bytes of SRAM available
[   33.531017] mx INFO: Board 0: Bridge is 10de:005d
[   33.531228] mx INFO: Board 0: MAC address = 00:60:dd:46:ea:ec
[   33.535971] mx INFO: Loaded mcp of len 235448
[   34.489244] mx INFO: Starting usermode mapper at /opt/mx/sbin/mx_start_mapper
[   39.148855] mx INFO: mx0: Link0 is UP
[   39.588511] mx INFO: myri0: Will use skbuf frags (4096 bytes, order=0)
[   39.589299] mx INFO: 1 Myrinet board found and initialized
[  287.706367] daqd used greatest stack depth: 3368 bytes left
[86605.907520] daqd[18407]: segfault at 38b08e4c0 ip 00007f11b3942a6c sp 00007f10b1917d50 error 4
[86605.907530] daqd[18424]: segfault at 38b544f90 ip 00007f11b3942a6c sp 00007f10b12c6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c00
0]
[86605.907544]
[86605.919454] daqd[21319] general protection ip:7f11b3942a6c sp:7f10b1814d30 error:0
[86605.919462] daqd[18442] general protection ip:7f11b3942a6c sp:7f10b0bf4d30 error:0
[86605.919615] daqd[18443]: segfault at 38aee3db0 ip 00007f11b3942a6c sp 00007f10b0b73d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919694] daqd[18412]: segfault at 38aff35d0 ip 00007f11b3942a6c sp 00007f10b1752d30 error 4
[86605.919701] daqd[18417]: segfault at 38b544f70 ip 00007f11b3942a6c sp 00007f10b154dd50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919708] daqd[18445]: segfault at 38aff35b0 ip 00007f11b3942a6c sp 00007f10b0ab1d50 error 4
[86605.919733] daqd[18429]: segfault at 38b42ae90 ip 00007f11b3942a6c sp 00007f10b10c1d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919741] daqd[18440]: segfault at 38b08e480 ip 00007f11b3942a6c sp 00007f10b0cb6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958551]  in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958557]
[86605.958577]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958586]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.959639] daqd used greatest stack depth: 3160 bytes left
[98139.100888] show_signal_msg: 13 callbacks suppressed
[98139.100895] daqd[23753]: segfault at 39c7363b0 ip 00007f5bf253ba6c sp 00007f5b69b48d30 error 4 in libc-2.10.1.so[7f5bf2507000+14c000]
[98687.815120] daqd used greatest stack depth: 2984 bytes left
[208995.594227] daqd[10386] general protection ip:7f3b7c930a6c sp:7f3a79f09d50 error:0 in libc-2.10.1.so[7f3b7c8fc000+14c000]
[353015.067479] daqd used greatest stack depth: 2880 bytes left
[367406.863618] daqd[13078]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ba2cf8 error 14 in daqd[400000+7c000]
[367406.863833] daqd[13104] general protection ip:7fb2f3018a6c sp:7fb1f01c8d30 error:0
[367406.863877] daqd[13086] general protection ip:7fb2f3018a6c sp:7fb1f089ad30 error:0
[367406.877408] daqd[13080]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ae0ca8 error 14 in daqd[400000+7c000]
[367406.877435]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.877442] daqd[13100]: segfault at 39ba287b0 ip 00007fb2f3018a6c sp 00007fb1f034cd30 error 4 in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.878372]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[399802.887523] daqd[18295] general protection ip:7fb056a71a6c sp:7faf96125f10 error:0 in libc-2.10.1.so[7fb056a3d000+14c000]
[410595.969327] daqd[22057]: segfault at 3a91f27b0 ip 00007f48e96eea6c sp 00007f47e6c26d50 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]
[410595.988926] daqd[22068]: segfault at 3a91f2790 ip 00007f48e96eea6c sp 00007f47e681bd30 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]

  9529   Tue Jan 7 21:00:02 2014 JenneUpdateIOOIP POS, IP ANG aligned

After locking the arms (after the MC alignment work), Manasa and I aligned IP POS, IP ANG, and both end transmission QPDs. 

We noticed that IP ANG is clipping in yaw as it comes onto the end table.  It looks to me like it's clipping on the edge of the plastic box's aperture, but I can't guarantee that it's not also clipping elsewhere. 

  9528   Tue Jan 7 20:57:41 2014 JenneUpdateIOOMC aligned

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good.

While we were out on the table, we also changed the anodized aluminum dump for a razor dump, to catch the reflection from the 2inch lens that is the first thing the MC refl path sees out of vac.

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

  9527   Tue Jan 7 17:16:04 2014 manasaUpdateIOOMC aligned

Quote:

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

 Aligned MC to offload the WFS

1. Turned OFF the WFS feedback servo.

2. Aligned the MC suspensions by moving the pit and yaw sliders. MC trans sum brought from ~11000 counts to ~15000 counts. MC RFPD DCMON reads 0.45 counts.

3. Turned ON the WFS servo. The WFS output now reads in the order of 0 to +/-15.

4. Measured the MC spot positions. The spot positions look like they moved for the better compared to what they were yesterday.

 

Attachment 1: MCspots.png
MCspots.png
  9526   Tue Jan 7 16:41:08 2014 manasaUpdateIOOWFS moving MC suspensions

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

The MC trend for the last 2 days shows that the MC suspensions were kicked again earlier today.  Looking back at the suspension channel INMONs along with the MC trans sum shows that the suspensions get kicked everytime MC locks and unlocks. (Attch:1)

So I checked the effect of WFS on the suspensions by disabling and enabling the WFS feedback servo (Attch:2).

Since the IMC is not at it best pointing, whenever the  MC autolocker runs and enables the WFS, the suspensions look like they are getting kicked.  But really, it's just the WFS doing their job. 

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

Attachment 1: 2dayMCtrend.png
2dayMCtrend.png
Attachment 2: WFSvsMCsuspensions.png
WFSvsMCsuspensions.png
  9525   Tue Jan 7 11:11:36 2014 ranaUpdateIOOMC drift

 

 NOT drift. The sudden steps are certainly the result of being kicked. The slow drift at the end of the day might be a slow strain relaxation.

It pays to be careful and not put too much weight or impulsive forces on the chambers or tables.

  9524   Tue Jan 7 10:44:13 2014 SteveUpdateIOOMC drift

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

 I was taking pictures at the AP table at the morning and ETMX optical table after noon. There was no activity on the IOO chamber.

 Look at the last 2 hours of  Rana's trend plot. MC1 and MC2 sensor voltage started increasing.

I think it was a drift action.

Attachment 1: 2dTrend.png
2dTrend.png
Attachment 2: driftNotKick.png
driftNotKick.png
  9523   Mon Jan 6 22:11:46 2014 JenneUpdateLSCPRCL sideband locking still not so happy

 

 The PRCL once again doesn't want to lock on sidebands for me.  I can lock on the carrier just fine (using the IFO Config settings, along with some hand-alignment of the PRM). 

However, I can't convince it to lock on sidebands.  Using the configs that I used on Dec 18th (elog 9491), I'm not getting it.  I've done the arm ASS alignment, and I've run LSCoffsets, both of which seemed to do their things appropriately. 

I'm going to attribute this today to not being in the groove yet, and I'll look at it again in the morning.

  9522   Mon Jan 6 20:52:09 2014 JenneUpdateIOOMC1/3 kicked this morning at 8:30

When I got in this morning at 9-something (9:45 maybe?), Steve was taking dust photos on the AS table, of the MC Refl path.  Other than that, I don't have any information. 

Also, Tuesday is our traditional janitor day, so I'm hesitant to put our blame there.  (I think we've kept Tuesdays, even though we're on a less-often schedule....Steve will have to correct me if I'm wrong on this).

  9521   Mon Jan 6 18:32:17 2014 RANAUpdateIOOMC1/3 kicked this morning at 8:30

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

Attachment 1: kicked.png
kicked.png
  9520   Mon Jan 6 16:32:40 2014 KojiSummaryGenerallinux1 RAID crash & recovery

Since this configuration change, the daily backup was speeded up by factor of more than two.
It was really limited by the bandwidth of the RAID array.

/cvs/cds/rtcds/caltech/c1/scripts/backup/rsync.backup.cumlog:

...
rsync.backup start: 2013-12-20-05:00:00, end: 2013-12-20-07:04:28, errcode 0
...
rsync.backup start: 2014-01-05-05:00:00, end: 2014-01-05-05:55:04, errcode 0

(The daily backup starts from 5:00)

  9519   Mon Jan 6 16:30:31 2014 JenneSummaryPSLPSL pointing monitoring

I'm not sure which pointing Rana wanted to fix today, but here's a measurement of the MC spots.  They actually look pretty good.  There is some room for improvement, but not a lot, so I'm leaving it alone for now, while I play with other things in the IFO.

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[0.63368182839757914, 1.3004245778952557, 0.33621668795755993, -1.5585578137597658, -3.1344594013487286, -1.0533063060089816]

MCspots_6Jan2014.png

  9518   Fri Jan 3 18:21:45 2014 ranaSummaryPSLPSL pointing monitoring

 

 I went to the PSL table to re-align the input pointing to the IMC. After trying to optimize the pointing into the PMC and not succeeding I also then touched the wrong mirror and messed up our IOO QPD reference pointing.

The IMC is locking again, but I'll have to fix the pointing on Monday.

ELOG V3.1.3-