40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 325 of 330  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  5362   Wed Sep 7 20:44:11 2011 SureshUpdateelogrestarted

Elog crashed / dormant for long time.  A look at the log file indicated that it was busy generating png thumbnails for pdf files.

Restarted at Wed Sep  7 20:41:13 PDT 2011

 

  5556   Tue Sep 27 11:43:59 2011 JenneUpdateelogElog has been dying a lot lately...

WTF?

  5739   Tue Oct 25 21:23:17 2011 DmassBureaucracyelogElog Restarted

Elog went nonreponsive. SSH'ed into nodus to run restart script. Elog came back ~15 minutes later.

  5750   Fri Oct 28 02:41:18 2011 SureshMetaphysicselogelog unresponsive: restarted

Elog did not respond despite running the /cvs/cds/caltech/elog/start-elog.csh  script two times.  

It worked the after the third restart. 
 

  5785   Wed Nov 2 14:07:25 2011 ZachUpdateelogrestarted

Elog was hanging, restarted with the script.

  5828   Mon Nov 7 11:50:42 2011 JenneUpdateelogRestarted elog

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

  5829   Mon Nov 7 12:51:44 2011 ZachUpdateelogRestarted elog

I've noticed that it always takes running the script twice for it to actually work. I think there's something wrong with how it's doing it. I'll mess with it sometime the elog isn't getting much use.

Quote:

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

 

  5855   Wed Nov 9 19:08:18 2011 SureshUpdateelogrestarted elog

Elog was not responding and was restarted.

  5870   Fri Nov 11 00:58:19 2011 DenUpdateelogrestarted elog

Elog suspended 2 times for 1 hour. Too high frequency.

Restarted.

  5902   Wed Nov 16 01:45:37 2011 ZachUpdateelogrestarted

Elog was hanging. Restarted it with script.

  5903   Wed Nov 16 02:36:35 2011 KojiUpdateelogrestarted

Basically, elog hangs up by the visit of googlebot.

