Displaying reports 67741-67760 of 84507.Go to page Start 3384 3385 3386 3387 3388 3389 3390 3391 3392 End
Reports until 15:35, Thursday 12 March 2015
H1 ISC
daniel.sigg@LIGO.ORG - posted 15:35, Thursday 12 March 2015 (17227)
Shutter installed in EX/EY main green beam

New uniblitz shutters (VS35) are installed in the main green path of ISCTEX and ISCTEY. Jumpers were set to VS35. In EY the A channel seems broken and we are using the B channel for now. Procedure for making cables and setting jumpers have been added to the dcc and the wiki.

Removed the ALS_REFL_B PDs in both end stations. For EX the software limit needs to be removed, otherwise the PDH autolocker barks.

H1 General (CDS, DetChar, SUS)
ryan.fisher@LIGO.ORG - posted 14:30, Thursday 12 March 2015 - last comment - 19:48, Friday 13 March 2015(17224)
ODC Work Wednesday and Thursday Morning
Ryan F., TJ Massinger, Stefan

We edited the following models in the local copy of userapps without committing them.  We tested that all of these compiled successfully (and emailed CDS about some RCG bugs found when using GoTo and From parts in the models).  Screenshots demonstrating the changes are attached.  

We added a proper ODC channel (mostly still placeholders with no inputs or logic) for the following models to replace the current placeholders:
 h1pemey  
 h1pemex
 h1caley
 h1calex
 h1iscex
 h1iscey
  these last two require the changes to sys/common/models/ODC_MASTER_PARTS_V2.mdl
 h1alsex
 h1alsey

We also edited the h1omc model that was installed Tuesday to add checks on DCPD_A,B and PZT2_MON_AC error signals.
 h1omc
  requires changes to omc/common/models/omc.mdl

All of these models should be ready to be make-installed, restarted and committed to the SVN during the next maintenance period.

We also edited PSL_STATUS.adl locally to fix a white box (changed H1:PSL-ODC_CHANNEL_OUTPUT to H1:PSL-ODC_CHANNEL_OUTMON)

We created a new MEDM screen for ASC_ODC.adl and fixed some errors in the LSC_ODC.adl created by Duncan M.  These screens are not yet linked to any other MEDM screens.

We also committed a new safe.snap file for h1odcmaster.
Images attached to this report
Comments related to this report
ryan.fisher@LIGO.ORG - 19:48, Friday 13 March 2015 (17261)DetChar, IOO
I made some additional changes to the staged OMC changes:  These affect omc.mdl and omclsc.mdl.  The changes add EPICs outputs to display intermediate steps in the ODC_SUBSTATE calculations.  The added outputs are shown in the attached screenshots.  These changes have not been committed to SVN, but the h1omc.mdl model has been tested to successfully compile.  
Images attached to this comment
H1 GRD
jameson.rollins@LIGO.ORG - posted 11:19, Thursday 12 March 2015 - last comment - 14:40, Thursday 12 March 2015(17223)
purged USERAPPS/guardian directory from USERAPPS checkout

The top-level USERAPPS/guardian directory was purged from the CDS_USER_APPS SVN last week, as it was no longer used (it had been used only by the old now-defunct guardian implementation).  I did an "update" on this directory in our local checkout (/opt/rtcds/userapps/release), which purged most things from the directory.  I then removed the accumulated cruft and purged the entire directory.

Comments related to this report
jameson.rollins@LIGO.ORG - 14:40, Thursday 12 March 2015 (17225)

The USERAPPS/guardian directory has been UNPURGED.

It turns out that at least the ISI "command scripts" were using the CaTools.pm perl module that was located at USERAPPS/guardian/CaTools.pm, and were therefore broken after the purge of the guardian directory.  I therefore checked out the directory from the version directly before the purge (r9933) (see below).  This got the ISI "comman scripts" working again.

I had sent multiple emails about this directory being purged, and received no response.  We need to figure out what is being used from here and transfer them somewhere else to be more properly maintained.

