Output has been at 100& for days now so this won't impact anything. If situation were different, i.e. were weren't already at 100% output but still ramping up, then this "bug" could have resulted in an over temperature condition. The program is behaving as if the "HOLD" condition is a function of run time based on 1C / hour expected rate of rise and time needed to get to SETPOINT value from measured temperature recorded at start of profile. If so, then this is a novice programmer mistake. The program should switch to the HOLD segment upon reaching the SETPOINT value as a function of the measured temperature irregardless of time so as to always be limited to the 1C / hour maximum rate of rise.
Following on from the driven electric field meter (EFM) measurements presented in alog lho-40878, I've made a rough conversion of the EFM noise floor into meters of DARM. It looks like the EFM might just be sensitive enough to see fields which could contribute to DARM. This calibration is very dodgey and is really just an order-of-magnitude (or 3) estimate. Based on the the transfer function from volts-of-ESD-shield-drive to meters-in-DARM, in alog llo-28675 (strongly dependent on which test mass was looked at), the EFM noise floor lies somewhere between the red and purple traces in the first plot.
How I made this plot:
First I fit our measured electric field strength vs volts of ESD shield drive measurement, to get a conversion from Vshield to electric field strength [V/m] (second plot, data read off the plots in Jeff's previous log post)
I fit Anamaria's transfer functions for mDARM per Vshield as shown in llo-28675. I just did a linear fit and extrapolated it to 500Hz, since their measurements only go to 200Hz.
I converted this transfer function into mDARM per electric field [V/m], using the fit in step 1 (shown in the third plot)
Finally I took the EFM noise floor, and multiplied it by the transfer function (x 5 since we drove all 5 shields where LLO only drove 1) to get the EFM noise floor in mDARM (plot 1).
EFM measurements will continue at EX in the future, we still need to look at the frequency-dependence of the ESD shield electric field, and take measurements where we drive the ESD signal/bias, ISI horizontal actuators, and anything else in-chamber that might generate electric fields.
Estimates I made a while ago when deciding that the smaller electric field meter was not adequate are the sensitivity of the meter had to be 5 e -5 Volts/meter/sqrt(Hz) at 100 Hz to intersect the ambient field noise in the chamber. This required that the test mass had acquired a charge of about 3 e -9 coulombs.
I noticed that the displayed value in the TC1 field was "#..." or absent a numeric value this morning at 0110 hrs. during a random check. I monitored for 10 minutes and noted displayed values as TC1="#..." TC2=85.5 TC4=83.0 %(can't determine due to pixel resolution) TC1="#..." TC2=85.8 TC4=83.2 %(can't determine due to pixel resolution) TC1="#..." TC2=85.7 TC4=83.1 %(can't determine due to pixel resolution) TC1="#..." TC2=85.6 TC4=85.2 %(can't determine due to pixel resolution) TC1=99.9 TC2=85.5 TC4=85.5 %71 TC1="#..." TC2=85.9 TC4=83.3 %76 Thus, displayed value of TC1 is alternating between gibberish and valid values.
Tagging VE.
It appears it doesn't like to read out three whole #s.
This is a late report about the work done in HAM6 on Thursday. Basically we have aligned things in HAM6, so that we should be able to work on locking the OPO for now.
In the morning Nico, TJ and Terry pulled off the viewport simulator, and Gerardo and TJ removed the septum window protector so that we could attempt to inject a beam into HAM5.
TJ and Terry recentered the osems on ZM1, which seems to have improved the performance of the damping loops (TJ is planning to remeasure the damping loops, but our experience in chamber was that it was not swinging around as badly once this was done).
We reentered the green rejected beam on the DCPD and its reflection onto the black glass dump, which was lost when TJ and Daniel fixed the short in the diode.
We also added the black glass clip to the last steering mirror before ZM1. This means that we should be finished making adjustments that might change the balancing of the OPO suspension.
Nutsinee and I borrowed the Thorlabs PZT driver from the optics lab so that we can scan the OPO PZTs more quickly which makes alignment into the OPO much easier. Nutsinee had installed a thorlabs PDA100A into the homodyne path so that we could look at the OPO transmitted power. We found that we were not well enough aligned through the apertures on HAM6 so that the flashes we saw on SQZT6 would sometimes be clipped on one of the apperature as the OPO suspension and ZM1 were swinging. Once we had the beam better aligned through the apertures, we can see the cavity scan for 1064 fairly well.
We decided that it wasn't worth trying to inject this beam into HAM5 and look for it returning to HAM6, since the power was so low it is hard to see the beam while scanning.
We had a hard time finding the green transmitted beam from the OPO, but with help we were able to turn off the cleanroom +LVEA lights. This allowed us to find the beam and align onto the green TRANS PD. With the OPO suspension locked we were able to align the green into the OPO decently. We then unlocked the OPO suspension.
Three purge air systems operating normal.
Corner pressures trended over six days.
Nutsinee Terry Daniel
Today we tried to lock the OPO in green. First, we swapped the busted 1801 with a BBPD and realigned it. The RF signal is quite large and we ended up installing a 20dB attenuator in the green EOM modulation path. As expected the green transmitted power is tiny, about 70nA when locked with ~1.3mW. We suffered from red contamination until we turned the seed off. We probably need a second dichroic beamsplitter in this path.
We first tried to lock the laser to the OPO, but soon realized that this won't work with 1MHz of VCO range. We switched to the OPO PZT and were able to keep it "locked" near resonance within about the full width. What remains looks like a ~1kHz feature that we can't suppress, since at higher gain setting we see an instability around 5kHz. The dip in reflection seems to be about ~0.7.
J. Oberling, E. Merilh, P. King, R. Savage
Today we confirmed our initial measurements of the FE beam propagation. Ed and I took a couple of extra data points closer to the FE (attached as LHO_FE_Caustic_no_lens.txt, the setup can be seen in the 1st attached picture; WP02 and PBS02 had to be removed to accommodate the beam profiler) in order to more tightly constrain the divergence angle. This was done because fits done yesterday by myself and Peter were producing different results, and indication of a possible problem with the measurement. I used a Matlab script provided by Rick to fit this data to a Gaussian beam; Peter did the same using a gnuplot script he developed. The 2 separate methods produced the same result: beam waist radius of 202 µm, positioned 162mm inside of the FE box. Using JamMT to model mode matching solutions, one stood out as giving good overlap and also not giving us an intermediate focus between the lenses (which can cause problems). This is attached in the 2nd picture as 70W_MM_Solution1-FE_caustic_no_lens.png; included is the setup for the mode matching model, with the chosen solution #9 highlighted, and the list of lenses used (all LINOS lenses we have readily on hand). The focal lengths given are the lens focal lengths at 1064nm, taken directly from the LINOS product page.
While working all this out, we noticed something in the layout that we didn't like. As currently laid out, any change in the beam alignment to the 70W amplifier also causes a change in alignment through the Faraday isolator (AMP_FI). This can have an effect on the isolation provided by AMP_FI, which can in turn present a danger to the FE should a beam get back-reflected and not be properly isolated by AMP_FI (can cause crystal damage to the FE MOPA, or if we're really unlucky could amplify that back-reflection and damage down-stream components in the FE); there are also personnel safety issues to consider should a slightly off-axis beam make it back through the FE MOPA while someone is working inside the FE box. To fix this, we removed the little zig-zag made by mirrors M33, M08, and M34. M33 was moved 6 hole patterns further down the table (thereby giving more room for mode matching solutions as well), while mirrors M08 and M34 will serve to direct the beam onto AMP_M01 and then into the 70W amp. AMP_FI will now reside between mirrors M33 and M08, while mirrors M34 and AMP_M01 will be the alignment mirrors for the 70W amplifier; now aligning the beam through the amplifier will not change the beam alignment through AMP_FI (before and after pictures are attached). Ed and I placed the 70W amp in its location on the table (per the layout) and finished the change with mirrors M33, M08, and M34; there is still some alignment work to do with these mirrors.
On Monday we will install and align the mode matching lenses from the attached solution and align the beam through its new path to M34. We will then set up the beam profiler at the waist location given to us by NeoLASE and optimize the mode matching lens alignment to get the proper beam size for the 70W amplifier.
Edit to add: As a precaution, we installed the 80W air cooled beam dump after mirror M33. The FE laser is ON, with watchdogs active.
State of H1:
Activity Detail:
Today, Betsy and I embarked on the final First Contact cleaning of the new ETMy. We started by taking a charge measurement with a handheld electrometer (although we didn't hold it in our hand, we used a mount specifically made for it mounted to the AERM side of the Quad lower structure). Since the new AERM has a hole in the middle, we had questions about where to mount the electrometer. We attempted to contact Calum from the end station, but ran into the usual working-at-the-end-station issues i.e. no GC WiFi to use WiFi calling from cell phones, no cell signal, and we were unable to locate TeamSpeak on the workstation. Using the landline phone in these situations is often impractical since we are usually fully garbed in which case you are supposed to stay in cleanrooms and the phone is located on the other side of the beamtube. After driving back to the corner station, we learned that the workstation does have TeamSpeak installed, but needed to be accessed via command line and there was no microphone/speaker anyways.
We then measured the charge in 5 locations (center, upper right, upper left, lower right, lower left) and found that all 5 locations were ~10 volts. We'll remeasure these after First Contact removal/TopGun blowoff. We then sprayed/painted on the First Contact layer onto the HR surface of the ETM. We'll let the paint dry and continue with chamber closeout activities on Monday.
I set the TCSX QPD dark offsets earlier today, but not TCSY QPDs offsets, and on both TCSX and TCSY QPD A and B sums I put an offset of 3 to keep the sum above zero, normal sums are around 10K counts.
In support of the CP4 bake-out, I've created a temporary Rate-Of-Change (ROC) medm and linked it as the last item on the VE pull-down on the SITEMAP. It is calculating the ROC for a CP3 thermocouple, which is actually located at CP4. When the 1-HOUR measurement exceeds 1.0degC/hour in either direction, the gray rectangle turns RED, indicating a cell phone alarm has been issued.
Note, ROC also calculates the LN2 consumption rate of EY-CP7-Dewar as a test channel (consumption is about 1% dewar capacity per day).
I have a script check_guardian_nodes_against_medm_screen which reports: nodes which exist but are not on MEDM screen, nodes which are on MEDM screen which do not exist. It produced one report: CS_BRS on the overview but does not exist. I have removed this node from the MEDM file.
Note: INJ_TRANS is white on the overview, Jamie is working on restarting this node.
The INJ_TRANS node can not be started, for unknown reasons. However, the h1guardian0 host is apparently suffering from some sort of NFS lockup having to do with the injection machine, which presumably explains what we're seeing. Dave is on the case. Once this issue is resolved, the INJ_TRANS node should be able to be restarted with the following commands:
$ guardctrl create INJ_TRANS
$ guardctrl start INJ_TRANS
The CP4 enclosure temperature ramp is slowing down and the heater has been running at 100% for the last day. I've been increasing the temp of the GN2 flowing into CP4 so it's not a heat sink. I'm also trying to increase flow by increasing head pressure of Dewar (valve is wide open).
Heaters controls still buggy. Heater ran at 100% all night with no significant increase in air temp. When I visited mid-Y this morning, I found it holding at temperature (setpoint 120C, actual air temps in 90s), so I rebooted the system. Heater now running at 34% and temps recovering (TC#1 reads 81C). New setpoint is 130C with 10C overlimit.
GN2 temp holding steady at 125C. No change yet in head pressure of Dewar after yesterday's change to economizer valve. Flow fluctuates between 30-40 scfhx100.
Bubba turned chiller off to allow VEA to warm up. ![]()
By request from Chandra, I have shut the chiller down at Mid-Y to see if that helps maintain temperature on the bake out. I will continue to monitor the space temps.
CP4 LN2 consumption is high ~5.4%/day. Three day trend attached, comparing CP4 to CP5. We have a truck delivery scheduled for Tuesday.
Current temps (degC):
TC1: 92.9
TC2: 80.6
TC3: 59.6
TC4: 78.4
GV11 air: 85
Heater output: 41%
GN2 gas regen temp: 124
GN2 pipe temp into enclosure: 85.6
GN2 exhaust pipe temp out of enclosure: <75
RGA valve flange temp: 107
No change on the Dewar head pressure; still reads 12 psig at top and 10 psi next to pressure relief valve
GN2 flow ~ 40 scfhx100
Foreline pressure on turbo has increased from 2.4e-2 Torr to 3.2e-2 Torr since this morning
VEA is warm. Certain areas of enclosure insulation are warm, particularly where the velcro flap overlays the adjacent panel. In some cases the 4" thick panels don't butt up to each other so there are losses through the thin overlap.
I also witnessed this happen on Friday when the control sensor clearly hadn't reached the set point yet and program transitioned to hold at temp. Heater had been at 100% output overnight.
Temperature at GV11 in air for the past 3 days.