repair external and internal links

docs.it4i/anselm-cluster-documentation/accessing-the-cluster/vpn-access.md

@@ -4,8 +4,10 @@ VPN Access
 Accessing IT4Innovations internal resources via VPN
 ---------------------------------------------------
 
->**Failed to initialize connection subsystem Win 8.1 - 02-10-15 MS patch**
-Workaround can be found at [vpn-connection-fail-in-win-8.1](../../vpn-connection-fail-in-win-8.1.html)
+!!! Note "Note"
+	**Failed to initialize connection subsystem Win 8.1 - 02-10-15 MS patch**
+
+    Workaround can be found at [vpn-connection-fail-in-win-8.1](../../vpn-connection-fail-in-win-8.1.html)
 
 For using resources and licenses which are located at IT4Innovations local network, it is necessary to VPN connect to this network. We use Cisco AnyConnect Secure Mobility Client, which is supported on the following operating systems:
 
@@ -81,5 +83,4 @@ After a successful logon, you can see a green circle with a tick mark on the loc
 
 ![](successfullconnection.jpg)
 
-For disconnecting, right-click on the AnyConnect client icon in the system tray and select **VPN Disconnect**.
-
+For disconnecting, right-click on the AnyConnect client icon in the system tray and select **VPN Disconnect**.
\ No newline at end of file

docs.it4i/anselm-cluster-documentation/resource-allocation-and-job-execution/capacity-computing.md

@@ -7,7 +7,8 @@ In many cases, it is useful to submit huge (>100+) number of computational jobs
 
 However, executing huge number of jobs via the PBS queue may strain the system. This strain may result in slow response to commands, inefficient scheduling and overall degradation of performance and user experience, for all users. For this reason, the number of jobs is **limited to 100 per user, 1000 per job array**
 
