Displaying reports 56601-56620 of 84566.Go to page Start 2827 2828 2829 2830 2831 2832 2833 2834 2835 End
Reports until 17:22, Friday 29 July 2016
H1 DAQ
jonathan.hanks@LIGO.ORG - posted 17:22, Friday 29 July 2016 (28749)
Timings on h1fw2
In looking at frame writer stability issues I installed a daqd build on h1fw2 that would report some timing information on the main producer thread.  This is the thread that reads the data in the data concentrator and checksums it and queues it up for the frame writing threads.

The four points I am measuring are:
full - a full cycle (should be under 1/16s)
recv - time to receive a 1/16s block of data
crc - time to checksum the data
xfer - time to move the data into the frame writing buffers

These numbers are do not include the time taken to output the timing samples to the log (so the full cycle time was really a bit longer).

Here is a particularly bad sample, time is in seconds:
 full min:0.030165 mean:0.0694159 max:0.371219
 recv min:0.00241995 mean:0.0398388 max:0.338558
 crc  min:0.0151799 mean:0.0171485 max:0.020812
 xfer min:0.0118489 mean:0.0124278 max:0.0145991

And another that was more typical

 full min:0.0603912 mean:0.0624495 max:0.0659258
 recv min:0.0284889 mean:0.0316754 max:0.0346711
 crc  min:0.0155029 mean:0.0183311 max:0.021708
 xfer min:0.012187 mean:0.012442 max:0.0149119

When a cycle on the producer thread goes over 1/16s we get retransmission requests on the network.  I had to stop running this build of daqd due to it triggering a large number of retransmission requests.

During a recent meeting at LLO to discuss daqd Keith had informed us that the producer thread is doing to much and it needs to be split into separate threads.  The timing test I ran today supports this.  I am working on code now to split the producer thread into two halves.

* reminder h1fw2 only writes to local disk and is being used to test fw changes under a production data load.
H1 ISC (CAL, ISC, SUS)
evan.goetz@LIGO.ORG - posted 16:29, Friday 29 July 2016 - last comment - 14:23, Sunday 31 July 2016(28746)
New L2-L3 crossover filters

Evan G., Jeff K., Evan H.

Summary:
We have updated the L2-L3 crossover filters to reduce the effect of the L2 actuation on the superactuator at frequencies above the L2-L3 crossover. In addition we have turned off the vStopB filter in the L2 drivealign bank. The old filters remain in the filter bank, but are turned off in case we need to revert. The SDF has been updated to reflect these changes.

Details:
The old lowpass [ :30], and highpass [0:30] filters were allowing too much interaction of the L2 stage on the frequencies above the crossover. We needed more aggresive rolloff of the L2 stage. A new design was used to develop prototype lowpass and highpass filters that were then normalized to produce complementary filters. The trick was to add some additional filtering in addition to the single pole or single-zero/pole design.

The Matlab zpk prototype lowpass is:

    29.804 (s^2 + 792s + 4.077e06)
  ----------------------------------
  (s+94.25) (s^2 + 1192s + 1.304e06)

and the prototype highpass is:

  0.68377 s (s+0.4816) (s+40.81)
  -------------------------------
  (s+125.7) (s^2 + 35.75s + 1174)

The resulting complementary filters are the lowpass:

      43.587 (s+125.7) (s^2 + 35.75s + 1174) (s^2 + 792s + 4.077e06)
  ----------------------------------------------------------------------
  (s^2 + 27.96s + 1124) (s^2 + 256s + 1.986e04) (s^2 + 1087s + 1.175e06)

and the complementary highpass:

        s (s+94.25) (s+40.81) (s+0.4816) (s^2 + 1192s + 1.304e06)
  ----------------------------------------------------------------------
  (s^2 + 27.96s + 1124) (s^2 + 256s + 1.986e04) (s^2 + 1087s + 1.175e06)

Putting this into Foton yields the lowpass design:

zpk([63.027+i*315.14;63.027-i*315.14;2.8446+i*4.6522;2.8446-i*4.6522;20], [20.375+i*9.3751;20.375-i*9.3751;2.2252+i*4.8498;2.2252-i*4.8498;86.475+i*149.24; 86.475-i*149.24],1,"n")

