Displaying reports 63221-63240 of 77240.Go to page Start 3158 3159 3160 3161 3162 3163 3164 3165 3166 End
Reports until 18:35, Friday 10 October 2014
H1 ISC
alexan.staley@LIGO.ORG - posted 18:35, Friday 10 October 2014 - last comment - 20:15, Friday 10 October 2014(14412)
Slow feedback to ETMs

(Sheila, Alexa)

Today we worked on the slow/tidal feedback to the ETMs. In doing so, we saw that the L2P for the M0 state was not very good at low frequency. Using the same method as was done for the BS (alog  14022), we found that the gain of ETMX L2P (with FM1, FM2 ON), should be changed from -1.0 to -4.0 at 0.01Hz. So far it appears that this is OK for high frequency. Meanwhile, we found that the gain of ETMY L2P (with FM1,FM2 ON) should be changed from -1 to 22 at 0.01Hz. We are not sure if this is okay at higher frequencies.

The slow/tidal feedback for both arms now works, and no longer causes a drift in the alignment. We made the following the changes to the feedback servo (this is all taken care of in the guardian already):

It appears that the DIFF PLL VCO is now in range, but maybe that's a coincidence with ground motion today....

Comments related to this report
daniel.sigg@LIGO.ORG - 19:46, Friday 10 October 2014 (14413)

One can probably bleed off the dc term (f<10mHz) by feeding back to HEPI. The path is all set up and the LSC signals are received by a HEPI ISC input filter. All that should be required is an integrator in this path.

alexan.staley@LIGO.ORG - 20:15, Friday 10 October 2014 (14414)

We were having some problems with ALS DIFF earlier tonight, so we reverted the L2P gains back to -1. It is unclear at the moment if this was related at all.

H1 AOS
edmond.merilh@LIGO.ORG - posted 16:02, Friday 10 October 2014 (14397)
Ops Daily Summary

~Two more 5.2mag aftershocks this morning on the Southern East Pacific Rise near Easter Island~ 

08:00 Morning checklist: Reset ALH; vacuum system looks ok - HAM6 cold cathode pressure reporting 10-7;  CDS/DAQ - everything looks normal.

08:30 Morning meeting

08:42 Krishna to X-End to do some BRS testing/tweaking

09:20 Krishna back from X-End

09:50 Keita to End Y to align green WFS. He will be using ETMY/ITMY/BS/PR3

10:14 Dale into the control room with a tour group

12:04 Jason to End X to align OpLev

12:30 Adjusted ISS Diffracted power to ~9.5% by reducing the refsignal voltage from -2.01 to -2.05

12:37 Jason back from End X

14:45 Sudarshan into LVEA, crawling under HAM2

12:48 Keita back into control room from End Y

12:50 Sudarshan back from crawling

H1 SEI (CDS, DetChar)
krishna.venkateswara@LIGO.ORG - posted 15:47, Friday 10 October 2014 - last comment - 16:32, Friday 10 October 2014(14408)
H1 ETMX Ground sensor correction model

J. Kissel, K. Venkatewara

Jeff K. designed a model to use the GND_Supersensor (tilt-corrected STS) to do sensor correction on Stage 1.

To get the supersensor, we take the GND_STS and add the Tilt signal from BRS converted to velocity units by multiplying g/w. To further correct for the small amount of acceleration present in BRS, we further add a factor of F * V_STS * g/w^2 where F = M * d  /  I  (M=Mass of beam-balance, d = Center of mass offset, I = Moment of Inertia)

Jim and I will try to implement and test this next week when not interefering with commissioning activity.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:32, Friday 10 October 2014 (14411)PEM
J. Kissel

A reminder to add the damping control signal monitor (currently fed into ADC0 CH 30, see D1400077, as of LHO aLOG 14351) to the h1isietmx model's channel list. In fact, it's already included and sent into a filter bank called "ETMX_SPARE" in the GND_BRS block, so let's just change it from a filter bank to an epics output (like the drift monitor) and call it "ETMX_DAMPCTRLMON." Once added to the front end, we should add it to the MEDM screen.
H1 SEI (CDS, DetChar)
krishna.venkateswara@LIGO.ORG - posted 15:45, Friday 10 October 2014 - last comment - 16:19, Friday 10 October 2014(14409)
H1 BRS calibration changed