Googlebot repeatedly tries to obtain all (!) of entries by specifying  "page0" and "mode=full".
Elogd seems not to have the way to block an access from the specified IP.
We might be able to use http-proxy via apache. (c.f. http://midas.psi.ch/elog/adminguide.html#secure)

Or can we tweak the source of elod such that it does not accept "page0"?


GET /40m/page0?mode=full&new_entries=1 HTTP/1.1
Host: 131.215.115.52:8080
Connection: Keep-alive
Accept: */*
From: googlebot(at)googlebot.com
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Accept-Encoding: gzip,deflate

 

Quote:

Elog was hanging. Restarted it with script.

 

  5908   Wed Nov 16 10:13:13 2011 jamieUpdateelogrestarted

Quote:

Basically, elog hangs up by the visit of googlebot.

Googlebot repeatedly tries to obtain all (!) of entries by specifying  "page0" and "mode=full".
Elogd seems not to have the way to block an access from the specified IP.
We might be able to use http-proxy via apache. (c.f. http://midas.psi.ch/elog/adminguide.html#secure)

 There are much more simple ways to prevent page indexing by googlebot: http://www.google.com/support/webmasters/bin/answer.py?answer=156449

However, I really think that's a less-than-idea solution to get around the actual problem which is that the elog software is a total piece of crap.  If google does not index the log then it won't appear in google search results.

But if there is one url that when requested causes the elog to crash then maybe it's a better solution to cut of just that url.

  5911   Wed Nov 16 12:21:33 2011 KojiUpdateeloggooglebot (Re: restarted)

- elogd itself is a sort of web server which has no freedom to put our own file, we can not put robots.txt

- If we include elog using proxy in the usual web tree of Apache, we can put robots.txt at the root.

- So far, if we prevent "page0" browse by google, we will be saved for a while.

- It seems that the indexing is set to be refused by the following meta tags. But it does not prohibit googlebot to use "page0" URL, of course.

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
  5936   Fri Nov 18 00:25:10 2011 ZachUpdateelogrestarted

 with script.

  5977   Tue Nov 22 14:39:50 2011 JenneUpdateelogAfternoon elog restart

Gave the elog its afternoon / tea-time reboot, since it was hanging yet again.

  5985   Wed Nov 23 00:30:55 2011 ZachUpdateelogsucks

Tried the script 3 times and it didn't come back. Pkill'd and then scripted. That worked.

  6001   Thu Nov 24 14:42:57 2011 KojiUpdateelogelogd gained an immunity to googlebot

I modified elogd.c as shown below in order not to allow to display all of the entries at once by specifying page number "0".

After this modification, elog seems to have survived 66 times of attacks by googlebots.

==============================

rossa:src>pwd
/cvs/cds/caltech/elog/elog-2.8.0/src

rossa:src>diff elogd.c_orig elogd.c
19912a19913,19917
>
>    /* KA */
>    if (page_n<1)
>      page_n = 1;
>

  6003   Thu Nov 24 15:48:27 2011 IllustratorUpdateelogelogd gained an immunity to googlebot

elog_mario.png

golden-monkey.jpeg

 

 

  6443   Mon Mar 26 12:50:24 2012 ZachUpdateelogrestarted with script

On the plus side, it was the first time I've had to do it in a while..

  7136   Thu Aug 9 12:55:15 2012 ZachUpdateelogelog was being a pain in the ass; I restarted it

The elog was not responding. I attempted to restart it by running .../start-elog.csh, but this didn't work (even after the usual ~2 times it needs).

Somehow pkill did not kill the daemon, so I kill -9'd it and that did the trick. I ran the start script once more and it came back online.

  7351   Thu Sep 6 17:06:25 2012 Rijuparna ChakrabortyConfigurationelogCavitymode scan

 Aim: to scan the cavitymodes of IMC

The circuit used: 

 Attachment4

Results obtained:

Attachment 1,2,3

 

Attachment 1: 3.pdf
3.pdf
Attachment 2: 2.pdf
2.pdf
Attachment 3: 1.pdf
1.pdf
Attachment 4: cavityscanconnections.pdf
cavityscanconnections.pdf
  7435   Mon Sep 24 20:28:13 2012 ranaSummaryelogrestarted elog: was unresponsive
  8586   Wed May 15 23:38:04 2013 ranaUpdateelogcategories trimmed

I deleted a bunch of useless categories from the 40m elogd.cfg file. IF you find your category has been deleted, you can now learn how to categorize yourself into the existing categories. ELOG restarted and log file zeroed.

  9603   Wed Feb 5 18:36:56 2014 ranaFrogselogMicroSoft BingBot is attacking us

 The ELOG was frozen, with this in the .log file:   

GET /40m/?id=1279&select=1&rsort=Type HTTP/1.1

Cache-Control: no-cache

Connection: Keep-Alive

Pragma: no-cache

Accept: */*

Accept-Encoding: gzip, deflate

From: bingbot(at)microsoft.com

Host: nodus.ligo.caltech.edu

User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

  (hopefully there's a way to hide from the Bing Bot like we did from the Google bot)

 

  10006   Fri Jun 6 14:56:09 2014 ericqUpdateelogAaaaaand we're back!

ELOG is back up and running after last Friday's disk-crash-a-thon. SVN is still a work in progress. Jenne and I are now restarting computers and such.

  10096   Wed Jun 25 01:18:24 2014 AkhilUpdateelogWeekly Update

 Plans for the Week:

  • Phase and noise characterization of the UFC RF Frequency Counter.
  •  Characterization of the temperature actuator.

Progress and Problems Faced:

  • Since past two days, I have been trying to measure the phase difference between the input and output signals of the FC using a 16 bit ADC ADS1115 (for input phase measurement) on Raspberry Pi(RPI).For that I have assembled a Circuit on a breadboard( Details will be mentioned in my next eLog). 
  • The interfacing and the codes seem to be alright but the RPI is not able to detect the address of the ADC chip. I will try to debug the issue as soon as possible and try to take data through the Pi so that I can have both delay and noise introduced by the FC.
  • Now since the minimum sampling time of the FC has been brought down to 0.1s, I will test how accurately the FC is writing values every 0.1 s for a modulating input.
  • The output data of the FC will be fitted into the input and the order of accuracy will be presented.Also the gain plots will be plotted at higher frequencies like 50 MHz, 100 MHz, 500 MHz and 1000 MHz using the network analyzer.

Work Inside the Lab:

  • On Friday Morning I will  go inside the  lab with Manasa to make measurements from the NPRO to characterize its response to the temperature.
  • I will be in the lab in the morning session(9 am- 1 pm) and make the required measurements. I will then analyze the data and by the end of the week will finish characterization of the FC and temperature actuator.
  • For the rest of the time in this week, I'll be on my desk and will not be entering  the lab.

Electronics Required:

  • I will require the network analyzer on Wednesday and Thursday to make measurements at higher frequencies(30 MHz <F<1000 MHz) from the R PI.

Goal- By the end of the week:

  • To characterize both the FC and the NPRO that would go into the FOL-PID loop.
  • The FC will be ready to replace the network analyzers that are currently being used in the 40m.

 

 

 

 

 

  10101   Wed Jun 25 14:52:22 2014 Andres MedinaUpdateelogPlacing a lens between the steering mirrors and another lens between the second steering mirror and the cavity

 I was asked to calculate the lenses that we need in order to obtained a Gouy phase close to 90 degrees between the two mirrors that are in the Xend green. Yesterday, I measured the distances between the mirrors, and the distance between the mirror relative to the cavity as illustrate in the image attached below. I looked in to the 40m elog and Manasa did the last update on the length of the cavity. She measured 37.7 + 0.05m. The waist size of the beam that was measured by Annalisa in ID 8637 after the Faraday was w0=2.943e-5m @ -0.039m. I calculated the waist size inside the cavity, and I found a waist of w0=2.2 mm. My plan this week is to keep working in the calculation and finish all the calculation this week so that next week I can go inside and place the lenses. 

Attachment 1: SchematicForXendGreenGoingToTheCavity.pdf
SchematicForXendGreenGoingToTheCavity.pdf
  10309   Thu Jul 31 18:54:03 2014 ChrisFrogselogMicroSoft BingBot is attacking us

Quote:

 The ELOG was frozen, with this in the .log file:   

GET /40m/?id=1279&select=1&rsort=Type HTTP/1.1

Cache-Control: no-cache

Connection: Keep-Alive

Pragma: no-cache

Accept: */*

Accept-Encoding: gzip, deflate

From: bingbot(at)microsoft.com

Host: nodus.ligo.caltech.edu

User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

  (hopefully there's a way to hide from the Bing Bot like we did from the Google bot)

 

Yesterday elog was excruciatingly slow, and bingbot was the culprit. It was slurping down elog entries and attachments so fast that it brought nodus to its knees. So I created a robots.txt file disallowing all bots, and placed it in the elog's scripts directory (which gets served at the top level). Today the log feels a little snappier -- there's now much less bot traffic to compete with when using it.

We might be able to let selected bots back in with a crawl rate limit, if anyone misses searching the elog on bing.

  10311   Thu Jul 31 21:21:49 2014 KojiFrogselogMicroSoft BingBot is attacking us

Oh, this is cool! Thanks!
I could not figure out how to place robot.txt as it was not so obvious how elogd handles the files in the "logfile" directory.

  10827   Mon Dec 22 13:34:34 2014 KojiUpdateelogStrange ELOG serach

I tried to find my own entry and faced with a strange behavior of the elog.

The search button invoked the following link and no real search has been done:

http://nodus.ligo.caltech.edu:8080/40m/?mode=summvry&reverse=0&reverse=1&npp=50&m&y&Authorthor=Koji

Summvry? Authorthor?

If I ran the following link, it returned correct search. So something must be wrong.

http://nodus.ligo.caltech.edu:8080/40m/?mode=summary&npp=50&Author=Koji

  10830   Mon Dec 22 16:21:15 2014 ericqUpdateelogStrange ELOG search

In order to fix ELOG search, I have started running ELOG v2.9.2 on Nodus.

Sadly, due to changes in the software, we can no longer use one global write password. Instead, we must now operate with registered users.

Based on recent elog users, I'll be creating user accounts with the following names, using the same old ELOG write password. (These will be valid across all logbooks)

  • ericq
  • rana
  • koji
  • diego
  • jenne
  • manasa
  • Steve
  • Kate
  • Zach
  • Evan
  • Aidan
  • Chris
  • Dmass
  • nicolas
  • Gabriele
  • xiaoyue

All of these users will be "Admins" as well, meaning they can add new users and change settings, using the "Config" link.

Let me know if I neglected to add someone, and sorry for the inconvenience.

RXA: What Eric means to say, is that "upgrading" from Solaris to Linux broke the search and made us get a new elog software that;s worse than what we had.

  10839   Tue Dec 23 16:49:32 2014 ericqUpdateelogStrange ELOG search

 So, despite having registered users, it turns out that the "Author" field is still open for editing when making posts. I.e. we don't really need to make new accounts for everyone. 

Thus, I've made a user named "elog" with the old write password that can write to all ELOGs. 

(Also, I've added a user called "jamie")

  11002   Wed Feb 11 16:49:41 2015 ranaUpdateelogELOGD restarted

No elog response from outside and no elogd process frownon nodus, so I restarted it using 'start-elog.csh'.

  11251   Sun Apr 26 00:08:56 2015 ranaHowToelogTroubles with putting plots in external locations

If it all possible, don't use links to your home directory. Its not robust. It would be like if you clicked on your Google Music and it told you to ask me to sing that song to you. Imagine that on auto-repeat next time your fancy-bone itches.

Attachment 1: 48.png
48.png
  12049   Sat Mar 26 18:28:24 2016 KojiUpdateelogelogd flakiness

Elogd have been restarted several times today because it died everytime I submit something.
Here is the copy of the log.


GET /OMC_Lab/255?cmd=loc&value=Submit HTTP/1.1
Returned 6 bytes
GET /40m/elog.rdf HTTP/1.1
Returned 17109 bytes
TCP connection #1 on socket 5 closed
POST /OMC_Lab/ HTTP/1.1
Returned 20 bytes
GET /OMC_Lab/255 HTTP/1.1
Returned 53721 bytes
GET /ckeditor/skins/moono/images/arrow.png HTTP/1.1
Returned 489 bytes
POST /OMC_Lab/ HTTP/1.1
*** buffer overflow detected ***: /export/home/elog/elog/elogd terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f1435639e57]
/lib/x86_64-linux-gnu/libc.so.6(+0x108d50)[0x7f1435638d50]
/lib/x86_64-linux-gnu/libc.so.6(+0x1081b9)[0x7f14356381b9]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0xdd)[0x7f14355ab0cd]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x25a8)[0x7f143557ac18]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x94)[0x7f1435638254]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7f143563819d]
/export/home/elog/elog/elogd[0x426405]
/export/home/elog/elog/elogd[0x473b7f]
/export/home/elog/elog/elogd[0x4abfb2]
/export/home/elog/elog/elogd[0x4ad7fb]
/export/home/elog/elog/elogd[0x4b0af5]
/export/home/elog/elog/elogd[0x4b1eb9]
/export/home/elog/elog/elogd[0x403568]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f143555176d]
/export/home/elog/elog/elogd[0x404299]
======= Memory map: ========
00400000-004e6000 r-xp 00000000 fc:00 10361276                           /export/home/elog/elog-3.0.d/elogd
006e5000-006e6000 r--p 000e5000 fc:00 10361276                           /export/home/elog/elog-3.0.d/elogd
006e6000-007c6000 rw-p 000e6000 fc:00 10361276                           /export/home/elog/elog-3.0.d/elogd
007c6000-0173d000 rw-p 00000000 00:00 0
0214d000-02656000 rw-p 00000000 00:00 0                                  [heap]
7f14342f8000-7f143430d000 r-xp 00000000 fc:00 2883628                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f143430d000-7f143450c000 ---p 00015000 fc:00 2883628                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f143450c000-7f143450d000 r--p 00014000 fc:00 2883628                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f143450d000-7f143450e000 rw-p 00015000 fc:00 2883628                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f143450e000-7f14348cd000 rw-p 00000000 00:00 0
7f1434a34000-7f1434d39000 r--p 00000000 fc:00 530477                     /usr/lib/locale/locale-archive
7f1434d39000-7f1434d4f000 r-xp 00000000 fc:00 655527                     /usr/local/lib/libz.so.1.2.8
7f1434d4f000-7f1434f4e000 ---p 00016000 fc:00 655527                     /usr/local/lib/libz.so.1.2.8
7f1434f4e000-7f1434f4f000 r--p 00015000 fc:00 655527                     /usr/local/lib/libz.so.1.2.8
7f1434f4f000-7f1434f50000 rw-p 00016000 fc:00 655527                     /usr/local/lib/libz.so.1.2.8
7f1434f50000-7f1434f52000 r-xp 00000000 fc:00 2883655                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f1434f52000-7f1435152000 ---p 00002000 fc:00 2883655                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f1435152000-7f1435153000 r--p 00002000 fc:00 2883655                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f1435153000-7f1435154000 rw-p 00003000 fc:00 2883655                    /lib/x86_64-linux-gnu/libdl-2.15.so
7f1435154000-7f1435307000 r-xp 00000000 fc:00 2883609                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f1435307000-7f1435506000 ---p 001b3000 fc:00 2883609                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f1435506000-7f1435521000 r--p 001b2000 fc:00 2883609                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f1435521000-7f143552c000 rw-p 001cd000 fc:00 2883609                    /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f143552c000-7f1435530000 rw-p 00000000 00:00 0
7f1435530000-7f14356e4000 r-xp 00000000 fc:00 2884139                    /lib/x86_64-linux-gnu/libc-2.15.so
7f14356e4000-7f14358e3000 ---p 001b4000 fc:00 2884139                    /lib/x86_64-linux-gnu/libc-2.15.so
7f14358e3000-7f14358e7000 r--p 001b3000 fc:00 2884139                    /lib/x86_64-linux-gnu/libc-2.15.so
7f14358e7000-7f14358e9000 rw-p 001b7000 fc:00 2884139                    /lib/x86_64-linux-gnu/libc-2.15.so
7f14358e9000-7f14358ee000 rw-p 00000000 00:00 0
7f14358ee000-7f1435943000 r-xp 00000000 fc:00 2884155                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f1435943000-7f1435b42000 ---p 00055000 fc:00 2884155                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f1435b42000-7f1435b45000 r--p 00054000 fc:00 2884155                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f1435b45000-7f1435b4c000 rw-p 00057000 fc:00 2884155                    /lib/x86_64-linux-gnu/libssl.so.1.0.0
7f1435b4c000-7f1435b6e000 r-xp 00000000 fc:00 2884145                    /lib/x86_64-linux-gnu/ld-2.15.so
7f1435d57000-7f1435d5c000 rw-p 00000000 00:00 0
7f1435d6a000-7f1435d6e000 rw-p 00000000 00:00 0
7f1435d6e000-7f1435d6f000 r--p 00022000 fc:00 2884145                    /lib/x86_64-linux-gnu/ld-2.15.so
7f1435d6f000-7f1435d71000 rw-p 00023000 fc:00 2884145                    /lib/x86_64-linux-gnu/ld-2.15.so
7ffd85795000-7ffd85997000 rw-p 00000000 00:00 0                          [stack]
7ffd859b2000-7ffd859b4000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
er_id"
Received unknown cookie "ajs_group_id"
Received unknown cookie "ajs_anonymous_id"
Received unknown cookie "__utma"
Received unknown cookie "_ga"
Received unknown cookie "__unam"
Received unknown cookie "__utma"
Received unknown cookie "tk_ni"
Received unknown cookie "ajs_user_id"
Received unknown cookie "ajs_group_id"
Received unknown cookie "ajs_anonymous_id"
Received unknown cookie "cache_disable"
Received unknown cookie "NO_CACHE"
Received unknown cookie "__utma"
Received unknown cookie "_ga"
Received unknown cookie "__unam"
Received unknown cookie "__utma"
Received unknown cookie "tk_ni"
Received unknown cookie "ajs_user_id"
Received unknown cookie "ajs_group_id"
Received unknown cookie "ajs_anonymous_id"
Received unknown cookie "__utma"
Received unknown cookie "_ga"
Received unknown cookie "__unam"
Received unknown cookie "__utma"
Received unknown cookie "tk_ni"
Received unknown cookie "ajs_user_id"
Received unknown cookie "ajs_group_id"
Received unknown cookie "ajs_anonymous_id"
Received unknown cookie "__utma"
Received unknown cookie "_ga"
Received unknown cookie "__unam"
Received unknown cookie "__utma"
Received unknown cookie "tk_ni"
Received unknown cookie "ajs_user_id"
Received unknown cookie "ajs_group_id"
Received unknown cookie "ajs_anonymous_id"
Received unknown cookie "__utma"
Received unknown cookie "_ga"
Received unknown cookie "__unam"
Received unknown cookie "__utma"
Received unknown cookie "tk_ni"
Received unknown cookie "ajs_user_id"
Received unknown cookie "ajs_group_id"
Received unknown cookie "ajs_anonymous_id"
  12764   Fri Jan 27 19:40:03 2017 ranaMetaphysicselogword wrapping & large images

