Displaying reports 66461-66480 of 83266.Go to page Start 3320 3321 3322 3323 3324 3325 3326 3327 3328 End
Reports until 03:15, Saturday 14 March 2015
H1 ISC
daniel.hoak@LIGO.ORG - posted 03:15, Saturday 14 March 2015 (17268)
OMC locking fully automated

In our many locks and relocks tonight we have worked out the bugs in the OMC guardian's locking sequence.  This process has succeeded several times now and is integrated with the overall ISC_LOCK guardian.

The steps taken by the guardian are the following:

The whole thing takes about two minutes.  There are ways to make it faster (Stefan suggested locking on a sideband earlier in the acquisition process and jumping to the carrier later on) and more robust (applying some more intelligent peak-finding will be necessary once we go to higher power), but for the near future this seems like a good, hands-free solution.

There's one failure mode which is likely to be encountered not infrequently: if the ETM roll mode is run up (or other modes, but that one is the most problematic) then the DCPDs will saturate and the OMC won't lock.  In this case the guardian will fail to read READY_FOR_HANDOFF and the ISC_LOCK guardian will not transition to DC readout.  If this happens you can damp the mode and then rerun the OMC guardian to get to low noise.

Images attached to this report
Non-image files attached to this report
H1 ISC (ISC, SUS)
daniel.hoak@LIGO.ORG - posted 23:24, Friday 13 March 2015 (17264)
scattering from OMC SUS motion

Robert, Dan

On some locks we've noticed very loud scattering noise, sometimes extending out to >100Hz, implying an impressive fringe velocity of tens of microns per second.  Robert pointed out to me yesterday that the OSEMs of the OMC suspension saw high amplitude motion around the time of these glitches.  The OMC SUS motion seemed to be in the vertical direction, and we guessed that the OMC ASC pitch feedback to the OMC SUS was coupling to the vertical motion of the suspension.  And, from there, some scattering path length was changing very rapidly.

Recently the OMC has been aligned using the QPD loops, which are relatively high gain (ugfs around 1Hz).  These loops drive the OMC SUS fairly hard.  Coupling to the other SUS DOFs has been a concern.

Today on our first low-noise lock we immediately noticed the scattering noise between 40 and 200Hz.  We reduced the OMC ASC gain and the noise disappeared.

The scattering noise is highly correlated with the velocity of the OMC SUS in the vertical and longitudinal directions.  In the plots attached, the top panel is a spectrogram of the whitened calibrated DARM channel.  Scattering arches are seen at 60Hz and up to 220Hz.  The bottom panel is the absolute value of the time-derivative of the OMC SUS motion, either vertical (first two plots) or longitudinal (second two plots).  The units are in velocity although I haven't gotten the calibration to make sense, and anyways we would need to calculate the motion of the bottom stage.  (These plots are reminiscient of similar work by Bas Swinkels a few years ago.)

The second plot or each pair shows 100 seconds of data, as I turned down the gain on the OMC ASC loops and the suspension was driven more and more gently.  As the velocity drops, so do the scattering glitches in DARM.

For now we'll run in a low-gain state for the OMC ASC.  After talking with Jeff, one solution might be coil balancing of the OMC SUS to decouple pitch actuation from the vertical mode.  Also, we might try some vertical and longitudinal  compensation in the OMC ASC actuation itself.  Or, we can chuck it all and use only the tip-tilts.

Non-image files attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 22:37, Friday 13 March 2015 (17257)
Easier alingment part 2

Sheila, Stefan, Chris

H1 CAL (CAL, ISC)
jeffrey.kissel@LIGO.ORG - posted 20:37, Friday 13 March 2015 (17262)
H1 CAL CS Changed to include a GAMMA Switch
J. Kissel

