Displaying reports 41481-41500 of 88807.Go to page Start 2071 2072 2073 2074 2075 2076 2077 2078 2079 End
Reports until 04:13, Friday 26 April 2019
H1 AOS
jeffrey.bartlett@LIGO.ORG - posted 04:13, Friday 26 April 2019 (48779)
Ops Owl Mid-Shift Summary
   Good first half of the shift. 

   The IFO has been locked for the past 15.75 hours,and continuously Observing for 9 hours. Winds are light and the microseism has been declining over the past 2 hours. There were several mid-sized (mag4.5 to 5.5) earthquakes in and around the Pacific that rung up the microseism. They were not powerful enough to cause any difficulties.

  
H1 General
jeffrey.bartlett@LIGO.ORG - posted 00:30, Friday 26 April 2019 (48778)
Ops Owl Shift Transition
Ops Shift Transition: 04/26/2019, Owl Shift 07:00 – 15:00 (00:00 -08:00) - UTC (PT)
State of H1: Locked at NLN
Intent Bit: Observing
Weather: Light scattered clouds; No rain in the forecast; Winds are Calm to Light Air, with temperatures in the mid-50s.
Primary 0.03 – 0.1Hz: 0.9um/s
Secondary 0.1 – 0.3Hz: 0.07mu/s
Outgoing Operator: Corey
Quick Summary: IFO and observing, range is 110.3Mpc, with 35.3W of power. Primary microseism is a bit rung up from a mag 5.0 EQ in the Philippines and a mag 5.5 EQ in Chile, but this is causing no problems. Currently running in triple coincidence observing.    
LHO General
corey.gray@LIGO.ORG - posted 00:18, Friday 26 April 2019 (48768)
EVE Shift Summary

TITLE: 04/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 113Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:

Other than two separate events knocking us out of OBSERVING, it has been a nice shift.  And seismically it is really calm & quiet. (but I said that last night, too!)  
LOG:

H1 SQZ (OpsInfo, SQZ)
corey.gray@LIGO.ORG - posted 19:29, Thursday 25 April 2019 (48776)
1:37-2:11 Bumped Out Of Observing Due To Squeezer (& Kept Out Due To Operator)!

1:37:23:  Bumped to COMMISSIONING due to SQZ/OPO unlocked!  (this happened while I was out of the Control Room!)

1:38:39:  Looks like the SQZ Manager took care of everything and returned SQZ_MANAGER to the Nominal SQUEEZING state on its own.  But when I returned I did not notice H1 was out of OBSERVING!  (If I was a good operator I should have first checked VERBAL for anything while I was out, and then should have seent we were out by looking at some of our wall monitors.)

