Displaying reports 43741-43760 of 84095.Go to page Start 2184 2185 2186 2187 2188 2189 2190 2191 2192 End
Reports until 11:52, Wednesday 18 April 2018
H1 CDS
david.barker@LIGO.ORG - posted 11:52, Wednesday 18 April 2018 (41520)
h1susauxex rebooted following freeze

h1susauxex froze around midnight last night. I rebooted it using front-panel-reset-button. Since this is not on dolphin, no other restarts were needed.

H1 SEI
edmond.merilh@LIGO.ORG - posted 10:18, Wednesday 18 April 2018 (41518)
H1 ISI CPS Sensor Noise Spectra Check - Weekly FAMIS #6946

All spectra appears to be within acceptable, nominal range.

Images attached to this report
H1 General
edmond.merilh@LIGO.ORG - posted 08:11, Wednesday 18 April 2018 (41513)
Shift Transition - Day

TITLE: 04/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.07 μm/s
    Secondary useism: 0.18 μm/s
QUICK SUMMARY:

H1 GRD
jameson.rollins@LIGO.ORG - posted 07:56, Wednesday 18 April 2018 - last comment - 10:38, Wednesday 18 April 2018(41512)
another attempt at moving guardian nodes to new h1guardian1 system

I am starting the process of moving all guardian nodes from h1guardian0 to the new h1guardian1 machine for testing.  We believe that we may have fixed the problem in guardian that was leading to anomalous segfaults (full explanation on the problem and fix in a follow-up post).

Comments related to this report
jameson.rollins@LIGO.ORG - 10:38, Wednesday 18 April 2018 (41519)

I have transitioned most nodes to h1guardian1.  I tried to make sure they all came back up in the same configuration, but I might have missed some things (I will work on cleaner restarts).

I've left the SEI ETMX nodes off for now, as they were all paused for the in-chamber activity

I also found syntax errors in the ALS nodes that need to be corrected before they can be restarted.

guardctrl and guardlog are not yet working on most workstations.  I am working on this.

H1 ISC (ISC, SYS)
craig.cahillane@LIGO.ORG - posted 21:16, Tuesday 17 April 2018 - last comment - 18:10, Wednesday 18 April 2018(41483)
Further Electric Field Meter Prototype Characterization and Rough Displacement Noise Estimate
Craig, Niko, Georgia

Today Georgia, Niko, and I went down to Xend to take more careful measurements of the Electric Field Meter (EFM) Prototype built by Rich, Calum, and Luis.  

We drove the ISI to check if we could see the electric fields above our EFM noise floor.  We drove the ISI both vertically and horizontally until the watchdog tripped, but never saw a signal in the EFM.  This is surprising, since Rai's prototype was sensitive to ISI driving in the Y chamber.

We measured a calibration TF for both the positive X EFM sensor plate and negative X EFM sensor plate (Plot 1),
the common mode rejection from the X sensor plates (Plot 2),
and an ambient electric field ASD in the X-end chamber (Plot 3).  

Finally, I roughly estimated the ETMX displacement noise we might expect from ambient electric fields given our usual ESD setup. (Plot 4)  
The details of the calculation made to get plots 3 and 4 are in a jupyter notebook on git.ligo.org.

At 100 Hz I estimate around 10^{-22} m/rtHz displacement noise, far below our noise floor.  However, I'm getting a stronger frequency dependence than we perhaps anticipated: our measured electric field falls like f^{-1.5}, until it runs into what is probably the EFM circuit noise floor at 200 Hz.  This gives an overall displacement frequency dependence of f^{-3.5}.

Pictures are courtesy of Niko and Georgia who did all the in-chamber work today.  

Things to do:
1) Get capacitance measurement between calibration plates for a better volts to electric field TF.
2) Understand and create a noise model of the EFM circuitry.  This will probably help explain the strong frequency dependence we're seeing with some low frequency pole.
Images attached to this report
Comments related to this report
rich.abbott@LIGO.ORG - 16:59, Tuesday 17 April 2018 (41498)SYS
I ran a noise simulation of the ungrounded-plate noise spectra.  The attached image shows what would be expected from the 10^12 ohm resistance filtered by the approximately 20pF capacitance of the sense plate to the body (including amplifier input capacity).  The results at 100Hz confirm the ~200nV/rtHz associated with the asymptote of the intrinsic electronics noise of the device as seen when the sense plates are grounded.
Non-image files attached to this comment
georgia.mansell@LIGO.ORG - 19:39, Tuesday 17 April 2018 (41506)

