layout di memoria per i dati maglia in calcolo scientifico

Question

sto sviluppando un elemento sistema finito. Come di consueto, la simulazione è costituito da insieme di nodi di maglia, ciascuna con una serie di proprietà (floating-punti), come ad esempio diverse proprietà dei materiali, coordinate o grandezze fisiche che si evolvono nel tempo.

È possibile sia utilizzare due estremi approcci:

• Proprietà-saggio: Mantenere un singolo array per ogni proprietà:

  double* x, *y, *z, *e_field, *b_field, *conductivity;

• Entry-saggio: Mantenere un singolo array, in cui ogni array è struct

  struct { double x, y, z, e_field, b_field, conductivity; } *meshnodedata;

Tra questi, si potrebbe mescolare, come applicare il secondo approccio unico per le coordinate x, y, z, e con il primo approccio per le proprietà rimanenti. Le proprietà più la simulazione mantiene per ogni nodo di maglia, le possibilità di mescolare.

Da un lato, ho avuto il problema classico, che di questi approcci (e le loro miscele) è la cosa migliore per il calcolo scientifico per quanto riguarda le prestazioni del programma e la manutenibilità del codice. D'altra parte, mi chiedo come implementare il codice in modo tale che una migrazione tra diversi approcci diventa facile. Inoltre, potrebbe anche essere una soluzione di migrare da una mappatura di memoria per diverse parti del programma.

Per venire al punto:

• Quali sono state le tue esperienze di Pentecoste questi diversi approcci?
• Come significativi sono queste differenze stati?
• avete guadagnato esperienza nella migrazione tra questi due layout?

Answer 1

La tua domanda in realtà si riduce alla domanda come progettare il software elemento flessibile e veloce finita, che è un'area di ricerca attiva. Ho lavorato su questo tipo di software, e credo che le risposte alle vostre domande in realtà dipendono da che tipo di caratteristiche che si desidera supporto. Per esempio, avete bisogno adattiva raffinatezza griglia e ingrossamento? Si fa a risolvere sistemi di equazioni alle derivate parziali? Se il vostro codice di esecuzione in un cluster? Quante incognite avrete? Senza conoscere i tuoi obiettivi, cerco di fare alcune Ponts generali in ogni caso.

1. Ci sono una gran quantità di quadri Fe e gestori di rete là fuori - l'uso uno di loro

!

2. gestori di rete sono più complessi di quanto si creda. Finché si tratta solo tets in 3D su un singolo computer, potrebbe essere ancora gestibile. Un gestore di rete con tipi di elementi misti in 3D con raffinatezza locale e paralleli bilanciamento del carico è un compito enorme. sviluppare il proprio gestore di rete solo se si sa cosa si vuole migliorare su quelli che sono facilmente disponibili.

3. Struttura memoria: Ora arriviamo alla domanda reale :)
   dati griglia e di problem dati separati. Questo renderà il codice più mantenibile. Il gestore di rete può essere utilizzata per diversi tipi di problemi, e ogni problema ha la sua propria serie di dati collegati a ciascun elemento.

4. Se si memorizzano le cose come la conducibilità all'interno della griglia o al di fuori non dovrebbe importa molto per quanto riguarda le prestazioni. Vorrei separarlo per motivi costruttivi, non per motivi di prestazioni.

5. Conservare le incognite (probabilmente e_field e b_field nel tuo esempio) in un blocco contiguo di memoria. In questo modo in maniera massiccia di migliorare le prestazioni del vostro risolutore lineare. Un solutore iterativo lineare è di solito limitata dalla larghezza di banda della memoria per le grandi matrici.

6. La struttura interna del vostro vettore di incognite potrebbe essere raggruppato o il blocco-saggio (in pratica i due approcci che hai descritto tu stesso) Quale di questi due approcci da scegliere per la numerazione di incognite dipende da molti fattori, tra cui il tipo di PDE a risolvere e il tipo di risolutore lineare che si usa. Ci sono molte pubblicazioni scientifiche su questo problema da solo.