J. Kissel, K. Venkateswara

We realized we had the wrong factor of 1/2 as described in alog entry 13448.  1/2 [V_sing / V_diff] was not needed/

The filters have been changed to account for the new calibration factor which is:

3.5e-6 [rad/pixel] * 1 [pixels/V_sing] * 1/2 [V_sing / V_diff] * 40/2^16 [V_diff/ct] * 1e9 [nrad/rad] =  2.1362 [nrad/ct]

 

Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:19, Friday 10 October 2014 (14410)PEM
J. Kissel, K. Venkateswara,

Krishna copied, pasted, and posted too fast and still included my erroneous single-ended to differential conversion in the piece-by-piece equation, even though the answer quoted is correct. 
The calculation to achieve the correct calibration is
3.5e-6 [rad/pixel] * 1 [pixels/V_sing] * 40/2^16 [V_diff/ct] * 1e9 [nrad/rad] =  2.1362 [nrad/ct]

Also, I've committed the updated filter file to the userapps repo.

Also, also, we need to
(a) Add the reference mirror filter bank and damping motor control signal* to the MEDM screen
(b) Capture a new safe.snap with the reference mirror calibration filter turned ON as it is now.

*The damping motor control signal isn't yet present in the user model, it's only available as a raw IOP test point. We should add this to the h1isietmx user model when we're making the front-end code modifications to create the tilt-free ground super sensor. I'll post this as a comment to the other suggested model changes so we don't forget.
LHO General
edmond.merilh@LIGO.ORG - posted 15:03, Friday 10 October 2014 (14407)
Adjustment of ISS Diffracted Power

At ~12:34PT I adjusted the diffracted power in the ISS to ~9.5% as instructed by Rick Savage. The refsignal is currently set to -2.05V.

H1 SUS (AOS, DetChar, ISC, SYS)
jeffrey.kissel@LIGO.ORG - posted 14:18, Friday 10 October 2014 (14405)
Refinement of ETM Alignment offset slider calibration
J. Kissel

I've arrived at numbers for refining the calibration of the ETM OPTICALIGN alignment offset sliders, using the same method as was used for the ITMs and BS (see LHO aLOGs 14265 and 14321, respectively). The new slider gains should be 
EX P =  15.344 [ct/urad]
   Y =  44.044 [ct/urad]
EY P =  19.341 [ct/urad]
   Y =  51.013 [ct/urad]
which are comparable to the ITMs' calibration, as expected.

I have not installed these new gains, nor have I corrected the saved alignment offsets since it will be too disruptive to commissioning. These can be installed at anyone's convenience, but I'll install them in week if know one's gotten around to it. 
The to-do list:
- Record current OPTICALIGN OUT values (in [ct]), to confirm you get the same answer after updates
- Install above calibration gains
- Restore to ALIGNED via guardian, enter in predicted offset values (in [urad]) below (adjust, if necessary, to get the previously recorded output value in [ct])
- Save ALIGNED value using pull-down menu in IFO_ALIGN MEDM screen
- Restore to MISALIGNED via guardian, enter in predicted offset values (in [urad]) below (adjust, if necessary, to get the previously recorded output value in [ct])
- Save MISALIGNED value using pull-down menu in IFO_ALIGN MEDM screen
- svn commit the updated aligned and misaligned .snap files in the ${userapps}/release/sus/h1/burtfiles/ directory
- IF AMBITIOUS (and commissioning team gives you some time) -- perform refinement of optical lever calibration with these new values, as was done with the ITMs and BS (see LHO aLOGs 14312 and 14387).

Details
-----------
The current alignment offset slider calibrations for both EX and EY are
23.219 [ct/"urad"]
51.689 [ct/"urad"]
and currect stored alignment offsets are
                  P       Y    ["urad"]
EX Aligned     274.1    63.9
   Misaligned  240.0   102.0

EY Aligned      83.4   -64.8
   Misaligned   62.0   -7.72

The ETM alignment slider values to hit the center of the ITM baffle PDs are
         P     Y     ["urad"]
EX PD1 261.4  79.75
   PD4 285.2  49.1
