Screen snapshots before ETMy cleanup:

ETMy screen snapshots now:

To specify what Betsy means when she says "This cleared out Kiwamu's settings leftover from earlier measurements," we cleared out the EFF_CHARGE values in ESD linearization block, and changed the FORCE COEFFICIENT to match ETMX, at -124518.4 (see LHO aLOG 16798 and 16843). 

This force coefficient is -124518.4 [ct] (i.e. raw DAC counts, NOT LOCK drive counts), representative of the bias voltage of 9.5 [V] (referenced to [V] output from the DAC, NOT on the ESD), or an bias voltage on the ESD of 380 [V]. As the commissioning vanguard prefers DAC voltage, we've entered 9.5 "[V]" into the LOCK_INBIAS, and calibrated FM1 accordingly. This is exactly how EX is configured, as Betsy says.

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.

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 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$ 

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.

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:

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. 

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.

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).