and the highpass design (properly normalized to 1 at high frequency):

zpk([94.821+i*155.07;94.821-i*155.07;0;0.076645;6.4948;15], [20.375+i*9.3751;20.375-i*9.3751;2.2252+i*4.8498;2.2252-i*4.8498;86.475+i*149.24; 86.475-i*149.24],1,"n")gain(0.000578996)

These are installed in the L2 and L3 drivealign banks as L2L3LP and L2L3HP, respectively.

We have compared the old and new design and the effect on the DARM actuation and DARM open loop gain and closed loop suppression, and we are satisfied with the improved filter design. Attached is a series of figures to illustrate the new design (see the plots.pdf file)

Figure 1: actuation plant transfer function (left plots) and the PUM/TST ratio (right plots)
Figure 2: current state of the distribution filters (before any modification)
Figure 3: current state of the actuation authority (before any modification) -- note the black curve has ripples in the 100-900 Hz band
Figure 4: new crossover filter design -- prototype and final design
Figure 5: new distribution filter design from Matlab continuous filters -- note that we turn off the vStopB filter module in the L2 drivealign bank
Figure 6: new actuation authority from the Matlab filters -- note the improvement in the black curve with much less ripple than before
Figure 7: using new design, L2 and L3 actuation transfer functions: drive at input to L3 lock bank and look at L3 response for both L2 and L3 paths and taking the sum
Figure 8: using new design, the ratio of the two single curves in figure 7 -- note the transfer function is unity at 23.3 Hz and with a phase margin of 67 degrees
Figure 9: new distribution filter design as implemented in Foton -- note that these are the same as the Matlab design
Figure 10: new actuation authority from the Foton filters -- again, same as before
Figure 11: compare the DARM open loop gain and closed loop suppression from the current state (old) and using the new filter design and also when there is no SRC detuning -- note there was a lingering 400 Hz notch filter in the ER9 run that shouldn't have been there (Evan H to make sure this is off) and this model takes into account the increase of the digital DARM gain to 1400. The blue curves have little ripple above 100 Hz, and the phase margin is actually a little larger than before, about 48 degrees. The gain peaking is roughly the same as before ~4 dB.
Figure 12: A final acutation authority plot showing the new total is much improved over the old total, especially in the range of 100-900 Hz (see zoom on right hand plots).

For the record, also attached are screen shots of the L2/L3 drivealign filter banks before and after the changes as well as a screenshot of the SDF.

Images attached to this report
Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 14:23, Sunday 31 July 2016 (28760)

I adjusted FM1 in DARM1 (2 Hz / 8 Hz boost) so that we no longer have gain loss around 10 Hz. Since we already lose gain from the antispring, this boost was not helping us in terms of loop stability.

We lose about 12 dB of gain at 2 Hz with this change.

Images attached to this comment
H1 General
cheryl.vorvick@LIGO.ORG - posted 16:11, Friday 29 July 2016 - last comment - 09:24, Monday 01 August 2016(28744)
Ops Day Summary:

State of H1: earthquake, unlocked, ISC_LOCK set to Down, IMC_LOCK set to Offline

Activities:

Since EQ:

Comments related to this report
cheryl.vorvick@LIGO.ORG - 16:18, Friday 29 July 2016 (28745)

SEI_CONF guardian is set to EARTH_QUAKE

Hugh and I opened the Blends MEDM and changed the SEI_CONF.

Should be returned to WINDY_NO_BRSY when locking resumes.

MEDM attached

Images attached to this comment
thomas.shaffer@LIGO.ORG - 09:24, Monday 01 August 2016 (28771)

Be very careful here! Even though the SEI_CONF says that it is in the correct state, it also has 10 notifications saying that 10 of its suborrdinate nodes are in ERROR. So it actually never got to its EARTHQUAKE state fully. If Guardian nodes are ever in error, someone who knows how,  needs to fix them. In this particular case it is a bug that I will post an alog about soon.