2:11 Back to OBSERVING!  (It was a this time I noticed we were out of Observing because I was Reloading the GWI.stat medm webpage on nuc1 (luckily it dies frequently, and it raised my attention!)

Text of SQZ_MANAGER node log is attached as a pdf.

Summary:  Always check your H1 after stepping out of the Control Room!!  Don't be like me and keep us out of OBSERVING for ~30min!!  :-/

Non-image files attached to this report
H1 TCS (TCS)
corey.gray@LIGO.ORG - posted 18:31, Thursday 25 April 2019 - last comment - 08:44, Friday 26 April 2019(48775)
0:55-1:06utc: Bumped Out Of OBSERVING Due To TCS ITMy CO2 Laser Losing Lock

0:55 H1 Bumped OUT of Observing.

This was found to be due to an "unlocked TCS_ITMy_CO2 laser".  Looking at NDScope (see attached screenshot), the laser power took a jump up from ~50.16W and the TCS_ITMY_CO2 guardian node spent a few minutes at the FIND_LOCK_POINT adjusting an offset (see attached pdf of log file).  Eventually the guardian returned to its nominal state, of LASER_UP (at 1:01utc).  It had a "new pzt setpoint of 50.536W".

At this point, it looked like everything was good to go to Observing, so at 1:06utc, I returned H1 to Observing.  

SummaryTCS ITMy CO2 laser was unlocked for a few minutes & Guardian restored laser.  However, laser power changed from 50.16W to 50.536W.  I have not seen this before.

Images attached to this report
Non-image files attached to this report
Comments related to this report
thomas.shaffer@LIGO.ORG - 08:44, Friday 26 April 2019 (48783)

This is normal. When the CO2 laser goes to reacquire lock, it will scan with its PZT to find a point where it has good buildup. This point changes from lock to lock due to a variety of reasons, so it's possible to have slightly different powers from the laser itself. [[abs(50.16 - 50.54)/50.16 = 0.76% change]]

Not too big of a deal since we control the power down stream anyway.

H1 CDS
david.barker@LIGO.ORG - posted 16:36, Thursday 25 April 2019 (48769)
Trending Hardware Watchdogs to verify operation

I've added a TRENDS button to the lower left of the HWWD MEDM screen. This allows you to trend the HWWD channels for 1, 2 and 3 months in the past.

How to read the trends: a value of 2 means the photodiode RMS exceeded its threshold, this is most probably due to physical movement of the test mass. A value of 8 means the LED draw current fell below threshold, this most probably means the suspension was under high drive and its monitor voltage dropped.

ITMX, ITMY show val=8 at a medium rate. ETMY shows val=8 at a high rate (starting about 6 weeks ago). ETMX is quiet, just showing few val=2 over two months ago.

Lines which go off the top of the y-axis are most probably bogus DAQ values and should be ignored.

 

Images attached to this report
H1 OpsInfo (DetChar)
sheila.dwyer@LIGO.ORG - posted 16:31, Thursday 25 April 2019 (48770)
control room glitch monitor changed

Patrick Thomas, Sheila

This morning on the detchar call, we discussed switching the glitch monitor that is displayed in the control room from DMT-Omega to omicron, since there are differences in the glitches which show up in the two tools and it seems that people have more confidence in the omicron glitches being real (or having a real impact on the searches) right now.  

The url for the omicron monitor is:

https://ldas-jobs.ligo-wa.caltech.edu/~detchar/monitor/omicron/

We have displayed this on the bottom half of nuc0 and Patrick is updating the operator instructions (FOM) wiki.  

H1 AOS
sheila.dwyer@LIGO.ORG - posted 16:24, Thursday 25 April 2019 - last comment - 17:41, Wednesday 08 May 2019(48767)
a couple of hours of commissioning

We took about 4 hours of time for commissioning today:

A quick summary of the cross over measurements (Jenne, Sheila):

Motivation:

Measurement:

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 17:41, Wednesday 08 May 2019 (49127)CAL, SUS

Here are the measurements from this time plotted against a pyDARM model.  

The blue line is a model of what the L2 LOCK IN1/IN2 measurement is expected to look like based on the pyDARM model of the actuators.  The green dots are measurements of this crossover made on April 3rd, they are plotted here just so that you can see some higher frequency data (we didn't retake any higher frequency measurements)

These measurements could be explained by a coupling of the length drive to either the angle of the optic through a mechanical coupling or to the angular sensor, the ASC loop then tries to actuate in response, but there is a coupling from angle back to length because we are not doing a nice job of a frequency dependent angle to length decoupling.  When we turned off the A2L decoupling, by setting the scalar gains to 0 but not running the ADS so that the spot positions stayed in their normal positions.  In principle, a more accurate frequency dependent A2L decoupling could be used to reduce this effect.

In 47824 and 47982 we saw that when we turned off the L2A decoupling filters, which increased the gain of the PUM by getting rid of the L2A2L coupling that comes from having our spots well off center and not routing the L2A output through the A2L decoupling, we had a crossover instability around 8 Hz.  This was solved by turning off the 4.5Hz boost in the PUM lock filter, which doesn't make complete sense but it is plausible given these emasurements that the problem with the boost was caused by these angular cross couplings, especially if there are features that are not resolved in this measurement.

Non-image files attached to this comment
LHO General
corey.gray@LIGO.ORG - posted 16:18, Thursday 25 April 2019 (48766)
Transition to Eve Summary

TITLE: 04/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 111Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s 

microseism is lower than yesterday and noticeably under the 50th percentile (Yay!), and winds are generally calm (under 10mph).
QUICK SUMMARY:

H1 was in OBSERVING when I arrived (and has been for 50+min).

H1 ISC (DetChar)
sheila.dwyer@LIGO.ORG - posted 15:10, Thursday 25 April 2019 - last comment - 17:43, Thursday 25 April 2019(48762)
Using both REFL sensors for CARM

I've edited the guardian to use the sum of REFL A and REFL B 9I for CARM control, which should give us sqrt(2) lower frequency noise at low frequencies (below 1kHz) where the frequency noise is limited REFL shot noise.  

To summarize the story of these two sensors, in case Detchar is interested in looking at these:

We've had this REFL B channel available since it was installed in November and phased in early December.  Since then REFL B has been an out of loop sensor for frequency noise, since Refl A has been the only one used in the loop.  The Refl A readback was calibrated into volts on April 16th, so that REFL A +refl B have the same units. 

This tuesday (April 23rd) I switched the CARM loop from using REFL A to REFL B, as a temporary test because the better whitening on the REFL A readback means that it has better ADC noise clearance to use as a out of loop sensor.  This was only temporary, and we continued to use only REFL A in the CARM loop since then.

Craig and Georgia also increased the gain of the CARM loop by 3dB on Tuesday which helps to suppress the frequency noise (due to IMC shot noise) above 1 kHz.  Since then, it has been noted (Ed's shift summary) that there was extra high frequency noise at the beginning of the lock that went away a few minutes into the lock.  It may be that the optical gain of REFL 9 is higher in the first few minutes of the lock, and that the CARM loop has some gain peaking with the higher gain.  

In this lock, starting at about 19 UTC April 25th, we saw this happening again.  Jenne and I turned down the CARM gain by a few dB, and saw that this also had an impact on the power build ups. A few minutes later, the higher gain (12dB on IN1 gain) was fine.  

 

Comments related to this report
jenne.driggers@LIGO.ORG - 15:46, Thursday 25 April 2019 (48763)

This is the list of SDFs that I accepted in the observe snapshot to capture these changes.

Images attached to this comment
craig.cahillane@LIGO.ORG - 17:43, Thursday 25 April 2019 (48774)
Spectra of REFL A and B for the two different configurations: 48773.
H1 General
cheryl.vorvick@LIGO.ORG - posted 15:09, Thursday 25 April 2019 - last comment - 16:01, Thursday 25 April 2019(48761)
OpsDay Update

TITLE: 04/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Patrick is covering OPS 3PM-4PM local (22:00-23:00 UTC) then Corey
SHIFT SUMMARY: H1 is in NLN, commissioning
LOG:

Currently On Site / at MX/MY / in LVEA / taking measurements:

Comments related to this report
patrick.thomas@LIGO.ORG - 16:01, Thursday 25 April 2019 (48765)
22:26 UTC Observing
H1 SQZ (SQZ)
nutsinee.kijbunchoo@LIGO.ORG - posted 14:58, Thursday 25 April 2019 (48760)
Intensity servo is having trouble keeping up

Today the intensity servo has been railing negative. It seems like it's trying to get more power through the coupler in order to meet the set point which normally would set the OPO input to the coupler to 20mW.

The changes I made today to try to mitigate the issue:

Adjusted SHG crystal temperature to optimize the conversion efficiency, this is to get more green out. Although we were already getting 40mW. Though I don't think that was the issue.

Adjusted half waveplate to get more power through when the servo is off so the default power sits around 18mW into the coupler.

SHG_PWR_TRANS_OFFSET went from -325 to -342

AOM low limit changed to -9000 this corresponds to nealy 20mW into the coupler.

I think the pump laser drifting is the problem here. When the red output goes down, green output goes down and the servo keep asking for more power until it hits the limit. The laser is still acting up as I'm writing this alog. I think it's going to keep hitting the rail.

Images attached to this report
H1 OpsInfo
jenne.driggers@LIGO.ORG - posted 13:06, Thursday 25 April 2019 (48759)
Changed DIAG_MAIN to not report for ALS fiber polarization when in NomLowNoise

The notification of ALS fiber polarization percentage is still super annoying.  I just changed DIAG_MAIN to only report on the ALS fiber polarization when we're acquiring lock.  It will not put up a message when we're in NomLowNoise anymore.

H1 ISC (OpsInfo)
jenne.driggers@LIGO.ORG - posted 10:10, Thursday 25 April 2019 - last comment - 15:52, Thursday 25 April 2019(48756)
BS Pit ASC not offloading to top mass

Last night, due to some guardian fast EZCA connection errors (alog 48744 and comment), Georgia and Corey had to manually turn on the BS pitch offloading.  Since Ed was unable to load the new version of the guardian that has the fast EZCA parts removed (alog 48747), he ran the old code and seems to have gotten a very similar error.  It looks like he accepted the SDF diffs (alog 48753), including the fact that BS offloading of pitch to the top mass is off.  So, at least for the entirety of this lock so far, we've been running without any pit offloading for the BS top mass.  Things seem okay for now (current lock is 7.75 hours and going), so I'm not going to turn it on just yet. 

Comments related to this report
jenne.driggers@LIGO.ORG - 10:41, Thursday 25 April 2019 (48757)

I believe that I have found and fixed the errors in the non-fez version of ISC_GEN_STATES.py, so I have put Georgia's modifications back in (with the fixes).  We just lost lock (I don't know why, but I hadn't reloaded or changed anything in the running code), so I've reloaded the guardian and hopefully next lock we won't be plagued by this problem again.

jenne.driggers@LIGO.ORG - 15:52, Thursday 25 April 2019 (48764)

We got through the acquisition sequence okay, and the BS pit top mass offloading is on as it should be, so I think we can call this one case closed.

H1 PSL
jason.oberling@LIGO.ORG - posted 10:22, Wednesday 24 April 2019 - last comment - 16:33, Thursday 25 April 2019(48731)
Noting an Interesting Feature - PMC Trans Changes with IFO Lock

Matt H. at LLO noticed that their PMC transmission changes slightly with IFO lock state (alog here) and asked me if we see the same thing.  Never having noticed this before, I took a look.  Sure enough, we do, see attached; when the IFO is locked PMC transmission drops slightly.  The change is slight (~0.3 W), so I don't think this is an issue, just noting it here so folks are aware.

I should note that we are using the new, all-bolted PMC while LLO is still using the original aLIGO PMC.  Also, the movement in PMC transmission immediately followed by it's loss, return, and resulting ramp-up seen on the right half of the plot were caused by yesterday's PSL enclosure incursion and small water leak repair.

Images attached to this report
Comments related to this report
georgia.mansell@LIGO.ORG - 16:33, Thursday 25 April 2019 (48771)

I had a closer look at exactly when the PMC transmission drops - as Adam noted at LLO, it occurs when we turn on the ISS second loop. The second loop is first engaged (with AC the coupling servo on) quite early in our lock acquisition sequence - in the DRMI_LOCK_CHECK_ASC state of the ISC_LOCK guardian, this causes the first step in PMC power in the attached screenshot. We get a second kick when we DC couple the ISS second loop, at the end of the lock acquisition sequence.

Images attached to this comment
H1 ISC (ISC)
craig.cahillane@LIGO.ORG - posted 00:18, Wednesday 24 April 2019 - last comment - 17:40, Thursday 25 April 2019(48717)
Frequency Noise Measurements today
Today I took some frequency noise measurements.  Posted are the results and the file locations.

I increased CMB IN1 from +9dB to +12dB.  We should always do this after thermalization of the IFO.  
We can't increase the CARM digital gain too much or we'll hit the FSR with the CARM UGF.  We have to wait for the optical gain to decay and replace it with digital gain.
POP18 NORM MON is at ~47 cts now, but is at around 60 when we first lock.  We should wait until we hit around 50 cts, then up the CARM gain.


IMC Locked Alone at 35 W
- IMC REFL stitched spectra      : /ligo/home/craig.cahillane/Git/IFO/IMC/data/Spectra/StitchedSpectrum_20190423_IMC_REFL_IMON_Spectra_IMCAlone_35WInput_IN1_22dB_SecondBoostOn.txt
- IMC OLG                        : /ligo/home/craig.cahillane/Git/IFO/IMC/data/TFs/20190423_IMC_OLG_IMCAlone_35WInput_IN1_22dB_SecondBoostOn.txt
- IMC MCL Crossover              : /ligo/home/craig.cahillane/Git/IFO/FrequencyNoise/data/20190423_IMC_MCL_Crossover.xml
- MC2 to IMCF TF (Refs 16 and 17): /ligo/home/craig.cahillane/Git/IFO/FrequencyNoise/data/20190423_MC2_to_IMCF_35W.xml 

Full Lock at 35 W
- REFL B Spectra               : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190423_REFL_B_35W_Input_CMBIN1Gain_9dB.txt
- REFL A Spectra               : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190423_REFL_A_35W_Input_CMBIN1Gain_9dB.txt
- CARM OUT2 Spectra            : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190423_CARM_OUT2_35W_Input_CMBIN1Gain_9dB.txt
- IMC REFL Spectra             : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190423_IMC_REFL_35W_Input_CMBIN1Gain_9dB.txt
- IMC TEST1 Spectra            : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190423_IMC_TEST1_35W_Input_CMBIN1Gain_9dB.txt

- CARM OLG w/ CMB IN1 = +9dB   : /ligo/home/craig.cahillane/Git/IFO/CARM/data/TFs/20190423_213400_20190423_CARM_OLG_FullLock_35W_Input_60mV_Exc.txt
- CARM OLG w/ CMB IN1 = +12dB  : /ligo/home/craig.cahillane/Git/IFO/CARM/data/TFs/20190423_214036_20190423_CARM_OLG_FullLock_35W_Input_60mV_Exc_12dB_CMBIN1Gain.txt
- IMC OLG w/ CMB IN1 = +9dB    : /ligo/home/craig.cahillane/Git/IFO/IMC/data/TFs/20190423_212909_IMC_OLG_FullLock_35W_Input_0dBm_Exc.txt
- IMC OLG w/ CMB IN1 = +12dB   : /ligo/home/craig.cahillane/Git/IFO/IMC/data/TFs/20190423_214142_IMC_OLG_FullLock_35W_Input_0dBm_Exc_12dB_CMBIN1Gain.txt

- LSC MCL Crossover            : /ligo/home/craig.cahillane/Git/IFO/FrequencyNoise/data/20190423_LSC_MCL_Crossover.xml
- MC2 to REFL9 Cal TF (Current): /ligo/home/craig.cahillane/Git/IFO/FrequencyNoise/data/20190423_MC2_to_IMCF_35W.xml  (This is the same as the MC2 to IMCF template above.  The current references are in full lock, Refs 16 and 17 are from IMC locked alone.)

- Frequency Noise Injs     +9dB: /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240118413_GPSstart_FrequencyNoise_CMB_EXC_inj_2000_7000_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240118674_GPSstart_FrequencyNoise_CMB_EXC_inj_600_2000_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240118847_GPSstart_FrequencyNoise_CMB_EXC_inj_175_600_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240119020_GPSstart_FrequencyNoise_CMB_EXC_inj_50_175_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240119191_GPSstart_FrequencyNoise_CMB_EXC_inj_15_50_Hz.pkl
- Frequency Noise Injs    +12dB: /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240119574_GPSstart_FrequencyNoise_CMB_EXC_inj_2000_7000_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240119754_GPSstart_FrequencyNoise_CMB_EXC_inj_600_2000_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240119927_GPSstart_FrequencyNoise_CMB_EXC_inj_175_600_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240120100_GPSstart_FrequencyNoise_CMB_EXC_inj_50_175_Hz.pkl
                                 /ligo/home/controls/craig.cahillane/Git/IFO/FrequencyNoise/data/Injections/20190423/1240120272_GPSstart_FrequencyNoise_CMB_EXC_inj_15_50_Hz.pkl

- LSC MCL Noise Injection  +9dB: /ligo/home/controls/craig.cahillane/Git/IFO/MCL/data/Injections/20190423/1240123470_GPSstart_MCL_inj_5_200_Hz.pkl
- LSC MCL Noise Injection +12dB: /ligo/home/controls/craig.cahillane/Git/IFO/MCL/data/Injections/20190423/1240120857_GPSstart_MCL_inj_5_200_Hz.pkl

- PRCL Noise Injection     +9dB: /ligo/home/controls/craig.cahillane/Git/IFO/PRCL/data/Injections/20190423/1240123215_GPSstart_PRCL_inj_5_200_Hz.pkl
- PRCL Noise Injection    +12dB: /ligo/home/controls/craig.cahillane/Git/IFO/PRCL/data/Injections/20190423/1240121461_GPSstart_PRCL_inj_5_200_Hz.pkl

- Intensity Noise Inj      +9dB: /ligo/home/controls/craig.cahillane/Git/IFO/IntensityNoise/data/Injections/20190423/1240122973_GPSstart_Intensity_inj_10_7300_Hz.pkl
- Intensity Noise Inj     +12dB: /ligo/home/controls/craig.cahillane/Git/IFO/IntensityNoise/data/Injections/20190423/1240122556_GPSstart_Intensity_inj_10_7300_Hz.pkl


I upped the CMB IN1 gain from 9 to 12 dB for a couple of CARM and IMC OLGs.  From the CARM OLG (PDF 3), we seem to have about 3 dB of clearance from the FSR with CMB IN1 = +12dB.  
We know that frequency noise is starting to limit us with our squeezing levels.
Images attached to this report
Non-image files attached to this report
Comments related to this report
craig.cahillane@LIGO.ORG - 19:22, Wednesday 24 April 2019 (48745)
Quick comparison of the frequency noise injections with low (CMB IN1 +9dB) and high (CMB IN1 +12 dB) CARM gain.
PDF 1 shows four ASDs:
1) DARM during a 2 to 7 kHz frequency noise injection into the common mode board, with +9dB on the CMB IN1 gain slider.
2) DARM during a 2 to 7 kHz frequency noise injection into the common mode board, with +12dB on the CMB IN1 gain slider.
3) Nominal DARM
4) Frequency noise projection into DARM for +9dB

