Table of Contents

• Connecting to taki
• A brief tour of your account
• Things to check on your new taki account
• Modules
• Storage areas

This tutorial below will walk you through your home directory, some useful Linux information, review what to expect in your new account, the module utility to load software, and the specialized storage areas on taki.

This video recording of a tour of the HPCF webpage is a good start to make sure you find all important information on this webpage.

Connecting to taki

The only nodes with a connection to the outside network are the login nodes, also called user nodes. Internally to the system, their full hostnames are taki-usr1.rs.umbc.edu and taki-usr2.rs.umbc.edu (notice the “-usr1” and “-usr2”). From the outside, we must refer to the hostname taki.rs.umbc.edu. To log in to the system, you must use a secure shell like (i) ssh from a Unix/Linux computer, (ii) ssh from a terminal window on a Mac computer, (iii) PuTTy from a Windows computer, (iv) ssh from a Windows PowerShell on a Windows computer, (v) using Termious, or (vi) using Remote-SSH extension in Visual Studio Code(VSC). A lot of our documentation uses the classical PuTTy approach to connect from a Windows computer, but the natively built-in Windows PowerShell is an alternative. The following two subsections document the PowerShell first and PuTTy second.

How to use Windows PowerShell

The following links provide a sequence of three videos that document the setup and use of the Windows PowerShell fully, with the second one already addressing how to connect graphically to taki. The first video shows how to Setup Native SSH Client. The second video shows how to Setup an X11 graphics connection from taki to your Windows computer using VcXsrv, a freely available X-server. Now that we have this, we can enable autologin to avoid typing in your password every time you start a new session. Please follow the video Setup SSH Keys and Autologins to enable autologin on Windows PowerShell.

Here is a summary of the steps that the above videos detail:

1. In Windows Settings >Apps and Features, click Optional Features, and then Add a Feature. Search for “ssh” and click to install the OpenSSH Client.
2. In the Windows Search bar, look for PowerShell; you can pin it to the task bar for future use, as it is already done in the first video (see bottom of that Windows screen).
3. Download the X-server VcXsrv and install on your computer once.
4. In the Windows Search bar, look for environment variables (type “env” and it should complete to “Edit the system environment variables”). In the Advanced tab, click on the Environment Variables button. In the resulting window under the User variables list, click the New button and fill in the Variable name as DISPLAY and Variable value as localhost:0.0. You do this setup once only.
5. Launch the X-server XLaunch of VcXsrv every time you want to have a graphics connection from taki; you may want to pin XLaunch to the task bar for future use.
6. Start a Windows PowerShell and then use the command ssh to connect to taki. To request a graphics connection, use the option -X or -Y. Your username on your local computer may not be the same as your username on taki, so the full command for example for user “gobbert” on taki would read:
   ssh -Y gobbert@taki.rs.umbc.edu

Follow the next section How to use PuTTy to see basic Linux shell commands.

How to use PuTTy

Please note that the video mentioned below uses a saved “taki.rs” session on PuTTy. In order to save a session on PuTTy, you must enter your preferred settings along with the hostname. Then you can type in the session name of your choice (in the video Dr. Gobbert’s saved session is named “taki.rs” but you can name a session whatever you’d like) in the “Saved Sessions” section. Click save and it will save your preferred settings and hostname for each connection. Now you can just click load in the saved sessions as per the video instead of having to change settings and enter hostname every time you connect to PuTTy.

This video recording on writing a “Hello, world!” program in C demonstrates also how to log in using the freely available terminal client PuTTY from a Windows laptop, shows basic Linux shell commands, and contrasts the three editors available on taki.

You connect to the user node, which is the only node visible from the internet. For example, suppose we are connecting to taki from the Linux machine “linux1.gl.umbc.edu”. We will take user “gobbert” as our example throughout this page.

linux1 ~ 101% ssh gobbert@taki.rs.umbc.edu
WARNING: UNAUTHORIZED ACCESS to this computer is in violation of Criminal
         Law Article section 8-606 and 7-302 of the Annotated Code of MD.

