Ho sempre sentito che la semplice parallelizzazione era uno dei vantaggi dei metodi DG, ma non vedo davvero perché uno di questi motivi non si applichi anche al Galerkin continuo.
Risposte:
Una delle ragioni per cui i metodi DG possono ricevere più attenzione come metodo parallelo è che si vede facilmente che il metodo è intrinsecamente locale a un elemento. L'accoppiamento nei metodi DG è debole, poiché si verifica solo attraverso bordi adiacenti (o facce in 3d). Pertanto, per triangoli o quad DG comunicherà al massimo a tre o quattro processori, rispettivamente. Mentre i metodi CG includeranno gli angoli degli elementi, quindi la valenza dell'angolo di un elemento diventa importante. A seconda del generatore di mesh utilizzato, questa valenza può essere di otto processori (possibilmente superiore). Pertanto, il costo dell'assemblaggio della derivata temporale può essere considerato "più elevato" per i metodi CG. Ciò è particolarmente preoccupante per i metodi spettrali, in cui il volume di informazioni da comunicare può essere piuttosto grande (e il nascondersi della latenza può diventare più difficile man mano che le dimensioni di ciascuna partizione si riducono).
Ma questo costo aggiuntivo per CG per assemblare il suo derivato temporale potrebbe essere compensato da una diversa strategia di bilanciamento del carico. Diverse strategie di partizionamento delle maglie (sono più esperto con METIS) consentono all'utente di bilanciare il carico attraverso varie metriche, ad esempio, garantendo che ogni partizione abbia approssimativamente lo stesso numero di elementi o limitando la quantità di comunicazione tra le partizioni. Sento una ragione per cui il colloquio di DG essendo prontamente parallelizzabile è che una spaccatura ingenua del problema in parti uguali può dare un'implementazione parallela molto efficiente, anche presentando un'accelerazione super lineare in alcuni casi a causa di effetti cache (vedi ad esempio Baggag et al. . o Altmann et. al.). Considerando che CG può richiedere un metodo di partizionamento più intelligente. Quindi potrebbe essere il caso che cambiare le discretizzazioni spaziali da DG a CG, per esempio, richiederebbe di riconsiderare anche come dividere la mesh in sottoproblemi.
Da molti anni a scrivere software FEM, credo che l'affermazione secondo cui gli schemi DG sono più adatti alla parallelizzazione rispetto agli schemi CG sia apocrifo. Viene spesso utilizzato nelle presentazioni dei documenti della DG come giustificazione per i metodi della DG, ma non l'ho mai visto avvalorato da un riferimento che ha effettivamente indagato sulla questione. È simile a ogni proposta del NSF su un progetto di teoria dei numeri che fa riferimento alla "crittografia" come un'area di più ampio impatto, un'affermazione che in questa generalità non è mai stata neppure confermata.
In effetti, credo che, con l'eccezione degli schemi espliciti di time stepping e, possibilmente, dei problemi in cui è necessario invertire una matrice di massa, gli schemi DG non sono migliori o peggiori degli schemi CG se si investigasse il costo della comunicazione coinvolto in entrambi. Intendo dire che questo è in senso pratico: certo, si potrebbe dover comunicare meno dati, ma immagino che la differenza nel tempo del wallclock sia trascurabile per tutti gli altri programmi operativi che fanno su questi dati.
Certo, sarei felice se qualcuno accettasse la sfida per dimostrarmi che ho torto!
Proprio come nel caso delle dichiarazioni più generali sugli schemi numerici, la risposta dipende dalle circostanze esatte che stai osservando. Innanzi tutto, i vantaggi della DG riguardo alla parallelizzazione pagano principalmente in caso di sistemi espliciti di integrazione temporale a causa di
Mentre queste dichiarazioni si applicano alle discretizzazioni della DG generiche, le applicazioni HPC reali (diciamo, usando diverse migliaia di processori) richiedono alcuni sforzi in più riguardo alla strategia di parallelizzazione per mantenere un buon ridimensionamento. Questo documento mostra, ad esempio, come si può ottenere un ridimensionamento quasi perfetto fino a una cella per processore . Questo è certamente qualcosa che non puoi aspettarti da un FEM continuo, ma come menzionato prima, gli schemi impliciti sono totalmente diversi.
Quando si assembla una matrice di rigidità, i dati memorizzati in un elemento in FEM continuo (nodale) devono essere comunicati a tutti i suoi vicini nodali. Al contrario, DGFEM richiede che i dati degli elementi siano comunicati a tutti i suoi vicini di casa. In 1D i vicini nodali e facciali sono identici, ma in 3D la differenza può essere piuttosto grande: per una normale rete esaedrica, ci sono 26 vicini nodali ma solo 6 vicini facciali. Per le mesh irregolari con molti vertici di alta valenza, la situazione peggiora per CG, mentre rimane invariata per DG.
DG per PDE iperbolico può essere utilizzato in sostituzione di schemi di volume finito. Nel volume finito come nella differenza finita, quando si aumenta l'ordine dello schema, lo stencil aumenta. Questo rende più difficile la parallelizzazione, poiché per ogni ordine di schema, hai uno stencil diverso. Ai confini della partizione, è necessario assicurarsi che tutte le celle richieste dalla partizione neigbouring per il particolare ordine dello schema siano disponibili. Ma con DG, indipendentemente dall'ordine in cui si trova lo schema, ogni cellula comunica solo con i suoi vicini di faccia. Quindi, confrontato tra volume / differenza finita e DG, si può dire che la DG è più facile da parallelizzare.