The frequency noise levels apparent in DARM decreased when the CARM analog gain was increased.  This is because we have squashed the frequency noise imposed by the IMC shot noise.  REFL B with high CARM gain was not measured yesterday.

The CARM to DARM coupling TF did not change between gain changes.  This is expected.
Non-image files attached to this comment
craig.cahillane@LIGO.ORG - 20:11, Wednesday 24 April 2019 (48749)
Some long term questions to answer:

- Unmodeled CARM OLG hump at 18 kHz 
-- Daniel claims this is 9 MHz resonating in the arms, we can try to model this
-- Was not apparent in Evan's thesis Figure 2.7
-- Not that apparent at Livingston (LLO alog 37620)

- Make sure OMC control noise not limiting DARM at current frequency noise levels
-- Georgia made OMC controls projections in the current noise budget at 30 W, showed noise way below DARM.
-- Controls noise not linear with frequency noise (alog 45768)

- Model shot noises for CARM, IMC
-- Can get a quick win of sqrt(2) from using both REFL detectors
-- Cyclostationary noise on REFL
-- Should increase optical gain of IMC to squash its shot noise so it doesn't appear in DARM
--- Increase modulation depth for IMC
--- Add fast shutter and rotation stage to IOT2L to control power levels on IMC REFL
georgia.mansell@LIGO.ORG - 20:12, Wednesday 24 April 2019 (48750)