NOTICE:  This system is for the use of authorized users only.
         Individuals using this computer system without authority, or in
         excess of their authority, are subject to having all of their
         activities on this system monitored and recorded by system
         personnel.

gobbert@taki.rs.umbc.edu's password: 
Last login: Wed Oct 31 08:55:30 2018 from pc23.math.umbc.edu

  UMBC High Performance Computing Facility              http://hpcf.umbc.edu
  --------------------------------------------------------------------------
  By using this system you agree with and will adhere to the HPCF usage
  policy.  If you have any questions or problems using this system please
  submit a help request via the "Help Request" link found on the HPCF
  website under "Forms".

  Remember that the Division of Information Technology will never ask for
  your password. Do NOT give out this information under any circumstances.
  --------------------------------------------------------------------------

Replace “gobbert” with your UMBC username (that you use to log into myUMBC). You will be prompted for your password when connecting; your password is your myUMBC password. Notice that connecting to taki.rs.umbc.edu puts us on taki-usr1. We may connect to the other user node with the following.

[gobbert@taki-usr1 ~]$ ssh taki-usr2
Warning: Permanently added 'taki-usr2,10.2.15.252' (ECDSA) to the list of known hosts.
... same welcome message ...
[gobbert@taki-usr2 ~]$

As another example, suppose we’re SSHing to taki from a Windows machine with PuTTY. When setting up a connection, use “taki.rs.umbc.edu” as the hostname. Once you connect, you will be prompted for your username and password, as mentioned above.

How to use Remote-SSH in Visual Studio Code(VSCode)

Detailed information on how to use Remote-SSH has been provided in Remote Development using SSH tutorial. In the following, we summarize the required steps for utilizing Remote-SSH in VSC for your convenience:

1. Install the Remote-SSH extension in Visual Studio Code from the extensions marketplace. You can do this by clicking on the Extensions icon in the left sidebar, searching for Remote-SSH, and clicking the Install button.
2. In Visual Studio Code, click on the Remote Explorer icon in the left sidebar and click on the “+” sign in the top menu and select “Add SSH Host…”.
3. In the “Enter SSH connection details” dialog box, enter the connection details for your remote server. This will include the server address, username, and password. You can also import full command like ssh username@taki.rs.umbc.edu.
4. Once you’ve entered the connection details, click the “Connect” button. Visual Studio Code will then attempt to connect to the remote server. If the connection is successful, you’ll see a list of available folders on the remote server in the Remote Explorer sidebar.
5. Click on the folder you want to work with, and Visual Studio Code will open a new window with that folder open. You can then edit and save files just as you would if you were working locally.
6. When you’re finished working on the remote server, click on the “Close Remote Connection” button in the bottom-left corner of the window.

*Please Note: VSCode stores some caches on the server, in a hidden directory named .vscode-server , and since the space for the home directory is limited you might face out-of-storage issues. To avoid that, you should move the .vscode-sever to your group_user space and have a symbolic link of that in your home directory.
Here are the steps you need to do that:

1. Navigate to your group_user directory. I.e. $cd gobbert_user/

2. Move vscode-server to this area (the current directory “.”): $ mv ~/.vscode-server .

3. Create symlink of .vscode-server in your home directory: `$ ln -s /home/username/gobbert_user/.vscode-server ~/.vscode-server`

4. Reconnect from your VSCode again. Now when VSCode looks for the remote server in your home directory, it would be redirected to the different directory seamlessly.

How to copy files to and from taki

Probably the most general way to transfer files between machines is by Secure Copy (scp). Because some remote filesystems may be mounted to taki, it may also be possible to transfer files using “local” file operations like cp, mv, etc.

The taki cluster only allows secure connection from the outside. Secure Copy is the file copying program that is part of Secure Shell (SSH). To transfer files to and from taki, you must use scp or compatible software (such as WinSCP or SSHFS). On Unix machines such as Linux or MacOS X, and also on Windows if using a Windows PowerShell, you can execute scp from the terminal window.