delta  23.8   30.65  
claimed displacement = 2*delta
       47.6   61.3

EY PD1  70.5   -83.5
   PD4 100.5   -48.0
delta   30.0    35.5  
claimed displacement = 2*delta
        60.0    71.0
where the factor of two to calculate the displacement is from the single-bounce, optical lever effect.

We know from D1200313 and D1200296 the ITMX and ITMY (respectively) PDs 1 and 4 are 11.329 [inches] = 0.287757 [m] apart vertically, and 11.313 [inches] = 0.28735 [m] horizontally on both ITM baffles, implying an angular displacement -- over the L = 3994.5 [m] arm lengths -- of
P   0.287757 [m] / 3994.5 [m] = 72.03 [urad]
Y   0.28735 [m]  / 3994.5 [m] = 71.94 [urad]

which means the correction factor for the OPTICALIGN gain is
EX P  47.6  ["urad"] / 72.03 [urad] = 0.661 ["urad"/urad]
EX Y  61.3  ["urad"] / 71.94 [urad] = 0.852
EY P  60.0  ["urad"] / 72.03 [urad] = 0.833
EY Y  71.0  ["urad"] / 71.94 [urad] = 0.987
or

EX P = 1.5132 [urad/"urad"]               
EX Y = 1.1736             
EY P =  1.2005
EY Y = 1.0132

which are corrections comparable to the ITMs (good sanity check, since they have the same actuation chain, and used the same offset calibrations prior to the refinement).
So the new alignment slider calibation gains should be
       Old Cal               Correction            New Cal
EX P 23.219 [ct/"urad"] * 0.661 ["urad"/urad] =  15.344 [ct/urad]
   Y 51.689 [ct/"urad"] * 0.852 ["urad"/urad] =  44.044 [ct/urad]
EY P 23.219 [ct/"urad"] * 0.833 ["urad"/urad] =  19.341 [ct/urad]
   Y 51.689 [ct/"urad"] * 0.987 ["urad"/urad] =  51.013 [ct/urad]
and the predicted alignment offsets that need be installed are
    old offsets ["urad"] * correction factor [urad / "urad"] = new offsets [urad]

                 P       Y    [urad]
EX Aligned     414.77    74.993
   Misaligned  363.17    119.71

EY Aligned      100.12  -65.655
   Misaligned   -77.792   -7.822 
   
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 10:10, Friday 10 October 2014 (14402)
a strange lock loss understood

Keita, Sheila, Kiwamu,

Keita pointed out yesterday that there was a strange lock loss event of the DRMI in which the guardian seemed to have switched the state to a unlocked state even though the  PRC and SRC build-up were still sufficiently high. This is now understood and fixed.