H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:47, Friday 29 July 2016 (28743)
Turn on Cleanrooms at HAM-6
   Powered up the three smaller cleanrooms this morning around HAM6. This afternoon (15:15) powered up the big cleanroom over HAM6. 

   These cleanrooms need to run over the weekend to be ready for next weeks vent. If there is commissioning work over the weekend that need the cleanrooms off, feel free to power them down. Please power them back up when finished.  

   For the small cleanrooms, simply unplug them.
   For the big cleanroom over HAM6, pull the wooden handled wire that is attached to the switch located on top of the SW corner of the cleanroom to shut it down. (see photos) To turn it back on, use a large ladder to reach the switch, and push it into the up position. 

   Note: the light in the big cleanroom is switch off.    

  

 
Images attached to this report
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 15:15, Friday 29 July 2016 (28742)
PSL water manifold flow sensor post mortem
Attached are photos of the power meter flow sensor that was in the water manifold, and of one
that was in "good" condition.  Clearly one can see a partial blockage where the water goes.
This certainly explains the observed reduced flow and increased pressure.

    Not sure about the sudden drop outs.  It might be that part of the blockage had a piece
that acted as some kind of flap that stopped the flow enough at a certain point, relaxed when
the chiller stopped and dislodged when the water flow started again.  We will see when we try
cleaning the flow sensor out.



JeffB/Jason/Gerardo/Peter
Images attached to this report
H1 SEI (PEM, SEI)
david.mcmanus@LIGO.ORG - posted 15:05, Friday 29 July 2016 (28741)
L4C noise issue

David McManus, Jenne Driggers, Conor Mow-Lowry

This is a late post for work that was done during the week after the 4th of July.

While the L4Cs were being huddled next to the STS-2, I used the mccs2 script to do a coherent subtraction of the signal from each L4C to estimate the noise floor. I plotted this against the L4C design sensor noise for comparison (taken from SEI_sensor_noise.m). We found that the noise floor estimate was still roughly an order of magnitude above the sensor noise floor. We determined that because the signal from our L4Cs is currently quite weak, we are not limited by sensor noise currently and instead are limited by some form of electronics noise (probably ADC noise). We are looking to implement some additional amplification in the L4C electronics prior to the ADC so that our SNR is improved to the sensor noise level.

Images attached to this report
H1 AOS
cheryl.vorvick@LIGO.ORG - posted 14:47, Friday 29 July 2016 (28740)
Ops afternoon update: 7.6 earthquake in the Pacific
Magnitude M 7.6
Region PAGAN REG., N. MARIANA ISLANDS
Date time 2016-07-29 21:18:23.1 UTC

It announced it's arrival by tripping ITM ISIs at 21:31:18UTC.

Signal is strong in our seismic channels 0.03-1Hz.

Signal is also strong in our useismic channels 0.1-0.3Hz.

At 21:40:02UTC all ISIs and some optics watchdogs tripped.

As of 21:43:33UTC:

optics that have not tripped: PRM, MC2, MC3, ITMX, ETMX, TMSX, ITMY, ETMY, TMSY, SRM, SR3, RMs, and OMs

optics that have tripped: MC1, IM1, IM2, IM3, IM4, PR2, PR3, BS, SR2

LHO VE
kyle.ryan@LIGO.ORG - posted 14:43, Friday 29 July 2016 (28738)
1435 hrs. local -> Shut down CS vent/purge air supply (Kobelco)
Prior to shutting down, I observed the compressor auto-drains functioning via squeezing the drain hoses and feeling drain pulses during loaded and unloaded states.  I also witnessed the drying towers switching.  Temperatures and pressures observed in normal ranges for loaded and unloaded states. 

Will restart on Monday for Tuesday's HAM6 vent

