Displaying reports 64681-64700 of 83228.Go to page Start 3231 3232 3233 3234 3235 3236 3237 3238 3239 End
Reports until 00:19, Wednesday 10 June 2015
H1 General
jim.warner@LIGO.ORG - posted 00:19, Wednesday 10 June 2015 (19036)
Shift Summary

17:13 IFO Locked, Intent bit set,

20:08 LLO has gone down, I start a DARM OLG measurement, done at 20:19

21:49 Lock loss

23:00 I start initial alignment again, start trying to lock at 23:45

H1 AOS
darkhan.tuyenbayev@LIGO.ORG - posted 20:57, Tuesday 09 June 2015 - last comment - 08:41, Monday 22 June 2015(19031)
Cavity pole fluctuations calculated from Pcal line at 540.7 Hz

Sudarshan, Kiwamu, Darkhan,

Abstract

According to the PCALY line at 540.7 Hz, the DARM cavity pole frequency dropped by roughly 7 Hz from the 17 W configuration to the 23 W (alog 18923). The frequency remained constant after the power increment to 23 W. This certainly impacts on the GDS and CAL-CS calibration by 2 % or so above 350 Hz.

Method

Today we've extracted CAL-DELTAL data from ER7 (June 3 - June 8) to track cavity pole frequency shift in this period. The portion of data that can be used are only then DARM had stable lock, so for our calculation we've used a filtered data taking only data at GPS_TIME when guardian flag was > 501.

From an FFT at a single frequency it is possible to obtain DARM gain and the cavity pole frequency from the phase of the DARM line at a particular frequency at which the drive phase is known or not changing. Since the phase of the resultant FFT does not depend on the optical gain but the cavity pole, looking at the phase essentially gives us information about the cavity pole (see for example alog 18436). However we do not know the phase offset due to time-delay and perhaps for some uncompensated filter. We've decided to focus on cavity pole frequency fluctuations (Delta f_p), rather than trying to find actual cavity pole. In our calculations we have assumed that the change in phase come entirely from cavity pole frequency fluctuations.

The phase of the DARM optical plant can be written as

phi = arctan(- f / f_p),

where          f is the Pcal line frequency;

                     f_p - the cavity pole frequency.

Since this equation does not include any dependence on optical gain, the technique we use, according to our knowledge, the measured value of phi does not get disturbed by the change of the optical gain. Introducing a first order perturbation in f_p, one can linearize the above equation to the following:

               f_p^2 + f^2
(Delta f_p) = ------------- (Delta phi)
                    f

An advantage of using this linearized form is that we don't have to do an absolute calibation of the cavity pole frequency since it focues on fluctuations rather than the absolute values.

Results

Using f_p = 355 Hz, the frequency of the cavity pole measured at the particular time (see alog 18420), and f = 540.7 Hz (Pcal EY line freq.), we can write Delta f_p as

Delta f_p = 773.78 * (Delta phi)

Delta f_p trend based on ER7 data is given in the attached plot: "Delta phi" (in degrees) in the upper subplot and "Delta f_p" (in Hz) in the lower subplot.

Judging by overall trend in Delta f_p we can say that the cavity pole frequency dropped to about 7 Hz after June 6, 3:00 UTC, this correspond to a time when PSL power was changed from 17 W to 23 W (see lho alog 18923, [WP] 5252)

Delta phi also show fast fluctuations of about +/-3 degrees, and right now we do not know the reason that causes this "fuzzyness" of the measured phase.

Filtered channel data was saved into:

aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS/H1-calib_1117324816-1117670416_501above.txt (@ r737)

Scripts and results were saved into:

aligocalibration/trunk/Runs/ER7/H1/Scripts/PCAL_TRENDS (@ r736)
Images attached to this report
Comments related to this report
darkhan.tuyenbayev@LIGO.ORG - 13:36, Thursday 11 June 2015 (19078)

Clarifications

Notice that this method does not give an absolute value of the cavity pole frequency. The equation

Delta f_p = 773.78 * (Deta phi)

gives a first order approximation of change in cav. pole frequency with respect to change in phase of Pcal EY line in CAL-DELTAL at 540.7 Hz (with the assumptions given in the original message).

Notice that (Delta phi) in this equation is in "radians", i.e. (Delta f_p) [Hz] = 773.78 [Hz/rad] (Delta phi) [rad].

shivaraj.kandhasamy@LIGO.ORG - 08:41, Monday 22 June 2015 (19266)

Darkhan, Did you also look at the low frequency (~30 Hz), both amplitude and phase? If these variations come from just cavity pole, then there shouldn't be any changes in either amplitude or phase at low frequencies (below cavity pole). If there is change only in gain, then it is optical gain. Any changes in the phase would indicate more complex change in the response of the detector.

H1 General
jim.warner@LIGO.ORG - posted 20:08, Tuesday 09 June 2015 - last comment - 20:19, Tuesday 09 June 2015(19039)
Intent bit turned off, DARM OLG measurement starting

LLO just went down and Jeff asked for a DARM OLG measurement, should be 20 minutes or so. Will revert intent bit when done.

Comments related to this report
jim.warner@LIGO.ORG - 20:19, Tuesday 09 June 2015 (19040)

Measurement done.

