[Jenne, Sheila]

We spent much of the evening trying to find a better combination of QPDs to use for the SOFT error signals, since SOFT is what is moving, and pulling down our recycling gain.

In the past, we have chosen combinations that are insensitive to TransMon pitch and yaw, so that we don't put TransMon motion back into our arms. 

One of the things we tried tonight was to instead chose a combination for SOFT that was insensitive to HARD. Unfortunately, our HARD and SOFT modes are very nearly degenerate in the QPDs, so that turns out to have been a poor idea.  We were able to close the loops around this combination (before we realized that it wasn't going to be great), and I moved the SOFT offsets around to recover our power recycling gain.  In the screenshot, you can see that when we increased the PSL power, we lost recycling gain.  Then, it comes back. (Also shown is my stray click on the PSL guardian screen where I accidentally requested more than 50W. We kept lock during that adventure).

We tried once to create a combination that is maximally sensitive to SOFT (which will also be very sensitive to HARD).  We engaged the pitch loops with this combo, and lost recycling gain, and then lost lock.  So, more work to be done here.

We're still not sure what is the best combo to use - there are more things in this department to try out.

Quiet shift environmentally, and the entire shift was devoted to Commissioning work.  Here are a few notes:

• nds1 went down (Dave, Jim brought it back)
• Always make sure the Down Script runs---> after a lockloss noticed that the X-arm was misaligned by alot (tracked down to ITMx pitch).  Apparently, the DOWN script didn't clear the ITMx Pit M0 path.  Running DOWN & INIT brought back ITMx.
• Mysterious Arm dark offset zeroing was another oddity.

Untimately we need to engate the 2nd and the 3rd ISS loop at the same time. Toward this goal, I first tried to engage the 2nd loop but without the 3rd loop, and measure the 3rd loop open loop transfer function while the 3rd loop was open, but the IFO didn't cooperate at 20W today.

I instead measured the 1st loop and the second loop sensing by injecting into the 1st loop error point via the second loop board while the input side of the 2nd and the 3rd loop were both open.  I measured between 6Hz and 0.4Hz, and it was mostly flat as it should be. At 2W, the ratio of the second loop sensing to that of the 1st loop sensing was:

Sens2(2W)/Sens1 = -0.4.

At P Watts, this will become -0.2*P.

Let's say that the 2nd loop works at 25 Watts with the same setting as in O1. And we already know that the 3rd loop (without 2nd loop) works with the 3rd loop filter gain of -1. A good starting point would be to engage the 2nd loop at 25 Watts without the 3rd loop, disable FM9 (boardComp) of the 3rd loop filter, set the gain to -1*(-0.2*25) = 5 and engage the 3rd loop.

The 3rd loop digital gain needs to be changed as the power goes up because the sensing for the second loop is not normalized by power. The analog gain control slider is downstream of the 3rd loop summation point and cannot be used as a poor man's power scaling for the sensing.

While locking this evening, Sheila noticed that while H1 was locked in DRMI & after it went through PREP_TR_CARM, the Arm Offsets were put at wrong values (which would have prevented us from FINDING IR for later locks).  

In Guardian, we basically take an average of 1sec of data of the IN1 signals & then this avg is entered as the offset (with a "-" sign).

[From the ISC_LOCK.py script]      

• # measure ARM offsets (This is not used for the signal in PREP TR CARM?!)
• myoffsets=cdu.avg(1,['LSC-TR_X_QPD_B_SUM_IN1','LSC-TR_Y_QPD_B_SUM_IN1'])
• ezca['LSC-TR_X_QPD_B_SUM_OFFSET']=-myoffsets[0]
• ezca['LSC-TR_Y_QPD_B_SUM_OFFSET']=-myoffsets[1]

This sounds like it makes sense, but for our lockloss, Guardian took BOTH offsets to 0.0  (and the IN1 signals were clearly not 0.0).  So this looks rather dubious.  Attached is 6-seconds of data for both X&Y arms.

After the OAF model wiring fix, the Suspoint -> IFO-basis appears to work fine, except for the (already mentioned) limited subtraction.

I compared the GS13 (Suspoint) DARM with H1:CAL-DELTAL_EXTERNAL_DQ. To do this, I had to de-whiten the DELTA-L signal with 6 zeroes at 30 Hz 
and 6 poles at 0.3Hz (10^12 dewhitening). In principle, this should be calibrated down to 10mHz (the calibration model has a pole at 10mHz 
instead of DC). 

The two spectra (attachment 1, 'DARM_suspoint_vs_IFO.png') somewhat agree. There seems to be some residual error in the calibration of 
Delta L at low frequencies (it should cross 10^-6m/rt(Hz) at some point). Kiwamu found that the gain field of H1CAL-CS_DARM_FE_ETMY_L1_LOCK_L 
was a factor of 3 different from its equivalent suspension model, and corrected it, but this cannot explain the difference we see. 
The coherence (attachment 2) is quite good from ~0.03-0.3Hz.

Note that the GS13s are calibrated only to 30mHz, but this is also where they begin to rapidly lose coherence anyway. GS13 noise floor 
(for a single device) is added to show that there is some significant SNR at nearly all frequencies shown.

Crystal Chiller:  Topped off with 125mL.

Diode Chiller:  No Fault light.

Two Canister Filters:  They both looked white; the one on the left had a small amount of particles on the bottom.

CLOSING out FAMIS #6476

The ITMX PI path was measured during maintenance day driving from CDS and measuriung the quadrant outputs to the ESD. WP#5931
Specifically driving H1:SUS-ITMX_PI_OMC_DAMP_MODE1_DAMP_EXC with 80k counts, and measuring P2-P5 of D1600122 directly with an SR785.
In this case a splitter was created and used to allow the cable and ESD load to be included in the measurement.  This configuration resulted in a 1.6% drop in drive amplitude of the LL quadrant fairly uniformly across all frequencies.

There is some confusion with the channel naming, on the chassis front panel left and right are switched relative to the model naming.  The model names appear consistent with wiring diagram D1500464.
Otherwise these channels behave well.  

late entry for yesterday's Tuesday Maintenance

SUS PI

Carl, Dave, Terra, TJ:

new models for h1susetm[x,y]pi with associated DAQ restart.

Terra and TJ got the new Guardian GRD_SUS_PI node started.

New Vacuum Controls PID code for CP7

Patrick, Dave:

New code and epics database installed on h0vacey. New INI file installed with associated DAQ restart. New autoBurt.req file installed in target area.

New ASC model

Jennie, Jim, Dave

New h1asc model installed. After the build process we saw confusing archived INI files. We rebuilt, restarted and performed a DAQ restart.

New OAF model:

Jeff, Dave

A new h1oaf model was installed. Surprisingly the CPU processing time went up by 3uS from 53uS to 56uS. This is getting uncomfortably close to its 60uS limit. The changes made yesterday should not have done this. More investigation is needed. DAQ restart was not needed as this was a very unintrusive model change.

New dataviewer code

Jim:

Installed new dataviewer code with bug fix to trend the new double precision floating point data type.

new NDS2 client code

Jim:

version 12.2 nds2 client code installed on CDS.

mini-epics-freeze events

Sheila, Dave:

Sheila reported and alogged some epics freeze up events while viewing ASC and LSC data. I did a quick analysis using my IOP duotone channels which get to the DAQ via channel access and did not see any freeze-up in these channels for ASC and LSC. This appears to be a new phenomenon, investigation is continuing.

runtime, graphical

For a running system a filter's SWSTAT value and its decoded switch bits can be viewed graphically by pressing the "GUARDIAN SET" button on the lower left of the filter medm. Of course these bits are also shown on the main medm, the FILTALH medm just shows just the switch settings more clearly.

command line, non graphical

For a command line decoding of the bits, Jamie has written the 'cdsutils sfm decode' function. This takes either one argument (the SWSTAT value) or two arguments (either SW(1,2) or SW(1,2)R). For a running system you can use either SWSTAT or the SW(1,2)(S,R) options. For past settings only SWSTAT is available from the DAQ. From conlog the SW(1,2)S values are also available, but they are equivalent to SWSTAT (filter engaged bits not available). Here is an example with SW(1,2)R supplied (so engaged bit data is shown).

cdsutils sfm decode 12292 1536

INPUT
FM5
FM5_ENGAGED
OUTPUT
DECIMATION

command line, graphical

Mike Thomas has written a python script called filterstate, which takes either SW(1,2)S or SW(1,2)R pairs as arguments and shows the switch settings graphically by creating a static png image which approximates to the standard filter module medm. Because only SWSTAT is available from the DAQ. I have written a script to convert SWSTAT to its equivalent SW(1,2)S pair called swstat2sw

For example, if the SWSTAT is 37904, the decode can be shown graphically with the command

filterstate $(swstat2sw 37904)

which produces the image shown below.

TITLE: 06/22 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Commissioning work all day after 9, currently locked at 20W in INCREASE_POWER.
LOG:

• 14:00 - Chris S to EX to retrieve tractor and water/1ton truck and then bring it back to the CS. Should be a couple hours of work.
• 15:07 - Richard to LVEA to swap sat amps
• 15:28 - Fil to LVEA to put tester boxes on ITMY M0 and R0
• 15:30 - Vac group tour in LVEA
• 16:00 - Fil, tour out
• 18:02 - Jeff B to Optics Lab
• 18:06 - Fil, Peter K to Optics lab
• 18:14 - Jeff B out
• 18:19 - Fil, Peter out
• 21:44 - Kyle to MY for CP3 fill
• 22:08 - Kyle back

Since the calibration for the rotation stage doesnt seem to last too long, I added a bootstrapping method from rs_power_control.py (that I think Jamie made?)

At the end of the RS move, the bootstrap will move (requested_power^2) / (current power) further. This assumes that it is already close.

We tried it once going from 9.2W to a request of 20W and it went to 20.0W. Very nice.

Conor, Jeff, Jim, Robert, Krishna

- Maximising coherence between the GND STS2 and the BRS is not necessarily the right move.
- Small gains at low frequencies might be made by moving the GND STS2 by some 10s of centimeters.
- Designing sensor-correction filters using offline data provides immediate quantitative performance metrics.

Robert's aLOG of ~1 month ago, 27170, showed 
that coherence between seismometers (and the BRS) changes very rapidly with distance, presumably due to warping of the 
floor or the wind acting like incoherent local sources. It was also apparent the magnitude of the tilt changed by a 
factor of ~5 or more from the edge of the slab to a position far from the walls. 

I wanted to see what the BRS-corrected seismometer performance is like as a function of position. Unfortunately the 
BRS-corrected sensor isn't saved to science frames (H1:HPI-ETMY_STSINF_C_Y_IN1_DQ), and it really should be. On the 
other hand it made me import all the appropriate filters into Matlab to perform offline sensor correction. This allows 
me to evaluate whether we should move the Ground STS2 to a position that is more coherent with the BRS. Attachment 1, 
'GND_spectra.png' shows that the ground motion spectrum is roughly equivalent in the three cases I looked at:
1) 06 May, STS2 huddle
2) 08 May, PEM-STS2 right next to BRS center
3) 13 May, PEM-STS2 at a position with low tilt, on the far side of the BSC, as far from the walls as possible.
These correspond to points 1, 3, and 6 from Robert's post.