How to set up a graphical connection (X11) on taki

To access GUI applications on a remote machine, you need to make a graphical connection (x11 forwarding). A useful page for establishing these connections is Running X Windows Programs Remotely.

A brief tour of your account

This section assumes that you have logged in as described above. It assumes that you are a member of a research group, otherwise you might not have some of the storage areas.

Home directory

At any given time, the directory that you are currently in is referred to as your current working directory. Since you just logged in, your home directory is your current working directory. The “~” symbol is shorthand for your home directory. The program “pwd” tells you the full path of the current working directory, so let us run pwd to see where your home directory really is:

[gobbert@taki-usr1 ~]$ pwd
/home/gobbert

Now let us use ll to get more information about your home directory.

[gobbert@taki-usr1 ~]$ ll
total 3
lrwxrwxrwx 1 gobbert pi_gobbert 25 Sep 21 09:06 gobbert_common -> /umbc/xfs1/gobbert/common/
lrwxrwxrwx 1 gobbert pi_gobbert 32 Sep 21 09:06 gobbert_user -> /umbc/xfs1/gobbert/users/gobbert/

The permissions “lrwxrwxrwx” starting with “l” (short for “link”) indicate that these two are symbolic links pointing to two storage areas that you have access to; a student account may have fewer areas. The purpose is to make changing directory to these areas easier, namely you would just write “cd gobbert_common” to change directory to common area of your research group. The ‘common’ area is for all users in the research group to share files, while the ‘user’ area is for each user to store his/her own research files. The space in your home directory is limited though. In your home directory, you are only allowed a very limited storage space. You should therefore use the common and user areas to do work on taki.

Common workspace

The intention of common workspace is to store large volumes of data, such as large datasets from computations, which can be accessed by everyone in your group. By default, the permissions of common workspace are set as follows to enable all members of your research group to work together on all sub-directories and files:

[gobbert@taki-usr1 ~]$ ll -d /umbc/xfs1/gobbert/common
drwxrws--- 12 gobbert pi_gobbert 14 Oct  7 14:19 /umbc/xfs1/gobbert/common/

The string “drwxrws—” indicates that the PI, who is the owner of the group, has read, write, and search permissions in this directory. In addition, other members of the group also have read, write, and search permissions. The “s” indicates that all directories created under this directory should inherit the same group permissions. (If this attribute were set but execute permissions were not enabled for the group, this would be displayed as a capital letter “S”).

User workspace

Where common workspace is intended as an area for collaboration, user workspace is intended for individual work. Again, it is intended to store reasonably large volumes of data. Your PI and other group members can see your work in this area, but cannot edit it, as indicated by these permissions:

[gobbert@taki-usr1 ~]$ ll -d /umbc/xfs1/gobbert/users/gobbert
drwxr-s--- 7 gobbert pi_gobbert 12 Feb 25  2018 /umbc/xfs1/gobbert/users/gobbert/

The string “drwxr-s—“, means that only you may make changes inside this directory, but anyone in your group can list or read the contents. Other users on taki do not have any access to this area, as indicated by the dashes.

More about permissions

Standard Unix permissions are used on taki to control which users have access to your files. We’ve already seen some examples of this. It’s important to emphasize that this is the mechanism that determines the degree of sharing, and on the other hand privacy, of your work on this system. In setting up your account, we’ve taken a few steps to simplify things, assuming you use the storage areas for the basic purposes they were designed. This should be sufficient for many users, but you can also customize your use of the permissions system if you need additional privacy, to share with additional users, etc.

Changing a file’s permissions

For existing files and directories, you can modify permissions with the “chmod” command. As a very basic example:

[gobbert@taki-usr1 ~]$ ll tmpfile 
-rwxrwxr-x 1 gobbert pi_gobbert 0 Jun 14 17:50 tmpfile
[gobbert@taki-usr1 ~]$ chmod o-rwx tmpfile 
[gobbert@taki-usr1 ~]$ chmod ug-x tmpfile
[gobbert@taki-usr1 ~]$ ll tmpfile 
-rw-rw---- 1 gobbert pi_gobbert 0 Jun 14 17:50 tmpfile

See “man chmod” for more information, or the Wikipedia page for chmod

Changing a file’s group

For users in multiple groups, you may find the need to change a file’s ownership to a different group. This can be accomplished on a file-by-file basis by the “chgrp” command

[gobbert@taki-usr1 ~]$ touch tmpfile 
[gobbert@taki-usr1 ~]$ ll tmpfile 
-rw-rw---- 1 araim1 pi_nagaraj 0 Jun 14 18:00 tmpfile
[gobbert@taki-usr1 ~]$ chgrp pi_gobbert tmpfile 
[gobbert@taki-usr1 ~]$ ll tmpfile 
-rw-rw---- 1 araim1 pi_gobbert 0 Jun 14 18:00 tmpfile

[reetam1@taki-usr1 ~]$ mkdir tmpfolder
[reetam1@taki-usr1 ~]$ ll
drwxrwx--- 2 reetam1 pi_nagaraj  2 Sep  4 17:53 tmpfolder/
[reetam1@taki-usr1 ~]$ chgrp -R pi_gobbert tmpfolder
[reetam1@taki-usr1 ~]$ chmod -R g+rwX tmpfolder
[reetam1@taki-usr1 ~]$ chmod -R o-rwx tmpfolder
[reetam1@taki-usr1 ~]$ ll
drwxrwx--- 2 reetam1 pi_gobbert  2 Sep  4 17:53 tmpfolder/
[reetam1@taki-usr1 ~]$ find tmpfolder -type d -exec chmod g+rws {} \;
[reetam1@taki-usr1 ~]$ ll
drwxrws--- 2 reetam1 pi_gobbert  2 Sep  4 17:53 tmpfolder/

Checking disk usage vs. storage limits

For users to check the amount of storage that is remaining in their local storage and their primary group they can use the module hpc_toolkit and then use the hpc_checkStorage script.

[normalUser@taki-usr1 ~]$ module load hpc_toolkit
[normalUser@taki-usr1 ~]$ hpc_checkStorage 

The user normalUser has currently used  284M  of  300M  of storage 

The group normalGroup has currently used  65B  of the total group storage 100G  
[normalUser@taki-usr1 ~]$ 

Things to check on your new taki account

The Bash shell is the default shell for taki users – this will be the shell that you are assumed to be in for purposes of documentation and examples on this webpage. Check your shell with the command “echo $SHELL” or by using “env” and searching for SHELL in the resulting lines of output.

[gobbert@taki-usr1 ~]$ echo $SHELL
/bin/bash

Group membership

Your account has membership in one or more Unix groups. On taki, groups are usually (but not always) organized by research group and named after the PI; students in a class are in the ‘student’ group. The primary purpose of these groups is to facilitate sharing of files with other users, through the Unix permissions system. To see your Unix groups, use the groups command:

[gobbert@taki-usr1 ~]$ groups
pi_gobbert 

In the example above, the user is a member of the pi_gobbert group.

If any of the symbolic links to storage areas do not exist, you may create them using the following commands. You only need to do this once. We suggest that you repeat it for each PI if you are a member of multiple research groups.

[gobbert@taki-usr1 ~]$ ln -s /umbc/xfs1/gobbert/common ~/gobbert_common
[gobbert@taki-usr1 ~]$ ln -s /umbc/xfs1/gobbert/users/gobbert ~/gobbert_user

Umask

By default, your account will have a line in ~/.bashrc which sets your “umask”

umask 007

The umask helps to determine the permissions for new files and directories you create. Usually when you create a file, you don’t specify what its permissions will be. umask 007 ensures that outside users have no access to your new files. See the Wikipedia entry for umask for more explanation and examples. On taki, the storage areas’ permissions are already set up to enforce specific styles of collaboration. We’ve selected 007 as the default umask to not prevent sharing with your group, but to prevent sharing with outside users. If you generally want to prevent your group from modifying your files (for example), even in the shared storage areas, you may want to use a more restrictive umask.

