Diese Seite wurde maschinell aus dem Englischen übersetzt und kann Fehler enthalten. Englisches Original

Batch-processing (Kopflos)

Headless Batch-Processing führt Simulationen auf einem Computer ohne grafischen Desktop und ohne Aufsicht durch. Seine Grundlage ist der job: eine Simulation, die als unabhängiger Prozess läuft und weiterläuft, nachdem das Terminal, das es gestartet hat, geschlossen wurde.

Arbeitsplätze

axqua submit <case-file> --kind steady

Der Befehl erstellt einen Job, startet ihn im Hintergrund, druckt die Job-ID aus und kehrt sofort zurück. Der Terminal kann dann geschlossen und eine Verbindung zu einem entfernten Computer beendet werden. Folgende Job-Arten gibt es:

Art	Funktion
`preprocessing`	Erstellen Sie das TELEMAC-Modell.
`steady`	Führen Sie die stetige 2D-Simulation aus.
`unsteady`	Führen Sie die Simulation mit einem variierenden Abfluss aus.
`build-3d`, `steady-3d`	Schreiben und Ausführen des TELEMAC-3D-Modells.
`mesh-convergence`	Führen Sie die Netzkonvergenzstudie durch.
`vertical-convergence`	Führen Sie die Studie der Anzahl der vertikalen Layer.
`openfoam-build`, `openfoam-run`	Erstellen und Ausführen des OpenFOAM-Modells.
`openfoam-sediment-build`, `openfoam-sediment`	Bauen und führen Sie die Simulation von Feinsediment über einem Festbett (OpenFOAM Setup).
`calibration`, `calibration-multiflow`	Führen Sie die Bayessche Kalibrierung aus.

Einstellungen eines einzelnen Durchlaufs werden mit --option und die Anzahl der Prozessorkerne mit --np:

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

Eine unbekannte Option wird abgelehnt, bevor der Job erstellt wird.

Jeder Job hat seinen eigenen Ordner in der Job-Root. Der Standardjob ist ~/.local/share/axqua/jobs. Ein anderer Ordner wird mit --job-root oder mit der Umgebungsvariable AXQUA_JOB_ROOT ausgewählt.

<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

Der Job speichert die Einstellungen des Falls zum Zeitpunkt der Einreichung. Eine spätere Änderung der Fall-Datei hat keinen Einfluss auf einen laufenden Job und ein abgeschlossener Job bleibt reproduzierbar.

Überwachungs- und Kontrollaufgaben

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

Ein Job läuft durch die Zustände QUEUED, STARTING, RUNNING und POSTPROCESSING und endet als COMPLETED, FAILED oder CANCELLED. Wenn der Prozess eines Jobs verschwindet, zum Beispiel weil der Computer neu gestartet wurde, kennzeichnet die nächste Statusabfrage den Job als FAILED. Ein Job bleibt daher niemals aus Versehen im Zustand RUNNING.

Um einen gescheiterten Job zu untersuchen, lesen Sie zuerst runner.log. Es enthält den Fehler mit einem Code und einem vorgeschlagenen Heilmittel (Fehlerbehebung). Der Befehl axqua execute <job-id> wiederholt den Job im Vordergrund, so dass alle Nachrichten im Terminal erscheinen.

Sequenzen von Arbeitsplätzen

TELEMAC-Jobs von einem Fall laufen einen nach dem anderen. Ein Job, der eingereicht wird, während ein anderer Job des gleichen Falls läuft, wartet, bis dieser Job beendet ist, so dass die Schritte einer Sequenz in direkter Folge eingereicht werden können. Die Builds der OpenFOAM-Modelle und der Feinsediment-Simulation warten in der gleichen Reihenfolge, da sie vom stetigen 2D-Ergebnis ausgehen. Ein Lauf des OpenFOAM-Modells (openfoam-run) wartet nicht: Senden Sie es, wenn sein Build beendet ist. Ein Wartejob überprüft nicht, ob der vorherige Job erfolgreich war. Das folgende Skript für Linux führt daher den Preprocessing, den Trockenlauf und die Netzkonvergenzstudie eines Falls nacheinander aus und stoppt, wenn ein Schritt fehlschlägt:

#!/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

Starten Sie ein solches Skript mit nohup bash my-study.sh &, damit es nach dem Schließen von Terminal fortgesetzt wird.

Um einen Schritt für mehrere Abflüsse zu wiederholen, erstellen Sie eine Fall-Datei pro Abfluss und rufen Sie run_step in einer Schleife über die Fall-Dateien auf.

Wie Jobs losgelöst werden

aXqua liest die Umgebung der Simulationssoftware einmalig, wenn ein Auftrag eingereicht wird und übergibt diesen direkt an den Auftrag. Der Job hängt daher nicht von den Einstellungen des Terminal ab, von dem aus er gestartet wurde. Die Methode des Ablösens hängt vom Betriebssystem ab und wird automatisch ausgewählt:

Trägerrakete	Methode
`systemd`	Ein Benutzerdienst des Linux-Systems. Bevorzugt unter Linux.
`posix`	Eine separate Prozessgruppe. Wird unter Linux und macOS verwendet, wenn keine Benutzerdienste verfügbar sind, beispielsweise in einigen Remote-Sitzungen.
`windows`	Ein Windows-Auftragsobjekt.
`wsl`	Ein Prozess im Windows-Subsystem für Linux.

Ein weiterer Launcher wird mit --launcher ausgewählt. Die Launcher windows und wsl wurden noch nicht auf einer echten Windows-Installation getestet.

Wenn Sie einen Job stornieren, wird der Job zuerst aufgefordert, sich selbst zu beenden, damit er seine Dateien schließen kann. Wenn der Job nicht innerhalb von 20 Sekunden reagiert, stoppt aXqua alle seine Prozesse, einschließlich der parallelen Prozesse des Simulationscodes.