40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 60 of 339 Not logged in
ID Date Author Type Category Subject
13512   Sun Jan 7 03:22:24 2018 KojiUpdatePonderSqueezeDisplacement requirements for short-term squeezing

Interesting. My understanding is that this is close to signal recycling, rather than resonant sideband extraction. Is that correct?

For signal recycling, we need to change the resonant condition of the carrier in the SRC. Thus the macroscopic SRC length needs to be changed from ~5.4m to 9.5m, 6.8m, or 4.1m.
In the case of 6.8m, SRC legnth= PRC length. This means that we can use the PRM (T=5%) as the new SRM.

Does this T(SRM)=5% change the squeezing level?

13513   Sun Jan 7 11:40:58 2018 KevinUpdatePonderSqueezeDisplacement requirements for short-term squeezing

Yes, this SRC detuning is very close to extreme signal recycling (0° in this convention), and the homodyne angle is close to the amplitude quadrature (90° in this convention).

For T(SRM) = 5% at the optimal angles (SRC detuning of -0.01° and homodyne angle of 89°), we can see 0.7 dBvac at 210 Hz.

13514   Sun Jan 7 17:27:13 2018 gautamUpdatePonderSqueezeDisplacement requirements for short-term squeezing

Maybe you've accounted for this already in the Optickle simulations - but in Finesse (software), the "tuning" corresponds to the microscopic (i.e. at the nm level) position of the optics, whereas the macroscopic lengths, which determine which fields are resonant inside the various cavities, are set separately. So it is possible to change the microscopic tuning of the SRC, which need not necessarily mean that the correct resonance conditions are satisfied. If you are using the Finesse model of the 40m I gave you as a basis for your Optickle model, then the macroscopic length of the SRC in that was ~5.38m. In this configuration, the f2 (i.e. 55MHz sideband) field is resonant inside the SRC while the f1 and carrier fields are not.

If we decide to change the macroscopic length of the SRC, there may also be a small change to the requirements on the RoCs of the RC folding mirrors. Actually, come to think of it, the difference in macroscopic cavity lengths explains the slight differences in mode-matching efficiencies I was seeing between the arms and RCs I was seeing before.

 Quote: Yes, this SRC detuning is very close to extreme signal recycling (0° in this convention), and the homodyne angle is close to the amplitude quadrature (90° in this convention). For T(SRM) = 5% at the optimal angles (SRC detuning of -0.01° and homodyne angle of 89°), we can see 0.7 dBvac at 210 Hz.

13515   Sun Jan 7 20:11:54 2018 KojiUpdatePonderSqueezeDisplacement requirements for short-term squeezing

In fact, that is my point. If we use signal recycling instead of resonant sideband extraction, the "tuning" of the SRC is opposite to the current setup. We need to change the macro length of the SRC to make 55MHz resonant with this tuning. And if we make the SRC macro length together with the PRC macro length for this reason, we need to thing again about the mode matching. Fortunately, we have the spare PRM (T=5%) which matches with this curvature. This was the motivation of my question. We may also choose to keep the current SRM because of its higher T and may want to evaluate the effect of expected mode mismatch.

256   Wed Jan 23 12:31:36 2008 AndreySummarySUSDissapointing Results of XARM optimization (PDF-file)

I attach a PDF-file which summarizes briefly the results of measurements/calculations of Q-factors for ITMX mass as a function of suspension damping gain,

