40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 77 of 341 Not logged in
ID Date Author Type Category Subject
13329   Sun Sep 24 20:47:15 2017 ranaUpdateComputer Scripts / ProgramsRF TF Uncertainties

I have made several changes to Craig's script for better pythonism. Its more robust with different libraries and syntaxes and makes a tarball by default (w/o a command line flag). These kinds of general util scripts will be going into a general use folder in the git.ligo.org/40m/ team area so that it can be used throughout the LSC.

I don't think we need/want a coherence calculation, so I have not included it. Usually, we use coherence to estimate the uncertainty, and here we are just plotting it directly from the dist of the sweeps so coherence seems superfluous.

Attachment 1: TFAG4395A_21-09-2017_115547_FourSquare.pdf
Attachment 2: TFAG4395A_21-09-2017_115547.tgz
13330   Mon Sep 25 17:56:33 2017 johannesUpdateComputer Scripts / Programstransmitted power during lossmap

I had to do a reboot + burt restore of c1psl today. It was unresponsive and I couldn't get the PMC to lock. I also had to slightly realign the PMC, and the IMC was too misaligned for the autolocker to catch lock. Adjusting it manually, it was predominantly MC1 PIT that was off. The YARM locked on a 10 mode and had to be aligned manually as well.

I left a script running on Donnatella that tilts ETMX and thus moves the beam on ITMX. I'm monitoring the transmitted power to evaluate sane thresholds for the demodulation offsets in a lossmap measurement. The script will return the IFO to normal after it is done and will take <2 hours to complete (no real clue, but there's no way it takes longer than that for ~50 datapoints).

13464   Thu Dec 7 11:14:37 2017 johannesHowToComputer Scripts / ProgramsLots of red on the FE status screen

Since we're getting ready to put the replacement slow DAQ for c1auxex in I wanted to bring the IFO back to operating condition after the PMC hasn't been locked for days. Something seems wrong with the CDS system though, many of the frontent models have red background and don't seem to be responsive. I followed the instructions laid out in https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures.

In the attached screenshot, initially all c1ioo models were red, and on c1iscex only c1x01 was blue, the other ones red. I was able to ssh into both machines and tried to restart indivitual models, which didn't work and instead turned their background white. Still following the wiki page, I restarted both machines but they don't respond to pinging anymore and thus I cannot use ssh to reach them. Not sure what to do, I also rebooted fb over telnet.

So far I couldn't find any records of how to fix this situation.

Attachment 1: 22.png
13465   Thu Dec 7 15:02:37 2017 KojiHowToComputer Scripts / ProgramsLots of red on the FE status screen

Once a realtime machine was rebooted, it did not come back. I suspect that the diskless hosts have a difficulty to boot up.

Attachment 1: DSC_0552.JPG
13466   Thu Dec 7 15:46:31 2017 johannesHowToComputer Scripts / ProgramsLots of red on the FE status screen

[Koji, Johannes]

The issue was partially fixed and the interferometer is in workable condition now.

What -probably- fixed it was restarting the dhcp server on chiara

sudo service isc-dhcp-server restart

Afterwards the frontends were restarted one by one. SSH access was possible and the essential models for IFO operation were started.

c1iscex reported initially that no DAQ card was found, and inside the IO chassis the LED indicator strip was red. Turning off the machine, checking the cables and rebooting fixed this.

Attachment 1: 04.png
13524   Wed Jan 10 14:17:57 2018 johannesConfigurationComputer Scripts / Programsautoburt no longer making backups

I was looking into setting up autoburt for the new c1auxex2 and found that it stopped making automatic backups for all machines after the beginning of the new year. There is no 2018 folder (it was the only one missing) in /opt/rtcds/caltech/c1/burt/autoburt/snapshots and the /latest/ link in /opt/rtcds/caltech/c1/burt/autoburt/ leads to the last backup of 2017 on 12/31/17 at 23:19.

The autoburt log file shows that the back script last ran today 01/10/18 at 14:19, as it should have, but doesn't show any errors and ends with "You are at the 40m".

I'm not familiar with the autoburt scheduling using cronjobs. If I'm not mistaken the relevant cronjob file is /cvs/cds/rtcds/caltech/c1/scripts/autoburt/autoburt.cron which executes /cvs/cds/rtcds/caltech/c1/scripts/autoburt/autoburt.pl

I've never used perl but there's the following statement when establishing the directory for the new backup:

  $yearpath =$autoburtpath."/snapshots/".$thisyear; # print "scanning for path$yearpath\n";   if (!-e $yearpath) { die "ERROR: Year directory$yearpath does not exist\n";   }

I manually created the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2018/ directory. Maybe this fixes the hickup? Gotta wait about 30 minutes.

13525   Wed Jan 10 15:25:43 2018 johannesConfigurationComputer Scripts / Programsautoburt making backups again
 Quote: I manually created the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2018/ directory. Maybe this fixes the hickup? Gotta wait about 30 minutes.

It worked. The first backup of the year is now from Wednesday, 01/10/18 at 15:19. Ten days of automatic backups are missing. Up until 2204 the year folders had been pre-emptively created so why was 2018 missing?

gautam: this is a bit suspect still - the snapshot file for c1auxex at least seemed to be too light on channels recorded. this was before any c1auxex switching. to be investigated.

13603   Fri Feb 2 23:28:13 2018 KojiUpdateComputer Scripts / Programsnetgpib data missing / PROLOGIX yellow box (crocetta) not working

I could not understand why 'netgpibdata' scripts are missing in "scripts/general" folder on pianosa... Where did they go???

Also, I found that the PROLOGIX GPIB-LAN controller for crocetta (192.168.113.108) is no longer working. I need to reconfigure it with "telnet"...

13604   Sat Feb 3 13:03:45 2018 gautamUpdateComputer Scripts / Programsnetgpib data missing / PROLOGIX yellow box (crocetta) not working

The netgpibdata scripts are now under git version control at /opt/rtcds/caltech/c1/scripts/general/labutils/netgpibdata. I think the idea was to make this directory a collection of useful utilities that we could then pull at various labs / at the sites.

 Quote: I could not understand why 'netgpibdata' scripts are missing in "scripts/general" folder on pianosa... Where did they go???
13607   Mon Feb 5 18:04:35 2018 KojiUpdateComputer Scripts / Programsnetgpib data missing / PROLOGIX yellow box (crocetta) not working

