BDF vs implicito Runge Kutta time stepping


16

Ci sono dei motivi per cui si dovrebbe scegliere Runge Kutta (IMRK) implicito di alto ordine rispetto al time stepping BDF? BDF mi sembra molto più semplice in quanto stage IMRK necessita di lineari per step temporale. La stabilità per BDF e IMRK sembra essere un punto controverso. Non riesco a trovare alcuna risorsa che paragona / contrapponga stepper di tempo implicito.qqq

Se aiuta, l'obiettivo finale è per me selezionare un stepper di tempo implicito di ordine elevato per PDE di diffusione dell'avviso.

Risposte:


34

Sì, non ci sono troppe risorse su questo per qualche motivo. Per molto tempo, il goto standard era "usa solo i metodi BDF". Questo mantra è stato messo in pietra per alcuni motivi storici: per un codice Gear era il primo risolutore rigido ampiamente disponibile, e per un altro la suite MATLAB non includeva / non includeva un metodo RK implicito. Tuttavia, questa euristica non è sempre corretta, e direi dai test che di solito è sbagliata. Lasciami spiegare in dettaglio.

I metodi BDF hanno un costo fisso elevato

Il timestamp adattivo e l'ordine adattivo nei metodi BDF hanno un costo davvero elevato. I coefficienti devono essere ricalcolati o i valori devono essere interpolati in tempi diversi. C'è stato molto lavoro da fare per far sì che gli attuali codici BDF facciano meglio qui (ci sono due "moduli" ben noti per l'implementazione che cerca di gestire questo problema in modo diverso), ma in realtà è solo un problema di ingegneria del software molto difficile. Per questo motivo, in realtà la maggior parte dei codici BDF sono tutti discendenti dal codice originale di Gear: Gear, vode, lsoda, CVODE di Sundial, anche i solutori DAE DASKR e DASSL sono discendenti dallo stesso codice.

Ciò significa che, se il tuo problema è "troppo piccolo", l'alto costo fisso conta davvero e i metodi RK impliciti faranno meglio.

I metodi BDF di alto ordine sono molto instabili per autovalori complessi

I metodi BDF consentono di controllare l'ordine massimo e renderlo più conservativo per un motivo: i metodi BDF di ordine superiore non sono in grado di gestire molto bene anche autovalori complessi di "medie dimensioni". Quindi in questi casi, per essere stabili, devono abbandonare il loro ordine. Questo è il motivo per cui il metodo BDF del 6 ° ordine, sebbene tecnicamente stabile, viene spesso ignorato perché anche il 5 ° ordine ha già dei problemi qui (e il 6 ° ordine è ancora meno stabile). Solo fino al 2 ° ordine è A-stabile, quindi può sempre ritornare a lì, ma poi il passo è dominato dall'errore.

Quindi, quando si utilizzano codici BDF per problemi non banali, non si ottiene sempre il 5 ° ordine. Le oscillazioni fanno cadere il suo ordine.

I metodi BDF hanno un costo iniziale elevato

iττ

I metodi BDF, essendo metodi multistep, hanno il miglior ridimensionamento

fradau

Quali benchmark sono disponibili?

Il libro per capelli e i segni DiffEqBench (spiegati di seguito) sono probabilmente i migliori in termini di diagrammi di precisione del lavoro facilmente disponibili. Le equazioni differenziali ordinarie di Hairer's Solving II hanno un sacco di diagrammi di precisione del lavoro alle pagine 154 e 155. I risultati sui problemi che ha scelto corrispondono a ciò che ho detto sopra per i motivi che ho indicato sopra: RK implicito sarà più efficiente se il problema non lo è "sufficientemente grande". Un'altra cosa interessante da notare è che i metodi di Rosenbrock di alto ordine risultano essere i più efficienti in molti dei suoi test (come Rodas) nel regime in cui l'errore è più elevato e l'RK implicito radau5è il più efficiente con errori più bassi. Ma i suoi problemi con i test non sono principalmente discretizzazioni di grandi PDE, quindi tieni conto dei punti sopra.

Come si effettua il test / benchmark?

Mi piace testarlo con DifferentialEquations.jl in Julia (dichiarazione di non responsabilità: sono uno degli sviluppatori). Questo è a Julia. Il linguaggio di programmazione dovrebbe davvero ottenere una nota qui. Ricordare che all'aumentare del costo della chiamata di funzione, i metodi BDF sono migliori. In R / MATLAB / Python, la funzione dell'utente è l'unico codice R / MATLAB / Python che i solutori ottimizzati devono effettivamente utilizzare: se si utilizzano involucri SciPy o Meridiane, è tutto il codice C / Fortran tranne la funzione che si passa . Ciò significa che, nei linguaggi dinamici (che non sono Julia), i metodi BDF funzionano meglio di quanto farebbero normalmente perché le chiamate di funzione sono molto non ottimizzate (questo è probabilmente il motivo per cui Shampine è incluso ode15snella suite MATLAB, ma nessun metodo RK implicito) .

fODEProblem

@time sol = solve(prob,CVODE_BDF())
@time sol = solve(prob,radau())

dove il primo usa Sundials CVODE(metodo BDF) e il secondo usa Hairer's radau(RK implicito).

Per chiunque ODEProblem, puoi usare gli strumenti di benchmarking per vedere come i diversi algoritmi si adattano alle diverse tolleranze adattive. Alcuni risultati sono pubblicati su DiffEqBenchmarks.jl . Ad esempio, sul problema ROBER (sistema di 3 ODE rigidi) si può vedere che le meridiane sono effettivamente instabili e divergono con una tolleranza abbastanza elevata (mentre gli altri metodi convergono bene), mostrando la nota sopra sui problemi di stabilità. Sul problema Van Der Pol , puoi vedere che è più un lavaggio. Ho molto più di quello che non ho pubblicato, ma probabilmente non ci riuscirò fino a quando non avrò finito alcuni metodi Rosenbrock di ordine superiore (Rodas è la versione Fortran di quelli).

(Nota: questi parametri di riferimento rigidi devono essere aggiornati. Per uno, il testo deve essere aggiornato poiché per qualche ragione i metodi di ODE.jl divergono ...)

Metodi di estrazione e RKC

Esistono anche metodi di estrapolazione come seulexquelli creati per problemi rigidi. Si tratta di un "ordine adattivo infinito", ma ciò significa che sono asimtopicamente buoni solo quando si cerca un errore molto basso (vale a dire cercare di risolvere problemi rigidi a un valore inferiore a 1e-10circa, nel qual caso è comunque possibile utilizzare un metodo esplicito) . Tuttavia, nella maggior parte dei casi non sono così efficienti e dovrebbero essere evitati.

Runge-Kutta Chebyschev è un metodo esplicito che funziona anche su problemi rigidi che dovresti considerare. Non l'ho ancora racchiuso in DifferentialEquations.jl, quindi non ho alcuna prova concreta di come sia fiere.

Altri metodi da considerare: metodi specializzati per PDE rigidi

Probabilmente dovresti prendere nota del fatto che i metodi Rosenbrock di alto ordine fanno davvero bene, molte volte anche meglio, per problemi rigidi di piccole e medie dimensioni quando puoi facilmente calcolare il giacobino. Tuttavia, per alcuni PDE, credo che i problemi di diffusione dell'avvezione rientrino in questa categoria, Rosenbrock può perdere alcuni ordini di accuratezza. Inoltre, hanno bisogno di giacobini molto precisi per mantenere la loro precisione. In Julia questo è facile perché i solutori sono dotati di simbolismo e autodifferenziazione che possono essere corretti per la macchina epsilon. Tuttavia, cose come MATLABode23spuò avere problemi perché queste implementazioni utilizzano la differenziazione finita. Per i metodi BDF e RK impliciti, gli errori nel Jacobiano portano a una convergenza più lenta, mentre per Rosenbrock, dal momento che queste non sono equazioni implicite e sono piuttosto metodi RK con inversioni giacobine, perdono solo un certo grado di accuratezza.

Altri metodi da considerare sono metodi esponenziali RK, esponenziale differenza di tempo (ETD), fattore di integrazione implicita (IIF) e metodi esponenziali di Rosenbrock. I primi tre fanno uso del fatto che, in molte discretizzazioni PDE,

ut=Au+f(u)

AAueAA

AJu+g(u)Jf=Ju+g

Ancora altri metodi: le ultime creazioni

I metodi che sono completamente impliciti ovviamente fanno bene alle equazioni rigide. Se il PDE non è abbastanza grande, non è possibile "parallelizzare nello spazio" in modo efficace per utilizzare gli HPC. Invece, puoi creare discretizzazioni parallele nel tempo che sono pienamente implicite e quindi buone per equazioni rigide, ma parallele per sfruttare appieno l'hardware. XBraid è un risolutore che utilizza una tecnica come questa e i metodi principali sono PFFAST e metodi parareali. DifferentialEquations.jl sta sviluppando un metodo di rete neurale che funziona in modo simile.

Ancora una volta, questo è ottimale quando non si dispone di una discretizzazione spaziale abbastanza ampia da poter parallelizzare in modo efficiente, ma sono disponibili le risorse per il calcolo parallelo.

Conclusione: prendere considerazioni asintotiche con un granello di sale

Δt

I metodi BDF sono asintoticamente i migliori, ma nella maggior parte dei casi probabilmente non stai lavorando in quel regime. Ma se la discretizzazione spaziale ha abbastanza punti, i metodi BDF possono parallelizzarsi efficacemente nello spazio (parallelizzando la risoluzione lineare) e avranno il minor numero di chiamate di funzioni, e quindi faranno il meglio. Ma se la tua discretizzazione PDE non è abbastanza grande, dai un'occhiata ai metodi impliciti di RK, Rosenbrock, esponenziale RK, ecc. Utilizzare una suite di software come DifferentialEquations.jl che semplifica lo scambio tra i diversi metodi può essere davvero utile per capire quale metodo fa meglio per il tuo dominio problematico, poiché in molti casi non può essere conosciuto in anticipo.

[Se hai qualche esempio di problema che vuoi aggiungere alla suite di test, non esitare a aiutarti a trovare qualcosa. Voglio mantenere una risorsa molto completa su questo. Spero di avere "presto" tutti i parametri di riferimento di Hairer in moduli per notebook eseguibili e vorrei altri problemi rappresentativi di settori scientifici. Qualsiasi aiuto è apprezzato!]


3
Questa è una risposta molto dettagliata, ho alcune nuove direzioni da esaminare! Apprezzo molto il tuo tempo.
user107904

3
La migliore risposta a qualsiasi domanda in questo forum tra un bel po '!
Wolfgang Bangerth,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.