C ++ o Python per uno sviluppo della libreria CFD


13

Quali diresti sarebbero i vantaggi / gli svantaggi di due approcci alla codifica di una libreria generale (volume finito, fem, dg) per la meccanica del calcolo continuo? Questo è il modo in cui vedo le cose in questo momento, quindi per favore fornisci le tue esperienze e non darmi fuoco per le mie :):

1) C ++:

  • programmazione generica, funzioni virtuali, sovraccarico, velocità ...: tutti gli strumenti di genere + OOP disponibili per costruire quello che vuoi

  • librerie di basso livello disponibili principalmente (nessuno sviluppo di librerie di scienza e ingegneria ampiamente diffuse come quello di Python)

2) Python + wrapper per calcolo parallelo (pyOpenCL e altri)

  • enorme quantità di librerie di supporto di vario genere

  • codifica ciò che pensi: l'implementazione avviene molto velocemente

  • tempi di esecuzione più lenti

Se desideri codificare un framework che supporti vari metodi, lavori con geometrie e problemi complessi, cosa sceglieresti e perché?


1
Non ho molta familiarità con pyOpenCL, ma in generale Python sarà troppo lento per problemi anche di dimensioni moderate in 2D o 3D, a meno che i tuoi "kernel" computazionali non siano implementati in un linguaggio di basso livello (Fortran, C, ecc. )
David Ketcheson,

Risposte:


14

Vorrei mirare a ottenere il meglio da entrambi i mondi e codificare l '"interfaccia utente" (ovvero il framework di funzioni che l'utente della tua libreria chiamerà per descrivere la geometria e altre proprietà del problema) in Python per ottenere rapidamente tempo di consegna, quindi scrivere il tempo di esecuzione della simulazione in C ++.

In effetti, probabilmente deriderei prima anche il tempo di esecuzione della simulazione in Python, quindi lo sostituirei con il codice C ++ pezzo per pezzo. Alla fine potresti prendere in considerazione la possibilità che il tuo codice Python generi sorgente C ++, che sia compilato e collegato al tuo runtime online, in modo che la simulazione effettiva non debba richiamare affatto in Python - restituisce solo i risultati alla fine. La cosa bella di questa configurazione è che è intrinsecamente agile: inizi con la soluzione di lavoro più rapida e semplice, scoprirai rapidamente cosa funziona e cosa non funziona e una volta che hai qualcosa che ti piace puoi iniziare ad accelerarla.

(Ecco come funziona il solutore ODE / DAE di Maple, tranne per l'uso di Maple invece di Python. Informativa completa: lavoro per loro.)


1
+1. Uno dei bei pezzi di Python è la possibilità di allontanarsi da "Pure Python" se necessario.
Fomite,

3

Puoi anche usare Cython per i tuoi algoritmi. È essenzialmente Python con informazioni di tipo aggiunte per alcune variabili che devono essere "veloci". Traduce il codice Python in codice C, che può essere successivamente compilato dal tuo compilatore C. preferito. L'accurata aggiunta di questo tipo di informazioni può rendere il tuo codice fino a 150 volte più veloce dell'ingenuo codice Python.


2

Penso che ci siano più a questa domanda. Innanzitutto, uno sviluppatore preferisce in genere ciò che ha familiarità a meno che non presentino vantaggi significativi (ad esempio in termini di produttività, tempo di sviluppo e strumenti). Personalmente, ho la priorità di essere produttivo (il tempo è di solito la risorsa più scarsa!) E questo favorisce le scelte che sono vicine alla mia base di esperienza.

Forse anche rilevanti da prendere in considerazione sono

3) Tempo di sviluppo

  • quanto tempo è riservato allo sviluppo
  • quando devono essere consegnati i risultati del lavoro? e come?
  • esiste già un codice che può fare il lavoro? (unicità?)

4) Manutenzione

  • quante (persone) risorse sono dedicate alla manutenzione?
  • quante persone devono lavorare sul codice?
  • Il codice verrà rilasciato ad un certo punto? (criteri?)
  • il codice farà affidamento su librerie di terze parti?

5) Rilascio delle licenze

  • è il codice per la ricerca?
  • è il codice per applicazioni commerciali?

6) Fattore di produttività e divertimento (spesso trascurato!)

  • Dove si può essere più produttivi?
  • Dove si può avere lo sviluppo più divertente?
  • Qualche opportunità di far parte di una rete (sociale)?

2

Questo dipende se il tuo codice può essere scritto come:

some_library_specific_type grid;

for t=0 to T do
    library_function_1(grid,...);
    library_function_2(grid,...);
end

o meglio deve essere scritto come qualcosa del genere:

some_home_made_mixture_of_native_types grid;

for t=0 to T do
    for all grid elements as g do
        some_function(g,...);
        library_function(g,...);
    end
end

Nel primo caso scegli quello che ti piace di più per programmare; nel secondo caso non usare alcun linguaggio di scripting o prepararsi a risentire dei tempi di esecuzione.


2

Come corollario della risposta di Allan (che il tuo tempo di sviluppo è la risorsa più preziosa): usa ciò che altri hanno già fatto. Dici che vuoi sviluppare una biblioteca per la meccanica del continuum computazionale ma ce ne sono già parecchi di quelli così grandi che quasi invariabilmente avranno già tutto ciò di cui hai bisogno. Dai un'occhiata a deal.II ad esempio per tutto ciò che può essere scritto come un problema agli elementi finiti, OpenFOAM per fluidodinamica o PyCLAW / CLAWPACK per problemi iperbolici. deal.II, ad esempio, ti chiede di programmare in C ++ ma in realtà il livello di programmazione è spesso così alto che si potrebbe dire che è come un linguaggio specifico del dominio per i codici FEM che usano la sintassi C ++.


2
Non ho mai incontrato una biblioteca che avesse tutto ciò di cui avevo bisogno ...
Jack Poulson il

Bene, ma hai capito il punto suppongo. Alcune librerie hanno "quasi tutto" di cui potresti aver bisogno. Per citare solo un esempio che conosco particolarmente bene, un risolutore di elementi finiti su mesh 3d completamente autoadattative, in esecuzione su oltre 10.000 processori utilizzando le righe di codice deal.II e PETSc 126. Questo è chiaramente più di zero, ma in realtà è un numero molto piccolo data la complessità di ciò che è sotto il cofano.
Wolfgang Bangerth,

Per interpretare l'avvocato del diavolo, è banale eseguire un codice su 10.000 core, ma è completamente diverso renderlo scalabile. Non molti precondizionatori paralleli per equazioni non ellittiche possono funzionare in modo efficiente su 300 core.
Jack Poulson il


Nell'interesse di una completa divulgazione: sono uno degli autori sia del documento che del codice sopra menzionato, nonché della libreria deal.II in generale.
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.