Attaching a screenshot shows DARM with the two LSC-REFL_SERVO_IN1 gains (grey = 12dB, red = 9dB). The improved frequency noise suppression is visible in DARM above 3.5 kHz, and also in the squeezer BLRMS (bottom time series), which looks at DARM at 4.68 kHz.

Images attached to this comment
craig.cahillane@LIGO.ORG - 17:40, Thursday 25 April 2019 (48773)
Additional CARM Spectra from 0.5 Hz to 5 MHz with the new changed configurations:

CMB IN1 = +12 dB:
REFL B    : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190425_REFL_B_35W_Input_CMBIN1_12dB.txt
REFL A    : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190425_REFL_A_Spectrum_35W_Input_CMBIN1_12dB.txt
CARM OUT2 : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190425_CARM_OUT2_Spectrum_35W_Input_CMBIN1_12dB.txt
IMC REFL  : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190425_IMC_REFL_Spectrum_35W_Input_CMBIN1_12dB.txt
IMC TEST1 : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190425_IMC_TEST1_Spectrum_35W_Input_CMBIN1_12dB.txt

CMB IN1 = +6dB, CMB IN2 = +6dB  (split control for REFL A and B)
REFL B    : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190425_REFL_B_Spectrum_35W_Input_CMBIN1_6dB_CMBIN2_6dB.txt
REFL A    : /ligo/home/craig.cahillane/Git/IFO/CARM/data/Spectra/StitchedSpectrum_20190425_REFL_A_Spectrum_35W_Input_CMBIN1_6dB_CMBIN2_6dB.txt

