OpenFOAM 14, parte 4: controlDict e controllo della simulazione

Ogni applicazione OpenFOAM costruisce all’avvio un oggetto Time (nel codice di solito chiamato runTime). È contemporaneamente l’orologio del calcolo e il registro radice di tutti gli oggetti che possono essere letti o scritti: mesh, campi, dizionari. Quando un campo viene «scritto», in realtà è runTime che decide se l’istante corrente è un istante di scrittura e chiede a ciascun oggetto registrato con l’opzione di scrittura automatica di salvarsi nella cartella del tempo corrente.

Per questo controlDict è letto prima di qualunque altro file del caso: senza di esso non esiste il database a cui gli altri oggetti si agganciano. Anche un’utility che non avanza nel tempo, come blockMesh, ha bisogno di un controlDict leggibile (lo si è visto nella Parte 2). Le cartelle con nome numerico (0, 0.01, …) sono le «istantanee» del database; ognuna, dopo una scrittura da parte del solutore, contiene anche una sottocartella uniform/ con il file time, che registra valore del tempo, indice del passo e passo temporale corrente (vedi la sezione 6).

Le impostazioni globali dell’installazione (unità di misura, OptimisationSwitches, DebugSwitches) non stanno nel controlDict del caso ma in $FOAM_ETC/configDict; si possono sovrascrivere per un singolo caso copiando il modello con foamGet configDict nella cartella system (Guida utente §4.3).

foamRun è un’applicazione generica: legge la parola chiave solver, carica la libreria condivisa del modulo con quel nome e poi esegue un ciclo temporale comune che chiama, a ogni passo, le funzioni del modulo (predittore del moto, correttore della pressione, modelli di trasporto e termofisici). La fisica e l’algoritmo stanno nel modulo; il controllo del tempo, la scrittura e i function object restano in foamRun e nel database del tempo. Per i casi multiregione (per esempio fluido + solido) si usa foamMultiRun, con i moduli indicati per regione in regionSolvers.

La tabella è un orientamento, non un elenco esaustivo: l’elenco autorevole per la tua installazione si ottiene con i comandi seguenti. Steady o transitorio non si sceglie più cambiando applicazione: con incompressibleFluid lo decide lo schema ddtSchemes in fvSchemes (steadyState o, per esempio, Euler), argomento della Parte 5.

foamToC -solvers                 # solver modules known to this installation
foamInfo incompressibleFluid     # description and example tutorials
foamDictionary -entry solver -value system/controlDict

Errore tipico: un controlDict copiato da un tutorial vecchio con application simpleFoam; e senza solver fa fallire foamRun con un FOAM FATAL IO ERROR del tipo «keyword solver is undefined in dictionary …/system/controlDict». Un nome di modulo scritto male produce invece un errore di selezione che indica il tipo sconosciuto. Alcuni tutorial Foundation contengono anche una riga application foamRun;: è usata dagli script dei tutorial per sapere quale eseguibile lanciare, ma la voce decisiva per la fisica resta solver.

La Guida utente v14 (§4.4) indica come obbligatorie le voci di controllo del tempo e la coppia writeControl/writeInterval; le altre hanno un valore predefinito. Scriverle comunque in modo esplicito rende il file autodocumentato e protegge da cambi futuri dei default.

Per vedere il file così come lo legge OpenFOAM, con macro espanse e valori effettivi, usa foamDictionary -expand system/controlDict. La guida elenca anche voci meno comuni: libs (librerie aggiuntive da caricare), functions (sezione 9), graphFormat (formato dei dati di grafico: raw predefinito, gnuplot, csv, vtk, ensight) e beginTime (sezione 4).

In un calcolo stazionario la derivata temporale viene eliminata dalle equazioni (ddtSchemes { default steadyState; }) e il modulo usa un algoritmo di tipo SIMPLE. Il database del tempo continua però ad avanzare: ogni «passo» è un’iterazione di sottorilassamento verso la soluzione stazionaria. Per convenzione si pone deltaT 1;, così il tempo coincide con il numero di iterazioni.