crochetta was reconfigured to have 192.168.113.108. It was confirmed that it can be used with netgpibdata.py

Configuration: I have connected my mac with the unit using an Apple USB-Ethernet adapter. The adapter was configured to have a manual IP of 192.168.113.222/255.255.255.0. "netfinder.exe" was run to assign the IP addr to the unit. It seemed that NVRAM of the unit evaporated as it had the IP of 0.0.0.0. Once it was configrued, it could be run with netgpibdata as usual.

13783   Tue Apr 24 10:10:43 2018 gautamUpdateComputer Scripts / ProgramsParticle swarm hyper parameter optimization

I'm copying and pasting Nikhil's email here as he was unable to login to the elog (but should now be able to in order to reply to any comments, and add more details about this test, motivation, methodology etc).

I did some post-processing after running the grid search. The following steps were carried out:

1) Selected those sets whose cost fun were less than a specific threshold (here 10000)

2) Next task was to see if the parameters of these good solutions had some pattern

3) I used a dimensionality reduction technique called t-SNE to project the 6 dimensional parameter space to 2 dim (for better visualization )

4) Made a scatter plot of these (see fig )

5) Used K-Means to find the clusters in this data

6) MarkerSize & Color reflect the cost fun. Bigger the marker size means better the solution.

7) Visual inspection implied cluster 5 had the best ranking points & more than any other cluster

8) These points had the following Parameter set: Workers {20,40}, SwarmSize {500}, MaxIter {500}, Self Adjustment {1}, Social Adjustment {1}, Tolerance {1e-3,1e-8}

     See fig: for the box plot

9) It looks like is a particular set of values rather than individual values that gives the best results.

Attachment 1: ClusterFminScaled.png
Attachment 2: ClusterID_5.png
13801   Mon Apr 30 23:13:12 2018 KevinUpdateComputer Scripts / ProgramsDataViewer leapseconds

I was trying to plot trends (min, 10 min, and hour) in DataViewer and got the following error message

Connecting.... done
mjd = 58235
Opening leapsecs.dat
Open of leapsecs.dat failed

thoough the plots showed up fine after. Do we need to fix something with the leapsecs.dat file?

13929   Thu Jun 7 20:21:15 2018 KojiUpdateComputer Scripts / Programs/cvs/cds Backup in danger

Local backup on chiara seems not working since Nov 19, 2017.
/opt/rtcds/caltech/c1/scripts/backup/localbackup.log

2017-11-18 07:00:01,504 INFO       Updating backup image of /cvs/cds 2017-11-18 07:03:00,113 INFO       Backup rsync job ran successfully, transferred 1954 files. 2017-11-19 07:00:02,564 INFO       Updating backup image of /cvs/cds 2017-11-19 07:00:02,592 ERROR      External drive not mounted!!!

13963   Thu Jun 14 15:21:58 2018 gautamUpdateComputer Scripts / Programs/cvs/cds Backup in danger

I think this is because /cvs/cds is getting too big. lsblk reveals:

controls@chiara|~> lsblk NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT sda      8:0    0 465.8G  0 disk  ├─sda1   8:1    0 446.9G  0 part / ├─sda2   8:2    0     1K  0 part  └─sda5   8:5    0  18.9G  0 part [SWAP] sdb      8:16   0   2.7T  0 disk  └─sdb1   8:17   0     2T  0 part /home/cds sr0     11:0    1  1024M  0 rom   sdc      8:32   0   1.8T  0 disk  └─sdc1   8:33   0   1.8T  0 part /media/40mBackup sdd      8:48   0   1.8T  0 disk  └─sdd1   8:49   0   1.8T  0 part 

I believe one of sdc or sdd is connected via SATA while the other is an external USB drive. Maybe we have to get bigger backup disks, but this may be a huge pain to setup as it will involve taking chiara down. Actually, now that I check the backup log, seems like backup is executing successfully - not sure if this is due to my unelogged mounting of sdc (using sudo mount /dev/sdc1 /media/40mBackup) last week, or if this is some LDAS backup. But in any case, seems undesirable that sdb1 is larger than sdc1 or sdd1.

2018-06-06 07:00:01,086 INFO       Updating backup image of /cvs/cds 2018-06-06 07:00:01,086 ERROR      External drive not mounted!!! 2018-06-07 07:00:01,147 INFO       Updating backup image of /cvs/cds 2018-06-07 07:00:01,147 ERROR      External drive not mounted!!! 2018-06-08 07:00:01,244 INFO       Updating backup image of /cvs/cds 2018-06-08 08:23:32,939 INFO       Backup rsync job ran successfully, transferred 316870 files. 2018-06-09 07:00:01,465 INFO       Updating backup image of /cvs/cds 2018-06-09 07:12:11,865 INFO       Backup rsync job ran successfully, transferred 1926 files. 2018-06-10 07:00:01,842 INFO       Updating backup image of /cvs/cds 2018-06-10 07:12:28,931 INFO       Backup rsync job ran successfully, transferred 1656 files. 2018-06-11 07:00:01,294 INFO       Updating backup image of /cvs/cds 2018-06-11 07:06:14,748 INFO       Backup rsync job ran successfully, transferred 1664 files. 2018-06-12 07:00:02,081 INFO       Updating backup image of /cvs/cds 2018-06-12 07:07:36,775 INFO       Backup rsync job ran successfully, transferred 1870 files. 2018-06-13 07:00:02,194 INFO       Updating backup image of /cvs/cds 2018-06-13 07:08:37,356 INFO       Backup rsync job ran successfully, transferred 1818 files. 2018-06-14 07:00:01,753 INFO       Updating backup image of /cvs/cds 2018-06-14 07:01:43,270 INFO       Backup rsync job ran successfully, transferred 1744 files.
 Quote: Local backup on chiara seems not working since Nov 19, 2017. /opt/rtcds/caltech/c1/scripts/backup/localbackup.log 2017-11-18 07:00:01,504 INFO       Updating backup image of /cvs/cds 2017-11-18 07:03:00,113 INFO       Backup rsync job ran successfully, transferred 1954 files. 2017-11-19 07:00:02,564 INFO       Updating backup image of /cvs/cds 2017-11-19 07:00:02,592 ERROR      External drive not mounted!!!

