Rapport de stages

Les indications ci-dessous sont tirés intégralement des conseils pour faire un bon mémoire de stage de Pierre David qui est enseignant de le Master CSMI et qui dirige le Master en Informatique SIRIS.

1. Introduction

Le mémoire est un élément essentiel de votre stage : il a pour but de de présenter, aussi fidèlement que possible, à la fois la portée du stage (organisationnelle et/ou (organisationnel et/ou technique) et votre contribution.

Votre mémoire sera lu par un rapporteur, c’est-à-dire un enseignant de l’équipe pédagogique (donc une personne ayant des compétences dans votre discipline), dont la mission est d’évaluer votre thèse pour comprendre : - le contexte dans lequel vous avez évolué, - votre apport (réalisation technique, travail scientifique) sa pertinence par rapport aux cours du Master.

Il vous est rappelé que le plagiat est puni par la loi, par l’université par l’université et par vos examinateurs : si de courtes citations sont autorisées, vous devez en indiquer la source.

2. Plan

La section Vérification est obligatoire. Les sections Validation et Quantification d’incertitude sont recommandées si pertinentes pour votre projet — avec justification brève si omises.

2.1. Missions & Objectifs

Décrivez les missions confiées, les objectifs mesurables, les livrables attendus et les contraintes (techniques, calendrier, données, sécurité). Indiquez votre rôle précis et les parties du travail dont vous êtes responsable.

2.2. Contexte

Présentez brièvement l’organisme et le contexte métier/technique utile à la compréhension du projet (sans recopier le site web). Précisez l’existant (outils, modèles, jeux de données, pipeline) et les choix imposés.

2.3. Contributions

Résumez vos contributions (méthodologie, modélisation, implémentation, expérimentation). Mentionnez les technologies, frameworks et ressources (HPC, conteneurs, CI/CD) effectivement utilisés.

2.4. Jeux de données (datasets)

Cette section est requise pour tout projet manipulant des données.

  • Origine & droits : source(s), licences, RGPD/éthique si applicable.

  • Description : taille, formats, variables cibles/caractéristiques, statistiques de base.

  • Découpage : train/val/test (ou CV), éviter les fuites de données; logique temporelle/spatiale si nécessaire.

  • Prétraitements : nettoyage, filtrage, normalisation, enrichissement, gestion des valeurs manquantes.

  • Pertinence/limitations : adéquation avec les objectifs, biais connus, représentativité.

2.5. Vérification — « Ai-je bien résolu le problème ? » (OBLIGATOIRE)

La vérification démontre la justesse technique (maths/numérique/logiciel) : implémentation correcte, expériences reproductibles, métriques calculées correctement.

  • Stratégie : tests unitaires/intégration, oracles simples, cas jouets, conservation d’invariants.

  • Numérique : études de convergence, sensibilité aux pas/maillages, stabilité, tolérances.

  • Reproductibilité : graine aléatoire, environnement (versions, conteneur), scripts d’expérience.

  • Mesures : métriques adaptées (p.ex. RMSE, MAE, F1, AUC, énergie, temps, mémoire).

  • Comparatifs : baseline(s) simples, ablations, profils HPC (si pertinent : temps noyau, scaling, IO).

  • Traçabilité : tableau récapitulatif des expériences (id, données, paramètres, métriques).

2.5.1. Tests de convergence numérique

Les tests de convergence sont essentiels pour valider l’implémentation d’algorithmes numériques. Ils démontrent que la méthode implémentée converge théoriquement.

A. Convergence de maillage (méthodes à base d’éléments finis, différences finies)

Utiliser une solution manufacturée (Method of Manufactured Solutions - MMS) : partir d’une solution analytique connue \(u_{exact}(x,y)\), calculer le terme source correspondant, puis vérifier que l’erreur numérique décroît selon l’ordre théorique.

Table 1. Tableau — Test de convergence (solution manufacturée)
h (taille maille) DOF \(‖u_h - u_{exact}‖_{L²}\) Ordre L² \(‖u_h - u_{exact}‖_{H¹}\) Ordre H¹

0.1

1024

2.34e-3

1.87e-2

0.05

4096

5.92e-4

1.98

9.45e-3

0.98

0.025

16384

1.49e-4

1.99

4.73e-3

1.00

0.0125

65536

3.74e-5

1.99

2.37e-3

1.00

Ordre = \(log(e_i/e_{i+1}) / log(h_i/h_{i+1})\). Éléments P1 ⇒ ordre théorique \(L²=2, H¹=1\).

B. Convergence d’algorithmes itératifs

Pour les solveurs, optimiseurs, méthodes de point fixe : montrer la décroissance du résidu/erreur.

Table 2. Tableau — Convergence résidu (Newton-Raphson, GMRES, etc.)
Itération Résidu \(‖r‖\) Erreur \(‖e‖\) Taux

0

1.0e+0

5

3.2e-2

8.1e-3

10

1.0e-4

2.6e-5

0.031

15

3.2e-7

8.2e-8

0.032

20

1.0e-9

2.6e-10

0.031

Taux = \(‖r_{k+1}‖/‖r_k‖\) (convergence linéaire si constant < 1).

C. Convergence de loss (apprentissage automatique)

Montrer la décroissance des fonctions de coût (entraînement + validation) et la stabilisation des métriques.

Table 3. Tableau — Évolution loss et métriques
Époque Loss train Loss val Acc train Acc val

1

2.31

2.28

0.12

0.15

10

1.85

1.92

0.34

0.31

50

0.97

1.18

0.67

0.59

100

0.52

0.94

0.83

0.71

200

0.31

0.87

0.91

0.74

# Exemple : vérification convergence loss
import matplotlib.pyplot as plt
import numpy as np

# Charger logs d'entraînement
epochs = [1, 10, 50, 100, 200]
train_loss = [2.31, 1.85, 0.97, 0.52, 0.31]
val_loss = [2.28, 1.92, 1.18, 0.94, 0.87]

plt.figure(figsize=(10, 4))
plt.subplot(1, 2, 1)
plt.semilogy(epochs, train_loss, 'b-o', label='Train')
plt.semilogy(epochs, val_loss, 'r-s', label='Val')
plt.xlabel('Époque'); plt.ylabel('Loss'); plt.legend()
plt.title('Convergence de la fonction de coût')

# Vérifier absence d'overfitting
plt.subplot(1, 2, 2)
gap = np.array(train_loss) - np.array(val_loss)
plt.plot(epochs, gap, 'g-^')
plt.xlabel('Époque'); plt.ylabel('Gap train-val')
plt.title('Écart train/validation')
plt.tight_layout()

D. Ordres de convergence théoriques (référence)

Table 4. Ordres attendus selon la méthode
Méthode Ordre spatial Ordre temporel Notes

Diff. finies centrées

p (schéma ordre p)

Stable si CFL < C

Éléments finis Pk

\(k+1\) (L²), \(k\) (H¹)

k = degré polynomial

Runge-Kutta ordre s

s

RK4 ⇒ ordre 4

Euler explicite

1

Ordre minimal

Newton-Raphson

2 (quadratique)

Si \(x₀\) assez proche

Gradient à pas fixe

Linéaire

Taux = \(1 - μ/L\)

E. Script type pour test de convergence

#!/usr/bin/env python3
# test_convergence.py
import numpy as np
import matplotlib.pyplot as plt

def manufactured_solution(x, y):
    """Solution exacte u = sin(πx)*sin(πy)"""
    return np.sin(np.pi * x) * np.sin(np.pi * y)

def source_term(x, y):
    """Terme source f = -Δu = 2π²sin(πx)sin(πy)"""
    return 2 * np.pi**2 * np.sin(np.pi * x) * np.sin(np.pi * y)

def solve_poisson(h):
    """Résout -Δu = f avec maillage de pas h"""
    # Implémentation du solveur (DF, EF, etc.)
    # Retourne u_h, erreur_L2, erreur_H1
    pass

# Test de convergence
h_values = [0.1, 0.05, 0.025, 0.0125]
errors_L2 = []
errors_H1 = []

for h in h_values:
    u_h, err_L2, err_H1 = solve_poisson(h)
    errors_L2.append(err_L2)
    errors_H1.append(err_H1)
    print(f"h={h:6.3f}, L2={err_L2:.2e}, H1={err_H1:.2e}")

# Calcul des ordres
orders_L2 = []
orders_H1 = []
for i in range(1, len(h_values)):
    order_L2 = np.log(errors_L2[i-1]/errors_L2[i]) / np.log(h_values[i-1]/h_values[i])
    order_H1 = np.log(errors_H1[i-1]/errors_H1[i]) / np.log(h_values[i-1]/h_values[i])
    orders_L2.append(order_L2)
    orders_H1.append(order_H1)
    print(f"Ordre L2: {order_L2:.2f}, Ordre H1: {order_H1:.2f}")

# Graphique
plt.loglog(h_values, errors_L2, 'bo-', label='L² error')
plt.loglog(h_values, errors_H1, 'rs-', label='H¹ error')
plt.loglog(h_values, [h**2 for h in h_values], 'k--', label='h²')
plt.loglog(h_values, h_values, 'k:', label='h')
plt.xlabel('h'); plt.ylabel('Erreur'); plt.legend()
plt.title('Test de convergence'); plt.grid(True)

Formules utiles :

\[S(N) = T(1) / T(N), \quad E(N) = S(N)/N\]
  • \(S(N)\): speedup

  • \(E(N)\): efficacité parallèle

  • \(T(N)\): temps total avec N ressources (nœuds/GPUs)

2.5.2. Exemples de tableaux de performance (valeurs fictives)

A. Forte scalabilité (strong scaling) — taille de problème fixe

Le travail est identique, on augmente les ressources.

Table 5. Tableau A1 — Strong scaling (problème fixe)
Exp ID Ressources (nœuds × CPU/GPU) \(T_{total}\) (s) Speedup S Eff. E Débit (it/s) Mémoire (GB)

SS-01

1×(32/0)

1200

1.00

1.00

85

56

SS-02

2×(32/0)

640

1.88

0.94

160

60

SS-03

4×(32/0)

340

3.53

0.88

300

68

SS-04

8×(32/0)

190

6.32

0.79

520

76

\(S = T(1)/T(N), E = S/N\). Indiquez aussi la version du code, le hash Git et l’image du conteneur.

B. Faible scalabilité (weak scaling) — charge par ressource constante

On double ressources et taille du problème pour conserver la charge par unité.

Table 6. Tableau B1 — Weak scaling (charge/device constante)
Exp ID Ressources \(T_{total}\) (s) Eff. faible \(E_w\) Débit (unités/s) Note

WS-01

1×(32/0)

300

1.00

3.2

Baseline

WS-02

2×(32/0)

310

0.97

6.3

I/O commence à dominer

WS-03

4×(32/0)

325

0.92

12.3

Synchro MPI plus coûteuse

WS-04

8×(32/0)

360

0.83

24.8

Bande passante réseau limite

\(E_w\) peut s’estimer via \(T(1)/T(N)\) (problème proportionnel).

C. Scalabilité par taille de données

Impact du volume de données sur temps, débit et métriques du modèle.

Table 7. Tableau C1 — Data scaling (taille dataset ↑)
Taille données \(T_{total}\) (min) Débit (échant./s) Acc./RMSE Mémoire (GB) Commentaire

10k

12

830

Acc=0.89

12

Sous-apprentissage

100k

95

1050

Acc=0.92

22

Bon compromis

1M

980

1010

Acc=0.925

76

I/O + mémoire limitent

10M

>256

Non tenable sans sharding

D. Sensibilité aux paramètres d’exécution (ex. batch size)

Montrer le compromis débit ↔ qualité ↔ mémoire.

Table 8. Tableau D1 — Sensibilité (batch size, précision)
Batch Précision (float16/32) \(T_{total}\) (min) Débit (it/s) Acc./F1 Mémoire (GB)

32

fp32

120

12.5

F1=0.88

24

64

fp32

95

17.6

F1=0.88

38

128

fp16

70

31.0

F1=0.87

26

256

fp16

62

35.2

F1=0.86

28

2.5.3. Modèles de tableaux vierges (à remplir)

Table 9. Modèle — Carte d’expérience (à répéter)
Champ Valeur

ID exp.

EXP-YYYYMMDD-XX

Objectif

(baseline / strong / weak / data scaling / sensibilité)

Version code

<hash git court>

Conteneur

<registry/image:tag + digest>

Données

<source + checksum + split>

Ressources

<nœuds × CPU/GPU, RAM, stockage>

Script

<chemin/job Slurm + options clés>

Paramètres

<batch, lr, tolérance, partitions, etc.>

Métriques

<\(T_{total}\), débit, S, E, pic RAM, précision>

Notes

<observations, goulets d’étranglement>

Table 10. Modèle — Tableau Strong scaling (problème fixe)
Exp ID Ressources \(T_{total}\) (s) Speedup S Eff. E Débit Mémoire (GB)
Table 11. Modèle — Tableau Weak scaling (charge constante)
Exp ID Ressources \(T_{total}\) (s) Eff. faible \(E_w\) Débit Note
Table 12. Modèle — Tableau Data scaling
Taille données \(T_{total}\) Débit Qualité Mémoire Commentaire
Checklist d’instrumentation — Reproductibilité
  • Seed(s) fixés, requirements.txt/environment.yml, hash Git, digest d’image (ex. sha256:), checksum des données.

  • Scripts d’exécution versionnés (ex. slurm/train.sbatch), configuration logguée (YAML/MLflow/DVC).

Mesure
  • Temps : /usr/bin/time -v, sacct -j <job> --format=…​.

  • CPU/mémoire : vmstat, pidstat, free, perf stat.

  • GPU : nvidia-smi --query (ou DCGM), échantillonnage régulier.

  • I/O : iostat, sar, compteurs FS/objet.

  • Réseau : métriques MPI (profilage), ibstat/rdma.

Traçabilité
  • Tableau récapitulatif par expérience (ID, ressources, paramètres, métriques).

  • Graphiques : \(S(N), E(N)\), débit vs taille, qualité vs batch.

2.6. Validation — « Ai-je résolu le bon problème ? » (SI PERTINENT)

La validation évalue la pertinence scientifique/métier via confrontation au réel (physique/biologie/usage). Si non applicable, l’indiquer en 1–2 phrases et justifier.

  • Données externes/terrain : protocole de comparaison, incertitudes de mesure.

  • Critères métier/physiques : unités, seuils d’acceptation, cohérences dimensionnelles.

  • Résultats : écarts modèle–réalité, cas limites, domaine de validité.

  • Discussion : explications, limites, pistes d’amélioration.

2.7. Quantification d’incertitude (UQ) (SI PERTINENT)

  • Méthode : MC, ensembles, intervalles/bootstraps, sensibilité (Sobol, LHS), GPs, etc.

  • Résultats : intervalles de confiance, variances, propagation d’incertitude.

  • Impact : robustesse des conclusions, recommandations (données/paramètres critiques).

Si UQ non réalisée, indiquez pourquoi (périmètre/temps/données) et ce qui serait fait en suite.

2.8. Annexe — Mode opératoire benchmark (HPC + local)

Cette annexe décrit un protocole minimal, reproductible et traçable pour vérifier les performances et la scalabilité (strong/weak) d’un projet. Elle s’utilise avec Slurm sur HPC (Apptainer/Singularity ou Docker selon la politique du site) et en local pour l’inférence.

2.8.1. Principes

  • Reproductibilité: figer code (hash Git), environnement (image conteneur + digest), données (checksum), config (YAML), seeds.

  • Mesure: collecter \(T_{total}\), débit, mémoire max, utilisation CPU/GPU, et ressources allouées.

  • Scalabilité:

  • Strong scaling: problème fixe, ressources ↑ ⇒ \(S(N)=T(1)/T(N),\;E(N)=S(N)/N\)

  • Weak scaling: charge par ressource ~constante ⇒ stabilité de \(T(N)\) et du débit.

2.8.2. Organisation minimale du dépôt

project/
├─ configs/exp.yaml
├─ data/              # (ou DVC si utilisé)
├─ images/ml.sif      # image Apptainer locale (optionnel)
├─ scripts/
│  ├─ train.sh        # lance entraînement (local/HPC)
│  ├─ strong_scaling.sh
│  └─ weak_scaling.sh
├─ slurm/
│  ├─ train_cpu.sbatch
│  └─ train_gpu.sbatch
├─ tools/
│  ├─ log_metrics.py  # append CSV
│  └─ parse_sacct.sh  # récupère métriques Slurm
└─ results/
   ├─ runs.csv
   └─ logs/

2.8.3. Conteneur & environnement

  • Apptainer recommandé sur HPC: apptainer build images/ml.sif docker://ghcr.io/<org>/<img>:<tag>

  • Sinon, utiliser une image déjà fournie par le site HPC.

  • Toujours citer l'image + digest dans le rapport.

2.8.4. Script Slurm — CPU

slurm/train_cpu.sbatch
#!/usr/bin/env bash
#SBATCH -J train_cpu
#SBATCH -A <account>              # compte projet
#SBATCH -p <partition>            # ex: cpu, long, normal
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=32
#SBATCH --time=02:00:00
#SBATCH -o results/logs/%x-%j.out
#SBATCH -e results/logs/%x-%j.err

set -euo pipefail

# Paramètres expérience
EXP_ID=${EXP_ID:-"EXP-$(date +%Y%m%d-%H%M%S)"}
CONFIG=${CONFIG:-"configs/exp.yaml"}
DATA_DIR=${DATA_DIR:-"$PWD/data"}
RESULTS=${RESULTS:-"$PWD/results"}
CSV=${CSV:-"$RESULTS/runs.csv"}
CONTAINER=${CONTAINER:-"$PWD/images/ml.sif"}  # ou "docker://ghcr.io/<org>/<img>:<tag>"

mkdir -p "$RESULTS/logs"

START_TS=$(date +%s)

# Exemple Apptainer (CPU)
srun apptainer exec \
  --bind "$DATA_DIR:/workspace/data","$RESULTS:/workspace/results" \
  "$CONTAINER" \
  bash -lc "python -m project.train --config $CONFIG --device cpu"

END_TS=$(date +%s)
T_TOTAL=$(( END_TS - START_TS ))

# Récupère métriques Slurm
tools/parse_sacct.sh "$SLURM_JOB_ID" > "$RESULTS/logs/${EXP_ID}-${SLURM_JOB_ID}.sacct"

# Journalise
python tools/log_metrics.py \
  --csv "$CSV" \
  --exp-id "$EXP_ID" \
  --resources "nodes=${SLURM_NNODES};ntasks_per_node=${SLURM_NTASKS_PER_NODE}" \
  --t-total "$T_TOTAL" \
  --container "$CONTAINER" \
  --config "$CONFIG" \
  --notes "cpu-run"

2.8.5. Script Slurm — GPU

slurm/train_gpu.sbatch
#!/usr/bin/env bash
#SBATCH -J train_gpu
#SBATCH -A <account>
#SBATCH -p <partition>            # ex: gpu
#SBATCH --nodes=1
#SBATCH --gres=gpu:1
#SBATCH --cpus-per-task=16
#SBATCH --time=02:00:00
#SBATCH -o results/logs/%x-%j.out
#SBATCH -e results/logs/%x-%j.err

set -euo pipefail

EXP_ID=${EXP_ID:-"EXP-$(date +%Y%m%d-%H%M%S)"}
CONFIG=${CONFIG:-"configs/exp.yaml"}
DATA_DIR=${DATA_DIR:-"$PWD/data"}
RESULTS=${RESULTS:-"$PWD/results"}
CSV=${CSV:-"$RESULTS/runs.csv"}
CONTAINER=${CONTAINER:-"$PWD/images/ml.sif"}

mkdir -p "$RESULTS/logs"

START_TS=$(date +%s)

# Exemple Apptainer (GPU)
srun apptainer exec --nv \
  --bind "$DATA_DIR:/workspace/data","$RESULTS:/workspace/results" \
  "$CONTAINER" \
  bash -lc "python -m project.train --config $CONFIG --device cuda"

END_TS=$(date +%s)
T_TOTAL=$(( END_TS - START_TS ))

tools/parse_sacct.sh "$SLURM_JOB_ID" > "$RESULTS/logs/${EXP_ID}-${SLURM_JOB_ID}.sacct"

python tools/log_metrics.py \
  --csv "$CSV" \
  --exp-id "$EXP_ID" \
  --resources "nodes=${SLURM_NNODES};gpu=1;cpus_per_task=${SLURM_CPUS_PER_TASK}" \
  --t-total "$T_TOTAL" \
  --container "$CONTAINER" \
  --config "$CONFIG" \
  --notes "gpu-run"

2.8.6. Lancements "scaling"

scripts/strong_scaling.sh (problème fixe, N nœuds ∈ {1,2,4,8})
#!/usr/bin/env bash
set -euo pipefail
for N in 1 2 4 8; do
  EXP_ID="SS-N${N}-$(date +%Y%m%d-%H%M%S)"
  sbatch --nodes=$N --export=ALL,EXP_ID=$EXP_ID,CONFIG=configs/exp.yaml slurm/train_cpu.sbatch
done
scripts/weak_scaling.sh (charge/dev fixe, données et ressources ↑)
#!/usr/bin/env bash
set -euo pipefail
# Associer (N, taille_données) pour garder charge par ressource ~constante
declare -a NS=(1 2 4 8)
declare -a DS=("10k" "20k" "40k" "80k")
for i in "${!NS[@]}"; do
  N=${NS[$i]}; D=${DS[$i]}
  EXP_ID="WS-N${N}-D${D}-$(date +%Y%m%d-%H%M%S)"
  sbatch --nodes=$N --export=ALL,EXP_ID=$EXP_ID,CONFIG=configs/exp_${D}.yaml slurm/train_cpu.sbatch
done

2.8.7. Extraction métriques Slurm & logs

tools/parse_sacct.sh
#!/usr/bin/env bash
# Usage: tools/parse_sacct.sh <jobid>
JOB=$1
sacct -j "$JOB" --format=JobID,Elapsed,MaxRSS,MaxVMSize,TotalCPU,AllocTRES%30,State -P

2.8.8. Journalisation CSV

tools/log_metrics.py
#!/usr/bin/env python3
import argparse, csv, os, subprocess, hashlib, json, time

p = argparse.ArgumentParser()
p.add_argument("--csv", required=True)
p.add_argument("--exp-id", required=True)
p.add_argument("--resources", default="")
p.add_argument("--t-total", type=float, required=True)
p.add_argument("--container", required=True)
p.add_argument("--config", required=True)
p.add_argument("--notes", default="")
args = p.parse_args()

def git_commit():
    try:
        return subprocess.check_output(["git","rev-parse","--short","HEAD"]).decode().strip()
    except Exception:
        return "NA"

def file_sha256(path):
    if not os.path.exists(path): return "NA"
    h=hashlib.sha256()
    with open(path,"rb") as f:
        for chunk in iter(lambda: f.read(1<<20), b""): h.update(chunk)
    return h.hexdigest()

row = {
  "timestamp": time.strftime("%Y-%m-%d %H:%M:%S"),
  "exp_id": args.exp_id,
  "git_commit": git_commit(),
  "container": args.container,
  "container_sha256": file_sha256(args.container) if args.container.endswith(".sif") else "NA",
  "config": args.config,
  "config_sha256": file_sha256(args.config),
  "resources": args.resources,
  "t_total_s": args.t_total,
  "notes": args.notes
}

file_exists = os.path.exists(args.csv)
os.makedirs(os.path.dirname(args.csv), exist_ok=True)
with open(args.csv, "a", newline="") as f:
    w = csv.DictWriter(f, fieldnames=list(row.keys()))
    if not file_exists: w.writeheader()
    w.writerow(row)
print(json.dumps(row, indent=2))

2.8.9. Exemple CSV (results/runs.csv)

timestamp,exp_id,git_commit,container,container_sha256,config,config_sha256,resources,t_total_s,notes
2025-09-09 09:15:02,SS-N1-20250909-091502,abc1234,images/ml.sif,sha256:...,configs/exp.yaml,sha256:...,nodes=1;ntasks_per_node=32,1200,cpu-run
2025-09-09 09:48:31,SS-N2-20250909-094831,abc1234,images/ml.sif,sha256:...,configs/exp.yaml,sha256:...,nodes=2;ntasks_per_node=32,640,cpu-run

2.8.10. Post-traitement — calcul S(N), E(N)

Ces calculs servent à remplir les tableaux de Vérification (strong/weak scaling).

# tools/compute_scaling.py (exemple)
import pandas as pd, sys
df = pd.read_csv("results/runs.csv")
# Filtrer la campagne strong scaling:
ss = df[df["exp_id"].str.contains("SS-N")]
# Extraire N depuis "resources" (ex: nodes=4;ntasks_per_node=32)
def get_nodes(s):
    for kv in s.split(";"):
        if kv.startswith("nodes="): return int(kv.split("=")[1])
    return 1
ss["N"] = ss["resources"].apply(get_nodes)
T1 = ss.loc[ss["N"]==1, "t_total_s"].min()
ss["S"] = T1 / ss["t_total_s"]
ss["E"] = ss["S"] / ss["N"]
print(ss[["exp_id","N","t_total_s","S","E"]].sort_values("N"))

2.8.11. Bonnes pratiques (rappel)

  • Vérification = OBLIGATOIRE: au moins un tableau de performance (temps total, débit, mémoire max) et, si possible, une campagne de strong scaling.

  • Validation / UQ = SI PERTINENT: si omis, l’indiquer et justifier en 1–2 phrases.

  • Lier chaque résultat à un commit et une image précisés (digest/sha).

  • Conserver tous les artefacts: scripts Slurm, logs, CSV, versions de config.

2.9. Bilan

  • Apports : techniques, scientifiques, méthodologiques, collaboration/gestion.

  • Limites & risques : points durs, dettes techniques.

  • Perspectives : recherche/industrialisation, extensions de données/modèles, monitoring en prod.

3. La Forme

3.1. Typographie

La rédaction de textes obéit à des règles précises en Français : cela s’appelle la typographie, voir <les petites leçons de typographie de Jacques André>.

Il est intéressant de s’en imprégner pour donner à votre document un aspect de qualité et éviter des erreurs grossières.

3.2. Orthographe et Grammaire

L’orthographe et la grammaire sont des prérequis indispensables pour la rédaction du mémoire. Si vous n’êtes pas sûr de vous, faites-vous relire par un tiers. C’est dommage de perdre des points sur ce critère.

3.3. Numérotation

Numérotez tout ce qui peut l’être.

  • pages,

  • chapitres,

  • sections,

  • figures,

  • tables,

  • équations,

  • bibliographie.

Laissez à Latex le soin de numéroter automatiquement, il le fera mieux que vous manuellement.

Pour les utilisateurs d’Antora, voici un template pour les équations qui utilisent un compteur:

[stem#eq-<some label>,reftext=Equation ({counter:eqs})]
++++
<Equation here>
++++
Exemple complet avec numérotation d’équations
= My Report
:sectnums:
:stem: latexmath
:eqnums: all

== Theory

[stem#eq-ode,reftext=Equation ({counter:eqs})]
++++
\mathbf{M}(t)\mathbf{\ddot{q}}(t) + \mathbf{C}(t)\mathbf{\dot{q}}(t) + \mathbf{K}(t)\mathbf{q}(t)
= \mathbf{F}(\mathbf{q}, \mathbf{\dot{q}}, t)
++++

See <<eq-ode>> for definition.

[stem#eq-emc,reftext=Equation ({counter:eqs})]
++++
E = mc^2
++++

<<eq-emc>> is another equation.

=== = My Report :sectnums: :stem: latexmath :eqnums: all

4. Theory

\[\mathbf{M}(t)\mathbf{\ddot{q}}(t) + \mathbf{C}(t)\mathbf{\dot{q}}(t) + \mathbf{K}(t)\mathbf{q}(t) = \mathbf{F}(\mathbf{q}, \mathbf{\dot{q}}, t)\]

See Equation (1) for definition.

\[E = mc^2\]

Equation (2) is another equation. ===

Utilisez des références si vous devez mettre en relation plusieurs éléments de votre discours en Latex (\ref, \pageref et \label).

4.1. Bibliographie

La bibliographie constitue une partie importante de votre mémoire. Elle constitue un critère de qualité du travail (avez-vous trouvé les bonnes sources ? les documents sur lesquels vous vous appuyez sont-ils sérieux ?). Vous devez indiquer les documents :

  • de référence que vous avez consultés dans votre recherche, pour vous familiariser avec votre sujet ou pour apprendre des techniques particulières ;

  • que vous avez consultés pour effectuer vos choix ou mettre en œuvre un dispositif logiciel ou autre ;

  • qui permettent au lecteur d’en savoir plus sur tel ou tel point de votre mémoire que vous ne pouvez davantage développer.

La bibliographie, voir <le document sur citer ses sources et présenter une bibliographie par Savoirs CDI> vient en annexe, elle doit donner tous les renseignements nécessaires pour permettre au lecteur de retrouver les documents concernés : auteur, titre du document ou de l’ouvrage, éditeur, année de publication, URL si nécessaire, date de consultation pour un site Web, etc.

Chaque document dans la bibliographie comporte une référence (un numéro, une abréviation ou autre), que vous devez citer dans le texte : un document non cité ne devrait pas apparaître dans la bibliographie.

5. Soutenance

Les soutenances ont lieu fin août, elles permettent à l’étudiant de présenter son travail de manière concise devant un jury de 3 personnes qui assistent à l’ensemble des présentations.

Les présentations durent 30 minutes dont 20 minutes de présentations et 10 minutes de questions.

  • Ne reproduisez pas le mémoire dans votre présentation : vous n’avez ni la place, ni le temps. Détachez-vous du mémoire et repartez de zéro pour construire un nouveau discours tenant compte de la contrainte de temps.

  • Travaillez sur les idées et les messages que vous voulez faire passer. Comptez une idée par diapo. Explicitez les idées, ne vous contentez pas de les suggérer.

  • Ne surchargez pas le texte de votre présentation : ne faites pas de phrases, insistez plutôt sur quelques mots pour exposer vos idées.

  • Si vous pouvez prendre des libertés avec la grammaire et ne pas mettre de phrases, vous n’êtes pas dispensé de respecter l’orthographe.

  • Adoptez un fond sobre pour ne pas perturber votre message. Numérotez vos diapos.

  • Faites des illustrations (schémas, figures, courbes) qui puissent être lues à plusieurs mètres de distance. N’hésitez pas à prendre des libertés avec votre style de présentation pour faire une figure en pleine page.

  • Attention aux contrastes : votre présentation projetée dans une salle éclairée aura un contraste beaucoup moins bon que l’écran de votre portable. Évitez donc les couleurs pâles sur fond clair, ou les couleurs peu foncées sur fond sombre.

  • Une de vos missions est de maintenir l’attention de votre auditoire. Pensez que les membres du jury ont déjà peut-être une dizaine de présentations à leur actif, ainsi qu’un bon repas…​ Vous devez les motiver pour vous écouter.

  • Ne lisez surtout pas les diapos que vous présentez ou, pire encore, un texte que vous auriez préparé. Regardez l’assistance et non vos diapos.

  • Respectez la durée de votre présentation. Ne terminez pas trop en avance (vous n’avez donc rien à dire ?), ne terminez pas trop en retard (vous ne savez pas synthétiser et tenir compte d’une contrainte ?).

  • Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez. Répétez.

  • Lors de la séance des questions, laissez les membres du jury aller jusqu’au bout de leurs questions, sans les interrompre. N’hésitez pas à prendre quelques secondes pour vous permettre de réfléchir à chaque question, voire de la reformuler pour vérifier que vous l’avez bien comprise.

Références

  • [JAndre] J. André. Petites leçons de typographie. Technical report, IRISA, 1990. btn:[> Site Web].

  • [SavoirsCDI] Savoirs CDI. Citer ses sources et présenter une bibliographie, 2016. btn:[> Site Web] .