Conclusion: we're fairly confident we are not actually driving the ISI at end-X, and this is why we don't see the associated electric fields.

As a sanity check, Craig brought the previous electric field meter (EFM) out to end-x and placed it in the chamber under the current EFM (see first two photos). We have previously detected the electric field generated by driving the ISI with this EFM (lho alog 40878).

We tried driving the locked ISI again, with increasing amplitude, at 353 Hz, and saw nothing in either EFM. We looked at the GS13 and CPS sensors, both now (first screenshot, with drive signal in the left column) and back in time, when we were driving the ISI back in March (second screenshot, again with drive signals in the left column). We see no signal associated with the drive now (right colum), while in March the drive was present in both these signals.

We checked the watchdogs, and reset the hardware watchdogs just in case, checked the ISI racks for unplugged cables, and the power supplies and are still unsure why we are not driving the ISI.

We took the old EFM out of the chamber for the night.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 09:26, Wednesday 18 April 2018 (41516)

I don't think that we can estimate the contribution to DARM from this data, since we don't have a good estimate of charge on the optic or the coupling from the EFM to the fields at the test mass.

craig.cahillane@LIGO.ORG - 18:10, Wednesday 18 April 2018 (41531)
In my estimate, I assumed that charge on the test mass is zero and the ambient electric fields at the EFM are the same as those at the test mass.
My concern is that we are just looking at EFM sensor noise and not really ambient electric fields.  It seems like we are seeing ambient electric fields below 200 Hz with a frequency dependence of f^{-1.5}.  
Many assumptions went into the estimated displacement noise, I wouldn't trust it to better than an order of magnitude.
H1 ISC (AWC, ISC, SQZ)
thomas.vo@LIGO.ORG - posted 20:27, Tuesday 17 April 2018 - last comment - 21:15, Tuesday 17 April 2018(41504)
Sqz Beam Scan at the OMC

Sheila, Nutsinee, Terry, Dan Brown, TVo

To get an idea of the mode-matching from the OPO to the OMC, we wanted to do a beam profile measurement of the squeezer and use Alamode to fit the data points.  The hope is that the fit will match a Finesse model that includes the squeezer path from the output of the OPO, through the two lenses, ZM1/ZM2, and into the Faraday.  Then the beam reflects off of SRM HR surface and propagates to the OMC. 

The squeezer crew was able to take profiling measurements between OM2 and OM3 with the nanoscan using a pick-off mirror. They repeated this for three positions of the lens on the VOPO translation stage which allows for about +/- 2cm in travel.  The translation stage position that moved the lens closest to the VOPO has the best overlap estimate with the OMC at about 83% (using alamode) which means it's possible that we have to move the translation stage on the breadboard to get better results.  It's clear that we should move the lens+translation stage closer to the VOPO, which will move the waist location into the right spot, but this will alter the waist size.  If our model is correct, we can estimate the amount of mode-mismatch if we have to live with this lens positioning.

To double check our distances to the , which is not clear because the OMC is covered up with the shroud, we measured the OMC_REFL beam as well as the beam coming right after ZM1.  One thing that is quite odd, is that the beam was pretty astigmatic ~18% on some of the measurements.  This was not seen in the previous measurement but was seen when we've measured the IFO beam profile.  However, rotating the profiler didn't change the effect so it might be real.

To do:

- OMC PZT scan with Sqz beam this will allow use to double check our mode-matching estimate.

- Hammer on the model a bit more to get real-world measurements, Finesse, and Alamode to match up.

Comments related to this report
thomas.vo@LIGO.ORG - 21:15, Tuesday 17 April 2018 (41509)

Attached are the beam sizes for three positions of the lens on the translation stage, 1 in the middle and the other two at each end of their ranges.  The blue is the X direction and the red is the Y direction.

I included the measurements from the REFL beam on the centered plot( this is in black and magenta), for some reason the y axis was very astigmatic and not what were were expecting.

Images attached to this comment
H1 IOO (PSL)
sheila.dwyer@LIGO.ORG - posted 19:04, Tuesday 17 April 2018 - last comment - 05:05, Wednesday 18 April 2018(41505)
IMC misaligned

