Skip to content

Myria calculator user guide

If you are new to the HPC environment, we recommend that you read the detailed version at format PDF. Otherwise, please read at least the first two paragraphs of the summary documentation before contacting support.

Connection, environment and workspaces

The connection is done in SSH to the frontals grouped under the name

Command line syntax : ssh (by replacing mylogin with your login). Linux and Mac environments natively integrate the SSH protocol through the terminal. If you are under Windows environment, we recommend you to use the software MobaXTerm which will bring you a complete working environment based on the ssh protocol (screen export, file transfer).

The first time you log in, you are prompted to change your password. Read carefully what is asked: (current) Password is the current password and not the new one you want...

Customizations (environment variables, aliases) are done with a ~/.bash_profile (not ~/.bashrc) to create.

The user has a personal workspace in /home.

By default a user disk quota is set to 50 GB in /home; the command mmlsquota gpfs1:home provides the quota and the space the user occupies in the /home partition.

We encourage you to compute in the temporary scratch folders (/dlocal/run/<jobid>) created by the Slurm batch tool for each job. A quota of 10 million files is applied to the /dlocal tree; the mmlsquota gpfs1:dlocal command provides the quota and the number of files you own in the /dlocal/run folder.

If you feel that these limits (quotas) are too restrictive for you, do not hesitate to open a ticket with the support. These limits can be increased upon justified request.

For more information about this workspace and recommended commands for managing your files, see this page.

Data transfers

For the transfer of significant amounts of data between Myria and the outside world, the server should be preferred because it is connected to the SYVIK network via a 40 Gbit/s interface.

This machine gives access to the same /home directory as the front ends. The connection identifiers on are the same as on

Transfers between Myria and IDRIS resources are only allowed through


