Displaying reports 61161-61180 of 83068.Go to page Start 3055 3056 3057 3058 3059 3060 3061 3062 3063 End
Reports until 15:53, Tuesday 13 October 2015
H1 AOS (ISC)
evan.hall@LIGO.ORG - posted 15:53, Tuesday 13 October 2015 (22491)
HAM2 illuminator turned off

Richard, Jeff, Evan

It had been on for at least several months.

H1 CAL
travis.sadecki@LIGO.ORG - posted 14:57, Tuesday 13 October 2015 (22489)
LHO Pcal EndX and EndY calibration measurements

Darkhan T., Travis S.

During today's maintenance period, we took PCal calibration measurements for both end stations.  Attached are photos of the datasheets (mostly for our own reference).  Analysis of the data to follow.

Images attached to this report
H1 TCS
jeffrey.bartlett@LIGO.ORG - posted 14:42, Tuesday 13 October 2015 (22488)
Add Water to TCS Chillers
Added 205ml cooling water to the TCSX chiller. First water added to TCSX in the past month.

Added 600ml cooling water to the TCSY chiller. Given the amount of water loss with the TCSY Chiller but not with the TCSX Chiller over the past three weeks, I am suspicious there is a leak in the TCSY cooling loop.    

I added marks (at 1/4 , 1/2, and 3/4) next to the site glass so we can more easily track water loss.   
H1 SEI (ISC)
hugh.radkins@LIGO.ORG - posted 14:33, Tuesday 13 October 2015 (22486)
HEPI Actuator Flushing Stand is Now Operating

and has been continually since Monday afternoon at ~39hz (1150rpm [19hz] at motor/pump.)  Let me know if this is a problem.

H1 IOO (PSL)
kiwamu.izumi@LIGO.ORG - posted 14:14, Tuesday 13 October 2015 - last comment - 14:33, Tuesday 13 October 2015(22482)
IMC WFS offset disabled, RIN became a bit better

I have disabled the IMC WFS offsets that Keita and Cheryl wanted to remove (alog 22370).

This may help the recent ISS issue (alog 22449) somewhat, but probably not a lot.

 

Background

I was investigating why the ISS recently started having the trouble in engaging the 2nd loop. A first thing I noticed is relatively high RIN after the IMC. It seems that the IMC adds some extra RIN below 1 Hz as the light goes through it. A large RIN at low frequencies can easily hinder the PID control of the 2nd loop when engaging. So this seemed suspicious to me.

Since the ISS 2nd loop had been running without a significant issue in the past, perhaps until the recent change on the IMC WFS (alog 22362), I speculated that the current IMC alignment is at a non-optimal point where the low frequency RIN became worse. One factor which affects the IMC alignment is the WFS offsets that are meant to minimize the jitter-to-RIN couplings. In the end, I decided to get rid of the offsets because it gave a better RIN coupling.

 

IMC_LOCK guardian edited

To disable the offset, I have commented out lines 555 and 556 in the IMC_LOCK guardian. They are now,

#ezca.switch('IMC-DOF_2_P', 'OFFSET', 'ON')
#ezca.switch('IMC-DOF_1_Y', 'OFFSET', 'ON')
 

RIN is better without the offsets

I did a simple test where I measured RIN after the IMC with and without the WFS offsets. Note that the offsets have been applied only on DOF2_P and DOF1_Y. They have not yet been optimized after the change in the IMC WFS. The measured RIN are shown in the attached screenshot.

Blue: RIN at the ISS in-vac array without the offsets, Cyan: RIN at the ISS in-vac array with the offsets, Brown and red: RIN before the IMC with and without the offsets, respectively. The 1st loop was always ON while the 2nd loop was always OFF. The input power was about 2 W.

First of all, it is clear that RIN after the IMC is higher than that before the IMC by a factor of more than 10 at around 0.1 Hz. I am not sure how long it has been like this.

Next, as shown in the plot, removing the offsets reduced the excess RIN below 1 Hz somewhat at the in-vac ISS array. This was repeatable and therefore I think the improvement is real. Additionally, it got rid of a nasty structure at around 600 Hz.  Also, some peaks above 100 Hz decreased their peak heights by a factor of few. These improvements were consistenly observed at IMC-MC2_TRANS_SUM as well. Therefore I think they are real improvement in RIN and not some kind of spurious couplings such as spatial jitter.

