Cette page a été traduite automatiquement de l’anglais et peut contenir des erreurs. Original en anglais

Batch-processing (sans tête)

Le traitement par lots sans tête exécute des simulations sur un ordinateur sans bureau graphique et sans supervision. Sa base est le tâche: une simulation qui fonctionne comme un processus indépendant et continue de fonctionner après que le terminal qui a commencé a été fermé.

Tâches

axqua submit <case-file> --kind steady

La commande crée une tâche, la démarre en arrière-plan, imprime l’ID tâche et retourne immédiatement. Le terminal peut alors être fermé, et une connexion à un ordinateur distant peut être terminée. Les types de tâche suivants existent :

Genre	Fonction
`preprocessing`	Construire le modèle TELEMAC.
`steady`	Lancez la simulation 2D stable.
`unsteady`	Lancez la simulation avec un débit variable.
`build-3d`, `steady-3d`	Écrire et exécuter le modèle TELEMAC-3D.
`mesh-convergence`	Exécutez l’étude de convergence en maillage.
`vertical-convergence`	Exécuter l’étude du nombre de verticale couches.
`openfoam-build`, `openfoam-run`	Construire et exécuter le modèle OpenFOAM.
`openfoam-sediment-build`, `openfoam-sediment`	Construire et exécuter la simulation de sédiments fins sur un lit fixe (Configuration OpenFOAM).
`calibration`, `calibration-multiflow`	Dirigez le calage bayésien.

Les paramètres d’une seule exécution sont passés avec --option, et le nombre de cœurs de processeur avec --np:

axqua submit <case-file> --kind mesh-convergence --np 16 --option tolerance=0.05

Une option inconnue est rejetée avant la création de la tâche.

Chaque tâche a son propre dossier dans la racine de tâche. La racine de tâche par défaut est ~/.local/share/axqua/jobs. Un autre dossier est sélectionné avec --job-root ou avec la variable environnement AXQUA_JOB_ROOT.

<job-root>/2026-08-14-my-reach-steady-a3f19c/
  job.json        the task, including a copy of the case settings
  status.json     the current state and progress
  runner.log      the log of aXqua for this job
  solver/         the output of the simulation code
  results/        a list of the result files

La tâche stocke les réglages du cas au moment de la soumission. Un changement ultérieur du fichier de cas n’affecte pas une tâche en cours d’exécution, et une tâche achevée reste reproductible.

Surveiller et contrôler les tâches

axqua list                          # all jobs with their state
axqua status <job-id>               # state and progress of one job
axqua status <job-id> --watch 30    # wait until the job has ended
axqua logs <job-id> --follow        # follow the log
axqua logs <job-id> --solver        # output of the simulation code
axqua cancel <job-id>               # stop the job

Une tâche passe par les états QUEUED, STARTING, RUNNING et POSTPROCESSING et se termine par COMPLETED, FAILED ou CANCELLED. Si le processus d’une tâche disparaît, par exemple parce que l’ordinateur a été redémarré, la prochaine requête de statut marque la tâche comme FAILED. Une tâche ne reste donc jamais dans l’état RUNNING par erreur.

Pour examiner une tâche échouée, lisez d’abord runner.log. Il contient l’erreur avec un code et un remède suggéré (Dépannage). La commande axqua execute <job-id> répète la tâche au premier plan, afin que tous les messages apparaissent dans la terminal.

Séquences des tâches

TELEMAC Les tâches d’un cas courent l’un après l’autre. Une tâche qui est soumise alors qu’une autre tâche du même cas est en cours d’attente jusqu’à ce que cette tâche soit terminée, de sorte que les étapes d’une séquence puissent être soumises en succession directe. Les constructions des modèles OpenFOAM et de la simulation sédiments fins attendent dans la même séquence, car elles partent du résultat 2D stable. Une exécution du modèle OpenFOAM (openfoam-run) n’attend pas : soumettez-le à la fin de sa construction. Une attente tâche ne vérifie pas si la précédente tâche a réussi. Le script suivant pour Linux exécute donc le prétraitement, la course à sec et l’étude de convergence en maillage d’un cas en séquence et s’arrête lorsqu’une étape échoue :

#!/bin/bash
CASE=cases/my-reach/my-reach.axq-case

run_step () {
    job=$(axqua submit "$CASE" --kind "$1" --json | python -c "import json, sys; print(json.load(sys.stdin)['data']['job_id'])")
    axqua status "$job" --watch 30 > /dev/null
    state=$(axqua status "$job" --json | python -c "import json, sys; print(json.load(sys.stdin)['data']['state'])")
    echo "$1: $state ($job)"
    [ "$state" = "COMPLETED" ] || exit 1
}

run_step preprocessing
run_step steady
run_step mesh-convergence

Commencez un tel script avec nohup bash my-study.sh & afin qu’il continue après la fermeture de terminal.

Pour répéter une étape pour plusieurs débits, créez une fichier de cas per débit et appelez run_step en boucle au-dessus de fichiers de cas.

Comment les tâches sont détachées

aXqua lit l’environnement du logiciel de simulation une fois lorsqu’une tâche est soumise et la transmet directement à la tâche. La tâche ne dépend donc pas des paramètres de la terminal à partir de laquelle elle a été lancée. La méthode de détachage dépend du système d’exploitation et est sélectionnée automatiquement :

Lanceur	Méthode
`systemd`	Un service utilisateur du système Linux. Préféré sur Linux.
`posix`	Un groupe de processus distinct. Utilisé sur Linux et macOS quand aucun service utilisateur n’est disponible, par exemple dans certaines sessions distantes.
`windows`	Un objet tâche Windows.
`wsl`	Un processus à l’intérieur du sous-système Windows pour Linux.

Un autre lanceur est sélectionné avec --launcher. Les lanceurs windows et wsl n’ont pas encore été testés sur une installation Windows réelle.

L’annulation d’une tâche demande d’abord à la tâche de se terminer, afin qu’elle puisse fermer ses dossiers. Si la tâche ne réagit pas en 20 secondes, aXqua arrête tous ses processus, y compris les processus parallèles du code de simulation.