->Please follow one of the procedures below, in case you wish to schedule more than 100 jobs at a time.
+!!! Note "Note"
+	Please follow one of the procedures below, in case you wish to schedule more than 100 jobs at a time.
 
 -   Use [Job arrays](capacity-computing/#job-arrays) when running huge number of [multithread](capacity-computing/#shared-jobscript-on-one-node) (bound to one node only) or multinode (multithread across several nodes) jobs
 -   Use [GNU parallel](capacity-computing/#gnu-parallel) when running single core jobs
@@ -20,7 +21,8 @@ Policy
 
 Job arrays
 --------------
->Huge number of jobs may be easily submitted and managed as a job array.
+!!! Note "Note"
+	Huge number of jobs may be easily submitted and managed as a job array.
 
 A job array is a compact representation of many jobs, called subjobs. The subjobs share the same job script, and have the same values for all attributes and resources, with the following exceptions:
 
@@ -148,7 +150,8 @@ Read more on job arrays in the [PBSPro Users guide](../../pbspro-documentation/s
 
 GNU parallel
 ----------------
->Use GNU parallel to run many single core tasks on one node.
+!!! Note "Note"
+	Use GNU parallel to run many single core tasks on one node.
 
 GNU parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. GNU parallel is most useful in running single core jobs via the queue system on  Anselm.
 
@@ -218,11 +221,13 @@ Please note the #PBS directives in the beginning of the jobscript file, dont' fo
 
 Job arrays and GNU parallel
 -------------------------------
->Combine the Job arrays and GNU parallel for best throughput of single core jobs
+!!! Note "Note"
+	Combine the Job arrays and GNU parallel for best throughput of single core jobs
 
 While job arrays are able to utilize all available computational nodes, the GNU parallel can be used to efficiently run multiple single-core jobs on single node. The two approaches may be combined to utilize all available (current and future) resources to execute single core jobs.
 
->Every subjob in an array runs GNU parallel to utilize all cores on the node
+!!! Note "Note"
+	Every subjob in an array runs GNU parallel to utilize all cores on the node
 
 ### GNU parallel, shared jobscript
 
@@ -276,7 +281,8 @@ cp output $PBS_O_WORKDIR/$TASK.out
 
 In this example, the jobscript executes in multiple instances in parallel, on all cores of a computing node.  Variable $TASK expands to one of the input filenames from tasklist. We copy the input file to local scratch, execute the myprog.x and copy the output file back to the submit directory, under the $TASK.out name.  The numtasks file controls how many tasks will be run per subjob. Once an task is finished, new task starts, until the number of tasks  in numtasks file is reached.
 
->Select  subjob walltime and number of tasks per subjob  carefully
+!!! Note "Note"
+	Select  subjob walltime and number of tasks per subjob  carefully
 
 When deciding this values, think about following guiding rules:
 

docs.it4i/anselm-cluster-documentation/resource-allocation-and-job-execution/introduction.md

@@ -13,13 +13,15 @@ The resources are allocated to the job in a fairshare fashion, subject to constr
 - **qnvidia**, **qmic**, **qfat**, the Dedicated queues
 - **qfree**, the Free resource utilization queue
 
->Check the queue status at <https://extranet.it4i.cz/anselm/>
+!!! Note "Note"
+	Check the queue status at <https://extranet.it4i.cz/anselm/>
 
 Read more on the [Resource AllocationPolicy](resources-allocation-policy/) page.
 
 Job submission and execution
 ----------------------------
->Use the **qsub** command to submit your jobs.
+!!! Note "Note"
+	Use the **qsub** command to submit your jobs.
 
 The qsub submits the job into the queue. The qsub command creates a request to the PBS Job manager for allocation of specified resources. The **smallest allocation unit is entire node, 16 cores**, with exception of the qexp queue. The resources will be allocated when available, subject to allocation policies and constraints. **After the resources are allocated the jobscript or interactive shell is executed on first of the allocated nodes.**
 
@@ -27,7 +29,9 @@ Read more on the [Job submission and execution](job-submission-and-execution/) p
 
 Capacity computing
 ------------------
->Use Job arrays when running huge number of jobs.
+!!! Note "Note"
+	Use Job arrays when running huge number of jobs.
+
 Use GNU Parallel and/or Job arrays when running (many) single core jobs.
 
 In many cases, it is useful to submit huge (100+) number of computational jobs into the PBS queue system. Huge number of (small) jobs is one of the most effective ways to execute embarrassingly parallel calculations, achieving best runtime, throughput and computer utilization. In this chapter, we discuss the the recommended way to run huge number of jobs, including **ways to run huge number of single core jobs**.

docs.it4i/anselm-cluster-documentation/resource-allocation-and-job-execution/job-priority.md

@@ -62,6 +62,7 @@ The scheduler makes a list of jobs to run in order of execution priority. Schedu
 
 It means, that jobs with lower execution priority can be run before jobs with higher execution priority.
 
->It is **very beneficial to specify the walltime** when submitting jobs.
+!!! Note "Note"
+	It is **very beneficial to specify the walltime** when submitting jobs.
 
 Specifying more accurate walltime enables better schedulling, better execution times and better resource usage. Jobs with suitable (small) walltime could be backfilled - and overtake job(s) with higher priority.
\ No newline at end of file

docs.it4i/anselm-cluster-documentation/resource-allocation-and-job-execution/job-submission-and-execution.md

@@ -12,7 +12,8 @@ When allocating computational resources for the job, please specify
 5.  Project ID
 6.  Jobscript or interactive switch
 
->Use the **qsub** command to submit your job to a queue for allocation of the computational resources.
+!!! Note "Note"
+	Use the **qsub** command to submit your job to a queue for allocation of the computational resources.
 
 Submit the job using the qsub command:
 
@@ -134,7 +135,8 @@ Although this example is somewhat artificial, it demonstrates the flexibility of
 
 Job Management
 --------------
->Check status of your jobs using the **qstat** and **check-pbs-jobs** commands
+!!! Note "Note"
+	Check status of your jobs using the **qstat** and **check-pbs-jobs** commands
 
 ```bash
 $ qstat -a
@@ -214,7 +216,8 @@ Run loop 3
 
 In this example, we see actual output (some iteration loops) of the job 35141.dm2
 
->Manage your queued or running jobs, using the **qhold**, **qrls**, **qdel**, **qsig** or **qalter** commands
+!!! Note "Note"
+	Manage your queued or running jobs, using the **qhold**, **qrls**, **qdel**, **qsig** or **qalter** commands
 
 You may release your allocation at any time, using qdel command
 
@@ -239,11 +242,13 @@ Job Execution
 
 ### Jobscript
 
->Prepare the jobscript to run batch jobs in the PBS queue system
+!!! Note "Note"
+	Prepare the jobscript to run batch jobs in the PBS queue system
 
 The Jobscript is a user made script, controlling sequence of commands for executing the calculation. It is often written in bash, other scripts may be used as well. The jobscript is supplied to PBS **qsub** command as an argument and executed by the PBS Professional workload manager.
 
->The jobscript or interactive shell is executed on first of the allocated nodes.
+!!! Note "Note"
+	The jobscript or interactive shell is executed on first of the allocated nodes.
 
 ```bash
 $ qsub -q qexp -l select=4:ncpus=16 -N Name0 ./myjob
@@ -272,7 +277,8 @@ $ pwd
 
 In this example, 4 nodes were allocated interactively for 1 hour via the qexp queue. The interactive shell is executed in the home directory.
 
->All nodes within the allocation may be accessed via ssh.  Unallocated nodes are not accessible to user.
+!!! Note "Note"
+	All nodes within the allocation may be accessed via ssh.  Unallocated nodes are not accessible to user.
 
 The allocated nodes are accessible via ssh from login nodes. The nodes may access each other via ssh as well.
 
@@ -303,7 +309,8 @@ In this example, the hostname program is executed via pdsh from the interactive
 
 ### Example Jobscript for MPI Calculation
 
->Production jobs must use the /scratch directory for I/O
+!!! Note "Note"
+	Production jobs must use the /scratch directory for I/O
 
 The recommended way to run production jobs is to change to /scratch directory early in the jobscript, copy all inputs to /scratch, execute the calculations and copy outputs to home directory.
 
@@ -334,11 +341,13 @@ exit
 
 In this example, some directory on the /home holds the input file input and executable mympiprog.x . We create a directory myjob on the /scratch filesystem, copy input and executable files from the /home directory where the qsub was invoked ($PBS_O_WORKDIR) to /scratch, execute the MPI programm mympiprog.x and copy the output file back to the /home directory. The mympiprog.x is executed as one process per node, on all allocated nodes.
 
->Consider preloading inputs and executables onto [shared scratch](../storage/storage/) before the calculation starts.
+!!! Note "Note"
+	Consider preloading inputs and executables onto [shared scratch](../storage/storage/) before the calculation starts.
 
 In some cases, it may be impractical to copy the inputs to scratch and outputs to home. This is especially true when very large input and output files are expected, or when the files should be reused by a subsequent calculation. In such a case, it is users responsibility to preload the input files on shared /scratch before the job submission and retrieve the outputs manually, after all calculations are finished.
 
->Store the qsub options within the jobscript. Use **mpiprocs** and **ompthreads** qsub options to control the MPI job execution.
+!!! Note "Note"
+	Store the qsub options within the jobscript. Use **mpiprocs** and **ompthreads** qsub options to control the MPI job execution.
 
 Example jobscript for an MPI job with preloaded inputs and executables, options for qsub are stored within the script :
 
@@ -370,7 +379,8 @@ sections.
 
 ### Example Jobscript for Single Node Calculation
 
->Local scratch directory is often useful for single node jobs. Local scratch will be deleted immediately after the job ends.
+!!! Note "Note"
+	Local scratch directory is often useful for single node jobs. Local scratch will be deleted immediately after the job ends.
 
 Example jobscript for single node calculation, using [local scratch](../storage/storage/) on the node: