J'ai commencé à utiliser python comme langage de programmation pour faire toutes mes tâches en CFD. J'ai très peu d'expérience en programmation. Je suis issu du génie mécanique et je poursuis des études supérieures en génie aérospatial.
Parfois, l'aspect informatique du CFD devient plus fastidieux que la manipulation des équations ou le calcul.
Quelles sont les directives générales qui accélèrent l'exécution de notre programme? Quelles sont les astuces pour faire les choses en parallèle? Comment écrire les codes qui s'exécutent plus vite?
Où puis-je obtenir des ressources (faciles à comprendre pour un profane comme moi) qui répondent aux questions ci-dessus?
algorithms
python
fluid-dynamics
Subodh
la source
la source
Réponses:
Je vais essayer de répondre à votre question étant donné que vous demandez spécifiquement Python. Je décrirai ma propre méthode pour résoudre un problème de simulation. Des stratégies pour des simulations plus rapides sont données dans cette description.
Tout d'abord, je prototype de nouvelles simulations en Python. Bien sûr, j'essaie d'utiliser NumPy et SciPy autant que possible. Alors que NumPy fournit un type de données de tableau approprié pour les simulations numériques, SciPy propose une large gamme de routines numériques fonctionnant avec les tableaux NumPy.
Une fois que les prototypes fonctionnent plus ou moins, j'essaie de savoir quelles parties du programme ou du script sont le goulot d'étranglement. Il y a des candidats typiques pour cela:
J'utilise une stratégie de profilage simple pour savoir où tout le temps d'exécution est passé. En utilisant le shell IPython (que je ne peux pas recommander assez), je lance mon script avec
Cette "commande magique" fera le profilage (en utilisant timeit ) pour vous et vous présentera une liste des heures une fois votre script terminé. Utilisez cette liste pour savoir où votre code est trop lent.
Une fois que vous avez cloué les parties à accélérer, vous pouvez envisager d'utiliser des langages compilés. J'évoquerai deux solutions.
Tout d'abord, il y a le langage Cython . Cython est un langage de programmation très similaire à Python (en fait, le code Python est souvent aussi du code Python valide); cependant, le compilateur Cython convertit les fichiers Cython en code C, qui peut ensuite être compilé en un module utilisable à partir de Python. Cython comprend les tableaux NumPy. Il y a deux manières dont l'utilisation de Cython peut vous aider: premièrement, vous pouvez introduire des types de données. Cela accélérera les appels de fonction. De plus, si vous parcourez les tableaux, votre boucle s'exécutera plus rapidement (en fait, si vous tapez à la fois la variable fictive et le tableau, vous obtenez une boucle C simple!). Deuxièmement, dans mes expériences, même les scripts non typés s'exécutent un peu plus rapidement en raison du fait qu'ils sont compilés au lieu d'être interprétés.
L'autre langage compilé qui vous sera utile est le Fortran. Il existe différentes façons d'utiliser Fortran avec Python ( f2py , fortwrap , Cython ). Quant à moi personnellement, f2py semble être le moyen le plus simple, je décrirai rapidement ce qu'il fait. f2py peut compiler du code Fortran en modules Python. Il vous permettra d'utiliser des tableaux NumPy comme variables d'entrée et de sortie à partir de l'espace Python. Dans l'espace Fortran, il s'agira de tableaux Fortran ordinaires. Vous pouvez les utiliser à pleine vitesse Fortran.
Personnellement, j'ai tendance à utiliser Cython où le nombre d'appels de fonction est le goulot d'étranglement. Pour les trucs lourds en boucle, je préfère f2py (peut-être parce que j'ai une solide expérience en Fortran).
Sur une note supplémentaire sur Fortran: Fortran moderne lit et écrit très similaire à NumPy - la syntaxe est très proche. Cela facilite la conversion du code NumPy en code Fortran.
Notez que Cython et f2py prennent en charge le paralleisme d'une manière ou d'une autre. Pour Cython, vous trouverez de l'aide ici , tandis que pour Fortran, il existe des techniques standard telles que OpenMP ou MPI. De plus, il existe également des wrappers P ython pour MPI . Personnellement, j'utilise mpi4py au niveau Python ainsi que OpenMP dans Fortran.
Permettez-moi de vous recommander un peu de littérature: le livre Python Scripting For Computational Science de H.-P. Langtangen est une excellente ressource sur Python en général ainsi que sur les stratégies pour rendre Python un peu plus rapide. Malheureusement, AFAIR, il ne mentionne rien sur Cython. Comme deuxième ressource, vous pouvez consulter ces diapositives . Ceux-ci donnent des exemples de tout ce que j'ai mentionné dans cet article (voir aussi le code et les sources ici ). Il existe de nombreux autres bons diapositives sur Internet.
Si vous avez des questions plus spécifiques, nous sommes tous heureux de vous aider!
la source
Pour CFD + Python, il existe une solution: http://pythonflu.wikidot.com/ Il s'agit de liaisons Python au-dessus d'OpenFOAM (qui a déjà été mentionné dans les commentaires des questions). Ces liaisons permettent de programmer au "niveau du solveur" (il existe des exemples où les solveurs OpenFOAM originaux sont répliqués en Python et ils ne sont pas plus lents que les originaux - les boucles lentes mentionnées dans une autre réponse ne sont pas un problème ici car les "boucles internes" se produisent dans le code C ++ d'OpenFOAM).
L'avantage de ces liaisons est également que toute la parallélisation dans OpenFOAM se produit sous le niveau du solveur, donc vous n'avez pas à vous en préoccuper (ainsi que les autres choses dont le noyau OpenFOAM s'occupe: entrée / sortie, solveur linéaire, discrétisation d'opérateur)
Donc, si vous voulez simplement écrire un nouveau solveur et ne pas ajouter de nouvelles fonctionnalités au noyau OF (conditions aux limites, solveur linéaire, etc.), alors PythonFlu pourrait être suffisant pour vous et vous pouvez éviter le C ++ (qui a une cure d'apprentissage beaucoup plus élevée que Python)
PS: à l'origine, je voulais ajouter ceci en tant que commentaire à la discussion de la question d'origine, mais ma réputation ne me le permet pas
la source