Displaying reports 45261-45280 of 88367.Go to page Start 2260 2261 2262 2263 2264 2265 2266 2267 2268 End
Reports until 12:10, Monday 08 October 2018
H1 SQZ (SQZ)
nutsinee.kijbunchoo@LIGO.ORG - posted 12:10, Monday 08 October 2018 (44401)
Quick OPO frequency noise hunting

After a quick coherent hunt between OPO frequency noise and PEM channels it seems that a lot of noise came from SQZT6 and ISCT6 table (2nd and 3rd row, 3rd column). Both ISCT6 and SQZT6 accelerometer shows highest coherence at ~1kHz compared to accelerometers and microphones everywhere else in the LVEA (along PSL fiber path). ISCT6 accelerometer also shows high coherence at ~300Hz (2nd row, 3rd column). Still unclear where the noise comes from, but it's probably safe to assume that whatever noise is giving us trouble they're all local to HAM6 area.

Images attached to this report
H1 ISC
gabriele.vajente@LIGO.ORG - posted 11:39, Monday 08 October 2018 (44400)
CHARD yaw coupling to all other dofs

For future reference: attached a sweep sine of CHARD yaw including the coupling to all other yaw degrees of freedom. Apart from DHARD, all other error signals see the excitation quite well.

Images attached to this report
Non-image files attached to this report
H1 TCS (TCS)
corey.gray@LIGO.ORG - posted 11:28, Monday 08 October 2018 - last comment - 16:55, Monday 08 October 2018(44399)
TCS Chiller Check/Fill (FAMIS #11460)

Time To Perform Task:  14min

TCSx:  Chiller level was at "Max Level" & no water added.

TCSy:  Chiller level was at 8.4cm & 1200 mL of water was added to [get] level to the "Max Level".

NOTE:  I only removed the GRAY chiller cap for TCSy Chiller.  I was not sure where/how to remove the mesh filter.  Thomas later informed me we are supposed to remove the Chiller Cap "Panel" to gain access to this Mesh Filter.  So there is a chance the level I filled to might be erroneous.

Comments related to this report
thomas.shaffer@LIGO.ORG - 16:55, Monday 08 October 2018 (44416)

This is the first FAMIS task for the TCS chillers. TCSY was just given a marker on its water level last week (and by marker, I mean it's a ruler taped to the side of the water level). We had paper logs for these chillers on the chillers themselves, but they were never checked consistently. Enter FAMIS task. Hopefully, combined logs and consistent checks will give us quicker indicators of leaks and normal/expected water loss rates. So yeah, there is a bit of slop here that we are cleaning up :)

 

thomas.shaffer@LIGO.ORG - 14:06, Monday 08 October 2018 (44409)

This seems like a large amount of water for TCSY. I have been keeping a close eye on the chillers, and the level for the Y chiller has been stable for the past few weeks. I only put the ruler on that chiller last week, so I can't say at what level it was at previously, but I would guess ~2cm below the max line. Either way, this warranted a leak check.

Jason and I walked the lines and checked on table to look for any hints of a leak and found nothing. Looking back at the chiller, the water level was a touch above max, and I could see that 1.2L could squeeze in there from the previous level. There seems to be no leak, that we could find, but we will continue to watch these chillers closely.

stephen.appert@LIGO.ORG - 16:08, Monday 08 October 2018 (44413)

A couple of (maybe not so helpful) observations:

  • It seems that there is maybe too much slop in the Chiller Level Check / Refill procedure.
  • If it doesn't make sense to track / fill ~100 mL at a time, that should be clearly indicated by tracking 1) the expected water loss per week, and 2) the last time the expected water loss was refilled / reset. The FAMIS task seems like the right place for these items to be tracked / commented, but it probably needs to be done within every instance of the task.
  • (procedure document number? I might expect it to be related to T1600431, PSL Chiller Maintenance Documents)

I think tightening up the procedure and sorting out the fill date tracking will help avoid confounding a leak with an accumulation of expected water loss in the future.

H1 PSL (PSL)
corey.gray@LIGO.ORG - posted 10:40, Monday 08 October 2018 (44397)
PSL Weekly Report (FAMIS #10981)

Laser Status:
Front End Power is 33.3W (should be around 30 W)
70W Output Power is 75.75W
Front End Watch is GREEN
70W Watch is GREEN

PMC:
It has been locked 2 days, 1 hr 6 minutes (should be days/weeks)
Reflected power = 17.14Watts
Transmitted power = 43.5Watts
PowerSum = 60.64Watts.

FSS:
It has been locked for 0 days 21 hr and 15 min (should be days/weeks)
TPD[V] = 2.075V (min 0.9V)

ISS:
The diffracted power is around 1.6%
Last saturation event was 2 days 1 hours and 6 minutes ago (should be days/weeks)

LHO General
corey.gray@LIGO.ORG - posted 10:37, Monday 08 October 2018 (44396)
Monday Coordination Meeting Notes

Discussed CDS crashes from the weekend (due to recent upgrad).  

Talking about Maintenance

General Coordination Tasks

LHO General
corey.gray@LIGO.ORG - posted 09:58, Monday 08 October 2018 (44395)
Operator CFC Check: h1asc Model Had Differnces

(Hang, Corey)

Ran through the Operator Check Sheet's CFC (Configuration File Change) Check.  h1asc was the one model which had a CFC Warning (red box on CDS Overview medm).  Ran the command "filter_diffs asc", and had a few diffs which came up (see attached output screenshot) related to Radiation Pressure Compensation (RPC) filter banks (as well as some "unused" filter banks, i.e. ASC_DC7_P).  Since this was probably commissioning-related, I grabbed Jenne to ask about the diffs, and she steered me to Hang.  Hang confirmed these were changes he did, and so we hit the Load Coefficients for this model (@16:39utc and this cleared the CFC Warning).

Images attached to this report
H1 PSL
edmond.merilh@LIGO.ORG - posted 09:41, Monday 08 October 2018 (44393)
PSL Weekly Report - 10 Day Trends FAMIS #10578

All looks nominal

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 08:26, Monday 08 October 2018 (44390)
Morning Status

TITLE: 10/08 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 0mph Gusts, 0mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY:

H1 ISC
jenne.driggers@LIGO.ORG - posted 08:23, Monday 08 October 2018 (44389)
ALS lasers off - interlock tripped?

Both ALS lasers are off.  It looks like they both think their interlocks were triggered / tripped?

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 08:18, Monday 08 October 2018 - last comment - 12:21, Monday 08 October 2018(44387)
h1susey computer remotely reset, models running again

I have remotely reset the h1susey computer. Procedure was: disable the Dolphin IXS600 port h1susey is connected to and then issue a 'chassis power reset' command via the remote management IPMI port.

The whole process only took about 5 minute to complete, so I was surprised to see the SWWD on SEI-EY had tripped (should take 10 mins to trip). Perhaps this was tripped before the reset?

Comments related to this report
david.barker@LIGO.ORG - 08:23, Monday 08 October 2018 (44388)

h1susey console before reboot

Images attached to this comment
betsy.weaver@LIGO.ORG - 08:44, Monday 08 October 2018 (44392)

FRS ticket 11611.

david.barker@LIGO.ORG - 12:21, Monday 08 October 2018 (44405)

The reboot of the h1susey computer to the point where the h1iopsusey model was running again took over 5 minutes, which caused the software-watchdogs on the seismic system (h1iopseiey) to trip, which in turn zeroed all the DAC drives for this front end.

We should perhaps reconsider the SWWD receivers on h1iopseiey. Two options are:

  • extend the trip time to more than 5 minutes (keeping within the requirements limit that the trip happens within 10 minutes of SUS ring-up)
  • not trip the SEI if the SUS IPC channels go away
H1 ISC (GRD, ISC, SUS)
jenne.driggers@LIGO.ORG - posted 07:18, Monday 08 October 2018 (44384)
Guardian didn't recognize lockloss, most SUS saturating

I walked into the control room this morning to a symphony of names of optics being announced on the verbal saturation alarm.  The ISC_LOCK guardian had connection errors, and so was not able to recognize the fact that the lock was lost, so it had not run the DOWN state.  I stopped and restarted the ISC_LOCK guardian, which cleared the error long enough for it to start the DOWN state. 

While the DOWN state was resetting things, I checked the alog and see that Jamie predicted this behavior in alog 44383, since a similar thing happened at LLO recently. 

I think the take-away here is that if a front end computer has crashed, we should ensure that the IFO is in its DOWN state.  (To do this, in ISC_LOCK guardian, request 'manual' control, then select DOWN, then request 'auto' control.  You may also have to ask the node to STOP (pulldown menu that is usually on EXEC), then request EXEC again.)  I'm happy to receive a call to do this remotely if someone is busy with other recovery. 

Carlos and DaveB are already working on recovery of the susetmy computer.

 

H1 ISC
sheila.dwyer@LIGO.ORG - posted 14:39, Sunday 07 October 2018 - last comment - 15:23, Monday 08 October 2018(44378)
Improved recycling gain means more power on REFL, tried switching to REFLAIR

This is a late alog of work done yesterday afternoon with Gabriele. 

Friday evening Daniel and I noticed that we have about 10 times more power on our REFL diodes than in O2 according to the readbacks, with 1mW on the in vac REFL LSC diode when we are locked at DC readout.  Yesterday we tried to check that the amount of DC power roughly makes sense, which it does.  Since this is one thing that is different than O2, we suspected it could be contributing to our fast lockloss problems.  

As a quick test yesterday afternoon Gabriele and I switched the CARM control from REFL to REFLAIR, since it has a fourth of the amount of light that in vac REFL has.

Ideas for things to try next:

Non-image files attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 07:29, Monday 08 October 2018 (44386)

We definitely need to fix the fast locklosses, but I think that the 45MHz is important to look at as well.

We have never reduced the 9MHz before power-up.  It is the 45MHz that we reduced by 3dB before power-up.  In O2, the 9MHz was reduced by 6dB after we've transitioned to the low noise ESD at high power.  So, we should look at both the 9 and the 45, just in case it's the 45 causing weird saturations and weird behavior in the REFL diodes, even though it's the 9 that we use for CARM control.

It's this 45MHz reduction state that I tried last week, and it failed and caused a lockloss, although I have not yet determined why.

daniel.sigg@LIGO.ORG - 12:10, Monday 08 October 2018 (44403)

Reflected power on lock is around 6.5% of unlocked power.
9MHz sideband power on input light is 1.8% (Γ~0.191); most of it will show up in reflection.
45MHz sideband power on input light is 3.3% (Γ~0.251); around half will show up in reflection.

So, the reflected sideband power is around 3.5%.

hang.yu@LIGO.ORG - 14:55, Monday 08 October 2018 (44410)

Sheila, Hang

In our previous calculation LHO:44370 we only kept tracking the carrier field. As Daniel pointed out, the sidebands also contributed a significant amount of power in the REFL port. Thus we updated our calculation to include the RF sidebands.

In the first figure we show the locked / unlocked refl power as a function of PRG for the current configuration, and the second plot for the O2 configuration (9 MHz mod depth is about a factor of 2 lower than current setup).

It seems that the measured result is consistent with the theoretical model prediction. For now P_refl (resonance) / P_refl (off) = 6.5% corresponds to a PRG of ~ 46.5, consistent with our measured PRG of 48.

For O2 w/ PRG of ~ 30 and 6 dB lower 9 MHz mod depth, we should expect P_refl (resonance) / P_refl(off) ~ 1%, also consistent with the measured value.

Also for the 45 MHz, we found that about 20 % of the power is reflected and 80 % transmitted, thus its contribution to the REFL port is more like 0.5%.

The code for doing the calculation is available at /ligo/home/hang.yu/Desktop/pyComm/refl_vs_trans.ipynb

Images attached to this comment
jenne.driggers@LIGO.ORG - 15:23, Monday 08 October 2018 (44411)

I discovered that I had a typo in the reduce modulation depth states, which are a remnant from when I cleaned up all of the guardian code a few months ago.  Instead of setting some TRAMP values to 30 seconds in preparation for increasing digital PD gains to compensate for lowering the modulation depth, I was setting the PD GAIN values to 30 (they should be order 1, not 30). 

This is now fixed in both the 45 MHz and 9 MHz states, and loaded.

H1 CDS
david.barker@LIGO.ORG - posted 19:23, Saturday 06 October 2018 - last comment - 07:20, Monday 08 October 2018(44380)
h1susey has crashed, presumably a kernel panic

h1susey has crashed. Similar to h1lsc0 this morning it looks like the models are still running and the suspensions are still being damped. We have lost DAQ data from this machine and EPICS monitoring/controls.

If we need to restart this system, please call me on my cell phone and I can do this remotely.

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 19:36, Saturday 06 October 2018 (44381)

h1susey crashed at 19:00 PDT (02:00 Sun 7th UTC).

david.barker@LIGO.ORG - 09:35, Sunday 07 October 2018 (44382)

current status of SUS-EY.

I spoke with Richard on the phone last night soon after the crash and we agreed we could leave this system overnight because both the software-watchdog (running on h1iopsusey) and the independent hardware-watchdogs were functioning.

I realized we can indirectly monitor what the h1susetmy model is doing by looking at the coil current monitors being acquired by the h1susauxey model. Attached plots show 24 hours of M0_F1 IMON against h1susetmy_cpu_meter, 7 days of M0_F1_IMON, and 24 hours of all the ETMY M0 IMONs.

It looks like the suspension has changed state around 4am this morning.

Would the first commissioner on site today please call me on my cell phone and we can schedule a restart of h1susey.

Images attached to this comment
jameson.rollins@LIGO.ORG - 10:07, Sunday 07 October 2018 (44383)

You have to be careful leaving the front end in this state, at least when it come to guardian.  If a guardian node can't see EPICS channels it needs it goes into a CERROR state, in which it won't progress on it's graph until the needed channels are recovered.

We had a very similar failure at LLO last week, while the IFO was at full lock.  The IFO kept operating otherwise normally, but the ISC_LOCK node went into CERROR.  When there was a lockloss the node was still stuck and the DOWN state was not executed.  This can be bad since certain resets don't take place in a timely manner, which can cause things like violin modes to et rung up.

jenne.driggers@LIGO.ORG - 07:20, Monday 08 October 2018 (44385)

Looks like that's exactly what happened here.  See alog 44384 for a few notes.

H1 ISC (ISC)
hang.yu@LIGO.ORG - posted 19:13, Friday 05 October 2018 - last comment - 10:04, Monday 08 October 2018(44370)
Refl power vs PRG

In the attached plot we show the refl pd power as a function of power recycling gain (PRG). Here the x-axis is the PRG, the y-axis is the refl PD power, normalized by the power when the carrier is anti-resonant in CARM & PRC. In generating the plot we vary the arm losses as a parameter to compute the PRG and refl power simultaneously.

Images attached to this report
Comments related to this report
hang.yu@LIGO.ORG - 10:04, Monday 08 October 2018 (44394)ISC

Daniel suggested that in the future we might consider changing the PRM transmissivity to optimize the power recycling gain (PRG), given that we have less losses in the arms.

In the attached figure we show the PRG and reflected power P_refl (normalized by the anti res value) as a function of the PRM transmissivity. In the calculation we have assumed a total loss in one arm is 67 ppm (55 ppm loss at the ITM, 8 ppm scattering loss at the ETM, and 4 ppm transmissivity of the ETM), which gives a PRG of 50 for the current PRM transmissivity of 0.03. The red-dashed line shows the theoretically expected optimal T_prm that maximizes the recycling gain, and can be calculated based on the simple relation (cf. eq. 2.18 of Evan Hall's thesis, assuming T_itm=0.014):

    T_prm (optimal) = 4 eta_arm / T_itm = 1.91% * (eta_arm / 67 ppm),

where eta_arm is the total loss per arm. This leads to an optimal recycling gain of

    PRG (optimal) = T_itm / (4 * eta_arm) = 52.2 * (67 ppm / eta_arm).

Images attached to this comment
H1 AOS
robert.schofield@LIGO.ORG - posted 19:04, Sunday 17 June 2018 - last comment - 11:38, Monday 12 November 2018(42551)
Sources of peaks in jitter spectra

The figure shows spectra from the 4 angular IMC WFS DC channels with labeled peaks. Eight of the peaks between 80 and 1000 Hz are from optics or structures on the PSL table, two were from IOT2 and four haven’t been identified. The unidentified peaks were not excited by our PSL injections, even the global ones. It is possible that they are associated with structures that weren’t excited on IOT2 or in HAM2, or they may be associated with structures on the PSL table that we weren’t able to excite.

The identified sources are table resonances, periscope resonances and optic mount resonances. All optics that produced peaks in the spectrum were downstream of the PMC and were mirrors rather than through-optics like lenses, as would be expected.

The figure also shows the location of the sources in the PSL, as well as samples of the bowing and tapping data used to make the identifications.

Robert, Craig

Non-image files attached to this report
Comments related to this report
robert.schofield@LIGO.ORG - 17:09, Sunday 15 July 2018 (42908)

This version of the jitter spectrum includes photos of the optics. It should be easy to lower the Q of some of the higher-Q optics like M3.

Non-image files attached to this comment
stephen.appert@LIGO.ORG - 10:45, Monday 08 October 2018 (44398)

This is a very interesting and impactful glimpse into the current state of PSL table jitter coupling. Wish I had noted the study on first release.

I'm sure many would be interested in seeing an equivalent study of LLO, in everyone's spare time devil.

This study is relevant to IIET Ticket 4639 with title: "ECR: Modify attachment of optics mount to mounting plate on PSL periscope, previously Bug 1140". This IIET Ticket corresponds to the upper periscope mirror mount, with designator IO_MB_M6.

This study is relevant to IIET Ticket 5132 with title: "Move IO input beam PZT-mount from periscope to PSL/IO table surface". This IIET Ticket corresponds to the steering mirror upstream of the periscope which has a PZT actuator, with designator IO_MB_M4.

stephen.appert@LIGO.ORG - 11:38, Monday 12 November 2018 (45221)

This effort was subsequently re-examined by Robert in

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=44460
Displaying reports 45261-45280 of 88367.Go to page Start 2260 2261 2262 2263 2264 2265 2266 2267 2268 End