Another arm loss measurement started at 6pm.
There are still several data quality issues that can be improved. I think there is little point in reading too much into this until some of the problems outlined below are fixed and we get a better measurement.
As an interim fix, I'm going to try and use the Oplevs as a DC reference, and run the dither alignment from zero each time, as this prevents the runaway problem at least. Data run started at 11:20 pm.
Attachment #1 shows estimated systematic uncertainty contributions due to
In all the measurements so far, the ratio seems to be < 1, so this would seem to set a lower bound on the loss of ~35 ppm. The dominant source of systematic uncertainty is the 5% assumed fudge in the mode-matching
Bottom line: I think we need to have other measurements and simultaenously analyse the data to get a more precise estimate of the loss.
From the measurements I have, the Y arm loss is estimated to be 58 +/- 12 ppm. The quoted values are the median (50th percentile) and the distance to the 25th and 75th quantiles. This is significantly worse than the ~25 ppm number Johannes had determined. The data quality is questionable, so I would want to get some better data and run it through this machinery and see what number that yields. I'll try and systematically fix the ASS tomorrow and give it another shot.
Model and analysis framework:
Johannes and I have cleaned up the equations used for this calculation - while we may make more edits, the v1 of the document lives here. The crux of it is that we would like to measure the quantity , where is the power reflected from the resonant cavity (just the ITM). This quantity can then be used to back out the round-trip loss in the resonant cavity, with further model parameters which are:
If we ignore the 3rd for a start, we can calculate the "expected" value of as a function of the round-trip loss, for some assumed uncertainties on the above-mentioned model parameters. This is shown in the top plot in Attachment #1, and while this was generated using emcee, is consistent with the first order uncertainty propagation based result I posted in my previous elog on this subject. The actual samples of the model parameters used to generate these curves are shown in the bottom. What this is telling us is that even if we have no measurement uncertainty on , the systematic uncertainties are of the order of 5 ppm, for the assumed variation in model parameters.
The same machinery can be run backwards - assuming we have multiple measurements of , we then also have a sample variance, . The uncertainty on the sample variance estimator is also known, and serves to quantify the prior distribution on the parameter for our Monte-Carlo sampling. The parameter itself is required to quantify the likelihood of a given set of model parameters, given our measurement. For the measurements I did this week, my best estimate of . Plugging this in, and assuming uncorrelated gaussian uncertainties on the model parameters, I can back out the posterior distributions.
For convenience, I separate the parameters into two groups - (i) All the model parameters excluding the RT loss, and (ii) the RT loss. Attachment #2 and Attachment #3 show the priors (orange) and posteriors (black) of these quantities.
So that the experts on MC analysis can correct me wheere I'm wrong.
To complete the story before moving on to ALS, I decided to measure the X arm loss. It is estimated to be 20 +/- 5 ppm. This is surprising to say the least, so I'm skeptical - the camera image of the ETMX spot when locked almost certainly looks brighter than in Oct 2016, but I don't have numerical proof. But I don't see any obvious red flags in the data quality/analysis yet. If true, this suggests that the "cleaning" of the Yarm optics actually did more harm than good, and if that's true, we should attempt to identify where in the procedure the problem lies - was it in my usage of non-optical grade solvents?
The old IBM laptop (Asia) has died from a fan error after 7 years. WE have a new Lenovo 330 IdeaPad to replace it:
Install done. Touchpad not recognized by linux - lots of forum posts about kernel patching...Arrgh!
Chub, Koji and I have been talking about Udit's re-design. Here are a few points that were raised. Chub/Koji can add to/correct where necessary. Summary is that this needs considerable work before we can order the parts for a prototype and characterize it. I think the requirements may be stated as:
Some problems with Udit's design as it stands:
[Gautam/Chub/Koji] ~ Mini discussion
Maintenance / Upgrade Items
(Priority high to low)
had trouble using YUM to update. This turned out to be a config problem with our Martian router, not the new laptop. Since I've changed the WiFi pwd awhile ago for the martian access for the CDS laptops, you'll have to enter that in order to use the laptops.
turned out to be some Access Control nonsense inside of the router. Even loggin in as admin with a cable gave some of the fields the greyed out color (had to hover over the link and then type the URL directly in the browser window). ASIA is now able to connect and use YUM + usual connections. Gautam and I have also moved the router a little to get easier view of its LED lights and not blockk its WiFi signal with the cable tray. We'll get a little shelf so that we can mount it ~1 foot off of the wall.
still, this seems like a bad laptop choice: the Lenovo Ideapad 330 will not have its touchpad supported by SL7 without compiling a new version of the kernel
The precision of the measurement is excellent. We should move on to look for systematic errors.
According to Johannes and Gautam (see T1700117_ReflectionLoss .pdf in Attachment 1), the loss in the cavity mirror is obtained by measuring the light reflected from the cavity when it is locked and when it is misaligned. From these two measurements and by using the known transmissions of the cavity mirrors, the roundtrip loss is extracted.
I write a Python notebook (AnalyzeLossData.ipynb in Attachment 1) extracting the raw data from the measurement file (data20190216.hdf5 in Attachment 1) analyzing the statistics of the measurement and its PSD.
Attachment 2 shows the raw data.
Attachment 3 shows the histogram of the measurement. It can be seen that the distribution is very close to being Gaussian.
The loss in the cavity pre roundtrip is measured to be 73.7+/-0.2 parts per million. The error is only due to the deviation in the PD measurement. Considering the uncertainty of the transmissions of the cavity mirrors should give a much bigger error.
Attachment 4 shows noise PSD of the PD readings. It can be seen that the noise spectrum is quite constant and there would be no big improvement by chopping the signal.
The situation might be different when the measurement is taken from the cavity lock PD where the signal is much weaker.
I borrowed one Marconi (2023 B) from 40 m lab to QIL lab.
ZHL-3A (2 units) —-> QIL
Following instructions here, I installed ndscope on this machine. DTT still could not be be run from this machine, and I want to use this today - so I ran the following commands from the K. Thorne setup instructions.
yum clean metadata
yum install cds-workstation pcaspy subversion redhat-lsb gnuradio google-chrome-stable xorg-x11-drv-nvidia epel-release redhat-lsb
Now diaggui can be opened, and spectra can be made. I'm moving this laptop to its new home at EY.
So Cal Earthquake. All suspension watchdogs tripped.
Tried to recover the OSEM damping.
=> The watchdogs for all suspensions except for ITMX were restored. ITMX seems to be stuck. No further action by me for now.
We unstuck ETMX by shaking the stack. Most effective was to apply large periodic human sized force to the north STACIS mounts.
At first, we noticed that the face OSEMs showed nearly zero variation.
We tried unsticking it through the usual ways of putting large excitations through AWG into the pit/yaw/side DOFs. This produced only ~0.2 microns of motion as seen by the OSEMs.
After the stack shake, we used the IFO ALIGN sliders to get the oplev beam back on the QPD.
The ETMX sensor trends observed before and after the earthquake are attached.
** plots deleted; SOMEONE, tried to take raster images and turn them into PDF as if this would somehow satisfy our vetor graphics requirement. Boo. lpots must be actual vector graphics PDF
After this activity, the DC bias voltage required on ETMX to restore good X arm cavity alignment has changed by ~1.3 V. Assuming a full actuation range of 30 mrad for +/- 10 V, this implies that the pitch alignment of the stack has changed by ~2 mrad? Or maybe the suspension wires shifted in the standoff grooves by a small amount? This is ~x10 larger than the typical change imparted while working on the table, e.g. during a vent.
Main point is that this kind of range requirement should probably be factored in when thinking about the high-voltage coil driver actuation.
The list of the iscaux channels and pin assignments were posted to google drive.
The spreadsheet can be viewable by the link sent to the 40m ML. It was shared with foteee@gmail for full access.
Necessary electronics modification
1. D990694 whitening filter modification (4 modules)
This module shares the fast and slow channels on the top DIN96pin (P1) connector. Also, the whitening selector (done by an analog signal per channel) is assigned over 17pin of the P1 connector, resulting in the necessity of the second DSUB cable. By migrating the fast channels, we can swap the cable from the P1 to P2. Also, the whitening selectors are concentrated on the first Dsub. (See Attachment1 P1)
2. D040180 / D1500308 Common Mode Board
CM servo board itself doesn't need any modification. The CM board uses P1 and P2. So we need to manufacture a special connector for CM Board P2. (cf The adapter board for P1 T1800260). See also D1700058.
3. D990543A1 LSC Photodiode Interface
PD I/F board has the DC mon channels spread over the 16pin limit. P1 21A can be connected to 6A so that we can accommdate it in the first Dsub.
Also the board uses AD797s. This is not necessary. We can replace them to OP27s. I actually don't know what is happening to those bias control, temp mon, enable, and status. These features should be disables at the I/F and the PDs. (See Attachment2 P1)
I looked into the design of the P2 interface board. The main difficulty here is geometric - we have to somehow accommodate sufficient number of D-sub connectors in the tight space between the two P-type connectors.
I think the least painful option is to stick with Johannes' design for the P1 connector. For the CM board, the P2 connector only uses 6 pairs of conductors for signals. So we can use a D-15 connector instead of 2 D-37 connectors. Then we can change the PCB shape such that the P1 connector can be accommodated (see Attachment #1). The other alternative would be to have 2 P-type connectors and 3 D-subs on the same PCB, but then we have to be extra careful about the relative positioning of the P-type connectors (otherwise they wont fit onto the Eurocrate). So I opted to still have two separate PCBs.
I took a first pass at the design, the files may be found here. I just auto-routed the connections, this is just an electrical feedthrough so I don't think we need to be too concerned about the PCB trace routing? If this looks okay, we should send out the piece for fab ASAP.
I will work on putting together the EPICS server machine (SuperMicro) this afternoon.
It's nice and compact, and the cost of new 15-pin DSUB cables shouldn't be a factor here. What does the 15p cable connect to?
it will connect to a 15 pin breakout board in the Acromag chassis
I looked at the PSL/IOO racks to check for which boards, if any, require an additional P2 interface, so that we can try and design a generic one for the IMC/CM boards and whatever else may require it. While searching the elog, I saw that Koji and Johannes had already done this, see Koji's elog in this thread. Some remarks:
Conclusion: Only the IMC Servo and CM boards need their P2 connectors connected to Acromag.It would be helpful to remove the TTFSS Interface board and figure out what exactly the pin-mapping for the backplane connectors are, but I didn't do this today because there is a "High Voltage" line going to the Interface Board and I'm not actually sure of the signal chain for the FSS servo.
Along with the plan in ELOG 14744, the ISC PD interface and the whitening filter board have been modificed. The ISC PD I/Fs were restored to the crate and the cables were connected. The whitening filteres are still on the electronics bench for some more tests before being returned to the crate.
The updated schematics were uploaded as https://dcc.ligo.org/D1900318 and https://dcc.ligo.org/D1900319
- Modification of the ISC PD interface: Jumpers between DIN96 P1 and P2. Replace all AD797s with OP27. In fact only I/F #1 (the left most) had total 12 AD797 but the other units already had OP27s.
- Modification of the whitening filter: Jumpers between DIN96 P1 and P2.
The whitening filter modules have been restored to the crates. The SMA cables have been restored and fastened by a spanner. The ribbon cable to the antialiasing board was also connected. The backplane cables have not been moved from the upper DIN96 connector to the lower one.
Everything is expected to be good, but just keep eyes on the LSC signals as the boards were not quantitatvely tested yet. If you find something suspicious, report on the elog.
The boards arrived. I soldered on a DIN96 connector, and tested that the goemetry will work. It does . The only constraint is that the P2 interface board has to be installed before the P1 interface is installed. Next step is to confirm that the pin-mapping is correct. The pin mapping from the DIN96 connector to the DB15 was also verified.
*Maybe it isn't obvious from the picture, but there shouldn't be any space constraint even with the DB37/DB15 cables connected to the respective adapter boards.
One of the biggest challenges in LIGO is reducing the alignment control noise. If you haven't worked on it for at least a few years, it probably seems like a trivial problem. But all versions of LIGO since 2001 have been limited by ASC noise below ~50 Hz.
I think the 40m IMC is a good testbed for us to try a few approaches towards mitigating this noise in LIGO. The following is a list of steps to take to get there:
I think that steps 1-6 are well within our existing experience, but we should do it anyway so as to reduce the IMC beam motion at low frequencies, and also to reduce the 10-100 Hz frequency noise as seen by the rest of the interferometer.
Steps 7-8 are medium hard, but we can get some help from the CSWG in tackling it.
Step is pretty tough, but I would like to try it and also get some help from MLWG and CSWG to address it.
The VEA laptop asia was configured to be able to connect to too many WiFi networks - it was getting conflicted in its default position at the vertex and trying to hop between networks, for some reason trying to connect to networks that had poor signal strength. I deleted all options from the known networks except 40MARS. Now the network connection seems much more stable and reliable.
The PCB board of the adapter for DIN 96pin to DSUB37 conversion (single DSUB version) was delivered yesterday and I quickly soldered the connectors.
They are ready for use and stored in a JLCPCB cardboard box on a pile of acromag stuff. (Note that the lacel is written on the box with Sharpie)
I installed 6 of these in 1Y2. Three were for PD INTF #1-3, and I used three more for the AS110, REFL11, and REFL33 Demod board FEs, where the strain-reflief of the DC power cables to the Eurocrate was becoming a problem. So now there are only 4 units available as spares.
Once the strain-relieving of the Dsub cabling to 1Y3 is done, we can move ahead with testing. I'd like to put this to bed this week if possible.
For the investigation of the latch logic issue for the CARM CM board, I have made the LED logic checkers with DB breakout boards. They require the pull up voltage supply of +15V because the acromag digital out is a open corrector (well... open "source") output.
The logic from Pin1 to Pin16 of DB37 can be monitored. The DB15 connector is only for monitoring the latch enable logic.
What Gautam and I found with the logic outputs was that the latch logic works fine but occasionally we found that the top 2 bits and the bottom 4bit were processed independently.
Yehonathan, please center the EX seismometer.
The attached PDF shows the seismometer signals (I'm assuming that they're already calibrated into microns/s) during the lab tour for the art students on 11/1. The big spike which I've zoomed in on shows the time when we were in the control room and we all jumped up at the same time. There were approximately 15 students each with a mass of ~50-70 kg. I estimate that out landing times were all sync'd to within ~0.1 s.
I have re-centered the EX (and EY) seismometers. They are Guralp CMG40-T, and have no special centering procedure except cycling the power a few times. I turned off the power on their interface box, then waited 10s before turning it back on.
The fist atm shows the comparison using data from 8-9 PM Saturday night:
I check the seismometers in the last 14 hours (Attached). Seems like the coherenece is restored in the x direction.
We carried out a set of cavity ringdown measurements of the PMC. The 1/e decay time scale is found to be 35.2 +/- 2.4 (systematic) μs. The statistical error is negligible compared to the systematic error, which is taken as the maximum absolute deviation of any measurement from the average value.
To make the measurement, we injected the first order deflection beam of an 80 MHz AOM, then extinguished it quickly by cutting the voltage offset to the AOM driver provided by an RF function generator. A 100 MHz oscilloscope configured to trigger on the falling voltage offset was used to sample the cavity in transmission as sensed by a PDA55. We found the detector noise of the DC-coupled output of the 35.5 MHz REFL PD to be too high for a reflection-side measurement.
Further loss analysis is forthcoming.
As per Gautam's request, I list the changes that were made since he left:
1. The AOM driver was connected to a signal generator.
2. The first order beam from the AOM was coupled into the PMC while the zero-order beam is blocked. We might want to keep this configuration if the pointing stability is adequate.
3. c1psl got Burt restored to Dec 1st.
4. Megatron got updated.
Currently, c1susaux seems unresponsive and needs to be rebooted.
There was no light entering the IFO. I worked on a few things to bring the interferometer to a somewhat usable state. The goal is to get back to PRFPMI locking ASAP.
Problem: All fast models report a "0x4000" DC error. See Attachment #1.
Solution: I think this is a "known" issue that happened last new year too. The fix was to add a hard-coded 1 second offset to the daqd config files. However, incrementing/decreasing this offset by +/- 1 second did not fix the errors for me today. I'll reach out to JH for more troubleshooting tips.
Update 15 Jan 2020 830am: The problem is now fixed. See here.
Problem: c1susaux and c1auxey were unresponsive.
Solution: Keyed c1auxey. Rebooted c1susaux and as usual, manually started the eth0/eth1 subnets. The Acromag crate did not have to be power-cycled. ITMY got stuck in this process - I released it using the usual bias jiggling. Why did c1susaux fail? When did it fail? Was there some un-elogged cable jiggling in that part of the lab?
Problem: IMC autolocker and FSS slow processes aren't running on megatron after the upgrade.
Solution: Since no one bothered to do this, I setup systemd infrastructure for doing this on megatron. To run these, you do:
and to check their status, use:
The systemd setup is currently done in a naive way (using the bash executable to run a series of commands rather than using the systemd infrastructure itself to setup variables etc) but it works. I confirmed that the autolocker can re-acquire IMC lock, and that the FSS loop only runs when the IMC is locked. I also removed the obsolete messages printed to megatron's console (by editing /etc/motd) on ssh-login, advising the usage of initctl - the updated message reflects the above instructions.
In order to do the IMC locking, I changed the DC voltage to the AOM to +1V DC (it was +0.8 V DC). In this setting, the IMC refl level is ~3.6 V DC. When using the undiffracted AOM beam, we had more like +5.6 V DC (so now we have ~65% of the nominal level) from the IMC REFL PD when the IMC was unlocked. IIRC, the diffraction efficiency of the AOM should be somewhat better, at ~85%. Needs investigation, or better yet, let's just go back to the old configuration of using the undiffracted beam.
There was also an UN-ELOGGED change of the nominal value of the PMC servo gain to 12.8, and no transfer function measurement. There needs to be a proper characterization of this loop done to decide what the new nominal value should be.
I'm going to leave the PSL shutter open and let the IMC stay locked for stability investigations. Tomorrow, I'll check the single-arm locking and the ALS system.
Single arm locking using POX and POY has been restored. After running the dither alignment servos, the TRX/TRY levels are ~0.7. This is consistent with the IMC transmission being ~11000 counts with the AOM 1st order diffracted beam (c.f. 15000 counts with the undiffracted beam).
Tomorrow, I'll check the single-arm locking and the ALS system.
On February 5, 2020, the Dell engineering workstation located in the 40M lab, was replaced with a newer Engineering workstation, per a request from Koji . The new workstation should perform a good deal better over the older unit. It has more cores, more memory and a better video card. Since this unit is being used by the 40M group, the Comsol s/w pkg. was also installed on the unit.
During the computer swap, Koji had a problem with a print job and it was discovered the bottom tray of the HP5550 printer was broken. The broken tray was replaced from another unit that was being disposed of.
To supplement the material presented during the BHD review, I've put together a projected noise budget for the 40m. Note these are the expected interferometer noises (originating in the IFO itself), not BHD readout noises. The key parameters for each case are listed in the figure title. Also attached is a tarball (attachment 4) containing the ipython notebook, data files, and rolled-back version of pygwinc which were used to generate these figures.
Attachment 1: Phase quadrature readout.
Attachment 2: Comparison to aLIGO design sensitivity (phase quadrature).
Attachment 3: Amplitude quadrature readout.
The quantum noise curves here are not correct. c.f. amplitude quadrature noise budget.
Updated noise budget curves, now computed using the latest version of pygwinc. This resolves the inconsistency between the gwinc quantum noise curves and Gautam's analytic calculations. As before, the key configuration parameters are listed in the figure titles.
Attachment 1: Phase quadrature
Attachment 2: Amplitude quadrature
Attachment 3: Comparison to aLIGO design (phase quadrature)
Revised noise estimates, correcting a couple of factor of 2 and factor of pi errors found in the coil driver noise calculation. Also resolves a strain vs. displacement units confusion using the new pygwinc. Gautam and I have checked these noises against the analytical predictions and believe they are now accurate. Attachments are again:
Attachment 1: Phase quadrature
Attachment 2: Amplitude quadrature
Attachment 3: Comparison to aLIGO design (phase quadrature)
We've completed almost all of the in-situ testing of the c1psl channels. During this process, we identified several channels which needed to be rewired to different Acromags (BIO sinking v. sourcing). We also elected to change the connector type of a few channels for practical advantages. Those modifications and other issues found during testing are detailed below. Also attached are the updated channel assignments, with a column indicating the in-situ testing status of each channel.
Attachment #1 shows the relevant parts of the schematic of the WFS demod board (not whitening board).
Before removing the boards from the eurocrate:
After Koji effected the fix, the boards were re-installed, HV supplies were dialled back up to nominal voltage/currents, and the PMC/IMC were re-locked. The WFS DC channels now no longer saturate even when the IMC is unlocked 👏 👏 . I leave it to Yehonathan / Jon to calibrate these EPICS channels into physical units of mW of power. We should also fix the MEDM screen and remove the un-necessary EPICS channels.
Later in the evening, I took advantage of the non-saturated readbacks to center the beams better on the WFS heads. Then, with the WFS servos disabled, I manually aligned the IMC mirrors till REFLDC was minimized. Then I centered the beam on the MC2 transmission QPD (looking at individual quadrants), and set the WFS1/2 RF offsets and MC2 Trans QPD offsets in this condition.
WFS DC channels are saturating when the IMC is unlocked.
In the past year, pygwinc has expanded to support not just fundamental noise calculations (e.g., quantum, thermal) but also any number of user-defined noises. These custom noise definitions can do anything, from evaluating an empirical model (e.g., electronics, suspension) to loading real noise measurements (e.g., laser AM/PM noise). Here is an example of the framework applied to H1.
Starting with the BHD review-era noises, I have set up the 40m pygwinc fork with a working noise budget which we can easily expand. Specific actions:
I set up our fork in this way to keep the 40m separate from the main pygwinc code (i.e., not added to as a built-in IFO type). With the 40m code all contained within one root-level directory (with a 40m-specific name), we should now always be able to upgrade to the latest pygwinc without creating intractable merge conflicts.
I just now modified the /etc/rsyncd.conf file as per Dan Kozak's instructions. The old conf file is still there with the file name appended with today's date.
I then enabled the rsync daemon to run on boot using 'enable'. I'll ask Dan to start the file transfers again and see if this works.
controls@nodus|etc> sudo systemctl start rsyncd.service
controls@nodus|etc> sudo systemctl enable rsyncd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/rsyncd.service to /usr/lib/systemd/system/rsyncd.service.
controls@nodus|etc> sudo systemctl status rsyncd.service
● rsyncd.service - fast remote file copy program daemon
Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2020-04-13 16:49:12 PDT; 1min 28s ago
Main PID: 4950 (rsync)
└─4950 /usr/bin/rsync --daemon --no-detach
Apr 13 16:49:12 nodus.martian.113.168.192.in-addr.arpa systemd: Started fast remote file copy program daemon.
Apr 13 16:49:12 nodus.martian.113.168.192.in-addr.arpa systemd: Starting fast remote file copy program daemon...
apt install source-highlight
then modified bashrc to point to /usr/share instead of /usr/bin
This is to facilitate the summary page config fines to be pulled from nodus in a scripted way, without being asked for authentication. If someone knows of a better/more secure way for this to be done, please let me know. The site summary pages seem to pull the config files from a git repo, maybe that's better?