C ++ ou Python pour un développement de bibliothèque CFD


13

Quels seraient, selon vous, les avantages / inconvénients de deux approches de codage d'une bibliothèque générale (volumes finis, fem, dg) pour la mécanique du continu informatique? C'est comme ça que je vois les choses en ce moment, alors s'il vous plaît fournissez vos propres expériences et ne me faites pas flamber pour la mienne :):

1) C ++:

  • programmation générique, fonctions virtuelles, surcharge, vitesse ...: tous les outils de genre + OOP disponibles pour construire ce que vous voulez

  • bibliothèques de bas niveau disponibles principalement (pas de développement de bibliothèques scientifiques et d'ingénierie à grande échelle comme celui pour Python)

2) wrappers Python + pour le calcul parallèle (pyOpenCL et autres)

  • énorme quantité de bibliothèques de support de différents types

  • codez ce que vous pensez: l'implémentation se fait très rapidement

  • temps d'exécution plus lent

Si vous vouliez coder un framework qui prendrait en charge diverses méthodes, travaillerait avec des géométries et des problèmes complexes, que choisiriez-vous et pourquoi?


1
Je ne suis pas très familier avec pyOpenCL, mais en règle générale, Python sera beaucoup trop lent pour des problèmes de taille même modérée en 2D ou 3D, à moins que vos "noyaux" de calcul soient implémentés dans un langage de bas niveau (Fortran, C, etc. )
David Ketcheson

Réponses:


14

Je viserais à tirer le meilleur parti des deux mondes et à coder l '"interface utilisateur" (c'est-à-dire le cadre des fonctions que l'utilisateur de votre bibliothèque appellera pour décrire la géométrie et d'autres propriétés du problème) en Python pour obtenir rapidement délai d'exécution, puis écrivez le temps d'exécution de la simulation en C ++.

En fait, je me moquerais probablement même du temps d'exécution de la simulation en Python d'abord, puis le remplacerais par du code C ++ morceau par morceau. Finalement, vous pourriez envisager d'avoir votre code Python générer une source C ++, pour être compilé et lié à votre runtime en ligne, afin que la simulation réelle n'ait pas du tout besoin d'appeler en Python - renvoyez uniquement les résultats à la fin. La bonne chose à propos de cette configuration est qu'elle est intrinsèquement agile: vous commencez avec la solution de travail la plus rapide et la plus simple, vous découvrirez rapidement ce qui fonctionne et ne fonctionne pas, et une fois que vous avez quelque chose que vous aimez, vous pouvez commencer à l'accélérer.

(Voici comment fonctionne le solveur ODE / DAE de Maple, sauf en utilisant Maple au lieu de Python. Divulgation complète: je travaille pour eux.)


1
+1. L'un des bons éléments de Python est la possibilité de s'éloigner de "Pure Python" si nécessaire.
Fomite

3

Vous pouvez également utiliser Cython pour vos algorithmes. Il s'agit essentiellement de Python avec des informations de type supplémentaires pour certaines variables qui doivent être "rapides". Il traduit le code Python en code C, qui peut ensuite être compilé par votre compilateur C préféré. L'ajout soigneux de ce type d'informations peut rendre votre code jusqu'à 150 fois plus rapide que le code Python naïf.


2

Je pense qu'il y a plus à cette question. D'abord et avant tout, un développeur préférera généralement ce qu'il / elle connaît à moins d'avantages importants (par exemple en termes de productivité, de temps de développement et d'outils). Personnellement, je donne la priorité à la productivité (le temps est généralement la ressource la plus rare!) Et cela favorise les choix qui sont proches de ma base d'expérience.

Peut-être aussi pertinents à prendre en compte sont

3) Temps de développement

  • combien de temps est réservé pour le développement
  • quand les résultats des travaux seront-ils livrés? et comment?
  • existe-t-il déjà un code qui peut faire le travail? (unicité?)

4) Entretien

  • combien de ressources (humaines) sont consacrées à la maintenance?
  • combien de personnes doivent travailler sur le code?
  • Le code doit-il être publié à un moment donné? (Critères?)
  • le code va-t-il s'appuyer sur des bibliothèques tierces?

5) Problème de licence

  • est le code de la recherche?
  • est le code pour les applications commerciales?

6) Facteur de productivité et de plaisir (souvent négligé!)

  • Où peut-on être le plus productif?
  • Où peut-on avoir le plus de plaisir à se développer?
  • Avez-vous la possibilité de faire partie d'un réseau (social)?

2

Cela dépend si votre code peut être écrit comme:

some_library_specific_type grid;

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

ou plutôt doit être écrit comme quelque chose comme ceci:

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

Dans le premier cas, choisissez ce que vous préférez coder; dans le second cas, n'utilisez aucun langage de script et ne vous préparez pas à souffrir du temps d'exécution.


2

En corollaire à la réponse d'Allan (que votre propre temps de développeur est la ressource la plus précieuse): utilisez ce que d'autres ont déjà fait. Vous dites que vous souhaitez développer une bibliothèque pour la mécanique du continuum de calcul, mais il y en a déjà plusieurs qui sont si grandes qu'elles auront presque toujours invariablement déjà tout ce dont vous avez besoin. Jetez un œil à deal.II par exemple pour tout ce qui peut être écrit comme un problème d'éléments finis, OpenFOAM pour la dynamique des fluides ou PyCLAW / CLAWPACK pour les problèmes hyperboliques. deal.II, par exemple, vous demande de programmer en C ++ mais en réalité le niveau de programmation est souvent si élevé que l'on pourrait dire que c'est comme un langage spécifique au domaine pour les codes FEM utilisant la syntaxe C ++.


2
Je n'ai jamais rencontré une bibliothèque qui avait tout ce dont j'avais besoin ...
Jack Poulson

Eh bien, mais vous comprenez ce que je suppose. Certaines bibliothèques ont "presque tout" dont vous pourriez avoir besoin. Pour citer un exemple que je connais particulièrement, un solveur d'éléments finis sur des maillages 3D entièrement auto-adaptatifs fonctionnant sur plus de 10000 processeurs utilisant des lignes de code deal.II et PETSc 126. C'est clairement plus que zéro, mais c'est en fait un très petit nombre étant donné la complexité de ce qui est sous le capot.
Wolfgang Bangerth

Pour jouer à l'avocat du diable, il est trivial d'exécuter un code sur 10 000 cœurs, mais c'est une question entièrement différente de le rendre évolutif. Peu de préconditionneurs parallèles pour les équations non elliptiques peuvent même fonctionner efficacement sur 300 cœurs.
Jack Poulson

Sûr. Mais l'exemple que je cite est évolutif: math.tamu.edu/~bangerth/publications/2010-distributed.pdf .
Wolfgang Bangerth

Dans l'intérêt d'une divulgation complète: je suis l'un des auteurs du document et du code référencés ci-dessus, ainsi que de la bibliothèque deal.II en général.
Wolfgang Bangerth
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.