Julia

Guidance last updated: 20 October 2026

The Julia programming language is a flexible dynamic language, appropriate for scientific and numerical computing, with performance comparable to traditional statically-typed languages.

Documentation: Julia manual.

Interactive Usage

After connecting to Stanage (see Establishing a SSH connection), start an interactive session:

salloc

Load a particular version of Julia with:

module load Julia/1.12.2
module load Julia/1.11.5

You can then start Julia REPL (interactive prompt) in an interactive session with:

$ julia

Exit the REPL with exit() or Ctrl+D. Inside the REPL, press ] to enter package mode, ? for help mode and ; for shell mode; press Backspace to return to the normal prompt.

To run a script instead:

$ julia myscript.jl

Installing packages

Packages are installed per user with Pkg. Create a project environment before adding packages, as shown below.

By default, packages are stored in ~/.julia (your home directory). This directory can grow to several GB and may fill your home directory quota. To store it elsewhere, set JULIA_DEPOT_PATH in your ~/.bashrc before starting Julia (best location might be your scratch space (fastdata) ):

export JULIA_DEPOT_PATH="/mnt/parscratch/users/$USER/.julia:"

The trailing colon preserves Julia’s system depots.

For reproducible work, use a project environment rather than the default global one. A project environment is a directory containing a Project.toml (the packages you asked for) and a Manifest.toml (the exact versions installed). Using one environment per project keeps package versions from conflicting between projects and makes your work reproducible.

Follow these rules to avoid conflicting or accidental environments:

  • One project per directory. Keep each project in its own directory with its scripts, Project.toml and Manifest.toml together. Do not put unrelated projects in the same directory, as they will share and overwrite one environment.

  • Never create a project in your home directory itself. Running julia --project=. from $HOME and adding a package creates ~/Project.toml, which will then silently apply to anything run from there.

  • Use explicit paths, not .. --project=. means “whatever directory I am in now”, so the environment changes depending on where Julia is started.

Create a new project:

$ mkdir -p $HOME/projects/myanalysis
$ cd $HOME/projects/myanalysis
$ julia --project=$HOME/projects/myanalysis

using Pkg
Pkg.add("DataFrames")     # recorded in ./Project.toml and ./Manifest.toml

To check which environment is active, run Pkg.status(); its first line shows the path of the Project.toml being used. You should get output like this:

Status `~/projects/myanalysis/Project.toml`
[a93c6f00] DataFrames v1.8.2

Making scripts independent of the working directory

A script can activate the environment stored alongside it, so it uses the right packages however and wherever it is started. Add this at the top of the script:

import Pkg
Pkg.activate(@__DIR__)   # the directory containing this script

Shared environments for general tools

For packages you want available across many small scripts (e.g. plotting tools), use a named environment instead of a directory. Named environments are stored in your Julia depot, not your working directory, so they cannot clash with a project folder:

$ julia --project=@tools

This creates or uses environments/tools within your user depot.

Note

Avoid adding packages to the default environment (shown as (@v1.12) pkg>). Packages there are visible to every project, which can cause version conflicts that are hard to track down.

Migrating projects to another HPC

If you want to use the same environment on another machine, copy the Project.toml and Manifest.toml files to the project directory on that machine. Start Julia with that project before restoring its packages:

$ julia --project=$HOME/projects/myanalysis

using Pkg
Pkg.instantiate()         # on another machine, installs exactly the same versions

Note

Installing and precompiling packages can be CPU-intensive and slow. Do this in an interactive session with multiple cores on a compute node, not on a login node. Packages are precompiled for the CPU they are built on, so code may recompile the first time it runs on a different node type (icelake vs znver3).

Batch usage

Note

Set up and precompile the environment before submitting jobs, in an interactive session on a compute node:

$ julia --project=$HOME/projects/myanalysis -e 'using Pkg; Pkg.instantiate(); Pkg.precompile()'

Do not run Pkg.add, Pkg.update or Pkg.instantiate inside batch jobs, especially job arrays or many jobs that share one environment. Jobs running these at the same time can conflict with each other and leave the environment broken. Batch jobs should only use an environment that is already set up.

Here, we assume that you wish to run the program example.jl on the system:

result = 0

# Prompt to enter
println("Enter 5 numbers line by line")

# Taking Input from user
for number in 1:5

num = readline()
num = parse(Int64, num)
global result+= num

end

println("The sum is :", result)

The program reads five numbers from standard input. Create input.txt with one number per line, for example:

1
2
3
4
5

The following example batch submission script, my_job.slurm, supplies this file as standard input:

#!/bin/bash
#SBATCH --ntasks=1
#SBATCH --time=10:00
#SBATCH --mem-per-cpu=1000

#load the julia module
module load Julia/1.12.2

julia --project=$HOME/projects/myanalysis example.jl < input.txt

This example assumes that example.jl, input.txt and my_job.slurm are in your current working directory. It prints The sum is :15 for the input above. Submit your job to the SLURM scheduler:

sbatch my_job.slurm

For work across multiple nodes, see the Distributed computing section of the Julia manual, or the MPI.jl package for MPI programs.

Installation notes

Julia was installed using Easybuild, build details can be found in $EBROOTJULIA/easybuild with a given module loaded.