que - Un buen diseño de OOP para un solucionador con Fortran moderno

programacion orientada a objetos javascript pdf

Question

Estoy diseñando un código Fortran para resolver un sistema PDE.

La forma en que está diseñado ahora es que tengo una Variable tipo que tiene varios atributos, el más importante de los cuales es el valor de matriz que almacena el valor.

Ahora también tengo una clase de solver , que realizaría cálculos en una variable . Pensé que pasar toda la variable al solucionador y trabajar con variable%val cada vez que quisiera ejecutarlo (varios miles de veces durante una ejecución) sería ineficiente, así que decidí definir campos de puntero en la clase de solver para enlazar el solucionador a la variable apropiada. Por ejemplo

program example
    use variable
    use solvers

    type(Variable) T 
    type(Solver) solver_temperature

    !Contructors
    call T%create()
    call solver_temperature%create(T)

    call solver_temperature%solve()
end program example

Y el módulo de solución

module solvers
type Solver
    real*8, pointer :: T(:,:)

contains 
    procedure :: create
    procedure :: solve
end type

contains
    subroutine create(this,T)
        type(Solver) :: this
        type(Variable) :: T

        this%T => T%val
    end subroutine
end module

En mi programa, defino diferentes variables para diferentes propiedades físicas y diferentes solucionadores que están asociados con esas variables en la forma que mostré arriba.

Soy nuevo en OOP en general, entonces mi pregunta es si ese es un diseño decente. Especialmente desde el punto de vista del rendimiento. ¿Cómo se compara esto con hacer de T una matriz y pasarla a una subrutina en términos de velocidad? ¿Hay alguna forma regular de hacer esto?

Answer 1

He estado trabajando con las características OO de Fortran durante un año más o menos, aquí hay algunos comentarios extendidos enmascarados como una respuesta.

Si simplemente le preocupa la velocidad de ejecución en bruto, probablemente sea, en general (y se base en argumentos y mi experiencia en lugar de datos), mejor evitar las características de OO; pero en muchos casos se puede hacer el mismo argumento de que es mejor mantenerse al margen de cualquier cosa que se agregue al idioma después de FORTRAN77.

Los argumentos a favor de OO son más fuertes cuando se basan en los problemas de diseño de códigos, comprensibilidad, extensibilidad, ese tipo de cosas. Si esto te importa, entonces deberías pensar en usar las características de OO.

Como ya comentó Vladimir, no parece tener mucho sentido usar el puntero variable. No olvide que la mayoría de las implementaciones de Fortran hacen llamadas por referencia específicamente para evitar el esfuerzo de copiar (grandes volúmenes de) datos.

Personalmente, no me gusta la forma en que ha definido su procedimiento de create tipo vinculado. Prefiero implementar ese tipo de operación como una función, de modo que pueda escribir líneas como esta:

t = solver%new()

en lugar de tu

call T%create()

Tenga en cuenta que esta es una preferencia mía, y es más una cuestión de estilo que de eficiencia o corrección. Observé que no ha declarado las intenciones de los argumentos a la subrutina create ; tal vez porque solo ha publicado un fragmento de su código.

Debido a que OO es relativamente nuevo en Fortran (y, posiblemente, relativamente desconocido para la mayoría de las personas que trabajan en los dominios donde se usa ampliamente Fortran), no hay mucho material útil para guiarnos en su adopción. Recomendaría Scientific Software Design . Proporciona al tema una cobertura decente y plantea el argumento de por qué los programadores científicos y de ingeniería deberían adoptar OO.