H1 General
vernon.sandberg@LIGO.ORG - posted 18:57, Tuesday 09 June 2015 (19037)
ER7 Policy on Handling GRB and SNEWS Alarms in the Control Room

from Michael Landry

This is a policy announcement about how to handle GRB and SNEWS alarms in the control room. (GRB = gamma ray burst and SNEWS = SuperNova Early Warning System.)

In the event of a GRB/SNEWS alarm during ER7, a 1hour stand-down time (no hardware injections, no calibrations, transfer functions or elective interventions such as mini-commissioning studies or IFO tuning) is in effect.  The DMT-ANALYSIS_READY (and thus the intent bit) should remain high for this time on a best-effort basis.

H1 CAL (AOS)
sudarshan.karki@LIGO.ORG - posted 17:45, Tuesday 09 June 2015 (19025)
Calibration Study during the first week of ER7

Calibration Team

Summary:

We did some Pcal trend study from the data taken during the first week of ER7 (03 June to 08 June).  Different comparisons were made between PCAL amplitude and DARM amplitude at these calibration frequencies.  We also used the data to estimate the Actuation stregth of ETMY ESD.

Details:

We use Spectral Line Monitoring Tool (SLMT) to  retrieve the data from the LIGO data frames and calculate the amplitude and phase by performing 60 seconds FFT on the time series. After that  we slected only the lock-stretch data (Guardian state vector greater than 500).  We use CAL-DELTAL_EXTERNAL_DQ channel for DARM readout and and respective PD channels for PCAL readout .

Plot 1-4:

We then plotted DARM/PCAL (Amplitude Ratio) at each calibration frequency.  The DARM/PCAL ratio varies at an average of about 10-20%  at higher frequency calibration lines(~500 Hz)  and slighlty more at lower frequencies (~30 Hz).  The first subplot is the DARM/PCAL Ratio. We also looked at the PCAL RxPD and TxPD reading along with DARM Amplitude and Phase.

PLot 5-6:

We also calculated the actuation strength of ETMY ESD using the PCAL calibration lines. Knowing the calibration coefficient of Pcal in [N/V] we use the DARM as an intermediary to calculate the ESD Actuation strength in [N/cts] of ESD excitation using the following equation:

[N]/ESD_EXC[cts] = PCAL_CALIBRATION_FACTOR[N]/[V]*(PCAL_PD[V]/PCAL_DARM[m])*(ESD_DARM[m]/ESD_EXC[cts])

Ideally this coefficient should be same at all frequencies but we see almost an order of magnitude different between the high frequency calculation and low frequency calculation. Don't know why.

PCAL Channel Higher Freq Low Freq
534.7 Hz 540.7 Hz 33.1 Hz 36.7 Hz
RX 3.44E-10 N/cts 3.72E-10 N/cts 3.64E-11 N/Cts 2.92E-11 N/cts
TX 3.50E-10 N/cts 3.66E-10 N/cts 3.71E-11 N/cts 2.87E-11 N/cts

P.S. Kiwamu pointed out CAL-DELTAL_EXTERNAL_DQ may not be an ideal chnanel to conside for this comparison because of multiple loop involved between injection and read out. I will followup by comparing this calculation using LSC-DARM_IN_DQ channel.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 16:47, Tuesday 09 June 2015 (19034)
CDS model and DAQ restart report, Monday 8th June 2015

model restarts logged for Mon 08/Jun/2015

no restarts reported.

H1 SUS (CAL, DetChar, ISC)
jeffrey.kissel@LIGO.ORG - posted 16:31, Tuesday 09 June 2015 - last comment - 13:49, Tuesday 16 June 2015(19018)
Dynamical Model of the QUAD Tagged Before Update for Future Reference
J. Kissel

In preparation for updating LHO's local copy of the QUAD model to receive all of Brett's new goodness (see LHO aLOGs 18987 and 18809), I've tagged the current SUS model that has been used for recent calibration studies for ER7. The tagged model lives here:
/ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/quadmodelproduction-rev7508_ssmake4pv2eMB5f_fiber-rev3601_fiber-rev7392_released-2015-06-09.mat.

Details:
--------
The tag was created using the following script:
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel.m  rev7650

The parameter set used,
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/quadopt_fiber.m  rev3602
are the parameters that have been originally fit to match H1 SUS ETMY's M0-to-M0 (TOP to TOP) transfer functions, but used generically for all quads. It does *not* however include the "correct" frequencies of the violin modes as measured from H1 SUS ETMY (this is half the reason for the update).

The filters for local damping loops wrapped around the dynamical model were grabbed directly from the following foton filter file
/opt/rtcds/lho/h1/chans/filter_archive/h1susetmy/H1SUSETMY_1116978122.txt,
HOWEVER, *which* filter module was used and the damping loop *gains* (i.e. the EPICs settings) were hard-coded to a value that Brett captured a few months ago:
loading M0_DAMP_L with module #s: 1   2   3   5  10. 
loading M0_DAMP_T with module #s: 1   2   5  10. 
loading M0_DAMP_V with module #s: 1   2   5  10. 
loading M0_DAMP_R with module #s: 1   2   5  10. 
loading M0_DAMP_P with module #s: 1   3   5   6  10.
loading M0_DAMP_Y with module #s: 1   2   3   5   6  10. 
with a gain of -1.17. This is different from the current typical gain of -1.0 (except for pitch which is -3.0), so all DOFs are slightly over damped, except pitch which is under damped.

