40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 32 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  15502   Tue Jul 28 12:22:40 2020 JonUpdateVACVac interlock test today 1:30 pm

This afternoon Jordan is going to carry out a test of the V4 and V5 hardware interlocks. To inform the interlock improvement plan [15499], we need to characterize exactly how these work (they pre-date the 2018 upgrade). I have provided him a sequence of steps for each test and will also be backing him up on Zoom.

We will close V1 as a precaution but there should be no other impact to the IFO. The tests are expected to take <1 hour. We will advise when they are completed.

  15501   Mon Jul 27 15:48:36 2020 JonSummaryVACVacuum parts ordered

To carry out the next steps of the vac refurbishment plan [ELOG 15499], I've ordered parts necessary for interfacing the UPS units and the analog TP2/3 controller outputs with c1vac. The purchase list is appended to the main BHD list and is located here. Some parts we already had in the boxes of Acromag materials. Jordan is gathering what we do already have and staging it on the vacuum controls console table - please don't move them or put them away.

Quote:

Replace failing UPS.

Remove interlock dependencies on TP2/TP3 serial readbacks. Due to persistent glitching [ELOG 15140, ELOG 15392].

  15500   Fri Jul 24 15:40:59 2020 JordanUpdateVACInstallation of two new UPS units

I installed the Tripp Lite SMX1000RT2U and Tripp Lite Smart1000LCD at the bottom of the 1x8 electronics rack. These are plugged in to power, and are ready for testing. All other cables (serial, usb, etc.) have been left on the table next to the 1x8 rack.

Attachment 1: UPS.jpg
UPS.jpg
  15499   Thu Jul 23 15:58:24 2020 JonSummaryVACVacuum controls refurbishment plan

This year we've struggled with vacuum controls unreliability (e.g., spurious interlock triggers) caused by decaying hardware. Here are details of the vacuum refurbishment plan I described on the 40m call this week.

 Refurbish TP2 and TP3 dry pumps. Completed [ELOG 15417].

 Automated notifications of interlock-trigger events. Email to 40m list and a new interlock flag channel. Completed [ELOG 15424].

Replace failing UPS.

  • Two new Tripp Lite units on order, 110V and 230V [ELOG 15465].
  • Jordan will install them in the vacuum rack once received.
  • Once installed, Jon will come test the new units, set up communications, and integrate them into the interlock system following this plan [ELOG 15446].
  • Jon will move the pumps and other equipment to the new UPS units only after completing the above step.

Remove interlock dependencies on TP2/TP3 serial readbacks. Due to persistent glitching [ELOG 15140, ELOG 15392].

Unlike TP2 and TP3, the TP1 readbacks are real analog signals routed to Acromags. As these have caused us no issues at all, the plan is to eliminate dependence on the TP2/3 digital readbacks in favor of the analog controller outputs. All the digital readback channels will continue to exist, but the interlock system will no longer depend on them. This will require adding 2 new sinking BI channels each for TP2 and TP3 (for a total of 4 new channels). We have 8 open Acromag XT1111 channels in the c1vac system [ELOG 14493], so the new channels can be accommodated. The below table summarizes the proposed changes.

Channel Type Status Description Interlock
C1:Vac-TP1_current AI exists Current draw (A) keep
C1:Vac-TP1_fail BI exists Critical fault has occurred keep
C1:Vac-TP1_norm BI exists Rotation speed is within +/-10% of set point new
C1:Vac-TP2_rot soft exists Rotation speed (krpm) remove
C1:Vac-TP2_temp soft exists Temperature (C) remove
C1:Vac-TP2_current soft exists Current draw (A) remove
C1:Vac-TP2_fail BI new Critical fault has occurred new
C1:Vac-TP2_norm BI new Rotation speed is >80% of set point new
C1:Vac-TP3_rot soft exists Rotation speed (krpm) remove
C1:Vac-TP3_temp soft exists Temperature (C) remove
C1:Vac-TP3_current soft exists Current draw (A) remove
C1:Vac-TP3_fail BI new Critical fault has occurred new
C1:Vac-TP3_norm BI new Rotation speed is >80% of set point new
  15498   Tue Jul 21 16:41:46 2020 gautamUpdateBHDPMC assembly space

I decided to use the old EY auxiliary optics table, which is now stored along the east arm about 10 m from the end, as a workspace for assembling the little PMCs. I wiped everything down with isopropanol for general cleanliness, removed the metal plate on the south edge of the table enclosure to allow access, covered the table with some clean Aluminium foil, and then moved the plastic box with PMC parts to the table - see Attachment #1. I haven't actually done any assembly just yet, waiting for more info (if available) on the procedure and implements available...

Attachment 1: IMG_8635.JPG
IMG_8635.JPG
  15497   Tue Jul 21 00:30:24 2020 gautamUpdateBHDIn-air BHD - LO RIN

Attachment #1 shows the RIN of the local oscillator beam delivered to the AP table via fiber. I used a PDA520 to make this measurement, while the electronics for the DCPDs are pending. I don't really have an explanation for the difference between the locked IFO trace vs the not locked trace - we don't have an ISS running (but this first test suggests we should) and the beam is picked off before any cavities etc, so this is a reflection of the state of the FSS servo at the times of measurement?


Tried locking CARM using the hybrid REFL (for AO path) and POX 11 (for MCL path) scheme a bunch of times today, but I had no luck. When the CARM offset is zeroed, the PRMI lock is lost almost immediately. Maybe this is indicative of some excess noise in the POX data stream relative to the REFL signal? The one thing I haven't tried is to take the IFO all the way to the locked state, and then transition the MCL actuation from CM_SLOW to POX11_I.


An SR785 is sitting on the North side of the AP table in the walkway - I will clear it tomorrow.

Attachment 1: LO_RIN.pdf
LO_RIN.pdf
  15496   Mon Jul 20 19:21:16 2020 anchalSummaryALSFew proposals for Voyager ALS

I've added 4 proposed schemes for implementing ALS in voyager. Major thing to figure out is what AUX laser would be and how we would compare the different PSL and AUX lasers to create an error signal for ALS. Everywhere below, 2um would mean wavelengths near 2 um including the proposed 2128nm. Since it is not fixed, I'm using a categorical name. Same is the case for 1um which actually would mean half of whatever 2 um carries.


