J. Kissel

I've installed IPC broadcasters into the h1isiham4 and h1isiham5 front-end models in order to broadcast the HAM4 & HAM5 ST1 GS13s. Subsequently, I've installed IPC receivers into the h1sussrm, h1sussr2, and h1sussr3 models. With this installation, it completes the signal chain such that each SUS can now compute their own suspension point motion. All that computational infrastructure had already been in place (calibration filters, transformation matrices, etc), but they were just not receiving any input signals. I attach a pdf demonstrating the power of this fully operational battle station for SR3. The pictures attached show trends of displacement SRM, SR2, and SR3 indicating that their positions have been restored to what they were before I started.

Detailed, roughly chronological notes:
---------------------------------------------------
Alignment Offsets before getting started:
        P [urad]    Y [urad]
SRM   -934.049    430.123
SR2   2963.7     2728.0
SR3    430.3      142.6

- made and saved mods to h1isiham4.mdl, h1isiham5.mdl, h1sussrm.mdl, h1sussr2.mdl, h1sussr3.mdl by adding 6 cdsIPCx_PCIE (i.e. corner station dolphin network IPCs) sender parts to each HAM ISI top-level model, with the following "channel names" H1:ISI-HAM[4,5]_2_SUS_GS13_[X,Y,RZ,Z,RX,RY], and created a corresponding 6 cdsIPCx_PCIE receiver parts in the SUS models.
- paused HAM4 and HAM5 SEI manager guardians
- changed ISI guardians to "EXEC", brought ISIs to "READY", turned off master switch (and left HEPIs alone)
- brought SUS guradians to "SAFE"
- captured new safe.snaps for SUS (forgot to do ISI, but J. Warner / H. Radkins are confident that their safe.snaps are up-to-date. I've confirmed that all local to cartesian matrices still obey the conventions defined in T1000388)
- logged onto h1build as controls, used cdsCode alias to get to build directory, /opt/rtcds/lho/h1/release/
- compiled models, e.g. make h1isiham4, making sure to compile the sender models first (i.e. the HAM ISI models)
- installed models, e.g. make install-h1isiham4, again making sure to install sender models first
- logged on to each model's front end, i.e. for the ISIs h1isih45, and for the SUSs, h1sush34 and h1sush56
- restarted models, e.g. starth1isiham4, again restarting sender models (the ISIs) first. Out of habit, I made sure to have the GDS_TP screens open and hit the BURT button as soon as it became available. I don't thin it's necessary, but for big models with tons of EPICs channels, I can click the button faster than the BURT restore can install the right value.
- Brought SUS back to "ALIGNED", confirmed that all SUS had the same alignments restored as mentioned above.
- Brought ISIs back up to "HIGH_ISOLATED,"
- changed ISI back to managed, SEI manager guardian back to exec
- DAQ restart, because I found nonsense (and its needed when one adds new *receiver* parts)
- Went through each model's GPD_TP screen and hit "diag reset" to clear initial, start-up transient, errors from both the timing and IPC- Started trending alignments of SUS to confirm they've gone back to the same place.
- SR3 optical lever damping came up with both stages (M2 and M3) on -- maybe turning this on is hard coded in an ISC guardian somewhere? 
- Turned the SR3 M3 optical lever damping OFF, now both filter modules' SWSTATs report what they were before I got started.
- Now SR3 optical lever reports the P and Y position has been restored to within 1 [urad].
- Found SRM in the same place (according to M3_WIT_P and Y OSEM sensor channels) with larger noise on trend, found with getting constantly pulsed by ISC L from. 
- Changed ISC_DRMI guard state to DOWN (it had been in INIT, and its background RED indicating an error; probably because it had lots communication with one of its subordinates, i.e. SRM). Noise in trend went away. Now restored to with 0.5 [urad] in P and T.
- Not sure about exponential shape of SR2's M3_WIT_P and Y signals, but they appear to be asymptotic toward the previous original position. Spot on AS camera appears centered, and as of this entry, Dan has been able to re-lock the OMC using an IX single-bounce.
- Committed modified top-level isi and sus models and safe.snaps to userapps repo.

This completes work permit Work Permit #4944. Note that this installation is simply completing what had been installed for the rest of the SUS in H1 back in October 2012 - Jan 2013, see e.g. LHO aLOG 4553. The theory behind the matrix transforms (that were already installed) can be found in T1100617.

I don't want to jinx anything, but I have misaligned OM3 to steer the beam away from the OMC and the DCPDs, in case of big power spikes at the AS port.

I found that moving the OMC SUS itself was useless for moving the beam away from the cavity axis (vice-versa, really).  Moving the PIT and YAW sliders rail to rail only moved the beam on the OMC QPDs by a small amount.  (It was clear the sliders were doing something, but it was puny compared to the tip-tilt actuation.)  FYI the OMC SUS pitch slider rails the output to the DAC at +/-6000, for the T2 and T3 actuators.  The yaw slider doesn't rail the DAC output until +/-12000 (LF and RT actuators).  I was expecting the OMC SUS to have a little more oomf than this, we should check that everything is working correctly.

So, I've moved OM3 to get the beam away from the OMC.  Current slider settings are PIT = 1800, YAW = -1800.  The sign was determined by looking for the best extinction on the OMC QPDs and DCPDs with the DRMI flashing.  The magnitude of the slider value puts the DAC just at the saturation point.

The good slider values, which will restore the alignment into the OMC, are:

PIT = -437

YAW = 657

Note that this only protects the OMC diodes from bright flashes, not the AS WFS.  Those guys need the toast to work before they'll be safe.

Intesnity noise was bad in transmission of the IMC, so I added some offsets to the angular controls: -20 counts to DOF_1_P and -9 counts to DOF_2_Y. Intensity noise improved a lot, see attached plot (blue/red after, green/brown before)

This morning we disconnected all DC power to PEM electronics (SEIS, TILT, MAG, MIC ect) and connected them to the dedicated PEM power supplies. This should start cleaning up some of the clutter in the VEA, example power supplies sitting on the floor used for temporary power. Everything should be up and running, but let me know if we missed something.

[Sudarshan, Gabriele]

To understand why intensity noise was worse than usual, we had a look again at the beam dumps we installed yesterday on the two beam coming out into IOT2R. 

After yesterday's realignment of the main beam, the two dumps were no more in a good position. To be more precise: the two beams coming into the enclosure are very close to the edge of the periscope upper mirror; one of the beams is hitting the bottom mirror in a reasonable position but was partially missing the beam dump; the other beam was hitting the edge of the mirror and the mount. Therefore, we moved the first beam dump to a better position, and we dumped the second beam before it hits the periscope bottom mirror. See attached picture

This improved the intensity noise, but we can still see a bit of 18 Hz peak. 

Intensity noise was very high this morning, see the red trace in the first attached plot. It started to be like that yesterday night, during some of the locking tests. After some investigations, it turned out to be due to the LSC correction sent to MC2 and generated by the ALS. After switching it off, intensity noise returned to reasonable values, even though a bit larger than usual, inicating a not optimal alignment of the IMC.

Another pecualir thing is that yesterday night, while IM4 ws moved, the power on IM4_TRANS changed as well. This is a bit unexpected...

Looked like commissioners were still working on the alignments so I held off on doing similar to WHAM3.  So, I went to the ITMY which also needed some matrices corrections.  These corrections required new controllers so I just went with Hugo's standard controllers and some mods to those, see 15112.

I brought down the HEPI at ~0805pst, the ISI watchdogs tripped very soon after.  About 0813 I loaded the new matrices and attempted to restart the HEPI after adjusting the X dof Target Location.  The RZ loaction did not change as the matrix errors I'm correcting are amplitudes in X & Y and the output matrix which was all 1s.  Did you notice I forgot to mention loading the new controllers (required with changed matrices?)  Well I did forget them, so then I prepared and loaded the new controllers and tried again.  Okay, not so good...the vertical dofs are tripping quickly when the boosts turn on.  Well, if you remember from my yesterday's alog, I elected to leave the vertical controllers at 5hz UGF.  So I lowered them to 2hz like all the horizontals (I hadn't actually tried the horizontals yet, but I later did and they were fine.)  Still the verticals blow up quickly when the boost is engaged.  So, I continued and reduced the zero of the boost from 1.0 to 0.7hz as I did with the horizontal dofs.  But, still no luck so I lowered them to 0.5hz and again no good.  Alright, I tried the horizontals and they worked, I did the verticals manually and they are fine without the boosts.

Next I set up to do an open loop, this would reveal if my controller's matrices did not match my installed matrices.  Well, the boosts would not engage at all for Z RY or VP!  We attempted all sorts of things like resaving the file from foton, confirming the turn on method, comparing the boosts, putting the boost in another module (where it did turn on.)  Finally, restarted the model, and HEPI isolated first attempt (3 hours later!)

So, the new matrices and new controllers work--why did these filter modules stop engaging properly and sending some wacko spike into the output--they would not have done any harm if they actually weren't doing anything?  I thought about reverting the controllers back to where I started to see if at first it was actually my boosts but the the shape changes were actually quite minor: the gain peaking dropped from less than 3 to less than 2, and phase margin went from ~30 to ~50 degrees.  Too little time so I didn't change them back.  So unless my controllers were very bad to start and the repeated loading of fotons and tripping the watchdogs did something, the first attempt with the non-updated controllers must have done something to the filter module/model, or, it was a problem waiting to happen.

I noticed that the Guardian was restoring the RX & RY Target Location.  I'm confused with that.  I thought we were only restoring RZ everywhere, with Pitch at the ends, and X on ITMY (initial alignment.)  I'll research the history and maybe I'll learn something but again, I did not think we were restoring these.  It might make sense to do so as these are the tilting of the platforms but that is another issue.

I'll put an updated image of the controllers in shortly.

Updated safe.snap and latest foton file filed in the svn.

[Sudarshan, Gabriele]

• Changed the ISS second loop medm screen, to include the correct functionalities to contrl the second loop
• Modified the ISS model to change the channels written to frames:
  • The first loop signals have changed: PDA_OUT and PDB_OUT are no more written. Instead we write PDA_REL_OUT and PDB_REL_OUT which are calibrated in units of RIN. They are both written to science frames, at 16kHz
  • Added both second loop signals SECONDLOOP_SUM14_REL_OUT and SECONDLOOP_SUM58_REL_OUT to science frames (only SUM14 was previously written). Reduced the sampling rate to 16kHz
  • Added the second loop QPD signals to the commissioning frames: SECONDLOOP_QPD_PIT_OUT, SECONDLOOP_QPD_YAW_OUT and SECONDLOOP_QPD_SUM_OUT, al at 2kHz

Model has been recompiled and restarted.

For Ubuntu workstations, a new version of TDS tools have been installed.  Following a complaint that ezsfft was failing, it was determined that the tool needed to be recompiled since libraries ezsfft depends on have been updated.

Note that the documentation states that ezsfft is obsolete, tdsdmd should be used instead.

The ezsfft no longer core dumps, but it doesn't seem to work, either.  The tdsdmd tool does appear to work, so it should be used instead,

The ezlockin script has been changed to use tdsdmd and tdssine instead of ezsfft and ezsine.  I have no idea if the script still works, there's no test case for regression testing.

This will affect all users -

The user environment setup scripts have been changed to include some common aliases that may be useful to users. 

alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

alias target="cd /opt/rtcds/lho/h1/target/"
alias t="cd /opt/rtcds/lho/h1/target"
alias chans="cd /opt/rtcds/lho/h1/chans"
alias h1="cd /opt/rtcds/lho/h1"
alias userapps="cd /opt/rtcds/userapps/release"

alias latest="ls -alt|head"

alias scripts='cd /ligo/lho/scripts'
alias data='cd /ligo/lho/h1/data'
alias medmdir='cd /opt/rtcds/lho/h1/medm'
(there's more than these...)

If an individual user wishes to redefine one of these aliases, they can do so by editing the ".bashrc" file in their home directory to include a different alias command AFTER the line "source /ligo/cdscfg/stdsetup.sh"

A complete list of aliases can be found by entering the "alias" command with no argument (in a terminal window, of course).

I have also changed the setup scripts to recognize a different operating system, but this should not affect any users and is in place for testing candidates for the next control room computer OS.

I've run the latest updates on all the CDS workstations and rebooted them as part of Tues maintenance.  (opsws6,9,10 are pending reboots as they were in use this morning.)

Add 125ml water to Diode room crystal chiller

The attached plot shows a trend of 60 days of beam spot position on the IMC WFS. Excluding two manual re-centerings of the beam (I'm sure about the last one, since I did it) the beam is not moving significantly on the WFS. The peak to peak motion is at most 0.1-0.2 in units of QPD normalized signal, which corresponds to 0.06-0.12 fraction of beam radius.

The position looks quite stable over long periods.

(Sheila, Evan, Keita, Nic, Kiwamu, Alexa)

We locked the IR to the x-arm and adjusted PR3 until we achieved the good IM4 alignment specificed in alog 15109. We adusted the HAM3 picometers to restore the ALS green trans beam on ISCT1; I used the camera reference position that we had previously found (alog 15072) and ensured a high build up in TRX. We then aligned MICH on the dark fringe and PRM using PRX lock. Not surprisingly, we had to move PRM a lot.  SRM was also aligned, with SR2 and SR3 in the old configuration. Attached is a screen shot with the current alignment values. The POP sled was aligned as noted in Keita's alog 15116.

We were able to lock PRMI on the sideband, and acheived 260 cnts build up. Our best build up had been between 260-399 cnts as seen by a trend Keita had taken over the span of 3 weeks. We feel okay about our current build up. 

Sheila and Evan marked a new IM4 trans beam on the wall in the LVEA. It seemed the beam hadn't moved all that much from the old position (from June); maybe a few millimeters.

We adjusted the ALS alignment on ISCT1; we got 0 dBm for COMM beatnote, and 6 dBm for DIFF beanote.

ALS DIFF locked right away. The UGF was 7 Hz, with 70 deg phase margin. The in loop RMS was 0.2e-3 um/srtHz at 0.1Hz. This was with feedback to ETMX only.  We then tried feeding back to both ETMX and ETMY L1 stage with Jeff's new EY L1 L2P filters engaged (FM6, FM7); however this did not work. The L2P filters output a huge value 1e+20 and we saturated the DAC immediatly. FM7 has a step response of 10^18 ! Also, are we supposed to leave Arnuads invP2P filter engaged? We must have rung up a mode around 10 Hz. Nic and Kwamu fixed this (see their alog 15118).

We locked DRMI 1f with the ASC wfs engaged. POPAIR18 measured 343cnts, and ASAIR90 measured 5731. It appeared to be the best DRMI "moment of [Sheila's] life." DRM1 1f lock time Nov 18, 2014 6:07 UTC. We transitioned to 3f flawlessly at ~ Nov 18, 2014 6:12 UTC. We lost lock at Nov 18, 2014 6:14 UTC.

Then we tried locking DRMI with the arms 500 Hz IR off resonance. At first, the DRMI alignment did not look as good; when we engaged the wfs the build up increased dramatically but we would lose lock when the build up got high. We deduced that the gain of the loops had to decrease with the precense of the arms. We reduced MICH gain from 5 to 4 to obtain a 15 Hz UGF. PRCL we reduced from 22 to 11. At some point the alignment looked good and the lock was stable for a bit, but we lost lock trying to measure the SRCL loop gain.  We got tired...

A second round of testing on the all-metal 3IFO QUAD unit Q7 is attached.  After we saw a few cross coupling terms and struggled with coherence in the prior measurement set, we made a few adjustments to the QUAD mechanics.  However, readjusting the lacing cabling and retuning the sensor mounting tablecloth seemed to not help much.  There is still L and R bleeding into P on the reaction chain.  We were able to improve the coherence by building a fort around the test stand however.  The main chain looks to be in pretty good shape though.

The first attachement below is of Q7 with damping on and off.