Implementación Computacional del Método de Red de …

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.


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.


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.


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


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


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.


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


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


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.


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


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


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


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


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


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.


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


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


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


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


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.


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


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


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


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)


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.


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.


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


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


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


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


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.


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


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.


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


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.


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.


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.


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.


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.


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.


48

Figura III.2: Diagrama de clases en UML.


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


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


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


END TYPE Point

CONTAINS

MODULE classControl_Point

! "Control_Point" extended class type definition ! Specialization of "Point"


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


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"


USE classPoint, only: Point

PUBLIC

TYPE, EXTENDS(Point), Public :: Nodal_Point !Extended type of "Point" !Attributes: INTEGER :: Label REAL, DIMENSION(3) :: InducedSpeed


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


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


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.


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


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


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


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.


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


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.


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


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.


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.


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


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.


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


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:


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.


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.


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


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


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.


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


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.


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


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)


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)


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


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.


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


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


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.


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.


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


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.


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,


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.

http://www.wwindea.org/

http://www.openvogel.com/

https://github.com/OpenVOGEL/OpenVOGEL

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.

https://drive.google.com/open?id=1sywCXKk8RaFxWJ34dRpYR1XMICcHrz1t

Implementación Computacional del Método de Red de …

Documents

Transcript of Implementación Computacional del Método de Red de …