Please run the following command to check your bashrc file:

[gobbert@taki-usr1 ~]$ more .bashrc
# .bashrc
# Set the permissions to limit the default read privs to only the user
umask 007

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# Loads the default module environment on taki
module load default-environment

# User specific aliases and functions

Modules

Modules are a simple way of preparing your environment to use many of the major applications on taki. Modules are normally loaded for the duration of an SSH session. They can be unloaded as well, and can also be set to automatically load each time you log in. The following shows the modules which are loaded for you by default; the version numbers will change as the software is upgraded over time.

[gobbert@taki-usr1 ~]$ module list

Currently Loaded Modules:
  1) shared
  2) DefaultModules
  3) GCCcore/7.3.0
  4) binutils/2.30-GCCcore-7.3.0
  5) icc/2018.3.222-GCC-7.3.0-2.30
  6) ifort/2018.3.222-GCC-7.3.0-2.30
  7) iccifort/2018.3.222-GCC-7.3.0-2.30
  8) impi/2018.3.222-iccifort-2018.3.222-GCC-7.3.0-2.30
  9) iimpi/2018b
 10) imkl/2018.3.222-iimpi-2018b
 11) dot
 12) intel/2018b
 13) slurm/17.11.8
 14) default-environment              

This means that, among others, SLURM, GCC, and the Intel compiler + Intel MPI implementation are usable by default as soon as you log in. If we wish to use other software, we must first load the appropriate module with “module load”.

To use compilers other than default you need to unload and load modules from time to time. If you lost track and want to get back to the default status, use the following commands:

[gobbert@taki-usr1 ~]$ module purge
[gobbert@taki-usr1 ~]$ module load default-environment

Complete documentation of module commands and options can be found by

man module

or

module help

We can list all available modules which have been defined by the system administrators with

module avail

If you want so search for sopeicific modules or find out more information about modules you can use the module spider command
To view all modules with their given description you can type

module spider

If you would like to search for a module by name or by partial name you can type as follows

module spider name

and you will recieve a list of all modules with names including that text

Handling Module Dependencies

When you load a module whose dependencies are different than what are currently loaded the module system will unload the old modules and load the needed ones. To demonstrate this effect, note first the currently loaded modules by module list before loading as example Python 3.6.3, then listing loaded modules again:

[barajasc@taki-usr1 ~]$ module list
Currently Loaded Modules:
  1) shared
  2) dot
  3) GCCcore/7.3.0
  4) binutils/2.30-GCCcore-7.3.0
  5) icc/2018.3.222-GCC-7.3.0-2.30
  6) ifort/2018.3.222-GCC-7.3.0-2.30
  7) iccifort/2018.3.222-GCC-7.3.0-2.30
  8) impi/2018.3.222-iccifort-2018.3.222-GCC-7.3.0-2.30
  9) iimpi/2018b
 10) imkl/2018.3.222-iimpi-2018b
 11) intel/2018b
 12) slurm/17.11.8
 13) Java/1.8.0_181
 14) MATLAB/2018b
 15) default-environment

[barajasc@taki-usr1 ~]$ module load Python/3.6.3-intel-2017b
The following have been reloaded with a version change:
1) GCCcore/7.3.0 => GCCcore/6.4.0
2) binutils/2.30-GCCcore-7.3.0 => binutils/2.28-GCCcore-6.4.0
3) icc/2018.3.222-GCC-7.3.0-2.30 => icc/2017.4.196-GCC-6.4.0-2.28
4) iccifort/2018.3.222-GCC-7.3.0-2.30 => iccifort/2017.4.196-GCC-6.4.0-2.28
5) ifort/2018.3.222-GCC-7.3.0-2.30 => ifort/2017.4.196-GCC-6.4.0-2.28
6) iimpi/2018b => iimpi/2017b
7) imkl/2018.3.222-iimpi-2018b => imkl/2017.3.196-iimpi-2017b
8) impi/2018.3.222-iccifort-2018.3.222-GCC-7.3.0-2.30 => impi/2017.3.196-iccifort-2017.4.196-GCC-6.4.0-2.28
9) intel/2018b => intel/2017b

