Similar to the BSC look here. Just looking at the higher frequency noise level indicating a problem. All the HAMs look fine in this regard. See the attached from diaggui template:
/ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/Common/CPS_Sensor_Spectra_HAM_ISI.xml
See logs 27648 27622 27549 27479 & 27475 for various looks & reports of the noise seen on BSC CPS channels.
In 27622, it is seen that ITMX Stage 1 has a very noisy V1 channel. This morning's view has no such issue for any of the stage1 CPSs (this was also reported in 27648.) The stage2 H3 channel however does now show a slight increase of noise relative to the others. All other BSC CPSs look good.
Dewpoints for the past 7 days for LTS containers in the LVEA.
SEI - More config testing
SUS - Tracking down noise in OSEMs from after power outage. Continues till 9am.
Fac - Wind fence is up at EXe.
PEM - Many L4Cs in bier garten, be careful. I
lluminator on ITMX that was turned OFF
Commissioning - made 50+W last night!
Next Tuesday afternoon tour
We had three PI modes - 15522 of ITMX and 15541 of ETMX and 15542 or ETMY- ring up tonight and were only able to damp successfully ~40 W for a few hours; around 4am local time ITMX and ETMY began ringing up (despite fully driving both ESDs) and broke the lock.
At 4:42 UTC we originally lost lock from ITMX and ETMX modes ringing up, shown below:.
In low power, I drove and damped each test mass to match it with it's peak. Here is a spectrum in low power with peaks labeled for this 15540 Hz mode group.
Tonight, 15521 Hz on ITMX was first damped easily but 15541 on ETMX is tricky since we don't have LV ESD on ETMX until further in the locking process. As Sheila mentioned, we tried switching to LV ESD ETMY so I could turn the LV ESD on for ETMX, but had some troubles and ultimately opted to not damp ETMX tonight but rather try remaining < 50 W. By 2 am we were successfully damping ITMX and (preventatively) ETMY ~40 W. A bit before 4am local, 15521 (ITMX), 15542 (ETMY) began ringing up. I'm having trouble grabbing data during these stretches to track the line amplitudes, so here's a spectrum showing the peak amplitude progression (in UTC times). It looks like ITMX led the ring up. Its not clear to me if ETMX went unstable.
We'll need to play with phases and iWave today to see if that helps strengthen damping.
Damping directions (for now) for 15522 of ITMX, 15541 of ETMX, 15542 of ETMY:
1. From orange PI button on sitemap, choose ITMX / ETMX / ETMY --> OMC OVERVIEW --> MODE2 / MODE 1 / MODE 4
2. BP and DAMP filters are populated correctly. DAMP filter gain around saturation with sign - / ? / +
Terra, it is at least theoretically possible to change the ETM LV Driver such that the HV path be active AND an AC coupled LV path (PI) active simultaneously. It would require some hacking and head scratching, but I don't see that it's impossible at this time. A high voltage relay selects between the LV mode and the HV mode for each quadrant. As you know, the HV mode doesn't have much PI drive capability, whereas the LV drive does. The trick would be to bypass the relay contacts between the LV and HV sides with a high voltage capacitor of 1 to 2nF. There is a 10k resistor in series with the HV side, so we would tie in on the optic side of the 10k with the bypass capacitor. Using 1.6nF would put the RC highpass corner at 10kHz, which would slightly reduce the drive amplitude at 10k, so a compromise of corner frequency and PI drive amplitude can be struck. Let me know, after exhausting other possibilities, whether or not this is worth pursuing.
Corey, Nergis, Stefan, Sheila, Terra
We were locked above 50 Watts for ~10 minutes. Our high bandwidth HARD loops along and the ISS 3rd loop are keeping us stable enough to power up, but we still have some things to work out.
Our first high power lock broke as we continued to increase the power beyond 50 W and a PI rang up.
Durring our second attempt Terra damped one PI, (separate alog coming) but we lost lock by increasing the power, ringing up a different PI, and ringing up the bounce modes.
We attempted to switch to ETMY at 20W so Terra could try damping a PI on ETMY, but found that we saturated the low noise driver with the high ASC noise we have right now. We engaged the Jenne Low passes in CHARD, which stopped the saturations at 20W, but we started to saturate again and lost lock as we tried to increase the power on ETMY. We will probably need to figure out how to power up on the low noise driver so that we have the option of damping PI on all test masses.
In our last attempt we let the guardian power up to 40 Watts, the power up took about 10 minutes, the only steps we did manually were engaging the ISS 3rd loop and turning off the bounce mode damping. We lost lock at 40 Watts around 9:18 UTC because of a problem with the ISS 3rd loop.
1. During power up from 2W to 50W, power-normalized arm transmission decreases by about a factor of 0.7 (attached).
That's a factor of 0.7 decrease of the optical gain of the 3rd loop. That's probably not enough to make something funny to the 3rd loop but it's something you need to know about.
And anyway, where's the power gone? MC transmission looks good, it should be IFO.
2. It might be possible to engage the 2nd and the 3rd loop at the same time before powering up, and changing the 2nd loop offset slider while powering up.
The reason why we need to adjust the offset is because the 2nd loop is DC coupled. Before engaging the 2nd loop (or 3rd loop) we run the offset adjustment servo, which is very slow due to double 0.1Hz pole in the offset path plus one 0.1Hz pole in the 2nd loop servo path itself. It's somewhat accelerated by digitally undoing a part of the delay, but it's impossible to undo three 0.1Hz poles without saturating the board badly.
However, once the 2nd loop is engaged, we only have to fight against two 0.1Hz poles to change the offset, so the task is somewhat easier (and quicker).
3. For engaging 2nd loop and 3rd loop at the same time, we need to change 3rd loop filter.
In principle all we need to do is to disable FM9 (boardComp) and set the gain correctly.
This evening has been focused on high power work (Nergis, Sheila, Stefan). This evening's claim to fame has been having H1 get to ~56W (Guardian request was higher). Somewhere above 50W, we were observing various instabilities---Nergis was watching PI modes ring up just before we lost lock.
Terra is now here and will most likely log in some PI investigation time along with more high power work.
I saved some ASC & LSC inmon templates, at Stefan's request for high power; they are saved in the ops folder:
/ligo/home/ops/Templates/Dataviewer/ [ ASC_inmons & LSC_inmons]
I injected into the 2nd loop board via PSL-ISS_TR (3rd looop filter) and SR560, and measured the transfer function from the readback of the analog input (H1:PSL-ISS_SECONDLOOP_PD_58_SUM_OUT, which is 32k channel) to the readback of the analog output ( H1:PSL-ISS_SECONDLOOP_SIGNAL_OUTPUT, which I think is in the 1st loop board) when the gain is set to 0, BOOST off, integrator off.
I was confused because of an additional 500Hz pole, but it seems like this was a questionable 500Hz digital pole in H1:PSL-ISS_SECONDLOOP_SIGNAL FM1. Anyway, in the attached, dots are as measured but after counter-compensating for the questionable 500Hz digital pole, and the lines are what is expected from D1300439 and S1400214.
The analog TF of the board itself should be something like zpk([1, 100, 8.46k, 10k], [0.1, 0.5, 500, 33.9k], 350). Yes there's 500Hz pole in analog. This is like one 0.1Hz pole up to 100Hz with some funny additional things (but don't forget SR560 with AC coupling and 10Hz pole, SR560 is used as a poor man's dewhitening to cut the DAC noise).
To make the 3rd loop design without 2nd loop somewhat easier, I made a simple zpk([0.1;0.5], [1;10; 50], 1) in FM9 of H1:PSL-ISS_TR called boardComp to get rid of p=[0.1, 0.5] and z=1. The potential problem of this is that the SR560 might rail. If this happens, we need something better.
Anyway, the starting point is to turn this filter on, then set the gain to whatever it was originally and divide it by 350, and measure the OLTF of the third loop without the second loop while the loop is open.
And it worked (Sheila, Kiwamu, Stefan, me).
No 2nd loop, boost off, integrator off, 20dB gain off.
Attached MEDM screen shows the filters used, and the dtt session shows the open loop transfer function when the loop gain was -1. At 2W, we were able to go as high as -3.
However, at 11W, when we turned the loop on with the gain of -3, something started oscillating with about 30 seconds period and we couldn't save the lock.
Questionable 500Hz pole in H1:PSL-ISS_SECONDLOOP_SIGNAL FM1 was removed.
Maintenance Day Log:
Locking is now in progress, Bounce/roll modes are high and are being damping at the moment.
Richard, Filiberto, Ed, Betsy
Following on from Andy's probing alog 27841 regarding funny looking OSEM spectra, today we looked into a few fishy signals. Based on spectra he took from before and after the early June power outage which show signal changes, he and Jenne identified the following set of problematic OSEM signals. I've annotated the list with status as to what we found or fixed today:
ITMY L2 LR - Fixed after power cycling the Satallite Amp box (see alog below)
ITMY R0 RT - Signal looks funny before power outage, old problem, TBC...
MC1 M3 UL - Signal looks funny before power outage, old problem, TBC...
PRM M2 UR - Fixed after power cycling the Satallite Amp box (see alog below)
PR2 M1 T2 - TBC...
PR2 M3 UL - Giant nominal YAW Bias which has been on this SUS for over a year - very little signal on OSEM - mechanical fix when vent
PR2 M3 LL - Giant nominal YAW Bias which has been on this SUS for over a year - very little signal on OSEM - mechanical fix when vent
SR2 M1 LF - Funny comb feature, TBC...
SR2 M1 T1 - Funny comb feature, TBC...
SR2 M1 T3 - Funny comb feature, TBC...
ETMX L2 LL - 50Hz turn up noise, TBC... Turn up is due to LOCK ACQ PUSHING, turn up not present during nominal SUS damping, no LOCK ACQ, see below plot
ETMX L2 LR - 50Hz turn up noise, TBC... Turn up is due to LOCK ACQ PUSHING, turn up not present during nominal SUS damping, no LOCK ACQ, see below plot
ETMX L2 UR - 50Hz turn up noise, TBC... Turn up is due to LOCK ACQ PUSHING, turn up not present during nominal SUS damping, no LOCK ACQ, see below plot
ETMY L2 UR - 50Hz turn up noise, TBC... Turn up is due to LOCK ACQ PUSHING, turn up not present during nominal SUS damping, no LOCK ACQ, see below plot
IM3 M1 LL - TBC...
We plan to pursue ITMy R0 and SR2 this week at next opportunity.
Before doing the sat amp power cycle, we first tried a coil driver power cycle on a few of our funny OSEM sets. This did not appear to clear the errant noise in any of the 4 cases. We then embarked on the sat amp power cycle which cured the 2 shown in the above list. Tomorrow we hope to revisit ITMY R0 RT and SR2 M1 which we have left off troubleshooting today with only coil driver OFF spectra. (Betsy, tomorrow you should use the attached spectra as a jump off point.)
TBC... Note the wildly different looking symptoms both of which were seen by Lundgren in 20675 AUG 2015.
Attached is the ITMY L2 OSEM signal spectra shown from before and after today's fix. The PRM M2 OSEM before and after-fix spectra are very similar to this.
ETMX High freq turn up during LOCK ACQ, not a stand alone OSEM signal feature.
ITMy R0 RT investigation - this morning Richard and Fil performed another round of tests on the ITMy R0 RT (shared cable and electronics with R0 LF, M0 RT, M0 LF). After power cycling the SAT box, other SAT box cable reseating, and reseating of the main cable to the chamber, the noise on this channel still exists.
SR2 M1 bouncy noise on 3 of 4 TOP investigation - Richard and Fil powert cycled the Sat AMp box for this set of 4 OSEMs, but the noise is still there.
TBC...
As requested by Betsy, I've made another set of spectra of the OSEMs. The green line is July 1 10:18 UTC. The reference time (black) is a time near the Boxing Day event (Dec 26 2015 4:30 UTC). This is because the OSEMINF channels are only stored in the commissioning frames, and those aren't stored for very long. But we did store them around events in O1. If we need to do these checks often, then we will need to 1) Store the OSEMINF channels in raw frames. 2) Occasionally save commissioning frames for some time in known-good states 3) Write some code to dump spectra to a file occasionally.
J. Kissel
After measuring charge today, I've flipped the BIAS sign on both ETMX and ETMY.
In addition, I've changed the compensation scheme downstream of the BIAS flip such that signs are flipped in each quadrant's ESDOUTF bank GAIN instead of being convoluted in the the DRIVEALIGN matrix elements. This separates the functionality, compensates any angular control as well as longitudinal (though we don't send any angular control to the test mass stage at the moment), and minimizes the possibility for losing the fine-tuned DRIVEALIGN gains.
Finally, I've modified the ISC guardian in such a way that it monitors the BIAS, and takes care of flipping all of the additional settings necessary to compensate for the bias change in the DOWN state. It had formerly had the DRIVEALIGN gain values hard coded, which was already bad news. Now the ESDOUTF gains (which have not been tuned / balanced as of yet) are flipped between -1 and +1; much easier to maintain. Also, I've added changing the CAL-CS settings to match as well, so the change in calibration will be taken care of as well.
I would post the latest results from today's change measurements, but I've been stuck trying to get 1 second of EPICS data from NDS2 for about 4 hours now.
Details
------------------
Before Flipping (to preserve my sanity, and minimize minus signs):
- Moved DRIVEALIGN negative signs into the ESDOUTF bank:
ETMX ETMY
OLD NEW OLD NEW
L2L -1 +1 -30 30
L2P -0.021 +0.021 0 0
L2Y -0.007 +0.007 0 0
and the ESDOUTF GAINs had all been positive unity, were flipped to negative unity so as to not yet actually flip the compensating sign.
Then, I changed the ETMX bias sign:
- Changed H1:SUS-ETMX_L3_LOCK_INBIAS from +9.5 to -9.5 [V_DAC]
- (unlike before) The ISC_LOCK guardian (now) takes care of checking the sign of H1:SUS-ETMX_L3_LOCK_INBIAS, and adjusting the sign of
- H1:SUS-ETMX_L3_ESDOUTF_[UL,LL,UR,LR]_GAIN from -1.000 to +1.000 (fixes the ESD stage longitudinal loop gain to match the bias sign change)
- H1:SUS-ETMX_L3_ESDOUTF_LIN_FORCE_COEFF from +124518.4 to -124518.4 (fixes the linearization force coefficient to match the new bias sign)
accordingly.
- (like before) Accepted the new values in *all* SDF snap files,
/opt/rtcds/userapps/release/sus/h1/burtfiles/
- h1susetmx_down.snap
- h1susetmx_observe.snap
- h1susetmx_safe.snap
by loading in each table and accepting the values I've changed, followed by a commit to the userapps repo.
- (like before) There's no need to make any further changes in the CAL-CS epics settings, because ETMX is not used in any capacity for calibration.
Followed by the ETMY bias sign:
- Changed H1:SUS-ETMY_L3_LOCK_INBIAS from -9.5 to +9.5 [V_DAC]
- (unlike before) The ISC_LOCK guardian (now) takes care of checking the sign of H1:SUS-ETMX_L3_LOCK_INBIAS, and adjusting the sign of
- H1:SUS-ETMY_L3_ESDOUTF_[UL,LL,UR,LR]_GAIN from -1.000 to +1.000 (fixes the ESD stage longitudinal loop gain to match the bias sign change)
- H1:SUS-ETMY_L3_ESDOUTF_LIN_FORCE_COEFF from -124518.4 to +124518.4 (fixes the linearization force coefficient to match the new bias sign)
accordingly.
- (like before) Accepted the new values in *all* SDF snap files,
/opt/rtcds/userapps/release/sus/h1/burtfiles/
- h1susetmy_down.snap
- h1susetmy_observe.snap
- h1susetmy_safe.snap
by loading in each table and accepting the values I've changed, followed by a commit to the userapps repo.
(This also involved *creating* a copy of the down.snap in the userapps repo, and changing the file in the
target/h1susetmy/h1susetmyepics/burt/ directory to a soft link, as was already the case for the OBSERVE.snap and safe.snap)
[Making sure Calibration is unaffected]
- (like before) We must make sure that the CAL-CS replica of the ETMY actuation matches the SUS ETMY digital signal chain. However, because the CAL-CS model had not been restarted, and its SDF system had been kept up-to-date it did not lose the appropriate settings, so the settings for
- H1:CAL-CS_DARM_FE_ETMY_L3_DRIVEALIGN_L2L_GAIN to +30.0
- H1:CAL-CS_DARM_FE_ETMY_L3_ESDOUTF_UL_GAIN to +1
- H1:CAL-CS_DARM_ANALOG_ETMY_L3_GAIN stays +1.0
- (unlike before) Again, to be consistent, I've changed the sign of the linearization force coefficient,
- H1:CAL-CS_DARM_FE_ETMY_L3_ESDOUTF_LIN_FORCE_COEFF from +124518.4 to -124518.4
- (unlike before) Accepted the new values in *all* SDF snap files,
/opt/rtcds/userapps/release/sus/h1/burtfiles/
- h1susetmx_observe.snap
- h1susetmx_safe.snap
by loading in each table and accepting the values I've changed, followed by a commit to the userapps repo.
(Since there is no change between the "down" and "observation" state, a "down" .snap doesn't and need not exist.)
Something is wrong with ALS DIFF, is seems to saturate constantly. Is something wrong after the bias flip?
Looks like the Linearization Force Coefficient some how got flipped back to +124518.4. We fixed the sign there, and made sure it was coded correctly in the ISC_LOCK guardian and moved on. To 50+ W no less!
WP 5948 The code for the Beckhoff vacuum controls at end Y has been updated and restarted. This changes the PID controller for the CP LLCV from the FB_BasicPID supplied with the Tc2_Utilities library to a PI controller that I wrote (PIContollerFB in the Vacuum library). The changes include: - There is a manual control mode. Switching to manual control stops and resets the PI controller. - Changing the PI gains does not reset the controller. - The controller can be set to run at a slower rate than the PLC task (not in effect in manual mode). This is the cycle time on the medm screen. - There are user settable limits on the size of the integral term (anti-windup). These are the integrator high and low limits on the medm screen. - There are user settable limits on the output (not in effect in manual mode). These are the output high and low limits on the medm screen. - There is a user settable dead-band. The controller output does not change unless the absolute value of the difference from the last controller output is greater than the dead-band (not in effect in manual mode). - It has a user settable offset term in addition to the proportional and integral gains. This is essentially a constant offload of the integral term. The form of the controller is basically: Output = KP * Error + sum( KI * Error * (cycle time in milliseconds)) + Offset where KP is the proportional gain and KI is the integral gain I have updated the medm screen for CP7. I have also updated the overview medm screen to add links to the fill control screens next to each CP. One issue is that the displayed precision for the integral gain is too small. I will fix this at the next opportunity to restart the code. In the mean time it can be temporarily changed by right clicking on the medm screen, selecting PV Limits, clicking on the input field of the integral gain, changing the precision source to user specified, and changing the precision value to 6. This change will be lost when the medm screen closes. The code is currently controlling CP7 in PID mode, which also happened to get a LN2 delivery around the same time as the code change. The current settings are shown in the attached screenshot. The PID setpoint and offset may be hard to read, they are 92 and 80 respectively. The following channels were removed from the DAQ: H0:VAC-EY_CP7_400_LLCV_PID_ERR_CODE H0:VAC-EY_CP7_400_LLCV_PID_ERR_FLAG H0:VAC-EY_CP7_400_LLCV_PID_OUT_PCT H0:VAC-EY_CP7_400_LLCV_PID_TD H0:VAC-EY_CP7_400_LLCV_PID_TN H0:VAC-EY_CP7_400_LLCV_PID_TV H0:VAC-EY_CP7_LIC400_LLCV_POS_CTRL_PCT_DEAD_BAND The following channels were added to the DAQ: H0:VAC-EY_CP7_400_LLCV_PID_KI H0:VAC-EY_CP7_400_LLCV_PID_OFFSET H0:VAC-EY_CP7_400_LLCV_PID_ITERM_MAX_LIM H0:VAC-EY_CP7_400_LLCV_PID_ITERM_MIN_LIM H0:VAC-EY_CP7_400_LLCV_PID_OUT_MAX_LIM H0:VAC-EY_CP7_400_LLCV_PID_OUT_MIN_LIM H0:VAC-EY_CP7_400_LLCV_PID_OUT_DEAD_BAND
Jenne, Nergis, Rana, Haocun
After all the PIT optical lever servos were on for both the ITMs and ETMs (27863), we measured the HARD Loops Gains again yesterday evening.
In the pictures attached, the red dots are mesurements when the PIT OLDAMPs are on for all the TMs, and also we have boosts on for those measurements (which explains the magnitude changes in low frequency and phase changes even for Yaw). The black curves are the measurements taken before the OL servos were on for the ETMs, and without boosts. The blue curves are the modeling results, which assume only OL on for ITMs.
.fig files attached.
Because we used up all the filter banks for the fundamentals, I made broadband filters for the high ETM 2nd harmonics.
ETMX 1003.664, 1003.778, 1004.078 and 1004.537 are damped with MODE9 FM1, FM4, FM10 (notch at 1003.907 Hz) with -50 gain.
butter("BandPass",4,1003.67,1004.54)gain(120,"dB")*gain(100,"dB")* ellip("BandStop",2,3,40,1003.807,1004.007)
This filter was later found to be ringing 1003.778 Hz. It has to be reconfigured. The individual damp settings for 1003.664, 1003.778, 1003.907, 1004.078, and 1004.537 are 0deg, +-180deg, 0deg, +-180deg, and 0 deg.
ETMY 1009.44 and 1009.49 are damped with MODE10 FM1, FM4 with +150 gain
butter("BandPass",4,1009.44,1009.49)zpk([0;0],[],1,"n")*gain(100,"dB")
ETMY 1008.45, 1008.49, and 1009.02 are damped with -60deg, -60deg, and 0deg (all + gain). No broadband filter has been made yet.
The other high amplitude modes that I haven't tried to damped are ETMX 1005.17, 1005.94, and 1006.5
ETMX MODE9 FM1 now covers 1003.667, 1003.778, and 1003.907. The face are correct here and should be damped with positive gain setting.
ETMY MODE 9 FM1 now covers 1008.45, 1008.49, 1009.02. The phase is close to what damped last night. Still has to be tested.
Conor, Jeff K Summary: - Conversion of ISI Suspoint motion into the DoF basis works for the arms, with limited fidelity. - Corner station DoFs seem not to work, possibly some problem with inclusion of the Beamsplitter. - IPC communication between ISI and SUS at ETMY is spoilt somehow. The GS-13s on stage 2 are used as witnesses for residual motion. Their outputs are calibrated to nm, and converted to suspension point motion using Euler matrices (Cart2Eul). The output is in the local suspension coordinates. For example, the channel 'H1:ISI-ITMX_SUSPOINT_ITMX_EUL_L_DQ' is the longitudinal motion of ITMX, which is along the normal vector pointing outward from the HR surface, in the global +X direction. These suspension point motions are IPC'd to the OAF model, and in the case of the ETMs this involves some multiplexing/AI-filtering for communication down the arm. In OAF they are combined into the IFO degrees of freedom based on T1500610 . As a sanity check, I fetched the ISI-model Suspoint channels and matrix'd them into the IFO DoFs in Matlab, for comparison with the OAF DoF channels. For the arms (XARM, YARM, CARM, DARM), things seem to be somewhat okay. I confirmed this by eye, and then took the spectrum of the subtraction (attachment 1, CARM_Spectrum). The residual is consistent with the dynamic range of single-precision floats (about 10^9), at least at high frequencies. A quick software-only transfer function using four poles at 0.1Hz and white-noise injection in a spare filter bank shows a similar total dynamic range (attachment 2, DTT_dynamic_range). The anti-imaging filters, for transmission of the ETM signals along the arm, should allow a considerably smaller residual than we see at low frequencies, and I don't really know what else might cause this. The corner station DoFs are substantially wrong, visible directly in the time series' (eg attachment 3, MICH_time_series). Since MICH only uses the ITMs (confirmed to be 'okay') and the Beamsplitter, presumably the difference arises there. PRCL and SRCL are similarly incorrect. Document T1500610 has some minor errors in the Suspoint->IFO-basis definitions, but the current matrix has correct values as far as I could see. It also points to the Suspension model versions of the Suspoint motion, eg 'H1:SUS-ITMX_M0_ISIWIT_L_DQ', but the model uses the ISI versions. Initial testing revealed discrepancies between: 'H1:ISI-ETMY_SUSPOINT_ETMY_EUL_L_DQ' 'H1:SUS-ETMY_M0_ISIWIT_L_DQ' visible in attachment 4 (ETMY_IPC_issue). The other 3 test masses didn't show this gross level of disparity.
The problem with the corner station calculations are a model mapping error. I pointed this out to Jeff but he must have thought I fixed it or he just spaced it out given his usual very full to-do list. I've never edited the OAF model and did not feel comfortable doing so. Attached is the errant part of the model. The BS PRM PR2 and PR3 are all mis-mapped in this section.
Dave, Conor, Jenne, Hugh
Jenne is fixing the mapping mis-wire for the corner station calculations.
Dave checked the data path and found the SUS and ISI versions of the CART2EUL matrix for the ETMY were not the same. This looks likely to be the issue rather than an IPC problem.
I checked the values against the data file I used to populate the matrices for all the suspensions and it still agrees. I suspect the values in the SUS ETMY matrix are out of date.
See alog 11036 for more details: Data file is
/opt/rtcds/userapps/release/isc/common/projections/ISI2SUS_projection_file.mat
Here is some detail on the GS13 signal paths. The six GS13 signals coming out of the ISI model are split, with one set going via Dolphin IPC to the SUS system, and the other set going through the ETMn_CAL into the ETMx_SUSPOINT part, in which is passes through a CART2EUL matrix. The SUS model receives the six dolphin channels, passes these through the ISIINF part, then through its CART2EUL matrix into the ISIWIT. It is these two CART2EUL matrices which have identical settings at ETMX and are slightly different at ETMY.
J. Kissel I've compiled, installed, and restarted the OAF model with the SUSPOINT to IFO basis transformation bug fix, and committed the top level model, /opt/rtcds/userapps/trunk/isc/h1/models/h1oaf.mdl Attached is a screen shot showing the current and correct channel ordering.
J. Kissel I've also updated the SUS version of the ETMY CART2EUL matrix (i.e. H1:SUS-ETMY_M0_CART2EUL channels) with the values found in /opt/rtcds/userapps/release/isc/common/projections/ISI2SUS_projection_file.mat that was apparently discrepant in only *some* of the rotational terms, and only by ~10%. I can't explain why these were off, and I'd trended the values for the past 850 days (with the stop time of June 2015, so I covered the time install time mentioned in LHO aLOG 11036) and they've not been changed. One of life's mysteries, I suppose. Fixed now! For the record, the new values are | L | | 0 -1.0000 0.2000 0 -0.2823 0 | | X | | T | | 1.0000 0 0.4294 0 0 -0.2823 | | Y | | V | = | 0 0 0 1.0000 -0.4294 0.2000 | | RZ | | R | = | 0 0 0 0 0 -1.0000 | | Z | | P | | 0 0 0 0 1.0000 0 | | RX | | Y | | 0 0 1.0000 0 0 0 | | RY |
Also, I posted some analysis of the relative motion between HAM2 and HAM3 in the DCC https://dcc.ligo.org/G1601390 differential Z is really small. differential X kind of sucks at the microseism. Not sure how much it matters for the IMC, but it is worth thinking about. I think there is some fruitful work to be done here - if it would be useful to reduce the relative motion of the ISI tables in the corner at the microseism.