After we got back to low-noise RF spectrum, we noticed our wall template displaying H1:CAL-DELTAL_EXTERNAL_DQ was not showing anything. We quickly realized that the recently implemented but still uncommissioned optical gain correction factor, GAMMA was dividing the sensing term in the calibration process by 0.0. This has been happening since Tuesday (LHO aLOG 17179), but we haven't noticed because we haven't put any low-noise points on the board. After the first low-noise lock broke, I quickly added a switch to the CAL-CS library part that passes a 1.0 into the sensing normalization of the switch is OFF. 

Of course, this required a model recompile, reinstall, restart, and a DAQ restart because I added one EPICs channel. Apologies for bypassing the work permit process, and rebooting front end models on a Friday evening, but I figured having a well-calibrated DARM spectrum during low-noise operation was more important.

We're now back in low-noise, and all is well calibrated again. 

We'll commission the optical gain compensation soon...

I've committed the updated CAL_CS_MASTER.mdl library part to the userapps repo.
Images attached to this report
H1 General (DetChar)
ryan.fisher@LIGO.ORG - posted 19:40, Friday 13 March 2015 - last comment - 09:25, Saturday 14 March 2015(17260)
ODC MEDM Screens Created and Settings Drafted for LSC, ASC and OMC
TJ Massinger, Ryan F.,

We created new MEDM screens for the new ASC and OMC ODC channels, and updated the screen for LSC.  These are in their appropriate common/medm/ directories.  The LSC_ODC.adl has not been committed to the SVN because the local directory is in a strange state.  Pictures attached!

We also took a first pass through setting all of the EPICs records for the LSC and ASC ODC channels.  These settings have been captured in the safe.snap files for the two models and committed to the SVN.
Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 09:25, Saturday 14 March 2015 (17270)

I remind everyone that white is a forbidden color for MEDM screens, since that's the color they turn when they have lost contact with the server.

H1 GRD (SUS)
jameson.rollins@LIGO.ORG - posted 17:43, Friday 13 March 2015 - last comment - 14:06, Saturday 14 March 2015(17259)
SUS automation overhaul: improved alignment handling, normalized output enabling; SUS guardians updated

The SUS guardians has been revamped

This was done in order to fix a couple of outstanding usability issues with the SUS guardians, and to make things generally easier to deal with.  Here are the key changes:

complete overhaul of alignment procedure

This is a fairly substantial change to procedure, but it has a couple of important benefits:

This gives an effective "one button" misalign/align.  We also no longer need to worry about saving alignments.  w00t!

no more ALIGN_TO_PD* states

Sheila declared that the ALIGN_TO_PD1 and ALIGN_TO_PD4 states are no longer needed with the new changes.

alignment offset ramps are now reset to default values after offsets are (dis)engaged

guardian no longer touches filter gains

In general, guardian now touches less stuff.  This is important because it reduces the cross section with the ISC automation that occaissionally needs to adjust the LOCK filter module gains.  It also increases what can be monitored by the new SDF system.

INIT improvements to better determine SUS state on intialization

This will help get the suspensions to the correct state quicker on guardian restarts, with less disturbance.

new procedure to fully enable SUS

In the SAFE state, the SUS is in the following state:

The full "enable" and alignment procedure is as follows:

Here's the new graph:

The DAMPED state now has just the DAMP outputs engaged, so just the damping loops are on.  The FULLY_ENABLED state has the remaining control outputs engaged.  The ALIGNED and MISALIGNED states have the OPTICALIGN and TEST P/Y OFFSETs enabled.

Current status

All SUS guardians were updated such that the TEST_P and TEST_Y filter modules have the same GAIN calibrations that are in the OPTICALIGN banks.  The OFFSETS in the TEST_{P,Y} modules were set such that they corresponded to the last stored "misaligned" values in the alignment snapshots.

All SUS guardian nodes were then restarted.  They all came up without issue.

Important notes

OPTICALIGN OFFSET is no longer the full story of the SUS alignment

This is probably the biggest gotcha.  We need to update the IFO_ALIGN screen to give an indication that the MISALIGNMENT (TEST) OFFSETs are enabled.  There is also no indicator on the SUS_*_OVERVIEW screens that the suspension is in a misaligned state.  Guardian should be considered the main authority for SUS alignment state now.

ALIGNMENT OFFSETS are no longer stored in files, nor are they stored in the safe.snaps

This means that after a front end reboot the stored alignment and misalignment OFFSETS will be lost.  However, they can be easily restored from the BURT snapshots.

I will put together a script that will allow us to easily restore an alignment offset to any point in past, including possibly the last alignment before a reboot.

OPTICALIGN calibrations should be set in the TEST_{P,Y}_GAINs

This is to ensure the same calibrations for the OPTICALIGN and TEST OFFSETs.  These don't usually change, so it shouldn't be an issue, but when they do need to be changed, they will need to be updated in two places

Configuration

The new code is in two new files:

The new SUS2.py holds all the new guardian logic, and the new sustools2.py is a slightly cleaned-up, guardian-ified and improved version of sustools.  SUS2.py imports sustools2.py.  The old SUS.py was renamed to SUS1.py.  Reverting to the old configuration is a simple matter of repointing the new SUS.py symlink to the old SUS1.py module.

TODO

The plan is still to overhaul the OPTICALIGN parts such that they handle all of this in one place, without needing to use these TEST modules.  This will make things even cleaner.  We will also integrate the new Sigg integrators so that we can have glitch-less offloading of integrated DC values from the ASC loops to the OPTICALIGN biases.

So, things to do:

Images attached to this report
Non-image files attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 20:45, Friday 13 March 2015 (17263)
😁
evan.hall@LIGO.ORG - 14:06, Saturday 14 March 2015 (17271)ISC
  • The OFFSET in the top-stage TEST_P/Y filter banks will be used to store relative misalignment values, which will be engaged (with a ramp) to misalign the optic.

I suppose this means that the ditherAlign script we use to align the TMSs needs to be somehow modified, since I think it currently overwrites these offsets in order to point the TMS to the ITM baffle PDs.

H1 General
travis.sadecki@LIGO.ORG - posted 16:00, Friday 13 March 2015 (17251)
OPS Shift Summary

Times in PST

08:33 Bubba to CER changing filters

08:37 Peter to H2 PSL enclosure

10:22 Corey to squeezer bay, Kyle checking vacuum gauges in LVEA

10:35 Kyle out of LVEA

11:05 Doug to Mid X

11:12 Corey out

11:41 Peter out

12:35 Corey to LVEA for a cable

12:40 Corey out

13:57 Peter and Ed to H2 PSL enclosure

15:31 Peter and Ed out

15:45 Kyle in LVEA shutting off pumps

15:52 Kyle out

LHO VE
kyle.ryan@LIGO.ORG - posted 15:53, Friday 13 March 2015 (17258)
Shut down HAM1/HAM2 annulus pumping for the weekend -> will finish next week


			
			
H1 SEI
jim.warner@LIGO.ORG - posted 14:54, Friday 13 March 2015 (17256)
Some more changes to BSC blend filters

Short version: we think CPS's are limiting st2 performance above 10hz. We have modfication ready to try that we think will be quick and painless to try that can be easily backed out.

 

So after sorting out configuration issues with the end stations, Jeff and I (mostly Jeff) have come up with a small modification to try on the St2 BSC 250mhz blends. We noticed on my BSC performance plots from the the other day that turning on the St2 loops reduced the St2 performance at high frequency. We think this is because the CPS isn't rolled off fast enough in the blend filter, so we messed around with a couple ideas in foton, see attachment. The current blend is shown in red The first idea was a simple pole a 5hz, blue on the plot. This rolled the CPS off quickly, but lost phase around the blend frequency. Next we tried a couple pairs of poles at 10zh, which improved things some, losing less phase at <1hz, but introduced some gain peaking at 10hz (green and brown traces). Finally we used a low-q elliptical filter and it was just right. Or less bad. The combined fitler is shown in cyan(?), the ellipse only is shown in black.

In foton the zpk of the ellipse is : zpk([17.782+i*26.674;17.782-i*26.674],[5.148+i*9.424;5.148-i*9.424],1,"n"). The filter isn't loaded yet, it's not  being used, but first thing Monday morning, I hope install and test it for each dof on st2.

Images attached to this report
LHO VE
bubba.gateley@LIGO.ORG - posted 14:25, Friday 13 March 2015 (17254)
Beam Tube Washing
Scott L. Ed P. Chris S.

The cleaning results for the past week are posted here. The crew was able to clean to the single door between X-1-5 and X-1-6 double doors. The crevice cleaning remains to be completed in this section. The crew only worked a half day today because of dentist and other appointments.
Continuous monitoring of beam tube pressures by the control room operator during cleaning operations. 
Non-image files attached to this report
H1 CDS
james.batch@LIGO.ORG - posted 13:48, Friday 13 March 2015 (17253)
The gnuradio package has been installed on Ubuntu workstations
The gnuradio package has been installed on Ubuntu control room workstations to support the cdsutils waterfall plotter.
H1 AOS
stefan.ballmer@LIGO.ORG - posted 11:03, Friday 13 March 2015 (17250)
ASC work
Chris, Stefan

Tonight we did a full alignment starting with the Green WFS and we tested the interplay of Green WFS to ETM during DRMI lock acquisition. The Green WFS loop as expected dues a great job at keeping the green arm power from drifting, even when the tidal is on. 

However we were hampered with a new issue: a growing oscillation in the IM4 loop that eventually broke the lock. Not sure why it is that different tonight. There are a couple of lock losses on record that can be looked at tomorrow.

H1 CDS
james.batch@LIGO.ORG - posted 10:52, Friday 13 March 2015 (17249)
Terminator package installed on Ubuntu workstations
The terminator package has been installed on the Ubuntu workstations, including opslogin. This package is particularly useful if you are logging in remotely using X forwarding, as it presents a terminal window that can be split vertically and horizontally multiple times, with a new shell in each window.  Execute "terminator" at the command line, use the right mouse button to split the display.
X1 DTS
james.batch@LIGO.ORG - posted 10:49, Friday 13 March 2015 (17248)
Terminator package installed on x1work
The terminator terminal package has been installed on x1work.  This would be particularly useful when logging in remotely (with X forwarding), as you can enter the command "terminator" and you'll get a terminal window that can be split vertically and horizontally multiple times (using the right mouse button), giving you a new terminal window each time.
H1 SEI
hugh.radkins@LIGO.ORG - posted 10:36, Friday 13 March 2015 (17247)
LHO SEI SDF all Clear--Red Means Something

With JeffK's adjustment of the HEPI ITMX last night and this morning's update, all the LHO SEI SDFs are zero'd.

After Jeff's HEPI ITMX change yesterday, all that remained was the changes (corrections) to the ETM ISI ST2 Z & RZ Blends that Jim did yesterday.  I updated the SDF & committed all files to the SVN this morning.

H1 PSL
peter.king@LIGO.ORG - posted 16:52, Thursday 12 March 2015 - last comment - 14:44, Friday 13 March 2015(17235)
LLO Pre-modecleaner
We inspected the input windows of the pre-modecleaner tank.

The window in line with the main output beam shows signs of drag wiping.
The window in line with the PZT shows signs of damage and some general
damage from dust (see attached image).

In order to get a better view of the cavity mirrors, we need to pull
the pre-modecleaner out of its tank.  At the moment it's stuck in the
tank after being compressed for over 3 years.



Ed, Peter
Images attached to this report
Comments related to this report
peter.king@LIGO.ORG - 02:37, Friday 13 March 2015 (17245)
I was reminded that at some stage the input windows of the pre-modecleaner
were removed and later re-installed, either for use or for shipping.  So
the window with the photographed damage was most likely the "output" window.
matthew.heintze@LIGO.ORG - 14:44, Friday 13 March 2015 (17255)

For further notes. 

I am 99% certain that the PMC currently being worked on is the LLO "spare". This is the one that degraded quite rapidly and only lasted in the system ~1 month.

 