13978   Mon Jun 18 10:34:45 2018 johannesUpdateComputer Scripts / Programsrunning comsol job on optimus

I'm running a comsol job on optimus in a tmux session named cryocavs. Should be done in less than 24 hours, judging by past durations.

14049   Tue Jul 10 16:59:12 2018 Izabella PastranaHowToComputer Scripts / ProgramsTaking Remote TF Measurements with the Agilent 4395A

I copied the netgpibdata folder onto rossa (under the directory ~/Agilent/), which contains all the necessary scripts and templates you'll need to remotely set up, run, and download the results of measurements taken on the AG4395A network analyzer. The computer will communicate with the network analyzer through the GPIB device (plugged into the back of the Agilent, and whose communication protocol is found in the AG4395A.py file in the directory ~/Agilent/netgpibdata/).

The parameter template file you'll be concerned with is TFAG4395Atemplate.yml (again, under ~/Agilent/netgpibdata/), which you can edit to fit your measurement needs. (The parameters you can change are all helpfully commented, so it's pretty straightforward to use! Note: this template file should remain in the same directory as AGmeasure, which is the executable python script you'll be using). Then, to actually set up, run, and download your measurement, you'll want to navigate to the ~/Agilent/netgpibdata/ directory, where you can run on the command line the following: python AGmeasure TFAG4395Atemplate.yml

The above command will run the measurement defined in your template file and then save a .txt file of your measured data points to the directory specified in your parameters. If you set up the template file such that the data is also plotted and saved after the measurement, a .pdf of the plot will be saved along with your .txt file.

Now if you want to just download the data currently on the instrument display, you can run: python AGmeasure -i 192.168.113.105 -a 10 --getdata

Those are the big points, but you can also run python AGmeasure --help to learn about all the other functions of AGmeasure (alternatively, you can read through the actual python script).

Happy remote measuring! :)

14157   Mon Aug 13 11:44:32 2018 gautamUpdateComputer Scripts / ProgramsPatch updates on nodus

Larry W said that some security issues were flagged on nodus. So I ran

on nodus. The exclude flag is because there were some conflicts related to that particular package. Hopefully this has fixed the problem. It's been a while since the last update, which was in January of this year.

controls@nodus|~> sudo yum history
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
29 | upgrade --exclude=elog-3 | 2018-08-13 11:36 | E, I, U        |  136 EE
28 | install yum-utils        | 2018-08-13 11:31 | Update         |    1
27 | install nmap             | 2018-06-29 01:57 | Install        |    2
26 | install grace            | 2018-05-31 16:52 | Install        |   11
25 | install https://dl.fedor | 2018-05-31 16:51 | Install        |    1
24 | install perl-Digest-SHA1 | 2018-05-31 15:34 | Install        |    1
23 | install python-devel     | 2018-01-13 15:33 | Install        |    1
22 | install gcc              | 2018-01-13 15:32 | Install        |    6
21 | install git              | 2018-01-12 18:11 | Install        |    4
20 | update                   | 2018-01-12 18:01 | I, U           |   39
19 | install motif            | 2018-01-05 17:35 | Install        |    3
18 | install sendmail sendmai | 2017-12-03 05:11 | Install        |    6
17 | install vim              | 2017-11-21 18:12 | Install        |    3
16 | reinstall mod_dav_svn    | 2017-11-21 17:40 | Reinstall      |    1
15 | install mod_dav_svn      | 2017-11-21 17:39 | Install        |    1
14 | install subversion       | 2017-11-21 15:36 | Install        |    2
13 | -y install php           | 2017-11-20 22:15 | Install        |    4
12 | install links            | 2017-11-20 19:10 | Install        |    2
11 | install openssl098e.i686 | 2017-11-18 18:28 | Install        |    1
10 | install openssl-libs.i68 | 2017-11-18 18:26 | Install        |   11
history list
14243   Thu Oct 11 13:40:51 2018 yukiUpdateComputer Scripts / Programsloss measurements
 Quote: This is the procedure I follow when I take these measurements for the XARM (symmetric under XARM <-> YARM): Dither-align the interferometer with both arms locked. Freeze outputs when done. Misalign ETMY + ITMY. ITMY needs to be misaligned further. Moving the slider by at least +0.2 is plentiful to not have the other beam interfere with the measurement. Start the script, which does the following: Resume dithering of the XARM Check XARM dither error signal rms with CDS. If they're calm enough, proceed. Freeze dithering Start a new set of averages on the scope, wait T_WAIT (5 seconds) Read data (= ASDC power and MC2 trans) from scope and save Misalign ETMX and wait 5s Read data from scope and save Repeat desired amount of times Close the PSL shutter and measure the PD dark levels

Information for the armloss measurement:

• Script which gets the data:  /users/johannes/40m/armloss/scripts/armloss_scope/armloss_dcrefl_asdcpd_scope.py
• Script which calculates the loss: /users/johannes/40m/armloss/scripts/misc/armloss_AS_calc.py
• Before doing the procedure Johannes wrote you have to prepare as follows:
• put a PD in anti-symmetric beam path to get ASDC signal.
• put a PD in MC2 box to get tranmitted light of IMC. It is used to normalize the beam power.
• connect those 2 PDs to oscilloscope and insert an internet cable to it.
• Usage: python2 armloss_dcrefl_asdcpd_scope.py [IP address of Scope] [ScopeCH for AS] [ScopeCH for MC] [Num of iteration] [ArmMode]

Note: The scripts uses httplib2 module. You have to install it if you don't have.

The locked arms are needed to calculate armloss but the alignment of PMC is deadly bad now. So at first I will make it aligned. (Gautam aligned it and PMC is locked now.)

gautam: The PMC alignment was fine, the problem was that the c1psl slow machine had become unresponsive, which prevented the PMC length servo from functioning correctly. I rebooted the machine and undid the alignment changes Yuki had made on the PSL table.

14245   Fri Oct 12 12:29:34 2018 yukiUpdateComputer Scripts / Programsloss measurements

With Gautam's help, Y-arm was locked. Then I ran the script "armloss_dcrefl_asdcpd_scope.py" which gets the signals from oscilloscope. It ran and got data, but I found some problems.

