Facultad de Ciencias Exactas, Físicas y Naturales Departamento de Química Industrial y Aplicada
Escuela de Ingeniería Química
DESARROLLO DE UN SIMULADOR DE PROCESOS QUÍMICOS
Proyecto Integrador de la Facultad de Ciencias Exactas, Físicas y Naturales de la Universidad Nacional de Córdoba conforme
a los requisitos para obtener el título de Ingeniero Químico
por
JULIÁN ANDRÉS SCORTECHINI
Córdoba 2015
QUÍMICOS desarrollado por el alumno Julián Andrés Scortechini ha sido dirigido por la Prof. MCs. Ing. Susana Martínez Riachi.
Directora del Proyecto Integrador
Nombre y Lugar de Trabajo
………. firma
El presente proyecto integrador de la carrera de Ingeniería Química ha sido aprobado el .…/.…/.….. , mereciendo la calificación de ...(………)
Tribunal Evaluador
Nombre Nombre Nombre
UNIVERSIDAD NACIONAL DE CÓRDOBA Facultad de Ciencias Exactas, Físicas y
DEDICATORIA
Dedico este trabajo a mis padres quienes con esfuerzo, sacrificio y mucho amor me han guiado durante toda mi vida.
AGRADECIMIENTOS
El autor de este proyecto desea agradecer al Señor Rogelio Andrés Scortechini y a la Señora Nelda Estela Soria por su constante aliento y paciencia durante la confección de este trabajo.
Se agradece muy atentamente a la Señora Olga Scortechini, al Señor Andrés Bonetto, a la Señora Florencia Foresi de Bonetto, a la Señorita Violeta Bonetto Foresi, al Señor Laureano Bonetto, a la Señora María José Luna de Bonetto y al joven Augusto Bonetto Luna por su constante aliento y por haber colaborado con el autor de este proyecto proporcionando materiales para su ejecución.
También se desea agradecer al Señor Ariel Arguello, al Señor Mauro Domingo, a la Señorita Florencia Buraschi y a la Señorita Vanesa Mascietti quienes han contribuido a la ejecución de este proyecto de manera inestimable en calidad de amigos, compañeros y colaboradores.
El autor de esta obra valora personalmente al Ingeniero Martín E. Gaitán, a todo el personal de la empresa PHASETY, a los Ingenieros Susana Martínez Riachi y Daniel L. Yorio, al Señor Maximiliano Duarte, como así también a toda la Escuela de Ingeniería Química quienes han contribuido al desarrollo de este proyecto proporcionando apoyo, conocimientos, materiales e instalaciones.
ÍNDICE GENERAL
Capítulo 1: Introducción a la simulación de procesos ... 1
Introducción ... 1
Historia ... 1
Hoy ... 3
Clasificación de los métodos de simulación ... 5
Simulación cualitativa y cuantitativa ... 6
Simulación estacionaria y dinámica. ... 6
Clasificación de simuladores ... 7
Simuladores Globales u orientados a ecuaciones ... 8
Simuladores Secuenciales-Modulares ... 10
Simuladores Híbridos... 13
Características de los Simuladores Comerciales ... 15
Nuestro Simulador ... 18 Bibliografía ... 19 Capítulo 2: Objetivos ... 20 Objetivos Generales ... 20 Objetivos Específicos ... 20 Capítulo 3: Programación ... 21 Introducción ... 21
Programación orientada a objetos ... 22
Definición de objeto ... 22
Definición de Mensaje... 24
Definición de Clase ... 26
Herencia ... 26
El lenguaje Python ... 30
Bibliografía ... 32
Capítulo 4: Termodinámica ... 33
Introducción ... 33
Propiedades termodinámicas generales ... 34
Sistemas ideales ... 37
Mezclas de gases ideales ... 37
La solución ideal ... 38
Sistemas no ideales ... 39
Propiedades Residuales de las Sustancias puras ... 40
Propiedades Residuales de las Mezclas ... 45
Propiedades en Exceso de las Mezclas líquidas ... 51
Biblioteca de Funciones Termodinámicas ... 57
Bibliografía ... 59
Capítulo 5: Objetos Desarrollados ... 60
Introducción ... 60
La clase Pantalla ... 60
La clase BaseDeDatos ... 62
La clase Proyecto... 63
La clase SistemaTermodinamico ... 65
Los primeros pasos ... 72
Corriente ... 85 Nodo Divisor ... 94 Mezclador ... 101 Flash ... 109 Intercambiador de Calor ... 115 Menús Auxiliares ... 121 El menú Herramientas ... 121
El Menú Ver ... 124
El Menú Ayuda ... 125
Bibliografía ... 127
Capítulo 6: Problemas y dificultades ... 128
Introducción ... 128
Resolución de ecuaciones ... 128
Niveles de iteración ... 130
Cálculo de temperaturas y balances de energía ... 131
Eliminación de equipos ... 131
Reconstrucción del diagrama de flujo ... 132
Conexión de los equipos ... 132
Capítulo 7: Conclusiones ... 133
Anexo A: Cálculos Termodinámicos ... 135
Sistemas Ideales ... 135
Mezclas de gases ideales ... 135
La solución ideal ... 136
Sistemas no ideales ... 138
Propiedades residuales ... 138
Coeficiente de Actividad ... 140
Anexo B: Cálculos de Corriente ... 142
Anexo C: Cálculos de Nodo Divisor ... 146
ÍNDICE DE ABREVIATURAS
Operador de derivación parcial
A Parámetro de la Ecuación Actividad
a, b, q, I Parámetros de las ecuaciones cúbicas de estado Ai, Bi, Ci Constantes de la ecuación de Antoine
AIChe American Institute of Chemical Engineers
atm Atmósfera
B Segundo coeficiente Virial
beta, Fracción de vapor
CAS Computer Algebra System
Cp Capacidad calorífica molar
Variación
d Operador de derivación total
DFI Diagrama de Flujo de Información
DTML, ΔTML Diferencia de Temperatura Media Logarítmica
tolerancia del error
E (Supraíndice) Exceso
Constantes de las ecuaciones cúbicas de estado
ej. elemplo
ENIAC Electronic Numerical Integrator And Computer
EOS Ecuaciones de Estado
etc. etcétera
F Caudal de corriente
f fugacidad
coeficiente de fugacidad de una especie pura
Cociente entre los coeficientes de fugacidad en fase gaseosa y en fase líquida
FORTRAN Formula Translator
G Energía libre de Gibbs
Coeficiente de actividad
gi (Supraíndice) gas ideal
GL Grados de Libertad
GPSS General Purpose Simulation System
H Entalpía molar
i, j, k
(subíndices) Especie química
IBM International Business Machines Corp.
id (Supraíndice) ideal, relativo a una solución ideal
K relación de equilibrio, y/x
Coeficiente binario de la ecuación de Wilson
Energía de interacción binaria en la ecuación de Wilson
ln logaritmo natural
M Propiedad genérica
Potencial químico
MATLAB MATrix LABoratory
MS MicroSoft
n Número de moles
N Número total de especies químicas
ni Número de moles de la especie "i"
NRTL Non-Random Two-Liquid
NumPy Numerical Python
P Presión
p presión parcial
Pc Presión crítica
PDF formato de documento portátil
PM Peso molecular
Pr Presión crítica
PR Ecuación de Peng-Robinson
Pydoc Python Document
Pyxls Python Excel
Q Flujo de calor
R Constante de los gases ideales
R (Supraíndice) Residual
RAND Research ANd Development
RK Ecuación de Redlich-Kwong
S Entropía molar
Operador de Sumatoria
sat saturación de un líquido o vapor
SciPy Scientific Python
SIMSCRIPT Simulation Script
Sobrebarra Propiedad molar parcial
SRK Ecuación de Soave-Redlich-Kwong
SymPy Symbolic Python
T Temperatura
Tc Temperatura crítica
Tr Temperatura reducida
U Energía interna molar
U Coeficiente global de transferencia de calor
V Volumen molar
Vc Volumen crítico
Factor acéntrico en cálculos termodinámicos. Fracción en masa.
W Flujo de trabajo
WSC Winter Simulation Conference
x Fracción molar en fase líquida
y Fracción molar en fase gaseosa
z Fracción molar global
Z Factor de compresibilidad
Zc Factor de compresibilidad en el punto crítico
ÍNDICE DE FIGURAS
Figura 1. Representación gráfica de un objeto 22
Figura 2. Modelo de un flash 23
Figura 3. Comunicación entre objetos a través de mensajes 24
Figura 4. Mezclador como ejemplo de clase 26
Figura 5. Clase Equipo como superclase de otras 28
Figura 6. Pantalla del simulador 60
Figura 7. Procedimiento para calcular la temperatura de burbuja 67
Figura 8. Procedimiento para calcular la temperatura de rocío 68
Figura 9. Pantalla de Configuración de HYSYS 73
Figura 10. Otra pantalla de Configuración de HYSYS 73
Figura 11. Pantalla de configuración de UNISIM 74
Figura 12. Pantalla de selección de compuestos de UNISIM 74
Figura 13. Menú de configuración general del simulador 75
Figura 14. Diálogo de configuración general 76
Figura 15. Mensaje de error durante la configuración de Cp líquidos 77
Figura 16. Diálogo de configuración para Cp líquidos 78
Figura 17. Parámetros de los modelos de actividad 78
Figura 18. Menú Archivo del simulador 79
Figura 19. Diálogo para nombrar el proyecto 80
Figura 20. Diálogo de apertura de proyectos 80
Figura 21. Menú Insertar del simulador 82
Figura 22. Diálogo para nombrar un nuevo equipo 82
Figura 23. Menú emergente y sus distintas opciones 84
Figura 24. Ejemplo de un pequeño diagrama de flujo 84
Figura 25. Representación de una corriente 85
Figura 26. Diálogo de configuración de corriente 90
Figura 27. Generación de incógnitas, ecuaciones y grados de libertad 92
Figura 28. Resolución de ecuaciones de corriente 93
Figura 29. Representación gráfica de un nodo divisor 94
Figura 30. Diálogo de configuración de un nodo divisor 97
Figura 31. Selección de corrientes del nodo divisor 98
Figura 32. Carga de datos en diálogo de nodo divisor 99
Figura 34. Resolución completa de un nodo divisor 101
Figura 35. Representación gráfica de un mezclador 101
Figura 36. Diálogo de configuración de un mezclador 105
Figura 37. Selección de corrientes del mezclador 106
Figura 38. Carga de datos en diálogo de mezclador 107
Figura 39. Actualización y resolución de un mezclador 108
Figura 40. Representación gráfica de un flash 109
Figura 41. Diálogo de configuración de flash 112
Figura 42. Actualización y resolución de flash 114
Figura 43. Representación de un flash en UNISIM 114
Figura 44. Resultados de cálculo flash con UNISIM 115
Figura 45. Representación gráfica de un intercambiador de calor. 115
Figura 46. Configuración de un intercambiador de calor. 119
Figura 47. Actualización de un intercambiador de calor. 120
Figura 48. Resolución completa de un intercambiador de calor. 121
Figura 49. Menú Herramientas. 122
Figura 50. Diálogo de Consulta a Biblioteca. 123
Figura 51. Diálogo para agregar nuevo compuesto. 124
Figura 52. Diálogo para editar compuesto. 124
Figura 53. Opciones del menú Ver. 125
Figura 54. El menú Ayuda. 126
Figura 55. Diálogo Acerca de los Autores. 126
Figura 56. Configuración general para el Ejemplo 6. 142
Figura 57. Diálogo de configuración de corriente del Ejemplo 6. 143
Figura 58. Completando los datos de la corriente. 143
Figura 59. Corriente del Ejemplo 6 resuelta. 144
Figura 60. Propiedades de la corriente del Ejemplo 7. 145
Figura 61. Diálogo de configuración de nodo divisor para el Ejemplo 8. 146
Figura 62. Carga de datos para el Ejemplo 8. 147
Figura 63. Nodo divisor y corrientes del Ejemplo 8 resueltos. 147
Figura 64. Diálogo de configuración de mezclador para el Ejemplo 9. 148
ÍNDICE DE TABLAS
Tabla 1. Principales características de los simuladores Globales u
orientados a ecuaciones 9
Tabla 2. Principales Características de los Simuladores
10 Modulares Secuenciales.
Tabla 3. Factores ponderados para seleccionar el lenguaje de
programación 29
Tabla 4. Parámetros de las ecuaciones cúbicas de estado 43
Tabla 5. Análisis de Corriente 85
Tabla 6. Análisis de Nodo Divisor 95
Tabla 7. Análisis de Mezclador 102
Tabla 8. Análisis de Flash 109
Tabla 9: Análisis de Intercambiador de Calor 116
Tabla 10. Comparación de propiedades residuales entre ecuaciones de
RESUMEN
Palabras clave: Simulador, Ingeniería, Química, Híbrido, Balances, Educativo, Python, Objetos.
En el presente proyecto se desarrolló un simulador de procesos químicos con fines educativos. Se optó por el diseño de un programa híbrido que combine los mejores aspectos de los simuladores modulares secuenciales y de aquellos orientados a ecuaciones. Se utilizó el lenguaje de programación Python para codificar el proyecto por sus excelentes recursos de programación orientada a objetos, cálculos vectoriales, numéricos y simbólicos aplicables a la Ingeniería. El programa obtenido es capaz de realizar balances de materia y de energía, así como cálculos termodinámicos avanzados, con gran precisión. Posee una amplia variedad de modelos termodinámicos disponibles como ecuación del gas ideal, ecuación Virial, ecuaciones cúbicas de estado, solución ideal, ecuaciones de Margules, Van Laar y Wilson. También se construyó una interface gráfica de usuario moderna, que permita una comunicación eficiente y amigable con el usuario. La misma permite una configuración del sistema de unidades, seleccionar compuestos entre una lista de más de 450 especies químicas orgánicas e inorgánicas y trabajar con caudales molares o másicos. El software permite además representar el diagrama de flujo del proceso a simular, identificando a cada equipo o accesorio de proceso con un ícono característico. La comunicación con el usuario se realiza mediante diálogos que hacen el proceso de configuración cómodo y natural. Cada equipo se caracteriza mediante un objeto informático constituido por atributos que simbolizan las propiedades del equipo y métodos que implementan su comportamiento e interacciones. El proceso de modelado de cada operación se basa en la identificación de las propiedades desconocidas, la abstracción de las mismas con símbolos algebraicos, el planteo de ecuaciones y la contabilización del número de grados de libertad. Entre las ecuaciones se encuentran algunas generales como las del balance de masa, de energía o de equilibrio de fases, las de restricción como la suma de fracciones molares igual a uno y otras específicas como aquellas propias de un modelo termodinámico o una operación en particular. Para la resolución de esas ecuaciones se utilizaron herramientas de cálculo propias del lenguaje Python y en casos excepcionales se programaron métodos numéricos específicos para un tipo
Capítulo 1: Introducción a la simulación de procesos
Introducción
El objetivo de todo simulador consiste en reproducir la realidad de la mejor manera posible. Si existiera un simulador capaz de representar las condiciones de la realidad, el usuario no podría distinguir los sucesos simulados de los reales. Sin embargo en la práctica ésta resulta tan compleja que ningún programa de computadora puede reproducirla totalmente, se habla entonces del grado de aproximación con que dicho programa refleja el comportamiento real de los sistemas simulados. La experiencia demuestra que a medida que se incrementa la capacidad de simulación también aumenta la complejidad del software.
Las herramientas informáticas implementan una serie de modelos matemáticos y algoritmos de decisión, basados en la lógica, para simular procesos industriales.
Historia
La historia de la simulación nace en 1777 con el planteo del problema “La aguja de Buffon”, un método matemático sencillo para ir aproximando el valor del número Pi a partir de sucesivos intentos.
En 1812 Laplace mejoró y corrigió la solución de Buffon y desde entonces se conoce como solución Buffon-Laplace.
Posteriormente, el estadístico William Sealy Gosset, que trabajaba en la destilería de Arthur Guinness, ya aplicaba sus conocimientos estadísticos allí, como también en su propia explotación agrícola. El especial interés de Gosset en el cultivo de la cebada le llevó a especular que el diseño de experimentos debería dirigirse no sólo a mejorar la producción media, sino también a desarrollar variedades de cebada cuya mayor robustez permitiese que la producción no se viese afectada por las variaciones en el suelo y el clima. Para evitar futuras filtraciones de información confidencial, Guinness prohibió a sus empleados la publicación de cualquier tipo de artículo independientemente de su contenido, de ahí el uso que hizo Gosset en sus publicaciones del seudónimo "Student", para evitar que su empleador lo detectara.
Es por esta razón que su logro más famoso se conoce como la "distribución t de Student", que de otra manera hubiera sido conocida como la "distribución t de Gosset”. Este hito histórico abrió las puertas a la aplicación de la simulación en el campo del proceso de control industrial así como a las sinergias que generaba esta simulación basada en la experimentación y técnicas de análisis para descubrir soluciones exactas a problemas clásicos de la industria y la ingeniería.
A mediados de la década de 1940 dos hechos sentaron las bases para la rápida evolución del campo de la simulación:
La construcción de las primeras computadoras de propósito general como el ENIAC.
El trabajo de Stanislaw Ulam, John Von Neumann y otros científicos para usar el método de Montecarlo en computadoras modernas y solucionar problemas de difusión de neutrones en el diseño y desarrollo de la bomba de hidrógeno. Ulam y Von Neumann ya estuvieron presentes en el proyecto Manhattan. En 1960, Keith Douglas Tocher desarrolló un programa de simulación general cuya principal tarea era la de simular el funcionamiento de una planta de producción donde las máquinas alternaban por los estados: Ocupado, Esperando, No disponible y Fallo; de manera que las simulaciones en los cambios de estado de las máquinas marcaran el estado definitivo de la producción de la planta. Este trabajo produjo además el primer libro sobre simulación: “The Art of Simulation” (1963).
Para aquel entonces, IBM desarrolló entre 1960 y 1961 el Sistema de Simulación de Propósito General o General Purpose Simulation System (GPSS). El GPSS se diseñó para realizar simulaciones de teleprocesos involucrando por ejemplo: control de tráfico urbano, gestión de llamadas telefónicas, reservas de pasajes de avión, etc. La sencillez de uso de este sistema lo popularizó como el lenguaje de simulación más usado de la época.
Por otro lado, en 1963 se desarrolló SIMSCRIPT, otra tecnología alternativa al GPSS basada en FORTRAN, más enfocada a usuarios que no tenían por qué ser obligatoriamente expertos informáticos en RAND CORPORATION.
Complementariamente a los desarrollos llevados a cabo por RAND e IBM, el Royal Norwegian Computing Center inició en 1961 el desarrollo del programa SIMULA con
En 1967 se fundó el WSC (Winter Simulation Conference), lugar donde desde entonces y hasta ahora se archivan los lenguajes de simulación y aplicaciones derivadas, siendo en la actualidad el referente en lo que a avances en el campo de los sistemas de simulación se refiere.
Durante este periodo se desarrollaron avanzadas herramientas de modelado y de análisis de resultados. Gracias también a los desarrollos obtenidos en la generación de datos y a las técnicas de optimización y representación de datos, la simulación llega a su fase de expansión donde comienza a aplicarse en múltiples campos. Anteriormente, los datos de salida obtenidos de una simulación por computadora se presentaban en una tabla o matriz, de manera que se mostraba el efecto que los múltiples cambios en los parámetros tenían sobre los datos. El empleo del formato de matriz se debía al uso tradicional que se hacía de la matriz en los modelos matemáticos. Sin embargo, los psicólogos advirtieron que los seres humanos percibían mejor los cambios en el desarrollo de las situaciones si miraban gráficos o incluso imágenes en movimiento o animaciones generadas a partir de dichos datos, como las que se ejecutan en las animaciones de imágenes creadas por computadora.
En 1981 Aparecen los softwares para la simulación de procesos químicos en PC. Pronto aparecen programas tales como: DESIGN II, ASPEN, SIMSCI (PRO II), HYSIM, CHEMCAD. etc. (LANDER, 2014).
Hoy
En la actualidad la simulación de procesos se encuentra en un estado de desarrollo avanzado, aun expandiéndose pero a menor velocidad que en las décadas pasadas. Los simuladores disponibles en la actualidad se caracterizan por una alta calidad para representar los procesos simulados, cuentan con interfaces gráficas de usuario modernas y amigables. También ha aumentado su potencia de cálculo y de procesamiento de la información de la mano con la evolución de la tecnología disponible en las computadoras de hoy en día y con la mejora en los modelos matemáticos usados para representar fenómenos fisicoquímicos.
Actualmente la simulación de procesos se ve como un procedimiento sistemático compuesto por las siguientes etapas:
Formulación del problema: En este paso debe quedar perfectamente establecido
el objeto de la simulación. Se deben definir lo más detalladamente posible los siguientes factores: los resultados que se esperan del simulador, el plan de experimentación, el tiempo disponible, las variables de interés, el tipo de perturbaciones a estudiar, el tratamiento estadístico de los resultados, la complejidad de la interfaz del simulador, etc. Se debe establecer si el simulador será operado por el usuario o si el usuario sólo recibirá los resultados. Finalmente, se debe establecer si el usuario necesita una simulación o una optimización.
Definición del sistema: El sistema a simular debe estar perfectamente definido. Es
necesario establecer la frontera del sistema a estudiar y las interacciones con el medioambiente que serán consideradas.
Formulación del modelo: Esta etapa es un arte. La misma comienza con el
desarrollo de un modelo simple que captura los aspectos relevantes del sistema real. Los aspectos relevantes del sistema real dependen de la formulación del problema; para un ingeniero de seguridad los aspectos relevantes de una planta son diferentes de los aspectos considerados por un ingeniero químico o electromecánico para el mismo sistema. Este modelo simple se irá enriqueciendo como resultado de varias iteraciones.
Colección de datos: La naturaleza y cantidad de datos necesarios están
determinadas por la formulación del problema y del modelo. Los datos pueden ser provistos por bases de datos, experimentos de laboratorios o mediciones realizadas en un equipo real. Los mismos deberán ser procesados adecuadamente para darles el formato exigido por el modelo.
Implementación del modelo en la computadora: El modelo es implementado
utilizando algún lenguaje de programación. Existen lenguajes específicos de simulación que facilitan esta tarea; también, existen programas que ya cuentan con modelos implementados para casos especiales.
Verificación: En esta etapa se comprueba que no se hayan cometidos errores
Validación: En esta etapa se comprueba la exactitud del modelo desarrollado. Esto
se lleva a cabo comparando las predicciones del modelo con: mediciones realizadas en el sistema real, datos bibliográficos o de sistemas similares. Como resultado de esta etapa puede surgir la necesidad de modificar el modelo o recolectar datos adicionales.
Diseño de experimentos: En esta etapa se decide las características de los
experimentos a realizar: el tiempo de arranque, el tiempo de simulación y el número de simulaciones.
Experimentación: En esta etapa se realizan las simulaciones de acuerdo al diseño
previo. Los resultados obtenidos son debidamente recolectados y procesados.
Interpretación: Se analiza la sensibilidad del modelo con respecto a los parámetros
que tienen asociados la mayor incertidumbre. Si es necesario, se deberán recolectar datos adicionales para refinar la estimación de los parámetros críticos.
Implementación: Conviene acompañar al usuario en la etapa de implementación
para evitar el mal manejo del simulador o el mal empleo de los resultados del mismo.
Documentación: Incluye la elaboración de la documentación técnica y manuales de
uso. La documentación técnica debe contar con una descripción detallada del modelo y de los datos; también, se debe incluir la evolución histórica de las distintas etapas del desarrollo. Esta documentación será de utilidad para el posterior perfeccionamiento del simulador (Tarifa, 2015).
Clasificación de los métodos de simulación
Las herramientas de simulación pueden clasificarse según diversos criterios, por ejemplo, según el tipo de procesos (batch o continuo), si involucra el tiempo (estacionario o dinámico -incluye a los equipos batch-), si maneja variables estocásticas o determinísticas, variables cuantitativas o cualitativas, etc.
A continuación se expondrán brevemente las características de los distintos tipos de herramientas de simulación generalmente utilizadas.
Simulación cualitativa y cuantitativa
La simulación cualitativa tiene por objeto principalmente el estudio de las relaciones causales y las tendencias temporales cualitativas de un sistema, como así también la propagación de perturbaciones a través de un proceso dado. Llamamos valores cualitativos de una variable, a diferencia del valor numérico (cuantitativo), a su signo; ya sea absoluto, o bien con relación a un valor dado o de referencia. Por lo tanto, en general se trabaja con valores tales como (+, -, 0). Son varios los campos de aplicación de la simulación cualitativa, por ejemplo el análisis de tendencias, supervisión y diagnóstico de fallas, análisis e interpretación de alarmas, control estadístico de procesos, etc.
La simulación cuantitativa, en cambio, es aquella que describe numéricamente el comportamiento de un proceso, a través de un modelo matemático del mismo. Para ello se procede a la resolución de los balances de materia, energía y cantidad de movimiento, junto a las ecuaciones de restricción que imponen aspectos funcionales y operacionales del sistema. La simulación cuantitativa abarca principalmente la simulación en estado estacionario y la simulación en estado dinámico.
Simulación estacionaria y dinámica.
La simulación en estado estacionario implica resolver los balances de un sistema que no involucra la variable temporal, por lo que el sistema de ecuaciones deberá estudiar o reflejar en el modelo las variaciones de las variables de interés con las coordenadas espaciales (modelos a parámetros distribuidos); entonces deberá utilizarse un sistema de ecuaciones diferenciales a derivadas parciales (según el número de coordenadas espaciales consideradas). Un ejemplo puede ser la variación radial de la composición en un plato en una columna de destilación, la variación de las propiedades con la longitud y el radio en un reactor tubular, etc. Por otra parte, y como su nombre lo indica, la simulación dinámica plantea los balances dependientes del tiempo, ya sea para representar el comportamiento de equipos batch, o bien para analizar la evolución que se manifiesta en el transitorio entre dos estados estacionarios para un equipo o una planta completa. En este
diferenciales ordinarias cuya variable diferencial es el tiempo. En caso contrario, se deberá resolver un sistema de ecuaciones diferenciales a derivadas parciales, abarcando tanto las coordenadas espaciales como la temporal.
Desde el punto de vista de los fenómenos o sistemas que se estudian, la simulación puede también clasificarse en determinística o estocástica. Como modelo determinístico consideramos aquél en el cual las ecuaciones dependen de parámetros y variables conocidos con certeza, es decir que no existe incertidumbre ni leyes de probabilidades asociadas a las mismas. En cambio en un modelo estocástico, como su nombre lo indica, ciertas variables estarán sujetas a incertidumbre, que podrá ser expresada por funciones de distribución de probabilidad. En este caso, por lo tanto, también los resultados del modelo estarán asociados a una ley de probabilidad. En esta obra estudiaremos únicamente los modelos determinísticos, dejando de lado los procesos estocásticos y la simulación de los mismos.
Por último, también cabe mencionar la simulación de eventos discretos, en la cual existen variables de interés que no tienen un comportamiento continuo. Existen numerosos procesos que sólo pueden simularse desde este punto de vista. Por ejemplo, la simulación o diseño de plantas batch multiproducto o multipropósito, o ambas simultáneamente, poseen características que imponen un modelo discreto para contemplar ciertos eventos de interés. Desde este punto de vista se deben utilizar modelos especiales para tratar funciones semicontinuas y en presencia de eventos discretos (Scenna, 1999).
Clasificación de simuladores
Los simuladores de procesos pueden dividirse en los siguientes tipos según el enfoque bajo el cual se plantea el modelo matemático que representa el proceso a simular:
simuladores globales u orientados a ecuaciones
simuladores secuenciales modulares
Simuladores Globales u orientados a ecuaciones
Bajo el enfoque de la simulación global u orientada a ecuaciones, se plantea el modelo matemático que representa al proceso construyendo un gran sistema de ecuaciones algebraicas que representa a todo el conjunto o planta a simular. De esta forma el problema se traduce en resolver un gran sistema de ecuaciones algebraicas, por lo general altamente no lineales. Como ejemplo puede citarse en problemas típicos de simulación de columnas de destilación por métodos rigurosos el sistema de ecuaciones puede llegar a contener más de mil variables. De ello se desprende la magnitud del sistema que represente el modelo de una planta completa típica (Himmelblau, 1997).
En la década del 70, cuando se generan los primeros simuladores, no existían los medios apropiados (principalmente hardware) para la resolución numérica de sistemas de ecuaciones de gran dimensión. Es por ello que los primeros simuladores comerciales adoptaron principalmente la arquitectura modular, en detrimento de la global (Scenna, 1999).
El principal problema asociado a la filosofía de resolución global u orientada a ecuaciones es la convergencia del sistema y la consistencia de las soluciones que se encuentran. En efecto, los sistemas altamente no lineales como los que corresponden a modelos de plantas químicas pueden, por ejemplo, producir múltiples soluciones. Además, la solución numérica para grandes sistemas exige estimaciones iniciales apropiadas, es decir próximas a un entorno de la solución, de lo contrario pueden presentarse serios inconvenientes.
Históricamente, estas dificultades han sido la causa que ha limitado el desarrollo de este tipo de simuladores en forma masiva. Una de las críticas fundamentales para la operación de los mismos que se realizaba a menudo por parte de usuarios no entrenados, era la imposibilidad de identificar los sectores de la planta en correspondencia con el sistema de ecuaciones que lo representa, dado que una vez que se hubo armado el sistema total, éste está integrado y se pierde la correspondencia biunívoca entre el equipo y el subsistema de ecuaciones que lo representa. De esta manera, si existieran inconvenientes durante la simulación, resulta difícil asignar el problema a un sector específico de la planta, o bien inicializar
convenientemente (Sifuentes, 2000). Las principales características (virtudes y defectos históricamente remarcados) se resumen en la Tabla 1.1.
Tabla 1. Principales características de los simuladores Globales u orientados a ecuaciones
Cada equipo se representa por las ecuaciones que lo modelan. El modelo es la integración de todos los subsistemas.
Desaparece la distinción entre variables de proceso y parámetros operativos, por lo tanto se simplifican los problemas de diseño.
Resolución simultánea del sistema de ecuaciones algebraicas (no lineales) resultante.
Mayor velocidad de convergencia.
Necesita una mejor inicialización (mejor cuanto mayor sea el problema a resolver).
A mayor complejidad, menor confiabilidad en los resultados y más problemas de convergencia (soluciones sin sentido físico).
Más difícil de usar por "no especialistas".
Una ventaja importante es que puede logarse una velocidad de convergencia cuadrática, esto es, mayor que en los simuladores secuenciales, como se verá más adelante. Además, dado que el sistema se plantea orientado a ecuaciones, es posible incorporar fácilmente las expresiones de restricción para definir problemas de optimización en forma directa, ya que solo basta con plantear las restricciones y la función de optimización. Esta flexibilidad es imposible en los simuladores secuenciales modulares, debido a que los módulos están orientados y definidos en forma rígida, esto es, resulta imposible agregar restricciones y/o variables, además de la expresión analítica de la función de optimización, debiéndose proceder tipo “caja negra” (Sifuentes, 2000).
Simuladores Secuenciales-Modulares
Los simuladores modulares secuenciales se basan en módulos de simulación independientes que siguen aproximadamente la misma filosofía que las operaciones unitarias, es decir, cada equipo: bomba, válvula, intercambiadores de calor, etc.; es simulado a través de modelos específicos para el mismo y además, el sentido de la información coincide con el “flujo físico” en la planta. En esta filosofía se tiene como ventaja el hecho que cada sistema de ecuaciones es resuelto con una metodología que resulta adecuada para el mismo, ya que es posible analizar bajo todas las circunstancias posibles, el comportamiento del método de resolución propuesto, esto es sistemas ideales, no ideales, topología diversa del equipo, distintas variantes, etc. Dado que se puede analizar específicamente la performance de los distintos métodos de resolución es factible lograr un modelo robusto y eficiente para cada módulo específico. (Himmelblau, 1997)
Tabla 2. Principales Características de los Simuladores Modulares Secuenciales.
Biblioteca de módulos (uno para cada equipo) Flow sheet: Equivale a un grafo orientado o dígrafo Orden de resolución fijo (iteraciones)
Tres niveles de iteración (se incorpora otro si se desea optimizar) 1. Cálculos fisicoquímicos.
2. Módulos en sí (ej. flash, columna, etc.). 3. Variables de iteración (reciclos).
4. Optimización
Modelos individuales resueltos eficientemente.
Fácilmente comprendido por ingenieros "no especialistas en simulación". Métodos de convergencia robustos.
La información ingresada por el usuario (relacionable con equipos o corrientes) resulta fácilmente chequeable e interpretable.
Los problemas de diseño (selección de parámetros) son más difíciles de resolver. Se incrementa la dificultad cuando se plantea un problema de optimización (funcionan como cajas negras).
Conceptualmente, bajo esta filosofía, para cada módulo de simulación (equipo) deberá plantearse su modelo matemático. Obviamente, para encarar la solución de cualquier sistema de ecuaciones deben diferenciarse los valores conocidos y los que deben calcularse, todo esto teniendo en cuenta los grados de libertad; es decir, la compatibilidad entre el número de ecuaciones y de incógnitas, a fin de obtener un sistema con solución única. El enfoque en la teoría secuencial modular por definición supone que se conocen (especifican) las variables de las corrientes de entrada, o sea las alimentaciones a los equipos, mientras que deben calcularse las corrientes de salida y los correspondientes parámetros de operación si correspondiera. Esto según comentamos, impone cierta rigidez que sacrifica, según sea el caso, la posibilidad de encontrar asignaciones tales que minimicen el tiempo de cómputo. Sin embargo esto resulta conveniente desde otro punto de vista, ya que de esta manera se impone una dirección al flujo de información entre módulos. Por otra parte, las combinaciones posibles de especificación de variables son enormes, incrementándose en forma dramática la cantidad de módulos a disponer si se quisiera cubrir todas las posibilidades.
En general, fijada la orientación en el cálculo (esto es dadas las entradas calcular las salidas del equipo), lograr que el sistema de ecuaciones sea compatible y tenga tantas incógnitas como ecuaciones no implica necesariamente una única opción, ya que debemos analizar las variables o parámetros de operación del equipo. En efecto, en la mayoría de los casos existirán varias combinaciones de valores posibles, es decir, existirán varias posibilidades de asignación de parámetros de equipos. Además, existen variantes para cada módulo que tienen en cuenta varios factores, como ser topología, -por ejemplo el número de entradas y salidas a una torre de destilación, o si hay condensadores parciales o totales-, o bien el nivel de las hipótesis realizadas (si se considera hidráulica de platos o no, pérdidas de calor al ambiente, etc.). (Scenna, 1999)
Resumiendo, en un simulador modular se define cada módulo por un sistema de ecuaciones independiente que se resuelve de la manera óptima, subordinados sin embargo a las limitaciones que ha impuesto la especificación de variables seleccionada. Esto implica una ventaja en el sentido que se podrían utilizar progresivamente distintos niveles de cálculo dependiendo de la etapa del proyecto en la que se realiza la simulación, o bien en función de los datos disponibles hasta el momento, aprovechando el conocimiento que proviene de la experiencia y análisis
del método de convergencia para cada caso en particular. No obstante, uno de los problemas que se originan es la conexión de los módulos según el proceso a simular y las rigideces que ello impone. La representación del diagrama de flujo (flow sheet) del proceso se traduce a un diagrama similar, llamado diagrama de flujo de información (DFI). Este diagrama matemáticamente es un dígrafo, en el cual los nodos son los módulos de equipos conectados uno a uno a través de las corrientes que los vinculan, las cuales se representan como arcos dirigidos. Estas corrientes de información por lo general coinciden con las corrientes físicas de la planta, pero no necesariamente en todos los casos. Lo mismo sucede con los equipos (nodos del dígrafo). En algunas oportunidades, será necesario representar un equipo real de la planta mediante la conexión de varios módulos disponibles en la biblioteca de módulos del simulador.
En síntesis, dado que en la filosofía modular, por definición los módulos resultan orientados, al construirse el diagrama de flujos del sistema, si éste contiene reciclos será necesario disponer de un procedimiento de cálculo iterativo para resolver los balances del proceso completo. Desde el punto de vista del análisis numérico, se puede afirmar que bajo el procedimiento de la filosofía modular secuencial se introducen tres niveles característicos de iteración, a diferencia de los simuladores orientados a ecuaciones donde existe sólo uno. Se debe iterar al nivel de cálculos fisicoquímicos, de módulos de equipos, y por último, a nivel del DFI o diagrama de flujo de la planta completa. Más aún, para problemas en los cuales se defina la optimización de alguna performance del proceso expresada según una función objetivo y las variables de optimización correspondientes, se introduce un nuevo nivel de iteración, por sobre el nivel correspondiente al DFI. (Sifuentes, 2000)
La estrategia de contemplar los grados de libertad posibles en la orientación de los módulos para mejorar la performance y flexibilidad del simulador basado en una óptica modular secuencial es utilizada por algunos simuladores comerciales para disminuir el tiempo de cómputo al reducir el número de corrientes iteradoras.
Simuladores Híbridos
Es posible plantear el desarrollo de simuladores combinando la estrategia modular y la orientada a ecuaciones de forma tal de aprovechar los aspectos positivos de ambas metodologías lo máximo posible. Para ello se selecciona un grupo de variables sobre las cuales se procederá según la filosofía global, esto es, se las resolverá simultáneamente, mientras que para el resto se mantiene la filosofía modular, es decir, se trata de encontrar una secuencia acíclica, que provea por su cálculo, en cada iteración, los valores de las variables a resolverse simultáneamente. Es por ello que a esta filosofía también se la conoce como “two-tear” o “de dos niveles jerárquicos”, ya que se trabaja en uno con las variables tratadas simultáneamente, y en el otro secuencialmente. Otro nombre con el que se conoce este enfoque es modular secuencial-simultáneo. (Scenna, 1999)
Con el advenimiento de nuevos paradigmas de programación (que, a diferencia de los lenguajes estructurados, hacen posible la manipulación de información simbólica, recursividad, programación orientada a objetos, etc.); se logra fácilmente generar algoritmos que cumplan respecto del armado de un sistema de ecuaciones global; la misma tarea lógica que debe realizarse en un simulador secuencial para administrar los módulos parciales que representan la planta completa. En otras palabras, es posible, tomando como dato el diagrama de flujo del proceso, diagramar una “interfaz inteligente o lógica”, que “arme” el sistema de ecuaciones correspondientes a los equipos seleccionados y de alguna forma considerar las interconexiones entre los mismos, a través de la identificación de las corrientes de entrada - salida como variables de conexión; elaborando de esta manera, a partir de los subsistemas, la gran matriz que representa el sistema global de ecuaciones de toda la planta. Consecuentemente, este sistema lógico (generación del sistema de ecuaciones que representa la planta completa), sería la interfaz hacia el usuario; presentaría a éste los equipos en un formalismo o lenguaje natural (como un simulador modular), mientras que hacia el simulador los traduciría en un único sistema de ecuaciones a ser resuelto. En este caso existiría una especie de banco o biblioteca de “módulos conteniendo subsistemas de ecuaciones de balance genéricas”, y no módulos de equipos (Henning, G., Leone, H., Stephanopoulos, Geo., 1990) (Himmelblau, 1997). Además, la inicialización podría resolverse con la misma estrategia. Las estimaciones correspondientes pueden ser volcadas en forma conveniente a la
inicialización del sistema global, a través de la interfaz inteligente, que presentaría al usuario “equipos” o variables con su “interpretación” física, pero hacia el simulador los traduciría al lenguaje matemático, esto es, las variables correspondientes en el sistema global de ecuaciones asociado a la planta completa.
En definitiva, la performance del sistema en cuanto a comunicación amigable, transparencia y flexibilidad hacia el usuario, sería indistinguible respecto de uno modular. La diferencia radicaría en la estructura asociada al problema matemático y en la estrategia de resolución del sistema de ecuaciones de gran dimensión, que como sabemos tiene una velocidad de convergencia cuadrática contra una menor del sistema modular. Debe balancearse entonces velocidad de convergencia vs robustez al resolver sistemas de ecuaciones de elevada dimensión, para optar entre una filosofía u otra. A medida que evolucionan los algoritmos y el software correspondiente para la solución de grandes sistemas de ecuaciones, mayor es la facilidad con que puede implementarse esta nueva filosofía en el diseño de simuladores de uso general. Más aún, existe en nuestros días una diversidad de productos comerciales que parcialmente llevan a la práctica los principios aquí discutidos. En efecto, uno de los condicionantes es la relativa necesidad de utilizar un criterio orientado a ecuaciones al enfrentar la simulación dinámica de plantas completas. Dado que los nuevos simuladores tienden a dotar al usuario de la facilidad de simular la planta tanto en estado estacionario como dinámico, es conveniente para el desarrollo de estos simuladores, migrar a la filosofía global (Sifuentes, 2000).
Se espera que en el futuro los modelos estén basados progresivamente en la filosofía global u orientada a ecuaciones debido al progreso del software y hardware. Esto permitirá además mayor flexibilidad en el planteo de problemas muy diversos, como la simulación estacionaria y dinámica, optimización, etc. Esto por otra parte, obligará al usuario a conocer cada vez más los detalles, tanto matemáticos como estructurales, así como también, la implementación de modelos específicos, ya que en una filosofía orientada a ecuaciones, solo implica agregar un paquete de ecuaciones adicionales a las contenidas en la “biblioteca” de módulos-ecuaciones del simulador (Scenna, 1999).
Características de los Simuladores Comerciales
Entre los programas de simulación que se encuentran disponibles en el mercado actualmente se puede mencionar a: HYSIM, CHEMCAD, UNISIM.
A continuación se expondrán algunas de las principales ventajas y desventajas de estos productos.
Ventajas
Metodología de cálculo en estado estacionario: los cálculos en el diagrama de flujo son realizados automáticamente cuando el usuario aporta información. Los resultados de cualquier cálculo pasan automáticamente a otra corriente u operación que esté afectada por el cálculo, propagando los resultados a través del diagrama de flujo. La información parcial (insuficiente para permitir un cálculo completo) también es dirigida bidireccionalmente a través del diagrama de proceso.
Metodología de cálculo en estado dinámico: cada operación unitaria individual contiene la información necesaria para calcular su respuesta dinámica, así como también integrar algebraicamente.
Multi-Flow sheet: Se puede instalar un número ilimitado de diagramas de flujo en una simulación. La información de cualquier locación es accesible en cualquier momento. (HoneyWell, 2010)
Sub-flow sheets y flow sheet “templates”: Cada diagrama de flujo posee un paquete de fluidos (componentes, propiedades, reacciones, etc.). Un subdiagrama aparece como una operación multientrada/salida y es resuelto automáticamente como cualquier otra operación. Los “templates” (plantillas) pueden ser construidos específicamente con paquetes de fluidos, operaciones, corrientes, especificaciones del proceso, etc., y guardados en disco.
Los cálculos de equilibrio de fase pueden ser automáticamente realizados por el método apropiado para el diagrama de flujo. Una vez que la composición y dos variables de estado (presión, temperatura, fracción de vapor o entalpía) son conocidas para una corriente, esta es automáticamente calculada. Los cálculos de las propiedades físicas son realizados automáticamente para cada fase. (Godoy-Rodríguez, 2013)
Diagramas de Flujo y Reportes configurables, en MS Word o MS Excel.
Poderosas capacidades de gráfico: curvas de destilación/absorción, diagramas de fases, diagramas presión-temperatura vs. Concentración.
Datos exportables a Excel.
Poderosa herramienta de Optimización de Procesos. (Wikispaces, 2015)
Herramienta de Análisis de Sensibilidad
Interfaces con Lotus 1-2-3, Excel y AutoCAD (para producir diagramas de ingeniería).
Conexión con Visual Basic/ Excel que le permite programar sus propias operaciones unitarias dentro del diagrama de proceso, utilizando funciones termodinámicas y la base de datos de sustancias puras desde Excel. (Worldpress, 2011)
Convergencia de operaciones unitarias independientes del diagrama de proceso. Esta característica es excelente para un manejo más veloz en simulaciones grandes y complejas.
Preselección automática de modelos termodinámicos (CHEMCAD detecta el tipo de sustancias en la catálogo de componentes y recomienda un modelo termodinámico automáticamente. (Collantes-Wilmer, 2006)
Equilibrio Líquido-Líquido y Vapor-Líquido
Estimación de propiedades físicas de productos no definidos
Incluyen paquetes termodinámicos especiales para AMINAS y POLIMEROS.
Predicción de azeótropos, formación de dos fases líquidas, puntos de burbuja y rocío a diferentes temperaturas y presiones.
Modelos de torres sencillas y rigurosas con cortes laterales.
Modelos rigurosos de equipos con platos y empaques aleatorios.
CHEMCAD no toma atajos, no supone etapas ideales, usa correlaciones rigurosas de transferencia de masa aprobadas por reconocidas instituciones como el AIChE.
Destilaciones Reactivas con hasta 20 reacciones.
Amplia base de datos de propiedades físicas de componentes puros (más de 1900). (Cabrera Benítez, 2007)
Disponibilidad de los métodos de Pitzer y NRTL para electrolitos fuertes y débiles. Estos métodos han sido modificados para incluir parámetros de
Parámetros de interacción binaria y terciaria.
Datos de equilibrio de reacción de electrolitos en los sistemas industriales más comunes.
Predicción automática del pH de la solución. Desventajas
CHEMCAD:
o Sólo tiene programados cierta cantidad de problemas tipo para cada equipo.
o Sólo posee el método de la temperatura media logarítmica para el intercambio de calor y asume que ésta ocurre en condiciones ideales. o El sistema de unidades se selecciona al principio y todos los datos
ingresados posteriormente deben estar en el sistema elegido. El usuario no puede ingresar los datos en distintos tipos de unidades. o Sólo muestra los resultados finales en los archivos de documentación y
no etapas de cálculo intermedias.
HYSIM y UNISIM:
o Tienen las opciones de configuración general y preferencias dispersas en múltiples submenús de diferentes menús que no siguen un orden lógico.
o Si bien los cuadros de diálogo son amigables están sobrecargados con pestañas y subventanas que vuelven los procesos de configuración tediosos al pasear al usuario por una gran cantidad de pantallas y opciones.
o Poseen múltiples barras de herramientas con opciones variadas de tipos y configuraciones de equipos que ocupan demasiado espacio en pantalla.
o No toleran datos faltantes en la composición de las corrientes de entrada, si se encuentra con alguno lo ajusta a creo (Aspen Technology Inc, 2003) (HoneyWell, 2010).
Nuestro Simulador
Este proyecto pretendía crear un simulador de tipo híbrido que combinara la mayor velocidad de convergencia de los simuladores orientados a ecuaciones con la especificidad para cada equipo característica de los programas modulares secuenciales.
Era deseable que el software abordara de manera genérica el proceso como un todo siguiendo la lógica orientada a ecuaciones. Sin embargo para simplificar esta tarea, que podía ser considerable en procesos grandes, también fue necesario que el simulador posea herramientas exclusivas de cada operación a simular que le permitieran resolver algunas incógnitas de manera más rápida y eficiente.
Se buscó que el producto fuera bidireccional, o sea que la información ingresada por el usuario, o calculada por el programa, se propagase hacia adelante y hacia atrás en el proceso afectando a todos los equipos relacionados directa o indirectamente por dichos eventos.
También resultó de interés que fuera predictor-corrector de modo que no solicitase estimaciones iniciales de las variables a resolver y que luego de cada iteración los resultados hallados fueran corregidos hasta minimizar el error asociado con ellos a un nivel aceptable. También se pretendió que se solicitara la mínima cantidad de información posible al usuario y que el simulador determinase en base a esa información propiedades tales como número de fases, composición de ellas, cálculo de temperaturas por correlación con valores de entalpía, etc.
En el presente proyecto se propuso además mejorar los aspectos de comunicación entre el programa y el usuario de modo que fuera más amigable y natural.
En los capítulos finales del informe se retomará este punto y se realizará un análisis de los resultados obtenidos.
Bibliografía
Aspen Technology Inc. (2003). HYSYS Tutorial & Applications. Cambridge.
Cabrera Benítez, D. (2007). Diseño e Implementación de un Simulador de un SPU. Collantes-Wilmer. (2006). Handbook of Unit Operations using CHEMCAD. Cyrius
Technology Inc.
Godoy-Rodríguez. (2013). (U. F. Rosario, Ed.) Recuperado el 20 de Abril de 2015 Himmelblau, D. M. (1997). Principios Básicos y Cálculos en Ingeniería Química.
México D.F.: Prentice Hall.
HoneyWell. (2010). UNISIM Design. London.
LANDER. (15 de Septiembre de 2014). Recuperado el 15 de Septiembre de 2014, de http://www.landersimulation.com/formacion-con-simulacion/el-mundo-en-movimiento/historia-de-la-simulacion/
Scenna, N. J. (1999). Modelado, Simulación y Optimización de Procesos Químicos. Sifuentes, M. (2000). Simulación de Procesos en Ingeniería Químicia. México D.F.:
Plaza y Valdés Editores.
Tarifa, E. E. (2015). Teoría y Modelos de Simulación. Universidad Nacional de Jujuy.
Wikispaces. (2015). Recuperado el 20 de Abril de 2015, de
https://simulacionprocesos.wikispaces.com/Ventajas+y+desventajas
Worldpress. (Mayo de 2011). Worldpress. Recuperado el 15 de Abril de 2015, de https://unitorunozeydiio.files.wordpress.com/2011/05/chemcad.pdf
Capítulo 2: Objetivos
Objetivos Generales
1. Crear un programa de computadora capaz de resolver los cálculos asociados a las operaciones unitarias de transferencia de calor y de masa.
2. Desarrollar una interface gráfica de usuario para el programa antes mencionado.
Objetivos Específicos
1. Realizar un relevamiento de las tecnologías existentes.
2. Estudiar la programación orientada a objetos y la técnica de las interfaces gráfica de usuario.
3. Desarrollar los elementos visuales (menús, botones, mensajes, etc.) que conformarán la interface de comunicación con el usuario.
4. Crear módulos computacionales que representen a los compuestos químicos y a los equipos involucrados en un proceso industrial.
5. Desarrollar una biblioteca de funciones que realicen cálculos termodinámicos típicos y necesarios para el cálculo de propiedades fisicoquímicas.
6. Programar los balances de materia y energía para los distintos equipos de proceso.
7. Integrar los elementos anteriores con los módulos de cálculo. 8. Realizar pruebas. Detectar fallas. Optimizar lo programado. 9. Confeccionar el manual de usuario.
Capítulo 3: Programación
Introducción
En el siglo pasado se ha utilizado la programación estructurada como paradigma de resolución de problemas. Aquella consiste en descomponer un problema complejo en problemas más simples y éstos en otros más sencillos, continuando este proceso hasta alcanzar un nivel de complejidad lo suficientemente bajo para que las tareas involucradas puedan ser realizadas por una computadora. Por lo tanto esta filosofía se caracteriza por la descomposición del problema en verbos, acciones que deben ser llevadas a cabo en un orden determinado para conseguir resolver el problema original. La estructura informática básica de la programación estructurada es el procedimiento o la función, que son una serie de instrucciones que operan sobre las variables involucradas en el proceso y producen un determinado resultado; de esta forma se implementan informáticamente las acciones en las que se ha descompuesto el problema del mundo real.
Hacia la última década del siglo pasado y la primera del presente fue ganando impulso otra filosofía, la programación orientada a objetos. Esto se debió a la necesidad de modelar de una forma más natural la realidad y también debido a la complejidad creciente de los problemas a abordar. Este nuevo paradigma se basa en la descomposición de los problemas en objetos. Un objeto es la representación computacional de un concepto del mundo real que contiene toda la información necesaria para definirlo. Esta información se compone de atributos y métodos. Los atributos son las características del objeto, sus propiedades tales como dimensiones físicas, color, temperatura, posición, energía, masa, etc. Mientras que los métodos son funciones que se encargan de implementar los comportamientos que determinan sus acciones propias. Los métodos pueden modificar los atributos del objeto al que pertenecen y también los de otra entidad. Las interacciones con otros objetos que forman parte del escenario se llevan a cabo mediante mensajes que intercambian los objetos.
Programación orientada a objetos
La programación orientada a objetos es una “filosofía”, un modelo de programación, con su teoría y su metodología, que conviene conocer y estudiar. Un lenguaje orientado a objetos es un lenguaje de programación que permite el diseño de aplicaciones orientadas a objetos. Lo normal es que toda persona que vaya a desarrollar aplicaciones orientadas a objetos aprenda primero la “filosofía” (o adquiera la forma de pensar) y después el lenguaje, porque “filosofía” sólo hay una y lenguajes muchos (Tarifa, 2015). En este capítulo se presentan los conceptos básicos de la programación orientada a objetos desde un punto de vista global, que resulta válido para cualquier lenguaje de programación.
Definición de objeto
Un objeto es un conjunto de variables (o datos) y métodos (o funciones) relacionados entre sí. Los objetos en programación se usan para modelar objetos o entidades del mundo real (una bomba, un intercambiador de calor, un evaporador, por ejemplo). Un objeto es, por lo tanto, la representación en un programa de un concepto, y contiene toda la información necesaria para abstraerlo: datos que describen sus atributos y operaciones que pueden realizarse sobre los mismos. La siguiente figura muestra una representación visual de un objeto.
Figura 1. Representación gráfica de un objeto.
Los atributos del objeto (estado) y lo que el objeto puede hacer (comportamiento) están expresados por las variables y los métodos que componen el objeto respectivamente.
Estas variables reciben el nombre de variables instancia o variables miembro porque se refieren al estado de un objeto en particular. En la programación orientada a objetos un objeto en particular se denomina una instancia.
Además de variables, un objeto podría tener métodos. Estos métodos se denominan formalmente métodos instancia o métodos miembro, ya que cambian el estado de una instancia u objeto particular. La siguiente figura muestra un equipo modelado como un objeto:
Figura 2. Modelo de un flash.
El diagrama anterior muestra las variables del objeto en el núcleo o centro del mismo y los métodos rodeando el núcleo y protegiéndolo de otros objetos del programa. Este hecho de empaquetar o proteger las variables miembro con métodos miembro se denomina encapsulación. Este dibujo conceptual es la representación ideal de un objeto y es el ideal que los programadores suelen buscar. Sin embargo, por razones prácticas, es posible que un objeto desee exponer alguna de sus variables miembro, o proteger otras de sus propios métodos o funciones miembro.
De todos modos, el hecho de encapsular las variables y las funciones miembro relacionadas proporciona dos importantes beneficios a los programadores de aplicaciones:
Capacidad de crear módulos: El código fuente de un objeto puede escribirse y mantenerse independiente del código fuente del resto de los objetos. De esta forma, un objeto puede pasarse fácilmente de una parte a otra del programa.
Protección de la información: Un objeto tendrá una interfaz pública perfectamente definida que otros objetos podrán usar para comunicarse con él. De esta forma, los objetos pueden mantener información privada y pueden cambiar el modo de operar de sus funciones miembros sin que esto afecte a otros objetos que usen estas funciones miembro.
Definición de Mensaje
Normalmente un único objeto por sí solo no es muy útil. En general, un objeto aparece como un componente más de un programa o una aplicación que contiene muchos otros. Es precisamente haciendo uso de esta interacción que se consigue una funcionalidad de mayor orden y modelar comportamientos mucho más complejos.
Los objetos de un programa interactúan y se comunican entre ellos por medio de mensajes. Cuando un objeto A quiere que otro objeto B ejecute una de sus funciones miembro (métodos de B), el objeto A manda un mensaje al objeto B.
Figura 3. Comunicación entre objetos a través de mensajes.
En ocasiones, el objeto que recibe el mensaje necesita más información para saber exactamente lo que tiene que hacer. Esta información se pasa junto con el mensaje en forma de parámetro.
Las tres partes que componen un mensaje son: 1. El objeto al cual se manda el mensaje.
3. Los parámetros que necesita ese método.
Estas tres partes del mensaje (objeto destinatario, método y parámetros) son suficiente información para que el objeto que recibe el mensaje ejecute el método o la función miembro solicitada. Los mensajes proporcionan dos ventajas importantes:
El comportamiento de un objeto está completamente determinado (a excepción del acceso directo a variables miembro públicas) por sus métodos, por lo tanto los mensajes representan todas las posibles interacciones que pueden realizarse entre objetos. Por ejemplo un objeto de la clase “Nodo_Divisor” tiene un método “__init__” que crea automáticamente algunos atributos (nombre, lista de ecuaciones, de incógnitas, etc.). Otro método “Actualizar” que se encarga de incorporar nueva información proveniente del diálogo de ese nodo y trata de cambiar el estado del nodo (valor de sus propiedades) si es posible. Otros métodos cuyo propósito es evidente son: “Buscar_Incognitas”, “Formular_Ecuaciones”, “CalcularGL” (calcula los grados de libertad) y “Resolver”. Así, estos métodos definen completamente el comportamiento del objeto “Nodo_Divisor”.
Los objetos no necesitan formar parte del mismo proceso, ni siquiera residir en un mismo ordenador para mandarse mensajes entre ellos (y de esta forma interactuar). Por ejemplo un botón de mezclador es un objeto diferente del diálogo de mezclador y del objeto clase “Mezclador”, pero el botón desencadena la creación del diálogo y le envía a éste último el correspondiente objeto mezclador. El objeto “Mezclador”, que pertenece a un objeto superior clase “Proyecto”, es independiente del botón, que pertenece a otro objeto superior clase “Pantalla”, y también lo es del objeto diálogo que no tiene superiores. Pero un mezclador intercambia información de propiedades con el diálogo de configuración de mezclador y responde sólo a su botón.
Definición de Clase
Una clase es una plantilla que define las variables y los métodos que son comunes para todos los objetos de un cierto tipo.
De este modo todos los objetos de una misma clase tienen atributos y métodos en común. Sin embargo el valor de los atributos de una instancia en particular puede diferir del valor de esos mismos atributos en otra instancia, pero ambas pertenecen a la misma clase y tienen los mismos tipos de atributos. De igual manera, el hecho de que una instancia ejecute uno de sus métodos en un determinado momento no implica que todas las instancias de la misma clase deban imitar ese comportamiento.
Figura 4. Mezclador como ejemplo de clase.
Herencia
Una vez que hemos visto el concepto de clase y el de objeto, estamos en condiciones de introducir otra de las características básicas de la programación orientada a objetos: el uso de la herencia.
El mecanismo de herencia permite definir nuevas clases partiendo de otras ya existentes. Las clases que derivan de otras heredan automáticamente todo su comportamiento, pero además pueden introducir características particulares propias que las diferencian. Entonces se conocen como subclases o clases derivadas.
Como hemos visto, los objetos se definen a partir de clases. Con el mero hecho de conocer a qué clase pertenece un objeto, ya se sabe bastante sobre él.
Además, no estamos limitados a un único nivel de herencia. El árbol de herencias o jerarquía de clases puede ser tan extenso como necesitemos. Los métodos y las
variables miembro se heredarán hacia abajo a través de todos los niveles de la jerarquía. Normalmente, cuanto más abajo está una clase en la jerarquía de clases, más especializado es su comportamiento.
La herencia es una herramienta clave para abordar la resolución de un problema de forma organizada, pues permite definir una relación jerárquica entre todos los conceptos que se están manejando. Es posible emplear esta técnica para descomponer un problema de cierta magnitud en un conjunto de problemas subordinados a él. La resolución del problema original se consigue cuando se han resuelto cada uno de los problemas subordinados, que a su vez pueden contener otros. Por consiguiente, la capacidad de descomponer un problema o concepto en un conjunto de objetos relacionados entre sí cuyo comportamiento es fácilmente identificable puede ser extraordinariamente útil para el desarrollo de programas informáticos.
La herencia proporciona las siguientes ventajas:
Las clases derivadas o subclases proporcionan comportamientos especializados a partir de los elementos comunes que hereda de la clase base. A través del mecanismo de herencia los programadores pueden reutilizar el código de la superclase tantas veces como sea necesario.
Los programadores pueden implementar las llamadas superclases abstractas, que definen comportamientos genéricos. Las clases abstractas definen e implementan parcialmente comportamientos, pero gran parte de estos comportamientos no se definen ni se implementan totalmente. De esta forma, otros programadores pueden hacer uso de estas superclases detallando esos comportamientos con subclases especializadas. El propósito de una clase abstracta es servir de modelo base para la creación de otras clases derivadas, pero cuya implementación depende de las características particulares de cada una de ellas.
