Displaying reports 44621-44640 of 83939.Go to page Start 2228 2229 2230 2231 2232 2233 2234 2235 2236 End
Reports until 21:07, Tuesday 06 February 2018
H1 SUS
betsy.weaver@LIGO.ORG - posted 21:07, Tuesday 06 February 2018 (40435)
ETMY SUS Status

Travis and I spent the morning in BSC10 re-lacing the ETMY PenRe, UIM, and ESD actuator cables through the reaction chain and re-securing them in the usual manner so they float with the masses and don't interfere with anything. 

We also reassembled and reattached the PUM and UIM flags in their nominal configuration.  Since we decided to do this after reinstalling the unit in the chamber, we had to remove the PenRe cans again and insert the flags for that stage through the holes in the PenRe mass.  Usually we attach the flags before installing it, however the unit then knocks around a bit while being maneuvered on the duct jack and the arm and we worried they could come free (although never has happened in the past).  Not sure which assembly order is better since today's activity took a lot longer than installing them outside of the chamber.

In the afternoon, we reattached the UIM-Top Mass wire segments and worked our way through the suspension to suspend all 8 masses.  The new ETM16 monolithic hangs!  With the reaction and main chains fully suspended, we observed a pretty good pitch misalignment of the reaction chain and a bit on the main.  We used the (now) easy PenRe Pitch mass slider bar to correct the gross reaction chain mis-pitch and the UIM coarse pitch adjusters on the main chain to do the correction there.  We dropped the ACB back into place (removed the wedge) and observed that the oplev beam was headed back to the oplev receiver port to within ~a cm or so of the diode.  Will continue from here tomorrow with reseating OSEMs and fine tuning alignment.

*Note to self, there will NOT be an oplev reflection from the reaction chain anymore - someone put a hole in the reaction mass!

LHO VE
chandra.romel@LIGO.ORG - posted 20:36, Tuesday 06 February 2018 (40448)
GV 5,7 closed again

Hard closed GV 5,7 around 8pm after checking in with commissioners.

Valved back in all three turbos. Left RGA and all six IPs valved in.

Pressure gauges PT 114,124,134 tripped after closing valves and disengaging switch at the LOTO pin. Ongoing Beckhoff issue.

GV 5 hard closed at 20 psi. GV 7 was stubborn and hard closed at 50 psi. I valved back in the gate annulus volumes at both GVs.

H1 AOS (AOS, ISC)
georgia.mansell@LIGO.ORG - posted 20:34, Tuesday 06 February 2018 (40444)
x-end aux laser mode-hopping and noise eater ringing

[Sheila Jenne TVo Georgia]

While trying to lock ALS we found that x-end aux laser was glitchy. An example of the sort of behavior we saw is shown in the first screenshot and indicated by the pink arrow, where noise was seen in the green and IR intensity. We thought this was due to the aux laser mode-hopping, so Sheila and I went to the end station to adjust the diode current and crystal temperature. Initially the diode current was 1.949 A and the crystal temperature was 23.73 C, we adjusted this to 1.902 A and 23.78 C.

After the initial adjustment to the laser current and temperature the green and IR power out of the laser was drifting with the crystal temperature (shown in second screenshot), also possibly due to mode-hopping. We returned to the end station to adjust the laser parameters again. The aux laser diode current is now 1.997 A and the crystal temperature ~23.67 C.

Later we determined the glitching was possibly due to the aux laser noise eater ringing, and is fixed by resetting the noise eater. In the future it would be good to have a way to monitor if the noise eater is ringing and toggle it on and off. This used to be achieved using the demod RF mon, but this was not working today.

Images attached to this report
H1 ISC (ISC)
thomas.vo@LIGO.ORG - posted 20:31, Tuesday 06 February 2018 - last comment - 16:52, Monday 12 February 2018(40447)
Loss Measurement, Locked and Unlocked XARM

[For the commissioning team]

We did a quick measurement of the loss in the x-arm after improving the pointing into the cavity using IM4 and PR2.

It is important to note that there were no angular loops closed when doing this measurement, so the power build up wasn't optimized ( LSC-TR_X_QPD_B_SUM ~ 0.95).   We were running short on time and verified that the DC angular alignment was good enough so that the locked vs unlocked state gave us a big enough dip to estimate a visibility.  

Channel Locked Power(Cts) Unlocked Power(Cts) Visibility Loss PPM (calc'd)
AS_A_DC_NSUM 286 307 93% 302

Comparing the above numbers to alog-38493. They are close, but I can't say anything definitive about the change in loss between the two ITMXs (before and after swap), we can redo this measurement when we have more time to close angular loops (and maybe try a more sophisticated loss measurement).  Also important to note, mode-matching contributes to the loss as well and this is not taken into account with this measurement.

Images attached to this report
Comments related to this report
thomas.vo@LIGO.ORG - 16:52, Monday 12 February 2018 (40498)

Sheila commented that the visibility/loss is a bit concerning, so I trended some other channels to see if they gave any other estimates, unfortunately, the ones I could think of (REFL and AS) were not of much use because they didn't show an obvious dip (First and second attachment) .  It is important to also note that the dark offsets for ASC-AS_A_DC_NSUM were on and roughly correct.

That got us thinking, if there is alignment or modal mismatch, will we be over or under estimating the total loss with this measurement? And how much does the modulation depth from the sidebands cause a difference in the power ratio between unlocked and locked compared to the losses of the ITM?

Using Finesse and the as-built Nebula page, I modeled the  single x-arm with input power of 1 W.  The modulation depths for 9 and 45 MHz was measured by Kiwamu in aLOG-8867.  Also, setting the arm cavity eigenmodes as the basis, I estimated 15% mode-mismatch and 15% alignment mismatch by injecting 01 and 02 modes alongside the 00 into the cavity.  Another parameter is of course the loss at the input coupler which for display purposes I used 5ppm. (Third attachment)

Conclusion:

The loss of the input-coupler dominates over the modulation depth from the sidebands, and the mismatch either from modal or misalignment will cause us to underestimate the total losses.

Images attached to this comment
H1 ISC
jenne.driggers@LIGO.ORG - posted 20:26, Tuesday 06 February 2018 - last comment - 09:14, Wednesday 07 February 2018(40445)
Xarm coaligned in Green and IR

[Georgia, TVo, Sheila, Jenne]

Summary: We were able to lock and align the Xarm and input beam for both green and IR.

This morning, we locked Xarm with the green laser, and aligned TMSX, ETMX and ITMX to the green beam.  As usual, PR3 was adjusted to get the transmitted green beam out onto ISCT1.  (The ALS light pipe was also opened.)  The ALS WFS didn't end up working for us today - the yaw signals seemed to make sense, but the pitch signals didn't really.  We decided to move on rather than investigate this in detail.  The TMS and ITM pointing were both set using the bafflePD alignment script, then ETMX was adjusted to maximize the transmission through the cavity.

After lunch, we succeeded in moving IM4 and PR2 to get the IR beam aligned to the Xarm. 

We ended up using LSC-POP_A_RF45_I to lock the Xarm, rather than the planned ASC-AS_A_RF45_I_SUM.  POP has worse SNR, but seemed to work a little bit better.  We did not go back and re-try to use AS_A after the cavity was well-aligned, but we need to check and confirm that the signal path is doing what we think it is, sometime using MICH (it all looked fine, and was going to Xarm_IN1, but we just weren't catching any good locks).  We used an input matrix element of -10 for POP, so that the XARM_IN1 was the same roughly +-200 counts that it was during O2 initial alignments of Xarm-only flashing with the old ASAIR_RF45.  Otherwise all the Xarm locking settings were as in guardian. 

We had some struggles throughout the day, see in particular Sheila and Georgia's alogs.  TVo is summarizing our Xarm visibility measurement in yet another alog.

Attached is our alignment after the arm peek.  IMC WFS were on, but no other ASC is engaged.  I also attach the IMC overview, for the IM4 trans and POP_B values, so we don't have to trend them later.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 09:14, Wednesday 07 February 2018 (40451)

Attached are screenshots showing the ITMX suspension overview, the IM overview, and spot positions on IM4 and the OSS QPD (which the beam is not on right now) and the oplev overview after yesterday's alignment, in case this information is useful in addition to the slider values. 

Also, after locking the X arm in green we also adjusted PR3 to maximize the comm beatnote on ISCT1 which has not moved since O2.  The final alignment of IR into the X arm was done with this PR3 alignment.

Images attached to this comment
H1 PSL
sheila.dwyer@LIGO.ORG - posted 20:00, Tuesday 06 February 2018 - last comment - 09:11, Wednesday 07 February 2018(40443)
FSS oscillating

Since the HPO has been off, the FSS has been oscillating at 238Hz according to the PZT fastmon.  THe attached screenshot shows some examples.  

This caused us some problems during the arm peak, and it would be difficult/futile to do DRMI with this happening.  It would be great if someone could look at this loop in the morning. 

Images attached to this report
Comments related to this report
peter.king@LIGO.ORG - 09:11, Wednesday 07 February 2018 (40450)
This morning I looked at the noise spectra for the Pockels cell path and the PZT path.  There is a broad hump
around the region Sheila mentioned, along with a large number of what I presume are mains related peaks.
Adjusting either the common gain or the fast gain did not appear to have any affect on the hump.  In the
Pockels cell path, there was a large peak at ~55 kHz, which might be a harmonic of the PZT/Pockels cell
cross over.

    Attached is the transfer function of the TTFSS measured this morning.  It is noticeably different from
ones I remember.  Not least of which the unity gain frequency is down a fair amount.  Increasing the
common gain increased the unity gain and phase margin but the PZT monitor became noisier.  Not 100% sure
of the reason.  My suspicion is that it may be related to the alignment of the Pockels cell after the
NPRO.  That would be one thing to look at when the laser gets overhauled.

    Also attached are the measured transfer functions of the pre-modecleaner servo for slider gains of
16 dB and 19 dB.
Images attached to this comment
LHO VE
kyle.ryan@LIGO.ORG - posted 17:19, Tuesday 06 February 2018 - last comment - 08:09, Wednesday 07 February 2018(40441)
PT246B tripped off (Beckhoff thing?)
I unplugged a read back signal cable (that we never have utilized) which indicates the OPEN/CLOSED status of CP4's 10" gate valve and, shortly thereafter, noticed that PT246B had tripped off -> I re-enabled it in CDS but it isn't likely to "fire" at these Y2 BT pressures -> I assume that this is another example of the inter-dependencies with the Beckhoff "daisy chain" setup?  I haven't yet adjusted to the new "normal". 
Comments related to this report
chandra.romel@LIGO.ORG - 20:29, Tuesday 06 February 2018 (40446)CDS

This also happened today when closing GVs 5,7. PTs 114,124,134 tripped.

patrick.thomas@LIGO.ORG - 08:09, Wednesday 07 February 2018 (40449)
This doesn't sound to me like a Beckhoff issue, or at least not the one I think you are referencing.
LHO VE
kyle.ryan@LIGO.ORG - posted 17:13, Tuesday 06 February 2018 (40440)
More CP4 decommissioning
Revisited leak checking the new hardware bolted to CP4's 10" gate valve -> No leaks detected with 6 x 10-10 torr*L/sec background -> Moved clean room etc. and began wrapping components for baking -> Expect to be baking by e.o.b. tomorrow.
LHO General
corey.gray@LIGO.ORG - posted 16:01, Tuesday 06 February 2018 (40429)
DAY Operator Summary

TITLE: 02/06 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

Today light was flashed down the X-arm.  Locked with green and currently working on locking in red.  Not sure if they'll stay here the full time to 8pm, but Jenne said, "will be definitely be here past 4pm."  :)
LOG:

LHO General
corey.gray@LIGO.ORG - posted 12:41, Tuesday 06 February 2018 (40436)
Mid Shift Status
H1 CDS
david.barker@LIGO.ORG - posted 10:48, Tuesday 06 February 2018 - last comment - 06:18, Monday 12 February 2018(40433)
xmgr plot skipping sections and displaying "max drawing path length" error

Some recent modest ASC full data trend plots have shown gaps in the data with an accompanying popup error:

[Error] Purging failed. Increase 'Max drawing path length' in prefs.

It is not immediately clear what "purging" and "max drawing path length" mean, but if you increase it from the default of 20k to 100k the gaps disappear.

Attached is the 'gappy' plot with the popup, and the preferences with the increased max drawing path length

Images attached to this report
Comments related to this report
keith.thorne@LIGO.ORG - 06:18, Monday 12 February 2018 (40491)CDS
Recently, Rolf and Jonathan alerted CDS to the existence on 'qtgrace', a currently-supported grace implementation that appears to solve several issues.  In the attached plot, you can see an extra sizing slider (currently at 1.3) and a "Fit" button that resizes a plot to fit the window. Currently packaged by Michael Thomas for SL7, we are working on a test rollout at LLO
Images attached to this comment
LHO VE
chandra.romel@LIGO.ORG - posted 08:45, Tuesday 06 February 2018 - last comment - 15:50, Tuesday 06 February 2018(40430)
GV 5,7 open

Opened GV 5,7 for commissioners x arm work. Opened up GV 5 to utilize cryopump #1. Pressure at beam splitter is currently 1.14e-7 Torr. Pressures just past CP 1,2 are 6.64e-8 Torr and 7.75e-8 Torr, respectively.

Recorded another RGA scan just before opening valves, after the filament was turned on overnight (thanks Jeff K.!). Will scan again later today.

(This RGA computer in control room is not functioning properly. An upgrade is in its future.)

Images attached to this report
Comments related to this report
chandra.romel@LIGO.ORG - 08:50, Tuesday 06 February 2018 (40432)

Note the high N2 peak.

chandra.romel@LIGO.ORG - 15:50, Tuesday 06 February 2018 (40437)

Here's an RGA scan at 3:30pm with corner exposed to arms (X1,X2,Y1). Carlos had to wipe the RGA computer today and unfortunately we lost all the stored ASCII data from previous RGA scans. Many should be in aLog but since the default ASCII file that exports from Quadera doesn't upload into aLOG, it sometimes didn't get uploaded (such as this morning's scan). Scan plots are always uploaded as PDF, jpeg, or similar.

Non-image files attached to this comment
H1 SUS (CDS, SQZ)
jeffrey.kissel@LIGO.ORG - posted 19:58, Monday 05 February 2018 - last comment - 18:23, Tuesday 06 February 2018(40427)
H1 SUS OPO Simulink and MEDM Infrastructure Mostly Upgraded
J. Kissel, D. Barker

A while back, I'd put together Simulink infrastructure for the OPOS (optical parametric oscillator suspension; then called VOPO) while we were beginning to rearrange the SUS HAM56 ADC / DAC allocation to accommodate the new squeezer suspensions (see LHO aLOG 38827). Since then, we've decided several things we'd like to change:
    - We don't like a suspension type and an instance of that suspension type to be the same. So, VOPO and VOPO gotta go.
    - We don't call the output mode cleaner the "vacuum output mode cleaner," so, we've dropped the V in VOPO for the instantiation, and now the suspension type is OPOS.
    - We don't like the channel ordering H1 V1, H2 V1, H3 V3, in the digital system, because that's not how team seismic orders there sensors named the same way, so we convert to H1 H2 H3, V2 V3 V3 (see E1700390 for sensor arrangement)
    - The important axis of the OPOS is *not* aligned with the HAM6 ISI's Cartesian coordinate system, so we convert to every other suspension's coordinate system, i.e. Euler, i.e. L T V R P Y (see G1701821).
Also, I never actually got the MEDM screen infrastucture up to speed to match *any* model, let alone the above new requests.

Today, I updated the front-end code to meet all of the above requests, compiled it, Dave installed it and restarted the h1susopo process. After that, I've moved things around in the sus/common/medm/ userapps repo folder to changing things from VOPO to OPOS, updated a bunch of screens and the associated marco file, and committed it all to the svn. 

I've also *begun* to fill in this infrastructure where I can, but it's not fully complete. OSEM2EUL and EUL2OSEM basis transformation matrices we copied by hand from TST aLOG 11396, 'cause the scripts that calculate the values need to be updated for the now-preferred channel order. I've still gotta 
    - copy over damping filters,  
    - re-check-in with TJ regarding magnet polarity for the COILOUTF gains, 
    - fill in the watchdog signal processing filters, and of course, 
    - we need OSEMs to include any open light current stuff in the OSEMINFs). 
Certainly good enough until we actually hook up our OPOS to the readout and control system.
We also need to change the naming convention in the h1susauxh56 model (VOPO to OPO) so we can pick up the coil driver monitor channels that are always useful when debugging whether suspension is being driven.
Finally, I've made sure the SDF system's safe.snap is up to date with all new settings, and committed that to the repo as well.

Attached are a few screenshots and a text file with more detailed notes about what needed changing -- especially the details of the top-level front-end model changes. 
Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:35, Tuesday 06 February 2018 (40439)
J. Kissel

I've made the necessary name changes to the h1susauxh56 front-end model and the associated channels on the OPOS overview screen. The auxiliary model has *not* been restarted, since I don't want to demand a DAC restart on the arm peak team. 
We should install the code and restart the h1susauxh56 front-end process as soon as is convenient.

Further MEDM and settings updates:
    - I've updated the overview screen to include a diagram of the relationship between the OSEM coordinate system and the Euler coordinate system, a. la. E1700390.
    - I've converted the coil driver monitor screen (which was a totally incorrect copy of a HAM triple's monitor screen) into a standard, six-channel, filter bank screen. This allows for calibration of the voltage monitor signals, if we so desire. Remember, the OPOS AOSEMs are driven with an HAM-A driver which *only* has voltage monitors, unlike core-optic suspensions which have the full NOISEMON, VOLTMON, FASTIMON and SLOWRMSIMON collection of monitors, and it only has one isolation stage, so a fancy screen in not needed here. (Since the h1susauxh56 model with corrected channel names has not been installed, the screen remains full of white EPICs records.)
    - I've installed COILOUTF coefficients: they're all negative. See explanation below.
    - I've installed filtering on the OSEMs for the OPOS watchdog. Remember, this is one of the first suspensions to receiuve the updated watchdog infrastructure (see E1700387) so it now, not only has a 0.1 to 10 Hz bandpass prior to the cdsRMS part that all , but a 10 sec "averaging" filter (i.e. a 4th order butterworth low pass filter with a corner at 0.1 Hz) after the cds RMS part. Y'know, like you're supposed to with an RMS calculation. We'll see how it goes once we hook up OSEMs. We'll also then decide how to calibrate the signal and set the threshold.
    - I've copied over the damping filters from LLO, using that which was committed to
          cds_user_apps/trunk/sus/l1/filterfiles/L1SUSOPO.txt rev. 16732 (last changed rev. 16627)
      Spying on LLO, I've found that although there are lots of filters in each bank, only one is used (FM6), and the gain field is otherwise populated with gains something like what's mentioned in LHO aLOG 11390. I'll have to have a conversation with Stuart / Arnaud before I claim I understand what's happening.