H1 SUS (ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 13:49, Friday 29 July 2016 (28736)
All HAM6 SUS Reference Transfer Functions Gathered Prior to HAM6 Vent
J. Kissel

In prep for next week's HAM6 vent, I've gathered driven transfer functions of all DOFs of the H1SUSOMC, H1SUSOM1, H1SUSOM2, and H1SUSOM3. As expected, they look identical to what Stuart measured prior to the last time we vented HAM6 (see LHO aLOG 17653). Note, all alignment and ISC control was OFF, so I did not see any of the problems with OM1 that Stuart mentions (and I only learned about those troubles after re-reading Stuart's entry -- too late now to investigate further). Note the models were never tuned and/or fit to measured data for these suspension types, so it's not surprising that resonances don't particularly match up with model.

We'll gather more some quick data in-air before the doors come off next week, and then again right after the doors go on (especially given that we'll have replaced the OMC breadboard). We'll compare against this data set once we're pumped back down.

Data templates have been committed to in:
/ligo/svncommon/SusSVN/sus/trunk/OMCS/H1/OMC/SAGM1/Data/
2016-07-29_1554_H1SUSOMC_WhiteNoise_L_0p2to50Hz.xml
2016-07-29_1554_H1SUSOMC_WhiteNoise_P_0p2to50Hz.xml
2016-07-29_1554_H1SUSOMC_WhiteNoise_R_0p2to50Hz.xml
2016-07-29_1554_H1SUSOMC_WhiteNoise_T_0p2to50Hz.xml
2016-07-29_1554_H1SUSOMC_WhiteNoise_V_0p2to50Hz.xml
2016-07-29_1554_H1SUSOMC_WhiteNoise_Y_0p2to50Hz.xml

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM1/SAGM1/Data/
2016-07-29_1611_H1SUSOM1_M1_WhiteNoise_L_0p2to50Hz.xml
2016-07-29_1611_H1SUSOM1_M1_WhiteNoise_P_0p2to50Hz.xml
2016-07-29_1611_H1SUSOM1_M1_WhiteNoise_Y_0p2to50Hz.xml

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM2/SAGM1/Data/
2016-07-29_1640_H1SUSOM2_M1_WhiteNoise_L_0p2to50Hz.xml
2016-07-29_1640_H1SUSOM2_M1_WhiteNoise_P_0p2to50Hz.xml
2016-07-29_1640_H1SUSOM2_M1_WhiteNoise_Y_0p2to50Hz.xml

/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/OM3/SAGM1/Data/
2016-07-29_1642_H1SUSOM3_M1_WhiteNoise_L_0p2to50Hz.xml
2016-07-29_1642_H1SUSOM3_M1_WhiteNoise_P_0p2to50Hz.xml
2016-07-29_1642_H1SUSOM3_M1_WhiteNoise_Y_0p2to50Hz.xml
These data were exported in the same location under similar names. 

I was delighted to find that all of the matlab analysis software still works like a charm [thanks Stuart & Arnaud!], specifically, 
/ligo/svncommon/SusSVN/sus/trunk/HTTS/Common/MatlabTools/
plotHTTS_dtttfs_M1.m
plotallhtts_tfs_M1.m

/ligo/svncommon/SusSVN/sus/trunk/OMCS/Common/MatlabTools/
plotOMCS_dtttfs.m
plotallomcs_tfs.m

I'd updated the plotall*.m scripts first to receive all of the measurements Stuart has taken recently of his SUS before adding my new measurements (No I didn't. I forgot, and had to reconcile after). The latest version of those scripts have been committed accordingly.
Non-image files attached to this report
H1 ISC
jenne.driggers@LIGO.ORG - posted 13:38, Friday 29 July 2016 - last comment - 08:07, Wednesday 17 August 2016(28737)
OMC alignment turned off

The OMC alignment servos keep turning on, even though the OMC guardian is paused.  I found that it gets turned on in engage_wfs_centering whenever we do any ASC since it's in a generate states function.  So, I have commented out that line, but we must uncomment it when we have the OMC back and are ready to use it again.  It is currently line 113 in ISC_GEN_STATES.

Comments related to this report
hugh.radkins@LIGO.ORG - 08:47, Monday 01 August 2016 (28768)

Maybe this should have a work permit to make sure this isn't forgotten; or at least some mechanism to undo the change in a timely manner.

corey.gray@LIGO.ORG - 08:07, Wednesday 17 August 2016 (29145)

Not sure when it happened, but looks like this has been restored to normal & uncommented (probably some time after the HAM6 work last week).

Making a note in Operator Sticky Notes wiki.

H1 General (OpsInfo)
cheryl.vorvick@LIGO.ORG - posted 12:16, Friday 29 July 2016 (28735)
Ops Mid-Day Update:

