Displaying reports 35521-35540 of 89220.Go to page Start 1773 1774 1775 1776 1777 1778 1779 1780 1781 End
Reports until 09:29, Wednesday 26 February 2020
H1 GRD (OpsInfo)
thomas.shaffer@LIGO.ORG - posted 09:29, Wednesday 26 February 2020 (55313)
Guardian Overviews Updated

I made some slight changes to the Guardian Overviews, mainly highlighting the SEI configuration nodes a bit better. SEI_ENV, SEI_CONF, SEI_DIFF are not in a grey box with their states shown. SUS_CONFIG seems to not really get used, so I made it smaller.

Images attached to this report
H1 OpsInfo (OpsInfo)
edmond.merilh@LIGO.ORG - posted 08:19, Wednesday 26 February 2020 - last comment - 08:38, Wednesday 26 February 2020(55311)
INJ_TRANS not Changing to INJECT_KILL for GRB?

15:30UTC I arrived on site.

15:35 I heard Verbal Alarms shouting about GRB Short - E365598 Tig Dur .016 and acknowledged

Anyway, those are my observations from this morning and food for thought regarding our current trial.

 

Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 08:38, Wednesday 26 February 2020 (55312)

Injections could come unannounced, so we need to be prepared for that.

INJ_TRANS will not go to INJECT_KILL when an external alert comes in, but it will automatically go to EXTTRIG_ALERT_ACTIVE as is shown in your screenshot of the log. This will do basically the same thing as INJ_KILL and will stay in that state for an hour. We manually take this node to INJ_KILL on GRBs for redundancy, making sure that there is no chance of an injection happening at that time.

The stand down time also is for site operations. We need to limit any activity on site, and make sure that maintenance and commissioning activities are delayed until after the stand down.

(I should change Verbal to handle the trial better).

LHO General
patrick.thomas@LIGO.ORG - posted 08:09, Wednesday 26 February 2020 (55310)
Ops Day Shift Start
TITLE: 02/26 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_CONF state: TEST_SWARM
    Wind: 2mph Gusts, 1mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.33 μm/s 
QUICK SUMMARY: SEI_ENV guardian node is in error.
H1 SEI
patrick.thomas@LIGO.ORG - posted 07:56, Wednesday 26 February 2020 - last comment - 09:36, Wednesday 26 February 2020(55309)
SEI_ENV user code error
See attached.
Images attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 09:36, Wednesday 26 February 2020 (55314)

Apparently SEI_CONF's earthquake state is spelled EARTH_QUAKE, so when SEI_ENV made the request for EARTHQUAKE, it couldnt find the state. Fixed.

H1 General (SQZ)
thomas.shaffer@LIGO.ORG - posted 06:42, Wednesday 26 February 2020 (55308)
Out of Observing to recycle SQZ_MANGER

Out from 14:34-14:36 UTC. H1:SQZ-OPO_REFL_DC_POWER was increasing past 1.15 and the range was starting to degrade.

I also noticed that the Observatory mode was set to Locking since around midnight, changed this back when we went back to observing.

LHO General
corey.gray@LIGO.ORG - posted 00:00, Wednesday 26 February 2020 - last comment - 19:58, Thursday 27 February 2020(55303)
EVE Shift Summary

TITLE: 02/26 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 119Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

H1's been locked the entire shift with a range hovering around 119Mpc.  There is an earthquake inbound squarely in the "Earthquake" region with R-Wave due to arrive around 8:25utc (1:25amPT).  We have a now have the new SEI_ENV guardian node active and ready to manage SEI_CONF in case it needs to transion to the EARTHQUAKE state. 

