When you log in, that's where you'll land. You have 100GB of space
here.
Our lab storage is /n/eddy_lab/. We have 400TB of what RC calls
-Tier 1 storage.
+Tier 1 storage, which is fast but expensive.
Both your home directory and our lab storage are backed up nightly to
what RC calls snapshots, and periodically to what RC calls disaster
recovery (DR) backups.
@@ -109,44 +109,17 @@
Overview
machine using samba. (Warning: a samba mount is slow, and may
sometimes be flaky; don't rely on it except for lightweight tasks.)
Instructions are below.
-
RC also provides shared scratch storage for us in
-/n/holyscratch01/eddy_lab. You have write access here, so at any
-time you can create your own temp directory(s). Best practice is to
-use a directory of your own, in
-/n/holyscratch01/eddy_lab/Users/<username>. We have a 50TB
-allocation. This space can't be remote mounted, isn't backed up, and
-is automatically deleted after 90 days.
+
RC also provides shared scratch storage, which is very fast but not backed up. Files on the scratch storage that are older than 90 days are automatically deleted, and RC strongly frowns on playing tricks to make files look younger than they are. Because RC occasionally moves the scratch storage to different devices, the easiest way to access it is through the \\(SCRATCH variable, which is defined on all RC machines. Our lab has an eddy_lab directory on the scratch space with a 50TB quota, which contains a Users directory, so '\\\)SCRATCH/eddy_lab/Users/' will point to your directory on the scratch space The Users directory was pre-populated with space for a set of usernames at some point in the past. If your username wasn't included, you'll have to email RC to get a directory created for you..
+
The scratch space is intended for temporary data, so is a great place to put input or output files from jobs, particularly if you intend to post-process your outputs to extract a smaller amount of data from them.
We have three compute partitions dedicated to our lab (the -p, for
-partition, will make sense when you learn how to launch compute jobs
-with the slurm scheduler):
-
-
-
-p eddy: 640 cores, 16 nodes (40 cores/node). We use this partition for most of
- our computing.
-
-
-
-p eddy_gpu:
- 4 GPU nodes [holyb0909,holyb0910,holygpu2c0923,holygpu2c1121].
- Each holyb node has 4 NVIDIA Tesla V100 NVLINK GPUs
- with 32G VRAM, 2 16-core Xeon CPUs, and 192G RAM [installed 2018].
- Each holygpu2c node has 8 NVIDIA Ampere A40 GPUs
- with 48G VRAM, 2 24-core Xeon CPUs, and 768G RAM [installed 2022].
-
-
-
We are awaiting one more GPU node with 4 NVIDIA HGX A100 GPUs
- with 80G VRAM, 2 24-core AMD CPUs, and 1024G RAM [shipping expected Nov 2022].
-
We use this partition for GPU-enabled machine learning stuff, TensorFlow and the like.
-
-
-p eddy_hmmer: 576 cores in 16 nodes. These are older cores
- (circa 2016). We use this partition for long-running or large jobs, to
- keep them from getting in people's way on -p eddy.
-
-
We are awaiting installation of another 1536 CPU cores (in 24 nodes,
-64 cores/node) [expected fall 2022].
+
All of our lab's computing equipment is contained in the eddy partition, which contains 1,872 cores. Most of our machines have 8GB of RAM per core. In addition, we have three GPU-equipped machines, which are part of the partition: holygpu2c0923, holygpu2c1121, and holygpu7c0920The "holy" at the beginning of our machine names refers to their location in the Holyoke data center.
We can also use Harvard-wide shared partitions on the RC cluster. -p
-shared is 17,952 cores (in 375 nodes), for example. RC has
+shared is 19,104 cores (in 399 nodes), for example (as of Jan 2023). RC has
much more documentation on available partitions.
Accessing the cluster
logging on, first time
@@ -197,9 +170,9 @@
configuring an ssh host alias
You still have to authenticate by password and OpenAuth code, though.
configuring single sign-on scp access
-
It can get tedious to have to authenticate every time you ssh to RC,
-especially if you're using ssh-based tools like scp to copy
-individual files back and forth. You can streamline this using
+
Even better, but a little more complicated: you can make it so you
+only have to authenticate once, and every ssh or scp after that is
+passwordless. To do this, I use
SSH ControlMaster for single sign-on,
to open a single ssh connection that you authenticate once, and all
subsequent ssh-based traffic to RC goes via that connection.
Add another hostname alias to your .ssh/config file. Mine is
- called odx:
+
Replace the above hostname alias in .ssh/config file with
+ something like this:
-
Host odx
+
Host ody
User seddy
HostName login.rc.fas.harvard.edu
ControlMaster auto
@@ -221,19 +194,19 @@
configuring single sign-on scp access
Add some aliases to your .bashrc file:
-
alias odx-start='ssh -Y -o ServerAliveInterval=30 -fN odx'
- alias odx-stop='ssh -O stop odx'
- alias odx-kill='ssh -O exit odx'
+
alias ody-start='ssh -Y -o ServerAliveInterval=30 -fN ody'
+ alias ody-stop='ssh -O stop ody'
+ alias ody-kill='ssh -O exit ody'
Now you can launch a session with:
-
% odx-start
+
% ody-start
It'll ask you to authenticate. After you do this, all your ssh-based
commands (in any terminal window) will work without further
authentication. To stop the connection, do
-
% odx-stop
+
% ody-stop
If you forget to stop it, no big deal, the connection will eventually
@@ -395,17 +368,7 @@
writing an sbatch script
format. An example that (stupidly) loads gcc and just calls
hostname, so the output will be the name of the compute node the
script ran on:
-
1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
-10
-11
#!/bin/bash
+
#!/bin/bash#SBATCH -c 1 # Number of cores/threads#SBATCH -N 1 # Ensure that all cores are on one machine#SBATCH -t 6-00:00 # Runtime in D-HH:MM
@@ -416,7 +379,7 @@
writing an sbatch script
module load gcc
hostname
-
+
Save this to a file (foo.sh for example) and submit it with sbatch:
sbatch foo.sh
@@ -468,6 +431,68 @@
etiquette
You can also add --nice 1000 to your sbatch command, to downgrade
your running priority in the queue, which helps let other people's
jobs get run before yours.
All good things must end, and that includes everyone's time in the
+Eddy lab. To help make sure that all your work is preserved after you
+leave, and to help keep us out of trouble with Harvard and our funding
+agencies, please follow the following checklist as you get ready to
+leave:
+
+
+
Copy any relevant data/code/results from your RC home directory,
+laptop, or other computing devices into your directory under
+/n/eddy_lab/users.
+
+
+
Work with your mentor/supervisor to determine what of your
+work/data needs to stay accessible after you leave and copy/transfer
+that data somewhere group-accessible, such as /n/eddy_lab/data.
+
+
+
If you have a lab laptop or other computing device, back it up to
+an external hard disk.
+
+
+
The last thing you should do on the research computing machines is
+to cd to /n/eddy_lab/users and run
+/n/eddy_lab/software/prep_for_archive.py . This will go
+through your home directory and mark everything in it accessible to
+the entire lab. It will then move your home directory under
+/n/eddy_lab/Lab and create a tarfile of your data there. Doing this
+will make it easy for us to archive your data to tape so that it costs
+less to maintain but is still accessible if we need it.
+
+
+
Return any lab "loaner" laptops to Nick. Turn in lab-owned
+computing equipment, including any backup disks to Ariane or her
+successor. Turn in any notebooks to Ariane as well
+so that they can be scanned to satisfy Harvard's research retention
+rules.
+
+
+
Enjoy the rest of your life, and come back to visit!
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/pages/modifying-this-website.html b/pages/modifying-this-website.html
index 98e3922..bda17d3 100644
--- a/pages/modifying-this-website.html
+++ b/pages/modifying-this-website.html
@@ -120,16 +120,18 @@
Modifying the Site
Make sure you have the most recent version:
Cd into the directory where you cloned the eddyrivaslab.github.io-src repository and run "git pull", which will update your local copy with any changes that have been made since your last pull.
-
Make your changes:
+
+
Make your changes:
The markdown pages containing our guides are located in the content/pages subdirectory of the git repository. If you just want to modify an existing guide, all you need to do is edit the corresponding file.
To create a new guide, copy the "template.md" file from the top-level directory to content/pages/yourfilename.md and run "git add content/pages/yourfilename.md" so that Git will know that the file has been added to the repository, and then edit that file. At the top of the markdown file you'll find four lines that start with "Title:", "Date:", "Authors:" and "slug:" that are used by Pelican to configure the resulting web page. You'll need to edit those. Most of them should be self-explanatory, except for the "slug:" field. Pelican uses that field to create the names of files associated with your guide, so it needs to be something that will be a legal filename on UNIX, Mac, and Windows computers.
One useful convention is to make the slug for a page the title of the page with all text in lowercase, spaces replaced by dashes and all other punctuation removed, so a page titled "Nick's Amazing Guide" would have the slug "nicks-amazing-guide". If you use the same convention for naming your markdown files, it'll be easy for others to figure out which file contains the source for each guide.
-After you've modified the Pelican lines, go ahead and write your page in Markdown. One note: the template we use to format our website will insert a title containing the value in the "Title:" field at the top of your page, so there's no need to put a top-level title in the markdown file.
-<<<<<<< HEAD
-
Commit and Push:
-Once you're happy with your changes, cd to the top level of your git repository and run 'git commit -a -m "<description of your changes>"'. This will call Pelican to create HTML pages from the markdown source and will push those changes to the eddyrivaslab.github.io repository that contains the actual web page. You may see a warning of the form "Locale could not be set ...". This can be ignored, as we explicitly set the locale of the web site in pelicanconf.py.
-The git commit command will take a while to run, and then it will take Github a while to make the changes visible on https://eddyrivaslab.github.io. If your changes haven't appeared after 5 minutes or so, you may need to clear your browser's cache and re-load the web page. Iterate this modify-commit cycle until you're happy with your changes.
-Finally, run "git push" to push your changes to the eddyrivaslab.github.io-src repository back up to Github so that they won't get lost when other people make changes to the site.
+After you've modified the Pelican lines, go ahead and write your page in Markdown. One note: the template we use to format our website will insert a title containing the value in the "Title:" field at the top of your page, so there's no need to put a top-level title in the markdown file.
+
+
+
Commit and Push: Once you're happy with your changes, cd to the top level of your git repository and run 'git commit -a -m "\<description of your changes>"'. This will call Pelican to create HTML pages from the markdown source and will push those changes to the eddyrivaslab.github.io repository that contains the actual web page. You may see a warning of the form "Local could not be set ...". This can be ignored, as we explicitly set the locale of the web site in pelicanconf.py.
+The git commit command will take a while to run, and then it will take Github a while to make the changes visible on https://eddyrivaslab.github.ioIf you want to know exactly when your changes will be visible, visit https://github.com/EddyRivasLab/eddyrivaslab.github.io/actions. If your commit is still being processed, there will be a yellow icon next to the top entry on that page, and you can click on the link next to the icon to see a detailed progress report.. If your changes haven't appeared after 5 minutes or so, you may need to clear your browser's cache and re-load the web page. Iterate this modify-commit cycle until you're happy with your changes.
+Finally, run "git push" to push your changes to the eddyrivaslab.github.io-src repository back up to Github so that they won't get lost when other people make changes to the site.
+
Tips and tricks
Markdown is intended to be a very "lightweight" way of formatting documents, but it has some idiosyncracies. One is the way it handles paragraph breaks. To put a paragraph break in your document, you need to add two spaces after the end of the first paragraph, and then hit return/enter. Otherwise, Markdown will ignore the end-of-line in your source document and merge the two paragraphs into one big one.
@@ -144,28 +146,7 @@
Equations
$$\frac{1}{2}$$
.
Adding pictures/images
-
Pictures and images should be placed in the content/images directory. Don't forget to "git add" your image files. I haven't figured out how to get image linking to work in Pelican yet, please let me (Nick) know if you figure it out.
-
-
Commit and Push: Once you're happy with your changes, cd to the top level of your git repository and run 'git commit -a -m "\<description of your changes>"'. This will call Pelican to create HTML pages from the markdown source and will push those changes to the eddyrivaslab.github.io repository that contains the actual web page. You may see a warning of the form "Local could not be set ...". This can be ignored, as we explicitly set the locale of the web site in pelicanconf.py.
-The git commit command will take a while to run, and then it will take Github a while to make the changes visible on https://eddyrivaslab.github.ioIf you want to know exactly when your changes will be visible, visit https://github.com/EddyRivasLab/eddyrivaslab.github.io/actions. If your commit is still being processed, there will be a yellow icon next to the top entry on that page, and you can click on the link next to the icon to see a detailed progress report.. If your changes haven't appeared after 5 minutes or so, you may need to clear your browser's cache and re-load the web page. Iterate this modify-commit cycle until you're happy with your changes.
-Finally, run "git push" to push your changes to the eddyrivaslab.github.io-src repository back up to Github so that they won't get lost when other people make changes to the site.
-
-
-
-
-
-
-
-
-
-
e5b6651 (changes from mac)
-
-
-
-
-
-
-
+
Pictures and images should be placed in the content/images directory. Don't forget to "git add" your image files. I haven't figured out how to get image linking to work in Pelican yet, please let me (Nick) know if you figure it out.