Displaying reports 36901-36920 of 89199.Go to page Start 1842 1843 1844 1845 1846 1847 1848 1849 1850 End
Reports until 19:01, Friday 13 December 2019
H1 SUS
cheryl.vorvick@LIGO.ORG - posted 19:01, Friday 13 December 2019 (53891)
ETMY violin mode gains reset, rining up modes 18,20, new gains in place

H1 lost lock, and relocked with the old ETMY violin mode damping gains, which, after 10 hours, were ringing up modes 18 and 20.

I currently have the ETMY violin mode gains to these values:

I changed lscparams to use the above gains if H1 loses lock

Plots attached show the damping done tonight.

Images attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 18:26, Friday 13 December 2019 (53890)
Mostly finished with the CS instrument air duty cycle modification but am postponing changeover until Monday

I still have to land the ground wires to the pressure switches and solenoid valve but otherwise am ready to test this out on Monday.  When enabled, this modification should reduce the CS instrument air compressor duty cycle significantly.

LHO VE
kyle.ryan@LIGO.ORG - posted 18:19, Friday 13 December 2019 - last comment - 19:10, Friday 13 December 2019(53889)
CP4's indicated dewar level yellow?

I noticed that the MEDM RED/YELLOW/GREEN field associated with CP4's dewar level had changed today from the nominal RED (CP4 is empty - decommissioned) to YELLOW and 1.3% full up from the nominal ~0% full -> I think that this is a bogus indication and should be ignored.

Comments related to this report
gerardo.moreno@LIGO.ORG - 19:10, Friday 13 December 2019 (53892)

See attached plot for dewar level, behaviour changes on 12/08/2019 around 22:00 utc, around 14:00 local time.

For now I've adjusted the high alarm level for this channel, from 1.0 to 1.5, field is green now.

Images attached to this comment
H1 SYS (ISC, Lockloss, OpsInfo)
jenne.driggers@LIGO.ORG - posted 17:57, Friday 13 December 2019 (53888)
Lock acquisition survey

Last week, I asked operators to begin using a new online survey to record lock acquisition attempts, rather than type out their attempts and manual interventions in the alog.  We've now had 4 locklosses / reacquisitions since then, so we're starting to get some data (thank you Operators!).  The point of this survey is to get information regarding manual interventions required, to help us identify where we need to work on the interferometer's relocking automation.  Operators have been giving us this information in their alogs (again, thank you!), but this online form should streamline responses and hopefully save everyone time. 

The online google form outputs to a google sheets spreadsheet that everyone (who has ligo.org credentials) can look at.  I'm starting to put some digestion of the data on other tabs in that sheets document; I'm hopeful that we'll be able to get some useful information out of the digested data, rather than every person having to individually read through the entirety of the spreadsheet, but that component is still a work in progress.