Posted are the comparison spectra of the three configurations of CARM we've been playing with:

+9 dB, REFL A sensor controlling CARM +12 dB, REFL A sensor controlling CARM +12 dB, Split REFL A and B sensors (+6 dB on each of the CMB Inputs)

We can see that the CARM loop is gain limited at ~2kHz, since the REFL B spectrum decreased from increasing the CARM gain (Dark blue vs Light Blue). We can also see that REFL shot noise is dominating the spectrum from 3kHz down, from the switch to split sensor control (Light blue vs Orange)
Non-image files attached to this comment
H1 CAL
jeffrey.kissel@LIGO.ORG - posted 16:33, Wednesday 17 April 2019 - last comment - 09:56, Friday 26 April 2019(48578)
Calibration Line Heights Adjusted, Fixed DEMOD Phase Rotation, Sensing Function Sweeps Taken -- Cavity Pole / kappa_C Estimate Returns to Reference Model Values
J. Driggers, J. Kissel, L. Sun

Today, during the calibration measurement time, we've done the following:
(1) Tuned the calibration line heights such that the uncertainty of each line is now roughly 0.2%. 
    2019-04-17_TuningCalibrationLineAmplitudes_Uncertainty.png shows the time series of the uncertainty for all calibration lines over many hours before and after the line amplitude change -- the middle section is where they were turned off for the standard suite of calibration sweeps; before they were at their former value, after they were at their current value.