Il tutorial del gradino all’indietro della Guida utente v14 (§2.1.7 e §2.1.9) lo mostra bene: endTime 2000, deltaT 1, writeControl timeStep, writeInterval 100. Il calcolo si ferma prima, quando i residui iniziali scendono sotto le tolleranze di residualControl in fvSolution: il log riporta la convergenza SIMPLE in 285 iterazioni e vengono scritte le cartelle 100, 200 e 285. L’ultima non è un multiplo di 100: all’arresto per convergenza il modulo scrive lo stato finale.

Conseguenza pratica: in un caso stazionario un nome di cartella come 285 non significa «285 secondi» e un valore di deltaT diverso da 1 non cambia la soluzione convergente; cambia solo i nomi. Prima di interpretare una cartella di tempo, controlla quindi ddtSchemes con foamDictionary -entry ddtSchemes system/fvSchemes.

Il numero di passi pianificato con passo fisso è N = (endTime − startTime)/Δt; nell’esempio 0,020/0,002 = 10. Il confronto però non avviene in aritmetica esatta: 0,002 non è rappresentabile esattamente in virgola mobile binaria e dieci somme successive non danno esattamente 0,02. Per evitare un passo in più o in meno per colpa dell’arrotondamento, il database del tempo della Foundation continua finché il tempo corrente è minore di endTime − ½Δt. Il tempo viene inoltre ricalcolato a ogni passo in modo da limitare l’accumulo di errori, e il nome della cartella viene generato con timePrecision cifre.

Esempio numerico: con endTime 0.021 e Δt = 0,002 il criterio è t < 0,020. Dopo il decimo passo t = 0,020, quindi il calcolo si ferma a 0,020 e non a 0,021: con passo fisso non c’è un ultimo passo «accorciato». Se endTime non è un multiplo di Δt, il tempo finale reale è il multiplo più vicino secondo questo criterio. Prevedilo sempre e confrontalo con l’ultima riga Time = del log.

Con stopAt writeNow e noWriteNow il database del tempo, alla prima rilettura del file, fissa di fatto la fine al passo corrente; con nextWrite attende che il passo corrente sia anche un tempo di scrittura. Con firstTime e latestTime il valore di startTime non conta; con startTime deve esistere una cartella con quel tempo che contenga i campi richiesti.

Con incompressibleFluid in regime transitorio l’algoritmo è PIMPLE. Un passo temporale contiene nOuterCorrectors cicli esterni; in ognuno c’è (facoltativamente) un predittore della quantità di moto, cioè la soluzione di un sistema lineare per ciascuna componente di velocità, seguito da nCorrectors correzioni della pressione, ciascuna con la soluzione di un’equazione di Poisson per p (più eventuali correzioni di non ortogonalità). Con 1 ciclo esterno e 2 correzioni si risolvono quindi, per passo, fino a 3 sistemi di velocità e 2 di pressione, e ogni sistema richiede a sua volta più iterazioni del solutore lineare.

Nel log questo si vede come un blocco per passo: una riga Time = …, poi righe del tipo «solutore: Solving for Ux, Initial residual = …, Final residual = …, No Iterations …» per ogni soluzione, gli errori di continuità e infine ExecutionTime e ClockTime. Contare le righe Time = conta i passi; contare le righe «Solving for p» conta le soluzioni di pressione. Le impostazioni di PIMPLE e le tolleranze appartengono a fvSolution e sono trattate nella Parte 6.

timeStep. Il passo corrente è un tempo di scrittura quando il suo indice è un multiplo intero di writeInterval (che va quindi inteso come numero intero di passi). L’indice è quello registrato nel database del tempo: dopo un restart prosegue dal valore salvato in uniform/time, non riparte da zero.

runTime / adjustableRunTime. A ogni passo si calcola un indice di scrittura come parte intera di (t − t_rif + ½Δt)/writeInterval; quando questo indice aumenta rispetto all’ultima scrittura, il passo corrente diventa un tempo di scrittura. Il mezzo passo rende il confronto robusto agli arrotondamenti: con Δt = 0,002 e intervallo 0,006, a t = 0,006 si ha (0,006 + 0,001)/0,006 ≈ 1,17 → indice 1 → scrittura. Se l’intervallo non è un multiplo di Δt, la scrittura cade sul passo più vicino all’istante richiesto (entro mezzo passo), non sull’istante esatto, e i tempi scritti non sono equidistanti.