1. It seemed that a process which makes arm cavity mislaigned in the script didn't work.
2. The script "armloss_dcrefl_asdcpd_scope.py" gets the signal and the another script "armloss_AS_calc.py" calculates the arm loss. But output file the former makes doesn't match with the type the latter requires. A script converts format is needed.

Anyway, I got the data needed so I will calculate the loss after converting the format.

14248   Fri Oct 12 20:20:29 2018 yukiUpdateComputer Scripts / Programsloss measurements

I ran the script for measuring arm-loss and calculated rough Y-arm round trip loss temporally. The result was 89.6ppm. (The error should be considered later.)

The measurement was done as follows:

1. install hardware
1. Put a PD (PDA520) in anti-symmetric beam path to get ASDC signal.
2. Use a PD (PDA255) in MC2 box to get tranmitted light of IMC. It is used to normalize the beam power.
3. Connect those 2 PDs to oscilloscope (IP: 192.168.113.25) and insert an internet cable to it.
2. measure DARK noise
1. Block beam going into PDs with dampers and turn off the room light.
2. Run the script "armloss_dcrefl_acdcpd_scope.py" using "DARK" mode.
3. measure the ASDC power when Y-arm locked and misaligned
1. Remove dampers and turn off the room light.
2. Dither-align the interferometer with both arms locked. Freeze outputs when done. (Click C1ASS.adl>!MoreScripts>ON and click C1ASS.adl>!MoreScripts>FreezeOutputs.)
3. Misalign ETMX + ITMX. (Just click "Misalign" button.)
4. Further misalign ITMX with the slider. (see previous study: ITMX needs to be misaligned further. Moving the slider by at least +0.2 is plentiful to not have the other beam interfere with the measurement.)
5. Start the script "armloss_dcrefl_acdcpd_scope.py" using "ETMY" mode, which does the following:
1. Resume dithering of the YARM.
2. Check YARM dither error signal rms with CDS. If they're calm enough, proceed. (In the previous study the rms threshold was 0.7. Now "ETM_YAW_L_DEMOD_I" signal was 15 (noisy), then the threshold was set 17.)
3. Freeze dithering.
4. Start a new set of averages on the scope, wait T_WAIT (5 seconds).
5. Read data (= ASDC power and MC2 trans) from scope and save.
6. Misalign ETMY and wait 5s. (I added a code which switchs LSC mode ON and OFF.)
7. Read data from scope and save.
8. Repeat desired amount of times.
4. calculate the arm loss
1. Start the script "armloss_AS_calc.py", whose content is follows:
• requires given parameters: Mode-Matching effeciency, modulation depth, transmissivity. I used the same value as Johannes did last year, which are (huga)
• reads datafile of beam power at ASDC and MC2 trans, which file is created by "armloss_dcrefl_acdcpd_scope.py".
• calculates arm loss from the equation (see 12528 and 12854).

Result:

YARM
('AS_DARK =', '0.0019517200000000003') #dark noise at ASDC
('MC_DARK =', '0.02792') #dark noise at MC2 trans
('AS_LOCKED =', '2.04293') #beam power at ASDC when the cavity was locked
('MC_LOCKED =', '2.6951620000000003')
('AS_MISALIGNED =', '2.0445439999999997') #beam power at ASDC when the cavity was misaligned
('MC_MISALIGNED =', '2.665312')

$\hat{P} = \frac{P_{AS}-P_{AS}^{DARK}}{P_{MC}-P_{MC}^{DARK}}$ #normalized beam power

$\hat{P}^{LOCKED}=0.765,\ \hat{P}^{MISALIGNED}=0.775,\ \mathcal{L}=89.6\ \mathrm{ppm}$

• "ETM_YAW_L_DEMOD_I_OUTPUT" was little noisy even when the arm was locked.
• The reflected beam power when locked was higher than when misaligned. It seemed strange for me at first. Johannes suggested that it was caused by over-coupling cavity. It is possible when r_{ETMY}>>r1_{ITMY}.
• My first (wrong) measurement said the arm loss was negative(!). That was caused by lack of enough misalignment of another arm mirrors. If you don't misalign ITMX enough then the beam or scattered light from X-arm would bring bad. The calculated negative loss would be appeared only when $\frac{\hat{P}^{LOCKED}}{\hat{P}^{MISALIGNED}} > 1 + T_{ITM}$
• Error should be considered.
• Parameters given this time should be measured again.
14251   Sat Oct 13 20:11:10 2018 yukiUpdateComputer Scripts / Programsloss measurements
 Quote: the script "armloss_AS_calc.py", "ETM_YAW_L_DEMOD_I_OUTPUT" was little noisy even when the arm was locked. The reflected beam power when locked was higher than when misaligned. It seemed strange for me at first. Johannes suggested that it was caused by over-coupling cavity. It is possible when r_{ETMY}>>r1_{ITMY}.

Some changes were made in the script for getting the signals of beam power:

• The script sees "C1:ASS-X(Y)ARM_ETM_PIT/YAW_L_DEMOD_I_OUTPUT" and stops running until the signals become small, however some offset could be on the signal. So I changed it into waiting until (DEMOD - OFFSET) becomes small. (Yesterday I wrote ETM_YAW_L_DEMOD_I_OUTPUT was about 15 and was little noisy. I was wrong. That was just a offset value.)
• I added a code which stops running the script when the power of transmitted IR beam is low. You can set this threshold. The nominal value of "C1:LSC-TRX(Y)_OUT16" is 1.2 (1.0), so the threshold is set 0.8 now.

In the yesterday measurement the beam power of ASDC is higher when locked than when misaligned and I wrote it maybe caused by over-coupled cavity. Then I did a calculation as following to explain this:

• assume power transmissivity of ITM and ETM are 1.4e-2 and 1.4e-5.
• assume loss-less mirror, you can calculate amplitude reflectivity of ITM and ETM.
• consider a cavity which consists two mirrors and is loss-less, then $\frac{E_{r}}{E_{in}} = \frac{-r_1+r_2e^{i\phi}}{1-r_1r_2e^{i\phi}}$ holds. r1 and r2 are amplitude reflectivity of ITM and ETM, and E is electric filed.
• Then you can calculate the power of reflected beam when resonated and when anti-resonated. The fraction of these value is $\frac{P_{RESONANT}}{P_{ANTI-RESO}} = 0.996$, which is smaller than 1.
• I found this calculation was wrong! Above calculatation only holds when cavity is aligned, not when misaligned. 99.04% of incident beam power reflects when locked, and (100-1.4)% reflects when misaligned. The proportion is P(locked)/P(misaligned)=1.004, higher than 1.