Everyone is welcome to click through the survey.  However, if you are not actively filling it out for a lockloss, please choose the name "Test / DeleteMe" so that if the response gets submitted, we can excise that row.  Also, please feel free to look at the results spreadsheet.  However, note that the spreadsheet is not archived, so please do not edit the responses (so that we don't lose any).

The form and spreadsheet should be accessible to everyone with ligo.org credentials.

Form: https://tinyurl.com/LHO-Lock-Acq-Questionnaire (hover for the actual link; I made a tinyurl that is easier to type)

Results: https://tinyurl.com/LHO-Lock-Acq-Responses (again, hover for the actual link)

Attached is a flow chart (also laminated at the operator station) describing the flow of the survey, as well as screenshots of some of the questions.  Note that there have been some updates to the questions and text since I made this pdf, as a result of excellent feedback from operators, but the gist of them should be similar.

Non-image files attached to this report
H1 CAL (CAL)
timesh.mistry@LIGO.ORG - posted 17:27, Friday 13 December 2019 - last comment - 17:59, Thursday 25 February 2021(53819)
NCAL Update -- NCAL Sweep Analysis Part 1

J.Kissel, T.Mistry

Here are some 'Money Plots' for the NCAL Sweep that was taken on the 04-Dec-2019.

Figure 1 :: A move/animation of the sweep as seen in the control room DARM spectrum.
Figure 2 :: ASD of the DARM plot with labelled frequencies from 5 to 600Hz.
Figure 3 :: ASD of the DARM plot with tagged frequencies from 5 to 40Hz.
Figure 4 :: Spectrogram of the NCAL Sweep from 0 to 50 Hz.
Figure 5 :: Spectrogram of the NCAL Sweep from 0 to 1000 Hz.
Figure 6 :: IWAVE line tracking of the Optical encoder as the NCAL changes velocity.

All the figures are also available in DCC G1902340.

An interesting feature to see is that when the NCAL is settling to a new frequency, making what appears to be sidebands. This is due to the NCAL slightly overshooting the requested frequency before settling down to the desired velocity. This is an expected results as a result of the NCAL motor behaviour due to the internal motor parameters. It is possible to configure the motor parameters to reduce the overshoot however, the current implementation is a trade off between time taken to accelerate to a given frequency and the stresses on the motor.

Below is a timeline of the NCAL sweep. The values in red are not visable due to the lack of SNR at low frequency. A longer intergration time would be required to see the lines below 5Hz.

NOTE: to create a movie and upload it to the alog I did the following onn the LHO control room machines:

ffmpeg -i out.ogv MyFile.mp4

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:58, Friday 05 February 2021 (57887)CAL
J. Kissel

These Dec 4th 2019 measurements were run from 1259535305 to 1259539158 (Dec 04 2019 22:54:47 UTC to Dec 04 2019 23:59:00 UTC).
Any and all O3 C01 systematic error estimates for any observation-ready hour are now available on the CIT cluster in a standard location that the GW data analysis teams use (they weren?t back in Apr 2020 when I produced the plot on page 32 of the Review of the First Results, G2000532). For Hanford, they live in
	https://ldas-jobs.ligo.caltech.edu/~cal/uncertainty/O3C01/H1/
So we want the file that?s the nearest in time to the time frame of 1259535305 to 1259539158 (which was *out* of observation ready time).

During the whole time the detector was out of observation ready mode, the IFO was locked, happy, and stable as one can see from the summary pages,
	https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20191204/
Also from the summary pages, one can see that the time-dependent correction factors remained the same before vs. after the observation ready stretch,
	https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20191204/cal/time_varying_factors/

We went back in to observation ready mode right *after* the NCAL injections, so actually the nearest time *after* the injections will be the best.

That's the file 
	https://ldas-jobs.ligo.caltech.edu/~cal/uncertainty/O3C01/H1/2020-06-12_O3_LHO_GPSTime_1259540100_C01_RelativeResponseUncertainty_FinalResults.txt
at 1259540100, or Dec 05 2019 00:14:42 UTC, 942 seconds later, or 16 minutes later.

(Ignore the date at the beginning of the file name: that?s a reflection of when the file was created, not a reflection of the time for which the systematic error budget applies. That?s indicated by the GPS time in the file name).

This shall be the h(f) systematic error we use to compare against in the forthcoming NCAL paper.
jeffrey.kissel@LIGO.ORG - 17:59, Thursday 25 February 2021 (58024)
J. Kissel

The spot positions for this measurement, determined by the P2L and Y2L decoupling gains which were 4.3 and 3.6 respectively for this entire lock stretch on Dec 04 2019, are 15.7 mm in -Vertical, and 13.2 mm in +Transverse. See further discussion of how these numbers are determined in LHO aLOG 58023 (i.e the NCAL's swan song on Sep 03 2020, which had the exact same spot positions).
H1 AOS
edmond.merilh@LIGO.ORG - posted 16:09, Friday 13 December 2019 (53886)
Shift Summary - Day

TITLE: 12/14 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 107Mpc
INCOMING OPERATOR: Niko
SHIFT SUMMARY:
LOG:

H1 General
yannick.lecoeuche@LIGO.ORG - posted 16:06, Friday 13 December 2019 (53885)
Ops EVE Shift Transition

Ops Shift Transition: 12/13/2019, Eve Shift 00:00–08:00 (16:00-00:00) - UTC (PT)

State of H1: Locked

Intent Bit: Observing

Weather: 0-10 mph wind

Primary 0.03 – 0.1Hz: 0.01 um/s

Secondary 0.1 – 0.3Hz: 1.0 um/s

Outgoing Operator: Ed

Quick Summary: Locked and Observing for 8.5 hours. Microseism still high

H1 General
edmond.merilh@LIGO.ORG - posted 10:57, Friday 13 December 2019 - last comment - 10:58, Friday 13 December 2019(53882)
Shift Transition - Day

TITLE: 12/13 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Camilla
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.74 μm/s
QUICK SUMMARY:

oops! forgot to post.

Comments related to this report
edmond.merilh@LIGO.ORG - 10:58, Friday 13 December 2019 (53883)

18:57 Returned INJ_TRANS Guardian node back to INJECT_SUCCESS following the mornings Superevent activity.

H1 General
camilla.compton@LIGO.ORG - posted 08:12, Friday 13 December 2019 (53881)
Shift Summary - Owl

TITLE: 12/13 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 112Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Lockloss, cause unknown.
LOG:

Cheryl's violin settings for ETMY seemed to work well all night, but I have not yet reset them, that could be done using Cheryl's alog 53875.

H1 General
camilla.compton@LIGO.ORG - posted 04:14, Friday 13 December 2019 (53880)
Mid Shift Summary

Remain locked and observing through this high microseism, where secondary useism: 0.92 μm/s

H1 IOO (IOO)
cheryl.vorvick@LIGO.ORG - posted 02:24, Friday 13 December 2019 - last comment - 03:24, Friday 13 December 2019(53878)
new HAM2 East door camera

On December 3rd I moved the HAM2 East door camera to a new port, and pointed the camera to look at AOE2, the beam dump for Calcite Wedge 2's forward rejected beam, the steering mirror for that beam, and the HWP baffle in the IO FI. 

 

The camera view is rotated counterclockwise by 90 degrees, so the top of the image is to the right in HAM2.  The focus is a bit farther back than intended, with the best focus being on the IO FI HWP baffle aperature, near the top of the image (to the right of AOE2).

Using HAM2 coordinates, the first component fromt the left is the IO beam dump.  This has a beam coming from the left, and hitting the outside of the beam dump.  The beam dump frame, that holds the SiC plates, is illuminated on the left and along the top, and here is where one can see the best example of the changing illumination from IR light.  Inside the beam dump, on the right, there is a beam which appears to e hitting the right of the beam dump, on the inside, which appears to be dumped directly on the metal side plate.

From center and to th right, is the back of AOE2.  The metal frame is visible, and the aperture in the front SiC baffle is surrounded by IR light.

To the far right one can see most of the IO FI HWP baffle aperture, meaning that the top and sides of the aperture are clear, but the bottom of the aperture is not, and that is because it's blocked by the steering mirror that sends the forward rejected beam to the beam dump.

Attached images were taken from both the East door and top viewport, and show AOE2, and the input to the IO FI, including CW1.

 

Images attached to this report
Comments related to this report
cheryl.vorvick@LIGO.ORG - 03:24, Friday 13 December 2019 (53879)

Attachment document shows both visible and the IR images from the East door.
In the previous images, it's possible that PRM was misaligned while I was taking photos, so some of the beams seen on baffles could be a result of that misalignment.

Images attached to this comment
H1 General
cheryl.vorvick@LIGO.ORG - posted 00:19, Friday 13 December 2019 (53877)
OPS Eve Summary

TITLE: 12/13 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: Camilla
SHIFT SUMMARY:  locked in Observed all shift
LOG:

H1 General
camilla.compton@LIGO.ORG - posted 00:12, Friday 13 December 2019 (53876)
Shift transition to OWL

TITLE: 12/13 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 16mph Gusts, 12mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.84 μm/s
QUICK SUMMARY: We have some high sustained winds ~20mph and raised microseism. Otherwise all fine, locked 15h35m.

 

H1 General (SUS)
cheryl.vorvick@LIGO.ORG - posted 00:06, Friday 13 December 2019 (53875)
ETMY violin modes damped

I damped ETMY violin modes 18, 20, and 12, and all are below 1e-5.

Images attached to this report
H1 General
cheryl.vorvick@LIGO.ORG - posted 21:02, Thursday 12 December 2019 (53874)
Mid-Shift Update

H1 has been in Observe for 7 hours, useism is above 0.5um/s and steady, winds have spiked to 40mph, currently between 5mph and 20mph.

H1 CAL
vladimir.bossilkov@LIGO.ORG - posted 17:58, Thursday 12 December 2019 - last comment - 13:49, Tuesday 17 December 2019(53870)
UIM Dynamics propagated through tagged models and to python friendly filter files available to pyDARM

Following up from the last alog.

With the UIM dyanamics filter ready I propagated it through a set of new tagged sus models. I made a set of three to help make an informed decision on how to treat the new UIM dynamics - the complication being that there appears to be dynamics around the violin modes. I have split off a second tagsusdynamicalmodel.m so I don't interfere with livingston using the file.

I have created the following files using /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel_h1.m

/ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/
quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10093_h1etmx_options-rev10093_released-2019-12-12.mat
quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10090_h1etmx_options-rev10090_released-2019-12-12_noUIMdyn.mat
quadmodelproduction-rev9944_ssmake4pv2eMB5f_fiber-rev8442_h1etmx-rev10093_h1etmx_options-rev10093_released-2019-12-12_noviolins.mat

And from these I have generated the following files using /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/matlab_scripts/export_AAAI_SUS.m:

/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/pyDARM/matlab_scripts/

H1susdata_O3_new.mat
H1susdata_O3_new_noUIMdyn.mat
H1susdata_O3_new_noviolins.mat

Using these I can compare before are afters, namely:

compare_with_no_violin.png
compare_with_violin.png

In the case when I plotted against no violins, the MATLAB removes the highest most zero in the UIM dynamics, making the TF look like its going down more than it should be (an effective extra 1/f term). This is a problem in the current workflow that takes the tagged model and splits it up into low frequency terms and the violin terms, where I'd need to add a separate operation that takes the tagged model that has no violin modes to split off these dynamics. Looks like I will have to rethink.

Also the low frequency features are being changed by a bit - seems even matlab has its limits of tolerance when it comes to how many poles and zeros it can play with at a time.

I think a better approach is to have the dynamics added into the "H1susdata_O3" matrix directly by export_AAAI_SUS.m, and make no changes to the tagged susmodels as they stand. At the end of the day I am always drawing from the same file into which I have saved my dynamics... I can just do that later down the line even for the foton file.

Images attached to this report
Comments related to this report
vladimir.bossilkov@LIGO.ORG - 12:08, Friday 13 December 2019 (53884)

Looks like how I've treated my raw data for the higher frequencies (near the violin modes) is incorrect. It seems the violin mode part of the TF is conflating with my data in part of the processing.

When I was doing fitting, I was dividing out a TF that had no violin modes (as was my intention), but "umodelUIM_afterLock_freqresp" was being divided out instead in a pyDARM function

I'll be dividing out more correctly, removing any data >200 Hz and refitting now.

Images attached to this comment
vladimir.bossilkov@LIGO.ORG - 10:41, Monday 16 December 2019 (53921)

After following through:

Things look pretty good, however,

  • Matlab seems to skip a zero pole pair at low frequency
    • For the foton filters, this is irrelevant as the minreal function cuts that out anyway
    • Somewhat important for the pyDARM models, and they would be relying on this model.
  • there is a little dip in magnitude after the 150 Hz feature (visible in both attachments), that restores  restores after about 1kHz. (This is an artifact of fitting)
  • Phase is flipped 180 degrees after the 150 Hz feature
  • There is something at 300 Hz, which may be the first harmonic of the 150 Hz feature.
    • It is hard to tell its significance without careful measurement with fine scale sweep sine measurements in the future.
  • There is a small misfit the the magnitude gain visible in the pdf.
    • The fit gets the mganitude correct at the 150Hz feature
    • Any added poles and zeroes are <410 Hz such that the TF can be broken up into 3 constituent pieces:
      • Low frequency part <45 Hz
      • UIM dynamics: 45-410 Hz
      • Violins: >410 Hz
    • better fits would push poles into the region of violin modes
Images attached to this comment
Non-image files attached to this comment
vladimir.bossilkov@LIGO.ORG - 13:49, Tuesday 17 December 2019 (53945)

Vlad, Jeff

We investigated the source of this apparent blip at around 0.5Hz, and traced it down to Matlab doing funny things when converting from SS to ZPK model. In fact, we got different results for every input for each of the latest 4 Matlab versions we have available (actually 2016b and 2017b gave identically bad results).

I have made a number of plots which I hope will convince people that we should, and importantly *can*, migrate this step to python.

I have put up a whole lot of plots which have one consistent aspect: the SS model response never changes.  The most plots worth highlighting are  are:

Old_Model_2015b.png and New_Model_2015b.png: Here you can see that my addition of the UIM dynamics (which has no features at <45 Hz)
Old_Model_Python.png and New_Model_Python.png: Here you can see that when I evaluate the SS->ZPK transition in Python, I get consistent results, which are far closer to the SS model. [Blue and Red lines just about perfectly overlap]
Old_Model_Python_Full.png and New_Model_Python_Full.png: Here you can see results are consistent up to higher frequencies. The Matlab's frequency response is degrading at some step: either at the output of Matlab, or at the import of Python.
 
I recommend that SS models are extracted from Matlab and that further conversion to ZPK is done within Python for the future. Vlad is overseeing improvements to the flow of this data through to pyDARM and foton, and can implement this.
Images attached to this comment
H1 General
cheryl.vorvick@LIGO.ORG - posted 16:34, Thursday 12 December 2019 (53873)
OPS Eve Transition

TITLE: 12/13 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 34Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 8mph Gusts, 4mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.76 μm/s
QUICK SUMMARY: H1 is locked in Observe, useism is on the high side, and we've had some spikes in wind up to 20mph is the last hour.

Displaying reports 36901-36920 of 89199.Go to page Start 1842 1843 1844 1845 1846 1847 1848 1849 1850 End