The windows were taken off the original PMC and put in the same locations on the spare when it was installed. So window positions as they are on the PMC currently should be where they have been the entire time they have been used. 

 

Here is a reference to an alog about cleaning of the windows of the PMC previously 

H1 SUS
betsy.weaver@LIGO.ORG - posted 15:53, Thursday 12 March 2015 - last comment - 13:40, Friday 13 March 2015(17229)
ETMy SDF cleanup leads to ETMy ESD cleanup

Due to all of the latest commissioning of ETMY, the SDF had accumulated 40+ differences.  With Jeff's help we remedied numerous line items via making the ETMy ESD banks look like the ETMx ones.  This cleared out Kiwamu's settings leftover from earlier measurements.  I've also moved the ESD calibration filters from the 4 ETMY L3 ESD OUTPUT banks to the L3 LOCKING BIAS bank to bring it in line with the ETMx settings.  I've edited the burt ETMy safe.snap to capture some of the other commissioning work.  THere are now only 20 SDF diffs which I will continue to track down.

Comments related to this report
betsy.weaver@LIGO.ORG - 15:54, Thursday 12 March 2015 (17230)

Screen snapshots before ETMy cleanup:

Images attached to this comment
betsy.weaver@LIGO.ORG - 15:55, Thursday 12 March 2015 (17231)

ETMy screen snapshots now:

Images attached to this comment
jeffrey.kissel@LIGO.ORG - 18:11, Thursday 12 March 2015 (17238)
To specify what Betsy means when she says "This cleared out Kiwamu's settings leftover from earlier measurements," we cleared out the EFF_CHARGE values in ESD linearization block, and changed the FORCE COEFFICIENT to match ETMX, at -124518.4 (see LHO aLOG 16798 and 16843). 

This force coefficient is -124518.4 [ct] (i.e. raw DAC counts, NOT LOCK drive counts), representative of the bias voltage of 9.5 [V] (referenced to [V] output from the DAC, NOT on the ESD), or an bias voltage on the ESD of 380 [V]. As the commissioning vanguard prefers DAC voltage, we've entered 9.5 "[V]" into the LOCK_INBIAS, and calibrated FM1 accordingly. This is exactly how EX is configured, as Betsy says.
kiwamu.izumi@LIGO.ORG - 13:40, Friday 13 March 2015 (17252)

Betsy, Jeff,

Thanks for cleaning up the mess and I am sorry that I did not alog the details. Regarding this configuration, I actually liked the ETMY configuration than ETMX because (1) the effective charge can be calibrated in Volts at the electrodes and (2) the bias voltage can be specified on the medm screen as the actual voltage at the electrode e.g. +380 V. We should decide which calibration convention we want to use. I will talk to you guys about this once I come back.

H1 General (CDS, DetChar, SUS)
ryan.fisher@LIGO.ORG - posted 14:30, Thursday 12 March 2015 - last comment - 19:48, Friday 13 March 2015(17224)
ODC Work Wednesday and Thursday Morning
Ryan F., TJ Massinger, Stefan

We edited the following models in the local copy of userapps without committing them.  We tested that all of these compiled successfully (and emailed CDS about some RCG bugs found when using GoTo and From parts in the models).  Screenshots demonstrating the changes are attached.  

We added a proper ODC channel (mostly still placeholders with no inputs or logic) for the following models to replace the current placeholders:
 h1pemey  
 h1pemex
 h1caley
 h1calex
 h1iscex
 h1iscey
  these last two require the changes to sys/common/models/ODC_MASTER_PARTS_V2.mdl
 h1alsex
 h1alsey

We also edited the h1omc model that was installed Tuesday to add checks on DCPD_A,B and PZT2_MON_AC error signals.
 h1omc
  requires changes to omc/common/models/omc.mdl

All of these models should be ready to be make-installed, restarted and committed to the SVN during the next maintenance period.