After these changes, I can definitely say we're ready for OSEMs.

OPOS COILOUTF Sign Convention Explanation:

To establish the sign I use +YAW for the horizontals, +VERT for the verticals, the existing EUL2OSEM matrix, the established AOSEM sign conventions requested regarding coil current vs. magnet polarity T1200015, and the physical orientation of the OSEMs found in the assembly drawing D1500295. 
          For +YAW, we wish for the OSEMs to expand (as per D1500295), i.e. to push the magnet away from the coil. Given that all OPOS magnets have N polarity facing in the OSEM (as per E1700390), we need a negative current across the coil to create a push with a N magnet (as per T1200015). The EUL2OSEM matrix retains the sign of the requested +Y drive (i.e. the Y to H1H2H3 EUL2OSEM elements are all positive), so we must invert the sign of the requested, +YAW * EUL2OSEM, drive signal to get a negative requested current on each OSEM. Thus the H1H2H3 COILOUTF gains shall be negative.
          For +VERT, we wish for the OSEMs to contract, i.e. to pull the magnet into the coil. With the N polarity facing into the magnet, that means we need a positive current across the coil. The EUL2OSEM matrix flips the sign of the requested +VERT drive (i.e. the V to V1V2V3 EUL2OSEM elements are all negative), so we again must invert the sign of the requested, +VERT * EUL2OSEM, drive signal to get a positive requested current on each OSEM. Thus, the V1V2V3 COILOUTF gains shall all be negative.