Il riferimento t_rif conta dopo un restart. La Guida v14 documenta la voce facoltativa beginTime, che ancora i tempi di scrittura ai multipli di writeInterval a partire da quel tempo, per i casi con un tempo di avvio «scomodo». Dopo un restart da un tempo che non è multiplo dell’intervallo, verifica con foamListTimes dove cade la prima scrittura invece di supporla.

clockTime / cpuTime. L’intervallo è in secondi di tempo reale o di CPU; i tempi simulati scritti dipendono dal carico della macchina e cambiano da un’esecuzione all’altra. Sono utili come salvataggi di sicurezza su calcoli lunghi (per esempio writeInterval 3600 con clockTime), mai per un confronto riproducibile.

Con adjustableRunTime il database del tempo, quando il passo viene impostato, calcola il tempo che manca alla prossima scrittura e lo divide in un numero intero di passi uguali, arrotondando per eccesso il rapporto tra tempo mancante e passo corrente. Il nuovo passo è il tempo mancante diviso per quel numero; la variazione rispetto al passo precedente è limitata per non introdurre salti bruschi. Il risultato è che le scritture cadono esattamente sui multipli di writeInterval.

Esempio: passo corrente 0,004 s, prossima scrittura tra 0,006 s. Il rapporto è 1,5 → 2 passi → Δt = 0,003 s. Senza adattamento, con runTime, i passi cadrebbero a 0,004 e 0,008 e la scrittura «a 0,006» finirebbe a 0,008 (il passo più vicino entro mezzo passo, secondo la regola della nota precedente).

La Guida v14 raccomanda adjustableRunTime insieme al passo automatico (adjustTimeStep yes): è lì che serve davvero, perché il passo cambia di continuo e senza aggiustamento i tempi scritti sarebbero arbitrari, come nota il tutorial della rottura della diga (§2.2). Con passo fisso già allineato all’intervallo, come nell’esempio della tabella, runTime e adjustableRunTime danno gli stessi tempi.

In memoria OpenFOAM lavora in doppia precisione (circa 15–17 cifre significative). In ASCII ogni valore viene scritto con writePrecision cifre significative: con 6 (il predefinito) un valore come 0,0123456789 diventa 0,0123457. Il solutore non perde accuratezza durante il calcolo, ma un restart da una cartella ASCII riparte da valori arrotondati: per piccole variazioni o per confronti bit a bit tra un calcolo continuo e uno ripreso, questo basta a far divergere leggermente le storie. Per questo il riferimento usa 8, e per restart rigorosi conviene binary, che conserva tutti i bit.

Con writeFormat binary l’intestazione FoamFile resta testuale (con format binary;) ma le liste di valori non uniformi diventano byte grezzi; less mostra caratteri illeggibili. Con writeCompression on i file diventano U.gz, p.gz, ecc.; OpenFOAM li legge in modo trasparente e zcat 0.01/U.gz | head -n 30 ne mostra l’inizio se sono ASCII.

Stima d’ordine per il canale della Parte 2 (40 × 10 × 5 = 2.000 celle; 5.350 facce interne): U contiene 2.000 vettori, cioè 6.000 numeri; in binario 8 byte ciascuno ≈ 48 kB, in ASCII con 8 cifre circa 12–15 caratteri per numero ≈ 70–90 kB. phi (un valore per faccia interna) e p aggiungono quantità simili. Moltiplica per il numero di scritture: 1.000 scritture di una mesh da 10 milioni di celle sono già centinaia di gigabyte. Misura sempre con du -sh invece di indovinare.

timeFormat accetta fixed, scientific e general (predefinito). Secondo la Guida v14, general usa la notazione scientifica quando l’esponente è minore di −4 o maggiore o uguale a timePrecision, altrimenti la notazione decimale senza zeri finali. timePrecision (predefinito 6) è il numero di cifre usate.

Una collisione è grave: due istanti diversi scriverebbero nella stessa cartella, sovrascrivendosi, oppure un tempo positivo verrebbe confuso con 0. Il database del tempo della Foundation rileva la situazione quando il passo è troppo piccolo per le cifre disponibili, aumenta automaticamente timePrecision e lo segnala con un avviso nel log («Increased the timePrecision …»). Non affidarti a questo meccanismo: scegli la precisione in base al passo più piccolo previsto (con passo adattivo, in base a quello che compare nel log) e cerca l’avviso nel log.

