Vertex pump down is not trending down (just one turbo is pumping since X&Y beam manifolds are vented. Attached is plot over 10 days.
The big jump from last Friday was a result of closing GV2 to vent XBM. It could be that both GV2 gate o-rings are leaking. It looks like at least one is (see earlier log entry about trying to pump gate annulus with AIP). We have experienced dual gate o-ring leaks (GV12). Will know more when we pump down XBM - maybe tomorrow.
So have had a continuous exponential spectra of the WHAM6 CPS signals running on the desktop watching for the grounding or whatever-it-is noise on the Corner3 sensors. The attached snap shows this new noise. The reference and the thicker traces are the corner3 signals, which look fine. The other four fine traces are the corners 1 & 2 signals. This isn't even the worse of it but it looks very similar to the corner3 noise seen previously while messing with the cabling there the last few days. Note that the corner3 channels are in one satellite crate and corners 1 & 3 are in the other. I'm suspicious activity around the chamber has disturbed the ground of that crate and made it iffy.
I went back to about 1pm yesterday (1900 utc 28 March) and watched the spectra until it went noisy like this. First time I spotted was 0130 pdt this morning. Will check with EE to see if they know of anything.
This noise has come and gone since starting and wouldn't bee too worried about it if it was associated always with activity near by the satellite crate but as it started in the wee hours...
Haven't been staring at this all day but haven't seen this noise pop up again all day. Haven't looked at crate or talked with EE. Will comment tomorrow.
Got a typo in the main (can't edit anymore): "...the corner3 channels are in one satellite crate and corners 1 & 3 are in the other." should be corners 1 & 2 are in the other.
Sorry for confusion. Still haven't made it out to the box to inspect but I haven't noticed any problem with the spectra either since ~9am yesterday.
I tried to open the GV2 gate annulus valve to pump out that volume while valve is hard closed (so we don't have to hook up a pump cart later), but it won't recover with annulus valve open. It's acting like there is an o-ring leak. Valve is closed an AIP current is a little higher now.
TITLE: 03/29 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
Wind: 7mph Gusts, 5mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.13 μm/s
QUICK SUMMARY:
NOTE: Operator Meeting at 3pm!
(So no operator coverage at 3pm PDT [22:00utc]).
Sheila, Georgia, Dan, Alexei, Nutsinee, TVo
We found it odd yesterday that we needed to move PRM ~100urad in pitch and ~50urad in yaw to get PRX fringes from Feb 8th. Sheila walked back PR2 a bit to get PRM back to where we were and this centered the beam onto the refl camera, which is good. At this point we should have seen the beam on AS_C in HAM6 because everything seemed to be the same, however, Georgia noticed the witness sensors on SR3 M3 were much different than Feb 8 even though the alignment sliders were the same, this was due to an alignment dither offset on M1 that was still on. Once this was turned off, we got a beam on AS_C.
Then we proceeded to HAM6 and were able to find a leakage beam on the squeezer side hitting ZM2, however, it seemed low in pitch coming out of HAM5 and not possible to coalign with the current Squeezer optics. This was not correctable with ZM2 (railed) alone so we're in a tough position here to see *maybe* correcting the squeezer beam without jeopardizing the IFO to OMC alignment. Sheila felt it was worth trying to nail down how much we can actually change the SR optics before clipping on the OFI, so we set out to try to find an edge of the OFI aperture by slowly moving SR3 in pitch while compensating with SR2:
SR3 Pit Alignment slider | SR2 Pit Alignment slider | |
-60 | 4000 | |
+1100 | -3557 |
This means that SR2 has the full range of pitch before we start falling off AS_C while compensating with SR3.
Now, If we then center on nominal with SR3, then the SR2 range is
SR3 Pit Alignment | SR2 Pit Max | SR2 Pit Min |
520 | 487 | 212 |
Based off our data, tomorrow, we'll go into chamber and see if it's possible to correct the ifo to squeezer alignment without clipping on the OFI.
J. Kissel More details to come after I'm able to measure H1SUSOPO again, but as a result of LLO converting to the standard SUS basis (LLO aLOG 38272). and remeasuring their OPOS TFs (LLO aLOG 38308), I've made a comparison between LLO** and LHO's data again and thinks look far more consistent. I've also updated the dynamical model after the (yet to be documented) work Alvaro and I have done during the LVC meeting. In summary, we added several more elements to the stiffness matrix that explain the cross-coupling visible in a lot of the degrees of freedom. (**Note, the confusion Stuart mentions regarding scale factors was that he didn't remove the special calibration conversion that accounted for the modified HAM-A driver, and the bad units in PRY lever arm basis change when processing the data with /ligo/svncommon/SusSVN/sus/trunk/OPOS/Common/MatlabTools/plotOPOS_dtttfs_M1.m. I've fixed and commited the script removing the special LLO case, and now both observatories are calibrated with the same scale factor. I've also re-processed and committed the LLO data.) Check out the new results attached. The notable differences are in the DOFs that I've not been able to close damping loops: T and Y. T appears to somehow have a sign flip from LLO and expected. Remember we're now using exactly the same basis change matrices. The only difference in the digital system is the magnet compensation signs in the COILOUTF banks, which we believe are correctly compensating the as-built configurations. But, this is to be investigated further. For Y, it looks like the phase at high frequency is asymptoting to a different value. No idea what's going on there. However, because the results from other DOFs are so similar, I copied over the damping loop design from LLO aLOG 38309, and tried things out. L, V, R, and P are just as successful as LLO. Nice! Now to still figure out what's going on with T and Y... I've started the investigation by taking (loops open) T and Y TFs with the L V P and R loops closed, hoping that it might clean things up a bit. The Qs look quite different from the 2018-03-16 measurements, but I ran out of time to investigate further. More tomorrow...
Dan:
late entry from yesterday's maintenance. Dan upgraded the firmware on the two controller cards for E18-1 (written to by h1fw1). Unlike the E18-0 upgrade, this time everything worked as advertised and both CDS writer and the LDAS readers continues to function during the staggered upgrade.
I have restarted the Beckhoff SDF system for c1plc[2,3] following recent changes to these systems. New channels were accepted and monitored. Note that the DAQ has not been restarted for the new channels.
Took several steps backwards today, although it did start off promising. I re-aligned the output of the front end laser and got ~90 W output power with a nicer beam. Spent time optimising the alignment into the pre-modecleaner. The mode matching was still pretty poor. Then the bad news, the diode currents on the PSL Computer were not those on the datasheet. After setting the diode currents and temperatures to the datasheet values, the output of the amplifier was ~84 W. However the output beam did not appear as good. The mode matching into the pre-modecleaner was less than 50%. The beam propagation was re-measured. Ed / Peter
All fours fibers have been welded and annealed. We ended up with a PUM-to-ETM differential pitch of ~3mRad. We'll attempt to reduce this with a further round of annealing tomorrow.
Various photos from today's welding efforts. Photo file names double as captions.
ResourceSpace collection to be populated - Note that I am working through some issues uploading to ResourceSpace.
See ResourceSpace for all photos from the effort, plus a few neat videos of welding, annealing, and loading the fibers of ETMx.
Until ResourceSpace gets up and running, I have added the welding/annealing/loading videos to this Box folder (should be accessible with access.caltech login) https://caltech.app.box.com/folder/48265585793
M&M finished wrapping the entire bake enclosure with Al foil and taping the seams. Bottom air temp has reached a new high of 95C (20C less than top air temp). This morning they swapped CP4's GN2 regen heater with CP3's - if we can resurrect that system we may have a chance to bring the entire enclosure up to uniform temperature. I raised the set point of bake enclosure to 130C (from 115C).
Turbo pump back end measures 55C with 35C cooling water.
Bottom air temp is now at 103C! However, we still have a significant delta - top temps are at 134C. Hope to test regen heater system today.
I have cleaned up the ISC guardian code (ISC_LOCK, ISC_DRMI, OMC_LOCK, ALIGN_IFO, ALS_XARM, ALS_YARM, ALS_COMM, ALS_DIFF, ISC_GEN_STATES, ISC_library and lscparams).
My goals were to remove depricated code (it's been growing since ~2014, and many functions clearly haven't been used since about then), merge nearly-identical functions (we don't need 15 different functions to determine if a cavity is locked), ensure that functions from sub-files (eg. ISC_library) are clearly called out (by removing all "from _______ import *", which Sheila had already done a lot of work toward), and make the code generally easier to read.
I was going to do a bit more syntax checking, but since we have IR light into the vacuum earlier than had been anticipated and several people have been working on locking the IMC, I deployed the new code this afternoon. All guardians were checked in before I did anything, and then I copied over my files from a side folder into the main userapps guardian folders.
So far, the IMC guardian is able to lock the IMC (after a few boost changes from Sheila, TVo, DanielBrown and Alexei...they'll write a separate alog). The ALIGN_IFO guardian is able to change the SUS configurations, although it hasn't been tested farther than that, since PeterK is working on the PSL.
This cleanup has removed ~4,000 lines of unnecessary guardian user code. I think it'll help make things easier as we go forward with a new commissioning phase.
Jeff Kissel loves this.
Stephen A., Chandra R.
This morning Stephen helped/instructed me on assembly of the first LHO chevron baffle. Baffle SN 001 was installed in nipple housing SN 001. We iterated several times on bending the louvers to securely set them in place and ended with an N2 "top gun" blow off before bolting the two baffle halves together and fastening to the nipple housing. The eight bolts that secure the baffle to the housing still need to be torqued. We placed the two 16.5" Cu gaskets on knife edges and wrapped with Al foil for temporary storage in VPW until we can install on IP11 at EY later this week. Stephen will post pictures later.
Refer to LLO aLOG for more detail on steps of installation. https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=38375
Assembly procedure is E1800067 (still needs updates based on lessons learned in assembly work at LLO and LHO). One key feature of this assembly effort - we only had 2 people, so we took the following approach to placing the D1600409 louver cell within the D1600410 nipple:
This assembly that we built is on ICS as ASSY-D1600431-001
I have attached photos of various stages - see below descriptions:
Evan G., Jeff K. We moved a compensation zero out of the ESD output filter bank for each quadrant that had generated an uncompensated 5.2 kHz pole in the DARM loop (see LHO aLOG 33927). This resulted in an effective delay of ~20 usec. There is adequate roll off already from a low pass filter in the ESD driver, so moving this out of the DARM loop will be minimally impactful. Instead, the compensation zero will be a compensation pole in the CAL-CS path and doesn't result in an additional 5.2 kHz zero being added to the Foton filter. We leave the filter in place and turned on, but the design string is now simply zpk([], [], 1, "n") The new filter is installed in CS_DARM_ANALOG_ETMY_L3, FM5: zpk([], [3245.33075], 1, "n") (this comes from the mean of the summing node poles, see 27619) Removing this from the DARM path means that we need to include these as an uncompensated poles in the DARM model and reduce the unknown actuation delay by 20 usec. This will bring the unknown actuation delay down to ~40 usec.
Associated with FRS Ticket 7351.
SudarshanK, RickS
To study the downconversion of Pcal excitation we used a DB9 breakout at the back of the Pcal chassis and routed the excitation channel through H1:CAL-PCALX_WS_PD for now. This will be returned to its original configuration once the investigation is complete.
The PcalX is still fully functional and hardware injection can be carried out if needed. The WS_PD channel through which the excitation channel is routed is a spare channel that is only used during the end-station PD calibration.
Summary:
We have established that most of these down converted lines (the one that hurts us) reported in alog 36959 arise from the aliasing of the harmonics of the injected high frequency calibration lines. The lines that have the possibility to show up in the DARM are the ones that lie between 10 Hz to few hundred Hz. We can avoid these lines by selecting the high frequency calibration lines such that the aliased lines are not in the given low frequency region.
Details:
We ran into issues with low frequency lines (in 100 Hz range) showing up in DARM when we were running high frequency calibration lines in the region of 5.5 - 6 kHz. This was first noticed in this LHO alog 36959 and LLO alog 34346. To understand this problem we wanted to find where these lines were being produced, photon calibrator itself or the data acquisition system. We disconnected the cable that inputs the excitation to the Pcal electronics and used a DB9 breakout box to acquire the excitation signal so that we were getting these signal before it enters the Pcal system. We rerouted this signal through the H1:CAL-PCALX_WS_PD channel which was one of the unused Pcal channel.
The first plot shows the spectrum with a 5036 Hz excitation line (in blue) and without an excitation (in red). Some of the extra lines seen in the blue spectra are the result of aliasing of the higher order harmonics of the injected as well as the imaged lines (imaging happens when going from 16khz to 64 kHz). In this particular case the 68 Hz line is the aliasing of the 13th order harmonic of 5036 Hz injected line. The second plot shows the predicted aliased lines (based on harmonics and upsampling) that would be produced for 5036 Hz injected line. Some of the predicted lines show up in the actual spectrum but not all and not all line that are present in the spectra are predicted. However, the lines that show up above few hundred Hz will be well below the DARM signal as the actuation transfer function goes as 1/f^2. Shivaraj, at LLO has taken some additional measurement to see if we can find the source of all the aliased lines. Report to follow.
Tagging DetChar and CDS on this, so that the CW group can follow up with them to understand how to flag the data for this known issue.
RickS, SudarshanK,
The breakout box used to acquire the analog excitation signal on X-end Pcal has been removed and the Pcal configuration is now back to normal. During the visit, Rick repeated some measurement that reproduced the 86 Hz line when a Pcal line was injected at 5950 Hz with an excitation amplitude of 25000 cts. This measurement was made at the DAC (analog) output using SR785. The 86 Hz line is about 70dB below the injected line. This still does not explain why we don't see 86 Hz line in analog output in the measurement (LLO alog 34495) that Shivaraj made using Agilent signal analyzer. :(
On Jeff's request, I am putting down the empirical formula that predicts the lowest frequency down-converted lines for each high frequency excitation.
DCF = 2^16 - EF * n, where DCF is the down converted frequency, EF is the excitation frequency and n is the harmonic number. For frequencies around 4-6 kHz, the harmonic number that produces the line in the bucket are between 11 and 13.
I don't have a physical intuition on why this happens. If we were looking at the resampled 16 kHz signals, the presence of these lines would not be surprising because these would be produced because of aliasing but we see these low frequency lines on the DAC output, measured using the analog spectrum analyzer. Plots showing the same are attached.
A new line at 86 Hz has appeared in the DARM channels after the vent. After running BruCo, I've seen that that frequency was coherent with some PCAL channels: https://ldas-jobs.ligo-wa.caltech.edu/~pep.covas/bruco/1181560000/ I attach two different plots showing the differences between before/after the vent for the DARM channels and for three different PCALX channels . The "before" data is from 07/05/2017 09:00 UTC, and the "after" data is from 15/06/2017 09:00 UTC.
I compared the de-whitened calibrated x-end Pcal TX PD channel (applying the appropriate [;1,1] filtering) with the de-whitened CAL-DELTAL_EXTERNAL just to check that the height is about right. Indeed, this does appear about right (see attached image). When H1 drops out of lock, we will perform some quick tests to see if we can determine what is wrong.
Pep C., Evan G. We localized the time to when this line turned on, at 00:24 May 31 2017 UTC (see attached). Now we investigate what changed at that time.
Evan, the frequency of the high-frequency calibration line we are running from X-end changed at this same time (plot attached). With large amplitudes of lines we are running, due to non-linear effects, they tend to produce many other lines in the spectra. It is possible that this is due to the current line (5950 Hz) we are running. We can definitely test this by changing the frequency and see if 86 Hz goes away (the line features strongly depends on what HF line we are running).
Thanks for pointing this out, Shivaraj. It's quite weird how this is appearing, perhaps beating against other harmonics of the calibration lines?
Evan G., Joe B., Jeff K. Joe B. pointed out that there is an uncompensated ~5.215 kHz pole in the ESD output filter bank because our filter design zpk([3229.1150], [], -1, "n") results in Foton providing a pole to compensate the zero at high frequency. So the actual installed filter is zpk([3229.115],[5215.189175235227],0.9999999999999999,"n"). The ~3.229 kHz zero compensates for a pole in the analog electronics. Unfortunately, the ~5.215 kHz pole is uncompensated. Attached is a Matlab figure showing the effects from 1 Hz to 10 kHz. The band of most interest to us is <200 Hz since above 200 Hz the actuation is sufficiently rolled off that it does not contribute to the response of the interferometer. Below 200 Hz, there is very small residual magnitude error. Phase, however, is incorrect by ~1.1 degrees at 100 Hz. The equivalent delay is ~30 usec. This could explain part of the unknown actuation delay, which--for LHO--is 61 usec.
Exporting the transfer function from Foton for zpk([], [5215.189175235227], 1, "n"), we obtain a slightly different functional form than Matlab due to IIR warping near the Nyquist. Instead of 30 usec delay that approximates the phase error, a delay of 20 usec fits the Foton version more precisely. Since this effect is already absorbed into the unknown actuation delay, and any changes would require regenerating GDS and DCS filters, so we will leave this as-is. In the future, we could account for the ~3.229 kHz zero in CAL-CS model and need to be accounted for in DCS.
Associated with FRS Ticket 7351.