Images attached to this comment
jeffrey.kissel@LIGO.ORG - 18:23, Tuesday 06 February 2018 (40442)
J. Kissel, S. Aston

Stuart rightfully noticed that although the OPOS_MASTER model had the usual OPTICALIGN, LOCK, and DRIVALIGN array of filters, it was not reflected on the MEDM overview screen. Whoops! I've now added all that and committed the screens to the userapps repo.
Images attached to this comment
LHO VE
chandra.romel@LIGO.ORG - posted 10:26, Monday 05 February 2018 - last comment - 08:46, Tuesday 06 February 2018(40410)
valved in corner IPs & RGA; valved out MTPs

Valved in vertex RGA and all six main ion pumps and valved out all three main turbo pumps (all pumps reading ~1 mA). Tomorrow will open GV 5,7 for x-arm commissioning (8am-8pm local).

Images attached to this report
Comments related to this report
chandra.romel@LIGO.ORG - 10:51, Monday 05 February 2018 (40411)

RGA scan with IPs valved in and MTPs valved out. Also attached scan pre-vent for comparison.

Non-image files attached to this comment
kyle.ryan@LIGO.ORG - 17:25, Monday 05 February 2018 (40424)
How long had the filament been energized before taking today's scan? 
chandra.romel@LIGO.ORG - 18:13, Monday 05 February 2018 (40426)