14254   Mon Oct 15 10:32:13 2018 yukiUpdateComputer Scripts / Programsloss measurements

I used these values for measuring armloss:

• Transmissivitity of ITM = 1.384e-2 * (1 +/- 1e-2)
• Transmissivitity of ETM = 13.7e-6 * (1 +/- 5e-2)
• Mode-Matching efficiency of XARM = 0.912 * (1 +/- 2e-2)
• Mode-Matching efficiency of YARM = 0.867 * (1 +/- 2e-2)
• modulation depth m1 (11MHz) = 0.179 * (1 +/- 2e-2)
• modulation depth m2 = 0.226 * (1 +/- 2e-2),

then the uncertainties reported by the individual measurements are on the order of 6 ppm (~6.2 for the XARM, ~6.3 for the YARM). This accounts for fluctuations of the data read from the scope and uncertainties in mode-matching and modulation depths in the EOM. I made histograms for the 20 datapoints taken for each arm: the standard deviation of the spread is over 6ppm. We end up with something like:

XARM: 123 +/- 50 ppm
YARM: 152+/- 50 ppm

This result has about 40% of uncertaintities in XARM and 33% in YARM (so big... ).

In the previous measurement, the fluctuation of each power was 0.1% and the fluctuation of P(Locked)/P(misaligned) was also 0.1%. Then the uncertainty was small. On the other hand in my measurement, the fluctuation of power is about 2% and the fluctuation of P(Locked)/P(misaligned) is 2%. That's why the uncertainty became big.

We want to measure tiny value of loss (~100ppm). So the fluctuation of P(Locked)/P(misaligned) must be smaller than 1.6%.

(Edit on 10/23)
I think the error is dominated by systematic error in scope. The data of beam power had only 3 degits. If P(Locked) and P(misaligned) have 2% error, then
$\frac{P_L}{P_M}\frac{1}{1+T_{\mathrm{ITM}}} = 0.99(3)$.
You have to check the configuration of scope.

Attachment 1: XARM_20181015_1500.pdf
Attachment 2: YARM_20181015_1500.pdf
 Quote: but there's one weirdness: It get's the channel offset wrong. However this doesn't matter in our measurement because we're subtracting the dark level, which sees the same (wrong) offset.

When you do this measurement with oscilloscope, take care two things:

1. set y-range of scope as to every signal fits in display: otherwise the data sent from scope would be saturated.
2. set y-position of scope to the center and don't change it; otherwise some offset would be on the data.
14258   Tue Oct 16 00:44:29 2018 yukiUpdateComputer Scripts / Programsloss measurements

The scripts for measuring armloss are in the directory "/opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_scope".

• armloss_derefl_asdcpd_scope.py: gets data and makes ascii file.
• armloss_AS_calc.py: calculates armloss from selected a set of files.
• armloss_calc_histogram.py: calculates armloss from selected files and makes histogram.
14268   Fri Nov 2 16:42:31 2018 aaronUpdateComputer Scripts / Programsarm loss measuremenents

I'm continuing the arm loss measurements Yuki was making. I'm first familiarizing myself with the procedures for the measurement Johannes describes.

I'm not very familiar with the medm screens, so I'm just kind of poking around and checking with Gautam. I do the following:

1. Turned Xarm ASS dither on, then off.
2. Turned X and Y ALS on, then off shortly after
1. Realizing I needed some guidance, I found this page on lock acquisition on the wiki
2. Gautam showed me how to align/lock the IFO so I could take some notes, and we locked the Y arm, misaligned X.
3. I put the PD back in the AS beam path to get the ASDC signal, and approximately centered the beam. This PD is on channel 1 of the scope, which is at 192.168.113.24.
4. I centered the beam onto the MC2 PD that Yuki had installed. This PD is on channel 2 of the scope.
1. Both scope channels are set to 1V scale (I also had tried 500mV, and it didn't seem to make a difference) and 10s time axis spacing (maximum integration time, since we're looking for a DC effect. Is this what we want?)
2. The impedance for both channels is 1MOhm.
5. I ran the script to start the loss measurement on the Y arm.
1. python2 armloss_dcrefl_asdcpd_scope.py 192.168.113.24 1 2 5 YARM
2. I'm reading ~15 (au?) for the MC channel and ~5% of that out the AS, which seems to make sense to me and looked to be about what Yuki the ratios when I checked the log files. However, I'm a bit confused by the normalization, because the maximum output of the MC PD is 10V, and indeed the scope's display is reading under 10V.

I've left the script running.

14269   Fri Nov 2 19:25:16 2018 gautamUpdateComputer Scripts / Programsloss measurements

Some facts which should be considered when doing this measurement and the associated uncertainty:

1. When Johannes did the measurement, there was no light from the AS port diverted to the OMC. This represents ~70% loss in the absolute amount of power available for this measurement. I estimate ~1W*Tprm * Ritm * Tbs * Rbs * Tsrm * OMCsplit ~ 300uW which should still be plenty, but the real parameter of interest is the difference in reflected power between locked/no cavity situations, and how that compares to the RMS of the scope readout. For comparison, the POX DC light level is expected to be ~20uW, assuming a 600ppm AR coating on the ITMs.
2. Even though the reflection from the arm not being measured may look like it's completely misaligned looking at the AS camera, the PDA520 which is used at the AS port has a large active area and so one must check on the oscilloscope that the other arm is truly misaligned and not hitting the photodiode to avoid interference effects artifically bloating the uncertainty.
3. The PDA255 monitoring the MC transmission has a tiny active area. I'm not sure the beam has been centered on it anytime recently. If the beam is not well centered on that PD, and you normalize the measurements by "MC Transmission", you're likely to end up with larger error.
 Quote: This result has about 40% of uncertaintities in XARM and 33% in YARM (so big... ).
14270   Mon Nov 5 13:52:18 2018 aaronUpdateComputer Scripts / Programsarm loss measuremenents

After running this script Friday night, i noticed Saturday that the data hadn't saved. Scrolling up inthe terminal, I couldn't see where I'd run the script, so I thought I'd forgotten to run it as I was making last minute changes to the scope settings Friday before leaving.