"Why does the word wrapping not work in our browsers with ELOG?" I sometimes wonder. Some of the elogs are fine, but often the 40m one has the text run off the page.

I found that this is due to people uploading HUGE images. If you need to do this, just use the shrink feature in the elog compose window so that we only have to see the thumbnail at first. Otherwise your 12 MP images will make it hard to read everyone else's entries.

  13879   Tue May 22 17:29:27 2018 keerthanaUpdateelogMEDM Diagram for the auxilary laser system control and display.

(keerthana, gautam, jon)

In the morning, Jon gave me an overview of the Auxiliary laser system which we are planning to setup. Based on the diagram he uploaded in the elog, I have made the MEDM diagram for controlling and displaying the parameters. Here the parameters which we will be controlling are temperature (in terms of voltage), oscilator frequency ( with the help of IFR 2023B), the frequency offset and the PID controls. The display includes the beat frequency, error signal voltage, control voltage and a switch to give feed back to the AUX laser. As the frequency counter is not connected at the moment, I haven't included its channel number in it. The screenshot of the diagram is attached with this. I am also considering to give a PID feedback to the slow control from the AUX feedback signal. The screen can be accessed from the PSL dropdown menu in sitemap.

Attachment 1: MEDM_aux.png
MEDM_aux.png
  13926   Thu Jun 7 14:35:26 2018 keerthanaUpdateelogTable- useful for doing the scanning.