(2) We realized the discrepancy between GDS production of kappa_C (the relative optical gain correction) and f_cc (the cavity pole frequency) and CAL-CS was because in the heat of battle yesterday, we neglected to update the value of the necessary one clock-cycle delay to 410.3 Hz in the PCAL DEMOD -- i.e. it errantly remained as the delay value at the former calibration line frequency at ~331 Hz. Fixing this error returned the time-dependent correction factors to the expected values from the reference model: kappa_C = 1.00 +/- 0.01, and f_cc = 410.6 +/- a few Hz (as opposed to the brief period yesterday between after the calibration line frequencies and now, where the cavity pole was reporting in the 425 Hz region, and the optical gain correction was reporting 0.97).
    2019-04-17_FixingPCALDEMODPhase_410Hz_Fixes_TDCFs.png shows a screenshot of the current values.

(3) We gather a collection of broad-band PCAL injections, as well as the standard sensing function sweeps.
Times of broad-band PCAL injections: 2019-04-17 20:13:20 UTC for ~2 minutes, and again at Apr 17 2019 20:15:31 UTC.
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs
        2019-04-17_H1_DARM_OLGTF_SS_5to1100Hz_15min.xml
        2019-04-17_H1_PCAL2DARMTF_BB.xml
        2019-04-17_H1_PCAL2DARMTF_SS_5t1100Hz_10min.xml