Comments related to this report
brett.shapiro@LIGO.ORG - 16:50, Tuesday 09 June 2015 (19035)

Jeff, you should also tag

makequad_with_modal_fibers.m (same directory)

This is the function that the generate script calls to add violin modes. It has also changed (a couple of times in the past couple weeks).

Just to clarify, because I don't think I said in any other log, the quadopt_fiber.m parameter file is unchanged in all these updqates. Any custom changes for particular suspensions are meant to be applied to new parameter files now on the SVN:

h1etmy.m, h1etmx.m, h1itmy.m, h1itmx.m, l1etmy.m, etc.

Currently all these custom quad parameter files are direct copies from quadopt_fiber.m. They are intended to be updated with measurements at some point. h1etmy.m differs only in that the measured violin modes from H1ETMY are included (first 8 modes).

Incidentally, quadopt_fiber.m was created by fitting it to H1ETMY data (as a representative case). Not just M0 to M0 TF data, but the single, double, and triple hang resonances were used too. Also, the measured mass values of the 4 stages are included. Therefore, h1etmy.m may be considered 'complete' in that it is already customized for H1ETMY, simply because quadopt_fiber.m was. The other files are just place holders for the other suspensions currently.

Previously, in log 18809 the violin modes for H1ETMY were hardcoded in the generate scripts. Now that we have customized parameter files, the violin modes have been moved into those.
So, unless you call the generate script with a custom parameter file, you will simply get the modeled modes.

jeffrey.kissel@LIGO.ORG - 13:49, Tuesday 16 June 2015 (19172)CAL
This purpose of these tags is to document the QUAD model that was used in the DARM calibration models circa ER7 (see LHO aLOG 18769). I have *not* yet updated the local copy of the repository to absorb all of Brett's recent work on improving the model (in fact, I really *want* to start using those improvements, which is why I need to make sure the calibration model for ER7 does not depend on the new-ness, and uses these tagged versions). So, yes, eventually, after I svn up the local LHO copy of the quad model directory, I will make new, additional, tagged version of the model, but for now the focus is preserving what we had *before* these upgrades that Brett mentions in his comment.