I think this table will help us to fix the scanning range of the Marconi frequency. This will also help in predicting the position of the resonance peak corresponding to the injected frequency.

fdiff = fm ±80 MHz ;                     fdiff = N*FSRy ;              FSRy = 3.893 MHz.

N = Integer number fdiff =injected fm = Marconi frequency
1 3.893 76.107
2 7.786 72.214
3 11.679 68.321
4 15.572 64.428
5 19.465 60.535
6 23.34 56.66
7 27.251 52.749
8 31.144 48.856
9 35.037 44.963
10 38.93 41.07
11 42.79 37.21
12 46.716 33.284
13 50.609 29.391
  13938   Mon Jun 11 11:45:13 2018 keerthana UpdateelogComparison of the analytical and finesse values of TMS and FSR.
Quantity Analytical Value Finesse Value Percentage Error
Free Spectral range (FSR) 3.893408 MHz 3.8863685 MHz 0.180 %
Transverse Mode Spacing (TMS) 1.195503 MHz 1.1762885 MHz 1.607 %

The values obtained from both analytical and finesse solution is given in the above table along with the corresponding percentage errors.finesse1.pdf

The parameters used for this calculation are listed below.

Parameter Value
length of the cavity (L) 38.5 m
Wavelength of the laser beam (\lambda) 1064 nm
Radius of curvature of ITM (R1) \infty
Radius of curvature of ETM (R2) 58 m