So overall, the configuration without the offsets seems better in terms of RIN. Perhaps this is an indication of better WFS sensing. I decided to disable the offsets in the IMC_LOCK guardian. I did not try to optimize the offsets yet. So this can be a next action item.

Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 14:33, Tuesday 13 October 2015 (22485)

SDFs are updated so as to accept the no-offset configurations in ASCIMC.

H1 IOO (ISC)
jeffrey.kissel@LIGO.ORG - posted 14:10, Tuesday 13 October 2015 (22483)
Cleaning Up the IMC WFS OFFLOAD Process and other Confusing Options
J. Kissel, S. Dwyer

While prepping for the PSL incursion today, we had supposed that we should offload DC values the IMC WFS CTRL OUTPUT to the IMC SUS's alignment sliders, a.k.a. "offload the MC WFS." This process has been historically dubious because there have been many MCWFS offloading scripts in various states of completion / testing, and the request to run the script from the IMC_WFS_MASTER MEDM screen does not tell you what script it is running, nor gives any indication that it has run or finished. 

Today we've made this better.

We've
- Removed 
${userapps}/release/ioo/h1/scripts/imc/mcwfsrelieve
${userapps}/release/ioo/common/scripts/mcwfsrelieve.py
from the svn repo.
- Edited 
${userapps}/release/asc/common/scripts/imc/offloadMCWFS.py
to display text indicating the progress of the script as it goes (and committed to the userapps repo)
- Edited 
${userapps}/release/asc/common/medm/imc/IMC_WFS_MASTER.adl
to call the offload script using xterm, such that a terminal pops up and displays standard out, i.e. the call to run the script in MEDM is now
xterm -g 140x10 -hold -e $(USERAPPS)/asc/common/scripts/imc/offloadMCWFS.py
- We've also edited the script to round off to the 10000th of a count (five decimal places), such that one can accept new offsets into any SDF system without having to worry about the precision problems that SDF has with small numbers.
We've successfully run the script 3 times, so we're sure that functional.

You should now call the offloading of WFS from the IMC_WFS_MASTER screen, as circled in red in the first screenshot. You should then see an xterm window pop up, and it'll walk through its processes -- see second attachment.

All of this infrastructure (as indicated by the paths) is common infrastructure that has now been committed to the repo. As such, LLO, needs only to update the screen and script to absorb the new goodness.
Images attached to this report
H1 ISC
sheila.dwyer@LIGO.ORG - posted 13:52, Tuesday 13 October 2015 (22481)
change to arm IR locking

