UNIVE RSIDAD NACIONAL DE CÓRDOB A
FACUL TAD DE CIENCIAS E XACTAS, FÍSICAS Y NATURALES
TESIS
MAESTRÍA EN CIENCIAS DE LA INGENIERÍA MENCIÓN AEROESPACIAL
Implementación Computacional del Método de
Red de Vórtices Inestacionario: Una Versión
Basada en los Paradigmas de Programación
Orientada a Objetos y Co-Simulación
Pérez Segura, Martín Eduardo
2018
UNIVERSIDAD NACI ONAL DE CÓ RDOBA
FACUL TAD DE CIEN CIAS EXACT AS, FÍSI CAS Y NA TURA LES
TESIS
MAESTRÍA EN CIENCIAS DE LA INGENIERÍA MENCIÓN AEROESPACIAL
Implementación Computacional del Método de
Red de Vórtices Inestacionario: Una Versión
Basada en los Paradigmas de Programación
Orientada a Objetos y Co-Simulación
Pérez Segura, Martín Eduardo
Direcci ón: Mg. Ing. Maur o S. Ma za
Co-D irecci ón: Dr. In g. Serg i o Pre idikm a n
2018
III
RESUMEN
La multi-física computacional ha adquirido un papel preponderante a medida que
los avances en el ámbito de la investigación científica en ingeniería impulsaron la
aparición de modelos cada vez más complejos y que exceden los métodos de análisis
tradicionales. En este contexto, el presente desarrollo intenta proporcionar un marco
generalizado de simulación computacional para análisis fluido-dinámico basado en el
método de red de vórtices inestacionario y no lineal, enfatizando aspectos tales como: i)
el desarrollo de software fundado en el paradigma de la Programación Orientada a
Objetos, ii) la utilización de técnicas de Computación de Alto Desempeño; y iii) el diseño
de software conducente a la vinculación con otras herramientas computacionales. Luego,
el objetivo general de este esfuerzo es construir una herramienta funcional que combine
la aceptación y aplicabilidad del método de red de vórtices, con la confiabilidad y
versatilidad de un código modular bajo la metodología de la Programación Orientada a
Objetos.
El desarrollo siguiendo el paradigma de la Programación Orientada a Objetos
contribuye a la implementación, la lectura, el mantenimiento y la extensibilidad del
código, garantizando las características necesarias para su utilización eficiente en
distintos grupos de investigación. Por otro lado, se incorporan rutinas de pre-
procesamiento que requieren cantidades mínimas de información como datos de
entrada. Esto brinda una gran flexibilidad frente a otras herramientas que tienen
importantes restricciones respecto a la definición topológica de las mallas utilizadas. Se
admiten también modelos compuestos por múltiples cuerpos, rígidos y/o flexibles,
definidos a partir de grillas independientes, con gran versatilidad en cuanto a la elección
de las zonas de convección de estelas, los tipos de elementos a utilizar y otras
características, tales como condiciones de permeabilidad y determinación de velocidades
en puntos arbitrarios inmersos en el seno del fluido.
En cuanto al desempeño, incluso con una estructura de programación secuencial,
el método de red de vórtices posee una excelente relación entre aplicabilidad y costo de
cálculo. Sin embargo, se explotan varias de las posibilidades que el método ofrece para
paralelizar el cómputo, así como también mecanismos de optimización de algoritmos
para reducir los tiempos de ejecución.
Por último, se presenta una etapa de prueba y validación, la cual proporciona
confiabilidad al desarrollo garantizando que los resultados obtenidos sean correctos.
Todo esto con la intención de generar un componente computacional que pueda incluirse
en un software de co-simulación para analizar problemas que involucren un modelo
aerodinámico inherentemente inestacionario y no lineal.
V
PRÓLOGO
En los últimos años, la simulación computacional se ha convertido en una
herramienta poderosa como consecuencia de los grandes avances en el área de la
computación científica y de la tecnología del hardware. En virtud de ello, la multi-física
se ha visto ampliamente favorecida. En décadas pasadas, los efectos del acoplamiento
entre los distintos modelos se tenían en cuenta de manera aproximada o incluso, en
ciertas ocasiones, eran ignorados debido a las limitaciones computacionales. Problemas
de esta índole son estudiados dentro del grupo de investigación el cual comparto con el
autor del presente trabajo, más concretamente, se trabaja sobre sistemas en los que
existe un acoplamiento fuerte entre fenómenos aerodinámicos y estructurales.
En términos generales, el análisis de un problema de interacción fluido-estructura
requiere la construcción de dos modelos físicos: el estructural y el aerodinámico. En el
área de la aerodinámica computacional existen softwares libres ampliamente difundidos
que son utilizados para estudiar la dinámica de fluidos, pero tienen la desventaja de no
haber sido desarrollados para acoplarse con facilidad a otros códigos, lo que se traduce
en un inconveniente para tratar problemas multi-físicos. Dentro de este contexto, se ubica
la implementación computacional del método de la red de vórtices inestacionario y no
lineal presentada en esta obra. El fruto que surge de este trabajo es una poderosa
herramienta de simulación aerodinámica que beneficia, no sólo a su autor, sino todos los
miembros del grupo de investigación. Resulta sumamente atractiva ya que no ha sido
diseñada exclusivamente para abordar un problema en particular, sino que admite
sistemas constituidos por diversos cuerpos, rígidos o flexibles, y de topología arbitraria.
Un atributo muy valorado es la incorporación de técnicas de paralelización multicore, lo
que origina un gran rendimiento del código desde el punto de vista del tiempo de
ejecución. Estas virtudes junto a los resultados confiables y precisos la posicionan como
una excelente herramienta para tratar problemas multi-físicos de interacción fluido-
estructura.
Desde una óptica más personal, el software diseñado en este trabajo resulta de
gran valor para el desarrollo de mi tesis doctoral, ésta consiste en la construcción de
modelos numéricos de alas multifuncionales para la cosecha de energía a partir de
inestabilidades aeroelásticas. El beneficio de disponer un modelo aerodinámico de este
nivel hace que pueda concentrar mis esfuerzos en el modelo estructural y en el eléctrico,
lo cual es el punto central del tema de investigación. En virtud de ello, aprovecho para
agradecer y felicitar al autor por el excelente trabajo realizado y el gran aporte efectuado
al grupo de investigación.
Emmanuel Beltramo
VII
CONTENIDOS
Capítulo I: Notas Introductorias ........................................................................................................... 1
I.1. Contexto General .................................................................................................................... 1
I.2. Contexto Particular ................................................................................................................. 2
I.3. Por qué buscar otro enfoque .................................................................................................. 3
I.4. Revisión de alternativas .......................................................................................................... 4
I.5. Objetivos ................................................................................................................................. 5
I.6. Organización de tesis .............................................................................................................. 6
Capítulo II: Marco Teórico ........................................................................................................................ 9
II.1. Paradigmas de Programación ................................................................................................. 9
II.1.1. Clasificación de Paradigmas .......................................................................................... 11
II.2. Paradigma por Procedimientos ............................................................................................ 12
II.2.1. Ventajas y desventajas de la programación por procedimientos ................................. 13
II.3. Otros Paradigmas .................................................................................................................. 14
II.3.1. Paradigma de Programación Orientada a Componentes ............................................. 14
II.3.2. Paradigma de Programación Orientada a Aspectos ..................................................... 15
II.4. Paradigma de Programación Orientada a Objetos ............................................................... 16
II.4.1. El software como sistema complejo ............................................................................. 16
Estructura jerárquica ................................................................................................................. 17
Organización relativa ................................................................................................................ 18
Clasificación de aspectos ........................................................................................................... 18
Patrones comunes ..................................................................................................................... 18
Estados intermedios estables .................................................................................................... 18
II.4.2. El modelo de software .................................................................................................. 18
II.4.3. Orientación a objetos .................................................................................................... 19
II.4.4. El modelo orientado a objetos ...................................................................................... 19
II.4.5. Elementos del modelo orientado a objetos .................................................................. 20
Abstracción ............................................................................................................................... 21
Encapsulación ........................................................................................................................... 21
Modularidad .............................................................................................................................. 21
Jerarquía.................................................................................................................................... 22
II.4.6. Análisis Orientado a Objetos ......................................................................................... 22
II.4.7. Diseño Orientado a Objetos .......................................................................................... 22
Principios de diseño .................................................................................................................. 22
VIII
II.4.8. Programación Orientada a Objetos .............................................................................. 23
Implementación de la abstracción ............................................................................................ 23
Implementación de encapsulación y modularidad ................................................................... 24
Implementación de jerarquía ................................................................................................... 24
Polimorfismo ............................................................................................................................. 25
Programación genérica ............................................................................................................. 26
II.5. Programación multi-paradigma ............................................................................................ 26
II.6. Modelo Aerodinámico: UVLM .............................................................................................. 27
II.6.1. Fundamentos del modelo ............................................................................................. 27
II.6.2. Vorticidad ...................................................................................................................... 28
II.6.3. Determinación de velocidades ...................................................................................... 29
Condiciones de contorno .......................................................................................................... 30
II.6.4. Aproximación numérica ................................................................................................ 30
II.6.5. Determinación del campo de vorticidad ....................................................................... 32
II.6.6. Cargas aerodinámicas ................................................................................................... 34
II.6.7. Simulación ..................................................................................................................... 34
Capítulo III: Implementación .................................................................................................................. 37
III.1. El lenguaje de programación: Fortran .................................................................................. 37
III.1.1. Fortran 2003/2008 ........................................................................................................ 39
III.1.2. Por qué Fortran ............................................................................................................. 40
III.2. Desarrollo de la aplicación .................................................................................................... 41
III.2.1. Análisis orientado a objetos del UVLM ......................................................................... 42
III.2.2. Diseño orientado a objetos del UVLM .......................................................................... 43
Definición de entidades y jerarquía .......................................................................................... 43
Asociación de entidades ........................................................................................................... 43
Aplicación del SRP ..................................................................................................................... 45
Definición de clases ................................................................................................................... 46
III.2.3. Programación orientada a objetos del UVLM ............................................................... 47
Abstracción: clases y objetos .................................................................................................... 47
Encapsulación y modularidad ................................................................................................... 47
Jerarquía o herencia .................................................................................................................. 50
Polimorfismo ............................................................................................................................. 50
III.2.4. El diseño por procedimientos como alternativa ........................................................... 52
III.3. Particularidades de la implementación ................................................................................ 55
III.3.1. Generalidad de Datos de entrada ................................................................................. 55
Definición de Grillas .................................................................................................................. 55
IX
Tipos de paneles ....................................................................................................................... 58
Tipos de Líneas de Convección ................................................................................................. 59
III.3.2. Dimensionalización ....................................................................................................... 60
III.3.3. Estela de Segmentos ..................................................................................................... 60
Estructuración de la Estela ........................................................................................................ 61
Asignación de memoria ............................................................................................................ 61
Inicialización .............................................................................................................................. 63
Generación ................................................................................................................................ 64
Actualización ............................................................................................................................. 65
Actualización de estela incompleta ........................................................................................... 66
Actualización de estela completa .............................................................................................. 66
Ajuste ........................................................................................................................................ 68
Capítulo IV: Resultados y Validación ................................................................................................... 71
IV.1. Generalidades ....................................................................................................................... 71
IV.2. Caso 1: Placa plana en arranque impulsivo .......................................................................... 72
IV.3. Caso 2: Placa plana con movimiento oscilatorio impuesto .................................................. 75
IV.4. Caso 3: Modelo de aeronave con configuración de alas unidas ........................................... 78
IV.5. Caso 4: Sistema de reducción de resistencia aerodinámica ................................................. 83
Capítulo V: Comentarios Finales .......................................................................................................... 87
V.1. Generales .............................................................................................................................. 87
V.2. Conclusiones ......................................................................................................................... 87
V.3. Trabajos Futuros ................................................................................................................... 88
Referencias Bibliográficas......................................................................................................................... 91
1
Capítulo I: NOTAS INTRODUCTORIAS
I.1. CONTEXTO GENERAL
Con el comienzo del nuevo milenio, la investigación y el desarrollo en el ámbito de
la ingeniería y la tecnología han sufrido una mutación sustancial. Aquellos principios
impulsores que fueron motores de la industria en la segunda mitad del siglo pasado han
entrado progresivamente en crisis, dando lugar a la necesidad de encontrar nuevos
caminos para garantizar la sustentabilidad de las sociedades crecientes. Evidentemente,
la contaminación ambiental, la crisis energética, el incremento poblacional, el acceso a la
información, la automatización de procesos y la globalización digital son algunos aspectos
que, sumados a los contextos políticos, económicos y sociales modernos, modificaron los
intereses y objetivos del desarrollo tecnológico.
Para ilustrar la situación, tómese el uso de combustibles fósiles como ejemplo. En
1956 M. King Hubbert [1], geólogo de Shell Oil Company, a partir de sus estudios sobre
las prestaciones de distintos pozos petroleros, postuló que para la década de 1970 se
alcanzaría el pico de producción de hidrocarburos. Pasado este punto, según Hubbert, la
producción decaería sensiblemente hasta volverse inviable. Estudios más modernos
indican que el pronóstico de Hubbert fue prematuro, sin embargo, coinciden en que la
decadencia de los combustibles fósiles como fuente de energía principal (90%
aproximadamente) es una realidad inminente. Esto es, sin considerar los efectos
ambientales que la producción y el uso de combustibles fósiles conllevan. Con lo anterior
en vista, cada vez más países han mudado sus matrices energéticas a fuentes alternativas
y renovables con la intención de paliar la escasez y la contaminación.
Dicho esto, todo aporte a la investigación, en cualquier escala, debe contemplar
estos nuevos escenarios y ser consistente con las nuevas tendencias de desarrollo. Luego,
en este trabajo se trata a la fluido-dinámica como una fuente de aportes a la innovación,
puesta al servicio de necesidades emergentes. Tal es el caso de la energía eólica y la
industria de grandes aerogeneradores, así como también los nuevos conceptos en el
desarrollo de aeronaves eficientes de gran alcance y autonomía.
En cuanto a la energía eólica, de acuerdo con los datos publicados en junio de 2017
por la Asociación Mundial de la Energía Eólica [2], el mercado mundial alcanzó en 2016
los 468 GW, de los cuales 54 GW fueron instalados durante 2016. Con esto, el conjunto de
todas las turbinas eólicas instaladas en el mundo para finales de 2016 puede generar
Capítulo I: Notas Introductorias
2
aproximadamente 5% de la demanda energética global, con una proyección de 20% para
el año 2030.
Por su parte, la industria aeroespacial se encuentra en la búsqueda de nuevos
conceptos que permitan sostener en el tiempo el desarrollo logrado en las últimas
décadas. Al respecto, téngase en cuenta el caso de un avión Boeing 747-400 que realiza
un vuelo desde la ciudad de Buenos Aires hasta Londres, recorriendo una distancia
aproximada de 11100 Km. Durante el vuelo dicha aeronave consume algo más de 160 tn
de combustible que, según los estándares, equivalen a 1,92 millones de KWh (fuente:
www.boeing.com). Con estos valores, un vuelo transatlántico desde Argentina hasta el
Reino Unido equivale, en términos de energía, al consumo anual de alrededor de 550
hogares argentinos promedio (fuente: www.enerdata.net).
Ciertamente, en ambos casos subyace la necesidad de encontrar alternativas a
futuro que sean coherente con las nuevas matrices de desarrollo. Por lo tanto, las diversas
áreas de investigación en ingeniería y tecnología se encuentran bajo una exigencia
creciente que pone a prueba a quienes integran los distintos grupos de trabajo.
I.2. CONTEXTO PARTICULAR
Actualmente, la investigación y el desarrollo en el ámbito de la ingeniería y la
tecnología han incorporado la simulación computacional como práctica habitual, para
lograr sus objetivos. En este contexto, se han impuesto metas cada vez más ambiciosas
en cuanto a la representatividad de los modelos computacionales, impulsando la
sofisticación de las técnicas de análisis en pos del detalle en la descripción de los
fenómenos estudiados. En este sentido, la multi-física es la disciplina computacional que
ha permitido la implementación de un enfoque particionado de fenómenos complejos,
involucrando diversas áreas de la física en un proceso de co-simulación, basado en la
combinación de modelos disímiles altamente especializados.
En lo que concierne a este trabajo, la co-simulación se enmarca en la
aeroelasticidad computacional (CAE) como método de análisis de la interacción entre
fluido y estructuras (FSI). Conceptualmente, el problema aerodinámico y el problema
estructural-dinámico se abordan por separado con modelos apropiados para cada uno de
ellos, requiriendo de la incorporación de un método de interacción entre ambos. Bajo
estas inferencias generales, se reduce el enfoque al desarrollo del modelo aerodinámico,
implementando el Método de Red de Vórtices Inestacionario (UVLM por sus siglas en
inglés, “Unsteady Vortex Lattice Method”).
La construcción de un modelo de investigación computacional no puede
concebirse de manera aislada, sino íntimamente relacionada con un lenguaje y un estilo
de programación, y un entorno de desarrollo. Luego, fijar el alcance de la implementación
y, en consecuencia, definir un paradigma como guía, resulta preponderante. En muchos
aspectos, y a pesar de la generalidad alcanzada por la programación por procedimientos,
para los grupos de investigación resulta necesario optar por un estilo más adecuado. De
entre las posibilidades que cuentan con probada aceptación, el presente desarrollo
adopta los paradigmas de la Programación Orientada a Objetos (OOP) y la co-simulación,
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
3
en el entorno de la investigación científica, para fijar las pautas que guían la
implementación del UVLM.
Todo el desarrollo se enmarca en el grupo de trabajo del Departamento de
Estructuras de la Facultad de Ciencias Exactas, Físicas y Naturales de la Universidad
Nacional de Córdoba del que el autor del presente esfuerzo forma parte.
I.3. POR QUÉ BUSCAR OTRO ENFOQUE
El contexto en el cual el presente trabajo se desarrolla se compone principalmente
por los numerosos aportes que fueron realizados a la CAE por distintos grupos de
investigación y, en particular, por los provenientes del que el autor forma parte, entre los
cuales se destacan el análisis de grandes aerogeneradores, el estudio de aeronaves de
geometría variable (morphing wings), el diseño de micro vehículos aéreos no tripulados
inspirados en la biología, el estudio de alas batientes y el análisis de aeronaves con
configuración de alas unidas. Cada uno de estos esfuerzos ha demostrado satisfacer
necesidades puntuales dentro de los numerosos casos de aplicación de la CAE y de los
modelos aerodinámicos correspondientes. Sin embargo, la necesidad de aunar los
desarrollos de una manera eficiente para construir una plataforma común de co-
simulación no resulta totalmente satisfecha.
Si bien enfrentarse a un problema específico que requiera de la simulación para
su solución es el motivo principal para el desarrollo de una implementación
computacional, muchas veces el desarrollo suele truncarse en la solución de dicho
problema. En otras palabras, cuando el objetivo de una implementación se reduce a la
simulación de un caso particular, el resultado final dista mucho de tener aplicación
general y normalmente entra en desuso cuando el caso en cuestión se da por agotado. Por
lo tanto, construir desde el inicio un programa de simulación, con la aplicabilidad general
como premisa, brinda la oportunidad de explorar aspectos de la programación que en
general no son tenidos en cuenta.
Luego, el enfoque que se da al desarrollo es distinto: se trabaja en un programa de
simulación por el programa mismo, sin pensar en un problema puntual como objetivo, a
pesar de la aplicabilidad que pueda tener una vez desarrollado. De ahí que una
importante porción del esfuerzo se dedica al análisis de posibles paradigmas y estilos, a
la confección de documentación, a la distribución, al mantenimiento, a la contribución del
entorno de trabajo y a la búsqueda de performance, entre otros aspectos que muchas
veces quedan relegados por la obtención de resultados.
Bajo estas consideraciones, la estructura del proyecto se vuelve un concepto
diferente, más global y generalizado, que no encuentra en el paradigma tradicional de
programación por procedimientos la alternativa más adecuada para sus requerimientos.
Por lo tanto, es preciso considerar toda la gama de alternativas en cuanto a estilos de
programación y desarrollo de proyectos computacionales para optimizar en un sentido
amplio la implementación.
Capítulo I: Notas Introductorias
4
I.4. REVISIÓN DE ALTERNATIVAS
Existen varias herramientas capaces de simular modelos aerodinámicos que
satisfacen las necesidades de co-simulación de la CAE y muchas de ellas han sido
utilizadas en distintos contextos. En primera instancia, cualquier método de la mecánica
de los fluidos computacional (CFD) proporciona una base de análisis especializada que
puede incorporarse a un modelo de co-simulación. Luego, deben fijarse ciertas
características del modelo bajo las cuales las distintas alternativas serán más o menos
atractivas.
Evidentemente, la elección de un método de simulación computacional
aerodinámica depende de muchos factores cuyo estudio excede el alcance de este trabajo.
Sin embargo, una vez que se optó por uno deben considerarse las opciones ya existentes
para su implementación. En este caso, por ser el UVLM un método altamente estudiado,
se cuenta con trabajos de implementación ya desarrollados y disponibles que pueden
utilizarse.
Una alternativa atractiva es el uso de softwares comerciales o comunitarios de uso
general que proporcionan un soporte más o menos adecuado al usuario. Entre ellos se
destaca el programa de código libre OpenVOGEL [3]. Esta implementación, con la autoría
original de Guillermo Hazebrouck, fue lanzada en 2016 y a la fecha se ha convertido en
un repositorio comunitario con licencia pública (GPLv3) que progresivamente incorpora
módulos aportados por sus usuarios. La codificación se desarrolla en framework .NET
utilizando el entorno de Visual Studio Express ™.
La principal ventaja que presenta OpenVOGEL es quizás la interfaz gráfica que,
junto con una serie de modelos pre-configurados, resulta sumamente amigable con el
usuario. Del mismo modo, cuenta con herramientas de visualización y procesamiento de
resultados que facilitan la interpretación de los análisis. En lo que al núcleo de cálculo
respecta, OpenVOGEL es una implementación tradicional del UVLM que se presenta como
orientada a objetos dentro del soporte que brinda .NET. Posee dos características
adicionales, por un lado, la incorporación del paralelismo de hilos y, por otro, un módulo
aeroelástico que incorpora la descomposición modal de vigas.
Si bien OpenVOGEL satisface muchos de los requerimientos de un software de
simulación aerodinámica, y en muchos casos es una opción más que adecuada, presenta
ciertas desventajas en relación al enfoque del presente trabajo. En primer lugar, el marco
o lenguaje de programación (.NET) no es el más difundido dentro de la programación
científica y, a pesar de que facilita el desarrollo de aplicaciones, presenta ciertos
inconvenientes respecto al control de la estructura de datos y al acoplamiento con
códigos de otras plataformas. En segundo lugar, la implementación del paralelismo no es
completamente eficiente y, debido al modo en que .NET incorpora dicha característica,
resulta dificultoso realizar mejoras de performance en este sentido. Por último, la
incorporación de funcionalidades a un proyecto de cierta dimensión suele ser intrincado
debido a la gran cantidad de versiones y módulos alternativos que se encuentran
disponibles.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
5
Una segunda alternativa a considerar es trabajar sobre la base de algún código
desarrollado en el grupo de trabajo. La principal ventaja en este caso es contar con un
núcleo de cálculo que ha sido verificado y correctamente validado con anterioridad.
Además, la mayoría de los autores de estas implementaciones todavía forman parte del
grupo de investigación por lo que pueden brindar soporte. Por otro lado, utilizar un
programa en funcionamiento evita lidiar con los numerosos pormenores que implica un
desarrollo integral, debido a que éstos ya fueron resueltos reduciendo sensiblemente la
carga inicial de trabajo.
Sin embargo, la mayoría de estos códigos fueron concebidos para tratar casos
particulares y no cuentan con la versatilidad suficiente para adaptarse a otros problemas
sin modificaciones sustanciales. Luego, alterar una herramienta integral para adecuarse
a otros usos puede representar un esfuerzo incluso mayor que reiniciar el desarrollo. Esto
es, sin considerar las restricciones al estilo y organización que un código ya construido
impone.
I.5. OBJETIVOS
Con la aeroelasticidad computacional como área de trabajo principal y
considerando los requerimientos del entorno de investigación, surge la necesidad de
implementar un modelo aerodinámico general, adaptable y eficiente. Por lo tanto, el
objetivo general de este esfuerzo es construir una herramienta funcional que combine la
aceptación y aplicabilidad del UVLM, con la confiabilidad y versatilidad de un código
modular bajo la metodología de la OOP.
En particular, se desarrolla un software de simulación fluido-dinámica desde el
punto de vista del grupo de investigación. Esto es, con el fin de facilitar la lectura, la
comprensión y el mantenimiento del código, explotando en la mayor medida posible las
ventajas que la OOP proporciona a este respecto. Del mismo modo, se favorece la
flexibilidad y expansibilidad para futuros desarrollos, el intercambio y divulgación de
módulos y la vinculación con otros modelos, sin la necesidad de modificaciones
sustanciales.
Como características adicionales, se acentúa la robustez y la generalidad
incluyendo mecanismos de pre-proceso que garantizan la correcta ejecución del método,
reduciendo las exigencias y restricciones impuestas al usuario en cuanto a la definición
de parámetros de simulación. Así también, con la adaptabilidad como premisa, se reduce
al mínimo la información a proporcionar como datos de entrada, a los fines de admitir la
construcción de simulaciones con independencia respecto de las características de los
mismos. Igualmente, se permite desestructurar los datos de salida dando mutabilidad
para generar visualizaciones, pos-procesamientos, nuevas iteraciones, etcétera. En
cuanto al desempeño, se prioriza la reducción de tiempos de ejecución implementando
técnicas de Computación de Alto Desempeño (HPC) y aprovechando las posibilidades de
ejecución en paralelo.
Capítulo I: Notas Introductorias
6
I.6. ORGANIZACIÓN DE TESIS
Teniendo en cuenta el contexto en el que se sitúa el presente trabajo y estando su
objetivo definido en las líneas precedentes, se da paso a exponer de manera resumida la
disposición y la relación que existe entre los temas que se tratarán a continuación.
Luego de este breve título introductorio necesario para ambientar al lector en la
materia, se da lugar a un capítulo de contenidos netamente teóricos que brindan nociones
conceptuales para los desarrollos subsiguientes. Inicialmente, en el Capítulo II se
exponen conceptos sobre los paradigmas de programación, dando definiciones generales
acerca de la estructuración de un paradigma. Luego, se presenta el paradigma de
programación procedural como una alternativa a la OOP, analizando sus ventajas y
desventajas respecto de la implementación de códigos de co-simulación. Además, se
presentan, los paradigmas orientados a aspectos y a componentes, su relación con la OOP
y la programación multi-paradigma. A continuación, se encara el paradigma orientado a
objetos en su totalidad, describiendo su estilo de diseño, análisis y programación.
Finalmente, se trata el UVLM como modelo aerodinámico y marco de simulación
numérica para dar contexto a la implementación.
Establecidas las nociones teóricas generales, se da paso a la implementación
propiamente dicha. En el Capítulo III se encuentran las características propias del
desarrollo de la aplicación, iniciando con una breve reseña del lenguaje utilizado.
Seguidamente, se analiza la implementación de cada uno de los elementos del paradigma
orientado a objetos en el caso particular del UVLM. Finalmente, se exponen algunas
particularidades de la implementación que son innovadoras respecto de los softwares
tradicionales.
El Capítulo IV se dedica a la validación del código y a la obtención de algunos
resultados a partir de éste. Aquí, se informa sobre las simulaciones de cuatro casos
puntuales pensados para poner a prueba la mayoría de los aspectos implementados. En
esta etapa, se analiza la coherencia física de los resultados y se comparan éstos con los
obtenidos con otras implementaciones.
El capítulo final de este trabajo se dedica al análisis reflexivo del material. El
Capítulo V se desdobla entre tres tópicos principales con una marcada influencia de lo
expuesto en las primeras secciones de éstas notas introductorias. Observaciones sobre el
grado de cumplimiento del objetivo planteado, recomendaciones basadas en las
experiencias intrínsecas del desarrollo del trabajo y propuestas de mejoras y opciones
para trabajos futuros, se incluyen como comentarios finales.
Luego de los cinco capítulos de desarrollo de material, se adiciona un Anexo que
complementa los temas tratados, en el cual se detalla la estructura interna del código
dividida en tres secciones. La primera sección del Anexo hace referencia a las clases
definidas, indica sus atributos y procedimientos, y presenta las variables utilizadas por
éstos últimos con sus características particulares. La segunda sección contiene un listado
de los módulos que componen el código con una breve descripción del contenido de cada
uno. Por último, la parte final refiere a las funciones externas, entendidas como funciones
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
7
auxiliares que son recurrentemente utilizadas dentro del código y no se encuentran
asociadas a ningún módulo en particular.
9
Capítulo II: MARCO TEÓRICO
II.1. PARADIGMAS DE PROGRAMACIÓN
Thomas Kuhn en su obra “La estructura de las revoluciones científicas” [4]
describe un paradigma como un conjunto de teorías, estándares y métodos, que juntos
representan un medio de organización del conocimiento, es decir, un medio para
visualizar el mundo. En el ámbito de la programación, esta descripción hace referencia a
la concepción sobre la computación, sobre qué significa realizar computación y cómo se
estructura la información dentro del computador.
En general, la ingeniería entorno a la resolución de un problema específico se
nutre de diferentes metodologías que guían la construcción de la solución, en base tanto
a las especificaciones del problema como al analista. En este sentido, el desarrollo de
software no es una excepción ya que, entendida como una actividad ingenieril, confronta
al desarrollador con los parámetros del problema y le exige construir una solución. Todo
este proceso se da bajo un ordenamiento conceptual que proporciona control y asegura
ciertos resultados. Así, Peter Van Roy [5] expresa que resolver un problema de
programación requiere escoger los conceptos adecuados y que, incluso los problemas
más sencillos, pueden requerir distintos conceptos para diferentes etapas.
En particular, la implementación computacional de un modelo fluido-dinámico, al
igual que con cualquier modelo físico de simulación, está sujeta a un proceso de
construcción de la solución para un problema específico. Por lo tanto, requiere
exhaustivas etapas de análisis y diseño, previas a la implementación propiamente dicha.
Aquí intervienen diversos niveles de abstracción que se concatenan progresivamente
desde el fenómeno físico que se pretende representar hasta el software desarrollado
como herramienta de simulación. Este proceso define lo que se conoce como Paradigma
de Programación. Es decir, representa un enfoque particular que define los conceptos, los
sistemas de abstracción y los procedimientos que integran la solución del problema en
análisis, en el marco del desarrollo computacional. Según Van Roy [5] un paradigma de
programación es un método para programar una computadora basado en una teoría
matemática o en un set coherente de principios, que soporta una serie de conceptos que
lo hace apropiado para un determinado tipo de problema.
La selección de un paradigma que enmarque un desarrollo de software implica
desvincular la implementación de sus atributos computacionales. Esto es, retroceder
hasta el origen del problema para reestructurar su concepción con métodos alternativos
Capítulo II: Marco Teórico
10
que sean más ventajosos, incluso antes de considerar un lenguaje o una plataforma para
la implementación.
Un diagrama representativo de estos conceptos se muestra en la Figura II.1. En el
ámbito de la multi-física, el problema se origina en un fenómeno físico complejo y
multidisciplinario que se desea simular. A partir de un análisis detallado, se divide el
fenómeno de acuerdo a las disciplinas involucradas y se seleccionan modelos propios de
cada una de ellas. Los modelos aplicados a cada una de las áreas de la física deben ser
apropiados tanto para la representación del problema como para relacionarse entre sí.
Luego, con cada uno de estos modelos se diseña un esquema de simulación específico
para la porción del fenómeno que analizan. El conjunto de estos esquemas y las
interacciones entre ellos se denomina co-simulación.
Figura II.1: Paradigma de programación, análisis y diseño.
Cada paso de abstracción que se transita genera conceptos, parámetros y procesos
que deben interpretarse en el contexto en el que se desarrolla la implementación. Es
decir, no debe perderse de vista el alcance que se desea obtener y el entorno en el que
este alcance se efectiviza.
En términos generales, se puede concebir un software como la combinación de
dos partes: una estructura de datos y un algoritmo que opera sobre ésta. El paradigma
adoptado para el desarrollo guarda una estrecha relación con ambas, determina cómo se
construye cada una y cómo se vinculan entre sí. Evidentemente el contexto y la
funcionalidad del código en desarrollo definen la factibilidad de adoptar un determinado
paradigma, al igual que el lenguaje de programación a utilizar. Mientras que la aceptación
Fenómeno Físico
Modelo Físico
1
Modelo Físico
2
Modelo Físico
'...'
Modelo Físico
'n'
Multi-física
Simulación
2
Simulación
'...'
Simulación
'n'
Simulación
1
Co-Simulación
Conceptos
Procesos
Parámetros
Entorno
Alcance
ESTRUCTURA DE DATOS + ALGORITMO
IMPLEMENTACIÓN
An
ális
is y
Dis
eñ
o
PA
RA
DIG
MA
DE
PR
OG
RA
MA
CIÓ
N
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
11
y el uso dentro de la comunidad de investigación también resultan influyentes. De ahí la
importancia de adoptar un paradigma para estructurar y unificar los desarrollos.
II.1.1. CLASIFICACIÓN DE PARADIGMAS Existen diversos paradigmas que han surgido y mutado en función de los
cambiantes requerimientos en el desarrollo de software. Por lo tanto, la bibliografía
especializada suele ser difusa a la hora de establecer los límites de cada uno de ellos. No
obstante, y en vista del alcance del presente trabajo, los paradigmas pueden clasificarse
en dos grandes grupos. Por un lado, aquellos relacionados con la programación
imperativa y, por otro, los relacionados con la programación declarativa.
La programación imperativa se concibe de forma elemental debido a que casi la
totalidad de las implementaciones de hardware son imperativas. Cualquier unidad
procesadora se diseña para la ejecución de un lenguaje nativo que, en principio, se escribe
bajo un paradigma imperativo. En este sentido, las acciones de asignar estado a lugares
de memoria y modificarlos con instrucciones sencillas de hardware es la versión más
básica de la programación imperativa. Naturalmente, los lenguajes de alto nivel
modernos que soportan estos estilos manejan instrucciones complejas y pre-procesadas
que trabajan sobre variables con diversas características, además de contar con la
asistencia de un sistema de interpretación o compilación.
En su primer nivel de abstracción, la programación imperativa consiste en definir
el estado del programa y ejecutar sentencias que progresivamente modifican dicho
estado para alcanzar la solución buscada. En otras palabras, la programación imperativa
establece cuidadosamente cómo se desarrolla una tarea específica y conduce al programa
a través de las instrucciones necesarias para completar dicha tarea.
Por su parte, los paradigmas declarativos suelen definirse por contraste respecto
a los imperativos. Sin embargo, cuentan con una estructura propia que los vuelve
atractivos para muchas aplicaciones, como por ejemplo el manejo de base de datos y el
diseño de programas paralelos.
La programación declarativa se basa en definir condiciones que describen el
problema y la búsqueda de la solución se realiza a través de mecanismos de control. No
es central definir cómo realizar una tarea sino detallar minuciosamente qué tarea se
quiere ejecutar y dar paso a mecanismos de inferencia de información a partir de la
misma. Estos paradigmas se estructuran en un nivel elevado donde se pretenden eliminar
los efectos de describir los flujos de control.
La clasificación precedente puede parecer imprecisa, pero constituye la base para
identificar y categorizar un paradigma. La programación científica en ingeniería es en
buena parte imperativa (al menos de manera conceptual), y es dentro de este grupo que
se encuentran los paradigmas que constituyen opciones factibles a la hora de la
implementación computacional de modelos multi-físicos. El ejemplo más ampliamente
difundido (o el más naturalizado) de programación imperativa es, probablemente, el
Paradigma por Procedimientos. Este paradigma se deriva o incluye dentro del paradigma
de programación estructurada y resulta dificultoso describir uno sin el otro.
Capítulo II: Marco Teórico
12
II.2. PARADIGMA POR PROCEDIMIENTOS
El Paradigma de Programación por Procedimientos (o procedimental) centra su
sistema de abstracción en los métodos. En este caso, el problema debe analizarse de
manera tal que sea descrito como un conjunto de procedimientos que puedan refinarse
sucesivamente. Luego, en una etapa de diseño se identifican estos procedimientos,
agrupándolos con criterios comunes e individualizando aquellos que sean recurrentes.
De este modo, se concibe un esquema que se estructura en los métodos y define
relaciones entre ellos.
En otras palabras, el Paradigma por Procedimientos se caracteriza por estructurar
el código en bloques (o procedimientos) reutilizables, a los que puede recurrirse de
manera arbitraria durante la ejecución. Por lo tanto, el proceso de diseño de código por
procedimientos se basa en identificar secuencias de instrucciones concretas que puedan
aislarse y estructurarse para ejecutarse cada vez que sean necesarias. Luego, se definen
entornos locales para cada procedimiento que se vinculan, a través de un punto de
entrada y un punto de salida, con el entorno principal. Durante la ejecución de cada
procedimiento las variables (o estados) del programa se modifican con una finalidad
específica en función de los datos disponibles en el punto de entrada. Esquemáticamente,
la Figura II.2 muestra cómo un flujo de ejecuciones se dispersa entre los distintos
procedimientos para llevar el estado del programa a la solución.
Figura II.2: Flujo de ejecuciones en el paradigma por procedimientos.
En cuanto a la estructura de datos, el paradigma procedimental posee dos estratos
bien definidos. Por un lado, las estructuras que son locales a cada procedimiento, que
existen dentro de ellos y son transparentes al resto de la implementación. Estos datos
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
13
suelen considerarse auxiliares, ya que pueden crearse, modificarse y/o eliminarse en el
entorno del procedimiento sin alterar el estado general del programa.
El segundo estrato es la estructura de datos global, la cual se encuentra por encima
de la primera y es común a todos los procedimientos. Los estados globales pueden ser
alterados por cualquier procedimiento y dicha alteración debe propagarse
apropiadamente a todo el programa. Por lo tanto, en general suelen guardarse recaudos
respecto de los permisos de modificación de estos estados, ya que alteraciones
inapropiadas pueden tener consecuencias en toda la estructura.
II.2.1. VENTAJAS Y DESVENTAJAS DE LA PROGRAMACIÓN POR
PROCEDIMIENTOS El paradigma procedimental ha demostrado cumplimentar las exigencias de los
desarrolladores por décadas y su principal ventaja es la proximidad conceptual a los
lenguajes nativos de los procesadores. Esto permite al desarrollador reducir el nivel de
abstracción de su programa, facilitando la eficiente administración de los recursos
computacionales. Además, esta característica popularizó el estilo procedimental al punto
que cualquier incursión en la computación se inicia a través de este paradigma. Asimismo,
la gran difusión de la programación por procedimientos la convirtió en la alternativa más
intuitiva y, en muchos casos, la única considerada para muchas aplicaciones.
Sin embargo, existen ciertos aspectos del desarrollo de software que la
programación procedimental está lejos de resolver, especialmente a medida que la
complejidad de las implementaciones crece. El principal inconveniente lo constituye la
etapa de análisis donde se establecen los niveles de abstracción. Aquí, pasar de un
problema real a las especificaciones computacionales puede ser intrincado: en general
los procedimientos que componen el problema real no son apropiados para la
implementación y deben reestructurarse; además, por supuesto, deben crearse nuevos
procedimientos auxiliares. Esta transición genera que los diseños aplicables a un
problema específico tengan naturalezas disímiles, dependiendo del criterio del
desarrollador. A su vez, la dificultad para concebir abstracciones como procedimientos
puede desembocar en diseños incompletos o ineficientes, obligando a retroceder en el
desarrollo y rever la estructura general de la aplicación.
Luis J. Aguilar [6] expone otras desventajas de la Programación por
Procedimientos. Hace referencia a la cantidad de recursos que se consumen en propagar
una modificación de estado a través de todos los procedimientos involucrados, la
criticidad del medio en el que se almacenan dichos estados y las limitaciones en la
intercambiabilidad de código dentro del grupo de desarrollo. En resumen, la
Programación por Procedimientos permite optimizar el desarrollo de procedimientos (o
algoritmos) pero presenta significativas debilidades a la hora de construir estructuras de
datos.
Las desventajas citadas por Aguilar se relacionan directamente con la dificultad a
la hora de confeccionar una estructura de datos bajo el paradigma procedimental. Cuando
un procedimiento modifica estados globales, éstos deben transmitirse a toda la aplicación
Capítulo II: Marco Teórico
14
teniendo en cuenta que otros procedimientos pueden hacer uso o incluso modificar estos
estados simultáneamente. Así, cada actualización debe recorrer toda la red de
comunicaciones entre procedimientos y adecuarse localmente a cada uno de ellos. Esto
incrementa la criticidad del medio donde se almacenan los datos: debe ser lo
suficientemente robusto como para conservar la estabilidad y permitir flexibilizaciones
de acuerdo a los requerimientos de los procedimientos.
El impacto de lo anterior en la intercambiabilidad de código no es menor. Cada
integrante del grupo de desarrollo debe tener presente la estructura global de datos y
considerar cualquier modificación que sus procedimientos, o los de otros, hagan sobre
ésta. Las incompatibilidades que puedan surgir aquí implicarán una gran pérdida de
tiempo en reescritura.
II.3. OTROS PARADIGMAS
Los paradigmas de programación que actualmente se utilizan son numerosos. En
su trabajo, Van Roy [5] enumera alrededor de treinta. Además, existen versiones mixtas
que han probado ser eficientes y, a medida que la arquitectura de software avanza como
disciplina, surgen algunas nuevas. Es por esto que incluso hacer un recorrido general a
través de los paradigmas existentes resultaría muy extenso y definitivamente excede el
enfoque de este trabajo. A pesar de esto, existen dos paradigmas modernos (en contraste
con aquellos aplicados tradicionalmente) que revisten interés para los temas en
tratamiento. Luego, se presentan breves reseñas sobre sus características con el objetivo
de difundirlos como alternativas.
II.3.1. PARADIGMA DE PROGRAMACIÓN ORIENTADA A
COMPONENTES El paradigma de programación orientada a componentes (COP) se caracteriza
principalmente por concebir a los programas como una construcción de componentes de
software ya desarrollados. Por lo tanto, los sistemas de abstracción deben priorizar las
interfaces y conexiones entre dichos componentes. El objetivo final es generar una serie
de componentes vinculados que sean reutilizables independientemente del contexto. A.
J. A. Wang y K. Qian [7] expresan que los componentes de la COP deben poder ser usados
“como sea” y “donde sea”. Luego, definen este paradigma como basado en las interfaces y
la composición.
El paradigma de COP cobra importancia principalmente debido a dos aspectos,
por un lado, su nivel de abstracción que es superior a la mayoría de los paradigmas
tradicionales y, por otro, por la capacidad de generar componentes reutilizables. Estos
aspectos sirven al objetivo principal de la COP que busca administrar la mutabilidad de
las aplicaciones a partir de la reutilización. En relación a esto, Wang y Qian [7] sostienen
que la COD proporciona un método eficiente para seguir el principio de la ingeniería de
software de lidiar con el cambio, esto es, planificar, diseñar y construir para el cambio.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
15
Para comprender el nivel de abstracción de la COP debe definirse qué se entiende
por componente. En este sentido, la bibliografía especializada suele alterar detalles sobre
las propiedades que deben exigirse a un componente, sin embargo, se acepta una
definición más o menos general: un componente es una porción de código auto contenida,
auto ejecutable, con una funcionalidad bien definida y que puede ser ensamblada con
otros a través de su interface. Luego, la principal característica que emerge de esta
definición es la capacidad de un componente de ser compilado y ejecutado sin necesidad
de vincularse con otros.
El concepto de reutilización en el paradigma orientado a componentes difiere de
aquél citado en el paradigma por procedimientos o en la OOP. En este caso, la reutilización
adquiere su nivel más alto y abarca los tipos que Wang y Qian [7] definen como “caja
blanca”, “caja gris” y “caja negra”. Esta clasificación de la reutilización hace referencia a
qué tan accesible es el contenido de cada componente. Es decir, un componente “caja
blanca” puede ser estudiado, adaptado y modificado, un componente “caja negra” se basa
en el ocultamiento de información y es inaccesible luego de confeccionado, mientras que
un componente “caja gris” se posiciona entre los anteriores. No debe perderse de vista
que la reutilización debe trascender el contexto de la aplicación y cada componente
reutilizable debe ser un bloque autónomo de programa.
Una particularidad adicional del paradigma de la COP es su estrecha relación con
la OOP. Si bien el paradigma orientado a objetos se tratará con detalle en la sección
siguiente, puede adelantarse que los conceptos implicados no son muy diferentes a los
expuestos aquí. En definitiva, la COP puede pensarse como el siguiente nivel de
abstracción de la OOP, donde los principios de análisis y diseño han sido intensificados.
El paradigma orientado a componentes refiere al empaquetado y la distribución de
código, con bloques de grano grueso que soportan diversas interfaces, son autónomos e
independientes del contexto. Mientras que la OOP sigue estos principios de manera más
sutil.
II.3.2. PARADIGMA DE PROGRAMACIÓN ORIENTADA A
ASPECTOS El paradigma de programación orientada a aspectos (AOP) tiene por finalidad
elevar la eficiencia en la modularización de las aplicaciones a partir de la separación de
conceptos. El eje principal del diseño es eliminar la dispersión de código (conocido como
“scattered code”) aislando las incumbencias transversales. Luego, la abstracción se centra
en los conceptos diseminados en el código que atraviesan partes del sistema no
relacionadas en el modelo original.
Se entiende por aspecto a una funcionalidad común que se define en términos de
información parcial de otras unidades funcionales. Esto es, un aspecto engloba las
cuestiones a resolver que no están vinculadas con un problema u objetivo en particular,
sino que se diseminan por toda la aplicación y afectan gran parte de ella. Los patrones de
acceso a memoria, la sincronización de procesos concurrentes, las comunicaciones entre
procesos, el manejo de errores y excepciones, son algunos ejemplos de funcionalidades
que comúnmente integran las aplicaciones y se definen como aspectos bajo este
Capítulo II: Marco Teórico
16
paradigma. Adicionalmente, estas funcionalidades cruzan a lo largo de la aplicación y es
deseable implementarlas de forma modular y separada del resto del sistema. Esto se debe
a que, como expone Moreno Nieto [8], los aspectos no suelen ser unidades funcionales
que obtengamos al descomponer el sistema, sino más bien, propiedades que afectan el
rendimiento o el comportamiento de los componentes.
El modelo orientado a aspectos generalmente se construye por encima del modelo
básico. Ambos modelos se vinculan a través de un “tejedor” que funciona como interface
de demanda para la ejecución de los aspectos. Esta estructura permite utilizar diversos
diseños para el modelo de base, mientras que se hace hincapié en el modelo de aspectos
utilizando lenguajes, formatos y diseños especializados. Así, el paradigma de AOP puede
combinarse con otros diseños, como de OOP, por ejemplo, lo que reviste de interés para
los tratamientos del presente trabajo.
II.4. PARADIGMA DE PROGRAMACIÓN ORIENTADA A
OBJETOS
El concepto de OOP fue formalmente introducido en la década de 1960 a partir de
estudios realizados en el Centro Noruego de Cómputos por O. J. Dahl y K. Nygaard.
Conceptualmente, G. Booch [9] define la OOP como: “un método de implementación en el
que los programas se organizan como colecciones cooperativas de objetos, cada uno de
los cuales representan una instancia de alguna clase, y cuyas clases son todas miembros
de una jerarquía de clases unidas mediante relaciones de herencia”.
La bibliografía dedicada a exponer y analizar los conceptos acerca de la OOP suele
agruparse en dos extremos diametralmente opuestos. Por un lado, se tienen obras sobre
arquitectura de software que son sumamente especializadas y exceden el alcance del
presente trabajo. Por otro, aquellas que abordan los conceptos con ejemplos imprácticos
que dan nociones generales y simplificadas, pero detienen el estudio considerablemente
antes de enfocarse en la aplicación. Por ende, aquí se explora un tratamiento intermedio
que brinda nociones teóricas básicas, suficientes para los objetivos de éste trabajo, para
luego dar paso a la efectivización del paradigma con la implementación del UVLM.
Desarrollar una implementación dentro del Paradigma de la Programación
Orientada a Objetos requiere entender los mecanismos de modelado, diseño y análisis
que lo componen. Sin embargo, el paradigma procedimental lideró por décadas la
programación científica, y desterrar sus premisas y convenciones para reestructurar el
desarrollo de software de investigación no es tarea fácil. Luego, en esta sección se
propone un tratamiento que parte de exponer los principales desafíos a la hora de
desarrollar software y cómo la OOP proporciona soluciones apropiadas para lidiar con
ellos.
II.4.1. EL SOFTWARE COMO SISTEMA COMPLEJO Ciertamente, determinadas aplicaciones pueden considerarse como sistemas
simples, pero en general no revisten el interés y la aplicabilidad suficientes para satisfacer
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
17
necesidades reales dentro del campo de la co-simulación. Aquellas aplicaciones que sí
constituyen herramientas funcionales de investigación se caracterizan como sistemas
complejos que presentan desafíos en todos los niveles de su desarrollo. Además, suelen
diseñarse con objetivos a largo plazo por lo que requieren actualizaciones,
mantenimiento y la participación de un grupo de trabajo. Luego, es preciso comprender
que, a partir del análisis de la complejidad de un sistema, pueden emerger mecanismos
para manejarla de manera eficiente.
En un intento de introducir el concepto de complejidad F. Brooks [10] señala que
“la complejidad de un software es una propiedad esencial de éste y no una accidental”.
Del mismo modo, Booch [9] respalda esta afirmación indicando que la complejidad en las
implementaciones computacionales cuenta con cuatro fuentes bien definidas: el dominio
del problema, la gestión del proceso de desarrollo, la flexibilidad del software y el
comportamiento de los sistemas discretos.
Por dominio del problema se entiende al conjunto de aspectos, conceptos y
funcionalidades lo definen. Estos elementos normalmente cuentan con una gran cantidad
de requisitos que pueden ser contradictorios e incluso mutar durante el desarrollo. Esto
se debe a que se pueden tener diversas perspectivas respecto de la naturaleza del
problema y realizar diferentes suposiciones respecto de su solución.
Por su parte, la gestión del proceso de desarrollo representa una solución de
compromiso entre la cantidad de trabajo, la cantidad de personas involucradas y la
factibilidad del software. En este sentido, a medida que el proyecto crece, el volumen de
trabajo necesariamente debe dividirse entre distintos desarrolladores y, a su vez, el
crecimiento del equipo de trabajo dificulta la coordinación, incluso al punto de volver
inviable al proyecto.
Por otro lado, la flexibilidad de un software en desarrollo es virtualmente
ilimitada. Los niveles de abstracción pueden concatenarse en diversos tipos y construir
una red cada vez más extensa y especializada. No obstante, la materialización de una
implementación requiere que se fijen ciertos límites para construir un marco en el que la
solución esperada sea realizable.
Finalmente, debido a su naturaleza, los sistemas discretos cuentan con un número
finito de estados posibles. Sin embargo, este número se incrementa conforme el sistema
crece, lo que determina una explosión combinatoria de estados posibles. Por otro lado,
cualquier evento externo al software posee el potencial para alterar cualquiera de estos
estados, generando anomalías, en principio, impredecibles. Luego, caracterizar todas las
posibles relaciones entre eventos y estados representa una tarea inherentemente
compleja.
Considerando las distintas fuentes de complejidad de un software, existen algunos
atributos que son comunes a todos los sistemas complejos y sobre los cuales puede
trabajarse para dominar dicha complejidad. Estos atributos se exponen a continuación.
ESTRUCTURA JERÁRQUICA
Todo sistema complejo se compone de subsistemas que son a su vez complejos en
sí mismos. Sin embargo, a medida que la subdivisión se realiza repetidamente la
Capítulo II: Marco Teórico
18
complejidad de las partes disminuye y esta relación se extiende hasta que se alcanza el
nivel de componentes más elementales. Luego, es posible subdividir sucesivamente un
sistema complejo hasta concebir un subsistema con un nivel de complejidad manejable
para el desarrollo.
ORGANIZACIÓN RELATIVA
Organizar los distintos componentes de un sistema según su nivel de abstracción
no resulta unívoco. Definir qué componentes de un sistema ocupan un nivel determinado
de abstracción, cuáles se encuentran por encima de éstos y cuáles por debajo, depende
fuertemente de los criterios y decisiones del analista, y múltiples estructuraciones
pueden coexistir.
CLASIFICACIÓN DE ASPECTOS
Cada componente de un sistema posee aspectos que pueden clasificarse en inter-
componentes e intra-componentes. De este modo, un componente puede analizarse bajo
un cierto grado de aislamiento para el estudio de sus aspectos intra-componentes,
independientemente de los vínculos que tenga con otros. Más adelante, el objeto de
estudio puede centrarse en estos vínculos para completar el análisis del sistema.
PATRONES COMUNES
Los componentes más elementales de un sistema usualmente son de algunas
pocas variedades distintas que se combinan de diferentes maneras para generar
estructuras complejas. Estos elementos constituyen patrones que se repiten a lo largo del
sistema y permiten estructurar el análisis alrededor de ellos.
ESTADOS INTERMEDIOS ESTABLES
Un sistema que evoluciona con el tiempo puede concebirse como una sucesión de
fases estables unidas por períodos de transición entre ellas. Así, ante cualquier
eventualidad que interrumpa el proceso de evolución, el sistema puede reestablecerse a
partir del último estado estable alcanzado.
II.4.2. EL MODELO DE SOFTWARE La construcción de modelos es una práctica habitual en todas las áreas de
investigación ingenieril y el desarrollo de software de simulación no es la excepción.
Implementar un modelo de desarrollo de sistemas complejos cuenta con varios enfoques
y es dificultoso, cuando no imposible, definir uno que sea absolutamente apropiado para
una aplicación. No obstante, habiendo caracterizado las fuentes y atributos de un sistema
complejo, esta tarea puede intentarse.
Un modelo de desarrollo se evalúa según la calidad del producto que proporciona
luego de ser implementado. En primera aproximación esto puede sonar contradictorio
puesto que los mecanismos de evaluación que se aplican a un software no son
compatibles para la evaluación de un modelo de desarrollo. Sin embargo, la aceptación
de un modelo se basa en cuánto énfasis pone en ciertos aspectos que potencian las
características positivas de la implementación computacional. Tampoco existe un
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
19
consenso universal sobre qué características de un código son más importantes, pero si
se pueden mencionar las siguientes como las más difundidas:
Eficiencia: optimización del uso de recursos.
Portabilidad: capacidad del software de mudar a diferentes sistemas físicos
o lógicos.
Verificabilidad: capacidad de soportar los procedimientos de validación.
Utilización: facilidad con la que el software se comunica con el usuario.
Robustez: capacidad de funcionar incluso ante situaciones anormales.
Extensibilidad: posibilidad de adaptarse a cambios en sus especificaciones.
Reutilización: posibilidad de incorporarse en su totalidad o en parte en
otras aplicaciones.
Compatibilidad: disponibilidad para combinarse con otros códigos.
Naturalmente, la posibilidad de afianzar todas las características precedentes en
una implementación está fuertemente ligada al contexto general de la aplicación que se
desarrolla. Por lo tanto, adoptar un modelo de desarrollo se reduce a la solución de
compromiso que mejor se adapte a la necesidad del grupo de trabajo.
II.4.3. ORIENTACIÓN A OBJETOS Luego de entender al software como un sistema complejo desde muchos enfoques
y teniendo presentes las características listadas en la sección anterior, resulta evidente
que no es apropiado encaminar la implementación de una aplicación a la ligera. En este
punto, surge la orientación a objetos no sólo como una alternativa viable sino también
como una muy atractiva para el desarrollo de software.
La orientación a objetos constituye una metodología alternativa no sólo para el
diseño y análisis de aplicaciones sino también para su concepción más elemental, que
pretende superar los obstáculos del desarrollo de software. En este sentido, Aguilar [6]
postula que la orientación a objetos puede describirse como el conjunto de disciplinas
que desarrollan y modelan software, facilitando la construcción de sistemas complejos a
partir de sus componentes.
El atractivo más elemental de la orientación a objetos es, entonces, tratar al
sistema desde sus componentes incluso antes de centrar la atención en la
implementación computacional. Esto quiere decir que los conceptos y mecanismos de
modelado buscan representar el fenómeno real, tan fielmente como sea posible, en el
código. De este modo, la orientación a objetos reduce al mínimo los recursos orientados
a transformar los requisitos definidos en términos del usuario en las especificaciones del
sistema definidas en términos del computador, lo que normalmente se conoce como
Transformación de Von Neumann. Adicionalmente, este enfoque permite manipular
distintas escalas de sistemas, haciendo el código más tangible y manejable,
proporcionando flexibilidad y mantenibilidad.
II.4.4. EL MODELO ORIENTADO A OBJETOS El modelo orientado a objetos es un término que colectivamente refiere a todas
las tecnologías y principios que conforman el Paradigma de la Programación Orientada a
Capítulo II: Marco Teórico
20
Objetos. Dentro de éste, la OOP constituye la etapa dedicada específicamente a la
escritura de código y, en general, está fuertemente vinculada al lenguaje de programación
con el que se trabaja.
Booch [9] indica que el modelo orientado a objetos es evolucionario más que
revolucionario debido a que no rompe con otros avances, sino que se construye sobre
aquellos que han sido probados. Un modelo orientado a objetos se centra en unificar las
ideas de algoritmo y estructura de datos, dando énfasis a la caracterización de los
componentes del sistema físico que luego serán representados con el sistema
computacional. Así, cuenta con un atractivo general basado en la posibilidad de gestionar
los distintos niveles de complejidad inherentes a muchos sistemas.
Como indica el esquema de la Figura II.3, dentro del Paradigma de la Programación
Orientada a Objetos, el modelo orientado a objetos cuenta con cuatro partes
fundamentales que merecen estudiarse por separado: elementos, análisis, diseño y
programación. Las tres últimas se suceden en el proceso de desarrollo de una aplicación
orientada a objetos y se retroalimentan cíclicamente a partir de una etapa de revisión,
mientras que los elementos imponen conceptos generales.
La exposición de cada una de las partes del modelo orientado a objetos puede
encararse desde dos enfoques, por un lado, desde el tratamiento conceptual que recorre
los principios y fundamentos teóricos y, por otro, desde el punto de vista de la
implementación de un caso particular de simulación. A continuación, se propone el
primero de los enfoques para luego dar lugar al tratamiento desde la implementación
computacional del UVLM.
Figura II.3: El modelo orientado a objetos.
II.4.5. ELEMENTOS DEL MODELO ORIENTADO A OBJETOS Cada modelo requiere un marco conceptual con ciertas directivas que regulan los
procesos y metodologías que se aplican a lo largo del desarrollo. Estas directivas se
condensan en elementos que se describen de manera precisa.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
21
En el caso del modelo orientado a objetos los elementos fundamentales que, según
Booch [9], son indispensables para poder definir un modelo como tal son los siguientes:
ABSTRACCIÓN La abstracción se entiende como el proceso de enfrentarse a la complejidad
inherente de un sistema. Se centra en la representación de las características externas de
cada entidad del sistema para describirlo desde sus propiedades y comportamiento,
independientemente del punto de vista de la implementación. Este proceso se relaciona
íntimamente con el concepto de descomposición, al punto que para entender cualquier
nivel de un sistema es necesario estudiar algunas partes de éste por separado. Luego, la
abstracción implica una descomposición inteligente.
Determinar qué son las entidades que pueden abstraerse de un sistema, cuáles son
sus propiedades y funciones, cómo se relacionan entre sí, y cuándo es necesario construir
nuevas y eliminar antiguas, no son decisiones unívocas. Por tanto, construir un sistema
abstracto a partir de un sistema físico puede tomar varios caminos y sólo la experiencia
y astucia de los desarrolladores determinará cuál es el más apropiado para la aplicación
en cuestión. Al respecto, Seidewitz y Stark [11] expresan que “existe un espectro de
abstracción que va desde objetos que representan cercanamente entidades del dominio
del problema a objetos que no tienen motivos para su existencia”.
Como resultado, el proceso de abstracción construye una imagen conceptual del
modelo físico compuesta por entidades, o abstracciones, que se condicen con el
vocabulario, el uso o la funcionalidad del mismo. Este nuevo modelo abstracto es el punto
de partida para el diseño de la implementación, el que se discutirá más adelante.
ENCAPSULACIÓN La encapsulación representa quizás uno de los aspectos menos tangibles del
modelo orientado a objetos, pero es, en términos de la implementación, uno de los más
importantes. También conocida como “ocultamiento de información”, la encapsulación es
la inclusión de todos los recursos que necesita una abstracción para su realización dentro
de sí misma.
En otras palabras, la encapsulación discrimina los aspectos inter-componentes de
los aspectos intra-componentes de las entidades surgidas del proceso de abstracción. Así,
garantiza que estos recursos estén ocultos para el resto de las entidades y sean sólo
accesibles selectivamente a través de mecanismos de vinculación.
MODULARIDAD Por su parte, la modularidad es una consecuencia directa de la encapsulación. Esto
es, luego de definir entidades y encapsularlas apropiadamente, éstas pueden agruparse
en módulos de acuerdo a sus aspectos inter-componentes. El objetivo de los módulos es
simplificar el manejo de las abstracciones bajo conceptos comunes, aportando
fuertemente a la gestión de la complejidad del sistema.
Los criterios para la construcción de módulos pueden ser arbitrarios, sin embargo,
deberán servir a la simplificación del sistema. En general, la premisa es construir módulos
Capítulo II: Marco Teórico
22
cohesivos, es decir, que agrupen entidades lógicamente relacionadas, minimizando las
dependencias entre ellos.
JERARQUÍA La definición de entidades implícitamente construye un sistema jerárquico de
niveles de abstracción que responde a un orden lógico. Ordenar y asignar categorías a las
abstracciones dentro de la estructura del sistema genera una matriz jerárquica que
expone el funcionamiento del sistema. Luego, la jerarquía refiere a cómo se relacionan las
abstracciones entre sí.
II.4.6. ANÁLISIS ORIENTADO A OBJETOS El análisis orientado a objetos es el proceso destinado a interpretar el fenómeno
físico que se busca simular, desde el punto de vista de la orientación a objetos. El objetivo
principal es identificar las especificaciones del problema y clasificarlas según la influencia
potencial que tienen sobre la simulación.
Aguilar [6] asocia la etapa de análisis a la pregunta “¿Qué hace?” realizada a las
partes del sistema. Asimismo, indica que durante el análisis se piensa en las
especificaciones en términos intuitivos, con independencia del lenguaje y de la máquina.
II.4.7. DISEÑO ORIENTADO A OBJETOS Siguiendo el planteo de Aguilar [6], la etapa de diseño responde a la pregunta
“¿Cómo lo hace?”. Aquí, la intención es definir una estructura lógica del problema,
identificando las entidades involucradas, jerarquizando los niveles de abstracción y
definiendo las interacciones que los relacionan.
El diseño orientado a objetos debe representar las especificaciones provenientes
de la etapa de análisis con precisión, disgregando componentes en instancias más
sencillas y realizando asociaciones si fuera necesario. Dentro de lo posible, se deben
esclarecer, incorporar o eliminar conceptos complementando la etapa de análisis. En este
proceso, los métodos de descomposición basados en diferentes criterios son
preponderantes.
Como resultado del diseño se debe tener un mapa del fenómeno físico puesto en
términos de entidades y relaciones. Se da así un punto de partida y las directivas
generales para dar paso al proceso de programación, que culminará con la
implementación propiamente dicha.
PRINCIPIOS DE DISEÑO Existen distintas metodologías para alcanzar los objetivos planteados en la etapa
de diseño. La mayoría de ellas consideran la definición de entidades del sistema como
núcleo fundamental y brindan criterios para realizarla.
Los principios alrededor de los cuales se construyen las metodologías de diseño
son diversos y, usualmente, la bibliografía especializada expone variantes para
aplicaciones específicas. Sin embargo, en términos generales existen cinco principios que
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
23
tienen aplicación general y gran difusión. Estos principios responden al acrónimo
mnemotécnico “SOLID” por sus iniciales en inglés y se listan a continuación:
Principio de Responsabilidad Simple
Principio Abierto/Cerrado
Principio de Sustitución de Liskov
Principio de Segregación de Interface
Principio de Inversión de Dependencia
Exponer un análisis exhaustivo de los principios anteriores excede el alcance del
presente trabajo. Sin embargo, por tratarse de ser el utilizado en la implementación en
cuestión, se describe brevemente el Principio de Responsabilidad Simple (SRP).
El SRP es el más intuitivo de estos principios y, según él, se individualiza una
entidad en términos de las funciones que puedan modificarla. Esto es, cada
“responsabilidad” que una entidad posee es entendida como un procedimiento que puede
alterar su estado, o bien, una función que debe cumplir dentro del sistema. Luego, se
buscará que exista una única función (o responsabilidad) por entidad y, de no ser así,
deberán constituirse otras entidades adicionales.
II.4.8. PROGRAMACIÓN ORIENTADA A OBJETOS La programación es la parte del modelo con la que los desarrolladores suelen estar
más familiarizados. En este punto todas las etapas anteriores se reducen al nivel de la
plataforma computacional para finalmente materializarse en la implementación.
Evidentemente, el lenguaje de programación cobra un papel fundamental ya que será la
herramienta principal a la hora de construir la aplicación, y, por supuesto, debe soportar
las características de la OOP.
El principal desafío de la etapa de programación dentro del paradigma orientado
a objetos es no perder de vista el diseño construido previamente. Si bien la
retroalimentación es constante y el diseño puede flexibilizarse para ganar eficiencia, el
diseño debe guiar al programador y no a la inversa. Así, cada principio y cada concepto
deben incluirse en la programación para que la implementación esté acorde al modelo.
Es decir, todos los elementos del modelo (abstracción, encapsulación, modularidad y
jerarquía) se transforman en componentes o funcionalidades que deben programarse en
la implementación.
IMPLEMENTACIÓN DE LA ABSTRACCIÓN El proceso de abstracción transitado en la etapa de diseño define las entidades del
problema, sus funciones y las relaciones entre ellas. Desde el punto de vista de la
programación, la abstracción se implementa en la definición de clases y objetos.
Aguilar [6] define a las clases como la descripción de un conjunto de objetos. Sin
embargo, dentro de la programación se definen como tipos de datos, es decir, que
constituyen la estructura o la plantilla para construir un objeto. Cabe destacar aquí que,
si bien una clase por sí misma representa una abstracción, no es capaz de aportar a la
implementación sin que se generen instancias de ella. Luego, un objeto se define como la
Capítulo II: Marco Teórico
24
instancia de una clase, lo que puede interpretarse, en términos generales, de la siguiente
manera: la clase es el tipo de dato y el objeto es un dato particular de dicho tipo.
Específicamente, un objeto es una entidad que computacionalmente posee estado,
comportamiento e identidad. El estado hace referencia a los atributos o propiedades del
objeto que son definidas estáticamente y a los valores de dichos atributos que se
modifican dinámicamente. Por su parte, el comportamiento de un objeto engloba los
procedimientos que pueden modificar su estado, es decir, las funcionalidades que posee
y los métodos a los cuales puede someterse. Por último, la identidad de un objeto es la
característica que lo diferencia de otros, cada objeto es único e independiente de otros,
incluso dentro de la misma clase.
IMPLEMENTACIÓN DE ENCAPSULACIÓN Y MODULARIDAD La encapsulación está fuertemente relacionada con la creación de clases, y
garantiza que sus recursos estén ocultos para el resto de los objetos y sean sólo accesibles
a través de mecanismos de vinculación. En este aspecto se distingue la visión interna de
la visión externa de una clase.
En la práctica, la encapsulación se traduce en la definición de la interface de una
clase, aquí se establece cuáles atributos se mostrarán al resto de la aplicación y cuáles
quedarán restringidos dentro de la clase. En este sentido, la implementación de una clase
puede darse bajo cuatro niveles de encapsulación que definen cuán accesible es para
otras, estos son: pública, privada, protegida y modular. Una clase es pública cuando la
accesibilidad es ilimitada y su encapsulación es transparente para la aplicación. Por el
contrario, una clase privada no admite ningún tipo de acceso a su estructura, su
encapsulación es robusta y sólo ella misma puede alterar su estado. Los niveles restantes
son intermedios entre los anteriores, una clase protegida sólo es accesible por clases
derivadas o subclases de ésta, mientras que la encapsulación de una clase modular es
transparente sólo para las clases que integran el mismo módulo.
Por su parte, los módulos son unidades independientes en funcionalidad pero que
pueden vincularse, aunque esta relación es, como lo indica Aguilar, débil. Así, se consigue
una construcción progresiva del software que, junto con la encapsulación aplicada de
manera apropiada, optimiza los desarrollos en grupos de investigación.
Existe una fuerte relación entre los módulos y el lenguaje de programación a la
hora de implementarlos. Esta relación se traduce en la posibilidad de que el lenguaje
utilizado soporte la definición de módulos como tales, o si debe recurrirse a otro
mecanismo para la asociación de clases. En el primer caso, cada módulo se define como
una unidad que puede compilarse independientemente sin necesidad de definir a priori
sus relaciones con otras y, dentro de ésta, deberá efectivizarse la agrupación de clases
definida en el diseño. Mientras que, en el segundo caso, la modularidad deberá
construirse desde las interfaces, definiendo afinidades y sistemas de accesos prioritarios.
IMPLEMENTACIÓN DE JERARQUÍA El verdadero potencial del OOP se vuelve evidente cuando se analizan las
relaciones entre clases. En la implementación deben materializarse las relaciones y
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
25
asociaciones surgidas en la etapa de diseño para consolidar la estructura jerárquica de
las abstracciones. Estas relaciones pueden ser de diversa naturaleza, dependiendo de
cómo se diagrame la estructura del código. En general, las relaciones pueden clasificarse
en tres grupos: aquellas que refieren a la generalización/especialización (también
llamadas herencia), aquellas que refieren a la agregación (o de composición de objetos)
y las que refieren a la asociación.
Las relaciones de generalización/especialización se conocen como “Is-a”, por su
nombre en inglés, y vinculan subclases con superclases. Conceptualmente la relación de
herencia consiste en derivar una clase (la subclase) de otra (la superclase), con lo que la
primera “hereda” los atributos y procedimientos de la segunda. Adicionalmente, es
posible incluir nuevas características exclusivas en la clase derivada, para
individualizarla de la superclase. Dependiendo del sentido de análisis, este proceso puede
considerarse una generalización o una especialización y brinda un recurso poderoso para
simplificar la red de vínculos entre clases.
Las relaciones de agregación, también nombradas “Has-a”, tienen la función de
reducir la complejidad agrupando clases dentro de otras clases. En este caso, la relación
puede entenderse como del tipo todo/parte, aunque no implique una existencia
condicionada. Al nivel de objetos, esto quiere decir que puede definirse un objeto de una
clase que posea atributos que se definan en clases distintas, pero, pueden existir objetos
de las clases contenidas que no tengan dependencia con la clase continente.
Por último, la asociación es el tipo de relación más débil que puede presentarse.
Asociar clases implica una dependencia puramente semántica que se establece en la
etapa de diseño para fijar vinculaciones generales. A la hora de la implementación, las
asociaciones no tienen un impacto directo en la programación ya que suelen
transformarse en alguno de los otros tipos de relación presentados. Sin embargo, algunas
asociaciones pueden conservarse en la forma de permisos de acceso prioritarios entre
clases, procedimientos compartidos o conformación de módulos.
POLIMORFISMO Otra característica que ilustra el potencial de la OOP es el polimorfismo, aunque
desde algunos puntos de vista más ortodoxos no se considere fundamental. De acuerdo a
lo que intuitivamente se prevé, el polimorfismo refiere a la posibilidad de que una
entidad, una clase en este caso, tome diversas formas. En un sentido más específico, una
variable polimórfica es aquella cuyo tipo de dato puede variar en tiempo de ejecución.
La vinculación entre objetos y procedimientos definida en la construcción de
clases presenta numerosas ventajas que se mencionaron anteriormente. Sin embargo,
limitar un procedimiento exclusivamente a una clase puede no resultar siempre
conveniente, en especial desde el punto de vista de la economía de código. Esto es, tener
que programar repetidamente un procedimiento específico que ejecute tareas análogas
sobre dos o más clases rompe con la búsqueda de eficiencia del paradigma. Luego,
implementar el polimorfismo permite codificar un único procedimiento que sea
transparente a la clase sobre la que actúa y pueda ejecutarse correctamente en cualquier
caso.
Capítulo II: Marco Teórico
26
Evidentemente, la implementación del polimorfismo es una herramienta
poderosa, pero debe utilizarse con extremados recaudos ya que su influencia repercute
en tiempo de ejecución. Definir clases polimórficas y procedimientos que las soporten
requiere el entendimiento de la evolución de los estados de la aplicación por parte del
desarrollador debido a que cualquier incompatibilidad de tipo puede generar errores
significativos.
PROGRAMACIÓN GENÉRICA Una última consideración sobre la OOP debe hacerse sobre la Programación
Genérica. De acuerdo con M. Glasser [12], la OOP proporciona facilidades para separar los
aspectos de un software y tratar cada uno de manera independiente. En consecuencia, se
pretende que cada aspecto sea representado una única vez para evitar multiplicidad de
código. Sin embargo, también es deseable que cada representación pueda aplicarse a una
gran variedad de situaciones. Estas intenciones combinadas desembocan en la necesidad
de recurrir a la programación genérica que produce código general e intensamente
parametrizado que puede ser utilizado, sin mayores modificaciones, en numerosos
contextos. No obstante, estos recursos no deben ser accidentales sino un estilo afianzado
bajo el paradigma de la OOP.
En la práctica, definir variables polimórficas, crear protocolos de manejo de
errores, incluir excepciones dentro de los procedimientos, dar autonomía a módulos y
clases, clasificar adecuadamente los vínculos entre entidades, son algunos mecanismos
propios de la programación genérica. Intuitivamente se asocian los conceptos de
encapsulación, herencia y polimorfismo a este tipo de programación, considerándolos
como herramientas para lograrla. Luego, programar de manera genérica implica prever
situaciones y estados dinámicos que pueden presentarse en tiempo de ejecución, y
construir una estructura robusta que pueda adaptarse a ellos sin la necesidad de
codificarlos específicamente.
II.5. PROGRAMACIÓN MULTI-PARADIGMA
Desde el punto de vista de la abstracción teórica, cada paradigma tiene sus bases
y criterios bajo los cuales el diseño de un software puede encuadrarse. Sin embargo,
cuando se trata con la realización, los límites no son tan claros y las exigencias de cada
implementación pueden, para generar soluciones más adecuadas, desviar el desarrollo
del paradigma original. Así, múltiples paradigmas pueden solaparse dando lugar a lo que
se conoce como programación multi-paradigma.
La programación multi-paradigma es un estilo combinado que fija como guía la
metodología de un paradigma en función del objetivo general, pero incluye atributos de
otros paradigmas para perseguir los objetivos particulares del proyecto. Esta flexibilidad
es una ventaja que suele desencadenar desarrollos mucho más eficientes que aquellos
que se hubieran conseguido bajo un paradigma único. Sin embargo, ampliar
excesivamente el enfoque puede incurrir en ofuscaciones innecesarias que dificultan el
mantenimiento y se vuelven ineficientes a medida que el desarrollo avanza. Como regla
general, la inclusión de otros paradigmas dentro de una estructura de implementación
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
27
debe ser localizada y deberá estar justificada por un incremento en la eficiencia del
desarrollo.
Por último y no menos importante, utilizar más de un estilo de programación
restringe el universo de lenguajes utilizables puesto que no todos son aptos para la
multiplicidad de paradigmas.
II.6. MODELO AERODINÁMICO: UVLM
Antes de abordar el tratamiento del desarrollo computacional es necesario hacer
referencia al modelo aerodinámico sobre el cual se construye la implementación. Si bien
exponer exhaustivamente el UVLM excede el alcance del presente trabajo, se
proporcionan conceptos generales que permiten interpretar el análisis y diseño de la
aplicación. Sin embargo, se refiere al lector al trabajo de S. Preidikman [13] si mayores
detalles fuesen necesarios.
II.6.1. FUNDAMENTOS DEL MODELO El modelo aerodinámico que da origen al UVLM, al igual que la mayoría de los
modelos físico-matemáticos que describen la mecánica de fluidos, se construye en torno
a las ecuaciones de Navier-Stokes. Concebidas a partir del equilibrio dinámico de un
fluido, en su forma más general, éstas ecuaciones tienen la siguiente expresión vectorial:
𝜌𝐷𝑽
𝐷𝑡= −𝛻�̅� + 𝜇𝛻2𝑽 +
1
3𝜇𝛻(𝛻 · 𝑽) + 𝜌𝒈 (II-1)
Donde 𝜌 es la densidad del fluido, 𝑽 es la velocidad del fluido, �̅� es la presión
mecánica del fluido, 𝜇 es su viscosidad dinámica, 𝒈 es un campo externo de aceleraciones
actuando sobre la masa del fluido, y 𝐷
𝐷𝑡 denota una derivada sustancial que aplicada al
vector velocidad resulta
𝐷𝑽
𝐷𝑡=
𝜕𝑽
𝜕𝑡+ 𝑽 · ∇𝑽 (II-2)
Las ecuaciones (II-1) constituyen un sistema en derivadas parciales no lineales del
que no se dispone una solución analítica general. Luego, se aplican ciertas hipótesis
simplificativas para formular el modelo.
La primera hipótesis a realizar sobre el fluido es la incompresibilidad, es decir, que
se considera su densidad como constante. De este modo, la ecuación de continuidad para
el fluido que de manera general se escribe
𝐷𝜌
𝐷𝑡+ 𝜌(𝛻 · 𝑽) = 0 (II-3)
se reescribe
Capítulo II: Marco Teórico
28
𝛻 · 𝑽 = 0 (II-4)
Tratar a la densidad del fluido como una constante afecta la precisión del modelo,
sin embargo, es una hipótesis válida cuando el número de Mach del flujo es relativamente
bajo: como regla general para 𝑀 < 0,3. El límite fijado para la incompresibilidad surge de
la relación básica que gobierna la variación isoentrópica de las propiedades del fluido a
medida que su velocidad crece (J. D. Anderson [14]), dada por
𝜌0
𝜌= (1 +
𝛾 − 1
2𝑀2)
1𝛾−1
(II-5)
donde 𝜌0 es la densidad del fluido en reposo. Luego, para el aire con 𝛾 = 1,4 y con 𝑀 =
0,3, la variación de la densidad es aproximadamente de un 5%, dando un margen
razonable.
La segunda hipótesis es considerar al flujo como no viscoso, o bien, despreciar los
fenómenos de transporte molecular que incluyen fricción, conductividad térmica y
difusión. Un flujo puede considerarse estrictamente no viscoso cuando el número de
Reynolds tiende a infinito,
𝑅𝑒 =𝜌𝑉𝐿
𝜇=
𝑉𝐿
𝜈→ ∞ (II-6)
siendo 𝑉 el módulo de la velocidad, 𝐿 una longitud de referencia, y 𝜈 la viscosidad
cinemática del fluido. Reemplazando las ecuaciones (II-4) y (II-6) en la (II-1), las
ecuaciones de Navier-Stokes se reducen a
𝐷𝑽
𝐷𝑡= −
1
𝜌𝛻𝑝 +
1
𝑅𝑒𝛻2𝑽 (II-7)
donde se asumió que la presión mecánica del fluido, �̅�, es igual a la presión
termodinámica, 𝑝, y se despreció el campo de aceleraciones másicas 𝒈.
En este punto, la hipótesis de flujo no viscoso es una solución asintótica de la
ecuación (II-7), bajo la cual las ecuaciones de Navier-Stokes se convierten en las
ecuaciones de Euler:
𝐷𝑽
𝐷𝑡= −
1
𝜌𝛻𝑝 (II-8)
II.6.2. VORTICIDAD La formulación matemática del modelo admite la coexistencia de dos campos
vectoriales: el campo de velocidades 𝑽(𝒙, 𝑡) y el campo de vorticidad 𝛀(𝒙, 𝑡). Ambos
campos son funciones de las coordenadas espaciales 𝒙 y del tiempo 𝑡, y guardan una
relación cinemática entre ellos, dada por el rotor del vector velocidad
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
29
𝛀 = ∇ × 𝐕 (II-9)
En general, para un fluido incompresible (o, más estrictamente, barotrópico),
donde los fenómenos de difusión sean despreciables y las fuerzas externas sean
conservativas, se satisfacen las leyes de conservación de Helmholtz. Estas leyes indican
que la vorticidad no puede crearse en el seno del fluido y que las distribuciones
compactas permanecerán compactas. Bajo estas condiciones, la estructura y evolución
del flujo puede describirse más económicamente en términos del campo de vorticidad
que en términos de las velocidades. Además, estas definiciones permiten analizar flujos
con números de Reynolds elevados pero finitos.
Dentro del dominio fluido la vorticidad se origina sobre las superficies sólidas
debido a la condición de no deslizamiento, generando capas límites por difusión. Una vez
generada, la vorticidad se transmite al seno del fluido por convección dando origen a la
estela. Por lo tanto, y tal como expone M. S. Maza [15], para números de Reynolds
crecientes, la distribución de vorticidad se vuelve lo suficientemente compacta como para
considerar el dominio dividido en dos zonas: una pequeña porción del espacio ocupada
por fluido rotacional (estelas y capa límite), con vorticidad distinta de cero, y la porción
restante, donde el fluido se asume irrotacional. En particular, estos flujos suelen llamarse
levemente viscosos y dominados por la vorticidad.
La utilización del campo de vorticidad para describir el flujo proporciona una
ventaja significativa. Esto se debe a que, dadas las condiciones anteriores, el campo de
velocidad en todo el dominio puede representarse a partir de resolver el campo de
vorticidad que se encuentra confinada en zonas compactas.
II.6.3. DETERMINACIÓN DE VELOCIDADES En cada punto dentro del seno del fluido, la velocidad cuenta con tres
componentes que provienen de fuentes distintas, puede expresarse entonces,
𝑽 = 𝑽∞ + 𝑽𝐵 + 𝑽𝑊 (II-10)
donde 𝑽∞ es la velocidad de la corriente libre, 𝑽𝐵 es la velocidad proveniente de la
perturbación producida por las capas límites, y 𝑽𝑊 es la velocidad asociada a la vorticidad
de las estelas.
La velocidad de la corriente libre es un parámetro de la simulación y no merece
mayores análisis. Mientras que, las velocidades provenientes de las perturbaciones
asociadas a la vorticidad de capa límites y estelas deben definirse como funciones del
campo de vorticidad que las representa. Para ello, se parte de dos expresiones ya
introducidas que se repiten por conveniencia:
𝛻 · 𝑽 = 0 (II-11)
Capítulo II: Marco Teórico
30
∇ × 𝐕 = 𝛀 (II-12)
Estas expresiones son idénticas a las que componen el conjunto de ecuaciones de
Maxwell, en particular a las leyes de Gauss y Ampere, que relacionan el flujo de corriente
eléctrica y el campo magnético. Con esta analogía, puede recurrirse a la ley de Biot-Savart
generalizada para representar en forma integral el campo de velocidad en términos del
campo de vorticidad, es decir,
𝑽(𝑥, 𝑡) =1
4𝜋∫
𝛀𝟎 × (𝑷 − 𝑷𝟎)
‖𝑷 − 𝑷𝟎‖3𝑑𝑣
𝑣
(II-13)
donde 𝑣 es la región en la que el fluido es rotacional, 𝑷 es el punto donde se evalúa la
velocidad, 𝑷𝟎 son los puntos contenidos en la región 𝑣, y 𝛀𝟎 es el vector vorticidad en el
punto 𝑷𝟎.
CONDICIONES DE CONTORNO El modelo exige ciertas restricciones al campo de velocidad para dar sentido físico
a la representación. Además, estas condiciones completan la formulación matemática del
problema dando cierre a la solución.
Son dos las condiciones impuestas sobre las velocidades. En primer lugar, la
condición de regularidad en el infinito, la cual establece que para flujos externos las
perturbaciones de las velocidades deben anularse en el infinito, se expresa entonces,
𝑷 → ∞, 𝑽 = 𝑽∞ (II-14)
La segunda condición se establece sobre las superficies sólidas y se conoce como
“condición de no penetración”. En este caso, se exige que la velocidad de una partícula de
fluido que se encuentra sobre el contorno de un cuerpo no tenga componentes normales
al mismo, es decir,
(𝑽 − 𝑽𝒔) · �̂� = 0 (II-15)
siendo 𝑽 la velocidad local del fluido; 𝑽𝒔, la velocidad de la superficie; �̂�, el versor normal
a la superficie; y el subíndice 𝑠 hace referencia a la superficie del cuerpo.
II.6.4. APROXIMACIÓN NUMÉRICA En forma general, si se verifican las hipótesis para que las capas límites y las
estelas sean lo suficientemente compactas, éstas pueden representarse con sábanas o
superficies vorticosas. Desde el punto de vista del modelo numérico, la vorticidad
distribuida en las sábanas se discretiza en una red de segmentos vorticosos rectos y de circulación, Γ(𝑡), constante a lo largo de su longitud, como lo muestran la Figura II.4 y la
Figura II.5.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
31
Se realiza una distinción en la representación de capas límites y estelas. En el caso
de éstas últimas, la grilla (denominada simplemente “estela”) se compone solo de nodos
y los segmentos que los unen, y ambos se mueven libremente en el seno del fluido. En
cuanto a las capas límites, los nodos y segmentos de la grilla, denominada grilla
aerodinámica (GA), forman además paneles. Asimismo, sobre cada panel que conforma
una GA se define un punto de control y un versor normal a la superficie, que permiten
aplicar la condición de contorno y determinar cargas aerodinámicas.
Figura II.4: Aproximación numérica de la sábana vorticosa.
Figura II.5: Discretización de la vorticidad.
Bajo esta nueva aproximación, si se conoce el campo de vorticidad, la
determinación del campo de velocidades puede realizarse con una expresión discreta que
surge de aplicar la (II-13) a un segmento vorticoso recto (Van Garrel [15]). Luego, la
velocidad en un punto 𝑃 arbitrario en el seno del fluido, asociada a un segmento vorticoso
𝑣, se calcula como:
𝑽𝑷𝒗 (𝒙, 𝑡) =
Γ(𝑡)
4𝜋
(𝑅1 + 𝑅2)(𝑹𝟏 × 𝑹𝟐)
𝑅1𝑅2(𝑅1𝑅2 + 𝑹𝟏 · 𝑹𝟐) + 𝑐𝑟2
(II-16)
Donde, siguiendo la Figura II.6, 𝑹𝟏 y 𝑹𝟐 son los vectores de posición relativa entre
el punto 𝑃 y los nodos inicial y final del segmento con 𝑅1 = ‖𝑹𝟏‖ y 𝑅2 = ‖𝑹𝟐‖, 𝑐𝑟 es el radio de “cut off”, y Γ(𝑡) es la circulación alrededor del segmento.
Capítulo II: Marco Teórico
32
En general, el radio de “cut off”, 𝑐𝑟, se define como una fracción de la longitud del
segmento y su función es eliminar la singularidad de la expresión y suavizar el
comportamiento de la misma cuando 𝑅1, 𝑅2 → 0.
Figura II.6: Velocidad inducida en un punto por un segmento vorticoso.
Luego, la velocidad en el punto 𝑃 se obtiene como la suma de los efectos de todos
los segmentos que componen el campo de vorticidad.
II.6.5. DETERMINACIÓN DEL CAMPO DE VORTICIDAD La velocidad en los puntos en el seno del fluido se obtiene a partir de la expresión
(II-16) luego de haber definido las posiciones de los segmentos que discretizan las
sábanas vorticosas. Sin embargo, es necesario conocer la circulación de cada segmento en cada instante de tiempo Γ(𝑡). Para ello, deben analizarse por separado los casos de las
GA y las estelas, puesto que se conforman con procesos diferentes.
En el caso de las GA, las circulaciones de los segmentos se determinan de manera
tal que se cumpla la condición de no penetración. Para ello, sobre cada punto de control
se exige que la componente normal de la velocidad relativa a la superficie sea nula de
acuerdo con (II-15). Luego, teniendo en cuenta la (II-10),
(𝑽∞ + 𝑽𝐵 + 𝑽𝑊 − 𝑽𝒔)𝑖 · �̂�𝑖 = 0, 𝑖 = 1, . . , 𝑛𝑐𝑝
−(𝑽∞ + 𝑽𝑊 − 𝑽𝒔) · �̂�𝑖 = 𝑽𝐵 · �̂�𝑖 , 𝑖 = 1, . . , 𝑛𝑐𝑝 (II-17)
donde 𝑖 se utiliza para indexar cada uno de los puntos de control de los paneles.
En la ecuación (II-17) 𝑽∞ y 𝑽𝑠 son conocidas, al igual que la dirección del versor
normal. Por su parte, 𝑽𝑊 se analizará más adelante, sin embargo, por el momento puede
suponerse que en el instante inicial no existe una estela lo que permite definir 𝑽𝑊 = 𝟎.
Ahora bien, en cada punto de control, la velocidad dada por la perturbación de la
GA puede determinarse a partir del aporte de cada uno de sus segmentos con la ecuación
(II-16), la cual es lineal en la variable Γ(𝑡). Así, puede definirse un sistema de ecuaciones
algebraicas lineales de la forma
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
33
∑ Γ𝑗[𝐵]𝑖𝑗
𝑛𝑠
𝑗=1
= −(𝑽∞ + 𝑽𝑊 − 𝑽𝒔) · �̂�𝑖 (II-18)
donde Γ𝑗[𝐵]𝑖𝑗 = 𝑽𝑩𝒊 representa la velocidad producida por la perturbación del segmento
𝑗 de la grilla en el punto de control 𝑖, de acuerdo con la (II-16). Además, 𝑛𝑠 es la cantidad
de segmentos que posee la GA.
Siguiendo el trabajo de Preidikman [13], la dimensión del sistema de la (II-18)
puede reducirse sensiblemente si en lugar de trabajar sobre los segmentos se asume que
cada panel posee una circulación “de anillo”, igual a la de los segmentos que lo forman.
Así, la circulación de cada segmento será la diferencia entre la circulación de anillo de los
paneles colindantes, según la expresión (II-19), (ver Figura II.7).
Figura II.7: Circulación de segmento interno.
Γ𝑛(𝑡) = 𝐺𝑗𝑡 − 𝐺𝑖
𝑡 (II-19)
Esta consideración permite reescribir el sistema de la ecuación (II-18) como
∑ G𝑗[𝐴]𝑖𝑗
𝑛𝑝
𝑗=1
= −(𝑽∞ + 𝑽𝑊 − 𝑽𝒔) · �̂�𝑖 (II-20)
O bien, en forma matricial
[𝑨]𝑮 = 𝑽𝑨 (II-21)
Donde, en este caso, 𝑛𝑝 es la cantidad de paneles de la grilla, 𝐺𝑗 es la circulación de
anillo del panel 𝑗, y [𝐴]𝑖𝑗 representan la velocidad normal a la superficie que produce la
perturbación del panel 𝑗 en el punto de control 𝑖 para un valor de circulación unitario,
(Figura II.8). Usualmente, la matriz 𝑨, que agrupa los coeficientes [𝐴]𝑖𝑗 , se denomina
matriz de coeficientes de influencia.
Resolver el sistema de la ecuación (II-21) equivale a ajustar las circulaciones de
todos los segmentos de la GA de manera que se satisfaga la condición de no penetración
discretizada sobre los puntos de control.
El caso de las estelas es algo diferente y se analiza en detalle en el Capítulo III.
Conceptualmente, se siguen las leyes de Helmholtz para determinar los valores de
Capítulo II: Marco Teórico
34
circulación (o de vorticidad) de los segmentos que las forman. Esto es, bajo las hipótesis
que rigen el modelo, la circulación que se transfiera al seno del fluido debe permanecer
inalterada y desplazarse junto con el fluido como partículas materiales. Por lo tanto, en
cada paso de tiempo, se transfiere (o se convecta) la circulación de los segmentos de
borde de fuga al seno del fluido. De esta forma, a medida que el tiempo avanza, se
construye la estela como una grilla que se estructura con segmentos de circulación
invariante que se desplazan con la velocidad local del fluido.
Figura II.8: Influencia de un anillo vorticoso en un punto de control.
II.6.6. CARGAS AERODINÁMICAS Habiendo definido los campos de vorticidad y de velocidad del flujo, el paso
siguiente es determinar las cargas aerodinámicas actuando sobre las superficies
inmersas en el fluido. Para ello se calcula en primera instancia la variación del coeficiente
de presión a través de cada panel (ΔCp) como
Δ𝐶𝑝 = 𝐶𝑝|𝐿
− 𝐶𝑝|𝑈
= [𝑝 − 𝑝∞
𝑞]|
𝐿
− [𝑝 − 𝑝∞
𝑞]|
𝑈
(II-22)
El ΔCp es el resultado principal del UVLM y se obtiene a partir da la ecuación de
Bernoulli inestacionaria que relaciona los campos vectoriales definidos en el flujo, 𝑽 y 𝛀,
con el salto de presión a través de las superficies. Luego, cada valor de ΔCp se multiplica
por el área del panel y el versor normal correspondiente para obtener una carga con
carácter vectorial sobre cada punto de control.
II.6.7. SIMULACIÓN El UVLM permite simular el flujo alrededor de una serie de sólidos deformables en
movimiento inmersos en el seno de un fluido. En principio, la cinemática de la
representación es arbitraria: los cuerpos pueden describir trayectorias sin restricciones
más que aquellas que impiden la interferencia, y la velocidad del fluido puede ser una
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
35
función del tiempo. El objetivo es captar los fenómenos provenientes de la interacción
entre los cuerpos y el fluido, que son retroalimentados por cambios en la configuración.
La aproximación que propone el UVLM concibe entidades bien definidas para
representar el fenómeno físico, las cuales se presentan en el esquema de la Figura II.9. En
primer lugar, las grillas (“Grid”) representan superficies sustentadoras y su cinemática
está definida por el cuerpo al cual están adheridas. En ellas, se identifican paneles
(“Panel”), constituidos por nodos (“Node”) y segmentos (“Vortex Segment”), que cuentan
con un punto de control (“Control Point”) y un versor normal (“Normal Versor”) que
define su orientación. Cada segmento vorticoso está definido, a su vez, por dos nodos y
discretiza una porción de la vorticidad de la grilla. Además, asociada a cada grilla, se
identifica al menos una línea de convección (“Convection Line”), formada por un grupo
de segmentos consecutivos, que permite determinar a priori el lugar desde el que se
convecta la estela.
Figura II.9: Modelo de simulación.
En segundo lugar, las estelas (“Wake”) están representadas por una sábana
vorticosa libre, es decir, que se mueve con el fluido. En este caso, no se definen paneles,
sino solo segmentos vorticosos que están definidos por nodos. Cada estela se vincula a la
grilla que la genera a través de su línea de convección y deben mantenerse en contacto a
lo largo de toda la simulación.
Además, conformada por paneles, nodos y segmentos de forma análoga a la “grilla”
se tienen superficies de contorno (“BC Grid”). Estas superficies representan cuerpos
Capítulo II: Marco Teórico
36
cuyas características aerodinámicas no son de interés pero que definitivamente alteran
el dominio fluido. La particularidad de éstas superficies es que no se prevé que de ellas
se convecten estelas, por lo que no tienen asociadas líneas de convección.
Por último, se tienen puntos adicionales (“Extra Points”) inmersos en el seno del
fluido. Sobre estos puntos se determina la velocidad local del flujo y su utilidad recae en
la posibilidad de describir el campo de velocidades en zonas de interés.
37
Capítulo III: IMPLEMENTACIÓN
III.1. EL LENGUAJE DE PROGRAMACIÓN: FORTRAN
La evolución de la programación, desde el uso de código octal y el código
ensamblador (assembly code) hasta los numerosos lenguajes de alto nivel y
multiplataforma que se conocen hoy en día, se produjo en conjunción con el desarrollo
de la computación y los sistemas informáticos. Inicialmente, los programadores
requirieron un conocimiento detallado de las instrucciones, registros, y otros aspectos de
las unidades de procesamiento (CPU) para ejecutar la tediosa tarea de escribir código.
Sin embargo, a medida que la actividad se volvió prolífera se desarrollaron compiladores
que dieron gran flexibilidad a los sistemas de programación a través de la traducción de
instrucciones con una pérdida de eficiencia cada vez menor.
En el seno de este proceso, en el año 1953, un equipo de IBM liderado por John
Backus inició el desarrollo de una alternativa al lenguaje ensamblador conocida como “El
Sistema de Traducción de Fórmulas Matemáticas de IBM” (“IBM Mathematical Formula
Translating System”) o, por su contracción, FORTRAN. Según lo expresan M. Metcalf, J.
Reid y M. Cohen [17], Fortran fue tanto revolucionario como innovador y liberó a los
programadores de los pormenores del uso del lenguaje ensamblador permitiéndoles
concentrarse en los problemas a resolver. Además, el advenimiento de Fortran hizo
masivo el acceso a la computación para científicos e ingenieros que, a cambio de un
esfuerzo menor para aprender el lenguaje, adquirieron la capacidad de programar
aplicaciones.
La primera versión de FORTRAN presentada contenía 32 instrucciones, de las
cuales la mayor parte eran de carácter aritmético, de control y manipulación de datos de
entrada y salida. Contaba también con un protocolo de diagnóstico que detenía las
ejecuciones mostrando un mensaje de error en la consola que permitía, junto con un
manual de operación, identificar fallas de codificación.
Más adelante, en 1958 IBM lanzó la segunda versión del lenguaje: FORTRAN II. En
este caso se introdujo soporte para la programación por procedimientos, permitiendo la
creación de subrutinas y funciones que utilizan variables por referencia, aunque sin
manejar recursividad. Asimismo, se incorporaron la doble precisión y los números
complejos.
Capítulo III: Implementación
38
Luego de una versión que nunca fue lanzada (FORTRAN III) en el año 1962 se dio
a conocer FORTRAN IV. En este caso se introdujeron, entre otras características, variables
lógicas y operaciones booleanas. Sin embargo, FORTRAN IV falló en convertirse en un
estándar que trascendiera las arquitecturas de IBM, lo que no se lograría hasta cuatro
años después con la siguiente versión.
Con la creciente aceptación y la amplia difusión que FOTRAN había tenido en la
comunidad científica, comenzaron a generarse variaciones que se centraban en
problemas específicos, generando inconvenientes en cuanto a la intercambiabilidad de
código. En respuesta a esta problemática, en 1966 el Instituto Nacional de Estándares
Americano (ANSI) lanzó el primer estándar para lenguaje de programación, lo que luego
se convertiría en FORTRAN 66. Esta versión acuñó muchas de las características que
perduraron incluso en las versiones más modernas y permitió aprovechar el hardware
disponible, especialmente en el manejo de la memoria.
A pesar de los esfuerzos por convertir a FORTRAN 66 en una versión normalizada,
muchos dialectos proliferaron incluso después de su lanzamiento ya que contenían
características esenciales para la implementación de programas de gran escala. Esto
provocó que en abril de 1978 se lanzara un nuevo estándar: FORTRAN 77. La nueva
versión condensó muchas de las implementaciones no oficiales de compiladores y
resolvió muchos de los inconvenientes de su predecesora.
A. Markus [18] comenta que desde la publicación de FORTRAN 77, el lenguaje
sufrió numerosas revisiones y que todos los cambios introducidos reflejan tanto las
nuevas ideas en técnicas de programación como los nuevos desarrollos en hardware,
siempre con la eficiencia como premisa. Todo este devenir se materializó en el estándar
lanzado entre 1991 (por ISO/IEC) y 1992 (por ANSI), que más tarde se conocería como
Fortran 90 (donde para su denominación intencionalmente se utilizaron minúsculas).
Fortran 90 fue caracterizado como la primera versión de lo que hoy se denomina
“Fortran Moderno” e incorporó cambios significativos que compensaron el retraso en su
lanzamiento, destacándose: el código de formato libre, el lenguaje de arreglos
(operaciones, asignaciones, secciones, procedimientos intrínsecos, etc.), los tipos de
datos abstractos, los módulos, el almacenamiento dinámico, los tipos de datos derivados,
la sobrecarga de operadores, las interfaces genéricas, los punteros, las funciones de
chequeo numérico, las estructuras de control, nuevos formatos de bucles, los
procedimientos recursivos, los argumentos opcionales, facilidades para manejo de
archivos, entre otros. Las nuevas características dieron pie a la conformación de un
lenguaje que más adelante soportaría la programación multi-paradigma y, en particular,
la OOP.
Una peculiaridad adicional de Fortran 90 fue que se diseñó para que contuviera
completamente el estándar anterior (FORTRAN 77) para evitar extraer de circulación las
aplicaciones precedentes. Sin embargo, muchas características fueron declaradas como
obsoletas y se alentó a los programadores para que poco a poco mudaran sus códigos a
los estándares modernos, y no fue hasta la siguiente revisión que dichas características
se eliminaron.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
39
En 1997 se publicó oficialmente una revisión menor que resolvía algunos
impedimentos incorporando algunas extensiones. Así, se lanzó Fortran 95 con la
particularidad de que contó con la fundación del Foro de Fortran de Alta Performance
(HPFF), haciendo de la HPC su principal tema de desarrollo.
Inicialmente denominada Fortran de Alta Performance (“High Performance
Fortran”), Fortran 95 dejó de lado la versión del año 1978 e hizo de Fortran 90 su lenguaje
de base debido a su aptitud para manejar arreglos. De entre las características
incorporadas se destacan la posibilidad de inicializar arreglos, el atributo de guardado,
nuevos constructores de bucle, y la especialización de arreglos dinámicos que permite
utilizarlos como componentes, variables de transferencia y resultados de funciones.
Además, se adicionó la interoperabilidad con el lenguaje C, dando enorme versatilidad a
la codificación.
Si bien no fueron numerosos, los cambios incorporados en Fortran 95 fueron bien
planificados y le dieron a este estándar una versatilidad importante. Esto fue a tal punto
que, a pesar que Fortran 90 ya era considerado una versión “moderna”, Fortran 95
trascendió hasta convertirse en un lenguaje aún escogido por los programadores y en el
que se basan la mayoría de los compiladores, aunque hoy en día se refiere a él como
Fortran 90/95.
La siguiente revisión publicada fue bastante mayor y se lanzó en 2004
denominándose Fortran 2003. Esta versión contó con una modificación menor lanzada
en 2010, conocida como Fortran 2008. Ambos estándares (2003 y 2008) incorporaron
de lleno las características necesarias para la OOP por lo que se describen con algo más
de detalle a continuación.
Desde Fortran 2008 el lenguaje no sufrió modificaciones, sin embargo, la próxima
revisión pretende ser publicada a mediados de 2018 bajo la denominación de Fortran
2015. En su planificación, Fortran 2015 pretende optimizar la interoperabilidad con C,
eliminar discrepancias y deficiencias entre las características existentes, e incorporar
características adicionales de paralelismo.
III.1.1. FORTRAN 2003/2008 En noviembre de 2004 se dio a conocer una revisión completa del lenguaje,
Fortran 2003, cuyo principal tema fue introducir la OOP al entorno. Este objetivo se logró
principalmente a partir de las siguientes características [18]:
Los tipos derivados de datos pueden contener procedimientos ligados al tipo.
Los tipos derivados de datos pueden extenderse en nuevos tipos, dando lugar
al mecanismo de herencia.
El constructor de selección de tipo para las variables que permite implementar
el polimorfismo.
La definición de procedimientos como interfaces abstractas.
Por supuesto, se agregaron rasgos adicionales referidos al manejo de memoria, al
uso de módulos, al acceso a archivos, y a la interoperabilidad con C, para nombrar
algunos. En definitiva, este estándar produjo un quiebre en el desarrollo del lenguaje
Capítulo III: Implementación
40
convirtiéndolo en una versión de soporte de multi-paradigma que aún conserva las
posibilidades brindadas por Fortran 95.
La fuerte aceptación que Fortran 90/95 había logrado ralentizó la aparición de
compiladores con soporte para Fortran 2003. Además, los usuarios argumentaban que
las características de programación paralela no habían sido reforzadas desde las
versiones anteriores, fue por esto que se lanzó una revisión menor en octubre de 2010.
Fortran 2008 tuvo como objetivo principal la programación paralela y se centró casi
exclusivamente en los co-arreglos y los arreglos contiguos. Estas características, junto
con algunas otras, le dieron la flexibilidad necesaria para convertirse en un lenguaje
sumamente apto para el paralelismo.
III.1.2. POR QUÉ FORTRAN La elección de un lenguaje de programación para iniciar un proyecto de
implementación computacional de cualquier índole constituye una etapa de decisión que
suele guiarse por muchos factores. Estos factores, ya sean objetivos o subjetivos, definen
el lenguaje principal del proyecto de entre las numerosas opciones disponibles, y deben
evaluarse con especial atención.
En primer lugar, el entorno en el cual se sitúa el proyecto constituye un parámetro
que, si bien puede considerarse subjetivo, es sumamente importante. Desde el enfoque
dado al presente trabajo, el entorno se compone principalmente por quienes integran el
grupo de investigación y, por lo tanto, es deseable utilizar el mismo lenguaje con el que
se ha trabajado anteriormente. Si otro fuera el caso, la intercambiabilidad y
expansibilidad del código se verían fuertemente diezmadas, o bien condicionadas a que
los restantes integrantes se instruyan en el uso del nuevo lenguaje.
Continuando con relación al entorno, el conocimiento previo de lenguajes por
parte del programador principal del proyecto debe ser tenido en cuenta. La inversión de
tiempo de desarrollo en el aprendizaje de un nuevo lenguaje no siempre es conveniente
y, por ende, si alguno de los lenguajes ya manejados por el autor es compatible con los
requerimientos del proyecto debería ser considerado como una opción principal.
Otro aspecto a tener en cuenta, de una forma más taxativa, es el diseño del
proyecto, específicamente el Paradigma de Programación bajo el cual se pretende encarar
el desarrollo. Optar por un paradigma determinado reduce, como se mencionó en el
Capítulo II, los posibles lenguajes candidatos. No obstante, existen algunos lenguajes que
soportan la programación multi-paradigma y constituyen opciones más versátiles.
Por último, las características generales del lenguaje deben evaluarse. En general,
la performance, la simplicidad, la disponibilidad, la mutabilidad y el soporte documental,
entre otras características, deben balancearse a la hora de efectuar la elección. Por
ejemplo, si se trata con una aplicación de gran envergadura la performance es
preponderante; luego, un lenguaje compilado con características para HPC es preferible.
Si, por el contrario, se trabaja en una etapa de validación con problemas relativamente
sencillos, un lenguaje interpretado más simple puede resultar adecuado.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
41
Efectuar un juicio de valor comparativo sobre las características de los lenguajes
de programación disponibles, no sólo excede ampliamente los objetivos de esta tesis, sino
que también las aptitudes de su autor. Sin embargo, es necesario quitar arbitrariedad a la
elección de un lenguaje de programación sin perder de vista las intenciones involucradas.
Bajo esta premisa y contextualizando esta discusión en el marco del presente trabajo, se
optó por Fortran 2008 como lenguaje principal para el desarrollo.
La elección se debió a que, primeramente, el grupo de investigación ha trabajado
durante los últimos años en el desarrollo de códigos de co-simulación utilizando a Fortran
(en diversas versiones) como lenguaje de cabecera. Por lo tanto, existen numerosas
aplicaciones computacionales en distintas áreas de la física, y en particular en
aeroelasticidad, originadas en el entorno de trabajo. Así también, es significativa la
documentación de soporte, casos pilotos, simulaciones, y otros materiales relacionados,
que son útiles para respaldar el trabajo. Esto es extensivo a su autor principal quien se
encuentra familiarizado no sólo con el lenguaje sino también con los entornos de
programación que lo soportan.
En segundo lugar, el paradigma de la OOP es perfectamente soportado por el
estándar de Fortran 2008. Si bien, los entendidos más ortodoxos argumentarán que en
sus orígenes el lenguaje no fue concebido bajo este paradigma, los esfuerzos realizados
en los últimos lanzamientos lo vuelven más que apto para la Programación Orientada a
Objetos.
Desde el punto de vista de la performance, la escala del proyecto hace
imprescindible recurrir a un lenguaje compilado que tenga aptitudes específicas para la
HPC. En este sentido, Fortran 2008 presenta características concretas para la
programación en paralelo y el adecuado manejo de memoria, entre otras, que lo
posicionan entre los lenguajes preferidos.
III.2. DESARROLLO DE LA APLICACIÓN
En el desarrollo de una aplicación de co-simulación siguiendo un paradigma de
programación intervienen dos áreas conceptuales importantes que deben indagarse
suficientemente. Es necesario, en primer lugar, manejar adecuadamente los principios y
elementos que construyen el paradigma de guía y, en segundo lugar, entender el
fenómeno físico que se busca representar. En este caso, el paradigma de guía es el
paradigma de la OOP y el fenómeno a representar es la interacción de un fluido sobre
cuerpos sólidos bajo las hipótesis de UVLM.
Dicho esto, no debe perderse de vista que todo el modelo orientado a objetos debe
construirse bajo los objetivos generales del proyecto. Es decir, el entorno de desarrollo y
el alcance definido para la aplicación deben marcar el estilo, los límites y la estructuración
general de la implementación.
En el Capítulo II se fijaron nociones teóricas acerca del paradigma de la OOP y se
establecieron las bases del UVLM. Luego, en este punto debe combinarse uno con el otro,
es decir, se debe someter al modelo aerodinámico a un proceso de análisis y diseño
Capítulo III: Implementación
42
basado en los elementos del modelo orientado a objetos, para desembocar finalmente en
la implementación computacional de la aplicación.
III.2.1. ANÁLISIS ORIENTADO A OBJETOS DEL UVLM La formulación del modelo aerodinámico utiliza una serie de hipótesis
simplificativas, incorpora entidades matemáticas y postula un modelo numérico para la
resolución del problema físico. Este proceso cumplimenta muchas de las etapas de
análisis que propone el paradigma de la OOP. Sin embargo, las especificaciones del
modelo numérico resultante deben definirse con claridad.
El modelo simula cuerpos sólidos deformables y el fluido que interactúa con ellos.
Matemáticamente, esta configuración se representa con dos campos vectoriales: el campo
de vorticidad y el campo de velocidad. Por lo que es fundamental comprender la relación
que une a estos dos campos, la cual está dada por las expresiones (II-13) y (II-16).
El siguiente nivel de abstracción es la aproximación discreta del campo de
vorticidad que da origen a grillas aerodinámicas adheridas (grillas, de aquí en más “grillas
aerodinámicas”, y grillas de contorno) y libres (estelas). A su vez, las grillas adheridas se
construyen con nodos y segmentos que forman paneles sobre los cuales se definen puntos
de control y versores normales. Las estelas, por su parte, se conforman sólo con
segmentos y nodos, y deben relacionarse de manera adecuada con las grillas adheridas.
El objetivo de la aproximación numérica es construir un sistema de ecuaciones
algebraicas lineales, a partir de imponer condiciones de contorno discretizadas sobre los
puntos de control de cada panel, garantizando la no penetración del flujo en los cuerpos
sólidos. El sistema de ecuaciones resultante está dado por (II-21) y permite determinar
en cada paso de tiempo las vorticidades de anillo de los paneles.
Asimismo, conociendo el campo de vorticidad se determina el campo de
velocidades y, en función de éste, se convectan las estelas. Finalmente, con ambos campos
definidos, se calculan las cargas aerodinámicas sobre cada panel.
En resumen, las especificaciones del sistema que representa el modelo
aerodinámico están contenidas en los siguientes puntos.
Representar los cuerpos sólidos deformables y el fluido con el que
interactúan.
Incluir los campos vectoriales de vorticidad y velocidad, y la relación entre
ambos.
Discretizar el campo de vorticidad en grillas adheridas y estelas.
Definir nodos, segmentos y paneles con las características adecuadas para
formar las grillas adheridas y las estelas.
Fijar condiciones de contorno.
Plantear y resolver un sistema de ecuaciones algebraicas lineales para
determinar el campo de vorticidad.
Calcular el campo de velocidades en función del campo de vorticidad.
Calcular las cargas aerodinámicas sobre los paneles.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
43
De este modo, se completa la etapa de análisis, definiendo qué incluir en la
implementación en forma de especificaciones.
III.2.2. DISEÑO ORIENTADO A OBJETOS DEL UVLM Como se mencionó, el diseño orientado a objetos debe construir un mapa del
fenómeno físico formado por entidades y relaciones, a partir las especificaciones surgidas
de la etapa de análisis. Este proceso se realiza de manera cíclica, refinando
progresivamente el mapeo a medida que se construye la estructura lógica del problema.
A continuación, se recorren las principales etapas del diseño de la aplicación
implementada.
DEFINICIÓN DE ENTIDADES Y JERARQUÍA El primer paso es definir entidades de forma general para establecer las primeras
asociaciones que puedan surgir. En esta etapa, una entidad puede tener tres naturalezas:
ser tangible o visible, ser comprendida intelectualmente, ser fuente u objeto de una
funcionalidad. Luego, considerando las especificaciones del modelo, en una primera
aproximación el mapa de entidades se compone de las siguientes:
Cuerpos.
Fluido.
Dominio, entendido como el espacio donde el fenómeno tiene lugar.
Campo de velocidades.
Campo de vorticidad.
Grillas.
Grillas de contorno.
Estelas.
Sistema de ecuaciones algebraicas.
Cargas aerodinámicas.
Paneles.
Segmentos.
Nodos.
Puntos de Control.
Versores normales.
El siguiente paso es ordenar las entidades en distintos niveles de abstracción para
jerarquizarlas. Un diagrama de este procedimiento se muestra en la Figura III.1.
ASOCIACIÓN DE ENTIDADES Tomando el diagrama jerárquico de abstracciones como referencia se deben
definir asociaciones entre entidades. Las asociaciones son relaciones de funcionalidad
que cumplen dos objetivos principales. Por un lado, completan el sentido lógico de la
estructura del problema y, por otro, ponen en evidencia faltas o excesos en la definición
de entidades. Esta última función convierte a las relaciones en un mecanismo evaluador
del proceso de abstracción, ya que indicarán si es necesario incorporar o eliminar
entidades para que el mapa se cierre adecuadamente.
Capítulo III: Implementación
44
Figura III.1: Ordenamiento en niveles de abstracción.
Con lo anterior en consideración se describen las relaciones fundamentales del
modelo que surgen de asociar las entidades listadas anteriormente:
El dominio del problema incluye a cuerpos y fluido, y en general a todas las
entidades que componen el problema.
Varios cuerpos pueden relacionarse entre sí formando un conjunto.
La interacción entre cuerpos y fluido es el principal objeto de investigación
y se basa en las cargas aerodinámicas que el segundo ejerce sobre los
primeros, a través de las condiciones de contorno.
Los campos de vorticidad y velocidad describen la cinemática del fluido.
El campo de vorticidad se obtiene a partir del sistema de ecuaciones
algebraicas que surge de imponer condiciones de contorno al fluido, sobre
los cuerpos.
Las estelas, grillas y grillas de contorno son las encargadas de representar
el campo de vorticidad.
El campo de vorticidad determina el campo de velocidades en todo el
dominio.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
45
Las cargas aerodinámicas se obtienen a partir del campo de vorticidad y del
campo de velocidades.
Paneles, segmentos y nodos conforman las grillas y las grillas de contorno.
Segmentos y nodos conforman las estelas.
Los paneles cuentan con un punto de control y un versor normal.
Las cargas aerodinámicas y las condiciones de contorno se definen sobre
los puntos de control y en la dirección de los versores normales de los
paneles.
Las estelas se convectan desde bordes filosos de las grillas definidos a
priori.
Las estelas se convectan con la velocidad local en los nodos designados.
Las grillas de contorno limitan el dominio.
APLICACIÓN DEL SRP Habiendo definido entidades y relaciones en forma general, la siguiente instancia
es refinar los conceptos aplicando un principio de diseño que fije un criterio para
confeccionar el mapa de entidades. El principio seleccionado para esta tarea es el
Principio de Responsabilidad Simple, el cual contrasta las entidades con las relaciones
para evaluar la condición de responsabilidad de éstas primeras.
Como se mencionó, cada entidad debe contar con una única función que pueda
alterar su estado y, de no ser así, deberá disgregarse o reemplazarse por otras. Del mismo
modo, si existen funcionalidades que no actúan sobre entidades definidas, nuevas
entidades deben crearse hasta satisfacer la responsabilidad simple. Con esto presente se
analiza cada entidad para definir la versión final del mapa de diseño con base en lo
expuesto en la Figura III.1.
Los dos primeros niveles de abstracción los constituyen el dominio, los cuerpos y
el fluido. El estado del dominio como entidad no tiene una responsabilidad directa debido
a que luego de definirse no se esperan alteraciones durante la simulación. Luego, en lo
que concierne al SRP el dominio no constituye una entidad del modelo. En cuanto a los
cuerpos sólidos, el UVLM los representa con grillas de vorticidad discretizada, por lo que
éstas serían entidades más apropiadas para definirlos. Algo similar ocurre con el fluido;
en este caso es el campo de velocidad el que define sus propiedades debido a las hipótesis
del UVLM.
En el siguiente nivel de abstracción, el campo de vorticidad se representa con
grillas, grillas de contorno y estelas, por lo que cualquier alteración que éste sufra se verá
reflejada en ellas. El campo de velocidades, en cambio, debe definirse punto a punto en el
dominio fluido por lo que requiere una entidad adicional que asuma sus
responsabilidades. Las cargas aerodinámicas se definen sobre los paneles y pueden
considerarse una propiedad de estos, luego su funcionalidad se transferirá al panel sobre
el que actúa. Mientras que el sistema de ecuaciones algebraicas depende de varios
factores (velocidades sobre grillas y grillas de contorno) por lo que su responsabilidad es
múltiple y debe disgregarse.
Capítulo III: Implementación
46
Al cuarto nivel de abstracción lo ocupan las estelas, grillas y grillas de contorno.
Todas estas entidades tienen la función de representar discretamente el campo de
vorticidad en distintas condiciones por lo que cumplen con el SRP.
Paneles, segmentos y nodos se encuentran en el siguiente nivel de abstracción. La
función de los paneles es materializar la circulación de anillo dentro de la grilla que
forman. Los segmentos, por su parte, discretizan el campo de vorticidad sobre grillas,
estelas y grillas de contorno. Por último, los nodos dan referencia a la formación de
paneles y segmentos. Luego, las tres entidades de éste nivel de abstracción deben
conservarse.
El último nivel lo conforman, primero, los puntos de control. Sobre éstos se
imponen las condiciones de contorno en los paneles por lo que satisfacen el SRP.
Igualmente lo hacen los versores normales que definen la orientación de los paneles.
DEFINICIÓN DE CLASES En este punto, aquellas entidades que cumplen con el SRP pueden definirse como
clases dentro del modelo orientado a objetos. Las clases surgidas en la sección anterior
son las siguientes:
Grillas.
Grillas de contorno.
Estelas.
Paneles.
Segmentos.
Nodos.
Puntos de control.
Sin embargo, existen funcionalidades que todavía no se encuentran representadas
por lo que deben incorporarse clases adicionales. Tal es el caso de la construcción de un
conjunto de cuerpos relacionados. Es decir, la posibilidad de representar un sistema
multi-cuerpo que interactúe con el fluido. Luego, esta característica requiere la
incorporación de una nueva clase, a saber, conjunto.
Otra funcionalidad no representada es la relación entre grillas y estelas. El UVLM
supone que se conoce a priori el lugar desde donde se convectan las estelas por lo que
debe existir una entidad asociada a las grillas que defina dicho lugar. Con este criterio se
incorpora la clase línea de convección.
Al igual que con el campo de vorticidad, el campo de velocidades debe ser
discretizado para poder representarse numéricamente. Para ello deben individualizarse
los puntos del dominio donde se desea conocer la velocidad, lo que se logra con la
definición de una clase: punto extra.
Como resultado de este análisis, se incorporan tres clases al listado anterior:
Conjunto (denominado “Body” en futuras referencias).
Línea de convección.
Punto extra.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
47
III.2.3. PROGRAMACIÓN ORIENTADA A OBJETOS DEL UVLM La etapa de programación se ata fuertemente al lenguaje principal del proyecto,
en este caso Fortran 2008. Desde el punto de vista de la aplicación, el lenguaje
proporciona herramientas específicas para implementar cada uno de los elementos del
modelo orientado a objetos y constituye la evaluación final del modelo diseñado. Esto es,
durante la programación, toda la estructura lógica del problema es puesta a prueba en un
sentido práctico y muchas veces es necesario reevaluar etapas anteriores.
La programación de una aplicación de simulación de uso general implica un
trabajo arduo y minucioso que pone a prueba la destreza del programador y su manejo
del lenguaje utilizado. Sin embargo, transitar los pormenores de la implementación
computacional propiamente dicha excede la intención de esta sección. Por lo que, se
presentan a modo ilustrativo algunas de las técnicas y mecanismos incorporados. En el
caso en que mayor información sobre el código sea necesaria, el ANEXO 1 proporciona
detalles sobre la aplicación.
ABSTRACCIÓN: CLASES Y OBJETOS Con todas las clases definidas y conocidas las relaciones entre ellas se concluye el
mapa del modelo orientado a objetos. A éste respecto, la Figura III.2 presenta un
diagrama de clases a través del Lenguaje Unificado de Modelado (UML) (M. Fowler y S.
Kendall [19]), donde se exponen todas las clases presentes en el código desarrollado y las
relaciones que se construyen entre ellas.
En la implementación una clase se define como un tipo abstracto de dato (ADT) y,
como se dijo, se compone de un nombre que lo identifica, atributos que lo caracterizan y
procedimientos que pueden actuar sobre éste. En Fortran 2008, se utilizan módulos para
implementar los ADT. Esto es, cada clase se define dentro de un módulo que luego será
incorporado en las dependencias de otro si fuera necesario y, a su vez, se relacionará con
otros a través de sus propias dependencias. Si bien la interdependencia de módulos es un
aspecto específico del lenguaje utilizado y no constituye una característica de la OOP, su
utilización es imprescindible para relacionar subrutinas. Al respecto, la Figura III.3
muestra el módulo de implementación de la clase “Panel” y en ella se han identificado
cada uno de sus componentes.
Por otro lado, la definición de objetos de las distintas clases se logra dando
instancia a la clase en cuestión y a todos los atributos que la forman. Por ejemplo, el panel
con índice número 9 es un objeto de la clase “Panel” y tiene a su vez atributos específicos
que lo caracterizan, tal y como se muestra en la Figura III.4.
ENCAPSULACIÓN Y MODULARIDAD La encapsulación representa una gran potencialidad del lenguaje y materializa el
ocultamiento de información propio de la OOP. En términos prácticos, permite proteger
y dar exclusividad a los atributos y procedimientos de una clase, restringiendo
selectivamente los accesos.
Capítulo III: Implementación
48
Figura III.2: Diagrama de clases en UML.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
49
Regresando a la Figura III.3 y a modo de ejemplo, todos los procedimientos
enlistados en el bloque CONTAINS son específicos de la clase “Panel” y, si bien pueden
relacionarse con otras clases, su contenido está restringido a cada objeto definido como
“Panel”. En particular para Fortran 2008, el uso de los atributos “Public” y “Private”
reflejan el nivel de ocultamiento de cada procedimiento y característica, en cuanto al
acceso a través de mecanismos de vinculación [17].
Figura III.3: Módulo de definición de clase.
MODULE classPanel
! "Panel" abstract data type definition
! Martín Eduardo Pérez Segura ! Mauro S. Maza
USE classControl_Point USE classVortex_Segment USE classNodal_Point, only: Nodal_Point USE ShFunct_DShFunct USE P_S_N
PUBLIC
TYPE, Public :: Panel
!Attributes: INTEGER :: Grid ! Owner INTEGER :: Label ! Global Id number of the panel INTEGER :: Panel_Type ! Sets the panel configuration accor... INTEGER :: nPanelNodes ! Number of nodes of the panel (3:8) INTEGER, ALLOCATABLE, DIMENSION (:) :: PanelNodes ! Nodes of the panel (3:8) INTEGER :: nPanelSegments ! Number of segments of the panel... INTEGER, ALLOCATABLE, DIMENSION (:) :: PanelSegments ! vortex segments of the panel REAL :: RingVorticity ! vortex ring vorticity of the panel REAL :: RngVtctyPrvStp ! vortex ring vorticity of the panel... type(CONTROL_POINT) :: CtrlPoint REAL :: Area ! Area of the panel
CONTAINS ! methods' names
PROCEDURE, Public, NoPass :: PanelSet_Allocation PROCEDURE, Public, NoPass :: PanelSet_Generation PROCEDURE, Public, NoPass :: PanelSet_Printing PROCEDURE, Public, NoPass :: Xa_Calculation PROCEDURE, Public, NoPass :: Sgmnt_Coef PROCEDURE, Public, NoPass :: Panel_DeltaV PROCEDURE, Public, NoPass :: Area_calc
END TYPE Panel
CONTAINS
Dependencias de Módulos
Atributos
Procedimientos
Definición de Módulo
Nombre
Capítulo III: Implementación
50
Figura III.4: Atributos del objeto “Panel”.
JERARQUÍA O HERENCIA Materializar las relaciones entre clases en la aplicación es imprescindible para
implementar el modelo diseñado. Además, cada relación debe precisar su naturaleza y
alcance para dar continuidad a la estructura lógica del código. En este sentido, Fortran
2008 proporciona atributos específicos para implementar las relaciones entre clases.
En primer lugar, la relación de generalización/especialización, de herencia, o “Is-
a”, en Fortran 2008, se especifica con el atributo “Extend”. En la Figura III.5 se muestra
una porción de código donde, a partir de un ADT, “Point”, se extienden dos clases
adicionales: “Control_Point” y “Nodal_Point”. Luego, éstas últimas son especializaciones
de la clase de base y, además de compartir sus atributos, poseen atributos específicos
exclusivos.
Por otro lado, la relación de agregación, “Has-a”, o de composición de objetos se
muestra en la Figura III.6. En este caso, un objeto de la clase “Grid” posee atributos que
se definen en otras clases. Aquí se representa el conjunto de nodos, de segmentos y de
paneles que conforman la grilla en cuestión y, cada una de estas entidades, son objetos de
clases específicas, en particular, de las clases “Nodal_Points”, “Panel” y “Vortex_Segment”.
POLIMORFISMO En Fortran 2008, existen dos formas principales de polimorfismo. En primer lugar,
el llamado de tipo compatible (“type-compatible”) que se representa con la clave “class”
y es una versión restringida. En este caso, el objeto polimórfico sólo puede mutar a una
clase compatible con su tipo, es decir, a una clase extendida (en
generalización/especialización) de ella. Por ejemplo, la Figura III.7 muestra un
procedimiento (subrutina) donde la variable de ingreso se declara con el atributo
“CLASS()”. Este tipo de declaración de variable permite que todas las clases, o mejor dicho
que los objetos de todas las clases, extendidas de aquella indicada en el argumento del
atributo, en particular “Grid”, sean indistinguibles para el procedimiento. Luego, todas las
instrucciones serán aplicadas a todos los objetos mientras sean de tipo compatible (es
decir de las clases “Grid” o “BC_Grid”) y alteren sólo los atributos comunes (ver Figura
III.2. Por otro lado, si alguna instrucción utiliza algún atributo exclusivo de una de las
clases compatibles, deberá explicitarse para evitar errores, , lo que se logra utilizando el
constructor “Select Type” [19].
12 15
3332
4
7
11
2
9
G9t
G9t
Label: 9
Panel_Type: Cuadrilátero
nPanelNodes: 4
PanelNodes: 12 ; 15 ; 33 ; 32
nPanelSegments: 4
PanelSegments: 7 ; 11 ; 2 ; 4
RingVroticity:
RngVtctyPrvStep:
CtrlPoint: Control_Point()
Area: A
G9t-1
OBJETO: PANEL 9
Area = A
Control_Point AT
RIB
UT
OS
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
51
La segunda forma es bastante más general y se conoce como polimorfismo
ilimitado. A pesar de que la denominación sugiera que es robusta, también posee
restricciones. Las entidades polimórficas ilimitadas permiten al programador de contar
con un puntero (polimórfico) que pueda referir no sólo a objetos de clases extendidas
sino a objetos de cualquier tipo, tanto ADT como tipos intrínsecos. En este caso el atributo
se expresa “CLASS(*)” y, aunque no fue utilizado en la implementación en análisis, posee
elevado potencial y merece mención [19].
Figura III.5: Relación de generalización/especialización.
MODULE classPoint
! "Point" abstract data type definition
! Martín Eduardo Pérez Segura ! Mauro S. Maza PRIVATE
TYPE, Public :: Point !Attributes: REAL, dimension (3) :: xyz ! point coordinates REAL, dimension (3) :: xyz_loc ! local coordinates
CONTAINS ! methods' names
END TYPE Point
CONTAINS
MODULE classControl_Point
! "Control_Point" extended class type definition ! Specialization of "Point"
! Martín Eduardo Pérez Segura ! Mauro S. Maza
USE classPoint, only: Point PUBLIC
TYPE, EXTENDS(Point), Public :: Control_Point!Extended type of "Point" !Attributes: REAL, dimension (3) :: OwnVelocity REAL, dimension (3) :: InducedVelocity REAL, dimension (3) :: WindVelocity REAL, dimension (3) :: NormalVersor REAL :: TrnspVelocity REAL :: Delta_Cp
CONTAINS ! methods' names
PROCEDURE, Public, NoPass :: CP_Coords PROCEDURE, Public, NoPass :: CP_NormalVersor PROCEDURE, Public, NoPass :: CP_Velocity
END TYPE Control_Point
CONTAINS
MODULE classNodal_Point
! "NodalPoint" extended class type definition ! Specialization of "Point"
! Martín Eduardo Pérez Segura ! Mauro S. Maza
USE classPoint, only: Point
PUBLIC
TYPE, EXTENDS(Point), Public :: Nodal_Point !Extended type of "Point" !Attributes: INTEGER :: Label REAL, DIMENSION(3) :: InducedSpeed
CONTAINS ! methods' names
PROCEDURE, Public, NoPass :: NPSet_Allocation PROCEDURE, Public, NoPass :: NPSet_Generation PROCEDURE, Public, NoPass :: NPSet_Printing
END TYPE Nodal_Point
CONTAINS
HE
RE
NC
IA
HE
RE
NC
IA
Capítulo III: Implementación
52
Figura III.6: Relación de agregación.
III.2.4. EL DISEÑO POR PROCEDIMIENTOS COMO ALTERNATIVA Como se planteó en los capítulos anteriores, el paradigma de programación por
procedimientos es la principal alternativa al paradigma de la OOP. Luego, es conveniente
presentar, en contraste, algunos aspectos de éste en términos de la implementación.
El mecanismo de implementación de un modelo procedimental es análogo al
planteado para el modelo de OOP. Por supuesto, cada etapa debe desarrollarse bajo otros
criterios e incorporando los elementos característicos del paradigma. Sin embargo, las
especificaciones del problema que surgen de la etapa del análisis de OOP son también
válidas para el diseño por procedimientos. Por lo tanto, la atención se vuelca sobre la
etapa de diseño que difiere sensiblemente de la del modelo orientado a objetos.
En el modelo procedimental, las especificaciones del problema deben mapearse
en procedimientos y en relaciones entre los entornos de éstos procedimientos. Aquí
también se trata con un proceso de refinamiento sucesivo, ya que cada bloque puede
MODULE classGrid
! GRID abstract data type definition
! Martín Eduardo Pérez Segura ! Mauro S. Maza
USE classVortex_Segment USE classNodal_Point USE classPanel USE P_S_N USE Input_ReadLoad
PUBLIC
TYPE, Public :: Grid
CHARACTER (len=15) :: GridName INTEGER :: GridLabel ! Grid ID. CHARACTER (len=15) :: ExtraData ! for miscellaneous purposes INTEGER :: KinCondition ! Kinematic condition of the grid. INTEGER :: nWakes ! Number of wakes shedding from the grid. INTEGER, ALLOCATABLE, DIMENSION(:) :: WakesLabels ! Labels of the nWakes. INTEGER :: nNodalPoints ! number of nodal points type(NODAL_POINT), ALLOCATABLE, DIMENSION(:) :: NodalPointSet ! Nodal points of the grid INTEGER :: nVortexSegments ! number of vortex segments type(VORTEX_SEGMENT), ALLOCATABLE, DIMENSION(:) :: VortexSegmentSet ! Vortex segments of the grid INTEGER :: nPanels ! number of panels type(PANEL), ALLOCATABLE, DIMENSION(:) :: PanelSet ! Panels of the grid INTEGER :: AMatLoc ! AeroMatrix position index.
CONTAINS ! methods' names
PROCEDURE, Public, NoPass :: GridLoading PROCEDURE, Public, NoPass :: GridPrinting PROCEDURE, Public, NoPass :: InGrid_Xa PROCEDURE, Public, NoPass :: Panel_Coef PROCEDURE, Public, NoPass :: RingVrtct_2_SgmntCirc PROCEDURE, Public, NoPass :: PanelSet_RingVtct_Loading PROCEDURE, Public, NoPass :: GridReading
END TYPE Grid
CONTAINS
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
53
subdividirse hasta alcanzar el nivel de complejidad deseado. Luego, la formulación
imperativa del modelo se realiza desde lo más general a lo más particular.
Figura III.7: Polimorfismo de tipo compatible.
A modo de ejemplo, algunos de los procedimientos básicos que el modelo
procedimental deberá incluir se enlistan a continuación.
Pre-proceso de datos de entrada.
Inicialización de la simulación.
Cálculo del campo de vorticidad.
Cálculo del campo de velocidades.
Convección de la estela.
Cálculo de cargas aerodinámicas.
Actualización de posiciones y velocidades de las grillas.
Pos-proceso de datos de salida.
Visualización.
Las relaciones entre los procedimientos anteriores son intuitivas y pueden
organizarse en un diagrama como el de la Figura III.8. Este esquema fija un punto de
partida para diseñar la aplicación según el paradigma por procedimientos y, en definitiva,
coincide con la mayoría de los códigos procedimentales de simulación aerodinámica
basados en el UVLM.
En este punto podría pensarse que el modelo procedimental es comparativamente
simple y, de cierta manera lo es. Sin embargo, como se mencionó, este modelo centra toda
su atención en sólo una de las partes de la implementación: el algoritmo. En lo que
SUBROUTINE Panel_Coef (GRD) ! USES POLYMORPHIC VARIABLES SO AS TO PROCESS GRIDS AND BC_GRIDS.
!Input VariableCLASS(Grid),INTENT (INOUT) :: GRD
!Local VariablesINTEGER :: i,j,k !Loop indexesINTEGER :: nShPnls, nPnlSgmnts ! Number of sharing panels, number of panel segments.INTEGER :: PanelID ! Panel Label. Extraction variableINTEGER :: SGN ! Sign of the label. Extraction variable
DO i=1,GRD%nVortexSegments nShPnls = GRD%VortexSegmentSet(i)%nSharingPanels
DO j=1,nShPnls PanelID = GRD%VortexSegmentSet(i)%SharingPanels(j) nPnlSgmnts = GRD%PanelSet(PanelID)%nPanelSegments DO k=1,nPnlSgmnts if (abs(GRD%PanelSet(PanelID)%PanelSegments(k))==GRD%VortexSegmentSet(i)%Label) then SGN = sign(1,GRD%PanelSet(PanelID)%PanelSegments(k)) end if END DO GRD%VortexSegmentSet(i)%SharingPanels(j) = SGN * GRD%VortexSegmentSet(i)%SharingPanels(j) END DOEND DO
END SUBROUTINE Panel_Coef
Capítulo III: Implementación
54
respecta a la estructura de datos, incluso en el nivel simplificado de la Figura III.8, las
dificultades son numerosas.
Figura III.8: Diagrama de flujo para el paradigma procedural.
Considérese, por ejemplo, la vorticidad distribuida. Definir una estructura que la
represente dentro de un modelo procedural requiere concebir mecanismos de
almacenamiento sincronizado que pueden resultar intrincados. En este caso, deben
almacenarse las circulaciones de anillos de los paneles, la vorticidad de los segmentos, la
posición de los nodos que los forman, entre otras variables que se modifican en cada
iteración, además de un sistema que las vincule entre sí. Si bien existen muchas
soluciones creativas para este inconveniente, no suelen ser tan evidentes, al menos en la
etapa de diseño, y requieren un proceso de adaptación significativo antes de
implementarse. Esto es previo a considerar los pormenores relacionados con la
interdependencia entre todas las estructuras y las cadenas de actualización de variables
que deben realizarse.
Algo similar ocurre, por ejemplo, con las cargas aerodinámicas. Uno de los datos
de salida de la simulación será un conjunto de variables vectoriales (las cargas
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
55
aerodinámicas) que deberán guardar correspondencia con los paneles de una grilla.
Digamos que se utiliza un sistema para numerar los paneles de una grilla, podría entonces
recurrirse al mismo sistema para identificar cada vector de carga. Sin embargo, si se
trabaja sobre múltiples grillas se deberá incorporar una referencia adicional al sistema
de numeración que deberá transferirse a todas las subrutinas que operen sobre estas
variables. Aquí también los puntos de control y los versores normales juegan un papel
similar y podrían o no utilizar el mismo sistema de numeración para referenciarse.
Razonamientos similares pueden aplicarse a todos los procedimientos del modelo
y la variabilidad en las posibles soluciones es significativa. Esto afecta la distribución de
código y la colaboración de un grupo de trabajo en el desarrollo, debido a que cualquier
alteración en las especificaciones, una vez iniciado el proyecto, puede desencadenar un
replanteo total en la estructura de datos implementada.
Otra arista a tener en cuenta sobre las implementaciones procedurales es la
performance. Definitivamente, una estructura de datos sólida y bien diseñada será
propicia para la aplicación de técnicas de HPC. No obstante, la potencial diversidad de
soluciones y las posibles modificaciones que deban implementarse pueden generar
controversias y variabilidad en las aptitudes de una aplicación frente al desempeño.
III.3. PARTICULARIDADES DE LA IMPLEMENTACIÓN
Dentro del modelo aerodinámico definido y del paradigma de programación
elegido, la aplicación desarrollada cuenta con ciertas características que difieren de los
rasgos tradicionales de las implementaciones del UVLM. Estas características fueron
pensadas con la robustez y la generalidad como premisas, pero sin perder de vista la
performance y la simplicidad en la lógica del código. Luego, constituyen una solución de
compromiso entre todos los aspectos prioritarios.
III.3.1. GENERALIDAD DE DATOS DE ENTRADA Con la intención de acentuar la robustez y la generalidad de la implementación, se
minimizan las restricciones impuestas al usuario en cuanto a la definición de parámetros
iniciales. En este sentido, se aborda aquí el tratamiento de los datos de entrada necesarios
para efectuar la simulación.
De acuerdo con el modelo aerodinámico implementado, el usuario debe definir las
superficies a simular como grillas, ya sean aerodinámicas o de contorno. Además, sobre
las primeras, se debe definir una (al menos una) línea de convección que dará lugar a la
estela a medida que la simulación avance.
Respecto a lo anterior, la implementación posee dos particularidades que no
suelen encontrarse en códigos similares. Por un lado, la flexibilidad en la definición de las
grillas y, por otro, la adaptabilidad al tipo de línea de convección a procesar.
DEFINICIÓN DE GRILLAS En cuanto a la construcción del modelo, la definición de grillas aerodinámicas y de
contorno es análoga, por lo que se tratará un caso genérico que cubre las dos variantes.
Capítulo III: Implementación
56
Esta construcción, como ocurre usualmente, se efectúa a partir de dos tipos de datos de
entrada: coordenadas de nodos y conectividades.
Las coordenadas de los nodos que componen una grilla no requiere mayor análisis.
Se trata de un archivo de datos que proporciona tres coordenadas correspondientes a las
direcciones de un espacio euclidiano para cada nodo. Estas coordenadas se utilizarán en
la etapa de pre-proceso para generar los arreglos de nodos que darán lugar a las
referencias conectivas de paneles y segmentos.
Por otro lado, las conectividades de una grilla se presentan en un arreglo que
ordena, según la numeración local de cada panel, los índices globales de los nodos que lo
componen. Estos datos deben ser suficientes para representar la grilla con todas las
características y parámetros que requiere el modelo. Es decir, sin requerir información
adicional, deben construirse segmentos orientados, paneles de distintos tipos, con puntos
de control y versores normales, y referenciar éstos entre sí.
En general, el archivo de conectividades de una grilla se genera a partir de un
algoritmo de mallado que, en sí mismo, guarda ciertas precauciones a la hora de definir
conectividades. Siendo así, la construcción de segmentos sólo requiere que el orden en la
numeración de conectividades sea ininterrumpido alrededor del panel, aunque admite
arbitrariedad en el sentido de numeración. Luego, cada segmento se compone de los
nodos locales 𝑖 e 𝑖 + 1, donde 𝑖 identifica el índice local.
Por su parte, la definición del punto de control se realiza con un algoritmo
conmutativo por lo que no se ve afectada por el sentido ni el ordenamiento de las
conectividades de un panel.
Además, en la etapa de pre-proceso deben definirse los versores normales que se
posicionan sobre el punto de control de cada panel. Conceptualmente, un versor normal
se define como el producto vectorial normalizado de dos vectores no paralelos y
tangentes a la superficie del panel. La definición de estos vectores se realiza a partir del
uso de un “panel maestro” y la transformación isoparamétrica que lo mapea desde el
dominio de origen al dominio del elemento (procedimiento habitual utilizado en el
Método de Elementos Finitos). Así, teniendo en cuenta la matriz jacobiana de la
transformación, se tiene:
[𝑻𝟏 𝑻𝟐] = 𝑱(𝜉, 𝜂) = 𝛁𝑻𝒆 = [
𝑥𝜉′ 𝑥𝜂
′
𝑦𝜉′ 𝑦𝜂
′
𝑧𝜉′ 𝑧𝜂
′
] (III-1)
Donde 𝑻𝟏 y 𝑻𝟐 son los vectores tangentes a la superficie y 𝑱(𝜉, 𝜂) es la matriz
jacobiana de la transformación 𝑻𝒆. Luego, el versor normal resulta:
�̂� =𝑻𝟏 × 𝑻𝟐
‖𝑻𝟏 × 𝑻𝟐‖ (III-2)
Naturalmente, la definición de las conectividades de un panel tiene un impacto
directo en la definición del versor normal. En la Figura III.9 se esquematiza lo anterior
con dos posibles definiciones del versor normal de un panel, en función del sentido de la
numeración local de los nodos. Luego, en la Figura III.9 a) la numeración local es en
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
57
sentido horario, lo que genera un versor normal entrante, mientras que lo opuesto ocurre
en la Figura III.9 b).
Generalmente, los malladores son consistentes con el sentido de numeración que
asignan a los paneles. Sin embargo, pueden presentarse alteraciones, como por ejemplo
la coexistencia de grillas definidas con distintos algoritmos. Considérese, entonces, el
caso de la Figura III.10 donde dos grillas con sentidos de numeración diferentes coexisten
en una simulación.
En este ejemplo, existe una indefinición en el sentido positivo de los versores
normales, ya que el mismo depende de la grilla a la que se haga referencia. Otra
alternativa, aunque menos probable debido a la naturaleza de la generación de grillas, se
muestra en la Figura III.11.
Aquí, los paneles indicados con 1 y 4 poseen numeración anti-horaria lo que
genera versores “salientes”, mientras que los paneles 2 y 3 representan el caso contrario.
Figura III.9: Definición del versor normal, a) entrante, b) saliente.
Figura III.10: Grillas con distintas orientaciones.
Capítulo III: Implementación
58
Figura III.11: Paneles con distintas orientaciones.
Entonces, la particularidad a resaltar en la implementación es la transparencia de
estos fenómenos a la hora de definir las grillas. Así, el usuario posee la flexibilidad de
incorporar más superficies a la simulación sin velar por la unificación en la definición de
conectividades.
TIPOS DE PANELES Otro aspecto a tener en cuenta es el tipo de paneles que conforman las grillas. Si
bien, en la mayoría de los casos los paneles son cuadriláteros (incluso si se encuentran
alabeados), la implementación permite utilizar otros formatos. Un caso particular e
interesante es el uso de paneles triangulares como los que se presentan en la Figura III.12,
donde se ilustran una grilla estructurada y una no estructurada con este tipo de paneles.
Figura III.12: Grillas con paneles triangulares, a) estructurada, b) no estructurada.
Luego, si el usuario desea trabajar con paneles como los de la Figura III.12, la
implementación es capaz de reconocer e interpretar estas topologías a partir de las
conectividades, sin necesidad de mayor información. Cabe destacar que la estela que se
convecte de paneles triangulares conservará su topología de cuadriláteros puesto que,
como se expuso oportunamente, sólo se construye con segmentos.
Como característica adicional, el código prevé los casos en los que se utilicen
paneles cuadriláteros de más de cuatro nodos. En la práctica, éstos paneles permiten
generar densificaciones localizadas de la grilla y suelen llamarse “de transición”.
Asimismo, es posible combinar distintos tipos de paneles en una misma grilla sin alterar
los procedimientos de la simulación. Pese a esto, ambas condiciones no se encuentran
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
59
perfectamente definidas por el del UVLM con lo cual, si bien son soportadas por la
aplicación, pueden generar inestabilidades en la simulación.
TIPOS DE LÍNEAS DE CONVECCIÓN Por cada grilla aerodinámica (es decir, aquellas que no son de contorno) inserta
en el modelo se espera convectar al menos una estela. Para ello, es necesario definir, para
la grilla en cuestión, por lo menos una línea de convección. La línea de convección
físicamente identifica el borde desde el que se convectará la estela, y se define en
términos de los componentes de la grilla.
Por su concepción, una línea de convección está formada por nodos y segmentos
que guardan relaciones conectivas entre sí. Sin embargo, a la hora de solicitar al usuario
la definición de la línea, la implementación es capaz de aceptar ambos formatos, es decir,
una línea definida por nodos o por segmentos, proporcionados en orden arbitrario.
Además, en la etapa de pre-proceso se identifica si la línea es cerrada, se encuentra
incompleta o posee elementos repetidos, y se informa oportunamente al respecto.
Como se mencionó, generalmente una grilla se define en términos de sus nodos y
las conectividades que estos guardan con los paneles. Luego, identificar los nodos que
componen la línea de convección es trivial. Este caso se presenta en la Figura III.13, donde
la serie de índices globales de los nodos son suficientes para definir la línea de convección.
No obstante, en algunos casos puede llegar a ser preferible identificar los segmentos que
componen la línea, por ejemplo, cuando la grilla sea importada de una simulación
anterior. El esquema de esta propiedad se encuentra en la Figura III.14 y son los índices
de los segmentos los que definen la línea de convección análoga a la del caso anterior.
Figura III.13: Línea de convección definida por nodos.
Capítulo III: Implementación
60
Figura III.14: Línea de convección definida por segmentos.
III.3.2. DIMENSIONALIZACIÓN El uso de variables adimensionales tradicionalmente se ha implementado en
simulaciones aerodinámicas en general y en las implementaciones de UVLM en
particular. No obstante, y en vista de dar versatilidad a la aplicación desarrollada en el
presente trabajo en cuanto al acoplamiento con otros códigos de simulación, se utilizan
variables dimensionales.
Esta decisión cobra sentido a la hora de utilizar los resultados de salida del UVLM
como datos de entrada de otras aplicaciones que trabajan con variables dimensionales, y
para realimentar el UVLM con las salidas de éstas aplicaciones. Cualquiera sea el caso, la
transformación de variables dimensionales en adimensionales no reviste mayor
complicación y puede implementarse con facilidad debido a la estructura modular del
código, si así fuera necesario.
III.3.3. ESTELA DE SEGMENTOS En esta implementación se optó por eliminar a los paneles como elementos
básicos de las estelas. En su lugar, cada estela se trata como una colección de segmentos
vorticosos independientes, que comparten nodos como conectividades.
En las implementaciones tradicionales, la estela se construye de anillos vorticosos
que se correlacionan con aquellos que componen la grilla adherida. El proceso de
convección con esta configuración es relativamente sencillo, pero acarrea una desventaja
significativa relacionada con la cantidad adicional de cómputos que requiere. Esto es
debido a que la velocidad que induce la estela en un punto se calcula a partir de sus
segmentos, y calcular la vorticidad de los segmentos, a partir de los anillos vorticosos,
implica un procesamiento adicional que puede evitarse.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
61
En contrapartida, estructurar la estela sólo con segmentos complejiza el proceso
de convección, pero reduce sensiblemente la cantidad de cómputos a realizar. Además,
proporciona facilidades a la hora de simular rupturas o interrupciones de la estela. Luego,
no utilizar paneles en la estela constituye una solución de compromiso entre el volumen
de procesamiento, la versatilidad de la simulación y la simplicidad del algoritmo.
La Figura III.15 contrapone esquemáticamente las dos configuraciones de estela
antes mencionadas, aplicadas en la misma grilla. En la configuración tradicional, Figura
III.15 a), los anillos vorticosos de los paneles colindantes a la línea de convección se
transfieren a la estela sin modificaciones, y sólo debe actualizarse su posición a medida
que la simulación avanza. En la Figura III.15 b), en cambio, la información a transferir a
la estela se encuentra en los segmentos que forman la línea de convección y debe
procesarse adecuadamente.
Figura III.15: Tipos de estelas, a) estela de paneles, b) estela de segmentos.
ESTRUCTURACIÓN DE LA ESTELA Desde el punto de vista de la estructura de datos, un objeto de la clase estela
(“WAKE”), a pesar de contar con otros muchos atributos (ver ANEXO 1), puede
interpretarse como un arreglo de objetos de la clase segmentos vorticosos
(“VORTEX_SEGMENT”). Luego, el algoritmo para construir una estela se centra
principalmente en organizar el arreglo de segmentos bajo ciertas directivas que
garanticen la repetitividad y no rompan con la física del fenómeno que representan. Se
distinguen, entonces, cuatro procedimientos para generar y convectar una estela de
segmentos: asignación de memoria, inicialización, generación y actualización.
ASIGNACIÓN DE MEMORIA La estela puede pensarse compuesta por “bloques” definidos como el conjunto de
segmentos (y nodos) que se adicionan en cada paso de convección. La cantidad de
segmentos que contiene la estela se define a partir de prefijar la cantidad de bloques que
se almacenarán y las dimensiones de la línea de convección que la genera. Esto es, se fija
Capítulo III: Implementación
62
como parámetro de la simulación una dimensión máxima de la estela por encima de la
cual los nuevos pasos de convección generados reemplazarán a aquellos más antiguos.
Físicamente, este proceso evoca la disminución en la influencia de los vórtices
convectados a medida que éstos se alejan de la grilla. Luego, se asume que superada cierta
distancia, la influencia se vuelve despreciable y dichos vórtices pueden eliminarse de la
simulación, disminuyendo sensiblemente el volumen de cálculo.
Por otro lado, al no contar con paneles, es necesario garantizar la completitud del
arreglo de segmentos, con la intención de evitar que se generen anillos incompletos que
rompan con la física del problema. Para ello, es conveniente identificar los segmentos de
cierre de cada bloque como aquellos que se convectan “paralelos” a la línea de convección.
Teniendo esto en consideración, se asigna memoria para almacenar el arreglo
calculando la cantidad de segmentos que contendrá la estela,
𝑛𝑉𝑆𝑤𝑎𝑘𝑒 = 𝑊𝑠𝑖𝑧𝑒(2 𝑛𝑉𝑆𝐶𝐿 + 1) + 𝑛𝑉𝑆𝐶𝐿 (III-3)
Donde 𝑛𝑉𝑆𝑤𝑎𝑘𝑒 es la cantidad de segmentos que tendrá la estela, 𝑊𝑠𝑖𝑧𝑒 es la
cantidad de bloques que se almacenarán, y 𝑛𝑉𝑆𝐶𝐿 es la cantidad de segmentos de la línea
de convección.
A modo de ejemplo, considérese la Figura III.16 donde la línea de convección posee
5 segmentos (𝑛𝑉𝑆𝐶𝐿 = 5) y se dimensiona la estela para 3 bloques (𝑊𝑠𝑖𝑧𝑒 = 3), luego se
tiene:
𝑛𝑉𝑆𝑤𝑎𝑘𝑒 = 38 (III-4)
Siguiendo el ejemplo, se esquematiza el arreglo de segmentos vorticosos que
forman la estela en la Figura III.17. Aquí se observa cómo cada bloque se compone de
segmentos “salientes” (o perpendiculares de la línea de convección) y segmentos de
cierre, además de un bloque reducido de segmentos “Init” que completa la última serie
de anillos. Así también, los colores de referencia se correlacionan entre la Figura III.16 y
la Figura III.17, para facilitar el entendimiento de la estructura de datos.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
63
Figura III.16: Estructura de la estela, bloques y segmentos de cierre.
Figura III.17: Esquema de asignación de memoria para la estela.
INICIALIZACIÓN El segundo paso para la construcción de la estela es la inicialización de la misma.
La inicialización se realiza previamente al primer paso de convección y transfiere los
segmentos de la línea de convección a la estela en las posiciones “Init”. De este modo se
proveen los segmentos que garantizan el cierre del último bloque de la estela en los
sucesivos pasos de convección. El proceso de inicialización se representa en la Figura
III.18 a).
Capítulo III: Implementación
64
Figura III.18: Proceso de convección de estela, a) inicialización, b) generación de bloque, c) inserción
del primer bloque, d) inserción del segundo bloque.
GENERACIÓN La generación construye nuevos bloques de nodos y segmentos que luego serán
incorporados a la estructura de datos. En este paso se transfiere la información de los
segmentos del borde de fuga de la grilla a la estela y debe guardarse consistencia con la
física de la simulación.
Desde el punto de vista conceptual, cada uno de los anillos vorticosos que forman
los paneles de la grilla en el borde de ataque se transfieren a la estela (Figura III.19 a)).
No obstante, al no utilizar paneles en la estela, la transferencia de vorticidad debe hacerse
desde los segmentos tal como muestra la Figura III.19 b).
En este caso, se tiene que:
𝐺𝑖𝑡 = Γ𝑖
𝑡 (III-5)
Luego, para replicar el anillo vorticoso de la grilla en la estela, debe ser:
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
65
Γ𝐴 = −Γ𝑖𝑡 ; Γ𝐵 = Γ𝑖
𝑡 ; Γ𝐶 = −Γ𝑖𝑡 ; Γ𝐷 = Γ𝑖
𝑡 (III-6)
Por otro lado, y de acuerdo a la Figura III.19 b), la circulación de aquellos
segmentos que se superponen debe adicionarse considerando su sentido de acción.
Entonces, para generar un nuevo bloque de segmentos como el de la Figura III.18 b),
donde el superíndice hace referencia al paso de tiempo actual, las circulaciones indicadas
se calculan de la siguiente manera:
Γ11 = Γ𝐴
1 Γ𝑖
1 = Γ𝛽1 − Γ𝛼
1, 𝑖 = 2, … ,5 ; 𝛽 = 𝐶, 𝐷, 𝐸 ; 𝛼 = 𝐵, 𝐶, 𝐷 (III-7)
Γ61 = −Γ𝐸
1 Γ𝑗
1 = −Γ𝛾1, 𝑗 = 7, … ,11 ; 𝛾 = 𝐵, 𝐶, 𝐷, 𝐸
(III-8)
Figura III.19: Generación de estela, a) a partir de paneles, b) a partir de segmentos.
Con este ejemplo puede interpretarse la conveniencia de encapsular el proceso de
generación independientemente del resto del algoritmo de convección. Es decir, de las
ecuaciones anteriores se desprende un patrón para la construcción de un bloque de
segmentos que se identifica con un algoritmo recurrente, lo que reduce sensiblemente el
volumen de código a ejecutar en esta etapa.
ACTUALIZACIÓN La actualización de la estela es la última etapa del proceso de convección y es,
quizás, la más compleja desde el punto de vista de la estructura de datos y del algoritmo.
Aquí se implementan dos procedimientos disímiles que tratan por separado los dos
estados de la estela que pueden presentarse. Por un lado, se trata el caso en el que la
estela se encuentra incompleta, es decir que existe un remanente de memoria asignada
para la incorporación de bloques de segmentos y, por otro, el de estela completa donde
indefectiblemente la convección de nuevos bloques implica la eliminación bloques más
antiguos.
Capítulo III: Implementación
66
ACTUALIZACIÓN DE ESTELA INCOMPLETA
Cuando todavía no se alcanzó la cantidad de pasos de convección límite prefijada,
existe espacio en la memoria asignada a la estela para incorporar nuevos bloques. Luego,
el proceso de actualización consiste en copiar el nuevo bloque generado en la posición
libre correspondiente del arreglo de segmentos. En la Figura III.20 se ilustra este
mecanismo para el primer bloque convectado luego de los segmentos “Init”, sin embargo,
es análogo para todos los bloques del arreglo.
Figura III.20: Actualización de bloque en estela incompleta.
Una consideración adicional debe realizarse sobre las circulaciones de los
segmentos de cierre del bloque cargado en el paso anterior que, en el ejemplo de la Figura
III.20, son los segmentos “Init”. Aquí, con el objetivo de completar la representación de
los anillos vorticosos, las circulaciones de los segmentos de cierre del bloque que se
convecta deben sumarse a aquellas correspondientes a los segmentos del paso anterior.
A modo de ejemplo, considérese el caso de la Figura III.18 c), donde luego de
inicializar la estela se incorpora el primer bloque de segmentos, correspondiente al paso
1. Luego de incorporado el bloque, las circulaciones de los segmentos “Init” se modifican
con la adición de las circulaciones de los segmentos de cierre insertados, lo que resulta
en:
Γ𝛼0+ = Γ𝛼
0 + Γ𝑖1, 𝛼 = 𝐴, … , 𝐸 ; 𝑖 = 7, … ,11 (III-9)
Análogamente, en la Figura III.18 d) la inserción del segundo bloque modifica las
circulaciones de los segmentos de cierre del bloque anterior, siendo en este caso:
Γ𝑖1+ = Γ𝑖
1 + Γ𝑖2, 𝑖 = 7, … ,11 (III-10)
Adicionalmente al manejo de las circulaciones de los segmentos, toda la estela
debe ser actualizada en cuanto a su posición. Para esto, todos los nodos deben
desplazarse de acuerdo a la velocidad local, tal y como se realiza en las implementaciones
tradicionales.
ACTUALIZACIÓN DE ESTELA COMPLETA
Como se mencionó, cuando la memoria asignada al arreglo de segmentos que
componen la estela se encuentra ocupada, cada uno de los bloques subsiguientes deberá
reemplazar a uno más antiguo, como se muestra en la Figura III.21.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
67
Figura III.21: Eliminación de bloque para actualización, a) estela completa, b) bloque eliminado.
En cuanto a la estructura de datos, llegado el punto en el que se completa la
memoria asignada, el arreglo se recorre cíclicamente sobrescribiendo los bloques. En este
caso, el bloque más alejado se corresponde con aquél más antiguamente cargado en el
arreglo de segmentos y, más específicamente, es el bloque que se encuentra en el próximo
lugar de memoria.
En la Figura III.22 se esquematiza el proceso de actualización para la estela
completa. En este caso, la inserción del nuevo bloque consiste en tres pasos.
Figura III.22: Actualización de bloque en estela completa.
Primeramente, se corrigen las circulaciones de los segmentos “Init” (Γ𝛼0+, ya
modificados en pasos anteriores), como se ilustra en la Figura III.22. Esta corrección
consiste en sumar a las circulaciones de los segmentos “Init” del paso anterior, las
circulaciones de los segmentos de cierre del bloque que se reemplazará. De este modo, se
recupera la vorticidad de anillo del último bloque de estela luego de la eliminación.
En la Figura III.23 se muestra el comportamiento de un bloque de estela en dos
pasos de tiempo sucesivos. En el paso 𝑖 − 1, Figura III.23 a), el segmento “Init” tiene una
circulación Γ𝑚𝑖−1 que, por construcción y asumiendo que se mantienen las vorticidades de
anillos en la estela es
Capítulo III: Implementación
68
Γ𝑚𝑖−1 = 𝐺1
𝑖 (III-11)
Figura III.23: Corrección de circulación, a) paso i-1, b) paso i.
Del mismo modo, la circulación del segmento intermedio se expresa:
Γ𝑘𝑖−1 = 𝐺2
𝑖 − 𝐺1𝑖 (III-12)
Al avanzar al siguiente paso de tiempo, Figura III.23 b), el último bloque de estela
debe ser eliminado y el segmento que antes era intermedio pasa a ocupar la posición
“Init”. En el paso 𝑖, la circulación de éste segmento debe ser
Γ𝑘𝑖 = 𝐺2
𝑖 (III-13)
para guardar coherencia con la vorticidad de anillo del panel. Luego, reemplazando se
tiene:
𝐺2𝑖 = (𝐺2
𝑖 − 𝐺1𝑖) + 𝐺1
𝑖 = Γ𝑘𝑖−1 + Γ𝑚
𝑖−1 (III-14)
Finalmente, la corrección de circulación se realiza como sigue:
Γ𝑘𝑖 = Γ𝑘
𝑖−1 + Γ𝑚𝑖−1 (III-15)
y se indica con el superíndice “–“ en la Figura III.21.
El segundo paso de la inserción consiste en reemplazar el bloque más antiguo con
el nuevo bloque generado. Volviendo a la Figura III.22, la copia es directa y no requiere
mayor análisis.
Por último, se debe adicionar la circulación de los segmentos de cierre del nuevo
bloque a los correspondientes del bloque anterior. Este proceso es análogo al realizado
con la estela incompleta y permite conservar la coherencia con el fenómeno físico durante
la simulación.
AJUSTE
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
69
Un proceso adicional debe realizarse previo a cada paso de convección que, si bien
no afecta directamente a la estructura de datos de la estela, es fundamental para el
desarrollo de la simulación. La etapa de ajuste se ejecuta previa a cada paso de convección
y garantiza la adherencia entre la estela y la línea de convección de la grilla desde la que
esta se convecta. Este proceso impide que se genere un intersticio entre la grilla y la estela
cuando esta primera se mueve o se deforma. Para ello, en cada paso de tiempo, luego de
actualizar la posición de la grilla adherida, debe actualizarse la posición de la línea de
convección. De este modo, en todo momento la estela y la grilla se encuentren en contacto,
garantizando la coherencia física de la simulación.
En la Figura III.24 se exhibe el proceso de ajuste de la estela ante un movimiento
esquemático de la grilla. En este caso, luego del último paso de convección, la estela se
encuentra correctamente conectada a la grilla (Figura III.24 a)). Seguidamente, en el paso
de tiempo actual la grilla sufre un desplazamiento (debido a la actualización de su
posición) separándose de la estela ya convectada y dejando un desfasaje entre ambas
(Figura III.24 b)). Finalmente, previo al próximo paso se ajusta la posición de la línea de
convección de acuerdo al movimiento de la grilla (Figura III.24 c)).
Figura III.24: Ajuste de estela, a) posición inicial, b) movimiento de la grilla, c) ajuste.
71
Capítulo IV: RESULTADOS Y VALIDACIÓN
IV.1. GENERALIDADES
Habiendo transitado las etapas de análisis, diseño y programación, es posible
efectuar simulaciones con la implementación. Así, el cierre del desarrollo implica
utilizarla para obtener resultados y, evidentemente, todo el desarrollo carece de sentido
si dichos resultados no son correctos. A este respecto, verificar que las salidas del
software sean adecuadas y contrastarlas contra otras versiones o métodos es
fundamental. Luego, el proceso de desarrollo de una aplicación de co-simulación debe
completarse con una exhaustiva etapa de obtención de resultados y validación, la cual
cierra el ciclo del modelo y retroalimenta los pasos anteriores.
En el proceso de validación se recurre a una serie de casos de simulación de
complejidad creciente, que permiten evaluar cada una de las características del código
desarrollado. Primeramente, se analiza una placa plana de gran alargamiento en un
arranque impulsivo. El segundo caso corresponde también a una placa plana a la que se
le impone un movimiento oscilatorio. En tercer lugar, se analiza un modelo de aeronave
con configuración de alas unidas (“joined-wings aircraft”). Por último, se modela el
sistema de reducción de resistencia aerodinámica (“DRS”, por sus siglas en inglés) del
alerón trasero de un automóvil.
Existen dos aspectos a tener en cuenta a la hora de la validación, por un lado, los
resultados numéricos y, por otro, la coherencia física de la simulación (entendida como
la no violación de los principios e hipótesis del UVLM). En cuanto a los resultados
numéricos, pueden tomarse como referencia y compararse para respaldar las salidas del
código, los coeficientes aerodinámicos (resistencia, sustentación, presión), las
circulaciones de anillo, las posiciones de los nodos de la estela, entre otros.
Si bien la coherencia física de la simulación se ve representada por los valores
numéricos, es fácilmente verificable a través de las visualizaciones. La presencia de
vórtices de arranque y punteras, la suavidad en el desarrollo de la estela, la adherencia
entre estelas y grillas aerodinámicas, el cumplimiento de la condición de no penetración,
la interacción entre estelas y grillas u otras estelas, la alineación entre estelas y la
dirección de la corriente libre, son algunos de los aspectos que pueden controlarse en la
visualización y, de no verificarse, proporcionan alertas de potenciales errores. Luego,
siempre que sea posible, la inspección de las salidas gráficas del código proporciona una
fuente de comprobación para la simulación.
Capítulo IV: Resultados y Validación
72
IV.2. CASO 1: PLACA PLANA EN ARRANQUE IMPULSIVO
El caso de análisis por excelencia para los códigos de simulación aerodinámicos es
la placa plana. Esto es debido a su simplicidad, que lo hace fácilmente adaptable a otras
versiones del UVLM, y a sus características geométricas, que permiten compararlo con
otras teorías. Además, tratándose de una superficie única, es propicia para realizar
modificaciones a la malla y analizar distintos tipos de paneles y densidades de la
discretización.
En particular, se analiza la evolución en función del tiempo del coeficiente de
sustentación (𝐶𝐿), hasta el estado estacionario para una placa plana con alargamiento Λ =
20, ángulo de ataque 𝛼 = 10º, y velocidad de la corriente libre 𝑉∞ = 3 (𝑚/𝑠).
Para estas condiciones, se comparan los resultados con la teoría de perfiles
delgados, corregida por alargamiento finito [14], según la cual,
𝐶𝐿 = (2𝜋
1 +2Λ
) 𝛼 (IV-1)
Como parte del análisis también se comparan los resultados con una versión
bidimensional del UVLM (E. Beltramo, et al. [20]), donde se consideraron cuatro y seis
paneles sobre la cuerda.
En cuanto al código en desarrollo, los casos simulados son tres: uno con cuatro
paneles cuadriláteros sobre la cuerda, uno con ocho paneles cuadriláteros sobre la
cuerda, y otro con ocho paneles triangulares sobre la cuerda. Las curvas de resultados se
muestran en la Figura IV.1 y en la Figura IV.2, donde P indica la cantidad de paneles
utilizados para discretizar la cuerda.
Adicionalmente, en la Figura IV.3 se presentan capturas de las simulaciones para
cada uno de los casos mostrados en los gráficos anteriores conjuntamente con una vista
en planta de la semi-envergadura de la placa plana, donde se aprecia la distribución de
coeficiente de presión.
Respecto de la evolución temporal del coeficiente de sustentación, los resultados
obtenidos muestran que en el estado estacionario los valores son aceptablemente
similares en todas las implementaciones y configuraciones evaluadas y, como es de
esperarse, son inferiores a la teoría de perfiles delgados. Sin embargo, la velocidad con la
que se alcanza el estado estacionario difiere sensiblemente respecto de cada caso. En
primer lugar, las implementaciones bidimensionales muestran una tasa de incremento
del 𝐶𝐿 bastante por debajo de sus contrapartes tridimensionales, que tienden más
rápidamente al valor estacionario a medida que se incrementa la cantidad de paneles en
la cuerda. Por otro lado, existe una diferencia entre el uso de paneles cuadriláteros y
triangulares, que se explica en la desalineación entre los puntos de control que produce
la disposición de triángulos sobre la cuerda.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
73
En cuanto a los coeficientes de presión sobre la placa, los resultados muestran que
las distribuciones obtenidas en los tres casos de la Figura IV.3 son similares y representan
lo que se esperaría en un análisis de éste tipo: un pico de presión hacia el borde de ataque
que decae suavemente hasta anularse en el borde de fuga. Por su parte, las estelas
muestran el vórtice de arranque y los dos vórtices de puntera, con una topología
suficientemente similar en los tres casos, incluso utilizando paneles triangulares.
Figura IV.1: Coeficientes de sustentación para placa plana en función del tiempo.
Figura IV.2: Detalle de coeficientes de sustentación para placa plana en función del tiempo.
0
0.2
0.4
0.6
0.8
1
1.2
0 1 2 3 4 5 6 7 8 9 10
CL
Tiempo (s)
Coeficiente de Sustentación
Thin Airfoil Quad, P=8 Quad, P=4 Trian, P=8 UVLM 2D, P=4 UVLM 2D, P=6
0.9
0.95
1
1.05
1.1
7 8 9 10
CL
Tiempo (s)
Coeficiente de Sustentación
Thin Airfoil Quad, P=8 Quad, P=4 Trian, P=8 UVLM 2D, P=4 UVLM 2D, P=6
Capítulo IV: Resultados y Validación
74
Figura IV.3: Placa plana, desarrollo de estela y distribución de Δ𝐶𝑝, a) cuatro paneles cuadriláteros en
la cuerda, b) ocho paneles cuadriláteros en la cuerda, c) ocho paneles triangulares en la cuerda.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
75
IV.3. CASO 2: PLACA PLANA CON MOVIMIENTO
OSCILATORIO IMPUESTO
Continuando con la placa plana como modelo, se incorpora un grado de
complejidad adicional. Aquí se imponen movimientos oscilatorios de cabeceo, variando
el ángulo de ataque (𝛼), y otro de traslación vertical (𝑢). Los valores de ambas
coordenadas se muestran en la Figura IV.4 y en la Figura IV.5, con sus correspondientes
derivadas temporales, para los primeros 10 segundos de simulación. Asimismo, se
incorpora el recorte de estela, para una distancia de seis cuerdas por detrás del borde de
fuga.
Figura IV.4: Coordenadas de movimiento vertical en función del tiempo.
Este caso fue analizado en el trabajo de M. L. Verstraete [21] con una velocidad de
corriente libre 𝑉∞ = 156,9 𝑚/𝑠 y un alargamiento Λ = 10, y se utiliza como referencia.
Luego, se comparan las evoluciones de los coeficientes aerodinámicos (sustentación y
resistencia) en función del tiempo (Figura IV.6 y Figura IV.7, respectivamente).
El principal objetivo de la simulación de este caso es evaluar y comparar los
resultados del código cuando se introduce la cinemática de los cuerpos sólidos. En este
sentido, los valores obtenidos se asemejan suficientemente a los de referencia
(Verstraete [21]), y son consistentes con lo que se espera en función de los parámetros
de la simulación. Sin embargo, pueden notarse algunas discrepancias menores en los
picos de las curvas, las cuales coinciden con el cambio de signo en el ángulo de ataque y
no exceden los valores esperables.
Adicionalmente, en la Figura IV.8 se muestra una visualización en secuencia de la
simulación a medida que los pasos de tiempo avanzan. Aquí, se observa que la estela se
desarrolla suavemente, de manera consistente con la variación del ángulo de ataque y la
-10
-8
-6
-4
-2
0
2
4
6
8
10
-8
-6
-4
-2
0
2
4
6
8
0 1 2 3 4 5 6 7 8 9 10
du
/dt
(ft/
s)
u (
ft)
Tiempo (s)
Movimiento vertical
u du/dt
Capítulo IV: Resultados y Validación
76
posición vertical de la placa y permanece adherida a ésta en todo momento. Además, en
la Figura IV.8. d) se aprecia que los segmentos que forman el vórtice de arranque (los
más antiguamente convectados) fueron descartados de la simulación, en consistencia con
el recorte implementado.
Figura IV.5: Coordenadas de ángulo de ataque en función del tiempo.
Figura IV.6: Coeficientes de sustentación en función del tiempo.
-0.25
-0.2
-0.15
-0.1
-0.05
0
0.05
0.1
0.15
0.2
0.25
-0.2
-0.15
-0.1
-0.05
0
0.05
0.1
0.15
0.2
0 1 2 3 4 5 6 7 8 9 10
dα
/dt
(rad
/se
g)
α(r
ad)
Tiempo (s)
Ángulo de ataque
α dα/dt
-0.8
-0.6
-0.4
-0.2
0
0.2
0.4
0.6
0.8
0 5 10 15 20 25 30 35 40
CL
Tiempo (s)
Coeficiente de SustentaciónImplementación UVLM Verstraete (2016)
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
77
Figura IV.7: Coeficientes de resistencia en función del tiempo.
Figura IV.8: Simulación de placa plana con movimiento oscilatorio impuesto, a) 1 paso de tiempo, b)
25 pasos de tiempo, c) 50 pasos de tiempo, d) 100 pasos de tiempo.
-0.01
0.01
0.03
0.05
0.07
0.09
0.11
0.13
0 5 10 15 20 25 30 35 40
CD
Tiempo (s)
Coeficiente de ResistenciaImplementación UVLM Verstraete (2016)
a) b)
c) d)
Capítulo IV: Resultados y Validación
78
IV.4. CASO 3: MODELO DE AERONAVE CON
CONFIGURACIÓN DE ALAS UNIDAS
El modelo simulado aquí es bastante más complejo que los anteriores y tiene una
correlación con algunos conceptos modernos de aeronaves. En términos generales, la
configuración de alas unidas posee mayor rigidez estructural y reduce la resistencia
aerodinámica respecto de una configuración tradicional. Luego, es posible proyectar
aeronaves más livianas y con mayor autonomía. Dos casos de aeronaves de este tipo se
presentan en la Figura IV.9 y la Figura IV.10, e ilustran el concepto de la simulación.
Figura IV.9: Aeronave con configuración de alas unidas, concepto de artista: Lillian Gipson (fuente:
www.nasa.gov)
Figura IV.10: Aeronave no tripulada con configuración de alas unidas NASA JW1 (fuente:
www.nasa.gov)
Ciertamente, este caso cuenta con un sentido práctico algo más notorio. Aquí, se
consideraron cuatro superficies sustentadoras: dos alas delanteras y dos alas traseras.
Por su parte, el fuselaje se modela como una superficie de contorno donde sólo se exige
la condición de no penetración del flujo. En cuanto al empenaje vertical, a pesar de que
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
79
en este caso también constituye una superficie sustentadora, se omitió la convección de
su estela para evitar ofuscar las visualizaciones.
Para la simulación se considera un arranque impulsivo con velocidad de corriente
libre constante 𝑉∞ = 3 (𝑚/𝑠), con ángulo de ataque , 𝛼 = 10º y ángulo de deslizamiento
𝛽 = 20º, con los siguientes valores:
En la Figura IV.11 se muestra una imagen de la simulación para 𝑡 = 45 𝑠, con un
formato de visualización de estela donde sólo se grafican los nodos para dar simplicidad
a la gráfica.
Figura IV.11: Simulación de aeronave con configuración de alas unidas.
Al contar con diversas superficies (sustentadoras y de contorno) esta simulación
permite analizar fenómenos puntuales que no se presentan en los ejemplos anteriores.
Tal es el caso de la intersección de grillas y, por ende, de sus estelas, como lo muestra la
Figura IV.12. Aquí, se detalla la unión entre las alas trasera y delantera, para analizar la
interacción entre las grillas aerodinámicas y sus estelas correspondientes.
Existen dos aspectos importantes a tener en cuenta cuando se tienen dos o más
grillas aerodinámicas que se unen o intersectan. Por un lado, la existencia de un nodo que
es común a ambas líneas de convección, es decir que de éste punto se convectarán nodos
de ambas estelas a la velocidad local de la corriente, por lo que serán indistinguibles entre
sí. Luego, las estelas deberán permanecer “unidas” en estos nodos durante toda la
simulación. Esto puede observarse en la Figura IV.12, donde los nodos de la estela del ala
delantera (en verde) convectados desde la intersección de las grillas, son análogos a
aquellos del ala trasera (en violeta) convectados desde el mismo punto.
Capítulo IV: Resultados y Validación
80
Figura IV.12: Interacción entre estelas, a) 2 pasos de tiempo, b) 25 pasos de tiempo.
El segundo aspecto a considerar es el vórtice de puntera que genera el ala trasera.
Necesariamente, la diferencia de presión entre el intradós y el extradós del ala trasera
generará un vórtice en la puntera. Si bien, su intensidad se verá disminuida por la
presencia del ala delantera, su influencia seguirá siendo notable sobre la estela de ésta.
Todo esto es coherente con lo ilustrado en la Figura IV.12 b), donde se observa una
perturbación en la estela del ala delantera (en verde) que progresivamente se arrolla
junto con la estela en violeta.
Otra observación que puede realizarse sobre esta simulación es la de la condición
de no penetración sobre las grillas adheridas, en este caso sobre el fuselaje y el empenaje
vertical. Imponer un ángulo de deslizamiento produce que la estela del ala delantera
impacte directamente sobre el fuselaje y el empenaje vertical. Luego, el cumplimiento de
la condición de no penetración exige que la estela rodee ambos cuerpos, como se observa
en el detalle en la Figura IV.13.
Figura IV.13: Condición de no penetración en fuselaje, a) vista superior, b) vista frontal.
Por tratarse de una superficie libre, la estela debe alinearse con la corriente libre
que, en este caso, no está alineada con el eje de la aeronave. Así, la estela del ala delantera
(en verde) se encuentra con el fuselaje primero, y con el empenaje vertical después.
Físicamente, los segmentos vorticosos de la estela se corresponden con líneas materiales
por lo que no deberían atravesar ninguna superficie sólida. Por lo tanto, en la Figura IV.13
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
81
puede observarse cómo la estela rodea suavemente al fuselaje para luego continuar
desarrollándose.
A pesar de la condición de no penetración, puede verse que dos segmentos
vorticosos atraviesan el empenaje vertical. Esto, que en principio contradice la física del
problema, se explica por dos motivos. En primer lugar, por la discretización de la estela,
debido a la cual el desarrollo de ésta está definido por el desplazamiento de sus nodos, y
los segmentos simplemente se representan por conectividad entre ellos. Este
desplazamiento se determina a partir de la velocidad local en la posición del nodo y el
paso de tiempo de la simulación (Δ𝑡). Luego, es posible que para un Δ𝑡 finito, dos nodos
conectados se posicionen a un lado y a otro de una superficie sólida produciendo el efecto
mencionado (Figura IV.13).
En segundo lugar, por la densificación de la grilla que conforma el empenaje
vertical. Teniendo en cuenta que la condición de contorno sólo se impone en los puntos
de control, si la densidad de éstos es relativamente baja, es posible que algunos nodos
atraviesen una superficie que posea pocos paneles, incluso para pasos de tiempo
reducidos.
La solución a este fenómeno consiste en partir, plegar o incluso eliminar los
segmentos vorticosos en conflicto, permitiendo que la estela rodee la superficie sin
atravesarla. Dado que los contornos sólidos (entendidos como límites del dominio), son
el único lugar donde la vorticidad puede generarse o destruirse, es posible realizar las
alternativas propuestas sin contradecir la física de la simulación (Figura IV.14).
Figura IV.14: Alternativas de redistribución de vorticidad, a) eliminación, b) quiebre, c) plegado.
Un último aspecto a destacar en la simulación de la aeronave de alas unidas es
sobre la orientación de los paneles de las grillas. Al tener diversas superficies
aerodinámicas es posible que no todas ellas se definan con las mismas orientaciones y
esto, en principio, puede ser problemático.
La orientación de una superficie o, en este caso, de una grilla aerodinámica, se
define por la dirección de los versores normales de los paneles que la forman. A su vez,
como se mencionó en el Capítulo III, los versores normales se definen a partir del sentido
de numeración de los nodos del panel. Luego, si existen grillas aerodinámicas que fueron
generadas con distintos métodos, es posible que sus orientaciones no sean las mismas
Capítulo IV: Resultados y Validación
82
dentro del modelo de simulación. Este caso debe preverse para que los sentidos positivos
de las circulaciones y coeficientes de presión calculados sobre los paneles sean
consistentes en todo el modelo.
En el ejemplo, las grillas que conforman las alas delanteras fueron generadas
utilizando la herramienta de espejado del mallador. Entonces, las conectividades de los
paneles y, por ende, sus orientaciones son antisimétricas, como se muestra en la Figura
IV.15, donde se omitieron por claridad las grillas del fuselaje y del empenaje vertical. Sin
embargo, las precauciones tomadas al respecto en la implementación hacen que estos
pormenores sean transparentes para la simulación y, en consecuencia, el resultado es
correcto como se observa en la Figura IV.16 donde los coeficientes de presión de las alas
se representan en superficies coloreadas.
Figura IV.15: Orientación de paneles antisimétrica.
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
83
Figura IV.16: Distribución de presión sobre las superficies sustentadoras de la aeronave.
IV.5. CASO 4: SISTEMA DE REDUCCIÓN DE
RESISTENCIA AERODINÁMICA
El DRS es un mecanismo aplicado al arreglo de superficies sustentadoras del
alerón trasero de un automóvil. Este sistema, al accionarse, modifica la posición de las
superficies ampliando el despeje entre ellas con el objetivo de reducir la resistencia
aerodinámica. De este modo, la activación del DRS incrementa la velocidad final del
automóvil, a expensas de la adherencia del eje trasero por la disminución de sustentación
negativa (hacia abajo). En la Figura IV.17 se muestran las dos posiciones alternativas del
DRS de un vehículo de Fórmula 1.
Además de la particularidad práctica de este sistema, el modelo es interesante ya
que tiene la característica de combinar en la simulación los tres tipos de superficies antes
expuestos: grillas aerodinámicas fijas, grillas aerodinámicas móviles y grillas de
contorno. Luego, el modelo cuenta con dos placas laterales, un deflector (fijo) y un flap
(móvil).
La simulación se inicia con el DRS cerrado (desactivado) y, a medida que avanzan
los pasos de tiempo, el sistema se activa dando lugar al movimiento del flap hasta
ubicarse en la posición abierta. Las posiciones inicial y final se muestran en la Figura
IV.18.
Capítulo IV: Resultados y Validación
84
Figura IV.17: DRS de un vehículo de Fórmula 1 (fuente: fi.wikia.com, Mercedes Benz)
Figura IV.18: Posiciones límites del DRS.
Adicionalmente, se incorpora el corte de estela para sólo una de ellas, en este caso
la estela del deflector. Aunque físicamente no es consistente que una estela se desarrolle
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
85
más que otra, se busca con esto validar esta posibilidad. Por otro lado, como condiciones
generales, se define la velocidad de la corriente libre 𝑉∞ = 86,1 (𝑚/𝑠) y el ángulo de ataque
𝛼 = 10º .
En la Figura IV.19 se muestra una secuencia de la simulación para los valores
anteriores, mientras que en la Figura IV.20 se presenta una vista frontal de tres pasos de
tiempo de la misma simulación, indicando el coeficiente de presión de los paneles con
superficies coloreadas.
Figura IV.19: Simulación de DRS, desarrollo de estelas.
Capítulo IV: Resultados y Validación
86
Figura IV.20: Simulación de DRS, coeficientes de presión. a) 10 pasos de tiempo, b) 40 pasos de
tiempo, c) 70 pasos de tiempo.
87
Capítulo V: COMENTARIOS FINALES
V.1. GENERALES
Durante todas las etapas del proceso de realización de este trabajo, surgieron
diversas situaciones en las cuales fue preciso aportar soluciones criteriosas. En definitiva,
la motivación de todo el desarrollo proviene de una dificultad real que afecta a los
problemas de aeroelasticidad computacional en cuanto a la simulación aerodinámica. Por
lo tanto, es necesario en este punto adoptar un enfoque retrospectivo para dilucidar si
dicha motivación fue satisfecha y en qué medida el objetivo propuesto en las notas
introductorias fue alcanzado.
A pesar de esto, concluir sólo con un balance evaluativo no es suficiente. Si se
comprende que el trabajo realizado contribuye en alguna medida al desarrollo de la co-
simulación, el capítulo final resulta oportuno para esbozar dicha contribución. La cual, en
definitiva, hará referencia a la aptitud de la implementación construida y a los
conocimientos adquiridos en el proceso.
Un tercer punto a plantear es el de generar motivaciones adicionales. La intención
es aportar un punto de partida sobre el cual desarrollar una estructura de simulación
computacional multi-física integral. Para ello, se procura un abanico de posibilidades
para trabajos futuros, mencionando aquellas áreas en las que se podría ahondar el
desarrollo.
V.2. CONCLUSIONES
En cuanto al tratamiento de los paradigmas de programación en general y a la OOP
en particular, el presente trabajo reúne un resumen de los aspectos más significativos
que surgieron a lo largo del desarrollo de la implementación, resaltando su relación con
las aplicaciones. Esto constituye un punto de partida que da al lector nociones sobre las
consideraciones realizadas antes de encarar la implementación computacional, la
importancia de dedicar tiempo del desarrollo a realizarlas, y la porción del extenso
camino de aprendizaje recorrido en este sentido. Así, se procuró poner en evidencia la
preponderancia de la elección de un paradigma de programación adecuado, el cual debe
articularse apropiadamente con la fuerte relación que existe entre el enfoque utilizado
para abordar la solución de un problema a través de la co-simulación y la dinámica de
trabajo del grupo de investigación que la desarrolla. En este contexto, una etapa previa
Capítulo V: Comentarios Finales
88
de análisis de alternativas y pre-diseño de soluciones representa una disminución de la
carga de trabajo asociada a la adaptación, modificación, expansión o especificación del
código y a las validaciones correspondientes.
Respecto a la implementación, a lo largo del presente esfuerzo se construyó una
herramienta computacional de simulación fluido-dinámica enmarcada en el paradigma
de la OOP, concebida para el uso eficiente en un grupo de investigación ingenieril,
adaptada para el acoplamiento con otros códigos de simulación, y haciendo énfasis en la
performance. En este proceso se exploró una alternativa a la clásica programación
procedural, procurando vencer las deficiencias que este paradigma impone para el
desarrollo colaborativo y la reutilización de código en grupos de investigación.
El resultado general es una implementación de UVLM que incorpora muchas de
las ventajas de la OOP. Éstas ventajas se hacen evidentes a la hora de incorporar nuevas
características al código, modificar funcionalidades y agregar elementos de simulación.
En particular, la inclusión de nuevos tipos de paneles, la adaptabilidad a distintos
formatos de datos de entrada, el cambio de formato de datos de salida, la variabilidad en
las propiedades de las superficies, la definición de puntos auxiliares para cálculo de
velocidades inducidas, la versatilidad en la descripción de las líneas de convección, son
algunas de las características que se vieron fuertemente favorecidas con el estilo de OOP.
En definitiva, la generación de una estructura de datos base, que permite incorporar
diversos desarrollos de acuerdo a los variantes requerimientos del grupo de
investigación, requiere un paradigma más adecuado que el tradicionalmente utilizado y
encuentra en la OOP soluciones a muchos de sus problemas.
La etapa de validación y resultados, por su parte, proporciona una muestra de la
versatilidad del código a la hora de aplicarse a distintos escenarios. Del mismo modo,
proporciona confianza respecto de la coherencia física de las simulaciones y da una pauta
comparativa respecto de otras implementaciones.
En resumen, el resultado obtenido es alentador y cumplimenta los objetivos
propuestos, los cuales se materializan en una implementación del UVLM diseñada y
construida desde el punto de vista del desarrollo colaborativo de software de simulación.
V.3. TRABAJOS FUTUROS
Considerando la intención de generar posibles espacios para desarrollos
subsiguientes, el presente trabajo representa un punto de partida tanto para desarrollos
en el área de la FSI como en aquellas relacionadas al desarrollo de herramientas
computacionales y al análisis de paradigmas de programación. De aquí se desprenden
varias líneas de trabajo que pueden seguirse, ya sea para completar una implementación
de co-simulación, o bien para ahondar en el tratamiento del desarrollo computacional.
En primer lugar, la implementación de variantes al UVLM constituye una posible
línea de trabajo. Entre ellas, la representación de estelas utilizando partículas vorticosas,
la incorporación de tipos de paneles que permitan realizar una densificación localizada
de grillas, la convección de paneles triangulares, la convección condicionada, etcétera,
Tesis de Maestría en Ciencias de Ingeniería Mención Aeroespacial Martín Eduardo Pérez Segura
89
son algunas de las alternativas. Estas variaciones permiten realizar análisis más precisos
de casos particulares que no se representan adecuadamente con la implementación
tradicional.
Otro pendiente lo constituye la evaluación de estructuras de datos que coloquen
otros elementos (por ejemplo, paneles) como núcleos de la definición de clases. Bajo esta
condición, todo el diseño de clases y las relaciones entre ellas debe redefinirse, lo que
posiblemente tenga aspectos ventajosos.
Siguiendo con la definición de clases, la utilización de otros criterios para ésta y su
comparación frente al SRP es una posible mejora adicional. Idealmente, deberían
confeccionarse diagramas de clases siguiendo distintos criterios, comparar los resultados
e implementar, finalmente, aquel que resulte más adecuado.
Otro tema a considerar son los paradigmas orientados a aspectos y orientados a
componentes para probar su adaptabilidad a las necesidades en consideración. Es decir,
indagar cómo sus principios se acoplan con la co-simulación y si es posible combinarlos
con la OOP.
El incremento en la exigencia de los procesos de evaluación, por su parte, puede
representar otra línea de trabajo a seguir. Esto es, extender los análisis de validación y
aplicabilidad para detectar posibles incompatibilidades o errores. En esta línea también
debe tenerse en cuenta la diversificación de los formatos de salida dando soporte a
distintos visualizadores.
Un aporte adicional lo constituye el análisis del balance entre el nivel de
parametrización del código y su performance. Sería oportuno evaluar hasta qué punto la
programación genérica proporciona una ventaja sin ir en desmedro de los tiempos de
ejecución.
Por último, la utilización de otros lenguajes de programación es una alternativa a
considerar, en conjunto con otros entornos de programación e incluso implementaciones
multilenguaje.
91
REFERENCIAS BIBLIOGRÁFICAS
[1] Hubbert, M. K. Nuclear energy and the fossil fuels. Shell Development Company
Publication No. 95. USA, 1956.
[2] Asociación Mundial de la Energía Eólica - http://www.wwindea.org/.
[3] The Open VOGEL community www.openvogel.com,
https://github.com/OpenVOGEL/OpenVOGEL.
[4] Khun, T. La estructura de las revoluciones científicas. University of Chicago
Press. USA, 1962.
[5] Peter Van Roy. “Programming Paradigms for Dummies: What Every
Programmer Should Know”, Artículo. Université Catholique de Louvain.
Francia, 2012.
[6] Aguilar, L. J. Programación Orientada a Objetos. McGraw Hill. España, 1996.
[7] Wang, A. J. A. y Qian, K. Component-Oriented Programming. Wiley-Interscience.
USA, 2005.
[8] Moreno Nieto, J. M. Introducción a la Programación Orientada a Aspectos.
Proyecto final de carrera de Ingeniería Informática, Universidad de Sevilla.
España, 2005.
[9] Booch, G. Object-Oriented Analysis and Design with Application, Third Edition.
Addison-Wesley. USA, 2007.
[10] Brooks, F. No silver Bullet: Essence and Accidents of Software Engineering. IEEE
Computer vol. 20(4). USA, 1987.
[11] Seidewitz, E. y Stark, M. Towards a General Object-Oriented Software
Development Methodology. First International Conference on Ada
Programming Language Applications. USA, 1986.
Referencias Bibliográficas
92
[12] Glasser, M. Open Verification Methodology Cookbook. Springer. USA, 2009.
[13] Preidikman S. Numerical Simulations of Interactions Among Aerodynamics,
Structural Dynamics, and Control Systems. PhD thesis, Department of
Engineering Science and Mechanics, Virginia Polytechnic Institute and State
University. USA, 1998.
[14] Anderson, J. D. Jr. Fundamentals of Aerodynamics, Fifth Edition. McGraw Hill.
USA, 2010.
[15] Maza, M. S. Desarrollo de Herramientas Numéricas para la Simulación de la
Interacción de Estructuras con un Fluido a Elevado Número de Reynolds. Tesis
de MSC, Facultad de Ingeniería, Universidad Nacional de Río Cuarto. Argentina,
2013.
[16] Van Garrel, A. Development of a Wind Turbine Aerodynamics Simulation
Module. NOVEM BV. Holanda, 2003.
[17] Metcalf, M., Reid, J. y Cohen, M., Modern Fortran Explained. Oxford. USA, 2011.
[18] Markus, A. Modern Fortran in Practice. Cambridge University Press. USA 2012.
[19] Fowler, M. y Kendall, S. UML Gota a Gota. Pearson. Méjico, 1999.
[20] Beltramo, E., Ribero, S., Hümöller, J. M., et al. Modelo electromecánico de un
cosechador aeroelástico de energía. Revista FCECyN, ISSN: 2362-2539.
Universidad Nacional de Córdoba. Argentina, 2018
[21] Verstraete, M. L. Simulaciones Numéricas del Comportamiento Aeroelástico de
Vehículos Aéreos No Tripulados con Alas que Cambian de Forma. Tesis
Doctoral, Facultad de Ingeniería, Universidad Nacional de Río Cuarto,
Argentina, 2016.
[ANEXO 1] Pérez Segura, M. E. Anexo 1: Información del Código. Material digital
complementario del presente trabajo, disponible en:
https://drive.google.com/open?id=1sywCXKk8RaFxWJ34dRpYR1XMICcHrz1t
Córdoba. Argentina. 2018.