The cavity scan data obtained from Finesse is also attached here.

Attachment 1: finesse1.pdf
finesse1.pdf
  13941   Mon Jun 11 18:10:51 2018 Koji UpdateelogComparison of the analytical and finesse values of TMS and FSR.

Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?

  13943   Mon Jun 11 19:16:49 2018 keerthanaUpdateelogComparison of the analytical and finesse values of TMS and FSR.

The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

But inorder to find the finesse value, I just used curser to get the central frequency of each peak and by substracting one from the other I found TMS and FSR.

The resolution was 6500 Hz. Thus, it seems that this method is not actually reliable. I am trying to find the central frequency of each mode with the help of lorentzian fits. I am attaching a fit which I did today. I have plotted its residual graph also.

I am uploading 4 python scripts to the github.

1. Analytical Solution

2. Finesse model- cavity scan

3. Finesse model- fitting

4. Finesse model- residual

Quote:

Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?

fitting_1.pdf

Attachment 1: fitting_1.pdf
fitting_1.pdf
  13944   Mon Jun 11 22:05:03 2018 KojiUpdateelogComparison of the analytical and finesse values of TMS and FSR.

> The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

Yes, I this does not give us 0.70%

(3.893408 - 3.8863685)/3.893408 *100 = 0.18%

But any way, go for the fitting.

  13945   Mon Jun 11 22:18:18 2018 keerthanaUpdateelogComparison of the analytical and finesse values of TMS and FSR.

