Displaying reports 56481-56500 of 78053.Go to page Start 2821 2822 2823 2824 2825 2826 2827 2828 2829 End
Reports until 08:00, Thursday 01 October 2015
LHO General
thomas.shaffer@LIGO.ORG - posted 08:00, Thursday 01 October 2015 (22146)
Ops Owl Shift Summery
LHO General
thomas.shaffer@LIGO.ORG - posted 07:43, Thursday 01 October 2015 - last comment - 08:49, Thursday 01 October 2015(22145)
Relocked but Injection while LLO is down

Relocked @ 14:38

Sheila wants to do a quick injection while LLO is down.

Comments related to this report
sheila.dwyer@LIGO.ORG - 08:49, Thursday 01 October 2015 (22148)

excitation ended just before we got a GRB alert, but I was making an excitation at the time of the GRB (LLO was not in observing so we were taking advantage of some single IFO time to investigate noise at 78 Hz in DARM that may come from EX).  

When we heard the alert I stopped the dtt session and Jeff B went to observing, but there were times even when we weren't in observing that there were no excitations running.  Grace DB lists 1127747079.41 as the event time for the first GRB alert, and unfortunately my excitation was running at that time.  My last excation was ramping down by 1127747090 as shown in the first attached dataviewer screenshot, where the GRB time is approximately in the middle of the plot, so I was exciting the ETMX ISI at the time of the event. 

The two channels that I was putting excitations on were H1:ISI-ETMX_ST2_ISO_Y_EXC and H1:ISI-ETMX_ST2_ISO_Y_EXC.  These were white noise excitations that produced ISI motions of 0.1 nm/rt Hz at 20 Hz with an amplitude that slowly drops off as the frequency increases until 100 Hz (0.02 nm/rt Hz).  The excitation was bandbassed from 20Hz-200 Hz.  They produced no features in the DARM spectrum, although they were intended to excite the peaks at 78-80 Hz.  

Images attached to this comment
LHO General
thomas.shaffer@LIGO.ORG - posted 07:14, Thursday 01 October 2015 (22144)
Lockloss

Lockloss @ 13:59 UTC

ITMX saturation, and it tripped SUS OMC WD. No obvious reason for lockloss.

H1 CDS
thomas.shaffer@LIGO.ORG - posted 06:17, Thursday 01 October 2015 - last comment - 07:56, Thursday 01 October 2015(22142)
Some red poping up on CDS Overview at Mid Y

H1IOPPEMMY and H1PEMMY both started to report errors for FE, ADC, and DDC on the CDS Overview around 12:55 UTC. There was a red around TDS, so I checked out the timing screen and there seems to be a problem with Port 13 "Invalid or no data".

Since this is only PEM at MidY, I have NOT taken us out of Observing.

Comments related to this report
james.batch@LIGO.ORG - 07:56, Thursday 01 October 2015 (22147)
The I/O chassis is no longer visible to the computer h1pemmy.  This is not critical to the operation of the interferometer. This can wait until Tuesday to fix unless someone desperately needs PEM data from MY.
LHO General
thomas.shaffer@LIGO.ORG - posted 04:30, Thursday 01 October 2015 (22141)
Ops Owl Mid Shift Report

Humming along @ 75Mpc. Have had a handful of glitches during my shift, but the RF noise seems to be in control for now.

