sistemas de control de flujo a lazo cerrado mediante controlador

UNIVERSIDAD DE BUENOS AIRES

Facultad de Ingenierıa

TESIS DE GRADO

Sistema de Control de Flujos a Lazo Cerrado Mediante

Controlador Lineal Basado en Imagenes

Presentada por:Pablo Daniel Roca

Director: Dr. Ing. Guillermo Artana

Octubre de 2013

Resumen

El presente trabajo estudia los sistemas de control de flujos a lazo cerrado de naturaleza predic-tiva. En particular, se centra el estudio en la definicion de un sistema basado en imagenes quecontrole el flujo de un fluido en el experimento prototipo del escurrimiento sobre un cilindro, conposibilidad de implementacion en tiempo real. Se elige este escenario por tratarse de una expe-riencia de oscilacion autosostenida por el flujo, y por lo tanto, con caracterısticas fuertementeno lineales que deben ser sobrellevadas por el controlador lineal en desarrollo.

Se define un sistema que estabiliza la estela del cilindro utilizando el procesamiento deimagenes. A tal fin, se realiza una simulacion numerica sobre el flujo del fluido a traves delcilindro. Se inyectan trazadores pasivos en el escurrimiento y se utilizan imagenes para medir laconcentracion e identificar el modelo AutoRegressive with eXtra inputs (ARX) que caracteriza alsistema fısico. Se implementa un algoritmo Generalized Predictive Controller (GPC) que calculala actuacion necesaria para estabilizar la estela a traves del agregado de cantidad de movimientotangencial a las paredes del cilindro mediante la inyeccion de plasma.

El algoritmo de control es ejecutado desde el codigo de simulacion que queda a la espera deuna respuesta para continuar con el procesamiento. Para ello, se crean interfaces de comunicacionentre el simulador (Fortran) y el controlador (C++ y Matlab). Tanto el diseno de la experienciacomo el desarrollo de los algoritmos se realiza con el objetivo de ser utilizados en un entornode ejecucion real en trabajos futuros. Se realizan algunos avances en el uso de General-PurposeComputing on Graphics Processing Units (GPGPU) mediante CUDA C/C++ sobre sectores delcodigo que requieren alto paralelismo a fin de aumentar la performance en posibles escenariosde tiempo real.

La efectividad del sistema de control y del algoritmo creado son comprobadas mediante di-versas simulaciones numericas para distintos escenarios. Los datos experimentales son analizadosy expuestos junto a posibilidades de mejora para trabajos futuros.

Palabras clave: control, fluidos, lazo cerrado, feedback, ARX, GPC, cilindro, estela, identifica-cion de sistemas, simulacion, controlador lineal, no-linealidades

1

Indice general

1 Introduccion 8

2 Sıntesis del Estado del Arte 11

2.1 Introduccion 12

2.2 Teorıa de Control 132.2.1 Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Estrategias de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2.1 Controlabilidad, Observabilidad y Estabilidad . . . . . . . . . . . . . . 172.2.3 Evolucion de la Teorıa Control . . . . . . . . . . . . . . . . . . . . . . . 172.2.3.1 Teorıa Control Clasica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3.2 Teorıa Control Moderno . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.4 Control Predictivo Basado en Modelo . . . . . . . . . . . . . . . . . . . 19

2.3 Control y Modelos de Fluidodinamica 242.3.1 Generalidades de Modelos de Fluidodinamica . . . . . . . . . . . . . . . 242.3.2 Modelos Basados en la Fısica . . . . . . . . . . . . . . . . . . . . . . . . 252.3.3 Modelos de Caja Negra . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.3.1 Identificacion de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.3.2 Efectos de No-Linealidades . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.4 Avances en Aplicaciones de Control en el Dominio de la Fluidodinamica 30

2.4 Trabajo Interdisciplinario y Aspectos Computacionales 322.4.1 Discretizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.2 Tiempos de Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5 Problematica a Resolver 34

2.6 Conclusiones 35

3 Solucion y Diseno de la Experiencia 36

3.1 Introduccion 37

3.2 Sistema Fısico Bajo Estudio 383.2.1 Estela de un Cilindro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.1.1 Desprendimiento de Vortices . . . . . . . . . . . . . . . . . . . . . . . . 383.2.1.2 Regımenes de Escurrimiento . . . . . . . . . . . . . . . . . . . . . . . . 413.2.2 Actuacion sobre el Cilindro . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.2.1 Actuadores por Rotacion . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.2.2 Actuadores de Plasma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.3 Aplicaciones Particulares de Control sobre el Cilindro . . . . . . . . . . 43

3.3 Diseno y Objetivos de la Experiencia 453.3.1 Configuracion y Dimensiones . . . . . . . . . . . . . . . . . . . . . . . . 453.3.2 Sensores y Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.3 Sıntesis y Objetivos de la Experiencia . . . . . . . . . . . . . . . . . . . 49

3.4 Algoritmo de Identificacion del Sistema 51

3.5 Algoritmo de Control a Lazo Cerrado 54

3.6 Conclusiones 58

4 Ensayo Experimental 59

4.1 Introduccion 60

4.2 Mallado de la Experiencia 614.2.1 Tamano de Celdas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.2 Paso de Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3 Simulacion de la Experiencia 654.3.1 Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3.1.1 usini1.f90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3.1.2 usclim.f90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.4 Comunicacion con el Sistema de Control 754.4.1 Lenguajes Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.4.2 Interaccion entre Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . 764.4.3 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.5 Identificacion del Sistema 814.5.1 Entrenamiento del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 814.5.2 Implementacion del Algoritmo . . . . . . . . . . . . . . . . . . . . . . . 834.5.3 Verificacion del Modelo ARX . . . . . . . . . . . . . . . . . . . . . . . . 84

4.6 Sistema de Control a Lazo Cerrado 904.6.1 Implementacion del Algoritmo . . . . . . . . . . . . . . . . . . . . . . . 904.6.1.1 Inicializacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.6.1.2 Iteracion de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.6.2 Resultados de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.6.2.1 Analisis de Energıa y RMS de las Fluctuaciones en la Estela . . . . . . 974.6.3 Pruebas de Robustez . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.7 Conclusiones 106

5 Conclusiones Generales y Perspectivas 108

5.1 Conclusiones Generales 109

5.2 Trabajos Futuros 111

Apendices 112

A Resena de Control de Fluidos 113A.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.2 Evolucion Historica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

B Mallado de la Experiencia 115B.1 Detalle del Mallado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115B.2 Efectos de Cambios Bruscos en la Malla durante la Simulacion . . . . . 117

C Verificacion de la Identificacion del Sistema 119C.1 Ajuste en Implementacion Matlab . . . . . . . . . . . . . . . . . . . . . 119C.2 Ajuste y Tiempos en Implementacion C++ . . . . . . . . . . . . . . . . 119

D Avances Experimentales para Trabajos Futuros 122D.1 Control Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122D.2 Control con Modelo ARX de Orden Elevado . . . . . . . . . . . . . . . 123D.3 Captura de Imagenes Mediante Camaras Digitales . . . . . . . . . . . . 125D.3.1 PixelFly qe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126D.3.2 Pulnix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126D.3.3 SpeedCam Mini Vis e2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

E Publicaciones 127E.1 Anales de la AFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127E.2 Physics of Fluids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

F Codigos Fuente 152F.1 Extension del Mallado 2D a 3D . . . . . . . . . . . . . . . . . . . . . . . 152F.2 Conversion del Mallado Irregular a una Grilla Cartesiana . . . . . . . . 155F.2.1 chrCleanFolderIfExists.m . . . . . . . . . . . . . . . . . . . . . . . . . . 155F.2.2 chrComputeAverage.m . . . . . . . . . . . . . . . . . . . . . . . . . . . 155F.2.3 chrComputeVorticityAverageForGeoXY.m . . . . . . . . . . . . . . . . 156F.2.4 chrExtractBinaryHeader.m . . . . . . . . . . . . . . . . . . . . . . . . . 156F.2.5 chrFindFiles.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156F.2.6 chrFindFilesAndComputeAverage.m . . . . . . . . . . . . . . . . . . . . 157F.2.7 chrGetAmountOfHeadingCharacters.m . . . . . . . . . . . . . . . . . . 157F.2.8 chrReadBinaryContent.m . . . . . . . . . . . . . . . . . . . . . . . . . . 157F.2.9 chrReadBinaryGeo.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157F.2.10 chrReadVelocity2D.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158F.2.11 chrWriteBinaryContent.m . . . . . . . . . . . . . . . . . . . . . . . . . . 158F.2.12 chrWriteCaseFile.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159F.2.13 geoComputeIntersectionArea.m . . . . . . . . . . . . . . . . . . . . . . . 159F.2.14 geoGetBoundingRectsForDelta.m . . . . . . . . . . . . . . . . . . . . . . 159F.2.15 geoTransformContentToNonXY.m . . . . . . . . . . . . . . . . . . . . . 160

F.2.16 geoTransformContentToXY.m . . . . . . . . . . . . . . . . . . . . . . . 160F.2.17 geoTransformMeshToXYGrid.m . . . . . . . . . . . . . . . . . . . . . . 160F.2.18 polygonArea.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161F.2.19 polygonClip.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162F.3 Calculo de Energıa Cinetica y RMS de las Fluctuaciones . . . . . . . . 163F.3.1 plotEnergy.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163F.3.2 processEnergy.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163F.3.3 processRmsCriteria.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165F.3.4 computeReynoldsTensor.m . . . . . . . . . . . . . . . . . . . . . . . . . 167F.3.5 computeRMS.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167F.3.6 selectIntegrationCoordinates.m . . . . . . . . . . . . . . . . . . . . . . . 167F.4 Simulacion en Code Saturne . . . . . . . . . . . . . . . . . . . . . . . . 167F.4.1 usini1.f90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167F.4.2 usclim.f90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181F.5 Identificador del Sistema en Matlab . . . . . . . . . . . . . . . . . . . . 189F.5.1 lfd arx.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189F.5.2 lfd compare.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191F.5.3 lfd training actuation.m . . . . . . . . . . . . . . . . . . . . . . . . . . . 191F.5.4 lfd training actuation gaussian.m . . . . . . . . . . . . . . . . . . . . . . 192F.5.5 lfd training actuation multiple gaussian.m . . . . . . . . . . . . . . . . . 192F.5.6 lfd training actuation pulse.m . . . . . . . . . . . . . . . . . . . . . . . 192F.5.7 lfd training actuation ramp.m . . . . . . . . . . . . . . . . . . . . . . . 192F.6 Controlador en C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193F.6.1 main.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193F.6.2 Config.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194F.6.3 configuration control.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . 195F.6.4 configuration training.txt . . . . . . . . . . . . . . . . . . . . . . . . . . 196F.6.5 Constants.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196F.6.6 Controller.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197F.6.7 Controller.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198F.6.8 Logger.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201F.6.9 lfd control lagrange init.m . . . . . . . . . . . . . . . . . . . . . . . . . 202F.6.10 lfd control lagrange.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205F.6.11 MatlabExecutor.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206F.6.12 MatlabExecutor.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206F.6.13 Matrix.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207F.6.14 Parser.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209F.6.15 Parser.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209F.6.16 SaturneCommunicator.h . . . . . . . . . . . . . . . . . . . . . . . . . . . 210F.6.17 SaturneCommunicator.cpp . . . . . . . . . . . . . . . . . . . . . . . . . 211

G Codigos Fuente de Avances Experimentales 212G.1 Pruebas de Concepto de Captura de Imagenes . . . . . . . . . . . . . . 212G.1.1 PixelFly qe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212G.1.2 Pulnix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213G.1.3 SpeedCam Mini Vis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213G.2 Pruebas de Concepto de Ident. de Sist. en CUDA C/C++ y C++/GSL 214G.2.1 main.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214G.2.2 arxEngine/ArxSystemIdentification.h . . . . . . . . . . . . . . . . . . . 216

G.2.3 arxEngine/ArxSystemIdentification.cpp . . . . . . . . . . . . . . . . . . 216G.2.4 common/Matrix.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220G.2.5 common/CULAContext.h . . . . . . . . . . . . . . . . . . . . . . . . . . 229G.2.6 common/CULAContext.cpp . . . . . . . . . . . . . . . . . . . . . . . . 229G.2.7 common/Exception.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230G.2.8 common/Exception.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 230G.3 Pruebas de Concepto de Controlador Adaptativo . . . . . . . . . . . . . 231G.3.1 lfd control init.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231G.3.2 lfd control.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Agradecimientos

A Claudia, por todo el tiempo compartido... y el que resta por compartir.A mi familia, por estar siempre presente.A los integrantes del Laboratorio de Fluidodinamica (UBA), por la colaboracion constante,

desinteresada y oportuna que siempre me prestaron. En particular, un agradecimiento especiala Guillermo Artana, Ada Cammilleri y Thomas Duriez que participaron activamente de lasexperiencias y me guiaron en el desarrollo del presente trabajo.

A mis companeros de trabajo, por todo lo que aprendı y crecı profesionalmente durante estosanos.

A mis companeros de facultad, por compartir las dificultades que presenta carrera.A mis companeros del Proyecto Nahual, por demostrar que la computacion tambien sirve

para cambiar algo.A mis companeros de ayudantıa, por introducirme al mundo de la docencia.A los que creen en la ciencia como camino para el desarrollo.A la gente tenaz y trabajadora.

Pablo Daniel Roca, Octubre de 2013

7

Parte 1

Introduccion

8

Sistema de Control de Flujos a Lazo Cerrado Pablo D. Roca

El control del movimiento de fluidos es una disciplina de gran importancia para la industriay la ciencia. Los objetivos de la teorıa clasica de control como el seguimiento de un valor dereferencia o el rechazo frente a perturbaciones son considerados en aplicaciones especıficas defluidodinamica como la reduccion del arrastre o la supresion de inestabilidades que guardan graninteres por su uso practico.

El presente trabajo introduce avances en el ambito del control de la dinamica de los fluidospresentando un sistema de control automatico lineal que pueda ser utilizado en sistemas nolineales y que posibilite su uso fuera de condiciones de laboratorio. A tal fin, se utilizan conceptosde teorıa de control e identificacion de sistemas que en conjunto permiten definir un algoritmogenerico, independiente de la experiencia.

Se escoge al escurrimiento sobre un cilindro como caso de estudio para realizar las simula-ciones pertinentes debido a su importancia como experiencia prototipo para diversos fenomenosde fluidodinamica. Asimismo, su naturaleza de oscilador autosostenido asegura la existenciade marcadas no-linealidades que permiten verificar la bondad del controlador lineal propuesto.Mediante consideraciones generales de control de fluidos, se establece el objetivo de control yesquema de actuacion particulares para dicho escenario. Se propone la inyeccion de filamentosde un trazador pasivo, como el humo, que permite demarcar la estela del cilindro y detectar suscambios mediante el diagnostico por imagenes. El objetivo de control establece que el escalarinyectado adopte un patron determinado que garantice la disminucion de fluctuaciones cercanasal cilindro.

Si bien existen trabajos de control de fluidos orientados a experiencias de control con retroali-mentacion (tambien conocido como control a lazo cerrado) utilizando imagenes, la obtencion deinformacion se realiza mediante tecnicas de Particle Image Velocimetry (PIV) donde se calculala velocidad instantanea de partıculas entre dos imagenes sucesivas. En contraposicion, el me-canismo propuesto permite obtener la informacion del estado instantaneo del sistema medianteuna unica imagen. Se reduce ası el tiempo de transferencia de datos necesarios para la toma dedecisiones y la necesidad de incurrir en calibracion de complicados sistemas de camara, laserspotentes para iluminar la zona ni tecnicas complejas de inyeccion de trazadores. Esto amplıa laposibilidad de uso en experiencias reales.

El controlador desarrollado utiliza tecnicas de lazo cerrado estudiadas en Teorıa de Controlpara permitir un ajuste automatico de la actuacion. Este esquema requiere una representacionmatematica adecuada, en este caso mediante la identificacion del sistema con un modelo decaja negra. Ya establecidos el marco de control y modelizada la experiencia se aplican tecnicasde generacion de plasma en las paredes del cilindro para controlar la estela. Este metodo esestudiado en el campo del control de fluidos por los beneficios potenciales de su rapido tiempode respuesta y carencia de componentes mecanicos.

A continuacion se describen las partes que componen el presente trabajo y su organizacion.La Parte 2 resume el estado del arte de la Teorıa de Control y del Control de Fluidos juntocon los conceptos generales que resultan indispensables para el trabajo en el area. Se focalizaen los controladores predictivos y los escenarios de control a lazo cerrado debido al impacto quetienen en aplicaciones reales. De igual forma, se hace mencion a las tecnicas de modelado pun-tualizando los esquemas de caja negra y la identificacion de dichos sistemas en base al muestreode experiencias. Por ultimo, se especifican ciertos aspectos computacionales importantes en elControl de Fluidos y se define la problematica a resolver.

La Parte 3 sintetiza los conceptos aplicados en el escurrimiento de un flujo sobre el cilindroy las aplicaciones del estudio de dicha experiencia en la vida cotidiana. Luego, se establecen las

9


particularidades del modelo a simular y se especifican los algoritmos disenados para la identifi-cacion del sistema y su control.

La Parte 4 incluye el detalle de la simulacion numerica de la experiencia, la definicion delmallado, la identificacion del sistema, el desarrollo del controlador y su integracion con el si-mulador. Los resultados de la aplicacion de control son expuestos y analizados para validar laefectividad del controlador. Luego, se realizan distintas pruebas con escenarios no ideales, esdecir con la existencia de ruido, para analizar robustez del algoritmo. De la misma forma severifica la adaptabilidad del controlador realizando simulaciones con cambios en las condicionesde entrada que definen la dinamica de la experiencia.

Por ultimo, la Parte 5 resume las conclusiones del estudio realizado y sintetiza las perspectivasfuturas y posibilidades de mejora.

Los distintos apendices incluyen el codigo fuente utilizado para la identificacion de siste-ma y el algoritmo de control ası como las aplicaciones y scripts auxiliares empleadas para elanalisis de la informacion. Se incluyen ademas avances experimentales en sistemas de controladaptativos, empleo de camaras digitales y paralelizacion en General-Purpose Computing onGraphics Processing Units (GPGPU) sobre identificacion de sistemas. Aunque estos casos noforman parte del controlador utilizado, muestran grandes ventajas de implementacion e incre-mentos de performance importantes respecto de los algoritmos usuales y, por lo tanto, debenser tenidos en cuenta en experiencias real-time del sistema de control. Como agregado, se in-cluyen las publicaciones presentadas en la los Anales de la Asociacion Fısica Argentina (AFA)y American Institute of Physics para la revista Physics of Fluids producto de la investigacionrealizada durante el presente trabajo.

10

Parte 2

Sıntesis del Estado del Arte

11

2.1 Introduccion

El presente capıtulo introduce los conceptos fundamentales y definiciones de la Teorıa deControl ası como posibles clasificaciones para controladores de acuerdo a su tipo. A su vez, serealiza una sıntesis sobre la evolucion y etapas claves del control: Teorıa de Control Clasicay Teorıa de Control Moderno, haciendo principal hincapie en el Control Predictivo Basado enModelo.

Una vez definidos los conceptos de control, se exploran las diferentes tecnicas de modelizacionpara fenomenos de fluidodinamica tanto para aquellos basados en la fısica como los de caja negra.Se profundiza en estas ultimas y se ejemplifica su uso en distintas situaciones de control de fluidosreforzando el impacto de las no-linealidades en la identificacion del sistema y posterior uso delmodelo.

Luego, se hace foco en la sub-rama de Control de Fluidos. Se presentan los objetivos mascomunes, aplicaciones conocidas y la importancia del trabajo interdisciplinario junto con losaspectos computacionales mas importantes para el area.

Por ultimo, se brinda una descripcion de la problematica a tratar incluyendo una brevedefinicion de la experiencia prototipo elegida a modo de ejemplo.

12

2.2 Teorıa de Control

2.2.1. Fundamentos

El termino control posee dos acepciones basicas: comprobar algun suceso o dominarlo. Enla Teorıa de Control, el primer significado se entiende como la actividad de verificar o validarque cierta representacion matematica de un suceso fısico tiene un comportamiento satisfactoriofrente a la realidad. La segunda acepcion implica la capacidad de actuar o llevar a cabo ciertasdecisiones para garantizar el comportamiento del suceso en cuestion. En otras palabras, controlarsupone la aplicacion de cierto plan para conseguir un orden determinado.

La teorıa de control involucra el trabajo interdisciplinario de matematicos con especialistas endiversas ramas de la ingenierıa tales como la mecanica, electronica, aeronautica e informatica.Se estudia la forma de influir sobre la dinamica de distintos sistemas mediante tecnicas demedicion, comparacion, calculo y correccion. Los conceptos basicos de la teorıa de control comoretroalimentacion, fluctuaciones y optimizacion pueden encontrarse en situaciones cotidianas yfenomenos naturales que, lejos de los planteos matematicos y complejidades ingenieriles, resultansimples e intuitivos [21, 1].

El concepto de retroalimentacion (o feedback) es utilizado en la teorıa de la evolucion delas especies, propuesta por C. Darwing (1805-1882), para explicar el mecanismo de seleccion a lolargo de perıodos largos de tiempo que resulta responsable de la evolucion. De la misma forma,el feedback resulta importante en modelos estadısticos de epidemiologıa y poblacion como elpropuesto por V. Volterra (1860-1940) para explicar las variaciones en la poblacion de peces alo largo del tiempo y su relacion con la cantidad de predadores con los que comparten el habitat[8]. Dicho modelo, que es uno de los primeros intentos exitosos de explicacion de poblacionbiologica, presenta un mecanismo natural de feedback para mantener el equilibrio de ambasespecies y determinar como inciden los cambios de poblacion de una sobre la tasa de crecimientode la otra.

Otro concepto clave de la teorıa de control es la necesidad de fluctuaciones que refiere a ladificultad de imponer un estado deseado de forma brusca. Por el contrario, resulta mas eficienteaceptar los cambios graduales y oscilaciones que presentan el sistema en estudio. Por ejemplo,el conductor de un vehıculo en movimiento conoce los riesgos de un frenado brusco y opta en sulugar por reducir la velocidad aplicando el freno de forma incremental hasta detener el vehıculo.Los primeros registros de esta idea pertenecen al ingeniero mecanico H.R. Hall al identificar almodelo de control de presion en maquinas de vapor como una aplicacion de la ley economica deoferta y demanda [29]:

“Es curioso el hecho que mientras economistas polıticos reconocen que por la accion dela ley de oferta y demanda deben existir fluctuaciones, esto no es generalmente reconocido pormecanicos en sus esfuerzos de controlar el motor a vapor. El objetivo de los ingenieros mecanicos,como el de los economistas polıticos, no debe ser el deshacerse de todas las fluctuaciones [...] sinodisminuirlas tanto como sea posible, aun dejandolas lo sufientemente altas como para mantener

13


su poder regulatorio.”

Por ultimo, el concepto de optimizacion resulta clave para entender el objetivo del control.Esta idea es estudiada como rama matematica cuya metodologıa base es definir las variables delproblema, un funcional que se desea maximizar o minimizar expresado en dichas variables y lastecnicas que permitan encontrar la condicion optima para el planteo. Este esquema es aplicadoen actividades diarias como ajustar el gas de una cocina para mantenerlo al mınimo necesarioque garantice el hervor del agua o determinar la cantidad de riego que requiere un cultivo paraconseguir la humedad necesaria sin desperdiciar agua.

Dado que las primeras aplicaciones formales de control se centran en problemas de ingenierıa,la terminologıa empleada hereda palabras utilizadas en la industria. A continuacion se definenconceptos basicos de amplio uso en la teorıa de control [47] que son referidos en el presentetrabajo:

Sistema: combinacion de componentes que interactuan con un cierto objetivo. El concepto desistema puede ser aplicado a elementos fısicos (como los sistemas biologicos o fenome-nos fısicos) o a nociones abstractas (como conceptos economicos, flujos de informacion oalgoritmos de procesamiento).

Proceso: conjunto progresivo de operaciones o cambios tanto naturales como artificiales quese suceden de alguna forma y cuyos efectos determinan un resultado o fin. Se puede decirque toda sucesion de operaciones que desea ser controlada es un proceso.

Planta: dispositivo fısico, pieza de algun equipamiento o conjunto de maquinas que opera conalgun objetivo particular que se desea controlar.

Actuador: elemento fısico de la planta que frente a una senal indicada por el controlador puedeoperar sobre la fısica que rige el proceso.

Controlador: sistema encargado de determinar la necesidad de actuacion para conseguir ciertoobjetivo de proceso e informar dicha senal al actuador.

Variables Controladas: cantidad o condicion que es medida y controlada. Tambien se lasconoce como senales de salida del proceso a controlar o, simplemente, salidas.

Variables Manipuladas: cantidad o condicion que puede ser modificada por el controladory cuyos cambios rigen la operacion del actuador. Tambien se las conoce como senalesde entrada del proceso o, simplemente, entradas. Se trata de variables independientesdel proceso que pueden incidir en las variables dependientes, que usualmente se deseancontrolar.

Perturbaciones: senales que perjudican la senal de salida de un sistema. Pueden ser generadasdentro del sistema (internas) o fuera del mismo (externas).

2.2.2. Estrategias de Control

Una posible clasificacion de la estrategia de control elegida para un sistema depende dela forma en que utiliza energıa para su actuacion. La division mas basica que plantea estaclasificacion separa aquellos sistemas cuyos actuadores utilizan energıa para poder forzar alproceso en estudio de aquellos que no emplean energıa. Se habla entonces de sistemas de controlactivo y pasivo respectivamente [22].

Capıtulo 2.2. Teorıa de Control 14


El control pasivo consiste en la disposicion de elementos fısicos dentro de la planta quemodifican la dinamica del proceso bajo estudio, acercandola a una configuracion deseada. Esteesquema de actuacion posee un interes menor para la teorıa de control dada la complejidaden modificar el objetivo de control durante su funcionamiento. Esta circunstancia presenta unlimitante importante para el uso del controlador ya que un cambio en el objetivo esperado(aunque se trate de un pequeno ajuste en el valor deseado) suele requerir la redefinicion delactuador, colocacion del nuevo dispositivo fısico y sucesivas pruebas y ajustes para obtener lanueva dinamica deseada.

Por otro lado, el control activo utiliza energıa para forzar las condiciones del fluido mediantedistintas tecnicas de actuacion. Este tipo de control acepta la posibilidad de variar parametrosde actuacion como la intensidad o frecuencia dentro de ciertos lımites en pleno ciclo de control,es decir, sin necesidad de practicar cambios ni ajustes sobre los actuadores. Los ajustes puedenhacerse manualmente, siendo un humano el que indica la variacion, o mediante un controladorque reaccione frente a los cambios que presente el sistema. Esta flexibilidad permite definir siste-mas de control con cierto grado de inteligencia, esto es, con la posibilidad de variar la actuacionde forma dinamica sin indicaciones humanas. Se definen entonces dos tipos de estrategias decontrol activo: el predeterminado y el reactivo. La Teorıa de Control se centra en esquemas decontrol reactivo mediante el estudio de distintos algoritmos, la medicion de variables de plantay la construccion de dispositivos de actuacion que mejor ajustan al proceso bajo estudio.

A continuacion se resume esta caracterizacion de controladores considerando su fuente deenergıa [22]:

Pasivo: no emplean energıa externa al proceso bajo estudio. Las posibilidades de modificacionessobre el controlador son, por lo general, limitadas.

Activo: utilizan energıa externa para activar los actuadores y controlar el proceso por lo queson mas versatiles.

Predeterminado: los parametros de actuacion son fijos e independientes del estado delproceso. Admite ajustes mediante cambios manuales aplicados por el humano.

Reactivo: la actuacion es definida por un algoritmo de control que reacciona frente amediciones realizadas sobre variables del proceso y del entorno.

El sistema de control puede utilizar sensores dispuestos en la planta para tener informacionsobre las variables controladas o fuera de ella para adquirir datos que permitan modelar lasperturbaciones que recibe el sistema. Por ejemplo, en un sistema de control de temperaturapara un horno de cocina, suponiendo que la variable controlada es la temperatura del centrodel horno, un sensor de temperatura colocado en las paredes internas puede proveer (o aproxi-mar) dicho valor. Por el contrario, un sensor de temperatura colocado en el exterior del hornoprovee informacion importante sobre las perturbaciones que sufre el sistema. En escenarios decontrol pasivo o predeterminado esta informacion no es usada por el controlador pero resultaindispensable para plantear un control reactivo.

Al emplear algoritmos en controladores reactivos se utiliza el concepto de ciclo (bucle o loop)para referirse a los pasos repetitivos que ejecuta el controlador estando en regimen. En estecontexto, si se utilizan valores presentes o pasados de las variables controladas para calcular laactuacion de los proximos pasos se habla de un ciclo de control con feedback. Por el contrario, si seutiliza informacion sobre las perturbaciones externas (que posiblemente aun no hayan afectadoa la planta) se trata de un ciclo de control con prealimentacion (feedforward). El primer caso esel mas comun y recibe la denominacion de control a lazo cerrado (closed-loop control) debido aldibujo esquematico que lo representa (Fig. 2.2.2). En contraposicion, se suele hablar de control



por lazo abierto (open-loop control) para los casos de control predeterminado, donde no existelazo.

Esto da lugar a una clasificacion de acuerdo al ciclo de control que se resume a continuacion:

Lazo Abierto (open-loop): guarda relacion con el control activo predeterminado en el sentidode que una vez definida la actuacion se requiere la intervencion humana para modificarla(Fig. 2.2.1).

Lazo Cerrado (closed-loop): tambien conocido como ciclo con retroalimentacion (feedback)ya que utiliza informacion sobre el estado del sistema para plantear acciones correctivasrespecto de los valores de referencia deseados (Fig. 2.2.2).

Con Prealimentacion (feedforward) se emplea informacion del entorno del sistema para ajus-tar la actuacion y anticipar los efectos de las perturbaciones sobre la planta (Fig. 2.2.3).

Figura 2.2.1: Esquema de control a lazo abierto. No se utiliza informacion sobre el estado del sistema paradeterminar la actuacion.

Figura 2.2.2: Esquema de control a lazo cerrado. Se utiliza feedback del sistema bajo estudio para determinar lasdiferencias que existen respecto de los valores de referencia esperados. Con este error respecto de lo esperado, elcontrolador calcula los valores de entrada que deberıan corregir la salida.

Figura 2.2.3: Controlador feedforward. Se utiliza informacion sobre las perturbaciones para prealimentar al con-trolador y actuar de forma anticipada a que los efectos sean notorios en la salida del sistema.



En el ejemplo de horno con temperatura automatica, un posible sistema de control a lazoabierto recibe del humano la temperatura esperada y activa el sistema de calefaccion a ciertaintensidad precalculada. Un sistema de control a lazo cerrado, por el contrario, activarıa la cale-faccion con una intensidad regulada por la diferencia entre la temperatura de referencia deseaday la medida en el interior del horno. A medida que esta diferencia disminuye, la intensidadde calefaccion converge a un valor pero, en caso de aparecer un cambio brusco en la medicion(por ejemplo, al introducir un producto congelado que reduce la temperatura), el sistema ajustanuevamente la actuacion. Por ultimo, se puede pensar en un sistema que varıa la intensidad decalefaccion dependiendo de la temperatura de referencia y de la temperatura exterior al horno,entregando mayor calor en dıas frıos pero mediante un calculo predefinido, independiente de latemperatura real del interior del horno.

2.2.2.1. Controlabilidad, Observabilidad y Estabilidad

En el caso particular del control a lazo cerrado, resultan importantes las propiedades de con-trolabilidad, observabilidad y estabilidad. Si bien es posible encontrar una definicion matematicaapropiada para estos terminos respecto de las ecuaciones de estado del sistema controlador [72],resulta de suma utilidad comprender la naturaleza de cada uno desde un punto de vista intui-tivo. La controlabilidad determina si todos los modos del sistema pueden ser influenciadospor el controlador de forma arbitraria. Se trata de una propiedad tanto del estado del sistemacomo del sistema de actuacion. De forma mas especıfica se puede hablar de la controlabilidadde salida que indica el control de las variables de salida del sistema independientemente de sipuede controlar variables de estado intermedias o no. La observabilidad esta relacionada conla habilidad del sistema de sensado para medir los cambios de estado de forma confiable. Elsistema es observable si se puede determinar el estado en base a las mediciones de las salidas ylos valores conocidos de las entradas. Como ejemplo de sistema con observabilidad limitada sepuede suponer el caso de una olla a presion hogarena con indicadores de temperatura pero sinsensores de presion y, por lo tanto, no es posible observar el conjunto de estados del sistema. Laestabilidad se asemeja a la controlabilidad pero en este caso exige unicamente que los modosno estables puedan ser controlados. Esta diferenciacion permite indicar en que casos un sistemaestabilizable puede ser suficiente o cuando es necesario un sistema controlable debido a que losmodos estables poseen un papel importante en la respuesta final y se los desea manipular.

2.2.3. Evolucion de la Teorıa Control

A lo largo de los anos, la evolucion de la teorıa de control denota distintas etapas en cuanto amadurez y enfoque de las tecnicas aplicadas. Durante ese avance continuo, se pueden identificardos tendencias que prevalecen y que presentan diferencias notorias respecto a los objetivos delcontrol: la Teorıa de Control Clasica y la Teorıa de Control Moderna.

Si bien existen estudios de control anteriores a la formalizacion de la teorıa, se trata deexperiencias muy diversas y basadas en el empirismo. Con la revolucion industrial aparece lanecesidad de maquinas automaticas y se acelera la investigacion sobre estos metodos [21]. Lainvencion del regulador de presion del motor a vapor por parte de J. Watt (1736-1819) en 1769 fijaun caso de estudio de suma importancia que permite delinear las bases teoricas del control en losanos subsiguientes. El escenario de control es dominado entonces por el ambito industrial hastala decada de 1940, donde los conflictos belicos enfocan la mayor parte del esfuerzo cientıfico decontrol en balıstica y desarrollo aereo y naval. Ya finalizando la decada, la aparicion del terminocybernetics (cibernetica) para referirse al estudio de control y comunicaciones en animales ymaquinas marca un hito importante en el desarrollo de la teorıa de control. Fue el matematico



N. Wiener (1894-1964) quien introduce el termino en 1948 como resultado de diversos trabajosen ciencia cognitiva pero influenciado por los avances de la epoca en tecnicas de comunicacion,mecanica estadıstica y computacion junto a su relacion con procesos de aprendizaje, lenguajes,informacion, sistemas auto-organizados entre otros campos de la ciencia. Al afirmar que lasmaquinas eran sistemas capaces de aprender (o learning machines) al igual que los animales[68] se amplıa el horizonte de aplicaciones para la teorıa de control. Los nuevos ambitos deaplicacion -entre los que se encuentra la inteligencia artificial, automatismo, ciencias de la vision,teorıa de la conversacion o neurociencia- otorgan grandes expectativas a futuro aun en nuestrosdıas. La computacion toma un rol fundamental en este nuevo campo que frente a necesidadde precision numerica, manejo de volumenes importantes de datos y velocidad en el calculo,evoluciona cambiando sus expectativas de uso de una compleja maquina calculadora hacia elambito natural para sistemas de proposito especıfico.

2.2.3.1. Teorıa Control Clasica

La Teorıa de Control Clasica centra su estudio en tecnicas en el dominio de la frecuencia.Este enfoque utiliza tecnicas provenientes de los avances matematicos propuestos por Laplace(1749-1827), Fourier (1768-1830) y Cauchy (1789-1857) para el analisis de sistemas Linealese Invariantes en el Tiempo (LTI) [47, 49]. A tal efecto se definen las variables dependientesdel tiempo y(t) y u(t) para referirse a la salida y entrada del sistema respectivamente. Si bienes posible conocer la relacion entre dichas variables respecto del tiempo, se define la funciontransferencia del sistema segun

H(s) =Y (s)

U(s)

donde Y (s) es la transformada de Laplace de la salida y U(s) es la transformada de Laplace dela entrada. Esta funcion es equivalente a la transformada de la respuesta del sistema al impulso(h(t)) y, por lo tanto, caracteriza al sistema si este es LTI [47]. Para sistemas LTI con variablesde salida y entrada unicas (single-input, single-output o SISO), se puede utilizar H(s) junto conpropiedades de la transformada de Laplace y tecnicas graficas (diagramas de Bode, diagramasde polos y ceros, lugar de las raıces, entre otras) [61] para determinar la respuesta del sistemaa distintas senales de entrada y variaciones de frecuencias. Estos mecanismos fueron usados deforma exhaustiva en comunicaciones y electronica para la solucion de problematicas particularesde las redes de comunicacion de larga distancia que se establecen durante la primer mitad delsiglo XX.

La rama de automatizacion y control industrial mostro grandes avances en sus aplicacionesal incorporar el controlador Proporcional-Integral-Derivativo (PID) que aplica feedback sobre lasvariables controladas en su valores actuales y pasados. Este controlador a lazo cerrado empleaun componente proporcional (P) al error instantaneo, una parte integral (I) que aporta respectode la acumulacion de error por sobre o por debajo de la referencia y un elemento derivativo (D)que entrega sensibilidad ajustando la actuacion en base a la velocidad con que varıa el error(Fig. 2.2.4). Este tipo de controlador sigue siendo de gran utilidad al igual que el concepto defuncion de transferencia sobre el que se basa. Sin embargo, al aumentar la necesidad de controlarsituaciones de multiples variables de entrada y salida (multiple-input, multiple-output o MIMO)donde las variables estan ligadas entre sı, los procedimientos de la Teorıa Clasica se mostraronpor demas engorrosos [61, 47] dando lugar a nuevos mecanismos.



Figura 2.2.4: Esquema de un controlador a lazo cerrado PID. Se puede observar el efecto individual del error, suintegral y su derivada en el dominio del tiempo sobre la actuacion del controlador.

2.2.3.2. Teorıa Control Moderno

En contraste con la Teorıa Clasica, la Teorıa de Control Moderno realiza sus planteos basicosen el dominio del tiempo y sobre sistemas MIMO con un manejo matricial en la matematicade control que otorga transparencia sobre la multiplicidad de variables. Fue R. Kalman (1930-)quien introdujo el concepto de estado como entidad matematica que intercede entre entradas ysalidas permitiendo la existencia de feedback multiple entre las variables de forma natural. Sedefine entonces el estado de un sistema dinamico segun [24]:

“El estado de un sistema dinamico es un conjunto de cantidades fısicas cuya especificacion(en ausencia de excitaciones externas) determina por completo la evolucion del sistema.”

Este concepto enfatiza la existencia de una estructura interna al sistema y la nocion decausalidad de su dinamica. Para un sistema de dimensiones finitas la representacion del estadoesta dada por una ecuacion diferencial vectorial de dimensiones finitas tal que:

x(t) = Ax(t) +Bu(t)

y(t) = Cx(t)

donde x(t) es el vector de variables internas del sistema tambien conocido como vector deestado, u(t) es el vector de las variables manipuladas e y(t) es el vector de variables controladas.Las matrices A, B y C describen las interconexiones en la dinamica del sistema. Usando estarepresentacion, Kalman formalizo las nociones de controlabilidad y observabilidad empleandolasen la propuesta de una ley de control con feedback de la forma:

u(t) = −Kx(t)

donde la matriz de feedback, K, debe ser determinada para minimizar cierta funcion objetivoJ =

∫∞0 (xTQx + uTRu)dt siendo Q y R matrices de pesos constantes. Una vez determinada

K, se asume que no varıa y por este motivo se habla de feedback estatico. Este esquema decontrolador es conocido como Linear Quadratic Gaussian (LQG) y establece las bases para losnuevos algoritmos de esta etapa de la Teorıa de Control.

2.2.4. Control Predictivo Basado en Modelo

El campo del control predictivo fue concebido en el ambiente industrial durante la decadade 1970 como respuesta para automatizacion de plantas quımicas, de energıa y refinerıas al



esquema clasico de control PID. Los motivos principales para la investigacion de nuevas tecnicasse pueden encontrar en las necesidades economicas fijadas por la industria y de difıcil aplicacionen los algoritmos de control clasicos:

Posibilidad de trabajo tan cercano a las restricciones como sea posible (usualmente vincu-lado con la maximizacion del empleo de recursos industriales)

Minimizacion de la variabilidad (que pretende evitar la disparidad en la calidad de pro-ductos)

El controlador LQG presentado en 1960 es considerado pionero en el uso de ciertos conceptospredictivos en controladores pero, aun demostrando buenos resultados en el campo de procesosno lineales, no tuvo aceptacion masiva por la industria. Una de las razones mas importantesde la poca penetracion de mercado reside en barreras culturales con la comunidad industrialque no vieron practicos a los nuevos conceptos de control y prefirieron continuar con estrategiasclasicas que les resultaban mas naturales [51]. Por el contrario, los avances en la teorıa decontrol en la decada de 1970 que culminan en fundamentos del control predictivo resultaron defacil entendimiento y adaptables a la problematica industrial:

Uso de un modelo que permita predicciones sobre las salidas futuras.

Minimizacion de una funcion objetivo mediante actuacion activa.

Ventana temporal del proceso que toma en cuenta las variables controladas y manipuladasdentro de cierto horizonte de prediccion.

Los nuevos algoritmos de control provenientes de la inversion industrial entregan peso teoricoen los conceptos de prediccion y suceden al LQG con mayor exito. El primer caso es provisto porJ. Richalet (1936-) con Model Predictive Heuristic Control (MPHC o tambien conocido comoIDCOM debido al primer sistema de software que lo adopto) que utiliza un modelo discretode respuesta al impulso finito para describir la relacion entre entradas y salidas. Este modeloes conocido como Finite Impulse Response (FIR) y relaciona y(t) con u(t) mediante ciertoscoeficientes de peso, hi, que deben ser determinados. La representacion matematica en tiempodiscreto de dicho modelo es:

y(k) =N∑i=1

hiu(k − i)

El modelo elegido vincula cierto paso del tiempo k de la salida unicamente con la entradade hasta N pasos de tiempo previos. La determinacion de las hi se realiza mediante algoritmosde estimacion que requieren un ajuste constante mediante comparacion con mediciones realesde la planta[51]. Se utiliza al ciclo de control como punto para corregir un modelo que requiererevalidacion continua por ser “inevitablemente imperfecto” [53].

Quizas el aporte conceptual mas importante de este tipo de control es la trayectoria dereferencia (Fig. 2.2.5) que define el camino deseado para los estados futuros de la planta. Estecamino, es interpretado como el comportamiento deseado de la planta convergiendo al valor dereferencia final. Calculando la trayectoria deseada se puede determinar la actuacion necesariapara cada paso y entender la necesidad de un mecanismo de fluctuacion para evitar cambiosbruscos del estado y sus complicaciones. Por ultimo, este esquema enfatiza la relacion Accion→ Comportamiento que, incorporando experiencia de campo y conocimientos sobre el procesoen estudio, se puede extender a Comportamiento Deseado → Accion → Comportamiento[53].



Figura 2.2.5: Posible trayectoria de referencia para la variable controlada (CV) en su camino para alcanzar lareferencia final (Set-point). Se asume que se posee la informacion pasada y del paso de tiempo actual (n) quepermite predecir la salida del proceso h pasos hacia el futuro gracias a un modelo matematico preestablecido (Sm).Definiendo el grado de aceptacion para la diferencia de error entre el proceso y el Set-point (ε(n)) o la variaciondel proceso (∆p) h pasos en el futuro, se puede calcular el valor de variable manipulada (MV) necesario (basadaen Richalet, 2009) [53].

En los anos subsiguientes aparecen nuevos sistemas de control entre los que se destacan Dy-namic Matrix Control (DMC) y Shell Multivariable Optimizing Control (SMOC) por los avancesconceptuales que aplicaron al MPHC. El DMC, introducido en 1980, mantiene un esquema si-milar al MPHC pero modela al sistema mediante la respuesta al escalon en lugar del impulso yprovee tratamiento de restricciones a las variables controlada (aunque no es incluido de formaorganica sino agregado ad-hoc) [44]. El esquema SMOC, presentado en 1988 como un “puenteentre modelos en espacio de estados y los algoritmos MPC”, permite incluir restricciones sobrevariables de salida agregandolas a la funcion objetivo. En efecto, esto es posible para restriccio-nes debiles (tambien llamadas soft) y para el establecimiento de un valor de referencia (setpoint)donde se minimiza la violacion penalizando en la funcion objetivo, pero no para restriccionesduras (hard) que requieren un tratamiento particular (Fig. 2.2.6).



Figura 2.2.6: Tipos de restricciones en las salidas. Tomando el caso de una unica salida, se grafica su magnitud(eje vertical) a lo largo del tiempo (eje horizontal) junto con los valores restringidos (zonas rayadas). Se puedeobservar el efecto directo de las restricciones la salida para el caso hard y el impacto en la funcion objetivo paralos casos soft y setpoint (basado en Qin, 2003) [51].

A pesar del exito de las nuevas generaciones de controladores predictivos ninguno de ellospodıa ser catalogado como de proposito general y ser aplicados tanto en situaciones de plantasimples como en sistemas complejos. En particular, estos ultimos suelen requerir el ajuste fino delos parametros del controlador que resulta muy sensible frente a los supuestos sobre el orden delmodelo y el tiempo de respuesta al control (o dead-time). En particular, el dead-time representala demora entre una modificacion en la variable manipulada y la aparicion de los primeros efectosen la variable controlada.

En 1987 se introduce el Generalized Predictive Controller (GPC) [14, 15] que se centra encalcular los valores de actuacion futuros tales que luego de cierto tiempo no sufran variaciones,es decir se estabilicen en torno de cierto valor definitivo de actuacion. Para ello se predicen lassalidas futuras en respuesta a las entradas calculadas a traves de una funcion objetivo y unhorizonte de tiempo que limita las variaciones.

Esta tecnica trajo beneficios en terminos de robustez y simplicidad de calculo, a la vez queproveyo un mecanismo de auto-ajuste (o self-tuning) que permite al algoritmo sobreponerse a



errores en supuestos sobre orden o dead-time. GPC utiliza el modelo Controlled Auto-Regressiveand Integrated Moving-Average(CARIMA) que vincula valores actuales y pasados de entradasy salidas segun:

y(k) + a1y(k − 1) + · · ·+anay(k − na)

=b1u(k − 1) + · · ·+ bnbu(k − nb)

+ξ(k)

∆+ c1

ξ(k − 1)

∆+ · · ·+ cnc

ξ(k − nc)∆

donde ξ(k) es un variable estocastica que modela el error por perturbaciones, ∆ es el operadorde diferencia y na, nb, nc son lımites de prediccion para las salidas, entradas y perturbaciones.Este modelo resulta apropiado para aplicaciones industriales donde las perturbaciones son noestacionarias como en el caso de saltos de escalon aleatorios o movimientos Brownianos [14]y es uno de los motivos por los que el GPC demuestra mayores areas de aplicacion que suscompetidores.


2.3 Control y Modelos de Fluidodinamica

El area de control de fluidos es una disciplina de gran crecimiento durante los ultimos anosdebido a su importancia en el ambito academico y de ciencia aplicada. La maduracion relativade las distintas disciplinas cientıficas contribuyo en esta rama proveyendo conocimientos clavey descubrimientos que permiten predecir un futuro muy promisorio [7].

En busca de una definicion general del control de fluidos, es posible citar a J. Flatt (1961)que brinda una descripcion para el control en fenomenos de capa lımite que se puede extenderfacilmente a otros escenarios:

“El control de capa lımite incluye cualquier mecanismo o proceso a traves del cual la capalımite del flujo de un fluido es forzada a comportarse de forma diferente de como normalmentese hubiera desarrollado [...]”

Pero la necesidad de forzar la condicion de un fluido esta asociado a un objetivo predefinidoen terminos de las propiedades del fluido. La manipulacion del arrastre, sustentacion, separacionde la capa lımite, repegado de la capa lımite, retardo de la transicion son considerados objetivosparticulares del control de fluidos que pueden combinarse de forma simultanea o en distintasfacetas de una experiencia para definir el objetivo general de control. El Apendice A incluye unabreve resena de la evolucion historica sobre esta rama de la fluidodinamica ası como el detallede objetivos particulares de control de flujos.

Como se explica en el Capıtulo 2.2, un sistema de control a lazo cerrado requiere de unmodelo para predecir estados futuros de las variables. A continuacion se detallan las distintastecnicas de modelizacion utilizadas en fluidodinamica y los avances de aplicacion conseguidos enel area.

2.3.1. Generalidades de Modelos de Fluidodinamica

En su acepcion mas generica, un modelo es una representacion de algun concepto en termi-nos de elementos que existen en cierta area de estudio. El area de estudio determina el lenguajecon el cual se describe el objeto en cuestion y por lo tanto, la informacion que se puede extraerde el.

M. Minsky (1927-) brinda una definicion concisa para modelo [45]:

“Un objeto A∗ es un modelo del objeto A para el observador B, si B puede emplear A∗ pararesponder cuestiones que le interesan acerca de A.”

De esta definicion se desprende una importante reflexion: el detalle del modelo respecto delobjeto depende del detalle de las observaciones que se pretendan realizar. Aun mas, el grado deexactitud del modelo respecto del objeto modelado dependera de las necesidades del estudio.

Es conocido que el estudio de fenomenos fısicos requiere el uso intensivo de herramientasmatematicas. En este contexto, el empleo de modelos matematicos para representar sistemas

24


fısicos ha sido un arma de gran utilidad para su analisis y manipulacionEn el estudio de fluidodinamica, la importancia de los modelos reside principalmente en la

capacidad de predecir la respuesta de un flujo frente a condiciones definidas y como cambiala respuesta al modificarse las condiciones. Si el modelo puede responder a estas preguntas,sera posible estimar la actuacion necesaria para obtener determinado objetivo respecto del flujo.

Las ecuaciones de Navier-Stokes proveen de un modelo matematico completo sobre losproblemas de fluidodinamica. Sin embargo, la complejidad de resolucion que presenta el sis-tema de ecuaciones que gobierna el fenomeno plantea la necesidad de aplicar simplificacionesal modelo. Esto es debido a su no-linealidad y alto orden. Un esquema alternativo consiste eninferir un modelo simplificado a partir de la observacion de un flujo particular y la adopcion desuposiciones sobre su naturaleza. Existen basicamente dos estrategias para obtener modelos quearreglen las observaciones mediante cierto patron: modelos basados en la fısica e identificacionde sistemas.

2.3.2. Modelos Basados en la Fısica

Este tipo de modelos buscan una reduccion de orden sobre el modelo de ecuaciones de Navier-Stokes utilizando una descomposicion modal. Una de las elecciones mas usuales es consideraruna descomposicion del tipo Proper Orthogonal Decomposition (POD) donde se identifican losmodos de mayor energıa y se desechan aquellos que producen un menor impacto. Este esquemaplantea una descomposicion del campo de velocidades del flujo u(x, t) en modos espaciales ytemporales segun:

u(x, t) =n∑

i=1

ai(t)φi(x)

donde las funciones φi(x) representan los n modos espaciales y las ai(t) indican los coeficientestemporales de cada modo. Los φi(x) son obtenidos mediante la resolucion de un problemade autovalores sobre un conjunto de observaciones de u(x, t) y definen una base ortogonal devectores.

El conjunto de ecuaciones del modelo de orden reducido es obtenida al utilizar los n elemen-tos de la base en una una proyeccion de Galerkin sobre las ecuaciones de Navier-Stokes. Esteprocedimiento provee un sistema de ecuaciones diferenciales ordinarias, compuesto de tantasecuaciones como modos retenidos luego del analisis inicial. Sin embargo, el sistema obtenidopuede divergir prematuramente o durante el perıodo de entrenamiento por la anulacion del fac-tor de amortiguamiento que ofrecen los modos mas altos y que fue suprimido por el truncado demodos. Aunque este comportamiento presenta grandes restricciones, existen algunas estrategiaspara evitarlo [3].

Los modos de POD usualmente exhiben multiples frecuencias y resulta difıcil asociar suestructura espacial con las caracterısticas observables del flujo. Como consecuencia, distintosautores se han preguntado sobre la correlacion de dichos modos con magnitudes fısicas medibles.Dado que los modos POD no pueden ser asociados a estructuras coherentes del flujo en todos loscasos, la base de funciones utilizadas para la proyeccion puede no ser lo suficientemente ampliapara expresar las diversas condiciones del flujo. Se conocen esfuerzos recientes en mejorar lacalidad de la base y remediar esta limitacion [58].

Otro inconveniente de este esquema es la limitacion para incluir estımulos externos, tanto losasociados como actuaciones de control como aquellos que resultan de perturbaciones autonomasy fuerzan el estado del flujo. Dentro de las bondades del esquema POD sobresale la posibilidadde definir facilmente la funcion objetivo del control. Cuando se desea minimizar las fluctuacionesdel flujo, es posible plantear la minimizacion del total de energıa asociada a las fluctuaciones

Capıtulo 2.3. Control y Modelos de Fluidodinamica 25


sobre un sector del flujo. Esa magnitud es determinada con los coeficientes temporales de losmodos (llamados chronos) [10].

Alternativamente, existen los Modelos de Orden Reducido (Reduced Order Models o ROM)que consideran los llamados modos globales, pero esta estrategia no presenta buenos resultadospara todas las situaciones [5]. Uno de los requerimientos mas restrictivos de los esquemas ROMes la necesidad de disponer del campo de velocidades del flujo para generar el modelo. Desde elpunto de vista de las aplicaciones practicas, la obtencion del campo de velocidades en tiemporeal constituye un gran impedimento. Es por ello que este tipo de modelos se limita a simula-ciones numericas o experiencias en tuneles de viento equipados con sistemas de Particle ImageVelocimetry (PIV) de mayor o menor complejidad. Incluso en estos casos existen problemasasociados con la robustez del modelo frente a cambios en el dominio.

2.3.3. Modelos de Caja Negra

En contraposicion a los modelos basados en la fısica del problema, el esquema de identificacionde sistemas utiliza modelos de caja negra que responden al sistema fısico. En este caso seemplean tecnicas empıricas y un conjunto de mediciones sobre la experiencia para elegir unaparametrizacion adecuada y determinar los parametros que mejor ajustan a los valores medidos.

AR

Una de las metodologıas de identificacion de sistemas mas utilizadas se basa en relacionesauto-regresivas (AutoRegressive o AR) entre los valores el estado del sistema en el tiempo actualy pasados. El ejemplo mas simple de un modelo AR consta de la siguiente relacion entre variables:

y(k) =

p∑i=1

αiy(k − i)

donde y(k) representa la variable observable en el tiempo k, p es el horizonte de regresion y αi

es un coeficiente de peso para el tiempo k − i. El modelo tendra un buen ajuste si la relacionfijada por los αi existe en el sistema fısico y se mantiene a medida que avanza el paso de tiempok dentro de la ventana definida por los p coeficientes αi. El modelo asume que no existe relacioncon variables para i > k o que la misma posee un αi despreciable.

ARX

Otro ejemplo de modelo autorregresivo contempla la existencia de entradas externas al sis-tema que condicionan el comportamiento de las variables observables del problema fısico enestudio. Las entradas actuan como variables independientes del problema mientras que las sali-das son dependientes o ligadas. En estos casos se habla de un modelo AutoRegresive with eXtrainputs (ARX) que en contextos de econometrıa se conoce como AutoRegresive with eXogenousvariables [42]. Se plantea la siguiente relacion entre variables para este tipo de modelos:

y(k) + a1y(k − 1) + · · ·+ aNay(k −Na) =

b0u(k) + b1u(k − 1) + · · ·+ bNbu(k −Nb)

que tambien puede expresarse como

y(k) +

Na∑i=1

aiy(k − i) =

Nb∑i=0

biu(k − i)



donde u(k) representa la variable externa independiente (en los sistemas bajo estudio sera lavariable de control), Na y Nb son los lımites de auto-regresion para los coeficientes ai y birespectivamente. En este modelo se admite la dependencia de y(k) respecto de u(k) para eltiempo actual y tiempos pasados. Esta dependencia resulta evidente al despejar la salida deltiempo actual (y(k)) y observar que para predecir dicho valor, es necesario contar con valoresprevios de y, valores previos de u y el valor de u en el tiempo actual (u(k)).

Los ejemplos anteriores contemplan la existencia de variables de entrada y salida unicas; setrata de sistemas SISO. Para modelos complejos, donde se define para cada paso de tiempo unvector de estado que incluye los valores de una o mas variables observables junto con una o masvariables de control, nos encontramos con sistemas MIMO. En este ultimo caso, las variables u ey se transforman en vectores (un componente de u por cada entrada y un componente de y porcada salida, para cada paso de tiempo). Sin cambios en la ecuacion, se la puede extender a laforma matricial para representar ese esquema si entendemos a u(k), y(k) como vectores columnay ai, bi matrices con dimensiones apropiadas.

Por ultimo, los coeficientes ai y bi se pueden agrupar utilizando una notacion reducida:

A(q)y(k) = B(q)u(k)

donde se definen las matrices de polinomios

A(q) = I + a1q−1 + · · ·+ aNaq

−NaB(q) = b0 + b1q−1 + · · ·+ bNbq

−Nb

siendo q−1 el operador de corrimiento:

q−nf(k) = f(k − n)

En todos los casos se debe entender la existencia de un termino de error e en cualquiera delos lados de la igualdad que corrige las incertezas que provoca el modelo de caja negra. Estemodelo matematico admite una representacion por bloques que se puede observar en la Fig.2.3.1.

Figura 2.3.1: Diagrama de bloques de un modelo ARX.

ARMAX

Una extension del modelo ARX se obtiene al considerar los efectos del ruido blanco y mo-delarlo con una media movil. En este caso se plantea el mismo tratamiento que el recibido porlas entradas de control donde se entrega distinto peso al ruido originado en el tiempo actualfrente a tiempos pasados. Dicho peso se modela mediante una matriz de coeficientes (en estecaso C(q)) y utilizando conocimientos previos sobre el orden de magnitud del ruido que aceptala experiencia. Este esquema se conoce como AutoRegressive with Moving Average and eXtrainputs (ARMAX) y se define mediante la siguiente relacion entre variables:

A(q)y(k) = B(q)u(k) + C(q)e(k)



donde e(k) representa el valor de error o ruido para el tiempo k. Un posible diagrama de bloquespara este esquema puede observarse en la Fig. 2.3.2.

Figura 2.3.2: Diagrama de bloques de un modelo ARMAX.

En este caso decimos que el modelo contempla la dinamica de los errores y que estos poseenun origen comun con las entradas u para afectar luego a la salida medida y segun puede verse enel diagrama. Existen otros modelos de la misma naturaleza lineal y auto-regresiva que planteanuna fuente de errores en la medicion de y. Tambien resulta factible la modelizacion de errores enambos extremos del proceso con el agregado de una nueva variable de error y su correspondientematriz de coeficientes. Es importante remarcar que al aumentar la complejidad del modeloa utilizar resulta mas difıcil definir la configuracion de parametros apropiada para reflejar alfenomeno en estudio. Por estos motivos es conveniente utilizar el modelo mas simple que otorguebuenos resultados, escalando de forma progresiva en complejidad de ser necesario.

2.3.3.1. Identificacion de Sistemas

La identificacion de sistemas cobra gran relevancia como campo de estudio para la obtencionde modelos de caja negra que representen fielmente el sistema fısico. El modelo elegido suele serpredefinido en base a preconceptos o suposiciones sobre la experiencia y sus caracterısticas. Laeleccion del tipo de modelo y sus parametros basicos como orden u horizontes de tiempo suelefundamentarse en los conocimientos sobre el fenomeno pero aceptando que seran necesariosajustes posteriores en base a la exactitud que demuestre el modelo.

A su vez, es necesario definir las variables de estado a medir y determinar cuales se considerandependientes (outputs para modelos auto-regresivos) y cuales independientes (inputs). Luego, serealiza un muestreo dentro del ambito de una experiencia controlada y el conjunto de vectores deestado obtenidos son utilizados para estimar los parametros del modelo matematico que mejorlos ajustan. A tal fin, las tecnicas de estimacion de parametros suelen plantear la minimizaciondel error que se presenta entre el valor real medido y una prediccion de dicho valor medianteel uso del modelo matematico. La tecnica de estimacion por cuadrados mınimos (Least SquaresEstimates o LSE) y sus variaciones son las de mayor aceptacion debido a caracterısticas comoconvergencia de la estimacion, estabilidad y robustez.

La aplicacion practica de estas tecnicas al campo del control de fluidos suele requerir de lamedicion del campo de velocidades del fluido en una etapa previa su uso en el control. Esta etapasuele denominarse fase de entrenamiento y puede incluir la contemplacion de la experiencia fısicapara su posterior caracterizacion o la necesidad de aplicar cierta actuacion para forzar el flujo.



Este ultimo caso permite obtener la relacion contemplada por los modelos ARX y ARMAXentre los parametros de entrada y la salida. Es conveniente hacer uso de un amplio espectrode frecuencia en la actuacion de entrenamiento para asegurar que las mediciones recolectadasson significativas de la relacion entre entradas y salidas. El empleo de pulsos en la actuacionsumada a la suposicion de linealidad del sistema deberıa permitir una correcta prediccion enbase a entrada de senales diversas, sin embargo no hay un criterio universalmente aceptado parafijar caracterısticas del pulso como duracion, amplitud, tiempo de descanso anterior y posterior,etc.

2.3.3.2. Efectos de No-Linealidades

Un inconveniente conocido en las estrategias antes descritas es la suposicion de linealidaddel modelo. En efecto, los modelos de caja negra ejemplificados (ARX y ARMAX) son linealesy asumen que el fenomeno que modelan posee caracterısticas lineales o al menos, se puedegarantizar su linealidad dentro de un entorno de trabajo. La respuesta predictiva del modelode caja negra dejara de ser precisa fuera de ese entorno, mostrara grandes diferencias con elfenomeno o divergira; dependiendo de el sistema fısico bajo estudio. Existen modelos de cajanegra no lineales entre los que se destacan las redes neuronales, Wavelets y Kernel Estimators[42] que no seran abordados en el presente trabajo.

Amplificadores de Ruido y Osciladores Auto-sostenidos

Si bien el caracter no lineal de la mayorıa de los fluidos en estudio esta relacionado conlas no-linealidades presentes en las ecuaciones de Navier-Stokes, esto no afecta con la mismaintensidad a todos los fenomenos. En efecto, la naturaleza inherente del flujo estudiado define dosclasificaciones basicas con grandes diferencias en las no-linealidades presentes: los amplificadoresde ruido y los osciladores auto-sostenidos.

Los amplificadores de ruido son altamente sensibles a las perturbaciones que son trasladadasfuertemente al resto del sistema. En estas experiencias, la modelizacion de las fuentes de ruido eincertezas resulta fundamental para capturar la dinamica del proceso y poder predecir el estadofuturo del sistema. Se puede reconocer sistemas amplificadores de ruido en varias aplicacionescomo la separacion de flujos de superficies planas, separacion de la capa lımite o problemas comoel salto por escalon.

Algunos flujos de naturaleza oscilatoria, por otro lado, presentan inestabilidades globalesque sostienen sus fluctuaciones y los vuelven poco sensibles a perturbaciones externas. En estoscontextos, el modelado de las perturbaciones no resulta tan importante como la captura dela dinamica de las inestabilidades propias. En el proceso de suprimir dichas inestabilidades yamortiguar el proceso oscilatorio se refuerzan las caracterısticas no-lineales del sistema.

Control de Sistemas No-Lineales Mediante Modelos Lineales

Para captar la dinamica de los fenomenos en sistemas fuertemente no-lineales como lososciladores auto-sostenidos, la eleccion mas natural es el uso de modelos no-lineales. Sin embargo,las dificultades computacionales y los problemas para relacionarlos con la fısica del sistema suelenreducir sensiblemente los beneficios de este esquema. En [31] se encuentra una discusion sobredistintos acercamientos al control de flujos no-lineales con sistemas de control lineales. En elcaso particular del control de la estela de un cilindro, se proponen estrategias basadas en redesneuronales [16]. Tambien es posible el uso de otras estrategias como algoritmos de identificacionadaptativos o la estabilizacion del flujo de forma previa a la identificacion del sistema [11].



En cualquiera de los casos, es importante remarcar que la construccion de un modelo simpleque permita un control efectivo y el uso de leyes de feedback es mas importante que la precisiony la exactitud con que describen el fenomeno [31].

En ese sentido, la posibilidad de utilizar simples modelos lineales de caja negra como ARXy ARMAX resulta por demas atractiva. Es posible encontrar esfuerzos en estudios de teorıa decontrol que utilizan ARMAX como modelo del sistema [30]. Aunque esta eleccion entregarıaun sistema mas robusto frente a la aparicion de ruidos, el empleo de control mediante ARX fueampliamente utilizado [4, 35, 36, 31] debido a la mayor simpleza y buenos resultados conseguidos.

2.3.4. Avances en Aplicaciones de Control en el Dominio de laFluidodinamica

En la actualidad, los mayores esfuerzos de investigacion estan dirigidos al control reactivopor las perspectivas a futuro que presenta su flexibilidad. Esto no significa que las tecnicas decontrol pasiva o activa predeterminada carezcan de utilidad. Al contrario, las estrategias decontrol pasivas suelen tener una gran aceptacion para aplicaciones reales debido a su bajo costode diseno, construccion y mantenimiento.

En dispositivos de control pasivo, la accion es permanente y no se encuentra preparadapara el ajuste dinamico de los parametros de control durante la experiencia debido a su fuertevinculacion con la estructura original del experimento. Esta metodologıa puede ser encontradaen la colocacion de generadores de vortices [41, 27, 20], placas de separacion a lo largo de la lıneacentral de la estela de un cilindro [54, 55] y cilindros de control de tamano menor al cilindrocontrolado [9].

Respecto del control predeterminado, es sabido que la mayor parte del trabajo experi-mental de control de fluidos fue realizado con este esquema de lazo abierto [17]. El monitoreode estos estudios frente a variaciones en los parametros de actuacion permitio obtener un buennivel de conocimiento sobre las dinamicas de los distintos fenomenos antes de emprender es-tudios a lazo cerrado. Ejemplos tıpicos de actuadores involucrados en este tipo de control sonlos j ets pulsados sinteticos [27, 38], dispositivos mecanicos ajustables, cilindros rotantes [66] oactuadores de plasma [18, 4, 46, 34, 56]. Es importante destacar que estas experiencias de controlpueden ser adaptadas y utilizar algoritmos de lazo cerrado gracias a las conclusiones obtenidasdurante su instrumentacion a lazo abierto.

En contraposicion al control predeterminado, el uso de control reactivo deberıa implicarmenores cantidades de energıa empleada. Mas aun, deberıa permitir su aplicacion en un amplioentorno de operaciones, dado que el controlador adapta su respuesta en pos de conseguir unobjetivo prefijado. Tanto los algoritmos de feedforward como los de feedback deben vincular losvalores de la salida medida en los sensores con la definicion de entradas para el actuador.

Se conocen trabajos a lazo cerrado con distintas tecnicas de actuacion y algoritmos de control.Se tiene referencias sobre actuaciones de succion/soplado para contrarrestar la separacion delflujo sobre una superficie plana [31] (ARX y control optimal lineal), transpiracion normal depared (mediante succion/soplado) para cancelar la interaccion con vortices incidentes [39] (leyde control lineal sobre un arreglo de sensores), inyeccion de cantidad de movimiento para reducirla separacion de la capa lımite en una superficie plana [30] (ARMAX y control LQG) y controlarlas fluctuaciones de presion en una cavidad de tonos mediante el movimiento mecanico de susbordes [35, 36] (ARX y control GPC). Se conocen ademas, escenarios de control aplicados ala experiencia prototipo de cilindros. En esta lınea se han utilizado tecnicas como inyeccion desonido en las paredes de un cilindro para cancelar el desprendimiento de vortices mediante elsensado del flujo de masa [32] (amplificacion y corrimiento de fase sobre medicion en sensor) yactuadores piezoelectricos sobre cilindros flexibles [71] (control PID).



En todos los casos se trata de experiencias con controladores lineales con resultadosexitosos. Sin embargo, se debe remarcar que las experiencias sobre las que fueron comprobadosno guardan un caracter no-lineal fuerte, por tratarse de sistemas amplificadores de ruido, o talesefectos son disminuidos por los rangos de amplitud o velocidad utilizados. Como agregado, losefectos de excluir ciertas no-linealidades del modelo matematico del problema afectan el ajustede los parametros al igual que la definicion de una funcion objetivo como se describe en [30].

Por otro lado, se conocen casos exitosos de controladores no-lineales que implican dis-tintos grados de complejidad. Como caso de baja complejidad se puede mencionar el controlmediante oscilaciones del cilindro para cancelar las estabilidades de su estela [64], donde se apli-ca una ley de control no-lineal sobre las mediciones del sensor. Si bien se obtuvieron buenosresultados, se trata de un esquema particular al caso bajo estudio y de difıcil extension a otrasexperiencias. Como ejemplo de mayor complejidad se conocen aplicaciones exitosas de redesneuronales aplicadas mediante rotaciones del cilindro [26]. En esta situacion se utilizan estruc-turas de decision que no se pueden relacionar con las magnitudes fısicas conocidas del problema,agregando una complicacion extra para adaptar el sistema a otras experiencias.


2.4 Trabajo Interdisciplinario y AspectosComputacionales

Trabajo Interdisciplinario

Durante siglos, el trabajo cientıfico baso su progreso en la especializacion bajo diversas dis-ciplinas. La especializacion permitio aislar las distintas problematicas y conseguir una mejorpreparacion de los investigadores en cuanto a tecnicas y conocimientos particulares. Pero a me-dida que las ramas cientıficas se hicieron mas y mas complejas, el enfoque de trabajo se torno masestrecho y aislado de las otras. Esta tendencia que permitio enormes avances cientıficos duran-te el siglo XX, resolviendo preguntas de gran complejidad e interes, se encuentra en retrocesodando lugar al auge del trabajo interdisciplinario. Sin embargo, el cambio de enfoque requieremodificaciones en los habitos de trabajo y mentalidad de los investigadores que no siempre sonaceptadas. En algunos casos se trata de complicaciones en la implementacion mientra que enotras son preconceptos o barreras mentales donde frases como “fuera de mi area” resultan pordemas frecuentes [7].

Este nuevo enfoque no solo favorece la rama de control de fluidos sino que sin el serıa impo-sible pensar en un crecimiento sostenido de la misma. Las nuevas competencias requieren cono-cimientos de areas tales como la fluidomecanica, matematica, ingenierıa de control, electronicay computacion que deben cooperar y coordinar esfuerzos. En este sentido, es necesario reforzarla necesidad de un enfoque amplio, del trabajo interdisciplinario y de un lenguage comun entrelas partes.

Aspectos Computacionales

Uno de los aspectos computacionales mas importantes del control de fluidos recae en lagran capacidad de procesamiento que requieren tanto las simulaciones como las experiencias delaboratorio. En efecto, la discretizacion de la dinamica de un fluido se expresa con la presion yel campo de velocidades instantaneo para los puntos que lo conforman. Esto implica una grancantidad de valores para describir cada experiencia que fijan de forma indirecta los tiempos decomputo necesarios. En este contexto, la discretizacion temporal y espacial elegidas determinanlas dimensiones del problema mediante un muestreo con cierta peridicidad y la recoleccion decierta cantidad de puntos. En estas condiciones, resulta importante evaluar los requisitos deprocesamiento de los algoritmos de control aplicados.

2.4.1. Discretizacion

La teorıa de fluidodinamica tiene sus bases en el estudio de funciones continuas en el tiempo.Gran parte de su bibliografıa y avance teorico se sustenta en formulaciones de tiempo continuoque contrastan con el enfoque de tiempo discreto propuesto en Teorıa de Control [61].

Lejos de pretender un analisis detallado del impacto que posee la discretizacion de senalescontinuas y el efecto que tiene sobre su espectro en frecuencias [49, 48], es importante entender

32


a la discretizacion como una necesidad de la rama de control dentro de la fluidodinamica. Elfactor mas importante en este sentido esta dado por el empleo de control reactivo y la fuertenecesidad de utilizar computadoras o microcontroladores para definir sus bucles de control.Estos dispositivos no admiten el manejo de magnitudes continuas sino que requieren algun tipode conversion analogico-digital de las senales de entrada y salida.

En este contexto, el desarrollo de los distintos esquemas de control de fluidos requiere ladiscretizacion de las ecuaciones de Navier-Stokes, en tiempo continuo, consideradas basicas parael estudio de la fluidodinamica [31]. Como alternativa a la discretizacion de ecuaciones, es posibleoptar por modelos de caja negra basados en muestras del proceso bajo estudio que establecende forma natural el entorno de trabajo digital para algoritmos de control [31].

2.4.2. Tiempos de Procesamiento

Es importante destacar que muchas de las experiencias sobre las que fueron ideadas lasdistintas estrategias que propone la teorıa de control poseen tiempos caracterısticos elevados yuna cantidad reducida de puntos de observacion. Esto se observa claramente en las experienciasque demuestran la efectividad del controlador GPC [15] donde el tiempo de muestreo es 1s contiempos de respuesta de 160 muestras. Si bien se verifico la efectividad de las estrategias decontrol y de los sistemas implementados bajo dichos entornos, existen ordenes de magnitud dediferencia respecto de los fenomenos usuales de fluidodinamica. Trabajos recientes de control deturbulencias muestran perıodos de 0,67s para el fenomeno caracterıstico de la experiencia, eneste caso el desprendimiento de vortices en un cilindro [18]. Otra implementacion de laboratorio,que implica velocidades de muestreo de menor perıodo para captar la dinamica del sistemarefiere perıodos caracterısticos de 0,098s con frecuencias de muestreo de 1Khz para obtener uncontrolador a lazo cerrado del tipo PID para la reduccion del efecto de arrastre sobre un cuerporomo [6].

Estas caracterısticas limitan la cantidad de informacion que puede ser procesada en tiemporeal para garantizar que el controlador actue dentro de los lapsos de tiempo previstos.

Varios investigadores han sugerido que hasta que se observen mejoras en las condiciones decomputo y la relacion con el costo asociado, no serıa factible el uso de sistemas de control contales caracterısticas [22]. En este sentido, el avance en el poder de computo obtenido durante losultimos anos tanto en supercomputadoras como en equipos convencionales alcanzo capacidadesque permiten pensar procesamiento de informacion de fluidos en tiempo real. Las mejoras envelocidad de procesamiento, espacios de almacenamiento y capacidades de concurrencia fueroncapitalizadas en mejores herramientas para simular y tratar casos no de flujos no estacionarios.De todas formas, esta expansion de horizontes aun no permite resolver el conjunto de aplicacionesque las distintas ramas de ingenierıa requieren [17].

Capıtulo 2.4. Trabajo Interdisciplinario y Aspectos Computacionales 33

2.5 Problematica a Resolver

El presente trabajo centra su analisis en el estudio de un sistema de control lineal a lazocerrado sobre sistemas de fluidodinamica no lineales. Esto plantea avances en el area de controlde fluidos debido a la simplicidad de los modelos lineales frente a los no lineales y la falta deresultados positivos a la fecha sobre su uso en sistemas netamente no lineales. Aunque se tienereferencia de trabajos similares, se entiende que la experiencias sobre las cuales se desarrollaronposeen no-linealidades de caracter debil por tratarse de sistemas amplificadores de ruido. Encontraposicion, se escoge como fenomeno fısico a controlar un sistema de oscilaciones auto-sostenido, que presenta marcadas no-linealidades.

A su vez, se estudia una metodologıa de sensado que relaje las condiciones necesarias parapoder realizar la experiencia fuera de laboratorios. En tal sentido, se opta por plantear uncontrolador basado en la medicion de propiedades sobre imagenes de la experiencia suponiendola inyeccion de humo u otro trazador pasivo aguas arriba.

Como sistema fısico bajo control se selecciona el escurrimiento de un cilindro inmerso enun flujo uniforme con el objetivo de controlar su estela. El forzado del flujo es producido poractuadores de plasma colocados en la superficie del cilindro. A fines practicos, se utilizan veloci-dades del fluido tales que la estela presente desprendimiento de vortices y un caracter netamentelaminar como se vera en los siguientes capıtulos.

Se utiliza un modelo ARX para expresar la dinamica de la estela del cilindro a traves deun vector de estado cuyas coordenadas son la intensidad del escalar pasivo observado en ciertospuntos de la imagen y la intensidad de actuacion. El controlador elegido posee un esquemaGPC para minimizar las fluctuaciones de la estela dentro de un horizonte de prediccion. Comopaso de verificacion previo a la implementacion real de la experiencia, se simula numericamenteel fenomeno, garantizando la ausencia de interferencias con senales externas y otras formasde ruido. Los resultados del controlador son integrados dentro del codigo de simulacion parasincronizar el momento de actuacion con los pasos de la simulacion propiamente dicha.

34

2.6 Conclusiones

Durante el presente capıtulo se introdujeron los conceptos fundamentales necesarios para eltrabajo en sistemas de control de fluidos. Se realizo una breve resena sobre el desarrollo historicode la Teorıa de Control y el Control de Fluidos con el fin de entender el camino transitado hastaalcanzar los niveles de complejidad actuales.

Se clasificaron las distintas estrategias de control en cuanto a bucles de control y actuadoresutilizados ejemplificando en cada caso con distintas experiencias del area del control de fluidos.En ese escenario se remarco la importancia de los actuadores reactivos y en especial de lazocerrado (o feedback) debido a su flexibilidad frente a cambios en las condiciones del sistema. Asu vez, se detallaron las distintas estrategias de modelizacion para fenomenos de fluidodinamicafocalizando en las de caja negra. En ese tipo de modelos resulta indispensable la identificacionde sistemas en base a fases de entrenamiento.

Por ultimo, se expuso la problematica a tratar, siendo fundamental la participacion de unequipo interdisciplinario. En ese contexto se detallaron los avances conocidos a la fecha y laimportancia de obtener un control a lazo cerrado, lineal y basado en imagenes. A tal fin, seestablecio la experiencia de control sobre la estela de un cilindro como caso prototipo y sedefinieron los detalles generales del experimento numerico.

35

Parte 3

Solucion y Diseno de la Experiencia

36

3.1 Introduccion

En este capıtulo son presentados los conceptos basicos sobre la experiencia del escurrimientosobre un cilindro en 2D, elegida como experimento prototipo para comprobar el algoritmo decontrol. Se introduce una caracterizacion basica sobre las zonas del flujo alrededor del cilindro yel fenomeno de desprendimiento de vortices en su estela. Asimismo, se ejemplifican algunos delos mecanismos de actuacion mas utilizados para reducir la turbulencia y desprendimiento devortices en el cilindro, a saber: actuacion por rotacion e inyeccion de plasma. Luego de lograrel entendimiento necesario sobre la fısica del sistema, se analizan brevemente ciertos casos deaplicacion de control para esta experiencia, haciendo hincapie en los cuerpos romos (o bluffbodies).

Luego, se define la estructura del sistema en estudio indicando dimensiones y condiciones desimetrıa que seran utilizadas en la simulacion pertinente. En este contexto se establece la posicionde los inyectores de humo, los actuadores de plasma y los sensores visuales sobre la estela delcilindro. Conociendo las caracterısticas de actuacion y sensado previstas para la experiencia,se definen las variables de entrada y salida que regiran el problema junto con el algoritmo deidentificacion del sistema ARX que las vincula en un modelo matematico.

Por ultimo, se define el algoritmo de control a implementar utilizando un controlador predic-tivo del tipo GPC. Se establece la funcion objetivo y se resume la importancia de las variablesde ajuste de la experiencia, tambien conocidas como parametros de tuning.

37

3.2 Sistema Fısico Bajo Estudio

El flujo viscoso externo alrededor de un cilindro representa un flujo prototipo de gran interespara la fluidodinamica. Buena parte de los estudios de flujos en estelas de bluff bodies (ver seccion3.2.3) han sido realizados sobre cilindros, gracias a su simple geometrıa y el comportamientocaracterıstico del flujo de separacion de la capa lımite.

3.2.1. Estela de un Cilindro

Se distinguen distintas regiones del flujo sobre el cilindro donde se originan fenomenos aso-ciados con la perturbacion (Fig. 3.2.1). Se estudiara unicamente su estela, donde el fenomeno dedesprendimiento de vortices y la turbulencia asociada tienen un caracter oscilatorio marcado.

Figura 3.2.1: Regiones del flujo perturbado. Se pueden identificar distintas regiones: (i) flujo retardado, (ii) capaslımite formadas en la superficie del cilindro, (iii) capas de corte, regiones de flujo separado y acelerado, (iv) esteladel cilindro.(Zdravkovich (1997) [70].

En base a las dimensiones del problema se define al numero de Reynolds, Re =UD

ν. Siendo

U la velocidad del flujo incidente, D el diametro del cilindro y ν la viscosidad cinematica. Estenumero es de suma importancia en experiencias que poseen movimiento relativos de fluidosrespecto a superficies ya que permite la clasificacion y comparacion de resultados. En efecto,ciertas caracterısticas en la dinamica de las experiencias son dependientes del Re utilizado ypueden ser comparadas con otras configuraciones de Re similares aunque las escalas sean muydiferentes.

3.2.1.1. Desprendimiento de Vortices

El fenomeno de desprendimiento de vortices resulta principalmente de la desaceleracion delfluido mas cercano a la superficie del cuerpo y su imposibilidad de mantener la velocidad poten-cial del flujo mas alejado (Fig. 3.2.2). Dependiendo del Re de la experiencia, es posible observar

38


el desprendimiento regular de vortices con signos opuestos, de una y otra parte del cilindro.Las sucesivas posiciones que ocupan los vortices son conocidas como camino de von Karman.

Se puede definir un numero adimensional llamado numero de Strouhal: St =fD

U, donde U es

la velocidad del flujo, f es la frecuencia de desprendimiento de vortices y D es el diametro delcilindro. En la Fig. 3.2.2 se puede observar un camino de von Karman tıpico durante experienciasde laboratorio mientras que la Fig. 3.2.3 muestra la generacion de oscilaciones que comienzanluego de la region de recirculacion que desestabilizan al flujo.

Figura 3.2.2: Mecanismo de separacion de la capa lımite y camino de von Karman. Izq.: Perfil de un cilindro, lıneaspotenciales del flujo y distribucion de presiones del flujo ideal. Se puede observar la aceleracion del flujo entre D yE junto con su desaceleracion entre E y F producto de los cambios de presion. En el flujo real, la friccion viscosacontra la pared del cilindro se suma a la desaceleracion provocando una insuficiencia para seguir la trajectoriapotencial con la consecuente separacion en el punto S (Schlichting, 1978) [59]. Der.: Desprendimiento de vorticesalternados formando el camino de von Karman.

Capıtulo 3.2. Sistema Fısico Bajo Estudio 39


Figura 3.2.3: Formacion de los vortices von Karman. En primer termino, la estela del cilindro presenta burbujasde recirculacion que se desprenden dando lugar a la generacion de vortices alternados (Perry.1982) [50].



3.2.1.2. Regımenes de Escurrimiento

Los distintos regımenes que pueden tener lugar en el flujo alrededor de un cilindro se clasificanen funcion del numero de Reynolds [69]. A medida que este aumenta, el regimen alterna entrelos modos laminar permanente (5 < Re < 49), desprendimiento laminar de vortices (49 < Re <200), transicion de las capas de corte (200 < Re < 3 · 105), desprendimientos asimetricos ysimetricos (3 · 105 < Re). La transicion entre los distintos regımenes no es abrupta y los efectosde las regiones vecinas pueden estar presentes si se utilizan rangos cercanos.

Como se vera en la seccion 3.3, el presente estudio se centra en valores de 219 < Re < 282y por lo tanto en la transicion de las capas de corte. Este regimen se caracteriza por teneruna estela del flujo turbulenta aunque en la zona de separacion se mantiene el flujo laminar.Aun fuera de la region de desprendimiento laminar de vortices, se mantienen sus caracterısticasvariando gradualmente hacia una estela completamente turbulenta a medida que aumenta Re.

Como agregado, en las capas de corte comienzan a desarrollarse estructuras tridimencionales(3D) como consecuencia de la complejidad del escurrimiento. Sin embargo, se decide estudiarlos efectos 2D del fenomeno ya que esta demostrado que frente a la actuacion sincronizada sobreel cilindro se mantienen las caracterısticas regulares bidimensionales (2D) del fenomeno hastavalores Re ≈ 450 [19].

3.2.2. Actuacion sobre el Cilindro

Existen una gran cantidad de estudios de control activo sobre el cilindro con el objetivo deestabilizar su estela. A continuacion se describe el modelo de actuacion mas usual que consisteen forzar la rotacion del cilindro. En contraposicion, se presenta el esquema de actuacion porinyeccion de plasma, de gran aceptacion en los ultimos anos debido a ciertas ventajas experi-mentales.

3.2.2.1. Actuadores por Rotacion

Se trata de uno de los mecanismos de control de cilindros mas estudiados. Consiste enforzar la rotacion del cilindro sobre su propio eje. Esta rotacion puede ser completa o a modo deoscilaciones temporales siendo este esquema el mas utilizado. Los movimientos rotatorios puedenvariar en frecuencia o en amplitud provocando distintos efectos sobre la estela resultante. Elmecanismo de rotacion oscilatoria provoca un retardo temporal en la separacion que disminuyeel efecto de arrastre [60].

En [66] se estudia el retardo en la aparicion de vortices bajo un sistema de control oscilatorioconcluyendo que las oscilaciones forzadas participan en la generacion de vortices adicionalesque interactuan con los naturales. Esta contribucion puede resultar constructiva o destructivaa la generacion global de vortices dependiendo de la diferencia de fase entre las oscilaciones yel desprendimiento natural del sistema. Se demuestra entonces que el efecto de las oscilacionespuede amplificar o reducir las fluctuaciones en la estela del cilindro dependiendo de la frecuenciay amplitud de oscilacion. La Fig. 3.2.4 y 3.2.5 dan ejemplo del efecto estabilizador con la eleccionadecuada de parametros.



Figura 3.2.4: Control por Rotacion Oscilatoria. La frecuencia de actuacion fue fijada mientras que la amplitud derotacion (A = Vtangencial/Vflujo) se definio en A = 1 y A = 2 respectivamente (Thiria, 2006) [66].

Figura 3.2.5: Control por Rotacion Oscilatoria. Continuando con la secuencia anterior, la amplitud de rotacion seaumenta llegando a A = 4 y A = 5 respectivamente [66]. Se puede observar la cancelacion de desprendimientosde vortices en la estela cercana para oscilaciones de amplitud suficientemente alta (Thiria, 2006).

3.2.2.2. Actuadores de Plasma

Dentro de las tecnicas de actuacion activas para el control de flujos se puede clasificar ala actuacion por plasma (medio gaseoso ionizado) frıos como sistema emergente y en plenaexpansion [56, 52, 62]. El mecanismo fundamental de estos actuadores consiste en forzar lamigracion de cargas mediante la disposicion de electrodos que provocan la ionizacion del gascircundante. La inyeccion de cantidad de movimiento junto a las paredes del cuerpo bajo estudiopuede ser utilizada para reducir el arrastre por friccion de la superficie y retardar la separacionde la capa lımite.

En la Fig. 3.2.6 se puede observar una posible configuracion de actuadores de plasma sobreun cilindro. Las Fig. 3.2.7 muestra la misma configuracion de actuadores en funcionamientosobre una experiencia de laboratorio y la comparacion con el escenario no actuado [40].



Figura 3.2.6: Dispositivo de actuacion por plasma montado en un cilindro (1) para estabilizar su estela. Se puedenobservar 4 electrodos externos (2) cada uno con su par interno (3). El cilindro posee una proteccion interna paraevitar descargas (4). El esquema muestra tambien la zona de descarga de plasma sobre las paredes del cilindro(5) (Kozlov, 2010) [40].

Como principales virtudes de esta tecnica se puede mencionar el escaso volumen y peso,la simpleza del montaje y la ausencia de partes moviles. Estas caracterısticas, que resultancruciales en la etapa de implementacion sobre aplicaciones reales, superan las posibilidades dela mayorıa de los actuadores mecanicos. Otro factor de importancia consiste en los tiempos derespuesta cortos, del orden de 1ns para el establecimiento de la descarga gaseosa. Estos tiemposse encuentran muy por debajo de los perıodos caracterısticos y tiempos de muestreo necesarios envarios escenarios de control de fluidodinamica (ver seccion 2.4). En contraposicion, los esquemasde actuacion que implican movimientos mecanicos poseen tiempos de respuesta mas prolongadosque les restan flexibilidad en experiencias de alta velocidad.

Se decide entonces utilizar este esquema de actuacion para la experiencia prototipo bajoestudio. En particular, es importante destacar las bondades extras que poseen los actuadoresElectroHidroDinamicos (EHD) [56, 62] donde las corrientes obtenidas son relativamente bajasy no es necesaria la aplicacion de campos magneticos externos. Este tipo de actuadores sonsimulados durante la experiencia y recomendados para su posterior implementacion.

Figura 3.2.7: Efecto de la actuacion por plasma en la estela de un cilindro (Kozlov, 2010) [40].

3.2.3. Aplicaciones Particulares de Control sobre el Cilindro

Se pueden identificar basicamente dos ramas de la industria donde la aplicacion de controlsobre estructuras comparables al cilindro cobra importancia: vehıculos (industria del automovil,



aeroespacial y nautica) y balıstica.En el ambito del transporte son conocidos los grandes esfuerzos de investigacion sobre las

condiciones aerodinamicas (o hidrodinamicas) de las superficies en contacto con el fluido. Estoscasos de control pasivo, donde se plantean estructuras con poca resistencia al fluido o superfi-cies que generan poca turbulencia en su estela, fueron indispensables para reducir el gasto decombustible y aumentar las velocidades de los automoviles, aeronaves y navıos.

Sin embargo, existen casos donde se deben ubicar ciertas estructuras por sobre el fuselaje dela aeronave para que puedan operar correctamente (emisores y receptores de senales, camarasde video, sensores infrarrojos, estructuras portantes, etc.). Estas superficies excedentes suelenposeer una longitud en direccion del flujo similar a su longitud en direccion perpendicular al flujo.Esa relacion de medidas les otorga un arrastre por friccion despreciable respecto al arrastre porpresion que ofrece su forma. Estos elementos son conocidos como cuerpos romos o bluff bodies.

A modo de ejemplo en automoviles, se puede mencionar a los espejos retrovisores que re-sultan imprescindibles debido a su utilidad. Por otro lado, en los nuevos modelos de avionesno tripulados (unmanned aerial vehicles o UAVs) se pueden encontrar varias estructuras cla-ves como las camaras infrarrojas y los emisores de senales (Fig. 3.2.8) que resultan de extremaimportancia para el manejo de la aeronave.

Figura 3.2.8: Ejemplos de bluff bodies en aumoviles y UAVs. Tanto el espejo retrovisor como las estructuras decontrol de los UAVs son claros ejemplos de elementos que no se pueden integrar al fuselaje debido a la naturalezade su uso.

En los ejemplos anteriores, la existencia de bluff bodies implica la aparicion de una estela condesprendimiento de vortices o turbulencia que puede generar arrastre, ruido y vibraciones.

La relacion de la experiencia del cilindro en 2D con el control de proyectiles resulta evidente.Los proyectiles son claros ejemplos de bluff bodies y el control de propiedades como el arrastre,sustentacion o turbulencias son de suma importancia para la balıstica. Si bien, este campo de es-tudio involucra efectos 3D no despreciables, el pasaje a 2D se justifica en escenarios simplificadoso donde reducir el tiempo de computo prevalece frente a la exactitud de los resultados.


3.3 Diseno y Objetivos de la Experiencia

Se considera el flujo alrededor de un cilindro con el objetivo de estabilizar su estela redu-ciendo el desprendimiento de vortices y la energıa cinetica de las fluctuaciones. Como fueraexplicado, esta configuracion posee principal importancia por su caracter de experiencia pro-totipo ampliamente estudiada. Respecto de intentos de control sobre la estela del cilindro, esposible encontrar una revision sobre distintas experiencias con feedback en [13].

Se conocen casos donde, aun bajo importantes interacciones no-lineales entre los modosglobales y la entrada de control, se logra la supresion de oscilaciones en las senales de lossensores utilizados para la experiencia [25, 57]. Si bien no existe una relacion directa entre lasoscilaciones en los sensores y la energıa cinetica de las fluctuaciones del flujo en su totalidad,se puede afirmar la posibilidad de utilizar modelos lineales para controlar ciertas cantidades deforma local. Con estas consideraciones se puede formular el objetivo de control centrado en lamanipulacion de las variables en torno a ciertos puntos en lugar de pretender un control sobre ladinamica total de los modos oscilatorios del sistema. Una forma de conseguir esto es observandolas lıneas de emision del flujo, que se denotan mediante la acumulacion de trazador pasivo, yrestringiendo su dinamica a cierto patron en la estela del objeto.

En el caso particular del escurrimiento del cilindro, se conoce que la estabilizacion produceuna estela mas angosta y larga. Entonces, al forzar la estela a que cumpla este patron, seespera que la energıa de las fluctuaciones disminuya. Con ese fin, se disponen varios sensoresformando un “tunel” que demarca los lımites pretendidos para las lıneas de emision aguas abajodel cilindro.

3.3.1. Configuracion y Dimensiones

La experiencia consta de un flujo entrante uniforme, de velocidad constante, que atraviesaun cilindro centrado respecto del eje perpendicular al flujo. El cilindro sera modelado con undisco unitario en 2D. Se establece el centro del sistema de coordenadas cartesianas en el centrodel disco. El eje de abscisas se define del mismo sentido que el flujo entrante (Fig. 3.3.1). La si-mulacion numerica es planteada con magnitudes adimensionales para posibilitar su escalamientoa las dimensiones reales en el caso de implementar la experiencia en un laboratorio. La correctaextension a un escenario real requiere entonces que se respeten las proporciones y relacionesadimensionales prefijadas (como el numero de Reynolds).

45


Figura 3.3.1: Estructura y dimensiones de la experiencia. El dominio de simulacion es medido proporcional altamano del disco que se considera unitario. Se fijan los lımites de la simulacion en 27.5 x 25 diametros con el discocentrado verticalmente a 7.5 diametros de la entrada del flujo.

La velocidad constante de entrada se define como unitaria y se deja variable al flujo desalida para que fluctue dependiendo de los resultados de simulacion de las celdas mas cercanas.La presion de referencia se decide colocar en el borde de salida y con valor nulo. Respecto delas condiciones de borde restantes, los laterales plantean simetrıa mediante la variacion nulade presion y velocidad respecto de la componente normal a los mismos. De forma analoga,la condicion de flujo entrante (inlet) posee variacion nula de la velocidad y presion respectode la normal. Por otro lado, la condicion de flujo saliente (outlet) define como nula solo a lavariacion de la velocidad normal. Cabe aclarar que al aplicar una variacion nula respecto dela normal a cierto borde, se pretende modelar una extension infinita de la superficie en dichadireccion. En el caso del flujo saliente, una variacion nula de la velocidad permite repetir el valorsimulado para las celdas interiores en las celdas exteriores (fuera de los lımites de la simulacion).Las condiciones de borde donde se fija el valor de la magnitud, como en el caso del inlet sonconocidas como Condiciones de Dirchlet. Por otro lado, cuando se fija el valor de la variacion (esdecir, del gradiente), como el caso del outlet, se trata de una Condicion de Neumann. El detallede las condiciones de borde y las dimensiones del problema son indicadas en la Fig. 3.3.2.

Capıtulo 3.3. Diseno y Objetivos de la Experiencia 46


Figura 3.3.2: Condiciones de borde, disposicion de sensores y actuadores de la experiencia. Se pueden observarlas condiciones de borde en los distintos laterales de la experiencia. Los actuadores son dispuestos sobre la pareddel disco y los sensores se alinean aguas abajo.

El numero de Reynolds elegido para la experiencia es Re = 235. Dado que la velocidad delflujo fue definida al igual que el diametro del cilindro, se fija el Re ajustando la viscosidad delfluido a ν = 235−1, segun:

ν =UD

Re=

1

235= 235−1 ≈ 4,2553E − 3

Luego de establecer los parametros generales de la experiencia, es posible estimar la frecuenciade desprendimiento de vortices mediante una aproximacion del numero de Strouhal. Se conoce larelacion entre Re y St mediante la tabulacion de distintas experiencias y la elaboracion de curvas3.3.3. Esta relacion presenta discontinuidades marcadas y, por lo tanto, no puede encontrarseuna forma funcional que la sintetice a menos que se la defina por tramos. Sin embargo, enregiones de trabajo acotadas es posible aproximar el numero de Strouhal mediante una funciondel Re. Para el Re elegido, se puede aproximar un valor de St = 0,1814 gracias a la relacionmatematica que resulta valida en entornos de Re ≈ 250:

St = 0,198

(1− 19,7

Re

)= 0,198

(1− 19,7

235

)≈ 0,1814



Figura 3.3.3: Evolucion del numero de Strouhal en funcion del numero de Reynolds (Williamson, 1996) [69].

3.3.2. Sensores y Actuadores

Un filamento de trazador pasivo de concentracion unitaria es inyectado en la entrada delfluido. Este trazador modela la inyeccion de humo que difunde a traves del escurrimiento permi-tiendo el sensado de su concentracion en la estela del cilindro. A fines practicos de la simulacion,se colocaran puntas de medicion (o probes) dentro de la aplicacion de simulacion para obtener laconcentracion en ciertos puntos. En un escenario real, se pueden sensar estos valores mediantela captura de imagenes en escala de grises y la comparacion de las intensidades en dichos puntoscon la del punto de inyeccion (concentracion patron unitaria).

Se dispone de 2 lıneas de sensores, simetricas respecto del eje X de la simulacion, con 4sensores cada una para capturar los valores de concentracion del escalar difundido aguas abajodel cilindro (Fig. 3.3.2). Las posiciones elegidas para los sensores pretenden demarcar un “tunel”a traves del cual se debe canalizar el escalar inyectado en un caso de control optimo. En el casono estabilizado, los sensores captaran el desplazamiento de los vortices y las fluctuaciones develocidad por la turbulencia de la estela. Es importante remarcar que la eleccion de la posicionde cada sensor y la cantidad de sensores utilizados resulta del ajuste luego de ejecutar variasexperiencias de control. El algoritmo y parametros de configuracion propuestos en las siguientessecciones demostraron ser altamente sensibles a la configuracion de la experiencia. De todasformas, se destaca que el concepto de “tunel” y sensado por vision propuestos resultan genericosy adaptables a una gran variedad de experiencias.

Se definen entonces las variables yi(k) con i = 1.,8 para el valor medido en cada sensor enel paso de tiempo k suponiendo un muestreo discreto. Dado que el trazador introducido poseeconcentracion unitaria en el punto de inyeccion, se espera que las variables yi posean valoresentre 0 y 1. Asimismo, se define el vector generico y(k) = (y1(k) . . . ym(k))T ∈ Rm con m = 8



que sera de utilidad para operar con las mediciones del paso k de forma matricial.

Se agregan 2 actuadores simetricos en la superficie del cilindro. Los actuadores poseen unalongitud de aproximadamente un 5 % de la circunferencia del cilindro y modelan los dispositivosde inyeccion de plasma. La funcion de los actuadores es la adicion sincronizada de cantidad demovimiento tangencial a la superficie del cilindro. Los actuadores son dispuestos cerca del puntode separacion (Fig. 3.2.2) con el objeto de retardar la separacion de la capa lımite respecto dela superficie del cilindro mediante la inyeccion simetrica de plasma. Estudios previos bajo unaconfiguracion similar demostraron que la inyeccion constante con una amplitud suficientementealta permite estabilizar la estela del cilindro [18]. En este caso, se propone estabilizar la estelamediante una actuacion variable durante el tiempo, que acepte las fluctuaciones naturales delmodelo fısico, y que eventualmente requiera una amplitud menor.

El actuador es simulado como en [18] y [28] mediante una condicion de borde en una regionlocalizada del cilindro. La amplitud de la actuacion indica la magnitud de velocidad tangencialinyectada por los actuadores. Se define entonces la variable u(k) como la magnitud de la velocidadtangencial inyectada por ambos actuadores de forma simultanea en el paso de tiempo k. De formaanaloga a la definicion de y(k), se considera una forma mas general de la variable de actuacionsegun u(k) ∈ Rr con r = 1.

A menos que se especifique lo contrario, se considera una inyeccion ideal del trazador ymediciones perfectas en los sensores. Asimismo, se asume una velocidad de entrada constante,uniforme a lo largo del eje de las ordenadas y constante en el tiempo. Esta situacion distade cualquier escenario de experimentacion real donde existen fluctuaciones en los sistemas deinyeccion y errores inherentes al esquema de camaras e iluminacion utilizados. Esto permitecentrar la atencion en las senales puras provenientes de la dinamica del fenomeno y demorar elanalisis de ruido u otro tipo de perturbaciones. Los efectos de las perturbaciones seran tomadosen cuenta en una etapa posterior a la verificacion de la efectividad del algoritmo a lazo cerrado.En esa etapa se pondra a prueba la robustez del sistema frente a la existencia de ruido en lainyeccion del escalar, en las condiciones de entrada y en las mediciones de los sensores.

3.3.3. Sıntesis y Objetivos de la Experiencia

A modo de sıntesis se resumen los parametros importantes del sistema fısico a simular. Encada caso se incluye su valor y una resena de la variable utilizada, en caso de existir (Tabla3.3.1):

Propiedad Variable Valor (adimensional)Reynolds Re 235Strouhal estimado St 0,1814Diametro Cilindro D 1Viscosidad Fluido ν 235−1

Vel. Flujo Entrada U 1 Cte. (Cond. Dirichlet)Vel. Flujo Salida Gradiente Nulo (Cond. Neumann)Entradas y(k) Concent. de Escalar en el tiempo kSalidas u(k) Amplitud de actuacion en el tiempo k

Tabla 3.3.1: Sıntesis de variables utilizadas en la experiencia de simulacion.

En las siguientes secciones se define el algoritmo de identificacion del sistema, planteandocomo vector de estado del sistema al conjunto de las variables y(k) y u(k) para cada paso de



tiempo. El sistema identificado permite predecir los estados futuros de las salidas si se asumenciertas entradas.

Luego se considera el algoritmo de control que calcula el valor adecuado de u(k) para los yi(k)medidos en el paso k y anteriores. El valor de actuacion calculado buscara cumplir el objetivode control que consiste en disminuir la concentracion medida en el conjunto de sensores paraforzar un fenomeno de “tunel” del humo sobre el camino formado por los sensores. Este objetivopuede ser planteado gracias a la disposicion de los elementos en la experiencia y su caracter desimetrıa respecto del “tunel”.

El sistema fısico elegido como escenario de verificacion plantea dificultades importantes enel terreno de la identificacion del sistema y la definicion del controlador. Se trata de un sistemacon oscilaciones auto-sostenidas que posee un caracter no-lineal marcado. Esta caracterısticaes reforzada por el numero de Reynolds elegido dentro de una zona de transicion, en la cualse presentan fenomenos mixtos de desprendimiento laminar de vortices y turbulencia. En esecontexto, se espera que las no-linealidades sean aun mas notorias.

Por otro lado, el esquema de sensado y control elegidos plantean ciertas ventajas sobre otrostrabajos de control para escenarios similares. En primer lugar, el empleo de trazadores pasivoscomo elemento de medicion en lugar de otras variables fısicas (presion, campo de velocidades,etc) desvıa el foco de la dinamica instantanea a una medida mas general del sistema, dondelas no-linealidades no resultan tan evidentes. En segundo lugar, se relaja el objetivo de controlal proponer el desvıo de los trazadores dentro de un “tunel” que se conoce como una solucionfactible para el problema en estudio. Esto acota los grados de libertad de la experiencia dentrode ciertos lımites que admiten una solucion de control conocida.

Por ultimo, es importante recalcar que aunque se demuestra la efectividad del algoritmo decontrol en el caso de 8 variables de salida simultaneas y 1 variable de entrada, su definicion esgenerica y como consecuencia se lo puede clasificar como un sistema de control MIMO.


3.4 Algoritmo de Identificacion del Sistema

Para representar la dinamica del flujo se considera un sistema lineal invariante en el tiempodefinido segun:

y(k) + α1y(k − 1) + · · ·+ αnay(k − na) =

ν1u(k) + ν2u(k − 1) + · · ·+ νnbu(k − (nb − 1))

donde y(k) ∈ Rm representa el estado observable del sistema (la salida), u(k) ∈ Rr representala actuacion (la entrada) y k ∈ N es el paso de tiempo actual. Los vectores y(k) y u(k) poseenlas m componentes de salida y las r componentes de entrada que se consideran observables paracada paso de tiempo k dentro de la experiencia. Las variables na ∈ N y nb ∈ N definen loshorizontes de auto-regresion para y y u respectivamente. A modo de simplificacion se puedeasumir na = p y na = nb − 1 sin perder generalidad. Reformulando los coeficientes del terminoderecho se obtiene una nueva forma del sistema:

y(k) + α1y(k − 1) + · · ·+ αnay(k − na) =

β0u(k) + β1u(k − 1) + · · ·+ βpu(k − p)(3.4.1)

donde p ∈ N define el orden del modelo.Nos referimos al sistema como un modelo AutoRegressive with eXtra inputs(ARX). Los coe-

ficientes αi para 1 ≤ i ≤ p y βi para 0 ≤ i ≤ p, de tamanos m×m y m× r respectivamente, sonllamados observer Markov parameters y caracterizan el modelo [33].

Si se define el vector de parametros

Θ := (α1 . . . αp β0 . . . βp)T ∈ R(pm+(p+1)r)×m

y el vector de regresion

ϕ(k) =

−y(k − 1)...

−y(k − p)u(k)

...u(k − p)

∈ Rpm+(p+1)r (3.4.2)

la Eq. 3.4.1 puede ser escrita de la siguiente forma

y(k) = ΘTϕ(k).

Por otro lado, definiendo θ, un vector de tamano d := pm2 + (p + 1)mr que contiene todoslos coeficientes de las matrices αi y βi, y considerando Ξ(k) := ϕ(k)⊗ Im, siendo ⊗ el productode Kronecker e Im la matriz identidad m ×m, es posible reescribir la Eq. 3.4.1 de la siguienteforma

y(k) = ΞT (k)θ.

51


Para estimar θ, se define una fase de entrenamiento donde se fuerza al actuador mientrasse mide la respuesta del sistema fısico durante N pasos de tiempo. Se propone como senal deactuacion para el entrenamiento un pulso de gran amplitud y corta duracion, que permita captarla respuesta del sistema a un gran rango de frecuencias. La Fig. 3.4.1 presenta un diagrama debloques que sintetiza la fase de entrenamiento e identificacion del sistema.

Figura 3.4.1: Esquema de bloques de la fase de identificacion del sistema.

Las N muestras del entrenamiento son utilizadas bajo el criterio de estimacion de mınimoscuadrados para obtener un estimador θLSN de θ. Se evalua Ξ(k) sobre el conjunto de las Nmuestras de entrenamiento utilizando p+ 1 ≤ k ≤ N . Se asume el inicio del muestreo en k = 1teniendo disponibles los valores de y(1), . . . , y(N), u(1) . . . , u(N):

θLSN =

1

N − p

N∑k=p+1

Ξ(k)ΞT (k)

−1

1

N − p

N∑k=p+1

Ξ(k)y(k). (3.4.3)

Dado que la matriz∑N

k=p+1 Ξ(k)ΞT (k) puede resultar mal condicionada, es decir que esta cer-ca de ser no inversible debido a su valor o a la precision numerica, se considera un metodo masefectivo para estimar los parametros [42]. Se define entonces

ΦT := (Ξ(p+ 1) . . .Ξ(N)) ∈ Rd×(N−p)m,

Y T := (yT (p+ 1) . . . yT (N)) ∈ R1×(N−p)m.

Finalmente, la estimacion de θ se obtiene de una descomposicion QR de la matriz [ΦY ] ∈R(N−p)m×(d+1) en la cual las primeras d columnas corresponden a las columnas de Φ y la ultimacolumna es el vector Y .

Con estas definiciones, el problema consiste en obtener un θ que minimice ‖Y − Φθ‖2. Seconsidera una descomposicion QR dada por [ΦY ] = QR, con Q ortonormal de (N −p)m× (N −p)m y R triangular superior de (N − p)m× (d+ 1) tal que

R =

R1 R2

0 R3

0 0

siendo R1 una matriz d× d triangular superior, R2 un vector d× 1 y R3 un escalar. Es posibledemostrar que la minimizacion de ‖Y −Φθ‖2 es equivalente a minimizar ‖QT (Y −Φθ)‖2. ComoQTΦ corresponde a las primeras d columnas de R y QTY a la ultima columna de R, se obtieneque

QTΦθ =

(R1θ

0

), QTY =

R2

R3

0

Capıtulo 3.4. Algoritmo de Identificacion del Sistema 52


Entonces, se concluye que ‖QT (Y −Φθ)‖2 = ‖(R2 −R1θ

R3

)‖2. Al determinar esta cantidad y

resolver el sistema R1θ = R2 se despeja θ, el estimador de θ, segun:

θ = R−11 R2 (3.4.4)

Este sistema suele estar mejor condicionado que Ec. 3.4.3 y por lo tanto es menos sensible aruidos, diferencias de magnitudes medidas, similitud de mediciones en distintos sensores, etc.

Parametros Utilizados

Como parametros destacados de la estrategia de identificacion del sistema se pueden men-cionar a la duracion y amplitud del pulso forzado como actuacion, el numero de muestras delperıodo de entrenamiento N y el horizonte de autoregresion determinado por p. Si bien es posibleajustar dichos parametros considerando unicamente el grado de aproximacion del modelo ARXrespecto de las muestras observadas y la posibilidad de predecir estados futuros, se observo quetales ajustes no aseguraban necesariamente un buen control. Dado que la estrategia de identi-ficacion del sistema se encuentra integrada con el algoritmo de control, se decide posponer laseleccion de parametros hasta definir el controlador y poder verificar que los ajustes aseguranlos objetivos de control propuestos. La Tabla 3.4.1 incluye una lista detallada de las propiedadesy variables utilizadas en esta fase.

Propiedad VariableCant. variables de salida mCant. variables de entrada rOrden del sistema pCant. muestras de entrenamiento NActuacion de entrenamiento u(1) . . . u(N)

Tabla 3.4.1: Sıntesis de variables utilizadas en la identificacion del sistema.

Capıtulo 3.4. Algoritmo de Identificacion del Sistema 53

3.5 Algoritmo de Control a Lazo Cerrado

Luego de la identificacion del model ARX, es necesario establecer el lazo cerrado del controly definir el algoritmo de feedback apropiado. La Fig. 3.5.1 muestra un diagrama de bloques dela fase de control que se considera a continuacion.

Figura 3.5.1: Esquema de bloques del algoritmo propuesto.

Siendo s ∈ N el horizonte de prediccion, se definen ys ∈ Rsm, us ∈ Rsr and vp ∈ Rp(m+r)

tales que

ys(k) :=

y(k)...

y(k + s− 1)

, us(k) :=

u(k)...

u(k + s− 1)

,

vp(k − p) :=

y(k − 1)...

y(k − p)u(k − 1)

...u(k − p)

.

De acuerdo con la Ec. 3.4.1 se puede obtener una expresion matricial para predecir las salidasfuturas del sistemas [33]

ys(k) = T us(k) + Ψvp(k − p) (3.5.1)

donde T es una matriz de Toeplitz definida segun

T :=

β0

β(1)0 β0

β(2)0 β

(1)0 β0

. . . . . . . . . . . . . . .

β(s−1)0 . . . . . . β

(1)0 β0

(3.5.2)

y los coeficientes β0, β(1)0 , . . . β

(s−1)0 son conocidos como los parametros del sistema de Markov

(system Markov parameters) [33]. T y Ψ son matrices de ms×sr y ms×p(m+r) respectivamentey son obtenidas por una serie de relaciones recursivas segun se describe en [33].

54


Los coeficientes β(k)0 son llamados parametros de respuesta del sistema al pulso (pulse reponse

parameters y son obtenidos segun:

β(0)0 = β0

β(k)0 = βk +

k∑i=1

αiβ(k−i)0 , 1 ≤ k ≤ p

β(k)0 =

p∑i=1

αiβ(k−i)0 , k > p

mientras que la matriz Ψ se define tal que

Ψ :=

α1 α2 . . . αp β1 β2 . . . βp

α(1)1 α

(1)2 . . . α

(1)p β

(1)1 β

(1)2 . . . β

(1)p

. . . . . . . . . . . . . . . . . . . . . . . .

α(s−1)1 . . . . . . α

(s−1)p β

(s−1)1 . . . . . . β

(s−1)p

(3.5.3)

con coeficientes calculados de forma recursiva. En primer lugar, es necesario definir los αk1 :

α(0)1 = α1,

α(k)1 = αk+1 +

k∑i=1

αiα(k−i)1 , 1 ≤ k ≤ p− 1,

α(k)1 =

k∑i=1

αiα(k−i)1 , k > p,

Luego, se calculan los βjk:

β(j)1 = α

(j−1)1 β1 + β

(j−1)2 ,

β(j)2 = α

(j−1)1 β2 + β

(j−1)3 ,

...,

β(j)p−1 = α

(j−1)1 βp−1 + β(j−1)

p ,

β(j)p = α

(j−1)1 βp,

Y finalmente αjk:

α(j)1 = α

(j−1)1 α1 + α

(j−1)2 ,

α(j)2 = α

(j−1)1 α2 + α

(j−1)3 ,

...,

α(j)p−1 = α

(j−1)1 αp−1 + α(j−1)

p ,

α(j)p = α

(j−1)1 αp.

El algoritmo de control se basa en un esquema Generalized Predictive Controller (GPC)[14,15, 35] cuya funcion objetivo consiste en reducir la concentracion de escalar medida en los

Capıtulo 3.5. Algoritmo de Control a Lazo Cerrado 55


sensores. De esta forma, se pretende generar un efecto de “tunel” sobre el trazador pasivo quegarantice la ausencia de desprendimiento de vortices en ese segmento de la estela. En efecto, siconsideramos la simetrıa en la posicion de los sensores y actuadores junto con la dinamica delsistema, podemos asumir que respuesta de control natural sera aumentar la actuacion cuandoel sistema aun no se encuentre estabilizado.

A tal fin, se define la funcion objetivo segun

J = yTs (k)Qys(k) + λuTs (k)us(k) (3.5.4)

donde Q es una matriz diagonal de sm× sm con bloques Qi tales que

Qi := diag(q1 . . . qm),

y qi representa el peso del sensor i. Si bien el peso de cada sensor puede definirse comounitario, es posible variar el valor para dar preponderancia a determinados sensores frente aotros. De esta forma se puede tomar en cuenta la distancia de cada sensor respecto del puntode actuacion y, por ejemplo, contemplar un peso menor en sensores con mayor retardo.

El parametro λ de la Ec. 3.5.4 penaliza la actuacion dentro del funcional. De esta forma sele asocia un costo a la energıa utilizada en el actuador para que el controlador se auto-regule yconsiga un balance de eficiencia. Durante la experiencia, se pudo comprobar que el valor de λconsiderado resulto muy sensible a la cantidad de los sensores utilizados, a su posicion y a lasescalas de los valores medidos o de actuacion. Por este motivo, se consideran experiencias deverificacion de robustez, fuera del entorno de diseno, que mantengan fijos parametros como lasposiciones y cantidad de sensores. De la misma forma, se considera la normalizacion y cambio deescala de los valores medidos para contar con series de datos homogeneas que quiten sensibilidada la variable λ. Estas cuestiones seran tratadas en el Capıtulo 4.

Es importante remarcar que la minimizacion de la funcion de costo, J , no implica de formadirecta la minimizacion de la energıa cinetica de la turbulencia. Este objetivo general se alcanzagracias a disponer adecuadamente de los sensores y a penalizar la existencia de lıneas del flujono deseadas. De esta forma se fuerza al flujo a adoptar una configuracion particular conocidacomo estable.

Se asume una ley de control lineal y se define us(k) = Kvp, donde K es una matriz desr × p(m+ r) que contiene los coeficientes del controlador.

Teniendo esto en cuenta y aplicando el metodo de Lagrange para minimizar J bajo lasrestricciones dadas por la Ec. 3.5.1, se plantea el Lagrangiano L = J+ < l, ys − T us − Ψvp >;donde l ∈ Rsm simboliza el multiplicador de Lagrange y < ·, · > es un producto interno usualen Rsm. Buscando la solucion optima del sistema, se obtienen las siguientes ecuaciones:

ys − T us −Ψvp = 0,

2Qys + l = 0,

2λus − T T l = 0.

De ellas se determina que

K = −(T TQT + λIsr)−1T TQΨ (3.5.5)

donde Isr representa la matriz identidad de sr × sr, y entonces

us(k) = −(T TQT + λIsr)−1T TQΨvp(k − p) (3.5.6)

.



Como se requiere unicamente el valor de la actuacion para el paso actual (k), es posibleahorrar tiempo de procesamiento si se calculan solo las primeras r filas del producto en elprimer termino de la Ec. 3.5.6 segun

u(k) = {−(T TQT + λIsr)−1}rT TQΨvp(k − p). (3.5.7)

Luego de la aplicacion de la actuacion u(k) es necesario medir el estado de los sensores y(k),calcular vp y cerrar el ciclo de control repitiendo la Ec. 3.5.7 para el nuevo paso de tiempo. Acontinuacion, se resume el algoritmo de control aplicado mediante pseudo-codigo:

Algorithm 1 Algoritmo de control propuesto.

Require: p: orden del modelo, s: horizonte de prediccion, λ: costo del actuadorEnsure: Sistema de control bajo estudio

1: Medir los valores de la fase de entrenamiento2: Calcular el modelo ARX de orden p3: Definir el controlador con s, λ y el modelo ARX4: Definir el vp inicial con los valores de y y u hasta el paso k − 15: for all paso de tiempo k do6: Usar Ec. 3.5.7 para obtener u(k)7: Aplicar la actuacion u(k) calculada8: Medir y(k), la salida resultante para el paso de tiempo k9: Actualizar vp con y(k) y u(k)

10: end for

Parametros Utilizados

El parametro de mayor importancia durante la fase de control es el costo del actuadorλ utilizado en la funcion objetivo. Su valor debe ser restrictivo para evitar que la salida seacontrolada con un uso de actuacion poco eficiente y a su vez lo suficientemente permisivo paraque el actuador fluctue de acuerdo con la naturaleza del sistema.

La Tabla 3.5.1 resume las propiedades y variables utilizadas en esta fase.

Propiedad VariableHorizonte de prediccion sCosto del actuador λPesos de cada sensor Q

Tabla 3.5.1: Sıntesis de las variables utilizadas en el control a lazo cerrado.


3.6 Conclusiones

El presente capıtulo introdujo la experiencia del escurrimiento sobre un cilindro en 2D ası co-mo los conceptos basicos asociados sobre su control. Se sintetizaron las zonas caracterısticas delescurrimiento poniendo foco en la estela del cilindro y los fenomenos de desprendimiento devortices y turbulencia. Asimismo, se introdujo el numero de Reynolds (Re) que caracteriza ladinamica del fluido y el numero de Strouhal (St) que se relaciona con la frecuencia de despren-dimiento de vortices y puede ser estimado en ciertos rangos de Re.

Luego de resumir las aplicaciones de control de bluff bodies y su relacion con la experienciadel cilindro, se detallo el esquema experimental incluyendo las dimensiones del problema, el valorde Re = 235 y una estimacion de Stestimado = 0,1814. Estos parametros permiten pronosticar elcomportamiento del fenomeno fısico previo a su simulacion.

Entonces, se introduce el algoritmo de identificacion del sistema que permite obtener unmodelo matematico ARX de orden p a partir de un conjunto de muestras de entrenamiento.Asimismo se utiliza el modelo ARX calculado, p, un horizonte de prediccion s, el peso de cadasensor y el coeficiente de penalizacion de la actuacion λ para definir el algoritmo de control.Dicho sistema hace uso de tecnicas predictivas utilizando un controlador del tipo GCP. Ambosalgoritmos son definidos de manera generica, para un conjunto de m sensores y r actuado-res arbitrarios consiguiendo un esquema de controlador MIMO lineal que puede ser extendidofacilmente a otras experiencias.

58

Parte 4

Ensayo Experimental

59

4.1 Introduccion

El presente capıtulo establece el mallado a utilizar durante la experiencia numerica, inclu-yendo tipos y tamanos de celda junto con la relacion que poseen con el paso de tiempo de lasimulacion. Luego de definir la configuracion fısica y numerica de la simulacion, se obtienen losprimeros resultados que son contrastados con las predicciones realizadas sobre el fenomeno fısicobajo estudio.

Ya verificada la validez del mallado y configuracion de la simulacion, se implementa unesquema de comunicacion con Code Saturne que permite obtener la informacion de cada pasode tiempo y generar una respuesta de actuacion acorde. Este mecanismo es puesto a pruebadurante una fase de entrenamiento del sistema donde se fuerza un pulso de actuacion y serecolecta la respuesta en los distintos sensores. Las mediciones son luego relacionadas con unmodelo ARX identificado mediante el algoritmo de mınimos cuadrados propuesto en el Capıtulo3.4. El modelo identificado es puesto a prueba para asegurar la capacidad de prediccion futurarespecto de distintas frecuencias de actuacion.

En la fase de control, se utiliza el modelo ARX para calcular la actuacion optima frentea cada paso de tiempo. Se desarrolla el algoritmo de control definido en el Capıtulo 3.5 y seajustan los parametros para obtener un control apropiado para la experiencia. Luego, se practicaun analisis sobre la energıa cinetica y las fluctuaciones de la estela del cilindro para verificarla bondad del controlador desarrollado. Para ello se convierte la estructura de malla irregularutilizada para la simulacion en una grilla cartesiana que permite la manipulacion de variablesfısicas (como la concentracion del escalar o el campo de velocidades) de manera uniforme.

Finalmente, se realiza una serie de simulaciones con condiciones fuera de diseno para verificarla robustez del sistema de control.

La implementacion de los algoritmos de identificacion y de control son realizadas en C++y Matlab. A su vez, se realizaron pruebas de concepto de la identificacion del sistema escritoıntegramente en CUDA C/C++ (lenguaje de GPGPU para tarjetas Nvidia) con el objetivo dedemostrar la versatilidad del esquema propuesto y la posibilidad de realizar un sistema de altaperformance para implementar la experiencia en laboratorios [37].

60

4.2 Mallado de la Experiencia

Se efectua la simulacion utilizando el aplicativo Code Saturne [23, 2], un sistema de codigoabierto escrito en Fortran, C99 y Python que realiza Direct Numerical Simulation (DNS). Estetipo de simulacion consiste en discretizar la experiencia con un conjunto de celdas y resolver lasecuaciones de Navier-Stokes para cada paso de tiempo. El conjunto de celdas se denomina malla(o mallado) y la solucion a las ecuaciones se practica sobre los puntos de union entre celdas.Como agregado a la resolucion del flujo de un fluido, Code Saturne permite resolver modelosfısicos de transferencia de calor y combustion de fluidos, entre otros, mediante un algoritmo devolumenes finitos de segundo orden utilizando el metodo de Crank-Nicolson [23].

4.2.1. Tamano de Celdas

Resulta intuitivo que a menor tamano de celda, mayor es la precision de calculo de la re-solucion DNS. Sin embargo, un elevado numero de celdas producto de un mallado fino implicamayores capacidades de computo para cada paso de tiempo a simular. Estos aspectos debenmantener una relacion de equilibrio, disminuyendo el tamano de celdas en las zonas donde serequiere mayor precision y aumentandolo en aquellas donde no es necesario un alto detalle.

La geometrıa del sistema fue mallada en 2D utilizando el aplicativo GID para generacion degrillas no-estructuradas [43]. Se opto por el empleo de triangulos como tipo de polıgono para lasceldas (Fig. 4.2.1) ya que permiten un facil encastre entre elementos sin necesidad de grandesdeformaciones. Si bien los triangulos no son necesariamente equilateros, se puede tomar comotamano caracterıstico a la longitud de sus lados. La malla se disena de forma tal de ser fina en lacircunferencia del cilindro (Fig. 4.2.2) y aumentar en grosor con la distancia a su centro. Lejosdel cilindro, se define un tamano medio uniforme de celdas que se extiende al resto de dominio(Fig. 4.2.3).

Figura 4.2.1: Detalle del tipo de celdas triangulares utilizadas en el mallado no-estructurado.

61


Figura 4.2.2: Mallado de la geometrıa del sistema cercana al cilindro. En si bien la diferencia entre el tamano delmallado sobre el borde del cilindro y las fronteras del dominio es grande, se utilizo una transicion gradual y variosanillos concentricos de diversos tamanos.

Figura 4.2.3: Mallado de la geometrıa del sistema. Se observa claramente la diferencia de densidad de celdas entrelas cercanıas del cilindro y la region circundante.

Dado que el cilindro posee un diametro unitario, su circunferencia resulta π. A fines practi-cos, se pretende un nivel de discretizacion tal que el cilindro este compuesto por 100 celdasen su superficie. Esto implica un numero aproximado de 5 celdas para describir a cada actua-dor, sabiendo que se representan como semi-arcos de aproximadamente 5 % de la circunferencia(Capıtulo 3.3). Se define entonces un tamano de celda de 0,03 en la proximidad del cilindro ydos anillos concentricos con tamanos de celda 0,035 y 0,05 permitiendo un aumento gradual delas dimensiones utilizadas (Fig. 4.2.2). El tamano general del resto del dominio y lımites de laexperiencia se fijo en 0,1 (Fig. 4.2.3).

Este tipo de configuracion permite economizar enormemente el tiempo de procesamiento sincomprometer la calidad de la simulacion en las regiones crıticas. Esto es posible al destinar unapequena cantidad de celdas a tomar dimensiones pequenas (con un bajo poder de cobertura) yuna cantidad sensiblemente mayor para aquellas de mayor tamano (con mejores posibilidadesde cubrir el amplio dominio). Es posible encontrar el detalle de las dimensiones empleados en

Capıtulo 4.2. Mallado de la Experiencia 62


cada region al generar la malla en el Apendice B.1. Se incluye ademas la distribucion final deceldas de acuerdo a su tamano.

Ya generada la malla 2D de triangulos utilizando GID, se adaptan sus nodos a un formato 3Dpara ser empleado por Code Saturne. Existen varias alternativas para realizar dicha extension, eneste caso se opta por agregar una nueva dimension al conjunto de celdas mediante la proyeccionde sus lados. Se extiende entonces cada triangulo a un pentaedro de altura 0,005 para mantenerrelacion con el orden de magnitud utilizado en las celdas mas pequenas. A tal fin, se realizaun script de Matlab que interpreta el archivo de salida de GID, extiende cada triangulo de lamalla y genera un nuevo archivo de malla con formato .msh que puede ser consumido por CodeSaturne. El codigo fuente de dicha rutina puede encontrarse en el Apendice F.1. En la Fig. 4.2.4se puede apreciar el agregado de una dimension ficticia a la malla original en 2D generando unpentaedro por cada triangulo existente.

Figura 4.2.4: Extension del mallado 2D a 3D. Se observa el detalle de una vista oblicua del mallado 2D (Izq.) encomparacion con su extension a 3D (Der.) mediante la conversion de celdas triangulares a pentaedros de altura0,005 homogenea.

4.2.2. Paso de Tiempo

Para garantizar la estabilidad de este mecanismo, la discretizacion temporal (entre pasosde tiempo sucesivos) y espacial (al definir los lımites de cada celda) deben permitir que elmovimiento de cada partıcula de fluido sea de una fraccion de la celda. De esta forma, se consigueuna propagacion suave de los distintos cambios en las magnitudes y se evitan las variacionesbruscas que provocan errores de calculo numerico.

Si estas condiciones no se cumplen, el sistema tiende a ser inestable durante la simulacion y,eventualmente, diverge. Esto suele ocurrir en puntos con gran intercambio de fluidos o sectoresdel mallado con celdas de tamano muy dispares. En cualquiera de los casos el flujo simulado norecorre las celdas de forma gradual y el desacople entre los valores de distintas celdas desestabilizalas magnitudes diferenciales simuladas que no pueden converger. En el Apendice B.2 se puedeencontrar un caso de divergencia de la simulacion como consecuencia de cambios bruscos en lasdimensiones de las celdas del mallado.

Por otra parte, el estudio matematico detallado de la resolucion numerica de ecuacionesdiferenciales en derivadas parciales contempla distintos criterios de convergencia. Uno de los



mas utilizados es la Condicion de Courant-Friedrich-Lewy (CFL), a saber:

C =U∆t

∆x< Cmax

donde U es la magnitud de la velocidad, (∆t) es el paso del tiempo y (∆x) indica el tamanoelegido para la discretizacion espacial del problema (en nuestro caso, el tamano de las celdas).El coeficiente C es conocido como numero de Courant y se exige que sea menor que ciertaconstante Cmax que dependera de la sensibilidad numerica del algoritmo utilizado. Cmax sueleser inferior a 1, reforzando la necesidad de que la distancia recorrida por cada partıcula en unpaso de tiempo (U∆t) sea menor que el tamano de la celda (∆x). En el caso particular delmetodo de Crank-Nicolson utilizado en la resolucion numerica, la condicion CFL no es necesariapara asegurar la estabilidad [67] por tratarse de un metodo A-Stable pero de todas formas, unnumero de Courant bajo es importante para mantener una buena precision numerica.

Se elige entonces ∆t = 0,061 como paso de tiempo constante para todas las simulaciones deforma arbitraria pero verificando que C ≈ 2. En efecto, para el caso extremo de ∆x = 0,03 yconociendo que la velocidad caracterıstica de la experiencia es unitaria, se obtiene:

C =1 · 0,061

0,03= 2,0333


4.3 Simulacion de la Experiencia

Ya definido el mallado, el paso de tiempo de simulacion (∆t = 0,061) y las condiciones decontorno, se construye un caso de estudio en Code Saturne para obtener las primeras mediciones.

4.3.1. Configuracion

El aplicativo posee dos archivos de suma importancia que deben ser modificados para confi-gurar correctamente el modelo:

usini1.f90 Establece los parametros fısicos y numericos del calculo. En el se define el pasode tiempo, viscosidad del fluido, la cantidad de pasos a simular, el orden del algoritmo devolumenes finitos, entre otras propiedades. Tambien contiene la informacion necesaria paradefinir los sensores de la experiencia que, dada la naturaleza del simulador, son definidosmediante sondas de prueba (probes) indicando la posicion cartesiana para cada una.

usclim.f90 Define las condiciones de contorno del sistema para las distintas caras de cada celdadel mallado. De esta forma se indican las condiciones de borde del sistema mediante elmapeo de las celdas del mallado a tipos conocidos por Code Saturne.

Es importante remarcar que mientras las subrutinas de configuracion del archivo usini1.f90 sonejecutadas una unica vez, al inicializar el motor de calculo, la configuracion de condiciones decontorno indicadas en usclim.f90 son invocadas cada paso de tiempo y por lo tanto, puedenser modificadas. En ese sentido, las condiciones de contorno son dinamicas y esto permitirıadinamizar los niveles de actuacion durante la iteracion de la simulacion.

A continuacion se incluye una breve resena sobre las principales modificaciones realizadas acada archivo para establecer la configuracion inicial de simulacion. El detalle del codigo fuenteutilizado puede encontrarse en el Apendice F.4.

4.3.1.1. usini1.f90

En primer lugar, es necesario fijar las variables numericas definidas para la simulacion. Deesta forma se define el paso de tiempo (dtref ), la cantidad de pasos a simular (ntmabs) y elorden de difusion para la resolucion de volumenes finitos (blencv) tanto en las componentesde velocidad (iu , iv y iw) como en el escalar pasivo utilizado (isca). Tambien es necesarioindicar los pasos de tiempo para el perıodo de muestreo empleado en las sondas (nthist) y parael total de celdas (ntchr). Cabe destacar que en ambos casos, el sistema almacena en archivoslos valores instantaneos medidos para la concentracion de escalar y las tres componentes develocidad. Salvo que se indique lo contrario, el muestreo en los sensores sera a cada paso detiempo y el muestreo general se realizara cada 10 paso a fines de obtener una representacioncompleta del estado de la simulacion.

...

65


dtref = 0.061d0

ntmabs = 16000

...

!first order diffusivity: 0.0d0

!second order diffusivity: 1.0d0

blencv(iu(iphas)) = 1.0d0

blencv(iv(iphas)) = 1.0d0

blencv(iw(iphas)) = 1.0d0

...

blencv(isca(1)) = 0.0d0

...

nthist = 1

ntchr = 10

...

A continuacion se definen las variables fısicas aplicables al fluido: la viscosidad dinamica(viscl0 ), las tres componentes de gravedad (gx , gy y gz ), la densidad (ro0 ), el calor especıfico,el valor de referencia de temperatura (t0 ) y de presion (p0 ). Salvo la viscosidad que tiene unimpacto directo en el numero de Reynolds, las otras variables fueron anuladas o llevadas a unvalor unitario para simplificar el desarrollo de la experiencia.

...

gx = 0.d0

gy = 0.d0

gz = 0.d0

...

ro0(iphas) = 1.d0

viscl0(iphas) = 1.d0/235.D0

cp0(iphas) = 1.d0

t0(iphas) = 1.d0

p0(iphas) = 0.d0

...

Ya definidas las variables fısicas y numericas, se debe especificar la ubicacion de cada sensor.Code Saturne soporta hasta 100 sondas de prueba para las cuales se almacena las magnitudesindicadas en archivos de texto especiales y con la frecuencia de muestreo correspondiente. Eneste caso, se decide definir las sondas de forma generica, estableciendo areas para su colocacionde forma equiespaciada. El siguiente extracto de codigo muestra la declaracion de la estructurapara indicar estas areas junto con las variables auxiliares necesarias:

! Declares a custom type which includes start and end coordinates for the probe’s area.

TYPE probes_area

double precision xStart

double precision yStart

double precision xEnd

double precision yEnd

double precision separation

END TYPE

!Declares auxiliary variables for the coordinates and separation between probes.

double precision xProbe, yProbe, xSeparationProbe, ySeparationProbe

integer iProbe, iProbeLine, iProbeArea

Luego, se definen las areas necesarias indicado la separacion, los lımites de inicio y de finpara cada una. En este caso se utilizaron dos areas de sondas, una con Y positivas y la otradispuesta simetricamente con Y negativas. Las areas son configuradas como lıneas paralelas aleje X con separacion de 0,5 diametros. Esta disposicion comprende a la necesaria para el sistemade control e incluye sondas extras que seran utilizadas con fines de inspeccion pero excluidas enlos distintos algoritmos.

!Defines two areas where the probes should be placed

TYPE(probes_area) probesAreas(2)

Capıtulo 4.3. Simulacion de la Experiencia 66


probesAreas(1) %xStart = 0.0

probesAreas(1) %xEnd = 20.0

probesAreas(1) %yStart = 1.0

probesAreas(1) %yEnd = 1.0

probesAreas(1) %separation = 0.5


probesAreas(2) %yStart = -1.0


probesAreas(2) %yEnd = -1.0


La coleccion de areas es recorrida y se almacena las coordenadas de cada sonda en xyzcap,con coordenada Z nula:

do iProbeArea = 1, size(probesAreas), 1

ySeparationProbe = sign(probesAreas(iProbeArea) %separation, &

probesAreas(iProbeArea) %yEnd - probesAreas(iProbeArea) %yStart)

xSeparationProbe = sign(probesAreas(iProbeArea) %separation, &

probesAreas(iProbeArea) %xEnd - probesAreas(iProbeArea) %xStart)

xProbe = probesAreas(iProbeArea) %xStart

do while (((xSeparationProbe.ge.0).and.(xProbe.le.probesAreas(iProbeArea) %xEnd)) &

.or.((xSeparationProbe.lt.0).and.(xProbe.ge.probesAreas(iProbeArea) %xEnd)))

yProbe = probesAreas(iProbeArea) %yStart

do while (((ySeparationProbe.ge.0).and.(yProbe.le.probesAreas(iProbeArea) %yEnd)) &

.or.((ySeparationProbe.lt.0).and.(yProbe.ge.probesAreas(iProbeArea) %yEnd)))

iProbe = iProbe + 1

xyzcap(1,iProbe) = xProbe

xyzcap(2,iProbe) = yProbe

xyzcap(3,iProbe) = 0.00d0

yProbe = yProbe + ySeparationProbe

end do

xProbe = xProbe + xSeparationProbe

end do

end do

ncapt = iProbe

4.3.1.2. usclim.f90

La definicion de las condiciones fısicas implica identificar las celdas del mallado que participanen cada una de los lımites de la experiencia. El mecanismo utilizado en este caso consiste enasignar un numero que representa un color a cada una de las celdas lımite. Aquellas celdas querequieran un tratamiento particular y la configuracion de condiciones de borde, seran filtradasdel resto para recibir la configuracion reservada por Code Saturne a tal fin.

El siguiente bloque de codigo, define las variables auxiliares necesarias junto con el mapeode bordes propuesto:

double precision alfa, beta

double precision xCentre, yCentre

real, parameter :: inputVelocity = 1d0

real :: upperActuatorValue, lowerActuatorValue

!Codigo de color, Nombre de Capa, Tipo de Lomite en CodeSaturne

!2, entrada, ientre + inyeccion de escalar

!3, salida, isolib

!4, pared, iparoi

!5, simetria, isymet

!7, actuador, iparoi + inyeccion de cantidad de movimiento



La pared del cilindro y el borde superior e inferior de simetrıa son de facil configuracion.Simplemente es necesario seleccionar las celdas que poseen sus respectivos colores mediantegetfbr(filtro, cantEncontradas, listaEncontradas) y luego definir el tipo de borde (itypfb)para cada cara de celda que cumpla con la condicion (ifac):

!pared -> iparoi

call getfbr(’4’, nlelt, lstelt)

do ilelt = 1, nlelt

ifac = lstelt(ilelt)

do iphas = 1, nphas

itypfb(ifac,iphas) = iparoi

enddo

enddo

!simetria -> isymet


do ilelt = 1, nlelt


do iphas = 1, nphas

itypfb(ifac,iphas) = isymet

enddo

enddo

La salida requiere configuraciones particulares sobre ciertos tipos de condiciones de borde(icodcl) y sus respectivos valores (rcodcl) para magnitudes en las caras como ser la presion(ipr), velocidad en X (iu), Y (iv) y Z (iw).

!salida -> isolib


do ilelt = 1, nlelt


iel = ifabor(ifac)

do iphas = 1, nphas

itypfb(ifac,iphas) = isolib

icodcl(ifac,ipr(iphas)) = 1 !dirichlet condition on pressure -> fixed value

icodcl(ifac,iu(iphas)) = 3 !neumann condition on velocity -> fixed gradient

icodcl(ifac,iv(iphas)) = 3

icodcl(ifac,iw(iphas)) = 3

rcodcl(ifac,ipr(iphas),1) = 0.0d0 !dirichlet value fixed to pressure=0

rcodcl(ifac,iu(iphas),3) = 0.0d0 !neumann value fixed to grad(u,normal) = 0

rcodcl(ifac,iv(iphas),3) = 0.0d0

rcodcl(ifac,iw(iphas),3) = 0.0d0

enddo

enddo

La entrada posee la complejidad extra de definir la zona de inyeccion de escalar para aquellascaras que posean el color indicado y tengan un centro en Y (calculado mediante cdgfbo(color,caraEncontrada)) entre las ordenadas −0,1 y 0,1. En estos casos, ademas de fijar la velocidadunitaria en el eje X a la constante inputVelocity = 1 , se define un valor unitario al escalar(isca).

!entrada -> ientre


do ilelt = 1, nlelt


do iphas = 1, nphas

itypfb(ifac,iphas) = ientre

rcodcl(ifac,iu(iphas),1) = inputVelocity





yCentre = cdgfbo(2,ifac)

do ii = 1, nscal

if(iphsca(ii).eq.iphas) then

if (yCentre.gt.-0.1d0.and.yCentre.lt.0.1d0) then

icodcl(ifac, isca(ii)) = 1

rcodcl(ifac, isca(ii),1) = 1.d0

else



endif

endif

enddo

enddo

enddo

Por ultimo, se filtran los elementos que definen los semi-arcos de actuacion para entregarlesun tratamiento particular. Mediante simples calculos de geometrıa, se asignan los componentesde velocidad enX e Y necesarios para obtener una inyeccion de movimiento tangencial a la pared.Se agregan dos variables para definir la magnitud de dichas velocidades: upperActuatorValuey lowerActuatorValue , ambas nulas para los fines de la simulacion inicial pero que seranmodificadas en cada iteracion cuando se defina el control para el cilindro.

upperActuatorValue = 0

lowerActuatorValue = 0

!actuador -> iparug

call getfbr(’7 and y > 0’, nlelt, lstelt)

do ilelt = 1, nlelt


xCentre = cdgfbo(1,ifac)


alfa = atan(yCentre / xCentre)

beta = alfa - pi/2.0

do iphas = 1, nphas


rcodcl(ifac,iu(iphas),1) = upperActuatorValue * cos(beta)

rcodcl(ifac,iv(iphas),1) = upperActuatorValue * sin(beta)


enddo

enddo

call getfbr(’7 and y < 0’, nlelt, lstelt)

do ilelt = 1, nlelt





beta = alfa + pi/2.0

do iphas = 1, nphas


rcodcl(ifac,iu(iphas),1) = lowerActuatorValue * cos(beta)

rcodcl(ifac,iv(iphas),1) = lowerActuatorValue * sin(beta)


enddo

enddo



4.3.2. Resultados

Una vez configurada de la experiencia, se procede con la ejecucion de la simulacion y el analisisde las mediciones obtenidas. La Fig. 4.3.1 muestra el avance del escalar inyectado generando unfilamento que difunde a traves del cilindro y demarca su burbuja de recirculacion. Una vez que laexperiencia entra en regimen, la aparicion de desprendimiento de vortices genera un movimientooscilatorio aguas abajo del cilindro que es adoptado por el trazador mediante las lıneas de emision(Fig. 4.3.2).

Figura 4.3.1: Inyeccion de trazador pasivo en el regimen inicial de la experiencia. Se puede observar la disposicionde los sensores aguas abajo del cilindro, en posiciones no alcanzadas aun por el escalar.

Figura 4.3.2: Inyeccion de trazador pasivo en regimen oscilatorio de la experiencia. El desprendimiento de vorticesprovoca un movimiento oscilatorio en la estela del cilindro que es copiado por el trazador.

Una magnitud caracterıstica para este tipo de experiencias fısicas es la vorticidad que sedefine como el rotor de la velocidad. En 2D se la puede expresar como ω(x, y, t) = ∂v

∂x −∂u∂y ,

siendo u(x, y, t) y v(x, y, t) las velocidades instantaneas en el eje X e Y respectivamente. Estamagnitud mide el grado de la rotacion local que sufre un punto (x, y) en el tiempo t entregandovalores negativos para una rotacion horaria y positivos para una anti-horaria. La Fig. 4.3.3compara los valores de escalar y vorticidad instantanea una vez que se establece el regimenoscilatorio.



Figura 4.3.3: Concentracion de escalar y vorticidad instantanea del flujo del cilindro. Realizando una comparacioncualitativa de ambas magnitudes se puede observar la similitud entre los caminos optados por el trazador y losvortices del camino de Von Karman.

La Fig. 4.3.4 entrega una vista de la variacion de la concentracion en los sensores 1 y 4 hastaque el sistema entra en regimen oscilatorio. En la misma se puede observar el retardo temporalque existe entre la informacion captada por cada sonda, producto de la distancia que poseenrespecto del cilindro.



Figura 4.3.4: Resultados de la concentracion de escalar medida por los sensores 1 y 4, el mas cercano y mas alejadodel cilindro respectivamente, durante la fase de inicio. Es posible apreciar el retardo que sufre el avance del escalarpor el frente izquierdo. Esto resulta evidente en las mediciones del sensor 4 respecto del 1 tanto en las primerasconcentraciones obtenidas como en las repetitivas oscilaciones que acompanan el desprendimiento de vortices.

Dado que la velocidad de muestreo es equivalente al paso de tiempo de la simulacion (∆t =0,061), resulta mas apropiado realizar los graficos en funcion de esta magnitud. La Fig. 4.3.5muestra los valores en cada uno de los sensores en funcion del paso de tiempo.



Figura 4.3.5: Evolucion de la concentracion del escalar media en los distintos sensores (probe 1..8). Se puedeobservar la diferencia de fase entre la senal de los sensores superiores (probe 1..4) y sus respectivas contrapartesinferiores (probe 5..8). Una vez alcanzado el regimen estacionario, las oscilaciones se identifican periodicas cada87 muestras.

Si bien, las senales de concentracion de escalar entregan una discretizacion del fenomenoreal simulado, se observa claramente una oscilacion periodica para el sistema. Una mediciondetallada de la oscilacion permite obtener una aproximacion del perıodo de la experiencia real.De esta forma, se determina empıricamente el perıodo de oscilacion para la concentracion delescalar en 87 muestras, es decir T = 87 · 0,061 = 5,307. Esto es ası tanto para los sensorescercanos al cilindro como para aquellos que se encuentran a mayor distancia.

Es importante comparar esta medicion con el numero de Strouhal estimado en el Capıtulo3.3 en base al Re de la experiencia: Stestimado = 0,1814. Dado que tanto el diametro como lavelocidad caracterıstica de la experiencia son unitarios, el valor de St coincide con la frecuenciaadimensional. Se puede aproximar el St real de la experiencia utilizando el T medido:

St =fD

U=f · 1

1= T−1 = 5,307−1

= 0,884



Luego, St resulta muy cercano al Stestimado e indica que las oscilaciones del escalar medidoestan relacionadas directamente con el desprendimiento de vortices. Mas aun, el perıodo de losdesprendimientos se puede aproximar como el perıodo de la senal medida en los sensores.


4.4 Comunicacion con el Sistema de Con-trol

El sistema de control disenado requiere algun mecanismo para modificar el valor de actuacionen Code Saturne de forma dinamica, esto es, frente a cada paso de tiempo.

Si bien las condiciones de borde pueden ser re-establecidas en cada iteracion de la simulacionmediante codigo Fortran, este lenguaje resulta poco flexible, no posee buenas interfaces parainteractuar con aplicaciones matematicas (Matlab, Scilab, Octave, Etc.) y su manejo de meca-nismos multi-threading posee muy poco soporte y escaso uso. Estos factores resultan importantessi se piensa en la extension y reuso del sistema tanto para escenarios de simulacion como paraimplementaciones experimentales. Por otro lado, los sistemas escritos en C y C++ se caracteri-zan por permitir la interaccion con una gran cantidad de lenguajes y esquemas de comunicacion,manteniendo a su vez un rendimiento de computo similar al de Fortran. Es importante remarcarque tanto Fortran como C/C++ poseen interfaces para realizar GPGPU mediante plataformascomo CUDA. Sin embargo, la version CUDA C/C++ posee una mayor aceptacion y soporte portratarse de un lenguaje mas popular.

4.4.1. Lenguajes Utilizados

Se plantea entonces un sistema externo a Code Saturne, escrito en C++, que resuelva elcontrol de la experiencia mediante la lectura de los sensores y el calculo de actuacion requerida. Afines practicos, se utiliza Matlab como utilitario de calculo matricial para resolver los algoritmosde identificacion del sistema y de control por su alto contenido matematico. Cabe aclarar queel objetivo principal de este esquema es obtener un entorno adecuado para implementar losalgoritmos descritos en los Capıtulos 3.4 y 3.5 debido a la complejidad matematica que poseeny a la flexibilidad necesaria para verificar la correctitud de los resultados.

Aunque es conocida la diferencia en velocidad de ejecucion entre programas de Matlab yC++, no se fijan requerimientos de performance particulares por tratarse de la etapa de si-mulacion de la experiencia. De todas formas, se entiende que todo el codigo escrito en rutinasde Matlab puede ser incluido en el sistema principal en C++ de una forma adecuada y, masaun, con la posibilidad de optimizar los tiempos de procesamiento de las secuencias altamenteparalelizables mediante GPGPU. Ese esquema posee grandes ventajas para una implementacionreal-time en laboratorio. La Fig. 4.4.1 presenta un esquema simplificado de la relacion entre losdistintos sistemas ideados que se detallan en las siguientes secciones.

75


Figura 4.4.1: Diagrama de bloques donde se muestra la dependencia entre los sistemas escritos en Fortran, C++y Matlab. Se utiliza el nombre de archivo representativo para cada caso.

Incluso cuando la implementacion en laboratorio queda fuera del alcance del presente trabajo,se realizaron distintos avances en tal direccion con el desarrollo de pruebas de concepto de losalgoritmos en CUDA C/C++(Apendice G.2) y de ejemplos de la obtencion programatica deimagenes a partir de distintas camaras (Apendice G.1).

4.4.2. Interaccion entre Modulos

En primer lugar es importante comprender que la amplitud de actuacion en la pared delcilindro se establece mediante las variables upperActuatorValue y lowerActuatorValue queconfiguran las condiciones de borde en el archivo usclim.f90 (ver Capıtulo 4.3.1). Para elobjetivo particular de la experiencia elegida, se asume que ambas variables estan sincronizadasy presentan la misma actuacion a cada instante de tiempo pero, de todas formas, el codigo delcontrolador esta preparado para soportar variables independientes.

Dado que se desarrolla el controlador en un sistema externo, el problema se resume enencontrar un mecanismo que detenga la ejecucion detallada en usclim.f90 frente a cada paso detiempo, notifique su numero al sistema externo, espere la respuesta de actuacion y modifique losvalores de upperActuatorValue y lowerActuatorValue . La Fig. 4.4.2 ilustra la dependenciaentre el sistema simulador y el controlador mediante un diagrama de actividades simple.

Capıtulo 4.4. Comunicacion con el Sistema de Control 76


Figura 4.4.2: Diagrama simple de las actividades del simulador y controlador. Se pueden observar la concurrenciaentre los ciclos principales de cada subsistema y la dependencia del simulador sobre los valores calculados por elcontrolador.

Por otro lado, el sistema controlador debe obtener los valores medidos en los distintos sensoresy elaborar una actuacion ya sea durante el entrenamiento del sistema e identificacion del ARX odurante el control de la estela. La actuacion de entrenamiento funciona en una fase inicial, dondelas muestras son acumuladas hasta contar con la cantidad suficiente para identificar el sistema.Luego de calcular el modelo ARX, se lo utiliza con las muestras pasadas en el algoritmo de controlpredictivo para calcular la actuacion que mejor ajusta la funcion objetivo. Esta secuencia nospresenta 2 fases marcadas: la fase de entrenamiento y la fase de control. La identificacion delsistema marca el punto de division entre ambas fases. En este caso, la muestra con los valoresde los sensores sera obtenida de los archivos generados por Code Saturne que almacenan lasmediciones en formato CSV a cada paso de tiempo. A tal fin, se implementa un Parser querecolecta las muestras.

Las Fig. 4.4.3 presenta un diagrama de colaboracion simple que describe la secuencia decomunicacion entre los modulos mencionados durante la fase de entrenamiento. Cuando lasmuestras recolectadas alcanzan el numero necesario, se ejecuta el algoritmo de identificacion delsistema y se entra en la fase de control a lazo cerrado (Fig. 4.4.4).



Figura 4.4.3: Diagrama de colaboracion de la fase de entrenamiento.

Figura 4.4.4: Diagrama de colaboracion de la fase de control.

4.4.3. Implementacion

Se decide mantener la independencia de procesos entre ambos sistemas y emplear una es-quema de comunicacion mediante pipes de sistemas operativos basados en Unix. Dado que lacomunicacion es bidireccional, se requieren dos archivos para establecer los canales de comuni-cacion en cada sentido. Los pipes son creados por nombre a traves de archivos especiales FIFOconstruidos con el comando mkfifo. El pipe de escritura para el simulador y lectura para elcontrolador es llamado semaphore dado que permite senalizar al controlador en el momentoen que se requiere calcular el nuevo valor de actuacion. La senal incluye el numero de paso detiempo como parametro que resulta importante en el sistema controlador para recolectar lasmuestras adecuadas mediante el Parser. El otro sentido de la comunicacion es representado porlos archivos act.upper y act.lower que permiten enviar los valores decimales de amplitud deactuacion al simulador. Los descriptores de archivo son abiertos en cada sistema de modo blo-queante, de esta forma, los sistemas intercalan mensajes y se esperan mutuamente mientras supar realiza operaciones de calculo.

El siguiente bloque de codigo muestra la creacion de los pipes y el lanzamiento del procesocontrolador al que se le indican los nombres definidos. Luego, el simulador abre los archivosespeciales en modo escritura o lectura segun sea necesario. Esta secuencia de inicio se efectuauna unica vez gracias a la guarda de la variable estatica actuatorValuesInitialized :

if (.not.actuatorValuesInitialized) then



call system("mkfifo semaphore")

call system("mkfifo act.upper")

call system("mkfifo act.lower")

call system("./controller act.upper.csv act.lower.csv" &

//" probes_Scalar1.dat < semaphore &")

open(unit=103, file="semaphore", action="write")

open(unit=104, file="act.upper", action="read")

open(unit=105, file="act.lower", action="read")

actuatorValuesInitialized = .true.

endif

Luego, frente a cada iteracion, el simulador escribe en el pipe el paso de tiempo (ntcabs) yespera hasta que los valores de actuacion son notificados por los otros pipes:

write(sStepNumber, ’(i0)’ ) ntcabs

write(103,*) sStepNumber

read(104,*) upperActuatorValue

read(105,*) lowerActuatorValue

Por ultimo, al encontrarse en el paso de tiempo final de la simulacion (ntmabs), cierra losdescriptores indicando al controlador que la simulacion ha finalizado:

if (ntmabs.eq.ntcabs) then

close(103)

close(104)

close(105)

endif

El sistema controlador, por su parte, consta de un ciclo en el archivo main.cpp que empleauna instancia de la clase SaturneCommunicator para esperar por el paso de tiempo (se-maphoreStepNumber) proveniente del pipe y enviar la actuacion (act.upper y act.lower)por los pipes restantes. A su vez, se utiliza un objeto Parser para recolectar las mediciones enel paso de tiempo anterior y un Controller para calcular la actuacion en base a las muestras.El ciclo de control finaliza cuando se obtiene un paso de tiempo invalido.

...

Controller controller(/*...*/);

Parser parser(/*...*/);

SaturneCommunicator saturneCommunicator;

controller.initialize(/*...*/);

bool continueControl = true;

while (continueControl) {

int semaphoreStepNumber = saturneCommunicator.waitForStep(semaphore);

if (semaphoreStepNumber > 0) {

Row values = parser.readValues(probesPressureFilepath , semaphoreStepNumber - 1);

Actuation act = controller.getActuationFor(semaphoreStepNumber, values);

saturneCommunicator.send(upperActuator, act.upper);

saturneCommunicator.send(lowerActuator, act.lower);

}

else {

continueControl = false;

}

}

...

Resulta interesante observar que la implementacion de los metodos de espera (waitForS-tep) y envıo (send) que posee la clase SaturneCommunicator se implementan con simplesoperaciones de lectura y escritura bloqueantes en los archivos que representan los pipes:



int SaturneCommunicator::waitForStep(std::istream& semaphore) {

unsigned int semaphoreStepNumber;

semaphore >> semaphoreStepNumber;

if (semaphore.good()) {

return semaphoreStepNumber;

else

return 0;

}

void SaturneCommunicator::send(std::ofstream& actuatorFile, double value) {

std::stringstream converter;

converter << value;

std::string strValue;

converter >> strValue;

actuatorFile << strValue <<std::endl;

}

El detalle del sistema controlador ası como las distintas abstracciones utilizadas puede en-contrarse en el Apendice F.6.


4.5 Identificacion del Sistema

La fase de identificacion del sistema tiene por objetivo la obtencion de un modelo ARX queajuste de la mejor manera al modelo fısico simulado. A tal fin, se utiliza el sistema controladorpara forzar una senal de actuacion predeterminada, capturar las muestras en los sensores duranteN pasos de tiempo e identificar el modelo ARX de orden p mediante una implementacion enMatlab del algoritmo introducido en el Capıtulo 3.4.

4.5.1. Entrenamiento del Sistema

Como senal de entrenamiento se escoge un pulso de gran altura y corta duracion. Este tipode senal es ampliamente utilizada para evaluar la respuesta de sistemas debido a la variedad defrecuencias que posee. La duracion del pulso se establece en 10 pasos de tiempo y la amplituden 10. Estos valores demuestran de forma empırica que son suficientes para obtener un cambiosignificativo en la dinamica de la estela con un efecto estabilizador durante un lapso corto detiempo.

La identificacion del sistema se realiza con una medicion de N = 1090 muestras totales y conun pulso iniciado en el paso de tiempo 90. Como fuera descrito en el Capıtulo 3.3, la cantidadde sensores que define al sistema es de m = 8 mientras que la cantidad de componentes de laactuacion es r = 1. Los resultados pueden observarse en la Fig. 4.5.1.

81


Figura 4.5.1: Fase de entrenamiento del sistema. Se puede observar la evolucion de la concentracion del escalar enlas 8 sensores en relacion con el pulso forzado en la actuacion. Los graficos del escalar muestran que el efecto delpulso posee un retardo dependiendo de la distancia del sensor a la zona de actuacion. Tambien es posible observarque el desfasaje constante que existe entre senales de sensores simetricas es afectado por la actuacion durante unbreve perıodo de tiempo.

Luego de cierto tiempo de disparar el pulso, la concentracion del escalar se reduce drastica-mente en los distintos sensores. Considerando el flujo como un sistema dinamico no lineal, lasvariables de estado orbitan alrededor de un centro de atraccion [65]. El pulso forzado perturbadicha orbita de forma abrupta para luego entrar en una etapa de relajacion. La orbita de oscila-cion natural es retomada gradualmente a medida que el sistema entra en regimen. El retardo decontrol (death-time) se explica por la distancia de los sensores al punto de actuacion y aumenta

Capıtulo 4.5. Identificacion del Sistema 82


gradualmente a medida que el sensor se aleja.El orden del modelo ARX, p, define la cantidad de muestras para el horizonte de autoregre-

sion y debe ser establecido de forma tal que el modelo capture las relaciones entre los distintoscomponentes del vector de estado. En efecto, el valor de p, establece una ventana temporaldonde las mediciones y actuacion se vinculan mediante los coeficientes del modelo. Si la ventanaes muy pequena, el modelo no captura efectos que cierta variable (por ejemplo, la actuacion)causa en otra (por ejemplo, un sensor arbitrario) en casos donde la reaccion posee un retardomayor al tamano de ventana. Una ventana muy grande, ademas de requerir cantidades excesivasde procesamiento para el calculo y uso del modelo, puede resultar innecesaria si los efectos deuna variable sobre otra tienen retrasos temporales mucho menores a la ventana. Como agre-gado se conoce que a mayor p se obtiene un mejor ajuste del modelo frente a la respuesta delentrenamiento con el costo de aumentar su sensibilidad frente a ruidos.

A fines practicos se elige un valor de p = 90, levemente mayor al perıodo natural de laexperiencia. Como se puede observar en el Apendice C.1, este valor de p asegura un ajustepromedio del 99,7 % entre los valores reales obtenidos de la fase de entrenamiento y los valoresde prediccion que puede realizar el modelo ARX.

4.5.2. Implementacion del Algoritmo

El calculo del modelo escrito en Matlab se dispara desde el sistema controlador en C++utilizando la interfaz provista por las librerıas MEX de Matlab. Este comportamiento es encap-sulado en la clase MatlabExecutor que interactua con la interfaz MEX transmitiendo datosy operaciones. Para facilitar su uso, se construye la abstraccion Matrix que almacena valoresdouble en formato matricial. La interfaz de MatlabExecutor incluye operaciones para definirvariables matriciales, obtener su valor o evaluar expresiones matematicas como se muestra acontinuacion:

class MatlabExecutor {

private:

Engine *ep;

//...

public:

MatlabExecutor(/* ... */);

~MatlabExecutor();

void putMatrix(const std::string& matrixVariableName, Matrix& values);

Matrix getMatrix(const std::string& matrixVariableName);

void evaluate(const std::string& expression);

double evaluateScalar(const std::string& expression);

};

La implementacion completa, las clases Matrix y MatlabExecutor , ası como su modo deuso puede encontrarse en el Apendice F.6.

El caso particular de la identificacion del sistema se resuelve evaluando la funcion lfd arx ,de Matlab. La funcion calcula las matrices A y B de orden p del modelo ARX en base a lasmediciones y y u indicadas por el sistema controlador:

function [A B] = lfd_arx(y, u, p)

Se definen las variables na y nb respecto del orden del modelo p y se obtiene m , r , N delas dimension de los vectores de muestras para agrupar sus valores en la variable ϕ(k), llamadaphi , segun la Ec. 3.4.2:

na = p;

nb = na+1;

[m,N] = size(y);



[r,N] = size(u);

phi = zeros(na*m+nb*r,N);

for j=na+1:N

phi(:,j)=[reshape(-y(:, j-1:-1:j-na), na*m, 1); ...

reshape(u(:, j:-1:j-(nb-1)), nb*r, 1)];

end

Luego se calcula la matriz de regresion Ξ(k), llamada reg , utilizando el producto de Kro-necker sobre los valores de ϕ(k):

phi_aux = fi(:, na+1:end);

reg = zeros(m*size(phi_aux,1), m*(N-na));

for j=1:N-na

reg(:, 1+(j-1)*m:j*m) = kron(phi_aux(:,j), eye(m));

end

Finalmente, se obtiene R de una descomposicion QR sobre la matriz de regresion y lasentradas para estimar el valor de θ, llamado th , segun la Ec. 3.4.4:

yna = y(:, na+1:end);

Y = reshape(yna, m*(N-na), 1);

R = triu(qr([reg’ Y]));

d = na*m*m+nb*r*m;

R0 = R(1:d+1,1:d+1);

R1 = R0(1:d,1:d);

R2 = R0(1:d,end);

th = pinv(R1) * R2;

Por ultimo, los coeficientes αi y βi son extraıdos del estimador y organizados en las matricesdel modelo: A y B .

a = zeros(m, m, na);

b = zeros(m, r, nb);

for j=1:na

a(:,:,j)=reshape(th(1+(j-1)*m*m:j*m*m),m,m);

end

for j=1:nb

b(:,:,j)=reshape(th(1+na*m*m+(j-1)*m*r:1+na*m*m+(j-1)*m*r+m*r-1),m,r);

end

A = zeros(m, m, na+1);

A(:,:,1) = eye(m);

A(:,:,2:end) = a(:,:,:);

B = b;

El codigo completo del calculo del modelo ARX se puede encontrar en el Apendice F.5 juntocon la version implementada en CUDA C/C++ (Apendice G.2.

El Apendice C.2 presenta una breve comparacion sobre las diferencias en los tiempos deprocesamiento requeridos por la version Matlab y CUDA C/C++ del algoritmo.

4.5.3. Verificacion del Modelo ARX

Para verificar la validez del modelo se utiliza una senal de excitacion distinta a la empleadadurante la fase de entrenamiento y se simula su respuesta mediante Code Saturne. Las medicionesresultantes de concentracion de escalar son comparadas con predicciones obtenidas del modeloARX. En tal sentido se plantea el uso de la rutina compare de Matlab para predecir los valoresde yi(k) y disponerlos graficamente juntos a los medidos. La prediccion utiliza un horizonte des = 90 pasos de tiempo en dos escenarios distintos donde se utiliza como entrada de actuacion



a la superposicion de ciertas senales gaussianas de la forma:

g(t) = A · e−((t−µ)2

2·σ2)

donde A indica la amplitud, µ la media de la campana y σ su desvıo estandar. El valor de µ difiereentre las distintas senales para desplazarlas entre sı. Se utiliza cierto perıodo de repeticion parael corrimiento de las senales que permite calcular una frecuencia caracterıstica de la actuacionresultante.

El primer escenario superpone gaussianas de A = 0,55 y σ = 20 con un desplazamiento entre

µ de 70 pasos de tiempo. Esto implica una frecuencia caracterıstica de1

70 · 0,061= 0,2342 que

equivale aproximadamente a un 125 % de la frecuencia natural de la experiencia (0,1884). Estadiferencia de frecuencias es pequena y permite lock-in entre la dinamica del desprendimientode vortices y la frecuencia impuesta por el actuador. En esos casos se observa que el sistemamodifica su frecuencia de oscilacion debido a la influencia de la senal de excitacion y su frecuencia(Fig. 4.5.2).



Figura 4.5.2: Comportamiento del modelo frente a una actuacion de frecuencia 0,2342 con A = 0,55 y σ = 20.Los graficos superiores presentan la evolucion en la concentracion del escalar a lo largo del tiempo para distintossensores. El grafico inferior muestra la senal aplicada simultaneamente a ambos actuadores.

En el segundo caso se utiliza A = 0,60 y σ = 20 con un desplazamiento entre µ de 45 pasos

de tiempo. Esto implica una frecuencia de1

45 · 0,061= 0,3643 equivalente a 193 % de la frecuen-

cia original. Se observa un comportamiento satisfactorio del modelo pudiendo reproducir lasfrecuencias principales de las oscilaciones de la experiencia. La concordancia de las prediccionescon la respuesta fısica resulta evidente en la etapa sin actuacion forzada y disminuye al iniciar elcontrol pero sin observarse diferencias considerables. El sistema resulta estable durante el lapsode actuacion y retorna al estado de equilibrio al finalizar (Fig. 4.5.3).



Figura 4.5.3: Comportamiento del modelo frente a una actuacion de frecuencia 0,3643 con A = 0,60 y σ = 20.En los graficos superiores se observa la evolucion en la concentracion del escalar a lo largo del tiempo paradistintos sensores. El grafico inferior muestra la senal aplicada simultaneamente a ambos actuadores. Se incluye larespuesta del sistema al cesar la actuacion pudiendose observar que las predicciones mejoran gradualmente hastaque el sistema entra nuevamente en regimen.

Realizando un analisis de frecuencia de la senales simuladas en comparacion con las pre-dicciones, se encuentra una gran similitud en los patrones de frecuencia resultantes. En amboscasos se analiza el numero de Strouhal de la experiencia entendiendo que, por las dimensionesutilizadas para la simulacion, St = f . Las frecuencias caracterısticas de la experiencia se mo-difican levemente durante el perıodo de control, hecho que es captado por las predicciones delsistema (Fig. 4.5.4 y 4.5.5).



Figura 4.5.4: Espectrogramas de la verificacion del modelo mediante una senal de frecuencia 0,2342 (125 % respectode la caracterıstica del sistema). Se compara el espectrograma de la simulacion (izquierda) y de las prediccionesdel modelo ARX obtenido en la fase de identificacion del sistema.

En el caso extremo de frecuencia de actuacion 0,2342 (Fig. 4.5.5), la prediccion del modeloagrega un componente de alta frecuencia a las salidas que el sistema real no posee. Esto puedeestar relacionado con la saturacion de la dinamica del flujo inducida por las no-linealidades queestan ausentes en el modelo lineal ARX. Un simple analisis de Fourier sobre la parte periodicade las senales de actuacion demuestra la componente de alta frecuencia no es introducida por elactuador, al menos no directamente (Fig. 4.5.6). El analisis de frecuencia para ambas actuacionespresenta picos para componentes que coinciden con las frecuencias estimadas de 0,2342 y 0,3643,correspondientes al 125 % y 193 % de la caracterıstica.

Figura 4.5.5: Espectrogramas de la verificacion del modelo mediante una senal de frecuencia 0,3643 (193 % respectode la caracterıstica del sistema). Se compara el espectrograma de la simulacion (izquierda) y de las prediccionesdel modelo ARX obtenido en la fase de identificacion del sistema.



Figura 4.5.6: Analisis de frecuencia de las senales de actuacion utilizadas para la verificacion del modelo ARX.Se elimina la componente media para mayor claridad de espectro de frecuencias relevante. Sup.: Modulo de latransformada de Fourier de la senal de gaussianas superpuestas con frecuencia 0,2342. Inf.: De forma analoga alanterior, se analizan los componentes de Fourier de la senal de gaussianas con frecuencia 0,3643.


4.6 Sistema de Control a Lazo Cerrado

Luego de identificado el modelo ARX, el sistema deja la fase de entrenamiento para entrar enmodo de control a lazo cerrado. Esta fase se caracteriza por requerir el calculo inicial de ciertosparametros que seran reutilizados en operaciones mas simples en iteracion de la simulacion. Estepaso es disparado una unica vez por el subsistema C++ efectuando el computo en Matlab. Asu vez, las muestras y valores de actuacion son acumulados en C++ para ser utilizados en lainvocacion de una nueva funcion en Matlab frente a cada paso de tiempo.

4.6.1. Implementacion del Algoritmo

4.6.1.1. Inicializacion

Al entrar en la fase de control, el sistema C++ inicia el estado del subsistema Matlab cal-culando control state . Esta estructura almacena los parametros basicos del controlador, p, s,q y λ, junto con la matriz de control, K, calculada en base al modelo ARX (Ec. 3.5.5). Laimplementacion incluye una variable limits que permite definir mınimo y maximo permitidospara la actuacion.

function [ control_state ] = lfd_control_lagrange_init(y, u, p, lambda, A, B, limits, q)

En primer lugar se determinan las dimensiones del sistema en base a la cantidad de compo-nentes del vector de estado y el paso actual de tiempo es asumido sobre la cantidad de muestras:

m = size(y,1);

r = size(u,1);

s = 3*p;

k = size(y,2);

El horizonte de prediccion se fija en s = 270, 3 veces el valor de p. Esta cantidad indica los pasosde tiempo proyectados por el controlador hasta conseguir una actuacion estable (sin variaciones).Se opta por emplear un valor de s elevado para evitar un controlador agresivo respecto de laproyeccion del valor de actuacion optimo y el tiempo para conseguirlo. De esta forma se pretendecontemplar la naturaleza oscilatoria del sistema y la posibilidad de oscilaciones en el control delorden de 3 veces el perıodo caracterıstico del fenomeno. A su vez, se tiene conocimiento deresultados exitosos en experiencias de control similares con 2p ≤ s ≤ 3p [35, 36].

A continuacion, se transforma el modelo ARX a la convencion propuesta en [33] que presentaciertas facilidades en su manipulacion. Luego, se calculan los parametros del sistema de Markov,

β0, β(1)0 , . . . β

(s−1)0 :

a = -A(:,:,2:end);

b = B;

beta00 = b(:,:,1);

beta0 = zeros(m, r, s-1);

beta0(:,:,1) = b(:,:,2) + a(:,:,1)*beta00;

90


for kk=2:s-1

if kk<=p

aux=zeros(size(beta00));

for l=1:kk-1;

aux=aux+a(:,:,l)*beta0(:,:,kk-l);

end

aux=aux+a(:,:,kk)*beta00;

beta0(:,:,kk) = b(:,:,kk+1)+aux;

else


for l=1:p;


end

beta0(:,:,kk)=aux;

end

end

Con estos valores se conforma T segun Ec. 3.5.2:

T=zeros(m*s,r*s);

T_column =zeros(m*s,r);

T_column(1:m,:)=beta00;

for j=2:s;

T_column((j-1)*m+1:j*m,:)=beta0(:,:,j-1);

end;

for column = 1:s

T(m*(column-1)+1:m*s, r*(column-1)+1:r*column) = T_column(1:(m*s - (column-1)*m),:);

end;

Luego se calculan las relaciones recursivas de αk1 , αj

k y βjk en las variables alpha y beta :

psi=zeros(m*s,p*(m+r));

for kk=1:p-1;

alpha(:,:,1,kk)=a(:,:,1)*a(:,:,kk)+a(:,:,kk+1);

end;

alpha(:,:,1,p)=a(:,:,1)*a(:,:,p);

for j=2:s-1;

for kk=1:p-1;

alpha(:,:,j,kk)=alpha(:,:,j-1,1)*a(:,:,kk)+alpha(:,:,j-1,kk+1);

end;

alpha(:,:,j,p)=alpha(:,:,j-1,1)*a(:,:,p);

end

for kk=1:p-1;

beta(:,:,1,kk)=a(:,:,1)*b(:,:,kk+1)+b(:,:,kk+2);

end

beta(:,:,1,p)=a(:,:,1)*b(:,:,p+1);

for j=2:s-1;

for kk=1:p-1;

beta(:,:,j,kk)=alpha(:,:,j-1,1)*b(:,:,kk+1)+beta(:,:,j-1,kk+1);

end;

beta(:,:,j,p)=alpha(:,:,j-1,1)*b(:,:,p+1);

end

que permiten definir Ψ, llamada psi , segun la Ec. 3.5.3:

psi(1:m,:) = [reshape(a, m, m*p) reshape(b(:,:,2:end), m, r*p)];

for j=2:s

psi((j-1)*m+1:j*m,:) = [reshape(alpha(:,:,j-1,:), m, m*p) reshape(beta(:,:,j-1,:), m, r*p)];

end

Capıtulo 4.6. Sistema de Control a Lazo Cerrado 91


Con las matrices T y Ψ definidas, se calculan las primeras r filas de la matriz de control K(Ec. 3.5.5) utilizando q y λ. Tanto la variable de resultado, K r , como los parametros de inicioson almacenados en control state :

Q=kron(eye(s), diag(q));

invLambdaTTQT = -pinv(lambda*eye(r*s) + T’*Q*T);

control_state.K_r = invLambdaTTQT(1:r, :) * T’ * Q * psi;;

control_state.p = p;

control_state.limits = limits;

control_state.s = s;

control_state.m = m;

control_state.r = r;

control_state.lambda = lambda;

4.6.1.2. Iteracion de Control

Ya inicializado el estado del control, se ingresan los valores y(k) medidos en los sensores yel u(k) utilizado en un paso de tiempo para calcular u(k + 1), la actuacion del siguiente paso.La funcion lfd control lagrange recibe dichos valores y retorna control state modificadoincluyendo la actuacion calculada:

function control_state = lfd_control_lagrange(control_state, y, u)

En primer lugar, se define el paso de tiempo k sobre el cual se realizara el calculo y serecuperan las variables de la estructura del estado para facilitar su uso:

k = size(y, 2) + 1;

limits = control_state.limits;

p = control_state.p;

m = control_state.m;

r = control_state.r;

K_r = control_state.K_r;

Se conforma el vector columna vp(k − p) con los valores pasados de y(k) y u(k). Luego, seutiliza el vector junto con las r filas calculadas de la matriz de control, K r , para obtener lanueva actuacion segun la ley de control establecida en Ec. 3.5.7:

vp = zeros(p*m+p*r, 1);

for i=1:p

vp((i-1)*m+1:i*m) = y(:,k-i);

end

offset = m*p;

for i=1:p

vp((i-1)*r+1+offset:i*r+offset) = u(:,k-i);

end;

u_k = K_r * vp;

Por ultimo, se utilizan los lımites definidos con anterioridad para eliminar valores de actua-cion fuera de los rangos aceptados por la experiencia:

indices_out_of_limit = find(u_k < limits.min_value);

u_k(indices_out_of_limit) = limits.min_value;

indices_out_of_limit = find(u_k > limits.max_value);

u_k(indices_out_of_limit) = limits.max_value;

control_state.u_k = u_k;

A modo de sıntesis, la Tabla 4.6.1 resume los valores de los parametros de ajuste utilizadosen el algoritmo de control. El resultado de control demostro ser muy sensible a la definicion de



dichos valores. Los ajustes finales requirieron un trabajo de comparacion manual y de reiteradassimulaciones a fin de balancear el efecto conjunto de los parametros.

Parametro Variable ValorOrden del Modelo p 90Horizonte de Prediccion s 270Paso de Tiempo Simulacion ∆t 0.061Peso de Sensores Sup. q1, q2, q3, q4 1,4, 1,4, 1,4, 1,4Peso de Sensores Inf. q5, q6, q7, q8 1,4 1,4 1,4 1,4Costo del Controlador λ 0,4

Tabla 4.6.1: Valores definidos para los distintos parametros de control del sistema.

4.6.2. Resultados de Control

A fines de verificar la respuesta del algoritmo de control, se ejecuta una nueva simulacion enla cual se activa el controlador luego de acumular las suficientes muestras para calcular y utilizarla matriz de control. En el sistema C++ se incluye la posibilidad de almacenar y recuperar elmodelo ARX debido a sus altos tiempos de computacion respecto de las operaciones de control.Se emplea entonces el modelo ARX calculado en la fase de entrenamiento, previamente guardadoen archivos de datos Matlab, y se activa el controlador obteniendo una actuacion que estabilizala estela (Fig. 4.6.1).



Figura 4.6.1: Resultados del sistema de control a lazo cerrado. Se puede observar el efecto de la amplitud deactuacion sobre la concentracion del escalar en los distintos sensores en funcion del tiempo.

La senal de actuacion resultante presenta un caracter oscilatorio marcado, donde los mo-vimientos ascendentes (descendientes) del actuador generan una reduccion (incremento) en elescalar medido en los sensores. De acuerdo con la posicion del sensor respecto de la actuacion,es necesario considerar un retardo temporal variable.

La estabilizacion de la estela del cilindro puede apreciarse en imagenes instantaneas de laslıneas de emision (Fig. 4.6.2) que difieren del escenario sin actuacion y se mantienen limitadasen la zona del “tunel” de sensores. Por su parte la vorticidad instantanea (Fig. 4.6.3) disminuyeconsiderablemente respecto de los valores originales.



Figura 4.6.2: Lıneas de mision y valores de la concentracion del escalar en los sensores durante la fase de actuacion.Es posible observar el efecto del control que restringe las lıneas de mision al interior del ”tunel“ de sensores.

Figura 4.6.3: Vorticidad instantanea y valores en las sondas durante la fase de control. Los valores detectadosresultan menores que las mediciones en un escenario sin actuacion.

La frecuencia de oscilacion de la entrada genera entonces una oscilacion en la salida. Esinteresante observar que las oscilaciones caracterısticas del fenomeno se mantienen con unafrecuencia similar a la original dentro de la envolvente de menor frecuencia. En la Fig. 4.6.4se puede observar el espectro de frecuencias de actuacion con un componente muy marcado entorno a frecuencias de 0,05 correspondiente al 26 % de la frecuencia caracterısticas del fenomeno(0,1884). Las Figs. 4.6.5 y 4.6.6 entregan una comparacion de la frecuencias de la salida medidaen los sensores 1, 2, 3 y 4 para los casos sin actuacion y con actuacion. En el segundo caso se



puede observar la aparicion de un componente de 0,05 inducido por la actuacion, preponderantesobre las otras frecuencias. La frecuencia caracterıstica original (Aprox. 0,19) y sus armonicos(0,38, 0,57, Etc.) de menor amplitud se pueden encontrar en las senales controladas pero conuna importante dispersion en torno a sus valores originales.

Figura 4.6.4: Analisis de frecuencias de la actuacion. Modulo de la transformada de Fourier de la entrada menossu media.

Figura 4.6.5: Analisis de frecuencias de la senal de salida para los sensores 1 y 2. Se puede comparar el modulode la transformada de Fourier de la senal menos su media para el caso sin actuacion (Izq.) respecto del caso conactuacion (Der.).



Figura 4.6.6: Analisis de frecuencias de la senal de salida para los sensores 3 y 4. Se puede comparar el modulode la transformada de Fourier de la senal menos su media para el caso sin actuacion (Izq.) respecto del caso conactuacion (Der.).

Es importante destacar la reduccion en la amplitud de los componentes de frecuencia, indi-cando una disminucion del trazador captado por los sensores. Se puede atribuir este resultado alcomportamiento de las lıneas de mision que se concentran ahora dentro del “tunel” de sensores.A su vez, esto coincide con el descenso en el valor medio detectado en cada sensor segun se puedeobservar en la Tabla 4.6.2.

Media y1 y2 y3 y4 y5 y6 y7 y8Sin Actuacion 0,077 0,071 0,063 0,058 0,077 0,071 0,064 0,057Con Actuacion 0,043 0,047 0,051 0,054 0,043 0,046 0,050 0,054

Tabla 4.6.2: Valores medios del escalar en los distintos sensores. Se puede ver un claro descenso de los valores deconcentracion medidos sin el controlador y con el controlador. La disminucion posee un porcentaje mayor en lossensores mas cercanos al punto de actuacion.

4.6.2.1. Analisis de Energıa y RMS de las Fluctuaciones en la Estela

Un posible criterio de estabilizacion de flujos consiste en el calculo de la energıa cineticade la turbulencia (Turbulent Kinetic Energy o TKE) en el estado original y compararlo con laobtenida durante el ciclo de control. El calculo de la TKE se basa en el principio de separacionde variables en las partes media y turbulenta de cierta senal [63]. La parte media es constante ycaracteriza el comportamiento estacionario del flujo mientras que la parte turbulenta dependedel tiempo y, por lo tanto, se relaciona a la dinamica del mismo. Con este esquema es posibledescribir la velocidad u(t) de una partıcula segun:

u(t) = u+ u′(t)

donde u es la velocidad media y u′(t) representa la velocidad de perturbaciones o turbulencias(Fig. 4.6.7). Luego, el calculo de la energıa cinetica sobre la componente fluctuante de la velocidadentrega la TKE. En el caso de 2D y sumando los aportes de cada partıcula serıa:

TKE(t) =1

2

∑(u′x(t)

2+ u′y(t)

2)



La formula anterior debe entenderse como el calculo de energıa por unidad de masa, siendoTKE(t)/m una definicion mas rigurosa. Luego, los valores de TKE calculados para cada celdade la simulacion se pueden integrar solo si se asume que poseen masa homogenea. Esto es unabuena aproximacion en el caso de celdas de identico tamano pero no puede asegurarse en elmallado no estructurado aplicado a la experiencia (Capıtulo 4.2).

Para resolver este problema y permitir el analisis detallado del campo de velocidades re-sultante de la experiencia, se implementa un sistema de transformacion para mallas irregularesdefinidas por polıgonos 2D en mallas regulares con celdas cuadradas de cierto tamano prefijado.La Fig. 4.6.8 entrega una vista de la malla original y la conversion a una grilla de celdas regula-res. Sabiendo que los celdas de la malla original varıan de tamano entre 0,03 y 0,1, se opta porgenerar una grilla con celdas cuadradas de lado 0,045 que permita captar el detalle de las celdaspequenas en las cercanıas del cilindro.

Figura 4.6.7: Representacion grafica de la composicion de una senal (u(t)) mediante sus partes media (u) yperturbaciones o turbulencias (u′(t)). La dinamica de la senal original queda caracterizada por u′(t) mientras queu responde al comportamiento estacionario (basado en Stull, 2008) [63].

Figura 4.6.8: Conversion de valores medidos en malla irregular a una grilla homogenea. Sobre el mallado original(Izq.) se dispone una grilla celdas cuadradas (Der.). A modo de ejemplo, se colorean los triangulos del malladooriginal que participan en una celda cuadrada del nuevo mallado (resaltada en rojo). Las superficies parcialesde color rojo participan en la composicion de la magnitud fısica mientras que las naranjas no lo hacen por serproyectadas fuera del cuadrado.

La transformacion se realiza generando una grilla cartesiana con celdas de identico tamano,recorriendo cada celda de la grilla y proyectando en ella las celdas originales de la malla. Paracada celda de la nueva grilla se recorren las celdas de la malla original calculando el porcentajede superposicion en la proyeccion. Luego, la magnitud fısica de la celda cuadrada se componedel aporte pesado de las celdas originales proyectadas en ella.

De esta forma, cada celda de la malla irregular puede aportar a una o mas celdas de la grillaregular. El codigo de conversion puede ser encontrado en el Apendice F.2 e incluye la lectura de



los archivos CHR de salida de la simulacion Code Saturne. Dichos archivos poseen informacionescalar (como la concentracion de trazador pasivo) o vectorial (como las componentes del campode velocidades) en formato Ensight Gold [12] que permite post-procesamiento y visualizacion delos valores para una geometrıa de la experiencia.

Luego de obtener la conversion a una grilla homogenea, se calcula el TKE instantaneo enla superficie que comprende la region bajo estudio. Un analisis detallado de la TKE demuestraque la energıa asociada con las fluctuaciones disminuye considerablemente luego de iniciadoel ciclo de control (Fig. 4.6.9). El cambio observado en el escenario controlado respecto de laexperiencia sin control corresponde a una reduccion de aproximadamente el 85 % del TKE. Elcodigo de implementacion puede ser encontrado en el Apendice F.3.

Figura 4.6.9: Valores de la Energıa Cinetica de la Turbulencia (TKE) instantanea en la transicion del sistema alactivar el controlador. Los valores fueron normalizados por unidad de superficie con una discretizacion cuadradade 0,045 y corresponden a la region definida por −5 < x < 20, −5 < y < 5. El controlador es activado en el pasode tiempo 500 provocando una caıda del TKE de aproximadamente el 85 %. Se incluyen los valores medios antesy despues de iniciado el control a modo de referencia.

El impacto del control puede apreciarse tambien en el grafico del desvıo estandar (StandardDeviation o STD) de la velocidad en el sentido del flujo. En este caso se toma la componente Xdel campo de velocidades en cada paso de tiempo y se calcula el STD para cada celda segun:

STD =

√√√√ 1

N

N∑k=1

(ujx(k)− µj)2,

donde ujx(k) corresponde a la velocidad en X para una celda arbitraria j y µj indica el valormedio calculado en dicha celda. Esta medida es similar al concepto de media cuadratica (RootMean Square o RMS) salvo que en esta ultima no se considera el valor de la media:

RMS =

√√√√ 1

N

N∑k=1

(ujx(k))2,

En el caso particular de senales con media nula, los valores de STD coinciden con RMS. Por otrolado, resulta claro que el calculo del RMS sobre las fluctuaciones de la velocidad (ujx(k) − µj)coincide exactamente con su calculo de STD.



Realizando el calculo del RMS de las fluctuaciones para cada celda se puede obtener un graficoque entregue una idea de la dispersion en las velocidades para el escenario sin actuacion (Fig.4.6.10) y para el controlado (Fig. 4.6.11). Se puede observar que el sistema de control modificala dispersion del campo de velocidades concentrando las fluctuaciones dentro del “tunel”desensores.

Figura 4.6.10: RMS de las fluctuaciones de la velocidad en X para el escenario sin control. La lınea horizontal eny = 0,415 atraviesa el valor maximo del RMS en el hemisferio superior.

Figura 4.6.11: RMS de las fluctuaciones de la velocidad en X para el escenario controlado. La lınea horizontal eny = 0,280 atraviesa el valor maximo del RMS en el hemisferio superior.

En ambas figuras se traza una lınea sobre la ordenada que posee el valor maximo en elhemisferio superior. La simetrıa del problema garantiza un comportamiento similar en el inferior(no incluido en el analisis). Graficando el valor del RMS a lo largo de dicha lınea se puedecomparar el descenso marcado de los valores del RMS maximos de un escenario al otro (Fig.4.6.12). A su vez, el valor pico se mueve de la lınea definida por y = 0,415 en el caso sin actuaciona y = 0,280 en el caso controlado, demostrando el efecto de estabilizacion en la estela. Estosresultados son similares a los obtenidos en experiencias de control a lazo abierto en laboratoriosobre el escurrimiento de cilindro con Re = 235 [18].



Figura 4.6.12: RMS de las fluctuaciones (STD) de la velocidad en X a lo largo de la ordenada que atraviesa losvalores maximos en los escenario con y sin actuacion. Los valores guardan correspondencia con las lıneas marcadasen Figs. 4.6.10 y 4.6.11.

4.6.3. Pruebas de Robustez

Se realizan distintas simulaciones para considerar la validez del algoritmo de control fuera delescenario de diseno. Se consideran escenarios con ruido pseudo-aleatorio agregado en la entradadel flujo, la inyeccion de trazador y las mediciones en los sensores. En todos los casos se realizancambios en los codigos de simulacion para agregar el ruido calculado como el producto entreuna variable pseudo-aleatoria (con valores entre 0 y 1) y cierto porcentaje sobre la magnitud amodificar. Luego de aplicados los cambios, se ejecutan las simulaciones y se calcula el TKE paracompararlo con el obtenido en el control original, sin el agregado del ruido.

La Fig. 4.6.13 compara el TKE obtenido con un ruido sobre el flujo de entrada de 10 % deamplitud. En este caso se agrega el ruido a la condicion de contorno correspondiente al bordede entrada de forma uniforme.



Figura 4.6.13: Valores instantaneos del TKE al agregar ruido pseudo-aleatorio con 10 % de amplitud en la velocidaddel flujo de entrada. A modo de referencia, se grafica el valor obtenido en el caso ideal y los valores medios deambos escenarios.

La Fig. 4.6.14 muestra el efecto de aplicar ruido al inyector del trazador pasivo con una ampli-tud del 10 %. Nuevamente, se modifican las condiciones de contorno para variar la concentracioninyectada en cada paso del tiempo.

Figura 4.6.14: Valores instantaneos del TKE al agregar ruido pseudo-aleatorio con 10 % de amplitud sobre laconcentracion de la inyeccion de trazador pasivo. A modo de referencia, se grafica el valor obtenido en el casoideal y los valores medios de ambos escenarios.

La Fig. 4.6.15 expone los resultados de aplicar ruido de amplitud 0,1 % en las medicionesobtenidas de los sensores. Para ello se modifica el sistema de control y se introduce un com-ponente pseudo-aleatorio luego del parseo de los archivos con muestras. En todos los casos, elcomportamiento del sistema de control fue satisfactorio verificandose su robustez y manteniendoel porcentaje de reduccion del TKE del escenario ideal.



Figura 4.6.15: Valores instantaneos del TKE al agregar ruido pseudo-aleatorio con 0,1 % de amplitud sobre laconcentracion medida en los sensores. A modo de referencia, se grafica el valor obtenido en el caso ideal y losvalores medios de ambos escenarios.

Del mismo modo, se consideran alteraciones en la velocidad de entrada que implican cambiosde hasta un 20 % en el numero de Reynolds. Para este proposito se varıa el valor de la velocidadde entrada utilizando una rampa hasta alcanzar el nuevo valor. Luego de cierta cantidad deiteraciones de simulacion, se reestablece el valor original con una nueva rampa. La Fig. 4.6.17plantea un cambio descendente de la velocidad hasta alcanzar el valor de Re = 219 (represen-tando una variacion del 7 % respecto del valor original de Re = 235). La Fig. 4.6.16 presenta uncambio ascendente hasta un valor de Re = 282 (variacion del 20 % respecto del original).

Figura 4.6.16: Respuesta del sistema de control frente a cambios de Re = 235 a Re = 219. Se modifican lascondiciones de entrada hasta obtener el nuevo valor. Luego de varios ciclos de simulacion se retorna a la condicionoriginal. Sup.: Concentracion del escalar medida en el sensor 1 y valor de referencia con el Re de simulacion paracada instante de tiempo. Inf.: Amplitud del actuador calculado por el sistema.



Figura 4.6.17: Respuesta del sistema de control frente a cambios de Re = 235 a Re = 282. Se modifican lascondiciones de entrada hasta obtener el nuevo valor. Luego de varios ciclos de simulacion se retorna a la condicionoriginal. Sup.: Concentracion del escalar medida en el sensor 1 y valor de referencia con el Re de simulacion paracada instante de tiempo. Inf.: Amplitud del actuador calculado por el sistema.

En ambos casos, el sistema de control se adapta y estabiliza la estela del cilindro paralas nuevas condiciones. Las flexibilidad del controlador se demuestra en cambios no solo de laamplitud del controlador sino en la frecuencia de control que se ve claramente afectada. Luego deun perıodo transitorio tanto en las rampas positivas como en las negativas, el sistema de controlse muestra capaz adaptar las predicciones sobre el modelo y calcular una actuacion optima parael nuevo escenario.

Los valores de TKE obtenidos en al modificar el numero de Reynolds son comparados consimulaciones a iguales Re pero sin actuacion (Fig. 4.6.18). En ambos casos se obtienen impor-tantes disminuciones en el TKE, obteniendo una reduccion de aproximadamente un 80 % conRe = 219 y 73 % con Re = 282.



Figura 4.6.18: Valores instantaneos del TKE obtenidos en el sistema controlado luego de modificar el numero deReynolds a Re = 219 y Re = 282. A modo de referencia, se grafica el valor medio correspondiente al caso nocontrolado con dichos numeros. El eje temporal guarda correlacion con las simulaciones graficadas en Figs. 4.6.17y 4.6.16.


4.7 Conclusiones

Durante el presente capıtulo fue definida la malla utilizada al simular la experiencia enCode Saturne ası como las variables numericas requeridas. Luego de obtener los resultados de lasimulacion, se verifica satisfactoriamente la frecuencia caracterıstica esperada para la experiencia(St = 0,1884) y la existencia de desprendimiento de vortices segun el regimen definido paraRe = 235.

Se presenta luego el sistema de control en C++ y el modelo de comunicacion con el simuladorescrito en Fortran. El sistema permite el control a lazo abierto que es utilizado con la actuacionde un pulso a modo de fase de entrenamiento. Se procede con la identificacion del sistemasobre los resultados de la fase de entrenamiento para obtener un modelo ARX que representeal sistema. El modelo ARX es validado mediante simulaciones a control a lazo abierto condistintas frecuencias de actuacion. En todos los casos se obtiene una respuesta aceptable de laspredicciones, sin un ajuste preciso pero respetando las frecuencias y comportamiento cualitativoverificado en las simulaciones. En el caso de actuaciones con frecuencia de 193 % respecto de lafrecuencia caracterıstica, se detectaron componente de alta frecuencia en las predicciones que noson agregados de forma directa por la actuacion. Se presume que dichas diferencias provienende la saturacion de la dinamica del flujo producto de las no-linealidades que el modelo ARX nocontempla.

En la fase de control a lazo cerrado, se utiliza el modelo ARX para calcular la actuacion opti-ma frente a cada paso de tiempo. Se desarrolla el algoritmo de control y se ajustan los parametrospara obtener un control apropiado de la experiencia. Los resultados arrojados demuestran quelos patrones de lıneas de mision se circunscriben al “tunel” de sensores, estabilizando las con-diciones de la estela del cilindro. El analisis de frecuencia sobre los resultados demuestra quelas frecuencias naturales de la experiencia persisten, atenuadas, luego de activado el controla-dor. Como agregado, se detecta cierto caracter oscilatorio en la actuacion cuya frecuencia estrasladada a la dinamica del sistema y, por lo tanto, a los valores medidos de escalar.

Se practica entonces un analisis sobre la energıa cinetica y las fluctuaciones de la estelapara verificar la bondad del controlador desarrollado. Para ello la estructura de malla irregularutilizada para la simulacion es convertida en una grilla cartesiana que permite la manipulacionde variables fısicas. Esta transformacion posibilita el analisis sobre la Energıa Cinetica de laTurbulencia (TKE) que demuestra una reduccion de aproximadamente un 85 % respecto dela energıa del caso sin actuacion. De la misma forma, se verifica la dispersion de los valoresde velocidad demostrando que el RMS de las fluctuaciones fue reducido. Mas aun, fue posiblecomprobar de forma cualitativa y cuantitativa que la zona con mayor dispersion se concentra entorno del eje X, dentro del “tunel” de sensores.

Por ultimo, la robustez del controlador fue puesta a prueba frente al agregado de ruidopseudo-aleatorio en distintos puntos de la experiencia. En todos los casos, el controlador res-pondio de forma estable y el TKE resultante se mantuvo dentro de los rangos del escenario decontrol original. Asimismo, se aplico el sistema de control en escenarios con variaciones en el Rerespecto del valor de diseno (Re = 235) consiguiendo buenos resultados en todos los casos. En

106


los mismos se observa la estabilizacion de la estela y reduccion del TKE en comparacion con elcaso sin actuacion (reduccion aproximada de un 80 % con Re = 219 y 73 % con Re = 282).

Capıtulo 4.7. Conclusiones 107

Parte 5

Conclusiones Generales yPerspectivas

108

5.1 Conclusiones Generales

Se desarrollo un sistema de control lineal de flujos a lazo cerrado basado en el analisis visualsobre las lıneas de emision de un flujo. El controlador se basa en la modelizacion del flujomediante modelos de caja negra y la optimizacion de un objetivo de control utilizando tecnicaspredictivas. Se utiliza un modelo lineal ARX para describir la dinamica del sistema a controlary se aplica un algoritmo de GPC para calcular la actuacion optima a cada paso de tiempo conuna ley de control lineal.

El sistema fue implementado y puesto a prueba mediante simulaciones numericas que de-mostraron su efectividad y robustez frente a variaciones en las condiciones de entrada. Comoexperiencia prototipo para los ensayos se eligio el escurrimiento de un cilindro por tratarse deun fenomeno de oscilaciones auto-sostenidas, sistemas conocidos por la existencia de fuertesno-linealidades.

El controlador estabilizo la estela del cilindro basandose en la medicion de trazadores pasivosen 8 sensores colocados aguas abajo y utilizando actuadores de plasma simetricos para agregarcantidad de movimiento tangencial al cilindro. Esta configuracion demostro una reduccion de laenergıa cinetica de las fluctuaciones (TKE) de mas de un 80 %. Esta verificacion empırica muestrala validez del controlador lineal bajo escenarios adversos, donde los esfuerzos y recientes avancescientıficos son orientados al uso de estructuras no-lineales de mayor complejidad.

De esta manera se obtiene un importante avance con implicancias en el area del control defluidos en tiempo real, donde la simpleza y su caracter generico juegan roles fundamentales paraconseguir una performance adecuada y la factibilidad tecnica de su construccion.

El armado de la experiencia numerica, implementacion de los algoritmos, construccion delsistema de control y verificacion de los resultados obtenidos implico un alto contenido de pro-gramacion y habilidades en distintos lenguajes/tecnologıas.

El uso de Matlab para la implementar los algoritmos de identificacion y control permitio re-ducir la cantidad de operaciones necesarias y reutilizar construcciones existentes ampliamenteprobadas. De esta forma, se intento minimizar la existencia de errores en las primeras implemen-taciones de los algoritmos que, en una etapa temprana de la experiencia, carecıan de resultadosprevios que permitieran su constrastacion.

Como agregado, sus caracterısticas de lenguaje utilitario y de scripting, resultaron clavespara operaciones de pre y post-procesamiento del mallado. Entre ellos se encuentra la extensiondel mallado 2D generado con GID a uno 3D en un formato aceptado por el simulador CodeSaturne, la conversion de la malla irregular en una grilla regular para el computo del TKE yRMS de las fluctuaciones junto con diversas actividades de verificacion de resultados.

Respecto del sistema de control, la eleccion de C++ demostro ser acertada pudiendo integrarlas distintas partes bajo un aplicativo robusto. La flexibilidad del lenguaje y gran soporte para laintegracion quedo expuesta al comunicar el sistema Fortran del simulador y las implementacionesde los algoritmos en Matlab. A su vez, su empleo facilito la inclusion experimental de tecnicas

109


de GPGPU mediante CUDA C/C++ para optimizar los tiempos de identificacion del sistema,factor clave para permitir el uso del sistema de control en una experiencia real de laboratorio.Otro paso importante en este sentido, consiste en la compatibilidad que ofrece C++ en lainteraccion con dispositivos perifericos como ser camaras digitales o generadores de senales. Eneste sentido, se realizaron pequenos sistemas experimentales para la obtencion de imagenes quepodrıan integrarse facilmente en el controlador y reemplazar el uso del simulador.

Tanto el diseno de los algoritmos de identificacion del sistema y de control como la defini-cion de la experiencia prototipo, la preparacion de la simulacion numerica y la verificacion deresultados, representaron un enorme desafıo de trabajo interdisciplinario. La coordinacion deesfuerzos dentro de un equipo de trabajo con areas de conocimiento tales como la matematica,fısica, fluidodinamica y teorıa de control resulta ardua, pero es a su vez un trabajo desafiantey fructıfero. Es importante remarcar el papel que juega la informatica en este contexto, don-de se requiere la cristalizacion de distintas concepciones teoricas en una experiencia de cienciaaplicada. La correcta simulacion, comunicacion entre sistemas nuevos o existentes, algoritmiaaplicada, analisis de tiempos o capacidades de computo resultan factores fundamentales paragarantizar el exito de estas lıneas de investigacion.

Capıtulo 5.1. Conclusiones Generales 110

5.2 Trabajos Futuros

El presente trabajo establece una base importante para el desarrollo de distintos proyectosde control a lazo cerrado de fluidos.

Quiza las mayores perspectivas del sistema de control desarrollado consisten en su implemen-tacion en una experiencia real de laboratorio. Con este objetivo en consideracion se desarrollo unprograma externo al simulador y que pudiera conectarse facilmente con dispositivos de labora-torio como camaras o generadores de senales. A su vez, los pequenos avances experimentalessobre el uso de GPGPU con CUDA C/C++ marcan el camino de evolucion del sistema pararesponder frente a las exigencias de velocidad y previsibilidad de un sistema en tiempo real.

La eleccion de ARX como modelo matematico fue componente importante del sistema cons-truido. Este modelo, sin embargo, no contempla la existencia de ruido en las senales. Unavariacion de modelos auto-regresivos que contempla dicho comportamiento puede encontrarseen modelos ARMAX. La extension del sistema de control en este sentido podrıa significar unpaso importante para garantizar la robustez del control frente a condiciones reales.

Otro factor que resulta de gran interes consiste en el uso de una cantidad mayor de sensoresvisuales. La modificacion de posiciones, sensibilidad y cantidad de los sensores demostro tenerun efecto directo sobre los parametros de tuning del controlador. Sin embargo, la extension delcampo de vision del algoritmo GPC podrıa asegurar la estabilidad en una zona mas amplia delfluido. El empleo entonces de una cantidad mayor de sensores permitirıa un mejor modelo de larealidad y la posibilidad de estabilizar experiencias que no cuenten con relaciones de simetrıacomo la del escurrimiento bajo estudio.

En caso de mantener la disposicion de sensores, es necesario evaluar el efecto de retardo queposeen frente a cambios en la actuacion. El retardo puede ser modelado mediante parametros quepermitan modificar la posicion de los sensores sin que esto afecte la sensibilidad del controlador.

Aun utilizando un controlador predictivo, existe la posibilidad de experimentar con distintasleyes de control para el modelo identificado. Se conocen referencias a sistemas de control adapta-tivos que fueron implementados experimentalmente para el presente trabajo. Si bien es necesariomejorar la velocidad de convergencia, simulaciones preliminares (Apendice D.1) demostraron re-sultados prometedores con actuaciones mas suaves y sin oscilaciones no deseadas. Por otra parte,el aumento del orden del modelo y horizontes de prediccion con el controlador original mejora suactuacion eliminando las altas frecuencias pero mantiene el caracter oscilatorio (Apendice D.2).

Por ultimo, se puede destacar la posibilidad de realizar un producto comercial o academicoque emplee el sistema desarrollado para simular experiencias. Aunque el exito comercial delproducto esta relacionado con la eficacia del sistema en una experiencia real aun no practicada,el alto grado de interconexion y el caracter generico de los algoritmos permitirıan un gran abanicode combinaciones entre experiencias prototipo, parametros de control y modelos matematicos.

111

Apendices

112

A Resena de Control de Fluidos

A.1. Objetivos

Los objetivos generales para el control de fluidos suelen estar vinculados a reducciones enel costo de recursos necesarios para cierto proceso, facilitar o impedir cierto fenomeno. Estosobjetivos macro se apoyan en otros mas especıficos que definen las particularidades del controla aplicar sobre el flujo bajo estudio. Para ilustrar esta diferencia se puede mencionar la ma-nipulacion de fuselajes de avion para aumentar la sustentacion, reducir el arrastre y demorarla transicion entre fluidos turbulento y laminar. Estos objetivos basicos no excluyentes tienencomo finalidad mejorar las condiciones de vuelo: reduccion de ruidos o vibraciones, reduccion delcombustible requerido para vencer la resistencia al aire, entre otras. Muchos de los estudios delarea se concentran en los objetivos especıficos para, una vez dominados, poder contribuir a unobjetivo de mayor envergadura. A continuacion se resumen los objetivos especıficos de controlde fluidos que resultan mas relevantes [22]:

Arrastre (drag): El efecto de arrastre esta relacionado con la resistencia al avance de ciertocuerpo sobre un fluido. Esta vinculado con la friccion que produce el fluido en movimientocontra las superficies del cuerpo y con la creacion de vortices o cambios de presion quedependen de la forma del cuerpo en cuestion.

Sustentacion (lift): Es la fuerza perpendicular al flujo del fluido que actua en sentido contrarioal peso del objeto en movimiento. En aeronautica, se aplican esfuerzos continuos a labusqueda de escenarios con mayor sustentacion sobre superficies alares para permitir ganaraltura a la aeronave. Por el contrario, en automovilismo, se realizan cambios en el fuselajecomo el agregado de alerones que disminuyen la sustentacion y empujan el vehıculo haciael suelo.

Separacion de la Capa Lımite (separation): Este fenomeno se observa al aparecer una va-riacion de la velocidad del fluido demasiado grande como para que el fluido se pueda adheriral solido. Al ocurrir esto, las lıneas de corriente alrededor del cuerpo se separan generandodesprendimientos en forma de vortices o turbulencia que aumentan la resistencia al movi-miento. Por estos motivos se pretende posponer la separacion de la capa lımite salvo ensituaciones donde una separacion temprana facilite la mezcla de ciertos fluidos.

Repegado de la Capa Lımite (reattachment): Al ocurrir la separacion de la capa lımite,las lıneas de corriente proximas al cuerpo son deflectadas y se forma una estela. Depen-diendo de las caracterısticas de la experiencia, las lıneas de corriente pueden convergery adherirse nuevamente formando una burbuja entre el punto de separacion y de read-herencia. Este fenomeno involucra ademas una zona de recirculacion de fluido que quedaconfinada al espacio de la burbuja y resulta deseable por la reduccion de los efectos nega-tivos de la estela.

113


Retardo en Transicion (transition delay): La transicion en el regimen del fluido denota lazona donde el fluido deja de comportarse de forma laminar para adoptar caracterısticasturbulentas. En el primer caso se pueden identificar capas paralelas definidas por las lıneasde corriente. El flujo es ordenado y no ocurre mezcla entre las distintas capas. Por elcontrario, en regimen turbulento, el movimiento del fluido es caotico y se intensifica elintercambio de materia entre las distintas capas. Dependiendo de los fines del control, latransicion temprana puede ser beneficiosa para facilitar cierta mezcla de materia aunqueen la mayorıa de los casos se opta por retardar su efecto debido al costo energetico asociadocon la aparicion de un flujo turbulento.

A.2. Evolucion Historica

A lo largo de los anos, el control de fluidos ha presentado una evolucion constante marcadapor etapas. Los primeros estadıos son definidos por una fase empırica de tecnicas e instrumentosque finaliza con los primeros estudios de L. Prandtl (1975-1953) que en 1904 introduce la teorıade la capa lımite e inicia la era cientıfica del control de fluidos. Durante esta etapa se obtuvieronavances teoricos importantes en dispositivos de control mediante la aplicacion de conceptosfısicos y principios racionales en contraposicion a la prueba y error que proliferaba en la eraanterior. Ya comenzada la Segunda Guerra Mundial y durante la carrera armamentista de lasdecadas subsiguientes (perıodo 1940-1970), el ritmo de progreso acelerado fue marcado por lasnecesidades militares en los campos de balıstica, aeroespacial y naval, entre otros. Fue la crisisenergetica de 1973 la que da inicio a una nueva era regida en esta oportunidad por el sector civil.Las necesidades de reduccion de costos en procesos industriales o transporte aereo, terrestre ynaval implicaron grandes inversiones de agencias gubernamentales y privadas en investigacionde control de fluidos. Por ultimo, la decada de 1990 da inicio a una nueva etapa que continua ala actualidad donde los avances alcanzados tanto en fluidodinamica como en teorıa de control,computacion, sistemas fısicos y electronicos amplıan los horizontes del control de fluidos. En estecontexto se incrementa la complejidad de las practicas y prepondera el uso de control reactivopor la versatilidad que posee [22].

Ademas del avance en tecnicas especıficas, las necesidades economicas suelen dirigir los esfuer-zos cientıficos de este sector de forma directa o indirecta. A modo de ejemplo de las implicanciaseconomicas que pueden causar los avances en control de fluidos, se estima que una reduccion del1 % en el consumo mundial de combustible aeronautico por aplicaciones de control implicarıa1,25 millones de dolares diarios de ahorro en costos directos (valores estimado al ano 2002) yreducirıa considerablemente el impacto ambiental de ese tipo de transporte [17].

Aun cuando existe un progreso continuo en la tecnologıa y metodos aplicados para el controlde fluidos, persisten ciertas diferencias entre teorıa, resultados simulados y aplicaciones reales.Esta circunstancia da origen a la frase “El Arte del Control de Fluidos”, refiriendose a la mezclade innovacion y experiencia con los que se llevan a cabo muchos de los ensayos que permiten elprogreso de la disciplina [17].

Apendice A. Resena de Control de Fluidos 114

B Mallado de la Experiencia

B.1. Detalle del Mallado

La Fig. B.1 muestra un histograma acumulativo de las cantidades de celdas utilizadas deacuerdo a la superficie que presentan. Se puede observar la cantidad de elementos triangularesutilizados dependiendo del volumen ocupado por los mismos con un incremento importante enaquellos que presentan un tamano cercano a 0,1, es decir, con superficie aproximada de 0,005.

Figura B.1: Histograma acumulativo sobre las cantidades de celdas. Si bien se muestra el volumen de las celdascomo clasificador para la acumulacion, se aclara que el mallado fue realizado 2D donde se asume una profundidadunitaria para el calculo volumetrico.

El total de celdas triangulares utilizadas en la malla es de 169507. El detalle de la configu-racion puede observarse en las Fig. B.2 y B.3.

115


Figura B.2: Tamano en la separacion del mallado para las lıneas de la geometrıa. El mallado en las lıneas defrontera se define con un tamano mayor (0,1) al utilizado en las lıneas que determinan el cilindro (0,03). A finesde proveer una transicion suave, es necesario agregar lıneas ficticias que fijen separaciones intermedias (0,04 y0,06).

Apendice B. Mallado de la Experiencia 116


Figura B.3: Tamano en la separacion del mallado para las superficies de la geometrıa. El sistema de mallado utilizalos tamanos definidos en las superficies para generar las celdas intermedias a las distintas lıneas del mallado. Lasdimensiones de las celdas varıan gradualmente entre los tamanos definidos por las lıneas y los indicados por lassuperficies encerradas entre ellas.

B.2. Efectos de Cambios Bruscos en la Malla durante la Simu-lacion

Las Fig. B.4, B.5 y B.6 muestran una secuencia de simulacion donde la existencia de cambiosbruscos en las dimensiones de las celdas del mallado generan errores de calculo localizados. Estoserrores se propagan rapidamente a traves de las celdas vecinas generando la divergencia de lasimulacion.



Figura B.4: Magnitud de la velocidad en una simulacion divergente. Un sector del mallado presenta celdas que nocumplen con las condiciones de estabilidad en la cercanıa del cilindro.

Figura B.5: Magnitud de la velocidad en una simulacion divergente. Las celdas afectadas comienzan a trasladarsus valores elevados a celdas vecinas.

Figura B.6: Magnitud de la velocidad en una simulacion divergente. El error de calculo se expande afectando aun porcentaje elevado de las celdas en la simulacion, se torna inestable y eventualmente diverge.


C Verificacion de la Identificacion del Sis-tema

C.1. Ajuste en Implementacion Matlab

El criterio utilizado para definir el orden del modelo ARX para el algoritmo de controlconsiste en verificar el nivel de ajuste que poseen las predicciones del modelo respecto de lasmuestras utilizadas para generarlo. Si bien se conocen rutinas pre-existentes en Matlab tanto parala identificacion del sistema (llamada arx ) como para realizar una comparacion visual sobre elgrado de ajuste del modelo calculado (llamada compare), se decide realizar una implementacionpropia de cada uno. En el primer caso, se pretende comprobar la efectividad del algoritmodefinido y la posibilidad de una implementacion que soporte alto paralelismo en CUDA C/C++.En el segundo caso se requiere control sobre los resultados del ajuste de cada variable, mientrasque la rutina existente tiene una clara orientacion a la comparacion visual.

El codigo fuente del desarrollo propio de la identificacion del sistema (lfd arx.m) y de lacomparacion sobre el porcentaje de ajuste que posee lfd compare.m pueden encontrarse en elApendice F.5. El algoritmo de comparacion utiliza la funcion predict de Matlab para predecirlos valores yi(k) futuros segun el modelo ARX utilizando un horizonte de prediccion s para cadapaso de tiempo.

A continuacion se presentan los resultados del ajuste calculado para distintos ordenes delmodelo (p) incluyendo la media del porcentaje de ajuste de todas las variables yi, ası como losvalores mınimo y maximo obtenidos. Como horizonte de prediccion se utiliza el valor aproximadode medio perıodo natural, s = 43 . Se utiliza la simulacion de entrenamiento de 1090 muestrascon la actuacion de un pulso.

Orden (p)Ajuste Matlab

Prom. [ %]Ajuste

Prom. [ %]Ajuste

Mın. [ %]Ajuste

Max. [ %]20 83,39 83.39 62.21 90.2130 91,28 91.31 83.09 95.3540 96,54 96.53 95.51 97.9350 98,08 98.08 97.21 99.1660 98,78 98.78 98.05 99.3570 99,32 99.32 98.96 99.5980 99,57 99.57 99.27 99.7090 99,70 99.70 99.44 99.82100 99,75 99.73 99.36 99.94

C.2. Ajuste y Tiempos en Implementacion C++

A continuacion se resumen las pruebas de concepto realizadas sobre el desarrollo del algoritmode identificacion del sistema en Matlab en comparacion su version en C++.

119


Dado que se requieren operaciones de algebra lineal para resolver multiplicaciones, descom-posiciones e inversiones, se decide evaluar el uso de librerıas Basic Linear Algebra Subprograms(BLAS) existentes. A tal fin, se utiliza la librerıa GNU Scientific Library (GSL) y GPU Accele-rated Linear Algebra (CULA) siendo la primera una implementacion pura en C++ y la segundauna version BLAS que da soporte a rutinas CUDA. A fin de comparar la velocidad de las im-plementaciones, se crea una abstraccion de matriz utilizando el tipo de dato abstracto de GSLpero con implementaciones de las operaciones con ambas librerıas.

El conjunto de datos utilizados coincide con la la fase de entrenamiento del sistema con laactuacion de un pulso y N = 1090 muestras. En cada caso, se realizo un promedio sobre losvalores obtenidos de dos ejecuciones. Se mide el tiempo de ejecucion total y el ajuste de cadacoordenada del vector de estado obteniendo un ajuste promedio de todas las coordenadas, lacoordenada de ajuste mınimo y la de ajuste maximo. Se utiliza aproximadamente un perıodocaracterıstico del fenomeno como horizonte de prediccion, s = 90, para realizar la comparacioncon lfd compare.m (ver Apendice F.5).

Se emplea un equipo con procesador Intel i5 2500K con 4 cores y una velocidad de reloj de3,3Ghz y una placa grafica nVidia GeForce GTX 570 con 480 CUDA cores y una velocidad deGPU de 1,57Ghz.

Orden (p) LenguajeTiempo

[s]Ajuste

Prom. [ %]Ajuste

Mın. [ %]Ajuste

Max. [ %]10 Matlab 1,7 57,0 50,4 67,710 C++ (CUDA/CULA) 1,5 56,9 50,5 67,610 C++ (GSL) 55,5 56,9 50,5 67,620 Matlab 13,6 61,6 49,1 72,720 C++ (CUDA/CULA) 3,4 61,4 48,7 72,820 C++ (GSL) 330,1 61,4 48,7 72,840 Matlab 118,9 88,0 66,8 93,640 C++ (CUDA/CULA) 12,4 87,9 66,8 93,640 C++ (GSL) 1952,1 87,9 66,8 93,650 Matlab 229,3 90,4 67,2 95,950 C++ (CUDA/CULA) 19,0 90,4 67,2 95,950 C++ (GSL) 3497,9 90,4 67,2 95,960 Matlab 403,9 91,6 67,4 97,860 C++ (CUDA/CULA) 28,0 91,6 67,4 97,860 C++ (GSL) 5746,2 91,6 67,4 97,870 Matlab 646,7 92,2 67,4 99,070 C++ (CUDA/CULA) 40,7 92,2 67,4 99,070 C++ (GSL) 8614,6 92,2 67,4 99,080 Matlab 951,7 92,4 67,4 99,480 C++ (CUDA/CULA) 53,5 92,4 67,4 99,480 C++ (GSL) 12317,8 92,4 67,4 99,490 Matlab 1349,6 92,5 67,4 99,690 C++ (CUDA/CULA) 70,2 92,5 67,4 99,690 C++ (GSL) 16957,2 92,5 67,4 99,6

Se observa un incremento importante del tiempo de ejecucion a medida que se aumenta ppara todos los sistemas. Sin embargo, la version que utiliza capacidades de GPGPU resultasensiblemente mas rapida resolviendo el caso de identificacion de sistema utilizado en el sistemade control (p = 90) en tiempos cercanos al minuto mientras el codigo Matlab utiliza aproxi-madamente 22 minutos. Por otra parte, la implementacion del sistema en GSL demostro unrendimiento muy pobre con ordenes de magnitud de diferencia en cuanto a los tiempos de eje-cucion para todo p.

Apendice C. Verificacion de la Identificacion del Sistema 120


Cabe destacar que el nivel de ajuste se mantiene similar en todos los casos.

Apendice C. Verificacion de la Identificacion del Sistema 121

D Avances Experimentales para TrabajosFuturos

D.1. Control Adaptativo

Se realizaron pruebas experimentales sobre leyes de control adaptativo. En este esquema, lamatriz de control se adapta a cada paso de simulacion en base a ajustes evaluados contra lafuncion objetivo. En el escenario ideal, la matriz de control converge hacia valores optimos decontrol. Las experiencias realizadas (Fig. D.1) muestran un posible escenario de convergenciadonde el actuador se acerca asintoticamente a su optimo.

Aunque posee resultados prometedores, este tipo de controlador presenta grandes complica-ciones en cuanto al tuning de parametros debido a la combinacion de varias variables sobre elpeso del control. Otro factor importante consiste en la necesidad de realizar largas simulacioneshasta contar con la suficiente informacion para determinar la convergencia o no de la actuacion(Fig. D.2). El codigo fuente utilizado en este esquema de pruebas fue basado en [36] y se puedeencontrar en el Apendice G.3.

Figura D.1: Control Adaptativo aplicado sobre el escurrimiento del cilindro. Se puede apreciar el caracter asintoticode la senal de actuacion.

122


Figura D.2: Comparacion de control adaptativo con distintos parametros de ajuste. Se puede observar grandiferencia en los resultados de control frente a cambios en los parametros, pudiendo divergir (lınea azul) o manteneruna progresion asintotica (lınea verde) con cambios menores en las variable de ajuste.

D.2. Control con Modelo ARX de Orden Elevado

Con el objetivo de comprobar el efecto de modificaciones drasticas en el orden del modeloARX sobre el sistema controlador, se realizaron distintas pruebas experimentales con un nuevomallado. En este caso, se definio una malla fina en el centro pero con celdas de mayor tamano enla periferia. De esta forma se obtuvo una menor cantidad total de celdas que permitio extenderel mallado aguas abajo de la experiencia para mejorar la resolucion numerica. Las Figs. D.3 yD.4 muestran el detalle del mallado.

Figura D.3: Tamano en la separacion del nuevo mallado para las lıneas de la geometrıa.

Apendice D. Avances Experimentales para Trabajos Futuros 123


Figura D.4: Tamano en la separacion del nuevo mallado para las superficies de la geometrıa.

Luego, se empleo el sistema de control bajo estudio cuyo codigo fuente se encuentra en elApendice F.6 ampliando el valor del orden del modelo, p. Los primeros resultados no fueronpositivos pero se pudo observar una mejora notable al realizar un muestreo mas lento sobre losvalores de simulacion (practicando under-sampling). En este caso se obtuvo una senal de controlmucho mas suave que en las experiencias originales, que controla los valores de escalar sin elagregado de fluctuaciones ni senales de alta frecuencia indeseables (Fig. D.5).

A fin de ajustar los parametros de control con el nuevo orden del modelo, fue necesariomodificar los pesos de los sensores. El resumen de los parametros de control se puede observaren la Tabla D.1.

Parametro Variable ValorOrden del Modelo p 150Paso de Tiempo Simulacion ∆t 0,061

Paso de Tiempo Muestreo

0.122 (1 muestra

cada 2 pasos de Sim.)Peso de Sensores Sup. q1, q2, q3, q4 1,1 0,75 0,5 0,25Peso de Sensores Inf. q5, q6, q7, q8 1,1 0,75 0,5 0,25Costo del Controlador λ 0,00045

Tabla D.1: Valores definidos para los distintos parametros de control del sistema.



Figura D.5: Experiencia de control realizada sobre una nueva malla utilizando ordenes de modelo ARX elevados.En este caso, utilizando p = 150, se consigue un control estable luego de reducir la frecuencia de muestreo a lamitad de la empleada en el control original.

.

D.3. Captura de Imagenes Mediante Camaras Digitales

Se realizaron trabajos experimentales con las distintas camaras digitales del Laboratorio deFluidodinamica de la Facultad de Ingenierıa (UBA), donde se realizo el proyecto de investigacion.En todos los casos se intento medir los tiempos de respuesta de las camaras para tomar ytransferir imagenes a un posible sistema controlador. Se adjuntan los resultados obtenidos que



pueden ser de utilidad en futuras implementaciones de la experiencia en tiempo real. La TablaD.2 incluye el detalle de las propiedades de cada camara evaluada. Los codigos fuente utilizadosse encuentran en el Apendice G.1.

Nombre Resol. Max. FPS

Crop/

ROI Buffer Tipo de TransferenciaPixelFly qe - Cooke Coroporation 640x480 50 Si Sin buffer Directa por RJ45 en placa Adq.SpeedCam Mini Vis e2 - Weinberger 512x512 2500 Si 2GB buffer Desde buffer por Ethernet 1GbitTM9701 - Pulnix 768x484 30 No Sin buffer Directa por placa Adq. PXD

Tabla D.2: Caracterısticas de camaras digitales evaluadas para la adquisicion de imagenes en futuros escenariosde control en tiempo real.

D.3.1. PixelFly qe

Se escribe el codigo de captura usando la API provista por PixelFly y se miden los tiemposaproximados. En este caso se cuenta con un SDK unificado para las PixelFly y las camaras dela familia Sensicam llamado Uniform SDK. Dicha librerıa posee una interfaz clara y requiereelementos de WinApi siendo por demas portable. Los resultados obtenidos se resumen segun:

Imagenes Capturadas 200FPS 50Tiempo Total 4000msTiempo Promedio 20ms. Equivalente a 50 FPS (tiempo de transferencia despreciable).

D.3.2. Pulnix

Se trata de una camara anticuada con una API de control del adaptador provista por laempresa Imagenation. Se posee documentacion de la API y se realiza un sistema que retorna lossiguientes resultados:

Imagenes Capturadas 120FPS 30Tiempo Total 4000msTiempo Promedio 33, 3ms. Equivalente a 30 FPS (tiempo de transferencia despreciable).

D.3.3. SpeedCam Mini Vis e2

La SpeedCam no posee una API de acceso programatico. Tampoco permite sacar fotogramasde forma unitaria, solo es posible sacar una rafaga que es almacenada en el buffer interno de lacamara y luego transmitido a la PC.

La camara posee codigo hecho en Java del cual se pueden obtener los .jar para emplearlos enun codigo de prueba. Se consulta al soporte de fabrica sobre manuales o informacion de utilidadpara utilizar las librerıas sin mayores resultados.

Luego de realizar distintos trabajos de re-ingenierıa mediante la decompilacion del sistemaque utiliza la camara, se elabora un codigo que permite obtener las siguientes mediciones:

Imagenes Capturadas 200FPS 2500Tiempo Total 7800ms (unicamente de transferencia)Tiempo Promedio 39ms. Equivalente a 25 FPS.


E Publicaciones

E.1. Anales de la AFA

Publicacion presentada durante el mes de Diciembre de 2012 en los Anales de la AsociacionFısica Argentina (AFA) bajo el tıtulo “Control a Lazo Cerrado de la Estela de un Cilindro” encoautorıa con Thomas Duriez, Ada Cammilleri y Guillermo Artana.

E.2. Physics of Fluids

Publicacion presentada durante el mes de Septiembre de 2013 en la revista Physics of Fluidsde la American Institute of Physics bajo el tıtulo “A visualization-based flow control system”en coautorıa con Thomas Duriez, Ada Cammilleri, Lionel Mathelin y Guillermo Artana.

127

29ANALES AFA Vol. 23 FLUIDOS (29-33) BUENOS AIRES 2012

CONTROL A LAZO CERRADO DE LA ESTELA DE UN CILINDRO

CYLINDER WAKE CLOSED-LOOP CONTROL SYSTEM

Pablo Roca, Thomas Duriez, Ada Cammilleri, Guillermo Artana

Laboratorio de Fluidodinámica, Facultad de Ingeniería, Universidad de Buenos Aires [email protected]

Recib ido: 13/12/2012; aceptado: 14/03/2013

Se introduce un sistema de control a lazo cerrado sobre el escurrimiento de un cilindro basado en el procesamiento de imágenes. Dentro de una simulación numérica directa, se considera el flujo que contornea un cilindro y se procura disminuir las fluctuaciones en su estela. Trazadores pasivos son inyectados en el sistema para construir un modelo matemático de identificación de sistema tipo ARX con su concentración medida en ciertos puntos de las imágenes. Luego, mediante el empleo de un algoritmo de control GPC, se actúa inyectando cantidad de movimiento tangencial al cilindro para forzar el flujo y reducir las fluctuaciones de la estela.

Palabras clave: cilindro, estela, simulación, imágenes, control, lazo cerrado, ARX, GPC.

A closed-loop control system is introduced to stabilize a cylinder wake based on image processing. A direct numerical simulation is used to compute the fluid flow through a cylinder and stabilize its wake. Passive scalar tracers are injected in the system to constitute an AutoRegressive with eXogenous input (ARX) mathematical model by sensing its concentration on certain image sectors. A Generalized Predictive Controller (GPC) algorithm is used to calculate the necessary actuation to stabilize the wake by adding momentum tangentially to the cylinder wall.

Keywords: cylinder, wake, simulation, images, control, closed-loop, ARX, GPC.

I. INTRODUCCIÓN Es conocida la importancia que reviste la disciplina

de control de fluidos tanto para el ámbito científico como para la industria. A los objetivos clásicos de teoría de control como el seguimiento de valores de referencia, rechazo de perturbaciones y de errores de medición se suman aplicaciones específicas como la reducción de fuerzas de arrastre o la supresión de inestabilidades que resultan de gran valor por sus aplicaciones prácticas.

El estudio de control de fluidos se caracteriza por buscar las partes sensibles de un flujo que permitan obtener modificaciones que lleven el flujo a un estado deseado en base a pequeñas perturbaciones intencionales conocidas como actuación. Un sistema de control se puede caracterizar por el esquema de actuación empleado según sea pasivo, activo o reactivo.

El control pasivo consiste en realizar modificaciones en el entorno de operación de forma de parametrizar ciertos cambios respecto de la modificación que se observa en el flujo. En este esquema, una vez establecido el entorno no es posible cambiar la parametrización. Ejemplos típicos son generadores de vórtices1,2,3 y pequeños objetos físicos dentro de la estela del fluido4. En control activo se aplica energía durante la actuación para adaptar la respuesta del fluido a un resultado deseado. En este caso, las condiciones de la experiencia pueden cambiar a lo largo del tiempo siendo necesario adaptar los parámetros de actuación definidos. Ejemplos típicos son controles tipo jet (pulsados o sintéticos)5,6, dispositivos mecánicos ajustables y cilindros rotantes7. El control reactivo implica que el estado del flujo es medido o estimado en

base a mediciones para retroalimentar al sistema de control y poder ajustar los parámetros en tiempo real. Se trata de un control activo con la capacidad de adaptar los parámetros de control y la energía utilizada en base a los resultados medidos en el sistema, el objetivo definido y la modelización matemática que se realizó sobre el sistema.

Es en este contexto donde la modelización del sistema físico recubre un carácter fundamental para estimar la actuación a aplicar en busca de un objetivo definido. Algunas estrategias implican el uso de ecuaciones fundamentales de la mecánica como es el caso de las ecuaciones de Navier-Stokes que son linealizadas para construir un modelo de orden reducido que permita estimar el flujo8. Otros modelos se concentran en propiedades globales como el consumo de energía para realizar control por búsqueda de extremos9 donde se busca un mínimo a la función global de costo determinada por el estudio de un control activo forzado (lazo abierto). Finalmente existen los modelos empíricos de caja negra basados en la observación del sistema en un proceso de control a lazo abierto. Un ejemplo de este escenario consta en la identificación de sistemas basados en modelos AutoRegressive (AR) que determinan una relación entre el estado del sistema actual y el medido en tiempos pasados. En el pasado se realizaron experiencias de control basadas en modelos autoregresivos ARX10,11,12,13 y autoregresivos ARMAX14 que permiten utilizar algoritmos de predicción y optimización sobre ciertas funciones definidas como objetivo para el control.

El presente trabajo desarrolla un sistema de control de fluidos reactivo basado en el procesamiento de


Apendice E. Publicaciones 128

30 ANALES AFA Vol. 23 FLUIDOS (29-33) BUENOS AIRES 2012

imágenes para obtener un modelo a caja negra ARX que permita describir y predecir el sistema físico. Se elige el experimento prototípico del escurrimiento sobre un cilindro a fin de efectuar las pruebas correspondientes sobre el algoritmo y bloques de control.

II. MODELO FÍSICO SIMULADO Como modelo físico bajo estudio se toma el

escurrimiento del fluido sobre un cilindro y se plantea el objetivo de estabilizar su estela. Filamentos de escalar pasivo son inyectados aguas arriba del experimento para medir luego la concentración en ciertos puntos y definir un vector de estado del sistema con dichos valores. Se colocan dos actuadores en la pared del cilindro con el objetivo de agregar cantidad de movimiento de forma tangencial para forzar el flujo y controlar la estela. Se simula una actuación del tipo plasma15 con inyección de cantidad de movimiento a través de un mecanismo de impacto iónico. La acción es homogénea, simultánea y simétrica a lo largo de dos semiarcos de 5% de circunferencia del cilindro, en una posición cercana al punto de separación. (Fig. 1)

Figura 1. Esquema del experimento. Ubicación de actuadores y sensores de concentración del escalar durante la simulación 2D (Re:235, dt:0.061, cilindro centrado verticalmente a 7.5 diámetros de la entrada sobre una superficie de 27.5 x 25 diámetros. Con este diseño la actuación procura posponer la separación de la capa límite.

Luego de mallar la geometría del sistema en 2D, se utiliza el aplicativo Código Saturne para realizar simulaciones de elementos finitos.

En cada paso de la simulación se mide la concentración de un escalar pasivo que se inyecta con flujo constante aguas arriba del cilindro. Los puntos de sensado se ubican de manera simétrica en dirección del escurrimiento dentro de la estela formada por el cilindro (Fig. 2, 3 y 4).

Figura 2. Concentración de escalar computada en la simulación luego de alcanzar el estado estacionario (Re:235).

Figura 3. Vorticidad computada en la simulación luego de alcanzar el estado estacionario (Re:235).

Figura 4. Concentración de escalar medida en el sensor 1 durante la fase de inicio de inicio del sistema. Al llegar al régimen estacionario se puede apreciar la periodicidad en la concentración con un T aproximado de 90 pasos de simulación (Re:235).

III. IDENTIFICACIÓN DEL SISTEMA Para representar la dinámica del escurrimiento

elegimos considerar un modelo lineal en tiempo discreto dado por

(1)

donde y(k) es un vector de m x 1 que representa el estado del sistema (la salida), u(k) es un vector de r x 1 que representa la actuación (la entrada), p es el orden del modelo, k es el paso del tiempo. En el caso que estudiamos y(k) es un vector que contiene la medida instantánea de concentración del trazador en las distintas posiciones de los sensores y u(k) representa la amplitud instantánea de los actuadores.

Nos referimos al sistema definido por (1) como un modelo Modelo autoregresivo con entrada exógena (ARX). Los coeficientes matriciales del modelo, para 1 ≤ i ≤ p, para 0 ≤ i ≤ p , de m x m y m x r respectivamente, son llamados parámetros de Markov del observador y caracterizan al modelo10.

Definiendo el vector de parámetros

y el vector de regresión

la Ec. 1 pueda ser escrita de la forma

A fin de estimar , se define una fase de entrenamiento donde la actuación es forzada mientras se mide la respuesta del sistema físico. Luego, se utilizan las N muestras de entrenamiento junto al criterio de estimación por cuadrados mínimos para determinar un estimador de según

Dado que la matriz puede estar mal condicionada consideramos un método más efectivo para estimar los parámetros16.

Si se define un vector de que reune a todos los

coeficientes de la matrices y , la Ec. 1 puede también ser escrita de la forma

Luego, la estimación de se obtiene a partir de la descomposición QR de la matriz donde es de Nm x d e Y es de Nm x 1 tales que

IV. ALGORITMO DE CONTROL A LAZO CERRADO

Siendo s el horizonte de predicción definimos de sr x 1, de sm x 1 y de p(m+r) x 1 según

De la Ec. 1 podemos obtener una ecuación matricial que predice las futuras salidas del sistema10

donde es una matriz Toeplitz dada por

siendo conocidos como parámetros de Markov del sistema10, y es una matriz de ms x sr definida por una serie de relaciones recursivas a partir de los parámetros del modelo.

Se establece un algoritmo de control basado en el algoritmo Generalizado de control predictivo (GPC)11 con el objetivo de disminuir la concentración de escalar medida en los sensores.

Se determina entonces la función de costo apropiada para describir la ley de control

donde es una matriz de sm x sm, diagonal en bloques , tales que y representa el peso del sensor i, .

Suponiendo una ley de control lineal, y utilizando el método de Lagrange, la minimización del funcional definido en la Ec. 4 sujeto a cumplir la Ec. 3 da como resultado

donde I representa a la matriz identidad de sr x sr. Dado que se requiere el valor de actuación para el

paso de tiempo actual (k), es posible ahorrar tiempo de cómputo determinando las primeras r filas del producto del primer término de la Ec. 5 según

Una vez aplicada la actuación y obtenidas las mediciones del paso de tiempo siguiente, se cierra el lazo de control calculando e ingresando nuevamente en la Ec. 6. La secuencia del sistema de control queda descripta en el Algortimo 1.

ALGORITMO 1: ALGORITMO DE CONTROL PROPUESTO

Entrada: p: orden del modelo, s: horizonte de predicción,

: costo del actuador Salida: Control del sistema en estudio 1: Medir valores del ciclo de entrenamiento 2: Obtener el modelo ARX de orden p 3: Definir el controlador con s, y el modelo ARX 4: Para cada Paso de tiempo k hacer 5: Medir los valores y para el paso k 6: Construir agregando los valores de y(k) 7: Utilizar Ec. 6. para obtener u(k) 8: Aplicar la actuación u(k) 9: Fin para

V. RESULTADOS DEL SISTEMA DE CONTROL A fin de identificar el modelo del sistema, se idea

una fase de entrenamiento donde la actuación es forzada con la señal característica de un pulso para medir su respuesta frente a una amplia variedad de frecuencias de entrada. Los valores medidos son utilizados en la Ec. 2 para formar los coeficientes de control en base al modelo estimado (Fig. 5).




A fin de estimar , se define una fase de entrenamiento donde la actuación es forzada mientras se mide la respuesta del sistema físico. Luego, se utilizan las N muestras de entrenamiento junto al criterio de estimación por cuadrados mínimos para determinar un estimador de según

Dado que la matriz puede estar mal condicionada consideramos un método más efectivo para estimar los parámetros16.

Si se define un vector de que reune a todos los

coeficientes de la matrices y , la Ec. 1 puede también ser escrita de la forma

Luego, la estimación de se obtiene a partir de la descomposición QR de la matriz donde es de Nm x d e Y es de Nm x 1 tales que

IV. ALGORITMO DE CONTROL A LAZO CERRADO

Siendo s el horizonte de predicción definimos de sr x 1, de sm x 1 y de p(m+r) x 1 según

De la Ec. 1 podemos obtener una ecuación matricial que predice las futuras salidas del sistema10

donde es una matriz Toeplitz dada por

siendo conocidos como parámetros de Markov del sistema10, y es una matriz de ms x sr definida por una serie de relaciones recursivas a partir de los parámetros del modelo.

Se establece un algoritmo de control basado en el algoritmo Generalizado de control predictivo (GPC)11 con el objetivo de disminuir la concentración de escalar medida en los sensores.

Se determina entonces la función de costo apropiada para describir la ley de control

donde es una matriz de sm x sm, diagonal en bloques , tales que y representa el peso del sensor i, .

Suponiendo una ley de control lineal, y utilizando el método de Lagrange, la minimización del funcional definido en la Ec. 4 sujeto a cumplir la Ec. 3 da como resultado

donde I representa a la matriz identidad de sr x sr. Dado que se requiere el valor de actuación para el

paso de tiempo actual (k), es posible ahorrar tiempo de cómputo determinando las primeras r filas del producto del primer término de la Ec. 5 según

Una vez aplicada la actuación y obtenidas las mediciones del paso de tiempo siguiente, se cierra el lazo de control calculando e ingresando nuevamente en la Ec. 6. La secuencia del sistema de control queda descripta en el Algortimo 1.

ALGORITMO 1: ALGORITMO DE CONTROL PROPUESTO

Entrada: p: orden del modelo, s: horizonte de predicción,

: costo del actuador Salida: Control del sistema en estudio 1: Medir valores del ciclo de entrenamiento 2: Obtener el modelo ARX de orden p 3: Definir el controlador con s, y el modelo ARX 4: Para cada Paso de tiempo k hacer 5: Medir los valores y para el paso k 6: Construir agregando los valores de y(k) 7: Utilizar Ec. 6. para obtener u(k) 8: Aplicar la actuación u(k) 9: Fin para

V. RESULTADOS DEL SISTEMA DE CONTROL A fin de identificar el modelo del sistema, se idea

una fase de entrenamiento donde la actuación es forzada con la señal característica de un pulso para medir su respuesta frente a una amplia variedad de frecuencias de entrada. Los valores medidos son utilizados en la Ec. 2 para formar los coeficientes de control en base al modelo estimado (Fig. 5).



32 ANALES AFA Vol. 23 FLUIDOS (29-33) BUENOS AIRES 2012

Figura 5. Fase de entrenamiento del sistema. Luego de aplicar el pulso de actuación, el valor de concentración medido en las líneas de sensores se reduce abruptamente producto de la estabilización de la estela.

Luego de realizada la calibración de los distintos parámetros de control, se simula el sistema físico con el controlador ya entrenado obteniendo una actuación de control que estabiliza la estela del cilindro (Fig. 6, 7 y 8).

De la misma forma se pudo verificar la adaptabilidad del algoritmo frente a condiciones fuera de diseño. A tal fin se modificó la velocidad del flujo de entrada de forma temporal observando la capacidad del control para encontrar un nuevo punto de actuación óptima. Luego de cierto período de transición, el sistema cambia su señal de control y logra estabilizar la estela (Fig. 9).

Figura 6. Lazo cerrado de control. La actuación se incrementa cuando el escalar medido crece y se reduce cuando su efecto estabiliza la estela y baja la concentración de escala en los sensores.

Figura 7. Vorticidad resultante de la simulación del control en el instante de máxima concentración medida en los sensores. En este momento, la actuación comienza a crecer para compensar las oscilaciones en la estela (Re:235).

Figura 8. Vorticidad resultante de la simulación del control en el instante de mínima concentración medida en los sensores (Re:235).

VI. CONCLUSIONES Se desarrolló un sistema de control a lazo cerrado en

una simulación numérica. Se verificó su correcto funcionamiento con la experiencia prototípica del escurrimiento del cilindro. La estela del cilindro fue sensada a través de la medición de la concentración del escalar inyectado y estabilizada gracias a la actuación de respuesta. El sistema de control definido resulta lo suficientemente genérico para ser adaptado a otros experimentos e implementado con un esquema de captura de imágenes.

Figura 9. Cambios en la condición de entrada. El sistema de control adapta la respuesta de su actuador para estabilizar la estela del cilindro bajo el cambio de las condiciones de entrada indicadas por la referencia.

Queda pendiente para trabajos futuros el estudio de

métodos adaptativos de control12 y sus resultados con el esquema propuesto.

Asimismo, procuraremos estudiar el incremento de la cantidad de sensores utilizados, la medición de los tiempos de cómputo requeridos, el análisis del desempeño con posibles optimizaciones del algoritmo y la implementación de la experiencia en laboratorio.

VI. REFERENCIAS 1- Lin J. Progress in Aerospace Sciences, 38(4-5), 389–420

(2002). 2- Godard G. and Stanislas M. Aerospace Science and

Technology, 10(6), 455–464 (2006). 3- Duriez T., Aider J., and Wesfreid J. Physical Review

Letters, 103(14) (2009). 4- Cadot O., Thiria B., and Beaudoin J. Solid Mechanics and

its Applications, 14, 529–537 (2009). 5- Godard G. and Stanislas M. Aerospace Science and

Technology, 10(6), 455–464 (2006). 6- Kostas J., Foucaut J., and Stanislas M. Flow, Turbulence

and Combustion, 78(3-4), 331–363 (2007).

7- Thiria B., Goujon-Durand S., and Wesfreid J. Journal of Fluid Mechanics, 560, 123–147 (2006).

8- Protas B. and Styczek A. Physics of Fluids, 14(7), 2073–2087 (2002).

9- Beaudoin J.F., Cadot O., Aider J.L., and Wesfreid J.E. Physics of Fluids, 18(085107) (2006).

10- Juang J.N. and Phan M. Deadbit predictive controllers. Technical Memorandum 112862, Nasa (1997).

11- Kegerise M.A., Cambell R.H., and Cattafesta L.N. Journal of Sound and Vibration, 307, 906–923 (2007).


13- Huang S.C. and Kim J. Physics of Fluids, 20(101509) (2008).

14- Hervé A., Denis Sipp P.J.S., and Samuelides M. Journal of Fluid Mechanics, 702, 26–58 (2012).

15- D’Adamo J., González L.M., Gronskis A., and Artana G. Fluid Dynamics Research, 44(055501), 20 (2012).

16- Ljung L. System Identification: Theory for the User. Prentice-Hall Inc., Englewood Cliffs, N.J. (1987)




7- Thiria B., Goujon-Durand S., and Wesfreid J. Journal of Fluid Mechanics, 560, 123–147 (2006).

8- Protas B. and Styczek A. Physics of Fluids, 14(7), 2073–2087 (2002).

9- Beaudoin J.F., Cadot O., Aider J.L., and Wesfreid J.E. Physics of Fluids, 18(085107) (2006).

10- Juang J.N. and Phan M. Deadbit predictive controllers. Technical Memorandum 112862, Nasa (1997).



13- Huang S.C. and Kim J. Physics of Fluids, 20(101509) (2008).

14- Hervé A., Denis Sipp P.J.S., and Samuelides M. Journal of Fluid Mechanics, 702, 26–58 (2012).

15- D’Adamo J., González L.M., Gronskis A., and Artana G. Fluid Dynamics Research, 44(055501), 20 (2012).

16- Ljung L. System Identification: Theory for the User. Prentice-Hall Inc., Englewood Cliffs, N.J. (1987)



A visualization-based flow control systemPablo Roca,1 Thomas Duriez,1 Ada Cammilleri,1 Lionel Mathelin,2 and Guillermo Artana3, a)1)Laboratorio de Fluidodinámica, Facultad de Ingeniería, Universidad de Buenos Aires,Argentina2)LIMSI, CNRS, Orsay, France3)CONICET, Laboratorio de Fluidodinámica, Facultad de Ingeniería, Universidad de Buenos Aires,Argentina(Dated: October 24, 2013)

A closed-loop control system is introduced to stabilize a cylinder wake flow based on images of streaklines.Passive scalar tracers are injected upstream the cylinder and their concentration is monitored downstreamat certain image sectors of the wake. An AutoRegressive with eXogenous inputs (ARX) mathematical modelis built from these images and a Generalized Predictive Controller (GPC) algorithm is used to computethe actuation required to stabilize the wake by adding momentum tangentially to the cylinder wall throughplasma actuators. The methodology is demonstrated on a numerical simulation and the provided results showthat good performances are achieved.

PACS numbers: 47.85.L

I. INTRODUCTION

Control of fluid flows is a discipline with a remarkable importance for industry and science. Classical controlobjectives such as reference value tracking or disturbances rejection can be applied to many configurations, includingdrag reduction or instability suppression that are of great interest for practical applications.

On one hand, passive control devices aim at controlling the flow state with a given target without requiring anexternal power source to operate. In this type of control, the action is permanent and is not suitable for a change inthe control parameter since they are strongly tight to the original layout of the experiment. This methodology canbe found for instance in vortex generators,1–3 or splitter plates,4. On the other hand, active control requires applyingenergy for the flow to attain a defined target. This kind of control allows changing the actuation parameters in timeto adjust the controller to new conditions in the experiment. Typical examples of actuators involved with this controlare pulsed and synthetic jets,2,5, adjustable mechanical devices, rotating cylinders,6 or plasma actuators,7–9. Thesedevices are most commonly used in an open-loop control configuration which does not involve feedback mechanismsat time scales comparable to characteristic times of the flow nor prediction of the future state of the actuated flow.

Closed-loop control is a signal-based control that involves the estimation or measurement of the instantaneous stateof the flow to feed the controller back and adjust the control parameters in real time. This configuration thus involvesevaluation of the actuators inputs from the sensor outputs to achieve a desired effect. This kind of control is suitablefor applications with limited amount of energy to manipulate the flow and for systems intended to a relatively wideoperating envelope, thereby limiting the drop in performance associated with multiple designs.

Inferring a model describing the system, and capable of predicting the response of the flow to the forcing, fromobservations is crucial to compute the necessary actuation for a given target. There basically exist two strategiesto obtain models that attempt to arrange observations into some pattern: the physics-based model approach andthe system identification approach. The former seeks a reduced order model (ROM) based on a basis deduced fromexperiments. One of the usual choices of basis has been to consider a Proper Orthogonal Decomposition (POD). Theset of equations of the reduced order model is obtained by a Galerkin projection of the Navier-Stokes equation ontothe POD modes. This procedure leads to a system of ordinary differential equations of as many equations as modesretained in the analysis. However, neglecting the high index modes usually responsible for damping of the physicalsystem may lead to a divergence of the resulting ROM. A description of efforts to avoid this effect can be found forinstance in10, among others. POD modes usually exhibit multiple frequencies and it is difficult to associate theirspatial structure to an easily observable flow feature. Further, the approximation basis obtained may not be versatileenough to accurately describe diverse flow conditions. Recently, different efforts have been dedicated to improve thequality of the basis to remedy this limitation,11. Another limitation of this POD-based approach is the difficulty withthe proper inclusion of an external action in the formulation, either associated to the actuation or to autonomousdisturbances to the flow.

a)Electronic mail: [email protected]



2

Among the advantages of this formulation is the possibility to easily define the objective function. When it isdesired to minimize fluctuations of the flow, it is possible to directly seek for a minimization of the total energy ofthe fluctuating part of the flow, which can be determined from the temporal coefficients of the modes (chronos). It isalso possible to build a ROM from the so-called global modes, but this strategy is not always well suited,12. However,one of the most restrictive requirements of ROM approaches is that the data used to generate the model are velocityfields of the flow to be controlled. From the point of view of field applications, this constitutes a major limitation.Hence, the analysis with this kind of approach has been mostly restricted to numerical benchmarks or experimentsin wind tunnels equipped with Particle Image Velocimetry (PIV) systems.

Models issued from the second approach, System Identification, are usually empirical black box models. One ofthe most popular choices of this methodology is based on an autoregressive relation between current and past systemcontrol variables and observables that constitute the state vector. Typical examples are the algorithms based onAutoRegressions with eXogenous inputs (ARX),13–16 or AutoRegressions with eXogenous inputs and Moving Average(ARMAX),17. Estimation of the parameters of the model is performed using known input-output data retrieved fromflow field measurements. The estimation involves minimizing the error norm (typically in the L2-sense) between themodel output and the actual output from the fluid flow system given the same input data sequence. Shortcomingsassociated with a system identification strategy such as that described in17 comprise effects associated to non-linearitiesnot included in the analysis, a laborious tuning of the parameters of the model and difficulties in the definition of theobjective function.

In this work we propose an improvement upon this last point. Actuation is introduced with the purpose of forcingsome characteristic streaklines of the flow to lie into a prescribed region. The objective function to be minimized isdefined in terms of the concentration of a tracer injected upstream in the flow, at selected points downstream. Tothis end, we introduce a new visualization-based approach for active fluid flow control.

This approach has similarities with the concept of visual servoing techniques. Control strategies based on visionare well established techniques in robotics and automation communities. The method consists in using feedbackinformation provided by a vision sensor observing the system to be controlled. In the field of flow control, only a fewefforts have been carried-out along these lines, using the velocity flow fields as input data18–20.

In practical applications, the techniques of flow control based on velocity field data often prove impractical. The useof Particle Image Velocimetry (PIV) systems outside of a laboratory environment may present some problems relatedto the use of powerful lasers, to the dense seeding of tracers required and to the careful alignment of sophisticatedcameras. Further, traditional PIV systems may not be rapid enough for all applications as a consequence of lowsampling rates and time required for the processing of the acquired images.

A. Scope of the paper

To avoid difficulties associated with the use of PIV, we here present a closed-loop control methodology simplybased on the image intensity in a set of probes (selected points of the image of the flow field). The image intensityis proportional to the local concentration of a passive tracer injected upstream. The prototypical wake produced bya cylinder immersed in a uniform stream is chosen as the physical system to control. The flow is controlled withplasma actuators disposed on the cylinder surface. The present work is focused on a laminar, two-dimensional flowat a low Reynolds number (Re, evaluated with the cylinder diameter, free stream velocity and viscosity coefficient)of 235. This value is close to the threshold of appearance of 3-D instabilities of the non-actuated flow. However, asynchronized plasma actuation in the span-wise direction, enlarges the range of Reynolds number in which the flowremains 2-D and a steady plasma actuation has already been shown to be able to stabilize this kind of flow,21. Wehere test the visualization-based control on a numerical benchmark since all system variables are then easily availableand this facilitates the evaluation of the control performance. However, the present method can be easily applied ina laboratory environment and beyond in a real application.

In section 2 of this manuscript we explain how data were generated using a numerical simulation. The systemidentification algorithm is presented in section 3. In section 4, we propose a Generalized Predictive Controller (GPC)scheme to minimize fluctuations of the wake over a predictive horizon. In section 5, the control system is tested andresults are discussed. Model validity and robustness under noise in the measurements, in the tracer injection system,and changes in the inflow conditions are analysed.

II. PSEUDO-EXPERIMENTAL SET-UP

We consider a two-dimensional flow around a circular cylinder and the control objective of stabilizing the wake(suppression of the vortex shedding).



3

Simulations are performed with the code Saturne,22. A uniform stream with constant velocity is considered as inletcondition, and the other boundary conditions are indicated on Fig. 1. The Strouhal number of the flow (calculatedfrom the shedding frequency, free-stream velocity and diameter of cylinder) is close to 0.2. Considering the meshused and the CFL condition, the non-dimensional time step of the simulation (based on velocity of the free-streamand cylinder diameter) was set to 0.061. A filament of a passive scalar with a unit constant concentration is injectedupstream the cylinder. The concentration of the injected scalar is monitored downstream and a control action isapplied at each simulation step. Several probes are symmetrically placed in the wake along the streamwise directionto measure the scalar concentration (see Figs. 2 and 3). Once the non-actuated flow system attains the asymptoticregime, the tracers concentration at each probe becomes periodic in time (Fig. 4). Note that in a physical experiment,the tracer’s concentration at a given point can be associated to the instantaneous gray level of a pixel, or group ofpixels, in a single camera snapshot. Unless specified, we consider a perfect tracer injection system, perfect sensors anda spatially uniform, constant in time, velocity at the inlet. In a practical implementation, there can exist fluctuationsof the injection system and the cameras used to visualize the flow have errors in the measurements. We will takeinto account these effects in the closed loop problem by considering a pseudo-random noise introduced in the scalarconcentration at the injection point and a pseudo-random noise affecting measurements of the sensors. In some cases,we will also admit that a pseudo-random noise may affect the inlet conditions and that the inlet velocity is alteredin time. Two actuators are set on the cylinder surface and add momentum tangentially to the surface. The set-up ofthe simulation considers plasma actuators,23 with simultaneous and equal momentum injection over an arc length ofabout 5% of the cylinder circumference (Fig. 1). The actuators are located close to the separation line with the goalthat the momentum injection produced by actuation promotes the postponement of the separation of the boundarylayer from cylinder surface. Previous studies have shown that, with this actuator configuration, a steady forcing ofamplitude high enough is able to stabilize the wake flow,21. We here propose to stabilize the wake flow with a timevarying forcing of much lower amplitude. The actuator is simulated as in21 and24 as an imposed boundary conditionin a localized region of the surface of the cylinder. We identify the amplitude of actuation with the value of thetangential velocity at that location at the surface of the cylinder. The control system we propose builds upon the twoactuators- that force the flow simultaneously, in phase, and with the same amplitude- and upon the measurementsobtained from eight probes. The system identification algorithm that we describe in the following section enables toderive a model that links the amplitude of the actuation and the value of scalar concentration at each probe. Thecontrol algorithm we consider in this work determines the command required at each time step based on the previousvalues of the amplitude of actuation, on the scalar concentration at the probes measured in the past and on the futuremeasurements predicted by the model within a time horizon. Consequently, the controller scheme can be classified asa multiple input multiple output (MIMO) configuration.

Figure 1. Experiment layout. Actuators and scalar concentration probes location (Re = 235, Simulation domain 27.5 × 25diameters, cylinder vertically centred at 7.5 diameters from the inlet).

III. SYSTEM IDENTIFICATION

To describe the flow dynamics we consider a linear time-invariant model given by

y(k) + α1y(k − 1) + · · ·+ αpy(k − p) = β0u(k) + β1u(k − 1) + · · ·+ βpu(k − p) (1)



4

Figure 2. Instantaneous streakline pattern of the non actuated flow and values of scalar concentration at the different probes.

Figure 3. Instantaneous vorticity field of the non actuated flow and vorticity amplitude at probes location.

Figure 4. Time evolution of scalar concentration measured at probes 1 and 4 when starting the simulation. Note the differencein amplitude and the delays in time between the two measures associated to the different positions of the probes.



5

where y(k) ∈ Rm is the system state (the output), u(k) ∈ Rr the actuation (the input), p ∈ N the model order andk ∈ N the current time step.

We refer to this system as an AutoRegressive with eXogenous inputs model (ARX). The model matrix coefficients,αi, 1 ≤ i ≤ p, and βi, 0 ≤ i ≤ p, of size m×m and m× r respectively, are the so-called observer Markov parametersand characterize the model,13. Sometimes the dynamics from u to y contains a delay of nd samples, so some firstcoefficients βi are zero. It may be a good idea in some cases to explicitly display this delay in eq. (1). However foreasier notation and taking into account that is acceptable to underestimate delays but not to overestimate them, wedirectly consider in this work nd = 0.

Defining the parameters matrix

Θ := (α1 . . . αp β0 . . . βp)T ∈ R(pm+(p+1)r)×m

and the regression vector

ϕ(k) =

−y(k − 1)...

−y(k − p)u(k)...

u(k − p)

∈ Rpm+(p+1)r,

Eq. (1) can be written as

y(k) = ΘTϕ(k).

If we define θ as a vector of size d := pm2 + (p+ 1)mr which gathers all the coefficients of matrices αi and βi, andconsider Ξ(k) := ϕ(k)⊗ Im, ⊗ being the Kronecker product and Im the m×m identity matrix, Eq. (1) rewrites as

y(k) = ΞT (k)θ.

To estimate θ, we consider a training phase where both the actuation and the response of the physical system areknown. N training samples are used, together with a least squares criterion, to determine an estimation θLS

N of θ from

θLSN =

(1N

N∑

k=1Ξ(k)ΞT (k)

)−11N

N∑

k=1Ξ(k)y(k). (2)

When the matrix∑N

k=1 Ξ(k)ΞT (k) is close to being singular, a more effective method may be used to estimate theparameters,25. Defining

ΦT := (Ξ(1) . . .Ξ(N)) ∈ Rd×Nm,

Y T := (yT (1) . . . yT (N)) ∈ R1×Nm,

the estimation of θ is obtained from a QR decomposition of the Nm × (d + 1) matrix [ΦY ], in which the first dcolumns are those of the matrix Φ and the last column is the vector Y .

With these definitions, our problem consists in finding θ which minimizes ‖Y − Φθ‖22. We consider a QR-

decomposition of matrix [ΦY ] = QR, Q being a Nm × Nm matrix with orthonormal columns and R =[R00

]

a Nm× (d+ 1) upper triangular matrix. In particular, R0 =[R1 R20 R3

]with R1 a d× d upper triangular matrix, R2

a d× 1 vector, and R3 a scalar.Q having orthonormal columns, it comes that ‖Y − Φθ‖2

2 =∥∥QT (Y − Φθ)

∥∥22. Since QT Φ is the first d columns of

R and QTY is the last column of R, it yieldsQT Φθ =

[R1θ

0

]and QTY =

[R2R3

].

So, we obtain∥∥QT (Y − Φθ)

∥∥22 =

∥∥∥∥[R2 −R1θ

R3

]∥∥∥∥2

2. When minimizing this quantity and solving the system R1θ =

R2 we obtain θ the estimation of θ. Also note that∥∥∥Y − Φθ

∥∥∥2

2= |R3|2.



6

A. Tuning of parameters

The training phase was designed to collect input-output instances (Fig. 5) and identify a model of the system.During this phase, the actuators trigger a step pulse and the scalar measurements are used in Eq. (2) to estimatethe coefficients. Considering the flow as a nonlinear dynamical systems, this forcing step perturbs the orbit in thestate space from the attractor. The system then enters a relaxation phase in which the trajectory gradually returnsto the orbit around the attractor. Analysis of these transients has been carried-out in some recent works,26. Whenthe pulse step is triggered, the scalar concentration in the probes is drastically reduced during a short period of time.This reduction occurs with different delays that depend on the distance of the probe to the cylinder. The number ofsamples to be considered to train the autoregression model is related to these delays and to the time required for thesystem to relax to an unperturbed flow dynamics when actuation ceases17.

Figure 5. Training phase of the system. The four upper plots show the scalar concentration evolution in time at the differentprobes during the training period. The bottom plot shows the pulsed actuation applied simultaneously to each actuator.

The variables involved in the system identification strategy are the pulse duration of the forcing, the number N oftraining samples, the sampling rate, the number of probes m and their location and the horizon of autoregression p.In our configuration, the tuning parameters have been set to p = 90 time steps, N = 1090, pulse duration of 10 timesteps and a non-dimensional sampling rate of 0.061.



7

B. Effects of non-linearities

A review of cylinder wake control with single sensor linear feedback control systems or systems involving severalpressure probes can be found in27. Wake flows can be considered in general as oscillators exhibiting self-excitedoscillations. Although the von Kármán mode is the first global mode to become unsteady, a wake flow far above thecritical Reynolds number, for which the steady flow becomes unstable, may exhibit multiple interacting global modes.Stabilization of the flow requires in principle attenuation of all these global modes. Single-sensor control is difficultsince forcing with an amplitude high enough to suppress the most unstable mode often destabilizes other modes.Measurements at different locations within the wake are therefore not simply related by a phase shift and multiple,spatially distributed, sensors are then required to control the flow. The present visualization-based approach is hencewell suited to stabilize a large number of modes since many sensors are available.

To account for the effect of non-linearities, a natural choice would probably have been to use a non-linear model,25.However, this approach is computationally more challenging and expected benefits are often limited. Discussionsabout linear control approaches in non-linear flows can be found for example in16. In particular, a strategy basedon neural networks has been proposed for a wake flow control problem in a recent work,28. Other strategies likeadaptive identification algorithms or the stabilization of the flow prior to system identification are also possible,29. Inagreement with the rationale of other researchers,16, for flow control purpose, instead of deriving an accurate systemmodel, our primary goal is to construct a simple input-output data-based system model, which could lead to effectivefeedback control laws.

When non-linear interactions between the global modes and the control input are significant, a linearised modeldeveloped with the purpose of reducing kinetic energy fluctuation of the flow manages to suppress oscillations of thesignal at the sensor locations,30,31. Therefore, even when non-linearities are present, the use of a linear model allowsto locally reduce the quantity to be minimized. We thus aim at deriving a model, not to control the dynamics of alloscillating modes, but to control the dynamics of some streaklines. It hence reformulates from annihilating all unstablemodes to stabilizing solely the modes that significantly drift the flow from its prescribed pattern. It reduces to awake design problem in which only wake fluctuations within prescribed margins determined by the probes location areallowed. Obviously, a physical knowledge of the flow pattern that can be associated to a stabilized flow is required.In the case of the cylinder wake, it is well known that stabilization produces narrow and longer wakes. Hence, byforcing the wake to exhibit this pattern one can expect that the energy associated to the fluctuations will be reduced.

To test the validity of the model, we compare tracer’s concentration signals, in conditions different from those ofthe training phase, with the outputs of the identified model (90 time step ahead prediction) yi, i = 1, · · · , 8. We testthe model with a data set, labelled data series 1, associated to a step actuation combined with a sinus function (sinusfrequency is 225 % higher than the natural frequency of the flow), Fig. 6. We can observe a satisfactory behaviourof the model reproducing the main frequencies of the oscillations and not dramatically straying from data (Fig. 8).The system is stable and returns to its equilibrium state once the actuation ceases. However, during the actuationinterval, the model predicts signals of tracer concentration with a high frequency component while the actual systemdoes not exhibit these frequencies. This can be related to saturations of the flow dynamics induced by non-linearitiesthat are absent in the identified linear model we consider.

A second data series (data series 2 ) considers the case when the period of the forcing allows lock-in (Fig. 7).The frequency of the excitation considered is here 1.25 times higher than the frequency of the natural flow and theactuation imposes its dynamics to the vortex shedding. For this data set, the identified model reproduces the signalsat the probes correctly without introducing significant spurious frequencies (Fig. 9).

IV. CLOSED-LOOP CONTROL ALGORITHM

Letting s ∈ N be the prediction horizon, we define vectors ys ∈ Rsm, us ∈ Rsr and vp ∈ Rp(m+r) according to

ys(k) :=

y(k)...

y(k + s− 1)

, us(k) :=

u(k)...

u(k + s− 1),

,



8

Figure 6. Model behaviour with data series 1. In the upper plots are shown the scalar concentration evolution in time atdifferent probes during the experiment. The bottom plot shows the actuation applied simultaneously to each actuator. Theactuation is a step combined with a sinus function having a frequency of 225 % higher than the natural frequency of the flow.

vp(k − p) :=

y(k − 1)...

y(k − p)u(k − 1)

...u(k − p)

.

From Eq. (1) we can obtain a matrix expression to predict future outputs of the system,

ys(k) = T us(k) + Ψvp(k − p) (3)

where T is a Toeplitz matrix given by



9

Figure 7. Model behaviour with data series 2 in a lock-in regime. In the upper plots are shown the predictions of theidentified model for the scalar concentration evolution in time at different probes. The bottom plot shows the actuation appliedsimultaneously to each actuator. Actuation is a sinus function with a frequency 125 % higher than the natural frequency ofthe flow.

T :=

β0

β(1)0 β0

β(2)0 β

(1)0 β0

. . . . . . . . . . . . . . .

β(s−1)0 . . . . . . β

(1)0 β0

with β0, β(1)0 , . . . β

(s−1)0 known as system Markov parameters, and T and Ψ matrices of size ms×sr and ms×p(m+r)

respectively. They are obtained by a series of recursive relations from the model parameters as described in13.

The so-called pulse response parameters of the system β(k)0 are obtained from:



10

Figure 8. Comparison of spectrograms of the simulation (left) and predictions of the model built through system identification(right) for the data set of Fig. 6.

Figure 9. Comparison of spectrograms of the simulation (left) and predictions of the model built through system identification(right) for the data set of Fig. 7.

β(0)0 = β0,

β(k)0 = βk +

k∑

i=1αiβ

(k−i)0 , 1 ≤ k ≤ p,

β(k)0 =

p∑

i=1αiβ

(k−i)0 , k > p.

The matrix Ψ is defined as

Ψ :=

α1 α2 . . . αp β1 β2 . . . βp

α(1)1 α

(1)2 . . . α

(1)p β

(1)1 β

(1)2 . . . β

(1)p

. . . . . . . . . . . . . . . . . . . . . . . .

α(s−1)1 . . . . . . α

(s−1)p β

(s−1)1 . . . . . . β

(s−1)p

with the following relations for αk1 , β

jk and αj

k:



11

α(0)1 = α1,

α(k)1 = αk+1 +

k∑

i=1αiα

(k−i)1 , 1 ≤ k ≤ p− 1,

α(k)1 =

k∑

i=1αiα

(k−i)1 , k ≥ p,

β(j)1 = α

(j−1)1 β1 + β

(j−1)2 ,

...β

(j)p−1 = α

(j−1)1 βp−1 + β(j−1)

p ,

β(j)p = α

(j−1)1 βp,

α(j)1 = α

(j−1)1 α1 + α

(j−1)2 ,

...α

(j)p−1 = α

(j−1)1 αp−1 + α(j−1)

p ,

α(j)p = α

(j−1)1 αp.

We consider a control algorithm based on Generalized Predictive Controller (GPC),14, with the objective of de-creasing the scalar concentration measured by the sensors. The algorithm generates, at each sampling instant, thefuture s inputs that minimize the cost function

J = yTs (k)Qys(k) + λuT

s (k)us(k) (4)

where Q is a sm × sm block diagonal matrix with blocks Qi := diag(q1 . . . qm), with qi the weight of sensor i,0 ≤ qi ≤ 1. The values of these weights are set to unity. The use of different weight values for each probe i allows,for instance, to take into account the downstream diffusion of the vorticity of the tracer. An improved version of thiscost function with vectors ys ranging from k + nd to k + s− 1 , gives the possibility to take into account the delaysfrom inputs to outputs. However, for the sake of simplicity, we consider in this manuscript nd = 0 .

The parameter λ of Eq. (4) penalizes the actuation magnitude. In our experiments, λ has always been set to 4.Note that minimizing the cost function J does not necessary imply minimizing the kinetic energy of fluctuations.This goal is achieved only by a suitable choice of probes location. The minimization of the cost function only allowsto penalize certain, undesirable, streaklines.

We consider a linear control law, us(k) = Kvp(k − p), with K a sr × p(m + r) matrix containing the controllercoefficients.

Applying Lagrange’s method to minimize J under the constraint given by Eq. (3), we consider the LagrangianL = J + 〈l, ys − T us −Ψvp〉, where l ∈ Rsm denotes the Lagrange multiplier, and 〈·, ·〉 is a suitable inner product ofRsm, yielding the system of optimality:

ys − T us −Ψvp = 0,2Qys + l = 0,

2λus − T T l = 0.

One then obtains K = −(T TQT + λIsr)−1T TQΨ, hence

us(k) = −(T TQT + λIsr)−1T TQΨvp(k − p) (5)

where Isr represents the sr × sr identity matrix.a. Since only the actuation value for the current time step k is required, only the first r rows of the product in

the first term of Eq. (5) are considered, so that finally

u(k) = {−(T TQT + λIsr)−1}rT TQΨvp(k − p). (6)

Once the actuation u is computed from Eq. (6) and the measurements y are taken, vp is updated and the wholeprocess is repeated at the next time step. The resulting control algorithm is now summarized:



12

Algorithm 1 Proposed control algorithm.Require: p: model order, s: prediction horizon, λ: actuator cost.Ensure: Control of the system under study.1: Take measurements during a training cycle.2: Compute an ARX model with order p.3: Define the controller K from s, λ, and the ARX model.4: Define the initial vp from y and u values up to step k − 1.5: for all time step k do6: Use Eq. (6) to obtain u(k).7: Apply the computed actuation u(k).8: Measure y(k), the resulting output for the time step k.9: Update vp from y(k) and u(k).10: end for

V. CONTROL SYSTEM RESULTS

Once the control parameters are tuned, the physical model is simulated and the trained controller determines anactuation signal that stabilizes the flow.

In Fig. 10, the clear link between actuation and scalar concentration is shown. As we can see, once the actuation isactivated and after a short period of time, the control system stabilizes. A decrease (increase) of scalar concentrationdetected by the sensors leads to a fast decrease (increase) of the magnitude of actuation. The instantaneous imagesof streaklines (Fig. 11) and vorticity field (Fig. 12) compared to the non-actuated flow (Figs. 2 and 3) show thestabilization of the wake as a consequence of the forcing and how the wake is controlled.

To further illustrate the stabilization of the wake, we represent in Fig. 13 the energy associated with fluctuationsas a function of time for the non-actuated and the actuated flow. As we can see, a reduction of about 85 percent inenergy is obtained.

The control impact can also be appreciated from the plot of the RMS fields of the velocity in the stream-wisedirection (Figs. 14 and 15). As can be seen, the control system forces the wake fluctuations to be concentrated withinthe narrow path delimited by the probes. We show on Fig. 16 the RMS values along an horizontal line containing thepoint that exhibits the maximum value of fluctuations (indicated as white lines on Figs. 14 and 15). The decreaseof the peak values of the RMS and the shift of this maximum towards downstream positions that we can observe inFig. 16 indicates the stabilizing effect of the control on the wake. These results are similar to those obtained with acontinuous forcing,21.

The validity of the control algorithm under conditions different from the training configuration is now consideredwith cases in which a pseudo-random noise of amplitude 10% affects the uniform inlet flow velocity (Fig. 17), apseudo-random noise of 10% affects the concentration injection (Fig. 18) and pseudo-random noise of 0.1% affectssensor measurements, (Fig. 19). In all these cases the behavior of the control system was satisfactory and illustratesits robustness.

Alteration of the inlet velocity was also considered with changes up to 20% in the Reynolds number. For thispurpose we considered a time varying velocity at the inlet following an ascending (resp. descending) ramp, plateauedat the new value and then decreased (resp. increased) to the original one. We can observe on Figures 20 and 21that the controller is able to adapt the command and preserve the control performance. After a transient, the controlsystem stabilizes the cylinder wake under the new conditions and the fluctuating energy diminishes (Fig. 22).

VI. CONCLUSIONS

A visualization-based closed-loop control system was developed and tested in a numerical simulation. The approachwe propose is based on images of the flow and essentially consists in preventing the flow field to exhibit some patterns.A laminar flow around a circular cylinder was chosen to demonstrate the algorithm performance in reducing the wakeoscillations amplitude. The control was achieved via plasma actuators disposed on the cylinder surface that addmomentum tangentially to the cylinder surface close to the boundary layer separation line. The control system isbased on an ARX system identification model with a Generalized Predictive Controller.

The flow considered here exhibits global instabilities with amplitudes that are driven by the non-linear interactionof the modes. Single-sensor control of this kind of flow is difficult since forcing with an amplitude high enough tosuppress the most unstable mode often destabilizes other modes. Indeed, the un-modelled non-linear dynamics may



13

Figure 10. Closed-loop control results. Scalar concentration at different probes and amplitude of actuation as a function oftime.

severely limit the performance of control systems based on a single or very few probes. The present visualization-based system effectively relies on a large number of non-intrusive sensors. The resulting linear controller was shown toachieve an efficient feedback control with a reduction of more than 80% in the mean fluctuating kinetic energy. In thecontext of separated flows, the control effectiveness is often limited by the absence of workable cost functions16. In thisregard, our study represents a step forward, extending the use of linear system models in complex flows by allowingthe choice of a suitable cost function. The goal of this work was restricted to obtaining a narrow wake, which, forthis kind of flow, is known to produce a reduction of the kinetic energy associated with wake fluctuations. Extensionsto other goals usually considered in separated flows like lift enhancement or separation reduction are possible by asuitable choice of the probes location.

Compared to noise amplifier flows, the present test case puts markedly less stringent constrains on how to take intoaccount the effects of external disturbances in the control strategy. The robustness of the control system was testedby considering pseudo-random noise in the measures of the sensors, tracer injection system and uniformity of the inletflow. We also tested the ability of the controller to adjust to a new inlet velocity. In all these cases, and within therange of the parameters studied, we obtained satisfactory results, achieving a reduction of the wake fluctuations energyof about 85%. These results provide confidence in application of this approach to physical experiments that may beclose to field configurations. The number of probes required depends on the characteristics of the flow considered andthe tuning of parameters may be laborious in some cases. In physical experiments, the use of a numerical benchmark to



14

Figure 11. Instantaneous streaklines and values of scalar concentration at the probes of the controlled wake.

Figure 12. Instantaneous vorticity field and values at the probes of the controlled flow.

Figure 13. Instantaneous and time-averaged kinetic energy of fluctuations for the non-actuated and controlled flow. Control isactivated at time step number 500.



15

Figure 14. RMS of the velocity in the stream-wise direction for the non-controlled flow. The horizontal white line at y=0.415is in correspondence with the maximum of the RMS.

Figure 15. RMS of the velocity in the stream-wise direction for the controlled flow. The horizontal white line at y=0.280 is incorrespondence with the maximum of the RMS.

Figure 16. RMS of the velocity in the streamwise direction along white lines indicated on figures 14 and 15.



16

Figure 17. Instantaneous values and time averages of the kinetic energy of the controlled flow when a pseudo-random noise of10 % is added to the inlet flow velocity.

Figure 18. Instantaneous values and time averages of the kinetic energy of the controlled flow when a pseudo-random noise of10% is added to the injection system.

Figure 19. Instantaneous values and time averages of the kinetic energy of the controlled flow when a pseudo-random noise of0.1 % is added to the sensors.



17

Figure 20. Changes in the inlet condition. The Reynolds number increases from 235 to 282 and recovers its initial value followinga ramp (green-dash plot)). Upper plot: Scalar concentration at probe 1 as a function of time. Lower plot: Instantaneousamplitude of the forcing in each actuator. The control system adapts its command to stabilize the wake to the new inletcondition.

Figure 21. Changes in the inlet condition: The Reynolds number of the controlled flow decreases from 235 to 219 and recoversits initial value following a ramp (green-dash plot)). Upper plot: Scalar concentration at probe 1 as a function of time. Lowerplot: Instantaneous amplitude of the forcing in each actuator. The control system adapts its command to stabilize the waketo the new inlet condition.

determine the appropriate parameters may simplify this procedure. Compared with other control techniques relyingon images of the flow, some advantages of the present implementation are the simplicity of the instrumentationrequired and a reduction of the post-processing steps of the acquired images. The proposed control methodologyis generic enough to be adapted to other experiments, in particular those involving three-dimensional flows wherethe tracer concentration can be monitored with images acquired from two or more cameras suitably disposed. Thepresent work can be considered as a proof-of-concept and an actual application to a real-world problem may benefitfrom the use of a more robust ARMAX model instead of the present ARX implementation. Mutatis mutandis, thecorresponding control methodology is quite similar.



18

Figure 22. Instantaneous and time averages of kinetic energy fluctuations when inlet conditions change in time as in Figs. 20and 21.

ACKNOWLEDGMENTS

We thank C. Collewet for helpful comments. This research is supported by grants of the UBA, CONICET andCNRS.

REFERENCES

1J. Lin, “Review of research on low-profile vortex generators to control boundary-layer separation,” Progress in Aerospace Sciences 38,389–420 (2002).

2G. Godard and M. Stanislas, “Control of a decelerating boundary layer. part 3: Optimization of round jets vortex generators,” AerospaceScience and Technology 10, 455–464 (2006).

3T. Duriez, J. Aider, and J. Wesfreid, “Self-sustaining process through streak generation in a flat-plate boundary layer,” Physical ReviewLetters 103 (2009).

4A. Roshko, “On the wake and drag of bluff bodies,” J. Aeronaut. Sci. 22, 124–132 (1955).5J. Kostas, J. Foucaut, and M. Stanislas, “The flow structure produced by pulsed-jet vortex generators in a turbulent boundary layer inan adverse pressure gradient,” Flow, Turbulence and Combustion 78, 331–363 (2007).

6B. Thiria, S. Goujon-Durand, and J. Wesfreid, “The wake of a cylinder performing rotary oscillations,” Journal of Fluid Mechanics560, 123–147 (2006).

7G. Artana, R. Sosa, E. Moreau, and G. Touchard, “Control of the near wake-flow around a circular cylinder with electrohydrodynamicactuators,” Experiments in Fluids 35, 580–588 (2003).

8M. Munska and T. Mclaughlin, “Circular cylinder flow control using plasma actuators,” AIAA paper 2005-0141 (2005).9T. Jukes and K. Choi, “Control of unsteady flow separation over a circular cylinder using dielectric-barrier-discharge surface plasma,”Physics of fluids 21, 094106 (2009).

10G. Artana, A. Cammilleri, J. Carlier, and E. Memin, “Strong and weak constraint variational assimilations for reduced order modellingfor flow control,” Physics of fluids 8, 3264–3288 (2012).

11C. Rowley, “Model reduction for fluid flows using balanced proper orthogonal decomposition,” Int. J. Bifurc. Chaos 15, 997–1013 (2005).12A. Barbagallo, D. Sipp, and P. Schmid, “Why may reduced order models based on global modes not work for closed loop control?”(2009).

13J.-N. Juang and M. Phan, “Deadbit predictive controllers,” Technical Memorandum 112862 (Nasa, 1997).14M. A. Kegerise, R. H. Cabell, and L. N. Cattafesta, “Real time feedback control of flow-induced cavity tones - part 1: Fixed-gaincontrol,” Journal of Sound and Vibration 307, 906–923 (2007).

15M. A. Kegerise, R. H. Cambell, and L. N. Cattafesta, “Real time feedback control of flow-induced cavity tones - part 2: Adaptivecontrol,” Journal of Sound and Vibration 307, 924–940 (2007).

16S.-C. Huang and J. Kim, “Control and system identification of a separated flow,” Physics of Fluids 20 (2008).17A. Herve, D. Sipp, P. J. Schmid, and M. Samuelides, “A physics-based approach to flow control using system identification,” Journalof Fluid Mechanics 702, 26–58 (2012).

18R. T. Fomena and C. Collewet, “Fluid flow control: a vision-based approach,” International Journal of Flow Control 3, 133–169 (2011).19M. Gharib, C. Willert, and M. Munson, “Real-time particle image velocimetry for closed-loop flow control applications,” (2010).20J. A. N. Gauthier, “Control of the detached flow behind a backward facing step by visual feedback,” ArXiv 1306.4554v (2013).21J. D’Adamo, L. M. Gonzalez, A. Gronskis, and G. Artana, “The scenario of two-dimensional instabilities of the cylinder wake underelectrohydrodynamic forcing: a linear stability analysis,” Fluid Dynamics Research 44, 20 (2012).

22F. Archambeau, N. Méchitoua, and M. Sakiz, “Code_saturne: a finite volume code for the computation of turbulent incompressibleflows,” International Journal on Finite Volumes 1 (2004).



19

23J. R. Roth, D. M. Sherman, and S. P. Wilkinson, “Electrohydrodynamic flow control with a glow-discharge surface plasma,” AIAAJournal 38, 1166–1172 (2000).

24A. Gronskis, R. Sosa, and G. Artana, “Modelling ehd actuation with a slip velocity,” (2009).25L. Ljung, System Identification: Theory for the User (Prentice-Hall Inc., Englewood Cliffs, N.J., 1987).26G. Tadmor, O. Lehmann, B. R. Noack, and M. Morzynski, “Mean field representation of the natural and actuated cylinder wake,”Physics of Fluids 22, 034102 (2010).

27H. Choi, W. Jeon, and J. Kim, “Control of flow over a bluff body,” Annual Review of Fluid Mechanics 40, 113–139 (2008).28K. Cohen, S. Aradag, S. Siegel, J. Seidel, and T. McLaughlin, Low Reynolds Aerodynamics and Transition (edt by Mustafa SerdarGenc, InTech Europe, 2012) Chap. 6, pp. 117–138.

29L. N. Cattafesta, Q. Song, D. R. Williams, C. W. Rowley, and F. S. Alvi, “Active control of flow-induced cavity oscillations,” Progressin Aerospace Sciences 44, 479–502 (2008).

30E. Gillies, “Low-dimensional control of the circular cylinder wake,” Journal of Fluid Mechanics 371, 157–178 (1998).31K. Roussopoulos, “Feedback control of vortex shedding at low reynolds number,” Journal of Fluid Mechanics 248, 267–296 (1993).



F Codigos Fuente

F.1. Extension del Mallado 2D a 3D

% Rutina para extrudar una malla 2D del GID (leida en formato .msh)

% una distancia dz y guardarla con formato .msh para utilizar en code saturne

close all;clear all

%numero de layers: condiciones de borde

layers_number=6;

% %espesor de extrudado

dz=5*1e-3;

%factor de escala para cambiar la unidad de medida de todos los nodos procesados

escala=1;

%nombre del archivo inicial

unit1=’cilindro.noestructurado.dat’;

%nombre del archivo final

unit2=’cilindro.noestructurado.msh’;

% Lectura de la malla 2D

fid = fopen(unit1, ’r’);

nnodes = textscan(fid, ’ %f’, 1, ’headerlines’, 4);

node_coords = textscan(fid, ’ %f %f %f’, nnodes{1});

nelems = textscan(fid, ’ %f’, 1, ’headerlines’, 3);

elems = textscan(fid, ’ %f %f %f %f %f %f %f %f %f’, nelems{1});

layers = textscan(fid, ’ %d %q’, layers_number, ’headerlines’, 3);

fclose(fid);

%deteccion del nro de BC asociado a simetria

Lnumber = -1;

for i=1:layers_number

name=char(layers{2}(i));

K=strcmp(name,’simetria’);

if K==1

Lnumber=layers{1}(i);

end

end

if Lnumber == -1

Lnumber=layers_number+1;

end

% Matriz de coordenadas de nodos: [nNodo x y z]

node_coordstot(1:nnodes{1},1)=node_coords{1};

node_coordstot(1:nnodes{1},2)=node_coords{2}*escala;

node_coordstot(1:nnodes{1},3)=node_coords{3}*escala;

node_coordstot(1:nnodes{1},4)=0.0*escala;

node_coordstot(nnodes{1}+1:2*nnodes{1},1)=node_coords{1}+nnodes{1};

node_coordstot(nnodes{1}+1:2*nnodes{1},2)=node_coords{2}*escala;

node_coordstot(nnodes{1}+1:2*nnodes{1},3)=node_coords{3}*escala;

node_coordstot(nnodes{1}+1:2*nnodes{1},4)=dz;

%Matriz de conectividad

n1=0;n2=0;n3=0;

for i=1:nelems{1}

if elems{2}(i)==1

n1=n1+1;

152


elseif elems{2}(i)==2

n2=n2+1;

elseif elems{2}(i)==3

n3=n3+1;

end

end

nelems_lin=n1;

nelems_tri=n2;

nelems_quad=n3;

nelemens_tot=nelems_lin+3*(nelems_tri+nelems_quad);

Elemconec1=zeros(nelems_lin,9);

Elemconec2=zeros(2*nelems_tri,8);

Elemconec3=zeros(2*nelems_quad,9);

Elemconec4=zeros(nelems_tri,11);

Elemconec5=zeros(nelems_quad,13);

n1=0;n2=0;n3=0;n4=0;n5=0;

for i=1:nelems{1}

if elems{2}(i)==1

n1=n1+1;

%elementos de superficie rectangulares (frontera)

Elemconec1(n1,1)=i;

Elemconec1(n1,2)=3;

Elemconec1(n1,3)=elems{3}(i);




Elemconec1(n1,7)=elems{6}(i)+nnodes{1};



end

end

nparcial=nelems_lin;

for i=1:nelems{1}

if elems{2}(i)==2

n2=n2+1;

%elementos de superficie triangulares (simentroa)

Elemconec2(n2,1)=n2+nparcial;



Elemconec2(n2,4)=Lnumber;





%elementos de superficie triangulares (la otra siemtroa en z=dz)

Elemconec2(n2+nelems_tri,1)=n2+nparcial+nelems_tri;

Elemconec2(n2+nelems_tri,2)=elems{2}(i);


Elemconec2(n2+nelems_tri,4)=Lnumber;


Elemconec2(n2+nelems_tri,6)=elems{8}(i)+nnodes{1};



end

end

nparcial=2*nelems_tri+nelems_lin;

for i=1:nelems{1}

if elems{2}(i)==3

n3=n3+1;

%elementos de superficie cuadrangulares (simentroa)




Elemconec3(n3,4)=Lnumber;





Apendice F. Codigos Fuente 153



%elementos de superficie cuadrangulares (simentroa)

Elemconec3(n3+nelems_quad,1)=n3+nparcial+nelems_quad;

Elemconec3(n3+nelems_quad,2)=elems{2}(i);


Elemconec3(n3+nelems_quad,4)=Lnumber;


Elemconec3(n3+nelems_quad,6)=elems{9}(i)+nnodes{1};




end

end

nparcial=2*nelems_tri+nelems_lin+2*nelems_quad;

for i=1:nelems{1}

if elems{2}(i)==2

n4=n4+1;

%elementos de volumen tipo prisma

Elemconec4(n4,1)=nparcial+n4;

Elemconec4(n4,2)=6;










end

end

nparcial=3*nelems_tri+nelems_lin+2*nelems_quad;

for i=1:nelems{1}

if elems{2}(i)==3

n5=n5+1;

%elementos de volumen tipo hexahedro


Elemconec5(n5,2)=5;












end

end

% Almacenamiento del archivo .msh

reng1=’$MeshFormat’;

reng2=’2 0 8’;

reng3=’$EndMeshFormat’;

reng4=’$Nodes’;

reng5=’$EndNodes’;

reng6=’$Elements’;

reng7=’$EndElements’;

reng8=’$PhysicalNames’;

reng9=’$EndPhysicalNames’;

fid2 = fopen(unit2,’w’);

fprintf(fid2, ’ %s\n’, reng1);




fprintf(fid2, ’ %d\n’, nnodes{1}*2);

fprintf(fid2, ’ %d %g %g %g\n’, node_coordstot’);





fprintf(fid2, ’ %d\n’, nelemens_tot);

if n1>0

fprintf(fid2, ’ %d %d %d %d %d %d %d %d %d\n’, Elemconec1’);

end

if n2>0

fprintf(fid2, ’ %d %d %d %d %d %d %d %d\n’, Elemconec2’);

end

if n3>0

fprintf(fid2, ’ %d %d %d %d %d %d %d %d %d\n’, Elemconec3’);

end

if n4>0

fprintf(fid2, ’ %d %d %d %d %d %d %d %d %d %d %d\n’, Elemconec4’);

end

if n5>0

fprintf(fid2, ’ %d %d %d %d %d %d %d %d %d %d %d %d %d\n’, Elemconec5’);

end



layers_numbers=layers{1};

layers_names=char(layers{2});

for i=1:layers_number

number=layers{1}(i);

name=char(layers{2}(i));

fprintf(fid2, ’ %d %s\n’, number, name);

end

if K==0

number=Lnumber;

name=’simetria’;

fprintf(fid2, ’ %d %s\n’, number, name);

end


fclose(fid2);

F.2. Conversion del Mallado Irregular a una Grilla Cartesiana

F.2.1. chrCleanFolderIfExists.m

function chrCleanFolderIfExists( folder )

if exist(folder, ’dir’)

rmdir(folder, ’s’);

end

mkdir(folder);

end

F.2.2. chrComputeAverage.m

function [ average ] = chrComputeAverage( filepaths , geo, isVector)

count = length(filepaths);

fprintf(’Computing average for %d files.\n’, count);

if count < 1

throw MException(’InvalidFileList:NotEnoughFiles’, ’It was not possible to compute the average for

the given file list’);

end

average = chrReadBinaryContent(filepaths{1}, geo, isVector);

for step = 2:count

content = chrReadBinaryContent(filepaths{step}, geo, isVector);

average = average + (content - average) / step;

end



fprintf(’Average computation finished.\n’);

end

F.2.3. chrComputeVorticityAverageForGeoXY.m

function [ vorticityZ ] = chrComputeVorticityAverageForGeoXY( filepaths , geo, geoXY)

count = length(filepaths);

fprintf(’Computing average vorticity for %d files.\n’, count);

if count < 1



end

average = chrComputeAverage(filepaths, geo, true);

fprintf(’Transforming average to XY...\n’);

averageXY = geoTransformContentToXY(average, geo, geoXY);

%content = chrReadBinaryContent(filepaths{1}, geo, true);

%contentXY = geoTransformContentToXY(content, geo, geoXY);

[x,y] = meshgrid(geoXY.gridValues.x,geoXY.gridValues.y);

u = averageXY(:,:,1); v= averageXY(:,:,2);

fprintf(’Computing vorticity...\n’);

vorticityZ = curl(x,y,u’,v’);

vorticityZ = vorticityZ’;

fprintf(’Average Vorticity computation finished.\n’);

end

F.2.4. chrExtractBinaryHeader.m

function [ header ] = chrExtractBinaryHeader( filepath )

headerCharacters = chrGetAmountOfHeadingCharacters();

file = fopen(filepath, ’rb’);

if file < 1

throw(MException(’FileError:CannotOpenTheFile’, strcat(’There was an error trying to open the file:

"’, filepath, ’".’)));

end

header = fread(file, headerCharacters, ’char*1=>char’);

fclose(file);

end

F.2.5. chrFindFiles.m

function [ filepaths ] = chrFindFiles( settings )

filesFilter = strcat(settings.folder, ’/’, settings.filenamesFilter);

fprintf(’Seeking files under " %s"\n’, filesFilter);

filenamesStruct = dir(filesFilter);

filenames = {filenamesStruct.name};

filepaths = strcat(repmat(strcat(settings.folder,’/’), length(filenames),1),filenames’);

filepaths = sort(filepaths);

filepathsCount = length(filepaths);

fileMin = max(1, settings.filerangeFilter.min);

fileMax = min(filepathsCount, settings.filerangeFilter.max);

filepaths = filepaths(fileMin:fileMax);

end



F.2.6. chrFindFilesAndComputeAverage.m

function chrFindFilesAndComputeAverage( settings )

filepaths = chrFindFiles(settings);

geoFilepath = strcat(settings.folder, ’/’, settings.geoFilename);

if settings.isVector

outputFilename = ’chr.vectoraverage’;

else

outputFilename = ’chr.scalaraverage’;

end

outputFilepath = strcat(settings.outputFolder, ’/’, outputFilename);

outputCaseFilepath = strcat(settings.outputFolder, ’/CHR.case’);

geo = chrReadBinaryGeo(geoFilepath);

average = chrComputeAverage(filepaths, geo, settings.isVector);

chrCleanFolderIfExists(settings.outputFolder);

header = chrExtractBinaryHeader(filepaths{1});

chrWriteBinaryContent(header, average, outputFilepath);

%ignore copyResult variable since it could fail because of user permissions

%in the OS

copyResult = copyfile(geoFilepath, settings.outputFolder);

chrWriteCaseFile(outputCaseFilepath, outputFilename, settings.geoFilename, settings.isVector);

end

F.2.7. chrGetAmountOfHeadingCharacters.m

function [ headingCharacters ] = getAmountOfHeadingCharacters( )

headingCharacters = 80 ... % description line 1 (80 chars)

+ 80 ... % part (80 chars)

+ 4 ... % # (1 int)

+ 80; % coordinates (80 chars)

end

F.2.8. chrReadBinaryContent.m

function [ content ] = readBinaryContent( filepath, geo, isVector)


if file < 1


"’, filepath, ’".’)));

end

if isVector

valuesPerCell = 3;

else

valuesPerCell = 1;

end

headerCharacters = chrGetAmountOfHeadingCharacters();

fseek(file, headerCharacters, -1);

content = fread(file, length(geo.cells) * valuesPerCell, ’float32=>double’);

content = reshape(content, length(geo.cells), valuesPerCell);

fclose(file);

end

F.2.9. chrReadBinaryGeo.m

function [ geo ] = chrReadBinaryGeo( filepath )




if file < 1


"’, filepath, ’".’)));

end

headerCharacters = 80 + ... %CBinary format

80 + 80 + ... %Description lines

80 + ... %node id

80 + ... %element id %80 + ... %extends optional %6*4 + ... %min,max, etc optional

80 + ... %part

4 + ... %part number

80 + ... %description

80 ; %coordinates

fseek(file, headerCharacters, -1);

countCoordinates = fread(file, 1, ’int32=>int’);

coordinates = fread(file, countCoordinates*3, ’float32=>double’);

fseek(file, 80, 0); %penta6 assumed

countCells = fread(file, 1, ’int32=>int’);

cells = fread(file, countCells*6, ’int32=>double’);

fclose(file);

geo.coordinates = reshape(coordinates, countCoordinates, 3);

geo.cells = reshape(cells, 6, countCells)’;

end

F.2.10. chrReadVelocity2D.m

function [ velocity ] = chrReadVelocity2D(filepaths , geo, geoXY, clipArea)

isVector = true;

qtyFiles = length(filepaths);

fprintf(’Reading values and transforming to XY. %d files.\n’, qtyFiles);

if qtyFiles < 1



end

areaX = find(geoXY.gridValues.x >= clipArea.x1 & geoXY.gridValues.x <= clipArea.x2);

areaY = find(geoXY.gridValues.y >= clipArea.y1 & geoXY.gridValues.y <= clipArea.y2);

velocity.u = zeros(length(areaX), length(areaY), qtyFiles);

velocity.v = zeros(size(velocity.u));

for step = 1:qtyFiles

fprintf(’Reading file %d.\n’, step);

content = chrReadBinaryContent(filepaths{step}, geo, isVector);

contentXY = geoTransformContentToXY(content, geo, geoXY);

contentXY = contentXY(areaX, areaY,:);

velocity.u(:,:, step) = contentXY(:,:,1);

velocity.v(:,:, step) = contentXY(:,:,2);

end

fprintf(’Reading and transforming to XY finished.\n’);

end

F.2.11. chrWriteBinaryContent.m

function writeBinaryContent( header, content, outputFilepath )

file = fopen(outputFilepath, ’wb’);

if file < 1

throw(MException(’FileError:CannotWriteTheFile’, strcat(’There was an error trying to write the

file: "’, filepath, ’".’)));

end

fwrite(file, header, ’char*1’);

fwrite(file, content, ’float32’);

fclose(file);

end



F.2.12. chrWriteCaseFile.m

function chrWriteCaseFile( filepath, valuesFilename, geoFilename, isVector )

file = fopen(filepath, ’wt’);

fprintf(file, ’FORMAT\ntype: ensight gold\n\n’);

fprintf(file, ’GEOMETRY\nmodel: %s\n\n’, geoFilename);

if isVector

fprintf(file, ’VARIABLE\nvector per element: %s %s\n’, valuesFilename,valuesFilename);

else

fprintf(file, ’VARIABLE\nscalar per element: %s %s\n’, valuesFilename,valuesFilename);

end

fclose(file);

end

F.2.13. geoComputeIntersectionArea.m

function area = geoComputeIntersectionArea(xyTriangle, rect, delta, gridBounds)

x1 = rect(1)*delta + gridBounds.minX;

y1 = rect(2)*delta + gridBounds.minY;

x2 = (rect(1)+1)*delta + gridBounds.minX;

y2 = (rect(2)+1)*delta + gridBounds.minY;

% create a counter-clockwise rectangle for the clip operation

xyRect = [x1 y1; x2 y1; x2 y2; x1 y2];

clip = polygonClip(xyTriangle, xyRect);

if isempty(clip)

area = 0;

else

area = polygonArea(clip);

end

end

F.2.14. geoGetBoundingRectsForDelta.m

function rects = geoGetBoundingRectsForDelta(xyTriangle, delta, bounds, gridBounds)

maxX = max(xyTriangle(:,1));

minX = min(xyTriangle(:,1));

maxY = max(xyTriangle(:,2));

minY = min(xyTriangle(:,2));

xCellsUpToMin = floor((minX - bounds.minX) / delta);

xCellsUpToMax = floor((maxX - bounds.minX) / delta);

yCellsUpToMin = floor((minY - bounds.minY) / delta);

yCellsUpToMax = floor((maxY - bounds.minY) / delta);

xCellsUpToMin = max(xCellsUpToMin, gridBounds.minX);

xCellsUpToMax = min(xCellsUpToMax, gridBounds.maxX);

yCellsUpToMin = max(yCellsUpToMin, gridBounds.minY);

yCellsUpToMax = min(yCellsUpToMax, gridBounds.maxY);

rects = zeros((xCellsUpToMax - xCellsUpToMin + 1)*(yCellsUpToMax - yCellsUpToMin + 1), 2);

iiRect = 1;

for xx=xCellsUpToMin:xCellsUpToMax

for yy=yCellsUpToMin:yCellsUpToMax

rects(iiRect, :) =[xx, yy];

iiRect = 1 + iiRect;



end

end

end

F.2.15. geoTransformContentToNonXY.m

function [ content ] = geoTransformContentToNonXY( contentXY, geo, geoXY )

contentXYCoordinatesCount = size(contentXY,3);

rowCount = size(geo.cells,1);

content = zeros(rowCount, contentXYCoordinatesCount);

for ii=1:rowCount

cellRectAndRatios = geoXY.cellsRectTargetAndRatio{ii};

contentCoords = 1:contentXYCoordinatesCount;

cellContent = zeros(1,1,contentXYCoordinatesCount);

for jj=1:length(cellRectAndRatios)

x = cellRectAndRatios{jj}.rect(1)+1;

y = cellRectAndRatios{jj}.rect(2)+1;

cellContent = cellContent + contentXY(x,y,contentCoords)*cellRectAndRatios{jj}.

ratioIntersectionTri;

end

content(ii,:) = reshape(cellContent, 1,contentXYCoordinatesCount,1);

end

end

F.2.16. geoTransformContentToXY.m

function [ contentXY ] = geoTransformContentToXY( content, geo, geoXY )

contentCoordinatesCount = size(content,2);

contentXY = zeros(geoXY.gridBounds.maxX + 1, geoXY.gridBounds.maxY + 1, contentCoordinatesCount);

rowCount = size(content, 1);

for ii=1:rowCount

cellRectAndRatios = geoXY.cellsRectTargetAndRatio{ii};

contentCoords = 1:contentCoordinatesCount;

cellContent = reshape(content(ii, contentCoords), 1,1,contentCoordinatesCount);

for jj=1:length(cellRectAndRatios)

x = cellRectAndRatios{jj}.rect(1)+1;

y = cellRectAndRatios{jj}.rect(2)+1;

contentXY(x,y,contentCoords) = contentXY(x,y,contentCoords) + cellRectAndRatios{jj}.

ratioIntersectionRect * cellContent;

end

end

end

F.2.17. geoTransformMeshToXYGrid.m

function [ geoXY ] = geoTransformMeshToXYGrid( geo, xyStep)

minBounds = min(geo.coordinates);

maxBounds = max(geo.coordinates);

bounds.minX = minBounds(1);

bounds.minY = minBounds(2);

bounds.maxX = maxBounds(1);

bounds.maxY = maxBounds(2);

gridBounds.minX = 0;

gridBounds.maxX = floor((bounds.maxX - bounds.minX)/xyStep);

if ~mod(bounds.maxX - bounds.minX, xyStep)

gridBounds.maxX = gridBounds.maxX - 1;

end



gridBounds.minY = 0;

gridBounds.maxY = floor((bounds.maxY - bounds.minY)/xyStep);

if ~mod(bounds.maxY - bounds.minY, xyStep)

gridBounds.maxY = gridBounds.maxY - 1;

end

if ~mod(bounds.maxX-bounds.minX,xyStep)

maxXValue = bounds.maxX - xyStep;

else

maxXValue = bounds.maxX;

end

if ~mod(bounds.maxY-bounds.minY,xyStep)

maxYValue = bounds.maxY - xyStep;

else

maxYValue = bounds.maxY;

end

gridValues.x = bounds.minX:xyStep:maxXValue;

gridValues.y = bounds.minY:xyStep:maxYValue;

cellsCount = size(geo.cells, 1);

rectArea = xyStep*xyStep;

cells = geo.cells;

xyCoordinates = geo.coordinates(:,1:2);

cellsRectTargetAndRatio = cell(cellsCount, 1);

parfor ii = 1:cellsCount

currentCell = cells(ii,:);

xyTriangle = xyCoordinates(currentCell(1:3),:);

triArea = polygonArea(xyTriangle);

boundingRects = geoGetBoundingRectsForDelta(xyTriangle, xyStep, bounds, gridBounds);

rectsCount = size(boundingRects, 1);

cellRectAndRatio = {};

iiCellRectAndRatio = 0;

for jj=1:rectsCount

rect = boundingRects(jj,:);

intersectionArea = geoComputeIntersectionArea(xyTriangle, rect, xyStep, bounds);

if intersectionArea > 0

iiCellRectAndRatio = iiCellRectAndRatio +1;

cellRectAndRatio{iiCellRectAndRatio}.rect = rect;

cellRectAndRatio{iiCellRectAndRatio}.ratioIntersectionRect = intersectionArea/rectArea;

cellRectAndRatio{iiCellRectAndRatio}.ratioIntersectionTri = intersectionArea/triArea;

end

end

cellsRectTargetAndRatio{ii} = cellRectAndRatio;

end

geoXY.gridValues = gridValues;

geoXY.gridBounds = gridBounds;

geoXY.bounds = bounds;

geoXY.step = xyStep;

geoXY.cellsRectTargetAndRatio = cellsRectTargetAndRatio;

end

F.2.18. polygonArea.m

function area = polygonArea(polygon)

%assumes clockwise orientation

%reference: http://alienryderflex.com/polygon_area/

area = 0;

points = size(polygon, 1);

jj = points;

for ii = 1:points

area = area + (polygon(jj, 1) + polygon(ii, 1))*(polygon(jj,2)-polygon(ii,2));

jj = ii;

end

area = area * 0.5;

%do not take care on clockwise or counterclockwise polygons, just take positive areas.

area = abs(area);

end



F.2.19. polygonClip.m

function clippedPolygon = polygonClip(subjectPolygon,clipPolygon)

%reference: http://rosettacode.org/wiki/Sutherland-Hodgman_polygon_clipping#MATLAB

% % Helper Functions

%computerIntersection() assumes the two lines intersect

function intersection = computeIntersection(line1,line2)

%this is an implementation of

%http://en.wikipedia.org/wiki/Line-line_intersection

intersection = zeros(1,2);

detL1 = det(line1);

detL2 = det(line2);

detL1x = det([line1(:,1),[1;1]]);

detL1y = det([line1(:,2),[1;1]]);

detL2x = det([line2(:,1),[1;1]]);

detL2y = det([line2(:,2),[1;1]]);

denominator = det([detL1x detL1y;detL2x detL2y]);

intersection(1) = det([detL1 detL1x;detL2 detL2x]) / denominator;

intersection(2) = det([detL1 detL1y;detL2 detL2y]) / denominator;

end %computeIntersection

%inside() assumes the boundary is oriented counter-clockwise

function in = inside(point,boundary)

pointPositionVector = [diff([point;boundary(1,:)]) 0];

boundaryVector = [diff(boundary) 0];

crossVector = cross(pointPositionVector,boundaryVector);

if ( crossVector(3) <= 0 )

in = true;

else

in = false;

end

end %inside

% % Sutherland-Hodgman Algorithm

clippedPolygon = subjectPolygon;

numVerticies = size(clipPolygon,1);

clipVertexPrevious = clipPolygon(end,:);

for clipVertex = (1:numVerticies)

if ~isempty(clippedPolygon)

clipBoundary = [clipPolygon(clipVertex,:) ; clipVertexPrevious];

inputList = clippedPolygon;

clippedPolygon = [];

previousVertex = inputList(end,:);

for subjectVertex = (1:size(inputList,1))

if ( inside(inputList(subjectVertex,:),clipBoundary) )

if( not(inside(previousVertex,clipBoundary)) )

subjectLineSegment = [previousVertex;inputList(subjectVertex,:)];

clippedPolygon(end+1,1:2) = computeIntersection(clipBoundary,subjectLineSegment);

end

clippedPolygon(end+1,1:2) = inputList(subjectVertex,:);



elseif( inside(previousVertex,clipBoundary) )

subjectLineSegment = [previousVertex;inputList(subjectVertex,:)];

clippedPolygon(end+1,1:2) = computeIntersection(clipBoundary,subjectLineSegment);

end

previousVertex = inputList(subjectVertex,:);

clipVertexPrevious = clipPolygon(clipVertex,:);

end %for subject verticies

end %if not empty

end %for boundary verticies

end %sutherlandHodgman algorithm

F.3. Calculo de Energıa Cinetica y RMS de las Fluctuaciones

F.3.1. plotEnergy.m

if ~exist(’results’, ’var’)

processEnergy;

end

result = results{1};

settings.noActuationMean.start = 1;

settings.noActuationMean.end = 50;

settings.actuationMean.start = 409;

settings.actuationMean.end = 891;

amountOfMarkersInPlot = 0;

timeStepRange = [1 5000];

stepsQty = length(result.energy);

plotSteps = timeStepRange(1):timeStepRange(2);

markerSteps = 1:floor(max(timeStepRange)/amountOfMarkersInPlot):max(timeStepRange);

noActuationMean = mean(result.energy(settings.noActuationMean.start:settings.noActuationMean.end));

actuationMean = mean(result.energy(settings.actuationMean.start:settings.actuationMean.end));

currentFigure = figure;

handleKinetic = plot(NaN,NaN,’k-’,plotSteps, spline(result.steps,result.energy, plotSteps), ’k-’,

markerSteps, spline(result.steps,result.energy, markerSteps),’ko’,’LineWidth’, 2, ’MarkerFaceColor’, ’

k’, ’MarkerSize’, 5);

hold on;

handleMeanNoAct = plot(result.steps,repmat(noActuationMean, stepsQty,1),’r-.’, ’LineWidth’, 2);

handleMeanAct = plot(result.steps,repmat(actuationMean, stepsQty,1),’b--’, ’LineWidth’, 2);

%grid on;

legend([handleKinetic(1), handleMeanNoAct, handleMeanAct], {’Instantaneous’, ’Mean (Non-actuated)’, ’Mean (

Actuated)’})

xlabel(’Time Step Number’, ’FontSize’, 22);

ylabel(’Energy of Fluctuations’, ’FontSize’, 22);

currentAxes = get(currentFigure,’CurrentAxes’);

currentAxis = axis;

axis(currentAxes, [timeStepRange currentAxis(3:4)]);

set(currentAxes,’FontSize’,18);

title(’Kinetic energy of fluctuations per unit area - Transition from non-actuated to actuated’);

F.3.2. processEnergy.m

resultsFilepath = ’ScenarioResults.mat’;

if exist(resultsFilepath, ’file’)

load(resultsFilepath);

else

xyStep = 0.045;

%cacheFolder = ’/Users/invitado/tmp/cache’;



cacheFolder = ’/media/Datos/Pablo/Workspace/tmp/cache/0.045’;

% Actuation p90 - g4 - From step 1 to 50 (noAct) and 51 to 900 (act)

settings.name = ’p90_rate1_g4_q1.4_including_noactuation’;

%settings.folder = ’/Users/invitado/tmp/TESIS_RESULTS/16_KEGERISE_LAGRANGE_p90_g4_1.4_1.4_1.4_1.4/CHR.

ENSIGHT.01031126’;

settings.folder = ’/media/Datos/Pablo/Workspace/Saturne/TESIS_RESULTS/16_KEGERISE_LAGRANGE_p90_g4_1.4_1

.4_1.4_1.4_7000steps/CHR.ENSIGHT.03262049’;

settings.filerangeFilter.min = 1;

settings.filerangeFilter.max = Inf;

settings.clipArea.x1 = -5;

settings.clipArea.y1 = -5;

settings.clipArea.x2 = 20;

settings.clipArea.y2 = 5;

ntchr = 10;

integrationArea = struct(’x1’, -5, ’y1’, -5, ’x2’, 20, ’y2’, 5);

settings.filenamesFilter = ’chr.velocity*’;

settings.geoFilename = ’chr.geo’;

settings.outputFolder = ’Out’;

settings.isVector = true;

outputFilename = ’chr.velocityaverage’;





geoCacheFilename = sprintf(’geo.cache.xyStep. %.3f.mat’, xyStep);

if exist(geoCacheFilename, ’file’)

fprintf(’Loading geo files from cache ( %s)\n’, geoCacheFilename);

result = load(geoCacheFilename);

geo = result.geo;

geoXY = result.geoXY;

clear result;

else

fprintf(’Computing geo data\n’);


fprintf(’Computing geoXY data\n’);

tic;

geoXY = geoTransformMeshToXYGrid(geo, xyStep);

toc;

fprintf(’Saving geo files to cache ( %s)\n’, geoCacheFilename);

save(geoCacheFilename, ’geo’, ’geoXY’);

end

if any( strcmp(fieldnames(settings), ’clipArea’ ))

clipAreaFlag = sprintf(’.clipped. %.1f. %.1f. %.1f. %.1f’, settings.clipArea.x1, settings.clipArea.y1,

settings.clipArea.x2, settings.clipArea.y2);

else

clipAreaFlag = ’’;

end

velocityXYCacheFilename = sprintf(’ %s/binaries.cache.xy. %s %s.mat’, cacheFolder, settings.name,

clipAreaFlag);

if exist(velocityXYCacheFilename, ’file’)

fprintf(’Loading velocityXY from cache ( %s)\n’, velocityXYCacheFilename);

result = load(velocityXYCacheFilename);

velocityXY = result.velocityXY;

clear result;

else

fprintf(’Cache ’’ %s’’ not found. Computing velocity data\n’, velocityXYCacheFilename);

tic;

velocityXY = chrReadVelocity2D(filepaths, geo, geoXY, settings.clipArea);

toc;

fprintf(’Saving velocityXY to cache ( %s)\n’, velocityXYCacheFilename);

save(velocityXYCacheFilename, ’velocityXY’);

end



[xIntegration, yIntegration] = selectIntegrationCoordinates(geoXY, settings.clipArea, integrationArea);

sizeVelocity = [1 1 size(velocityXY.u, 3)];

kineticEnergyPerturb = 0.5 * ((velocityXY.u(xIntegration, yIntegration,:)-repmat(mean(velocityXY.u(

xIntegration, yIntegration,:),3), sizeVelocity)).^2+ ...

(velocityXY.v(xIntegration, yIntegration,:)-repmat(mean(velocityXY.v(

xIntegration, yIntegration,:),3), sizeVelocity)).^2);

clear velocityXY;

kineticEnergyPerturbInt = sum(sum(kineticEnergyPerturb, 1), 2);

stepsQty = size(kineticEnergyPerturbInt, 3);

steps = 1:ntchr:stepsQty*ntchr;

integrationSurface = (integrationArea.x2-integrationArea.x1) * (integrationArea.y2-integrationArea.y1)/

xyStep^2;

kineticEnergyPerturbIntNormalized = reshape(kineticEnergyPerturbInt, stepsQty, 1)/integrationSurface;

result = struct();

result.ntchr = ntchr;

result.energy = kineticEnergyPerturbIntNormalized;

result.steps = steps;

save(resultsFilepath, ’results’);

end

F.3.3. processRmsCriteria.m

PLOT = true;

xyStep = 0.045;

%cacheFolder = ’/Users/invitado/tmp/cache’;

cacheFolder = ’/media/Datos/Pablo/Workspace/tmp/cache’;

% No Actuation - From step 1000 to step 11100

settings.name = ’noactuation’;

%settings.folder = ’/Users/invitado/tmp/TESIS_RESULTS/11_NO_ACTUATION_R235/CHR.ENSIGHT.01251100’;

settings.folder = ’/media/Datos/Pablo/Workspace/Saturne/TESIS_RESULTS/11_NO_ACTUATION_R235/CHR.ENSIGHT

.01251100’;

settings.filerangeFilter.min = 50;

settings.filerangeFilter.max = 250;

settings.minXToSeekForPeak = 0.5;

settings.minYToSeekForPeak = 0;

settings.filenamesFilter = ’chr.velocity*’;

settings.geoFilename = ’chr.geo’;

settings.outputFolder = ’Out’;

settings.isVector = true;

outputFilename = ’chr.velocityaverage’;





geoCacheFilename = sprintf(’geo.cache.xyStep. %.3f.mat’, xyStep);

if exist(geoCacheFilename, ’file’)

fprintf(’Loading geo files from cache ( %s)\n’, geoCacheFilename);

%result = load(geoCacheFilename);

%geo = result.geo;

%geoXY = result.geoXY;

%clear result;

else

fprintf(’Computing geo data\n’);


fprintf(’Computing geoXY data\n’);

tic;

geoXY = geoTransformMeshToXYGrid(geo, xyStep);

toc;

fprintf(’Saving geo files to cache ( %s)\n’, geoCacheFilename);



save(geoCacheFilename, ’geo’, ’geoXY’);

end

velocityXYCacheFilename = sprintf(’ %s/binaries.cache.xy. %s.mat’, cacheFolder, settings.name);

if exist(velocityXYCacheFilename, ’file’)

fprintf(’Loading velocityXY from cache ( %s)\n’, velocityXYCacheFilename);

result = load(velocityXYCacheFilename);

velocityXY = result.velocityXY;

clear result;

else

fprintf(’Computing velocity data\n’);

tic;

velocityXY = chrReadVelocity2D(filepaths, geo, geoXY);

toc;

fprintf(’Saving velocityXY to cache ( %s)\n’, velocityXYCacheFilename);

save(velocityXYCacheFilename, ’velocityXY’);

end

if PLOT

%magnitude = sqrt(sum(binariesXY{1}.^2, 3));

reynoldsVel = computeReynoldsTensor(velocityXY.u);

varVel = std(velocityXY.u, 0, 3).^2;

rmsVel = computeRMS(velocityXY.u);

meanVel = mean(velocityXY.u,3);

figure;

subplot(121);

pcolor(x,y,reynoldsVel’);

hold on;

axis equal;

xlim([geoXY.bounds.minX geoXY.bounds.maxX]);

ylim([geoXY.bounds.minY geoXY.bounds.maxY]);

shading interp;

colorbar;

title(sprintf(’Reynolds Long. Tensor over %s Dataset’, settings.name));

subplot(122);

pcolor(x,y,varVel’);

hold on;

axis equal;



shading interp;

colorbar;

title(sprintf(’Variance over %s Dataset’, settings.name));

figure;

subplot(121);

pcolor(x,y,rmsVel’);

hold on;

axis equal;



shading interp;

colorbar;

title(sprintf(’Root Mean Square over %s Dataset’, settings.name));

subplot(122);

pcolor(x,y,meanVel’);

hold on;

axis equal;



shading interp;

colorbar;

title(sprintf(’Mean over %s Dataset’, settings.name));

end



F.3.4. computeReynoldsTensor.m

function [ UxUx ] = computeReynoldsTensor( velocityXY )

% compute <u’x u’x> or <u’y u’y> (use u for <u’x u’x> and v for <u’y u’y>)

% compute <u’x u’x> = <uxux> - <ux><ux> (cell to cell operations)

% notation: U means u’. u means u.

% then: <UxUx> = <uxux> - <ux>.*<ux>

uxux = mean(velocityXY.^2, 3);

ux = mean(velocityXY, 3);

UxUx = uxux - ux.*ux;

end

F.3.5. computeRMS.m

function [ rms ] = computeRMS( velocityXY )

rms = sqrt(mean(velocityXY.^2, 3));

end

F.3.6. selectIntegrationCoordinates.m

function [xIntegration, yIntegration] = selectIntegrationCoordinates(geoXY, clipArea, integrationArea)

xValues = geoXY.gridValues.x(find(geoXY.gridValues.x >= clipArea.x1 & geoXY.gridValues.x <= clipArea.x2

));

yValues = geoXY.gridValues.y(find(geoXY.gridValues.y >= clipArea.y1 & geoXY.gridValues.y <= clipArea.y2

));

xIntegration = find(xValues >= integrationArea.x1 & xValues <= integrationArea.x2);

yIntegration = find(yValues >= integrationArea.y1 & yValues <= integrationArea.y2);

end

F.4. Simulacion en Code Saturne

F.4.1. usini1.f90

!-------------------------------------------------------------------------------

! Code_Saturne version 2.0.2

! --------------------------

! This file is part of the Code_Saturne Kernel, element of the

! Code_Saturne CFD tool.

! Copyright (C) 1998-2009 EDF S.A., France

! contact: [email protected]

! The Code_Saturne Kernel is free software; you can redistribute it

! and/or modify it under the terms of the GNU General Public License

! as published by the Free Software Foundation; either version 2 of

! the License, or (at your option) any later version.

! The Code_Saturne Kernel is distributed in the hope that it will be

! useful, but WITHOUT ANY WARRANTY; without even the implied warranty

! of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

! GNU General Public License for more details.

! You should have received a copy of the GNU General Public License

! along with the Code_Saturne Kernel; if not, write to the

! Free Software Foundation, Inc.,

! 51 Franklin St, Fifth Floor,

! Boston, MA 02110-1301 USA

!-------------------------------------------------------------------------------

! Purpose:

! -------



! User subroutines for input of calculation parameters (Fortran commons).

! These subroutines are called in all cases.

! If the Code_Saturne GUI is used, this file is not required (but may be

! used to override parameters entered through the GUI, and to set

! parameters not accessible through the GUI).

! Several routines are present in the file, each destined to defined

! specific parameters.

! To modify the default value of parameters which do not appear in the

! examples provided, code should be placed as follows:

! - usipsu for numerical and physical options

! - usipes for input-output related options

! As a convention, "specific physics" defers to the following modules only:

! pulverized coal, gas combustion, electric arcs.

!===============================================================================

subroutine usipph &

!================

( nphmax, nphas , iihmpu, nfecra , iturb , icp , iverif )

!===============================================================================

! Purpose:

! --------

! User subroutine for input of parameters depending on the number of phases.

!-------------------------------------------------------------------------------

! Arguments

!__________________.____._____.________________________________________________.

! name !type!mode ! role !

!__________________!____!_____!________________________________________________!

! nphmax ! i ! <-- ! maximum number of phases !

! nphas ! i ! <-- ! number of active phases !

! iihmpu ! i ! <-- ! indicates if the XML file from the GUI is !

! ! ! ! used (1: yes, 0: no) !

! nfecra ! i ! <-- ! Fortran unit number for standard output !

! iturb(nphmax) ! ia ! <-> ! turbulence model !

! icp(nphmax) ! ia ! <-> ! flag for uniform Cp or not !

! iverif ! i ! <-- ! flag for elementary tests !

!__________________!____!_____!________________________________________________!

! Type: i (integer), r (real), s (string), a (array), l (logical),

! and composite types (ex: ra real array)

! mode: <-- input, --> output, <-> modifies data, --- work array

!===============================================================================

implicit none

! Arguments

integer nphmax, nphas, iihmpu, nfecra

integer iturb(nphmax), icp(nphmax)

integer iverif

! Local variables

integer iphas

!===============================================================================

! --- Turbulence (for each phase)

! 0...Laminar

! 10...Mixing length

! 20...k-epsilon

! 21...k-epsilon (linear production)

! 30...Rij-epsilon, (standard LRR)

! 31...Rij-epsilon (SSG)

! 40...LES (Smagorinsky)

! 41...LES (Dynamic)

! 42...LES (WALE)

! 50...v2f (phi-model)

! 60...k-omega SST

! For 10, contact the development team before use

iphas = 1

iturb(iphas) = 0

! --- Variable specific heat (ICP=1) or not (ICP=0)

! for each phase IPHAS

! For these specific physics, ICP MUST NOT BE MODIFIED here, and the

! following options are forced:

! coal and combustion: constant CP constant;



! electric arcs: variable CP.

! Caution: complete usphyv with the law defining Cp

! ========= if and only if variable Cp has been selected here

! (with icp(iphas)=1)

iphas = 1

icp(iphas) = 0

return

end subroutine

!===============================================================================

subroutine usinsc &

!================

( iihmpu, nfecra , nscaus , iverif )

!===============================================================================

! Purpose:

! ------

! User subroutine for input of the number of user scalars.

!-------------------------------------------------------------------------------

! Arguments

!__________________.____._____.________________________________________________.


!__________________!____!_____!________________________________________________!


! ! ! ! used (1: yes, 0: no) !


! nscaus ! i ! <-> ! number of user scalars !


!__________________!____!_____!________________________________________________!




!===============================================================================

implicit none

! Arguments

integer iihmpu, nfecra

integer nscaus

integer iverif

! Local variables

!===============================================================================

! --- Number of USER scalars (thermal or not, and whatever their carrier phase).

! These scalars come in addition to the following "basic" scalars

! (which are naturally included in the model):

! - pressure

! - turbulent variables

! - nscapp scalars introduced by an active combustion, coal,

! or electric arc module.

! Thus, for a calculation with no specific physics, the user scalars

! may for example be:

! - temperature or enthalpy,

! - mass fractions of transported scalars

! - the variance of another user scalar

! The maximum number of scalars is defined by ’nscamx’ in paramx.h;

! it is the maximum admissible value for: nscaus + nscapp.

! Set nscaus = 0 if there is no user scalar.

nscaus = 1

return

end subroutine

!===============================================================================

subroutine usipsc &

!================

( nscmax, nscaus, iihmpu, nfecra, iscavr, ivisls , iverif )

!===============================================================================

! Purpose:

! -------

! User subroutine for the input of parameters depending on the

! number of user scalars.



!-------------------------------------------------------------------------------

! Arguments

!__________________.____._____.________________________________________________.


!__________________!____!_____!________________________________________________!

! nscmax ! i ! <-- ! maximum number of scalars !

! nscaus ! i ! <-- ! number of user scalars !


! ! ! ! used (1: yes, 0: no) !


! iscavr(nscmax) ! ia ! <-- ! associated scalar number for variance scalars !

! ivisls(nscmax) ! ia ! <-> ! uniform scalar diffusivity flag !


!__________________!____!_____!________________________________________________!




!===============================================================================

implicit none

! Arguments

integer nscmax, nscaus, iihmpu, nfecra

integer iscavr(nscmax), ivisls(nscmax)

integer iverif

! Local variables

integer iutile, iscal

!===============================================================================

! --- Variance of a USER scalar:

! If we wish a user scalar j to represent the variance of a

! user scalar k, we set

! iscavr(j) = k.

! The values taken by iscavr are thus naturally greater or equal to 1

! and less than or equal to the total number of scalars.

! So, if we set iscavr(j) = k, we must have

! 0 < j < nscaus+1, 0< k < nscaus+1 and j different from k.

! For example for user scalar 3 to be the variance of user scalar 3,

! we set:

! iscavr(3) = 2

! with nscaus at least equal to 3.

! Do not intervene if you do not wish to explicitly include the

! variance of a user scalar in the simulation.

! For non-user scalars relative to specific physics (coal, combustion,

! electric arcs: see usppmo) implicitly defined in the model,

! the corresponding information is given automatically, and

! iscavr should not be modified.

! --- Variable diffusivity (ivisls=1) or constant diffusivity (ivisls=0) for

! each USER scalar, EXCEPT those which represent the variance

! of another.

! For user scalars iscal which represent the variance of another user

! scalar, we do not set ivisls(iscal) here.

! This is the purpose of the test on iscavr(ISCAL) in the example below.

! Indeed, the diffusivity of the variance of a scalar is assumed to

! have the same behavior as the diffusivity of this scalar.



! the corresponding information is given automatically, and

! ivisls should not be modified here.

! Caution: complete usphyv with the law defining the diffusivity

! ========= if and only if ivisls = 1 has been set here.

do iscal = 1, nscaus

! For user scalars which do not represent the variance of another scalar

if (iscavr(iscal).le.0) then

ivisls(iscal) = 0

endif

enddo

return

end subroutine

!===============================================================================

subroutine usipgl &



!================

( nphmax, nesmax, &

iespre, iesder, iescor, iestot, &

nphas , iihmpu, nfecra, &

idtvar, ipucou, iphydr, ialgce , iescal , iverif )

!===============================================================================

! Purpose:

! -------

! User subroutine for the setting of global parameters.

!-------------------------------------------------------------------------------

! Arguments

!__________________.____._____.________________________________________________.


!__________________!____!_____!________________________________________________!

! nphmax ! i ! <-- ! maximum number of phases !

! nesmax ! i ! <-- ! maximum number of error estimators per phase !

! iespre ! i ! <-- ! number of the prediction error estimator !

! iesder ! i ! <-- ! number of the derivative error estimator !

! iescor ! i ! <-- ! number of the correction error estimator !

! iestot ! i ! <-- ! number of the total error estimator !

! nphas ! i ! <-- ! number of active phases !


! ! ! ! used (1: yes, 0: no) !


! idtvar ! i ! --> ! variable time step flag !

! ipucou ! i ! --> ! reinforced u-p coupling flag !

! iphydr ! i ! --> ! flag for handling of the equilibrium between !

! ! ! ! the pressure gradient and the gravity and !

! ! ! ! head-loss terms !

! ialgce ! i ! <-- ! option for the method of calculation of !

! ! ! ! cell centers !

! iescal ! ia ! <-- ! flag for activation of error estimators for !

! (nesmax,nphmax) ! ! ! Navier-Stokes !


!__________________!____!_____!________________________________________________!




!===============================================================================

implicit none

! Arguments

integer nphmax, nesmax

integer iespre, iesder, iescor, iestot

integer nphas , iihmpu, nfecra

integer idtvar, ipucou, iphydr

integer iescal(nesmax,nphmax)

integer iverif

! Local variables

integer iphas, ialgce

!===============================================================================

! --- Time step (0 : uniform and constant

! 1 : variable in time, uniform in space

! 2 : variable in time and space

! -1 : steady algorithm)

idtvar = 0

! --- Velocity/pressure coupling (0 : classical algorithm,

! 1 : transient coupling)

! Only in single-phase

ipucou = 0

! --- Handling of hydrostatic pressure

! (0 : usual algorithm

! 1 : specific handling)

! Only in single-phase

iphydr = 0



! --- Estimators for Navier-Stokes (non-frozen velocity field)

! We recommend running a calculation restart on a few time steps

! with the activation of the most interesting of those.

! (=2 to activate, =0 to deactivate).

iphas = 1

iescal(iescor,iphas) = 0

iescal(iestot,iphas) = 0

return

end subroutine

!===============================================================================

subroutine usipsu &

!================

( nmodpp , iverif )

!===============================================================================

! Purpose:

! -------

! User subroutine for the input of additional user parameters.

!-------------------------------------------------------------------------------

! Arguments

!__________________.____._____.________________________________________________.


!__________________!____!_____!________________________________________________!

! nmodpp ! i ! <-- ! number of active specific physics models !


!__________________!____!_____!________________________________________________!




!===============================================================================

implicit none

include "paramx.h"

include "cstnum.h"

include "dimens.h"

include "numvar.h"

include "optcal.h"

include "cstphy.h"

include "entsor.h"

include "vector.h"

include "parall.h"

include "period.h"

include "ihmpre.h"

include "ppppar.h"

include "ppthch.h"

include "ppincl.h"

include "coincl.h"

include "cpincl.h"

include "elincl.h"

!===============================================================================

! Arguments

integer nmodpp

integer iverif

! Local variables

integer iphas, iutile, ii, jj, imom

!===============================================================================

!===============================================================================

! This subroutine allows setting parameters

! which do not already appear in the other subroutines of this file.

! It is possible to add or remove parameters.

! The number of physical properties and variables is known here.

!===============================================================================

! Calculation options (optcal.h)

! ==============================

! --- Calculation restart: isuite (= 1) or not (0)

! In case of restart, read auxiliary restart file ileaux (= 1) or not (0).

isuite = 1

ileaux = 1



! --- Reference time step

! The example given below is probably not adapted to your case.

! the dt variable should complain with the {{CourantFriedrichsLewy (CFL) condition in order to avoid

divergency.

! u*dt/dx <= C

! being C an dimensionless constant depending on the solver algorithm.

!

! the condition can be also written as

! dt/(dx^2*re) <= C2

dtref = 0.061d0

! --- Duration

! ntmabs = absolute number of the last time step required

! if we have already run 10 time steps and want to

! run 10 more, ntmabs must be set to 10 + 10 = 20

! ntmabs = total_time / dtref

ntmabs = 16000

iphas = 1

iscalt(iphas) = -1

! --- Calculation (restart) with frozen velocity field (1 yes, 0 no)

iccvfg = 0

! --- Vortex method for inlet conditions in L.E.S.

! (0: not activated, 1: activated)

! The vortex method only regards the L.E.S. models

! and is only valid with one phase.

! To use the vortex method, edit the ’usvort.f90’ user file.

! --- Convective scheme

! blencv = 0 for upwind (order 1 in space, "stable but diffusive")

! = 1 for centered/second order (order 2 in space)

! we may use intermediate real values.

! Here we choose:

! for the velocity of phase 1 and user scalars:

! an upwind-centered scheme with 100 % centering (blencv=1)

! for other variables

! the default code value (upwind standard, centered in LES)

! Specifically, for user scalars

! if we suspect an excessive level of numerical diffusion on

! a variable ivar representing a user scalar

! iscal (with ivar=isca(iscal)), it may be useful to set

! blencv(ivar) = 1.0d0 to use a second-order scheme in space for

! convection. For temperature or enthalpy in particular, we

! may thus choose in this case:

! blencv(isca(iscalt(iphas))) = 1.0d0


! electric arcs: see usppmo) implicitly defined by the model,

! the corresponding information is set automatically elsewhere:

! we do not modify blencv here.

iphas = 1

blencv(iu(iphas)) = 1.0d0

blencv(iv(iphas)) = 1.0d0

blencv(iw(iphas)) = 1.0d0

if (nscaus.ge.1) then

do ii = 1, nscaus

! first order diffusivity : blencv(isca(ii)) = 0.0d0

! second order diffusivity : blencv(isca(ii)) = 1.0d0

blencv(isca(ii)) = 0.0d0

idiff(isca(ii)) = 0.0d0

enddo

endif

! --- Linear solver parameters (for each unknown)

! iresol = -1: default



! iresol = 1000*ipol +j: ipol is the degree of the Neumann polynomial

! used for preconditioning,

! j = 0: conjugate gradient,

! j = 1: Jacobi

! j = 2: bi-CgStab

! nitmax: maximum number of iterations for each unknown ivar

! epsilo: relative precision for the solution of the linear system.

! --- Algebraic multigrid parameters

! imgr = 0: no multigrid

! imgr = 1: algebraic multigrid

! Only available for pressure and purely diffusive variables.

imgr = 0

!=========================================================================

! Physical constants (cstphy.h)

! =============================

! --- gravity (g in m/s2, with the sign in the calculation coordinate axes).

gx = 0.d0

gy = 0.d0

gz = 0.d0

! --- Reference fluid properties (for each phase)

! ro0 : density in kg/m3

! viscl0 : dynamic viscosity in kg/(m s)

! cp0 : specific heat in J/(degres kg)

! t0 : reference temperature in Kelvin

! p0 : total reference pressure in Pascal

! the calculation is based on a

! reduced pressure P*=Ptot-ro0*g.(x-xref)

! (except in compressible case)

! xyzp0(3,.) : coordinates of the reference point for

! the total pressure (where it is equal to p0)

! In general, it is not necessary to furnish a reference point xyz0.

! If there are outlets, the code will take the center of the

! reference outlet face.

! On the other hand, if we plan to explicitly fix Dirichlet conditions

! for pressure, it is better to indicate to which reference the

! values relate (for a better resolution of reduced pressure).

! Other properties are given by default in all cases.

! Nonetheless, we may note that:

! In the standard case (no gas combustion, coal, electric arcs,

! compressibility):

! ---------------------

! ro0, viscl0 and cp0

! are useful and represent either the fluid properties if they

! are constant, either simple mean values for the initialization

! if properties are variable and defined in usphyv.

! t0 is not useful

! p0 is useful but is not used in an equation of state. p0

! is a reference value for the incompressible solver

! which will serve to set the (possible) domain outlet pressure.

! We may also take it as 0 or as a physical value in Pascals.

! With compressibility:

! ---------------------

! ro0 is not useful, stricto sensu; nonetheless, as experience

! shows that users often use this variable, it is required

! to assign to it a strictly positive value (for example,

! an initial value).

! viscl0 is useful and represents the molecular dynamic viscosity,



! when it is constant, or a value which will be used during

! initializations (or in inlet turbulence conditions,

! depending on the user choice.

! cp0 is indispensable: it is the heat capacity, assumed constant

! in the thermodynamics available by default

! t0 is indispensable and must be in Kelvin (> 0).

! p0 is indispensable and must be in Pascal (> 0).

! With the thermodynamic law available by default,

! t0 and p0 are used for the initialization of the density.

! xyzp0 is not useful because the pressure variable directly

! represents the total pressure.

iphas = 1

ro0(iphas) = 1.d0 !calculo adimensional

viscl0(iphas) = 1.d0/235.D0 !1/Reynolds

cp0(iphas) = 1.d0

t0(iphas) = 1.d0

p0(iphas) = 0.d0

! We only specify XYZ0 if we explicitely fix Dirichlet conditions

! for the pressure.

! xyzp0(1,iphas) = 0.d0



! --- irovar, ivivar: density and viscosity constant or not ?

! When a specific physics module is active

! (coal, combustion, electric arcs, compressible: see usppmo)

! we DO NOT set variables ’irovar’ and ’ivivar’ here, as

! they are defined automatically.

! Nonetheless, for the compressible case, ivivar may be modified

! in the uscfx1 user subroutine.

! When no specific physics module is active, it is necessary to

! specify is the density and the molecular viscosity

! are constant (irovar=0, ivivar=0)

! or variable (irovar=1, ivivar=1)

! if they are variable, the law must be defined in usphyv;

! if they are constant, they take values ro0 and viscl0.

! as an example, we assume below that they are constant.

iphas = 1

irovar(iphas) = 0

ivivar(iphas) = 0

! --- Reference diffusivity visls0 in kg/(m s) for each

! USER scalar except those which represent the variance of another.



! the information is given automatically elsewhere:

! we do not modify visls0 here.

! For user scalars JJ which represent the variance of another user

! scalar, we do not define visls0(jj) here.

! This is the purpose of the test on iscavr(jj) in the example below.

! Indeed the diffusivity of the variance of a scalar is assumed

! identical to that scalar’s diffusivity.

! When no specific physics has been activated

! (coal, combustion, electric arcs) and if a user scalar represents

! the temperature or enthalpy:

! visls0(iscalt(iphas)) = Lambda/Cp



! Here, as an example, we assign to viscl0 the viscosity of the

! carrier phase, which is fitting for passive tracers which

! follow the fluid.

if (nscaus.gt.0) then

! We loop on user scalars:

do jj = 1, nscaus

! For scalars which are not variances

if (iscavr(jj).le.0) then

! We define the diffusivity

visls0(jj) = viscl0(iphsca(jj))

endif

enddo

endif

! --- Reference velocity for turbulence initialization (m2/s)

! (useful only with turbulence)

iphas = 1

uref(iphas) = 1.d0

! --- Definition of moments

! (at the most nbmomx moments, correlations of maximum order ndgmox)

! We calculate temporal means of the type <f1*f2*f3*...*fn>

! The fi’s are cell-defined variables (arrays rtp and propce).

! idfmom(i,imom) ientifies the variable fi of moment imom

! if idfmom > 0 it is a resolved variable (rtp)

! if idfmom < 0 it is an auxiliary variable (propce)

! imoold(imom) defined in the case of a restart the number, in the

! previous calculation, of the moment to use to initialize moment

! imom of the new calculation (by default imoold(imom)=imom).

! Value -1 indicates the we must reinitialize moment imom.

! ntdmom(imom) defined the time step at which the moment calculation

! is started.

! We give below the example of the calculation of moments <u> and <rho u v>

! the moment <u> is reread in the restart file if we are restarting,

! the moment <rho u v> is reinitialized to zero.

! Moment <u> is calculated starting from time step 1000

! Moment <rho u v> is calculated from time step 10000.

! The test on iutile allows deactivation of the instructions

! (which are only given as an example).

iutile = 0

if (iutile.eq.1) then

! First moment: <u>

imom = 1

iphas = 1

idfmom(1,imom) = iu(iphas)

ntdmom(imom) = 1000

! Second moment: <rho u v>

imom = 2

iphas = 1

idfmom(1,imom) = -irom(iphas)

idfmom(2,imom) = iu(iphas)

idfmom(3,imom) = iv(iphas)

imoold(imom) = -1

ntdmom(imom) = 10000

endif

return

end subroutine

!===============================================================================



subroutine usipes &

!================

( nmodpp , iverif )

!===============================================================================

! Purpose:

! --------

! User subroutine for the input of additional user parameters for

! input/output.

!-------------------------------------------------------------------------------

! Arguments

!__________________.____._____.________________________________________________.


!__________________!____!_____!________________________________________________!

! nmodpp ! i ! <-- ! number of active specific physics models !


!__________________!____!_____!________________________________________________!




!===============================================================================

implicit none

include "paramx.h"

include "cstnum.h"

include "dimens.h"

include "numvar.h"

include "optcal.h"

include "cstphy.h"

include "entsor.h"

include "vector.h"

include "parall.h"

include "period.h"

include "ihmpre.h"

include "ppppar.h"

include "ppthch.h"

include "ppincl.h"

!===============================================================================

! Arguments

integer nmodpp

integer iverif

! Local variables

integer ii, iphas, ipp, imom, iutile

! Local variables - LFD

TYPE probes_area






END TYPE

TYPE probes_line






END TYPE

double precision xProbe, yProbe, xSeparationProbe, ySeparationProbe

integer iProbe, iProbeLine, iProbeArea

TYPE(probes_line) probesLines(0)

TYPE(probes_area) probesAreas(2)

! Should define TYPE(probes_area) probesAreas(2)



probesAreas(1) %yStart = 1.0



probesAreas(1) %yEnd = 1.0



probesAreas(2) %yStart = -1.0


probesAreas(2) %yEnd = -1.0


!===============================================================================

!===============================================================================

! 1. Input-output (entsor.h)

!===============================================================================

! --- write auxiliary restart file iecaux = 1 yes, 0 no

iecaux = 1

! Frequency of log output

ntlist = 25

! --- post-processing output

! ichrvl: post-processing of the fluid domain (yes 1/no 0)

! ichrbo: post-processing of the domain boundary (yes 1/no 0)

! ichrsy: post-processing of zones coupled with SYRTHES (yes 1/ no 0)

! ichrmd: indicates if the meshes output are:

! 0: fixed, 1: deformable with constant connectivity, ...

! fmtchr: output format, amid

! ’EnSight Gold’, ’MED’, or ’CGNS’

! optchr: options associated with the output format, separated by

! commas, from the following list:

! ’text’ (text format, for EnSight)

! ’binary’ (binary format, default choice)

! ...

ichrvl = 1

ichrbo = 0

ichrsy = 0

ichrmd = 0

fmtchr = ’EnSight Gold’

optchr = ’binary’

! --- chronological output step

! (-1: only one valua at calculation end)

! (strictly positive valeu: output periodicity)

ntchr = 10

! --- history output step

nthist = 1

ntsuit = 100

! --- Number of monitoring points (probes) and their positions

! (limited to ncaptm=100)

! nthsav: saving period the chronological record files (they are first stored in a temporary file and then

saved every nthsav time step)

! = 0: by default (4 times during a calculation)

! = -1: saving at the end of the calculation

! > 0: period (every nthsav time step)

nthsav = 1

iProbe = 0

do iProbeLine = 1, size(probesLines), 1

ySeparationProbe = sin(atan((probesLines(iProbeLine) %yEnd - probesLines(iProbeLine) %yStart)/ &

(probesLines(iProbeLine) %xEnd - probesLines(iProbeLine) %xStart))) &

*probesLines(iProbeLine) %separation

xSeparationProbe = cos(atan((probesLines(iProbeLine) %yEnd - probesLines(iProbeLine) %yStart)/ &

(probesLines(iProbeLine) %xEnd - probesLines(iProbeLine) %xStart))) &

*probesLines(iProbeLine) %separation

xProbe = probesLines(iProbeLine) %xStart



yProbe = probesLines(iProbeLine) %yStart

do while ((((ySeparationProbe.ge.0).and.(yProbe.le.probesLines(iProbeLine) %yEnd)) &

.or.((ySeparationProbe.lt.0).and.(yProbe.ge.probesLines(iProbeLine) %yEnd))) &

.and.(((xSeparationProbe.ge.0).and.(xProbe.le.probesLines(iProbeLine) %xEnd)) &

.or.((xSeparationProbe.lt.0).and.(xProbe.ge.probesLines(iProbeLine) %xEnd))))

iProbe = iProbe + 1






end do

end do

do iProbeArea = 1, size(probesAreas), 1

ySeparationProbe = sign(probesAreas(iProbeArea) %separation, probesAreas(iProbeArea) %yEnd - probesAreas

(iProbeArea) %yStart)

xSeparationProbe = sign(probesAreas(iProbeArea) %separation, probesAreas(iProbeArea) %xEnd - probesAreas

(iProbeArea) %xStart)

xProbe = probesAreas(iProbeArea) %xStart

do while (((xSeparationProbe.ge.0).and.(xProbe.le.probesAreas(iProbeArea) %xEnd)) &

.or.((xSeparationProbe.lt.0).and.(xProbe.ge.probesAreas(iProbeArea) %xEnd)))

yProbe = probesAreas(iProbeArea) %yStart

do while (((ySeparationProbe.ge.0).and.(yProbe.le.probesAreas(iProbeArea) %yEnd)) &

.or.((ySeparationProbe.lt.0).and.(yProbe.ge.probesAreas(iProbeArea) %yEnd)))

iProbe = iProbe + 1





end do


end do

end do

ncapt = iProbe

! --- current variable

! As for other variables,

! if we do not assign the following array values,

! default values will be used

! nomvar( ) = variable name

! ichrvr( ) = chonological output (yes 1/no 0)

! ilisvr( ) = logging in listing (yes 1/no 0)

! ihisvr( ) = history output (number of probes and their numbers)

! if ihisvr(.,1) = -1, output for all probes

! Note: Only the fist 8 characters of a name will be used in the most

! detailed log.

iphas = 1

!ex ! pressure variable

ipp = ipprtp(ipr (iphas))

nomvar(ipp) = ’Pressure’

ichrvr(ipp) = 1

ilisvr(ipp) = 1

ihisvr(ipp,1) = -1

!ex ! variable v1x

ipp = ipprtp(iu (iphas))

nomvar(ipp) = ’VelocityX’

ichrvr(ipp) = 1

ilisvr(ipp) = 1

ihisvr(ipp,1) = -1

!ex ! v1y variable



ipp = ipprtp(iv (iphas))

nomvar(ipp) = ’VelocityY’

ichrvr(ipp) = 1

ilisvr(ipp) = 1

ihisvr(ipp,1) = -1

!ex ! v1z variable

ipp = ipprtp(iw (iphas))

nomvar(ipp) = ’VelocityZ’

ichrvr(ipp) = 1

ilisvr(ipp) = 1

ihisvr(ipp,1) = -1

! User scalar variables.

! We may modify here the arrays relative to user scalars, but scalars

! reserved for specific physics are handled automatically. This explains

! the tests on ’nscaus’, which ensure that the targeted scalars are

! truly user scalars.

! By specific physics, we mean only those which are handled in specific

! modules of the code, such as coal, combustion, electric arcs (see usppmo).

if (isca(1).gt.0.and.nscaus.ge.1) then

ipp = ipprtp(isca (1))

nomvar(ipp) = ’Scalar1’

ichrvr(ipp) = 1

ilisvr(ipp) = 1

ihisvr(ipp,1)= -1

endif

! Other variables

iphas = 1

return

end subroutine

!===============================================================================

subroutine ustbtr &

!================

( ncel , ncelet , nfac , nfabor , nnod , &

longia , longra , &

nideve , nituse , nrdeve , nrtuse )

!===============================================================================

! Purpose:

! -------

! User subroutine to define the sizes of macro-arrays ia and ra,

! of user arrays ituser and rtuser,

! of developper arrays idevel and rdevel.

!-------------------------------------------------------------------------------

! Arguments

!__________________.____._____.________________________________________________.


!__________________!____!_____!________________________________________________!

! ncel ! i ! <-- ! number of cells !

! ncelet ! i ! <-- ! number of extended (real + ghost) cells !

! nfac ! i ! <-- ! number of interior faces !

! nfabor ! i ! <-- ! number of boundary faces !

! nnod ! i ! <-- ! number of vertices !

! longia ! i ! --> ! size of array ia !

! longra ! i ! --> ! size of array ra !

! nideve ! i ! --> ! size of array idevel !

! nituse ! i ! --> ! size of array ituser !

! nrdeve ! i ! --> ! size of array rdevel !

! nrtuse ! i ! --> ! size of array rtuser !

!__________________!____!_____!________________________________________________!






!===============================================================================

implicit none

! Arguments

integer ncel , ncelet, nfac , nfabor, nnod

integer longia, longra

integer nideve, nituse, nrdeve, nrtuse

!===============================================================================

return

end subroutine

F.4.2. usclim.f90

!-------------------------------------------------------------------------------

! Code_Saturne version 2.0.2

! --------------------------

! This file is part of the Code_Saturne Kernel, element of the

! Code_Saturne CFD tool.

! Copyright (C) 1998-2009 EDF S.A., France

! contact: [email protected]

! The Code_Saturne Kernel is free software; you can redistribute it

! and/or modify it under the terms of the GNU General Public License

! as published by the Free Software Foundation; either version 2 of

! the License, or (at your option) any later version.

! The Code_Saturne Kernel is distributed in the hope that it will be

! useful, but WITHOUT ANY WARRANTY; without even the implied warranty

! of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

! GNU General Public License for more details.

! You should have received a copy of the GNU General Public License

! along with the Code_Saturne Kernel; if not, write to the

! Free Software Foundation, Inc.,

! 51 Franklin St, Fifth Floor,

! Boston, MA 02110-1301 USA

!-------------------------------------------------------------------------------

subroutine usclim &

!================

( idbia0 , idbra0 , &

ndim , ncelet , ncel , nfac , nfabor , nfml , nprfml , &

nnod , lndfac , lndfbr , ncelbr , &

nvar , nscal , nphas , &

nideve , nrdeve , nituse , nrtuse , &

ifacel , ifabor , ifmfbr , ifmcel , iprfml , maxelt , lstelt , &

ipnfac , nodfac , ipnfbr , nodfbr , &

icodcl , itrifb , itypfb , &

idevel , ituser , ia , &

xyzcen , surfac , surfbo , cdgfac , cdgfbo , xyznod , volume , &

dt , rtp , rtpa , propce , propfa , propfb , &

coefa , coefb , rcodcl , &

w1 , w2 , w3 , w4 , w5 , w6 , coefu , &

rdevel , rtuser , ra )

!===============================================================================

! Purpose:

! -------

! User subroutine.

! Fill boundary conditions arrays (icodcl, rcodcl) for unknown variables.

! Introduction

! ============

! Here one defines boundary conditions on a per-face basis.

! Boundary faces may be identified using the ’getfbr’ subroutine.

! getfbr(string, nelts, eltlst):

! - string is a user-supplied character string containing selection criteria;

! - nelts is set by the subroutine. It is an integer value corresponding to

! the number of boundary faces verifying the selection criteria;

! - lstelt is set by the subroutine. It is an integer array of size nelts

! containing the list of boundary faces verifying the selection criteria.



! string may contain:

! - references to colors (ex.: 1, 8, 26, ...)

! - references to groups (ex.: inlet, group1, ...)

! - geometric criteria (ex. x < 0.1, y >= 0.25, ...)

! These criteria may be combined using logical operators (’and’, ’or’) and

! parentheses.

! Example: ’1 and (group2 or group3) and y < 1’ will select boundary faces

! of color 1, belonging to groups ’group2’ or ’group3’ and with face center

! coordinate y less than 1.

! Operators priority, from highest to lowest:

! ’( )’ > ’not’ > ’and’ > ’or’ > ’xor’

! Similarly, interior faces and cells can be identified using the ’getfac’

! and ’getcel’ subroutines (respectively). Their syntax are identical to

! ’getfbr’ syntax.

! For a more thorough description of the criteria syntax, it can be referred

! to the user guide.

! Boundary condition types

! ========================

! Boundary conditions may be assigned in two ways.

! For "standard" boundary conditions:

! -----------------------------------

! (inlet, free outlet, wall, symmetry), one defines a code in the ’itypfb’

! array (of dimensions number of boundary faces, number of phases).

! This code will then be used by a non-user subroutine to assign the

! following conditions (scalars in particular will receive the conditions

! of the phase to which they are assigned). Thus:

! Code | Boundary type

! --------------------------

! ientre | Inlet

! isolib | Free outlet

! isymet | Symmetry

! iparoi | Wall (smooth)

! iparug | Rough wall

! These integers are defined elsewhere (in paramx.h header).

! Their value is greater than or equal to 1 and less than or equal to

! ntypmx (value fixed in paramx.h)

! In addition, some values must be defined:

! - Inlet (more precisely, inlet/outlet with prescribed flow, as the flow

! may be prescribed as an outflow):

! -> Dirichlet conditions on variables other than pressure are mandatory

! if the flow is incoming, optional if the flow is outgoing (the code

! assigns zero flux if no Dirichlet is specified); thus,

! at face ’ifac’, for the variable ’ivar’: rcodcl(ifac, ivar, 1)

! - Smooth wall: (= impermeable solid, with smooth friction)

! -> Velocity value for sliding wall if applicable

! at face ifac, rcodcl(ifac, iu, 1)

! rcodcl(ifac, iv, 1)

! rcodcl(ifac, iw, 1)

! -> Specific code and prescribed temperature value at wall if applicable:

! at face ifac, icodcl(ifac, ivar) = 5

! rcodcl(ifac, ivar, 1) = prescribed temperature

! -> Specific code and prescribed flux value at wall if applicable:


! rcodcl(ifac, ivar, 3) = prescribed flux

! Note that the default condition for scalars (other than k and epsilon)

! is homogeneous Neumann.

! - Rough wall: (= impermeable solid, with rough friction)

! -> Velocity value for sliding wall if applicable

! at face ifac, rcodcl(ifac, iu, 1)

! rcodcl(ifac, iv, 1)

! rcodcl(ifac, iw, 1)

! -> Value of the dynamic roughness height to specify in

! rcodcl(ifac, iu, 3)



! -> Value of the scalar roughness height (if required) to specify in

! rcodcl(ifac, iv, 3) (values for iw are not used)

! -> Specific code and prescribed temperature value at wall if applicable:


! rcodcl(ifac, ivar, 1) = prescribed temperature

! -> Specific code and prescribed flux value at rough wall, if applicable:


! rcodcl(ifac, ivar, 3) = prescribed flux

! Note that the default condition for scalars (other than k and epsilon)

! is homogeneous Neumann.

! - Symmetry (= slip wall):

! -> Nothing to specify

! - Free outlet (more precisely free inlet/outlet with prescribed pressure)

! -> Nothing to prescribe for pressure and velocity. For scalars and

! turbulent values, a Dirichlet value may optionally be specified.

! The behavior is as follows:

! * pressure is always handled as a Dirichlet condition

! * if the mass flow is inflowing:

! one retains the velocity at infinity

! Dirichlet condition for scalars and turbulent values

! (or zero flux if the user has not specified a

! Dirichlet value)

! if the mass flow is outflowing:

! one prescribes zero flux on the velocity, the scalars,

! and turbulent values

! Note that the pressure will be reset to p0 on the first free outlet

! face found

! For "non-standard" conditions:

! ------------------------------

! Other than (inlet, free outlet, wall, symmetry), one defines

! - on one hand, for each face:

! -> an admissible ’itypfb’ value (i.e. greater than or equal to 1 and

! less than or equal to ntypmx; see its value in paramx.h).

! The values predefined in paramx.h:

! ’ientre’, ’isolib’, ’isymet’, ’iparoi’, ’iparug’ are in this range,

! and it is preferable not to assign one of these integers to ’itypfb’

! randomly or in an inconsiderate manner. To avoid this, one may use

! ’iindef’ if one wish to avoid checking values in paramx.h. ’iindef’

! is an admissible value to which no predefined boundary condition

! is attached.

! Note that the ’itypfb’ array is reinitialized at each time step to

! the non-admissible value of 0. If one forgets to modify ’typfb’ for

! a given face, the code will stop.

! - and on the other hand, for each face and each variable:

! -> a code icodcl(ifac, ivar)

! -> three real values rcodcl(ifac, ivar, 1)

! rcodcl(ifac, ivar, 2)

! rcodcl(ifac, ivar, 3)

! The value of ’icodcl’ is taken from the following:

! 1: Dirichlet (usable for any variable)

! 3: Neumann (usable for any variable)

! 4: Symmetry (usable only for the velocity and components of

! the Rij tensor)

! 5: Smooth wall (usable for any variable except for pressure)

! 6: Rough wall (usable for any variable except for pressure)

! 9: Free outlet (usable only for velocity)

! The values of the 3 ’rcodcl’ components are:

! rcodcl(ifac, ivar, 1):

! Dirichlet for the variable if icodcl(ifac, ivar) = 1

! Wall value (sliding velocity, temp) if icodcl(ifac, ivar) = 5

! The dimension of rcodcl(ifac, ivar, 1) is that of the

! resolved variable: ex U (velocity in m/s),

! T (temperature in degrees)

! H (enthalpy in J/kg)

! F (passive scalar in -)

! rcodcl(ifac, ivar, 2):

! "exterior" exchange coefficient (between the prescribed value



! and the value at the domain boundary)

! rinfin = infinite by default

! For velocities U, in kg/(m2 s):

! rcodcl(ifac, ivar, 2) = (viscl+visct) / d

! For the pressure P, in s/m:

! rcodcl(ifac, ivar, 2) = dt / d

! For temperatures T, in Watt/(m2 degres):

! rcodcl(ifac, ivar, 2) = Cp*(viscls+visct/sigmas) / d

! For enthalpies H, in kg /(m2 s):

! rcodcl(ifac, ivar, 2) = (viscls+visct/sigmas) / d

! For other scalars F in:

! rcodcl(ifac, ivar, 2) = (viscls+visct/sigmas) / d

! (d has the dimension of a distance in m)

!

! rcodcl(ifac, ivar, 3) if icodcl(ifac, ivar) <> 6:

! Flux density (< 0 if gain, n outwards-facing normal)

! if icodcl(ifac, ivar)= 3

! For velocities U, in kg/(m s2) = J:

! rcodcl(ifac, ivar, 3) = -(viscl+visct) * (grad U).n

! For pressure P, in kg/(m2 s):

! rcodcl(ifac, ivar, 3) = -dt * (grad P).n

! For temperatures T, in Watt/m2:

! rcodcl(ifac, ivar, 3) = -Cp*(viscls+visct/sigmas) * (grad T).n

! For enthalpies H, in Watt/m2:

! rcodcl(ifac, ivar, 3) = -(viscls+visct/sigmas) * (grad H).n

! For other scalars F in:

! rcodcl(ifac, ivar, 3) = -(viscls+visct/sigmas) * (grad F).n

! rcodcl(ifac, ivar, 3) if icodcl(ifac, ivar) = 6:

! Roughness for the rough wall law

! For velocities U, dynamic roughness

! rcodcl(ifac, iu, 3) = roughd

! For other scalars, thermal roughness

! rcodcl(ifac, iv, 3) = rought

! Remarks

! =======

! Caution: to prescribe a flux (nonzero) to Rij, the viscosity to take

! into account is viscl even if visct exists

! (visct=rho cmu k2/epsilon)

! One have the ordering array for boundary faces from the previous time

! step (except for the fist one, where ’itrifb’ has not been set yet).

! The array of boundary face types ’itypfb’ has been reset before

! entering the subroutine.

! Note how to access some variables (for phase ’iphas’

! variable ’ivar’

! scalar ’iscal’):

! Cell values (let iel = ifabor(ifac))

! * Density: propce(iel, ipproc(irom(iphas)))

! * Dynamic molecular viscosity: propce(iel, ipproc(iviscl(iphas)))

! * Turbulent viscosity: propce(iel, ipproc(ivisct(iphas)))

! * Specific heat: propce(iel, ipproc(icp(iphas))

! * Diffusivity(lambda): propce(iel, ipproc(ivisls(iscal)))

! Boundary face values

! * Density: propfb(ifac, ipprob(irom(iphas)))

! * Mass flux (for convecting ’ivar’): propfb(ifac, ipprob(ifluma(ivar)))

! * For other values: take as an approximation the value in the adjacent cell

! i.e. as above with iel = ifabor(ifac).

!-------------------------------------------------------------------------------



! Arguments

!__________________.____._____.________________________________________________.


!__________________!____!_____!________________________________________________!

! idbia0 ! i ! <-- ! number of first free position in ia !

! idbra0 ! i ! <-- ! number of first free position in ra !

! ndim ! i ! <-- ! spatial dimension !

! ncelet ! i ! <-- ! number of extended (real + ghost) cells !

! ncel ! i ! <-- ! number of cells !

! nfac ! i ! <-- ! number of interior faces !

! nfabor ! i ! <-- ! number of boundary faces !

! nfml ! i ! <-- ! number of families (group classes) !

! nprfml ! i ! <-- ! number of properties per family (group class) !

! nnod ! i ! <-- ! number of vertices !

! lndfac ! i ! <-- ! size of nodfac indexed array !

! lndfbr ! i ! <-- ! size of nodfbr indexed array !

! ncelbr ! i ! <-- ! number of cells with faces on boundary !

! nvar ! i ! <-- ! total number of variables !

! nscal ! i ! <-- ! total number of scalars !

! nphas ! i ! <-- ! number of phases !

! nideve, nrdeve ! i ! <-- ! sizes of idevel and rdevel arrays !

! nituse, nrtuse ! i ! <-- ! sizes of ituser and rtuser arrays !

! ifacel(2, nfac) ! ia ! <-- ! interior faces -> cells connectivity !

! ifabor(nfabor) ! ia ! <-- ! boundary faces -> cells connectivity !

! ifmfbr(nfabor) ! ia ! <-- ! boundary face family numbers !

! ifmcel(ncelet) ! ia ! <-- ! cell family numbers !

! iprfml ! ia ! <-- ! property numbers per family !

! (nfml, nprfml) ! ! ! !

! maxelt ! i ! <-- ! max number of cells and faces (int/boundary) !

! lstelt(maxelt) ! ia ! --- ! work array !

! ipnfac(nfac+1) ! ia ! <-- ! interior faces -> vertices index (optional) !

! nodfac(lndfac) ! ia ! <-- ! interior faces -> vertices list (optional) !

! ipnfbr(nfabor+1) ! ia ! <-- ! boundary faces -> vertices index (optional) !

! nodfbr(lndfbr) ! ia ! <-- ! boundary faces -> vertices list (optional) !

! icodcl ! ia ! --> ! boundary condition code !

! (nfabor, nvar) ! ! ! = 1 -> Dirichlet !

! ! ! ! = 2 -> flux density !

! ! ! ! = 4 -> sliding wall and u.n=0 (velocity) !

! ! ! ! = 5 -> friction and u.n=0 (velocity) !

! ! ! ! = 6 -> roughness and u.n=0 (velocity) !

! ! ! ! = 9 -> free inlet/outlet (velocity) !

! ! ! ! inflowing possibly blocked !

! itrifb ! ia ! <-- ! indirection for boundary faces ordering !

! (nfabor, nphas) ! ! ! !

! itypfb ! ia ! --> ! boundary face types !

! (nfabor, nphas) ! ! ! !

! idevel(nideve) ! ia ! <-> ! integer work array for temporary development !

! ituser(nituse) ! ia ! <-> ! user-reserved integer work array !

! ia(*) ! ia ! --- ! main integer work array !

! xyzcen ! ra ! <-- ! cell centers !

! (ndim, ncelet) ! ! ! !

! surfac ! ra ! <-- ! interior faces surface vectors !

! (ndim, nfac) ! ! ! !

! surfbo ! ra ! <-- ! boundary faces surface vectors !

! (ndim, nfabor) ! ! ! !

! cdgfac ! ra ! <-- ! interior faces centers of gravity !

! (ndim, nfac) ! ! ! !

! cdgfbo ! ra ! <-- ! boundary faces centers of gravity !

! (ndim, nfabor) ! ! ! !

! xyznod ! ra ! <-- ! vertex coordinates (optional) !

! (ndim, nnod) ! ! ! !

! volume(ncelet) ! ra ! <-- ! cell volumes !

! dt(ncelet) ! ra ! <-- ! time step (per cell) !

! rtp, rtpa ! ra ! <-- ! calculated variables at cell centers !

! (ncelet, *) ! ! ! (at current and previous time steps) !

! propce(ncelet, *)! ra ! <-- ! physical properties at cell centers !

! propfa(nfac, *) ! ra ! <-- ! physical properties at interior face centers !

! propfb(nfabor, *)! ra ! <-- ! physical properties at boundary face centers !

! coefa, coefb ! ra ! <-- ! boundary conditions !

! (nfabor, *) ! ! ! !



! rcodcl ! ra ! --> ! boundary condition values !

! (nfabor,nvar,3) ! ! ! rcodcl(1) = Dirichlet value !

! ! ! ! rcodcl(2) = exterior exchange coefficient !

! ! ! ! (infinite if no exchange) !

! ! ! ! rcodcl(3) = flux density value !

! ! ! ! (negative for gain) in w/m2 or !

! ! ! ! roughness height (m) if icodcl=6 !

! ! ! ! for velocities ( vistl+visct)*gradu !

! ! ! ! for pressure dt*gradp !

! ! ! ! for scalars cp*(viscls+visct/sigmas)*gradt !

! w1,2,3,4,5,6 ! ra ! --- ! work arrays !

! (ncelet) ! ! ! (computation of pressure gradient) !

! coefu ! ra ! --- ! work array !

! (nfabor, 3) ! ! ! (computation of pressure gradient) !

! rdevel(nrdeve) ! ra ! <-> ! real work array for temporary development !

! rtuser(nrtuse) ! ra ! <-> ! user-reserved real work array !

! ra(*) ! ra ! --- ! main real work array !

!__________________!____!_____!________________________________________________!




!===============================================================================

implicit none

include "paramx.h"

include "pointe.h"

include "numvar.h"

include "optcal.h"

include "cstphy.h"

include "cstnum.h"

include "entsor.h"

include "parall.h"

include "period.h"

include "ihmpre.h"

!===============================================================================

! Arguments

integer idbia0 , idbra0

integer ndim , ncelet , ncel , nfac , nfabor

integer nfml , nprfml

integer nnod , lndfac , lndfbr , ncelbr

integer nvar , nscal , nphas

integer nideve , nrdeve , nituse , nrtuse

integer ifacel(2,nfac) , ifabor(nfabor)

integer ifmfbr(nfabor) , ifmcel(ncelet)

integer iprfml(nfml,nprfml), maxelt, lstelt(maxelt)

integer ipnfac(nfac+1), nodfac(lndfac)

integer ipnfbr(nfabor+1), nodfbr(lndfbr)

integer icodcl(nfabor,nvar)

integer itrifb(nfabor,nphas), itypfb(nfabor,nphas)

integer idevel(nideve), ituser(nituse), ia(*)

double precision xyzcen(ndim,ncelet)

double precision surfac(ndim,nfac), surfbo(ndim,nfabor)

double precision cdgfac(ndim,nfac), cdgfbo(ndim,nfabor)

double precision xyznod(ndim,nnod), volume(ncelet)

double precision dt(ncelet), rtp(ncelet,*), rtpa(ncelet,*)

double precision propce(ncelet,*)

double precision propfa(nfac,*), propfb(nfabor,*)

double precision coefa(nfabor,*), coefb(nfabor,*)

double precision rcodcl(nfabor,nvar,3)

double precision w1(ncelet),w2(ncelet),w3(ncelet)

double precision w4(ncelet),w5(ncelet),w6(ncelet)

double precision coefu(nfabor,ndim)

double precision rdevel(nrdeve), rtuser(nrtuse), ra(*)

! Local variables

integer idebia, idebra



integer ifac, iel, ii, ivar, iphas

integer ilelt, nlelt

double precision uref2, d2s3

double precision rhomoy, dh, ustar2

double precision xintur

double precision xkent, xeent

! Local Variables - LFD

double precision alfa, beta

double precision xCentre, yCentre

character*10 sStepNumber

character*10 sProcessorNumber

integer, parameter:: actuatorStartingStep = 7500

real, parameter :: inputVelocity = 1d0

real :: upperActuatorValue, lowerActuatorValue

logical, save:: actuatorValuesInitialized = .false.

!===============================================================================

!===============================================================================

! 1. Initialization

!===============================================================================

if (.not.actuatorValuesInitialized) then

write( sProcessorNumber, ’(i1)’ ) irangp

call system("mkfifo semaphore."//sProcessorNumber)

call system("mkfifo act.upper.csv."//sProcessorNumber)

call system("mkfifo act.lower.csv."//sProcessorNumber)

call system("./controller "//sProcessorNumber//" act.upper.csv."//sProcessorNumber &

//" act.lower.csv."//sProcessorNumber//" probes_Scalar1.dat < semaphore."//sProcessorNumber//" &")

open(unit=103, file="semaphore."//sProcessorNumber, action="write")

open(unit=104, file="act.upper.csv."//sProcessorNumber, action="read")

open(unit=105, file="act.lower.csv."//sProcessorNumber, action="read")

actuatorValuesInitialized = .true.

endif

idebia = idbia0

idebra = idbra0

d2s3 = 2.d0/3.d0

!===============================================================================

! 2. Assign boundary conditions to boundary faces here

! One may use selection criteria to filter boundary case subsets

! Loop on faces from a subset

! Set the boundary condition for each face

!===============================================================================

! Code | Boundary type

! --------------------------

! ientre | Inlet

! isolib | Free outlet

! isymet | Symmetry

! iparoi | Wall (smooth)

! iparug | Rough wall

!$PhysicalNames

!1 Layer0

!2 entrada

!3 salida

!4 pared

!5 simetria

!6 interna

!7 actuador

!5 simetria

!$EndPhysicalNames



!entrada -> ientre


do ilelt = 1, nlelt


do iphas = 1, nphas

itypfb(ifac,iphas) = ientre

rcodcl(ifac,iu(iphas),1) = inputVelocity




do ii = 1, nscal

if(iphsca(ii).eq.iphas) then

if (yCentre.gt.-0.1d0.and.yCentre.lt.0.1d0) then



else



endif

endif

enddo

enddo

enddo

!salida -> isolib


do ilelt = 1, nlelt


iel = ifabor(ifac)

do iphas = 1, nphas

itypfb(ifac,iphas) = isolib

icodcl(ifac,ipr(iphas)) = 1 !dirichlet condition on pressure -> fixed value

icodcl(ifac,iu(iphas)) = 3 !neumann condition on velocity -> fixed gradient

icodcl(ifac,iv(iphas)) = 3

icodcl(ifac,iw(iphas)) = 3

rcodcl(ifac,ipr(iphas),1) = 0.0d0 !dirichlet value fixed to pressure=0

rcodcl(ifac,iu(iphas),3) = 0.0d0 !neumann value fixed to grad(u,normal) = 0



enddo

enddo

!pared -> iparoi


do ilelt = 1, nlelt


do iphas = 1, nphas


enddo

enddo

!simetria -> isymet


do ilelt = 1, nlelt


do iphas = 1, nphas

itypfb(ifac,iphas) = isymet

enddo

enddo

if (ntcabs.ge.actuatorStartingStep) then

write(sStepNumber, ’(i0)’ ) ntcabs



write(103,*) sStepNumber

read(104,*) upperActuatorValue

read(105,*) lowerActuatorValue

else

upperActuatorValue = 0

lowerActuatorValue = 0

endif

if (ntmabs.eq.ntcabs) then

close(103)

close(104)

close(105)

endif

!actuador -> iparug

call getfbr(’7 and y > 0’, nlelt, lstelt)

do ilelt = 1, nlelt





beta = alfa - pi/2.0

do iphas = 1, nphas


rcodcl(ifac,iu(iphas),1) = upperActuatorValue * cos(beta)

rcodcl(ifac,iv(iphas),1) = upperActuatorValue * sin(beta)


enddo

enddo

call getfbr(’7 and y < 0’, nlelt, lstelt)

do ilelt = 1, nlelt





beta = alfa + pi/2.0

do iphas = 1, nphas


rcodcl(ifac,iu(iphas),1) = lowerActuatorValue * cos(beta)

rcodcl(ifac,iv(iphas),1) = lowerActuatorValue * sin(beta)


enddo

enddo

return

end subroutine

F.5. Identificador del Sistema en Matlab

F.5.1. lfd arx.m

function [A B] = lfd_arx(y, u, p)

y = y’;

u = u’;

na = p;

nb = na+1;

%Modelo de partida:

% y(k)+a_1*y(k-1)+a_2*y(k-2)+...a_na*y(k-na)=



% =b_1*u(k)+b_2*u(k-1)+...+b_nb*u(k-(nb-1))

%donde

% y(k) es la salida en el tiempo k, vector de mx1

% u(k) es la entrada en el tiempo k, vector de rx1

% a_1,..a_na matrices de mxm

% b_1,...b_nb matrices de mxr

%venimos considerando na=nb-1

%De acuerdo con esta escritura, se considera

% N:cantidad de observaciones

% y: matriz de observaciones de las salidas, de mxN; es decir, en la

%columna j la salida en el tiempo j

% u: matriz de las observaciones de las entradas, de rxN; es decir, en la columna j la entrada en el

tiempo j

%segon Ljung, se define el vector de regresion en el tiempo k como:

% fi(k)=(-y(k-1), ...,-y(k-na),u(k), u(k-1),...u(k-(nb-1))’

% y el "vector" de parometros a calcular mp’=(a_1,...,a_na,_1,...b_nb)

[m,N] = size(y);

[r,N] = size(u);

%se construye fi con los valores de regresion, considerando los tiempos de

%na+1 en adelante

fi = zeros(na*m+nb*r,N);

for j=na+1:N

fi(:,j)=[reshape(-y(:, j-1:-1:j-na), na*m, 1); ...


end

%se construye la matriz de regresion

fi2 = fi(:, na+1:end);

reg = zeros(m*size(fi2,1), m*(N-na));

for j=1:N-na

reg(:, 1+(j-1)*m:j*m) = kron(fi2(:,j), eye(m));

end

%REVISAR SIG LINEA



F = [reg’ Y];

R = triu(qr(F));

%d: cantidad de nomeros a determinar para armar las matrices %del modelo

d = na*m*m+nb*r*m;

R0 = R(1:d+1,1:d+1);

R1 = R0(1:d,1:d);

R2 = R0(1:d,end);

%se desecha la parte Q de la matriz F y se resuelve por cuad. monimos

%th: resultante que contiene los valores para armar las matrices A y B

th = pinv(R1) * R2;



for j=1:na


end

for j=1:nb


end


A(:,:,1) = eye(m);

A(:,:,2:end) = a(:,:,:);

B = b;



F.5.2. lfd compare.m

function [ fit ] = lfd_compare(data, max_steps_to_predict, model)

%LFD_COMPARE Compares a given system identification model against the real data

% Returns the Fit information.

y = pvget(data, ’OutputData’);

y = y{1};

ny = size(y , 2);

y_predicted = predict(model, data, max_steps_to_predict, ’e’);

y_predicted = pvget(y_predicted, ’OutputData’);

y_predicted = y_predicted{1};

fit = zeros(ny, 1);

for ky = 1:ny

err = norm(y_predicted(:, ky) - y(:, ky));

meanerr = norm(y(:, ky) - mean(y(:, ky)));

fit(ky) = 100*(1-err/meanerr);

end

% Original code adapted from the compare function in the System

% Identification toolbox:

% ksys = 1;

% th = model;

% z1 = data;

% m = Inf;

% kexp = 1;

%

% y = pvget(data, ’OutputData’);

% y{1} = y{ksys,kexp};

% [nrow, ny] = size(y{1});

% [nrow, nu] = size(u);

%

% sampizf{1} = 1:nrow;

% ksysinit = ’e’;

%

% [yh{ksys}, x01{ksys}] = predict(th, z1, m, ksysinit);

% yhh = pvget(yh{ksys}, ’OutputData’);

%

% for ky = 1:ny

% kyy = ky;

% err = norm(yhh{kexp}(sampizf{kexp}, kyy) - y{kexp}(sampizf{kexp}, ky));

% meanerr = norm(y{kexp}(sampizf{kexp}, ky) - mean(y{kexp}(sampizf{kexp}, ky)));

% fit(kexp, ksys, ky) = 100*(1-err/meanerr);

% end

end

F.5.3. lfd training actuation.m

function act = lfd_training_actuation(totalSteps, freq_range, amplitude)

% Computes the actuation for a training phase for a given amount of totalSteps. It is possible to

% define amount of random phases of actuation and frequency, modulus, etc. per each.

% Params: totalSteps, amountOfPhases, allowable_freq_range, allowable_modulus_range, stepDifference

s = RandStream.create(’mrg32k3a’,’NumStreams’,1);

RandStream.setDefaultStream(s); %to ensure deterministic output

%randseed(45233); %to ensure deterministic output

act = chirp(1:totalSteps, freq_range(1), totalSteps, freq_range(2))*amplitude;

act = repmat(act’, 1, 2);

end



F.5.4. lfd training actuation gaussian.m

function act = lfd_training_actuation_gaussian(peakMagnitude, totalSteps, meanStep, sigma)



steps = 1:totalSteps;

act = peakMagnitude * exp(-((steps-meanStep).^2)/(2*sigma^2));


end

F.5.5. lfd training actuation multiple gaussian.m

function act = lfd_training_actuation_multiple_gaussian(peakMagnitude, totalSteps, meanSteps, sigma)



steps = 1:totalSteps;

act = zeros(1, totalSteps);

for ii=1:length(meanSteps)

meanStep = meanSteps(ii);

gaussian = peakMagnitude * exp(-((steps-meanStep).^2)/(2*sigma^2));

act = act + gaussian;

end


end

F.5.6. lfd training actuation pulse.m

function act = lfd_training_actuation_pulse(pulseMagnitude, delayBeforePulseSteps, pulseSteps,

delayAfterPulseSteps)


% define amount of random phases of actuation and frequency, modulus, etc. per each.


s = RandStream.create(’mrg32k3a’,’NumStreams’,1);

RandStream.setDefaultStream(s); %to ensure deterministic output

%randseed(45233); %to ensure deterministic output

totalSteps = delayBeforePulseSteps + pulseSteps + delayAfterPulseSteps;


act(delayBeforePulseSteps+1:delayBeforePulseSteps+pulseSteps) = pulseMagnitude;


end

F.5.7. lfd training actuation ramp.m

function act = lfd_training_actuation_ramp(peakMagnitude, delayBeforeRampSteps, rampUpSteps, rampDownSteps,

delayAfterRampSteps)



totalSteps = delayBeforeRampSteps + rampUpSteps + rampDownSteps + delayAfterRampSteps;


deltaRampUp = 1/rampUpSteps;

deltaRampDown = 1/rampDownSteps;

act(delayBeforeRampSteps+1:delayBeforeRampSteps+rampUpSteps) = peakMagnitude*[deltaRampUp:

deltaRampUp:1];



act(delayBeforeRampSteps+rampUpSteps+1:delayBeforeRampSteps+rampUpSteps+rampDownSteps) =

peakMagnitude*[1-deltaRampDown:-deltaRampDown:0];


end

F.6. Controlador en C++

F.6.1. main.cpp

/*

In order to compile the code it is possible to run the "mex" command either via Matlab or Linux Shell:

Matlab: mex(’-v’, ’-f’, fullfile(matlabroot,’bin’,’engopts.sh’),’controlador.cpp’, ’Parser.cpp’, ’

MatlabExecutor.cpp’, etc)

Shell: mex -v -f /usr/local/opt/matlab2009/bin/engopts.sh main.cpp Parser.cpp MatlabExecutor.cpp

Controller.cpp SaturneCommunicator.cpp -o controller

Run with:

LD_LIBRARY_PATH=/usr/local/opt/matlab2009/bin/glnxa64:/usr/local/opt/matlab2009/sys/os/glnxa64:

$LD_LIBRARY_PATH

sudo ldconfig /usr/local/opt/matlab2009/bin/glnxa64

./controller

*/

#include <iostream>

#include <fstream>

#include <string>

#include <sstream>

#include <fstream>

#include <string>

#include <sstream>

#include <vector>

#include <limits>

#include <algorithm>

#include "Parser.h"

#include "Logger.h"

#include "MatlabExecutor.h"

#include "Controller.h"

#include "SaturneCommunicator.h"

#include "Constants.h"

int main(int argc, char* argv[]) {

if (argc != 5) {

std::cerr << "Se esperaban 4 argumentos. Modo de uso: ./controlador <processor-number> <upper-actuator-

output-file> <lower-actuator-output-file> <probes-pressure-input-file> < semaforo." << std::endl;

return 1;

}

else {

std::string logFilepath;

std::string logPrefix;


converter << "controlador.log." << argv[1];

converter >> logFilepath;

std::stringstream prefixConverter;

prefixConverter << "[CPU." << argv[1] << "]";

prefixConverter >> logPrefix;

Logger logger(logPrefix, logFilepath);

Parser parser(logger, PROBES_COUNT);

MatlabExecutor matlabExecutor(logger);

logger << "Abriendo archivo actuador alto: ’" << argv[2] << "’." << std::endl;

std::ofstream upperActuator(argv[2]);

logger << "Abriendo archivo actuador bajo: ’" << argv[3] << "’." << std::endl;

std::ofstream lowerActuator(argv[3]);

char* probesPressureFilepath = argv[4];



logger << "Tomando semaforo de STDIN..."<< std::endl;

std::istream& semaphore = std::cin;

try {

Controller controller(argv[1], logger, matlabExecutor);

SaturneCommunicator saturneCommunicator;

controller.initialize("configuration.txt");

bool continueControl = true;

while (continueControl) {

int semaphoreStepNumber = saturneCommunicator.waitForStep(semaphore, logger);

if (semaphoreStepNumber >= 0) {

Row values = parser.readValues(probesPressureFilepath , semaphoreStepNumber - 1);

Actuation act = controller.getActuationFor(semaphoreStepNumber, values);

saturneCommunicator.send(upperActuator, logger, act.upper);

saturneCommunicator.send(lowerActuator, logger, act.lower);

}

else {

logger << "Seoal de cierre recibida. Finalizando..." << std::endl;

continueControl = false;

}

}

return 0;

}

catch(const char* message) {

logger << "ERROR DURING SIMULATION: " << message << std::endl;

return 1;

}

catch(...) {

logger << "UNKNOWN ERROR DURING SIMULATION: " << std::endl;

return 1;

}

}

}

F.6.2. Config.h

#ifndef CONFIG__

#define CONFIG__

#include <map>

#include <string>

#include <fstream>

class Config {

private:

typedef std::map< std::string, std::string > t_keyvalues;

typedef std::pair< std::string, std::string > t_keyvalue;

t_keyvalues keyValues;

public:

Config(const std::string& configurationFilepath){

initialize(configurationFilepath);

}

Config(){

}

void initialize(const std::string& configurationFilepath) {

std::ifstream keyValuesFile(configurationFilepath.c_str());

if (! keyValuesFile)

throw "There was an error trying to read the configuration file.";

else {

while(keyValuesFile.good()) {

std::string line;

getline(keyValuesFile, line);

trim(line);



if (!line.empty()){

std::string::size_type pos = line.find_first_of("=");

if (pos != std::string::npos) {

std::string key = line.substr(0, pos-1);

std::string value = line.substr(pos+1, line.size());

trim(key);

trim(value);

keyValues.insert(t_keyvalue(key, value));

}

}

}

}

}

float getFloat(const std::string& key) {

return get< float >(key);

}

bool getBool(const std::string& key) {

return get< bool >(key);

}

int getInt(const std::string& key) {

return get< int >(key);

}

std::string get(const std::string& key) {

t_keyvalues::iterator it = keyValues.find(key);

if (it == keyValues.end()) {

std::stringstream ss;

ss << "The key ’" << key << "’was not found.";

throw ss.str().c_str();

}

else

return it->second;

}

private:

void trim(std::string& str, const std::string trimChars = std::string(" \f\n\r\t\v") ) {

std::string::size_type pos;

pos = str.find_last_not_of(trimChars);

str.erase( pos + 1 );

pos = str.find_first_not_of(trimChars);

str.erase( 0, pos );

}

template < typename T >

T get(const std::string& key) {

std::string value = get(key);

std::stringstream ss;

ss << value;

T result;

ss >> result;

return result;

}

};

#endif

F.6.3. configuration control.txt

CONTROL_PARAMETER_P = 90

CONTROL_PARAMETER_Q = [1.4 1.4 1.4 1.4 1.4 1.4 1.4 1.4]

CONTROL_PARAMETER_GAMMA = 4

CONTROL_LIMITS_MAX_VALUE = 5

CONTROL_LIMITS_MIN_VALUE = 0



CONTROL_CALCULATE_ACTUATION_AFTER_STEPS = 1

CONTROL_PREDICTION_MAX_STEPS = 1000

SENSORS_MASK_PROBES_TO_USE = 7,9,11,13,48,50,52,54

SENSORS_NORMALIZE_VARIABLE_Y_SENTENCE = if ~exist(’yNormalizerScalars’),global yNormalizerScalars;range =

1:170; yNormalizerScalars=diag(1./mean(y(range,:)));end;y=y*yNormalizerScalars;

ACTUATOR_UPPERVALUE_ARRAYINDEX = 0

ACTUATOR_LOWERVALUE_ARRAYINDEX = 0

ACTUATOR_NORMALIZE_VARIABLE_U_SENTENCE = u=u(:,1);

SAVE_OUTPUT_FILEPATH = outputs.csv

SAVE_INPUT_FILEPATH = inputs.csv

TRAINING_FROM_STORED_DATA_ENABLED = 1

TRAINING_FROM_STORED_DATA_FILEPATH = ProbesAndActuation_one_pulse_sync_r235_full_line.mat

TRAINING_FROM_STORED_DATA_OUTPUT_VARIABLE = scalar_values

TRAINING_FROM_STORED_DATA_INPUT_VARIABLE = actuation

TRAINING_FROM_STORED_DATA_SAMPLING_RATE = 1

TRAINING_GENERATION_ENABLED = 0

TRAINING_GENERATION_FUNCTION_INVOKE = %lfd_training_actuation_pulse(10, 375, 37, 3750)

COMPUTE_MODEL_STEPS = 1

F.6.4. configuration training.txt

CONTROL_PARAMETER_P = 35

CONTROL_PARAMETER_Q = [1 1 1 1]

CONTROL_PARAMETER_GAMMA = 0.8

CONTROL_LIMITS_MAX_VALUE = 3

CONTROL_LIMITS_MIN_VALUE = 0

CONTROL_CALCULATE_ACTUATION_AFTER_STEPS = 1

CONTROL_PREDICTION_MAX_STEPS = 1000

SENSORS_MASK_PROBES_TO_USE = 4,6,13,15

SENSORS_NORMALIZE_VARIABLE_Y_SENTENCE = if ~exist(’yNormalizerScalars’),global yNormalizerScalars;

yNormalizerScalars=diag(1./mean(y));end;y=y*yNormalizerScalars;

ACTUATOR_UPPERVALUE_ARRAYINDEX = 0

ACTUATOR_LOWERVALUE_ARRAYINDEX = 0

ACTUATOR_NORMALIZE_VARIABLE_U_SENTENCE = u=u(:,1);

SAVE_OUTPUT_FILEPATH = outputs.csv

SAVE_INPUT_FILEPATH = inputs.csv

TRAINING_FROM_STORED_DATA_ENABLED = 0

TRAINING_FROM_STORED_DATA_FILEPATH = %ProbesAndActuation_mixed_sync.mat

TRAINING_FROM_STORED_DATA_OUTPUT_VARIABLE = %scalar_values

TRAINING_FROM_STORED_DATA_INPUT_VARIABLE = %actuation

TRAINING_FROM_STORED_DATA_SAMPLING_RATE = %10

TRAINING_GENERATION_ENABLED = 1

TRAINING_GENERATION_FUNCTION_INVOKE = lfd_training_actuation_pulse(10, 180, 10, 900)

COMPUTE_MODEL_STEPS = 10

F.6.5. Constants.h

#ifndef CONSTANTS__

#define CONSTANTS__

#define LINE_PROBES 11.0 //nLineProbes = 11 check values in usini1.f90

#define SAMPLES_PER_LINE 9.0 //nSamplesPerLine = 9 check values in usini1.f90

#define PROBES_COUNT LINE_PROBES*SAMPLES_PER_LINE

#define X_STEP 1.0 //1 diametre in between line probes



#define Y_STEP (6.0+6.0)/SAMPLES_PER_LINE //based on the amount of samples per line. Having 12.5 diametres

to the upper and bottom limits of the tunnel.

#include <vector>

#include "Matrix.h"

struct Actuation {

Cell upper;

Cell lower;

};

#endif

F.6.6. Controller.h

#ifndef CONTROLLER__

#define CONTROLLER__

#include <vector>

#include <set>

#include "Logger.h"



#include "Config.h"

class Controller {

private:

Matrix cummulativeOutputsForModel, cummulativeOutputs;

Matrix cummulativeActuationForModel, cummulativeActuation;

std::vector < Actuation > trainingActuations;

std::vector < Actuation >::const_iterator itTrainingActuation;

Actuation previousActuation;

bool initialized;

bool modelAlreadyComputed;

size_t invocationsCount;

char* processorNumber;

std::set< size_t > probesToUse;

Logger& logger;

MatlabExecutor& matlabExecutor;

std::ofstream inputsLogFile;

std::ofstream outputsLogFile;

Config config;

public:

Controller(char* processorNumber, Logger& logger, MatlabExecutor& matlabExecutor);

void initialize(const std::string& configurationFilepath);

Actuation getActuationFor(int currentStep, const Row& lastStepOutputs);

private:

void addOutputsForModelComputation(const Row& lastStepOutputs, const Row& actuation);

std::vector < Actuation > getTrainingActuation();

Actuation getActuationFromRow(const Row& row);

void computeModel();

Actuation computeActuation();

Actuation getActuationForNewStep();

Matrix removeUselessProbeValues(const Matrix& values);

Row removeUselessProbeValues(const Row& values);

void checkInitialized();

void restoreTrainingData();

void saveLastStepInformation(int currentStep, const Actuation& input, const Row& output);

};

#endif



F.6.7. Controller.cpp

#include <sstream>

#include <set>

#include "Controller.h"

Controller::Controller(char* processorNumber, Logger& logger, MatlabExecutor& matlabExecutor)

: cummulativeOutputsForModel(0,0), cummulativeOutputs(0,0), cummulativeActuationForModel(0,0),

cummulativeActuation(0,0),

initialized(false), modelAlreadyComputed(false), invocationsCount(0), processorNumber(

processorNumber), logger(logger), matlabExecutor(matlabExecutor) {

}

void Controller::initialize(const std::string& configurationFilepath) {

this->config.initialize(configurationFilepath);

this->previousActuation.upper = 0;

this->previousActuation.lower = 0;

this->initialized = true;

inputsLogFile.open(config.get("SAVE_INPUT_FILEPATH").c_str(), std::ofstream::out);

outputsLogFile.open(config.get("SAVE_OUTPUT_FILEPATH").c_str(), std::ofstream::out);

if (! inputsLogFile.good())

throw "There was an error trying to open the input file";

if (! outputsLogFile.good())

throw "There was an error trying to open the output file";

std::istringstream maskProbesToUseStr(config.get("SENSORS_MASK_PROBES_TO_USE"));

logger << "Defining Mask Probes to use: ";

std::string probeToUse;

while ( getline(maskProbesToUseStr, probeToUse, ’,’) )

{

this->probesToUse.insert(atoi(probeToUse.c_str()));

logger << " " << probeToUse;

}

logger << std::endl;

bool trainingFromStoredData = config.getBool("TRAINING_FROM_STORED_DATA_ENABLED");

bool trainingGeneration = config.getBool("TRAINING_GENERATION_ENABLED");

if (trainingFromStoredData && trainingGeneration || !trainingFromStoredData && !trainingGeneration)

throw "It is neccessary to define whether TRAINING_FROM_STORED_DATA or TRAINING_GENERATION will be used

in the configuration file.";

if (trainingFromStoredData) {

//let trainining to be empty

this->itTrainingActuation = this->trainingActuations.begin();

this->restoreTrainingData();

logger << "Before computing model. CummulativeOutputs Rows: " << cummulativeOutputsForModel.getRows()

<< " - Cols: " << cummulativeOutputsForModel.getColumns() << std::endl;

this->computeModel();

}

else { //trainingGeneration

//Create a training function and use it during the first steps

this->trainingActuations = this->getTrainingActuation();

this->itTrainingActuation = this->trainingActuations.begin();

}

}

void Controller::restoreTrainingData() {

std::ostringstream loadExpression;

loadExpression << "load(’"<< config.get("TRAINING_FROM_STORED_DATA_FILEPATH") << "’);";

loadExpression << "y = " << config.get("TRAINING_FROM_STORED_DATA_OUTPUT_VARIABLE") << ";";

loadExpression << "u = " << config.get("TRAINING_FROM_STORED_DATA_INPUT_VARIABLE") << ";";

loadExpression << "y = y(1:" << config.getInt("TRAINING_FROM_STORED_DATA_SAMPLING_RATE") << ":end,:);";

loadExpression << "u = u(1:" << config.getInt("TRAINING_FROM_STORED_DATA_SAMPLING_RATE") << ":end,:);";

matlabExecutor.evaluate(loadExpression.str());

Matrix yMatrix = matlabExecutor.getMatrix("y");



logger << "Received y data values. Rows: " << yMatrix.getRows() << ". Cols: " << yMatrix.getColumns() <<

std::endl;

cummulativeOutputs = yMatrix;

cummulativeOutputsForModel = yMatrix;

Matrix uMatrix = matlabExecutor.getMatrix("u");

logger << "Received u data values. Rows: " << uMatrix.getRows() << ". Cols: " << uMatrix.getColumns()

<< std::endl;

if (uMatrix.getRows() != yMatrix.getRows()) {

logger << "Error computing restarting values. ’u’ amount of samples should match ’y’ amount of samples.

ySamples:" << yMatrix.getRows() << " uySamples:" << uMatrix.getRows() << std::endl;

throw "Error computing training actuation values.";

}

else {

cummulativeActuation = uMatrix;

cummulativeActuationForModel = uMatrix;

}

matlabExecutor.evaluate("clear y u;");

cummulativeOutputs = this->removeUselessProbeValues(cummulativeOutputs);

cummulativeOutputsForModel = this->removeUselessProbeValues(cummulativeOutputsForModel);

}

void Controller::checkInitialized() {

if (! this->initialized)

throw "The controller was not initialized yet.";

}

Actuation Controller::getActuationForNewStep() {

this->checkInitialized();

if (itTrainingActuation != trainingActuations.end()) {

Actuation act = *itTrainingActuation;

++itTrainingActuation;

logger << "Taking training actuation: [" << act.lower << ", " << act.upper << "]" << std::endl;

return act;

}

else {

logger << "Computing actuation from sensor values ..." << std::endl;

return this->computeActuation();

}

}

std::vector < Actuation > Controller::getTrainingActuation() {

std::stringstream expression;

expression << "training_act = " << config.get("TRAINING_GENERATION_FUNCTION_INVOKE") << ";";

matlabExecutor.evaluate(expression.str());

Matrix trainingAct = matlabExecutor.getMatrix("training_act");

matlabExecutor.evaluate("clear training_act;");

logger << "Received training actuation with " << trainingAct.getRows() << " samples." << std::endl;

if (trainingAct.getColumns() != 2 ) {

logger << "Error computing training actuation values. Expected actuation values per sample: 2 " << std

::endl;

throw "Error computing training actuation values.";

}

std::vector < Actuation > result;

for(size_t i = 0; i < trainingAct.getRows(); ++i) {

result.push_back(this->getActuationFromRow(trainingAct[i]));

}

return result;

}

void Controller::computeModel() {

std::ostringstream expression;

expression << "p = " << config.getInt("CONTROL_PARAMETER_P") << "; gamma= " << config.getFloat("

CONTROL_PARAMETER_GAMMA") << ";";

expression << "q = " << config.get("CONTROL_PARAMETER_Q") << ";";




expression.str(" ");

expression << "limits.max_value = " << config.getInt("CONTROL_LIMITS_MAX_VALUE") << "; limits.min_value =

" << config.getInt("CONTROL_LIMITS_MIN_VALUE") << ";";


matlabExecutor.putMatrix("y", cummulativeOutputsForModel);

matlabExecutor.putMatrix("u", cummulativeActuationForModel);

std::ostringstream saveExpression;

saveExpression << "save model_data."<< processorNumber <<".dat y u;";

matlabExecutor.evaluate(saveExpression.str());

matlabExecutor.evaluate(config.get("SENSORS_NORMALIZE_VARIABLE_Y_SENTENCE"));

matlabExecutor.evaluate(config.get("ACTUATOR_NORMALIZE_VARIABLE_U_SENTENCE"));

matlabExecutor.evaluate("data = iddata(y, u);");

matlabExecutor.evaluate("[A B] = lfd_arx(data.OutputData, data.InputData, p);");

matlabExecutor.evaluate("control_state = lfd_control_lagrange_init(y, u, p, gamma, A, B, limits, q);");

matlabExecutor.evaluate("clear data y u A B limits;");

}

Actuation Controller::computeActuation() {

matlabExecutor.putMatrix("y", cummulativeOutputs);

matlabExecutor.putMatrix("u", cummulativeActuation);

matlabExecutor.evaluate(config.get("SENSORS_NORMALIZE_VARIABLE_Y_SENTENCE"));

matlabExecutor.evaluate(config.get("ACTUATOR_NORMALIZE_VARIABLE_U_SENTENCE"));

matlabExecutor.evaluate("control_state = lfd_control_lagrange(control_state, y, u);");

matlabExecutor.evaluate("next_step_act = control_state.u_k;");

matlabExecutor.evaluate("clear y u;");

Matrix result = matlabExecutor.getMatrix("next_step_act");

if (result.getRows() != 1) {

logger << "Error computing next actuation value. One actuation was expected. Received actuations: "

<< result.getRows() << std::endl;

throw "Error computing next actuation value. One actuation was expected.";

}

else

return this->getActuationFromRow(result[0]);

}

Actuation Controller::getActuationFromRow(const Row& row) {

unsigned int upperActIndex = config.getInt("ACTUATOR_UPPERVALUE_ARRAYINDEX");

unsigned int lowerActIndex = config.getInt("ACTUATOR_LOWERVALUE_ARRAYINDEX");

unsigned int actIndexMax = (lowerActIndex > upperActIndex) ? lowerActIndex: upperActIndex;

if (row.getColumns() < actIndexMax) {

logger << "Error computing actuation values. Received values do not match the configuration indices for

upper and lower actuator. Available indices: " << row.getColumns() << "Upper index:" <<

upperActIndex << ". Lower index:" << lowerActIndex << std::endl;

throw "Error computing next actuation values. Configuration index mismatch";

}

else {

Actuation act;

act.upper = row[upperActIndex];

act.lower = row[lowerActIndex];

return act;

}

}

void Controller::addOutputsForModelComputation(const Row& lastStepOutputs, const Row& actuation) {

if (! modelAlreadyComputed) {

if (cummulativeActuationForModel.getRows() < config.getInt("COMPUTE_MODEL_STEPS")) {

cummulativeActuationForModel.pushRow(actuation);

cummulativeOutputsForModel.pushRow(lastStepOutputs);

}

if (cummulativeActuationForModel.getRows() == config.getInt("COMPUTE_MODEL_STEPS")) {

this->computeModel();

this->modelAlreadyComputed = true;

}

}

}

Matrix Controller::removeUselessProbeValues(const Matrix& values) {

Matrix normalizedMatrix(0, 0);

for(size_t i = 0; i < values.getRows(); ++i) {



Row normalizedRow = this->removeUselessProbeValues(values[i]);

normalizedMatrix.pushRow(normalizedRow);

}

if (values.getRows() > 0) {

logger << "Normalization finished. Input amount of samples for first line. Original:" << values[0].

getColumns() << " normalized:" << normalizedMatrix[0].getColumns() << std::endl;

}

return normalizedMatrix;

}

Row Controller::removeUselessProbeValues(const Row& values) {

Row normalizedRow(0);

for(size_t i = 0; i < values.getColumns(); ++i) {

if (probesToUse.end() != probesToUse.find(i + 1)) {

normalizedRow.pushCell(values[i]);

}

}

return normalizedRow;

}

void Controller::saveLastStepInformation(int currentStep, const Actuation& input, const Row& output) {

this->inputsLogFile << currentStep << ’,’ << input.upper << ’,’ << input.lower << std::endl;

this->outputsLogFile << currentStep;

for(size_t i = 0; i < output.getColumns(); ++i) {

this->outputsLogFile << ’,’ << output[i];

}

this->outputsLogFile << std::endl;

}

Actuation Controller::getActuationFor(int currentStep, const Row& lastStepOutputs) {

Row lastStepOutputsNormalized = this->removeUselessProbeValues(lastStepOutputs);

Actuation act;

if ((invocationsCount % config.getInt("CONTROL_CALCULATE_ACTUATION_AFTER_STEPS")) != 0) {

act = this->previousActuation;

}

else {

logger << "Calculating actuation for step: " << currentStep << std::endl;

act = this->getActuationForNewStep();

Row actRow(2);

actRow[0] = act.upper;

actRow[1] = act.lower;

cummulativeActuation.pushRow(actRow);

cummulativeOutputs.pushRow(lastStepOutputsNormalized);

this->addOutputsForModelComputation(lastStepOutputsNormalized, actRow);

if (cummulativeOutputs.getRows() > config.getInt("CONTROL_PREDICTION_MAX_STEPS")) {

size_t indexFrom = cummulativeOutputs.getRows() - config.getInt("CONTROL_PREDICTION_MAX_STEPS");

cummulativeOutputs = cummulativeOutputs.submatrixByRows(indexFrom, cummulativeOutputs.getRows() -1);

cummulativeActuation = cummulativeActuation.submatrixByRows(indexFrom, cummulativeActuation.getRows()

-1);

}

logger << "Finished: Calculating actuation for step: " << currentStep << std::endl;

}

++this->invocationsCount;

this->previousActuation = act;

this->saveLastStepInformation(currentStep, act, lastStepOutputs);

return act;

}

F.6.8. Logger.h

#ifndef LOGGER__



#define LOGGER__

#include <iostream>

#include <fstream>

class Logger {

private:

bool includePrefix;

std::string prefix;

std::ofstream file;

public:

typedef std::ostream& (*ostream_manipulator)(std::ostream&);

Logger(const std::string& prefix, const std::string& filepath) : includePrefix(true), prefix(prefix),

file(filepath.c_str()) {

if (!file)

std::cerr << "Error al inicializar el log en ’" << filepath << "’." << std::endl;

}

template< typename T >

Logger& operator<<(const T& msg){

if (includePrefix) {

this->file << this->prefix;

std::cout << this->prefix;

includePrefix = false;

}

this->file << msg;

this->file.flush();

std::cout << msg;

std::cout.flush();

return *this;

}

Logger& operator<<(ostream_manipulator pf)

{

this->includePrefix = true;

pf(this->file);

pf(std::cout);

return *this;

}

};

#endif

F.6.9. lfd control lagrange init.m

function [ control_state ] = lfd_control_lagrange_init(y, u, p, gamma, A, B, limits, q)

%Parameters:

% y: m*N matrix with the output values

% u: r*N matrix with inputs

% p: orden del modelo ARX

% A: m*m*(p+1). ARX coefficient matrix

% B: m*r*(p+1). ARX coefficient matrix

% q: m*s weights vector. Should have values between 0 and 1. Q=diag(q) will

% gamma: actuation cost

% be used for the control iteration

% where N: observations count

%

% Usage example:

% [A, B] = lfd_arx(y, u, 2);

% limits.min_value = 0;

% limits.max_value = 3;

% control_state = lfd_control_lagrange_init(y, u, 2, 0.99999, 1/625000, A, B, limits, ones(1,sizeof(y,2)))

;

% next_actuation = lfd_control_lagrange(control_state, y, u);



%In order to get a proper control algorithm, the functional was defined as

% min(y_s^tQy_s+gamma u_s^u_s)

%Where y_s=(y_k y_k+1 ...y_k+s-1)’

% u_s=(u_k u_k+1 ...u_k+s-1)’

%Then, it can be applied as:

% u_s = K * v_p

%Where v_p = (y_k-1..y_k-p u_k-1...u_k-p)’

% y_s = T*u_s + phi*v_p ,

%Then, the K matrix can be computed as

% K = -inv(T’Q*T+gamma*I)*T’*Q*phi

y = y’;

u = u’;

if size(y,2) ~= size(u,2)

error(’lfd_control:input’,’Unable to determine current time step number: k. Samples in y(count: %d) and

u(count: %d) do not match’, size(y,2), size(u,2));

end

%m: y components count

%r: u components count

m = size(y,1);

r = size(u,1);

%s: prediction horizont (should be between 2 and 3 times ’p’)

s=3*p;

% k should match the following rule to allow vp collection: k-p >=1,

k = size(y,2);

if k-p < 1

error(’lfd_control:k_validation’, ’Arguments error. TimeStep and Order should match the following rule:

k-p>=1. k: %d,p: %d’, k, p);

end

%Since Matlab ARX convention includes ’y’ coefficients on the right

%side, starting with the identity matrix, we should re-arrange the info

a = -A(:,:,2:end);

b = B;

% Being y(k) = a_1*y(k-1)+a_2*y(k-2)+...a_p*y(k-p) +

% b_0*u(k)+b_1*u(k-1)+...+b_p*u(k-p)

% The markov parameters can be defined as:

% alpha_1^0 = a_1,..., alpha_1^k = a_1 if k = 0

% ..., alpha_1^k = a_k+1 + sum_1^k(a_i*alpha_1^k-i) if k = 1, 2, .. p-1

% ..., alpha_1^k = sum_1^p(a_i*alpha_1^k-i) if k = p, p+1, ...

% beta_0^0 = b_0,..., beta_0^k = b_0 if k = 0

% ..., beta_0^k = b_k + sum_1^k(a_i*beta_0^k-i) if k = 1, 2, .. p

% ..., beta_0^k = sum_1^p(a_i*beta_0^k-i) if k = p+1,

% p+2, ..

beta00 = b(:,:,1);

beta0 = zeros(m, r, s-1);

beta0(:,:,1) = b(:,:,2) + a(:,:,1)*beta00;

for kk=2:s-1

if kk<=p


for l=1:kk-1;


end

aux=aux+a(:,:,kk)*beta00;

beta0(:,:,kk) = b(:,:,kk+1)+aux;

else


for l=1:p;




end

beta0(:,:,kk)=aux;

end

end

clear aux

% T: [beta_0^0 0 0 ... 0;

% beta_0^1 beta_0^0 0 ... 0;

% beta_0^2 beta_0^1 beta_0^0 0 ... 0;

% ...

% beta_0^s-1 ... beta_0^1 beta_0^0]

%T y phi se definen a partir de los parometros de markov que se encuentran en A y B

T=zeros(m*s,r*s);

T_column =zeros(m*s,r);

T_column(1:m,:)=beta00;

for j=2:s;

T_column((j-1)*m+1:j*m,:)=beta0(:,:,j-1);

end;

for column = 1:s

T(m*(column-1)+1:m*s, r*(column-1)+1:r*column) = T_column(1:(m*s - (column-1)*m),:);

end;

% phi: [alpha_1^0 ... alpha_p^0 beta_1^0 ... beta_p^0 ;

% ... ;

% alpha_1^s-1 ... alpha_p^s-1 beta_1^s-1 ... beta_p^s-1]

%

% alpha_k^j = alpha_1^j-1 * a_k + alpha_k+1^j-1 if k= 1, 2, .., p-1

% alpha_1^j-1 * a_k if k= p

% beta_k^j = alpha_1^j-1 * b_k + beta_k+1^j-1 if k= 1, 2, .., p-1

% alpha_1^j-1 * b_k if k= p

phi=zeros(m*s,p*(m+r));

% The variables bellow adopt the following syntax:

% a(:,:,subIndex) -> a_subIndex == alpha_subIndex^0

% b(:,:,subIndex+1) -> b_subIndex == beta_subIndex^0

% alpha(:,:,superIndex,subIndex) -> alpha_subIndex^superIndex

% beta(:,:,superIndex,subIndex) -> beta_subIndex^superIndex

for kk=1:p-1;

alpha(:,:,1,kk)=a(:,:,1)*a(:,:,kk)+a(:,:,kk+1);

end;

alpha(:,:,1,p)=a(:,:,1)*a(:,:,p);

for j=2:s-1;

for kk=1:p-1;

alpha(:,:,j,kk)=alpha(:,:,j-1,1)*a(:,:,kk)+alpha(:,:,j-1,kk+1);

end;

alpha(:,:,j,p)=alpha(:,:,j-1,1)*a(:,:,p);

end

for kk=1:p-1;

beta(:,:,1,kk)=a(:,:,1)*b(:,:,kk+1)+b(:,:,kk+2);

end

beta(:,:,1,p)=a(:,:,1)*b(:,:,p+1);

for j=2:s-1;

for kk=1:p-1;

beta(:,:,j,kk)=alpha(:,:,j-1,1)*b(:,:,kk+1)+beta(:,:,j-1,kk+1);

end;

beta(:,:,j,p)=alpha(:,:,j-1,1)*b(:,:,p+1);

end



phi(1:m,:) = [reshape(a, m, m*p) reshape(b(:,:,2:end), m, r*p)];

for j=2:s

phi((j-1)*m+1:j*m,:) = [reshape(alpha(:,:,j-1,:), m, m*p) reshape(beta(:,:,j-1,:), m, r*p)];

end

% size(T’*Q*T) = r*s;

gammaIdentitySize = r*s;

% Since: u_s = K*vp and only ’r’ rows are necessary from u_s, it is possible to reduce the computation

taking ’r’ rows from K

% Let K=-inv(gamma*eye(n)+T’*Q*T)*T’*Q*F, so ’r’ rows are necessary

% from -inv(gamma*eye(n)+T’*Q*T) to compute the first ’r’ u_s components.

Q=kron(eye(s), diag(q));

invGammaTTQT = -pinv(gamma*eye(gammaIdentitySize) + T’*Q*T);

control_state.K_r = invGammaTTQT(1:r, :) * T’ * Q * phi;






control_state.gamma = gamma;

control_state.u_k = zeros(r, 1);

end

F.6.10. lfd control lagrange.m

function control_state = lfd_control_lagrange(control_state, y,u)

y = y’;

u = u’;





K_r = control_state.K_r;

k = size(y, 2) + 1;

vp = zeros(p*m+p*r, 1);

for i=1:p

vp((i-1)*m+1:i*m) = y(:,k-i);

end

offset = m*p;

for i=1:p

vp((i-1)*r+1+offset:i*r+offset) = u(:,k-i);

end;

%Finally: u_s = K*vp

%where u_s:control value from k to k+s-1

%So, lets take the first r values to compute only u_s(k)

u_k = K_r * vp;






end



F.6.11. MatlabExecutor.h

#ifndef MATLABEXECUTOR__

#define MATLABEXECUTOR__

#include <vector>

#include "engine.h"

#include "Logger.h"

#include "Matrix.h"

class MatlabExecutor {

private:

Engine *ep;

Logger& logger;

public:

MatlabExecutor(Logger& logger);

~MatlabExecutor();

void putMatrix(const std::string& matrixVariableName, Matrix& values);

Matrix getMatrix(const std::string& matrixVariableName);

void evaluate(const std::string& expression);

double evaluateScalar(const std::string& expression);

};

#endif

F.6.12. MatlabExecutor.cpp

#include <string.h>

#include "engine.h"


MatlabExecutor::MatlabExecutor(Logger& logger) : logger(logger) {

logger << "Opening engine..." << std::endl;

if (!(ep = engOpen("\0"))) {

fprintf(stderr, "\nCan’t start MATLAB engine\n");

throw "Unable to start MATLAB engine";

}

}

MatlabExecutor::~MatlabExecutor() {

if (!(ep = engOpen("\0"))) {

logger << "Closing engine..." << std::endl;

engClose(ep);

}

}

void MatlabExecutor::putMatrix(const std::string& matrixVariableName, Matrix& values) {

if (values.getRows() == 0 || values.getColumns() == 0)

throw "Values are required";

mwSignedIndex rows = values.getRows();

mwSignedIndex cols = values.getColumns();

logger << "Calling Matlab for matrix " << rows << "x" << cols << std::endl;

mxArray *matrix = mxCreateDoubleMatrix(rows, cols, mxREAL);

double *ptrMatrix = mxGetPr(matrix);

logger << "Copying matrix..." << std::endl;

for(mwSignedIndex i = 0; i < rows; ++i) {

for(mwSignedIndex j = 0; j < cols; ++j) {

*(ptrMatrix + (j*rows) + i) = values.get(i,j);

}

}

logger << "Putting matrix. Variable: " << matrixVariableName << std::endl;

engPutVariable(ep, matrixVariableName.c_str(), matrix);

mxDestroyArray(matrix);



}

Matrix MatlabExecutor::getMatrix(const std::string& matrixVariableName) {

logger << "Getting matrix. Variable: " << matrixVariableName << std::endl;

mxArray *result;

if ((result = engGetVariable(ep,matrixVariableName.c_str())) == NULL) {

logger << "There was an error getting the values from variable ’" << matrixVariableName << "’" << std::

endl;

throw "There was an error getting the values from a variable.";

}

else {

mwSize dimensionsCount = mxGetNumberOfDimensions(result);

if (dimensionsCount > 2) {

logger << "Matrices are prepared to be 2D only. The variable ’" << matrixVariableName << "’ was a ";

logger << dimensionsCount << "D." << std::endl;

throw "Matrices are prepared to be 2D only.";

}

else {

const mwSize* dimensions = mxGetDimensions(result);

mwSize rows = dimensions[0];

mwSize cols = dimensions[1];

Matrix matrix(rows, cols);

double* resultPtr = mxGetPr(result);

for(size_t i = 0; i < rows; ++i) {

for(size_t j = 0; j < cols; ++j) {

double value = *(resultPtr + (j*rows) + i);

matrix.set(i,j, value);

}

}

mxDestroyArray(result);

return matrix;

}

}

}

void MatlabExecutor::evaluate(const std::string& expression) {

#define BUFSIZE 1024

static char buffer[BUFSIZE+1];

memset(buffer, 0, sizeof(buffer));

engOutputBuffer(ep, buffer, sizeof(buffer) - 1);

logger << "Matlab. Evaluating: " << expression << std::endl;

engEvalString(ep, expression.c_str());

logger << "Matlab. Evaluation result: " << buffer << std::endl;

}

double MatlabExecutor::evaluateScalar(const std::string& expression) {

evaluate(expression);

mxArray *ans = NULL;

if ((ans = engGetVariable(ep,"ans")) == NULL) {

logger << "There was an error retrieving the answer of a previusly evaluated command." << std::endl;

throw "Error retrieving the answer of a previosly evaluated command.";

}

else {

double result = mxGetScalar(ans);

mxDestroyArray(ans);

return result;

}

}

F.6.13. Matrix.h

#ifndef MATRIX__



#define MATRIX__

typedef double Cell;

class Row {

private:

std::vector< Cell > data;

public:

Row(size_t columns) {

this->data.resize(columns);

}

Row(const std::vector< Cell >& data) : data(data) {

}

void resize(size_t columns) {

data.resize(columns);

}

Cell& operator[](size_t column) {

return data[column];

}

const Cell& operator[](size_t column) const {

return data[column];

}

std::vector< Cell > toCellsVector() {

return this->data;

}

void pushCell(const Cell& value) {

data.push_back(value);

}

size_t getColumns() const {

return data.size();

}

};

class Matrix {

private:

std::vector< Row > data;

public:

Matrix(size_t rows, size_t columns): data(rows, Row(columns)) {

}

const Cell& get(size_t row, size_t col) const {

return data[row][col];

}

void set(size_t row, size_t col, Cell& value) {

data[row][col] = value;

}

const Row& getRow(size_t row) const {

return this->data[row];

}

void pushRow(const Row& row) {

data.push_back(row);

}

size_t getRows() const {

return this->data.size();

}

size_t getColumns() const {

if (this->getRows() == 0)

return 0;

else

return this->data[0].getColumns();

}

std::vector< Row > toRowsVector() {

return this->data;

}

Row& operator[](size_t row) {

return data[row];

}

const Row& operator[](size_t row) const {



return data[row];

}

Matrix submatrixByRows(size_t rowIndexFrom, size_t rowIndexTo) {

Matrix result(rowIndexTo - rowIndexFrom + 1, this->getColumns());

size_t j = 0;

for(size_t i = rowIndexFrom; i <= rowIndexTo; ++i) {

result[j++] = this->data[i];

}

return result;

}

};

#endif

F.6.14. Parser.h

#ifndef PARSER__

#define PARSER__

#include <string>

#include <vector>

#include "Logger.h"

#include "Matrix.h"

class Parser {

private:

Logger& logger;

unsigned int probesCount;

void processLine(const std::string& line, unsigned int& currentStep, Row& probeValues);

Row readValuesForStep(const std::string& probesFilepath, unsigned int stepNumber);

Row readValuesWithRetry(const std::string& probesFilepath, unsigned int stepNumber, unsigned int retries)

;

public:

Parser(Logger& logger, unsigned int probesCount);

Row readValues(const std::string& probesFilepath, unsigned int stepNumber);

};

#endif

F.6.15. Parser.cpp

#include <iostream>

#include <fstream>

#include <sstream>

#include <limits>

#include <algorithm>


#include "Parser.h"

Parser::Parser(Logger& logger, unsigned int probesCount) : logger(logger), probesCount(probesCount) {

}

void Parser::processLine(const std::string& line, unsigned int& currentStep, Row& probeValues) {

unsigned int aux;

std::istringstream converter(line);

converter >> aux;

if (! converter.fail()) {

float auxTime;

converter >> auxTime;

currentStep = aux;

logger << "Parse successful. Step read: " << currentStep << std::endl;

for(int i = 0; i < this->probesCount; ++i) {



Cell value;

converter >> value;

probeValues[i] = value;

}

}

}

Row Parser::readValuesForStep(const std::string& probesFilepath, unsigned int stepNumber) {

Row probeValues(this->probesCount);

std::ifstream probes(probesFilepath.c_str());

probes.seekg(0, std::ios::beg);

std::ifstream::pos_type posBegin = probes.tellg();

probes.seekg(-1, std::ios::end);

unsigned int currentStep = std::numeric_limits<unsigned int>::max();

std::string line;

char buffer;

do {

buffer = probes.peek();

if (buffer != ’\n’ || probes.tellg() == posBegin)

line += buffer;

else {

std::reverse(line.begin(), line.end());

processLine(line, currentStep, probeValues);

line.clear();

}

probes.seekg(-1, std::ios::cur);

} while (probes.tellg() != posBegin && probes.good() && currentStep > stepNumber);

if (currentStep == stepNumber)

return probeValues;

else

throw "El archivo de muestras no posee el paso indicado. Posiblemente aon no fue escrito y se deba

reintentar.";

}

Row Parser::readValuesWithRetry(const std::string& probesFilepath, unsigned int stepNumber, unsigned int

retries) {

#define MAX_RETRIES 4

#define SECS_BETWEEN_RETRIES 5

try {

return readValuesForStep(probesFilepath, stepNumber);

}

catch(const char* msg) {

if (retries < MAX_RETRIES) {

sleep(SECS_BETWEEN_RETRIES);

logger << std::endl << "Step:" << stepNumber << " not found. Retrying parse: " << retries + 1 << std

::endl;

return readValuesWithRetry(probesFilepath, stepNumber, retries + 1);

}

else

throw;

}

}

Row Parser::readValues(const std::string& probesFilepath, unsigned int stepNumber) {

return readValuesWithRetry(probesFilepath, stepNumber, 0);

}

F.6.16. SaturneCommunicator.h

#ifndef SATURNE_COMMUNICATOR__



#define SATURNE_COMMUNICATOR__

#include <iostream>

#include "Logger.h"

class SaturneCommunicator {

public:

int waitForStep(std::istream& semaphore, Logger& logger);

void send(std::ofstream& actuatorFile, Logger& logger, double value);

};

#endif

F.6.17. SaturneCommunicator.cpp

#include <sstream>

#include "SaturneCommunicator.h"

int SaturneCommunicator::waitForStep(std::istream& semaphore, Logger& logger) {

unsigned int semaphoreStepNumber;

logger << "Waiting..." << std::endl;

semaphore >> semaphoreStepNumber;

if (semaphore.good()) {

logger << " ...Signal received: ’" << semaphoreStepNumber << "’. Resuming..." << std::endl;

return semaphoreStepNumber;

}

else {

logger << " ...File Closed or damaged. Resuming..." << std::endl;

return -1;

}

}

void SaturneCommunicator::send(std::ofstream& actuatorFile, Logger& logger, double value) {


converter << value;

std::string strValue;

converter >> strValue;

logger << "Sending ’" << strValue << "’." << std::endl;

actuatorFile << strValue <<std::endl;

}


G Codigos Fuente de Avances Experi-mentales

G.1. Pruebas de Concepto de Captura de Imagenes

G.1.1. PixelFly qe

#define GAIN 1

#define DELAY 0 //ms

#define EXPOSURE_TIME 5 //ms

#define ROIX 2 //from 1 to 20

#define ROIY 2 //from 1 to 20

int main(int argc, char* argv[]) {

int totalSnapshots;

std::cout << "Qty of snapshots to take: ";

std::cin >> totalSnapshots;

int camId;

CAMINFO camData[8];

int boardNumber = 0;

int error;

if (error = SELECT_CAMERA("pixelfly", boardNumber, &camId, camData))

showErrorAndClose(error);

else {

if (error = SETUP_CAMERA(camId, camData, 0, 0, 0, 1, ROIX, 1, ROIY, 1, 1, GAIN, DELAY,

EXPOSURE_TIME))


else {

time_t beginTime, endTime;

time(&beginTime);

int snapshotNumber = 0;

while (! error && snapshotNumber < totalSnapshots) {

if (error = SNAP(camId, camData, 0))


else {

if (error = GETIMAGE(camId, camData, 2000))


else

// image in memory at this point

}

snapshotNumber++;

}

time(&endTime);

std::cout << std::endl << "Tiempo Promedio por imagen: " << 1000.0 * (double)difftime(endTime,

beginTime) / (float)totalSnapshots << "ms." << std::endl;

}

CLOSE_CAMERA(camId, camData);

}

return 0;

}

212


G.1.2. Pulnix

#include <cstdio>

#include <iostream>

#include "pxd.h"

#include "iframe.h"

#define IMAGEWIDTH 738

#define IMAGEHEIGHT 484

using namespace std;

int main(int argc, char* argv[])

{

PXD pxd;

FRAMELIB frameLib;

long hFG=0;

FRAME* pFRAME=0;

char arcFileName[20];

static int num=0;

int NO_FRAMES;

cout << "Ingrese el Nro de imagenes a capturar (30 fps)";

cin >> NO_FRAMES;

imagenation_OpenLibrary(".\\PXD_32.DLL", &pxd, sizeof(PXD));

imagenation_OpenLibrary (".\\frame_32.dll", &frameLib, sizeof(FRAMELIB));

CAMERA_TYPE *configInMem;

char configFile[] = {"default.cam"};

printf(" %s\n",configFile);

printf("Incio de Soft %d imagenes \n\n",NO_FRAMES);

hFG= pxd.AllocateFG (-1);

configInMem = pxd.LoadConfig(configFile); // load structure from file

pxd.SetCameraConfig(hFG,configInMem); // use the configuration file here

pxd.FreeConfig(configInMem);

pFRAME = pxd.AllocateBufferList (pxd.GetWidth(hFG), pxd.GetHeight(hFG), pxd.GetPixelType(hFG),NO_FRAMES);

printf("Incio de Captura %d imagenes \n\n",NO_FRAMES);

pxd.Grab (hFG, pFRAME,IMMEDIATE);

for(num= 0; num<NO_FRAMES ; num++) {

sprintf_s(arcFileName,"30fps %.3d.bmp", num);

printf(" %s \n",arcFileName);

frameLib.WriteBMP ( frameLib.ExtractPlane(pFRAME,num), arcFileName,1);

}

frameLib.FreeFrame (pFRAME);

pxd.FreeFG (hFG);

return 0;

}

G.1.3. SpeedCam Mini Vis

import com.artho.visart.plugins.minivis.internal.jni.MinivisFactory;

import com.artho.visart.util.TypedNetAddress;

import com.artho.visart.plugins.minivis.Proxy;

import com.artho.visart.plugins.minivis.internal.jni.CallbackConsumer;

import com.artho.visart.plugins.minivis.internal.jni.MDriverException;

import com.artho.visart.plugins.minivis.internal.jni.MFrameInfo;

class DummyConsumer implements CallbackConsumer {

public void modeChanged(int paramInt){

}

Apendice G. Codigos Fuente de Avances Experimentales 213


public void statusChanged(int paramInt) {

}

public void shutterChanged(boolean paramBoolean, short paramShort) {

}

}

public class Application {

public static void main(String[] arguments) {

System.out.println("Getting MinivisFactory...");

MinivisFactory factory = MinivisFactory.getInstance();

try {

System.out.println("Discovering cameras...");

factory.discover();

System.out.println("Getting known devices...");

TypedNetAddress[] addresses = factory.getKnownDevices();

System.out.println("Found " + addresses.length + " devices.");

System.out.println("Getting camera from MAC...");

DummyConsumer callbackConsumer = new DummyConsumer();

Proxy camera = factory.getCamera("MAC", callbackConsumer);

System.out.println("Connecting camera...");

camera.connect();

System.out.println("Triggering camera...");

camera.trigger();

System.out.println("Getting image...");

MFrameInfo frameInfo = new MFrameInfo();

byte[] frameBytes = camera.getFrame(-1, -1, frameInfo);

System.out.println("Get Frame result: " + frameInfo.width + "x" + frameInfo.height + " - " +

frameBytes.length + " bytes.");

}

catch(MDriverException e) {

e.printStackTrace();

}

}

}

G.2. Pruebas de Concepto de Ident. de Sist. en CUDA C/C++y C++/GSL

Los archivos de codigo fuente que se adjuntan a continuacion, representan una prueba deconcepto sobre la posibilidad de implementar el algoritmo de identificacion del sistema en C++.Para esta nueva version del sistema se utilizaron 2 librerıas de algebra lineal con punto flotante dedoble precision: GSL y CUDA/CULA. En el ultimo caso se emplean las capacidades de GPGPUdel ordenador. Una comparacion de los resultados obtenidos se puede encontrar en el ApendiceC.2.

G.2.1. main.cpp

#include <iostream>

#include <sstream>

#include <fstream>

#include "common/CULAContext.h"

#include "common/Exception.h"

#include "common/Matrix.h"

#include "arxEngine/ArxSystemIdentification.h"

void readFromFile(const std::string& filepath, Matrix<t_sample>& target)



{

std::ifstream file(filepath.c_str());

if (file)

file >> target;

else

throw Exception("The file could not be opened for reading");

}

void writeToFile(const std::string& filepath, const Matrix<t_sample>& target)

{

std::ofstream file(filepath.c_str());

if (file)

file << target;

else

throw Exception("The file could not be opened for writing");

}

void calculate(int order, Matrix<t_sample>& input, Matrix<t_sample>& output, const std::string&

outputFolder)

{

ArxSystemIdentification arx(order, input, output);

arx.estimateModel();

std::string normalizedOutputFolder = outputFolder;

if (*outputFolder.rbegin() != ’/’ && *outputFolder.rbegin() != ’\\’)

normalizedOutputFolder.append("\\");

for(int i = 0; i < order+1; ++i)

{

std::stringstream aFilepath, bFilepath;

aFilepath << normalizedOutputFolder << "A" << i << ".txt";

bFilepath << normalizedOutputFolder << "B" << i << ".txt";

writeToFile(aFilepath.str(), arx.getAModel(i));

writeToFile(bFilepath.str(), arx.getBModel(i));

}

}

int main(int argc, char* argv[])

{

if (argc != 8)

{

std::cout << "ArxGSL usage:" << std::endl;

std::cout << "ArxGSL.exe <arx-order> <samples-qty> <input samples-filepath> <input-components-dimension

> <output samples-filepath> <output-components-dimension> <output-folder>" << std::endl;

std::cout << "Output: A0.txt A1.txt B0.txt B1.txt will be written into the <output-folder>" << std::

endl;

return -1;

}

else

{

CULAContext context;

int order = atoi(argv[1]);

int samples = atoi(argv[2]);

char* uFilepath = argv[3];

int inputDim = atoi(argv[4]);

char* yFilepath = argv[5];

int outputDim = atoi(argv[6]);

char* outputFolder = argv[7];

try

{

context.init();

Matrix<t_sample> input(samples, inputDim);

Matrix<t_sample> output(samples, outputDim);

readFromFile(uFilepath, input);

readFromFile(yFilepath, output);

calculate(order, input, output, outputFolder);

return 0;

}

catch(const std::exception& ex)



{

std::cerr << "There was an unexpected error:" << ex.what() << std::endl;

return -1;

}

}

}

G.2.2. arxEngine/ArxSystemIdentification.h

#ifndef ARXSYSTEMIDENTIFICATION__H

#define ARXSYSTEMIDENTIFICATION__H

#include "../common/Matrix.h"

#include <vector>

typedef float t_sample;

class ArxSystemIdentification

{

private:

size_t order;

size_t m;

size_t r;

size_t samples;

const Matrix<t_sample>& input;

const Matrix<t_sample>& output;

std::vector< Matrix<t_sample> > estimatedA;

std::vector< Matrix<t_sample> > estimatedB;

public:

ArxSystemIdentification(int order, const Matrix<t_sample>& input, const Matrix<t_sample>& output);

void estimateModel();

const Matrix<t_sample>& getAModel(int index) const;

const Matrix<t_sample>& getBModel(int index) const;

};

#endif

G.2.3. arxEngine/ArxSystemIdentification.cpp

#include "ArxSystemIdentification.h"

#include "../common/Exception.h"

ArxSystemIdentification::ArxSystemIdentification(int order, const Matrix<t_sample>& input, const Matrix<

t_sample>& output)

:order(order), input(input), output(output)

{

this->m = output.getColumns();

this->r = input.getColumns();

if (output.getRows() != input.getRows())

throw Exception("Invalid dimensions. The input and output samples quantity should match");

else if (output.getRows() <= this->order + 1)

throw Exception("Not enough samples to compute the given order. The samples quantity should be higher

than the order plus 1.");

else

this->samples = output.getRows();

}

void ArxSystemIdentification::estimateModel()

{

/* Model definition:

y(k)+a_1*y(k-1)+a_2*y(k-2)+...a_na*y(k-na) = b_1*u(k)+b_2*u(k-1)+...+b_nb*u(k-(nb-1))

where



y(k) is the output at time k with dimension m x 1.

u(k) is the input at time k with dimension r x 1.

a_1,..a_na matrices of m x m

b_1,...b_nb matrices of m x r

The algorithm will consider na = nb-1 and N=qty of samples.

*/

size_t na = this->order;

size_t nb = na + 1;

size_t N = this->samples;

/*

Let y : mxN / j-th column has the j-th time sample.

Let u : rxN / j-th column has the j-th time sample.

*/

Matrix<t_sample> y = this->output.transpose();

Matrix<t_sample> u =this->input.transpose();

/*

Let fi : na*m+nb*r x N -> Regresion vector for k time step being:

/ fi(k column) = [-y(k-1 to k-na time samples); u(k to k-(nb-1) time samples)]

= [-y(:,k-1); ...;-y(:,k-na);u(:,k);u(:,k-1);...;u(:,k-(nb-1))]

when k in [na+1,N] = [nb,N]

/ fi(k colum = [0; ... ; 0] when k in [1,na] = [1,nb-1]

*/

Matrix<t_sample> fi(na*m+nb*r, N, true);

// fi should take na columns of y and nb columns from u in order to create one single column.

// fi will take N columns as above but slicing the y and u column indexes each.

for(size_t fiColumn = na; fiColumn < N; ++fiColumn) {

size_t fiRow = 0;

int columnOffset = fiColumn - (int)na;

//iterates columns na-1 to 0 for fiColumn=na and N-2 to N-na-1 for fiColumn=N-1

for(int yColumn = na - 1 + columnOffset; yColumn >= 0 + columnOffset; --yColumn) {

for(size_t yRow = 0; yRow < m; ++yRow) {

fi.set(fiRow, fiColumn, -y.get(yRow, yColumn));

++fiRow;

}

}

//iterates columns nb-1 to 0 for fiColumn=na and N-1 to N-na-1=N-nb for fiColumn=N-1

for(int uColumn = nb - 1 + columnOffset; uColumn >= 0 + columnOffset; --uColumn) {

for(size_t uRow = 0; uRow < r; ++uRow) {

fi.set(fiRow, fiColumn, u.get(uRow, uColumn));

++fiRow;

}

}

}

/*

Let reg: m*(na*m+nb+r) x m*(N-na) -> Regresion matrix

reg(k to column block) = [fi(1,na+1 + (k-1))*eye(m); fi(2,na+1 + (k-1))*eye(m);...; fi(na*m+nb*r, na

+1 + (k-1))*eye(m)] when k in [1,N-na]

and

Y = reshape(y(:, na+1:end), m*(N-na), 1);

*/

Matrix<t_sample> reg(m*(na*m+nb*r), m*(N-na), true);

for(size_t kBlock = 0; kBlock < N-na; ++kBlock) {

//fiColumn from na to N-1

size_t fiColumn = kBlock+na;

for(size_t fiRow = 0; fiRow < (na*m+nb*r); ++fiRow) {

t_sample value = fi.get(fiRow, fiColumn);

for(size_t iBlock = 0; iBlock < m; ++iBlock) {

reg.set(fiRow * m + iBlock, kBlock * m + iBlock, value);

}



}

}

Matrix<t_sample> Y(m*(N-na),1);

for(size_t yColumn = na; yColumn < N; ++yColumn) {

for(size_t yRow = 0; yRow < m; ++yRow) {

Y.set((yColumn-na)*m + yRow, 0, y.get(yRow, yColumn));

}

}

/*

Let F: m*(N-na) x m*(na*m+nb*r)+1)

F = [reg’ Y]

*/

Matrix<t_sample> F(m*(N-na), m*(na*m+nb*r)+1);

for(size_t regRow = 0; regRow < m*(na*m+nb*r); ++regRow) {

for(size_t regCol = 0; regCol < m*(N-na); ++regCol) {

F.set(regCol, regRow, reg.get(regRow, regCol));

}

}

for(size_t yRow = 0; yRow < m*(N-na); ++yRow) {

F.set(yRow, m*(na*m+nb*r), Y.get(yRow, 0));

}

/*

Compute the QR decomposition of F and keep the R part.

Then, collect R1 and R2 according to:

R1 = R(1:d, 1:d);

R2 = R(1:d, 1:d+1);

being d = na*m*m+nb*r*m

*/

int d = na*m*m+nb*r*m;

Matrix<t_sample> qr = F.decomposeQRGsl();

Matrix<t_sample> rDecomp = qr.getTriu();

Matrix<t_sample> r1 = rDecomp.getSubmatrix(0, 0, d-1, d-1);

Matrix<t_sample> r2 = rDecomp.getSubmatrix(0, d, d-1, d);

/*

Then, we disregard Q part and unnecesary R values to estimate the A and B coefficients:

th = pinv(R1) * R2;

*/

Matrix<t_sample> th = r1.invert().multiply(r2);

/*

Collect the A and B parameters from within th

*/

Matrix<t_sample> A0(m, m, true);

for(size_t i = 0; i < m; ++i)

{

A0.set(i,i,1);

}

this->estimatedA.push_back(A0);

for(size_t k = 0; k < na; ++k)

{

//Take the submatrix as per: a(:,:,j)=reshape(th(1+(j-1)*m*m:j*m*m),m,m);

Matrix<t_sample> Ak = th.getRow(k*m*m, (k+1)*m*m-1);

this->estimatedA.push_back(Ak.reshape(m,m));

}

for(size_t k = 0; k < nb; ++k)

{

//Take the submatrix as per: b(:,:,j)=reshape(th(1+na*m*m+(j-1)*m*r:1+na*m*m+(j-1)*m*r+m*r-1),m,r);

Matrix<t_sample> Bk = th.getRow(na*m*m + k*m*r, na*m*m + (k+1)*m*r - 1);

this->estimatedB.push_back(Bk.reshape(m,r));

}

}

const Matrix<t_sample>& ArxSystemIdentification::getAModel(int index) const

{



return this->estimatedA.at(index);

}

const Matrix<t_sample>& ArxSystemIdentification::getBModel(int index) const

{

return this->estimatedB.at(index);

}

/*

Source code in Matlab:

y = y’;

u = u’;

na = p;

nb = na+1;

%Modelo de partida:

% y(k)+a_1*y(k-1)+a_2*y(k-2)+...a_na*y(k-na)=

% =b_1*u(k)+b_2*u(k-1)+...+b_nb*u(k-(nb-1))

%donde

% y(k) es la salida en el tiempo k, vector de mx1

% u(k) es la entrada en el tiempo k, vector de rx1

% a_1,..a_na matrices de mxm

% b_1,...b_nb matrices de mxr

%venimos considerando na=nb-1

%De acuerdo con esta escritura, se considera

% N:cantidad de observaciones

% y: matriz de observaciones de las salidas, de mxN; es decir, en la

%columna j la salida en el tiempo j

% u: matriz de las observaciones de las entradas, de rxN; es decir, en la columna j la entrada en el

tiempo j

%segon Ljung, se define el vector de regresion en el tiempo k como:

% fi(k)=(-y(k-1), ...,-y(k-na),u(k), u(k-1),...u(k-(nb-1))’

% y el "vector" de parometros a calcular mp’=(a_1,...,a_na,_1,...b_nb)

[m,N] = size(y);

[r,N] = size(u);

%se construye fi con los valores de regresion, considerando los tiempos de

%na+1 en adelante

fi = zeros(na*m+nb*r,N);

for j=na+1:N

fi(:,j)=[reshape(-y(:, j-1:-1:j-na), na*m, 1); ...


end

%se construye la matriz de regresion

fi2 = fi(:, na+1:end);

reg = zeros(m*size(fi2,1), m*(N-na));

for j=1:N-na

reg(:, 1+(j-1)*m:j*m) = kron(fi2(:,j), eye(m));

end

%REVISAR SIG LINEA



F = [reg’ Y];

R = triu(qr(F));

%d: cantidad de nomeros a determinar para armar las matrices %del modelo

d = na*m*m+nb*r*m;

R0 = R(1:d+1,1:d+1);

R1 = R0(1:d,1:d);

R2 = R0(1:d,end);



%se desecha la parte Q de la matriz F y se resuelve por cuad. monimos

%th: resultante que contiene los valores para armar las matrices A y B

th = pinv(R1) * R2;



for j=1:na


end

for j=1:nb


end


A(:,:,1) = eye(m);

A(:,:,2:end) = a(:,:,:);

B = b;

*/

G.2.4. common/Matrix.h

#ifndef MATRIX__H

#define MATRIX__H

#include <iostream>

#include <iomanip>

#include <fstream>

#include <sstream>

#include <cstdlib>

#include <exception>

#include <cstring>

#include "../common/Exception.h"

#include <gsl/gsl_matrix.h>

#include <gsl/gsl_permutation.h>

#include <gsl/gsl_blas_types.h>

#include <gsl/gsl_linalg.h>

#include <gsl/gsl_blas.h>

#include <cula_lapack.h>

#include <cula_blas.h>

#define GSL_DLL

#define PRINT_MATRIX_CELL_VALUE_PRECISION 10

#define MINIMUN_ACCEPTED_EIGENVALUE_ON_SVD 0.000001

template < typename T = float>

class Matrix

{

private:

gsl_matrix* inner;

size_t rows;

size_t columns;

public:

Matrix(size_t rows, size_t columns, bool defaultToZero = false)

:rows(rows), columns(columns)

{

if (defaultToZero)

inner = gsl_matrix_calloc(rows, columns);

else

inner = gsl_matrix_alloc(rows, columns);

}

Matrix(const Matrix<T>& toCopy)

:rows(toCopy.rows), columns(toCopy.columns)

{




gsl_matrix_memcpy(inner, toCopy.inner);

}

Matrix(gsl_matrix* matrix, bool manageMemory)

:rows(matrix->size1), columns(matrix->size2)

{

if (manageMemory) {

inner = matrix;

}

else {


gsl_matrix_memcpy(inner, matrix);

}

}

Matrix<T>& operator=(const Matrix<T>& toCopy)

{

if (this != &toCopy)

{

gsl_matrix_free(inner);

this->rows = toCopy.rows;

this->columns = toCopy.columns;


gsl_matrix_memcpy(inner, toCopy.inner);

}

return *this;

}

Matrix<T> reshape(size_t newRows, size_t newColumns) const

{

if (newRows*newColumns != this->rows*this->columns)

{

std::stringstream message;

message << "It is not possible to reshape a " << this->rows << "x" << this->columns << " to a " <<

newRows << "x" << newColumns << " matrix. Amount of elements should match.";

throw Exception(message.str().c_str());

}

Matrix<T> newShape(newRows, newColumns);

size_t iNew = 0;

size_t jNew = 0;

for(size_t j = 0; j < this->columns; ++j)

{

for(size_t i = 0; i < this->rows; ++i)

{

newShape.set(iNew, jNew, this->get(i,j));

if (iNew == newRows - 1)

{

iNew = 0;

++jNew;

}

else

++iNew;

}

}

return newShape;

}

Matrix<T> transpose() const

{

gsl_matrix* transposed = gsl_matrix_alloc(this->columns, this->rows);

gsl_matrix_transpose_memcpy(transposed, inner);

return Matrix<T>(transposed, true);

}

Matrix<T> getTriu() const

{

Matrix<T> triu(this->rows, this->columns, true);


{



for(size_t j = i; j < this->columns; ++j)

{

triu.set(i,j, this->get(i,j));

}

}

return triu;

}

Matrix<T> decomposeQRCULA() const

{

int lda = this->rows;

int matrixRank = this->rows > this->columns? this->columns: this->rows;

Matrix<T> transposed = this->transpose();

T* aCula = transposed.toArrayRowMajor();

T* tauCula = (T*) malloc(matrixRank*sizeof(T));

culaStatus status = culaSgeqrf(this->rows, this->columns, aCula, lda, tauCula);

checkStatus(status);

Matrix<T> resultTransposed(this->columns, this->rows);

resultTransposed.fromArrayRowMajor(aCula);

free(aCula);

free(tauCula);

return resultTransposed.transpose();

}

Matrix<T> decomposeQRGsl() const

{


gsl_matrix* copy = gsl_matrix_alloc(this->rows, this->columns);

gsl_matrix_memcpy(copy, inner);

gsl_vector* tau = gsl_vector_alloc(matrixRank);

gsl_linalg_QR_decomp (copy, tau);

gsl_vector_free(tau);

return Matrix<T>(copy, true);

}

Matrix<T> pseudoInvertCULA()

{

//A = U S V^T where U:mxm, S:mxn, V:nxn

Matrix<T> transposed = this->transpose();

int lda = this->rows;

int ldu = this->rows;

int ldvt = this->columns;


T* aCula = transposed.toArrayRowMajor();

T* sCula = (T*) malloc(matrixRank*sizeof(T));

T* uCula = (T*) malloc(ldu*this->rows*sizeof(T)); //[u] = mxm

T* vtCula = (T*) malloc(ldvt*this->columns*sizeof(T)); //[v] = nxn

//char jobu, char jobvt, int m, int n, culaFloat* a, int lda, culaFloat* s, culaFloat* u, int ldu,

culaFloat* vt, int ldvt);

//culaStatus status = culaSgesvd(’A’, ’A’, this->rows, this->columns, aCula, lda, sCula, uCula, ldu,

vtCula, ldvt);

culaStatus status = culaSgesvd(’A’, ’A’, this->rows, this->columns, aCula, lda, sCula, uCula, ldu,

vtCula, ldvt);


//Inverting S//

//----------------------------------------------------------

// Matrix ’S’ is diagonal, so it is contained in a vector. We operate to convert the vector ’S’

//----------------------------------------------------------

//sInv should be columns x rows -> use transposed order for cula having ’columns’ qty of elements per

memory row

T* sInvCula = (T*)calloc(this->rows*this->columns*sizeof(T), true);



for (size_t i = 0; i < matrixRank; i++) {

if (*(sCula+i) > MINIMUN_ACCEPTED_EIGENVALUE_ON_SVD)

*(sInvCula+i*this->columns+i) = 1.0 / *(sCula+i);

}

//THE PSEUDOINVERSE//

//----------------------------------------------------------

//Computation of the pseudoinverse of A as pinv(A) = V.pinv(S).trans(U)[nxn.nxm.mxm=nxm]

//----------------------------------------------------------

Matrix<T> pInvT(this->rows, this->columns);

T* sInvUtCula = multiplyCULANoneTransposed(sInvCula, uCula, this->columns, this->rows, this->rows, this

->rows);

T* pInvCula = multiplyCULATransposedNone(vtCula, sInvUtCula, this->columns, this->columns, this->

columns, this->rows);

free(aCula);

free(sCula);

free(uCula);

free(vtCula);

free(sInvUtCula);

pInvT.fromArrayRowMajor(pInvCula);

free(pInvCula);

return pInvT.transpose();

}

Matrix<T> pseudoInvertGsl()

{

//A = U S V^T where U:mxn, S:nxn, V:nxn

gsl_matrix * U = gsl_matrix_alloc (this->rows, this->columns); //[u] = mxn

gsl_matrix * V = gsl_matrix_alloc (this->columns, this->columns); //[v] = nxn

gsl_vector * S = gsl_vector_alloc (this->columns); //[s] = n

// Computing the SVD of A

// The variable ’U’ should contain A as input and U as output.

gsl_matrix_memcpy(U, this->inner);

gsl_vector * work = gsl_vector_alloc (this->columns);

gsl_linalg_SV_decomp (U, V, S, work);

gsl_vector_free(work);

//Inverting S//

// Matrix ’S’ is diagonal, so it is contained in a vector.

// We operate to convert the vector ’S’ into the matrix ’SI’.

gsl_matrix * SI = gsl_matrix_calloc (this->columns, this->columns);

for (size_t i = 0; i < this->columns; i++) {

if (gsl_vector_get (S, i) > MINIMUN_ACCEPTED_EIGENVALUE_ON_SVD)

gsl_matrix_set (SI, i, i, 1.0 / gsl_vector_get (S, i));

}

//THE PSEUDOINVERSE//

//----------------------------------------------------------

//Computation of the pseudoinverse of A as pinv(A) = V.pinv(S).trans(U)[nxn.nxn.nxm=nxm]

//----------------------------------------------------------

gsl_matrix * SIpUT = multiplyGslNoneTransponsed(SI, U); //[SIpUT] = nxm

gsl_matrix * pinv = multiplyGslNoneNone(V, SIpUT); //[pinv] = nxm

gsl_matrix_free(SI);

gsl_matrix_free(SIpUT);

gsl_matrix_free(V);

gsl_vector_free(S);

return Matrix<T>(pinv, true);

}

Matrix<T> invert()

{

if (this->rows != this->columns)

throw Exception("It is not possible to invert a non square matrix.");



int matrixRank = this->rows;

gsl_matrix *matrixCopy = gsl_matrix_alloc(matrixRank, matrixRank);

gsl_matrix_memcpy(matrixCopy, inner);

gsl_matrix *inverse = gsl_matrix_alloc(matrixRank, matrixRank);

gsl_permutation* p = gsl_permutation_alloc(matrixRank);

int s=0;

gsl_linalg_LU_decomp (matrixCopy, p, &s);

gsl_linalg_LU_invert(matrixCopy,p,inverse);

gsl_matrix_free(matrixCopy);

gsl_permutation_free(p);

return Matrix<T>(inverse, true);

}

Matrix<T> sum(const Matrix<T>& toSum) const

{

if (toSum.columns != columns) {


message << "Invalid column size for sum operation. Left matrix cols: " << columns << ". right matrix

cols: " << toSum.getColumns();


}

if (toSum.rows != rows) {


message << "Invalid row size for sum operation. Left matrix rows: " << rows<< ". right matrix rows: "

<< toSum.getRows();


}

gsl_matrix* result = gsl_matrix_alloc(this->rows, this->columns);

gsl_matrix_memcpy(result, inner);

gsl_matrix_add(result, toSum.inner);

return Matrix<T>(result, true);

}

Matrix<T> multiply(const Matrix<T>& toMultiply) const

{

if (toMultiply.getRows() != columns) {


message << "Invalid rows size for multiply operation. Left matrix dimension: " << rows << "x" <<

columns << ". Right matrix dimension: " << toMultiply.getRows() << "x" << toMultiply.getColumns()

;


}

Matrix<T> multiplyResult(this->rows, toMultiply.getColumns());


{

for(size_t j = 0; j < toMultiply.getColumns(); ++j)

{

T cellValue = 0;

for(size_t k = 0; k < this->columns; ++k)

{

cellValue += this->get(i, k) * toMultiply.get(k, j);

}

multiplyResult.set(i, j, cellValue);

}

}

return multiplyResult;

}

Matrix<T> multiplyCULA(const Matrix<T>& toMultiply) const

{

if (this->columns != toMultiply.rows) {


message << "Invalid row size for multiply operation. Left matrix columns: " << this->columns << ".

right matrix rows: " << this->columns;




}

T* atCula = this->toArrayRowMajor();

T* btCula = toMultiply.toArrayRowMajor();

T* resultTCula = multiplyCULATransposedTransposed(atCula, btCula, this->columns, this->rows, toMultiply

.columns, toMultiply.rows);

Matrix<T> resultT(toMultiply.columns, this->rows);

resultT.fromArrayRowMajor(resultTCula);

return resultT.transpose();

}

Matrix<T> multiplyGsl(const Matrix<T>& toMultiply) const

{

if (this->columns != toMultiply.rows) {


message << "Invalid row size for multiply operation. Left matrix columns: " << this->columns << ".

right matrix rows: " << this->columns;


}

gsl_matrix* result = multiplyGslNoneNone(this->inner, toMultiply.inner);

return Matrix<T>(result, true);

}

Matrix<T> divide(T denominator) const

{

Matrix<T> divisionResult(this->rows, this->columns);


{

for(size_t j = 0; j < this->columns; ++j)

{

divisionResult.set(i, j, this->get(i, j) / denominator);

}

}

return divisionResult;

}

Matrix<T> getSubmatrix(size_t rowFrom, size_t columnFrom, size_t rowTo, size_t columnTo) const

{

this->validateRow(rowFrom);

this->validateColumn(columnFrom);

this->validateRow(rowTo);

this->validateColumn(columnTo);

if (rowFrom > rowTo || columnFrom > columnTo) {


message << "Invalid column range. Row/Column From should be less than row/column to. RowFrom: " <<

rowFrom << ". ColumnFrom: " << columnFrom << ". RowTo: " << rowTo << ". ColumnTo: " << columnTo;


}

Matrix<T> submatrix(rowTo - rowFrom + 1, columnTo - columnFrom + 1);

for(size_t column = columnFrom; column <= columnTo; ++column)

{

for(size_t row = rowFrom; row <= rowTo; ++row)

{

submatrix.set(row - rowFrom, column - columnFrom, this->get(row, column));

}

}

return submatrix;

}

Matrix<T> getColumn(size_t columnFrom, size_t columnTo) const

{

return this->getSubmatrix(0, columnFrom, this->rows-1, columnTo);

}

Matrix<T> getColumn(size_t column) const

{

return this->getColumn(column, column);



}

Matrix<T> getRow(size_t rowFrom, size_t rowTo) const

{

return this->getSubmatrix(rowFrom, 0, rowTo, this->columns-1);

}

Matrix<T> getRow(size_t row) const

{

return this->getRow(row, row);

}

~Matrix()

{

gsl_matrix_free(inner);

}

size_t getRows() const

{

return rows;

}

size_t getColumns() const

{

return columns;

}

T get(size_t row, size_t column) const

{

validateCell(row, column);

return gsl_matrix_get(inner, row, column);

}

void set(size_t row, size_t column, T value)

{

validateCell(row, column);

return gsl_matrix_set(inner, row, column, value);

}

T* toArrayRowMajor() const

{

T* array = (T*)malloc(this->rows*this->columns*sizeof(T));

for(size_t i = 0; i < this->rows; ++i){

//memcpy(array + i*this->columns, inner->data + i * inner->tda, this->columns*sizeof(T));

for(size_t j = 0; j < this->columns; ++j){

*(array + i*this->columns + j) = (T)(*(inner->data + i * inner->tda + j));

}

}

return array;

}

void fromArrayRowMajor(const T* array) const

{

for(size_t i = 0; i < this->rows; ++i){

//memcpy(inner->data + i * inner->tda, array + i*this->columns, this->columns*sizeof(T));

for(size_t j = 0; j < this->columns; ++j){

*(inner->data + i * inner->tda + j) = (double)(*(array + i*this->columns + j));

}

}

}

private:

void validateCell(size_t row, size_t column) const

{

this->validateRow(row);

this->validateColumn(column);

}

void validateColumn(size_t column) const

{

if (column < 0 || column >= columns) {


message << "Invalid column index. Total Cols: " << columns << ". Asked: " << column;

throw Exception(message.str());



}

}

void validateRow(size_t row) const

{

if (row < 0 || row >= rows) {


message << "Invalid row index. Total Rows: " << rows << ". Asked: " << row;

throw Exception(message.str());

}

}

void checkStatus(culaStatus status) const

{

if(status)

{

char buf[256];

culaGetErrorInfoString(status, culaGetErrorInfo(), buf, sizeof(buf));

throw Exception(buf);

}

}

T* multiplyCULATransposedNone(T* aCula, T* bCula, int mA, int nA, int mB, int nB) const

{

if (mA != mB) {


message << "Invalid row size for multiply operation. Left matrix columns: " << mA << ". right matrix

rows: " << mB;


}

return blasMultiplyCULA(aCula, ’T’, bCula, ’N’, nA, nB, mA, mA, mA);

}

T* multiplyCULANoneTransposed(T* aCula, T* bCula, int mA, int nA, int mB, int nB) const

{

if (nA != nB) {


message << "Invalid row size for multiply operation. Left matrix columns: " << nA << ". right matrix

rows: " << nB;


}

return blasMultiplyCULA(aCula, ’N’, bCula, ’T’, mA, mB, nA, mA, mB);

}

T* multiplyCULATransposedTransposed(T* aCula, T* bCula, int mA, int nA, int mB, int nB) const

{

if (mA != nB) {


message << "Invalid row size for multiply operation. Left matrix columns: " << mA << ". right matrix

rows: " << nB;


}

return blasMultiplyCULA(aCula, ’T’, bCula, ’T’, nA, mB, mA, mA, mB);

}

T* multiplyCULANoneNone(T* aCula, T* bCula, int mA, int nA, int mB, int nB) const

{

if (nA != mB) {


message << "Invalid row size for multiply operation. Left matrix columns: " << nA << ". right matrix

rows: " << mB;


}

return blasMultiplyCULA(aCula, ’N’, bCula, ’N’, mA, nB, nA, mA, nA);

}

gsl_matrix* multiplyGslTransposedNone(gsl_matrix* a, gsl_matrix* b) const

{

if (a->size1 != b->size1) {




message << "Invalid row size for multiply operation. Left matrix columns: " << a->size1 << ". right

matrix rows: " << b->size1;


}

return blasMultiplyGsl(a, b, CblasTrans, CblasNoTrans, a->size2, b->size1);

}

gsl_matrix* multiplyGslNoneTransponsed(gsl_matrix* a, gsl_matrix* b) const

{






}

return blasMultiplyGsl(a, b, CblasNoTrans, CblasTrans, a->size1, b->size1);

}

gsl_matrix* multiplyGslNoneNone(gsl_matrix* a, gsl_matrix* b) const

{






}

return blasMultiplyGsl(a, b, CblasNoTrans, CblasNoTrans, a->size1, b->size2);

}

gsl_matrix* blasMultiplyGsl(gsl_matrix* a, gsl_matrix* b, CBLAS_TRANSPOSE_t opA, CBLAS_TRANSPOSE_t opB,

size_t responseRows, size_t responseCols) const

{

gsl_matrix * r = gsl_matrix_alloc (responseRows, responseCols);

gsl_blas_dgemm (opA, opB,

1.0, a, b,

0.0, r);

return r;

}

/**

* T* blasMultiplyCULA(T* aCula, char opA, T* bCula, char opB, int m, int n, int k, int lda, int ldb)

* */

T* blasMultiplyCULA(T* aCula, char opA, T* bCula, char opB, int m, int n, int k, int lda, int ldb) const

{

T* cCula = (T*) malloc(m*n*sizeof(T));

//culaStatus culaSgemm(char transa, char transb, int m, int n, int k, culaFloat alpha, culaFloat* a,

int lda, culaFloat* b, int ldb, culaFloat beta, culaFloat* c, int ldc);

//C := alpha*op(A)*op(B)+beta*C, where op=[N(none), T(transposed), C(conjugate)]

culaStatus status = culaSgemm(opA, opB, m, n, k, 1, aCula, lda, bCula, ldb, 0, cCula, m);


return cCula;

}

};

template <typename T>

std::istream& operator>>(std::ifstream& input, Matrix<T>& matrix)

{

for(size_t j = 0; j < matrix.getColumns(); ++j)

{

for(size_t i = 0; i < matrix.getRows(); ++i)

{

T cellValue;

input >> std::setiosflags(std::ios::fixed) >> std::setprecision(PRINT_MATRIX_CELL_VALUE_PRECISION) >>

cellValue;

matrix.set(i, j, cellValue);

if (! input.good())

throw Exception("Error writing the matrix file");

}

}



return input;

}

template <typename T>

std::ostream& operator<<(std::ostream& output, const Matrix<T>& matrix)

{

for(size_t j = 0; j < matrix.getColumns(); ++j)

{

for(size_t i = 0; i < matrix.getRows(); ++i)

{

T cellValue = matrix.get(i, j);

output << std::setiosflags(std::ios::fixed) << std::setprecision(PRINT_MATRIX_CELL_VALUE_PRECISION)

<< cellValue << " ";

if (! output.good())

throw Exception("Error writing the matrix file");

}

output << std::endl;

}

return output;

}

#endif

G.2.5. common/CULAContext.h

#ifndef CULACONTEXT_H_

#define CULACONTEXT_H_

#include <cula_lapack.h>

class CULAContext {

public:

CULAContext();

void init();

virtual ~CULAContext();

private:

void checkMinimumCulaRequirements();

void checkStatus(culaStatus status);

};

#endif /* CULACONTEXT_H_ */

G.2.6. common/CULAContext.cpp

#include "CULAContext.h"

#include "Exception.h"

#include <sstream>

CULAContext::CULAContext() {

culaStatus status = culaInitialize();


}

void CULAContext::init() {

this->checkMinimumCulaRequirements();

}

CULAContext::~CULAContext() {

culaShutdown();

}

void CULAContext::checkMinimumCulaRequirements()

{

std::stringstream errorMessage;



int cudaMinimumVersion = culaGetCudaMinimumVersion();

int cudaRuntimeVersion = culaGetCudaRuntimeVersion();

int cudaDriverVersion = culaGetCudaDriverVersion();

int cublasMinimumVersion = culaGetCublasMinimumVersion();

int cublasRuntimeVersion = culaGetCublasRuntimeVersion();

int errors = 0;

if(cudaRuntimeVersion < cudaMinimumVersion)

{

errorMessage << "CUDA runtime version is insufficient; version " << cudaMinimumVersion << " or greater

is required" << std::endl;

++errors;

}

if(cudaDriverVersion < cudaMinimumVersion)

{

errorMessage << "CUDA driver version is insufficient; version " << cudaMinimumVersion << " or greater

is required" << std::endl;

++errors;

}

if(cublasRuntimeVersion < cublasMinimumVersion)

{

errorMessage << "CUBLAS runtime version is insufficient; version " << cublasMinimumVersion << " or

greater is required" << std::endl;

++errors;

}

if (errors)

throw Exception(errorMessage.str());

}

void CULAContext::checkStatus(culaStatus status)

{

char buf[256];

if(status){

culaGetErrorInfoString(status, culaGetErrorInfo(), buf, sizeof(buf));

throw Exception(buf);

}

}

G.2.7. common/Exception.h

#ifndef EXCEPTION_H_

#define EXCEPTION_H_

#include <string>

#include <exception>

class Exception : public std::exception {

private:

std::string message;

public:

Exception(const std::string& message);

virtual ~Exception() throw() {}

virtual const char* what() const throw();

};

#endif /* EXCEPTION_H_ */

G.2.8. common/Exception.cpp

#include "Exception.h"

Exception::Exception(const std::string& message) : message(message) {

}



const char* Exception::what() const throw() {

return this->message.c_str();

}

G.3. Pruebas de Concepto de Controlador Adaptativo

G.3.1. lfd control init.m

function [ control_state ] = lfd_control_init(y, u, p, alpha, mu, A, B, limits, q)

% usage example:

%

% [A, B] = lfd_arx(y, u, 2);

% limits.min_value = 0;

% limits.max_value = 3;

% control_state = lfd_control_init(y, u, 2, 0.99999, 1/625000, A, B, limits, ones(1,sizeof(y,2)));

% next_actuation = lfd_control(control_state, y, u);

y = y’;

u = u’;

%y de m*N datos de las salidas

%u de r*N datos de entradas, N=cantidad de observaciones

%p=orden del modelo ARX


error(’lfd_control:input’,’Unable to determine current time step number: k. Samples in y(count: %d) and u(

count: %d) do not match’, size(y,2), size(u,2));

end

k = size(y,2);

%m=cantidad de componentes de y

%r=cantidad de componentes de u

m = size(y,1);

r = size(u,1);

%alfa=0.999999, mu, parametros de Kegerise

g=(1-alpha)/mu; %g=gamma otro de los parametros de Kegerise

%alfa=0.999999=1-2*g*mu

%s=horizonte de prediccion (valores recomendados entre 2 y 3 veces ’p’)

s=2*p;


control_state.alpha = alpha;

control_state.mu = mu;





control_state.g = g;

control_state.k = k;

%k indica el paso a partir del cual se aplica el control; debe ser k-p-s >=1,

%k-s>=1

if k-p-s < 1

error(’lfd_control:k_validation’, ’Arguments error. TimeStep, Order and PredictionHorizon should match

the following rule: k-p-s>=1. k: %d,p: %d,s: %d.’, k_last_computation, p, s);

end

%segun la idea de Kegerise se busca min y_s’Qy_s+g tr(H’H)

%Q es diagonal en bloques, de msxms, con bloques diagonales

%Q_1,..Q_s de tamanios mxm, con numeros entre 0 y 1 en la diagonal

%Cada Q_i=diag(q_1(i),..q_m(i))



%el termino y_s’Qy_s se puede leeer:

%y(k)’Q_1y(k)+y(k+1)’Q_2y(k+1)+...y(k+s-1)’Q_sy(k+s-1)

%Se define q=vector de m componentes para indicar el peso para cada componente.

%Se forma T’Q; se necesitan onicamente las primeras r filas de T‘Q usando la notacion de Juang

%por lo tanto no es necesario computar Q completa. Donde se supone Q=diag(repmat(q,1,s));

A=-A(:,:,2:end);

beta00=B(:,:,1);

beta0(:,:,1)=B(:,:,2)+A(:,:,1)*beta00;

for kk=2:s-1;

if kk<=p;

aux=zeros(size(beta00));for l=1:kk-1;aux=aux+A(:,:,l)*beta0(:,:,kk-l);end;aux=aux+A(:,:,kk)*beta00;

beta0(:,:,kk)=B(:,:,kk+1)+aux;

else

aux=zeros(size(beta00));for l=1:p;aux=aux+A(:,:,l)*beta0(:,:,kk-l);end;

beta0(:,:,kk)=aux;

end;

end;

%TTQr=r primeras filas de T’Q

TTQr(:,1:m)=beta00’*diag(q);

for j=1:s-1;TTQr(:,m*j+1:(j+1)*m)=beta0(:,:,j)’*diag(q);end;

control_state.TTQr = TTQr;

control_state.h_k = zeros(r,p*r+p*m);

control_state.u_k = zeros(1,r);

%tengo que tener tanto cada salida y como cada entrada u dados como

%vectores columna, es decir y de mxN, u de r*N, N=cantidad de

%observaciones

end

G.3.2. lfd control.m

function [ control_state ] = lfd_control(control_state, y, u)

% example:

% [A, B] = arx_ljung(y, u, 2);

% u_next_step = lfd_control(y, u, 2, 0.99999, 1/625000, ones (1,2*4), A, B)

y = y’;

u = u’;

%y de m*N datos de las salidas

%u de r*N datos de entradas, N=cantidad de observaciones

%p=orden del modelo ARX




s = control_state.s;


alpha = control_state.alpha;

mu = control_state.mu;

TTQr = control_state.TTQr;

h_k_1 = control_state.h_k;

k = size(y,2)+1;

if m ~= size(y,1)

error(’lfd_control:input’,’Coordinates from state vector ’’y’’ do not match ’’m’’ previously defined. y

(coords= %d), m= %d’, size(y,1), m);



end

if r ~= size(u,1)

error(’lfd_control:input’,’Coordinates from actuation vector ’’u’’ do not match ’’r’’ previously

defined. u(coords= %d), r= %d’, size(u,1), m);

end


error(’lfd_control:input’,’Unable to determine current time step number: k. Samples in y(count: %d) and

u(count: %d) do not match’, size(y,2), size(u,2));

end

%k indica el paso a partir del cual se aplica el control; debe ser k-p-s >=1,

%k-s>=1

if k-p-s < 1

error(’lfd_control:k_validation’, ’Arguments error. TimeStep, Order and PredictionHorizon should match

the following rule: k-p-s>=1. k: %d,p: %d,s: %d.’, k, p, s);

end

%According to Kegerise:

%3. Update the data vectors ys(k-s) and vp(k-p-s).

%4. Update h(k) according to Eq. 16. so h(kk + 1) = alpha*h(kk)-2mu*TTQr*ys(kk-s)*vp’(kk-p-s)

%5. Compute the control effort as: u(k) = hvp(k-p).

%ys_k_1_s = ys(k-1-s) = [y(k-1-s);y(k-1-s+1);...;y(k-2)]

ys_k_1_s = reshape(y(:,(k-1-s):(k-2)), m*s, 1);

%vp_k_1_p_s = vp(k-1-p-s) = [u(k-1-p-s);...;u(k-2-s);y(k-1-p-s);...;y(k-2-s)]

up_k_1_p_s = reshape(u(:,(k-1-p-s):(k-2-s)), r*p, 1);

yp_k_1_p_s = reshape(y(:,(k-1-p-s):(k-2-s)), m*p, 1);

vp_k_1_p_s = [up_k_1_p_s;yp_k_1_p_s];

%vp_k_p = vp(k-p) = [u(k-p);...;u(k-1);y(k-p);...;y(k-1)]

up_k_p = reshape(u(:,(k-p):(k-1)), r*p, 1);

yp_k_p = reshape(y(:,(k-p):(k-1)), m*p, 1);

vp_k_p = [up_k_p;yp_k_p];

%according to eq. 16 h(k) = alpha*h(k-1) - 2*mu*tqr*ys(k-1-s)*vp(k-1-p-s)’

h_k = alpha * h_k_1 - 2 * mu * TTQr * ys_k_1_s * vp_k_1_p_s’;

u_k = h_k * vp_k_p;





u_k = u_k’;


control_state.h_k = h_k;

end


Bibliografıa

[1] Neculai Andrei. Modern control theory - a historical perspective, 2005.

[2] Frederic Archambeau, Namane Mechitoua, and Marc Sakiz. Code saturne: a finite volumecode for the computation of turbulent incompressible flows. International Journal on FiniteVolumes, 1, 2004.

[3] G. Artana, A. Cammilleri, J. Carlier, and E. Memin. Strong and weak constraint variationalassimilations for reduced order modelling for flow control. Physics of fluids, 8:3264–3288,2012.

[4] G. Artana, R. Sosa, E. Moreau, and G. Touchard. Control of the near wake-flow around acircular cylinder with electrohydrodynamic actuators. Experiments in Fluids, 35:580–588,2003.

[5] Alexandre Barbagallo, Denis Sipp, and Peter J. Schmid. Closed-loop control of an opencavity flow using reduced-order models. Journal of Fluid Mechanics, 641:1–50, 12 2009.

[6] J. F. Beaudoin, O. Cadot, J. L. Aider, and J. E. Wesfreid. Drag reduction of a bluff bodyusing adaptive control methods. Physics of Fluids, 18(085107), 2006.

[7] Thomas R. Bewley. Flow control: new challenges for a new renaissance. Progress in Aeros-pace Sciences, 37(1):21 – 58, 2001.

[8] F.A. Brauer and C. Castillo-Chavez. Mathematical Models in Population Biology and Epi-demiology. Texts in Applied Mathematics. Springer-Verlag, 2001.

[9] O. Cadot, B. Thiria, and J.F. Beaudoin. Passive drag control of a turbulent wake by localdisturbances. Solid Mechanics and its Applications, 14:529–537, 2009.

[10] A. Cammilleri, F. Gueniat, J. Carlier, L. Pastur, E. Memin, F. Lusseyran, and G. Artana.Pod-spectral decomposition for fluid flow analysis and model reduction. Theoretical andComputational Fluid Dynamics, pages 1–29, 2013.

[11] Louis N. Cattafesta, Qi Song, David R. Williams, Clarence W. Rowley, and Farrukh S.Alvi. Active control of flow-induced cavity oscillations. Progress in Aerospace Sciences,44(7-8):479–502, 2008.

[12] CEI. EnSight User Manual for Version 10.0. Computational Engineering International,Inc, 1 2012.

[13] H. Choi, W. Jeon, and J. Kim. Control of flow over a bluff body. Annual Review of FluidMechanics, 40(1):113–139, 2008.

[14] D W Clarke, C Mohtadi, and P S Tuffs. Generalized predictive control - part 1. the basicalgorithm. Automatica, 23(2):137–148, March 1987.

234


[15] D W Clarke, C Mohtadi, and P S Tuffs. Generalized predictive control - part 2. extensionsand interpretations. Automatica, 23(2):149–160, March 1987.

[16] Kelly Cohen, Selin Aradag, Stefan Siegel, Jurgen Seidel, and Tom McLaughlin. A Metho-dology Based on Experimental Investigation of a DBD-Plasma Actuated Cylinder Wake forFlow Control, chapter 6, pages 117–138. InTech Europe, 2012.

[17] S. Scott Collis, Ronald D. Joslin, Avi Seifert, and Vassilis Theofilis. Issues in active flow con-trol: Theory, control, simulation, and experiment. Progress in Aerospace Sciences, 40(1):237– 289, 2004.

[18] Juan D’Adamo, Leo M. Gonzalez, Alejandro Gronskis, and Guillermo Artana. The scenarioof two-dimensional instabilities of the cylinder wake under electrohydrodynamic forcing: alinear stability analysis. Fluid Dynamics Research, 44(055501):20, 2012.

[19] E. Detemple-Laake and H. Eckelmann. Phenomenology of karman vortex streets in oscilla-tory flow. Experiments in Fluids, 7(4):217–227, 1989.

[20] T. Duriez, J.L. Aider, and J.E. Wesfreid. Self-sustaining process through streak generationin a flat-plate boundary layer. Physical Review Letters, 103(14), 2009.

[21] E. Fernandez-Cara and E. Zuazua. Control theory: History, mathematical achievementsand perspectives. Bol. Soc. Esp. Mat. Apl., 26:79–140, 2003.

[22] HeinrichE. Fiedler. Control of free turbulent shear flows. In Mohamed Gad-el Hak andAndrew Pollard, editors, Flow Control, volume 53 of Lecture Notes in Physics, pages 335–429. Springer Berlin Heidelberg, 1998.

[23] Power Generation Fluid Dynamics and Environment Department Single Phase Thermal-Hydraulics Group. Code Saturne 2.3.1 Theory Guide. EDF R&D, 12 2011.

[24] B. Friedland. Control System Design: An Introduction To State-Space Methods. DoverBooks on Electrical Engineering Series. Dover Publications, Incorporated, 2005.

[25] E. Gillies. Low-dimensional control of the circular cylinder wake. Journal of Fluid Mecha-nics, 371:157–178, 1998.

[26] E. A. Gillies. Low-dimensional control of the circular cylinder wake. Journal of FluidMechanics, 371:157–178, 9 1998.

[27] G. Godard and M. Stanislas. Control of a decelerating boundary layer. part 3: Optimizationof round jets vortex generators. Aerospace Science and Technology, 10(6):455–464, 2006.

[28] A. Gronskis, R. Sosa, and G. Artana. Modelling ehd actuation with a slip velocity. 2009.

[29] H.R. Hall. Governors and governing mechanism. The Technical Publishing Co., 287, Deans-gate, Manchester, 1903.

[30] Aurelien Herve, Denis Sipp, Peter J. Schmid, and Manuel Samuelides. A physics-basedapproach to flow control using system identification. Journal of Fluid Mechanics, 702:26–58, 2012.

[31] Shao-Ching Huang and John Kim. Control and system identification of a separated flow.Physics of Fluids, 20(101509), 2008.

Bibliografıa 235


[32] X.Y. Huang. Feedback control of vortex shedding from a circular cylinder. Experiments inFluids, 20(3):218–224, 1996.

[33] Jer-Nan Juang and Minh Phan. Deadbit predictive controllers. Technical Memorandum112862, Nasa, 1997.

[34] T. Jukes and K. Choi. Control of unsteady flow separation over a circular cylinder usingdielectric-barrier-discharge surface plasma. Physics of fluids, 21(9):094106, 2009.

[35] Michael A. Kegerise, Randolph H. Cabell, and Louis N. Cattafesta. Real time feedbackcontrol of flow-induced cavity tones - part 1: Fixed-gain control. Journal of Sound andVibration, 307:906–923, 2007.

[36] Michael A. Kegerise, Randolph H. Cambell, and Louis N. Cattafesta. Real time feedbackcontrol of flow-induced cavity tones - part 2: Adaptive control. Journal of Sound andVibration, 307:924–940, 2007.

[37] David B. Kirk and Wen-mei W. Hwu. Programming Massively Parallel Processors: AHands-on Approach. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1stedition, 2010.

[38] J. Kostas, J.M. Foucaut, and M. Stanislas. The flow structure produced by pulsed-jet vortexgenerators in a turbulent boundary layer in an adverse pressure gradient. Flow, Turbulenceand Combustion, 78(3-4):331–363, 2007.

[39] Petros Koumoutsakos. Active control of vortex–wall interactions. Physics of Fluids,9(12):3808–3816, 1997.

[40] Alexey Kozlov. Plasma actuators for bluff body flow control. PhD thesis, University ofNotre Dame, 2010.

[41] J.C. Lin. Review of research on low-profile vortex generators to control boundary-layerseparation. Progress in Aerospace Sciences, 38(4-5):389–420, 2002.

[42] Lennart Ljung. System Identification: Theory for the User. Prentice-Hall Inc., EnglewoodCliffs, N.J., 1987.

[43] D. J. Mavriplis. Unstructured grid techniques. Annual Review of Fluid Mechanics,29(1):473–514, 1997.

[44] D.Q. Mayne, J.B. Rawlings, C.V. Rao, and P.O.M. Scokaert. Constrained model predictivecontrol: Stability and optimality. Automatica, 36(6):789 – 814, 2000.

[45] M.L. Minsky and Massachusetts Institute of Technology. Artificial Intelligence Laboratory.Matter, Mind and Models. AI memo. Massachusetts Institute of Technology, Project MAC,1965.

[46] M. Munska and T. Mclaughlin. Circular cylinder flow control using plasma actuators. AIAApaper 2005-0141, 2005.

[47] Katsuhiko Ogata. Modern Control Engineering. Prentice Hall PTR, Upper Saddle River,NJ, USA, 4th edition, 2001.

[48] A.V. Oppenheim, R.W. Schafer, and J.R. Buck. Discrete-time signal processing. Prentice-Hall signal processing series. Prentice Hall, 1999.

Bibliografıa 236


[49] A.V. Oppenheim, A.S. Willsky, and S.H. Nawab. Signals and Systems. Prentice-Hall signalprocessing series. Prentice-Hall International, 1997.

[50] A. E. Perry, M. S. Chong, and T. T. Lim. The vortex-shedding process behind two-dimensional bluff bodies. Journal of Fluid Mechanics, 116:77–90, 2 1982.

[51] S.Joe Qin and Thomas A. Badgwell. A survey of industrial model predictive control tech-nology. Control Engineering Practice, 11(7):733 – 764, 2003.

[52] J. Reece Roth. Prospective industrial applications of the one atmosphere uniform glowdischarge plasma. 1:–223 Vol.1, 2004.

[53] J. Richalet and D. O’Donovan. Predictive Functional Control: Principles and IndustrialApplications. Advances in industrial control. Springer London, Limited, 2009.

[54] A. Roshko. On the wake and drag of bluff bodies. J. Aeronaut. Sci., 22:124–132, 1955.

[55] Anatol Roshko. Experiments on the flow past a circular cylinder at very high reynoldsnumber. Journal of Fluid Mechanics, 10:345–356, 5 1961.

[56] J. Reece Roth, Daniel M. Sherman, and Stephen P. Wilkinson. Electrohydrodynamic flowcontrol with a glow-discharge surface plasma. AIAA Journal, 38(7):1166–1172, 2000.

[57] K. Roussopoulos. Feedback control of vortex shedding at low reynolds number. Journal ofFluid Mechanics, 248:267–296, 1993.

[58] C. Rowley. Model reduction for fluid flows using balanced proper orthogonal decomposition.Int. J. Bifurc. Chaos, 15:997–1013, 2005.

[59] H. Schlichting. Boundary-Layer Theory. MacGraw-Hill, 7th edition, 1979.

[60] D. Shiels and A. Leonard. Investigation of a drag reduction on a circular cylinder in rotaryoscillation. Journal of Fluid Mechanics, 431:297–322, 3 2001.

[61] C.A. Smith and A.B. Corripio. Principles and practice of automatic process control. Wiley,2006.

[62] Roberto Sosa. Mecanismos de Acople en Actuadores EHD. PhD thesis, Facultad de Inge-nierıa, Universidad de Buenos Aires, 2007.

[63] R.B. Stull. An Introduction to Boundary Layer Meteorology. Atmospheric and oceanograp-hic sciences library. Kluwer Academic Publishers, 1988.

[64] G. Tadmor, O. Lehmann, B.R. Noack, L. Cordier, J. Delville, J. Bonnet, and M. Morzynski.Reduced-order models for closed-loop wake control. Philos Trans A Math Phys Eng Sci,369(1940):1513–24, 2011.

[65] Gilead Tadmor, Oliver Lehmann, Bernd R. Noack, and Marek Morzynski. Mean fieldrepresentation of the natural and actuated cylinder wake. Physics of Fluids, 22(3):034102,2010.

[66] B. Thiria, S. Goujon-Durand, and J.E. Wesfreid. The wake of a cylinder performing rotaryoscillations. Journal of Fluid Mechanics, 560:123–147, 2006.

[67] Lloyd Nicholas Trefethen. Finite difference and spectral methods for ordinary and partialdifferential equations. Cornell University - Department of Computer Science and Center forApplied Mathematics, 1996.

Bibliografıa 237


[68] N. Wiener. Cybernetics: Or, Control and Communication in the Animal and the Machine.The @MIT paperback series: Massachusetts Institute of Technology. Mit Press, 1965.

[69] C H K Williamson. Vortex dynamics in the cylinder wake. Annual Review of Fluid Mecha-nics, 28(1):477–539, 1996.

[70] M. M. Zdravkovich. Flow Around Circular Cylinders: Volume I: Fundamentals. FlowAround Circular Cylinders: A Comprehensive Guide Through Flow Phenomena, Experi-ments, Applications, Mathematical Models, and Computer Simulations. OUP Oxford, 1997.

[71] M. M. Zhang, L. Cheng, and Y. Zhou. Closed-loop-controlled vortex shedding and vibra-tion of a flexibly supported square cylinder under different schemes. Physics of Fluids,16(5):1439–1448, 2004.

[72] K. Zhou and J.C. Doyle. Essentials of Robust Control. Prentice-Hall International editions.Prentice-Hall International, 1998.

Bibliografıa 238

sistemas de control de flujo a lazo cerrado mediante controlador

Documents