From a0edc431e0fb2682ddd88b19aff61790954e6362 Mon Sep 17 00:00:00 2001
From: Tanner Prestegard <tanner.prestegard@ligo.org>
Date: Mon, 21 Nov 2016 11:20:09 -0600
Subject: [PATCH] updates to lvalert docs
---
doc/source/responding_to_lvalert.rst | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/doc/source/responding_to_lvalert.rst b/doc/source/responding_to_lvalert.rst
index f64abda97..d455b3a0c 100644
--- a/doc/source/responding_to_lvalert.rst
+++ b/doc/source/responding_to_lvalert.rst
@@ -62,7 +62,8 @@ authentication information*::
machine lvalert.cgca.uwm.edu login user.name password passw0rd
*With this setup, you won't need to include the* ``-a`` *flag for your username,
-or enter your password.*
+or enter your password. Your .netrc file should only be accessible by you, so
+be sure to do* ``chmod 600 $HOME/.netrc``.
To actually subscribe to a pubsub node, we use ``lvalert_admin``
which allows you to manage your subscriptions. This includes subscribing to new
@@ -144,7 +145,7 @@ create a file called ``myLVAlertListen.ini`` with the following as its contents:
Now run::
- lvalert_listen -a user.name -c myLVAlertListen.ini > myLVAlertListen.out &
+ lvalert_listen -a user.name -c myLVAlertListen.ini > myLVAlertListen.out &
Congratulations! You've set up an ``lvalert_listen`` instance which reacts to
announcements published to the ``cbc_gstlal_lowmass``, ``cbc_gstlal_highmass`` and
@@ -191,7 +192,7 @@ which contains::
#!/bin/bash
read a
- echo "received a test alert: ${a}" >> user.name-TestNode.out
+ echo "received a test alert: ${a}" >> lvalert_user.name-TestNode.out
Once you've done that, ensure that all three shell scripts are executables (required
by the delegation through ``subprocess.Popen``) with::
@@ -203,13 +204,13 @@ by the delegation through ``subprocess.Popen``) with::
and edit myLVAlertListen.ini so it reads::
[cbc_gstlal_lowmass]
- executable = lvalert-run_cbc_gstlal_lowmass.sh
+ executable = ./lvalert-run_cbc_gstlal_lowmass.sh
[cbc_gstlal_highmass]
- executable = lvalert-run_cbc_gstlal_highmass.sh
+ executable = ./lvalert-run_cbc_gstlal_highmass.sh
[user.name-TestNode]
- executable = lvalert-run_user.name-TestNode.sh
+ executable = ./lvalert-run_user.name-TestNode.sh
It is generally a good rule of thumb to provide the full paths to executables
and output files in both ``myLVAlertListen.ini`` as well as these simple shell
@@ -239,7 +240,9 @@ resource names for all of your listener processes, you can do something like::
lvalert_listen -a user.name -c myLVAlertListen.ini -r twoInstance &
This will launch two instances of ``lvalert_listen`` (both using the same
-config file) with different resource names. They will both react to alerts and fork
+config file) with different resource names (note that this can also be
+achieved by not specifying the resource name at all).
+They will both react to alerts and fork
processes. If each points to a different config file, I can then get multiple
types of follow-up processes forked for the same announcement through a single
pubsub node.
@@ -385,11 +388,11 @@ check that this worked, you'll need to look at the associated GraceDB page,
expand the "full log" section and look for your log message.
**IMPORTANTLY,** I've just made up 'G12345' as an example. If you really want
-to test your script you'll need to choose a real event from GraceDB. However,
-PLEASE DO NOT TEST YOUR SCRIPT WITH IMPORTANT GraceDB EVENTS like G184098 (the
-cWB entry for GW150914). Instead, please pick an event with high FAR that
-you've never heard of before. Chances are, if FAR>1e-5 no one will care about
-it and you can use it to test your script. There are also test instances of
+to test your script, you should choose a test event from GraceDB. A query for
+these events is available `here <https://gracedb.ligo.org/events/search/?query=group%3A%20Test>`__.
+*NOTE: please do* **NOT** *test your script with important events in GraceDB
+like G184098 (the cWB entry for GW150914) or others with low FAR.*
+Instead, please use a test event as described above. There are also test instances of
GraceDB available if you'd prefer to not work with the production server right
away. Contact uwm-help@cgca.uwm.edu with a descriptive subject line for more
information.
--
GitLab