Jonathan, Tony, Erik,
As per WP 13402 the h1daq*1 systems where updated today. We removed the Dolphin PX cards from the systems, installed the new ethernet cards.
In the prep stages the GDS broadcast was moved to the 0 leg and h1daqfw2 was changed to pull data from the 0 leg.
Notable changes:
* h1daqgds1 -> is now the the data concentrator + broadcaster. It is named h1daqdc1. This is the machine that receives the front end data.
* h1daqdc1 -> is now h1daqkc1 (h1daq kafka connector) for use with the ngdd project.
We found one issue where the daqd could not write jobs into the nds servers job queue folder. This was a permissions issue. Not sure why this popped up as a problem now. I updated the puppet config specifically avoid this happening again.
WP 13417
The MSR Safety System Chassis D1600176 was modified. The EL6900 terminal was replaced with an EL6910. Internal connections were made for the Bypass input and Bypass LED in the control room.
The EtherCAT safety modules EP1908 for IOT1R, ISCT1, and IOT2L were mounted over HAM2. The same was done for the safety modules (EP1908 and EP1957) for TCSX, CHETA_Y&X, and HWS. They are mounted on top of TCS-R1.
Two E-Stop buttons were mounted down the X&Y arms for CHETA.
Software upgrades are ongoing. The system will be left offline. System will need to be fully tested before bringing lasers back online.
We are still on scroll pumps for the corner station, so the pumpdown was paused for the night and the pumps valved out. Pressure in the corner is ~0.5 Torr. We should be able to get on turbo tomorrow.
HAM1 pumpdown was started today after sorting some gauge issues. Pressure is 6e-2 Torr at COB. This will also go onto turbo tomorrow.
TITLE: 07/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
IFO is in IDLE for MAINTENANCE
Very productive day. Here's what happened:
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:34 | VAC | Travis | LVEA | N | Resume pumpdown | 16:20 |
| 15:44 | FAC | Christina | Recieving | N | Forklifting some palettes | 18:43 |
| 15:46 | EE | Fil | LVEA | N | Working on adding JAC , SPI, and Cheta to LASER interlock | 00:31 |
| 15:50 | CDS | Jonathan | Remote | N | NDS & FrameWriter restarts | 20:12 |
| 15:53 | PEM | Ryan C | LVEA | N | Restarting Dust monitors | 16:07 |
| 16:00 | PSL | Ryan S, Jason | LVEA | Local | PSL Chiller Swap | 17:00 |
| 16:18 | FAC | Christina | Ends, Mids | N | Supply photos | 17:41 |
| 16:19 | FAC | Tyler | LVEA, Ends | N | Getting parts | 16:19 |
| 16:20 | SUS | Ryan C, Rahul | LVEA | N | HAM7 work | 18:19 |
| 16:29 | PEM | Shrey, Miranda, Carlos | LVEA | N | Seismometer work\\ | 17:28 |
| 17:22 | EPO | Mike (+ tour) | LVEA | ~ | Tours | 17:53 |
| 17:52 | SEI | Jim | LVEA | N | Unlocking HEPI | 18:05 |
| 18:14 | SEI | Jim | LVEA | N | Unlocking BSCs HEPI | 20:04 |
| 18:27 | PEM | Shrey, Carlos, Miranda | LVEA | N | 18:27 | |
| 18:33 | SUS | RyanC | CR | N | ZM5 intial health check TF | 18:59 |
| 19:13 | FAC | Randy, Erik | LVEA | N | West Bay scissor lift craning to High Bay | 19:55 |
| 20:05 | PEM | Carlos, Shrey, Miranda | LVEA | N | Seismometer checks | 21:49 |
| 20:05 | VAC | Travis | LVEA | N | Checking on pumps | 23:12 |
| 20:10 | CDS | Dave | CER | N | Turning off AI chassis | 20:22 |
| 20:16 | SUS | Ryan C | LVEA | N | HAM7 Work PSAMs Cable | 20:17 |
| 20:26 | SUS | Rahul | LVEA | N | HAM7 Work | 21:17 |
| 21:51 | TCS | Madi | Optics lab | N | Measuring Focal length of optics with eye safe laser. | 23:51 |
| 21:51 | Safety | Richard | LVEA | N | Helping Fil | 22:10 |
| 23:26 | FAC | Richard | LVEA | N | Checking on Fil | 00:26 |
Roger's Machinery installed the Enmet Matrix Air monitoring system on the purge air skid today. The air is sampled after the drying towers. The system is intended to monitor the air and alarm if breathable air conditions are not met.
Inventory of DRMI locking data in 87768. By eye (someone overwrote the data in the MICH xml since it was taken), the MICH UGF is roughly 15 Hz when we achieve DRMI 1f lock.
I used the BSFM model in /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/TripleModel_Production (bsfmopt_metal) to generate a model of the MICH loop using the MICH control filters and BSFM locking filters. I applied a fudge factor to generate a loop with a 15 Hz UGF, which I then used to estimate the m/ct calibration required to generate a BBSS model, assuming we have the same optical gain when locking with the new beamsplitter. (suspension calibration table is G1100968). This model indicates that the MICH L M1/M2 crossover is 30 mHz, which agrees with the data in the table in Evan Hall's thesis, Table 2.4 page 33. See first attachment for BSFM model
Then, I generated a BBSS model in the same triple model directory using bbssopt. I applied the same beamsplitter locking filters and MICH control.
Overall, it shows us that if we use the same feedback design with M1/M2 control, we should end up with a MICH loop that is almost the same as the one we have now in DRMI 1f lock- 15 Hz UGF, 30 mHz crossover between M1 and M2. See second attachment for BBSS model
It also seems to me that it should be fairly straightforward to move the MICH length control from M2 to M3, although we will likely need to adjust the locking filters to achieve the same crossover frequency. See third attachment of the comparison of each stage sus transfer function to M3.
I have not been able to generate a model of the oplev damping that looks reasonable, so I will poke around the alog to see if I can figure out what the design is supposed to be.
Executive summary: we should have no problem locking DRMI with the current MICH and BS control scheme, and it shouldn't take that much effort to move BS feedback from M2 to M3 if we so choose.
R Crouch, R Kumar
SUS ZM5 has been re-installed in HAM7 chamber after replacing the faulty bottom mass PSAMS unit with a spare one sent by CIT.
The bottom wires were replaced and the entire was chain was re-balanced after suspending all stages. The PSAMS cable (with mighty mouse connector) was carefully laced around the cage and clamped at strategic position (so that it doesn't short with the cage). We then took a health check and the suspension looks healthy - see transfer function results in attachment01 and attachement02 (we see some slight shift in frequencies, especially P dof - however they can be easily damped with the current filters we have in place).
Attached below are many pictures showing ZM5 in chamber after the repair work was complete and suspension re-installed.
We also took pictures for reference after installing the wires and balancing it after suspending all stages - outside the chamber on the table.
Details of our repair work are listed in this checklist attached below.
We re-tested (see picture01 and picture02) the strain gauge readout for the PSAMS units after installing it in ZM5 and then placing it in HAM7 chamber, connected to the electronics chain of ZM5. Given below are the test results,
| Voltage Calibrator Setting (Voltage) | PZT (Voltage) | Strain Gauge (Voltage) |
| +10 | 0.384 | 2.780 |
| +9 | 103.5 | 2.966 |
| +8 | 20.33 | 3.179 |
| +7 | 30.30 | 3.408 |
| +6 | 40.28 | 3.658 |
| +5 | 50.25 | 3.910 |
| +4 | 60.23 | 4.177 |
| +3 | 70.2 | 4.453 |
| +2 | 80.1 | 4.744 |
| +1 | 90.1 | 5.090 |
| 0 | 100.1 | 5.350 |
| -1 | 110.1 | 5.660 |
| -2 | 120.0 | 5.965 |
| -3 | 130.0 | 6.275 |
| -4 | 140.0 | 6.591 |
| -5 | 150 | 6.900 |
| -6 | 159.9 | 7.210 |
| -7 | 169.8 | 7.530 |
| -8 | 179.8 | 7.850 |
| -9 | 189.8 | 8.170 |
| -10 | 194.0 | 8.320 |
Ibrahim, Ryan S, EJ, Erik, Jonathan, Dave:
We chose to fix h1susb2h34's 20bit-DAC issue with the boot parameter pci=pci_bus_safe rather than a BIOS MPS=128 change. We did however make the BIOS change to Enable PERR/SERR support.
1. Control room put BS, MC2, SR2, PR2 into safe. I bypassed the seismic SWWD for BSC2, HAM3,4
2. I powered down the AI chassis which is driven by the two 20bit-DACs. It is in rack SUS-C1 U24. From front, left side is DAC0, right side is DAC1.
3. I verified the IOP shows both 20bit-DACs in AI-WD mode. I turned on DAC-DUOTONE and verified no readback on ADC0-30 (safe to do so now the AI is powered down)
4. EJ configured h1vmboot5-5 to boot h1susb2h34 with pci=pcie_bus_safe and disabled the auto-start of the models.
5. We stopped the models, fenced from Dolphin and rebooted.
6. EJ caught the reboot, went into BIOS, Enabled PERR/SERR Support and reset.
7. After the reboot, we verified the Adnaco cards had MPS=128B and the Dolphin IX had MPS=256B.
8. We started the models. I enabled DAC-DUOTONE (AI still off) and now DAC0-7 is driving correctly.
9. EJ ran his DAC-FIFO-Check, both 20bit-DACs checked out.
10. We started the local_dc and cps_xmit to get DAQ data moving again.
11. I powered the AI chassis on. Unbypassed SWWD and handed system over to the control room.
We will leave this system in no-auto-start state from now until the upgrade at the end of this month.
Instructions to start the DAQ data after models have been started (as root):
mbuf_probe list # Check models are writing
systemctl start rts-local_dc
mbu_probe list # Check local_dc shows as last item
systemctl start rts-transport@cps_xmit
I've unlocked HEPI on BSCs 1-2-3. I haven't had a chance to look at the loop design for BSC2 yet, but B1&3 are both able to fully isolate. HEPI runs on all three chambers. Almost back to normal running.
J. Oberling, R. Short
With the PSL down for safety interlock work, Ryan and I have completed the annual PSL chiller swap. There were no issues with the swap, the backup chiller started right up and has been running for over 1 hour now. We let it run at a higher flow rate (~4.7 lpm) to push any accumulated air out of the line, and then returned it to our operating flow rate of ~2.8 lpm. While the system was down we also changed the system filter; there was some slight yellowing to the filter, but other than that it looked pretty good for being installed for ~15 months. We updated the chiller operating hours in the PSL control software to match the new chiller, 17004.0 hours at time of update. We will continue to monitor the chiller over the course of the day.
The SN of the now in-service PSL chiller is 119247. This closes LHO WP 13413.
Jennie found that HAM3 ISI loops wouldn't turn on. This morning I have been looking at why the loops are unstable. I'm pretty sure that the locked HEPI on that chamber is creating a notch in the ISI plant at 15 hz, where the loop gains and phase margin are both pretty low. The easiest way to fix this would be to unlock HEPI, but I don't think vac is ready for that. I could also tweak the boost filter to get some phase margin back, but that will reduce the loop gain below 10hz. I think that's probably the best choice at this point.
Attached plot shows some open loop gain measurements I've done for this chamber. Red trace is the unboosted loop, the cursor is at 15 hz, which is where HAM3 was ringing up when Jennie tried to turn the ISI on. This notch is not visible in the green trace, which is the unboosted loop gain with HEPI unlocked.
The boost filter is a pair of poles at .2hz and normally a pair of zeros at 9 hz. I've moved the zeros down to 7hz, which has substantially increased the phase margin shown in the attach plot. Red is the current, modified loop. I will test if this is stable. The other vertical loops don't seem to be affected by this.
Things were still kind of ringing even with the modified loop gain, so I asked Travis if he was done climbing around HAM3. He said the only thing was an annulus pump that could be accessed from the cover on the pier, so I've unlocked HEPI on HAM3. The ISI is much happier now. I haven't tried reverting the filter change yet, I will wait for a bit before changing anything, in case HAM3 HEPI needs locked and we need to try to run the ISI.
Started on WP13402. The 1 leg of the daqd system is down for upgrade. The control room workstations and FOM displays were pushed to using the h1daq0 nds last night.
Ryan And I drove to EX and TJ drove to EY.
Ryan and I turned off the HEPI VFD power supply then turned it Back on.
Then hit the reset button.
The Pump then Whirled back to life !!!
Then H1:HPI-PUMP_EX_PRESS_HIGH Flashed Bright red for less than a second and the Interlock turned red and and the Whirling sound died.
Welp that didn't work.
We then ensured the setpoint: H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_INPUT was set to 70.
Tried it again with H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_MODE set to manual. But we ramped H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_OUTPUT_TWEAK_REQ too fast(?) and H1:HPI-PUMP_EX_DIFF_PRESS_PSI went too high and the interlock tripped again.
...
Then we tried a bunch of attempts to manually increase H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_OUTPUT to the value [2.29 V] that holds H1:HPI-PUMP_EX_DIFF_PRESS_PSI at 70 and Every time it would shoot well past 70 and trip the interlock again.
We then opened up the control loop screen and noticed this integral term was set to 6. Which perhaps was too high.
So we hit the reset button.... H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_ITERM_RESET_REQ....
Thankfully that reset the Integral Term down to 0.....
We then tried again to turn it all back on manually, and keep the H1:HPI-PUMP_EX_DIFF_PRESS_PSI at 70 PSI. Once H1:HPI-PUMP_EX_DIFF_PRESS_PSI was stable at 70 PSI we then switched over to auto. Now this Tanks the Output voltage that we just set to 2.29 ..... all the way down to 0.0...... ok...... then back up..... ok..... then over shoots to the moon, Again Tripping the interlock and shutting it down..... again.
We tried using different H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_OUTPUT_TWEAK_SIZEs and otherwise tried to baby poor lil HEPI back into it's setpoints.... and it just wanted to FULL Send to the MOON!.
Then I had a weird thought... what if we set it too high? Will it go to 0? Will it go to negative Moon?! IDK but I wanted to find out.
Really what I truly wanted was for H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_ITERM to simply go to the 2.28 value that allows H1:HPI-PUMP_EX_RMT_PRESS_PUMP_CTRL_OUTPUT to be 2.28 Volts which keeps the Diff pressure H1:HPI-PUMP_EX_DIFF_PRESS_PSI @ 70 PSI. But for some reason I cannot change that value Integral Value at all. Or atleast I couldn't directly....
So this is what I did:
I set the output voltage a bit High.... such that the Differential pressure was just a lil too high. This is to convice the control loop to go down instead of Up.
I then reset the Integral Term so it starts at zero when we switch it from manual mode to auto mode.
Then I hit auto.... the Output voltage drops to 0 and comes back up.... but.... this time I'm ready! ..... I'm waiting to switch it back to Manual mode Right AFTER the output votage PASSES the output voltage that I want . This has now set both the Differential pressure, Output voltage, AND the Integral Value ABOVE my desired destination. I let it settle a little high. THEN I clicked Auto again, which finally allowed the control loop to stablize at 70 PSI.
We were on the phone with TJ at EY and that worked for EY as well.
Then we watched it for a bit and drove back to the corner station.
Shoutout to Ryan S. and TJ for showing me the ropes and pointing things out that that helped me jump to my conclusions.
TLDR: The Control loop overshoots when approaching from below. Approach it from above. It works for both End stations. ¯\_(ツ)_/¯
I find it best to ramp it by slowly increasing the setpoint from 0 to 70 in auto mode: Set it to manual. Tweak the output slowly to 0. Set the setpoint to 0. Clear the integral term if there is one. Set it to auto. Slowly ramp the setpoint up to 70.
[Sheila, Camilla, Ryan, Eric]
We would like to verify that our recent mode measurements after ZM5 ( 90783) and before ZM4 (90815 ) make sense by connecting the two. We decided to use the q value from the measurement at the nominal ZM2 strain in 90815 (ZM2 strain = 3.15V) and propagate that mode through the path containing ZM4 and ZM5 and calculate the overlap with the q values from 90783 measured at different strain settings for ZM4/ZM5. The goals here are as follows:
First, I address item 1.
Mode Measurements with M2 > 1:
Our system seems to be adding some higher order abberations to the beam. As a result, our mode measurements indicate that we have an M^2 number significantly above 1 (between 1.2 - 1.5 depending on the PSAM settings). When M^2 is > 1, the presence of HOM content in the beam prevents one from focusing down to as tight of a waist, for the same divergence angle, the beam radius at the waist will be larger by a factor of M. The thorlabs beam profiler accounts for this by fitting the data to the following formula (which we confirmed by doing our own independent fit):
w(z)2 = wM2[1 +(z - z0)2 (pi*wM2/(M2*lambda))2]
Where wM2 = M2*w02 Is the waist for a beam with M2>1, and w0 is the waist for the TEM00 component of the beam (ie for M2 = 1).
The q parameter ends up the same as before:
q(z) = (z-z0) + i*zR
where zR = pi*w02/lambda = pi*wM2/(lambda* M2)
Knowing that M2 > 1 tells us that our beam is a mixture of TEM00 and some higher order mode content. However, from the M2 value alone we don't know which higher order modes are excited (in principle one might be able to make some rough projections using the surface abberation measurements of the PSAMs from Caltech, but that sounds tricky and is beyond the scope of today's post). If we want to do mode matching calculations, the only thing we can do at the moment is back propagate the TEM00 component and do all mode calculations for TEM00.
We use the same beam propagation matricies as always to back propagate the TEM00 component to determine what the TEM00 mode looks like in HAM 7.
Determination of the ZM4 and ZM5 ROCs
I then took the q value (for the nominal ZM2 = 3.15V) from the measurement before ZM4, back propagated it to ZM4 using our length measurements. I then propagated the q through ZM4 and ZM5 and calculated the overlap with the q values measured after ZM5 for various values of the ZM4/ZM5 strain gauge settings in ( 90783)
Then, the ROCs for ZM4 and ZM5 were chosen for each strain gauge settings to maximize the overlap. The overlap is => 98% over the entire 2D grid of ZM4/ZM5 strain gauge values, which gives us some confidence that the ROC values are accurate. One thing that gives us pause is that the change in ROC for ZM5 doesn't appear to change linearly in diopters with the strain gauge reading. ZM4, on the other hand is roughly consistant with a 5 mD/V change though because the beam spot is quite small on ZM4, we are relatively insensitive to its ROC value.
| ZM4 Strain (V) | ZM4 ROC (m) |
|---|---|
| 2.0 | -12 |
| 4.0 | -11 |
| 6.0 | -10 |
| 8.0 | -9 |
| ZM5 Strain(V) | ZM5 ROC (m) |
|---|---|
| -4.5 | 3.8 |
| -2.0 | 4.05 |
| 0.0 | 4.4 |
| 2.0 | 4.55 |
These values give the following overlaps for the x and y direction (our mode measurements indicate we have non-negligible asitgmatism on this path) for propagating the nominal q value from (90815 where ZM2 strain = 3.15) to the q vales from ( 90783) .
| ZM4 \ ZM5 | -4.5 | -2.0 | 0.0 | 2.0 |
|---|---|---|---|---|
| 2.0 | x = .994, y = .995 | x = .998, y = .997 | x = .990, y = .995 | x = .9874, y = .993 |
| 4.0 | x =.996, y = .997 | x = .994, y = .995 | x = .986, y = .992 | x = .983, y = .991 |
| 6.0 | x =.995, y = .997 | x =.992, y = .993 | x =.983, y = .989 | x =.980, y = .984 |
| 8.0 | x =.993, y = .995 | x =.990, y = .992 | x =.980, y = .984 | x =.977, y = .980 |
The fact that this set of ROC values gives good overlap over the entire 2D grid suggests that these ROCs are a resonable model for ZM4 and ZM5 at these strain gauge settings.
Attached is an a la mode file for doing the beam propagation. One could do some more intellegent fitting of the data to extract the best ROC estimates; I'm just sorta hand fitting it at the moment.
We have ZM5 SN4 installed now. Original data before we changed the preloading (E2100297) had the ROC range 3.0m to 3.9m. With at 0V applied 667mD optical power, with 200V applied 508mD.
In alog 75709 we increased the preload from 20 in lb to 47 in lbs. An estimated linear increase of 65mD as according to T2300426, changing the preloading changes the optical power by 2.4mD/in.lb.The preloading should make the magnitude of the optical power larger, so it should be increased to 667mD - 2.4mD/in lb * 27 in lbs = 602mD mD with 0 V on the PZT, 443mD with 200V on the PZT. This is an estimated ROC range of 3.3 to 4.5 meters for strain gauge -5.0 to +2.6V (it's range with 0V and 200V applied). This mostly agrees with Eric's data.
We have ZM4 SN1 installed now. Original data before we changed the preloading (E2100289) had the ROC range -19.3m to -9.0m. With at 0V applied -104mD optical power, with 200V applied -221mD.
In alog 75677 we increased the preload from 46 in lb to 75 in lb. An estimated linear increase of 70mD. This should be increased to -104mD - 2.4mD/in lb * 29 in lbs = -174mD mD with 0 V on the PZT, -291mD with 200V on the PZT. This is an estimated ROC range of -11.5 to -6.9 meters for strain gauge 1.0 to 8.3V. This mostly agrees with Eric's data.
I attempted to confirm these values by repeating this exercise with a second dataset from 90827. This was an additional set of q measurements made directly after ZM4. The idea here is that this should allow us to fit the ROC values for ZM5 only by taking these measured qs, propagating them through ZM 5 and comparing with the measurements from 90783. Unfortunately this did not proceed as smoothly. The fits and mode overlap values are tabulated below. This isn't too far from the old ROC range, but the agreement between the q values isn't nearly as good as before
Rough values for ZM5:
| ZM5 Strain (V) | ZM5 ROC (m) |
|---|---|
| -4.5 | 4.0 |
| -2 | 4.3 |
| 0 | 4.7 |
| 2 | 4.9 |
Mode overlap after propagating through ZM5 assuming the above ROC values. I was mostly optimizing the y value; the astigmatism seemed to be quite different in this dataset, leading to poor x/y agreement when propagating and comparing with the other data.
| ZM4 \ ZM5 | -4.5 | -2 | 0 | 2 |
|---|---|---|---|---|
| 2 | x = .975, y = .996 | x = .976, y = .990 | x = .954, y = .986 | x = .948, y = .982 |
| 4 | x = .981, y = .994 | x = .971, y = .986 | x = .956, y = .982 |
x = .947, y = .981 |
| 6 | x = .974, y = .992 | x = .969, y = .990 | x = .946, y = .977 | x = .937, y = .971 |
| 8 | x = .969, y = .990 | x = .955, y = .980 | x = .940, y = .970 | x = .930, y = .963 |
Attached is a Sw plot at SRM made using the ROCs Eric logged above, and the measured q at the input of ZM4.
The measurements seem to be systematically different from the prediction based on ROC and the input q. I reproduced the overlaps that Eric listed above, and they are similarly above 98% for all of these (the overlap between the prediction and the measurement for each strain guage pair).
I also made a linear estimate of the diopters per strain guage based on the ROCs that Eric listed above, for ZM4 this give -7mD/ strain guage volt (for -11m ROC at 4V SG), for ZM5 -10.5mD/ SG V (for 4.05m ROC with SG at -2V). This is shown by the orange stars and blue + in the attached plot, there is some discrepancy with the red and brown "predicted" points (based on just the ROCs that Eric listed above and the input q), because of the nonlinearity of Eric's ZM5 ROCs.
Continuing from Camilla's accounting of where we want the ZM4 preload to be.
Eric's ROC values above show the range to be from -12m ROC to -9meters (this is not quite the full range but close to it), which is -170mD to -220 mD, so the range of ZM4 psams seems to be close to 50mD. In Camille's original charachterization data before the preload change E2100289 the range was 118mD.
If we make a decision on where we want to move ZM4 based on the OMC matching grid in the attachment to 90804, we would gues that we'd want the lower edge of the ZM4 range to be in the middle of the range. This means we want to reduce the pre-load by 25mD, reducing the pre-load by 10 in lbs, to 65 in lbs.
Above, Eric found ROCs for each strain guage value that can predict our measured q's after ZM5 (90783) starting with the measured q before ZM4, where the predicted qs overlapped with the measured qs by more than 98%. We are aiming for sqz to OMC mode matching of better than 99%, so I wondered if we can get better agreement than this with our measurement technique. If we want to be able to set ROCs or distances based on these measurements, we want to know if they are repeatable and consistent with a model at a level better than the mode matching that we are trying to acheive. In O4 we had squeezer to OMC mode mismatch of 2.2%, we would like that to be less than 1%.
I take the q's measured after ZM5, propagate them back to before zm4 using the guesses for ROCs and the AOIs from the finesse .yml file, and calculates the overlap with the measured q before ZM4 for each. The sum off the mode mismatches is the cost function used to fit either vertical or horizontal ROCs. In this version of the script, it is fitting either the vertical or horizontal data, I would like in the future to have it include both in the cost function.
These plots (horizontal and vertical) show that this fitting results in overlap between the measured beam and the forward propagated beam using the fit ROCs is better that 99.5% for all the data. This is true when I use only the horizontal (vertical) data in the fit, and use those ROCs to propagate the vertical (horiztonal) mode. The worst overlaps are all for points measured where ZM5 strain guage was at -4.5V, which also had the worst values of M^2 (see top left panel).
Using these fit ROCs and the measured q before ZM4, we can propagate to the usual Sw plot on the AR side of SRM, using either vertical or horizontal data gives us an sw plot that looks a lot closer to the measured data than the guesses above. I think this means that we can use this kind of fit data to determine what ROC we need to move us to a particular place in Sw space in the future, at least at the level of 0.5% mode matching.
| ZM4 (strain guage voltage) | 2 | 4 | 6 | 8 |
| ROC fit with vertical data[m] | -8.687 | -7.699 | -6.923 | -6.280 |
| ROC fit with horiztonal data [m] | -7.621 | -6.886 | -6.313 | -5.798 |
| ZM5 (strain guage voltage) | -4.5 | -2 | 0 | 2 |
| ROC fit with vertical data [m] | 3.600 | 3.889 | 4.266 | 4.351 |
| ROC fit with horizontal data [m] | 3.544 | 3.852 | 4.190 | 4.273 |
The script to make these fots and plots can be found here
I've been talking to Jeff about changes to the ISI and seiproc models for SPI and CRS integration. The ISI models are pretty much done, but today I added a parts to seiproc to take HAM2345 cps and gs13 cart channels and blend them to create cartesian differential supersensor channels. The idea being these will be good metrics for determing if SPI is actually improving the differential ISI motion. Plan is to use blend filters to combine the cps and gs13 pairs from each chamber to make supersensor channels, and then compare the differential supersensors for HAM2-3 to the differential supersensors at HAM45. I've checked that seiproc builds with these changes, but I now have some changes to make to the HAM45 models and some ipcs to make. And then a whole bunch of medm work.
Erik had to attach my screen shot, because firefox is not cooperating in the control room for me, but it shows a snippet of the flow in the ISI_DIFF block in seiproc and the channels I think Jeff wants to save. We didn't talk about data rate, so that's just a guess.
Adding png
I made a medm screen for these super sensor comparisons. Its under the SPI menu on sitemap as 'ISI DIFF'.
I haven't got the layout pretty or the displays working for the resultant differential supersensor filter banks. WIP...
Committed the custom adls to the userapps svn.
To help with load testing, h1daqfw2 was moved to reading data from dc1, and kc1 is pulling data from dc1 even though it is not publishing data yet (only kc0 does at this point).