jameson.rollins@operator1:/opt/rtcds/userapps/release 0$ svn co -r9932  https://redoubt.ligo-wa.caltech.edu/svn/cds_user_apps/trunk/guardian
A    guardian/test.pl
A    guardian/simulator.pl
A    guardian/GuardTools.pm
A    guardian/guardManagerMakeMEDM
A    guardian/runManager
A    guardian/guardManagerMEDM
A    guardian/makeGuardian.pl
A    guardian/generate_alarms.pl
A    guardian/guardMakeMEDM
A    guardian/makeBurtPatch.pl
A    guardian/caswitch
A    guardian/guardExec
A    guardian/documentation
A    guardian/documentation/DirectoryStructure.graffle
A    guardian/documentation/DirectoryStructure.pdf
A    guardian/documentation/verify_TEMPLATE
A    guardian/documentation/ligodoc.cls
A    guardian/documentation/medm_FAIL.png
A    guardian/documentation/medm_BURT.png
A    guardian/documentation/guardian.pdf
A    guardian/documentation/verify_TRANSIT_TEMPLATE
A    guardian/documentation/goto_TEMPLATE
A    guardian/documentation/ISC_Common.png
A    guardian/documentation/medm_TIMEOUT.png
A    guardian/documentation/itmx_scripts.png
A    guardian/documentation/medm_GOOD.png
A    guardian/documentation/transit_TEMPLATE
A    guardian/documentation/Guard.png
A    guardian/documentation/guard_medm.png
A    guardian/documentation/guardian.tex
A    guardian/userHost.substitutions
A    guardian/makeBurtPatchSimple.pl
A    guardian/makeAllGuardians.pl
A    guardian/generateChannelList
A    guardian/CaTools.pm
A    guardian/runGuardian
A    guardian/test
A    guardian/test/gcd
A    guardian/test/restoreSnapshot.pl
A    guardian/test/watchAlarm.pl
A    guardian/test/watchValue.pl
A    guardian/test/defaultChannelList.req
A    guardian/test/cleanUp.pl
A    guardian/test/gxd
A    guardian/test/logs
A    guardian/test/logs/guardian.txt
A    guardian/test/readSnapshot.pl
A    guardian/test/makeSnapshot.pl
A    guardian/test/guardian.txt
A    guardian/test/caStep.pl
A    guardian/test/BURT.txt
A    guardian/test/gpd
A    guardian/test/autoBurt.req
A    guardian/python
A    guardian/python/README
A    guardian/script_templates
A    guardian/script_templates/transit_TEMPLATE
A    guardian/script_templates/verify_TEMPLATE
A    guardian/script_templates/goto_TEMPLATE
A    guardian/script_templates/verify_TRANSIT_TEMPLATE
A    guardian/gxd
A    guardian/dbGuardian.db
Checked out revision 9932.
jameson.rollins@operator1:/opt/rtcds/userapps/release 0$ 
H1 SEI
jim.warner@LIGO.ORG - posted 11:17, Thursday 12 March 2015 - last comment - 19:56, Thursday 12 March 2015(17222)
Change blend on BSC St2

After staring at the data I posted yesterday with JeffK, he suggested we try blending lower on the ISI in RZ. I saw that the blend filter we use on the HAM's was installed already on ETMX, so I decided to take advantage of this morning's non-commissioning period to make some measurements. The results are, um, good. See attached plots. Blue (st1) and green (st2) are the nominal configuration, red(st1) and brown(st2) are the different blend in the first plot, which is calibrated to rad/rthz. Second plot shows the CPS (low pass) part of the two blends, blue is the nominal, red is the new blend. I'm only attaching the RZ data, but every other degree of freedom shows improvement, which I only kind of understand, considering the ground motion was worse after I changed blends.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 19:56, Thursday 12 March 2015 (17241)
J. Kissel, J. Warner