If your structure has a firewall limiting the outgoing flows of your site, here are the ports to open:

  • SSH connections (port 22) to the 4 front-ends behind the name
    • IPv4 : ( to (
    • IPv6 : 2001:660:7401:273::66 ( to 2001:660:7401:273::69 (
  • SSH connections (port 22) to the data transfer node
    • IPv4 : (
    • IPv6 : 2001:660:7401:273::70 (

Concerning the remote visualization sessions, to know the IP and the ports to open, please contact the support by mail at

Available software

Most of the submission script templates for the following software are available in the directory /soft/slurm/criann_modeles_scripts.

If not, contact (same as for requesting new software).

Application and library environments are accessed by modules (see the module avail, module help commands and the general documentation on modules).

Commercial software_ (license to be taken by the user)

  • CFD/Mechanics : ANSYS Fluent, StarCCM+, FINE/Marine, Hyperworks

Free software

  • Fluid mechanics :
    • FDS 5.5.0 (incendies)
    • Telemac v7p1r1, v8p1r1, v8p2r0 and v8p3r1
    • Code_Saturne 5.0.7 and 6.1.1
    • OpenFOAM 2.3.0, 2.4.0, 3.0.1, 3.0.x, 4.x-version-4.0, 4.x-version-4.1, 5.x-version-5.0, 5.x-20171030, 6-version-6, 6-20190304, 7-version-7, 8-version-8, 10-version-10, 1606+, 1612+, 1706, 1712, 1806, 1812, 1906, 1912, 2006, 2012, 2106, 2112, 2206 and 2212
    • Foam-extend 3.2 and 4.0
    • Delft3d4
  • Mechanics of structures :
    • Castem 2016, 2017, 2019 and 2021
    • Code_Aster 11.6.0 serial, 13.4.0 serial, 14.2.0_testing ("stabilized development version") serial and parallel (MPI), 14.6.0 serial
    • Salome-Meca 2017.0.2
    • LMGC90/user_2019_rc1
  • Chemistry :
    • GAMESS 2013 and 2016
    • Dalton 2018
    • Psi4
    • Cfour v1
    • Open Babel 3.0.0
  • Molecular dynamics :
    • GROMACS 5.1.4, 2019.2, 2020.4, 2021.1 and 2022.1 (Plumed patch or not)
    • NAMD 2.9 (patch Plumed), 2.12, 2.13 (Plumed patch or not) and 2.14
    • LAMMPS 7Aug19 and 7Jan2022
    • OpenMolcas 19.11
    • Quantum Espresso 6.5
  • Climate : WRF 3.7.1, 3.9, 3.9.1 and 4.3
  • Ocean : Croco v1.1
  • Geodynamics :
    • SPECFEM2D 2018
    • SPECFEM3D 2021
  • Mathematics :
    • Octave 3.8.2 and 4.2.1
    • R 3.3.2, 3.5.1, 3.5.2, 4.0.2, 4.0.3, 4.0.5, 4.1.1 and 4.1.2
    • Scilab 5.5.2 and 6.0.1
  • IA – Deep Learning : one page is dedicated to the installed software library

Software under academic license

  • Quantum chemistry :
    • GAUSSIAN 03
    • Shrödinger JAGUAR 8.0 and 9.4
  • Molecular dynamics : Shrödinger Desmond 2016.3

Software for visualization or pre/post-processing

  • Gmsh 2.16.0 and 4.5.1
  • Neper 3.0.1
  • Triangle 1.6
  • ParaView 4.0.1, 5.2.0, 5.4.1, 5.6.0, 5.7.0 and 5.9.0
  • Salome 7.8.0 and 8.5.0
  • Visit 2.12.1 and 2.12.3
  • Blender 2.76b and 2.79b
  • ffmpeg 4.1
  • Helix-OS
  • XCrysDen 1.6.2
  • VMD 1.9.3


Intel's MPI compiler and library environments, version 2017, are enabled by default (type module list).

MPI codes are compiled using the commands mpiifort (FORTRAN), mpiicc (C, 2 "i" in the name of this command), mpiicpc (C++).

The optimization option for the general-purpose (Broadwell) processor architecture is -xCORE-AVX2 (for compiling on a frontend, or batch in a non-knl partition, the -xHost option is equivalent).

The optimization option for the manycore Xeon Phi KNL processor architecture is -xMIC-AVX512.

The generation of an optimized executable for both Broadwell and KNL architectures is possible, with the -axCORE-AVX2,MIC-AVX512 option.

Examples of optimization option sets for Broadwell, in order of increasing aggressiveness

  • -O2 -xCORE-AVX2
  • -O3 -xCORE-AVX2 -fp-model precise
  • -O3 -xCORE-AVX2

Example of an optimization option set for KNL

  • -O3 -xMIC-AVX512

Example of debugging options

  • -O2 -g -traceback -check all

Sample Makefiles are provided in /soft/makefiles.

The modules environment facilitates the compilation of applications linked to the available libraries.

Submission environment (Slurm)

The directory /soft/slurm/criann_modeles_scripts contains the generic submission scripts (sequential code, OpenMP, MPI, hybrid, KNL, GPU) or application specific.


It is advisable to use Slurm's #SBATCH --mem directive, specifying the memory demand per compute node (rather than memory per reserved core, --mem-per-cpu).

If a parallel computation needs more than 4300MB of memory per MPI task, the standard Myria compute nodes must be depopulated by adding the directive #SBATCH --ntasks-per-node in the submission script.

For example, the following settings require a total of 140 MPI jobs with, per standard compute node (server), 14 MPI jobs and 120000 MB of memory (since these servers have 28 cores each, half of the compute units will be used but all RAM will be available):

# Partition (submission class)
#SBATCH --partition 2tcourt

# MPI tasks number
#SBATCH --ntasks 140

# MPI tasks per compute node
#SBATCH --ntasks-per-node 14

# Maximum memory per compute node (MB)
#SBATCH --mem 120000


This table provides useful commands for submitting jobs.

Action Commande
Calculator load slurmtop -f -
Characteristics of the partitions (classes) sinfo
Submit a job sbatch
Submit a job in "hold" sbatch -H
Release a job in "hold" (waiting) scontrol release job_id
List all jobs squeue
List your own jobs squeue -u login
Displaying the characteristics of a job scontrol show job job_id
Predicting when a job will be queued squeue --start --job job_id
Syntax checking and scheduling of a job without submitting it sbatch --test-only
Forecasting the schedule of its own work squeue -u login --start
Killing a job scancel job_id

Environment variables

The following utility variables (non-exhaustive list) can be used in the user commands (Shell) of a submission script.

Variable name Value
$SLURM_JOB_ID Job identification (example: 64549)
$SLURM_JOB_NAME Job name (specified by #SBATCH -J)
$SLURM_SUBMIT_DIR Name of the initial directory (in which the sbatch command was launched)
$SLURM_NTASKS Number of job MPI processes
$LOCAL_WORK_DIR Name of the temporary scratch directory based on the job number: /dlocal/run/$SLURM_JOB_ID.
This folder is deleted 45 days after the end of the job.

Partitions (submission classes)

The partitions use the 368 Broadwell dual-socket nodes (10,304 cores), the 10 Xeon Phi KNL nodes (640 cores) and the SMP node (256 cores).

The number of compute nodes accessed by jobs in different partitions is given below as a guide. Administrators sometimes adjust the size of these "firing windows" slightly depending on the observed load. On the other hand, the per-computation limits generally remain constant. In any case, these limits are not modified without an announcement to the users' mailing list.

Note: The reproducibility of an application's performance on the cluster can be enhanced by applying the #SBATCH --exclusive directive in the submission script, which enforces the execution of the submitted job on a set of unshared nodes. This directive is advisable for multi-node MPI production jobs, recommended for performance testing.

For production or scientific development jobs, in the particular case of sequential applications, it is preferable not to apply this directive (so as not to monopolize a compute node).

The partition is specified by the submission script with the #SBATCH --partition directive (or in the command line: sbatch --partition 2tcourt

Debugging jobs

This partition contains all servers equipped with the Xeon Broadwell processor.

Partition Maximum duration Available nodes Limits by job Hints
debug 0 h 30 363 nodes 5 nodes (140 cores and 585 GB / 28 cores and 1 TB of memory) One of the 363 servers associated with this partition is equipped with 1 TB of memory

Work on standard architecture (Broadwell)

The partitions are defined according to the resource quantities requested.

Partition Maximum duration Available nodes Limits by job Hints
2tcourt 12 h 332 nodes 75 nodes during the week (2100 cores and 9600 GB of memory)
150 nodes during the weekend (*) (4200 cores and 19200 GB of memory)
#SBATCH --mem 120000MB for MPI or OpenMP entire node(s)
tcourt 24 h 322 nodes 75 nodes (2100 cores and 9600 GB of memory) #SBATCH --mem 120000MB for MPI or OpenMP entire node(s)
court 48 h 100 nodes 20 nodes (560 cores and 2560 GB of memory) #SBATCH --mem 120000MB for MPI or OpenMP entire node(s)
long 100 h 50 nodes 10 nodes (280 cores ans 1280 GB of memory) #SBATCH --mem 120000MB for MPI or OpenMP entire node(s)
tlong 300 h 15 nodes 2 nodes (56 cores ans 256 GB of memory) #SBATCH --mem 120000MB for MPI or OpenMP entire node(s)
tcourt_intra 24 h 134 nodes 1 nœud (28 cores ans 128 GB of memory) #SBATCH --mem 120000MB for MPI or OpenMP entire node

(*) Weekend schedule starts on Friday evening at 5 pm and ends on Sunday evening at 8 pm. During this period, the total number of cores used by a user can reach 4200 cores, thus allowing a job in the 2tcourt partition up to 4200 cores.

Jobs on specific architectures

Partitions match the type of the targeted architecture.

Partition Maximum duration Available nodes Limites par calcul Conseils
disque 300 h 13 nodes (Broadwell) (including 12 to 128 GB and 1 to 1 TB of memory) 28 cores and 1TB of memory
(#SBATCH --mem 1016GB)
Scratch local disk (not shared in network) : $LOCAL_SCRATCH_DIR
smplarge 3 h Full SMP server (Haswell) 256 cores and 3.99 TB of memory #SBATCH --mem 4090GB (available)
smplong 72 h Half SMP server (Haswell) 128 cores and 2TB of memory #SBATCH --exclusive forbidden
#SBATCH --mem 2045GB (available)
knl 100 h 10 nodes (KNL) 4 nodes (256 cores and 384GB of memory) #SBATCH --mem 89000MB for MPI or OpenMP entire node(s)
gpu_k80 48 h 9 nodes (Broadwell) (with Kepler K80 GPUs) 8 nodes (224 cores and 1024GB of memory)
gpu_p100 48 h 9 nodes (Broadwell) (with Pascal P100 GPUs) 8 nodes (224 cores and 1024 GB of memory)
gpu_v100 48 h 5 knots (SkyLake) (with Volta V100 GPUs) 5 nodes (160 cores and 900 GB of memory)
gpu_all 48 h 18 nodes (Broadwell) (with K80 or P100 GPUs) 1 node (28 cores and 128 GB of memory)
gpu_court 4 h 4 nodes (Broadwell) (with K80 GPUs) 1 node (28 cores and 128 GB of memory)
visu 6 h 2 nodes (Broadwell) with 256 GB RAM 8 cores and 128 GB of memory
visu2 6 h 2 nodes (Broadwell) with 128 GB RAM 8 cores and 128 GB of memory

The disk partition should be specified for write-intensive chemistry applications. See the submission file templates in /soft/slurm/criann_modeles_scripts :



A description of how to submit GPU jobs is available.

One paragraph is for users who need to compile or run multi-GPU applications (for the CUDA aware MPI case) on the V100-SXM2 architecture from Myria.


Servers with a Xeon Phi KNL processor have several configurations (clustering and fast on-board memory modes).

The KNL documentation page describes these configurations and the Slurm guidelines for specifying them for jobs.

Remote visualization

A specific documentation for visualization jobs is available.

Management of signals sent by Slurm

A specific documentation for catching and processing signals sent by Slurm is available.


The detailed documentation in PDF format (paragraphs "Bonnes pratiques de soumission" and "Exécution des travaux : aspects avancés") provides useful information:

  • Ratio of resource consumption (e.g. memory) per job
  • Multi-step jobs (e.g. pre-processing, solver and post-processing) and dependencies between jobs.
  • Consideration of network topology for MPI communication performance
  • Optimal placement of parallel processes in a job for performance (when using depopulated compute nodes)

Tracking hourly consumption

From the frontend nodes, the maconso command displays your consumption as well as that of the project. If you are a project manager or deputy manager maconso -u shows the details for all accounts.

This information is also available in JSON format in the file ~/.acct_myria.json.

The consumption is updated every night.

Last update: April 6, 2023 15:05:45