Higher Harmonic Generation:

  • We can follow the current system of ALS with using 1.5 times PSL frequency as AUX instead of second harmonic as 1 um is strongly absorbed in Si.
  • To generate 1.5 times PSL frequency, three stages would be required.
    • SHG: Second Harmonic Generation mode matched to convert 2um to 1um. If we are instead making 2 um from 1um to start with, this stage will not be required.
    • SFG: Sum Frequency Generation mode matched to sum 2um photon and 1um photon to give 0.65 um photon.
    • DPDC: Degenerate Parametric Down Conversion mode matched to convert 0.65 um to 1.3 um (which would be 1.5 times PSL frequency).
  • To compare, we can either convert pick-off from PSL to AUX frequency by doing the above 3 stages (Scheme II).
  • Or we can just do SHG and SFG at PSL pick-off and do another SHG at AUX end (Scheme I) to compare the AUX and PSL both converted to 0.65 um (which would be 2 times AUX and 3 times PSL frequency).
  • This method would have added noise from SHG, SFG and DPDC processes along with issues to be inefficiency of conversion.

Arbitrary AUX frequency:

  • We can get away with using some standard laser near 1.5 um region directly as AUX. Most probably this would be 1550 nm.
  • What's left is to devise a method of comparing 1.5 um and 2um frequencies. Following are two possible ways I could think of:

Using a frequency comb:

  • Good stable frequency combs covering the wavelength region from 1.5 um to 2 um are available of the shelf.
  • We would beat PSL and transmitted AUX separately with the frequency comb. The two beat note frequencies would be:
    \Delta_\text{PSL} = \nu_\text{PSL} - \nu_{CEO} - m_1 \nu_\text{Rep}
    \Delta_\text{AUX} = \nu_\text{AUX} - \nu_{CEO} - m_2 \nu_\text{Rep}
  • Here, m1 and m2 represent the nearest modes (comb teeth) of frequency comb to PSL and AUX respectively.
  • Carrier Envelope Offset frequency (\nu_{CEO}) can be easily generated by using an SHG crystal in front of the Frequency comb. This step is not really required since most of the modern frequency combs now comb with inbuilt zero \nu_{CEO} stabilization.
  • Mixing above beatnotes with \nu_{CEO} would remove \nu_{CEO} from them along with any noise associated with \nu_{CEO}.
  • Further, a Direct Digital Synthesis IC is required to multiply the AUX side RF signal by m1/m2. This finally makes the two RF signals to be:
    \nu_{A} = \nu_\text{PSL} - m_1 \nu_{Rep}
    \nu_{B} = \frac{m_1}{m_2}\nu_\text{AUX} - m_1 \nu_{Rep}
  • Which on mixing would give desired error signal for DFD as :
    \nu_\text{PSL} - \frac{m_1}{m_2}\nu_\text{AUX}
  • This method is described in Stenger et al. PRL. 88, 073601 and is useful in comparing two different optical frequencies with a frequency comb with effective cancellation of all noise due to the frequency comb itself. Only extra noise is from the DDS IC which is minimal.
  • This method, however, might be an overkill and expensive. But in case (for whatever reason) we want to send in another AUX at another frequency down the 40m cavity, this method allows the same setup to be used for multiple AUX frequencies at once.

Using a Transfer Cavity:

  • We can make another more easily controlled and higher finesse cavity with a PZT actuator on one of the mirrors.
  • In the schematic, I have imagined it has a triangular cavity with a back end mirror driven by PZT.
  • Shining PSL from one side of the transfer cavity and employing the usual PDH, we can lock the cavity to PSL.
  • This lock would require to be strong and wide bandwidth. If PZT can't provide enough bandwidth, we can also put an EOM inside the cavity! (See this poster from Simon group at UChicago)
  • Another laser at AUX frequency, called AUX2 would be sent from the other side of the cavity and usual PDH is employed to lock AUX2 to the transfer cavity.
  • So clearly, this cavity also requires coatings and coarse length such that it is resonant with both PSL and AUX frequencies simultaneously.
  • And, the FSS for AUX2 needs to be good and high bandwidth as well.
  • The transmitted AUX2 from the transfer cavity now would carry stability of PSL at the frequency of AUX and can be directly beaten with transmitted AUX from the 40m cavity to generate an error signal for DFD.
  • I believe this is a more doable and cheaper option. Even if we want to do a frequency comb scheme, this could be a precursor to it.

_________________________

