QUAD Master model change WP5899

Kiwamu, Betsy, Dave:

Kiwamu made a changed to QUAD_MASTER. All four quad models were rebuilt and restarted (h1susitm[x,y], h1susetm[x,y]

CAL model changes WP5894

Kiwamu, Dave:

All three calibration models were changed, built and restarted (h1calcs, h1calex, h1caley).

Vacuum Controls change for Mech Room IP1,3,8 WP5889

Patrick, Dave:

Beckhoff code for h0vacmr control of IP[1,3,8] changed. New EPICS database, autoBurt.req and DAQ ini files generated. This entails a channel name change, I have changed the running minute trend files. Still need to cover archived files.

Update NDS2 client code. WP5886

Jim B:

nds2 client code updated, please see earlier alog.

DMT Broadcaster channel change

Dave:

Changed the duotone channels in H0BROADCAST0.ini to reflect LLO names (use IN1 rather than OUT channels in filtermodule). This change went into effect when the DAQ was restarted.

New SUS PI models

Tega, Ross, Dave

New h1susitmpi, h1susetmxpi and h1susetmypi models were installed.

ADC card installed in h1oaf0 IO Chassis for NGN model

Dave, Jim:

We installed a 6th ADC card into h1oaf0's IO Chassis. This is a long-term-temporary card (will be removed post O2) which will provide the h1ngn model with 30 sensor channels. Powering down h1oaf0 meant that the following models were restarted: h1ngn, h1pemcs, h1oaf, h1tcscs, h1odcmaster, h1calcs.

The h1iopoaf0 model was edited to add the 6th ADC.

The h1ngn model was modified to use the new ADC.

In the IO Chassis we decided to locate the ADC between the DAC and DC power supply rather than group it with the other 5 ADC cards, This minimized the models which needed to be modifed to just 2.

Check 18bit DAC card in h1susb123 which failed its autocal

Dave, Jim:

Following the reboot of h1susb123, h1iopsusb123 reported that the first 18bit DAC card had failed its autocal. Today we restarted h1iopsusb123 three times, and each time the first DAC is reported to have failed autocal.

h1asc filter file loaded

Dave:

h1asc was showing a modified filter file. Investigation shows another repeated-filters problem (DHARD this time). I performed a full load.

J. Oberling, T. Schaffer

The PR3 and SR3 oplevs have been moved from the stand-alone DC power supplies on loan from the EE shop to a power supply installed in the LVEA CER.  Both lasers came back up without issue but will need a few hours to thermally stabilize again, as we had to open the coolers to turn them off and on.  This completes work permit #5895.

J. Oberling, T. Schaffer

We re-centered all active H1 optical levers (ITMx/y, ETMx, PR3, SR3, BS, HAM2) except for ETMy (which was done by Ed and I last week).  This completes work permit #5795.

WP 5894, 5899

related alogs: LLO log 26126, LHO log 27336

In order to update the online calibration model and some related infrastructure, I have recompiled, rebuilt and restarted the following front end models this morning.

• h1susitmx
• h1susitmy
• h1susetmx
• h1susetmy
• h1calcs
• h1calex
• h1caley

All of them are burt-restored to 7:10 AM this morning. The changes I made on h1cal* are already summarized in alog 27336. As for the change on h1sus*, it is only quad suspensions' master library, QUAD_MASTER.mdl, that was modified; I have replaced a calibration oscillaltor on the L3 stage with a new fixed phase oscillator.

Summary:
A new, better inverse actuation filter has been made for the x-arm Pcal, but it has not yet replaced the old filter. This was constructed using knowledge of the Pcal OFS-AOM gain coefficient (see LHO alog 27155), the suspension model, and models of the digital/analog AI components. The AI components had to be approximated since the injection model runs at 16k. Also, the actuation function delays couldn't be included in the filter, so all waveforms using the attached actuation function or using the inverse actuation filter should assume a timing advance of 225 us. Another aLOG will be posted once the new filter is in place.

When including this timing shift, the new actuation function/inverse actuation filter match the real values to within 5% in magnitude and 5 degrees in phase up to 2 kHz. Above 2 kHz, the deviations from the true actuation function are significant due to the approximations chosen for the analog/digital AI filters and a rolloff filter being applied.


Details:
The continuous wave hardware injections would like to use the Pcal actuation function instead of an inverse actuation filter for O2. Meanwhile, the transient injections will continue to use an inverse actuation filter. The actuation function is nominally modeled as follows:
PCALX_EXC --> IOP-15 --> 16k-64k AI(D) --> DAC (V/ct) --> ZOH 7.5 --> AI(A) --> OFS --> AOM --> N/W --> Norm. SUS --> 1/f^2 --> DC SUS (m/N) --> 1/L (h/m) --> strain
Legend:
IOP-15 = 15 us delay from the IOP
16k-64k AI(D) = digital anti-imaging filter (using the new RCGv3.0.2 filter, see LHO alog 27173)
DAC = digital-to-analog converter
ZOH 7.5 = zero-order-hold, 7.5 us delay
AI(A) = analog anti-imaging filter
OFS = optical follower servo
AOM = acousto-optic modulator
N/W = power-to-force coefficient = 2*cos(theta)/c (Note that this does not include rotation-induced errors, with 1-sigma uncertainty of 0.4%, see LIGO-L1600018)
Norm. SUS = normalized suspension transfer function model which has been multiplied by zpk filter with 2 zeros at 1 Hz
1/f^2 = zpk filter with 2 poles at 1 Hz
DC SUS (m/N) = suspension force-to-length "DC" coefficient
1/L (h/m) = inverse of the mean arm length

The OFS-AOM system has a wide-bandwidth (UGF ~50 kHz) and a gain of 0.0923 W/V for H1 ETMX Pcal (this is watts impinging on the ETM per volt of drive sent to the OFS, LHO alog 27155). The SUS file used is in the SUS repository:
/ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/quadmodelproduction-rev7652_ssmake4pv2eMB5f_fiber-rev3601_h1etmx-rev7641_released-2015-08-07.mat
However, in order to construct an *inverse* actuation filter, some of these components cannot be included because a delay would turn into an advance (breaking causality). In addition, the model runs at 16k, so the inverse AI digital filter must be approximated. The high frequency components of the inverse actuation filter need to be rolled off using additional filtering. Thus, the *inverse* actuation filter model is constructed as follows:
strain --> L (m/h) --> 1/DC SUS (N/m) --> f^2 --> 1/Norm. SUS --> W/N --> 1/[OFS * AOM] --> 1/AI(A) approx --> DAC (ct/V) --> 1/AI(D) approx --> Ellip. rolloff --> 3 7kHz poles --> PCALX_EXC
Here, there are two approximations made: the analog/digital AI filters are modeled to roughly match the magnitude (see comparisons in figures 1 and 2), as well as removing the IOP and ZOH delays. Note that two rolloff filters are used to suppress high-frequency content, a 3rd-order elliptic filter and 3 7kHz poles. The phase error in the approximations is accounted for with the expectation that waveforms using this inverse actuation filter will need a timing advance of 225 us.

The analog AI approximation is one zero at 5160 Hz and 2 poles at 7100 Hz (e.g., [5160:7100,7100])--see figure 1. The digital AI approximation is 4 zeros at 7000 Hz, and 2 complex pole pairs (e.g., [7k,7k,7k,7k:pair(4300,30),pair(7000,50)])--see figure 2. The elliptic rolloff filter is given by the Matlab function myellip_z2(6900,3,.4,10,10)--6900 Hz knee frequency, 3rd-order, 0.4 dB ripple, 10 dB stopband, and zQ of 10.

The final Pcal actuation function and comparison to the real value is shown in figure 3 with the delay included, and figure 4 is the inverse actuation function with the advance included. Figure 5 shows the impulse response of the inverse actuation filter (no delay included).

The attached H1PCALXactuation.dat file is the actuation function sampled every 0.125 Hz.

Code that produced these results is located in
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/DARMmodel/Scripts/pcal_actuation_function_quack.m

Next steps: replace the old inverse actuation filter, move the inverse actuation filters from the PINJ_HARDWARE bank into the PINJ_TRANSIENT bank so that the CW injections (which will use the Pcal actuation function manually) will not pass through the inverse actuation filter.

Summary:

I analyzed the HWSY measurements from a ~28 hour period around the 18th of May during a long lock segment and lock/unlocked transitions. There are systematic shifts in the measured defocus which can only be coming from some alignment coupling. There is evidence that the delivered CO2 laser power may be more than the CO2Y power meter suggests.

Our attempts to maintain the total lens using the CO2 laser power during locked/unlocked transitions are currently ineffective because the CO2-induced thermal lens response is not calibrated correctly.

Analysis:

There was as a period of a 7 hour lock last week. I extracted the RAW HWS images corresponding to this period (t0 = 1147500000 to t0 + 1E5s) from the directory: controls@h1hwsmsr:~/framearchive/h1hwsmsr/ITMY/1147500000/. These were centroided offline to determine the measured defocus (a proxy for H1:TCS-ITMY_HWS_PROBE_SPHERICAL_POWER which should be running online). The offline calibration included:

• dividing by a factor of 2x to convert from double-pass to single-pass
• dividing the raw spherical power measurement by the nominal magnification (7.5) squared to convert to the spherical power at the ITM.
• The zero value was reset such that defocus = 0 around t = 70 minutes

I also extracted the SIM estimates of defocus (defocii?) from the self-heating (H1:TCS-SIM_ITMY_SUB_DEFOCUS_SELF_OUTPUT) and CO2 laser power (H1:TCS-SIM_ITMY_SUB_DEFOCUS_SELF_OUTPUT). All three of these time series are plotted below.

And a zoomed version of the first 600 minutes is shown below:

A few points to note:

• There are unexplained (and unphysical) jumps in spherical power after the system loses lock around 550 minutes. My working hypothesis is that alignment changes during attempts to reaquire lock are somehow coupling to this HWS measurement.
• There are transient glitches in the spherical power every so often. I don't know the cause of these
• The measured drop in spherical power from the HWS is much larger than the expected drop in the SIMulation (from lowering the CO2 laser power)

If I double the expected CO2 response and create a new channel that is the sum of the double CO2 lens and the SELF heating (and reset the zero value of this channel), I get a result that is much closer to the measured lens in the HWS.

Additionally:

As you can see in the images attached to aLOG 27047,  that CO2Y table is capable of delivering a maximum of ~2.3W off the table (when the CO2Y laser is running at 57W). The CO2X table is capable of delivering a maximum of ~5.5W off the table (when the CO2X laser is running at 59W). There is no functional difference in the design of the two tables (expect that Y is a mirror image of X). The possibilities for this difference are:

• Optical (we may be clipping the beam somewhere on the CO2Y table)
• Electrical (We're somehow losing signal between the H1:TCS-ITMX_CO2_LSRPWR_MTR power meter and the ADC input electronics).
• Software (we have an unexpected calibration difference between the tables). Scanning L1TCSCS.txt and looking at the gain settings in the filter banks for the X and Y power meters and comparing the EPICS GAIN channel for these filter banks rules out this possibility (barring some hardcoded difference in the SIMULINK model).

And: the maximum power that could be delivered from this table on 26-Jan-2016 was around 5.5W.

Therefore: Given all this information, I suspect that the CO2 laser is somehow reading back less power than it is delivering (or, if you like, delivering more power than we're expecting).

TO DO:

• Measure the CO2 laser power directly on the table with an independent power meter
• Measure the CO2 central heating thermal lens with the HWS with the IFO unlocked and no other changes to the IFO alignment
• Determine why we see systematic changes in the HWSY defocus apparently with IFO alignment changes.

WP #5886

The NDS2 client software has been updated to nds2-client-0.12.1 for Ubuntu 12.04 and Ubuntu 14.04 workstations in the control room.  Changes since the previous 0.11.6 version include:

* Added a set_parameter call to allow default settings on the connection to be changed
* No longer using sqlite database for nds2
* Can set epochs [start,stop) ranges to reduce channel list size on nds2 queries (also constrains data)
* Added a version string to the SWIG interface
* The system now defaults to it being an error condition when is on tape.
   - this can be overridden in the environment or through a call to set_parameter(‘ALLOW_DATA_ON_TAPE’, 1)
* Added a new swig backend which is released as a seperate interface for testing.
  Currently exposed through the ‘nds’ module/namespace.  It is expected that this backend
  will become the default in the near future.
  - includes the ability to count the number of channels available
  - includes full gap handling (for both fetch and iterate)
  - includes the ablilty to get detailed channel availability information
* Added Octave bindings for the C++ interface

Note that the user environment setup scripts set NDS2_CLIENT_ALLOW_DATA_ON_TAPE=1 to allow data searches to request data from tape.  If you don't want your search to proceed if data is on tape, you'll have to set the environment variable to 0 before the query, and be prepared to handle the error condition.

Sheila, Haocun

We switched back to 36MHz demodulation first (with Gain=33), but there was still an offset for Yaw between the REFL loops and POP loops.

Then we chose to use 45MHz demod and adjusted the phases to put the SRM into Q phase (figures attached). We used -0.1 for Pitch (POP X_Q) and +0.1 for Yaw (POP X_I) in the input matrix, taking the measurements for gain and increased the power. It remained stable till 38W.

For the past week or two, we've been annoyed by "ISS first loop is maybe off?" message in ISC_LOCK guardian, preventing guardian to go to DC. The guardian checks PSL-ISS_LOOP_STATE_OUTPUT, and if it's 32700 it passes, otherwise it wouldn't.

However, when Sheila looked back, PSL-ISS_LOOP_STATE_OUTPUT was 32000 (NOT 32700) in most of O1.

It turns out that LOOP_STATE can only become 32700 when ISS auto locker is OFF: LOOP_STATE is 32700 (1st loop ON with integrator, manual), -32700 (1st loop ON, integrator OFF, manual) or 0 (1st loop OFF, manual). The numbers are hard coded in MEDM screen buttons.

When the ISS auto locker is ON, LOOP_STATE is dictated by the state machine C code in the front end and it only outputs 32000 (1st loop ON with integrator), -32000 (1st loop ON, transition to integrator ON) or 0 (1st loop OFF, transition to 1st loop ON).

Somebody should have changed the guardian recently when we had a problem engaging ISS auto locker just to get by. But the reality is that LOOP_STATE output is sent to DAC to control the analog board, and there's no meaningful difference between 32000 and 32700 as far as analog switching is concerned.

Since ISS auto locker is working OK with larger diffraction, we changed it so it fails when PSL-ISS_LOOP_STATE_OUTPUT is smaller than 32000. This way, even when ISS auto locker has a problem, operators can change ISS to manual mode and the guardian will still pass.

1/2 open LLCV bypass valve, and the exhaust bypass valve fully open.
Flow was noted after 95 seconds, closed LLCV valve, and 3 minutes later the exhaust bypass valve was closed.

Prior to upgrading an end station sus front end system to Gentoo linux kernel 3.0.8 I have trended the ETMX and ETMY SUS statewords looking for Timing and/or ADC errors since Jan 1st. The attached plot shows the instances of these glitches on h1susetmx (red circles) and susetmy (blue circles). Since sometimes a SUS glitch is accompanied with an IOP glitch, I have also shown h1iopsusex (red cross) and h1iopsusey (blue cross).

These glitches are normally latched on. To enable trending, for the whole time a cron job running on h1fescript0 has been clearing the stateword bits once a minute.

As can be seen, the rate of errors is not constant. At the tail end of O1 EY was glitching more than EX. During Feb and early Mar both systems glitched frequently. Since then there have been quiet and glitchy periods, lasting from several days to a week or so.

The plots show that sometimes an IOP can glitch without the sus model, in most cases it is the other way around or they both glitch.

Darkhan, Kiwamu,

We have updated the h1calcs, h1calex and h1caley models to make them up-to-date by following Joe's instruction (alog 26126). We will install the models tomorrow during the maintenance period.

In addition to the implementation, we have edited CAL_LINE_MONITOR_MASTER.mdl to improve a complex division where we used to calculate the phase by a simple subtraction between two phase values. This part is now replaced with a complex division and then is converted to phase and magnitude in order to avoid a 360 deg phase ambiguity. We also had an issue with the compiler where the choice of the name for instances of the MAGNITUDE_PHASE library caused errors in a somewhat unintelligible manner. Eventually we came up with a set of names that do not make the compiler crazy. Dave is now taking a look at the code to see if there is a particular cause for this issue.

In summary, the followings are the ones we modified today.

• cal/h1/models/h1calcs.mdl
• cal/h1/models/h1calex.mdl
• cal/h1/models/h1caley.mdl
• cal/common/models/CAL_LINE_MONITOR_MASTER.mdl

Needed to power cycle the camera in the BRS Box on the floor as well as restarting the program code.  TJ was able to test his diagnostic code and all is running well now.

• The instability occurs without a DARM offset (as expected).
  • confirmed once with the interferometer locked on RF at 25-30 W
• At 25 W or a seemingly stable but high circulating power, aligning the pointing of the arms (aka soft degees of freedom) in situ lead to the instability.
  • Or perhaps the in situ alignment took a long enough time to run into the instability. Not clear.
• The DRMI 2 omega RF signals seem to show a silimiar linear dependency to arms' dP/d(theta)
  • could be a hint for localizing the position dependent loss?

An automated measurement is setup for the ITMY ring heaters. A script will turn on the ITMY ring heater for 4 hours with a 1 W power on each segment. Once the measurement is done it is going to automatically shut the ring heaters off.

The measurement will start at 22:00 PST tonight and finish at 2:00 AM tomorrow morning. Please do not change the alignment of ITMY or SR2 during the measurement.

Took H1 to DC Readout for Kiwamu to run high power tests.  

• The Power Recycling gain has been running low (i.e. 33?).  Kiwamu wanted to adjust alignment to see if this could improve this gain.  

Toward the end of the shift, H1 could not lock the OMC.  Kiwamu traced this down to a rung up violin mode for ETMy.  I remember watching others damp violin modes, but I have not done it before.  I tried looking through wikis and alogs for instructions but could not find any.  

H1 taken to a DOWN state for the night.