Oopss !! I made a mistake while taking the values from my notes. Sorry.

Quote:

> The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

Yes, I this does not give us 0.70%

(3.893408 - 3.8863685)/3.893408 *100 = 0.18%

But any way, go for the fitting.

 

  13954   Wed Jun 13 11:59:03 2018 keerthanaUpdateelogcommand line enabled code for frequency scanning

I have modified the code for frequency scanning and have made it completely command line enabled. The code is written in python. It is saved in the name "frequency_scanning_argparse.py". I have uploaded it to the Mode-Spectroscopy Github repository.

Inorder to use this code there are two ways.

1. We can mention the ' frequency' on which marconi need to work. Then it will change the marconi frequency to that perticular value.

eg: Type in the terminal as follows for changing the marconi frequency to 59 Mhz.

python frequency_scanning_argparse.py 59e6

2. Inorder to give a scan to the marconi frequency, provide the 'start frequency', 'end frequency' and the 'number of points' in between. This will be more conveniant when we want to run the scan in different ranges.

eg: Type in the terminal as follows for a start frequency of 59 Mhz, end frequency of 62MHz and number of points in between equal to 1000.

python frequency_scanning_argparse.py 59e6 62e6 1000

In both cases the code will show you the frequency of the marconi before we run this code and it will change the marconi frequency to the desired frequency.

  13995   Thu Jun 21 13:24:00 2018 keerthanaUpdateelogThe cavity scan data of June 20