[barajasc@taki-usr1 ~]$ module list
Currently Loaded Modules:
  1) shared
  2) dot
  3) slurm/17.11.8
  4) Java/1.8.0_181
  5) MATLAB/2018b
  6) default-environment
  7) GCCcore/6.4.0
  8) binutils/2.28-GCCcore-6.4.0
  9) iccifort/2017.4.196-GCC-6.4.0-2.28
 10) icc/2017.4.196-GCC-6.4.0-2.28
 11) ifort/2017.4.196-GCC-6.4.0-2.28
 12) impi/2017.3.196-iccifort-2017.4.196-GCC-6.4.0-2.28
 13) iimpi/2017b
 14) imkl/2017.3.196-iimpi-2017b
 15) intel/2017b
 16) bzip2/1.0.6-GCCcore-6.4.0
 17) zlib/1.2.11-GCCcore-6.4.0
 18) ncurses/6.0-GCCcore-6.4.0
 19) libreadline/7.0-GCCcore-6.4.0
 20) Tcl/8.6.7-GCCcore-6.4.0
 21) SQLite/3.20.1-GCCcore-6.4.0
 22) GMP/6.1.2-GCCcore-6.4.0
 23) XZ/5.2.3-GCCcore-6.4.0
 24) libffi/3.2.1-GCCcore-6.4.0
 25) Python/3.6.3-intel-2017b

As you can see, the default modules are unloaded and older versions of modules are loaded so that Python will function correctly. Specifically, the module system has loaded 10 new modules and reloaded 9 modules which were already loaded. Additionally all modules which are listed as dependencies are loaded.

Storage areas

The directory structure that DoIT will set up as part of your account creation is designed to facilitate the work of research groups consisting of several users and also reflects the fact that all HPCF accounts must be sponsored by a faculty member at UMBC. This sponsor will be referred to as PI (short for principal investigator) in the following. A user may be a member of one or several research groups on taki. Each research group has several storage areas on the system in the following specified locations. See the System Description for a higher level overview of the storage and the cluster architecture.

Note that some special users, such as students in a class, may not belong to a research group and therefore may not have all of the group storage areas set up.

“Mount point” indicates the actual location of the storage on the filesystem. Traditionally, many users prefer to have a link to the storage from their home directory for easier navigation. The field “symlink” gives a suggested location for this link. For example, once the link is created, you may use the command “cd ~/pi_name_user” to get to User Workspace for the given PI. These links may be created for users as part of the account creation process; however, if they do not yet exist, simple instructions are provided below to create them yourself.

Checking your available storage

The amount of space available in the PI-specific areas depend on the allocation given to your research group. Your AFS quota is determined by DoIT. The quota for everyone’s home directory is generally the same.

Any user can navigate to their own home directory by running `cd` at the command line and then issuing the command: `du -skh .` The final size shown is the total size of the directory. This command works for any directory you’re in. To check your group’s total storage, type `df -h` at any place while logged into the taki cluster environment and find the entry for the group in question.

Note that listing the contents of /umbc/xfs1 may not show storage areas for all PIs. This is because PI storage is only loaded when it is in use. If you attempt to access a PI’s subdirectory in /umbc/xfs1, it should be loaded (seamlessly) if it was previously offline.

In order to see what space is used by each USER, we will assume that all of the USER’s data is stored in their USER directory under the GROUP storage, i.e. at /umbc/xfs1/pi_name/users/username/ as described in the table above. Either the user or their PI can navigate to this directory and run the `du -skh .` command. This command may take a while to run depending on the complexity of the directory structure.