1) Huddled STS2s, attachment 2, 'Huddle_BRS_correction.png'
Sensor correction works nearly identically on both devices, using the low-frequency cumulative RMS as a figure of merit. 
Note that I only accumulate RMS below the microseism to better see sensor correction performance.

To get this level of sensor correction, I had to multiply the BRS output by 0.85 for the GND device, and 0.7 for the 
PEM device (in addition to the 'match' filter of 0.85). This means that, even when huddled and coherent, there is ~18% 
less tilt in the PEM device. This is the cause of the better low-f performance, where incoherent BRS noise dominates.

2) PEM next to BRS center, attchment 3, 'BRS_center_BRS_correction.png'
The coherence between the STS2 and the BRS at this position is slightly higher than at the GND position. Perhaps 
this is visible near to 0.1Hz. However, to get good performance, I had to multiply the BRS out by 1.5. This factor is 
solely responsible for the worse low-frequency performance.

3) PEM at low-tilt position, attachment 4, 'low_tilt_BRS_correction.png'
Due to its 5.5m distance from the BRS and GND-STS2, there is almost coherence below 0.1 Hz. The best RMS performance 
comes, unsurprisingly, with no BRS sensor correction. The corrected seismometer wins by a factor ~2 down to 10mHz.

My conclusion from all this is that: Moving the GND-STS2 to increase coherence is not the correct thing to do. 
Moving it ~40cm may surprisingly result in a 18% reduction of noise injection from the BRS with no real loss. 
There may be additional gains to make in this fashion. Moving the BRS to a lower-tilt position, along with the 
GND-STS2 may help, but ideally the BRS will be in a place with higher, but still coherent tilt.