Due to oscialltions in the X arm IR loop that were causing difficulties in inital alingment, (22443), we made a small change to the Xarm locking filters today (WP#5558).  

There was a pole at 100 Hz that did not make much sense, we moved it to a kHz now, which gives us an extra 40 degrees at the ugf of 100 Hz.  Before and after rms and transfer function screenshots are attached.  This should solve the egregious problem with the 1206 Hz instability, but there are still problems with the loop, which due to the distribution filters in MC2.  These distribution filters are used in MCL, ALS COMM and CARM loops, so we will not try to fix these today.  

First, note that the rms of M2 and M3 are both dominated by things below 0.5 Hz, meaning that we need a boost in the top stage.  We could probably skip M2 altogether as we have done with the recycling mirrors.  Also, Evan and Jeff note that the loop is rather flat around 100 Hz, which is because of a 41z:150p in MC2 M3.    

Images attached to this report
H1 INJ (CAL, INJ, SYS)
duncan.macleod@LIGO.ORG - posted 12:50, Tuesday 13 October 2015 (22479)
Updated ODC EPICS configuration for PINJX

[Jeff K, Duncan M]

ODC EPICS changes

With Jeff's assistance (and that of the on-duty operator) I have remotely updated the EPICS configuration for ODC to commission the state monitoring for the new PINJX infrastructure [alog 22445 22465 22470 22473].

Changes were made to EPICS records in the h1calex, h1iscex, and h1odcmaster models as follows

These changes have been monitored and accepted in SDF for the relevant models and can serve as a reference for L1 when the same changes are made next week.

ODC MEDM changes

Associated changes were made to the ODC MEDM screens in order to show the CAL_X ODC input. This required separating the SYS_CUST_ODC_MASTER_END.adl screen into separate screens for MASTER_X and MASTER_Y (no CAL_Y ODC). These changes were committed to userapps as r11886.

H1 CDS
patrick.thomas@LIGO.ORG - posted 12:19, Tuesday 13 October 2015 (22478)
Updated Conlog channel list
Added H1:SUS-SR3_M2_TEST_P_OFFSET to the exclude list and rescanned.

Added 70 channel names. Removed 11 channel names. All except H1:SUS-SR3_M2_TEST_P_OFFSET were H1:CAL channels.
H1 PEM (DetChar)
jordan.palamos@LIGO.ORG - posted 12:03, Tuesday 13 October 2015 (22474)
Replaced PEM accelerometer on BSC10 Z axis. Also connected X axis.

Josh reported H1:PEM-EY_ACC_BSC10_ETMY_Z as glitchy in an email Oct 5. Today during maintenance I went down to EY and replaced the accelerometer and also put it through a different channel (channel 1) on the endevco (accelerometer power supply / signal conditioning box), pictures attached. The cable going into the sensor itself was slightly loose before I changed anything.

Looking back at the history of this channel (also attached), it looks like this accelerometer went down at ~17UTC on Sep 8 and started working again on Sep 14 ~19UTC for unknown reasons (possibly loose cable).  I don't know whether the glitchyness reported by Josh continued after the 14th, when the timeseries returned to expected values. In any case, there is a new sensor there now and spectra/timeseries both look good.

Also, I had noticed that H1:PEM-EY_ACC_BSC10_ETMY_X had been unplugged at the electronic racks, so I plugged it back in (looks like its been unplugged since last tuesday).

 

Images attached to this report
H1 INJ (CAL)
jeffrey.kissel@LIGO.ORG - posted 11:55, Tuesday 13 October 2015 (22473)
PCAL Inverse Actuation Filter Copied over to PINJX_HARDWARE and PINJX_BLIND Filter Banks
J. Kissel
ECR E1500386
WP 5553
II 1126

I've copied over the PCAL Inverse Actuation filter, as recently updated by Sudarshan (see LHO aLOG 22185). For the record, the foton design string is

zpk([0.01;0.01],[1215.5+i*6893.7;1215.5-i*6893.7;7000],3.4514e+12,"n")*gain(3994.47)

The filters have been turned ON as shown.

I've accepted the filter states in the SDF system. In the process, I've also made sure that the "CHANS NOT MONITORED" list is the same between CAL-CS and CAL-EX. In summary, they're the EPICs "readback" channels that get filled in with TINJ and the EXTERNAL ALERT system, and the ODC string records that tell what each ODC bit means (see attached screenshot).
Images attached to this report
H1 SEI (DetChar, SEI)
jenne.driggers@LIGO.ORG - posted 11:35, Tuesday 13 October 2015 - last comment - 13:05, Tuesday 13 October 2015(22477)
Comparison of 45mHz vs 90mHz ISI blend filters

Over the last few days, we've been trying out the new 45 mHz blend filters for the BSC ISIs, which are designed to help out during times of high microseism. 

This aLog is just meant to be a collection of logs relating to the switching, to help Team DetChar know which state things were in at which times, so they can hopefully make a comparison.  One of the things that might be most interesting is the effect on the artifacts that Josh pointed out in aLog 22405.

Some of the logs that have talked about the switching back and forth include aLog 22440 and aLog 22459.

Looking at the SWSTAT of the ISI-[chamber]_ST1_BLND_[x or y]_CPS_CUR_SWSTAT channels I can see when the blends were in each state.  FM7 is the nominal 90mHz blends (SWSTAT = 40000), and FM9 is the new 45mHz blend (SWSTAT = 40192).  Below is a table of the lock stretches in each state.

90 mHz blends (nominal) 45 mHz blends (new)
all locks through the one ending 10 Oct, 21:25 UTC  
  11 Oct 16:22 UTC - 12 Oct 18:11 UTC
  13 Oct 00:53 UTC - 13 Oct 09:30 UTC
13 Oct 11:35 UTC - 13 Oct 14:43 UTC  
Comments related to this report
sheila.dwyer@LIGO.ORG - 13:05, Tuesday 13 October 2015 (22480)

For some background, 45 mHz blends provide us with isolation at the microseism, which may be partially coherent between the buildings. When we lock with 90 mHz blends, we lock the position of the ISI to stage 0 at the microseism frequencies.  With the normal seismic environment at LHO we find this better, because the interial sensors confuse wind induced building tilt with translation at these frequencies and if we try to use them to isolate they move the ISI in response to these spuirious signals.  

In the fall, we tend to have less wind and more microseism, meaning that our seismic environment can sometimes be more similar to LLO's normal situation.  Using the 45 mHz blends which are more similar to LLO's had allowed us to lock durring a high microseism, low wind time when we were unable to lock on our normal 90 mHz blends.  We know that durring winds above about 20 mph we will be imposing spurious tilt signals on the ISI with these 45 mHz blends, which can make locking imposible or difficult.  

So can you tell us the impact of these blends on DARM by comparing lock stretches with similar microseism and wind but different blends?  It would be good to know this for a few different environmental conditions, (say winds below 15 mph and microseism high, and winds from 15-30 mph and microseism high). 

H1 SEI
hugh.radkins@LIGO.ORG - posted 11:35, Tuesday 13 October 2015 (22476)
HEPI CS Pump Pressure cabling returned to nominal

Re WP 5527 & alog 22305, I've returned the cabling to its nominal connections.

H1 SEI
hugh.radkins@LIGO.ORG - posted 11:29, Tuesday 13 October 2015 (22475)
HEPI Fluids Checked--No further HEPI Maintenance

nm

H1 ISC (GRD)
sheila.dwyer@LIGO.ORG - posted 11:04, Tuesday 13 October 2015 - last comment - 23:35, Tuesday 13 October 2015(22472)
Added PRMI branch to ISC_LOCK guardian

I've rearranged the PRMI branch in the DRMI guardian, and added states to the ISC_LOCK guardian to request both these states and the ALIGN_IFO states used for PRMI  (finshing unfinished item from WP5533).  This is for use when you think that the DRMI alignment is bad (based on the AS camera and the flashes as seen in dataviewer)  and will not lock.  If DRMI is slow to lock but has been locked recently and looks well aligned on the AS camera, this procedure is probably not your best bet.

We will test this durring maintence recovery today, but the instructions replacing those in 21745 will be:

done!

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 14:35, Tuesday 13 October 2015 (22487)

This has now been tested, and had some bugs but after fixing several typos we made a sucsesfull transition from PRMI to DRMI.  If you are trying to lock DRMI and decide to change to PRMI, you would need to take ISC_LOCK to manual, then request LOCK_PRMI, and go back to AUTO.

corey.gray@LIGO.ORG - 23:35, Tuesday 13 October 2015 (22503)

And remember "Manual" will be on the "ALL" screen for ISC_LOCK (it's the pink button on the upper left).  [I forgot where this button was and had to call Sheila!]

H1 AOS
betsy.weaver@LIGO.ORG - posted 15:07, Friday 09 October 2015 - last comment - 15:13, Tuesday 13 October 2015(22371)
SUS OSEMINF and NOISEMON Spectra Templates added to OPS directory

On Tuesday, while most of the IFO was down for various maintenance tasks, I grabbed a bunch of SUS spectra and started a Template directory. 

I set all of the references to be the ~quiet, unlocked data from the down period of the IFO.  These spectra could be run when trying to troubleshoot locking.  On Tuesday, I was only able to collect the following, located in /ligo/home/ops/Templates/SUS_Spectra/

BS_NOISEMON_spectra.xml

BS_OSEMINF_spectra.xml      

PR2_NOISEMON_spectra.xml

PR2_OSEMINF_spectra.xml  

PRM_NOISEMON_spectra.xml

PRM_OSEMINF_spectra.xm

SR3_NOISEMON_spectra.xml

SR3_OSEMINF_spectra.xml

SR2_NOISEMON_spectra.xml

SR2_OSEMINF_spectra.xml

SRM_NOISEMON_spectra.xml

SRM_OSEMINF_spectra.xml

ITMX_NOISEMON_spectra.xml

ITMX_OSEMINF_spectra.xml

ITMY_NOISEMON_spectra.xml

ITMY_OSEMINF_spectra.xml
 

NOTE - Many of the lower stage NOISEMON channels look... weird.  They should be used as a before/.after snapshot for troubleshooting only.  Work to improve what the various strangenesses of these channels is on a few low priority to-do lists.

There are templates ready to collect the balance of the SUS spectra data, namely ETMs, MCs, PR3.  We should do this when the IFO is set to DOWN for whatever reason.  The spectra are quick to run, then update all references (currently bogus data) and resave.

Comments related to this report
travis.sadecki@LIGO.ORG - 15:13, Tuesday 13 October 2015 (22490)

While we were unlocked due to wind during my Sunday Owl shift, I managed to get through taking, updating, and resaving templates for:

ETMX_NOISEMON_spectra.xml

ETMX_OSEMINF_spectra.xml      

ETMY_NOISEMON_spectra.xml

ETMY_OSEMINF_spectra.xml  

PR3_NOISEMON_spectra.xml

PR3_OSEMINF_spectra.xml

H1 IOO
keita.kawabe@LIGO.ORG - posted 23:39, Thursday 08 October 2015 - last comment - 14:31, Tuesday 13 October 2015(22362)
IMC WFSA quadrant gains all set to 1 (Cheryl, Keita)

We set all quadrant gains of IMC WFSA to [1 1 1 1] from [1, 0.25, 1, 4]. (WFSB was already all 1.)

We also disabled IMCWFS error offsets in servo filters.

After this, we steered IM2 to bring the beam position on IM4 trans back (at first we tried IM3, but it would make the OSEM output to become larger, and they're already close to saturation).

IFO locked after this without any problem.

We haven't done any jitter coupling optimization and I don't know if Robert had time to do it.

Comments related to this report
keita.kawabe@LIGO.ORG - 12:01, Friday 09 October 2015 (22370)

The first and the second attachment show the current and the old settings, respectively.

In the first one, yellow boxes show what we changed. Red box show what we changed but are somehow reverted (automatically?).

  • IMC WFSA I2, Q, I4, Q4 gains were set to 1 based on the measurement done in July (alog 20065).
  • IMC WFSA and WFSB head input matrix (not the WFS servo input matrix) were changed. This is apparently used to account for 90deg-ish geometric rotation of the beam due to non-ideal use of periscope inside HAM2.
    • Quickly measured by injecting a 20Hz-ish line into IOOPZT PIT or YAW, one at a time, and minimizing YAW or PIT error.
    • WFSA matrix didn't change much. Rotation doesn't seem to make sense, but I haven't done the PIT/YAW sensing calculation for a rotated beam myself. I'll do it and see if it really doesn't make sense.
    • WFSB matrix now looks more like a 90 degree rotation.
  • We disabled the offsets but somehow they were enabled again, it seems.
Images attached to this comment
kiwamu.izumi@LIGO.ORG - 14:31, Tuesday 13 October 2015 (22484)PSL

This is just an observation related to entry 22482 where I was investigating the relation between ISS and IMC.

After Keita and Cheryl set the IMC WFS gains back to 1, it seems to have shifted the pointing to the ISS array a little bit. See the attached trend.

The QPD signals at the ISS array have moved by 0.1 or so both in PIT and YAW when the WFS gain was changed to 1. Both PIT and YAW moved towards the center of the QPD although SUM seems to have decreased at the same time. I am not sure what exactly was going on. We may need to optimize the pico-motors to minimize the jitter-coupling to the ISS array.

Images attached to this comment
Displaying reports 61161-61180 of 83068.Go to page Start 3055 3056 3057 3058 3059 3060 3061 3062 3063 End