Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision
  • FAQ
  • RDPv10
  • UNL_OneDrive
  • atticguidelines
  • data_share
  • globus-auto-backups
  • good-hcc-practice-rep-workflow
  • hchen2016-faq-home-is-full
  • ipynb-doc
  • master
  • rclone-fix
  • sislam2-master-patch-51693
  • sislam2-master-patch-86974
  • site_url
  • test
15 results

Target

Select target project
  • dweitzel2/hcc-docs
  • OMCCLUNG2/hcc-docs
  • salmandjing/hcc-docs
  • hcc/hcc-docs
4 results
Select Git revision
Loading items
Show changes
Show whitespace changes
Inline Side-by-side
Showing
with 0 additions and 2153 deletions
content/guides/running_applications/using_anaconda_package_manager.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Using Anaconda Package Manager"
description = "How to use the Anaconda Package Manager on HCC resources."
+++
[Anaconda](https://www.anaconda.com/what-is-anaconda),
from [Anaconda, Inc](https://www.anaconda.com)
is a completely free enterprise-ready distribution for large-scale data
processing, predictive analytics, and scientific computing. It includes
over 195 of the most popular Python packages for science, math,
engineering, and data analysis. **It also offers the ability to easily
create custom _environments_ by mixing and matching different versions
of Python and/or R and other packages into isolated environments that
individual users are free to create.** Anaconda includes the `conda`
package and environment manager to make managing these environments
straightforward.
- [Using Anaconda](#using-anaconda)
- [Creating custom Anaconda Environment](#creating-custom-anaconda-environment)
- [Creating custom GPU Anaconda Environment](#creating-custom-gpu-anaconda-environment)
- [Adding Packages to an Existing Environment](#adding-packages-to-an-existing-environment)
- [Using an Anaconda Environment in a Jupyter Notebook on Crane](#using-an-anaconda-environment-in-a-jupyter-notebook-on-crane)
### Using Anaconda
While the standard methods of installing packages via `pip`
and `easy_install` work with Anaconda, the preferred method is using
the `conda` command.
{{% notice info %}}
Full documentation on using Conda is available
at http://conda.pydata.org/docs/
A [cheatsheet](/attachments/11635089.pdf) is also provided.
{{% /notice %}}
A few examples of the basic commands are provided here. For a full
explanation of all of Anaconda/Conda's capabilities, see the
documentation linked above.
Anaconda is provided through the `anaconda` module on HCC machines. To
begin using it, load the Anaconda module.
{{% panel theme="info" header="Load the Anaconda module to start using Conda" %}}
{{< highlight bash >}}
module load anaconda
{{< /highlight >}}
{{% /panel %}}
To display general information about Conda/Anaconda, use the `info` subcommand.
{{% panel theme="info" header="Display general information about Conda/Anaconda" %}}
{{< highlight bash >}}
conda info
{{< /highlight >}}
{{% /panel %}}
Conda allows the easy creation of isolated, custom environments with
packages and versions of your choosing. To show all currently available
environments, and which is active, use the `info `subcommand with the
`-e` option.
{{% panel theme="info" header="List available environments" %}}
{{< highlight bash >}}
conda info -e
{{< /highlight >}}
{{% /panel %}}
The active environment will be marked with an asterisk (\*) character.
The `list` command will show all packages installed
in the currently active environment.
{{% panel theme="info" header="List installed packages in current environment" %}}
{{< highlight bash >}}
conda list
{{< /highlight >}}
{{% /panel %}}
To find the names of packages, use the `search` subcommand.
{{% panel theme="info" header="Search for packages" %}}
{{< highlight bash >}}
conda search numpy
{{< /highlight >}}
{{% /panel %}}
If the package is available, this will also display available package
versions and compatible Python versions the package may be installed
under.
### Creating Custom Anaconda Environment
The `create` command is used to create a new environment. It requires
at a minimum a name for the environment, and at least one package to
install. For example, suppose we wish to create a new environment, and
need version 1.8 of NumPy.
{{% notice info %}}
The `conda create` command must be run on the login node.
{{% /notice %}}
{{% panel theme="info" header="Create a new environment by providing a name and package specification" %}}
{{< highlight bash >}}
conda create -n mynumpy numpy=1.8
{{< /highlight >}}
{{% /panel %}}
This will create a new environment called 'mynumpy' and installed NumPy
version 1.8, along with any required dependencies.
To use the environment, we must first *activate* it.
{{% panel theme="info" header="Activate environment" %}}
{{< highlight bash >}}
source activate mynumpy
{{< /highlight >}}
{{% /panel %}}
Our new environment is now active, and we can use it. The shell prompt
will change to indicate this as well (this can be disable if desired).
### Creating Custom GPU Anaconda Environment
We provide GPU versions of various frameworks such as `tensorflow`, `keras`, `theano`, via [modules](../module_commands). However, sometimes you may need additional libraries or packages that are not available as part of these modules. In this case, you will need to create your own GPU Anaconda environment.
To do this, you need to first clone one of our GPU modules to a new Anaconda environment, and then install the desired packages in this new environment.
The reason for this is that the GPU modules we support are built using the specific CUDA drivers our GPU nodes have. If you just create custom GPU environment without cloning the module, your code will not utilize the GPUs.
For example, if you want to use `tensorflow` with additional packages, first do:
{{% panel theme="info" header="Cloning GPU module to a new Anaconda environment" %}}
{{< highlight bash >}}
module load tensorflow-gpu/py36/1.12 anaconda
conda create -n tensorflow-gpu-1.12-custom --clone $CONDA_DEFAULT_ENV
module purge
{{< /highlight >}}
{{% /panel %}}
This will create a new `tensorflow-gpu-1.12-custom` environment in your home directory that is a copy of the `tensorflow-gpu` module. Then, you can install the additional packages you need in this environment.
{{% panel theme="info" header="Install new packages in the currently active environment" %}}
{{< highlight bash >}}
module load anaconda
source activate tensorflow-gpu-1.12-custom
conda install <packages>
{{< /highlight >}}
{{% /panel %}}
Next, whenever you want to use this custom GPU Anaconda environment, you need to add these two lines in your submit script:
{{< highlight bash >}}
module load anaconda
source activate tensorflow-gpu-1.12-custom
{{< /highlight >}}
{{% notice info %}}
If you have custom GPU Anaconda environment please only use the two lines from above and **DO NOT** load the module you have cloned earlier. Using `module load tensorflow-gpu/py36/1.12` and `source activate tensorflow-gpu-1.12-custom` in the same script is **wrong** and may give you various errors and incorrect results.
{{% /notice %}}
### Adding Packages to an Existing Environment
To install additional packages in an environment, use the `install`
subcommand. Suppose we want to install iPython in our 'mynumpy'
environment. While the environment is active, use `install `with no
additional arguments.
{{% panel theme="info" header="Install a new package in the currently active environment" %}}
{{< highlight bash >}}
conda install ipython
{{< /highlight >}}
{{% /panel %}}
{{% notice info %}}
The `conda install` command must be run on the login node.
{{% /notice %}}
If you aren't currently in the environment you wish to install the
package in, add the `-n `option to specify the name.
{{% panel theme="info" header="Install new packages in a specified environment" %}}
{{< highlight bash >}}
conda install -n mynumpy ipython
{{< /highlight >}}
{{% /panel %}}
The `remove` subcommand to uninstall a package functions similarly.
{{% panel theme="info" header="Remove package from currently active environment" %}}
{{< highlight bash >}}
conda remove ipython
{{< /highlight >}}
{{% /panel %}}
{{% panel theme="info" header="Remove package from environment specified by name" %}}
{{< highlight bash >}}
conda remove -n mynumpy ipython
{{< /highlight >}}
{{% /panel %}}
To exit an environment, we *deactivate* it.
{{% panel theme="info" header="Exit current environment" %}}
Newer versions of anaconda:
{{< highlight bash >}}
conda deactivate
{{< /highlight >}}
Older versions of anaconda:
{{< highlight bash >}}
source deactivate
{{< /highlight >}}
{{% /panel %}}
Finally, to completely remove an environment, add the `--all `option
to `remove`.
{{% panel theme="info" header="Completely remove an environment" %}}
{{< highlight bash >}}
conda remove -n mynumpy --all
{{< /highlight >}}
{{% /panel %}}
### Using an Anaconda Environment in a Jupyter Notebook on Crane
It is not difficult to make an Anaconda environment available to a
Jupyter Notebook. To do so, follow the steps below, replacing
`myenv` with the name of the Python or R environment you wish to use:
1. Stop any running Jupyter Notebooks and ensure you are logged out of
the JupyterHub instance at https://crane.unl.edu
1. If you are not logged out, please click the Control Panel button
located in the top right corner.
2. Click the "Stop My Server" Button to terminate the Jupyter
server.
3. Click the logout button in the top right corner.
2. Using the command-line environment, load the target conda
environment:
{{< highlight bash >}}source activate myenv{{< /highlight >}}
3. Install the Jupyter kernel and add the environment:
1. For a **Python** conda environment, install the IPykernel
package, and then the kernel specification:
{{< highlight bash >}}
# Install ipykernel
conda install ipykernel
# Install the kernel specification
python -m ipykernel install --user --name "$CONDA_DEFAULT_ENV" --display-name "Python ($CONDA_DEFAULT_ENV)"
{{< /highlight >}}
2. For an **R** conda environment, install the jupyter\_client and
IRkernel packages, and then the kernel specification:
{{< highlight bash >}}
# Install PNG support for R, the R kernel for Jupyter, and the Jupyter client
conda install r-png
conda install r-irkernel jupyter_client
# Install jupyter_client 5.2.3 from anaconda channel for bug workaround
conda install -c anaconda jupyter_client
# Install the kernel specification
R -e "IRkernel::installspec(name = '$CONDA_DEFAULT_ENV', displayname = 'R ($CONDA_DEFAULT_ENV)', user = TRUE)"
{{< /highlight >}}
4. Once you have the environment set up, deactivate it:
{{< highlight bash >}}conda deactivate{{< /highlight >}}
5. To make your conda environments accessible from the worker nodes,
enter the following commands:
{{< highlight bash >}}
mkdir -p $WORK/.jupyter
mv ~/.local/share/jupyter/kernels $WORK/.jupyter
ln -s $WORK/.jupyter/kernels ~/.local/share/jupyter/kernels
{{< /highlight >}}
{{% notice note %}}
**Note**: Step 5 only needs to be done once. Any future created
environments will automatically be accessible from SLURM notebooks
once this is done.
**Note**: For older version of anaconda, use `source deactivate` to
deactivate the environment.
{{% /notice %}}
6. Login to JupyterHub at https://crane.unl.edu
and create a new notebook using the environment by selecting the
correct entry in the `New` dropdown menu in the top right
corner.
{{< figure src="/images/24151931.png" height="400" class="img-border">}}
content/guides/sandstone/_index.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Sandstone"
description = "How to use HCC's sandstone environment"
weight = "45"
+++
### Overview
The HCC Sandstone environment is a GUI interface to the Crane cluster featuring a file browser, text editor, web terminal and SLURM script helper,
To login to the Sandstone environment, go to [crane.unl.edu](https://crane.unl.edu) in your web browser and sign in using your HCC Login Info and DUO authentication.
Upon login, you will land at the File Browser.
### File Browser
The file browser allows you to view, access, and transfer files on Crane. On the left side you will have your available spaces, both your home and work directories. In the upper right of the page, you have buttons to upload files, create a file, and create a directory.
{{< figure src="/images/SandstonefileBrowserOver.png">}}
Clicking on either box under "My Spaces" will change your current directory to either your home or work directory and display your user/group usage and quotas. You can then navigate directories by clicking through them in a similar manner as you would with Windows or MacOS.
{{< figure src="/images/SandstonefileOptions.png">}}
Clicking on a file or directory will bring up some options such as the permissions and actions to do such as editing the file, duplicating or moving it, deleting it, and downloading it.
### Editor
The editor is a basic text editor that allows you to have multiple files loaded and manipulate the files. A small file explorer is available on the left side to access more files. There are similar actions available for files above the mini file browser.
{{< figure src="/images/Sandstoneeditor.png">}}
Like most text editors, basic functions exist to undo and redo changes, find and replace, and most importantly, to save the file.
{{< figure src="/images/SandstoneedtiorDropDown.png">}}
### Terminal
The terminal gives you access to the linux command line on crane, similar to what you would have if you SSH'd directly into Crane. Once the login and quote screen, you can enter commands and interact as you would with a standard terminal.
{{< figure src="/images/SandstoneTerminal.png">}}
### Slurm Assist
Slurm assist is a tool to help create and run slurm submit scripts. The first step is to select a base profile from the profile dropdown menu. Options will appear and the directives will automatically appear. The options are editable to better fit to your specific job with more details found in our submitting jobs documentation. After the directives are filled out, you can then add the commands to start your job in the script section. To save the job, select 'save script for later' and save the script in a known location for later.
{{< figure src="/images/SandstoneSASettings.png">}}
From here, you can also schedule the script recently create, by selecting "Schedule Job". A confirmation will appear with the Job ID and then an instruction on how to view the status of your job.
{{< figure src="/images/SandstoneJobConf.png">}}
{{< figure src="/images/SandstoneSAStatus.png">}}
You can view the progress of other jobs from slurm assist by going to the status page. Here you will see the State of the job, its ID, name, group name, runtime, and the start and end times.
{{< figure src="/images/SandstoneSAStatusPage.png">}}
{{< figure src="/images/SandstoneSAStatuses.png">}}
\ No newline at end of file
content/guides/submitting_jobs/condor_jobs_on_hcc.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Condor Jobs on HCC"
description = "How to run jobs using Condor on HCC machines"
weight = "54"
+++
This quick start demonstrates how to run multiple copies of Fortran/C program
using Condor on HCC supercomputers. The sample codes and submit scripts
can be downloaded from [condor_dir.zip](/attachments/3178558.zip).
#### Login to a HCC Cluster
Log in to a HCC cluster through PuTTY ([For Windows Users]({{< relref "/quickstarts/connecting/for_windows_users">}})) or Terminal ([For Mac/Linux Users]({{< relref "/quickstarts/connecting/for_maclinux_users">}})) and make a subdirectory called `condor_dir` under the `$WORK` directory. In the subdirectory `condor_dir`, create job subdirectories that host the input data files. Here we create two job subdirectories, `job_0` and `job_1`, and put a data file (`data.dat`) in each subdirectory. The data file in `job_0` has a column of data listing the integers from 1 to 5. The data file in `job_1` has a integer list from 6 to 10.
{{< highlight bash >}}
$ cd $WORK
$ mkdir condor_dir
$ cd condor_dir
$ mkdir job_0
$ mkdir job_1
{{< /highlight >}}
In the subdirectory condor`_dir`, save all the relevant codes. Here we
include two demo programs, `demo_f_condor.f90` and `demo_c_condor.c`,
that compute the sum of the data stored in each job subdirectory
(`job_0` and `job_1`). The parallelization scheme here is as the
following. First, the master computer node send out many copies of the
executable from the `condor_dir` subdirectory and a copy of the data
file in each job subdirectories. The number of executable copies is
specified in the submit script (`queue`), and it usually matches with
the number of job subdirectories. Next, the workload is distributed
among a pool of worker computer nodes. At any given time, the number of
available worker nodes may vary. Each worker node executes the jobs
independent of other worker nodes. The output files are separately
stored in the job subdirectory. No additional coding are needed to make
the serial code turned "parallel". Parallelization here is achieved
through the submit script.
{{%expand "demo_condor.f90" %}}
{{< highlight fortran >}}
Program demo_f_condor
implicit none
integer, parameter :: N = 5
real*8 w
integer i
common/sol/ x
real*8 x
real*8, dimension(N) :: y_local
real*8, dimension(N) :: input_data
open(10, file='data.dat')
do i = 1,N
read(10,*) input_data(i)
enddo
do i = 1,N
w = input_data(i)*1d0
call proc(w)
y_local(i) = x
write(6,*) 'i,x = ', i, y_local(i)
enddo
write(6,*) 'sum(y) =',sum(y_local)
Stop
End Program
Subroutine proc(w)
real*8, intent(in) :: w
common/sol/ x
real*8 x
x = w
Return
End Subroutine
{{< /highlight >}}
{{% /expand %}}
{{%expand "demo_c_condor.c" %}}
{{< highlight c >}}
//demo_c_condor
#include <stdio.h>
double proc(double w){
double x;
x = w;
return x;
}
int main(int argc, char* argv[]){
int N=5;
double w;
int i;
double x;
double y_local[N];
double sum;
double input_data[N];
FILE *fp;
fp = fopen("data.dat","r");
for (i = 1; i<= N; i++){
fscanf(fp, "%lf", &input_data[i-1]);
}
for (i = 1; i <= N; i++){
w = input_data[i-1]*1e0;
x = proc(w);
y_local[i-1] = x;
printf("i,x= %d %lf\n", i, y_local[i-1]) ;
}
sum = 0e0;
for (i = 1; i<= N; i++){
sum = sum + y_local[i-1];
}
printf("sum(y)= %lf\n", sum);
return 0;
}
{{< /highlight >}}
{{% /expand %}}
---
#### Compiling the Code
The compiled executable needs to match the "standard" environment of the
worker node. The easies way is to directly use the compilers installed
on the HCC supercomputer without loading extra modules. The standard
compiler of the HCC supercomputer is GNU Compier Collection. The version
can be looked up by the command lines `gcc -v` or `gfortran -v`.
{{< highlight bash >}}
$ gfortran demo_f_condor.f90 -o demo_f_condor.x
$ gcc demo_c_condor.c -o demo_c_condor.x
{{< /highlight >}}
#### Creating a Submit Script
Create a submit script to request 2 jobs (queue). The name of the job
subdirectories is specified in the line `initialdir`. The
`$(process)` macro assigns integer numbers to the job subdirectory
name `job_`. The numbers run form `0` to `queue-1`. The name of the input
data file is specified in the line `transfer_input_files`.
{{% panel header="`submit_f.condor`"%}}
{{< highlight bash >}}
universe = grid
grid_resource = pbs
batch_queue = guest
should_transfer_files = yes
when_to_transfer_output = on_exit
executable = demo_f_condor.x
output = Fortran_$(process).out
error = Fortran_$(process).err
initialdir = job_$(process)
transfer_input_files = data.dat
queue 2
{{< /highlight >}}
{{% /panel %}}
{{% panel header="`submit_c.condor`"%}}
{{< highlight bash >}}
universe = grid
grid_resource = pbs
batch_queue = guest
should_transfer_files = yes
when_to_transfer_output = on_exit
executable = demo_c_condor.x
output = C_$(process).out
error = C_$(process).err
initialdir = job_$(process)
transfer_input_files = data.dat
queue 2
{{< /highlight >}}
{{% /panel %}}
#### Submit the Job
The job can be submitted through the command `condor_submit`. The job
status can be monitored by entering `condor_q` followed by the
username.
{{< highlight bash >}}
$ condor_submit submit_f.condor
$ condor_submit submit_c.condor
$ condor_q <username>
{{< /highlight >}}
Replace `<username>` with your HCC username.
Sample Output
-------------
In the job subdirectory `job_0`, the sum from 1 to 5 is computed and
printed to the `.out` file. In the job subdirectory `job_1`, the sum
from 6 to 10 is computed and printed to the `.out` file.
{{%expand "Fortran_0.out" %}}
{{< highlight batchfile>}}
i,x = 1 1.0000000000000000
i,x = 2 2.0000000000000000
i,x = 3 3.0000000000000000
i,x = 4 4.0000000000000000
i,x = 5 5.0000000000000000
sum(y) = 15.000000000000000
{{< /highlight >}}
{{% /expand %}}
{{%expand "Fortran_1.out" %}}
{{< highlight batchfile>}}
i,x = 1 6.0000000000000000
i,x = 2 7.0000000000000000
i,x = 3 8.0000000000000000
i,x = 4 9.0000000000000000
i,x = 5 10.000000000000000
sum(y) = 40.000000000000000
{{< /highlight >}}
{{% /expand %}}
content/guides/submitting_jobs/monitoring_jobs.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Monitoring Jobs"
description = "How to find out information about running and completed jobs."
+++
Careful examination of running times, memory usage and output files will
allow you to ensure the job completed correctly and give you a good idea
of what memory and time limits to request in the future.
### Monitoring Completed Jobs:
To see the runtime and memory usage of a job that has completed, use the
sacct command:
{{< highlight bash >}}
sacct
{{< /highlight >}}
Lists all jobs by the current user and displays information such as
JobID, JobName, State, and ExitCode.
{{< figure src="/images/21070053.png" height="150" >}}
Coupling this command with the --format flag will allow you to see more
than the default information about a job. Fields to display should be
listed as a comma separated list after the --format flag (without
spaces). For example, to see the Elapsed time and Maximum used memory by
a job, this command can be used:
{{< highlight bash >}}
sacct --format JobID,JobName,Elapsed,MaxRSS
{{< /highlight >}}
{{< figure src="/images/21070054.png" height="150" >}}
Additional arguments and format field information can be found in
[the SLURM documentation](https://slurm.schedmd.com/sacct.html).
### Monitoring Running Jobs:
There are two ways to monitor running jobs, the top command and
monitoring the cgroup files. Top is helpful when monitoring
multi-process jobs, whereas the cgroup files provide information on
memory usage. Both of these tools require the use of an interactive job
on the same node as the job to be monitored.
{{% notice warning %}}
If the job to be monitored is using all available resources for a node,
the user will not be able to obtain a simultaneous interactive job.
{{% /notice %}}
After the job to be monitored is submitted and has begun to run, request
an interactive job on the same node using the srun command:
{{< highlight bash >}}
srun --jobid=<JOB_ID> --pty bash
{{< /highlight >}}
Where `<JOB_ID>` is replaced by the job id for the monitored job as
assigned by SLURM.
Alternately, you can request the interactive job by nodename as follows:
{{< highlight bash >}}
srun --nodelist=<NODE_ID> --pty bash
{{< /highlight >}}
Where `<NODE_ID>` is replaced by the node name that the monitored
job is running. This information can be found out by looking at the
squeue output under the `NODELIST` column.
{{< figure src="/images/21070055.png" width="700" >}}
Once the interactive job begins, you can run top to view the processes
on the node you are on:
{{< figure src="/images/21070056.png" height="400" >}}
Output for top displays each running process on the node. From the above
image, we can see the various MATLAB processes being run by user
cathrine98. To filter the list of processes, you can type `u` followed
by the username of the user who owns the processes. To exit this screen,
press `q`.
During a running job, the cgroup folder is created which contains much
of the information used by sacct. These files can provide a live
overview of resources used for a running job. To access the cgroup
files, you will need to be in an interactive job on the same node as the
monitored job. To view specific files, and information, use one of the
following commands:
##### To view current memory usage:
{{< highlight bash >}}
less /cgroup/memory/slurm/uid_<UID>/job_<SLURM_JOB_ID>/memory.usage_in_bytes
{{< /highlight >}}
Where `<UID>` is replaced by your UID and `<SLURM_JOB_ID>` is
replaced by the monitored job's Job ID as assigned by Slurm.
{{% notice note %}}
To find your uid, use the command `id -u`. Your UID never changes and is
the same on all HCC clusters (*not* on Anvil, however!).
{{% /notice %}}
##### To view maximum memory usage from start of job to current point:
{{< highlight bash >}}
cat /cgroup/memory/slurm/uid_${UID}/job_${SLURM_JOBID}/memory.max_usage_in_bytes
{{< /highlight >}}
content/guides/submitting_jobs/partitions/_index.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Partitions"
description = "Listing of partitions on Crane and Rhino."
scripts = ["https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/jquery.tablesorter.min.js", "https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/widgets/widget-pager.min.js","https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/widgets/widget-filter.min.js","/js/sort-table.js"]
css = ["http://mottie.github.io/tablesorter/css/theme.default.css","https://mottie.github.io/tablesorter/css/theme.dropbox.css", "https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/css/jquery.tablesorter.pager.min.css","https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/css/filter.formatter.min.css"]
+++
Partitions are used on Crane and Rhino to distinguish different
resources. You can view the partitions with the command `sinfo`.
### Crane:
[Full list for Crane]({{< relref "crane_available_partitions" >}})
### Rhino:
[Full list for Rhino]({{< relref "rhino_available_partitions" >}})
#### Priority for short jobs
To run short jobs for testing and development work, a job can specify a
different quality of service (QoS). The *short* QoS increases a jobs
priority so it will run as soon as possible.
| SLURM Specification |
|----------------------- |
| `#SBATCH --qos=short` |
{{% panel theme="warning" header="Limits per user for 'short' QoS" %}}
- 6 hour job run time
- 2 jobs of 16 CPUs or fewer
- No more than 256 CPUs in use for *short* jobs from all users
{{% /panel %}}
### Limitations of Jobs
Overall limitations of maximum job wall time. CPUs, etc. are set for
all jobs with the default setting (when thea "–qos=" section is omitted)
and "short" jobs (described as above) on Crane and Rhino.
The limitations are shown in the following form.
| | SLURM Specification | Max Job Run Time | Max CPUs per User | Max Jobs per User |
| ------- | -------------------- | ---------------- | ----------------- | ----------------- |
| Default | Leave blank | 7 days | 2000 | 1000 |
| Short | #SBATCH --qos=short | 6 hours | 16 | 2 |
Please also note that the memory and
local hard drive limits are subject to the physical limitations of the
nodes, described in the resources capabilities section of the
[HCC Documentation]({{< relref "/#resource-capabilities" >}})
and the partition sections above.
### Owned Partitions
Partitions marked as owned by a group means only specific groups are
allowed to submit jobs to that partition. Groups are manually added to
the list allowed to submit jobs to the partition. If you are unable to
submit jobs to a partition, and you feel that you should be, please
contact {{< icon name="envelope" >}}[hcc-support@unl.edu] (mailto:hcc-support@unl.edu).
### Guest Partition
The `guest` partition can be used by users and groups that do not own
dedicated resources on Crane or Rhino. Jobs running in the `guest` partition
will run on the owned resources with Intel OPA interconnect. The jobs
are preempted when the resources are needed by the resource owners and
are restarted on another node.
### tmp_anvil Partition
We have put Anvil nodes which are not running Openstack in this
partition. They have Intel Xeon E5-2650 v3 2.30GHz 2 CPU/20 cores and
256GB memory per node. However, they don't have Infiniband or OPA
interconnect. They are suitable for serial or single node parallel jobs.
The nodes in this partition are subjected to be drained and move to our
Openstack cloud when more cloud resources are needed without notice in
advance.
### Use of Infiniband or OPA
Crane nodes use either Infiniband or Intel Omni-Path interconnects in
the batch partition. Most users don't need to worry about which one to
choose. Jobs will automatically be scheduled for either of them by the
scheduler. However, if the user wants to use one of the interconnects
exclusively, the SLURM constraint keyword is available. Here are the
examples:
{{% panel theme="info" header="SLURM Specification: Omni-Path" %}}
{{< highlight bash >}}
#SBATCH --constraint=opa
{{< /highlight >}}
{{% /panel %}}
{{% panel theme="info" header="SLURM Specification: Infiniband" %}}
{{< highlight bash >}}
#SBATCH --constraint=ib
{{< /highlight >}}
{{% /panel %}}
content/guides/submitting_jobs/partitions/crane_available_partitions.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Available Partitions for Crane"
description = "List of available partitions for crane.unl.edu."
scripts = ["https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/jquery.tablesorter.min.js", "https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/widgets/widget-pager.min.js","https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/widgets/widget-filter.min.js","/js/sort-table.js"]
css = ["http://mottie.github.io/tablesorter/css/theme.default.css","https://mottie.github.io/tablesorter/css/theme.dropbox.css", "https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/css/jquery.tablesorter.pager.min.css","https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/css/filter.formatter.min.css"]
+++
### Crane:
{{< table url="http://crane-head.unl.edu:8192/slurm/partitions/json" >}}
content/guides/submitting_jobs/partitions/rhino_available_partitions.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Available Partitions for Rhino"
description = "List of available partitions for rhino.unl.edu."
scripts = ["https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/jquery.tablesorter.min.js", "https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/widgets/widget-pager.min.js","https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/js/widgets/widget-filter.min.js","/js/sort-table.js"]
css = ["http://mottie.github.io/tablesorter/css/theme.default.css","https://mottie.github.io/tablesorter/css/theme.dropbox.css", "https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/css/jquery.tablesorter.pager.min.css","https://cdnjs.cloudflare.com/ajax/libs/jquery.tablesorter/2.31.1/css/filter.formatter.min.css"]
+++
### Rhino:
{{< table url="http://rhino-head.unl.edu:8192/slurm/partitions/json" >}}
content/guides/submitting_jobs/submitting_an_interactive_job.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Submitting an Interactive Job"
description = "How to run an interactive job on HCC resources."
+++
{{% notice info %}}
The `/home` directories are read-only on the worker nodes. You will need
to compile or run your processing in `/work`.
{{% /notice %}}
Submitting an interactive job is done with the command `srun`.
{{< highlight bash >}}
$ srun --pty $SHELL
{{< /highlight >}}
or to allocate 4 cores per node:
{{< highlight bash >}}
$ srun --nodes=1 --ntasks-per-node=4 --mem-per-cpu=1024 --pty $SHELL
{{< /highlight >}}
Submitting an interactive job is useful if you require extra resources
to run some processing by hand. It is also very useful to debug your
processing.
And interactive job is scheduled onto a worker node just like a regular
job. You can provide options to the interactive job just as you would a
regular SLURM job.
### Priority for short jobs
To run short jobs for testing and development work, a job can specify a
different quality of service (QoS). The *short* QoS increases a jobs
priority so it will run as soon as possible.
| SLURM Specification |
|---------------------|
| `--qos=short` |
{{% panel theme="warning" header="Limits per user for 'short' QoS" %}}
- 6 hour job run time
- 2 jobs of 16 CPUs or fewer
- No more than 256 CPUs in use for *short* jobs from all users
{{% /panel %}}
{{% panel theme="info" header="Using the short QoS" %}}
{{< highlight bash >}}
srun --qos=short --nodes=1 --ntasks-per-node=1 --mem-per-cpu=1024 --pty $SHELL
{{< /highlight >}}
{{% /panel %}}
content/guides/submitting_jobs/submitting_an_mpi_job.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Submitting an MPI Job"
description = "How to submit an MPI job on HCC resources."
+++
This script requests 16 cores on nodes with InfiniBand:
{{% panel theme="info" header="mpi.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --ntasks=16
#SBATCH --mem-per-cpu=1024
#SBATCH --time=03:15:00
#SBATCH --error=/work/[groupname]/[username]/job.%J.err
#SBATCH --output=/work/[groupname]/[username]/job.%J.out
module load compiler/gcc/8.2 openmpi/2.1
mpirun /home/[groupname]/[username]/mpiprogram
{{< /highlight >}}
{{% /panel %}}
The above job will allocate 16 cores on the default partition. The 16
cores could be on any of the nodes in the partition, even split between
multiple nodes.
### Advanced Submission
Some users may prefer to specify more details. This will allocate 32
tasks, 16 on each of two nodes:
{{% panel theme="info" header="mpi.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=16
#SBATCH --mem-per-cpu=1024
#SBATCH --time=03:15:00
#SBATCH --error=/work/[groupname]/[username]/job.%J.err
#SBATCH --output=/work/[groupname]/[username]/job.%J.out
module load compiler/gcc/8.2 openmpi/2.1
mpirun /home/[groupname]/[username]/mpiprogram
{{< /highlight >}}
{{% /panel %}}
content/guides/submitting_jobs/submitting_cuda_or_openacc_jobs.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Submitting CUDA or OpenACC Jobs"
description = "How to submit GPU (CUDA/OpenACC) jobs on HCC resources."
+++
### Available GPUs
Crane has four types of GPUs available in the **gpu** partition. The
type of GPU is configured as a SLURM feature, so you can specify a type
of GPU in your job resource requirements if necessary.
| Description | SLURM Feature | Available Hardware |
| -------------------- | ------------- | ---------------------------- |
| Tesla K20, non-IB | gpu_k20 | 3 nodes - 2 GPUs with 4 GB mem per node |
| Teska K20, with IB | gpu_k20 | 3 nodes - 3 GPUs with 4 GB mem per node |
| Tesla K40, with IB | gpu_k40 | 5 nodes - 4 K40M GPUs with 11 GB mem per node<br> 1 node - 2 K40C GPUs |
| Tesla P100, with OPA | gpu_p100 | 2 nodes - 2 GPUs with 12 GB per node |
| Tesla V100, with 10GbE | gpu_v100 | 1 node - 4 GPUs with 16 GB per node |
To run your job on the next available GPU regardless of type, add the
following options to your srun or sbatch command:
{{< highlight batch >}}
--partition=gpu --gres=gpu
{{< /highlight >}}
To run on a specific type of GPU, you can constrain your job to require
a feature. To run on K40 GPUs for example:
{{< highlight batch >}}
--partition=gpu --gres=gpu --constraint=gpu_k40
{{< /highlight >}}
{{% notice info %}}
You may request multiple GPUs by changing the` --gres` value to
-`-gres=gpu:2`. Note that this value is **per node**. For example,
`--nodes=2 --gres=gpu:2 `will request 2 nodes with 2 GPUs each, for a
total of 4 GPUs.
{{% /notice %}}
### Compiling
Compilation of CUDA or OpenACC jobs must be performed on the GPU nodes.
Therefore, you must run an [interactive job]({{< relref "submitting_an_interactive_job" >}})
to compile. An example command to compile in the **gpu** partition could be:
{{< highlight batch >}}
$ srun --partition=gpu --gres=gpu --mem-per-cpu=1024 --ntasks-per-node=6 --nodes=1 --pty $SHELL
{{< /highlight >}}
The above command will start a shell on a GPU node with 6 cores and 6GB
of ram in order to compile a GPU job. The above command could also be
useful if you want to run a test GPU job interactively.
### Submitting Jobs
CUDA and OpenACC submissions require running on GPU nodes.
{{% panel theme="info" header="cuda.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --time=03:15:00
#SBATCH --mem-per-cpu=1024
#SBATCH --job-name=cuda
#SBATCH --partition=gpu
#SBATCH --gres=gpu
#SBATCH --error=/work/[groupname]/[username]/job.%J.err
#SBATCH --output=/work/[groupname]/[username]/job.%J.out
module load cuda/8.0
./cuda-app.exe
{{< /highlight >}}
{{% /panel %}}
OpenACC submissions require loading the PGI compiler (which is currently
required to compile as well).
{{% panel theme="info" header="openacc.submit" %}}
{{< highlight batch >}}
#!/bin/sh
#SBATCH --time=03:15:00
#SBATCH --mem-per-cpu=1024
#SBATCH --job-name=cuda-acc
#SBATCH --partition=gpu
#SBATCH --gres=gpu
#SBATCH --error=/work/[groupname]/[username]/job.%J.err
#SBATCH --output=/work/[groupname]/[username]/job.%J.out
module load cuda/8.0 compiler/pgi/16
./acc-app.exe
{{< /highlight >}}
{{% /panel %}}
content/guides/submitting_jobs/submitting_htcondor_jobs.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Submitting HTCondor Jobs"
description = "How to submit HTCondor Jobs on HCC resources."
+++
If you require features of HTCondor, such as DAGMan or Pegasus,
[HTCondor](http://research.cs.wisc.edu/htcondor/) can
submit jobs using HTCondor's PBS integration. This can
be done by adding `grid_resource = pbs` to the submit file. An example
submission script is below:
{{% panel theme="info" header="submit.condor" %}}
{{< highlight batch >}}
universe = grid
grid_resource = pbs
executable = test.sh
output = stuff.out
error = stuff.err
log = stuff.log
batch_queue = guest
queue
{{< /highlight >}}
{{% /panel %}}
The above script will translate the condor submit file into a SLURM
submit file, and execute the `test.sh` executable on a worker node.
{{% notice warning %}}
The `/home` directories are read only on the worker nodes. You
have to submit your jobs from the `/work` directory just as you would in
SLURM.
{{% /notice %}}
### Using Pegasus
If you are using [Pegasus](http://pegasus.isi.edu),
instructions on using the *glite* interface (as shown above) are
available on the
[User Guide](http://pegasus.isi.edu/wms/docs/latest/execution_environments.php#glite).
content/osg/_index.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "The Open Science Grid"
description = "How to utilize the Open Science Grid (OSG)."
weight = "40"
+++
If you find that you are not getting access to the volume of computing
resources needed for your research through HCC, you might also consider
submitting your jobs to the Open Science Grid (OSG).
### What is the Open Science Grid?
The [Open Science Grid](http://opensciencegrid.org) advances
science through open distributed computing. The OSG is a
multi-disciplinary partnership to federate local, regional, community
and national cyber infrastructures to meet the needs of research and
academic communities at all scales. HCC participates in the OSG as a
resource provider and a resource user. We provide HCC users with a
gateway to running jobs on the OSG.
The map below shows the Open Science Grid sites located across the U.S.
{{< figure src="/images/17044917.png" >}}
This help document is divided into four sections, namely:
- [Characteristics of an OSG friendly job]({{< relref "characteristics_of_an_osg_friendly_job" >}})
- [How to submit an OSG Job with HTCondor]({{< relref "how_to_submit_an_osg_job_with_htcondor" >}})
- [A simple example of submitting an HTCondorjob]({{< relref "a_simple_example_of_submitting_an_htcondor_job" >}})
- [Using Distributed Environment Modules on OSG]({{< relref "using_distributed_environment_modules_on_osg" >}})
content/osg/a_simple_example_of_submitting_an_htcondor_job.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "A simple example of submitting an HTCondor job"
description = "A simple example of submitting an HTCondor job."
+++
This page describes a complete example of submitting an HTCondor job.
1. SSH to Crane
{{% panel theme="info" header="ssh command" %}}
[apple@localhost]ssh apple@crane.unl.edu
{{% /panel %}}
{{% panel theme="info" header="output" %}}
[apple@login.crane~]$
{{% /panel %}}
2. Write a simple python program in a file "hello.py" that we wish to
run using HTCondor
{{% panel theme="info" header="edit a python code named 'hello.py'" %}}
[apple@login.crane ~]$ vim hello.py
{{% /panel %}}
Then in the edit window, please input the code below:
{{% panel theme="info" header="hello.py" %}}
#!/usr/bin/env python
import sys
import time
i=1
while i<=6:
print i
i+=1
time.sleep(1)
print 2**8
print "hello world received argument = " +sys.argv[1]
{{% /panel %}}
This program will print 1 through 6 on stdout, then print the number
256, and finally print `hello world received argument = <Command
Line Argument Sent to the hello.py>`
3. Write an HTCondor submit script named "hello.submit"
{{% panel theme="info" header="hello.submit" %}}
Universe = vanilla
Executable = hello.py
Output = OUTPUT/hello.out.$(Cluster).$(Process).txt
Error = OUTPUT/hello.error.$(Cluster).$(Process).txt
Log = OUTPUT/hello.log.$(Cluster).$(Process).txt
notification = Never
Arguments = $(Process)
PeriodicRelease = ((JobStatus==5) && (CurentTime - EnteredCurrentStatus) > 30)
OnExitRemove = (ExitStatus == 0)
Queue 4
{{% /panel %}}
4. Create an OUTPUT directory to receive all output files that
generated by your job (OUTPUT folder is used in the submit script
above )
{{% panel theme="info" header="create output directory" %}}
[apple@login.crane ~]$ mkdir OUTPUT
{{% /panel %}}
5. Submit your job
{{% panel theme="info" header="condor_submit" %}}
[apple@login.crane ~]$ condor_submit hello.submit
{{% /panel %}}
{{% panel theme="info" header="Output of submit" %}}
Submitting job(s)
....
4 job(s) submitted to cluster 1013054.
{{% /panel %}}
6. Check status of `condor_q`
{{% panel theme="info" header="condor_q" %}}
[apple@login.crane ~]$ condor_q
{{% /panel %}}
{{% panel theme="info" header="Output of `condor_q`" %}}
-- Schedd: login.crane.hcc.unl.edu : <129.93.227.113:9619?...
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
720587.0 logan 12/15 10:48 33+14:41:17 H 0 0.0 continuous.cron 20
720588.0 logan 12/15 10:48 200+02:40:08 H 0 0.0 checkprogress.cron
1012864.0 jthiltge 2/15 16:48 0+00:00:00 H 0 0.0 test.sh
1013054.0 jennyshao 4/3 17:58 0+00:00:00 R 0 0.0 hello.py 0
1013054.1 jennyshao 4/3 17:58 0+00:00:00 R 0 0.0 hello.py 1
1013054.2 jennyshao 4/3 17:58 0+00:00:00 I 0 0.0 hello.py 2
1013054.3 jennyshao 4/3 17:58 0+00:00:00 I 0 0.0 hello.py 3
7 jobs; 0 completed, 0 removed, 0 idle, 4 running, 3 held, 0 suspended
{{% /panel %}}
Listed below are the three status of the jobs as observed in the
above output
| Symbol | Representation |
|--------|------------------|
| H | Held |
| R | Running |
| I | Idle and waiting |
7. Explanation of the `$(Cluster)` and `$(Process)` in HTCondor script
`$(Cluster)` and `$(Process)` are variables that are available in the
variable name space in the HTCondor script. `$(Cluster)` means the
prefix of your job ID and `$(Process)` varies from `0` through number of
jobs called with `Queue - 1`. If your job is a single job, then
`$(Cluster) =` `<job ID>` else, your job ID is combined with `$(Cluster)` and
`$(Process)`.
In this example, `$(Cluster)`="1013054" and `$(Process)` varies from "0"
to "3" for the above HTCondor script.
In majority of the cases one will use these variables for modifying
the behavior of each individual task of the HTCondor submission, for
example one may vary the input/output file/parameters for the run
program. In this example we are simply passing the `$(Process)` as
arguments as `sys.argv[1]` in `hello.py`.
The lines of interest for this discussion from file the HTCondor
script "hello.submit" are listed below in the code section :
{{% panel theme="info" header="for `$(Process)`" %}}
Output= hello.out.$(Cluster).$(Process).txt
Arguments = $(Process)
Queue 4
{{% /panel %}}
The line of interest for this discussion from file "hello.py" is
listed in the code section below:
{{% panel theme="info" header="for `$(Process)`" %}}
print "hello world received argument = " +sys.argv[1]
{{% /panel %}}
8. Viewing the results of your job
After your job is completed you may use Linux "cat" or "vim" command
to view the job output.
For example in the file `hello.out.1013054.2.txt`, "1013054" means
`$(Cluster)`, and "2" means `$(Process)` the output looks like.
**example of one output file "hello.out.1013054.2.txt"**
{{% panel theme="info" header="example of one output file `hello.out.1013054.2.txt`" %}}
1
2
3
4
5
6
256
hello world received argument = 2
{{% /panel %}}
9. Please see the link below for one more example:
http://research.cs.wisc.edu/htcondor/tutorials/intl-grid-school-3/submit_first.html
Next: [Using Distributed Environment Modules on OSG]({{< relref "using_distributed_environment_modules_on_osg" >}})
content/osg/how_to_submit_an_osg_job_with_htcondor.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "How to submit an OSG job with HTCondor"
description = "How to submit an OSG job with HTCondor"
+++
{{% notice info%}}Jobs can be submitted to the OSG from Crane, so
there is no need to logon to a different submit host or get a grid
certificate!
{{% /notice %}}
### What is HTCondor?
The [HTCondor](http://research.cs.wisc.edu/htcondor)
project provides software to schedule individual applications,
workflows, and for sites to manage resources. It is designed to enable
High Throughput Computing (HTC) on large collections of distributed
resources for users and serves as the job scheduler used on the OSG.
Jobs are submitted from the Crane login node to the
OSG using an HTCondor submission script. For those who are used to
submitting jobs with SLURM, there are a few key differences to be aware
of:
### When using HTCondor
- All files (scripts, code, executables, libraries, etc) that are
needed by the job are transferred to the remote compute site when
the job is scheduled. Therefore, all of the files required by the
job must be specified in the HTCondor submit script. Paths can be
absolute or relative to the local directory from which the job is
submitted. The main executable (specified on the `Executable` line
of the submit script) is transferred automatically with the job.
All other files need to be listed on the `transfer_input_files`
line (see example below).
- All files that are created by
the job on the remote host will be transferred automatically back to
the submit host when the job has completed. This includes
temporary/scratch and intermediate files that are not removed by
your job. If you do not want to keep these files, clean up the work
space on the remote host by removing these files before the job
exits (this can be done using a wrapper script for example).
Specific output file names can be specified with the
`transfer_input_files` option. If these files do
not exist on the remote
host when the job exits, then the job will not complete successfully
(it will be place in the *held* state).
- HTCondor scripts can queue
(submit) as many jobs as you like. All jobs queued from a single
submit script will be identical except for the `Arguments` used.
The submit script in the example below queues 5 jobs with the first
set of specified arguments, and 1 job with the second set of
arguments. By default, `Queue` when it is not followed by a number
will submit 1 job.
For more information and advanced usage, see the
[HTCondor Manual](http://research.cs.wisc.edu/htcondor/manual/v8.3/index.html).
### Creating an HTCondor Script
HTCondor, much like Slurm, needs a script to tell it how to do what the
user wants. The example below is a basic script in a file say
'applejob.txt' that can be used to handle most jobs submitted to
HTCondor.
{{% panel theme="info" header="Example of a HTCondor script" %}}
{{< highlight batch >}}
#with executable, stdin, stderr and log
Universe = vanilla
Executable = a.out
Arguments = file_name 12
Output = a.out.out
Error = a.out.err
Log = a.out.log
Queue
{{< /highlight >}}
{{% /panel %}}
The table below explains the various attributes/keywords used in the above script.
| Attribute/Keyword | Explanation |
| ----------------- | ----------------------------------------------------------------------------------------- |
| # | Lines starting with '#' are considered as comments by HTCondor. |
| Universe | is the way HTCondor manages different ways it can run, or what is called in the HTCondor documentation, a runtime environment. The vanilla universe is where most jobs should be run. |
| Executable | is the name of the executable you want to run on HTCondor. |
| Arguments | are the command line arguments for your program. For example, if one was to run `ls -l /` on HTCondor. The Executable would be `ls` and the Arguments would be `-l /`. |
| Output | is the file where the information printed to stdout will be sent. |
| Error | is the file where the information printed to stderr will be sent. |
| Log | is the file where information about your HTCondor job will be sent. Information like if the job is running, if it was halted or, if running in the standard universe, if the file was check-pointed or moved. |
| Queue | is the command to send the job to HTCondor's scheduler. |
Suppose you would like to submit a job e.g. a Monte-Carlo simulation,
where the same program needs to be run several times with the same
parameters the script above can be used with the following modification.
Modify the `Queue` command by giving it the number of times the job must
be run (and hence queued in HTCondor). Thus if the `Queue` command is
changed to `Queue 5`, a.out will be run 5 times with the exact same
parameters.
In another scenario if you would like to submit the same job but with
different parameters, HTCondor accepts files with multiple `Queue`
statements. Only the parameters that need to be changed should be
changed in the HTCondor script before calling the `Queue`.
Please see "A simple example " in next chapter for the detail use of
`$(Process)`
{{% panel theme="info" header="Another Example of a HTCondor script" %}}
{{< highlight batch >}}
#with executable, stdin, stderr and log
#and multiple Argument parameters
Universe = vanilla
Executable = a.out
Arguments = file_name 10
Output = a.out.$(Process).out
Error = a.out.$(Process).err
Log = a.out.$(Process).log
Queue
Arguments = file_name 20
Queue
Arguments = file_name 30
Queue
{{< /highlight >}}
{{% /panel %}}
### How to Submit and View Your job
The steps below describe how to submit a job and other important job
management tasks that you may need in order to monitor and/or control
the submitted job:
1. How to submit a job to OSG - assuming that you named your HTCondor
script as a file applejob.txt
{{< highlight bash >}}[apple@login.crane ~] $ condor_submit applejob{{< /highlight >}}
You will see the following output after submitting the job
{{% panel theme="info" header="Example of condor_submit" %}}
Submitting job(s)
......
6 job(s) submitted to cluster 1013038
{{% /panel %}}
2. How to view your job status - to view the job status of your
submitted jobs use the following shell command
*Please note that by providing a user name as an argument to the
`condor_q` command you can limit the list of submitted jobs to the
ones that are owned by the named user*
{{< highlight bash >}}[apple@login.crane ~] $ condor_q apple{{< /highlight >}}
The code section below shows a typical output. You may notice that
the column ST represents the status of the job (H: Held and I: Idle
or waiting)
{{% panel theme="info" header="Example of condor_q" %}}
-- Schedd: login.crane.hcc.unl.edu : <129.93.227.113:9619?...
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
1013034.4 apple 3/26 16:34 0+00:21:00 H 0 0.0 sjrun.py INPUT/INP
1013038.0 apple 4/3 11:34 0+00:00:00 I 0 0.0 sjrun.py INPUT/INP
1013038.1 apple 4/3 11:34 0+00:00:00 I 0 0.0 sjrun.py INPUT/INP
1013038.2 apple 4/3 11:34 0+00:00:00 I 0 0.0 sjrun.py INPUT/INP
1013038.3 apple 4/3 11:34 0+00:00:00 I 0 0.0 sjrun.py INPUT/INP
...
16 jobs; 0 completed, 0 removed, 12 idle, 0 running, 4 held, 0 suspended
{{% /panel %}}
3. How to release a job - in a few cases a job may get held because of
reasons such as authentication failure or other non-fatal errors, in
those cases you may use the shell command below to release the job
from the held status so that it can be rescheduled by the HTCondor.
*Release one job:*
{{< highlight bash >}}[apple@login.crane ~] $ condor_release 1013034.4{{< /highlight >}}
*Release all jobs of a user apple:*
{{< highlight bash >}}[apple@login.crane ~] $ condor_release apple{{< /highlight >}}
4. How to delete a submitted job - if you want to delete a submitted
job you may use the shell commands as listed below
*Delete one job:*
{{< highlight bash >}}[apple@login.crane ~] $ condor_rm 1013034.4{{< /highlight >}}
*Delete all jobs of a user apple:*
{{< highlight bash >}}[apple@login.crane ~] $ condor_rm apple{{< /highlight >}}
5. How to get help form HTCondor command
You can use man to get detail explanation of HTCondor command
{{% panel theme="info" header="Example of help of condor_q" %}}
[apple@glidein ~]man condor_q
{{% /panel %}}
{{% panel theme="info" header="Output of `man condor_q`" %}}
just-man-pages/condor_q(1) just-man-pages/condor_q(1)
Name
condor_q Display information about jobs in queue
Synopsis
condor_q [ -help ]
condor_q [ -debug ] [ -global ] [ -submitter submitter ] [ -name name ] [ -pool centralmanagerhost-
name[:portnumber] ] [ -analyze ] [ -run ] [ -hold ] [ -globus ] [ -goodput ] [ -io ] [ -dag ] [ -long ]
[ -xml ] [ -attributes Attr1 [,Attr2 ... ] ] [ -format fmt attr ] [ -autoformat[:tn,lVh] attr1 [attr2
...] ] [ -cputime ] [ -currentrun ] [ -avgqueuetime ] [ -jobads file ] [ -machineads file ] [ -stream-
results ] [ -wide ] [ {cluster | cluster.process | owner | -constraint expression ... } ]
Description
condor_q displays information about jobs in the Condor job queue. By default, condor_q queries the local
job queue but this behavior may be modified by specifying:
* the -global option, which queries all job queues in the pool
* a schedd name with the -name option, which causes the queue of the named schedd to be queried
{{% /panel %}}
Next: [A simple example of submitting an HTCondorjob]({{< relref "a_simple_example_of_submitting_an_htcondor_job" >}})
content/osg/using_distributed_environment_modules_on_osg.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Using Distributed Environment Modules on OSG"
description = "Using Distributed Environment Modules on OSG"
+++
Many commonly used software packages and libraries are provided on the
OSG through the `module` command. OSG modules are made available
through the OSG Application Software Installation Service (OASIS). The
set of modules provided on OSG can differ from those on the HCC
clusters. To switch to the OSG modules environment on an HCC machine:
{{< highlight bash >}}
[apple@login.crane~]$ source osg_oasis_init
{{< /highlight >}}
Use the module avail command to see what software and libraries are
available:
{{< highlight bash >}}
[apple@login.crane~]$ module avail
------------------- /cvmfs/oasis.opensciencegrid.org/osg/modules/modulefiles/Core --------------------
abyss/2.0.2 gnome_libs/1.0 pegasus/4.7.1
ant/1.9.4 gnuplot/4.6.5 pegasus/4.7.3
ANTS/1.9.4 graphviz/2.38.0 pegasus/4.7.4 (D)
ANTS/2.1.0 (D) grass/6.4.4 phenix/1.10
apr/1.5.1 gromacs/4.6.5 poppler/0.24.1 (D)
aprutil/1.5.3 gromacs/5.0.0 (D) poppler/0.32
arc-lite/2015 gromacs/5.0.5.cuda povray/3.7
atlas/3.10.1 gromacs/5.0.5 proj/4.9.1
atlas/3.10.2 (D) gromacs/5.1.2-cuda proot/2014
autodock/4.2.6 gsl/1.16 protobuf/2.5
{{< /highlight >}}
Loading modules is done with the `module load` command:
{{< highlight bash >}}
[apple@login.crane~]$ module load python/2.7
{{< /highlight >}}
There are two things required in order to use modules in your HTCondor
job.
1. Create a *wrapper script* for the job. This script will be the
executable for your job and will load the module before running the
main application.
2. Include the following requirements in the HTCondor submission
script:
{{< highlight batch >}}Requirements = (HAS_MODULES =?= TRUE){{< /highlight >}}
or
{{< highlight batch >}}Requirements = [Other requirements ] && (HAS_MODULES =?= TRUE){{< /highlight >}}
### A simple example using modules on OSG
The following example will demonstrate how to use modules on OSG with an
R script that implements a Monte-Carlo estimation of Pi (`mcpi.R`).
First, create a file called `mcpi.R`:
{{% panel theme="info" header="mcpi.R" %}}{{< highlight R >}}
montecarloPi <- function(trials) {
count = 0
for(i in 1:trials) {
if((runif(1,0,1)^2 + runif(1,0,1)^2)<1) {
count = count + 1
}
}
return((count*4)/trials)
}
montecarloPi(1000)
{{< /highlight >}}{{% /panel %}}
Next, create a wrapper script called `R-wrapper.sh` to load the required
modules (`R` and `libgfortran`), and execute the R script:
{{% panel theme="info" header="R-wrapper.sh" %}}{{< highlight bash >}}
#!/bin/bash
EXPECTED_ARGS=1
if [ $# -ne $EXPECTED_ARGS ]; then
echo "Usage: R-wrapper.sh file.R"
exit 1
else
module load R
module load libgfortran
Rscript $1
fi
{{< /highlight >}}{{% /panel %}}
This script takes the name of the R script (`mcpi.R`) as it's argument
and executes it in batch mode (using the `Rscript` command) after
loading the `R` and `libgfortran` modules.
Make the script executable:
{{< highlight bash >}}[apple@login.crane~]$ chmod a+x R-script.sh{{< /highlight >}}
Finally, create the HTCondor submit script, `R.submit`:
{{% panel theme="info" header="R.submit" %}}{{< highlight batch >}}
universe = vanilla
log = mcpi.log.$(Cluster).$(Process)
error = mcpi.err.$(Cluster).$(Process)
output = mcpi.out.$(Cluster).$(Process)
executable = R-wrapper.sh
transfer_input_files = mcpi.R
arguments = mcpi.R
Requirements = (HAS_MODULES =?= TRUE)
queue 100
{{< /highlight >}}{{% /panel %}}
This script will queue 100 identical jobs to estimate the value of Pi.
Notice that the wrapper script is transferred automatically with the
job because it is listed as the executable. However, the R script
(`mcpi.R`) must be listed after `transfer_input_files` in order to be
transferred with the job.
Submit the jobs with the `condor_submit` command:
{{< highlight bash >}}[apple@login.crane~]$ condor_submit R.submit{{< /highlight >}}
Check on the status of your jobs with `condor_q`:
{{< highlight bash >}}[apple@login.crane~]$ condor_q{{< /highlight >}}
When your jobs have completed, find the average estimate for Pi from all
100 jobs:
{{< highlight bash >}}
[apple@login.crane~]$ grep "[1]" mcpi.out.* | awk '{sum += $2} END { print "Average =", sum/NR}'
Average = 3.13821
{{< /highlight >}}
content/quickstarts/_index.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Quickstarts"
weight = "10"
+++
The quick start guides require that you already have a HCC account. You
can get a HCC account by applying on the
[HCC website] (http://hcc.unl.edu/newusers/)
{{% children %}}
content/quickstarts/connecting/_index.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "How to Connect"
description = "What is a cluster and what is HPC"
weight = "9"
+++
High-Performance Computing is the use of groups of computers to solve computations a user or group would not be able to solve in a reasonable time-frame on their own desktop or laptop. This is often achieved by splitting one large job amongst numerous cores or 'workers'. This is similar to how a skyscraper is built by numerous individuals rather than a single person. Many fields take advantage of HPC including bioinformatics, chemistry, materials engineering, and newer fields such as educational psychology and philosophy.
{{< figure src="/images/cluster.png" height="450" >}}
HPC clusters consist of four primary parts, the login node, management node, workers, and a central storage array. All of these parts are bound together with a scheduler such as HTCondor or SLURM.
</br></br>
#### Login Node:
Users will automatically land on the login node when they log in to the clusters. You will [submit jobs] ({{< ref "/guides/submitting_jobs" >}}) using one of the schedulers and pull the results of your jobs. Running jobs on the login node directly will be stopped so others can use the login node to submit jobs.
</br></br>
#### Management Node:
The management node does as it sounds, it manages the cluster and provides a central point to manage the rest of the systems.
</br></br>
#### Worker Nodes:
The worker nodes are what run and process your jobs that are submitted from the schedulers. Through the use of the schedulers, more work can be efficiently done by squeezing in all jobs possible for the resources requested throughout the nodes. They also allow for fair use computing by making sure one user or group is not using the entire cluster at once and allowing others to use the clusters.
</br></br>
#### Central Storage Array:
The central storage array allows all of the nodes within the cluster to have access to the same files without needing to transfer them around. HCC has three arrays mounted on the clusters with more details [here]({{< ref "/guides/handling_data" >}}).
content/quickstarts/connecting/basic_linux_commands.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "Basic Linux commands"
description = "Simple commands you'll want to know"
weight = "32"
+++
Basic commands
--------------
###### [[Jump to the Video Tutorial]](#tutorial-video)
Holland clusters all run on the Linux operating system, similarly to how
your personal computer might run Windows or Mac OS. However, unlike
Windows or Mac OS, our systems do not utilize a graphical user interface
where you can use a mouse to navigate and initiate commands. Instead, we
use a command line interface, where the user types in commands which are
then processed and text output is displayed on the screen. The default
shell used is Bash. Bash may seem complicated to learn at first, but
with just a small handful of commands, you can do anything that you
would usually do with a mouse. **In fact, once people become proficient
in Bash, many of them prefer it over graphical interfaces due to its
versatility and performance.**
Below, we have compiled a list of common commands and usage examples.
For a more information, check out one of these references:
- [Software Carpentry’s "Introduction to the Bash Shell" Lesson](https://eharstad.github.io/shell-novice) -
a great walkthrough of the basics of Bash designed for novice users
- [Linux Users Guide](http://www.comptechdoc.org/os/linux/usersguide) -
detailed information about the Linux command line and how to utilize
it
- [Linux Command Line Cheat Sheet](https://www.cheatography.com/davechild/cheat-sheets/linux-command-line) -
a quick reference for Linux commands. Offers a PDF version that you
can print out.
Linux Commands Reference List:
------------------------------
<table>
<tbody>
<tr class="odd">
<td>ls</td>
<td>list: Lists the files and directories located in the current directory</td>
<td><ul>
<li>ls</li>
<li>`ls -a`
<ul>
<li>shows all the files in the directory, including hidden ones</li>
</ul></li>
<li>ls -l
<ul>
<li>shows contents in a list format including information such as file size, file permissions and date the file was modified</li>
</ul></li>
<li>ls *.txt
<ul>
<li>shows all files in the current directory which end with .txt</li>
</ul></li>
</ul></td>
</tr>
<tr class="even">
<td>cd</td>
<td>change directory: this allows users to navigate in or out of file directories</td>
<td><ul>
<li>cd &lt;folder path&gt;</li>
<li>cd folder_name
<ul>
<li>navigates into directory &quot;folder_name&quot; located in the current directory</li>
</ul></li>
<li>cd ..
<ul>
<li>navigates out of a directory and into the parent directory</li>
</ul>
cd $HOME (or $WORK)
<ul>
<li>navigates to a user's home (or work) directory</li>
</ul></li>
</ul></td>
</tr>
<tr class="odd">
<td>mv</td>
<td>move: used to move a file or directory to another location</td>
<td><ul>
<li>mv &lt;current file(s)&gt; &lt;target file(s)&gt;</li>
<li>mv * ../
<ul>
<li>moves all files from the current directory into the parent directory</li>
</ul></li>
<li>mv old_filename new_filename
<ul>
<li>renames the file &quot;old_filename&quot; to &quot;new_filename&quot;</li>
</ul></li>
</ul></td>
</tr>
<tr class="even">
<td>cp</td>
<td>copy: used to copy a file or directory to another location</td>
<td><ul>
<li>cp &lt;current file(s)&gt; &lt;target file(s)&gt;</li>
<li>cp * ../
<ul>
<li>copies all files in the current directory and puts the copies into the parent directory</li>
</ul></li>
<li>cp -r ./orig_folder ./new_folder<br />
<ul>
<li>copies all files and directories within orig_folder into new_folder (-r indicates this is a recursive copy, so all sub-directories and files within orig_folder will be included in new_folder)</li>
</ul></li>
</ul></td>
</tr>
<tr class="odd">
<td>man</td>
<td><p>manual: displays documentation for commands</p>
<p><strong>Note:</strong> Use up and down arrows to scroll through the text. To exit the manual display, press 'q'</p></td>
<td><ul>
<li>man &lt;command name&gt;</li>
<li>man ls
<ul>
<li>displays documentation for the ls command</li>
</ul></li>
</ul></td>
</tr>
<tr class="even">
<td>mkdir</td>
<td>make directory: creates a directory with the specified name</td>
<td><ul>
<li>mkdir &lt;new_folder&gt;
<ul>
<li>creates the directory &quot;new_folder&quot; within the current directory</li>
</ul></li>
</ul></td>
</tr>
<tr class="odd">
<td>rmdir</td>
<td><p>remove directory: deletes a directory with the specified name</p>
<p><strong>Note:</strong> rmdir only works on empty directories</p></td>
<td><ul>
<li>rmdir &lt;folder_name&gt;
<ul>
<li>removes the directory &quot;folder_name&quot; if the directory is empty</li>
</ul></li>
<li>rmdir *
<ul>
<li>removes all directories within the current directory</li>
</ul></li>
</ul></td>
</tr>
<tr class="even">
<td>rm</td>
<td>remove: deletes file or files with the specified name(s)</td>
<td><ul>
<li>rm &lt;file_name&gt;
<ul>
<li>deletes the file &quot;file_name&quot;</li>
</ul></li>
<li>rm *
<ul>
<li>deletes all files in the current directory</li>
</ul></li>
</ul></td>
</tr>
<tr class="odd">
<td><p>nano</p></td>
<td><p>nano text editor: opens the nano text editor</p>
<p><strong>Note:</strong> To access the menu options, ^ indicates the control (CTRL) key.</p></td>
<td><ul>
<li>nano
<ul>
<li>opens the text editor in a blank file</li>
</ul></li>
<li>nano &lt;file_name&gt;
<ul>
<li>opens the text editor with &quot;file_name&quot; open. If &quot;file_name&quot; does not exist, it will be created if the file is saved</li>
</ul></li>
</ul></td>
</tr>
<tr class="even">
<td>clear</td>
<td>clear: clears the screen of all input/output</td>
<td><ul>
<li>clear</li>
</ul></td>
</tr>
<tr class="odd">
<td>less</td>
<td><p>less: opens an extended view of a file</p>
<p><strong>Note:</strong> Use up and down arrows to scroll through the text. To exit the extended view, press 'q'</p></td>
<td><ul>
<li>less &lt;file_name&gt;
<ul>
<li>opens an extended view of the file &quot;file_name&quot;</li>
</ul></li>
</ul></td>
</tr>
<tr class="even">
<td>cat</td>
<td>concatenate: sends file contents to standard input - used frequently with pipes</td>
<td><ul>
<li>cat &lt;file_name&gt;
<ul>
<li>prints the contents of the file &quot;file_name&quot;</li>
</ul></li>
<li>cat *.txt
<ul>
<li>prints the contents of all files in the current directory that end in &quot;.txt&quot;</li>
</ul></li>
</ul></td>
</tr>
</tbody>
</table>
Tutorial Video
--------------
{{< youtube B0VdKiHNjU4 >}}
content/quickstarts/connecting/for_maclinux_users.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "For Mac/Linux Users"
description = "Quickstart Guide for Mac/Linux Users"
weight = "22"
+++
##### Use of Duo two-factor authentication is **required** to access HCC resources.
##### Please see [Setting up and Using Duo]({{< relref "setting_up_and_using_duo" >}}).
---
- [Access to HCC Supercomputers] (#access-to-hcc-supercomputers)
- [File Transferring with HCC Supercomputers] (#file-transfering)
- [SCP] (#using-the-scp-command)
- [CyberDuck] (#using-cyberduck)
- [Mac Tutorial Video](#mac-tutorial-video)
- [Linux Tutorial Video](#linux-tutorial-video)
This quick start will help you configure your personal computer to work
with the HCC supercomputers.
If you are running Windows, please use the quickstart [For Windows
Users]({{< relref "for_windows_users" >}}).
Access to HCC Supercomputers
-------------------------------
For Mac/Linux users, use the system program Terminal to access to the
HCC supercomputers. In the Terminal prompt,
type `ssh <username>@crane.unl.edu` and the corresponding password
to get access to the HCC cluster **Crane**. Note that &lt;username&gt;
should be replaced by your HCC account username. If you do not have a
HCC account, please contact a HCC specialist
({{< icon name="envelope" >}}[hcc-support@unl.edu] (mailto:hcc-support@unl.edu))
or go to https://hcc.unl.edu/newusers.
To use the **Rhino** cluster, replace crane.unl.edu with with rhino.unl.edu.
{{< highlight bash >}}
$ ssh <username>@crane.unl.edu
$ <password>
{{< /highlight >}}
File Transferring with HCC Supercomputers
-----------------------------------------
### Using the SCP command
For Mac/Linux users, file transferring between your personal computer
and the HCC supercomputers can be achieved through the command `scp`.
Here we use **Crane** for example. **The following commands should be
executed from your computer. **
**Uploading from local to remote**
{{< highlight bash >}}
$ scp -r ./<folder name> <username>@crane.unl.edu:/work/<group name>/<username>
{{< /highlight >}}
The above command line transfers a folder from the current directory
(`./`) of the your computer to the `$WORK` directory of the HCC
supercomputer, Crane. Note that you need to replace `<group name>`
and `<username>` with your HCC group name and username.
**Downloading from remote to local**
{{< highlight bash >}}
$ scp -r <username>@crane.unl.edu:/work/<group name>/<username>/<folder name> ./
{{< /highlight >}}
The above command line transfers a folder from the `$WORK` directory of
the HCC supercomputer, Crane, to the current directory (`./`) of the
your computer.
### Using Cyberduck
---------------
If you wish to use a GUI, be aware that not all programs will function
correctly with Duo two-factor authentication. Mac users are recommended
to use [Cyberduck](https://cyberduck.io). It is compatible with Duo, but a
few settings need to be changed.
Under **Preferences - General**, change the default protocol to SFTP:
{{< figure src="/images/7274497.png" height="450" >}}
Under **Preferences - Transfers**, reuse the browser connection for file
transfers. This will avoid the need to reenter your password for every
file transfer:
{{< figure src="/images/7274498.png" height="450" >}}
Finally, under **Preferences - SFTP**, set the file transfer method to
SCP:
{{< figure src="/images/7274499.png" height="450" >}}
To add an HCC machine, in the bookmarks pane click the "+" icon:
{{< figure src="/images/7274500.png" height="450" >}}
Ensure the type of connection is SFTP. Enter the hostname of the machine
you wish to connect to (crane.unl.edu, rhino.unl.edu) in the **Server**
field, and your HCC username in the **Username** field. The
**Nickname** field is arbitrary, so enter whatever you prefer.
{{< figure src="/images/7274501.png" height="450" >}}
After you add the bookmark, double-click it to connect.
{{< figure src="/images/7274505.png" height="450" >}}
Enter your HCC username and password in the dialog box that will appear
and click *Login*.
{{< figure src="/images/7274508.png" height="450" >}}
A second login dialogue will now appear. Notice the text has changed to
say Duo two-factor.
{{< figure src="/images/7274510.png" height="450" >}}
Clear the **Password** field in the dialogue. If you are using the Duo
Mobile app, enter '1' to have a push notification send to your phone or
tablet. If you are using a Yubikey, ensure the cursor is active in the
**Password** field, and press the button on the Yubikey.
{{< figure src="/images/7274509.png" height="450" >}}
The login should complete and you can simply drag and drop files to or
from the window.
{{< figure src="/images/7274511.png" height="450" >}}
Mac Tutorial Video
------------------
{{< youtube ulfcmRGfqxU >}}
Linux Tutorial Video
--------------------
{{< youtube K0i3swpwtdc >}}
content/quickstarts/connecting/for_windows_users.md deleted 100644 → 0
View file @ 9d5e5e58
+++
title = "For Windows Users"
description = "Quickstart for Windows Users"
weight = "20"
+++
##### Use of Duo two-factor authentication is **required** to access HCC resources.
##### Please see [Setting up and Using Duo]({{< relref "setting_up_and_using_duo" >}}).
---
- [Access to HCC Supercomputers] (#access-to-hcc-supercomputers)
- [For Windows 10 Users](#windows-10)
- [For Windows 7 and 8.1 Users](#windows-7-and-8-1)
- [File Transferring with HCC Supercomputers] (#file-transferring)
- [SCP - Command Line] (#scp)
- [WinSCP - GUI] (#winscp)
- [Tutorial Video](#tutorial-video)
Access to HCC Supercomputers
-------------------------------
{{% notice info %}}
If you are on a Mac, please use the quickstart for [For Mac/Linux
Users]({{< relref "for_maclinux_users" >}}).
{{% /notice %}}
### Windows 10
--------------
For Windows 10 users, use the Command Prompt, accessed by entering `cmd` in the start menu, to access to the
HCC supercomputers. In the Command Prompt,
type `ssh <username>@crane.unl.edu` and the corresponding password
to get access to the HCC cluster **Crane**. Note that &lt;username&gt;
should be replaced by your HCC account username. If you do not have a
HCC account, please contact a HCC specialist
({{< icon name="envelope" >}}[hcc-support@unl.edu] (mailto:hcc-support@unl.edu))
or go to http://hcc.unl.edu/newusers.
{{< highlight bash >}}
C:\> ssh <username>@crane.unl.edu
C:\> <password>
{{< /highlight >}}
### Windows 7 and 8.1
--------------
This quick start will help you configure your personal computer to work
with the HCC supercomputers. Here we use the two third party application
**PuTTY** and **WinSCP** for demonstration.
PuTTY: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
or [Direct Link](https://the.earth.li/~sgtatham/putty/latest/w32/putty.exe)
Here we use the HCC cluster **Tusker** for demonstration. To use the
**Crane** cluster, replace `tusker.unl.edu` with `crane.unl.edu`.
1. On the first screen, type `tusker.unl.edu` for Host Name, then click
**Open**.
{{< figure src="/images/3178523.png" height="450" >}}
2. On the second screen, click on **Yes**.
{{< figure src="/images/3178524.png" height="300" >}}
3. On the third screen, enter your HCC account **username**. If you do
not have a HCC account, please contact an HCC specialist
({{< icon name="envelope" >}}[hcc-support@unl.edu] (mailto:hcc-support@unl.edu))
or go to http://hcc.unl.edu/newusers.
{{% notice info %}}Replace `jingchao` with your username.{{% /notice %}}
{{< figure src="/images/8127261.png" height="450" >}}
4. On the next screen, enter your HCC account **password**.
{{% notice info %}}**Note that PuTTY will not show the characters as you type for security reasons.**{{% /notice %}}
{{< figure src="/images/8127262.png" height="450" >}}
5. After you input the correct
password, you will be asked to choose a Duo authentication
method.
6. If you have a Yubikey set up by HCC, please hold the Yubikey for \~1
second. Then you will be brought to your home directory similar as
below.
{{< figure src="/images/8127266.png" height="450" >}}
7. If you set up Duo via a smart phone, please type "1" in your
terminal and press "Enter". (Duo-Push is the most cost-effective way
for Duo authentication, we recommend all user use this option if
that is applicable.)
8. Check your smart phone for Duo login request. Press "Approve" if you
can verify the request. If you find any Duo login request that is
not initiated by yourself, deny it and report this incident
immediately to {{< icon name="envelope" >}}[hcc-support@unl.edu] (mailto:hcc-support@unl.edu).
{{< figure src="/images/8127263.png" height="450" >}}
9. After you approve the Duo login request, you will be brought to your
home directory similar as below.
{{< figure src="/images/8127264.png" height="450" >}}
File Transferring with HCC Supercomputers
-----------------------------------------
{{% notice info%}}
For best results when transfering data to and from the clusters, refer to [Handling Data]({{< ref "/guides/handling_data" >}})
{{%/notice%}}
### SCP
For Windows users, file transferring between your personal computer
and the HCC supercomputers can be achieved through the command `scp`.
Here we use **Tusker** for example. **The following commands should be
executed from your computer. **
**Uploading from local to remote**
{{< highlight bash >}}
C:\> scp -r .\<folder name> <username>@tusker.unl.edu:/work/<group name>/<username>
{{< /highlight >}}
The above command line transfers a folder from the current directory
(`.\`) of the your computer to the `$WORK` directory of the HCC
supercomputer, Tusker. Note that you need to replace `<group name>`
and `<username>` with your HCC group name and username.
**Downloading from remote to local**
{{< highlight bash >}}
C:\> scp -r <username>@tusker.unl.edu:/work/<group name>/<username>/<folder name> .\
{{< /highlight >}}
The above command line transfers a folder from the `$WORK` directory of
the HCC supercomputer, Tusker, to the current directory (`.\`) of the
your computer.
### WinSCP
WinSCP: http://winscp.net/eng/download.php
Usually it is convenient to upload and download files between your personal computer
and the HCC supercomputers through a Graphic User Interface (GUI).
Download and install the third party application **WinSCP**
to connect the file systems between your personal computer and the HCC supercomputers.
Below is a step-by-step installation guide. Here we use the HCC cluster **Tusker**
for demonstration. To use the **Crane** cluster, replace `tusker.unl.edu`
with `crane.unl.edu`.
1. On the first screen, type `tusker.unl.edu` for Host name, enter your
HCC account username and password for User name and Password. Then
click on **Login**.
{{< figure src="/images/3178530.png" height="450" >}}
2. On the second screen, click on **Yes**.
{{< figure src="/images/3178531.png" >}}
3. Choose option "1" and press "Enter". Or simply press your Yubikey if
you have one.
{{< figure src="/images/8127268.png" >}}
4. On the third screen, click on **Remote**. Under Remote, choose Go To
and Open Directory/Bookmark. Alternatively, you can use the keyboard
shortcut "Ctrl + O".
{{< figure src="/images/3178532.png" height="450" >}}
5. On the final screen, type `/work/<group name>/<username>` for Open
directory. Use your HCC group name and username to replace
`<group name>` and `<username>`. Then click on **OK**.
{{< figure src="/images/3178533.png" height="450" >}}
6. Now you can drop and drag the files between your personal computer
and the HCC supercomputers.
{{< figure src="/images/3178539.png" height="450" >}}
Tutorial Video
--------------
{{< youtube -Vh7SyC-3mA >}}