(Jon, Keerthana, Sandrine)

We tried to align the AUX and PSL laser yesterday. We collected the data from the spectrum analyser for the Y-ARM reflection and also for the Y-ARM transmission from the ETM mirror. I am attaching the plots here.

Attachment 1: AS110_Beat.pdf
AS110_Beat.pdf
Attachment 2: YEND_Beat.pdf
YEND_Beat.pdf
  14039   Thu Jul 5 17:33:36 2018 keerthana, sandrineUpdateelogLights not working
  • N/S ARM FL.
  • N/S ARM INC.

These two lights inside the 40m-lab are not working.

  14040   Thu Jul 5 17:58:04 2018 keerthana, sandrineUpdateelog 

(Analisa, Sandrine, Keerthana)

Today Annalisa helped us to understand the new set up used to make the frequency scans of the AUX laser. While tracking the cables it seemed that there were quite a lot of cables near the mixer. So we have reconnected one of the splitter which was splitting the RF out put signal from the Agilent and have placed it just near the Agilent itself. A picture of the changed setup is provided below. The splitter divides the signal into two components. One goes to the LO port of the mixer and the other goes to the R port of the Agilent. We have tried locking the PLL after the change and it works fine. We are trying to make a diagram of the setup now, which we will upload shortly.

 

Attachment 1: setup1.jpg
setup1.jpg
Attachment 2: setup2.jpg
setup2.jpg
  14057   Thu Jul 12 14:06:39 2018 keerthanaUpdateelogFinesse and Analytical solution - Comparison