La Guida v14 descrive purgeWrite come un limite al numero di cartelle di tempo conservate: superato il limite, le cartelle più vecchie vengono sovrascritte in modo ciclico, cioè eliminate a ogni nuova scrittura. Con purgeWrite 2 e scritture ogni 5 passi nel caso di riferimento esteso a 0,040 s, al termine resterebbero solo 0.035 e 0.04; 0.01, 0.015, … sarebbero andate perse durante il calcolo.

Nell’implementazione Foundation la coda delle cartelle da eliminare contiene i tempi scritti dall’esecuzione corrente: la cartella iniziale 0/ e, dopo un restart, le cartelle prodotte da esecuzioni precedenti non vi entrano. Non usarlo però come garanzia: verifica su una copia con foamListTimes prima e dopo.

Uso legittimo: calcoli molto lunghi in cui interessano solo statistiche raccolte dai function object (sezione 9) e un punto di restart recente. Esiste anche lo strumento foamListTimes -rm, che elimina tutte le cartelle di tempo elencate tranne 0: anch’esso è irreversibile e va usato solo su copie, mai come scorciatoia diagnostica (sezione 13).

Dopo una scrittura del solutore, una cartella come 0.02/ contiene i campi risolti (U, p), il flusso sulle facce phi (con incompressibleFluid; al restart viene letto se presente, invece di essere ricostruito dalla velocità) ed eventuali campi dei modelli (per esempio nut, k, omega con un modello di turbolenza). La sottocartella uniform/ contiene il file time con il valore del tempo, il nome, l’indice del passo e gli ultimi passi temporali (deltaT, deltaT0).

foamDictionary 0.02/uniform/time
# voci tipiche: value, name, index, deltaT, deltaT0
foamDictionary -entry index -value 0.02/uniform/time

Due conseguenze. Primo: con writeControl timeStep l’indice prosegue, quindi un restart da 0,02 (indice 10) con writeInterval 5 scrive a 0,03 e 0,04 (indici 15 e 20), coerentemente con il primo calcolo. Secondo: il database del tempo usa le informazioni di uniform/time per riprendere; se per il restart hai cambiato deltaT in controlDict, controlla nel log il passo effettivamente usato nei primi passi (per esempio l’intervallo tra due righe Time =) invece di supporlo.

foamListTimes (Guida §4.7) elenca le cartelle di tempo escludendo 0; con -latestTime mostra solo quella che startFrom latestTime selezionerà. foamDictionary -set modifica le voci in modo ripetibile e accetta più assegnazioni in una sola chiamata con la sintassi chiave=valore separata da virgole; dopo ogni modifica rileggi il valore con -value.

# Prevedi che cosa selezionerà latestTime, senza eseguire nulla
foamListTimes -latestTime

# Modifica le voci in modo riproducibile invece che a mano
foamDictionary -set "startFrom=latestTime, endTime=0.040" system/controlDict
foamDictionary -entry startFrom -value system/controlDict
foamDictionary -entry endTime -value system/controlDict

La trappola: foamCloneCase vecchio nuovo copia solo 0, system e constant. È perfetto per un nuovo avvio da zero, ma un clone non contiene le cartelle di tempo successive: un restart latestTime sul clone ripartirebbe silenziosamente da 0/. Per un restart usa cp -a, che copia tutto conservando date e permessi, come nella sequenza sicura qui sopra.

Se la mesh è cambiata (per esempio dopo un infittimento), i campi salvati non hanno più il numero di celle giusto e la lettura fallisce. Non è più un restart ma un nuovo calcolo inizializzato da un altro: la Guida v14 (§5.8) descrive mapFields per mappare i campi tra geometrie diverse.

Ai volumi finiti la velocità non è trasportata da un singolo |U| ma dai flussi volumetrici sulle facce φ_f = U_f·S_f (m³/s). Per ogni cella P OpenFOAM calcola Co_P = ½ Δt Σ_f |φ_f| / V_P: la somma di tutti i flussi entranti e uscenti, divisa per due (ciò che entra uguaglia ciò che esce), rapportata al volume. In parole: la frazione del volume della cella attraversata dal fluido in un passo. Il log riporta per ogni passo una riga «Courant Number mean: … max: …», cioè la media sulle celle e il massimo.