H1 CAL (DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 00:36, Thursday 01 October 2015 - last comment - 18:06, Friday 28 October 2016(22140)
Official, Representative Calibrated ASD for the Start of O1 -- Now With Time Dependent Corrections Displayed
J. Kissel, for the Calibration Team

I've updated the results from LHO aLOG 21825 and G1501223 with an ASD from the current lock stretch, such that I could display the computed time dependent correction factors, which have recently been cleared of systematics (LHO aLOG 22056), sign errors (LHO aLOG 21601), and bugs yesterday (22090). 

I'm happy to say, that not only does the ASD *without* time dependent corrections still fall happily within the required 10%, but if one eye-balls the time-dependent corrections and how they would be applied at each of the respective calibration line frequencies, they make sense.

To look at all relevant plots (probably only interesting to calibrators and their reviewers), look at the first pdf attachment. The second and third .pdfs are the money plots, and the text files are a raw ascii dump of respective curves so you can plot them however or whereever you like. All of these files are identical to what is in G1501223.

This analysis and plots have been made by
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/produceofficialstrainasds_O1.m
which has been committed to the svn.
Non-image files attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 18:06, Friday 28 October 2016 (30973)

Apparently, this script has been moved to a slightly different location. The script can be found at

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/DARMASDs/produceofficialstrainasds_O1.m

LHO General
thomas.shaffer@LIGO.ORG - posted 00:02, Thursday 01 October 2015 (22139)
Ops Owl Shift Transition
H1 General
travis.sadecki@LIGO.ORG - posted 00:00, Thursday 01 October 2015 (22138)
OPS Eve shift summary

Title: 9/30 Eve Shift 23:00-7:00 UTC (16:00-24:00 PST).  All times in UTC.

State of H1: Observing

Shift Summary: No news is good news.  Locked my entire shift in Observing.  Only 4 ETMy saturations.  Seismic and wind calm.  No RF45 issues.

Incoming operator: TJ

Activity log:

23:38 ETMy saturation

3:07 ETMy saturation

4:56 ETMy saturation

6:36 ETMy saturation

H1 General
betsy.weaver@LIGO.ORG - posted 23:05, Wednesday 30 September 2015 - last comment - 20:40, Thursday 01 October 2015(22137)
Balance of OBSERVE.SNAP files copied to userapps

Following on from where Hugh left off in alog 21412, I have copied the OBSERVE.snap files from their target area to their appropriate userapps/...h1xxxxx_observe.snap area in prep for committing them to svn.  I have copied these files for: SUS, ALS, ISC, CALEX, CALEY.  Hugh had already done LSC LSCAUX ASC ASCIMC OMC OAF TCSCS CALCS, and all SEI.  The balance (AUX IOP ODC and PEM) have no observe.snap file since it is unneccessary.  The ones that I've just copied will be committed to svn tomorrow.

Comments related to this report
betsy.weaver@LIGO.ORG - 20:40, Thursday 01 October 2015 (22176)

This eve, I finished committing the moved-over OBSERVE.snap files to the svn.  I also committed the lsc OBSERVE.snap since we had changed a few settings (DHARD Y FM2 for example) recently.

H1 CAL (DetChar, ISC, SUS, SYS)
jeffrey.kissel@LIGO.ORG - posted 22:23, Wednesday 30 September 2015 - last comment - 22:44, Wednesday 30 September 2015(22135)
The Case For and Consequences of Flipping the ESD Bias on H1 ETMY
J. Kissel, B. Weaver

This aLOG serves more as a discussion of recent results and future impact, but I figure the aLOG is the most visible place to cover a message that needs discussion among many disparate groups. I discuss the latest evidence for charge evolution on the H1 ETMY test mass, why it matters for that test mass alone, and what it will impact when we do change it (especially in regards to calibration). Conclusions are in bold at the bottom of each section.

----------------
Why I think it's looming:

    :: kappa_TST is the calibration group's measure of the change in actuation strength of the test mass stage as a function of time, and since H1 ETMY is the only DARM actuator, it's showing that the H1 ETMY ESD / TST / L3 stage's strength has increased. kappa_TST has shown an increase in actuation strength in ~3 [weeks] of a ~2%: See blue trace in the top subplot of the first attachment. (copied from LHO aLOG 22082). 
	
    :: H1 ETMY is showing steadily increasing charge since we've last flipped the ESD bias, as expected: See the trend in all subplots of the second attachment (copied from LHO aLOG 22062).
	
	> Recall that actuation strength changes as a function of charge, proportional to the ratio of effective bias voltage from charge to the bias voltage we apply intentionally, Vc / Vb.

	> Regrettably, we've measured the charge so infrequently since the start of the run, that it's dicey to corroborate between charge and actuation strength. But I'll try anyway. If you take Betsy's last and second to last charge measurement points, which are bounding Sudarshan's kappa_TST time span, you can eyeball that the change is 15 [V] effective bias. This means an actuation strength change of 15 / 380 = 4%. Given the error bars on the charge measurements and how few measurements we've had, is totally consistent with the ~2% change seen by tracking the calibration lines. Also, if we increase the effective bias voltage from charge, on an already positive bias, then than you're increasing the bias voltage, which is consistent with an increase in actuation strength, since the linear component of the actuation force is proportional to the bias voltage.

	> The current rate of change of ETMY is ~3V / week. But also recall that the rate of change has *changed* every time we've flipped the bias; see Leo's analysis in LHO aLOG 20387 which (for ETMY) quotes 1.75V / week for one epoch and 5V  / week for the next. So it's going to be subjective when we flip the bias sign, and we have to keep close tabs on it, especially since the error bars on an individual day's measurement require many data points to show a pattern. However, the evidence up to now suggests that even though a bias sign flip changes the rate, it stays at a constant until the bias sign is flipped again.

    :: The calibration group -- now that we finally have removed all systematic errors, fixed all problems, and cleaned up all sign confusion -- finally believe that the live-tracking of this slow time dependence is working, and is tracking the real thing as far as these very long term trends (see first attachment again). But we have not yet started applying them, because we haven't figured out the right *time scale* upon which to apply them, and applying them takes some debugging. See the third attachment (this is new). These time dependent parameters are being computed at a rate of 16 [Hz], but if you look at say, one 420 [sec] chunk, the record wanders all over within a roughly +/-3% swing on a ~10 [sec] cadence. We have no evidence to believe this the test mass actuation strength is changing this fast, so this is likely noise. So at this point, unless we're willing to lose a day or so of data (i.e. enough lock stretches where can get a sense of a pattern) where we're testing out, I don't think we *can* start correcting for these factors

    :: The calibration group's requirement is to stay within a 10% and 5 [deg] uncertainty over the course of the entire run. We already know from Craig's uncertainty analysis of ER8 (see fourth attachment, copied from LHO aLOG 21689), that -- without including time-dependence -- the reference time model (in reference to which all time-dependent parameters are calculated), has an uncertainty of 5% and a little more that 5 [deg]. The change in actuation strength means that we'll have a systematic error that grows with time, and since we're fighting for what's left of the 10% uncertainty budget, this changein actuation strength that we've tracked over these first three weeks of the run of 2-3% are significant.

    :: If we let the charge continue to gather at its current rate, that means we'll gather an additional 11 more weeks, that means another ~35 [V], for a total accumulated charge of 60 [V], and a total actuation strength change of 60 / 380 = 15%, which is *well* outside of our budget.

In summary, we're going to need to change the bias on H1 ETMY sign soon.
-------------------

What will be impacted when we change it:

    :: First, foremost, and easiest, when we change the digital bias sign, it changes the sign of the test mass actuation stage. That means we have to compensate for it in order for the DARM loop to remain stable. That means we change the sign of the gain in the L3 DRIVEALIGN bank, i.e. H1:SUS-ETMY_L3_DRIVEALIGN_L2L_GAIN. Done. easy.
    :: Now on to the hard stuff -- making sure it doesn't affect the calibration.
In the CAL-CS replication of the reference model of the DARM loop is the obvious first impact

        > Of course, we need to flip sign of the digital replica of the drive align matrix, H1:CAL-CS_DARM_FE_ETMY_L3_DRIVEALIGN_L2L_GAIN
        > We also need to flip the sign of the replica of the ESD itself, H1:CAL-CS_DARM_ANALOG_ETMY_L3_GAIN 
    
    :: The not-so obvious impact is on the tracking of the actuation strength. Because the ESD / TST / L3 calibration line is injected downstream of the DARM distribution, but upstream of the drive-align bank, the sign of the analysis code must change. We've already been bitten by this once -- see LHO aLOG 21601

        > That means we need to update the EPICs records that capture the reference model values at the calibration line frequencies
        > *That* means we need to create a new DARM model parameters set, which also maps all of the changes to ESD / TST / L3 sign change (just like CAL-CS)
        > *THAT* means we ought to take a new DARM Open Loop Gain and PCAL to DARM TF, to verify that the parameter set is valid.
        > *THAT* means we need a fully functional and undisturbed IFO (i.e. this can't just be done on a Tuesday, or as a "target of oppurtunity" when L1 is down), *after* the sign flip that we're will to take out of observation mode for an hour or so

    :: Once we have a new, validated model, then we push the new EPICs records into the CAL-CS model, and everything that needs updating should be complete. 

    :: There's then the "offline" work of updating the SDF system -- but this must be done quickly because it prevents you from setting the observation intent bit. For these particular records which have very small numbers, there're precision issues that means you must hand-edit the .snap files (see, e.g. LHO aLOGs 22079, LHO aLOG 22065, 21014), which is another hour of time, instead of just hitting "accept all" and "confirm" in the SDF GUI interface like any other record.

In summary If we are properly prepared for this, and everyone is on deck ready for it, I think this all can be done in a (human, but very long, human) day, especially if we have a *team* of dedicated calibrators, detector engineers, and some commissioning support. Further It's not a "just do it on a Tuesday" or "just do it target of oppurtunity when L1 is down" kind of task and should each of the above steps should be done slowly and methodically.

Also, I should say that is room for improvement in just about every part of this bias sign flipping process, but all of those would require non-science run friendly changes to front-end code, RCG infrastructure, and a good bit of time commissioning.
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 22:44, Wednesday 30 September 2015 (22136)ISC, SUS, SYS
Why isn't this an issue with any of the other test masses?

Both site's ETMX's ESD drivers are turned entirely off during low-noise operation, so they have no impact on noise or actuation strength.

For lock acquisition, 
At H1, ETMX is used, but whether the ETMX acqusition ESD has a 10-20% change in actuation strength over the course of the run does not matter for calibration or lock acquisition. Regrettably H1 ETMX bias is currently negative, so its current trend of positive charge means that actuation strength will be decreasing over the run. But, again, a 10-20% drop in strength won't matter. The only place where I could see us run into trouble is whereever we're on the edge of stability / robustness, like acquiring during very high winds, or if we've designed the L3/L1 ALS DIFF cross-over particularly agressively (which I hope we have not). 

At L1, they've recently switched to using ETMY for lock acquisition, then transitioning to their *ITMX* driver, switching the ETMY driver to low noise, and then transisition back. So only their ETMY ESD strength matters. And, goh'bless'm, they flipped their bias sign *just* before the run started with the charge a -40 [v] effective bias, so they'll have enough time at their current rate charging positive ~10 V/month, or 2.5 V / week then to go through zero right around the end of the run. That means the impact of this on their actuation strength will be slowly reducing over time. 

At H1, the ITMs do not have any ESD drivers (high or low voltage), so they also need no consideration.

At L1, only ITMX has an ESD driver, but again, it's currently used in transit to low noise, so it doesn't play a role in calibration, and assuming the loops were designed with ample margin, a 10-20% change in actuation strength shouldn't be a bother.

In summary H1 ETMY is the only test mass where we will ne to play such terrible games during O1.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 22:07, Wednesday 30 September 2015 - last comment - 16:55, Thursday 01 October 2015(22107)
bilinear coupling of End X motion to DARM follow up

I'm posting an early version of this alog so that people can see it, but plan to edit again with the results of the second test. 

Yesterday I took a few minutes to follow up on the meausrements in alog 21869.  This time in addition to driving TMS I drove the ISI in the beam direction to reproduce the motion caused by the backreaction to TMS motion. We also breifly had a chance to move the TMSX angle while exciting L. 

The main conclusions are:

Comparison of ISI drive to TMS drive for X and Y

The attached screenshot shows the main results of the first test (driving ISIs and TMSs).  In the top right plot you can see that I got the same amount of ISI motion for 3 cases (driving ETMX ISI, TMSX, ETMY ISI) and that driving TMSY with the same amplitude as TMSX resulted in a 50% smaller motion of the ISI.  Shaking the TMS in the L direction induces a larger motion measured by the GS13s in the direction perpendicular to the beam, than in the beam direction, which was not what I expected.  I chose the drive strength to get the same motion in the beam direction, so I have not reproduced the largest motion of the ISI with this test. If there is a chance it would be interesting to also repeat this measurement reproducing the backreaction in the direction perpendicular to the beam.  

The middle panels of the first screnshot show the motion measured by OSEMs. TMS osems see about a factor of 10 more motion when the TMS is driven than when the ISI is driven.  The signal is also visible in the quad top mass osems, but not lower down the chain.  For the X end, the longitudnal motion seen by the top mass is about a factor of 2 higher when the TMS is excited than when the ISI is excited (middle left panel), which could be because I have not reproduced the full backreaction of the ISI to the TMS motion.  However, it is strange that for ETMY the top mass osem signal produced by driving TMS is almost 2 orders of magnitude larger than the motion produced by moving the ISI. It seems more likely that this is a problem of cross coupling between the osems than real mechanical coupling. The ETMY top mass osems are noisier than ETMX, as andy lundgren pointed out (20675).  It would be interesting to see a transfer function between TMS and the quad top mass to see if this is real mechanical coupling or just cross talk. 

In the bottom left panel of the first screenshot, you can compare the TMS QPD B yaw signals.  The TMS drive produces larger QPD signals than the ISI drive, as you would expect for both end stations.  My first gues would be that driving the ISI in the beam direction could cause TMS pitch, but shouldn't cause as much yaw motion of the TMS.  However, we see the ETMX ISI drive in the yaw QPDs, but not pitch.  The Y ISI drive does not show up in the QPDs at all.  

Lastly, the first plot in the first screenshot shows that the level of noise in DARM produced by driving the ETMX ISI is nearly the same as what is produced by driving TMSX.  Since the TMS motion (seen by TMS osems) is about ten times higher when driving TMS, we can conclude that this coupling is not through TMS motion but the motion of something else that is attached to the ISI. Driving ETMY ISI produces nothing in DARM but driving TMSY produces a narrow peak in DARM. 

For future reference:

I drove ETMX-ISI_ST2_ISO_X_EXC with an amplitude of 0.0283 cnts at 75 Hz from 20:07:47 to 20:10:00UTC sept 29th

I drove 2000 cnts in TMSX test L from 20:10:30 to 20:13:30UTC 

I drove ETMY-ISI_ST2_ISO_Y_EXC with an amplitude of 0.0612 cnts at 75 Hz from 20:13:40 to 20:16:30UTC 

I drove 2000 cnts in TMSY test L from 20:17:10 to 20:20:10UTC

Driving TMSX L while rastering TMS position and angle

I put a 2000 cnt drive on TMSX L from about 2:09 UTC September 30th to 2:37 when I broke the lock. We found a ghost beam that hits QPD B when TMS is misaligned by 100 urad in the positive pitch direction.  There is about 0.5% as much power in this beam as in the main beam (not accounting for the dark offset).  I got another chance to do this this afternoon, and was able to move the beam completely off of the QPDs, which did not make the noise coupling go away or reduce it much.  We can conclude then scatter off of the QPDs is not the main problem.  There were changes in the shape of the peak in DARM as TMS moved, and changes in the noise at 78 Hz (which is normally non stationary) Plots will be added tomorrow.

Speculation

There is a feature in the ETMX top mass osems (especially P and T) around 78 Hz that is vaugely in the right place to be related to the excess noise in the QPDs and DARM. Also, Jeff showed us some B&K measurements from Arnaud (7762) that might hint at a Quad cage resonance at around 78 Hz, although the measured Q looks a little low to explain the spectrum of the TMSX QPDs or the feature in DARM. One could spectulate that the motion driving the noise at 78Hz  is the quad cage resonance, but this is not very solid.  Robert and Anamaria have data from their PEM injections that might be able to shed some light on this.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 16:37, Thursday 01 October 2015 (22157)

The units in the attached plots are wrong, there GS13s are calibrated into nm, not meters

sheila.dwyer@LIGO.ORG - 16:55, Thursday 01 October 2015 (22159)

This morning I got the chance to do some white noise excitations on the ETMX ISI, in the X and Y directions.  The attached screenshot shows the result, which is that for ISI motion a factor of 10-100 above the normal level, for a wide range of frequencies, no noise shows up in DARM.  SO the normal level of ISI motion in the X and Y directions is not driving the noise in DARM at 78 Hz.  We could do the same test for the other ISI DOFs to eliminate them as well.

Images attached to this comment
H1 General (DetChar)
laura.nuttall@LIGO.ORG - posted 18:44, Wednesday 30 September 2015 (22132)
RF45 flag since driver swap

For the last UTC day (30th Sept 00:00 UTC - 1st Oct 00:00 UTC) the RF45 flag only removed 60 seconds of science data. Since the swap it has only marked 180 seconds of time. This could mean things are better or I need to retrain the flag since the swap, investigating...

H1 INJ (CAL, DetChar, INJ)
christopher.biwer@LIGO.ORG - posted 16:12, Wednesday 30 September 2015 - last comment - 19:35, Wednesday 30 September 2015(22124)
Summary of injection tests with PCAL and DARM
J. Kissel, C. Biwer, S. Karki

We tested using PCAL as a hardware injector. We did 3 injections into the traditional H1:CAL-INJ_TRANSINET_EXC used for hardware injections in the past and 3 into H1:PCALX_SWEPT_SINE_EXC to test using PCAL for hardware injections.

All injections used the 15Hz test waveform from aLog 21838.

The first injection into H1:CAL-INJ_TRANSINET_EXC was successful. The command line was:
 awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC.txt

We then tried an injection into H1:PCALX_SWEPT_SINE_EXC but it was unsuccessful because the injection channel list for the hinj account was restricted and did not include this channel. The command line was:
 awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ.txt

D. Barker added H1:PCALX_SWEPT_SINE_EXC to the allowed excitation channels list for the hinj account and we had a successful set of injections:
 awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ.txt
 awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ_Trial2.txt
 awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_PCALINJ_Trial3.txt
 awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC_Trial2.txt

We then tried another injection but NDS happened to fail as we tried the injection and the injection was unsuccessful:
 awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC_Trial3.txt

The problem was quickly fixed and we set up to retry the injection. It was successful:
 awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d >> 2015-09-30_PCALInjTest_DARMCTRLEXC_Trial4.txt

The logs are attached.

The end times of the injections should be:
DARM 1             1127683334.985681295
PCAL 1              1127683905.985681295
PCAL 2              1127684170.985681295
PCAL 3              1127684464.985681295
DARM 2             1127684765.985681295
DARM 3             1127685142.985681295

As we were doing the injections we made omega scans, they can be found in aLog 22123.
Non-image files attached to this report
Comments related to this report
christopher.biwer@LIGO.ORG - 17:21, Wednesday 30 September 2015 (22129)DetChar, INJ
I've recovered the injections by match filtering using the injection template.

Label        GPS time             SNR      chi-squared  newSNR
DARM1     1127683334.986 17.99     24.70            17.99
DARM2     1127685142.986 17.97     33.40            17.46
DARM3     1127685142.986 17.04     23.94            17.04
PCAL1      1127683905.986 9.61       44.27            8.48
PCAL2      1127684170.985 10.10     41.44            9.14
PCAL3      1127684464,986 10.54     73.52            7.48

It looks like PCAL injections were a bit quieter in SNR.
sudarshan.karki@LIGO.ORG - 17:38, Wednesday 30 September 2015 (22130)CAL, INJ

I see a factor of two missing in my transfer function measurement as well in the same direction that would produce low SNR through Pcal. Some clues but investigation ongoing.

peter.shawhan@LIGO.ORG - 19:35, Wednesday 30 September 2015 (22133)
The PCAL injections (numbers 2,3,4 in the set of 6) appear to be inverted, besides being too small by close to a factor of 2 -- see the attached plots.  The ESD injections look rather good by comparison.
Images attached to this comment
Non-image files attached to this comment
H1 INJ (CAL, DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 14:18, Wednesday 30 September 2015 - last comment - 06:21, Thursday 01 October 2015(22121)
Testing PCAL as Hardware Injector
C. Biwer, J. Kissel

Taking advantange of single IFO time to run PCAL vs DARM hardware injections. More details later.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:11, Wednesday 30 September 2015 (22122)
PCAL Injection tests complete. PCAL X has been restored to nominal configuration.


Injection           Approx End time (GPS)
DARM 1              1127683335
PCAL 1              1127683906
PCAL 2              1127684171
PCAL 3              1127684465
DARM 2              1127684766
DARM 3              1127685143

More details and analysis to come.

These were run from the hwinjection machine as hinj.
Usual DARM Command
awgstream H1:CAL-INJ_TRANSIENT_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d

PCAL Command:
awgstream H1:CAL-PCALX_SWEPT_SINE_EXC 16384 coherenttest1from15hz_1126257408.out 1.0 -d -d

We turned OFF the 3 [kHz] PCAL line during the excitation.

We're holding off on observation mode to confir about other single IFO tests we can do while L1 is down.
christopher.biwer@LIGO.ORG - 15:14, Wednesday 30 September 2015 (22123)DetChar, INJ
I've attached omega scans of the PCAL and DARM injections.

All injections used the 15Hz template from aLog 21838.
Images attached to this comment
andrew.lundgren@LIGO.ORG - 17:08, Wednesday 30 September 2015 (22127)DetChar, INJ
The SNRs of the Pcal injections seem a bit lower than intended. Omega reports SNR 10.5 for the injection through the normal path, which is about right. But for the Pcal injections, the SNRs are 5.5, 7.6, and 7.2. Note that these are the SNRs in CAL-DELTAL; someone should check in GDS strain as well. Links to scans below:

Standard path
Pcal 1
Pcal 1
Pcal 1
peter.shawhan@LIGO.ORG - 06:21, Thursday 01 October 2015 (22143)INJ
*** Cross-reference: See alog 22124 for summary and analysis
H1 AOS
robert.schofield@LIGO.ORG - posted 20:31, Tuesday 29 September 2015 - last comment - 16:42, Thursday 01 October 2015(22094)
Danger using DTT with NDS2 data on a channel whose sampling rate has changed

When DTT gets data from NDS2, it apparently gets the wrong sample rate if the sample rate has changed. The plot shows the result. Notice that the 60 Hz magnetic peak appears at 30 Hz in the NDS2 data displayed with DTT. This is because the sample rate was changed from 4 to 8k last February.  Keita pointed out discrepancies between his periscope data and Peter F's. The plot shows that the periscope signal, whose rate was also changed, has the same problem, which may explain the discrepancy if one person was looking at NDS and the other at NDS2. The plot shows data from the CIT NDS2. Anamaria tried this comparison for the LLO data and the LLO NDS2 and found the same type of problem. But the LHO NDS2 just crashes with a Test timed-out message.

Robert, Anamaria, Dave, Jonathan

Non-image files attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 17:24, Wednesday 30 September 2015 (22128)

It can be a factor of 8 (or 2 or 4 or 16) using DTT with NDS2 (Robert, Keita)

In the attached, the top panel shows the LLO PEM channel pulled off of CIT NDS2 server, and at the bottom is the same channel from LLO NDS2 server, both from the exact same time. LLO server result happens to be correct, but the frequency axis of CIT result is a factor of 8 too small while Y axis of the CIT result is a factor of sqrt(8)  too large.

Jonathan explained this to me:

keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo.caltech.edu L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 2
Channel                  Rate  chan_type
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          2048      raw    real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo-la.caltech.edu L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 3
Channel                  Rate  chan_type
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384   online    real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          2048      raw    real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4

As you can see, both at CIT and LLO the raw channel sampling rate was changed from 2048Hz to 16384Hz, and raw is the only thing available at CIT. However, at LLO, there's also "online" channel type available at 16k, which is listed prior to "raw".

Jonathan told me that DTT probably takes the sampling rate number in the first one in the channel list regardless of the actual epoch each sampling rate was used. In this case dtt takes 2048Hz from CIT but 16384Hz from LLO, but obtains the 16kHz data. If that's true there is a frequency scaling of 1/8 as well as the amplitude scaling of sqrt(8) for the CIT result.

FYI, for the corresponding H1 channel in CIT and LHO NDS2 server, you'll get this:

keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo.caltech.edu H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 2
Channel                  Rate  chan_type
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          8192      raw    real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo-wa.caltech.edu H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 3
Channel                  Rate  chan_type
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384   online    real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          8192      raw    real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4

In this case, the data from LHO happens to be good, but CIT frequency is a factor of 2 too small and magnitude a factor of sqrt(2) too large.

Images attached to this comment
jonathan.hanks@LIGO.ORG - 17:40, Wednesday 30 September 2015 (22131)

Part of this that DTT does not handle the case of a channel changing sample rate over time.

DTT retreives a channel list from NDS2 that includes all the channels with sample rates, it takes the first entry for each channel name and ignores any following entries in the list with different sample rates.  It uses the first sample rate it receives ans the sample rate for the channel at all possible times.  So when it retreives data it may be 8k data, but it looks at it as 4k data and interprets the data wrong.

I worked up a band-aid that inserts a layer between DTT and NDS2 and essentially makes it ignore specified channel/sample rate combinations.  This has let Robert do some work.  We are not sure how this scales and are investigating a fix to DTT.

jonathan.hanks@LIGO.ORG - 16:42, Thursday 01 October 2015 (22158)

As followup we have gone through two approaches to fix this:

  1. We created a proxy we put between DTT & NDS2 for Robert that was able to strip out the versions of the channels that we are not interested in. This was done yesterday and allowed Robert to work. This has allowed Robert to work but is not a scalable solution.
  2. Jim and I investigated what DTT was doing and have a test build of DTT that allows it to present a list with multiple sample rates per channel. We have a test build of this at LHO. There are rough edges to this, but we have filed a ECR to see about rolling out a solution in this vein in production (which would include LLO).
H1 ISC
evan.hall@LIGO.ORG - posted 16:51, Saturday 25 July 2015 - last comment - 20:19, Wednesday 30 September 2015(19895)
REFL9Q dark noise

Summary

Attached is the dark noise of REFL9Q, along with an estimate of the shot noise and a conversion of these noises into equivalent frequency noise in CARM.

The dark noise appears to be slightly below the shot noise level.

Details

I took the TNC that goes directly into the common-mode board and put it into an SR785. Also attached is the noise with the input of the SR785 terminated.

I also have tried to estimate how this compares to the shot noise on the diode. In full lock at 24 W, we see 3.6 mW of dc light on the PD (according to the calibrated REFL_A_LF channel). Off resonance and at 2.0 W, we have 13.6 mW of dc light. So the CARM visibility is about 98%.

The shot noise ASD (in W/rtHz) and the CARM optical plant (in W/Hz) are both given in Sigg's frequency response document. With a modulation index of 0.22 rad and an incident power of 24 W, the shot noise is 9.4×10−10 W/rtHz, the CARM optical gain is 11 W/Hz, and the CARM pole is 0.36 Hz. [Edit: I was missing some HAM1 attentuation when first calculating the shot noise level. Out of lock, the amount of power on REFL A should be 24 W × 0.1 × 0.5 × 0.5 × 0.5 = 300 mW. That gives a predicted shot noise level of 7.7×10−11 W/rtHz, assuming a sideband amplitude reflectivity of 0.44. On the other hand, from the measured in-lock power we can calulate 2(hνP)1/2 = 5.2×10−11 W/rtHz for P = 3.6 mW. This includes the factor of sqrt(2) from the frequency folding but does not include the slight cyclostationary enhancement in the noise from the sidebands (although this latter effect is not enough to explain the discrepancy).] Additionally, I use Kiwamu's measurement of overall REFL9 response (4.7×106 ct/W) in order to get the conversion from optical rf beat note power into demodulated voltage (2900 V/W). These numbers are enough to convert the demodulated dark noise of REFL9Q (and the shot noise) into an equivalent frequency noise. At 1 kHz, the shot noise is about 10 nHz/rtHz; as a phase noise this is 10 prad/rtHz (which is smaller than Stefan's estimate of 80 prad/rtHz). The dark noise, meanwhile, is about 5 nHz/rtHz.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 17:11, Monday 27 July 2015 (19967)

Hang, Evan

We measured the input-referred voltage noise of the summing node and common-mode boards.

  • We terminated the input of the SNB that receives REFL9Q (INA2). INA1 was disabled. On the CMB, IN1 was enabled with -22 dB, and IN2 was disabled. The 40 Hz / 4 kHz boost was engaged. The fast gain was 7 dB.
  • We measured the noise at the output of the CMB fast output.
  • We then took the TF from SNB INA2 to CMB fast out. This is sufficient to get the input referred noise.

According to this estimate, the CARM loop is not shot noise limited; rather, at 1 kHz the noise is about a factor of 3 in ASD above shot noise.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 10:03, Wednesday 30 September 2015 (22104)

I looked back at the CARM sensing noise data I took (on 12 Aug) using the new gain distribution: 0 dB SNB gain, −13 dB CMB common gain, 0 dB CMB fast gain, and 107 ct/ct digital MCL gain.

[For comparison, the old CARM gain distribution was 0 dB SNB gain, −20 dB CMB common gain, 7 dB CMB fast gain, and 240 ct/ct digital MCL gain.]

☞ For those looking for a message in this alog: something about the current frequency noise budgeting doesn't hang together. The projection based on the CARM sensing noise and the measured CARM-to-DARM coupling TF suggests a CARM-induced DCPD sum noise which is higher than what can be supported by coherence measurements.

☞ Second attachment: As expected, the noise (referred to the input of the SNB) is lower; at 40 Hz, it is about 350 nV/Hz1/2. However, we are not really shot-noise (or dark-noise) limited anywhere.

☞ Third attachment: I am also including the CARM-to-DARM coupling TF from a few weeks ago. This TF was taken by injecting into the CARM excitation point and measuring the response in OMC DCPD sum, using the old CARM gain distribution. Then I referred this TF to the SNB input by multiplying by the SNB gain (0 dB), the CMB common gain (−20 dB), and the CMB common boost (40 Hz pole, 4 kHz zero, ac gain of 1).

This gives a coupling which is flat at 1.0×10−2 mA/V, transitioning to 1/f2 around 250 Hz. Or, to say it in some more meaningful units:

  • Assuming a REFL9Q demodulation coefficient of 2900 V/W, this implies a flat power coupling of 3.4×10−6 mA/W above 250 Hz, rising like 1/f2 below that.
  • Assuming a CARM optical gain of 13 W/Hz and an optical pole of 0.48 Hz, this implies a 1/f frequency coupling above 250 Hz, a 1/f3 coupling below 250 Hz, and an overall magnitude of 6.2×10−5 mA/Hz at 1 kHz.
  • Stated in terms of phase coupling (Stefan's favorite), the magnitude of the CARM optical plant is 6.2 W/rad above the cavity pole, which implies a flat phase coupling of 6.2×10−2 mA/rad above 250 Hz, rising like 1/f2 below that.

☞ Synthesis of the above: based on the measurements described above, at 40 Hz we expect a coupling into the DCPD sum of 350 nV/Hz1/2 × 0.4 mA/V = 1.4×10−7 mA/Hz1/2, which is very close to the overall DCPD sum noise of 3.2×10−7 mA/Hz1/2.

But what is wrong with this picture? If 1.4/3.2 = 44 % of the DCPD sum noise comes from CARM sensing noise, we should expect a coherence of 0.442 = 0.19 between the DCPD sum and the CARM error point.

☞ First attachment: The coherence between the CARM error point and the DCPD sum is <0.01 around 40 Hz. Now, it is almost certainly the case that not all of the CARM error point noise is captured by LSC-REFL_SERVO_ERR, since this channel is picked off in the middle of the CMB rather than the end. Conservatively, if we suppose that LSC-REFL_SERVO_ERR contains only dark noise and shot noise, this amounts to 180 nV/Hz1/2 of noise at 40 Hz referred to the SNB error point, or 0.72×10−7 mA/Hz1/2 referred to the DCPD sum. This would imply a coherence of 0.05 or so.

☞ What is going on here?: Four possibilities I can think of are:

  • I've overestimated the sensing noise.
  • I've overestimated the CARM-to-DARM coupling TF.
  • I've made an algebra mistake somewhere.
  • LSC-REFL_SERVO_ERR is corrupted by noise that is not in the CARM loop.

☞ A word about noise budgeting: In my noise budget, there was a bug in my interpolating code for the CARM-to-DARM TF, making the projection too low below 100 Hz. With the corrected TF, the projected CARM noise is much higher and begins to explain the mystery noise from 30 to 150 Hz. However, given that the above measurements don't really hang together, this is highly speculative.

Images attached to this comment
Non-image files attached to this comment
evan.hall@LIGO.ORG - 20:19, Wednesday 30 September 2015 (22134)

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes through some unity-gain op-amps and then directly into the ADC. So I don't think we have much chance of seeing the 180 nV/Hz1/2 of shot/dark noise above the 4 µV/Hz1/2 of the ADC.

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes a gain of 200 V/V and then directly into the ADC. So the 180 nV/Hz1/2 of shot/dark noise appears as 36 µV/Hz1/2 at the ADC. But as Daniel pointed out, this should be heavily suppressed by the loop. For comparison, the ADC's voltage noise is 4 µV/Hz1/2.

For the sake of curiosity, I'm attaching the latest noise budget with the corrected CARM-to-DARM coupling TF. However, I note again that this level of frequency noise coupling is not supported by the required amount of coherence in any of our digitally acquired channels. Additionally, this level of frequency noise coupling is not seen at Livingston, although they've done a better job of TCS tuning than we have. I would not be surprised to find out that this coupling is somehow an overestimate.

Non-image files attached to this comment
Displaying reports 56481-56500 of 78053.Go to page Start 2821 2822 2823 2824 2825 2826 2827 2828 2829 End