During the process of exploring this better noise performance with ST2 RZ loops, he found that both the ETMs had been mistakenly running the high-blend-frequency, T750mHz, Z and RZ blend filters. This is why the performance in Z and RZ shown in LHO aLOG 17197 has a similar frequency dependence around 1 [Hz] as the 750 [mHz] blend that Jim shows in his second attachment, and why the performance in RZ isn't as good as expected. Recall that in this frequency region, assuming a single-stage-like system, if we're not limited by measurement noise (because we're using the GS13s to assess the performance), then we're limited by the ST2 CPS filtered by the displacement sensor blend (see T1300645, G1400134, or P1000103).

If one only saw Jim first plot, one might switch all BSC ISI ST2 platforms to the HAM, 01_28 blends. However 
(a) we later compared the 01_28 RZ performance (in brown) against the GS13 sensor noise, and the awesome double-notched out performance at 1 [Hz] is below the sensor noise -- the classic deceptive flaw of looking at an uncompensated in-loop sensor, 
(b) the HAM 01_28 blends have a really broad-band gain peaking of (a max of) ~1.5 between 30 and 500 [mHz], which translates to an order of magnitude (or more) more displacement below 0.1 [Hz] as shown in Jim's plot (we compared the ground motion in the two plots, and they're comparable, so it's not that there was an earthquake or high winds),
and 
(c) Jim ran out of time, so he hasn't added the 01_28 filters to every BSC yet.
In regards to (b), why does a displacement sensor filter gain peaking of 1.5 result in a factor 10 amplification and not just 1,5? As the good Dr. DeRosa says in SEI aLOG 645, 
"You always get MORE motion than the predicted gain peaking / amplification (below the microseism) because the tilt decoupling isn't perfect."

In lieu of switching everyone's Z and RZ to the 01_28 blends, Jim switched all of the platforms to the T250mHz blends. See attached for a comparison of all three options.

I think that the T250mHz will be the best compromise, because 
(a) The gain peaking is limited to a smaller region of 30 to 250 [mHz], and only maxes out at ~1.3,
(b) The notches in the HAM 01_28 blends are just digging us deep into the GS13 sensor noise floor. We will probably hit the GS13 noise floor with the T250mHz blends as well.

We'll check the performance overnight, especially with an *aligned* optical lever, and re-evaluate.
Non-image files attached to this comment
H1 GRD (SUS)
jameson.rollins@LIGO.ORG - posted 11:00, Thursday 12 March 2015 (17208)
Improvements to SUS guardian

I've made some improvements, and done a bit of cleanup, to the SUS guardian code.

Some of this was to clarify the SUS/ISC interface, after discussion with the ISC team.

To the main SUS.py (H1 is using a separate copy of this in sus/h1/guardian/SUS.py, so we should eventually merge these changes into the common SUS.py):

I then cleaned up the various ALIGNED_TO_PD* states that have been added to align optics to various baffle PDs.

All code has been committed, and SUS guardians have been restarted to pull in these changes.

H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 10:48, Thursday 12 March 2015 - last comment - 11:31, Thursday 12 March 2015(17219)
ETM HWS computers need updated .bashrc files

The ETM HWS computers currently have outdated .bashrc files that specify aliases and paths. I'm updating these.

 

Comments related to this report
aidan.brooks@LIGO.ORG - 11:31, Thursday 12 March 2015 (17220)

Some specifics:

H1HWSEY

The .bashrc file is the same as that on H1HWSMSR with the following modifications:

  1. Copied the old .bashrc to .bashrc.old.20150312
  2. Changed the environment variable name OPTIC_0 to ETMY_HWS
  3. Commented out OPTIC_1=ITMY_HWS environment variable
  4. Commented out PREFIX1=$IFO:TCS-$OPTIC1 environment variable
  5. Added 'stream_image_EY' alias: '/opt/Hartmann_Sensor_SVN/release/bin/stream_image_Y/distrib/stream_image_Y' (this file is called 'stream_image_Y' but that's just a name, the important thing is that it points to the first port on the capture card
  6. Commented out Run_HWS_ITMY and Run_HWS_ITMX aliases
  7. Added an alias: Run_HWS_H1ETMY='/opt/HWS/Run_HWS_Y/distrib/Run_HWS_Y'

The libraries for the MATLAB Runtime Environment are now properly identified in the path. I confirmed that stream_image_EY runs and displays the image from the camera. See the second attached image.

 

H1HWSEX

The .bashrc file is the same as that on H1HWSMSR with the following modifications:

  1. Copied the old .bashrc to .bashrc.old.20150312
  2. Changed the environment variable name OPTIC_0 to ETMX_HWS
  3. Commented out OPTIC_1=ITMY_HWS environment variable
  4. Commented out PREFIX1=$IFO:TCS-$OPTIC1 environment variable
  5. Added 'stream_image_EX' alias: '/opt/Hartmann_Sensor_SVN/release/bin/stream_image_Y/distrib/stream_image_Y' (this file is called 'stream_image_Y' but that's just a name, the important thing is that it points to the first port on the capture card)
  6. Commented out Run_HWS_ITMY and Run_HWS_ITMX aliases
  7. Added an alias: Run_HWS_H1ETMX='/opt/HWS/Run_HWS_Y/distrib/Run_HWS_Y' (this is not a mistake - the Run_HWS_Y code points to the first port on the capture card)

The libraries for the MATLAB Runtime Environment are now properly identified in the path. I confirmed that stream_image_EX runs and displays the image from the camera. See the first attached image.

Additionally on both:

  • I added the directory /home/controls/archived_images
  • I added the symbolic link to the latest version of the HWS code: /opt/HWS -> /opt/Hartmann_Sensor_SVN/release/HWS_v1.1.8/
  • I added the symbolic link to the framearchive directory: /home/controls/framearchive/ -> /data/ETM/

Note that when the HWS code stores data, it does so in the environment variable named FRAME_ARCHIVE_DIR which is defined by: export FRAME_ARCHIVE_DIR=/home/controls/framearchive/$HOSTNAME 

So, the files will be stored, ultimately in the following way:

HWS Data Directory
ITMX /data/ITM/h1hwsmsr/ITMX/
ITMY /data/ITM/h1hwsmsr/ITMY/
ETMX /data/ETM/h1hwsex/ETMX/
ETMY /data/ETM/h1hwsey/ETMY/
Images attached to this comment
H1 SUS
travis.sadecki@LIGO.ORG - posted 10:37, Thursday 12 March 2015 (17218)
SUS Driftmon updated

With all SUSes in their aligned states, I have updated the Driftmon threshold values.  This was mostly to address OM and RM values that have been ignored in the past.  I trended their alignments in Dataviewer and found them to be in their nominal state this morning.  The script to update these thresholds updates ALL SUSes, so the new values will reflect the latest in the constantly changing 'good' alignment of the IFO.

H1 SEI
hugh.radkins@LIGO.ORG - posted 10:32, Thursday 12 March 2015 (17217)
SEI SDFs Updated--almost all zero--HAM6 & BS GS13s Gains different than all the others

All SEI GS13s are now set in High Analog Gain without Whitening except HAM6 and BS (Stage2.)  This standard High Gain configuration is with both FM4 & 5 Off in the GS13 INF module, H1:ISI-HAM5_GS13INF_H1 for example.

For HAM6, because of the shutter hit to the ISI, the GS13s are run with Low Analog Gain without Whitening.  This configuration is with FM4 On and FM5 Off.

For BS, because of the hit to the ISI when the MICH acquires, we run the GS13s in the standard low Gain configuration of Analog Low Gain and Whitening.  This has both FM4 & 5 On.

These configurations are set in SDF.

H1 PSL (DetChar, PSL)
jason.oberling@LIGO.ORG - posted 10:29, Thursday 12 March 2015 (17216)
PSL DBB/ISS Scans

Here are the PSL DBB/ISS scans for this week.  No significant change from last week.

Non-image files attached to this report
H1 ISC
keita.kawabe@LIGO.ORG - posted 10:12, Thursday 12 March 2015 (17215)
ISCT6 enclosure handle is now lockable (Corey, Keita)

One of the ISCT6 enclosure handle could not be locked and it was guarded with an yellow caution tape.

Corey brought a new handle, but when we assessed the situation it turns out that the new one and the old one were identical, it was just that the old one was installed at a wrong angle. We removed the old one and re-installed after rotating 90 degrees, and voila, it can be locked when the door is closed and the handle becomes horizontal. Only  caveat is that the handle tip points up, not down, when the door is open.

We locked the doors and removed the yellow caution tape.

H1 PSL (DetChar, PSL)
edmond.merilh@LIGO.ORG - posted 09:00, Thursday 12 March 2015 (17213)
PSL Weekly Report

Here are the past 10 days trends:

Images attached to this report
H1 CDS
james.batch@LIGO.ORG - posted 08:29, Thursday 12 March 2015 - last comment - 09:36, Thursday 12 March 2015(17212)
Web MEDM screen shots and simlink captures is down
The computer that generates web-accessible MEDM screen shots and model simlink captures is not running well since about March 11, 17:59 PDT.

It will hopefully be repaired soon.
Comments related to this report
james.batch@LIGO.ORG - 09:36, Thursday 12 March 2015 (17214)
MEDM screen shots are working now, simlink capture will run at 12:00 PDT.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 01:05, Thursday 12 March 2015 - last comment - 14:45, Thursday 12 March 2015(17209)
Locking tonight

Today we have spent most of the day trying to lock. We have locked, but only after some diifictulties. 

Comments related to this report
stefan.ballmer@LIGO.ORG - 02:05, Thursday 12 March 2015 (17211)
As Sheila mentioned we had problems engaging the ASC in DRMI.

In particular, with today's initial alignment, for some reason, both POB_A and AS_C see pointing numbers between 0.2 and 0.46. When we engage the PRC1 loop (which uses POB_A), the control signal very quickly saturates the bottom stage of PRM, leading to a lock loss. The top mass relief loops are not fast enough this engagement. To a lesser extent the same is true for the SRC2 loop.

For now I implemented a Guardian section that copies the error signal into the offset (with opposite sign), engages all loops at nominal bandwidth, and starts a 5min slow offset ramp back to the nominal point.

We should do several things to mitigate this, probably in this order:
- 1) Find an initial alignment procedure that puts us closer to where we want to be, making the WFS turn-on transient less violent.
- 2) Commission a much higher bandwidth relief servo to the top mass.
- 2) Implement a saturable integrator in the ASC control filter bank - like we have in the tidal servo. This would make engaging the WFS trivial, and guarantee to avoid saturation.