EditTue Jul 21 17:24:09 2020: (Jamie's suggestion)

Using Mode Cleaner cavity as Transfer Cavity:

  • If we coat the mode cleaner cavity mirrors appropriately, we can use it to lock AUX2 laser (mentioned above).
  • This will get rid of all extra optics. The only requirement is for FSS to be good on AUX2 to transfer PSL (MC) stability to AUX frequency.
  • I've added suggested schematic for this scheme at the bottom.

 

Attachment 1: VoyagerALSSchemes.pdf
VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf VoyagerALSSchemes.pdf
  15495   Mon Jul 20 17:55:15 2020 gautamUpdateBHDIn-air BHD - preparing the LO path

The LO pickoff has been coupled into a fiber with ~90% MM (8 mW / 9 mW input). While I wait for the DCPD electronics to be found in the Cryo lab, I want to monitor the stability of the pointing, polarization etc, so I'd like to clear some space on the AP table that was occupied for the mode spectroscopy project. If there are no objections before 2pm tomorrow July 21 2020, I will commence this work.

  15494   Mon Jul 20 17:23:46 2020 gautamUpdateElectronicsCoil drivers for the test masses

Summary:

Looking at the signals to the test mass coils, it seems borderline to me that we will be able to acquire lock and run in a low noise configuration with the same series resistor in the coil driver circuit. The way I see it, options are:

  1. Use a moderately high series resistance (e.g. 5 kohms) for the time being, and go ahead with the HAM-A coil driver.
    • This will mean a current noise of ~3pA/rtHz, which translates to ~3e-18 m/rtHz @ 100 Hz in DARM displacement noise (assuming the ITMs have much higher series resistance than the ETMs).
    • If the lock acquisiton looks smooth, double the resistance to 10 kohms.
    • With 5 kohm series resistance, there is negligible possibility of measuring ponderomotive squeezing for any of the input powers we consider feasible, but this is under the assumption that we will expose coil driver noise, which is very optimistic imho.
  2. Re-design a new coil driver that allows switchable impedance, so we can have a higher noise acquisition mode for acquiring and holding the ALS lock, then transition to a lower noise, lower range config once the RF / BHD lock has been acquired.
    • On paper, this solves all the problems, but the design of such a circuit is probably pretty non-trivial and time consuming.

Details:

I only looked at the ETMs for this study. The assumption is that we will have no length actuation on the ITMs, only local damping and Oplev loops (and maybe some ASC actuation?), which can be sufficiently low-pass filtered such that even with coil de-whitening, we won't have any range issues.

Attachment #1 shows the time-domain traces of the coil driver signals as we transition from POX/POY lock to the ALS lock. There are some transients, but I think we will be able to hold the lock even with a 5 kohm resistor (~twice what is on ETMX right now). From just these numbers, it would seem we can even go up to 10 kohms right away and still be able to acquire lock, especially if we re-design the digital feedback loop to have better low-pass filtering of the high-frequency ALS noise, see the next attachment.

Attachment #2 shows the f-domain picture, once the arm lengths are fully under ALS control (~25 seconds onwards in Attachment #1). The RMS is dominated by high frequency ALS length loop noise, which we can possibly improve with better design of the digital control loop.

Finally, Attachment #3 shows the situation once DARM control has been transitioned over to AS55_Q. Note that the vertex DoFs are still under 3f control, so there is the possibility that we can make this even lower noise. However, one thing that is not factored in here is that we will have to de-whiten these signals to low-pass filter the DAC noise (unless there is some demonstrated clever technique with noise-mons or something to subtract the DAC noise digitally). Nevertheless, it seems like we can run safely with 5 kohms on each ETM coil and still only use ~2000 cts RMS, which is ~1/10th the DAC range (to allow for dealing with spurious transients etc). 

Quote:

Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).

Attachment 1: ALSlock_timeDomain.pdf
ALSlock_timeDomain.pdf
Attachment 2: ALSlock.pdf
ALSlock.pdf
Attachment 3: RFlock.pdf
RFlock.pdf
  15493   Sun Jul 19 15:40:15 2020 gautamUpdateBHDIn-air BHD - CDS and wiring summary

Attachment #1 shows the proposed wiring and CDS topology for the in air BHD setup. The PDF document has hyperlinks you can follow to the DCC entries. Main points:

  1. I think we should run the realtime model on c1lsc. This will negate the need for any IPC between c1ioo and c1lsc machines.
  2. I think we have most of the electronics we need already, though I am still in the process of testing the various boards, especially the HV ones.
  3. We may choose to use the switchable whitening feature for the M2 ISS board
    • This would require some BIO channels
    • There are plenty spare in c1lsc, so it's not going to be a show stopper
    • This is why I've not explicitly included a whitening board for now...
  4. The main job seems to be to make a whole bunch of custom cables. For the most part, I think we have the long (~20m) long D9 cables, so I propose just snipping off the connector at one end, and soldering on the appropriate connectors to the correct conductors.
  5. For the homodyne phase control - the proposal is to use a PI PZT with 3 piezoelectric elements. We would drive the 3 elements with the same voltage, by shorting the conductors together (at least that's how I understood Koji's comment), so we'd only need a single DAC channel for this purpose.
    • Need to confirm that the parallel PZT capacitances (each element is ~300 nF so 3 in parallel would be ~900 nF) still allows sufficient actuation bandwidth.
    • If the relative actuation strength of the 3 elements needs to be individually tuned, we may have to use three DAC channels. The D980323 board will allow the driving of 3 independent channels. I have one of these boards in hand, but need to check if it works, and also implement the changes outlined here.
  6. The alignment control has not yet been accounted for
    • We could consider using the in-vacuum PZTs, these were verified to be working ~2018.
    • If we use only 1 steering PZT mirror, we have sufficient free DAC channels available in c1lsc. But if we need both (to avoid clipping for example), then we need more DAC channels - we can either free up one DAFI channel, or install a DAC in the c1lsc expansion chassis
  7. We may want to expand to have a second OMC at some point. In which case we'd need, at the very least
    • 1 more DAC card
    • A HV driver for the second OMC length (could use the Trek driver if we use D980323 for the homodyne phase control).

Please comment if I've overlooked something.

Attachment 1: wiringDiagram.pdf
wiringDiagram.pdf
  15492   Fri Jul 17 09:03:58 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake lab today from 9am to 4pm.

  15491   Fri Jul 17 00:18:13 2020 gautamUpdateGeneralLocking updat
  1. I found that an EPICS channel wasn't reset to the correct value by burtrestore after the FE bootfest yesterday.
    • This cost me the whole of last night, found it finally tonight. 
    • I'll try and modify the locking scripts to better capture such errors, but ideally, we should just use Guardian or something since it's made for this purpose already.
    • Anyways, tonight I was able to re-acquire the PRFPMI lock in a completely scripted way.
  2. Locking CARM on POX remains out of reach.
    • I think this has to do with the fact that the zero-crossing of the CARM and REFL error signals are dependent on the 3f PRCL/MICH error point offsets.
    • So even if the DC gain is right, the fact that we use POX for the digital AO path and REFL for the analog AO path is leading to some conflict I think.
    • Ran out of energy tonight, I'll try again tomorrow.

The DQ channels of the ETM coils were active tonight, so I'll make the coil driver actuation budget over the next couple of days.

  15490   Thu Jul 16 14:41:22 2020 gautamUpdateGeneralFire extinguisher inspection

The (masked) tech accessed all areas in the lab (office area, control room, VEA) between ~230pm-3pm. The laser safety goggles he used have been kept aside for appropriate sanitaiton.

  15489   Thu Jul 16 01:12:22 2020 gautamUpdateBHDIn-air BHD - preparing the LO path

Attachment #1 - The 80mW pickoff was getting clipped on a BNC cable, and not making it to the doubling oven. 😢 .

  • Since the PSL doubled beam isn't used for locking these days, I just didn't notice.
  • I blame the ringdown team, this crazy tee arrangement wasn't the case before.
  • I fixed the situation by changing the cabling such that the beam clears the cables comfortably.