Monday it turns out I hadn't forgotten to run the script, but the script itself was getting hung up as it waited for ASS to settle, due to the offset on the ETM PIT or YAW setpoints. The script was waiting until both pitch and yaw settled to below 0.7, but yaw was reading ~15; I think this is normal, and it looks like Yuki had solved this problem by waiting for the DEMOD-OFFSET to become small, rather than just the DEMOD signal to be small. Since this is a solved problem, I think I might be using an old script, but I'm pretty sure I'm running the one in Johannes' folder that Yuki is referencing for example here. The scripts in /yutaro_scripts/ have this DEMOD-OFFSET functionality commented out, and anyway those scripts seem to do the 2D loss maps rather than 1D loss measurements.

In the meantime I blocked the beams and ran the script in DARK mode. The script is saving data in /armloss/data/run_20181105/, and runs with no exceptions thrown.

However, when I try to dither align the YARM, I get an error that "this is not a degree of freedom that has an ASS". I'm alsogetting some exceptions from MEDM about unavailable channels. It must have been something about donatella not initializing, because it's working on pianosa. I turned on YARM ADS from pianosa. Monitoring from dataviewer, I see that LSC-TRY_OUT has some spikes to 0.5, but it's mostly staying near 0. I tried returning to the previous frozen outputs, and also stepping around ETMY-[PIT/YAW] from the IFO_ALIGN screen, but didn't see much change in the behavior of LSC-TRY. I missed the other controls Gautam was using to lock before, and I've also made myself unclear on whether ASS is acting only on angular dof, or also on length.

I unblocked the beams after the DARK run was done.

14274   Tue Nov 6 10:19:26 2018 aaronUpdateComputer Scripts / Programsarm loss measuremenents

I'm checking out the data this morning, running armloss_AS_calc.py using the parameters Yuki used here.

I made the following changes to scripts (measurement script and calculator script)

• Included the 'hour' of the run in the armloss_dcrefl_* script. This way, we can run more than once a day without overwriting data.
• Changed the calculator script to loop over all iterations of locked/misaligned states, and calculate the loss for adjacent measurements.
• That is, the measurement script will make a measurement with the arm locked, then with it misaligned, and repeat that N times
• The calculator now finds the loss for the nth iteration using *_n_locked and *_n_misaligned, and finds N separate loss measurements
• The dark signal is also computed N times, though all of the dark measurements are made before running the arm scripts, so they could be all integrated together.
• All of these are saved in the same directory that the data was grabbed from.

I repeated the 'dark' measurements, because I need 20 files to run the script and the measurements before had the window on the scope set larger than the integration time in the script, so it was padded with bad values that were influencing the calculation.

On running the script again, I'm getting negative values for the loss. I removed the beamstops from the PDs, and re-centered the beams on the PDs to repeat the YARM measurements.

14280   Wed Nov 7 05:16:16 2018 yukiUpdateComputer Scripts / Programsarm loss measuremenents

Please check your data file and compare with those Johannes made last year. I think the power in your data file may have only three-disits and flactuate about 2%, which brings huge error. (see elog: 40m/14254)

 Quote: On running the script again, I'm getting negative values for the loss.
14387   Mon Jan 7 11:54:12 2019 JonConfigurationComputer Scripts / ProgramsVac system shutdown

I'm making a controlled shutdown of the vac controls to add new ADC channels. Will advise when it's back up.

14388   Mon Jan 7 19:21:45 2019 JonConfigurationComputer Scripts / ProgramsVac system shutdown

ADC work finished for the day. The vac controls are back up, with all valves CLOSED and all pumps OFF.

 Quote: I'm making a controlled shutdown of the vac controls to add new ADC channels. Will advise when it's back up.

14542   Mon Apr 15 18:13:23 2019 ranaUpdateComputer Scripts / ProgramsAutomated suspension testing with susPython

if this gonna be general for everybody, maybe it oughta be called IFOtest (like the last incarnation that was tried in Livingston) ?

:

### In anticipation of needing to test hundreds of suspension signals after the c1susaux upgrade, I've started developing a Python package to automate these tests: susPython

then the SUS tests could just be some smaller set of measurements. Using the same code base, but different params.

14582   Sun Apr 28 16:00:17 2019 gautamUpdateComputer Scripts / ProgramsList of suspension test

Here are some tests we should script.

