VolkerQ, RickS
Today we went to Xend and aligned the AOM.
The transmitter module is #1x.
We adjusted the max RF power delivered to the AOM to be 1.3 W.
The total power transmitter through the AOM was 1.44 W; power in the diffracted beam 1.13 W -> 78% diffraction efficiency (about right).
We installed the Polarizing Beam Splitter Cube downstream of the AOM.
Installed NE01A-B filter in front of OFS PD. -> 9.0 V at max power.
Adjusted for Max modulation.
Power incident on the OFS PD 1.34 mW.
Power incicent on the Tx PD 6.75 mW.
s-pol light reflected from PBSC 10-15 mW
Closed OFS loop with offset at 4.5 V.
Adjusted bias on AOM driver to minimize AOM drive with loop locked.
HAM1/HAM2 annulus system still needs pump cart assistance for a few more days
Scott L. Ed P. Chris S. The cleaning crew was able to clean 49 meters from X-1-5 double doors towards the mid station. Beam tube pressures continually monitored by control room operator during cleaning operations.
Morning meeting:
Hugh working on isolation loops
SUS acceptance TFs
3IFO moving parts from LVEA to midstations
Time in PST
08:19 Richard and Fil to both end stations installing shutters
08:48 JoeD to LVEA checking fire extinguishers
08:51 Elli and Nutsinee to EY working on HWS
09:15 Mitchell to West Bay LVEA
09:15 Jodi/Gary to West Bay
09:24 Corey and Keita to ISCT1 for optics check, Corey to squeezer bay thereafter
09:30 Betsy to West Bay
09:32 Richard and Fil done at EX, Richard to Air Handler room EX and EY
09:53 Peter and Ed to H2 PSL enclosure
10:22 Mitch out
10:30 Jodi/Gary out
10:33 Mitch to West Bay
10:39 Richard to EY
10:40 Fil and Manny to MY
11:21 Richard done at EY
11:42 Elli and Nutsinee done at EY, going to EX
12:28 Peter out
12:42 Karen to Mid Y
12:42 Cris to Mid X
13:38 Karen out
13:45 Elli and Nutsinee back from EY
14:08 Fil to EX for shutter modification
14:08 Peter and Ed to H2 PSL enclosure
14:17 Elli and Nutsinee to EX
14:39 Fil back from EX
14:44 Rick to EX for PCal work
15:17 Daniel done at EY
15:56 Ed and Peter out
Due to all of the latest commissioning of ETMY, the SDF had accumulated 40+ differences. With Jeff's help we remedied numerous line items via making the ETMy ESD banks look like the ETMx ones. This cleared out Kiwamu's settings leftover from earlier measurements. I've also moved the ESD calibration filters from the 4 ETMY L3 ESD OUTPUT banks to the L3 LOCKING BIAS bank to bring it in line with the ETMx settings. I've edited the burt ETMy safe.snap to capture some of the other commissioning work. THere are now only 20 SDF diffs which I will continue to track down.
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.
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.
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.
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.
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$
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.
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.
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.
The ETM HWS computers currently have outdated .bashrc files that specify aliases and paths. I'm updating these.
Some specifics:
H1HWSEY
The .bashrc file is the same as that on H1HWSMSR with the following modifications:
.bashrc
to .bashrc.old.20150312
OPTIC_0
to ETMY_HWS
OPTIC_1=ITMY_HWS
environment variablePREFIX1=$IFO:TCS-$OPTIC1
environment variablestream_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 cardRun_HWS_ITMY
and Run_HWS_ITMX
aliasesRun_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:
.bashrc
to .bashrc.old.20150312
OPTIC_0
to ETMX_HWS
OPTIC_1=ITMY_HWS
environment variablePREFIX1=$IFO:TCS-$OPTIC1
environment variablestream_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)Run_HWS_ITMY
and Run_HWS_ITMX
aliasesRun_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:
/home/controls/archived_images
/opt/HWS -> /opt/Hartmann_Sensor_SVN/release/HWS_v1.1.8/
/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/ |
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.
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.
Here are the PSL DBB/ISS scans for this week. No significant change from last week.
Today we have spent most of the day trying to lock. We have locked, but only after some diifictulties.
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.
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.
Chris, Alexa
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.
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.
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.
Screen snapshots before ETMy cleanup:
ETMy screen snapshots now:
Betsy, Jeff,
Thanks for cleaning up the mess and I am sorry that I did not alog the details. Regarding this configuration, I actually liked the ETMY configuration than ETMX because (1) the effective charge can be calibrated in Volts at the electrodes and (2) the bias voltage can be specified on the medm screen as the actual voltage at the electrode e.g. +380 V. We should decide which calibration convention we want to use. I will talk to you guys about this once I come back.