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

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?

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.)

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.

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)?

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.

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 ++.