and this file contains the results of measurements of RMS peaks on the values of suspension gains of ITMX and ETMX (see ELOG entries from December 2007, specifically #202, #199, #194)),
but now those dependences are plotted in Q-ITMX and Q_ETMX axes.

Unfortunately, there are no clear narrow areas of minimum in those dependences (that explains the sad title of this ELOG entry).

The attached pdf-file can be shown as a short presentation for a wall during our Wednesday meeting.
8559   Thu May 9 15:07:51 2013 JenneUpdateGeneralDistances from CAD drawing

Since I keep asking Manasa to "measure" distances off of the CAD drawing for me, I thought I might just write them all down, and quit asking.

So, these are only valid until our next vent, but they're what we have right now.  All distances are in meters, angles in degrees.

4696   Wed May 11 23:02:52 2011 valeraUpdateASSDither angular stabilizitaion system update

This is what was done in past two days:

- The ETMY and ITMY pitch and yaw dofs are modulated at 40, 44, 42, 46 Hz respectively (oscillator A=30). The c1ass lockin numbers are 12, 14, 27, 29.

- The NAS55I signal is demodulated at the above frequencies. The demodulated I/Q signal phase is set to shift all signal into I-phase. The lockin inputs are bandpassed around respective frequency f with butter("Bandpass",2,f-0.5,f+0.5). The demod signals are then additionally low passed with butter ("Lowpass",4,0.5) so the servo ugf has to be below 0.5 Hz. The servo filter is p:z 0.0001:0.1.

- The ETMY demodulated signal is fed back to ITMY and visa versa.

- With the above 2x2 servo running we moved the input beam PZTs by hand to follow the cavity.

- At the end we offloaded the servo control signals to the SUS biases again by hand.

- The beam spot centering was estimated by unbalancing the ETMY/ITMY pitch/yaw coil combinations intentionally by 5%, which produces 1.3 mm shift of the node, and comparing the response to the residual signals.

- The dof set up currently is: ETMY pitch lockin 12 -> dof2, ITMY pitch lockin 14 -> dof4, ETMY yaw lockin 27 -> dof7, ITMY yaw lockin 29 -> dof9

- The next step is to demodulate the TRY(X) and servo the input beam PZTs

5165   Wed Aug 10 02:40:40 2011 JennyUpdatePSLDither freq for PZT chosen: 2.418 MHz

I've finished using the network analyzer to characterize find a dither frequency for driving the PZT to use in my PDH locking. I found a region in which the amplitude response of the PZT is low: The dip is centered at 2.418 MHz. Changing the NPRO laser temperature by 100mK has no significant effect on the transfer function in that region. I will post plots tomorrow.

I'm finished with the network analyzer. It is unplugged, and the cart is still near the PSL table. (I'll roll it back tomorrow when it won't disturb interferometer locking).

I closed the shutter on the NPRO at the end of the night.

Tomorrow I plan to put together the fast locking setup. I'll drive the PZT at 2.418 MHz. More details to come tomorrow.

10581   Wed Oct 8 03:20:46 2014 JenneUpdateLSCDo we need AO for acquisition?

As part of trying to determine whether we require the AO path for lock acquisition, or if we can survive on just digital loops, I looked at the noise suppression that we can get with a digital loop.

I took a spectrum of POX, and calibrated it using a line driving ETMX to match the ALSX_FINE_PHASE_OUT_HZ channel, and then I converted green Hz to meters.

I then undid the LSC loop that was engaged at the time (XARM FMs 1,2,3,4,5,8 and the pendulum plant), to infer the free running arm motion.

I also applied the ALS filters (CARM FMs 1,2,3,5,6) and the pendulum plant to the free running noise to infer what we expect we could do with the current digital CARM filters assuming we were not sensor noise limited.

In the figure, we see that the free running arm displacement is inferred to be about 0.4 micrometers RMS.  The in-loop POX signal is 0.4 picometers RMS, which (although it's in-loop, so we're not really that quiet) is already better than 1/10th the coupled cavity linewidth.  Also, the CARM filters that we use for the ALS lock, and also the sqrtInvTrans lock are able to get us down to about 1 pm RMS, although that is not including sensor noise issues.

For reference, here are the open loop gains for the LSC filters+pendulum and ALS filters+pendulum that we're currently using.  The overall gain of these loops have been set so the UGF is 150Hz.

It seems to me that as long as our sensors are good enough, we should be able to keep the arm motion down to less than 1/10th or 1/20th the coupled cavity linewidth with only the digital system.  So, we should think about working on that rather than focusing on engaging the AO path for a while.

Attachment 3: CARMnoise_7Oct2014.zip
1272   Wed Feb 4 19:22:57 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ?
I also estimated the mode matching degradation caused by the astigmatism.
Since the incident angles to the mode matching mirrors are not 0, the effective focal lengths in the incident plane and the perpendicular plane are different.
This effect leads to astigmatism of the beam.
When there is astigmatism, the maximum achievable mode matching rate becomes less than 100%.
According to my calculation, the mode matching cannot be better than 94% for the input beam.
For the output mode matching, we can theoretically achieve more than 99% even with the astigmatism.
The difference comes from the fact that the OMMT is longer, thus the incident angle is smaller.

If we don't like this 94%, we have to use off-axis parabolic mirrors, or modify the IMMT to a longer one.
I prefer to make it longer. Just 5" elongation will increase the mode matching rate to 99.4%.
We have a room for this 5" elongation.

Again, the details of the calculation are added to the Mathematica notebook below.

 Quote: I did mode matching calculations for the new optical layout. For the input mode matching, we have to change the focal length of the second mirror from 687mm to 315mm and the distance between the two MMT mirrors from 137mm to 149.2mm. For the mode matching to the OMC, we only have to change the distance between the OMMT mirrors from 384mm to 391mm. No need to change the mirrors. Details of the calculations can be found in http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecyclingCavities.zip (Mathematica notebook) or if you prefer PDF, here http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_08/Optical_Layout?action=AttachFile&do=get&target=NewRecCav.pdf
1274   Thu Feb 5 10:42:33 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ? No way !
I made a mistake in estimating the astigmatism problem.
If we use the current MMT1 as it is, this one is already an off-axis parabolic (OAP) mirror.
In this case, the astigmatism of this mirror is very small (if we use it with the correct angle). I did not include this effect in the previous calculation.
It turned out that the maximum achievable mode matching becomes far smaller (only 77%) if we use the OAP for MMT1 and a spherical mirror for MMT2.
This is not acceptable.
The reason behind this is that when we use spherical mirrors for both MMT mirrors, the astigmatism caused by the MMT1 is somewhat canceled by the astigmatism of MMT2. We don't get this cancellation if we mix OAP and spherical mirrors.

We should either (1) change MMT1 to a spherical mirror and keep the length of the input MMT as it is, or (2) change MMT1 to a spherical mirror and elongate the length of the input MMT.
In the case of (1) the maximum achievable mode matching is 94%. The focal length of MMT2 should be 315.6mm.
If we do (2), the mode matching rate can be as high as 99.8%. The focal lengths are MMT1 = -301.3mm, MMT2=558mm. The distance between the mirrors is 262mm.
We have enough space to do this elongation. But we have to mechanically modify the MMT mount.
I prefer (2).

As usual, the document on the Wiki was updated to include the above calculations.
11113   Sat Mar 7 18:53:48 2015 JenneUpdateLSCDoF selector matrices replaced with filter banks

This is work that I did yesterday but didn't have time to elog.  Since it seems non-trivial to give ourselves ramping matrices, but we only really needed the ramping in the DoF selector matrices, I've replaced the separate _A and _B parts with full filterbanks.  Recall from elog 10910 that I had given each degree of freedom's _A and _B input options an offset, an epics monitor and a test point.  Now those are removed, and handled inside of the filter banks.  The outputs of the filter banks sum together.

This required some screen modifications, but everything should work the same way that it did before this change.  I've also changed the DAQ channels from the _A_ERR and _B_ERRs that I had hand-created to now be the _A_OUT and _B_OUT test points from the filter banks (acquired at 2048Hz).

I have not yet modified the burt snapshots for the ifo configure screen.  The arms will work the same as always, since they didn't have any selector matrix stuff ever, but the rest still need tweaking.

Attachment 1: DoFselectors_7March2015.png
16249   Fri Jul 16 16:26:50 2021 gautamUpdateComputersDocker installed on nodus

I wanted to try hosting some docker images on a "private" server, so I installed Docker on nodus following the instructions here. The install seems to have succeeded, and as far as I can tell, none of the functionality of nodus has been disturbed (I can ssh in, access shared drive, elog seems to work fine etc). But if you find a problem, maybe this action is responsible. Note that nodus is running Scientific Linux 7.3 (Nitrogen).

13858   Thu May 17 13:51:35 2018 Jon RichardsonConfigurationElectronicsDocumentation & Schematics for AUX-PSL PLL

[Jon, Gautam]

Attached is supporting documentation for the AUX-PSL PLL electronics installed in the lower PSL shelf, as referenced in #13845.

Some initial loop measurements by Gautam and Koji (#13848) compare the performance of the LB1005 vs. an SR560 as the controller, and find the LB1005 to be advantageous (a higher UGF and phase margin). I have some additional measurements which I'll post separately.

## Loop Design

Pickoffs of the AUX and PSL beams are routed onto a broadband-sensitive New Focus 1811 PD. The AUX laser temperature is tuned to place the optical beat note of the two fields near 50 MHz. The RF beat note is sensed by the AC-coupled PD channel, amplified, and mixed-down with a 50 MHz RF source to obtain a DC error signal. The down-converted term is isolated via a 1.9-MHz low-pass filter in parallel with a 50 Ohm resistor and fed into a Newport LB1005 proportional-integral (PI) servo controller. Controller settings are documented in the below schematic. The resulting control signal is fed back into the fast PZT actuator input of the AUX laser.

## Hardware Photos

13876   Tue May 22 10:14:39 2018 Jon RichardsonConfigurationElectronicsDocumentation & Schematics for AUX-PSL PLL

Quote:

[Jon, Gautam]

Attached is supporting documentation for the AUX-PSL PLL electronics installed in the lower PSL shelf, as referenced in #13845.

Some initial loop measurements by Gautam and Koji (#13848) compare the performance of the LB1005 vs. an SR560 as the controller, and find the LB1005 to be advantageous (a higher UGF and phase margin). I have some additional measurements which I'll post separately.

## Loop Design

Pickoffs of the AUX and PSL beams are routed onto a broadband-sensitive New Focus 1811 PD. The AUX laser temperature is tuned to place the optical beat note of the two fields near 50 MHz. The RF beat note is sensed by the AC-coupled PD channel, amplified, and mixed-down with a 50 MHz RF source to obtain a DC error signal. The down-converted term is isolated via a 1.9-MHz low-pass filter in parallel with a 50 Ohm resistor and fed into a Newport LB1005 proportional-integral (PI) servo controller. Controller settings are documented in the below schematic. The resulting control signal is fed back into the fast PZT actuator input of the AUX laser.

## Hardware Photos

Attachment 1: Schematic_PLL.pdf
11823   Mon Nov 30 10:41:45 2015 yutaroUpdateLSCDoes a baffle in front of ETMY have effect on loss map measurement?

It might have, so I think I need to estimate shift of beam spot more preciely.

According to Steve's drawing, radius of the hole of the baffle is 19.8 mm.

Intensity distribution of fundamental mode in x axis direction is this (y is integrated out):

$I(x)=\frac{1}{\sqrt{2\pi(w/2)^2}}e^{-\frac{1}{2}\left(\frac{x}{w/2}\right)^2}$

With the radius of curvature of ETMY of 60 m and the arm length of 37.78 m, the beam width $w$ on ETMY is estimated to be 5.14 mm. From this expression of the intensity, $\int^\infty_{x=9.56\mathrm{mm}}\mathrm{d}xI(x)=100\,\mathrm{ppm},\,\int^\infty_{x=10.00\mathrm{mm}}\mathrm{d}xI(x)=50\,\mathrm{ppm}$, for example. If round trip loss is considered, these values are doubled.

Although maximum shift of beam spot from the ideal spot on ETMY is estimated to be sqrt(6.0^2+(1.7+1.7)^2)=6.9 mm, this value could have error of several tens of % because I am not sure to what exten the calibration is precise, which means that the maximum shift could be ~10 mm and seperation between the baffle and the beam could be ~10 mm.

Therefore, I need to check how much the beam spot shifts with another way, maybe with captured image of the CCD camera.

11828   Mon Nov 30 17:17:30 2015 yutaroUpdateLSCDoes a baffle in front of ETMY have effect on loss map measurement?

With captured images of ETMYF, I measured the shift of the beam spot on ETMY.

The conclusions are:

the baffle would have almost no effect on loss map measurement and

the calibration of beam spot shift is confirmed to be not so bad.

What I did:

I captured ETMYF images in the cases that (i)beam spot is centered on ETMY, beam spot is at the rightest and lowest point of my loss map measurement (corresponding to [0,0] component of the matrix shown in elog 11818), and beam spot is at the leftest and highest point of my loss map measurement ([4,4] component). Each captured image is attached.

Then using ImageJ, I measured the shift of the beam spot. I calibrated lengh in horizontal direction and vertical direction with the diameter of the mirror.

Results:

The amount of the beam shift was 7.2 mm and 8.0 mm for each case.

These values indicate that clapping loss due to the baffle is less than 10 ppm in a round trip.

Today's results support the previous calibration with oplev, which says the amount of the beam shift is 7.0 mm. Two values derived by different calibrations coincide within ~10 % though they are totally different methods. This also support the calibration of the oplev for ETMY (elog 11785) indirectly.

Attachment 1: element2-2.png
Attachment 2: element0-0.png
Attachment 3: element4-4.png
7321   Thu Aug 30 19:08:08 2012 JenneUpdateVACDogs on BS, ITM chambers checked

I tightened as many of the dog clamps on the bottom of the BS, ITMX and ITMY chambers as I could find.  I used a torque wrench at 45 ft-lbs.  Some of the bolts of the dogs were too long, and I couldn't find an extender thing to accommodate the bolt so I could reach the nut.  None of the bolts moved that I was able to reach.

Steve, we're not doing final final alignment today (we will do it tomorrow), so please go around and double-check my work by checking all of the dogs first thing in the morning.  Thanks.

14487   Wed Mar 20 12:31:30 2019 JonUpdateVACDoing vac controls work

I'm rebooting the IOLAN server to load new serial ports. The interlocks might trip when the pressure gauge readbacks cut out.

14489   Wed Mar 20 20:07:22 2019 JonUpdateVACDoing vac controls work

Work is completed and the vac system is back in its nominal state.

 Quote: I'm rebooting the IOLAN server to load new serial ports. The interlocks might trip when the pressure gauge readbacks cut out.

10029   Wed Jun 11 20:09:37 2014 ZachConfigurationWikiDokuWiki situation

I have been looking into the DokuWiki situation, with no great progress so far.

The problem is with authentication. When you try to access the wiki, you get: "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin."

As Evan points out, this goes away if you turn off ACL (Access Control Lists), but---as he also mentions---that just means that authentication is disabled, so the wiki becomes open. All signs point to this being a problem with the authentication mechanism. We use the 'authplain' plaintext method, where the usernames and hashed passwords are stored in a plaintext file.

Evan and I have both done plenty of testing with the config settings to see if the problem goes away. Even if you restore everything to default (but enable ACL using authplain and the existing user file), you still get an error.

I went as far as installing a brand new wiki on the web server, and, surprisingly, this also exhibits the problem. Interestingly, if I install an old enough version (2012-10-13), it works fine. After this revision, they transitioned their authentication methods from "backends" to "plugins", so this is a clue. As a side note, the other wikis on nodus (ATF and Cryo) are running earlier versions of DokuWiki, so they have no problems.

As it stood, our options were:

1. No wiki (not even read-only, since the issue prevents logging in and also prevents anonymous reading, somehow)
2. No ACL = open wiki. Also not good.

So, I created a temporary read-only version of the wiki using the aforementioned earlier DokuWiki release. It has a soft link to the real wiki data, but I deleted the user database so no one can log in and edit (I also disabled registration). It can be found at https://nodus.ligo.caltech.edu:30889/wiki_ro/.

I also created a backup of the real wiki as wiki_bak to avoid any potential disasters.

The simplest thing to do would be to just roll the wiki back to this working version, but that doesn't sound so smart. Clearly, it was working with the plugin structure before our snafu, and somehow our fixing everything else has broken it.

Quote:

 Quote: It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

I went into local.php and changed $conf['useacl'] = 1; to$conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

10021   Tue Jun 10 19:11:27 2014 EvanConfigurationWikiDokuWikis are back up

As of this writing, the DokuWiki appears to be working.

As you and I suspected, it looks like this was a clusterwhoops with the permissions for the NFS mount. Let's recap what happened in the past 24 hours:

1. Yesterday, 8 PM: I restart the Apache server, thereby resurrecting the SVN (now conveniently located at /export/home/svn). The DokuWikis remain borked.
2. Yesterday, 7 to 11 PM: Zach, Rana, and Jenne perform deep magic to get the front-end machines up and running again. This should be irrelevant for this Apache/SVN/DokuWiki witchcraft.
3. Today, morning: the townsfolk happily resume their svn up and svn ci festival.
4. Today, ca. 3 PM: Zach runs stopapache.sh to bring down Apache, thinking he can bring it back up momentarily with startapache.sh. But NFS is a jealous and vengeful god, and Apache now complains that it doesn't have permission to write to its logfiles, and therefore can't start httpd.
5. Today, 5 PM: "How can this be?", Zach and I ask. Apache had no problem starting up yesterday night, and to our knowledge nobody futzed with chiara's NFS mount of /home/cds. This change remains mysterious to us.

Despite the aforementioned mystery, Zach and I pressed on and tried to diagnose the permissions issue. We found that even if you are logged into nodus or pianosa or rossa or whatever as the controls user, the NFS mount saw us as the user nobody (in the group nogroup). If we created a file on the NFS mount, it was owned by nobody/nogroup. If we tried to modify a file on the NFS mount that was owned by controls/controls or controls/staff, we got a "permission denied" error, even if we tried with superuser privileges.

It turns out this has to do with the vagaries of NFS (scroll down to gotcha #4). We have all_squash enabled in /etc/exports , which means that no matter your username or group on nodus, rossa, pianosa, or harpischordsa, NFS coerces your UID/GID to chiara's nobody/nogroup. Anyway, the fix was to go into chiara's /etc/exports and change this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,insecure)

to this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001,insecure)

where 1001/1001 are the UID/GID for chiara's controls/controls (as opposed to 65534/65534 for chiara's nobody/nogroup). That way, the NFS mount sees you as chiara's controls/controls.

In order to make chiara's NFS daemon aware of the new /etc/export settings, I ran sudo exportfs -r based on the answer to this StackOverflow question. As with all the best StackOverflow questions, the moderators closed it for being "off-topic".

[Edit, 2014-06-11, 11 AM: I've repeated the above anonuid/anongid change for the /home/cds/caltech/home/controls mount, so that nodus's /home/controls is writeable as well. I've also added a .screenrc for nodus in order to maintain sanity.]
10022   Wed Jun 11 05:16:14 2014 ZachConfigurationWikiDokuWikis are back up

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

 Quote: As of this writing, the DokuWiki appears to be working.

10024   Wed Jun 11 10:15:15 2014 EvanConfigurationWikiDokuWikis are back up

Quote:

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

 Quote: As of this writing, the DokuWiki appears to be working.

I went into local.php and changed $conf['useacl'] = 1; to$conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

10366   Mon Aug 11 23:50:38 2014 ranaConfigurationWikiDokuWikis are back up

Quote:

 Quote: It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

I went into local.php and changed $conf['useacl'] = 1; to$conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

There was still some residual permissions issue. This is now bypassed and so the ACL is ON and all seems to be back the way it was. I've tested that I can login and edit the wiki.

Some useless knowledge follows here. Please ignore.

After some hours of reading unhelpful DokuWiki blogs, I just put the backup wiki into the local disk on NODUS and then made a soft link to point to that from /users/public_html/wiki/. So this implies that the new NFS setup on chiara is different enough that it doesn't allow read/write access to the apache user on the NODUS/Solaris machine.

12935   Mon Apr 10 15:22:46 2017 ranaConfigurationWikiDokuWikis are back up

AIC Wiki updated to latest stable version of DokuWiki: 2017-02-19b "Frusterick Manners" + CAPTCHA + Upgrade + Gallery PlugIns

10019   Tue Jun 10 11:54:36 2014 ZachConfigurationWikiDokuWikis are still down

Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)

I get:

# DokuWiki Setup Error

The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer

4809   Mon Jun 13 15:33:55 2011 Jamie, JoeUpdateCDSDolphin fiber between 1Y3 and 1X4 appears to be dead

The fiber that connects the Dolphin card in the c1lsc machine (in the 1Y3 rack) to the Dolphin switch in the 1X4 rack appears to have died spontaneously this morning.  This was indicated by loss of Dolphin communication between c1lsc and c1sus.

We definitively tracked it down to the fiber by moving the c1lsc machine over to 1X4 and testing the connection with a short cable.  This worked fine.  Moving it back to using the fiber again failed.

Unfortunately, we have no replaced Dolphin fiber.  As a work around, we are stealing  a long computer->IO chassis cable from Downs and moving the c1lsc machine to 1X4.

This is will be a permanent reconfiguration.  The original plan was to have the c1lsc machine also live in 1X4.  The new setup will put the computer farther from the RF electronics, and more closely mimic the configuration at the sites, both of which are good things.

4815   Tue Jun 14 09:25:17 2011 JamieUpdateCDSDolphin fiber tested with c1sus, still bad

The bad Dolphin was still bad when tested with a connection between c1sus and the Dolphin swtich.

I'm headed over to Downs to see if we can resolve the issue with the PCIe extension fiber.

4045   Mon Dec 13 11:56:32 2010 josephb, alexUpdateCDSDolphin is working

## Problem:

The dolphin RFM was not sending data between c1lsc and c1sus.

## Solution:

Dig into the controller.c code located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/.  Find this bit of code on line 2173:

2173 #ifdef DOLPHIN_TEST 2174 #ifdef X1X14_CODE 2175         static const target_node = 8; //DIS_TARGET_NODE; 2176 #else 2177         static const target_node = 12; //DIS_TARGET_NODE; 2178 #endif 2179         status = init_dolphin(target_node);

Replace it with this bit of code:

2173 #ifdef DOLPHIN_TEST 2174 #ifdef C1X02_CODE 2175         static const target_node = 8; //DIS_TARGET_NODE; 2176 #else 2177         static const target_node = 4; //DIS_TARGET_NODE; 2178 #endif 2179         status = init_dolphin(target_node);

Basically this was hard coded for use at the site on their test stands.  When starting up, the dolphin adapter would look for a target node to talk to, that could not be itself.  So, all the dolphin adapters would normally try to talk to target_node 12, unless it was the X1X14 front end code, which happened to be the one with dolphin node id 12.  It would try to talk to node 8.

Unfortunately, in our setup, we only had nodes 4 and 8.  Thus, both our codes would try to talk to a nonexistent node 12.  This new code has everyone talk to node 4, except the c1x02 process which talks to node 8 (since it is node 4 and can't talk to itself).

I'm told this stuff is going away in the next revision and shouldn't have this hard coded stuff.

## Different Dolphin Problem and Fix:

Apparently, the only models which should have pciRfm=1 are the IOP models which have a dolphin connection.  Front end models that are not IOP models (like c1lsc and c1rfm) should not have this flag set.  Otherwise they include the dolphin drivers and causes them and the IOP to refuse to unload when using rmmod.

So pciRfm=1 only in IOP models using Dolphin, everyone else should not have it or should have pciRfm=-1.

Current CDS status:

 MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Dolphin RFM Sim.Plant Frame builder TDS
5841   Tue Nov 8 17:48:21 2011 MirkoUpdateCDSDolphin weirdness

Had since yesterday evening some trouble with getting a channel from rfm on c1sus to oaf on c1lsc via dolphin. Several restarts of c1lsc and c1sus didn't help. At some point this morning a restart of c1lsc helped. Everything ok again.
At the bad time the dolphin TF looked like this:

Should be flat at gain 1 and no phase change obviously.

184   Mon Dec 10 13:54:26 2007 robHowToComputer Scripts / ProgramsDon't blame the Matlab compiler

For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution...
4985   Mon Jul 18 21:06:32 2011 PSL Table GuardianOmnistructurePSLDon't leave the PSL table open, unattended!!!!!!!!!!!!11111

I found the PSL table left open, and unattended again.

As far as I know, Jamie and Jenne (working on the LSC rack, so no lasers / optics work involved) have been the only ones in the IFO room for several hours now.

I'm going to start taking laser keys, or finding other suitable punishments.  Like a day of lab cleanup chores or something.  Seriously, don't leave the PSL table open if you're not actively working on it.

602   Mon Jun 30 13:48:47 2008 John, RobConfigurationPSLDon't put the bin in front of the air conditioning unit
We spotted that the laser power was dropping.

The air conditioning unit was blocked by the blue bin/trash can/cestino causing the laser head temp to increase by 2 degrees.

Attachment 1: binremoval.png
603   Mon Jun 30 14:07:26 2008 RobConfigurationPSLDon't put the bin in front of the air conditioning unit

 Quote: We spotted that the laser power was dropping.

the offending configuration:
Attachment 1: DSC_0140.png
12376   Thu Aug 4 17:57:09 2016 KojiConfigurationGeneralDon't restart apache2 - nodus /etc/apache2/sites-available/* accidentally deleted

Late coming elog about the deletion of the apahce config files

Thu Aug 4 8:50ish 2016

I accidentally deleted four files in /etc/apache2/sites-available / on nodus. The deleted files were

elog   nodus  public_html  svn

I believe public_html is not used as it is not linked from /etc/apache2/sites-enabled

They are the web server config files and need to be reconfigured manually. We have no backup.

Currently all the web services are running as it was. However, once apache2 is restarted, we'll lose the services.

7278   Sun Aug 26 20:58:21 2012 JenneUpdateVACDon't vent!!!!

[Koji, Jenne]

Steve, do not vent tomorrow morning!  We are still not prepared, and will not finish the preparation tonight.  Hopefully we can finish the prep tomorrow, and then vent Tues.

Things we need to do before the vent:

MC spots centered [Jenne, tonight]

Use PZT2, BS to hit ~center of ETMs.

Realign arms, measure spot positions.

Make sure BS, ITMs are good - we want a good AS spot since we'll likely have to adjust some AS optics while we're inside

Insert attenuation optics, recover MC trans by rotating PBS cube to translate beam slightly

2961   Thu May 20 20:03:37 2010 JenneUpdateSAFETYDon't walk down the Y(new convention) arm tonight!

Please don't go down the Yarm (Old Xarm) for right now, or if you do, please be very careful.  Kiwamu and I are set up to take beam scan measurements down the walkway, and so there are some cables / carts / other stuff down there.  We are going to get dinner really quickly before beginning the measurements.

Right now, the PSL shutter is Closed, so there is no beam hazard outside of the chambers, just crowded space hazard.

2962   Fri May 21 00:21:24 2010 JenneUpdateSAFETYDon't walk down the Y(new convention) arm tonight!

All clear.

 Quote: Please don't go down the Yarm (Old Xarm) for right now, or if you do, please be very careful.  Kiwamu and I are set up to take beam scan measurements down the walkway, and so there are some cables / carts / other stuff down there.  We are going to get dinner really quickly before beginning the measurements.  Right now, the PSL shutter is Closed, so there is no beam hazard outside of the chambers, just crowded space hazard.

11837   Wed Dec 2 15:08:41 2015 ericqUpdateComputer Scripts / ProgramsDonatella sudo problem resolved

Somehow, the controls user account on donatella lost its membership to the sudoers group, which meant doing anything that needs root authentication was impossible.

I fixed this by booting up from a Linux install USB drive, mounting the HD, and running useradd controls sudo

14578   Thu Apr 25 18:14:42 2019 AnjaliUpdatePSLDoor broken

It is noticed that one of the doors (door # 2 ) of the PSL table is broken. Attachement #1 shows the image

Attachment 1: IMG_6069.JPG
16867   Fri May 20 12:42:23 2022 TegaUpdateVACDoor installation on the end stations

[JC, Tega, Chub]

Today we installed the 200 lbs doors on the end station chambers.

15932   Wed Mar 17 15:02:06 2021 gautamUpdatesafetyDoor to outside from control room was unlocked

I came into the lab a few mins ago and found the back door open. I closed it. Nothing obvious seems amiss.

Caltech security periodically checks if this door is locked but it's better if we do it too if we use this door for entry/exit.

15938   Thu Mar 18 12:35:29 2021 ranaUpdatesafetyDoor to outside from control room was unlocked

I think this is probably due to the safety tour yesterday. I beleive Jordan showed them around the office area and C&B. Not sure why they left through the control room.

 Quote: I came into the lab a few mins ago and found the back door open. I closed it. Nothing obvious seems amiss. Caltech security periodically checks if this door is locked but it's better if we do it too if we use this door for entry/exit.

7432   Mon Sep 24 16:59:31 2012 JenneUpdateVACDoors on, ready to pump

[The 40m Family]

The access connector and all heavy doors are back on.

Jamie put the regular viton EQ stops back on PRM, since he had to adjust the distance between the EQ stops and the PRM anyway.  Jamie also waved an IR card near the IPANG steering mirrors in ETMY, but it was not possible to take a good photo.  Jamie certifies that the beam is centered on both of those 2 optics.

I have centered IPPOS and IPANG QPDs.

All oplevs need a little realignment, especially ETMY, which had it's lens removed (Rana has a Wall of Shame photo of this, which is why it was removed by him).  Steve will look into this tomorrow, after he starts pumping.

I have turned off all PZT high voltage supplies for in-vac PZTs: The input PZTs, the output PZTs, and the OMC PZTs (which weren't on, but I confirmed they were off).

I have also prepared the 3 low-power items for high power: MC refl's path was changed back to regular BS, AS camera was moved to its nominal position, and IPPOS has its ND filters back.  MC refl and the AS camera will need to be realigned once we're actually at high power tomorrow afternoon.

Long vent, but good work everyone.

 Quote: All oplevs need a little realignment, especially ETMY, which had it's lens removed (Rana has a Wall of Shame photo of this, which is why it was removed by him).  Steve will look into this tomorrow, after he starts pumping.

The shame:

There is no situation in which it is OK to install a mount like this. Steve had installed this flaky and shaky mount to optimize the beam size on the OL QPD.

Everyone in the lab should know better. Putting in something like this is just like sabotage - it creates extra noise in our interferometer in a sneaky way and just makes locking harder. All mounts for anything useful (including QPDs) must have highly rigid mounts.

Use the example from the PSL relayout: use the 3/4" steel mounts and the wide aluminum bases from Newport. No more art projects using home made mounting crap, Steve.

7250   Wed Aug 22 16:50:09 2012 JenneUpdateLockingDouble integrator in ARM LSC servos

Last week, Rana changed the integrators in the arm LSC servo filters to be double integrators with complex poles.

Yesterday, I found that using the "timeout" feature of Foton (at filter ON/OFF request, waits for zero crossing, or T seconds, whichever comes first) is useful for turning on the integrators, but bad for turning them off.  When we're locked, the error signal is oscillating around zero, so there is often a zero crossing.  When we lose lock, we want to turn off the filter immediately.  But, as soon as lock is lost, the input signal gets large, and doesn't often cross zero, so the filter waits 8 seconds until actually turning off.  If the arm flashes any time during that 8 sec, we send a big kick to the optics.

An alternative option could be ramping the filter on.  However, since the double integrator has -180deg phase at low frequencies (until the poles at ~5Hz), the transition between no filter (0deg phase) and integrator on could be problematic.  I simulated this, and find that for the very beginning of the ramping process, we would have a problem.

The filter is defined as:  NoFilter * (1 - R) + Integrator * (R), so for R=0, the integrator is off, and for R=1, the integrator is fully on.  R can be any value [0,1].

The first figure is the time series (1 second, 16kHz), ramp goes from 0->1 or 1->0 in 1 second:

The second figure is bode plots for selected values of R:

As R gets smaller and smaller, the notch goes to lower frequency, and becomes higher Q.  So perhaps ramping is not a good answer here.

What if we go for single or triple integrator, to get rid of the (+1) + (-1) problem?

11516   Wed Aug 19 01:45:10 2015 IgnacioUpdateIOODoubly Improved SISO (T240-X) FF of MCL

Today I tried and doubly-improved SISO FF filter on MCL. This filter has a stronger rolloff than the previous SISO filters I have tried. The rolloff most definelty helped towards reducing the ammount of noise being injected into YARM. Below is the usual stuff:

Filter:

T240-X (SISO)

Training data + Predicted FIR and IIR subtraction:

Online subtraction results:

MCL
YARM
MCL TRANS

Subtraction performace:

3583   Fri Sep 17 12:11:42 2010 josephbUpdateCDSDowns update

In doing a re-inventory prior to the IOO chassis installation, I re-discovered we had a missing interface board that goes in an IO chassis.  This board connects the chassis to the computer and lets them talk to each other.  After going to Downs we remembered Alex had taken a possibly broken interface board back to downs for testing.

Apparently the results of that testing was it was broken.  This was about 2.5 months ago and unfortunately it hadn't been sent back for repairs or a replacement ordered.  Its my fault for not following up on that sooner.

I asked Rolf what the plan for the broken one was.  His response was  they were planning on repairing it, and that he'd have it sent back for repairs today.  My guess the turn around time for that is on the order of 3-4 weeks (based on conversations with Gary), however it could be longer.  This will affect when the last IO chassis (LSC) can be made fully functional.  I did however pickup the 100 foot fiber cable for going between the LSC chassis and the LSC computer (which will be located in 1X3).

As a general piece of information, according to Gary the latest part number for these cards is OSS-SHB-ELB-x4/x8-2.0 and they cost 936 dollars (latest quote).

5824   Sun Nov 6 16:58:25 2011 ZachUpdateSUSDr. SUS failed--NDS2 problems again

Dr. SUS failed while trying to get the sensor data. Specifically, it couldn't get ETMY data. This is odd, because in my tribulations last week I ended up having to add the ETMY_SENSOR channels manually into the NDS2 channel files. After doing this, I was able to get ETMY data just fine (though I admitted that we would have problems again as soon as we wanted to update the channel files). I even ran the diagAllSUS code in a sandbox and it pulled data---and generated input matrices---just fine.

The error persists even if I try to get the data manually:

>> d = NDS2_GetData({'C1:SUS-ETMY_SENSOR_UL'},t0,10,'mafalda.martian:31200');

Connecting.... authenticate done

Warning: daq_recv_next failed

??? Error using ==> NDS2_GetData

Fatal Error getting channel data.

I think Jamie is still waiting for J.Z.'s help with this, but it is probably pointless to keep trying to run this code before NDS2 is working again. Another option is to just use NDS, but I think certain people are opposed to this.

ELOG V3.1.3-