The GWIstat tool (and my Chirp phone app) saw H1 drop out of OBSERVING three times at the beginning of the shift for a few seconds (I chatted to Greg M about this.  (so this is why the Observing time and Lock time look different.)
LOG:

Comments related to this report
peter.shawhan@LIGO.ORG - 19:58, Thursday 27 February 2020 (55343)
The CHIRP app gets its detector status information from gwistat, so it makes sense that it would show the same status drop-out.
LHO General
corey.gray@LIGO.ORG - posted 20:02, Tuesday 25 February 2020 (55307)
Mid Shift Status

Smooth sailing with H1 locked for 5+hrs and a range which is trending slightly up (currently 119Mpc).

LHO VE
kyle.ryan@LIGO.ORG - posted 17:15, Tuesday 25 February 2020 (55306)
Removed GV19 and GV20's lead screw covers

Tyler G., Kyle R.

This will allow us to do the requisite gate valve inspection on March 3rd when we next operate GV20 (GV19 too?) as part of the scheduled EX turbo replacement. 

LHO General
corey.gray@LIGO.ORG - posted 16:09, Tuesday 25 February 2020 (55301)
Transition to Eve Summary

TITLE: 02/26 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
    SEI_CONF state: TEST_SWARM
    Wind: 7mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.26 μm/s 
QUICK SUMMARY:

Walked in to find a locked (1.25+hrs) and OBSERVING H1 post-Maintenance. (woo woo!)  Environmentally we are quiet for microseism & winds.

LHO General
patrick.thomas@LIGO.ORG - posted 16:04, Tuesday 25 February 2020 (55302)
Ops Day Shift Summary
TITLE: 02/25 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
INCOMING OPERATOR: Corey
LOG:

15:35 - 15:39 UTC Tumbleweed chipping close to end X
15:45 UTC Dropped out of observing. Observatory mode set to CALIBRATION. Running PEM injection.
16:00 UTC Observatory mode set to PREVENTIVE MAINTENANCE. SEI_CONF to SC_OFF_NOBRSXY.
16:00 UTC Jeff B. to cleaning area
16:01 UTC Karen to end Y
16:02 UTC Fire department through gate
16:03 UTC Kyle WP 8546
16:04 UTC Vanessa to end X
16:04 UTC Gerardo to IP5
16:05 UTC Hugh to HAM8
16:07 UTC Betsy to LVEA
16:21 UTC Jeff B. to end stations for garb inventory
16:24 UTC Fire department through gate
16:30 UTC Richard, Ken, fire department to end X
16:32 UTC Vanessa at end X
16:34 UTC Filiberto to end X, laser safety relay
16:43 UTC Camilla and TJ to LVEA, turn off TCS X and squeezer, mechanical room, turn off chiller, replace filter, turn on chiller, turn lasers back on
16:45 UTC Chandra to LVEA
16:50 UTC Rick and Jason to PSL enclosure for FSS work
16:59 UTC Vanessa leaving end X and heading to LVEA
17:02 UTC Chandra back
17:03 UTC Karen done at end Y
17:15 UTC APS through gate to end X
17:20 UTC Desert Green through gate
17:33 UTC Niko to optics lab
17:36 UTC TJ back
17:48 UTC TJ and Camilla to LVEA to turn on TCS and squeezer lasers
17:52 UTC Paradise water through gate
17:54 UTC LN2 delivery through gate to tank 8514371 (CP7) (end Y)
18:05 UTC Rick and Jason done
18:09 UTC TJ and Camilla to CER mezzanine to check on TCS HV
18:10 UTC Gerardo WP 8547
Jason, Rick, Patrick to PSL enclosure to restart Beckhoff machine
18:50 UTC Jeff B. done and going to LVEA
18:53 UTC Filiberto to beer garden to take pictures
18:54 UTC Niko out of optics lab
18:55 UTC TJ and Camilla back
18:56 UTC Jim starting a measurement on end Y
19:03 UTC Jason tweaking beam alignment into PMC
19:08 UTC Ken and fire department to corner station to disable RAFAR
19:14 UTC Jason done
19:19 UTC Dave restarting H1SEIPROC and DAQ
19:24 UTC TJ renaming guardian node
19:27 UTC Filiberto done
19:34 UTC Marc and Dick to PSL racks
Corner station SC turned back on
19:53 UTC Kyle done at end station
20:13 UTC Ken to LVEA entry way to get ladder
20:15 UTC Ken done
20:24 UTC Jeff J. back
20:26 UTC Gerardo done
20:39 UTC Jim done
20:44 UTC Dick and Marc back
20:45 UTC Starting relocking
20:46 UTC Observatory mode set to LOCKING
20:46 UTC Pepsi through gate
20:47 UTC Lock loss from LOCKING_ARMS_GREEN
20:48 UTC Tumbleweed chipping done
20:50 UTC Camilla done sweeping LVEA
21:14 UTC Fire alarm testing is complete. Richard to mid station.
21:24 UTC Tyler and Chris chipping tumbleweeds on X arm
21:28 UTC Lock loss from ENGAGE_SOFT_LOOPS
21:49 UTC Lock loss from POWER_10W
22:06 UTC APS through gate
22:10 UTC Lock loss from POWER_10W
22:59 UTC Observing
23:33 UTC Fire department, Ken and APS off site
H1 CDS
david.barker@LIGO.ORG - posted 15:39, Tuesday 25 February 2020 (55300)
Lock Loss Alert System, Guardian alerts now sent at any time

Shiela, Jenne, TJ, Dave:

Following discussion with Sheila, Jenne and TJ it was decided that the LLA system should send alerts when there is a squeezer oscillation requiring operator intervention. Previously, alerts were not sent when the IFO was in its target state of locked and observe.

The system now sends guardian alerts independent upon the IFO state. Alerts are latched once they are sent, preventing repeat alerts. When the guardian IFO_NOTIFY goes out of alert the latch is unset. The contacts' status are no longer cleared continually, instead they are only cleared when the IFO state changes.

H1 SEI
hugh.radkins@LIGO.ORG - posted 15:31, Tuesday 25 February 2020 (55299)
H2 HEPI Removal & Transport Fixturing Installation Progress --HAM7 and now HAM8 Done

WP 8384 Gerardo & Hugh, continuing from 54892:

Missed two weeks on this task but made up for that today.  HAM8 South Crossbeam removed but still needs crane & laydown.  Support Tubes all secure & SEI is ready for Transport.

Thanks to Gerardo for the much needed assists.

Photo is from the East side with South side to left.

Images attached to this report
H1 OpsInfo (CAL, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 15:16, Tuesday 25 February 2020 (55297)
Instructions on how to turn ON (and OFF) Calibration Line Comb Test During IFO Thermalization
J. Kissel

After the success of injection a large collection of extra/new calibration lines (i.e. a frequency "comb" of calibration lines) back on 2019-12-17 (see LHO aLOG 53951), and the results turned out to be quite interesting (see LHO aLOG 55182), the calibration group would like to repeat this measurement. However, it requires manual turn-off of these extra lines, and it requires that the data be taken for 2 hours, just after hitting NOMINAL_LOW_NOISE, and staying OUT of observation mode. Thus, it must get run-coordinator approval (which we already have), and it has to be done during a target of opportunity (T.O.O.; i.e. after a lock loss). Thus, I provide instructions here, in hopes that any one may start the measurement, if that T.O.O. arises. 

We only need this measurement once more, so please check in with me and/or Keita to see if (a) tonight / today is a good day for this measurement, or (b) we've already taken the measurement.

Here're the instructions to run the measurement:
    (1) Wait until the ISC_LOCK guardian has acquired past MAXIMUM_POWER 
    - It's not *imperative* when exactly you start the following *exact* when MAXIMUM_POWER finishes, but I haven't tested the robustness of the IFO against these lines at earlier stages (specifically -- between ENGAGE_SOFT_LOOPS and POWER_10W may not be able to tolerate these lines, but thus far that's anecdotal evidence).
    - It *is* imperative that you at least get steps 2 and 3 below done *before* we enter NOMINAL_LOW_NOISE.

    (2) From a terminal and run the script to turn on all the the new *PCAL* calibration lines,
    ~$ cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/CALCS_FE
  ~$ python3.5 setup_sensingfunction_callinecombs.py

    (3) From a terminal, open up the DTT template for the DARM calibration lines, and run it.
    ~$ cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/CALCS_FE
  ~$ diaggui 2019-12-17_H1DARMEXC_SpringMonitoring.xml
    hit RUN

    (4) From a terminal, open up an ndscope trend of the detuned SRC, optical spring frequency (squared; aka "f_s^2"); this is your metric for "doneness" of the measurement.
    ~$ NDSSERVER=nds2.ligo.caltech.edu ndscope H1:GDS-CALIB_F_S_SQUARED -w [-7200,0]&
    [you'll have to wait *very* patiently, for these 2 hours of live 16 Hz data to populate, but, don't worry, you've got time.]

    (5) Watch and wait as the ISC_LOCK guardian reaches NOMINAL_LOW_NOISE, and then wait there for ~2 hours, until the detuned optical spring frequency levels out around -10 Hz^2.

    (6) While you're waiting, trend the PCALX high frequency roaming line frequency,
    ~$ NDSSERVER=nds2.ligo.caltech.edu ndscope H1:CAL-PCALX_PCALOSC1_OSC_FREQ -w [-7200,0]&
    and find out what it has been during the last, most recent observation ready segment. Store that number; we'll call it PCALXHFLINEFREQ for use below.

    (7) Record the UTC times (and GPS times, if you're nice) when we hit NOMINAL_LOW_NOISE and when you deem that ~2 hours is up and you begin to turn off the measurement, and grab a screenshot of the trend of f_s^2.

    (8) Go through the "turn off" instructions below

    (9) Write an independent aLOG (with CAL as its primary task, and OpsInfo tagged) that you've completed this measurement, and shoot an email to Jeff Kissel and Evan Goetz to let them know you've completed the measurement

Here's how to "turn off" and/or revert to *actual* NOMINAL_LOW_NOISE:
    (1) Hit "STOP" on the above DTT template.

    (2) Go to the CALEX and CALEY SDF screens and REVERT all differences. REVERT. REVERT. DO NOT ACCEPT.

    (3) Set the high frequency PCALX line back to it's most recent roaming line frequency,
    caput H1:CAL-PCALX_PCALOSC1_OSC_FREQ PCALXHFLINEFREQ

Thank you!
H1 SEI (GRD, OpsInfo)
thomas.shaffer@LIGO.ORG - posted 15:09, Tuesday 25 February 2020 (55296)
Earthquake Automation Turned On

Jim and I, and the LLO SEI crew, have been trying to figure out the best way for the seismic system to handle earthquakes and the changing environmental conditions. These two intertwine a bit and will take some more work, effort, and time to get a solution to encompass both. For now, we are going to turn on ONLY the earthquake response.

We've been running the ENV_STAT node in the background for a few months and it suggests a transition to earthquake mode in a consistent and reliable manner. Alog53985 from back in December has a few sample plots for what this response looks like. Today, we've changed the name of the node from ENV_STAT to SEI_ENV, which will now manage SEI_CONF.  The conditions for when SEI_ENV will transition are currently as follows:

  1. SEISMON produces an alert that falls into our earthquake area on the SEIPlot. We are then transitioned to the state PREP_FOR_EARTHQUAKE. When SEI_ENV begins to see the Z peakmon channel (H1:ISI-GND_STS_CS_Z_EQ_PEAK_OUTMON) get above 400 that it will request for SEI_CONF to transition to Earthquake.
  2. Or if there is no SEISMON alert, but the peakmon signal gets above 1000, then it will immediately request SEI_CONF to go to the Earthquake.

Once in earthquake, it will stay here until the peakmon signal stays below a slightly higher threshold for 10 minutes. It will then transition SEI_CONF back to its nominal state.

There is more work to be done here to handle the more extreme environment cases, but this will be a good start.

H1 CDS (ISC, SUS, TCS)
filiberto.clara@LIGO.ORG - posted 12:54, Tuesday 25 February 2020 - last comment - 17:07, Tuesday 25 February 2020(55291)
ALS EX Laser interlock reconnected to safety system

WP 8543
FRS 14250

Safety system at EX was restarted this morning. Power cycling the system cleared the interlock errors for both the ALS (FRS 14250, alog 55171 ) and PCAL (alog 55260).

The temporary bypassed jumper was removed and the ALS laser interlock reconnected to the safety system. With system down, we moved the 24V power for the safety chassis to its own dedicated power supply.

Effected systems from this work were powered back on.

ALS EY laser
ALS EX laser
EX ESD HV
SQZ laser
TCSX/Y lasers

F. Clara, C. Compton, R. McCarthy, T. Shaffer, and P. Thomas

Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:07, Tuesday 25 February 2020 (55305)CAL, DetChar, INJ
For future reference and data quality flags, the total time that PCALX laser was down is as follows (based on trending the channel showing the PCALX laser diode current, H1:CAL-PCALX_LASERDIODECURRENT):
2020-02-19 00:16:57 UTC to 2020-02-25 17:38:49 UTC 
1266106635 to 1266687547
580912.0 seconds
161.36 hours
6.7 days.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 19:11, Monday 24 February 2020 - last comment - 15:50, Tuesday 03 March 2020(55278)
45 minutes of commissioning for DARM offset change tests

I measured the optical gain for different light levels on the DCPDs before and after lowering the 9MHz modulation depth.  We did this as we relocked. 

The scan started at 2:18:40 UTC Feb 23rd, and went until 3:05:23 UTC

 

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 10:49, Wednesday 26 February 2020 (55287)

Attached is a plot of the DCPD power vs optical gain during this test.  Although these two traces look similar when plotted this way, there is a consistent difference between the two, and fitting for the amount of junk light inboth cases gives 1.09 +/- 0.06 mA in the high modulation depth measurement, and 1.35+/- 0.06 mA in the low modulation depth case.  

While looking at this data I realized that I had made an error in an earlier alog about modulation depths, which is corrected in the comment now.  Based on the change in modulation depth (first scan taken with a 23.4dBm epics setting on driver, which means 0.189 radians modulation depth, second scan taken at 20.3dBm setting which means 0.159 radians), we would expect that carrier light in the interferometer would be reduced by 0.5% and the sideband power injected would be increased by 40% when the modulation depth is decreased. 

This result suggests that the junk light we are seeing is probably not the 9th order 9MHz mode which is near resonance in H1's OMC 46667.  

One explanation for this result could be that I made the test while the interferometer was still thermalizing.  The attached screenshot shows trends while the measurement was taken, the fastest part of the thermal transient was over. 

There was a 0.8% increase in the circulating power in the Y arm, 0.9% increase in the X arm, when the modulation depth was increased, so both of those are sligthly higher than we expected for the change in modulation depth.  It could be that an alignment set point changes when we change the 9MHz modulation depth, which is generating extra carrier junk light. 

Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 13:57, Wednesday 26 February 2020 (55316)

The increase in junk light after the 9MHz reduction made Keita and I ask ourselves why we are doing this reduction, and if the tests that motivated the change would have the same outcome in our current configuration.  It seems plausible that the reason this produces junk light (if it does) are related to TCS settings, spot positions and circulating power.

history of 9MHz modulation depth:

  • Sept 2016:
    • 9MHz reduction by 6dB added to guardian after power increase.  29983
    • OMC trans image changed with 6dB reduction in 9MHz; suggestion that 900 Hz peak is reduced by 9MHz reduction, 29817 I seem to remember that this change in the 900Hz peak was not repeatable, we were just being confused by noise which came and went.
    • Identification of 9th order 9MHz mode in transmission through OMC: 29395
  • Nov 2016:
    • 9MHz reduction which was done after power increase is removed from guardian because of locklosses, we weren't sure if it mattered for sensitivity.
  • April 2018:
    • EOM swapped, so dBm settings are not directly comparable before and after this time. 41435
  • late Oct 2018:  
    • Refl 9 slew rate limited: 44771
    • The first result in this alog looks dramatic but if you read all the comments and the story becomes much less clear.  The drive levels being compared aren't written in the alog, but I am infering from the plots that these are comparisons between 23dBm drive setting (nominal at the time, 0.184rad) and 17dBm (called redcued here, 0.130 radians) : 44781
  • Nov 2018:
    • increasing 9MHz by 6dB compared to nominal setting (of 20dBm) makes DARM worse, lowering it doesn't help 45173
    • I am not finding this discussion in the alog, but my memory is that Koji told us that the EOM driver is more noisy when operating at it's max power, so we probably have more 9MHz RIN when we operate at 26dBm on the driver. 
  • Mid Jan 2019: 
    • 46444 we were operating with a 20dBm setting on the 9MHz driver, (0.159 radians 55304) and reported that increasing the drive by 3dBm reduced the range by 10Mpc. (Also estimated sideband/carier ratios on OMC QPDs)
sheila.dwyer@LIGO.ORG - 15:50, Tuesday 03 March 2020 (55405)

Daniel suggested that we look at what happens to the BS alignment when the modulation depth changes, since AS36 is the signal used to control the BS alignment.  Jenne looked into this and found that the beam splitter doesn't react to the change in modulation depth, but SR2 and SRM both do.  The first attachment shows that this is mostly in pitch, but there is also a yaw reaction. The second attachment shows that the AS-C QPD seems to be the reason why changing this modulation depth changes the alignment of the SRC.  (You can see the change in AS_C before the SRC2 loop brings it back to it's error point by moving the alignment of SR2+SRM).  There is not much happening in the AS72 loop (SRC1), which you would expect if they are well diagonalized. 

This suggests that the amount of junk light we have on the DCPDs can be changed by changing our offset on AS_C.  We plan to try a test of this tomorow.

 

Images attached to this comment
H1 CAL (CAL, DetChar)
jeffrey.kissel@LIGO.ORG - posted 14:28, Monday 02 December 2019 - last comment - 15:30, Tuesday 25 February 2020(53624)
O3B Summary of High-Frequency Roaming Calibration Line Start Times
J. Kissel,

As we've done in O3A (see LHO aLOG 51245), I hold this space for documenting start times of high-frequency roaming calibration line sweeps to be used for estimating the sensing function uncertainty above 1 kHz.

(All times UTC)
2019-11-01 16:55:02 HIGH_FREQ_LINES guardian reinitialized for the Start of O3B, starting at 4001.3
2019-11-12 18:35:25 data not found on ndscope while only shortly at last data point, 1001.3,  [CAL EX / EY front-end models restarted, and filter coefficients updated; see LHO aLOG 53188 LHO aLOG 53210]
resumes at
2019-11-12 18:38:37 re-started at 4001.3 Hz
2019-11-21 00:49:47 re-started at 4001.3 Hz
2019-11-29 14:40:20 re-started at 4001.3 Hz (and not yet finished)
Comments related to this report
sudarshan.karki@LIGO.ORG - 13:53, Wednesday 18 December 2019 (53974)CAL
 Start Date       Starttime        Endtime
2019-11-01      
1256662520       1257619135
2019-11-12       1257619135       1258332605
2019-11-21       1258332605       1259072078
2019-11-29       1259072078       1260382861
2019-12-14       1260382861       (not yet finished)
sudarshan.karki@LIGO.ORG - 16:09, Monday 06 January 2020 (54317)

Start Date       Starttime        Endtime
2019-11-01       
1256662520       1257619135

2019-11-12       1257619135       1258332605

2019-11-21       1258332605       1259072078

2019-11-29       1259072078       1260382861

2019-12-14       1260382861       1261341875    

2019-12-25       1261341875       1262275805

2020-01-05       1262275805       (not yet finished)

sudarshan.karki@LIGO.ORG - 11:03, Monday 10 February 2020 (55008)CAL

Start Date       Starttime        Endtime
2019-11-01       
1256662520       1257619135

2019-11-12       1257619135       1258332605

2019-11-21       1258332605       1259072078

2019-11-29       1259072078       1260382861

2019-12-14       1260382861       1261341875     

2019-12-25       1261341875       1262275805

2020-01-05       1262275805       1263263360

2020-01-17       1263263360       1264044992

2020-01-26       1264044992       1265150433

2020-02-07       1265150433       (not yet finished)

jeffrey.kissel@LIGO.ORG - 15:30, Tuesday 25 February 2020 (55298)
Start Date       Starttime        Endtime
2020-02-07       1265150433       1265939082

2020-02-17       1265939082       lost because PCALX interlock was inadvertently tripped during the majority of this sweep.

I *should* have restarted the sweep upon the fix of the problem today, but was distracted by trying to install a frequency comb and forgot to trend this before we hit OBSERVATION_READY. Had I, I probably would have re-initialized the HIG_FREQ_LINES guardian to restart a new sweep. Ah well. The first OBSERVATION_READY segment that PCALX returns to functionality is at 1266706798 (2020-02-25 22:59:40 UTC), with a frequency of 1001.3 Hz.
The guardian should take care of "restarting the sweep" at 4001.3 Hz on the next nominal low noise stretch.
Images attached to this comment
H1 ISC
sheila.dwyer@LIGO.ORG - posted 17:45, Monday 15 April 2019 - last comment - 16:28, Tuesday 25 February 2020(48513)
modulation depths

This is just a summary so that this is written in one place in the log:

Koji measured the modulation depths for 9 and 45 MHz using an OSA after installing the new EOM: 41435  For the 9 MHz Koji measured gamma =0.191 for an epics setting of 23.6dBm, which is used during lock acquisition.  We reduce this in low noise to 20dBm, giving us the final modulation depth of 0.1352  (That is the whole story for 9MHz).

After that Daniel and company moved the EOM driver out of the PSL enclosure and added an RF combiner/amplifier, (41889) which increased the drive power for 45MHz by +1.83dBm compared to the time of Koji's measurement.  The modulation depth measured with an epics setting of 27dBm (used for lock acquisition) should have a modulation depth of 0.243 assuming the EOM response measured by Koji. In low noise we use an EPICS setting of 24dBm, so we should expect 0.172 modulation depth for 45 in full lock.   (These numbers are a little different from Daniels because he used the EOM response from G1800724 rather than Koji's measurement).

Craig and Georgia also measured modulation depths by exciting RFAM and measuring intensity noise after the OMC (47113) but those results aren't agreeing well with the numbers that Koji and Daniel posted. 

Comments related to this report
sheila.dwyer@LIGO.ORG - 16:28, Tuesday 25 February 2020 (55304)

The above is wrong!  Let me try again:

Koji measured the modulation depths for 9 and 45 MHz using an OSA after installing the new EOM: 41435 

9 MHz:

For the 9 MHz Koji measured gamma =0.191 radians for an epics setting of 23.6dBm, meaning that we are getting 0.220 rad/V.  Durring lock acquistion we are now using 23.4dBm out of the EOM driver, meaning that our acquisition modulation depth is now 0.189 rad, in low noise we are using 20.4dBm meaning that our modulation depth is 0.159 radians in low noise  

45 MHz:

Koji's measurement for 45 MHz indicates that 0.239 rad/V delivered to the EOM (which is different from the epics setting, which was 27dBm at that time).  After that Daniel and company moved the EOM driver out of the PSL enclosure and added an RF combiner/amplifier, (41889) which increased the drive power for 45MHz by +1.83dBm for the same epics setting compared to the time of Koji's measurement.  The modulation depth measured with an epics setting of 27dBm (used for lock acquisition) should have a modulation depth of 0.233 assuming the EOM response measured by Koji. In low noise we use an EPICS setting of 24dBm, so we should expect 0.177 modulation depth for 45 in full lock.   (These numbers are a little different from Daniels because he used the EOM response from G1800724 rather than Koji's measurement).

Craig and Georgia also measured modulation depths by exciting RFAM and measuring intensity noise after the OMC (47113) but those results aren't agreeing well with the numbers that Koji and Daniel posted. 

Displaying reports 35521-35540 of 89220.Go to page Start 1773 1774 1775 1776 1777 1778 1779 1780 1781 End