stefan.ballmer@LIGO.ORG - 14:45, Thursday 12 March 2015 (17226)
I also added limiters to the PRC1_P, PRC1_Y, SRC2_P and SRC2_Y filter modules:

- PRC1: 1e4 cts limit. This corresponds to a drive of
   - 53168cts to PRM M3 coils
   -  8741cts to PR2 M3 coils
   - 24221cts to SRM M3 coils
   -  3457cts to SR2 M3 coils
   -   809cts to IM4 coils

- SCR2: 1e3cts limit. This corresponds to a drive of
   - 40368cts to SRM M3 coils
   -  5762cts to SM2 M3 coils

This should under all circumstances leave us enough range for length control on the M3 coils.


In addition I added limiters to all involved to top stages angular controls:
H1:SUS-BS_M1_LOCK_P_LIMIT = 500
H1:SUS-BS_M1_LOCK_Y_LIMIT = 500
H1:SUS-IM4_M1_LOCK_P_LIMIT = 1000
H1:SUS-IM4_M1_LOCK_Y_LIMIT = 1000
H1:SUS-PR2_M1_LOCK_P_LIMIT = 1000
H1:SUS-PR2_M1_LOCK_Y_LIMIT = 1000
H1:SUS-PR3_M1_LOCK_P_LIMIT = 500
H1:SUS-PR3_M1_LOCK_Y_LIMIT = 500
H1:SUS-PRM_M1_LOCK_P_LIMIT = 1000
H1:SUS-PRM_M1_LOCK_Y_LIMIT = 1000
H1:SUS-SR2_M1_LOCK_P_LIMIT = 1000
H1:SUS-SR2_M1_LOCK_Y_LIMIT = 1000
H1:SUS-SR3_M1_LOCK_P_LIMIT = 500
H1:SUS-SR3_M1_LOCK_Y_LIMIT = 500
H1:SUS-SRM_M1_LOCK_P_LIMIT = 1000
H1:SUS-SRM_M1_LOCK_Y_LIMIT = 1000