Attachment #2 - PSL green shutter removed. Alignment into the doubling oven is extremely tedious, and so I opted to preserve the capability of recovering the green beam by simply removing a single mirror.

Attachment #3 - The beam path for coupling the LO beam into a fiber.

  • Primary goal was to have easy access to some steering mirrors so that I can optimize alignment into the fiber collimator.
  • I opted to use the NW corner of the PSL table - that's where most of our existing fiber hardware is anyways, and there was sufficient space and easy access over there.
  • 3 Y1 mirrors were installed, using the preferred Polaris mounts and 3/4" post + baseplate hardware. They were labelled Y1-1037-45P so that future workers need not be un-necessarily tortured. The third mirror is not visible in this photograph.
  • Once the collimator arrives, I will mode match this beam into the fiber. Plan is to use the fiber originally used for the mode spectroscopy project. It needs to be moved to the NW corner of the PSL table, and the other end needs to be routed to the AP table (it was brought back to the PSL table to facilitate Anjali's fiber MZ experiment). 
  • There is plenty of space in the beam path for mode-matching lens(es) and polarization control optics.

Attachment #4 shows the BHD photodiodes taken from QIL. 

  • Unfortunately, we could not find the readout electronics. 
  • In the worst case, we can just interface these PDs with the existing Satellite box (associated with the copper OMC).
  • It might be that the OMC cavity can simply be placed on this breadboard, making the whole setup nice and portable.
  • We may want to consider having an OFI between the OMC and the IFO AS beam at some point...
Attachment 1: IMG_8626.JPG
IMG_8626.JPG
Attachment 2: IMG_8627.JPG
IMG_8627.JPG
Attachment 3: IMG_8628.JPG
IMG_8628.JPG
Attachment 4: IMG_8629.JPG
IMG_8629.JPG
  15488   Wed Jul 15 21:08:43 2020 gautamUpdateElectronicsETM coil outputs DQed

To facilitate this investigation, I've DQed the 4 face coil outputs for the two ETMs. EX is currently running with 5 times the series resistance of EY, so it'll be a nice consistency check. Compilation, installation etc went smooth. But when restarting the c1scx model, there was a weird issue - the foton file, C1SCX.txt, got completely wiped (all filter coefficients were empty, even though the filter module names themselves existed). I just copied the chiara backup version, restarted the model, and all was well again.

This corresponds to 8 additional channels, recorded at 16k as float 32 numbers, so in the worst case (neglecting any clever compression algorithms), we are using disk space at a rate of ~4 MB/s more. Seems okay, but anyway, I will remove these DQ channels in a few days, once we're happy we have enough info to inform the coil driver design.

spoke too soon - there was an RFM error for the TRX channel, and restarting that model on c1sus took down all the vertex FEs. Anyways, now, things are back to normal I think. The remaining red light in c1lsc is from the DNN model not running - I forgot to remove those channels, this would've been a good chance! Anyways, given that there is an MLTI in construction, I'm removing these channels from the c1lsc model, so the next time we restart, the changes will be propagated.

For whatever reason, my usual locking scripts aren't able to get me to the PRFPMI locked state - some EPICS channel value must not have been set correctly after the model reboot 😞. I'll debug in the coming days.

Fun times lie ahead for getting the new BHD FEs installed I guess 🤡 ....

Quote:
 

Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).

So we may need a version of the fast coil driver that supports a low noise mode (with large series resistance) and a high-range mode (with lower series resistance for lock acquisition).

Attachment 1: CDS.png
CDS.png
Attachment 2: coilOutDQed.png
coilOutDQed.png
  15487   Wed Jul 15 20:58:40 2020 gautamUpdateGeneralEmergency light on in control room

True - it is now not on anymore.

Quote:

It happened before too. Doesn't it say it has occasional self-testing or something?

  15486   Wed Jul 15 19:51:51 2020 KojiUpdateGeneralEmergency light on in control room

It happened before too. Doesn't it say it has occasional self-testing or something?

  15485   Wed Jul 15 19:23:44 2020 gautamUpdateGeneralEmergency light on in control room

The emergency lamps above the exit sign on the NW entrance to the control room are on. I tried opening and closing the door, but it remains on. Probably nothing to worry about, but noting here anyway.

  Draft   Wed Jul 15 19:17:09 2020 gautamUpdateBHDIn-air BHD - alignment into OMC

You can activate all 3axis

 

  15483   Wed Jul 15 19:11:40 2020 gautamUpdateBHDIn-air BHD - alignment into OMC

I forgot about the pointing - probably we will need another actuator to control the pointing of the AS beam onto the DCPDs. I found a few old PI PZTs (model number is S-320, which is a retired part), one is labelled broken but the others don't indicate a-priori that they are broken. I'll post a more detailed hardware survey later.

  15482   Wed Jul 15 17:46:05 2020 anchalSummaryALSNoise budget for ALS

I started my attempt on noise budgeting of ALS by going back to how Kiwamu did it and adding as many sources as I could find up till now. This calculation is present in ALS_Noise_Budget notebook. I intend to collect data for noise sources and all future work on ALS in the ALS repo.

The noise budget runs simulink through matlab.engine inside python and remaining calculations including the pygwinc ones are done in python. Please point out any errors that I might have done here. I still need to add noise due to DFD and the ADC after it. For the residual frequency noise of AUX laser, I have currently used an upper limit of 1kHz/rt Hz at 10 Hz free-running frequency noise of an NPRO laser.

Attachment 1: ALS_nb.pdf
ALS_nb.pdf
  15481   Tue Jul 14 17:28:29 2020 gautamUpdateLSCLocking with POX for CARM

From Attachment #1, looks like the phasing and gain for CARM on POX11 is nearly the same as CARM of REFL11, which is probably why I was able to execute a partial transition last night. The response in POY11 is ~10 times greater than POX11, as expected - though the two photodiodes have similar RF transimpedance, there is a ZFL-500-HLN at the POY11 output. The actual numerical values are 2.5e10 cts/m for CARM-->REFL11_I, 2.6e10 cts/m for CARM-->POX11_I, and 3.2e11 cts/m for CARM-->POY11_I.

