{"id":238,"date":"2016-12-15T16:13:40","date_gmt":"2016-12-15T21:13:40","guid":{"rendered":"https:\/\/www.bates.edu\/research-resources\/?page_id=238"},"modified":"2026-03-20T13:46:40","modified_gmt":"2026-03-20T17:46:40","slug":"running-jobs","status":"publish","type":"page","link":"https:\/\/www.bates.edu\/research-resources\/leavitt-hpc-cluster\/running-jobs\/","title":{"rendered":"Running Jobs"},"content":{"rendered":"\n
 <\/h5>\n\n\n\n

Quick Start Guide to Running Jobs on Leavitt<\/h4>\n\n\n\n

Once you have gained access to the Leavitt cluster (<\/span>see access request page<\/a>), you will be able to access Leavitt via SSH using a suitable terminal application, such as Terminal (Mac machines) or PuTTY (Windows machines). <\/span><\/p>\n\n\n\n

Jobs on Leavitt are typically run from the command line using the terminal application of your choosing and the bash shell, so it is a good idea to gain some basic familiarity with these tools if you plan to be using the cluster regularly (see FAQ page<\/a> for a list of guides and video tutorials). <\/span><\/p>\n\n\n\n

Mac Users – Terminal<\/a><\/p>\n\n\n\n

To login to Leavitt with your terminal application, simply type: <\/span>ssh leavitt.bates.edu<\/code><\/p>\n\n\n\n

Windows Users – PuTTY<\/a><\/p>\n\n\n\n

To login to Leavitt using PuTTY, simply enter <\/span>leavitt.bates.edu<\/code> in the Host Name field, and make sure the Connection type is set to SSH.<\/span><\/p>\n\n\n\n

Once you enter your standard Bates username and password, you will be brought to your home directory on the Leavitt cluster: <\/span><\/p>\n\n\n\n

\"screen-shot-2016-11-22-at-10-15-56-am\"<\/a><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Running jobs on Leavitt typically involves a couple steps: first, the appropriate modules are added to your environment, giving you access to the software packages or compilers your job needs to run. Second, you submit the job to the job scheduling system, Slurm, which also allows you to monitor your submitted jobs. <\/span><\/p>\n\n\n\n

We will review each of these steps in detail in the following sections. <\/span><\/p>\n\n\n\n

 <\/p>\n\n\n\n

<\/a>Modules<\/h4>\n\n\n\n

The Modules package allows users to dynamically configure their environment to run specific software packages and libraries. It also allows us to support potentially thousands of applications in a single system. <\/span><\/p>\n\n\n\n

However, it is important to note that<\/span> not all software packages use Modules. <\/span><\/i>Common software packages that many users or core software will need (e.g. Python 2.7 and editors like vi\/vim or emacs) are simply available on the system. Modules are used to customize the computing environment for specific users, for example to load a particular GNU or Intel compiler. <\/span><\/p>\n\n\n\n

More information about the Modules package can be found on the <\/span>module man-page<\/span><\/a> (short for manual page), which you can access by typing and executing \u2018<\/span>man module\u2019<\/span><\/i> at the command prompt once you\u2019ve logged into Leavitt.<\/span><\/p>\n\n\n\n

Here are a few of the most important commands:<\/span><\/p>\n\n\n\n

module avail<\/pre>\n\n\n\n
The <\/span>module avail<\/span><\/i> command will print a list of the available modules, or <\/span>modulefiles<\/span><\/i>. You should use this command as a guide when you need to load a particular module, as some of the modules have similar names and the list of available modules will change periodically as we add new software to the system. <\/span><\/p>\n\n\n\n
\"screen-shot-2016-11-22-at-11-36-46-am\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
 <\/p>\n\n\n\n
module add <module><\/pre>\n\n\n\n
The <\/span>module add<\/span><\/i> command (where <module> is the name of the module to be added) allows you to load a particular module into your shell environment. For example, executing <\/span>module add gcc<\/span><\/i> adds the 6.1.0 implementation of the GNU Compiler Collection to your environment. <\/span><\/p>\n\n\n\n
It\u2019s worth noting that some software packages or standards have multiple implementations available on Leavitt via distinct modules, such as the multiple Open MPI implementations shown here: <\/span><\/p>\n\n\n\n
\"screen-shot-2016-11-23-at-9-58-26-am\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
 <\/p>\n\n\n\n
module list<\/pre>\n\n\n\n
The <\/span>module list<\/span><\/i> command will return a list of all the currently loaded modules:<\/span><\/p>\n\n\n\n
\"screen-shot-2016-11-23-at-9-07-32-am\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
module rm <module><\/pre>\n\n\n\n
The <\/span>module rm <\/span><\/i>command (where <module> is the name of the module to be removed) will remove the specified module from your environment. This can be helpful if you need to, for example, switch compilers. <\/span><\/p>\n\n\n\n
\"screen-shot-2016-11-23-at-9-11-09-am\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
module purge<\/pre>\n\n\n\n
Not to be confused with the above, the <\/span>module purge <\/span><\/i>command will remove <\/span>all<\/span> modules from your environment. <\/span><\/p>\n\n\n\n
\"screen-shot-2016-11-23-at-9-13-51-am\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
module initadd <module><\/pre>\n\n\n\n
The <\/span>module initadd <\/span><\/i>command allows more advanced users to add modules to the shell\u2019s initialization file (.bashrc) in the user\u2019s home directory so that these modules will be automatically loaded in future sessions. If you need to make changes to your .bashrc file in the future, you can edit the file with an editor like vim or emacs, or use the <\/span>module initrm <module> <\/span><\/i>command.<\/span><\/p>\n\n\n\n
Note that this command does not load modules in the current environment. To do this you need to either start a new session or reload your .bashrc file using one of the following commands: <\/span><\/p>\n\n\n\n
source ~\/.bashrc<\/pre>\n\n\n\n
or <\/span><\/p>\n\n\n\n
. ~\/.bashrc<\/pre>\n\n\n\n
One of the default modules, preloaded for all users, is Slurm.<\/span><\/p>\n\n\n\n
 <\/p>\n\n\n\n
<\/a>Slurm<\/h4>\n\n\n\n
Slurm, or <\/span>Simple Linux Utility for Resource Management<\/span><\/i>, is an open-source cluster management and job scheduling system widely used on high performance computing clusters like Leavitt. Slurm is one of the most important software packages on Leavitt, where it is used to (1) allocate access to compute resources for users, (2) provide a framework for running and monitoring jobs, and (3) manage a queue for submitted jobs. As such, it is important for Leavitt users to have some familiarity with Slurm. <\/span><\/p>\n\n\n\n
This documentation will provide an introduction to some of the most important concepts and commands, but there are many resources available online through a simple Google search (http:\/\/slurm.schedmd.com\/<\/a> is a good place to start). Additionally, you can always find documentation on a particular command when logged into Leavitt via the manual page (man-page): <\/span><\/p>\n\n\n\n
man command<\/pre>\n\n\n\n
(e.g. <\/span>\u201cman sinfo\u201d <\/span><\/i>to see manual information on the sinfo command<\/span>).<\/span><\/p>\n\n\n\n
 <\/p>\n\n\n\n
Common Slurm Commands<\/b><\/h5>\n\n\n\n
 <\/p>\n\n\n\n
sinfo<\/pre>\n\n\n\n
Executing the <\/span>sinfo<\/span><\/i> command will show you information about the available compute nodes and partitions on Leavitt, including information about job limitations on each of the partitions, such as time limits (for a more in-depth description of each of the partitions, see the Slurm Partitions section<\/a>).<\/span><\/p>\n\n\n\n
Like most commands, there are many options available for output (view the sinfo man-page for a list). For example, you can view more detailed information about the available partitions by using the the –long<\/em> option (e.g. <\/span>sinfo --long<\/code> (<\/span>-l<\/em> for short):<\/span><\/p>\n\n\n\n
\"screen-shot-2016-11-30-at-10-00-36-am\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
squeue<\/pre>\n\n\n\n
Use the <\/span>squeue<\/span><\/i> command to view a list of jobs that have been submitted to the Slurm scheduling queue. This is a useful way to monitor jobs that have been submitted, and also to retrieve job ID\u2019s, which are necessary to cancel or get statistics on jobs (see <\/span>scancel <\/span><\/i>and <\/span>sacct<\/span><\/i> sections below). <\/span><\/p>\n\n\n\n
To view only jobs submitted by a particular user, use the -u<\/em><\/span> option, e.g. <\/span>squeue -u kevenson<\/code><\/p>\n\n\n\n
 <\/p>\n\n\n\n
sbatch<\/pre>\n\n\n\n
The <\/span>sbatch<\/span><\/i> command is used with serial batch jobs, and typically includes a submission script. For example, executing <\/span>sbatch myscript.sh<\/code> would submit the <\/span>myscript.sh<\/span><\/i> shell script to Slurm.<\/span><\/p>\n\n\n\n
Submission scripts may also include options preceded by <\/span>#SBATCH<\/code> to set key job parameters, such as the partition to be used, memory, nodes, etc. <\/span><\/p>\n\n\n\n
See the examples below or the sbatch man-page for more information. <\/span><\/p>\n\n\n\n
 <\/p>\n\n\n\n
srun<\/pre>\n\n\n\n
The <\/span>srun<\/span><\/i> command can be used to run parallel and interactive jobs with Slurm. It can be used within an existing job (e.g. in a script submitted using sbatch<\/span>), or as a way to create a new job allocation and spawn an application (e.g. for X11 forwarding to run a graphical application like Jupyter Notebook or Matlab). <\/span><\/p>\n\n\n\n
 <\/p>\n\n\n\n
scancel<\/pre>\n\n\n\n
The <\/span>scancel<\/span><\/i> command provides a simple way to cancel Slurm jobs. There are a few ways this can done, but here are a few of the most frequently used options:<\/span><\/p>\n\n\n\n
To cancel one job: <\/span>scancel <jobid> <\/code><\/p>\n\n\n\n
To cancel all the jobs for a user: <\/span>scancel -u <username> <\/code><\/p>\n\n\n\n
To cancel all the pending jobs for a user: <\/span>scancel -t PENDING -u <username><\/code><\/p>\n\n\n\n
The <\/span>scancel<\/span><\/i> command can also be used to cancel Slurm job arrays and job steps–see the man-page for more information.<\/span><\/p>\n\n\n\n
 <\/p>\n\n\n\n
sacct<\/pre>\n\n\n\n
sacct<\/span><\/i> displays accounting information for jobs submitted to Slurm and saved in the accounting log or Slurm database. This is a good way to retrieve basic statistics about a particular job. <\/span><\/p>\n\n\n\n
For example, to retrieve stats for a completed job: <\/span>sacct -j <jobid> --format=JobID,JobName,MaxRSS,Elapsed<\/code><\/p>\n\n\n\n
 <\/p>\n\n\n\n
<\/a>Submitting Batch Jobs<\/b><\/h4>\n\n\n\n
The most common way to run jobs on Leavitt is to submit a script to Slurm using the <\/span>sbatch<\/span><\/i> command. Submissions scripts will vary based on the specifics of the jobs being run, but there are a few common components, which we\u2019ll review in the example scripts below. <\/span><\/p>\n\n\n\n
Example 1: <\/b>myfirstscript.sh<\/span><\/i><\/p>\n\n\n\n
\"screen-shot-2016-12-20-at-11-31-32-am\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
This is a very simple script, created on Leavitt using the vi editor and titled <\/span>myfirstscript.sh. <\/span><\/i>(To create the script, you can use the touch<\/em> command, e.g. touch myfirstscript.sh<\/code>; to then edit the script with the vi editor, you would execute vi myfirstscript.sh<\/code>)<\/span>. <\/span><\/p>\n\n\n\n
To submit the script, we\u2019d simply execute <\/span>sbatch myfirstscript.sh<\/code> at the command prompt, and Slurm would give us our job ID:<\/span><\/p>\n\n\n\n
\"screen-shot-2016-12-06-at-3-55-24-pm\"<\/a><\/figure>\n\n\n\n
<\/p>\n\n\n\n
We\u2019ll go through the script line-by-line below, but it is worth noting the three main components first:<\/span><\/p>\n\n\n\n
    \n
  1. The first line of this script tells the system which interpreter to use. This is sometimes called the <\/span>shebang<\/span><\/i> or <\/span>hashbang<\/span><\/i> line. The syntax is standard in Unix-like systems, with the number sign and an exclamation point (#!) followed by the path to the interpreter to be used: <\/span>#!\/path\/to\/interpreter<\/code>. <\/span><\/li>\n\n\n\n
  2. The #SBATCH lines (e.g. <\/span>#SBATCH -p defq<\/code>), which make up the bulk of this particular script, are used by Slurm to set key parameters for the job. The text that you see following \u201c#SBATCH\u201d are the options specifying these parameters. See <\/span>https:\/\/slurm.schedmd.com\/sbatch.html<\/span><\/a> or the sbatch man-page for more information. <\/span><\/li>\n\n\n\n
  3. The last part of the script, in this trivial example beginning with \u201c<\/span>for j in\u2026<\/span><\/i>\u201d is the most important part–this is the code that comprises most of the job steps, or tasks that must be done for your job to complete, such as modules to load or algorithms to solve (another job step is the script itself). <\/span><\/li>\n<\/ol>\n\n\n\n
     <\/p>\n\n\n\n
    #!\/bin\/bash<\/pre>\n\n\n\n
    As noted above, this is the <\/span>shebang<\/span><\/i> line that tells the system what interpreter to use. When the script above is run, the <\/span>\/bin\/bash<\/code> text tells the system to run the script using the bash shell found in the \/bin directory. <\/span><\/p>\n\n\n\n
    Another example of a shebang line, this one for Python 2.7 users, would be <\/span>#!\/usr\/bin\/python<\/code><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH -p defq<\/pre>\n\n\n\n
    The<\/span> -p<\/span><\/i> option in this line tells Slurm what partition to use. In this case, it\u2019s telling Slurm to use the <\/span>defq<\/span><\/i> partition, which also happens to be the default partition that all Leavitt users have access to. <\/span><\/p>\n\n\n\n
    Note<\/b>: the partition used for a job determines many of the options that will be available. For example, the <\/span>defq <\/span><\/i>has a maximum job size of 6 nodes. To see a list of partitions and their usage options, see the SECTION BELOW, or use the <\/span>sinfo -la<\/span><\/i> command for a summary.<\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH -N 1<\/pre>\n\n\n\n
    The<\/span> -N<\/span><\/i> option tells Slurm how many nodes to allocate to this job. In this case, only one node is being requested. <\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH --ntasks-per-node=8<\/pre>\n\n\n\n
    The<\/span> –ntasks-per-node=<ntasks><\/span><\/i> option tells Slurm how many tasks to invoke on each node, and will be treated as a maximum count of tasks per node. Note: this is meant to be used with the <\/span>-N <\/span><\/i>option, above. <\/span><\/p>\n\n\n\n
    maximum number of tasks for which it needs to allocate resources. The default is for one task per node, so this essentially tells Slurm how many cores to allocate to the job. (Remember, each node has 2 CPU\u2019s\/sockets, each with 14 cores.)<\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH --mem-1000<\/pre>\n\n\n\n
    The<\/span> –mem <\/span><\/i>option tells Slurm how much memory you expect to be required per node in megabytes. In this particular case, 1000MB were requested <\/span>(note that in the core Leavitt cluster, each of the compute nodes has 128GB of memory).<\/span><\/p>\n\n\n\n
    Remember<\/b>: Leavitt is a shared resource, so it is very important that you make accurate requests for the amount of memory you need. If insufficient memory is requested, your job may fail. On the flip side, if you request much more memory than you need for your job, you may be taking resources that another Leavitt user needs. <\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH -t 0-01:1:30<\/pre>\n\n\n\n
    The<\/span> -t<\/span><\/i> option allows you to set a limit on the total run time for your job. Multiple formats are acceptable (see the sbatch man-page for more information), but in this example, a time limit of 1 hour and 30 minutes was imposed. <\/span><\/p>\n\n\n\n
    Note that this option may have no real bearing on how long your job takes to actually run. In this example, the job completed in approximately 19 seconds. <\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH -o slurm-%u-%N-%j.out<\/pre>\n\n\n\n
    The<\/span> -o<\/span><\/i> option tells Slurm to direct its output to the filename specified. The filename pattern can include a number of replacement symbols. In the example above, the \u2018%u\u2019 is replaced with the username associated with the job, the \u2018%N\u2019 is replaced by the name of the node that runs the script and \u2018%j\u2019 is replaced by the job allocation number\u2014resulting in an output file called <\/span>slurm-kevenson-node001-242.out<\/span><\/i>.<\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH -e slurm-%u-%N-%j.err<\/pre>\n\n\n\n
    Similar to the above, the<\/span> -e<\/span><\/i> option tells Slurm to direct its standard error directly to the filename specified. The filename pattern options are the same, so this particular line results in an error file called <\/span>slurm-kevenson-node001-242.err<\/span><\/i>.<\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    #SBATCH --mail-type=END,FAIL\n#SBATCH --mail-user=kevenson@bates.edu<\/pre>\n\n\n\n
    The<\/span> –mail-type <\/span><\/i>and<\/span> –mail-user<\/span><\/i> options tell Slurm (a) to notify a user by email when certain event types occur (here END and FAIL) and (b) what user should be notified when these events occur. <\/span><\/p>\n\n\n\n
    See the sbatch man-page for more type values. <\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    for j in {1..50000}; do \n   echo $RANDOM >> MyRandomNumbers.txt \ndone\n\nsort -n MyRandomNumbers.txt<\/pre>\n\n\n\n
    These remaining lines comprise the real work you want to do. The for loop generates a long, long list of random numbers, which are appended to the file MyRandomNumbers.txt. This is then sorted in ascending order in the output file. <\/span><\/p>\n\n\n\n
    So, nothing too interesting in this example but this is where you would instruct Slurm to load particular modules, open another script with your custom software or perform additional job steps with the <\/span>srun<\/span><\/i> command.<\/span><\/p>\n\n\n\n
     <\/p>\n\n\n\n
    <\/a>Slurm Partitions<\/b><\/h4>\n\n\n\n
    Partitions in Slurm are essentially queues for jobs. Partitions all have differing levels of access to the resources available on the Leavitt cluster. You may have access to different partitions based on your user type (e.g. if you are a faculty member or a student), and you may choose to use different partitions based on the types of jobs you need run. <\/span><\/p>\n\n\n\n
    As of this writing, the L<\/span>eavitt cluster is composed of 11 Dell PowerEdge 430’s compute nodes and one Dell PowerEdge 730XD head node. Each of the compute nodes has 128GB of memory and dual Intel Xeon E5-2680 processors, each with 14 cores running at 2.40GHz, for a total of 308 cores and 1.4 terabytes of memory. The head node has an additional 48 terabytes of disk storage, which is shared amongst the compute nodes. The 12 nodes are also connected by an Intel Omni-Path switch, which provides very high speed (100 gigabits\/second) network access between each member in the cluster.<\/span><\/p>\n\n\n\n
    Below is an overview of the available partitions on Leavitt.<\/span><\/p>\n\n\n\n
    defq<\/i><\/b><\/h5>\n\n\n\n
    The defq or default queue is available to all Leavitt users, including students. This queue has access to a maximum of roughly half of Leavitt\u2019s resources for a maximum of 48 hours, making this an appropriate partition for classroom work. <\/span><\/p>\n\n\n\n
      \n
    • Max compute nodes<\/span>: 6 (12 sockets \/ 168 total cores)<\/span><\/li>\n\n\n\n
    • Max job time<\/span>: 48 hours<\/span><\/li>\n\n\n\n
    • Default time<\/span>: 2 hours<\/span><\/li>\n<\/ul>\n\n\n\n
      Note that if you do not specify a partition when you submit your job, it will automatically run on this partition. <\/span><\/i><\/p>\n\n\n\n
       <\/p>\n\n\n\n
      faculty<\/i><\/b><\/h5>\n\n\n\n
      The faculty queue is available to all Leavitt faculty and staff users. This queue has access to all Leavitt\u2019s resources, but jobs submitted to this queue have a lower priority than jobs submitted to the contributor queue, detailed below. <\/span><\/p>\n\n\n\n
        \n
      • Max compute nodes<\/span>: 11 (22 sockets \/ 308 total cores)<\/span><\/li>\n\n\n\n
      • Max job time<\/span>: 15 days<\/span><\/li>\n\n\n\n
      • Default time<\/span>: 6 hours<\/span><\/li>\n<\/ul>\n\n\n\n
         <\/p>\n\n\n\n
        contributor<\/i><\/b><\/h5>\n\n\n\n
        The contributor queue is restricted to faculty who have contributed to the expansion of the Leavitt cluster\u2019s resources, e.g. through grant applications or the purchasing of additional nodes through startup funds.<\/span><\/p>\n\n\n\n
          \n
        • Max compute nodes<\/span>: 11 (22 sockets \/ 308 total cores)<\/span><\/li>\n\n\n\n
        • Max job time<\/span>: unlimited<\/span><\/li>\n\n\n\n
        • Default time<\/span>: 10 days<\/span><\/li>\n<\/ul>\n\n\n\n
           <\/p>\n\n\n\n
          interactive<\/i><\/b><\/h5>\n\n\n\n
          tbd<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
            Quick Start Guide to Running Jobs on Leavitt Once you have…<\/p>\n","protected":false},"author":34,"featured_media":0,"parent":215,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_hide_ai_chatbot":false,"_ai_chatbot_style":"","associated_faculty":[],"_Page_Specific_Css":"","_bates_restrict_mod":false,"_table_of_contents_display":true,"_table_of_contents_location":"sidebarBottom","_table_of_contents_disableSticky":false,"_is_featured":false,"footnotes":"","_bates_seo_meta_description":"","_bates_seo_block_robots":false,"_bates_seo_sharing_image_id":0,"_bates_seo_sharing_image_twitter_id":0,"_bates_seo_share_title":"","_bates_seo_canonical_overwrite":"","_bates_seo_twitter_template":""},"class_list":["post-238","page","type-page","status-publish","hentry","with-sidebar"],"_links":{"self":[{"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/pages\/238","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/users\/34"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/comments?post=238"}],"version-history":[{"count":5,"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/pages\/238\/revisions"}],"predecessor-version":[{"id":1022,"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/pages\/238\/revisions\/1022"}],"up":[{"embeddable":true,"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/pages\/215"}],"wp:attachment":[{"href":"https:\/\/www.bates.edu\/research-resources\/wp-json\/wp\/v2\/media?parent=238"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}