Conclusion #2: while looking at this sensor correction, it became clear that significant gains can be made in the 
BRS sensor correction performance both in global gain and in the high-pass BRS blending filter. I will try to find 
a long, windy period for 'training' this filter.

Conlusion #3: placing STSs in low-tilt positions (like STS_ITMY in the beer garden) is already quite beneficial, at 
the factor 2 or more level. The low-tilt position at ETMY seems to perform as well as the buried seismometer, and for 
some reason much better during the 13 May stretch of data.

Nergis, Peter, Stefan,

Currently, as we transition from 10W to 57W input power, our recycling gain drops from about 34 to 27. It seems like we need to tune the common TCS:

Attached are 3 plots:

Plot 1: DC signals:

PR_GAIN and normalized arm power (both blue)
AS_DC A and B (green and red)
POP_DC A and B (cyan and purple)
REFL_DC A and B (yellow and black)

Note the interesting behaviour of the REFL DC, all while AS_DC is linear in power.

Plot 2:

Arm and power recycling cavity powers, as well as test mass pitch control signals. The test masses have to compensate for radiation pressure, making the pitch control signal proportional to the arm cavity power.

Plot 3: RF signals:

Power and signal recycling cavity sideband buildups.

Jenne, Sheila, Haocun

We took measurements on the hard loops with 40w (actually 37w) laser power today.