The data remains remarkably consistent with the reference model (see 2019-04-17_H1_sensingFunction_mcmcModel_vs_measurement.pdf ).
We've stacked all the recent sensing function measurements without correcting for time dependence to form an estimate of the frequency dependent, time-independent systematic erro with a Gaussian process regression, and it shows the same consistency (see 20190416_ref_model_H1_sensingFunction_GPR_on_AllSensingMeasurements.pdf)

More details to come.
Images attached to this report
Non-image files attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 08:38, Tuesday 23 April 2019 (48690)CAL

Here is a look at one of the excursion that happened in the front-end estimation of kappa_tst (first one seen in this summary page). The attached plot show various estimations of kappa_tst that happens in the front-end. It also show uncertainty estimation in the calculation of calibration line ratios. We see that when the uncertainty in the estimation of calibration line ratios exceeds set threshold of 0.02, it triggers the gating function. Since the glitch happened to be in the DARM_ERR (IFO) both PCAL_LINE1/DARM_ERR and TST/DARM_ERR ratios get uncertainties higher than 0.02 as in this case. The KAPPA_TST_GATE_UNC_INPUT which is finally used, according to model, supposed to be maximum of the two uncertainties but in this case it is the minimum of the two (KAPPA_TST_GATE_UNC_INPUT is on top of SUS_LINE3_UNCERTAINTY). Since it is still larger than 0.02, gating is triggered. However the gated kappa_tst values don't make any sense. It supposed to be avoid the excursion in the raw kappa_tst but it seems to change the level values of kappa_tst. This function need to checked (this is a user defined c function block). The signals after that make sense.

