The primary purpose of this wiki is to enable comfortable editing of the skill definitions from the git repository and for the available certificates. One skill or certificate is exactly one page.

To navigate the skills effectively, use the Freeplane-based mindmap. Freeplane version 1.11 or higher is required.

We welcome improvements to the skill definitions and suggestions for skill tree changes. The skill tree has several representations, the Freeplane mindmap version forms the base with its navigational features and ability to link directly to the markdown files. The markdown version is available in this wiki. Users may use it to modify the descriptions once registered. All skill tree changes and modifications should be executed by creating a GitHub pull request to either Markdown or XML representation. Note that the chairs for the subtree may comment on or discuss the proposal. The Skill Tree and the related Markdown file must have the same name and coordinates.

A skill is located in a unique place in the skill tree, which is the URI (Uniform Resource Identifier). There may be multiple references to a skill in the tree which are hyperlinked within the structure of the skill tree or linked and mentioned in the markdown file in the wiki. On the skill tree, there are two types of entries: a: Skill and b: Overview. Both are defined, and the compulsory sections are below.

The following is the format:

Example: Modules and Spack (USE2.5.2)

The name refers to a simplified name for the skill. Names must be short and to the point. Avoid names that are vague and unrelated. Also, do not use entire sentences as names. Do not use syntaxes as names, either, even if they are shorter than a descriptive name. The same name must be used in the skill tree and in the markdown file.

Coordinates are a unique identifier from the root of the skill tree. The coordinates indicate the position of the skill on the skill tree and are unique for every skill. Skills with the same name on different parts of the tree may exist, and each will have its own unique Coordinate. The exact coordinates must be used in the skill tree and the subsequent markdown file.

Breakdown of an ID example: USE2.5.2 USE2.5.2 → [USE] = Main branch, [2.5.2] = Branch co-ordinates. See image:

The description for a leaf node can be short or long depending on the section, but it does not need to be comprehensive.

This section must have a list of requirements needed to learn the contents of a leaf. Requirements are split further into external and internal requirements. Any requirements present on the skill tree are internal. Any skill that needs to be learnt externally before learning the particular skill is an external requirement. A leaf node need not have either of these sections filled if there are no requirements to learn the skill. Local requirements must be hyperlinked within the Skill Tree and the Wiki.

Learning objectives are essentially a list of everything the user needs to learn to acquire a certification for the particular leaf node. It is a comprehensive list of everything they need to know. The learning objectives also form the base of the testing phase of HPC CF, where candidates will be tested online for their knowledge of the topics covered under the learning objectives.

This section appears when an online test for a particular leaf is available. It links the user directly to an online test.

Sections which are blank need not be represented in the Markdown. However, some sections like Header, Description and Learning Objectives are compulsory in the leaf nodes markdown file.

Example: Modules and Spack (USE2.5.2)

The name for an Overview skill will always be the word 'Overview' followed by the branch head name. See Image.

Coordinates are a unique identifier from the root of the skill tree. The coordinates indicate the position of the skill on the skill tree and are unique for every skill. Skills with the same name on different parts of the tree may exist, and each will have its own unique Coordinate. The exact coordinates must be used in the skill tree and the subsequent markdown file. An overview always ends with a one as part of their ID!

Breakdown of an ID example: USE2.5.1 USE2.5.1 → [USE] = Main branch, [2.5.1] = Branch overview co-ordinates. See image:

This is the most crucial section of the Overview leaf. Unlike skill leaf nodes, where descriptions do not need to be comprehensive. Descriptions on the Overview nodes must cover every leaf present on its branch. Overview is meant to be an introductory topic, a way to cover a skill topic without going in depth. While the description explains all the leaves on the branch, it need not be an in-depth description. Instead, it should only cover the critical information that the user must know. The overview node, however, must have more of a structure to its description. The structure must represent the other skill leaves on the branch, complete with links and coordinates.

This section must have a list of requirements needed to understand the skill leaves on the branch. Requirements are split further into external and internal requirements. Any requirements present on the skill tree are internal. Any skill that needs to be learnt externally before learning the particular skill is an external requirement. An overview node need not have either of these sections filled if there are no requirements to learn the skill. Local requirements must be linked within the Skill Tree and the Wiki. All requirements listed in the overview are applied recursively to the skill topics and skills under it.

This section contains links to the skill topics and skills listed under this overview branch. In case of a skill topic, the relevant overview branch is linked.

There are no learning objectives or tests for an overview branch. The overview branch lets trainers pick and choose relevant topics within a branch to teach at any required level, so it does not need to complete the learning objectives strictly specified in the leaf sections.

In Overview, only the Header and Description as well as the list of skill topics and skills are required.

Most cluster operating systems do not have a GUI and are therefore accessed via a Command Line Interface (CLI).

Using a CLI requires knowledge of the underlying system as well as the programs it can execute. It is essential to learn about the functionality of the bash or shell program. Important to know is how to start, stop, interrupt and kill programs and what programs are available. Especially programs, like file editors and the manual program are of great importance. Additionally, it is vital to understand the file structure of the base operating system. Some paths lead to programs, while others contain configuration files, documentation, libraries and user-definable code. Finally, knowing about regular expressions and wildcards is fundamental, it helps run programs without fully specifying a path. Wildcards, in particular, are helpful if a selection of files is needed to be read or autocompleted by the CLI. Regular expressions are also used to match a content list but are more general because they are used in text body searches.

• 2: Bash (USE2.2.2)
• 3: Unix file system (USE2.2.3)
• 4: Regular Expressions and Wildcards (USE2.2.4)

HPC systems are usually accessed via a Linux-based Command Line Interface (CLI or CMD) provided by a shell (Bash in this case).

At its core, a shell is a convenient tool that can be used to execute commands on a Linux computer. The shell provides a textual interface allowing it to interact with the operating system and perform all possible operations, i.e., accessing and manipulating files and running programs. However, there are various misconceptions that new users typically face when handling a shell such as the Bash. Particularly, dealing with control characters and the format expected when executing programs with arguments can be error-prone. Part of this skill is the general principles of the interaction with a shell to execute and stop programs.

• Utilise the bash shell to execute individual programs with arguments
• Identify potential special characters that must be handled with care
• Utilise escaping to ensure the correct handling of arguments
• Utilise the available help of a program (–help argument and the man pages)
• Analysing the meaning of the exit code or SIGNALS of a program
• Interrupt or abort a program execution by sending SIGNALS:
• Keyboard command: CTRL-C
• Keyboard command: CTRL-Z
• Using the kill -9 command
• Run multiple programs after another depending on the exit code ;, &&, ||
• Use the set of basic programs and their tasks:
  • pwd
  • whoami
  • sleep
  • kill
  • echo
  • clear
  • date
  • man
  • vi, vim, emacs, nano
  • exit
• Use the shell history to search and execute previously executed commands
• Learn about environment and variables
• Print all currently set variables
• Set and print variables
• Learn how to close popular command line text editors with/or without saving changes:
  • nano
  • vi
  • emacs

Get Tested