Per un esaedro uniforme con flusso solo lungo x la formula si riduce a |U|Δt/Δx, cioè alla stima del richiamo. Esempio sul canale della Parte 2 (Δx = 2,5 mm, Δy = Δz = 1 mm) con velocità assiale 0,05 m/s e Δt = 0,002 s: Co = 0,05 × 0,002 / 0,0025 = 0,04. Se la mesh viene infittita in x a Δx = 1,25 mm il Courant raddoppia a 0,08 a parità di passo: infittire la mesh senza ridurre il passo aumenta Co. Usa la velocità di picco, non la media: in un condotto il massimo al centro supera sensibilmente la velocità media.

Stabilità e accuratezza sono questioni diverse. Gli schemi temporali impliciti di OpenFOAM possono restare stabili anche con Co > 1, ma l’errore di discretizzazione temporale cresce con Δt e gli algoritmi di accoppiamento pressione-velocità con poche correzioni perdono accuratezza. Per i problemi con interfacce (VoF) esiste un limite separato, maxAlphaCo, usato dal tutorial della rottura della diga insieme a maxCo 1.

Nell’implementazione Foundation dei moduli fluidi il nuovo passo si ottiene dal rapporto r = maxCo/Co_max tra Courant obiettivo e massimo attuale. Quando r < 1 (Courant troppo alto) il passo viene ridotto subito in proporzione; quando r > 1 la crescita è smorzata (fattore non superiore a 1 + 0,1·r) e limitata a un aumento del 20% per passo. Infine il passo non supera mai maxDeltaT. All’avvio deltaT di controlDict è il valore iniziale, eventualmente ridotto subito se già viola maxCo.

Esempio con l’estratto di questa sezione: Δt iniziale 0,002 s, Co_max = 0,10, maxCo 0.5 → r = 5, ma la crescita è limitata a ×1,2 per passo: 0,0024; 0,00288; 0,003456; 0,004147; 0,004977; poi il passo successivo (0,00597) viene troncato da maxDeltaT 0.005. Con il passo a 0,005 il Courant atteso è 0,10 × 0,005/0,002 = 0,25, ancora sotto 0,5: qui il limite attivo è maxDeltaT, non maxCo. Contemporaneamente adjustableRunTime accorcia i passi vicino a 0,010 e 0,020 per farvi cadere le scritture.

Verifica nel log: con passo adattivo, a ogni passo compare una riga deltaT = … accanto alla riga del Courant. Estrai la storia con grep '^deltaT' log.foamRun e grep 'Courant Number' log.foamRun; se deltaT non cambia mai pur con adjustTimeStep yes, il modulo o il caso non stanno usando l’adattamento (per esempio perché il caso è stazionario).

A ogni passo i dizionari registrati come «da rileggere se modificati» vengono confrontati con il file su disco. Il metodo di controllo è l’opzione fileModificationChecking delle OptimisationSwitches in $FOAM_ETC/configDict (predefinito timeStampMaster: controllo della data di modifica, eseguito dal processo master in parallelo; alternative timeStamp, inotify, inotifyMaster). Su file system di rete conta anche fileModificationSkew, i secondi sottratti alla data del file per compensare ritardi e orologi non sincronizzati (Guida §4.3). Quando un file viene riletto, il log riporta un messaggio che nomina l’oggetto riletto (per esempio controlDict): è la conferma da annotare.

Che cosa risponde in modo affidabile: le voci di controllo del tempo e della scrittura di controlDict (endTime, stopAt, writeInterval, …) e, in generale, i parametri numerici di fvSchemes e fvSolution. Che cosa non va dato per scontato: la mesh, il modulo solver (già caricato), le condizioni al contorno nei campi della cartella di tempo in uso e molte proprietà fisiche.

Un editor che salva in più fasi può far leggere al solutore un file a metà, con un errore di sintassi che interrompe il calcolo. Più sicuro: una sola scrittura completa con foamDictionary -set, preceduta da una copia datata.

# 1. conserva una copia datata del file che stai per cambiare
cp -p system/controlDict system/controlDict.$(date +%Y%m%d-%H%M%S)
# 2. cambia una sola voce con un'unica scrittura completa
foamDictionary -entry stopAt -set nextWrite system/controlDict
# 3. cerca la conferma nel log
grep -n 'controlDict' log.foamRun | tail -n 3