State of H1:  vent prep, parasitic down-time work, camera crew is here

Details:

Currently:

H1 General
edmond.merilh@LIGO.ORG - posted 11:03, Friday 29 July 2016 - last comment - 14:44, Friday 29 July 2016(28729)
DBB Scans FAMIS# 6583

File extensions - .001= 35W path .002=200W

RPN - 35W; no changes worth mentioning.

          200W; noise is higher in the 300Hz-2k range.

FRQ - 35W; seems to hav a higher degree of error correction. Resonances that aren't noticible in recent past scans appear starting at ~7Hz/20Hz and seem to have harmonics out to ~100Hz

         200W; These same resonances mentioned above seem present in this path as well. Last weeks scan by comparison show these resonances propogating out as far as 200Hz

PNT - 35W; This looks much better than last weeks which had 2x and 2y higher than the rest by a factor of two from 1Hz-30Hz.

         200W; This weeks scan looks almost identical to last weeks scan with the outliers being 2x and 2y all the way out to 2K

MSC - 35W; HOM ct/ mode matching looks pretty good with the exception of TEM10 mode which is a bit higher than reference. Significantly better looking scan than last week.

         200W; Mode matching looks a  little sloppy. No change from last week.

Non-image files attached to this report
Comments related to this report
jason.oberling@LIGO.ORG - 14:44, Friday 29 July 2016 (28739)

Should also add that the out-of-loop PD in the ISS in iss_rpn-001.pdf (PDB in this case, the blue trace) is seeing roughly an order of magnitude more noise than the reference.  This is the 3rd time the ISS scan has been run since we resurrected the DBB after the HPO turn on, and the other scans match this one.  What is odd is is not a RPN noise increase of this magnitude in either the FE or HPO RPN scans.  Unknown at this time where the noise is coming from.

H1 SEI
nutsinee.kijbunchoo@LIGO.ORG - posted 10:04, Friday 29 July 2016 - last comment - 11:24, Friday 29 July 2016(28727)
H1 ISI CPS Noise Spectra Check - Weekly

Note that there are people in the LVEA during this measurement.

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 11:24, Friday 29 July 2016 (28731)

It is not HUGE, but the ETMY V2 and ITMX H3, have higher levels than in previous measurements.

H1 General
cheryl.vorvick@LIGO.ORG - posted 08:51, Friday 29 July 2016 - last comment - 11:29, Friday 29 July 2016(28724)
Morning Meeting: OMC is down, plans being made for venting next week

OMC / Vent plans

 

- OMC is down, we're venting HAM6 and going in next week

 

- Spare OMC needs some attention before it can be installed - may not be ready by Tuesday

 

- we may go into HAM6 on Monday to diagnose the situation

 

- HAM6 is locked down

 

- cleanrooms around HAM6 being turned on today and will be on all weekend

 

Tasks:

 

- CDS - Richard - taking advantage of down time to 

 

- EY - Kyle wants to bake RGA installed on BSC6, not valved in, next week

- EX - Kyle wants to bake RGA installed on BSC6, not valved in, next week

 

- PSL - Peter and Jason next Monday and Tuesday - have PSL for alignment and calibrations

 

- Rich Abbott is here and has a film crew here for today and tomorrow (related to chip manufacturer)

--- in LVEA up to 10AM

 

- JeffK - getting transfer functions of HAM6 optics for reference

 

- EY BRS is off - see morning update and Jim's alog from last night

 

- Hugh - HAM6 guardian is off and needs to stay off - screenshot of HAM6 HEPI and HAM6 ISI attached

Comments related to this report
hugh.radkins@LIGO.ORG - 11:29, Friday 29 July 2016 (28732)

Regarding the HAM6 Guardian.  The HAM6 SEI chamber manager is paused so it will not try to isolate HEPI.  HEPI will not isolate and should be kept READY.  The ISI is fine and should be kept isolated by responding to trips at the watchdog as usual.  Be sure to use the ISI Guardian and not the HAM6 SEI chamber manager if guardian attention is needed.