This being said, the ability to add violin modes to the model (albiet with in-accurate frequencies), has been around for a while. As such, I did use the first 25 violin modes modeled with viscous damping in the DARM calibration model. HOWEVER, the above mentioned tagging function did not include the violin modes (i.e. it didn't give generate_QUAD_Model_Production enough inputs) because that script pre-dates the addition of violin modes, and I forgot.

So in the same place as described in my above aLOG, I've
(1) changed the name of the above mentioned 2015-06-09 tag to reflect that it is with NO violin mode damping (which may still be useful to people):
/ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/
quadmodelproduction-rev7508_ssmake4pv2eMB5f_fiber-rev3601_fiber-rev7392_NOviolinmodes_released-2015-06-09.mat, 
and
(2) tagged a new version of the model WITH violin modes:
/ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/
quadmodelproduction-rev7508_ssmake4pv2eMB5f_fiber-rev3601_fiber-rev7392_WITHviolinmodes_released-2015-06-16.mat

Again -- BOTH OF THESE TAGS STILL HAVE INCORRECT LOCAL DAMPING LOOP GAINS, as mentioned above.
LHO VE
kyle.ryan@LIGO.ORG - posted 16:21, Tuesday 09 June 2015 (19033)
~1000 - 1130 hrs. local -> Ran rotating pumps at X-end -> Configured new turbo gauge controller
Demonstrated new gauge controller operates turbo isolation safety valve as normal 

~1500 hrs. local -> De-engergized turbo controller
H1 CDS (SUS)
david.barker@LIGO.ORG - posted 14:28, Tuesday 09 June 2015 - last comment - 15:41, Wednesday 10 June 2015(19030)
status of 18bit DAC calibrations

We are seeing two issues with the autocal of the 18bit DAC cards (used almost exclusively by suspension models). The first is a failure of the autocal; the second is the autocal succeeding but taking longer than normal.

There are three calibration completion times: ~5.1S for unmodified DAC, ~5.3S for modified DAC, ~6.5S for modified long-running DAC

h1sus2b, h1sush34, h1susex, h1susey all have no DAC issues

h1sush2a: the third DAC is taking 6.5S to complete. This DAC is shared between PRM and PR3 models. First two channels are PRM M1 Right and Side. Last six channels are PR3 M1 T1,T2,T3,Left,Right,Side.

h1sush56: this has unmodified cards. 4th DAC is failing autocal

h1susb123: This one is strange:

On first autocal run after a computer reboot: 7th DAC failed autocal

On first restart of all models: 1st DAC failed autocal, 7th DAC succeeded

On second restart of all models: 1st DAC failed autocal, all others good (consistent restart behavior)

In all cases, 5th DAC card is running long for autocal (6.57S).

In the current situation with the 7th card now succeeding and the 1st DAC failing, the 1st DAC is driving ITMY M0 (F1,F2,F3,LF,RT,SD) and M0 (LF,RT)

Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:41, Wednesday 10 June 2015 (19052)CDS, DetChar, ISC, SUS
I've been asked to translate / expand on the above entry, and I figure my reply was worth just commenting on the aLOG itself. If one person asks, many more are just as confused.

---------
We know that DetChar have seen Major Carry Transition or "DAC" [digital-to-analog converter (DAC)] glitches in some of the detectors interferometric signals, that have been pin-pointed to be from a few select stages of a few select suspensions (see e.g. LHO aLOGs 18983, 18938, or 18739).

To combat the issue, yesterday, we restarted all the front-end processes (including the Input Output Processor [IOP] process) on the four corner station SUS computers:
h1sush2a (controlling MC1, MC3, PRM and PR3 all in HAM2)
h1sush2b (controlling IMs 1 through 4)
h1sush34 (controlling MC2 and PR2 in HAM3 and SR2 in HAM4)
h1susb123 (controlling ITMY, BS, and ITMX in BSCs 1, 2 and 3 respectively)

Restarting the IOP process for any front-end who is coupled with an I/O chassis that runs 18-bit DAC cards performs the auto-calibration (autocal) routine on those 18-bit DACs, recalibrating the voltage bias between the (2-bit + 16-bit cards) of the 18-bit DAC to reduce Major Carry transition glitching. When the front-end computer is rebooted or power-cycled, the IOP process is started first, and therefore runs the auto-calibration routine as well. After autocalibration is complete, the user models for each suspension are started. 

Note that the other 3 SUS "control" computers,
h1sush56 (controlling SRM and SR3 in HAM5 and the OMC in HAM6 )
h1susex (controlling ETMX and TMSX)
h1susey (controlling ETMY and TMSY)
were NOT restarted yesterday, but have been restarted several times over recent history.

Each of these front-end or I/O chassis contains many DAC cards, because it (typically) controls many suspensions (as described above), hence the distinction between the card numbers in each front-end. Said differently, each DAC card has 8 channels -- because of initial attempts to save money and conserve space, the above mentioned corner station computers / IO chassis have some DAC cards that control OSEMs of two different suspensions. There's a map of which DAC card which controls which OSEM in the wiring diagrams; there is a diagram for each of the above mentioned computers / I/O chassis; each diagram, named after the chambers the I/O chassis controls can be found from the suspension electronics drawing tree, E1100337.

Recall that we have recently swapped out *most* of the suspensions' 18-bit DAC cards for a "new" 18-bit DAC card with upgraded EPROMs (see LHO aLOGs 18557 and 18503, ECR E1500217, and Integration Issue 945). This is what Dave means when he references "modified" vs. "unmodified" DAC cards. All DAC cards in h1sush56 remain unmodifed, where as the other corner-station DAC cards in all other SUS I/O chassis have all been upgraded.

Dave also describes that 18-bit DACs are used "almost exclusively by suspension models." The PCAL and PEM DACs are also 18-bit DACs. Every other fast DAC (used by TCS, SEI, PSL, ISC, etc.) is a 16-bit DAC which have not been found to have any issues with major carry transition glitching. Note that because the tip-tilt suspensions (the OMs and RMs, collectively abbreviated as the HTTS for HAM Tip-Tilt Suspensions) were purchased under ISC dollars, who made the decision to do this (as with many other things) differently -- they have 16-bit DACs. 

After we've restarted the IOP front-end process, we track its start-up log file to ensure that the auto-calibration was successfully completed. We've found that there are two "failure" modes to this auto-calibration process that get reported in these log files. 
(1) The IOP process log reports that the auto-calibration process has failed.
(2) The IOP process log reports that the auto-calibration process took longer than is typical. 
We don't know the practical result of either of these two failure modes means. This was brought up on the CDS hardware call today, but no one had any idea. I've pushed on the action item for Rolf&Co to follow up with the vendor to try to figure out what this means.

As for (2), 
- the typical time for an IOP process to complete the auto-calibration of one unmodified DAC card is 5.1 [sec]. 
- the typical time for a modified DAC card with the new EEPROM is 5.3 [sec].
- the atypical "errant" time appears to be 6.5 [sec]. 
But, again, since we have no idea what "running long" means, our only reason to call this a "failure mode" is that it is atypical.

So re-writing Dave's above status (which is a combined status that is the results of yesterday's IOP model restarts and other previous IOP model restarts) with the jargon explained a little differently and in more detail:
- h1sus2b, h1sush34, h1susex, h1susey all have no DAC auto-calibration issues. All DAC cards in these front ends / I/O chassis report a successful auto-calibration routine.
- h1sush2a: of the all the DAC cards in this I/O chassis, only the 3rd DAC (which is s controls the some of the TOP, M1 mass OSEMs of PRM and some of the TOP, M1 OSEMs of PR3) is suffering from failure mode (2).
- h1sush56: the 4th DAC is suffering from failure mode (1).
- h1susb123: this computer's IOP process was restarted several times. 
	- Upon the first autocal, which was performed as a result of rebooting the computer, 
		- the 1st and 7th DAC card suffered from failure mode (1), 
		- the 5th DAC card suffered from failure mode (2),
		- all other DAC cards reported success.
	- Upon the second autocal, which was performed as a result of restarting the IOP process, 
		- the 1st DAC card suffered from failure mode (1), 
		- the 5th DAC card suffered from failure mode (2),
		- all other DAC cards reported success.
	- Upon the thir autocal, which was performed as a result of restarting the IOP process again, 
		- the 1st DAC card suffered from failure mode (1), 
		- the 5th DAC card suffered from failure mode (2),
		- all other DAC cards reported success.
	The first DAC card is shared between the two TOP, M0 and R0 masses of ITMY. (note Dave's typo in the initial statement)

For previous assessments, check out LHO aLOG 18584.
H1 ISC
daniel.sigg@LIGO.ORG - posted 14:16, Tuesday 09 June 2015 (19029)
ALS fiber polarization

We received an error by the EY PLL that the fiber polarization has driftyed out of spec. The attached plot shows the trend over the past 12 days. We can see daily fluctuations and the y-arm drifting higher over time, but nothing of particular interest.

Images attached to this report
H1 AOS (AOS)
darkhan.tuyenbayev@LIGO.ORG - posted 13:49, Tuesday 09 June 2015 (19026)
Pcal line frequencies have been swapped
Sudarshan, Darkhan,

We have swapped Pcal line frequencies (EX <--> EY) and plan to keep them this way until the end of the ER7.

Before swapping we had Pcal lines at following frequencies:
PCALX at 33.1 Hz and 534.7 Hz
PCALY at 36.7 Hz and 540.7 Hz

For the rest of ER7 we will have lines at:
PCALX at 36.7 Hz and 540.7 Hz
PCALY at 33.1 Hz and 534.7 Hz

SDF_OVERVIEW monitors have been updated accordingly.
H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 13:00, Tuesday 09 June 2015 (19007)
Owl Shift Summary

00:00 Jim left the interferometer locked for me!

            EY dust monitor went off. > 0.3 u has 914.3 counts/ft^3, >0.5 u has 57.1 counts/ft^3

2:42 Lock loss

3:00 AS 90 too low. Adjusted BS yaw did the job.

3:11 Lock loss at BOUNCE_VIOLIN_MODE_DAMPING. Redo the initial alignment.

3:20 LSC-TR_X Not flashing. Realigned SR2, SR3, and PR2 pitch and yaw.

04:30 Locking at LSC_FF. Intent bit switched to Undisturbed. Guardian worked fine at LOWNOISE_ESD_ETMY step (I was told that it might not work properly). I think it worked at BOUNCE_VIOLIN_MODE_DAMPING as well (after running the code by hand I accidentally let the Guardian run through this state. It didn't lose lock).

6:06 Intent bit switched to Commissioning. Get ready for the hardware injection (scheduled to start at 1117890580 GPS time)

6:09 Injection started

6:13 Injection finished. Intent bit switched to Undisturbed.

6:17 Intent bit switched to Commissioning. Another injection scheduled to start at 1117891250 GPS time. Same injection with gain increased.

6:24 Injection finished. Intent bit switched to Undisturbed.

8:00 Handling off the ifo to Jeff.

Images attached to this report
LHO General (CAL, DetChar, GRD, INJ)
vernon.sandberg@LIGO.ORG - posted 12:29, Tuesday 09 June 2015 (19024)
State of ER7 Data Taking

ER7 Data Taking started 2015 June 3 at 14:00:00 pdt, 21:00:00 utc, 1117400416 gps.
As of this morning, 2015 June 9, we have accumulated approximately 33 hours of "analysis-ready" coincident data between LHO and LLO.  H1 has collected approximately 77 hours of analysis-ready data.  L1 has collected approximately 37 hours of analysis-ready data.  We have approximately 5 days left in the run plan for ER7.

At the beginning of ER7 Data Taking, H1 was configured and calibrated for operation at ~17 W of input power.  Over the weekend its input power was raised to 24 W.  This resulted in a few percent error in the calibration and operating configuration.  We have restored the input power for H1 back to 17 W and will operate it in this configuration for the remainder of ER7.  This is to deliver data to the analysis groups from a known characterization of the detector.


Where we are with regard the JRPC ER7 page (https://wiki.ligo.org/LSC/JRPComm/EngRun7):
Requirements
Detectors
Stable and reliable locking of H1 and L1 in configurations that could plausibly serve in an observing run
Best effort to have similar sensitivities, but no requirement stated
State reporting by Guardian and ODC
Calibrated h(t) channel (see T1300950 for O1 requirements)
    Expect L1 calibration accuracy of 20% amplitude & 10-20deg phase from 10 Hz to 2kHz. Aiming for 20% amplitude and 20 deg phase from 2kHz to 5 kHz.
    Expect H1 calibration accuracy within a factor of 2 in amplitude; no phase requirement.  - delivered 2015 June 2
Sufficient automation to be controllable by operators - achieved, guardian is working well
Hardware injections  - hardware and software installed, injections have been carried out and confirmed by analysis groups
Blind Injections Implementation and Testing
approximately 7 days of data taking - in progress, the most stringent is the CBC coincidence requirement of 48 hours, of which we have 33 hours to date

Requirements checklist for ending the run:

CBC:
    Would like >2 days coincident science data
    Lock periods >4 hours benficial for CBC detchar investigations
    (Request) Test H1 and L1 coherent HW injections

CW:
    CW hardware injections for at least one interferometer
    More than 75 hours of L1 DC-readout data and more than 50 hours of H1 DC-readout data

Stochastic:
    Carry out and recover a stochastic injection.

Burst:
    Would like >2 days coincident science data
    Test EM follow-up infrastructure (EM Processor, PE codes, ...) with coherent HW injection in H1 and L1.


Detailed progress in acheiving these goals is discussed every day at 1:00 pm pdt at the JRPC ER7 Run Status meeting on teamspeak JRPC channel, during the period of the run.


 

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 12:26, Tuesday 09 June 2015 (19023)
CDS maintenance Summary

09:55PDT h1oaf - all filter coefficients loaded

10:14PDT cdsegw0 - epics gateway between H1FE and H1SLOW VLANs restarted to permit h1guardian0 connection to h1ecatx1 (which was restarted)

10:25PDT h1sush2a - restart all models to perform a DAC-AUTOCAL

10:30PDT h1sush2b - restart all models to perform a DAC-AUTOCAL

10:34PDT h1sush34 - restart all models to perform a DAC-AUTOCAL

10:43PDT h1broadcast0 - reboot to clear potential network error

11:50PDT h1susb123 -  restart all models to perform a DAC-AUTOCAL

Other than h1broadcast0, no DAQ restart today.

LHO General
thomas.shaffer@LIGO.ORG - posted 12:04, Tuesday 09 June 2015 - last comment - 16:14, Tuesday 09 June 2015(19013)
Ops Maintenance Log

809 - Richard to both ends

809 - Jeff B to LVEA then to ends setting up dust mons

811 - Christina fork lifting to OSB receiving and opening door

814 - Rick to manifolds on both arms

820 - Kyle to EY

823 - Jodi to LVEA to put signs up, then to MY

826 - Christina/Karen to EY to clean

827 - Beam tube cleaning start

832 - Robert to EY to move coils

832 - Patrick to restart EX Beckhoff

835 - Jodi and Rick out of LVEA

838 - Andres to LVEA to move parts around

845 EX Beckhoff back up

853 - Fil/Peter K to LVEA

900 - Kingsoft on site for RO work

905 - Praxair truck on site

907 - Fil/Peter out of LVEA

909 - Jodi leaving MY

917 - Andres out

921 - Gerardo to LVEA for wrenches

923 - Mitch to ends for serial number hunt

927 - Karen/Christina leaving EY for EX

928 - Gerardo out and to EY

947 - Robert out of LVEA

1000 - Praxair truck #2 on site

1006 - Daniel to EY to look at TCS setup

1010 - Richard back fomr Ends

1020 - Robert to LVEA

1020 - Karen/ Christina leaving EX

1020 - Fil to EY

1027 - Ed to CER

1036 - Ed out

1040 - RIchard to EY

1049 - Rick LVEA fit check

1052 - Daniel back, for a moment

1057 - Richard to LVEA looking at Cosmic Ray Detector

1105 - Christina/Karen to LVEA

1107 - Patrick restarting PEMEY

1128 - Mitch back

1128 - Daniel back

1133 - Jeff B back

Comments related to this report
jeffrey.bartlett@LIGO.ORG - 16:14, Tuesday 09 June 2015 (19032)
Log for second half of the day:

11:48 Beam Tube cleaning crew breaking for lunch
12:00 Start both dust monitors at End-Y
12:00 Kyle – Back from End-X – Note: Fan and power supply running while turbo pump spins down
12:27 Bubba & Gerardo – Back from End-Y 
13:35 Beam tube cleaning restarted HNWX2
14:48 Kyle – Going to End-X to shut off turbo pump fans and power supply
15:16 Kyle – Back from End-X
15:30 Beam cleaning team done for the day
H1 INJ (DetChar, INJ)
peter.shawhan@LIGO.ORG - posted 07:43, Tuesday 09 June 2015 - last comment - 14:01, Tuesday 09 June 2015(19006)
First test of detchar 'safety' injections
Peter Shawhan, Andy Lundgren, Nutsinee Kijbunchoo

We did a first -- and successful! -- test of the "detchar" or "safety" hardware injections shortly after 6:00 PDT this morning, at the time recommended by Jeff (work permit 5262).

The detchar injections are a sequence of loud sine-gaussians at a range of frequencies, primarily intended to check for couplings from the GW strain channel to auxiliary channels.  (See https://dcc.ligo.org/LIGO-G1500713 .)  For now, at least, we are using a set of 14 frequencies logarithmically spaced from 30 Hz to 2000 Hz, each injected at 3 different amplitudes to try to get target SNR values, spaced 5 seconds apart.  Here is the full list with times relative to the start time of the injection:
Matlab> GenerateSGSequence('H1','H1_ASD_at_1117710916.txt');
__time__   __freq__   __SNR__    __AMP__
    0.50       30.0      25.0    2.22e-20
    5.50       41.4      25.0    7.54e-21
   10.50       57.2      25.0    2.86e-21
   15.50       79.1      25.0    1.72e-21
   20.50      109.2      25.0    1.52e-21
   25.50      150.9      25.0     1.7e-21
   30.50      208.4      25.0    1.97e-21
   35.50      287.9      25.0    2.92e-21
   40.50      397.7      25.0    3.73e-21
   45.50      549.3      25.0    5.42e-21
   50.50      758.8      25.0    6.95e-21
   55.50     1048.2      25.0     1.1e-20
   60.50     1447.9      25.0    1.71e-20
   65.50     2000.0      25.0    2.68e-20
   70.50       30.0      50.0    4.44e-20
   75.50       41.4      50.0    1.51e-20
   80.50       57.2      50.0    5.71e-21
   85.50       79.1      50.0    3.44e-21
   90.50      109.2      50.0    3.03e-21
   95.50      150.9      50.0    3.41e-21
  100.50      208.4      50.0    3.94e-21
  105.50      287.9      50.0    5.85e-21
  110.50      397.7      50.0    7.47e-21
  115.50      549.3      50.0    1.08e-20
  120.50      758.8      50.0    1.39e-20
  125.50     1048.2      50.0     2.2e-20
  130.50     1447.9      50.0    3.41e-20
  135.50     2000.0      30.0    3.22e-20
  140.50       30.0     100.0    8.88e-20
  145.50       41.4     100.0    3.02e-20
  150.50       57.2     100.0    1.14e-20
  155.50       79.1     100.0    6.87e-21
  160.50      109.2     100.0    6.06e-21
  165.50      150.9     100.0    6.81e-21
  170.50      208.4     100.0    7.87e-21
  175.50      287.9     100.0    1.17e-20
  180.50      397.7     100.0    1.49e-20
  185.50      549.3     100.0    2.17e-20
  190.50      758.8     100.0    2.78e-20
  195.50     1048.2     100.0    4.41e-20
  200.50     1447.9      75.0    5.12e-20
  205.50     2000.0      30.0    3.22e-20
The file, on h1hwinj, is /data/scirun/O1/HardwareInjection/Details/config/Burst/Waveform/detchar_1117890580_3_H1.txt . With H1 running in good low-noise mode, Nutsinee switched the intent bit to 'commissioning' and we first injected the sequence starting at 1117890580 with an overall scale factor of 0.25 -- so the target SNRs/amplitudes are a factor of 4 smaller than in the table above. Nutsinee didn't see anything obvious appearing in the live spectrum initially, but Andy looked at Omicron output afterward and say that it had picked up at least some of the louder signals. We then injected the sequence again starting at 1117891250, this time with an overall scale factor of 1.0 . Nutsinee saw the signals clearly peak up in the live spectrogram, and Andy's quick check with Omicron showed many signals found with large SNR. The interferometer appeared to handle the injections fine, staying in lock. Afterward (and also in between the two injections), Nutsinee set the intent bit back to 'science'. Note: In the future, we expect detchar safety injections such as these to be marked with the DetChar bit in the CAL-INJ_ODC bitmask, but for the test today we treated it as a burst injection -- it will be marked in ODC (and GDS-CALIB_STATE) as a burst injection, and should produce ODC-INJECTION_BURST segments in the DQ segment database.
Comments related to this report
andrew.lundgren@LIGO.ORG - 12:01, Tuesday 09 June 2015 (19019)DetChar, INJ
I've done a few checks of the injections. The first attachment is the spectrum before the first injections were started compared to the spectrum just after the last one finished. The spectrum is the same before as after, so I don't think anything got rung up. Maybe we can check the violin modes more carefully. There was a fairly big glitch two minutes later (Omega scan) but I don't think it was related.

The other four attachments are the injections of the first round of the injection set, done at normal gain. These are meant to have SNR of about 25, but that varies with the spectrum. Most look fine. However, the injections at 1 kHz and above are not correct. They look to be anti-aliased down, or maybe there's a saturation or something wrong with the actuation. We'll check our code to see if there's something wrong with the file we generated.
Images attached to this comment
peter.shawhan@LIGO.ORG - 14:01, Tuesday 09 June 2015 (19028)DetChar, INJ
When Andy presented this on the ER7 call and talked about the higher-frequency injections not appearing correctly, Jeff asked if we were hitting the software limit at +-200 counts.  That limit had been set based on some CBC injection studies; we don't really know the level at which unavoidable saturation in the software or hardware chain would set in.  Duncan M quickly confirmed that the H1:CAL-INJ_HARDWARE_OUT_DQ channel was hitting +-200 for some of the injections.  I took a look too and estimated what SNR value hits that software limit:
 At 549 Hz,  SNR=80  hits 200 counts
   759 Hz   SNR=33
  1048 Hz   SNR=10.4
  1448 Hz   SNR<6.25  (saturated even for the weakest one we injected)
  2000 Hz   SNR<6.25  (saturated even for the weakest one we injected)
So this tells us how much that (currently rather arbitrary) software limit would need to be relaxed to put in larger-SNR injections at those higher frequencies, if it's important to do so.
H1 General
jim.warner@LIGO.ORG - posted 00:00, Tuesday 09 June 2015 - last comment - 19:32, Tuesday 09 June 2015(19001)
Shift Summary

Mostly quiet shift

16:00 Took over initial alignement from Cheryl, trying to lock

18:30 Finally locked

19:00 Robert to  EY to bang on beam tube, lots of glitching -> particulate?

20:00 Evan breaks lock with a small change to Guardian

22:00 Lock reacquired, LLO is up too.

23:26 HFD is on site, out the gate at 23:55

Comments related to this report
robert.schofield@LIGO.ORG - 19:32, Tuesday 09 June 2015 (19038)

I went out to watch the cleaning earlier in the day and returned after work had finished to reproduce some of the cleaning activities. I was on the phone with the operator who monitored DARM for glitches. I found that tapping the beam tube with metal like the water/vacuum nozzles produced large glitches, but brushing with the brushes did not. I found that the softer the instrument, the harder it was to make glitches. I was never able to make glitches with my fist, but there was nearly a one-to-one coincidence with metal taps. All glitches, according to Jim, the operator, were broad band and a couple of orders of magnitude above background. I had to wait quite a time for the spectrum to settle down before tapping again. The glitches were like delta functions, not like scattering shelves. There did not seem to be a difference between locations at a baffle and half way between baffles.

I suggested to Bubba and John that we might make fewer glitches if there was a polymer guard on the nozzles.

I guess that the important quantities for freeing metal oxide particles are either acceleration or change in curvature of the beam tube. The difference between soft and hard "hammers" is consistent with both of these hypotheses. I think that it is important to estimate the inter-site coincidence rate and propose that I mount an accelerometer and a shaker on the tube to study glitching as a function of frequency and amplitude. I suspect that there is a soft threshold in curvature change or acceleration, and that this will be fairly constant with time since the oxide layers should no longer be growing. 

H1 ISC
evan.hall@LIGO.ORG - posted 16:18, Saturday 06 June 2015 - last comment - 17:31, Thursday 11 June 2015(18939)
Sum, null, and residual of OMC DCPDs

Using two hours of undisturbed data from last night's 66 Mpc lock, I repeated Den's sum/null stream analysis in order to see if we have a similar 1/f1/2 excess in our residual.

I took the OMC sum/null data (calibrated into milliamps), undid the effect of the DARM OLTF in order to get an estimate for the freerunning OMC current, and then scaled by the DARM optical gain (3.5 mA/pm, with a pole at 355 Hz) to get the equivalent freerunning DARM displacement. The residual is then the quadrature difference between the sum and null ASDs.

The attachment shows the sum, null, and residual ASDs, along with the anticipated coating Brownian noise from GWINC. [Just to be clear: the "sum" trace on this plot corresponds to our usual freerunning DARM estimate, although in this case it comes purely from the error signal rather than a combination of the error and control signals.]

If there is some kind of excess 1/f1/2 noise here, it is not yet large enough to dominate the residual. Right now it looks like the residual is at least a factor of 2.2 higher than the expected coating noise at all frequencies. We already know some of this is intensity noise.

The other thing to note here is that we are evidently not completely dominated by shot noise above 1 kHz.

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 15:51, Sunday 07 June 2015 (18959)

I repeated this on a lock stretch from 2015-06-07 00:00:00Z to 02:00:00Z, but the result is pretty much the same. The best constraint we can put on coating noise right now from the residual is about a factor of 2.2 higher than the GWINC prediction. I also think the residual is not yet clean enough in this frequency band to make an inference about its spectral shape.

I tried increasing the CARM gain by 3 dB to see if the residual would decrease, but it does not (except maybe round 6 kHz; see the attached dtt pdf). So this broadband excess in the sum may not be frequency noise.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 14:09, Tuesday 09 June 2015 (19027)

There is an error in the above plots.

Only the DCPD sum should be corrected by the DARM OLTF to get the equivalent freerunning noise. The DCPD null should not be corrected. To refer to noise to DARM displacement, however, all these quantities must be corrected by the DARM cavity pole.

This time I've included the DCPD dark noise (sum of A and B), also not corrected by the loop gain.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 17:31, Thursday 11 June 2015 (19077)

A few more corrections and additions:

  • These plots use median averaging. As is widely known, this biases the estimate of the ASD downward by a factor of sqrt(ln(4)). This is now corrected in the new attachment.
  • I looked at the 540 Hz pcal line in order to get a tighter value for the optical gain; it is 3.85 mA/pm. I am still assuming a DARM pole of 355 Hz, which is what is currently installed in the DARM calibration.
  • The shot noise as predicted by GWINC lines up fairly well with the DCPD null stream, with minimal additional tuning of the of the parameters required. Input power is 24.2 W, with 88% transmission efficiency of the IMC. SRM transmissivity is 37%, DCPD quantum efficiency is 85%. The round-trip arm losses are set at 84 ppm, which is what I found previously was required to achieve a recycling gain of 40 W/W. Loss at the beamsplitter is 500 ppm, excess SRC loss (the "TCS loss") is 0, and SRC modematching is perfect, which are the defaults in IFOModel. Of course, we should get a better handle on these numbers and then actually verify that the GWINC shot noise estimate still agrees with the null. For now, it is just a weak indicator that we roughly understand the shot noise level.
  • The apparent low-frequency excess in the null stream (<30 Hz) seems roughly consistent with the expected contribution from dark noise that Dan and I measured a few months ago. Since Koji has retuned by hand the digital compensation of the DCPDs, ideally we should measure this again.
  • Some extra plots (cross spectrum and coherence of DCPDs A and B) and parameters file attached in zip.
Non-image files attached to this comment
Displaying reports 64681-64700 of 83228.Go to page Start 3231 3232 3233 3234 3235 3236 3237 3238 3239 End