Ctrl-C (SIGINT) o kill terminano il processo senza scrivere: tutto ciò che è stato calcolato dopo l’ultima scrittura va perso e il punto di restart è l’ultima cartella completa. Un’interruzione durante una scrittura può lasciare una cartella di tempo incompleta (alcuni campi mancanti o troncati): prima di un restart latestTime controlla che l’ultima cartella contenga tutti i campi e, se no, spostala fuori dal caso invece di cancellarla.

Confronto tra le vie ordinate: stopAt writeNow scrive subito al passo successivo alla rilettura (nessun calcolo perso, ma il tempo scritto è fuori dalla griglia pianificata); stopAt nextWrite mantiene la griglia di scrittura (a costo di attendere fino al prossimo evento); stopAt noWriteNow si ferma senza scrivere ed è utile solo quando i dati successivi all’ultima scrittura non servono. Esistono anche le OptimisationSwitches writeNowSignal e stopAtWriteNowSignal (Guida §4.3), che associano un segnale del sistema operativo a «scrivi ora» o «scrivi e fermati»; controlla il loro valore in $FOAM_ETC/configDict con foamDictionary -entry OptimisationSwitches/writeNowSignal $FOAM_ETC/configDict prima di farvi affidamento.

Modello di annotazione per il registro di laboratorio: «2026-10-16 14:32 — caso channel_B — endTime 0.020 → 0.040 — richiesto a t ≈ 0,014 — confermato nel log alla riga N (rilettura di controlDict) — motivo: estensione del transitorio».

La Guida v14 (§7.2) indica che dalla v12 i function object vanno preferibilmente in un file separato system/functions, invece che nel sotto-dizionario functions di controlDict: così le applicazioni che non usano function object non devono leggerli. La vecchia collocazione in controlDict, mostrata qui sopra, funziona ancora. Le funzioni preconfigurate si includono con la direttiva #includeFunc, passando gli argomenti tra parentesi; quelle con molti parametri (per esempio le forze) si copiano nel caso con foamGet e si modificano: una copia locale in system ha la precedenza sui modelli in $FOAM_ETC/caseDicts/postProcessing.

# Dalla v12 in poi è preferibile un file separato system/functions
foamGet functions                       # copia un modello in system/
# dentro system/functions, per esempio:
#includeFunc patchFlowRate(patch=outlet)

foamPostProcess -list                   # funzioni configurate disponibili
foamToC -functionObjects                # tipi di function object sottostanti
# dopo il calcolo, con i modelli del modulo solutore costruiti:
foamPostProcess -solver incompressibleFluid -func "patchFlowRate(patch=outlet)"

foamInfo dà descrizione ed esempi per modelli, moduli e funzioni; foamPostProcess -list elenca le funzioni configurate disponibili; foamToC -functionObjects elenca i tipi di function object compilati. I risultati vanno di norma nella cartella postProcessing/<nome>/<tempo di avvio>/. Per il canale, una portata in uscita (patchFlowRate) è il primo controllo naturale: deve uguagliare la portata in ingresso imposta nella Parte 3.

La tabella sopra distingue «quando valutare» e «quando scrivere». Nei function object Foundation le due domande corrispondono alle coppie executeControl/executeInterval e writeControl/writeInterval, che accettano le stesse modalità viste nella sezione 4 (timeStep, runTime, adjustableRunTime, clockTime, cpuTime) più writeTime, che lega l’evento alle scritture dei campi del caso. Una sonda può quindi essere valutata a ogni passo e scritta a ogni passo (per una storia temporale fine) mentre i campi completi vengono salvati solo ogni 5 passi: è proprio il modo di avere molti dati senza riempire il disco.

Attenzione alla coerenza con purgeWrite: i dati dei function object non vengono eliminati da purgeWrite, ma un function object che lavora «a posteriori» con foamPostProcess può elaborare solo le cartelle di tempo rimaste. Decidi prima del calcolo quali grandezze servono durante l’esecuzione e quali si possono ricavare dopo.

Previsione: 0,020/0,002 = 10 passi; scritture ai passi 5 e 10 → cartelle 0.01 e 0.02. Prima del calcolo ls mostra 0, constant, system (più eventuali script del caso); dopo, compaiono 0.01, 0.02 e log.foamRun. 0/ resta invariata: il solutore non la sovrascrive.