They are large enough that we shoul never run into them under normal operations, but small enough to avoid "astronomical" kicks on lock-loss. 
H1 ISC
alexan.staley@LIGO.ORG - posted 20:30, Wednesday 11 March 2015 - last comment - 11:11, Thursday 12 March 2015(17207)
PRELIMINARY NB Model Report

Chris, Alexa

Loop Gains

The first two attachments show the OLTFs of the various length DOFs. In these plots, the model is the blue trace and the red trace is measured data. The DARM TF agrees pretty well. The PRCL and SRCL loops appear to have a gain missing. The CARM and MICH model loops are not correct. 

Noise Budget Overview (***Rough Estimates***)

The fourth attachment depicts the noise budget produced by the model for the 8W lock on March 04, 2015 15:30 UTC. This roughly agrees with the conclusions Evan has made with his NB (LHO#17101). At high frequencies we are dominated by shot noise. At around 300 Hz we suspect intensity noise (or maybe beam jitter), as Gabriele noticed. From 30-100 Hz we are limited by DAC noise. And below 10 Hz we see some angular fluctuations. 

Noise Budget Details

Images attached to this report
Comments related to this report
christopher.wipf@LIGO.ORG - 01:41, Thursday 12 March 2015 (17210)

The modeled MICH loop gain is looking better now. There were some aggressive BSFM plant inversion filters that weren't being linearized accurately in Simulink. This was fixed by using numerical TFs for them. The shape is still off above 60 Hz, but that's probably due to the filter change from alog 17148.

I put in sign flips as needed to ensure an even number of them are present in each OLTF. There remains some 10 dB of mystery gain to be hunted for in the DRMI loops.

Images attached to this comment
gabriele.vajente@LIGO.ORG - 11:11, Thursday 12 March 2015 (17221)ISC, TCS

The larger coupling of intensity noise is something that was seen in Livingston as well (13767) and turned out ot be due to the ITM lenses (14091 and 14736). 

Displaying reports 67741-67760 of 84507.Go to page Start 3384 3385 3386 3387 3388 3389 3390 3391 3392 End