So I think I'll just have to fiddle around with the transition settings a little more tonight. 

One possible concern is that the POX and POY signals are digitized without preamplificatio, maybe this explains the larger uncertainty ellipse for the POX and POY photodiodes relative to the REFL11 photodiode? Maybe the high frequency noise is worse and is injecting junk in the AO path? I think it's valid to directly compare the POX and REFL spectra in Attachment #2, without correcting for any loops, because this signal is digitized from the LSC demodulator board output (not the preamplified one, which is what goes to the CM board, and hence, is suppressed by the CARM loop). Hard to be sure though, because while the heads are supposed to have similar transimpedance, and the POX photodiode has +12dB more whitening gain than REFL11, and I don't know what the relative light levels on these photodiodes are in lock.

Quote:

I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be

Attachment 1: PRFPMI_2020712sensMat.pdf
PRFPMI_2020712sensMat.pdf
Attachment 2: LSCerrSigs.pdf
LSCerrSigs.pdf
  15480   Tue Jul 14 16:52:47 2020 gautamUpdateElectronicsCoil drivers for the test masses

Summary:

Koji and I had a discussion last Friday about the suspension electronics. I think there are still a few open questions - see Attachment #1. We should probably make a decision on these soon.

Other useful links:

  1. High-voltage coil driver circuit - D1900163
    • This board is ready to be fabricated and tested on the bench.
    • The way the connectors J2 and J3 are designed currently is meant to interface with the existing coil driver electronics.
    • Depending on the eventual coil driver we choose for the fast path, it may be benificial to change the signals on the connectors J2 and J3, to avoid the need for a custom interface board.
  2. HAM-A coil driver noise analysis.
    • The linked attachment evaluates the noise for the design value of the fast path series resistor, which is 1.2 kohms.
    • Iff we still have ambitions of measuring ponderomotive squeezing, we will need the resistance to be much higher, ~10 kohms (in the linked noise budget, only the Johnson noise of the series resistor is considered, but in reality, the OpAmp voltage and current noises also matter). 
    • This corresponds to a maximum current of 10V/10kohms = 100uA
    • Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).
    • So we may need a version of the fast coil driver that supports a low noise mode (with large series resistance) and a high-range mode (with lower series resistance for lock acquisition).
  3. You can follow the links to DCC entries for other parts from Attachment #1.
Attachment 1: coilDriverSchem.pdf
coilDriverSchem.pdf
  15479   Tue Jul 14 15:29:25 2020 gautamUpdateBHDIn-air BHD - DCPD amplifier noise

For the first pass, it's probably easiest to use the existing DCPD amplifier. Looking at the gain and noise performance in Attachment #1, seems totally fine, the electronics noise will not be limiting if we have ~10mW of LO power. I assumed a transimpedance resistor of 1 kohm, and all other numbers as on the schematic (though who knows if the schematic is accurate). The noise should be measured to confirm that the box is performing as expected...

Attachment 1: DCPDamp.pdf
DCPDamp.pdf
  15478   Tue Jul 14 09:04:53 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake Lab today from 9am to 4pm.

  15477   Tue Jul 14 01:55:03 2020 KojiUpdateLSCLocking with POX for CARM

The usual technique is that keeping the IFO locked with the old set of the signals and the relative gain/TF between the conventional and new signals are measured in-lock so that you can calibrate the new gain/demod-phase setting.

  15476   Tue Jul 14 00:06:09 2020 gautamUpdateLSCLocking with POX for CARM

I tried using the POX_I error signal for the DC CARM_B path today a couple of times. Got to a point where the AO path could be engaged and the arm powers stabilized somewhat, but I couldn't turn the CARM_A path off without blowing the lock. Now the IMC has entered a temperemental state, so I'm abandoning efforts for tonight, but things to try tomorrow are:

  1. Check that the demod phase is set correctly
  2. With the CARM_B path engaged, measure some CARM OLTFs. Tonight, I was a bit over-optimistic I think, by expecting the scripted transition to take me all the way, but I think I'll have to fiddle around with the gains a bit.
  3. Check for offsets. The AO path should be AC coupled, but maybe the POX signal has some offset?

I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be.

The motivation here is to see if the sensing matrix looks any different with a modified locking scheme.

  15475   Mon Jul 13 12:37:05 2020 gautamUpdateComputersrossa: more developmental work

In fact, all these utilities are now available in python3. There may be some bugs (e.g. this), but I've checked basic functionality and things look usable enough for development to proceed. While we can have a python2 env on rossa, I think it's unnecessary.

Quote:

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

  15474   Mon Jul 13 11:36:08 2020 ranaUpdateLSCMC2 coils need DC balancing?
  1. if IMC REFL is not increasing, I don't think its a mis-alignment. Usually, REFL is a more sensitive indicator of alignment than TRANS since its usually near zero. Maybe the MC2 TRANS PD is not centered or doesn't have enough lens action.
  2. to reduce the DC load on MC2, you could have a slow releif drive the ETMs and DC and minimize LSC-MCL
  15473   Mon Jul 13 11:33:18 2020 ranaUpdateComputersrossa: more developmental work

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

Is it possible to just make a python2 conda environment on rossa? I would guess that its simple and won't interfere with the regular operation of that machine.

  15472   Sun Jul 12 22:40:35 2020 gautamUpdateElectronicsWFS characterization - old SURF report