Una fine normale ha tre segni concordi: l’ultima riga del log è End; nel log non compare FOAM FATAL ERROR o FOAM FATAL IO ERROR; il codice di uscita del processo è 0 (echo $? subito dopo foamRun). Se si usa | tee invece del reindirizzamento, il codice di uscita è quello di tee a meno di impostare prima set -o pipefail. Un file di log esiste anche dopo un errore al primo passo: per questo la sola presenza del file non prova nulla.

tail -n 3 log.foamRun              # una terminazione normale finisce con la riga "End"
grep -c '^Time = ' log.foamRun     # numero di passi completati (qui 10)
grep -n 'FOAM FATAL' log.foamRun   # nessun output = nessun errore fatale registrato
foamListTimes                      # tempi scritti, 0 escluso

Le due fonti indicate sono un tutorial nativo v14 già funzionante oppure il caso completo e validato della serie: il primo caso pratico, il canale laminare di Poiseuille, contiene tutti i file necessari (mesh, campi, physicalProperties, momentumTransport, fvSchemes, fvSolution) per incompressibleFluid. Tra i tutorial, cerca quelli che selezionano lo stesso modulo e copiane uno nella tua cartella di lavoro prima di toccarlo.

# Casi nativi v14 che selezionano il modulo incompressibleFluid
grep -rl --include=controlDict 'incompressibleFluid' "$FOAM_TUTORIALS" | head
# Copiane uno nella tua cartella di lavoro prima di toccarlo
mkdir -p ~/run && cp -a "$FOAM_TUTORIALS/incompressibleFluid/cavity" ~/run/cavityBaseline
ls ~/run/cavityBaseline

Il percorso della cavità è quello abituale nelle versioni Foundation recenti; se nella tua installazione è diverso, usa il risultato della ricerca con grep. Molti tutorial vanno preparati con un passo di mesh (blockMesh) o hanno uno script Allrun: leggilo prima di eseguirlo e, per questo laboratorio, sostituisci solo i valori di controlDict della Fase B. Una cavità è chiusa: le patch non si chiamano inlet/outlet, ma la logica del tempo è identica.

Due osservazioni da scrivere nella scheda. In B lo stato finale calcolato a 0,020 non viene salvato: il calcolo esegue 10 passi, ma gli ultimi due (0,018 → 0,020) non lasciano traccia su disco; un restart da B riparte da 0,018. Per evitarlo, scegli un writeInterval che divida l’intervallo totale. In C la riduzione di dimensione dipende dalla mesh e dai valori (campi quasi uniformi si comprimono molto); su una mesh da 2.000 celle il tempo di calcolo è dominato dall’avvio e dal solutore, quindi differenze di tempo di pochi decimi di secondo sono rumore: ripeti la misura prima di trarre conclusioni.

# tre copie indipendenti della stessa base validata
for c in A B C; do cp -a channelBaseline channel_$c; done

foamDictionary -set "writeControl=runTime, writeInterval=0.006" channel_B/system/controlDict
foamDictionary -set "writeFormat=binary, writeCompression=on" channel_C/system/controlDict

for c in A B C; do (cd channel_$c && foamRun > log.foamRun 2>&1); done

# misure per la scheda di laboratorio
for c in A B C; do
  echo "== $c"
  (cd channel_$c && foamListTimes && du -sh $(foamListTimes) \
     && grep 'ExecutionTime' log.foamRun | tail -n 1)
done

Gli errori fatali di OpenFOAM hanno una struttura fissa: un’intestazione --> FOAM FATAL ERROR (errore di logica o di selezione) oppure --> FOAM FATAL IO ERROR (errore di lettura di un file), un messaggio, poi il file e la riga coinvolti e la funzione del codice che ha rilevato il problema. Cerca il primo blocco del genere con grep -n -A 12 'FOAM FATAL' log.foamRun | head -n 30: gli errori successivi sono spesso conseguenze.

Le formulazioni esatte cambiano tra versioni: usa la tabella per riconoscere la categoria, non come testo da cercare parola per parola. Correggi una causa alla volta e rilancia lo stesso comando, conservando il log precedente con un nome diverso (mv log.foamRun log.foamRun.1).