Peter King went back into the PSL so that we could try to lock the IMC for some work in HAM6 this evening.  While Peter was in the enclosure, the IMC was locked and the alignment was decent, however as Peter was leaving it looks like something misaligned in yaw which is not in the same gouy phase as the PZT, so we can't re-aling it without going back into the PSL.  Since I'm not sure which irises Peter and the PMC crew were using, we are not going to try to align it tonight.  If we can lock the IMC tomorrow that will help us to finish of HAM6 work. 

Comments related to this report
craig.cahillane@LIGO.ORG - 20:35, Tuesday 17 April 2018 (41507)IOO
Attached is the IMC alignment values from before the EOM swap by Koji and Peter.  We should return IMC alignment to these values if the PSL irises were set up before anything was done to the PSL table.
Images attached to this comment
sheila.dwyer@LIGO.ORG - 21:15, Tuesday 17 April 2018 (41510)

I've left the alignment sliders as they were last night, this is the alingment that Craig had used to lock the IMC between the EOM and PMC swap.  If the irises were set after the EOM swap then these might be a good reference for recovering the IMC alignment. 

Images attached to this comment
peter.king@LIGO.ORG - 05:05, Wednesday 18 April 2018 (41511)
Attached is a coincidental shot of the table I took yesterday.  The two irises are (poorly) marked in the photo.
The first is before the second lens located after the EOM.  The second is the smaller iris located before the
mirror at the base of the IO periscope.  Both irises were positioned before the pre-modecleaner was replaced.

    The laser and pre-modecleaner had been off for about an hour before I went into turn things back one.  After
re-locking the pre-modecleaner, I checked the beam position on the irises.  To me the beam appeared slightly high
on the first iris and okay on the second iris.  The image of the pre-modecleaner reflected spot was also slightly
different.  However I would expect that things would return one the pre-modecleaner warmed up.  This is also
true with the "old" pre-modecleaner.
Images attached to this comment
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 18:30, Tuesday 17 April 2018 (41503)
H1SUSOPO Update: V2 OSEM Replacement is Successful, TFs Look Good, especially with HAM6 ISI Unlocked
J. Kissel

Following up on all the work from yesterday replacing the V2 OSEM on H1SUS OPO (ID of problem: LHO aLOG 41468, Replacement LHO aLOG 41470), I've had a bit of time between HAM6 SQZ Team Closeout Activity to grab a set of undamped Euler basis TFs.

Attached are the results.

One can see -- especially in pitch -- that swapping the V2 OSEM has moved out the PD-to-Coil cross-coupling zero to the typical ~10 Hz, and fixed the problem.

The TFs are pretty noisy, but not unexpectedly so: while the ISI was unlocked, the chamber was still half-open letting in SQZ light, so I expect purge was still flowing heavily over the OPOS.

I'd like to get
    - A Repeat of the Euler basis TFs,
    - OSEM basis TFs,
    - Damped TFs,
one morning when we have the chamber door parachutes completely closed, and pulled away from the ISI (as was true for the 2018-04-02 data).
Non-image files attached to this report
H1 SUS (ISC, SQZ, SUS)
jeffrey.kissel@LIGO.ORG - posted 18:22, Tuesday 17 April 2018 (41502)
ZM1 Update: ECD Magnets Pulled In, TFs still abnormal but likely acceptable
J. Kissel, T. Shaffer 

While in HAM6 fixing the OPOS (LHO aLOG 41468), TJ noticed that the ECD magnets for ZM1 were still far away from being engaged and functional. He moved them into place, so I've retaken TFs to ensure there's no *new* rubbin. There is no new rubbing. We're otherwise still as it was left at the end of March LHO aLOG 41181.

Attached are the usual metrics.

The remaining flaws: 
   - L2L doesn't show the primary pitch mode
   - Y2Y shows the primary L mode
   - The Y2Y primary Y mode is lower in frequency than other HTTSs.
   - When damped, the primary Y mode's Q is reduce, but the unwanted L mode still shows up with the original Q in the Y2Y TF.

I'll talk with TJ again, in hopes to recreate he and Betsy's two-OSEM test -- hopefully if I witness it, I'll understand the results better and offer further suggestions.
Non-image files attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 18:15, Tuesday 17 April 2018 (41501)
Installed new 10" gate valve @ X-end Main Turbo Pump inlet
Gerardo M., Tyler G., Kyle R. 

Today we replaced the "legacy" 10" Cetek gate valve with a new 10" VAT valve.  I am pumping the turbo volume with a leak detector overnight and will leak check the turbo-side joint tomorrow.  