We also edited PSL_STATUS.adl locally to fix a white box (changed H1:PSL-ODC_CHANNEL_OUTPUT to H1:PSL-ODC_CHANNEL_OUTMON)

We created a new MEDM screen for ASC_ODC.adl and fixed some errors in the LSC_ODC.adl created by Duncan M.  These screens are not yet linked to any other MEDM screens.

We also committed a new safe.snap file for h1odcmaster.
Images attached to this report
Comments related to this report
ryan.fisher@LIGO.ORG - 19:48, Friday 13 March 2015 (17261)DetChar, IOO
I made some additional changes to the staged OMC changes:  These affect omc.mdl and omclsc.mdl.  The changes add EPICs outputs to display intermediate steps in the ODC_SUBSTATE calculations.  The added outputs are shown in the attached screenshots.  These changes have not been committed to SVN, but the h1omc.mdl model has been tested to successfully compile.  
Images attached to this comment
H1 ISC
stefan.ballmer@LIGO.ORG - posted 09:56, Tuesday 10 March 2015 - last comment - 01:11, Saturday 14 March 2015(17166)
2h lock overnight
We left the IFO on a DC lock last night. Attached is the spectrum. Two nights were notable:

1) The hump around 800Hz (apparently known as "twin peaks") was bigger than ever. Interestingly it was NOT there at all during earlier locks during the day. The only thing we know we did between the locks was a complete initial alignment. Also, over the period of about 1h, the hump completely disappeared.

2) The low-frequency noise (20Hz to 100Hz) is significantly less stationary now. (This did not improve over time.)
Images attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 11:39, Tuesday 10 March 2015 (17171)
ASC showing up in displacement / roll mode ringup

a) The first plot, middle graph, shows coherence between ASC loops and DARM. CHARD shows up very prominently - it's narrow stop-band get imprinted on the coherence. The same noise is also seen in IMP1_P, but it is likely just a witness, since it shares sensors with CHARD. Bottom lime: CHARD needs a proper low-pass.

b) The first plot, bottom graph shows some coherence between the 20Hz-100Hz excess and ASC_MICH_P. ASC_SRC2_P also shows it, but might again just be a witness (it uses AS_C as error signal). That excess BTW is all glitches.

c) The roll mode was seen to ring up over the 2h lock. Interestingly both ETMX and ETMY modes seem to be ringing. Since DARM feedback only goes to ETMX, but CHARD goes to both, I again suspect CHARD. Again: CHARD needs a proper low-pass.

Images attached to this comment
daniel.hoak@LIGO.ORG - 17:08, Tuesday 10 March 2015 (17184)

The bounce and roll mode ringups were due to human intervention -- Chris and I stayed a bit later last night working on the violin mode damping, and we couldn't resist changing the gains on the feedback loops, enough that things became unstable.  At 09:10 UTC when Stefan took his DTT spectrum, the gains on the feedback were nonzero, which impresses bounce & roll mode noise on the M0 stage OSEMs.  When the feedback gain is zero you can't see these modes in the top stage OSEMs -- this makes identifying the optic that's bouncing or rolling a challenge.  It may have been only one ETM was rolling, or an ITM (although I suspect both ETMs thanks to the ASC loops, as Stefan says.)

The attached images from the summary pages show the roll mode increasing around 09:40 UTC, when we realized our feedback was hurting more than helping.  After this I zeroed the gain on the DARM --> ETM M0 feedback and the mode stayed the same height for the rest of the night.  (When the noise got very bad after 11:00 UTC the bounce mode stayed pretty much the same.)

That said I would not argue against some roll-off filters for CHARD!

Images attached to this comment
christopher.wipf@LIGO.ORG - 01:11, Saturday 14 March 2015 (17266)

The attached screencaps show the roll mode damping setup that has worked well for us, tonight. (ETMX gain 10000/ETMY gain -600)

Images attached to this comment
Displaying reports 66461-66480 of 83266.Go to page Start 3320 3321 3322 3323 3324 3325 3326 3327 3328 End