We found out that this was due to our bad coding in the guardian. The "WFS_CENTERING" state had a unwated command (I don't exactly know what part was it) which brings the state to "DOWN" immediately. So every time when we requested the "WFS_CENTERING", it then shut down the lock. Sheila edited the code and now it does not show a funny lock loss any more.

The attached is time series from a second example of the funny lock loss. You can see that PRCL cut its input at t = 1.2 sec even though POP_RF18 and AS_RF90 were high. This was actually initiated by our request for the guardian to go to "WFS_CENTERING". Then it immediately transitioned to a wrong state DOWN, which shuts all the LSC control loops. Of course, this resulted in lock loss.

Images attached to this report
H1 SEI (CDS, DetChar)
krishna.venkateswara@LIGO.ORG - posted 10:09, Friday 10 October 2014 (14403)
H1 BRS damper working correctly and DriftMonitor

K. Venkateswara

I did another test to make sure the BRS damping works as expected. The attached pdf shows the results of the test. I disturbed the BRS by walking in its vicinity at t=200 seconds and the amplitude gets rung up. The turn-table starts damping it and it switches off after ~1000s.

DriftMonitor:

The channel H1:ISI-GND_BRS_DRIFTMON monitors the position of the beam-balance mirror pattern on the CCD camera. It was scaled to go roughly from +/-16k counts. But it looks like on the positive side it happens a bit earlier than that, roughly 14.5k counts. The second attachment (DriftMonOlder.png) shows the DriftMon output from August-September. It looks like it had already hit the edge on Sept. 4th. The code still works if the pattern goes over the edge but it can appear noisy if there is a partial pattern, so ideally we want to keep it in the working range.

The current DriftMon position is shown in the third file (DriftMonCurrent.png) after I completed the damper installation. It seems to be trending logarithmically towards -10k which is a bit lower than ideal but still in range. Adjustment of the position are not trivial and there are large drifts after each adjustment which are not always easy to predict, so adjustments should be avoided unless necessary. I will monitor it over time and if needed make further adjustments.

Images attached to this report
Non-image files attached to this report
X1 DTS (CDS)
james.batch@LIGO.ORG - posted 09:14, Friday 10 October 2014 (14401)
Modified user environment setup to include new CAL subsystem
The setup script for the userapps directory has been modified to add paths for the new calibration subsystem, cal.  The environment variables USERAPPS_LIB_PATH, USERAPPS_MEDM_PATH, and USERAPPS_SCRIPTS_PATH have been modified, and environment variables CAL_SRC and CAL_IFO_SRC have been added.

This change is effective for new logins or new shells.
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 09:12, Friday 10 October 2014 (14400)
CDS model and DAQ restart report, Thursday 9th October 2014

model restarts logged for Thu 09/Oct/2014
2014_10_09 08:51 h1fw1
2014_10_09 10:23 h1fw1
2014_10_09 13:12 h1fw1
2014_10_09 21:41 h1fw0

all unexpected restarts

LHO General
edmond.merilh@LIGO.ORG - posted 09:10, Friday 10 October 2014 (14398)
Morning meeting summary

In attendance: Sudarshan, Bubba, Vern. Keita Jason, Patrick, Krishna, Jeff, Hugh, Jim, Kissel, Gerardo, Fil, Aaron, Christina, Dick, Travis & Greg.

SEI- Nothing new to report. Going to wait and see what happens when the waves created by yesterday's 6.8 quake start hitting the west coast

SUS- Working on OpLev slider calibration

PSL- working on ISS outer loop

BRS- seems to be working. Maybe test/tweak one more time

Commish- Robust locking DRMI. ASC helping greatly.

3IFO- ongoing

Facilities- beam tube cleaning is ongoing

BSC2 Test Stand was shut down on Wed the 8th!

H1 CDS
james.batch@LIGO.ORG - posted 08:59, Friday 10 October 2014 (14399)
Modified user environment setup to include new CAL subsystem
The setup script for the userapps directory has been modified to add paths for the new calibration subsystem, cal.  The environment variables USERAPPS_LIB_PATH, USERAPPS_MEDM_PATH, and USERAPPS_SCRIPTS_PATH have been modified, and environment variables CAL_SRC and CAL_IFO_SRC have been added.

This change is effective for new logins or new shells.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 01:57, Friday 10 October 2014 (14394)
DRMI better

Kiwamu, Sheila

DRMI ASC helps stability

We have REFL A 9I going to PRM with a gain of 1e-3 in yaw, 1e-4 in pitch, and AS A 45 Q to the BS with a gain of -5e-5 in pitch and 1e-3 in yaw.   We looked at using REFL 45 I to feedback to the SRM, but the refl B signals have a large offset, and the refl A signals don't seem sensitve to motion of the SRM. We checked the phasing of the rel 45 wfs, (it was already good) and set the dark offsets, but this didn't help.  The four loops that we do have are working well, in the attached screen shot the loops come on at about -30 seconds, and bring us to a good build up.  After this, DRMI is stable and we have none of the mode hopping problems that have been plauging us,and preventing us from locking most of the day today.  Since taking that screen shot I've edited the guardian to bring the ASC on faster, because sometimes we loose the lock due to mode hopping problems before the asc comes on.  The slowest part is the AS WFS centering servo.  These asc loops are all in the gaurdian, as well as offloading, but the user has to decide when they have done their job and manually request offloading for now.

Stable 3F DRMI

After getting the drmi stable, on 1F, we moved it to 3F to confirm that it is stable after the improvements Kiwamu made last night.  That was easy, the gaurdian did it right away without any problems.  It was locked on 3F and left alone for a half hour with no disturbance, from 5:21:25 Sept 10 UTC to 5:51:07.  This is in the middle of almost 2 hours of locked DRMI.
 

DRMI+ALS

After this we attempted to lock DRMI with the arms controlled by ALS.  We had some sucess locking ALS without the ezca servo, (and slow feedback from the end station PDH).  but the slow feedback needs some work (it misalings the arms).  Kiwmau decreased the ALS DIFF gain from 0.8 to 0.5, (already in the gaurdian) which helps prevent saturations, and lets diff lock stably.  We were able to lock both COMM +DIFF+ find the IR resonances, offset the COMM VCO by 500 Hz (which is only 250 Hz in IR) and align PRM and SRM.  We couldn't engage the ASC like this.  We locked DRMI serveral times like this, but it quickly drops because of the mode hopping problem. 

Images attached to this report
H1 SEI (DetChar, VE)
jeffrey.kissel@LIGO.ORG - posted 17:15, Thursday 09 October 2014 - last comment - 09:14, Tuesday 14 October 2014(14391)
H1ISIETMY L4C Pod Pressure Alarm -- Nothing to be Concerned About
J. Kissel

I happened to have the H1 ISI ETMY overview screen open and noticed a blinking red light in the bottom corner alarming that the pod pressures are low, indicative of a potential leak. Jim informed me that Gerardo had noticed this earlier as well (both interactions verbal, no aLOG). Further investigations reveal that, though the sensors indicate a slow leak over the past 5 months on all three L4Cs; the leak rate is ~0.25e-6 [torr-Liter/sec] (see attached 2014-10-09_H1ISIETMY_L4CPod_LeakRate.pdf) -- a rate that is 1/4th of what has been deemed acceptable (see T0900192). Indeed, for further comfort -- though Brian's original guess (see G1000561, pg 15) says that the pod pressure sensors might only be able to sense 5e-6 [torr.Liter/sec] - level leaks -- it appears that we are indeed at least a factor of 8 more sensitive than that. 

Though I don't understand it well enough to make adjustments, the action item is to 
(a) adjust the threshold to represent 1e-6 [torr.Liter/sec] (if we're still OK with that number). and 
(b) have @DetChar or @Operators make a similar study on the rest of the chambers across the project to ensure that the rest of the pods aren't leaking any worse than these L4Cs.

Note that this ETMY is the second oldest ISI (save the LASTI ISI) in the project, as it was installed just after ITMY for the H2 OAT.

Details / Logical Path / Figures
--------------------------------------
On the MEDM pod-pressure screen (accessible in the bottom right corner of the overview), Corner 1 L4C and Corner 2 and 3 T240 are blinking around 96-97, 100-101, and 100-100 [kPa] respectively, which directly correspond to the blinking alarm light. So, I trended them over the past 300 days. I quickly found that the signals have been non-flat, and in fact going down in pressure, indicative that the in-air pods were leaking air out to the in-vacuum chamber. I focused on the L4Cs, because they appeared to be the worst offender. After identifying that the major features in the 300-day minute trend time series: 
-- We begin to see data ~1/4 of the way into the time series, right when Hugh and Richard are cabling up the ISI ETMY, now moved into BSC10 on Feb 25 2014 (see 10360),
-- The hump that starts at ~1/3 of the time axis is the beginning of the chamber closeout, where kyle turns on the roughing pumps on March 28 (see LHO aLOG 11076), and 
-- Shark-fin feature 3/4 through the time axis which corresponds to Rai's charge dissipation experiments on Aug 06 (see LHO aLOG LHO aLOG 13274,
I believe that the sensors are indicating a real pressure signal, and not some electronics drift as Brian had worried in G1000561. Interestingly, the *differential* pressure does not show a trend, implying that all six L4C pods are leaking at roughly the same rate.

To quantify the leak rate, I grabbed the average of one hour of minute-trend data on the first of every month over the linear ramp down the of the pressure for all three L4C pods (i.e. from May 01 2014 to Oct 01 2014):

                Pod 1  Pod 2  Pod 3
pressure_kPa = [97.423 98.956 98.86;...   % May
                97.358 98.910 98.771;...  % Jun
                97.288 98.820 98.710;...  % Jul
                97.199 98.734 98.573;...  % Aug
                97.110 98.665 98.526;...  % Sep
                97.026 98.568 98.369];    % Oct
(At this point, I'm just *hoping* the pressure sensors are correctly calibrated, but we know that 1 [atm] = ~750 [torr] = ~ 100 [kPa], so it seems legit.)

Taking the matrix of 6 months by 3 pods, I converted to torr,
torr_per_kPa = 7.5;  % [torr/kPa]
pressure_torr = pressure_kPa * torr_per_kPa; % [torr]
and assuming the volume enclosed in the pod is volume_L4C = 0.9 [Liter], as Brian assumed in G1000561, and taking time = 1 [month] = 2.62974e6 [sec], the leak rate over each month is
leakRate(iMonth,iPod) = (pressure_torr(iMonth,iPod) - pressure_torr(iMonth+1,iPod))*volume_L4C/time;
(manipulating the P1* V - L* T = P2 * V equation on pg 15 of G1000561). I attach the .m file to make the calculation, if the above isn't clear enough to write your own.
It's a rather noisy calculation from month-to-month that could be refined, but it gets the message across -- the leak rate is roughly 0.25e-6 [torr.Liter/sec], a factor of 4 smaller than deemed acceptable. If one puts on your trusty pair of astronomy goggles, you could argue that the leak rate is increasing, but I would refine the quantification of the leaks before I made such claims.

Finally, I checked the GS13s and T240s to make sure they're leaking less, and indeed they are.

I also post a copy of the simulink bit logic that creates the warning bit -- it's gunna take me some time to verify it all -- but the goal will be to change the "ABS REF", "DEV REF", and "DEV REL" such that we don't alarm unnecessarily, as we've done here. 
Images attached to this report
Non-image files attached to this report
Comments related to this report
rainer.weiss@LIGO.ORG - 19:45, Thursday 09 October 2014 (14393)SEI, VE
One can check if there are really leaks in the pods by looking at amu20 and amu22 on an RGA mounted on the
chamber with the suspect pods. The pods are filled with neon. The peaks should be in the ratio of the
isotopic abundance of the two neon isotopes.
michael.zucker@LIGO.ORG - 03:17, Friday 10 October 2014 (14395)
Quoting T0900192, 

"We conclude that any leak is unacceptable from a contamination viewpoint..."

This should be followed up.
john.worden@LIGO.ORG - 04:47, Friday 10 October 2014 (14396)

I am skeptical.

We have many conflats and feedthrus installed on LIGO and the failure rate is extremely low once the initial leak test is passed.

I think it is more likely that there is an aging effect here with the sensors or possibly some gettering action of air in the pod (we do not know how much air remained in the pod when the neon was filled). The aging could be mechanical fatigue or permeation of gas into the "zero" side of the capactive sensor.

The kp125 sensors are "low cost" capacitive barometric sensors and a typical use would be in an automobile engine intake manifold. Long term drift of the sensor due to aging would not be a factor in this application because the manifold is routinely exposed to one atmosphere prior to startup - allowing for a calibration.

Depending on the air content in the pods a chemical reaction (slow oxidation??) could also be responsible for this drift. The L4C is the smallest unit and would therefore show the largest loss of gas if this were the case.(smaller reservoir)

 

Quote from the vendor spec sheet:

 "Because the KP125 is a high-precision IC for cost-critical solutions, the chip is packaged in a “green” 
low-cost SMD housing. The sensor is developed for measurement of barometric air pressure (BAP).
High accuracy and high sensitivity enable the deployment of this device in automotive applications as well as in 
consumer applications."
 
 
 
An RGA spectra can be taken but I believe the RGA has not yet been mounted on the chambers. The temporary unit at HAM3 was removed and was used for the Beam Tube accumulations.
 
Do we have long term data of a POD that has not been installed into the vacuum system but has been powered? 
fabrice.matichard@LIGO.ORG - 09:14, Tuesday 14 October 2014 (14436)

The table attached shows the pressure and "apparent leak rates" of the L4C pods for all BSC-ISI.   For the calulations, I used a short period of data from the first data of each month. Results for ETMY are consistent with Jeff's numbers.

Results/Comments:

- Unlike ETMY, other units don't show a consitent trend. The pressure signal seems to go up and down, rather than consitently down.

- The sign and amplitude of the apparent leak rate is always very similar within the three pods of a given chamber.

 

 

Images attached to this comment
H1 SEI
hugh.radkins@LIGO.ORG - posted 11:08, Thursday 09 October 2014 - last comment - 12:55, Friday 10 October 2014(14383)
WHAM4 ISI Stage0 L4C2CART (Senscorr) Matrix corrected

re my 14373 entry, I figured I could correct these to the T1000388 even though there is a "Check the signs" Note in the doc as Fabrice says we'll just change the signs in the sym filters.

The matrix had correct elements in the primary transformations; only some of the cross coupling elements were variant.  I went ahead and ran the populate matrices medm script.  It crashed as it tried to load CPSALIGN values which are not in the data file.  Makes me wonder how the GS13 & CART2ACT values got loaded before...  So, I moved the CPSALIGN load section to the end and ran the script again.  I then confirmed all the matrices complied with the T1000388--all good.  Then confirmed the ISI still isolated--yes.

Then with the ISI just damped and HEPI not isolating( no Pos loops,) I drove HEPI in Z with a random noise signal band passed between .1 and 1 hz.  Monitoring the HEPI L4Cs and the ISI Stage0 L4Cs, see attached, it appears that the vertical sensors are out of phase.  So it seems we need that sign change in the SYM filters.

Made and committed safe.snap file.

Commissioners wanted the machine back before I could do other dof measurements, maybe I can do them with passive TFs.  Either way, later.

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 12:55, Friday 10 October 2014 (14404)

Here is some horizontal data.  I drove HEPI RZ but since the ISI L4Cs go to the Sensor Correction bank, it only has X Y & Z.  So, here I look at the L4CINFs, the tangentially oriented sensors should be seeing this RZ.  Compared to the vertical data above, I drove 4x as hard to get the coherence higher(still kinda poor.)  It may not say the same thing, but, based on the phase, the signs are the same.  Of course now this is before the input filters (I should have grabbed the _OUTs but too late for this run) much less the L4C2CART matrix so I'm really mixing apples and applesauce.

Images attached to this comment
H1 AOS (DetChar)
sheila.dwyer@LIGO.ORG - posted 10:25, Thursday 09 October 2014 - last comment - 09:07, Friday 14 November 2014(14381)
etmx oplev glitches

Jason, Sheila

There have been some glitches on the ETMX oplev, which don't seem to correspond to motion of the optic, the attached screen shot shows an example.  I think that I have seen glitches like this that were much larger in amplitude, but am not sure. 

One question for detchar is if they have a tool that can search for glitches like these, and give us some information about how often they are happening, how large they are, and maybe monitor to see if they are happening on other op levs

Another issue is that sometimes the lasers fail, which is often foretold by a several seconds oscillation in the oplev sum.  Can detchar set up some kind of monitoring for that?

Of course the real question is how can we fix it......

Images attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 14:40, Friday 10 October 2014 (14406)DetChar

Hi Jason and Sheila, here at LLO  Olmo Cerri, a summer student from UMISS, looked at the possible causes of glitches in OPLEVs. He worked with Suresh. Suresh earlier found that the the temperature variation could cause changes in the cavities of OPLEV laser and thereby changing the laser intensity which would look like glitches. Olmo looked at week long strecthes of data from a few OPELVs and charactersized how many glicthes we see (he wrote a matlab script to find the such gltiches).  They also implemetned a simple temperature stabilization method (LLO a-log) to reduce the gltiches. It seemed to work well. Here is a presentation by  Olmo on this work which shows data before and after the temperature stabilization setup. He is now looking into implemneting an online version of the code.

cody.arceneaux@LIGO.ORG - 09:07, Friday 14 November 2014 (15053)
I set Olmo's code to run on a cron job with the results here:

https://ldas-jobs.ligo-wa.caltech.edu/~codyca/MHoF_results/

We still need to put together a better way to present the results.  The code is set to remove glitches caused by human interaction by looking at the OPTICALIGN offsets.  Also, the results for LLO can be found here:

https://ldas-jobs.ligo-la.caltech.edu/~codyca/MHoF_results/
Displaying reports 63221-63240 of 77240.Go to page Start 3158 3159 3160 3161 3162 3163 3164 3165 3166 End