Fun Fact -> I, necessarily, started and will be running overnight the instrument air compressors (located in the chiller yard)
H1 PSL (PSL)
richard.savage@LIGO.ORG - posted 18:03, Tuesday 17 April 2018 (41500)
PMC swap complete

PeterK, JasonO, EdM, RickS

Today, we swapped out the original PMC for one of the new "All-bolted" PMCs (see LIGO-T1700543-v2), S/N007 (photos attached)

We aligned the PMC, FSS and ISS paths, locked the servos and adjusted the light levels and gains.

When we increased the power into the PMC to ~ 20 W, we noticed that the modematching to the PMC was degrading.

We found that the first turning mirror downstream of the new 70-W amplifier is damaged (extremely bright glow where the beam is reflecting from the surface (if you zoom on the photo below you will see the bright spot on the surface - 9:00, slightly left of center).  This is likely the cause of the change in the beam characteristics with power.

We plan to swap this optic out first thing tomorrow.

 

Images attached to this report
H1 ISC (AWC)
terra.hardwick@LIGO.ORG - posted 16:36, Tuesday 17 April 2018 - last comment - 09:24, Thursday 19 April 2018(41490)
Output beam study, clipping?

Aidan, Daniel V-H., TVo, Dan B., Terra

This is the initial analysis of the HAM6 output beam scan we did last weekAttached is the overall picture, in the style of LLO's beam study.

Measurements are done in HAM6 during single bounce configuration (no TCS) either directly in beam or using pickoff. Data is then fit by varying input beam parameters and, to some degree, OM optical/path length parameters. These are compared against the original output beam design. (There is a caveats to this, see below.) Since there was large astigmatism, what I show is beam fit prioritized to fit vertical measurements. [R,w] directly after SRM for design and vertical fits shown in plot. X-axis distances are in meters from SRM.

Main points:

Caveat/to do: the design beam includes a 50km ITM lens, so I need to subtract that for more meaningful comparison; in the works.

For reference, the parameters used are:

 

Images attached to this report
Comments related to this report
terra.hardwick@LIGO.ORG - 10:20, Wednesday 18 April 2018 (41517)

Adding screen shot of raw data from beam scanner: horizontal data on top, vertical on bottom. A one-sided pedestal on the right side of top plot can be seen. This measurement was taken ~10 inches from the edge of the ISI table closest to the septum window in the beam path as it enters HAM6 from SRM to OM1.

Images attached to this comment
aidan.brooks@LIGO.ORG - 09:24, Thursday 19 April 2018 (41541)

I enhanced the bottom image [vertical cross-section of beam] and rescaled it to the same horizontal and vertical scale as the top image [horizontal cross-section of beam], then I pasted this over the top image. Horizontal cross section = thin white line. Vertical cross-section = thick black line. 

This highlights the excess power in the right hand side of the horizontal cross-section.

Images attached to this comment
H1 SEI
hugh.radkins@LIGO.ORG - posted 16:40, Tuesday 10 April 2018 - last comment - 15:44, Thursday 19 April 2018(41368)
Attempt to Update ISI code for smooth Isolation loop ramp down from Watchdog Trip.
ISI code change to ramp DAC drive down when watchdog trips and not instantaneously
go to zero volts. Dave composed this and I added in red text.

Hugh and Dave. 10 April 2018
WP7462 to implement ECR E1800026 addressing II 9889 with details explained by Stocks & Lantz in T1800031.

Summary: we attempted to test the new ISO_RAMP code, but were unable to
reach that point due to filter modules outputting very large signals.
We abandoned the test and restored the code and hardware back to its original
configuration.

----------------------------------------------------------------------------

Hugh elected to test the new code on h1isietmy.

Using the latest isi/common/models/isi2stagemaster.mdl (r17117)
which uses the new isi/common/models/cushion_DOF.mdl (r17116)
and the associated C code isi/common/src/RAMP_ISO_OFF.c (r17084)
we compiled and installed h1isietmy.

Following a C code review by Jonathan, it was expected that the model
would have problems if the ramp time is zero of a divide-by-zero nature.
Our first test was to execute the if-conditional block
which would run the divide-by-zero lines.

While Hugh was manually causing watch dog trips, he noticed that the ISI DAC channels 
were negatively railing to -10.0 Volts. 
This was tracked to ST1 and ST2 OUTF filters having a railed output of 1.0e+20
with a zero input. These filter modules have two filters installed: Comp and Sym.
We found that the Sym filter (a simple gain stage) was causing the output to shoot
to rail on WD trip. It was not obvious to us why this was happening.
The rail could be removed by clearing the FM history, and could be prevented by
turning off the Sym filter. Are you sure? Hugh's not sure if we ever prevented it...

After further setup work Hugh discovered that ST[1,2] RZ T240SUBTRACT_Z filter modules
were also railing at 1.0e+20.

Due to the violent motion being caused by the ISI DAC outputs instantaneously
driving to -10.0V each time the watchdog was tripped, we needed to stop the DAC
output from driving the DAC cards. Our first attempt was to SWWD trip the output
of the h1iopseiey model. However, the ISI code and/or guardian monitors this and
this prevented our test from proceeding. Could not get the guardian to run with IOP(software WD) tripped. We eventually had to go to EY and power
off the anti-imaging (AI) chassis for the ISI DAC. We could then green up all the software
watchdogs and still be sure that no sudden motion was being driven to the seismic stack.

Hugh spent a further hour trying to get the isolation ramp code to be executed,
but was being thwarted by the misbehaving filter modules. Same drive to 1e+20 counts & -10Vs.

We decided to abandon the tests as maintenance time was running out, and to 
revert the code back to what it was.

I reverted the svn version of isi/common/models/isi2stagemaster.mdl from 
r17117(05apr2018) to r16398(31oct2017), and isi/common/models/isihammaster.mdl
from r17118(05apr2018) to r16422(06nov2017).  Thank you Dave!

I rebuilt h1isietmy and we were happy to see the DAQ INI file return to its original
content. We verified the checksum of the INI file was as it was originally.
When the model was restarted, the DAQ-ini-mismatch error was cleared, so no
DAQ restart was needed.

Hugh then damped ISI-ETMY with no re-occurance of the 1.0e+20 FM outputs.  Finally, using the ISI Guardian (no SEI Manager) the stages isolated stabily.

As far as the code problem--Don't have it to look at now since Dave reverted but I suspect some  X Y Z etc DOF wires got crossed.  Don't know if that addresses the railing FMs but it would not help.

 
Comments related to this report
brian.lantz@LIGO.ORG - 17:28, Tuesday 17 April 2018 (41499)CDS

I'm trying to reproduce the issue on our test-stand but I can not.

First test shows the behavior is what I expect - I set the filter module for stage 1, X, to just be a constant (100), gain =1,  and turn the filter modules off so that the output of the filter is 100.

Then I trip the watchdog and compare the signal at the filter output to the signal at the output of the ramp stage. I do this 2 times, first with a ramp time of 0, and once with a ramp time of 0.1 sec. In the two attached plots one can see that the red filter module output drops immediately to 0, while the ramp output (blue triangles) either drops immediately to 0 or ramps to 0 in 0.1 seconds. I do not see a big glitch. I wonder what the heck is going on - will follow up with Hugh ASAP.

-Brian

 

Images attached to this comment
hugh.radkins@LIGO.ORG - 08:53, Wednesday 18 April 2018 (41515)

Hey Brian,

We never even got to try the smooth ramp as we could not get the system isolated.  We did not think to try a fake isolation state as I think you are indicating.

dane.stocks@LIGO.ORG - 15:44, Thursday 19 April 2018 (41551)
Hi Hugh,

I did a quick test just now. In the isi2stagemaster model, I went through both stage 1 and stage 2 paths to ensure that there were no "crossed-wires." That is, I went through each dof in the isolation bank and ensured that an input signal appeared as it should in the final output of each stage (a 1 count offset in ST1 X appeared as solely a 1 count output in ST1_OUTF H1, etc). (note - we set the cart2act matrix to be the identity matrix for our convenience in this test - so X goes to H1, etc) For the stage 1 path I ensured this also held true for the ST1_ST2_DRIVE_COMP. This indeed held true in the updated model, the one with the changes Brian and I made. Thus we think that the problem lies elsewhere, possibly in the way that the model was started on the H1 machines; it is my understanding that IOP model was not restarted after grabbing the updated model from the svn. However, if you have any further suggestions for us to investigate, please send them our way.
Displaying reports 43741-43760 of 84095.Go to page Start 2184 2185 2186 2187 2188 2189 2190 2191 2192 End