LHO VE
kyle.ryan@LIGO.ORG - posted 19:07, Thursday 28 July 2016 - last comment - 12:11, Friday 29 July 2016(28719)
Pressure bump at Y-end
The pressure change seen in the attached is typical of the Y-arm gauges with PT410 responding first followed by subsequent responses in time as it propagates toward the CS.  Looks like a real change and occurs 15 mins or so after a seismic system change was made at the Y-end (Jim W?) or not.  IP9 has not changed voltage -> Will monitor from home.
Non-image files attached to this report
Comments related to this report
chandra.romel@LIGO.ORG - 11:20, Friday 29 July 2016 (28730)
Y2-8 IP is not pumping. Controller doesn't power past 350 V and 430 mA. Gerardo & Chandra reseated cable at both ends and rebooted controller. Next Gerardo & Richard will test HV cable. The controller initially read back an error code 02. Gerardo contacted Gamma for troubleshooting and waiting to hear back (their online screens are currently not available).
chandra.romel@LIGO.ORG - 12:11, Friday 29 July 2016 (28734)
UPDATE:  bad HV cable
H1 ISC
evan.hall@LIGO.ORG - posted 12:01, Thursday 28 July 2016 - last comment - 11:48, Friday 29 July 2016(28702)
Locking with different macroscopic SRC lengths

Hugh, Evan

Over the course of several locks, we moved the HAM4 HEPI in the y direction by several hundred microns in order to see the interferometer behavior at 2 W with the SRC locked on different fringes.

For a 1.1 mm shift in the HEPI position (i.e., a 2.2 mm shift in the one-way SRC length), there is no discernible trend in the rf sideband buildups or in the DARM pole frequency.

We would like to repeat this test with SR2 offsets as well.

Images attached to this report
Non-image files attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 11:48, Friday 29 July 2016 (28733)

Craig C, Rana

We've been looking at the Gouy phase in the LHO SRC to understand the mode hopping, matching, etc.

The attached PDF shows something like the diagonal elements of the Jacobian: the change in the round trip Gouy phase as a function of each of 4 distances and 4 Radii of Curvature. The goal for the RT Gouy was 38 deg assuming a 50 km thermal lens.

 

In the plots the zero position on the x-axis is the nominal position of each optic according to (E1400205) the IAS as-built numbers OR the RoC according to the specs/measurements in optics database (galaxy.ligo.caltech.edu/optics).

The first page of the PDF shows the situation in the nominal warm state (ITM thermal lens with 50 km focal length). The second page is with no thermal lens. I have ignored the curvature of the CP as well as the cold lens in the ITM due to index inhomogeneity; assuming for now that these effects are small.

As you can see by flipping between pages 1 & 2, the ITM thermal lens stabilizes the SRC by increasing the round trip phase shift by ~15 deg.

 

So, is the LHO mode hopping problem due to a 0.05% RoC increase of SR3? Or is the LLO SRC more stable because it has a short RoC?

Is it possible that the alignment trouble with the LHO SRC can be mitigated by increasing the Gouy phase shift? If so, perhaps we could determine this by translating the HAM4/5 HEPI as well as pushing on the M1 stages of the SUS. If it goes in the right direction, perhaps we can make a bigger correction using the screws on HAM4 and get more like a 1 cm motion of the SR3-SR2 length without venting the main volume.

 

Uncertainties:

  • The placement of the SR2 and the SR3 has a small uncertainty in the x & z axes, but the y-direction (the important one for the SRC) has an uncertainty of +/- 1.5 mm since the measurement method is different.
  • The RoC uncertainty on the SR3 is ~15 mm or dRoC/Roc ~ 0.05%. This corresponds to a Gouy phase deficit of  ~15 deg.
  • The RoC uncertainty of the SR2 is the next most important parameter, but even a 0.1% error (standard off-the-shelf tolerance) would not be so bad.
  • We are very insensitive to the distance between the ITM and SR3, as well as the SR2-SRM distance.
  • Similarly, there is no conceivable distortion of the SRM temporary mirror which could destabilize the SRC.
Non-image files attached to this comment
H1 ISC
stefan.ballmer@LIGO.ORG - posted 16:16, Monday 25 July 2016 - last comment - 17:06, Friday 29 July 2016(28627)
Script for moving the beam spot on PRM only