The results are plotted with the modeling.

David.M, Jenne.D

Yesterday I set up the sensors for the Newtonian noise L4C array in the beer garden. There are 31 sensors there in total (30 for the array and 1 spare), I arranged them in a huddle beneath the stairs near the STS-2. 20 of them are plugged into the two chassis located in the beer garden which correspond to the first 20 L4C channels. The other chassis is located external to the beer garden next to HAM2, I only connected two sensors to this rack because of a lack of long cables. The channels with these two sensors are L4C channels 26 and 30. I've attached a table which states which serial number L4C is connected to which channel for reference. Also attached are a photo of the current sensor huddle as well as an initial plot of the sensor spectrums calibrated to the STS-2 (thick black line).

The sensors themselves are each only touching the floor (despite what it looks like in the photo), although each wire touches many other wires and don't have any proper strain relief yet. The sensors currently being recorded are the ones more closely huddled together in the photo. The ones which are seperated slightly off to the left are the currently unrecorded L4Cs.

Why is the ETMY motion so different in character than all the other test masses?  All 4 test masses have angular control applied right now, but ETMY looks crazy.  I see it on the oplevs, as well as the L2 OSEMs, so I think it's real motion.

The attached plot shows the arm cavity higher order mode spacing as calculated by Aidan's on-line thermal simulation (TCS_SIM). At 37 W input, the HOM spacing in each arm cavity increases by 60 Hz (X arm) and 75 Hz (Y arm) - relative to the no power-loading case. The ring heater configuration was constant during this time: both cavities had 1 W (total) RH power on the ETM, and no RH power on the ITM. The plot shows that the HOM spacing increases by 30-40 Hz in going from 18 W to 37 W input. If the 15.5 kHz PI modes are stable at 18 W, then we can increase the ETM RH powers to reduce the HOM spacing by 30-40 Hz, and they should then be stable at 37 W. This requires additional RH power of 0.5 W (total, top + bottom).

Couple things to note:

The X-arm simulation output shows a long time constant, but the Y-arm does not. The simulation does include a low pass filter for the surface change due to laser beam self-heating, to simulate this heating time constant. However, this low-pass filter was only engaged for ITMX. I have turned on the filter (surfTF, in FM1) now for all 4 test masses.

The arm cavity power calculation used in the simulation seems to be off. At 37 W input, it is using about 75 kW for both arms, when it should be closer to 150 kW. Something to look into.