J. Kissel, D. Tuyenbayev We've grabbed another set of calibration measurements of the IFO's sensing function in order to build confidence in our newly commissioned front-end tracking of time dependent model parameters, and to confirm the discrepancy seen yesterday (LHO aLOG 30391) was not something funny about that lock stretch. Indeed the discrepancy remains. We've found bugs in our code that compares our DARM model against these measurements, so we can't yet confirm exact numbers like optical gain, DARM coupled cavity pole frequency, or SRC detuning spring frequency to offer a proposed change to the CAL-CS front-end parameters to fix it. We'll hopefully have something by tomorrow. Attached are screenshots of the measurements and the DARM loop parameters during the measurement. Timeline: (in UTC) 2016-10-12 01:30:00 -- IFO in stable Nominal Low Noise (PCALY calibration lines are ON); IFO undisturbed 01:46:00 -- IFO sufficiently thermalized to start measurements; PCALY lines turned OFF 01:47:48 -- PCAL2DARM measurement begins 02:05:48 -- DARM OLGTF measurement begins 02:24:00 -- measurements done; PCALY lines turned back ON; IFO undisturbed 02:40:00 -- Official Undisturbed period ends (but no one has done anything with the IFO since, up to 03:06 UTC) Data files (which are exported and committed to the SVN): /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/ DARMOLGTFs/2016-10-12_H1_DARM_OLGTF_4to1200Hz.xml PCAL/2016-10-12_H1_PCAL2DARMTF_4to1200Hz.xml
J. Kissel, D. Tuyenbayev,
These are kappas calculated in the front-end after the TF measurements have been completed.
The optical gain is still ~15% lower w.r.t. the value in the DARM model parameters and the coupled-cavity pole frequency is ~ 340-350 Hz, which is higher compared to the yesterday's value (LHO alog 30391).
There's still more noise in the calculated values of fC. The SNR of the 331.9 Hz line is affected by a slightly increased noise in the [0.2, 1.0] kHz band.
Doing the same thing as was done in LHO aLOG 30475, I've grabbed similar undisturbed data from the times quoted in the original entry, and replotted them in matlab after doing some rudimentary math. The 15 minute (900 sec) average value (starting at Oct 12 2016 02:39:00 UTC) for all of the time dependent parameters just after the sweeps are: Param Units Mean Std kappa_{C} [ ] 0.868 pm 0.01 f_{cc} [Hz] 325 pm 5.5 Re: kappa_{PU} [ ] 1.01 pm 0.0089 Im: kappa_{PU} [ ] 0.0007 pm 0.015 Re: kappa_{TST} [ ] 0.998 pm 0.011 Im: kappa_{TST} [ ] -0.010 pm 0.0091 Input Power [W] 51.8 pm 0.029 The script to generate these values lives in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/CAL_EPICS/get_fe_tdep_params.m
J. Kissel I've used Kiwamu's templates (LHO aLOG 29860) to gather new DARM OLG and PCAL2DARM transfer functions, to help increase the number of data points for darm coupled cavity pole and SRC detuning spring frequencies. In doing so, I've found that PCAL suggests that CAL-DELTAL_EXTERNAL is wrong low by ~20% above 50 Hz, in a frequency dependent fashion (confirmed by the phase and ridiculously high coherence). We will analyze the data in-full, and report what the measured pole and spring frequencies are in the morning. We'll also show trends of calibration line heights, such that eventually we can confirm the frequencies over time. This frequency dependent error in CAL-DELTAL_EXTERNAL may be because the DARM coupled cavity pole frequency programmed into the CAL CS fron end is 342 Hz, and that's just not correct for this lock stretch. We have to turn OFF the PCALY calibration lines during the measurement due to range issues, but the front end calculation of the DARM cavity pole, after the measurement, suggests anywhere for 315 Hz to 340 Hz. Unclear whether we can trust the online calculation just yet, so we're leaving the IFO alone for ~30 minutes after the measurement to be able to confirm offline later. Recall that we're still not controlling the cavity waist angle/translation of the SRC entirely: the SRC1 loop (nominally controlling SRM alone) is OFF, but the SRC2 loop (controlling SRM and SR2) is ON. Undisturbed time post-sweeps: Start Oct 11 2016 02:36:00 UTC Oct 10 2016 19:36:00 PDT 1160188577 Stop Oct 11 2016 03:07:00 UTC Oct 10 2016 20:07:00 PDT 1160190437 The new measurements have not yet been exported, but have been committed to the CalSVN here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/ DARMOLGTFs/2016-10-10_H1_DARM_OLGTF_4to1200Hz.xml PCAL/2016-10-10_H1_PCAL2DARMTF_4to1200Hz.xml EDIT: I've added two screenshots showing the digital settings relevant to the DARM loop parameters. Unfortunately, the production conlog is down for maintenance/upgrades, but thankfully Patrick setup a test bed a few nights ago (goto http://conlog-test-replica/), I was able to pull the list of channels I needed. FAlso for the record, some of those channels have changed since O1, so I quote the new list here for easier copy and paste in the future: H1:LSC-DARM1_SWSTAT H1:LSC-DARM1_GAIN H1:LSC-DARM2_SWSTAT H1:LSC-DARM2_GAIN H1:SUS-ETMY_L1_LOCK_L_SWSTAT H1:SUS-ETMY_L1_LOCK_L_GAIN H1:SUS-ETMY_L1_DRIVEALIGN_L2L_SWSTAT H1:SUS-ETMY_L1_DRIVEALIGN_L2L_GAIN H1:SUS-ETMY_L2_LOCK_L_SWSTAT H1:SUS-ETMY_L2_LOCK_L_GAIN H1:SUS-ETMY_L2_DRIVEALIGN_L2L_SWSTAT H1:SUS-ETMY_L2_DRIVEALIGN_L2L_GAIN H1:SUS-ETMY_L3_ISCINF_L_SWSTAT H1:SUS-ETMY_L3_ISCINF_L_GAIN H1:SUS-ETMY_L3_LOCK_L_SWSTAT H1:SUS-ETMY_L3_LOCK_L_GAIN H1:SUS-ETMY_L3_DRIVEALIGN_L2L_SWSTAT H1:SUS-ETMY_L3_DRIVEALIGN_L2L_GAIN H1:SUS-ETMY_L3_LOCK_INBIAS H1:SUS-ETMY_L3_ESDOUTF_LIN_BYPASS_SW H1:SUS-ETMY_L3_ESDOUTF_LIN_FORCE_COEFF H1:SUS-ETMY_BIO_M0_STATEREQ H1:SUS-ETMY_BIO_L1_STATEREQ H1:SUS-ETMY_BIO_L2_UL_STATEREQ H1:SUS-ETMY_BIO_L2_LL_STATEREQ H1:SUS-ETMY_BIO_L2_UR_STATEREQ H1:SUS-ETMY_BIO_L2_LR_STATEREQ H1:SUS-ETMY_BIO_L3_UL_STATEREQ H1:SUS-ETMY_BIO_L3_UR_STATEREQ H1:SUS-ETMY_BIO_L3_LL_STATEREQ H1:SUS-ETMY_BIO_L3_LR_STATEREQ
J. Kissel, D. Tuyenbayev,
Kappas calculated in the front-end suggest that an optical gain was lower compared to the reference time (optical gain in the DARM model) by ~15% and the coupled-cavity pole frequency was ~325 Hz at the TF measurement time.
Also it seems that the SNR of 331.9 Hz line is not sufficient - higher statistical noise in the calculated κC and fC.
A little bit more quantitative assessment if the time dependent correction factors as computed by the front end (or "kappas"): I've grabbed similar undisturbed data from the times quoted in the original entry, and replotted them in matlab after doing some rudimentary math. The 15 minute (900 sec) average value (starting at Oct 11 2016 02:51:00 UTC) for all of the time dependent parameters just after the sweeps are: Param Units Mean Std kappa_{C} [ ] 0.866 pm 0.011 f_{cc} [Hz] 323 pm 4.5 Re: kappa_{PU} [ ] 1.01 pm 0.011 Im: kappa_{PU} [ ] -0.007 pm 0.012 Re: kappa_{TST} [ ] 0.998 pm 0.0085 Im: kappa_{TST} [ ] 0.0095 pm 0.0065 Input Power [W] 50.5 pm 0.031 The script to generate these values lives in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/CAL_EPICS/get_fe_tdep_params.m And for ease of copy and paste for someone in the future, I'm gathering the following channels (which correspond to the parameters in the same order as the table above) H1:CAL-CS_TDEP_KAPPA_C_OUTPUT H1:CAL-CS_TDEP_F_C_OUTPUT H1:CAL-CS_TDEP_KAPPA_PU_REAL_OUTPUT H1:CAL-CS_TDEP_KAPPA_PU_IMAG_OUTPUT H1:CAL-CS_TDEP_KAPPA_TST_REAL_OUTPUT H1:CAL-CS_TDEP_KAPPA_TST_IMAG_OUTPUT H1:IMC-PWR_IN_OUTPUT
WP6232 Upgrade frame writers
Jonathan, Jim B, Dave:
h1fw2 was running with close to the new code, it was upgraded to add the md5 filename change only. Quickly following h1fw0 and h1fw1 were upgraded to the latest code. I am updating the DAQ MEDM to show the new diagnostic md5 check sum data.
WP6217 ISI frontend code upgrade
Hugh, Jim B
All ISI models were restarted with new code
WP6227 HEPI frontend code upgrade
Hugh, Jim B
All HEPI models were restarted with new code.
WP6235 PSL-DBB jitter feed-forward to LSC
Daniel, Gabrielle, Dave:
New code on the h1psldbb exports the jitter signal as a 64kHz Dolphin channel. The h1lsc model uses this feed-forward data. Change added a 16kHz LSC DQ channel to the commissioning frame.
WP6242 Migration of virtual machines to proxmox
Carlos
Old vmware virtual hosts were migrated to the new Proxmox system.
WP6236 SUS ITMX.ETMX model changes for HWWD install
Fil, Richard, Jim B, Dave
sister wp to 6234. The ITMX and ETMX hardware watchdogs were install. The h1susitmx, h1susetmx models were modified to read the HWWD status via the binary input feed from these chassis. Since we are not controlling these units, I did not put in the binary output logic.
WP6229 h1tcscs model change for SIM parts
Kiwamu, Dave
A new h1tcscs model was installed. We verified that the TCS CO2 chillers behaved correctly on loss of temperature control voltage.
WP6231 GDS-DMT upgrade
team-GDS
Code was upgraded, no impact was seen from the control room
WP6239 PSL-ISS model change
Daniel, Dave
New h1psliss model was installed. This was done at the same time as the h1psldbb change.
WP6240 Beckhoff Slow Controls change
Daniel, Dave
Daniel installed new PLC code. I updated the DAQ INI files, the target autoBurt.req files and the Beckhoff SDF monitor files.
WP6238 CAL-CS model change
Darkhan, Jeff K, Dave
a new h1calcs model was installed.
DAQ restarts
Dave:
The DAQ was restarted several times today to support the above work.
(note we did not get to removing h1ldasgw2 WP#6237, will defer this to later in the week)
Regarding the following:
WP6217 ISI frontend code upgrade
Hugh, Jim B
All ISI models were restarted with new code
Only the HAM ISIs models were updated. I might have implied to DaveB that I was going to do something to the BSC ISIs but in the end I do no changes there.
LP_v_H4 shows the laser output power and the head 4 flow rate. At this point in time the flow rate trip 0.2 lpm. The drop in laser power seems to coincide with the increase in flow rate. XC_v_H4 shows the output of the crystal chiller and the head 4 flow rate. The chiller clearly switches off after the spike in the head 4 flow rate. InletP_v_H4 shows the inlet pressure versus head 4 flow rate. The oscillations in pressure take place after the spike in the flow rate. The same is true for the outlet pressure. The sudden increase in the flow rate perhaps suggests that something in the flow sensor may have been dislodged but I (PK) would expect that the flow rate would not drop to zero but to some other non-zero value. Unless there was a following object that promptly jammed things up. But things started up okay for the subsequent startup. The various filters in the system are clean from a visual inspection. Jason/Peter
The trip Peter discusses above took place at around 6:17am PDT on Sunday, 10/9/2016.
The laser did trip off on Saturday (first reported by Patrick here) at 21:06:02 PDT (04:06:02 UTC, Sunday 10/9/2016). As noted by Kiwamu the reason for the trip was due to a trip of the Laser Head 1-4 Flow interlock.
PSL_Heads_Flow_2016-10-8.png shows the 4 laser head flow sensors around the time of the trip; head 4 is once again the most likely culprit. As seen in the plots posted above by Peter for the early Sunday morning trip, head 4 sees a spike in flow rate before falling off to zero. Interestingly, when compared to the actual interlock (PSL_Head4_v_HeadIL_2016-10-8.png) the interlock trips just prior to the spike in flow rate; from the plot it can be seen that the interlock starts to trip just before the spike in head 4 flow begins. The trip threshold at this time was set to 0.2 lpm, which none of the flow sensors were below at the time the interlock tripped; I can't explain why the interlock tripped.
PSL_Head4_v_XChil_2016-10-8.png shows the crystal chiller turning off several seconds after the interlock trips (5 seconds after in this case). I've noted this before (here).
PSL_Head4_v_InletP_2016-10-8.png shows the head 4 flow rate versus the inlet pressure in the PSL water manifold. The oscillation in the pressure occurs after the interlock tripped and has been seen before (noted above by Peter and here).
details in alog 30410
Update as of 23:05UTC (16:05PT)
State of H1: in Initial Alignment
Activities:
Attached are plots of the cooling related signals from around the time of the laser trip on ~midday Sunday. The minimum head flow rate was set to be 0.5 lpm as a precaution because the front end and power meter circuit flow meters were disabled. From the XChilFlow_v_Head4 plot it looks like the flow rate in head 4 was down on its way beyond 0.5 lpm and then the crystal chiller shutdown, as it was supposed. The plots {In,Out}letPressure_v_Head4Flow show the pressures in the water manifold at the same time. The pressure oscillations occur as the chiller was shutting down and not before it. XChil_v_H4, {In,Out}P_v_H4 are plots for the Sunday afternoon laser trip. Again consistent with the flow rate in head 4 dipping below the trip threshold.
Removed check valve from CP4 exhaust and installed a thermocouple up inside the pipe several feet. Signal is being read out via H0:VAC-MY_CP4_TE252B_DISCHARGE_TEMP_DEGC. Tomorrow I'll overfill CP4 and collect temp data.
Kiwamu Daniel
With ISS PD A mounted in the main path we measured the spectrum of the second loop ISS. The attached plot shows a clear improvement in the signal sent to the inner loop ISS. The red curve is a representation of the new control signal, whereas the dark red curve is representing the old configuration. The second loop out-of-loop sensor also sees improvements (black against gray) between 600 Hz and 4 kHz. The jitter out of the HPO is unchanged. The measurements were done at 54W into the IMC.
WP 6234
FRS 4504
Installed D1300642 HWWD electronics for ITMX and ETMX. Units installed in monitor-only mode.
1. Units were powered up
2. DB37 cables connected
3. DB9 cable connected from HWWD chassis to binary input chassis
4. Three BNC cables were pulled to SEI ISI coil drivers
ISI coil drivers need to be replaced with modified units that will enable the HWWD electronics to power off the coil drivers.
Serial numbers of units installed.
ITMX - S1500333
EX - S1301706
Peter, Kiwamu,
We have taken out the PD A photodiode out of the ISS inner loop box and placed it at a location where the PWR_EOM photodiode was. We confirmed that we can close the loop with the moved PD A.
[New setup]
We opened up the inner loop box and removed the base plate on which the two photodiodes sat. Then we took out only PD A from the base plate while leaving PD B mounted on the base plate. We put the base plate back into the inner loop box. A black glass beam dump was placed at the location where PD A used to be. Careful: because we could not find a good screw hole, we could not clamp down the black glass beam dump which is currently just sitting on the base plate.
We placed PD A to the location where PWR EOM (Thoralbs PDA55) had been. We rerouted all the associated cables for PD A (a 5 pin lemo, 2 normal lemos) to the new location. We measured the beam power at this location to be 8 mW. Because this is too much for PD A (which we think typically runs with 1 mW), we installed an ND filter on the front panel of PD A (see the picture).
A few more pictures are available at ResourceSpace.
[ISS loop closed with PD A]
Here shows a screenshot of the setup for closing the inner loop with PD A. The gain slider needed to be a 12 dB higher (which still smells like a factor of two calibration error...) than the usual. The ref signal for PD A needed to be -0.46.
Here are some plots of the open loop transfer function with PD A used as the in-loop sensor. A gain of more than 20-30 dB in the gain slider actually does not do the job -- needs more investigation. The ugf is about 46 kHz with the gain slider set to 30 dB. Note that when PD B was in use, the ugf had been 54 kHz (29942).
Intend to confirm that CP3 isn't overfilling following today's delivery via observing absence of vapor at exhaust at some point before leaving today (It's similar to a sentence - only without all of the unnecessary comprehension!)
I lowered it again to 17% because the last length of the exhaust pipe was frosty and LN2 was trickling out. (this is Chandra, not Bubba)
State of H1: in Maintenance, 18 Work Permits in progress / done
Activities: (Corey 8:00-10:38(15:00-17:38UTC))
As of 18:00UTC (11:00PT) Work in progress: (Cheryl)
Activities Since (UTC):
Work that continues:
as of 22:18:
J. Betzwieser, D. Barker, D. Tuyenbayev,
Overview
Updated the h1calcs model to include modifications from LLO, restarted the DAQ system (LHO WP #6238). Now H1 and L1 are running the same version of the CAL-CS model.
Details
CTRL_DELAY
filter bank was added to the DELTAL_CTRL
signal path, before the summation with DELTAL_RESIDUAL
(see LLO alog 28268).BUFFER_AND_AVERAGE.c
, currently using version of the script in CDS SVN r14393 (see LHO alog 30293).After the DAQ restart the coherence calculation settings were changed to:
Number of averages: H1:CAL-CS_TDEP_COH_BUFFER_SIZE 13
Seconds between averages: H1:CAL-CS_TDEP_COH_STRIDE 10
The new CTRL_DELAYfilter is currently empty (unused), and the DELAY_CYCLES (ring buffer / integer delay cycles) is set to 7.
The synchronized oscillators in the CAL-CS time-dependent parameter and coherence calculations were restarted manually. This is a necessary step to get correct phases in the oscillators after a model restart (a bug is described in LHO alog 30220).
ECR E1600042 WP 6217; ECR E1500325 WP 6227
To Remove DACKILL elements from HAM ISIs and HEPIs:
HAM ISI
.) Removed DACKILL Widgets on WD Block--Attachment 1.
.) Removed DACKILL link from WD Block to the ERRMON Block--Attachment 2.
.) Routed WD_STATE from WD Block to ERRMON--Attachment 2.
.) Added WD_STATE Logic in ERRMON Block for Rogue Excitation Evaluation--Attachment 3.
HEPI
.) Removed DACKILL elements from HEPI (Top) Level--Attachment 4.
.) Removed DACKILL parts on WD Block--like ISI Attachment 1.
To update HEPIs to Bleedoff-Accumulated-Saturations feature running on ISIs for months:
.) Add WINDOWTIME inputs on HEPI WD Block--Attachment 5.
.) Removed Test Point pickoffs WD Flag channels--also on Attachment 5.
.) Replace model saturation counter on WD/IPS, L4C & ACT Blocks with WD_SATCOUNT_vb.c counter & bleedoff Function--Attachment 6 becomes Attachment 7, e.g.
JimB restarted all these models after the build and install. Reisolation was not a problem. HAM2 did have one trip on CPS during 1st isolation attempt but it worked fine on the 2nd...
SVN COMMITS:
/opt/rtcds/userapps/release/isi/common/models/
hugh.radkins@opsws1:models 0$ svn commit -m "Removed DACKILL remenants & wired WD_STATE to ERRMON"
Sending models/isihammaster.mdl
Transmitting file data .
Committed revision 14424.
/opt/rtcds/userapps/release/hpi/common/models
hugh.radkins@opsws1:models 0$ svn commit -m "Added sensor/actuator WD Saturation Bleedoff ala ISI & removed Test Point WD Flag channels"
Sending models/hepitemplate.mdl
Transmitting file data .
Committed revision 14425.
Still have some medm and SDF cleanup to do. In progress.
Yes I do know how to spell remnants!
I've edited the HEPI and ISI Watchdog medms getting rid of the DACKILL widgets that do not connect to anything now. Also added the IOP DACKILL to the HEPI screen which were absent. Also removed is the RESET ALL button as all it did was push the DACKILL and the RSET buttons. Only 1 WD reset button remains, RESET WD. CLEAR SATURATIONS ONLY button is on the ISIs, pretty self explanitory there. On the HEPIs, I elected to not add the Clear Saturations Only infrastructure as the RESET WD button will do the trick anyway and won't harm the platform if it is not tripped. The RESETs for the IOPDACKILL and the Rogue Exc WD on the ISIs still need to be done in addition to the RESET WD, if, the medms suggest (red) they need it. There is no Rogue Excitation Watchdog on the HEPIs.
I will commit these medms to the SVN when I confirm that LLO does not need the RESET ALL button.
I have updated the TCS corner station model (h1tcscs.mdl). I confirmed that the model comiples without an error. The model is ready for installation tomorrow. The model change includes the followings.
The first item is described in T1600451 in detail. The second point is something we newly implemented today in order to get rid of two paricular ezcaread blocks which had been referencing channels that are in the same front end model. To improve this self-referencing situation, we modified TCS_MASTER.mdl so that the TCS block returns the CO2 power as an output. See the attached screenshot for how we routing the CO2 powers to the SIM block.
This is now installed. See 30429. The filters for the new channels were set by running the code attached to T1600451-v2. The SDF is also updated.