Three complete examples, one per kind of work. Each one says which environment to pick, what to request on the launch form, and roughly how long it takes, so you can reproduce it rather than adapt it.

• Quantum chemistry with ORCA — from a molecule to an infrared spectrum
• Data analysis in R — model, plot and a reproducible report
• Machine learning on CPU — scikit-learn across 16 cores

Quantum chemistry with ORCA

Starting from a molecule written as SMILES, this builds a 3D structure, optimises the geometry, computes vibrational frequencies and plots the infrared spectrum — all from a notebook.

Using the ready-made template

A template notebook is available on the cluster at:

/share/apps/exemplos/biofisica/ORCA_SeARCH_template.ipynb

Copy it to your own area, open it in Jupyter, and edit a single cell. Everything else runs unchanged:

JOB    = "water_01"                 # a new name for each run
SMILES = "O"                        # the molecule; "O" is water
METODO = "B3LYP def2-SVP Opt Freq"  # Opt = optimise, Freq = IR
CARGA, MULTIPLICIDADE = 0, 1        # charge, multiplicity
NPROCS, MAXCORE = 8, 1000           # MPI processes, MB per process

Then Cell → Run All. The notebook builds the geometry, submits the job to SLURM, waits for it, and reports the energy, the bond lengths, the vibrational modes, the IR spectrum and an interactive 3D view of the final structure.

Other molecules to try: C methane, CCO ethanol, NC=O formamide, CC(=O)O acetic acid, c1ccccc1 benzene.

The variable names are in Portuguese because the template was written for a Biophysics class. CARGA is charge, MULTIPLICIDADE is spin multiplicity, METODO is the method line passed to ORCA.

Submitting ORCA directly

If you would rather write your own job script, the ORCA 6.0.1 module is:

#!/bin/bash
#SBATCH --job-name=orca_run
#SBATCH --partition=day
#SBATCH --nodes=1
#SBATCH --time=02:00:00

module load orca/6.0.1
module unload rocks-openmpi
module load gnu/openmpi_eth/4.1.1

$ORCA_DIR/orca molecule.inp > molecule.out

ORCA must be called by its full path, even with the module loaded. That is a requirement of the program itself, not of the cluster.

Parallel runs need OpenMPI 4.x. The default rocks-openmpi (version 2.1.1) is not compatible with ORCA 6 and the job dies at startup with libmpi.so.40: cannot open shared object file. Load gnu/openmpi_eth/4.1.1, as above. Note also that login shells set MPIHOME=/opt/openmpi, which is the old version — if your script uses ${MPIHOME-...} it will inherit that value instead of your default, so set the path explicitly.

To run in parallel, add to the input file:

%pal nprocs 8 end
%maxcore 1000

%maxcore is memory per process, in MB, so nprocs × maxcore must fit in the node’s RAM. The smaller SeARCH nodes have about 11.8 GB, which makes 8 processes at 1000 MB a safe starting point. Exceeding it makes the job fail part way through.

Check the output file for:

Program running with 8 parallel MPI-processes

How many processes are worth using. The speed-up is sublinear. For formamide (B3LYP/def2-SVP, optimisation and frequencies) we measured 147 s on 1 process, 60 s on 4 and 46 s on 8. For very small molecules such as water, running in parallel can be slower than serial, because starting MPI costs more than the calculation. Larger systems scale better.

Data analysis in R

Read a data file from your cluster area, fit a model, plot it:

library(tidyverse)

# Your own data, read straight from the cluster filesystem.
# No copying: the session runs on a node that already sees it.
dados <- read_csv("~/data/measurements.csv")

modelo <- lm(response ~ dose + batch, data = dados)
summary(modelo)

ggplot(dados, aes(dose, response, colour = batch)) +
  geom_point(alpha = 0.6) +
  geom_smooth(method = "lm", se = TRUE) +
  labs(x = "Dose", y = "Response") +
  theme_minimal()

For large files, data.table::fread() is considerably faster than read_csv() and is also installed.

A reproducible report

rmarkdown and pandoc are installed, so a document with text, code and figures can be rendered on the cluster:

rmarkdown::render("analysis.Rmd", output_format = "html_document")

In RStudio, the Knit button does the same thing. The result lands in your own area and can be downloaded through Files in the portal.

Using more than one core

library(parallel)
n <- detectCores()           # cores on this node

resultados <- mclapply(1:1000, funcao_pesada, mc.cores = n)

Parallelism only pays off when each task is substantial. For very cheap operations, the cost of starting the processes outweighs the gain.

Machine learning on CPU

CPU only. The cluster’s GPUs are too old for current versions of PyTorch — see environments. What this environment gives you is 16 cores and plenty of memory.

A complete example: load a dataset, search over hyperparameters across all cores, and report honest test-set accuracy.

from sklearn.datasets import load_digits
from sklearn.model_selection import train_test_split, GridSearchCV
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report

X, y = load_digits(return_X_y=True)
X_tr, X_te, y_tr, y_te = train_test_split(
    X, y, test_size=0.25, random_state=0, stratify=y)

grelha = {"n_estimators": [200, 500],
          "max_features": ["sqrt", "log2"],
          "min_samples_leaf": [1, 2, 4]}

busca = GridSearchCV(
    RandomForestClassifier(random_state=0),
    grelha, cv=5, n_jobs=-1)        # n_jobs=-1 uses every core

busca.fit(X_tr, y_tr)

print("best parameters:", busca.best_params_)
print(classification_report(y_te, busca.predict(X_te)))

The grid above fits 60 forests. On one core that is slow; with n_jobs=-1 on a 16-core node it finishes in well under a minute. This is the shape of problem where the cluster helps most — many independent fits, each small.

Use n_jobs rather than setting thread counts yourself: the kernel deliberately limits the numerical libraries to one thread each so that they do not compete with scikit-learn’s own parallelism.

Reading real data

import pandas as pd

df = pd.read_parquet("~/data/dataset.parquet")   # pyarrow installed
df = pd.read_csv("~/data/dataset.csv")

For anything above a few hundred megabytes, Parquet is worth the conversion: it reads faster and uses far less memory than CSV.

A limitation worth knowing

The sbatch command does not work inside a Jupyter session: the session runs on a compute node, and SLURM only accepts submissions from the login nodes. The ORCA template above handles this for you. If you need to submit from your own notebook, see troubleshooting for the workaround.

See also: web portal · environments · troubleshooting

Last updated: November 2026