< 90 min. Jeff K. turned filament on for me via phone instructions. Will scan again tomorrow morning before opening up to beam tube.

chandra.romel@LIGO.ORG - 08:46, Tuesday 06 February 2018 (40431)

Here is a scan after the IPs were pumping over night and turbos valved out, and RGA filament turned on for > 12 hrs.

Images attached to this comment
H1 SQZ (SQZ)
sheila.dwyer@LIGO.ORG - posted 12:52, Thursday 01 February 2018 - last comment - 11:11, Sunday 18 February 2018(40362)
VIP aligned for 1064 and 532 before M1 swap

Sheila, Nutsinee, Terry,

This is an update on the progress so far on the VIP. We have aligned and mode matched both the CLF/seed 1064 path and the 532 pump path to the OPO, and are ready to think about swapping M1 for the higher green reflectivity version.  

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 17:22, Tuesday 06 February 2018 (40434)

Here's the green data (+PZT calibration). Note that the data hasn't been corrected for dark current. 

  • I did the same trick Sheila did (poly degree 2 fit to the time vs. FSR plot) to rescale the voltage applied to the PZT driver so the relationship between resonance peaks and frequency is linear.
  • The mode matching calculated from transmitted power is 66% +/-1%  
  • The dips in reflected power are 75.6% +/-0.4% of the power off resonance. Higher order modes has not been taken into account.
  • The PZT driver (Thorlabs MDT694) has an external input gain of 15V/V. This results in 22V per FSR, or 40V/um.
Images attached to this comment
nutsinee.kijbunchoo@LIGO.ORG - 11:11, Sunday 18 February 2018 (40594)

I corrected the green data for dark current as Sheila suggested. The mode matching calculated from transmitted power is now 73.5%. The dips in reflected power are 78.8% of the power off resonance. Higher order modes has not been taken into account.

Images attached to this comment
Displaying reports 44621-44640 of 83939.Go to page Start 2228 2229 2230 2231 2232 2233 2234 2235 2236 End