I tried to compare the cavity scan data we get from the Finesse simulation and that we expect from the Analytical solution. The diagram of the cavity I defined in Finesse is given below along with the values of different quantities I used. For the analytical solution I have used two different equations and they are listed below.

Analytical 1 - Blue Graph

\phi = \frac {2.L.\Omega_1}{c}

t_{cav} = \frac{t_e. t_f \exp^{-i\frac{\phi}{2}}}{1- r_f. r_e \exp^{-i\phi} }

T_{cav} = \left|{t_{cav}} \right|^2

 

Analytical 2 - Red Graph

F = \frac {4. r_f.r_e}{(1-r_f.r_e )^2}

\phi = \frac {2.L.\Omega_1}{c}

T_{cav} = \left|{t_{cav}} \right|^2 = \frac {(t_e.t_f)^2}{(1 - r_f . r_e)^2} \frac{1}{1+F(\sin\frac {\phi}{2})^2}

The graph obtained from both these solutions completely matches with each other.

Finesse Solution

The cavity which I defined in Finesse is shown below. The solution from Finesse and the Analytical solution also matches with each other. Another plot is made by taking the difference between Finesse solution and Analytical solution. The difference seems to be of the order of \approx 10^{-19}.

The Difference plot is also attached below.

Attachment 1: finesse_cavity.png
finesse_cavity.png
Attachment 2: Analytical1.pdf
Analytical1.pdf
Attachment 3: Finesse_Analytical.pdf
Finesse_Analytical.pdf
Attachment 4: Difference.pdf
Difference.pdf
  14336   Fri Dec 7 19:42:47 2018 ranaFrogselogcan't upgrade DokuWiki because of PHP / SL7

All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.

I tried this recently and it fails with this message:

DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
! New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!

So we'll have to wait until SL7 (which is what NODUS is running).

I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):

> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version

  15274   Fri Mar 13 12:48:47 2020 Larry WallaceUpdateelogCert Renewal

Updated the cert in /etc/httpd/ssl. The new cert is good until March 12, 2022.

ELOG V3.1.3-