C ++ o Python para el desarrollo de la biblioteca CFD

13

¿Cuáles diría que serían las ventajas / desventajas de dos enfoques para codificar una biblioteca general (volumen finito, fem, dg) para la Mecánica de Continuo Computacional? Así es como veo las cosas ahora, así que por favor brinde sus propias experiencias y no me llame por las mías :):

1) C ++:

  • programación genérica, funciones virtuales, sobrecarga, velocidad ...: todas las herramientas genreic + OOP disponibles para construir lo que quieras

  • bibliotecas de bajo nivel disponibles en su mayoría (no hay un amplio desarrollo de bibliotecas de ciencia e ingeniería como la de Python)

2) Python + envoltorios para computación paralela (pyOpenCL y otros)

  • gran cantidad de bibliotecas de apoyo de varios tipos

  • codifique lo que piensa: la implementación se realiza realmente rápido

  • tiempo de ejecución más lento

Si quisieras codificar un marco que admitiera varios métodos, trabajar con geometrías y problemas complejos, ¿qué elegirías y por qué?

tmarico
fuente
1
No estoy muy familiarizado con pyOpenCL, pero en general Python será demasiado lento incluso para problemas de tamaño moderado en 2D o 3D, a menos que sus "núcleos" computacionales se implementen en un lenguaje de bajo nivel (Fortran, C, etc. )
David Ketcheson

Respuestas:

14

Mi objetivo sería obtener lo mejor de ambos mundos y codificar la "interfaz de usuario" (es decir, el marco de funciones que el usuario de su biblioteca llamará para describir la geometría y otras propiedades del problema) en Python para obtener la información rápida. tiempo de respuesta, luego escriba el tiempo de ejecución de la simulación en C ++.

De hecho, probablemente me burlaría incluso del tiempo de ejecución de la simulación en Python primero, luego lo reemplazaría por código C ++ pieza por pieza. Eventualmente, podría considerar que su código Python genere una fuente C ++, para ser compilada y vinculada a su tiempo de ejecución en línea, de modo que la simulación real no necesite llamar a Python en absoluto, solo devuelva los resultados al final. Lo bueno de esta configuración es que es inherentemente ágil: comienza con la solución de trabajo más rápida y fácil, descubrirá rápidamente qué funciona y qué no funciona, y una vez que tenga algo que le guste, puede comenzar a acelerarlo.

(Así es como funciona el solucionador ODE / DAE de Maple, excepto el uso de Maple en lugar de Python. Divulgación completa: trabajo para ellos).

Erik P.
fuente
1
+1. Una de las mejores partes de Python es la capacidad de alejarse de "Pure Python" si es necesario.
Fomite
3

También puede usar Cython para sus algoritmos. Es esencialmente Python con información de tipo agregada para algunas variables que necesitan ser "rápidas". Traduce el código de Python a código C, que posteriormente puede ser compilado por su compilador de C favorito. La adición cuidadosa de este tipo de información puede hacer que su código sea hasta 150 veces más rápido que el código ingenuo de Python.

Daniel Eberts
fuente
2

Creo que hay más en esta pregunta. En primer lugar, un desarrollador generalmente preferirá lo que está familiarizado a menos que tenga ventajas significativas (por ejemplo, en productividad, tiempo de desarrollo y herramientas). Personalmente, le doy prioridad a ser productivo (¡el tiempo suele ser el recurso más escaso!) Y esto favorece opciones que están cerca de mi base de experiencia.

Quizás también sea relevante tener en cuenta son

3) tiempo de desarrollo

  • cuánto tiempo está reservado para el desarrollo
  • ¿Cuándo se entregarán los resultados del trabajo? ¿y cómo?
  • ¿ya existe un código que pueda hacer el trabajo? (¿unicidad?)

4) mantenimiento

  • ¿Cuántos recursos (de personas) se dedican al mantenimiento?
  • ¿Cuántas personas deben trabajar en el código?
  • ¿Se lanzará el código en algún momento? (criterios?)
  • ¿El código va a depender de bibliotecas de terceros?

5) Problema de licencia

  • Cuál es el código para la investigación?
  • Cuál es el código para aplicaciones comerciales?

6) Productividad y factor de diversión (¡a menudo se pasa por alto!)

  • ¿Dónde se puede ser más productivo?
  • ¿Dónde se puede divertir más desarrollando?
  • ¿Alguna oportunidad de ser parte de una red (social)?
Allan P. Engsig-Karup
fuente
2

Esto depende de si su código se puede escribir como:

some_library_specific_type grid;

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

o más bien debe escribirse como algo así:

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

En el primer caso, elija lo que más le guste codificar; en el segundo caso, no use ningún lenguaje de script ni se prepare para sufrir el tiempo de ejecución.

mbq
fuente
2

Como corolario a la respuesta de Allan (que su propio tiempo de desarrollador es el recurso más valioso): use lo que otros ya han hecho. Usted dice que desea desarrollar una biblioteca para la mecánica de la computación continua, pero ya hay varias de ellas que son tan grandes que casi invariablemente ya tendrán todo lo que necesita. Eche un vistazo a deal.II, por ejemplo, para todo lo que se puede escribir como un problema de elementos finitos, OpenFOAM para dinámica de fluidos o PyCLAW / CLAWPACK para problemas hiperbólicos. deal.II, por ejemplo, le pide que programe en C ++, pero en realidad el nivel de programación a menudo es tan alto que se podría decir que es como un lenguaje específico de dominio para códigos FEM que usan la sintaxis de C ++.

Wolfgang Bangerth
fuente
2
He nunca se encontró una biblioteca que tenía todo lo que necesitaba ...
Jack Poulson
Bueno, pero entiendes el punto, supongo. Algunas bibliotecas tienen "casi todo" que pueda necesitar. Para citar un ejemplo con el que estoy particularmente familiarizado, un solucionador de elementos finitos en mallas 3D totalmente autoadaptativas que se ejecutan en más de 10,000 procesadores utilizando las líneas de código deal.II y PETSc 126. Eso es claramente más que cero, pero de hecho es un número muy pequeño dada la complejidad de lo que hay debajo del capó.
Wolfgang Bangerth
Para jugar al abogado del diablo, es trivial ejecutar un código en 10,000 núcleos, pero es completamente diferente hacerlo escalable. No muchos preacondicionadores paralelos para ecuaciones no elípticas pueden funcionar de manera eficiente en 300 núcleos.
Jack Poulson
Seguro. Pero el ejemplo que cito es escalable: math.tamu.edu/~bangerth/publications/2010-distributed.pdf .
Wolfgang Bangerth
En aras de la divulgación completa: soy uno de los autores tanto del artículo como del código mencionado anteriormente, así como de la biblioteca deal.II en general.
Wolfgang Bangerth