Le migliori metodologie per la gestione di una mesh nel calcolo di elementi finiti paralleli?

Attualmente sto sviluppando un metodo di decomposizione del dominio per la soluzione del problema di scattering. Fondamentalmente sto risolvendo un sistema di Helmholtz BVP in modo iterativo. Discretizzo le equazioni usando il metodo degli elementi finiti su maglie triangolari o tetraedriche. Sto sviluppando il codice per la mia tesi di dottorato. Sono a conoscenza di alcune delle librerie di elementi finiti esistenti là fuori come deal.ii o DUNE e anche se penso che siano fantastici, con design ispiratore e API, per scopi di apprendimento ho voluto sviluppare la mia piccola applicazione da zero.

Sono in un punto in cui ho le mie versioni seriali in esecuzione e ora voglio parallelizzarle. Dopotutto, è uno dei punti di forza del framework di decomposizione del dominio formulare algoritmi facili da parallelizzare, almeno in linea di principio. In pratica, tuttavia, ci sono molti dettagli da considerare. La gestione delle maglie è una di queste. Se le applicazioni devono raggiungere una risoluzione elevata scalando bene su molte CPU, la replica di un'intera mesh su ogni CPU è inefficiente.

Volevo chiedere a quegli sviluppatori che lavorano su applicazioni simili in ambienti di elaborazione ad alte prestazioni come affrontare questo problema.

Esiste una libreria p4est per la gestione di mesh distribuite. Non ho bisogno di AMR, quindi potrebbe essere eccessivo poiché mi interessa solo utilizzare mesh uniformi e non sono sicuro di poter affinare le mesh triangolari. Potrei anche semplicemente creare una mesh uniforme, quindi inserirla in uno dei partizionatori di mesh e fare un po 'di post elaborazione dell'output.

L'approccio più semplice sembra creare un file separato per ogni partizione contenente informazioni mesh relative solo a quella particolare partizione. Questo file verrebbe letto da una singola CPU che sarebbe responsabile dell'assemblaggio del sistema discreto su quella parte della mesh. Naturalmente, alcune informazioni sulla connettività / vicinato della partizione globale dovrebbero anche essere archiviate in un file letto da tutte le CPU per la comunicazione tra processi.

Quali altri approcci ci sono là fuori? Se qualcuno di voi potesse condividere, quali sono alcune delle metodologie comunemente utilizzate nel settore o istituti di ricerca governativi relativi alla gestione di questo problema? Sono abbastanza nuovo nella programmazione di un risolutore di elementi finiti parallelo e volevo avere un'idea del fatto se sto pensando a questo problema correttamente e come gli altri si stanno avvicinando. Qualsiasi consiglio o suggerimento per articoli di ricerca pertinenti sarebbe molto apprezzato!

Grazie in anticipo!

Se non si utilizza AMR e non si desidera scalare oltre i core 1K-4K, è sufficiente farlo.

1. Il grado 0 legge l'intera mesh e la suddivide usando METIS / Scotch ecc. (Nota: questa è un'operazione seriale).

2. Rango 0 trasmette le informazioni di partizionamento elemento / nodo a tutti gli altri ranghi e libera la memoria (utilizzata per memorizzare la mesh)

3. Tutti i gradi leggono i nodi / elementi che possiedono (compresi i nodi fantasma) dallo stesso file di input (Nota: 2000 gradi che accedono allo stesso file di input potrebbero sembrare lenti ma non sono in pratica, anche se potrebbero essere dannosi per il file system ma poi noi lo stanno facendo solo una volta).

4. Tutti i gradi devono creare le mappature nodo / elemento / dof da locale a globale per l'applicazione di BC e l'assemblaggio di matrici e rinumerare i nodi.

Dopo che tutto è stato detto e fatto tutti i dati su un rango saranno locali, quindi dovresti essere in grado di ridimensionare bene (per quanto riguarda la memoria). Faccio tutto questo in circa 100 righe (vedere le righe 35-132 qui ) in un mio piccolo codice.

Ora se la tua mesh è troppo grande (ad es.> 100-250 milioni di elementi) che non puoi partizionare usando METIS su un singolo nodo e hai bisogno di ParMETIS / PT-Scotch, allora hai il lavoro aggiuntivo di partizionarlo in parallelo prima di tutti i core / i ranghi possono leggerlo. In tale scenario potrebbe essere più semplice mantenere la fase di partizionamento separata dal codice principale per motivi logistici.

Le librerie AMR di solito non fanno le virgolette. Inoltre PETSc è una buona scelta per la parallelizzazione del codice.

Modifica: vedi anche qui e qui .

Questo potrebbe non essere una sorpresa per te dato che sviluppo affare.II, ma ecco la mia prospettiva: quando parlo con gli studenti, in genere dico loro di sviluppare il proprio prototipo all'inizio in modo che possano vedere come è fatto. Ma poi, una volta che hanno qualcosa di piccolo in esecuzione, li faccio usare una libreria che permette loro di andare molto oltre perché non devono reinventare la ruota praticamente con ogni passo che fanno.

Nel tuo caso, hai già visto come implementare un semplice solutore Helmholtz. Ma trascorrerai i prossimi 6 mesi a scrivere il codice necessario per farlo in parallelo, trascorrerai altri 3 mesi se vuoi usare geometrie più complicate. Trascorrerai altri 6 mesi se desideri un risolutore efficiente. E per tutto questo tempo stai scrivendo un codice che è già stato scritto da qualcun altro e che, in un certo senso, non ti avvicina di più a ciò che devi effettivamente fare per il tuo dottorato: sviluppare qualcosa di nuovo che non è stato fatto prima. Se percorri questa strada, trascorrerai 2-3 anni del tuo dottorato di ricerca facendo ciò che gli altri hanno fatto, e forse 1 anno facendo qualcosa di nuovo.

L'alternativa è che ora passi 6 mesi ad imparare una delle biblioteche esistenti, ma dopo avrai 2-3 anni in cui fai cose davvero nuove, cose in cui ogni due settimane puoi entrare nell'ufficio del tuo consulente e mostrargli / lei è qualcosa di veramente nuovo, che gira su scale di grandi dimensioni, o è molto bello sotto altri aspetti. Penso che probabilmente vedrai dove sto andando con questo ormai.

Questa non è una risposta completa.

Per l'implementazione dei metodi di decomposizione del dominio parallelo, ho riscontrato alcune complicazioni. Innanzitutto, è possibile utilizzare molti processori per un sottodominio o alimentare un processore con molti sottodomini e si potrebbe voler implementare entrambi i paradigmi. In secondo luogo, la forma sottostrutturata dei metodi di decomposizione del dominio richiede la separazione delle facce, dei bordi, dei vertici dei sottodomini (non degli elementi). Non credo che queste complicazioni siano prontamente incluse nella gestione della mesh parallela. La situazione diventa più semplice se si considera un processore per un sottodominio e si utilizza il metodo RAS / RASHO sovrapposto. Anche in questo caso, gestiresti meglio il layout parallelo da solo,