Following the same idea as elog 28442, here is a script for moving the beam spot position on PRM (prmspotmove.py).

It monitors IM3 slides, and moves IM4, PRM and PR2 sliders in such a way the the beam spot positions on PR2 and PR3 don't change.

The script was tuned in INPUT_ALIGN (for IM4 and PR2 matrix elements) and PRM_ALIGN (for PRM matrix elements).

 

Matrix  elements (in rad /rad IM3)

pitIM3toPR2=+0.0022;
yawIM3toPR2=+0.0055;
pitIM3toIM4=-1.3;
yawIM3toIM4=+0.92;
pitIM3toPRM=-0.009;
yawIM3toPRM=+0.031;
 

Also attached is the python script used for finding the matrix element, getMx.py.

Non-image files attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 17:06, Friday 29 July 2016 (28747)

Here is the theoretical matrix for this move (note that signs will vary for pitch and yaw):

    IM4/IM3=-1.022385686091801*tim3;

    PR2/IM3=0.069871106113604*tim3;

    PRM/IM3=-0.350788523435222*tim3;

 

This was calculated with the following data (in meters):

RPRM=-11;

RPR2=-4.555;

RPR3=36.0;

RITM=1939;

LPRM=16.6128;

LPR2=16.1551;

LPR3=24.88797;

LARM=3994.5;

LIM4=0.413;

LIM3=1.17;

n=1.45;

f=-RITM/(n-1);  # thin lens approximation

fm=-RPRM/(n-1); # thin lens approximation

 

 

 

 

H1 ISC
stefan.ballmer@LIGO.ORG - posted 17:09, Friday 15 July 2016 - last comment - 17:08, Friday 29 July 2016(28442)
Recycling gain does not depend on PR2 spot position

Kiwamu, Stefan

Using the pr2spotmove script (see alog 28420), we moved the spot on PR2 in lock by almost 1 milimeter.

Conclusions:

- The carrier recycling gain desn't care about the PR2 spot positon.
- The POP beam from PR2 to the invacuum POP diode is fairly close to the edge of the visibility aperture. This might be an issue for LSC aux noise.

Details:

- To be able to explore the full range of motion, we had to switch back to the REFL B WFS for PRC2 / PR3 control. We BTW verified that this WFS also works at 40W (and during the power increase).
- With that, the move-limiting aperture is the path from PR2 to POP. We can move until the POP_A loses the beam. The pitch and yaw min/nominal/max values for PR3 alignment angles are
    Pitch value / delta:
     min: -302.95  / -4.6urad
     nom: -298.35 / 0urad
     max: -275.35 /  +23urad
    Yaw value / delta:
     min: 257.45 / -16urad
     nom: 273.45 / 0urad
     max: 281.45 / +8urad
  Notice how close to the edge we are in pitch - this could be a factor for PRCL/SRCL/MICH auxiliary length noise and scatter coupling. We have to revisit this in low-noise.

- The 27.6urad move in pitch (24urad in yaw) peak-to-peak move corresponds to 0.9mm (0.8 mm) for the PR2 spot position. Note though that for the beam in transmission of PR2 that corresponds to several spot sizes of motion. (The virtual beam waist behind PR2 is 114u, i.e. we moved the spot more than 7 beam waists. As a result the beam completly left the POPAIR camera view.)


 


 

Non-image files attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 17:08, Friday 29 July 2016 (28748)

Here is the theoretical matrix for this move (note that signs will vary for pitch and yaw):

    PR2/PR3=-9.041812537326308*t3;

    PRM/PR3=1.824484077268346*t3;

    IM4/PR3=0.964764706304192*t3;

 

This was calculated with the following data (in meters):

RPRM=-11;

RPR2=-4.555;

RPR3=36.0;

RITM=1939;

LPRM=16.6128;

LPR2=16.1551;

LPR3=24.88797;

LARM=3994.5;

LIM4=0.413;

LIM3=1.17;

n=1.45;

f=-RITM/(n-1);  # thin lens approximation

fm=-RPRM/(n-1); # thin lens approximation

 

 

 

Displaying reports 56601-56620 of 84566.Go to page Start 2827 2828 2829 2830 2831 2832 2833 2834 2835 End