1. Checking Coil Vmons, OSEM PDmons, and watchdog enable wiring
• Disable input to all the coil output filter modules using C1:SUS-<OPTIC>_<COIL>_SWSTAT (this is to prevent the damping loop control signals from being sent to the suspension)
• Set ramptimes for these filter modules to 0 seconds.
• Apply a step of 100 cts (~15 mV) using the offset field of this filter module (so the test signal is being generated by the fast CDS system).
• Confirm that the step shows up in the correct coil Vmon channel with the appropriate size (in volts), and that other Vmons don't show any change (need to check the sign as well, based on the overall gain in this filter module).
• Confirm that the largest response in the PDmon signals is for the same OSEM. There will be some cross-coupling but I think we always expect the largest response to be in the OSEM whose magnet we pushed provided the transimpedances are the same across all 5 coils (which is true except for PRM side), so this should be a robust criterion.
• Take the step off using the watchdog enable field, C1:SUS-<OPTIC>_<COIL>_COMM. This allows us to confirm the watchdog signal wiring as well.
• Reset ramptimes, watchdogs, input states to filter modules, and offsets to their pre-test values.
• This test should tell us that the wiring assignments are correct, and that the Acromag ADC inputs are behaving as expected and are calibrated to volts.
• This test should be done one channel at a time to check the wiring assignments are correct.
2. Checking the SUS PD whitening
• Measure spectrum of individual PD input (fast CDS) channels above 30 Hz with the whitening in a particular state
• Toggle the whitening state.
• Confirm that the whitened sensor noise above 30 Hz is below the unwhitened case (which is presumably ADC noise.
• This test should be done one channel at a time to check the wiring assignments are correct.

Checking the Acromag DAC calibration is more complicated I think. There are measurements of the actuator calibration in units of nm/ct for the fast DACs. But these are only valid above the pendulum resonance frequency and I'm not sure we can synchronously drive a 10 Hz sine wave using the EPICs channels. The current test which drives the PIT/YAW DoFs with a DC misalingment and measures the response in the PDmon channels is a bit ad hoc in the way we set the "expected" response which is the PASS/FAIL criterion for the test. Moreover, the cross-coupling between the PDmon channels may be quite high. Needs some thought...

14585   Mon Apr 29 19:23:49 2019 JonUpdateComputer Scripts / ProgramsScripted tests of suspension VMons using fast system

I've added a scripted VMon/coil-enable test to PyIFOTest following the suggestion in #15542. Basically, a DC offset is added to one fast coil output at a time, and all the VMon responses are checked.

After resolving the swapped ITMX/ITMY eurocrate slots described in #14584, I ran the new scripted VMon test on all eight optics managed by c1susaux. All of them passed: SRM, BS, MC1, MC2, MC3, PRM, ITMX, ITMY. This is not the final suspension test we plan to do, but it gives me reasonably good confidence that all channels are connected correctly.

14650   Mon Jun 3 23:18:59 2019 MilindUpdateComputer Scripts / Programsupdating bashrc

I was working with the git repo in the SnapPy_pypylon folder (/cvs/cds/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon) and needed to create a branch. To avoid any confusion, I modified the PS1 variable and that alone in the bashrc file to reflect the git branch so that the prompt now displays the git branch if you enter a repository. This is just an update.

14680   Mon Jun 17 22:19:04 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

As Rana asked me to in the last meeting, I dug through the elogs to determine what had become of the previous autolockers. I stumbled upon this elog by Rana from before Gautam cleaned up the medm screen. Out of curiosity, I ran the autolocker script using the instructions in Rana's elog. I did this a total of 5 times and could lock the PMC 3 times fairly quickly. I attempted to decipher the details of the code but did not make much headway owing to my unfamiliarity with the language. From what I could make out from the medm screen while the autolocker was running, it appeared to be the same method as that in this elog. I will take a look at it again tomorrow. However, I intend to spend most of tomorrow working on preprocessing the data, developing the CNN script and then the simulation.

 Quote: I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.
14715   Mon Jul 1 20:18:01 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

I've begun working on this. Steps to complete:

1. Convert the autolocker to python. Test that it works.
2. Run the script with different settings of the servo gain adjust and DC output adjust parameters and obtain a plot of the average time of lock to determine what the best settings of the aforementioned parameters are.
Quote:

As Rana asked me to in the last meeting, I dug through the elogs to determine what had become of the previous autolockers. I stumbled upon this elog by Rana from before Gautam cleaned up the medm screen. Out of curiosity, I ran the autolocker script using the instructions in Rana's elog. I did this a total of 5 times and could lock the PMC 3 times fairly quickly. I attempted to decipher the details of the code but did not make much headway owing to my unfamiliarity with the language. From what I could make out from the medm screen while the autolocker was running, it appeared to be the same method as that in this elog. I will take a look at it again tomorrow. However, I intend to spend most of tomorrow working on preprocessing the data, developing the CNN script and then the simulation.

 Quote: I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.
14717   Tue Jul 2 12:30:44 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

Just finished a raw version of the autolocker!! Tested it once and was able to achieve lock! This is a python version of the code at /opt/rtcds/caltech/c1/scripts/PSL/PMC/AutoLock.sh.

The current code lives in my users directory. Gautam asked me to put the completed autolocker at /opt/rtcds/caltech/c1/scripts/PSL/PMC/ and that I needn't necessarily put it on git. However, I had previously added it to my Non-linear control repo. Not sure if I should take it off? The current script still lacks some checks like those that enable it to stop after a certain time of attempting to lock or those that handle interrupt signals. Will do that in some time.

P.S. As Koji says, Victory! :-P

P.P.S. Rana pointed out that this is not the objective and what we actually wanna do is run a search over the parameter space of the locking process. I will document my ideas about this process as soon as I do a little more reading. He also said that it would not do to have command line arguments as the main source from which parameters are procured and that .yml files ought to be used instead. I will make that change asap.

Quote:

I've begun working on this. Steps to complete:

1. Convert the autolocker to python. Test that it works.
2. Run the script with different settings of the servo gain adjust and DC output adjust parameters and obtain a plot of the average time of lock to determine what the best settings of the aforementioned parameters are.
Quote:

As Rana asked me to in the last meeting, I dug through the elogs to determine what had become of the previous autolockers. I stumbled upon this elog by Rana from before Gautam cleaned up the medm screen. Out of curiosity, I ran the autolocker script using the instructions in Rana's elog. I did this a total of 5 times and could lock the PMC 3 times fairly quickly. I attempted to decipher the details of the code but did not make much headway owing to my unfamiliarity with the language. From what I could make out from the medm screen while the autolocker was running, it appeared to be the same method as that in this elog. I will take a look at it again tomorrow. However, I intend to spend most of tomorrow working on preprocessing the data, developing the CNN script and then the simulation.

 Quote: I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.
14731   Sun Jul 7 17:54:34 2019 MilindUpdateComputer Scripts / ProgramsPMC autolocker

I modified the autolocker code I wrote to read from a .yaml configuration file instead of commandline arguements (that option still exists if one wishes to override what the .yaml file contains). I have pushed the code to github. I started reading about MCMC and will put up details of the remaining part of the work ASAP.

 Quote: P.P.S.  He also said that it would not do to have command line arguments as the main source from which parameters are procured and that .yml files ought to be used instead. I will make that change asap.
15007   Mon Nov 4 11:41:28 2019 shrutiUpdateComputer Scripts / ProgramsEpics installed on donatella

I've installed pyepics on Donatella running

sudo yum install pyepics

Pip and ipython did not seem to be installed yet.

15021   Thu Nov 7 17:55:37 2019 shrutiUpdateComputer Scripts / ProgramsPython packages on donatella

Today I realized that pip and other python2,3 packages were installed in the conda base environment, so after running

conda activate

I could run the python-GPIB scripts to interface with the Agilent.

Although, I did have to add a python2 kernel to jupyter/ipython, which I did in a separate conda environment:

conda create -n ipykernel_py2 python=2 ipykernel
source activate ipykernel_py2
python -m ipykernel install --user
 Quote: I've installed pyepics on Donatella running sudo yum install pyepics Pip and ipython did not seem to be installed yet.

15117   Mon Jan 13 15:47:37 2020 shrutiConfigurationComputer Scripts / Programsc1psl burt restore

[Yehonathan, Jon, Shruti]

Since the PMC would not lock, we initially burt-restored the c1psl machine to the last available shapshot (Dec 10th 2019), but it still would not lock.

Then, it was burt-restored to midnight of Dec 1st, 2019, after which it could be locked.

15171   Wed Jan 29 00:27:13 2020 gautamUpdateComputer Scripts / Programsmcup / mcdown modified

To fix the apparent slowness of execution of the caput commands on megatron, I changed the "ewrite" macro in the mcup and mcdown scripts to use ezcawrite instead of caput. The old lines are simply commented out, and can be reverted to at any point if we so desire. After these changes, we saw that both scripts complete execution much faster.

15207   Tue Feb 11 19:11:35 2020 shrutiUpdateComputer Scripts / ProgramsMATLAB on donatella

Tried to open MATLAB on Donatella and found the error:

MATLAB is selecting SOFTWARE OPENGL rendering.

License checkout failed. License Manager Error -9 This error may occur when:  -The hostid of this computer does not match the hostid in the license file.  -A Designated Computer installation is in use by another user.  If no other user is currently running MATLAB, you may need to activate.

Troubleshoot this issue by visiting:  http://www.mathworks.com/support/lme/R2015b/9

Diagnostic Information: Feature: MATLAB  License path: /home/controls/.matlab/R2015b_licenses/license_donatella_865865_R2015b.lic:/cvs/cds/caltech/apps/lin ux64/matlab15b/licenses/license.dat:/cvs/cds/caltech/apps/linux64/matlab15b/licenses/license_chiara_ 865865_R2015b.lic:/cvs/cds/caltech/apps/linux64/matlab15b/licenses/license_pianosa_865865_R2015b.lic  Licensing error: -9,57.

So I used  my caltech credentials to get an activation key for the computer. I could not find the option for a campus license so I used the individual single machine license.

Now it can be run by going to the location:

/cvs/cds/caltech/apps/matlab17b/bin

and running

./matlab

On opening MATLAB, there were a whole bunch of other errors including a low-level graphics error when we tried to plot something.

15325   Tue May 12 17:51:25 2020 ranaSummaryComputer Scripts / Programsupdated LESS syntax highlight on nodus

apt install source-highlight

then modified bashrc to point to /usr/share instead of /usr/bin

15331   Thu May 14 00:47:55 2020 gautamSummaryComputer Scripts / Programspcdev1 added to authorized keys on nodus

This is to facilitate the summary page config fines to be pulled from nodus in a scripted way, without being asked for authentication. If someone knows of a better/more secure way for this to be done, please let me know. The site summary pages seem to pull the config files from a git repo, maybe that's better?

15341   Wed May 20 20:10:34 2020 rana, John ZUpdateComputer Scripts / ProgramsNDS2 server / conf updated - seems OK now

We noticed about a week ago that the NDS2 channel lists were not getting updated on megatron. JZ and I investigated; he was able to fix it all up this afternoon by logging in and snooping around Megatron.

Please try it out and tell me about any problems in getting fresh data.

1. The NDS2 server is what we connect to through our python NDS2 client software to download some data.
2. It has been working for years, but it looks like there was a file corruption of the channel lists that it makes back in 2017.
3. Since the NDS2 server code tries to make incremental changes, it was failing to make a new channel list. Was failing to parse the corrupted file.
4. there was a controls crontab entry to restart the server every morning, but the file name in that tab had a typo, so that wasn't working. I commented it out, since it shouldn't be necessary (lets see how it goes...)
5. the nds2mgr account also has a crontab, but that was failing since it didn't have sudo permission. JZ added nds2mgr to the sudoers list so that should work now.
6. I was able to get new channels as of 4 PM today, so it seems to be working.

* we should remember to rebuild the NDS2 server code for Ubuntu. The thing running on there is for CentOS / SL7, but we moved to Ubuntu recently since the SL7 support is going away.

** the nds2 code & conf files are not backed up anywhere since its not on /cvs/cds. It has 52 GB(!!) of txt channel lists & archives which we don't need to backup

15342   Thu May 21 15:31:26 2020 gautamUpdateComputer Scripts / ProgramsNDS2 service restarted

The service had failed at 16:09 yesterday. I just restarted it and am now able to fetch data again.

Unrelated to this work: I restarted the httpd service on nodus a couple of times this afternoon while experimenting with the summary pages.

 Quote: Please try it out and tell me about any problems in getting fresh data.
15345   Fri May 22 10:37:41 2020 ranaUpdateComputer Scripts / ProgramsNDS2 service restarted

was dead again this morning - JZ notified

current restart instructions (after ssh to megatron):

cd /home/nds2mgr/nds2-megatron

sudo su nds2mgr

make -f test_restart

15346   Mon May 25 10:54:41 2020 ranaUpdateComputer Scripts / ProgramsNDS2 service restarted

so far it has run through the weekend with no problems (except that there are huge log files as usual).

I have started to set up monit to run on megatron to watch this process. In principle this would send us alerts when things break and also give a web interface to watch monit. I'm not sure how to do web port forwarding between megatron and nodus, so for now its just on the terminal. e.g.:

monit>sudo monit status Monit 5.25.1 uptime: 4m

System 'megatron'   status                       OK   monitoring status            Monitored   monitoring mode              active   on reboot                    start   load average                 [0.15] [0.22] [0.25]   cpu                          0.6%us 1.0%sy 0.2%wa   memory usage                 1001.4 MB [25.0%]   swap usage                   107.2 MB [1.9%]   uptime                       40d 17h 55m   boot time                    Tue, 14 Apr 2020 17:47:49   data collected               Mon, 25 May 2020 11:43:03

Process 'nds2'   status                       OK   monitoring status            Monitored   monitoring mode              active   on reboot                    start   pid                          25007   parent pid                   1   uid                          4666   effective uid                4666   gid                          4666   uptime                       3d 1h 22m   threads                      53   children                     0   cpu                          0.0%   cpu total                    0.0%   memory                       19.4% [776.1 MB]   memory total                 19.4% [776.1 MB]   security attribute           unconfined   disk read                    0 B/s [2.3 GB total]   disk write                   0 B/s [17.9 MB total]   data collected               Mon, 25 May 2020 11:43:03

ELOG V3.1.3-