After some hunting, I found this old SURF report with the WFS head measurements. The y-axes don't make much sense to me, and I can't find the actual data anywhere (her wiki page doesn't actually exist). So I think it's still unknown if these heads ever had the advertised transimpedance gain, or if the measured transimpedance of ~1kohm was what it always was.

  15471   Sun Jul 12 02:42:01 2020 gautamUpdateLSCLocking (on rossa)

Main goals tonight were:

  1. Check if I can lock the interferometer by working on rossa - indeed, I could! It is much snappier than the ageing pianosa. The viewing angle of the CRT monitors from this corner isn't so good though.
  2. Measure step responses for the arm ASC loops to see if any insight can be gained into these loops. Analysis forthcoming...
Attachment 1: ASCsteps.png
ASCsteps.png
  15470   Sat Jul 11 18:24:30 2020 KojiUpdateLSCMC2 coils need DC balancing?

> Can't we offload this DC signal to the laser crystal temperature servo?
No. PSL already follows the MC length. So this offset is coming from the difference between the MC length and the CARM length.
What you can do is to offload the MC length to the CARM DC if this helps.

  15469   Sat Jul 11 00:10:22 2020 gautamUpdateComputersrossa: more developmental work

After some consultation with Erik von Reis at LHO, this workstation is progressing towards being usable for most commissioning tasks. DTT, awggui, foton, and MEDM are all now working well. The main limitation now comes from the fact that many of our python scripts are written for python2, and rossa doesn't have many dependencies installed for python2. I see no reason to build these dependencies on rossa for python2, we should not have to work with an unsupported language. But at the same time, I don't want to completely wipe all our python2 scripts, and make them python3, because this would involve a lot of tedious testing that I'm not prepared to undertake at the moment (the problem is compounded by the fact that pianosa does not have many dependencies installed for python3).

So what I have done in the interim is make python3 versions of the most important scripts I need to get the PRFPMI locking working - they are in the scripts directory and have the same names as their python2 counterparts, but have a 3 appended to their names. So when working on rossa, these are the scripts that are called. Eventually, after a lot more testing, we can depracate the old scripts. Currently, where applicable, the MEDM screens allow for either the python2 or python3 version of the script to be called.

Please, for the time being, do not try and install any new packages on rossa unless you are prepared to debug any problems caused and return the machine to a workable state. If you find some issue with a missing package on rossa, (i) make a note of it on the elog, and (ii) if possible, set up your own conda environment for testing and install dependencies to that environment only.

  15468   Fri Jul 10 15:26:28 2020 gautamUpdateLSCMC2 coils need DC balancing?

I was looking at some signals from last night, see Attachment #1.

  • It looks like as the DC control signal to the MC2 suspension increases, the MC transmission decreases.
    • I confirmed that the IMC REFL level doesn't correspondingly trend up, but didn't include it here for plot compactness, so I think the cavity length isn't being detuned.
    • So the problem is suggestive of some L2A coupling, and the MC2 coil actuators need to be balanced better at DC?
    • You can see from the IMC WFS control signals that the WFS servo is presumably trying to counteract this L2A action, but doesn't succeed, probably because the servo isn't tuned correctly.
    • This is a problem that is distinct from the drifting TT alignment. So it complicates the alignment situation.
    • Ideally, if the dither alignment servos could be made to work for the arm cavities when locked in the PRFPMI config, this wouldn't be so much of a problem, as the TTs would just adjust the beam pointing to match the cavity axes of the arms. But since I haven't managed to get that servo working yet...
  • But why should MC2 need such a large DC control signal ever?
    • In the PRFPMI lock, the CARM servo is supposed to match the laser frequency to the average length of the two arm cavities.
    • The MC2 suspension is used as a frequency actuator in order to realize this matching.
    • But, as you can see, the digital CARM control signal picks up a significant DC offset the deeper we go into the lock.
    • Can't we offload this DC signal to the laser crystal temperature servo? Is there going to be some weird interaction with the existing slow loop? Or is the idea itself flawed?

Attachment #2 shows some ASC metrics. My conclusion here is that running the PRCL and MICH dither alignment servos (former demodulating REFLDC and latter demodulating ASDC to get an error signal) that running the dither alignment servo and hand tuning the arm ASC loop offsets improves the mode matching to the IFO, because:

  1. The arm transmission increases.
  2. POPDC increases.
  3. ASDC decreases.

The REFLDC behavior needs a bit more interpretation I think, because if the IFO is overcoupled (as I claim it is), then better alignment would at some point actually result in REFLDC increasing. 

All the DC signals recorded by the fast system come from the backplane P2 connector of the PD interface boards. According to the schematic, these signals have a voltage gain of 2. The LSC photodiodes themselves have a nominal DC gain of 50 ohms. So, the conversion from power to digital counts is: 0.8 A/W * 50 V/A * 2 * 3276.8 cts/V * whtGain. Inverting, I get 3.8 uW/ct for a whitening gain of 1. This is power measured at the photodiode - optical losses upstream of the photodiode will have to be accounted for separately.

Assuming a modulation depth of 0.2, the 55 MHz sideband power should be ~20 mW. The Schnupp asymmetry is supposed to give us O(1) transmission of this field to the AS port. Then, the SRM will attenuate the field by a factor of 10, so we expect ~2 mW at the AS port. Let's assume 80 % throughput of this field to the AP table, and then there is a 50/50 beamsplitter dividing the light between the AS55 and AS110 photodiodes. So, we expect there to be ~700 uW of power in the TEM00 mode 55 MHz sideband field. This corresponds to 1600 cts according to the above calibration (the ASDC whitening gain is set to 18 dB). The fact that much smaller numbers were seen for ASDC indicates that (i) the schnupp asymmetry is not so perfectly tuned and the actual transmission of the sideband field to the dark port is smaller, or (ii) one or more optical splitting fractions assumed above is wrong. If the former is true, we can still probably infer the contrast defect if we can somehow get an accurate measurement of the sideband transmission to the dark port.

Attachment 1: MC2_balancing.png
MC2_balancing.png
Attachment 2: ASDC.png
ASDC.png
  15467   Fri Jul 10 10:37:30 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake lab today from 9am to 4pm

  15466   Fri Jul 10 01:25:28 2020 gautamUpdateLSCLocking notes

More tomorrow, but I tried the following tonight:

  1. Dither alignment for PRC / MICH seems to work when the PRFPMI is locked. Unfortunately, the correct settings for the arm cavity dither alignment loops continue to elude me.
  2. I tried some arm ASC loop characterization by stepping the error points of these loops - I saw some weird cross coupling between the loops that needs investigation.
  3. I'm unable to turn an integrator on for the "Common YAW" QPD loop - unclear why this is, but every time I attempt to engage said integrator, the lock is immediately blown. Needs some investigation of the signals.
  4. With the PRC / MICH angular DoFs aligned with the dither alignemnt, and the arm ASC loops hand tuned, I was able to get the darkest dark port I've seen. In terms of ASDC counts, it was ~ 200, which after undoing all the digital gains etc corresponds to ~100 uW of light. I think we can get a rough estimate of the contrast defect by accounting for (i) T_SRM, (ii) OMC pickoff fraction (iii) other losses between the BS dark port and the AP table (iv) 50/50 BS between AS55 and AS110 PD (the ASDC signal is derived from the former) and (v) the throughput of the 55 MHz sideband to the dark port, although there are many uncertainties. 
  15465   Thu Jul 9 18:00:35 2020 JonConfigurationVACUPS replacements

Chub has placed the order for two new UPS units (115V for TP2/3 and a 220V version for TP1).

They will arrive within the next two weeks.

Quote:

​I looked into how the new UPS devices suggested by Chub would communicate with the vac interlocks. There are several possible ways, listed in order of preference:

  • Python interlock service directly queries the UPS via a USB link using the (unofficial) tripplite package. Direct communication would be ideal because it avoids introducing a dependency on third-party software outside the monitoring/control capability of the interlock manager. However the documentation warns this package does not work for all models...
  • Configure Tripp Lite's proprietary software (PowerAlert Local) to send SYSLOG event messages (UDP packets) to a socket monitored by the Python interlock manager.
  • Configure the proprietary software to execute a custom script upon an event occurring. The script would, e.g., set an EPICS flag channel which the interlock manager is continually monitoring.

I recommend we proceed with ordering the Tripp Lite 36HW20 for TP1 and Tripp Lite 1AYA6 for TP2 and TP3 (and other 120V electronics). As far as I can tell, the only difference between the two 120V options is that the 6FXN4 model is TAA-compliant.

  15464   Thu Jul 9 17:12:52 2020 gautamUpdateBHDIn-air BHD

Summary:

We can probably learn something about the interferometer / top level BHD plan with an in-air BHD setup, even if the noise is bad. Here are some thoughts about how we would do it. 

LO delivery:

For this first attempt, we don't really care about the PRC filtering. So possible places to pick off an LO beam are:

LO beam pickoff options
Location Pros Cons
IP POS
  • Filtered by IMC
  • Medium level of invasiveness  
  • We lose the IP POS diagnostic, which is kind of useful nowadays given the drifty TTs.
  • Only few mW LO power available
PSL table IR beam currently going to green doubling setup
  • Least invasive w.r.t. normal IFO operation
  • Plenty of light (~100 mW) available. But how much can we safely couple into fiber?
  • Beam not filtered by IMC (although it is filtered by the PMC)
POX/POY
  • Since this beam is extracted from inside the PRC, probably enjoys the best filtering.
  • Possibly drifts a lot, so tricky to reliably couple into a fiber?
  • Maximally invasive w.r.t. regular IFO operations.

In all cases, I think the easiest option to actually route whatever beam we choose into a fiber, and then bring it over to whatever cavity we choose to use for an OMC. I'm assuming whatever phase control technique we end up using can cancel the fiber phase noise at relevant frequencies.

LO phase control

  • Stress the fiber? This will require us to purchase some custom hardware, and interface it to the CDS system.
  • PZT mirror? We should have sufficient hardware available to drive a PI style PZT mirror.

There is a question about the range, but I think these are the only two realistic options we can implement on a reasonable time scale.

OMC:

Again, there are a few options. Here are some pros and cons that come to my mind.

OMC cavity options
Option Pros Cons
Old copper OMC
  • Probably the simplest option in terms of the peripherals.
  • PZT driver recently verified to work
  • We can get the OMMT and DCPDs out as well.
  • Allows us to not compromise on the RF darm optical gain (not sure if locking will be as easy if we cut the power to the AS55 photodiode by 50-75%).
  • Requires a vent.
  • Probably not the most efficient use of the space on the AP table.
  • Filtering performance isn't quantified.
Spare PMC
  • Doesn't require a vent.
  • Compact footprint.
  • Need to build the cavity.
  • Need to check if the drive electronics from the old copper OMC can easily be interfaced with whatever PZT we use on this cavity.
  • Filtering performance kind of unknown?
Custom cavity with spare mirrors
  • Doesn't require a vent.
  • Probably no more difficult than the spare PMC option?
  • We need at least one actuatable mirror, so we'd need some PZT mounted optic + associated drive electronics.

If we can do a vent (we'd just need a single chamber open), I'd go for the option of getting the copper OMC out and using that. Attachment #1 shows the approximate sizes of the various components (OMMT, OMC cavity, DCPDs), while Attachment #2 shows a rough sketch of where things would go on the AP table, with the rectangles approximately to scale.

CDS:

I'd made a c1omc model sometime ago. Basically, I think we have sufficient ADC/DAC channels in the c1ioo machine for any of the options listed above - but using the copper OMC and associated peripherals would allow the easiest interfacing.

Criticisms/comments/thoughts please.

Attachment 1: OMCchamber.pdf
OMCchamber.pdf
Attachment 2: AP_Table_20180328.pdf
AP_Table_20180328.pdf
  15463   Thu Jul 9 16:16:20 2020 gautamUpdateComputersrossa: graphics driver issues?

I noticed these streaky lines again today (but they were not a problem last night). It is annoying if we have to reboot this machine all the time. I wonder if this has something to do with missing drivers. When I ran sudo apt update && sudo apt upgrade, I got several lines like (this isn't the whole stack trace)

W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_unload.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/ucode_load.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/unload_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gp108/acr/bl.bin for module nouveau

Is this indicative of the graphics drivers being installed incorrectly? I am hesitant to mess with this because I think in the past, it was always trying to update some graphics driver that crashed the whole machine into some weird state where we have to wipe the drive and do a fresh re-install of the OS.

Should we just follow these instructions? The graphics card is apparently Quadro P400, which is one of the supported ones according to the list of supported devices.

Or just swap donatella and rossa monitors and defer the problem for later?

Quote:

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

  15462   Thu Jul 9 16:02:33 2020 JonHowToCDSProcedure for setting up BHD front-ends

Here is the procedure for setting up the three new BHD front-ends (c1bhd, c1sus2, c1ioo - replacement). This plan is based on technical advice from Rolf Bork and Keith Thorne.

The overall topology for each machine is shown here. As all our existing front-ends use (obsolete) Dolphin PCIe Gen1 cards for IPC, we have elected to re-use Dolphin Gen1 cards removed from the sites. Different PCIe generations of Dolphin cards cannot be mixed, so the only alternative would be to upgrade every 40m machine. However the drivers for these Gen1 Dolphin cards were last updated in 2016. Consequently, they do not support the latest Linux kernel (4.x) which forces us to install a near-obsolete OS for compatibility (Debian 8).

Hardware

Software

  • OS: Debian 8.11 (Linux kernel 3.16)
  • IPC card driver: Dolphin DX 4.4.5 [works only with Linux kernel 2.6 to 3.x]
  • I/O card driver: None required, per the manual

Install Procedure

  1. Follow Keith Thorne's procedure for setting up Debian 8 front-ends
  2. Apply the real-time kernel patches developed for Debian 9, but modified for kernel 3.16 [these are UNTESTED against Debian 8; Keith thinks they may work, but they weren't discovered until after the Debian 9 upgrade]
  3. Install the PCIe expansion cards and Dolphin DX driver (driver installation procedure)
  15461   Thu Jul 9 09:22:44 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake lab today from 9am to 3pm

  15460   Wed Jul 8 22:50:33 2020 gautamUpdateComputersrossa: more symlinks

I wanted to try using rossa as my locking workstation today. However, a few problems became quickly evident. Basically, any of our scripts that rely on the cdsutils package (there are MANY) will not work on rossa, because of some library error. This machine is running Debian 10, while the cdsutils package is being loaded from a pre-compiled install on the shared drive, so perhaps this isn't surprising?

Digging a little more, I found that actually, a version of cdsutils that actually works with python3 is actually shipped with the standard cds-workstation meta-package. This is great news, and we should try and use this where possible I guess. Deferring further debugging for daytime work.

Anyway, I added a symlink: sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5, and installed wmctrl using sudo apt install wmctrl

  15459   Wed Jul 8 08:51:35 2020 JordanUpdateGeneralPresence at 40m

I will be in the clean and bake lab today from 9am to 3pm.

  15458   Tue Jul 7 14:06:10 2020 gautamUpdateASCSome more thoughts about ASC

Summary:

I want to be able to run the dither alignment servo with the PRFPMI locked - I've been thinking about what the scheme should be, and I list here some questions I had while thinking about this.

Details:

  1. ITM Oplev DC coupling
    • In the current scheme, I DC couple the ITM Oplev servos after the arms have been aligned to maximize POX/POY transmission.
    • However, looking back at data from when the CARM offset is reduced (e.g. Attachment #1), it looks like the ITMs are being torqued quite a bit during this process (ITMX PIT changes by ~20urad, ITMY YAW by ~10urad in this particular lock attempt). 
    • So the spots are not actually being centered on the test-masses? I guess the spot position on ITMX isn't actually controlled because we have only one actuator (BS) for the XARM beam axis. Is it unexpected that ITMY gets torqued so much? 
    • It is unclear what would happen if the ITM Oplev servos are not DC coupled. I wonder if I'd still be able to reach the high circulating powers and then rely solely on the TR QPDs for the arm cavity angular control.
    • Another possibility is to offload the DC part of the control signal to the optic's slow bias voltage slider, and then turn off the DC coupling. After that, the dither alignment can optimize the cavity alignment.
  2. Dither alignment at high circulating power
    • think that the system should work with the same settings as for the POX/POY locking, with the following changes:
      • Scale the overall loop gain by the arm transmission.
      • Change LSC2ASS matrix element from XARM/YARM ---> DARM.
        Does this sound right?
    • In light of the above, I was thinking that we should introduce a gain scaling field in the c1ass RTCDS model (like we have for the LSC power normalization matrix). Is it worth to go through the somewhat invasive process of model recompilation etc?
    • With the PRFPMI locked, I am wondering if I can simultaneously run the dither alignment loops for all the DoFs. Probably not, especially for MICH, since the actuator is the BS, which is also the actuator for the XARM loop?
Attachment 1: ITM_OL_DCcoupling.png
ITM_OL_DCcoupling.png
  15457   Mon Jul 6 17:41:19 2020 gautamUpdateLSCAn LSC puzzler

Last Tuesday evening, while attempting the PRFPMI locking, I noticed a strange feature in the LSC signals, which is shown in Attachment #1 (the PDF exported by dataviewer is 14MB so I upload the jpeg instead). As best as I can tell, the REFL33 and POP22 channels show an abrupt jump in the signal levels, while the other channels do not. POP110 shows a slight jump at around the same time, and the large excursion in AS110_Q actually occurs a few seconds later, and is probably some angular excursion of the PRC/BS. I'm struggling to interpret how this can be explained by some interferometric mechanism, but haven't come up with anything yet. The LO for the 3f error signals is the 2f field, but then why doesn't the POP110 channel show a similar jump if there is some abrupt change in the resonant condition? Is such a change even feasible from a cavity length change point of view? Or did the sideband frequency somehow abruptly jump? But if so, why is the jump much more clearly visible in one sideband than the other?

Does anyone have any ideas as to what could be going on here? This may give some clue as to what's up with the weird sensing matrices, but may also be something boring like broken electronics... 

Attachment 1: LSCsignals.jpg
LSCsignals.jpg
  15456   Mon Jul 6 15:10:40 2020 JonSummaryBHD40m --> A+ BHD design analysis

As suggested last week, Hang and I have reviewed the A+ BHD status (DRD, CDD, and reviewers' comments) and compiled a list of key unanswered questions which could be addressed through Finesse analysis.

In anticipation of others helping with this modeling effort, we've tried to break questions into self-contained projects and estimated their level of difficulty. As you'll see, they range from beginner to Finesse guru.

  15455   Mon Jul 6 12:51:41 2020 gautamUpdateComputersrossa: resolvconf installed

Indeed, this is now fixed by following instructions from here. I rebooted rossa at ~1250 PDT and confirmed that resolv.conf didn't get overwritten. The resolv.conf file also now has the following useful lines at the head:

~>cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
Quote:

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

  15454   Mon Jul 6 12:43:02 2020 ranaUpdateComputersrossa: lib symlink

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

  15453   Mon Jul 6 08:48:15 2020 JordanUpdateGeneralPresence at 40m

I will be in the Clean and Bake lab today from 8:30am to 4pm

ELOG V3.1.3-