Images attached to this comment
shivaraj.kandhasamy@LIGO.ORG - 22:52, Thursday 25 April 2019 (48777)

Similar plot for LLO which also show similar problem with gating function block.

Images attached to this comment
joseph.betzwieser@LIGO.ORG - 09:56, Friday 26 April 2019 (48788)
Turns out the switch blocks used were defaulting to a logic comparison of >= 0 instead of > 0.  Which means the first input was always being passed.  I'll update this in the common CAL_CS_MASTER.mdl file and we should be able to push that next Tuesday.

The gating issue is a bit trickier.  As far as I can tell the gate is doing what its supposed to do.  At the time the uncertainty rises above threshold, it freezes then and there as shown in Shivaraj's plots.  The problem is, since the uncertainty calculation is basically on a cadence of 10 seconds, there's a 10 second gap between the demodulated low pass starting to respond to a large excursion and the 

I think this means we need to put 10 seconds (or maybe a touch longer) buffer between the kappa value input to the gate, so that the coherence corresponds represents the data coming in instead of data that came in during the last 10 seconds.  A 163840 or so sample ring buffer is doable, but I'll have to modify a C code user block to do so.
Displaying reports 41481-41500 of 88807.Go to page Start 2071 2072 2073 2074 2075 2076 2077 2078 2079 End