troubleshooting

Problems are listed by what you actually see. If you have an error message, search this page for a distinctive part of it.

Sessions

My session takes a long time to start

This is normal, and it is not the portal. Launching an interactive session creates a SLURM job like any other, which waits in the queue until a node has the cores and memory you asked for. Asking for fewer resources, or a shorter time, usually means starting sooner.

The kernel I need is not in the list

Two possible reasons.

Your session is older than the environment. A running session keeps the list of kernels it had at startup. End the session and launch a new one.

The environment does not exist. Only environments installed by the Department of Informatics appear. Ask for what you need — see environments.

My session disappeared and I lost work

Interactive sessions end when the time you requested on the launch form runs out. Save your work before then, and do not use an interactive session for long production runs — submit those as jobs and use the session only to prepare data and inspect results.

Jobs and SLURM

sbatch fails inside a notebook

Access/permission denied

Cause. Your session runs on a compute node, and SLURM only accepts submissions from the login nodes. This is a property of the cluster, not a misconfiguration.

Fix. Submit over SSH to a login node, from the notebook cell itself:

!ssh -o BatchMode=yes search7edu2 \
    'bash -lc "cd ~/my_job && sbatch my_script.slurm"'

For repeated use, a helper that handles the quoting and returns the job ID:

import subprocess, shlex

LOGIN_NODE = "search7edu2"

def submit(folder, script):
    inner = (f"cd {shlex.quote(folder)} && "
             f"sbatch --parsable {shlex.quote(script)}")
    cmd = (f"ssh -o BatchMode=yes {LOGIN_NODE} "
           f"{shlex.quote(f'bash -lc {shlex.quote(inner)}')}")
    r = subprocess.run(["bash", "-c", cmd],
                       capture_output=True, text=True)
    if r.returncode != 0:
        raise RuntimeError(r.stderr.strip())
    return r.stdout.strip().splitlines()[-1].split(";")[0]

This relies on passwordless SSH between nodes, which cluster accounts have by default. Any login node will do.

Query commands — squeue, sacct, scancel — work inside a notebook with no workaround.

My job was cancelled and the results are gone

Some job scripts run the calculation in temporary space on the node and only copy the results back at the end. If the job is cancelled or hits its time limit, that copy never happens. Either write intermediate results straight to your own area, or make the script react to cancellation and to the time limit before it is killed.

Environments and libraries

An environment will not start on a login node

RuntimeError: NumPy was built with baseline optimizations:
(X86_V2) but your machine doesn't support: (X86_V2)

Cause. The login nodes have processors of different generations. The older ones — search7 in particular — predate the x86-64-v2 instruction set that the NumPy builds require.

Fix. Use the portal, whose Jupyter sessions and shell both land on search7edu2, or request a compute node first:

srun --pty -n 1 --mem=2G -t 60 bash

A package I installed with pip is not found

Cause. This is deliberate. The shared Python kernels run with PYTHONNOUSERSITE=1, so anything in ~/.local from pip install --user is ignored. It is what guarantees that the same notebook gives the same results for everybody.

Fix. Ask for the library to be added to the shared environment. Installing it yourself will not help, because the kernel will not look there.

In R this does not apply: install.packages() into your personal library works normally — see environments.

Can I use the GPUs for deep learning?

In practice, no. The cluster’s GPUs are NVIDIA Tesla K20m cards from 2012, with compute capability 3.5; PyTorch has required 3.7 or higher since version 1.11, so it does not recognise them. Use the CPU machine-learning environment, which has 16 cores per node — see usage examples.

ORCA

A parallel calculation dies immediately

orca_startup_mpi: error while loading shared libraries:
libmpi.so.40: cannot open shared object file

Cause. ORCA 6.0.1 needs OpenMPI 4.x. The default rocks-openmpi is version 2.1.1 and does not provide libmpi.so.40.

Fix. In your job script:

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

If you set the path by hand. Login shells already define MPIHOME=/opt/openmpi, which is the old version. A script written as MPIHOME="${MPIHOME-/share/apps/openmpi/4.1.1/gnu/eth}" inherits the old value and the default you wrote is never used. Set the variable unconditionally, and remove /opt/openmpi from PATH and LD_LIBRARY_PATH.

A calculation fails part way through

Usually memory. %maxcore is per process, so nprocs × maxcore must fit in the node’s RAM — about 11.8 GB on the smaller nodes. Eight processes at %maxcore 1000 is a safe starting point.

Parallel is slower than serial

Expected for very small molecules: starting MPI costs more than the calculation itself. The speed-up is also sublinear in general — for formamide we measured 147 s on 1 process, 60 s on 4 and 46 s on 8. Larger systems scale better.

RStudio

“R version change detected when restoring session”

Not an error. RStudio noticed that the R version changed since your last session and discarded the saved state instead of restoring it, which is the right thing to do. To stop the message, clear the stored state from a terminal:

mv ~/.local/share/rstudio ~/.local/share/rstudio.old

The console shows output from an old session

RStudio saves the console buffer between sessions and restores it, so a brand-new session can open showing text from days ago. The version shown next to the R logo at the top of the Console panel is the one you are actually running. The command above clears the buffer too.

Still stuck?

Contact the Department of Informatics at search-admin@di.uminho.pt.

Please include, where they apply:

  • the job ID;
  • the output and error files (job1.o<id> and job1.e<id>, or whatever your script writes);
  • the complete error message, not a summary of it;
  • which environment you were using, and whether it was Jupyter or RStudio.

The complete message matters more than it looks: the useful part is often several lines above the line that says the job failed.

See also: web portal · environments · usage examples

Last updated: November 2026