Desarrollo de un visualizador 3D para la interpretación de concentraciones de toxinas en embalses

Desarrollo de un visualizador 3D para la interpretación de concentraciones de toxinas en embalses Development of a 3D viewer for the interpretation of toxin concentrations in reservoirs Trabajo de Fin de Grado Curso 2023–2024 Autor Mohamed Tabakkouht Achouri Fumu Grace Makitu Koudymba Director José Luis Risco Martín Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid Desarrollo de un visualizador 3D para la interpretación de concentraciones de toxinas en embalses Development of a 3D viewer for the interpretation of toxin concentrations in reservoirs Trabajo de Fin de Grado en Ingeniería Informática Autor Mohamed Tabakkouht Achouri Fumu Grace Makitu Koudymba Director José Luis Risco Martín Convocatoria: Junio 2024 Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid 27 de mayo de 2024 Dedicatoria A mis padres, por su inquebrantable apoyo y confianza en mí, y a mi hermana Karima, por ser una fuente constante de inspiración y ejemplo. v Agradecimientos Quiero expresar mi más sincero agradecimiento a nuestro tutor de TFG, José Luis, por su orientación y guía en todas las fases de este proyecto. Agradezco también a todo el equipo de investigadores del proyecto SMART-BLOOM, cuyo trabajo va más allá de lo habitual y representa una gran labor social. Estoy seguro de que su esfuerzo contribuirá significativamente a predecir concentraciones de toxinas en el agua, mejorando así la salud pública. vii Resumen Desarrollo de un visualizador 3D para la interpretación de concentraciones de toxinas en embalses La proliferación de algas tóxicas en ecosistemas de agua dulce, como lagos y embalses, representa un grave problema para la salud pública. El sistema actual de monitoreo de estas proliferaciones se basa en la recogida manual de muestras, un método muy ineficiente que provoca retrasos en la predicción de estos eventos. Por ello, surge el proyecto SMART-BLOOM, una iniciativa de investigación que propone una forma innovadora de monitorear estas concentraciones. Este proyecto abarca desde la introducción de vehículos autónomos no tripulados en los embalses hasta la visualización y predicción de áreas propensas a estas proliferaciones. Hasta ahora, dentro del proyecto SMART-BLOOM, solo existía un visualizador bidimensional para analizar los resultados. Nuestro objetivo es contribuir a este proyecto de investigación desarrollando un visualizador 3D que permita visualizar el entorno acuático en profundidad, ofreciendo una nueva perspectiva. Este visualizador integra algunos de los modelos computacionales como EEMS y DEVS-BLOOM, con el fin de facilitar la interpretación de datos para los investigadores y autoridades sanitarias y ambientales, permitiéndoles tomar decisiones con mayor rapidez. Palabras clave Cianobacterias, concentraciones, modelado tridimensional, EEMS, DEVS-BLOOM, Blender, Three.js, Node.js. ix 3.20. Fps del visualizador tras la optimización . . . . . . . . . . . . . . . . 53 3.21. Número de draw calls tras la optimización . . . . . . . . . . . . . . . 54 3.22. Transmisión ilustrativa sin errores de un tamaño de ventana de 100 bytes. ................................... 56 4.1. Flujo de ejecución del sistema . . . . . . . . . . . . . . . . . . . . . . 59 4.2. Interfaz de la configuración de la misión . . . . . . . . . . . . . . . . 60 4.3. Reproductor con scroll para configurar el tiempo . . . . . . . . . . . . 62 4.4. Etiqueta con información al hacer doble click en un punto determinado 62 4.5. Representación de temperaturas en el visualizador . . . . . . . . . . . 63 4.6. Representacion del oxigeno . . . . . . . . . . . . . . . . . . . . . . . . 63 4.7. Interfaz completa micro-devs-bloom . . . . . . . . . . . . . . . . . . . 64 4.8. Representación de la primera celda en GeoGebra . . . . . . . . . . . . 66 4.9. Corrección de aristas de la primera celda en GeoGebra . . . . . . . . 67 4.10. Representación fallida utilizando la nueva geometría . . . . . . . . . . 67 4.11. Representación 3D de una parte del estanque de Santillana. . . . . . . 68 Índice de tablas 2.1. Intoxicaciones alimentarias en animales . . . . . . . . . . . . . . . . . 10 3.1. Tabla 3.2.1. Dimensiones de las variables de Washington-1m-200809_UGRID.nc .............................. 26 3.2. Sensores registrados dentro de micro-devs-bloom . . . . . . . . . . . . 45 xvii Cap´ ıtulo 1 Introducción El presente Trabajo de Fin de Grado (TFG) se inscribe en el marco de un proyecto de investigación respaldado por el Ministerio de Ciencia e Innovación, en colaboración con el Departamento de Arquitectura de Computadores de la Universidad Complutense de Madrid (UCM). Este proyecto tiene como objetivo principal abordar la problemática de las concentraciones de toxinas en embalses, una preocupación creciente en el ámbito medioambiental y de la salud pública. Hasta ahora, existía únicamente un sistema de monitorización y gestión de cianobacterias bidimensional. Este trabajo busca lograr una representación tridimensional para abordar esta problemática, ofreciendo una nueva perspectiva y facilitando la labor de investigadores, gestores ambientales y otros actores interesados en la monitorización y gestión de la calidad del agua. 1.1. Motivación En los ecosistemas de agua dulce, como lagos o estanques, las proliferaciones nocivas suelen ser ocasionadas por cianobacterias, conocidas como algas verde-azules, un tipo de microorganismo unicelular perteneciente al fitoplancton. Algunas de estas cianobacterias generan toxinas llamadas cianotoxinas, que pueden causar enfermedades tanto en humanos como en animales. Los síntomas varían dependiendo de varios factores, incluyendo el grado y la duración de la exposición, y la toxina involucrada. Las personas y los animales pueden entrar en contacto con cianotoxinas de diversas maneras: A través del contacto de la piel con el agua contaminada mientras nadan o realizan actividades acuáticas. Al ingerir agua que contiene cianotoxinas. Inhalando pequeñas gotas en el aire que contienen cianotoxinas. Al consumir pescado o mariscos contaminados con cianotoxinas. Ingiriendo suplementos nutricionales que contienen algas verde-azules contaminadas. 1 2Capítulo 1. Introducción Teniendo en cuenta que el agua dulce es un recurso limitado y que las proliferaciones nocivas de cianobacterias afectan directamente a la salud pública, el sistema actual se basa principalmente en la recolección manual de muestras de agua por parte de personal especializado. Estas muestras se analizan luego en laboratorio y, en los mejores casos, se utilizan instrumentos automáticos fijos para recopilar datos, aunque la toma de muestras en esta modalidad es menos común. Sin embargo, la disponibilidad limitada de recursos económicos y personal ha restringido la recolección manual a períodos específicos del año, cuando es más probable la presencia de cianobacterias, y solo en un número limitado de ubicaciones geográficas con poca frecuencia. Este sistema de reacción (predicción, prevención y mitigación) puede provocar retrasos. Por ende, han surgido sistemas de alerta temprana como SAICA, que monitorizan diferentes parámetros. Sin embargo, estos sistemas presentan muchos inconvenientes, como mediciones en puntos fijos sin tener en cuenta la dinámica y evolución de las cianobacterias. Además, estos procedimientos no proporcionan datos con la resolución espacial y temporal deseable para anticipar la formación de cianobacterias. Es por ello que surge el proyecto SMART-BLOOM, con el fin de desarrollar sistemas de vigilancia de cianobacterias y cianotoxinas en las zonas protegidas de áreas de captación o de aguas de baño, desarrollar modelos matemáticos que ayuden a predecir la calidad de las zonas de baño con precisión, y desarrollar servicios digitales que permitan informar y predecir el estado de los recursos en tiempo (cuasi-)real. El proyecto SMART-BLOOM tiene tres fases, que abarcan desde la recolección de datos iniciales hasta la realización de predicciones y la posterior visualización y análisis de estas predicciones. Las fases son las siguientes: Edge: la capa edge es la más baja y en ella se encuentran los dispositivos necesarios para recopilar información sobre el sistema acuático, como sensores, cámaras o USV (Vehículos de Superficie No Tripulados). Fog: es una capa intermedia entre Edge y Cloud. Esta capa se encarga de procesar los datos en tiempo real y de reducir el número de datos que deben enviarse a la nube. Cloud: realiza tareas complejas de análisis de datos y aprendizaje automático para la posterior visualización y predicción de poblaciones de cianobacterias. Nuestro proyecto se enmarca dentro de la fase Cloud, donde actualmente solo se dispone de una visualización en 2D. Nuestro objetivo será desarrollar un sistema de visualización en 3D que permita a las autoridades una mayor facilidad en la interpretación de concentraciones y formaciones de cianobacterias. 1.2. Objetivos El objetivo general del trabajo es desarrollar un visualizador 3D avanzado que permita la interpretación intuitiva y eficaz de las concentraciones de toxinas en embalses, facilitando la comprensión de los resultados numéricos de modelos computacionales y contribuyendo a la validación de los modelos de calidad del agua. 1.3. Plan de trabajo 3 Los objetivos específicos son los siguientes: 1. Diseño de un visualizador 3D: crear una herramienta de visualización que represente de manera tridimensional las concentraciones de cianobacterias y sus toxinas en embalses, utilizando bibliotecas de renderización gráfica avanzadas. 2. Integración con modelos computacionales: Implementar la capacidad de interpretar y visualizar los resultados de modelos computacionales existentes, como los generados por simuladores especializados (MIKE, COMSOL, EEMS, DEVS-BLOOM). Facilitar la comparación entre datos sintéticos y reales para validar los modelos de comportamiento de cianobacterias. 3. Facilitación de la interpretación de datos: Desarrollar métodos y técnicas que simplifiquen la interpretación de los complejos datos del comportamiento tridimensional de las cianobacterias. Proveer una interfaz de usuario intuitiva que permita a los investigadores y autoridades sanitarias y ambientales analizar y tomar decisiones informadas con mayor rapidez. Los objetivos secundarios son los siguientes: 1. Asegurar que el visualizador sea capaz de manejar y representar datos en formatos CSV o H5, provenientes de simulaciones o mediciones directas. 2. Validar los resultados utilizando diferentes casos de uso para asegurarnos de que el simulador 3D del funciona correctamente. Esta validación implica probar la simulación en diversos escenarios y situaciones para observar cómo se comporta el editor en cada uno. 1.3. Plan de trabajo Los objetivos no han sido establecidos al principio del proyecto debido al desconocimiento inicial respecto al modelado 3d de los miembros del proyecto, y han sido propuestos de forma dinámica, estableciendo pequeños objetivos para llevar a cabo la implementación del visualizador 3d. Para asegurar la implementación de estos objetivos cada 3 semanas se han producido reuniones con el director del TFG, cuya finalidad era la de establecer los siguientes objetivos a cumplir, revisar el estado del visualizador resaltando sus posibles errores y resolver cualquier tipo duda a la hora de implementar el visualizador 3d. Adicionalmente se han establecido reuniones semanales entre los miembros encargados de implementar el visualizador, con el fin de repartir el trabajo a realizar y revisar el estado en el que se encuentra el visualizador. Aunque en la figura 1.1, aparentemente el trabajo se ha realizado de forma lineal, la realidad es que en muchas ocasiones hemos desarrollado una versión simple de una función para posteriormente mejorarlo, como puede ser a la hora de realizar un 4Capítulo 1. Introducción Figura 1.1: Plan de trabajo seguido modelo 3d del lago en el que inicialmente usamos cubos para llevar cabo su representación, obteniendo como resultado un lago que se acercaba a la realidad, pero que seguía sin ser muy preciso. Gran parte de las pruebas han sido realizadas utilizando este modelo inicial, pero posteriormente se mejoró su representación por un modelo más realista y se llevó a cabo los cambios necesarios para que el visualizador siga funcionando. Otra funcionalidad que requirió de una revisión, fue la implementación de la creación de una subsección de lago a partir del lago, que inicialmente se introducía textualmente los puntos que iban a delimitar el lago, pero posteriormente se sustituyó por una implementación más interactiva e intuitiva, realizando los cambios necesarios para llevarlo a cabo. Aunque hayamos decidido usar como base un simple editor creado por Three.js, podemos ver en la figura 1.1 tal que la implementación de la página web es uno de los objetivos que mayor tiempo hemos invertido. Esto se debe a que inicialmente, empezamos implementando una aplicación usando c++ y Opengl para llevar a cabo el visualizador, pero gracias a las indicaciones del director del TFG terminamos implementando una página web ya que de esta forma se iba facilitar la posible integración del visualizador 3d a la página web en el que se encuentra el visualizador 2d actual. Otro de los motivos por los que este objetivo ha tomado más tiempo que otros objetivos, es debido a que inicialmente implementamos la interfaz de usuario de la página web haciendo uso de html y css, pero debido a que implementar la interfaz de usuario desde cero consumía demasiado tiempo decidimos usar un editor ya creado por Three.js. Para poder hacer uso de él de forma correcta, tuvimos que invertir cierto tiempo estudiando el código del editor. 1.4. Estructura del documento 5 1.4. Estructura del documento Este Trabajo de Fin de grado se encuentra dividido en 5 capítulos. El capítulo 1 introduce el marco del proyecto de investigación donde se inscribe el presente trabajo y la motivación del trabajo. A su vez, se incluyen una serie de objetivos que se buscan completar. Seguidamente, en el capítulo 2, se indaga más en las diferentes fases que componen el contexto del trabajo de investigación, detallando el funcionamiento de los sistemas actuales para recogida y monitorización de las aguas respecto al novedoso sistema que propone el proyecto SMART-BLOOM. Tras esto, se procede a explicar la dependencia entre las diferentes fases, explicando detalladamente el objetivo de cada fase. Finalmente, se detalla la importancia de desarrollar un sistema de visualización tridimensional para la gestión de cianobacterias. Por otro lado, en el capítulo 3, se describe el trabajo realizado, introduciendo conceptos básicos propios de la representación tridimensional, así como el conjunto inicial de datos que se utiliza para finalmente desarrollar el visualizador. Además, se detallan los diferentes lenguajes de programación utilizados y sus respectivos entornos de ejecución, explicando las diferentes fases para finalizar proponiendo algunas optimizaciones para editor 3D. En el capítulo 4, se describe el flujo de ejecución del sistema, empezando desde un editor de escenarios para terminar con la representación del visualizador. Asi mismo, se utiliza un pequeño embalse como caso de uso, elaborado por el Trabajo de Fin de Grado Análisis de la calidad de aguas en embalses mediante simulación con EEMS, elaborado por Marcos Padilla Alonso y Fernando Sánchez García, dirigido por José Luis Risco Martín. Por último, en el capítulo 5 se revisan el cumplimiento de los objetivos marcados inicialmente, y se resumen las diferentes conclusiones extraídas durante la elaboración de este proyecto. A su vez, se proponen algunas propuestas para el contexto del trabajo de investigación SMART-BLOOM. Cap´ ıtulo 2 Contexto del TFG En este capítulo, se abordará en detalle la problemática de las concentraciones de cianobacterias, así como las condiciones que propician la proliferación de estas algas tóxicas y sus repercusiones negativas en la salud pública. Se analizará el modelo actualmente empleado para prever y abordar este problema, señalando sus limitaciones y se contrastará con el sistema innovador SMART-BLOOM. Además, se describirá la propuesta de este sistema y se contextualizará nuestro trabajo de fin de grado dentro de esta línea de investigación. El enfoque se centrará en comprender la complejidad del fenómeno de las proliferaciones de cianobacterias, identificar las variables involucradas en su desarrollo y evaluar las estrategias existentes para su control, con especial atención en la propuesta de SMART-BLOOM. Esta comparación permitirá resaltar las posibles mejoras y contribuciones de nuestro trabajo en este campo de investigación. 2.1. Proliferación de algas tóxicas El agua es un recurso vital para la vida, esencial tanto para la flora como para la fauna. Todos los seres vivos dependen del agua para su supervivencia. Sin embargo, este recurso natural es escaso. Se estima que solo el 2,5 % del agua en el mundo es dulce, y de ese porcentaje, el 2 % está congelado en glaciares. Esto deja apenas un 0.5 % de agua dulce disponible, distribuida en distintos sistemas acuáticos como depósitos subterráneos, lagos y ríos. En estos sistemas acuáticos de agua dulce, las algas desempeñan un papel fundamental. Su presencia es beneficiosa ya que actúan como fuente de alimento para otros organismos del ecosistema y contribuyen al aumento de los niveles de oxígeno a través de la fotosíntesis. Sin embargo, en ciertas circunstancias, el crecimiento descontrolado de algas puede tener efectos negativos, afectando directamente a la salud pública, así como a los ecosistemas y a las industrias pesquera y turística. La proliferación de algas se produce por un rápido crecimiento de algas en un sistema acuático como pueden ser lagos, ríos o reservas. Dependiendo del tipo de alga, una proliferación de alga puede ser toxica o no, siendo las cianobacterias, los dinoflagelados y los diátomos los principales tipos de algas causantes de estas proliferaciones tóxicas. La proliferación de algas puede volverse tóxica por dos motivos: 7 14 Capítulo 2. Contexto del TFG esto nos ayudará a implementar el sistema de forma más eficiente al igual que reducir los costes de su implementación. También podremos conocer cómo reaccionará el sistema ante eventos extremos que se produzcan en el lago, que en ocasiones normales no se podrían replicar en un laboratorio y como consecuencia poder investigar de forma segura las acciones que habrá que tomar ante estas situaciones y preparar a los operadores encargados de los sistemas acuáticos. Implementar un gemelo digital requiere de los mismos conocimientos necesarios para construir el elemento físico que se busca replicar digitalmente. Por lo que es de gran importancia que ingenieros informáticos y biólogos expertos en el comportamiento de cianobacterias colaboren para llevar a cabo el sistema. Al igual que es necesario de investigadores expertos en física capaces de reproducir el comportamiento del sistema acuático y de eventos meteorológicos adversos. Una vez el sistema haya sido implementado la retroalimentación de los biólogos será de gran necesidad para seguir entrenando al machine learning encargado de la toma de decisiones. Por esta razón el proyecto SMART-BLOOM está constituido por biólogos de la Universidad Autónoma de Madrid (UAM) e ingenieros informáticos de la Universidad Complutense de Madrid. Los biólogos de UAM son expertos en la proliferación de algas tóxicas causadas por la cianobacteria. Los ingenieros informáticos de UCM están divididos en dos grupos: ISCAR (Systems engIneering, Control, Automation and Robotics) y ArTeCS (Architecture and Technology of Computing Systems). ISCAR está compuesto de expertos en simulaciones, en inteligencia artificial relacionados con vehículos autónomos y en sensores. ArTeCS está compuesto por expertos en computación de alto rendimiento, en el diseño de sistemas embebidos y en computación de frontera. Los modelos que constituyen la ontología (conjunto de modelos que describen exhaustivamente un dominio determinado) encargada en la gestión de las funciones y comportamiento del gemelo digital, serán construidas usando la metodología de Modelado y Simulación en el que se desarrolla un modelo matemático que representa de forma virtual un modelo físico, de forma más específica se usará DEVS. Existe dos tipos de funciones de un gemelo digital: el básico y los basados en decisiones. Los comportamientos básicos se encargan de las características esenciales de un gemelo digital como pueden ser la recogida de datos, la sincronización y el almacenamiento. Las funciones encargadas de la toma de decisiones dependen del objetivo del gemelo digital como puede ser la detección de anomalías, la simulación, planeador de ruta, etc. Estas funciones son implementadas mediante el uso de algoritmos de inteligencia artificial, incluyendo metodologías clásicas como K-means, Bayes,Support Vector Machines o metodologías más complejas como Convolutional Neural Network. La evolución en tiempo real de estos algoritmos mediante el uso de datos reales obtenidos por los elementos que componen Iot de la capa Edge es una de las mayores características que diferencia a un gemelo digital de una simple simulación. 2.3.2. Computación en frontera Los elementos (vehículos acuáticos y sensores) encargados de la recopilación de información del medio físico, deben subir a través de la red una gran cantidad de 2.4. Funcionamiento de DEVS-BLOOM 15 datos al marco que encapsula el gemelo digital. Esta acción causaría la saturación de la red afectando al rendimiento del sistema. Por esta razón, con el fin de aliviar la cantidad de datos que la red debe manejar y, a fin de disminuir la carga de trabajo del gemelo digital, los elementos que componen la red de las cosas(Iot), encargados de recoger información sobre el medio físico(Vehículos acuáticos autónomos y sensores), serán capaces de procesar los datos que recogen y serán dotados de algoritmos machine learning que les permitirán tomar decisiones, disminuyendo la cantidad decisiones que los operadores han de tomar. Para llevar esto a cabo los elementos Iot de la capa Edge, estos serán dotados de una arquitectura computacional que le permitirá realizar esta toma de decisiones. Este proceso es denominado Edge computing, un sistema integrado que permitirá reducir el número de comunicaciones que los elementos de Iot de la capa Edge han de realizar, donde a su vez, también disminuirá el estrés al que los operadores son sometidos al tomar decisiones. 2.4. Funcionamiento de DEVS-BLOOM Para esclarecer el comportamiento de las proliferaciones de algas tóxicas se usa el modelado y la simulación(M&S). Para ello debemos usar modelados de las proliferaciones de algas tóxicas capaces de replicar su comportamiento de forma precisa. De igual forma es necesaria la obtención de modelados de los diferentes elementos que sean relevantes para la monitorización y la predicción de proliferaciones de algas como puede el comportamiento del viento y del agua. La mayoría de estos modelos están implementados en EMMS un software que sido usado por diferentes países para a la implementación de sistemas de alerta temprano. Con el fin de implementar un sistema que incluya no solamente los modelos proporcionados por EMMS, sino la infraestructura necesaria para implementar el sistema de alerta temprana nace DEVS-BLOOMS, un marco que usa el modelado y la simulación para poder monitorizar en tiempo real y predecir proliferaciones de algas. Devs(Discrete Event System Specification) es un formalismo de modelado de sistemas de eventos discretos creado por Bernard P. Zeigler. Devs puede ser visto como una extensión del formalismo de la maquina Moore. Esta extensión consiste en asignar a cada estado un numero real no negativo que designa la duración del estado, e introducir el concepto de jerarquía a través una operación denominada coupling. Devs incluye dos tipos de modelos: Atomic Devs y Couple Devs. Atmomic Devs esta definido por una tupla de 7 elementos: x: Conjunto de eventos de entrada y: Conjunto de eventos salida s: Conjunto de estados s0: Conjunto Inicial perteneciente a s ta: Función encargada de devolver el tiempo dado un estado perteneciente a s 16 Capítulo 2. Contexto del TFG Ext: Función que indica como un evento de entrada cambia el estado del sistema int: Función que indica como el sistema cambia de forma interna cuando transcurre. alfa: Función que genera el evento salida. Coupled DEVS está formado por atomic DEVS interconectados entre sí, dando lugar a un sistema jerárquico compuesto por subsistemas. Con el fin de mantener coordinados e integrados todos los modelos a lo largo de la construcción del sistema, DEVS BLOOMS se basa en los principios de la Ingeniería de sistemas basada en modelos: estar basado en el uso de modelos, visualizar el sistema como un todo, desarrollar los modelos de forma iterativa e incremental, reutilizar los componentes y otros elementos para reducir posibles errores. DEVS-BLOOM es un modelo acoplado que está constituido otros 3 modelos interconectados entre sí (el modelo acoplado sensores y USV en la capa EDge,el modelo acoplado fog y el modelo atomico cloud). Existe un modelo atómico conectado a los modelos mencionados previamente denominado Simulation, que recibe en su entrada todos los eventos provenientes de un archivo para luego comunicarlo a los demás modelados a través de su puerto de salida. Este modelo se encuentra constituido por eventos, que replican los eventos que ocurrirían en la realidad, los cuales se les asigna un comando a ejecutar y un tiempo en el que se debe ejecutar. 2.4.1. Estructura DEVS-BLOOM está divido en tres capas que se comunican entre sí para poder monitorizar y predecir las proliferaciones que son la capa edge, la capa fog y la capa cloud: Edge: La capa Edge es la más baja y en él se encuentra los modelos atómicos de los dispositivos necesarios para recompilar información sobre el sistema acuático, como puede ser sensores, cámaras o USV (Vehículos de Superficie No Tripulados). Los modelos atómicos que componen esta capa reciben a través de su entrada información ya sea proveniente de la base de datos o del elemento real que representa. Una vez la información haya sido procesada por el modelo, envía a través su puerto de salida un evento genérico en el que se establece el tiempo en el que se ha producido el evento, un id para saber de qué modelo atómico proviene y una lista con la información recogida. Fog: La capa fog se trata de un modelo acoplado, en principio está formado por el modelado atómico principal Ground Control Station(GCS) y el modelado de los diferentes servicios, como son la detección de datos atípicos, predicción de proliferaciones de algas, generación de reporte mediante el análisis de datos almacenados y planificación del recorrido que el USV ha de seguir. En la actualidad, estos modelos están integrados dentro del modelo GCS. El modelo GCS es el modelo principal de esta capa y, como los demás modelos, su comportamiento está dictado por los eventos que recibe del modelo de simulación 2.4. Funcionamiento de DEVS-BLOOM 17 Figura 2.5: Estructura DEVS-BLOOM que, junto a los eventos de entrada, determinará el siguiente estado en el que se encuentre el sistema. Aunque DEVS-BLOOM pueda predecir la proliferacion de algas tóxicas y guiar el USV de forma automática, sigue siendo necesaria la aprobación de operadores y expertos que se encuentran en esta capa. Cloud: Cada sistema acuático del cual se busca predecir la formación de proliferaciones de algas, requiere de una capa Edge y de una capa Fog, lo que conlleva la necesidad de una última capa, la capa Cloud. Se trata de una capa clave para el escalado horizontal del sistema capaz de almacenar todos los datos históricos de los sistemas acuáticos estudiados en un mismo lugar, con los que se podrán realizar un mejor análisis de los datos y mejorar la capacidad de predicción de proliferaciones de algas de las capas fog de los diferentes sistemas acuáticos. 2.4.1.1. Escenario Uno de los escenarios de los que dispone DEVS-BLOOM es el escenario de monitorización del lago Washington, en él DEVS-BLOOMS recibe un modelado preciso por parte de EMMS del sistema acuático que se quiere monitorizar que incluye datos relevantes para la monitorización como pueden ser la velocidad del agua, la tempe- 18 Capítulo 2. Contexto del TFG ratura del agua, el nivel de oxígeno, la densidad de nitratos y la concentración de algas. En este escenario la capa Edge dispone de un USV encargado de enviar a la capa Fog información del sistema acuático en el que se encuentra e información sobre sus componentes internas. Una vez que la capa Fog recibe los datos provenientes de la capa Edge, usa el servicio de predicción que tiene a su disposición que está basado en ecuaciones diferenciales para predecir el lugar en el que puede aparecer una proliferación de algas. Una vez obtenida la posición se comunica con el servicio encargado de planear la USV que envía a la capa edge la posición a la que el USV tiene que dirigirse. A su vez toda esta información es enviada a la capa cloud con el fin de mantener actualizada la base de datos. 2.4.2. Visualizador actual en 2D Con el fin de permitir a los operadores y expertos de la capa Fog encargados de tomar ciertas decisiones respecto a los sistemas acuáticos en los que se encuentran como mejorar el análisis de datos de los expertos de la capa Cloud, surge la necesidad de implementar una interfaz de usuario (UI). Para respetar los principios de la ingeniería de sistemas basada en modelos la UI es implementada en una capa dedicada denominada Front-End, y la parte funcional del sistema es integrada en una capa denominada Back-End de esta forma los ingenieros de cada capa podrán trabajar de forma paralela sin necesidad de depender entre ellos gracias a la disponibilidad de una base datos en las etapas iniciales de la implementación del sistema, creando un flujo de trabajo más eficiente reduciendo de forma considerable el tiempo necesario para implementar el sistema y permitiendo en etapas iniciales del sistema la capacidad de testeado. La UI se encuentra en la capa cloud en la que tiene acceso a la base de datos global. Basado en es esta información la UI proporcionara a los gestores de aguas los servicios necesarios para la monitorización y la visualización de sistemas acuáticos. Para llevar a cabo este intercambio de informacion de forma segura y eficiente entre DEVS-BLOOM y DEVS-BLOOM-Web-UI diferentes formatos son utilizados: JSON, CSV, NetCDF64 La UI se trata de una página web que usa el marco de trabajo DJango que debido a que esta implementado en python facilita su integración al sistema para implementar un visualizador 2d interactivo. Actualmente la página web ofrece principalmente 3 funciones: Predicción de proliferaciones de algas toxicas: permite visualizar la evolución de las algas en el sistema acuático y la información relevante para la toma de decisiones. Creación de escenarios: el usuario puede establecer las condiciones meteorológicas iniciales. así como las posiciones y parámetros de los dispositivos usv y sensores. La UI nos da la habilidad de modificar estos parámetros de forma dinámica, lo que nos permite monitorizar el sistema acuático en diferentes situaciones. Monitorización USV: nos permite monitorizar el trayecto que sigue o que realizó el dispositivo USV en diferentes periodos de tiempo. 2.4. Funcionamiento de DEVS-BLOOM 19 El visualizador 3d implementado en este proyecto se situaría en este apartado, actuando como alternativa al visualizador actual, en situaciones en los que el visualizador 2d no proporciona suficiente información, especialmente información relativa a la profundidad del sistema acuático que puede ser una gran ayuda para los administradores de sistemas acuáticos para la toma de decisiones. Cap´ ıtulo 3 Descripción del Trabajo En este capítulo, exploraremos la metodología empleada en el desarrollo del visualizador 3D diseñado para interpretar las concentraciones de toxinas en embalses. Para comenzar, se explicarán algunos conceptos básicos de la representación 3D, seguido por la presentación del conjunto de datos inicial utilizado durante las pruebas. Posteriormente, detallaremos el diseño del visualizador 3D, incluyendo algunas conclusiones surgidas durante esta fase de desarrollo y las optimizaciones implementadas para garantizar un funcionamiento eficiente del editor 3D. Nuestro enfoque abarca el contexto general del proyecto, incluyendo el entorno de trabajo y la configuración de ejecución utilizados durante las pruebas, junto con detalles sobre los distintos lenguajes de programación empleados y la naturaleza de los datos utilizados en nuestro proyecto. 3.1. Conceptos básicos de en visualización 3D Antes de empezar con el desarrolló del visualizador, es necesario comprender algunos elementos básicos que caracterizan a los editores tridimensionales, a fin de comprender como funcionan y como empezar a trabajar con ellos. 3.1.1. Escena Una escena 3D representa un espacio tridimensional que contiene datos geométricos, generalmente en coordenadas cartesianas, y suele estar asociada con otros elementos visuales como luces y texturas. Su objetivo principal es realizar cálculos para generar imágenes resultantes que pueden ser almacenadas para visualización posterior o mostradas en tiempo real. Esta capacidad también permite la creación de animaciones. A continuación, se enumeran algunos de los elementos más comunes en la escena: 1. Modelos: Representación matemática de la superficie de un objeto tridimensional, generalmente creada mediante un software especial. Se almacena como una serie de puntos (vértices) conectados por diferentes objetos geométricos (por ejemplo, líneas, triángulos, cuadrados, etc.). 21 22 Capítulo 3. Descripción del Trabajo 2. Texturas: A través de un programa especial, es la imagen de mapa de bits que se utiliza para cubrir la superficie de un objeto. 3. Cámaras: Se trata del punto de vista que se tendrá en cuenta para renderizar la escena. Podemos distinguir dos tipos: Ortogonal. Los objetos se visualizan del mismo tamaño independientemente de la distancia ente estos objetos y la cámara. Perspectiva. El tamaño del objeto depende de la distancia a la cámara. 4. Luces. Puntos a partir de los cuales se generan puntos lumínicos que se clasifican en: Luz direccional. Conocida como luz infinita, se utiliza para simular la luz del sol o la luz de la luna porque la luz producida se distribuye en haces paralelos como una fuente de luz distante. Luz puntual u omnidireccional. También llamada luz omni, irradia luz desde un único punto en todas las direcciones. Se emplea frecuentemente para proporcionar luz de relleno, ya que no posee una forma o tamaño definidos. A medida que un objeto se acerca a la fuente de luz, su brillo aumenta. Un ejemplo cotidiano de luz puntual es una bombilla. La luz de área. Emite luz desde una superficie específica con forma y tamaño definidos, como una ventana o panel retroiluminado. Es una opción popular en el modelado 3D y la visualización arquitectónica, ya que crea sombras suaves y realistas sin emitir rayos paralelos como la luz direccional. Un foco. Emite un cono de luz en una dirección específica. La intensidad de la luz es mayor cerca de la fuente y en el centro del cono. Se puede ajustar el ángulo del cono, el tamaño de la luz y suavizar el borde exterior para obtener diferentes efectos visuales. Una linterna es un ejemplo común de foco en la vida real. Estas técnicas pueden combinarse para crear diversos esquemas de iluminación. Por ejemplo, en un esquema de tres luces, se establece una luz principal, más intensa que las otras, que ilumina el objeto desde arriba. La segunda luz puede utilizarse para ajustar las sombras generadas por la luz principal, mientras que la tercera puede controlar la ambientación del fondo. 3.1.2. Figuras 3D Las figuras 3D son representaciones de objetos que abarcan tres dimensiones: altura, anchura y profundidad. Esta característica ofrece una representación más realista y detallada que las figuras en 2D, lo que resulta especialmente útil en campos como el diseño, la animación, la arquitectura, la ingeniería, la medicina y diversas áreas profesionales. Podemos destacar 2 tipos de objetos diferenciados: 3.1. Conceptos básicos de en visualización 3D 23 1. Figuras geométricas predeterminadas. Elementos que ya vienen integrados en muchos de los editores 3D como cubos, planos, cilindros o esferas. 2. Mallas nuevas. creación de nuevas formas a partir de la especificación de unos vértices y unas caras. Además de su capacidad para representar objetos en tres dimensiones, las figuras 3D ofrecen la flexibilidad de ser combinadas y modificadas para crear estructuras más complejas y de mayor tamaño. Esta capacidad de composición y fusión de múltiples figuras permite la creación de objetos y entornos más elaborados y detallados en campos como la animación y la simulación de distintos procesos y muchas otras aplicaciones. La posibilidad de combinar varias figuras abre un amplio abanico de posibilidades creativas y funcionales, permitiendo a los diseñadores dar forma a sus ideas con mayor libertad y precisión. 3.1.3. Formatos de datos Con el aumento de la presencia de las empresas en el espacio 3D y los avances tecnológicos continuos, como la realidad virtual (RV), la realidad aumentada (RA), el diseño de juegos, los efectos especiales y la evolución de las aplicaciones de diseño asistido por ordenador (CAD), se han desarrollado nuevos tipos de archivos para satisfacer estas crecientes capacidades. Algunos de los formatos más utilizados en la actualidad son los siguientes: 1. OBJ. El archivo OBJ (.obj) es un formato utilizado para almacenar información geométrica en tres dimensiones (3D). Es uno de los formatos más antiguos y ampliamente utilizados para exportar objetos, y está integrado en la mayoría de los programas de modelado. Aunque su capacidad para proporcionar una percepción de escala (centímetros, pulgadas, etc.) es notable, su definición de materiales puede considerarse algo anticuada en comparación con técnicas más modernas de materiales y sombreado. Sin embargo, sigue siendo un estándar establecido y confiable para la exportación de formas geométricas simples y rectas. Sus ventajas son las siguientes: Permite almacenar varios objetos en un mismo archivo. Es compatible con la mayoría de editores 3D de la actualidad. Suele pesar menos que otros formatos con el mismo modelo almacenado. 2. GLTF. El formato GLTF (GL Transmission Format) es un estándar para la transmisión y almacenamiento de modelos 3D. Desarrollado por el grupo Khronos, está diseñado para ser un formato eficiente y de rendimiento óptimo para aplicaciones web. GLTF es conocido por su capacidad de representar tanto la geometría como los materiales de los modelos 3D, incluyendo texturas, animaciones y más, de una manera compacta y rápida de cargar. Ventajas: Eficiencia y Rapidez. GLTF está optimizado para la transmisión y el uso en aplicaciones web, lo que lo hace rápido de cargar y renderizar. 30 Capítulo 3. Descripción del Trabajo 3.4. Modelado del lago En esta sección, nos adentramos en la fase crucial del modelado tridimensional, donde se busca crear una representación virtual del lago con el objetivo de lograr una interpretación realista de embalses y lagos. El modelado tridimensional es un proceso complejo que abarca una variedad de aspectos, desde la adquisición inicial de datos hasta la creación de geometrías y texturas que reflejen fielmente la realidad del entorno acuático. El modelado tridimensional es una tarea que implica una complejidad considerable, especialmente para aquellos que se enfrentan a ella por primera vez. Este proceso abarca una variedad de aspectos, desde la recolección inicial de los datos hasta la elección de geometrías y texturas que reproduzcan con precisión la realidad del entorno acuático. 3.4.1. Primeros pasos Antes de adentrarnos en el proceso de modelado, es crucial configurar los datos de entrada que pretendemos emplear. Para ello, hemos llevado a cabo ensayos con datos provenientes del EEMS, específicamente del lago Washington. Se trata del segundo lago más grande del estado de Washington, con una superficie de 87,6 km2. En este conjunto de datos, se incluyen diversas concentraciones, como niveles de nitrógeno y temperaturas en diferentes puntos del lago, identificados por sus coordenadas de longitud y latitud. Estos datos son cruciales para llevar a cabo predicciones sobre las poblaciones de cianobacterias en el lago. Sin embargo, es importante destacar que estos datos se encuentran en formato netCDF4, el cual puede resultar poco legible para los usuarios. Por ende, nuestro primer paso ha sido convertir estos datos al formato CSV, el cual es más ampliamente utilizado y fácilmente interpretable. Esta conversión nos permitirá manipular y analizar los datos de manera más efectiva durante el proceso de modelado. 3.4.2. Modelado de la superficie Para comenzar con el proceso de modelado, hemos optado por iniciar con la representación de la superficie del lago. Entendemos la superficie como la capa más alta del lago, es decir, las mediciones tomadas en los puntos más elevados del cuerpo de agua. A través de estos puntos, buscamos capturar y representar la forma del nivel superficial del lago de manera precisa y detallada. Esta etapa inicial nos permitirá establecer una base sólida para la creación del modelo tridimensional completo, que luego podremos complementar con otros elementos y detalles para lograr una representación fiel del entorno acuático. Para lograr esta representación, consideramos apropiado extraer del conjunto de datos inicial las mediciones correspondientes a cada longitud y latitud registradas para cada celda. Por lo tanto, procedimos a crear nuestro primer dataframe, el cual consta de dos columnas: una para las longitudes y otra para las latitudes asociadas a cada punto de medición. Este enfoque nos permite tener un conjunto estructurado de datos que servirá como base para la posterior construcción de la representación tridimensional de la superficie del lago. 3.4. Modelado del lago 31 Nuestro objetivo es representar de manera realista la superficie del lago. Para lograrlo, hemos optado por utilizar un plano para cada celda de los datos de latitud y longitud. Empleando la librería de Python bpy, disponible en Blender, hemos procedido a cargar los datos provenientes del dataframe que contiene las mediciones para cada longitud y latitud, y hemos creado un plano para cada uno de ellos. En este proceso hemos podido distinguir dos etapas: la creación de los materiales que se asigna a los planos y la creación de los planos. 3.4.2.1. Materiales Para la asignación de los materiales, hemos definido una función create material para generar un nuevo material que asignaremos a los planos. Este material se configura en formato RGB en escala 0-1, formato similar al más común usado RGB 255, donde los colores se representan en la escala de 0 a 1 en lugar de 0 a 255. Los colores se asignan en una tupla que consta de cuatro campos: material.diffuse_color = (RED, GREEN, BLUE, ALPHA) Donde: RED: indica la cantidad de rojo presente en el color, en el rango de 0 a 1. GREEN: indica la cantidad de verde presente en el color, en el rango de 0 a 1. BLUE: indica la cantidad de azul presente en el color, en el rango de 0 a 1. ALPHA: indica la opacidad del color, en el rango de 0 a 1, donde 0 significa completamente transparente y 1 significa completamente opaco. Para las primeras pruebas hemos asignando un mismo color a todos los planos, el color amarillo puro (1,1,0,1) al material, ya que nuestra prioridad es primero poder visualizar la superficie del lago. 3.4.2.2. Creación de los planos Para la creación de los planos, hemos implementado un operador ImportCSVOperator que nos permite importar los datos del archivo CSV y crear los planos correspondientes en la escena de Blender. Este operador se encarga de leer el archivo CSV y generar un plano para cada celda del lago, utilizando las coordenadas de longitud y latitud como ubicación. La instrucción que hemos utilizado para añadir los planos es la siguiente: bpy.ops.mesh.primitive_plane_add(size, location) Donde: size: indica el tamaño que tendrá dicho objeto en unidades. location: indica la localización del objeto en los ejes xyz. 32 Capítulo 3. Descripción del Trabajo Cada plano que se creaba lo hemos ubicado en su respectiva localización (lon, lat, 0) que obteníamos del archivo de datos CSV. La coordenada z la dejábamos a 0 debido a que solo queremos mostrar la superficie. Respecto del tamaño a asignar, hay que tener en cuenta la precisión de las coordenadas del archivo de datos y a la distancia entre estas celdas. Tras varias pruebas, le asignamos un tamaño predeterminado a cada plano de 1/200 unidades. 3.4.2.3. Resultados Para poder visualizar el resultado de manera efectiva, creábamos una pequeña interfaz que incluía un pequeño panel para que pudiésemos añadir los objetos a escena y poder visualizar el resultado sin necesidad de tener que ejecutar el código continuamente. Esto nos ha permitido que, tras varias pruebas con el tamaño de los planos, obtengamos el siguiente resultado. Figura 3.3: Comparación entre el modelo generado en Blender y la imagen tomada mediante Google Earth del Lago Washington. 3.4.2.4. Conclusiones La representación, como se puede apreciar, se acerca mucho a la geometría real del lago Washington. A continuación, se detallan las ventajas y desventajas que hemos observado: Ventajas: Se puede representar el lago con tan solo información de la ubicación de las celdas longitud latitud. La representación tridimensional de este lago se acerca mucho a la geometría real. Desventajas: 3.4. Modelado del lago 33 Hay zonas más pequeñas o estrechas del lago, que requieren de una precisión mayor, que impide que se refleje correctamente al ser un tamaño de cubo prefijado. Esta representación no tiene en cuenta la separación entre celdas, provocando solapamiento entre cubos o huecos en blanco en caso de que el tamaño de los cubos sea menor del necesario. Esta representación podría resultar en problemática a la hora de representar otros lagos que tuviesen una diferente separación entre celdas. Teniendo en cuenta tanto las ventajas como las desventajas se avanzará en el proyecto con otras implementaciones de forma paralela que se investiga otras posibles representaciones, a fin de avanzar lo máximo posible en la investigación del proyecto. Explicar que la visualización se acerca mucho al objetivo y que por ende hemos continuado por este camino para visualizar el lago completo. Y que no obstante avisar del tamaño de los planos. Este enfoque nos permite construir una representación detallada y fiel de la superficie del lago, utilizando los datos de entrada proporcionados en el archivo CSV. La combinación de la funcionalidad proporcionada por la librería bpy y el procesamiento de datos realizado con la librería pandas nos permite avanzar hacia nuestro objetivo de crear un visualizador 3D preciso y realista para la interpretación de concentraciones de cianobacterias en embalses. 3.4.3. Otras representaciones A continuación, se presentan otras métricas y formas de representar de manera tridimensional el lago Washington, que ha surgido durante la fase de investigación. 3.4.3.1. Métrica de distancias Se trata de una representación que hemos creado basándonos en la distancia entre las diferentes celdas. Lo primero de todo, identificamos cada celda mediante su longitud y latitud zonal, como si fuesen puntos dentro de un plano. La idea consiste en calcular la distancia a los puntos más cercanos. Una vez tengamos la distancia a los puntos más cercanos, le asignamos a dicho punto un tamaño. El objetivo de esta métrica se basa principalmente en evitar asignar a cada punto un tamaño de cubo predeterminado como hacíamos anteriormente. La idea es basarnos en la distancia media respecto a las cuatro celdas más cercanas, y asignarle dicho tamaño a la celda. Para ello utilizamos la librería de python KDTree. De acuerdo con ?, se trata de una librería que permite guardar un conjunto de localizaciones o coordenadas, que se utilizarán para hacer búsquedas. Por ejemplo, se pueden realizar búsquedas dentro del espacio de coordenadas para obtener los "X" puntos más cercanos, siendo "X" asignado por el programador. Ventajas: Ya no hay tamaño predefinido en celdas. Se consigue mayor precisión de modelado en algunas regiones del lago. Figura 3.5. 34 Capítulo 3. Descripción del Trabajo Figura 3.4: Comparación entre el modelo generado en Blender usando la métrica de distancias y la imagen tomada mediante Google Earth del Lago Washington. Figura 3.5: Precisión métrica de distancias Se consigue que las celdas ya no se sobrepongan unas sobre otras. Desventajas: Sigue sin ser lo suficientemente preciso. Se forman isletas dentro del lago que no corresponden debido a que hay celdas que son más pequeñas de lo que deberían. Figura 3.6. Los resultados de esta métrica se muestran en la figura 3.4. Teniendo esto en cuenta, decidimos ajustar el tamaño de las celdas para evitar espacios entre celdas, Figura 3.7. Sin embargo, con este ajuste surge el error de la anterior representación, que consistía en la pérdida de precisión del lago. Por lo tanto, teniendo en cuenta que apenas se ha mejorado la representación 3D del lago, decidimos seguir investigando a fin de conseguir una métrica más precisa. 3.4.3.2. Métrica de celdas Se trata de una métrica que basa su representación en la información que contienen los archivos ".nc" provenientes de el simulador EEMS. Recordemos que en este archivo de datos, hay información acerca de la estructura de las celdas, concretamente de los vértices que delimitan cada celda, llamada nv. Esta variable tiene 3.4. Modelado del lago 35 Figura 3.6: Espacios en blanco entre celdas Figura 3.7: Ajuste de métrica de distancias para evitar huecos en blanco. dimensión como lon ylat, ya que a fin de cuentas, debe tener información para cada celda. Además, para cada celda, hay una tupla de 4 elementos, lo que nos da la forma original de cada celda. En Blender, existe una función para crear mallas nuevas a partir de unos vértices y caras definidos con anterioridad. malla = bpy.data.meshes.new(nombre) malla.from_pydata(vertices, [], caras) Con la primera función creamos una nueva malla asignándole un determinado nombre. Con la segunda función, le asignamos su geometría a través de unos vértices y unas caras. Los vértices los obtenemos del archivo inicial de datos, de la tupla de 4 elementos 0, 1, 2, 3: Vértice 0: unido a vértices 1 y a 3. Vértice 1: unido a vértices 0 y a 2. Vértice 2: unido a vértices 1 y a 3. Vértice 3: unido a vértices 0 y a 2. A partir de aquí, podemos sacar la cara superior de nuestras mallas. Sin embargo, para que se realice la representación 3D, necesitamos definir 8 vértices para su posterior visualización en profundidad. Estos vértices tendrán la misma longitud y latitud que los vértices anteriores, pero a una profundidad superior. Para simular solo la superficie, asumimos una profundidad de una unidad. Por tanto, la estructura de los vértices nos queda de la siguiente manera: 36 Capítulo 3. Descripción del Trabajo Vértice 0: unido a vértices 1, 3 y 4. Profundidad 0. Vértice 1: unido a vértices 0, 2 y 5. Profundidad 0. Vértice 2: unido a vértices 1, 3 y 6. Profundidad 0. Vértice 3: unido a vértices 0, 2 y 7. Profundidad 0. Vértice 4: unido a vértices 5, 7 y 0. Profundidad 1. Vértice 5: unido a vértices 4, 6 y 1. Profundidad 1. Vértice 6: unido a vértices 5, 7 y 2. Profundidad 1. Vértice 7: unido a vértices 4, 6 y 3. Profundidad 1. Una ver tenemos definidos los vértices, podemos definir la estructura de las caras, que será igual para toda la estructura de las celdas. Superior: compuesta por los vértices 0, 1, 2 y 3. Inferior: compuesta por los vértices 4, 5, 6 y 7. Frontal: compuesta por los vértices 0, 1, 5 y 4. Trasera: compuesta por los vértices 2, 3, 7 y 6. Lateral izquierda: compuesta por los vértices 0, 3, 7 y 4. Lateral derecha: compuesta por los vértices 1, 2, 6 y 5. Por tanto, tenemos unas mallas compuestas por 8 vértices y 6 caras. A continuación, se muestran algunas conclusiones obtenidas que se pueden ver en la imagen 3.8. Ventajas: No se pierde precisión de los datos obtenidos del simulador EEMS. Figura 3.9. Celdas perfectamente cohesionadas sin separación entre ellas. Figura 3.10. Desventajas: Dependencia de los datos provenientes del simulador EEMS, sin posibilidad de hacer una representación independiente. 3.4.3.3. Conclusiones Considerando todas las opciones, la métrica final elegida para la realización de simulaciones dentro del visualizador 3D es la métrica de celdas. Con ella conseguimos una visualización mucho más precisa del conjunto de datos inicial sin perder precisión en la representación 3D, pero dependiendo de que los datos provengan del simulador EEMS exclusivamente, o simuladores que produzcan salida similar, con especial enfasis en la variable nv. 3.4. Modelado del lago 37 Figura 3.8: Comparación entre el modelo generado en Blender usando la métrica de celdas y la imagen tomada mediante Google Earth del Lago Washington. Figura 3.9: Precisión métrica de celdas Figura 3.10: Sin espacios en blanco entre celdas 38 Capítulo 3. Descripción del Trabajo Figura 3.11: Lago en profundidad 3.4.4. Modelado del lago en profundidad Una vez hemos conseguido la representación de la superficie del lago, representar el lago en profundidad parece tarea sencilla. Sin embargo, hay que tener en cuenta que, para modelar la superficie, teníamos 1183 celdas para las longitudes y latitudes, y una profundidad del lago es de hasta 55 celdas. En nuestras primeras implementaciones de prueba Blender no respondía porque saturación y consumo de recursos del sistema. Por ende, continuamos con las pruebas limitando la profundidad hasta un máximo de 4 celdas en profundidad para una misma longitud y latitud. Recordemos que cada celda estará compuesta por 8 vértices de acuerdo con la métrica de celdas, 4 en la parte superior y 4 en la parte inferior. La idea para que no haya espacios en blanco entre celdas de misma longitud y latitud consiste en ubicar los vértices superiores justo en la ubicación de los vértices inferiores de la celda inmediatamente superior. La altura de cada celda vendrá dada por la variable "sigma" del conjunto de datos inicial, que contiene información para cada celda ubicada a una longitud, latitud y profundidad dadas. Con todo esto, conseguimos obtener la representación que se muestra en la figura 3.11. A fin de distinguir los diferentes niveles en profundidad, se alternan los colores a cada nivel de manera que no haya dos niveles con el mismo color. Para ello utilizamos el color azul y el color blanco. En la figura 3.12 se puede observar los diferentes niveles del lago hasta una profundidad de 4 celdas, pudiendo distinguir que celdas de un mismo nivel tienen una misma altura. 3.4. Modelado del lago 39 Figura 3.12: Lateral del lago de 4 celdas de profundidad. 3.4.5. Escalas Durante el modelado del lago, se han utilizado diferentes escalas a fin de visualizar el lago. En la métrica final escogida cada celda tiene el tamaño que encierran sus 8 vértices, siendo diferente para cada celda. Sin embargo, recordemos que asignamos una altura a cada celda, que obtenemos de la variable sigma. Esta variable contiene números reales positivos cuyo valor máximo en nuestros datos iniciales es de 0.99091053, y un valor mínimo de 0.0 en celdas que no tienen valor. Recordemos que los vértices y coordenadas se ubican con una precisión de varios decimales. A base de probar, se ha conseguido mostrar el lago a una escala aceptable, aunque podría variar en otros sistemas o lagos. Para ello, cuando asignamos la altura a una celda, le asignamos sigma / x, siendo xuna variable que toma valores que rondan el valor 500. Durante las pruebas, hemos mantenido la variable en 500, pudiendo ser necesaria aumentar este valor para mostrar el lago en su totalidad y no a profundidad de 4 celdas. El tamaño de la variable xdependerá del tamaño de las celdas y del tamaño del lago en su totalidad, ya que, en entornos acuáticos más pequeños como las lagunas, será necesario aumentar el valor de x. 3.4.6. Paletas de colores Existen numerosas paletas de colores diseñadas para visualizar datos en gráficos o visualizaciones científicas. Para representar las diferentes concentraciones del archivo inicial de datos, hemos investigado acerca de cuáles son las paletas más utilizadas y recomendadas para nuestra visualización 3D. A continuación, se enumeran algunas de las más utilizadas: Viridis. Paleta de colores que se desarrollo inicialmente para el paquete de python matplotlib, que se utiliza para representar datos continuos. Esta paleta abarca desde tonalidades verdes suaves hasta tonos azules oscuros, proporcionando una transición gradual para destacar los cambios en el conjunto de datos. Magma. Paleta de colores que se extiende desde tonos morados oscuros hasta amarillos brillantes. Esta paleta resulta muy útil pasa representaciones de mapas de calor, densidades, así como resaltar contrastes en datos de intensidad. 46 Capítulo 3. Descripción del Trabajo main.py. A nivel práctico, este método es poco recomendable para el uso diario de la monitorización. Por esta razón, se decidió buscar herramientas que permitieran integrarlo dentro de nuestro editor tridimensional. Tras una investigación, se decidió incorporar Node.js al proyecto Mardan et al. (2018). Esto permitió integrar un botón para ejecutar directamente el script, simplificando significativamente el proceso para el usuario final. Además, uno de los inconvenientes de micro-devs-bloom es que las coordenadas de inicio están predeterminadas, es decir, las coordenadas ya vienen fijadas dentro del archivo principal main.py. Nuestro objetivo es habilitar en micro-devs-bloom la opción de escoger libremente las coordenadas de inicio de la simulación, como se muestra en la figura 3.16. Toda esta fase, que detalla cómo se realiza la integración de micro-devs-bloom dentro del editor, se explica en la sección 3.6. Figura 3.16: Interfaz de micro-devs-bloom para ejecutar una simulación. 3.5.4. Sublago Debido que el barco normalmente no recorre todo el lago e inicialmente solo somos capaces de visualizar la profundidad más cercana a las costas, surge la necesidad de dar la posibilidad al usuario de ser capaz de mostrar únicamente una porción del lago. Mostrar únicamente una porción del lago mejorará el rendimiento del visualizador al tener que renderizar una porción. 3.5.4.1. Algoritmo de filtrado En primer lugar, para simplificar el proceso solamente consideramos la superficie de lago a la hora de identificar la porción del lago. Existen diversos algoritmos para indicar cuando un punto se encuentra dentro de un polígono cerrado, en este caso el algoritmo usado está basado en el teorema de la curvatura de Jordan nombrada de esta forma por el matemático que la descubrió. 3.5. Visualizador 3D(Three.js) 47 En este teorema se afirma que, dados dos puntos, uno dentro del polígono y otro fuera de él la línea formada por los dos puntos crea una intersección en alguna parte del contorno de la figura. A partir del teorema podemos saber fácilmente si un punto se encuentra dentro del polígono, trazando una línea en una dirección fija partiendo del punto, en caso de que el número de intersecciones con el contorno del lago sea par, significará que el punto no se encuentra dentro del polígonos, en caso contrario, sí se encuentra dentro de él. Extrapolándolo al lago, primero necesitamos conocer cuál será la porción del lago con la que el usuario se quiere quedar, para ello obligamos al usuario a proporcionar 4 latitudes y longitudes con las que formaremos la figura para después recorrer todos los objetos que conforman el lago, diferenciando aquellos objetos que no se encuentran dentro de la figura de los que sí para su posterior renderización. En un principio ofrecíamos la posibilidad al usuario de introducir manualmente las longitudes y latitudes, pero puede resultar bastante incómodo para el usuario, por lo que implementamos la función de seleccionar los 4 puntos de una forma más interactiva y de esta forma mejorar y facilitar la experiencia del usuario al usar el editor. En vez de introducir las longitudes y latitudes de forma manual permitimos al usuario seleccionar 4 puntos del lago haciendo click con el ratón, para ello haremos uso del raytracing para el cual necesitaremos la posición del ratón en la pantalla al hacer click y la posición del lago para saber si coinciden ambas posiciones. Para ello, en la clase Viewport, encargada de gestionar la interacción del usuario con el visualizador, establecemos un evento que se activa cuando el usuario indica al editor que quiere subdividir el lago. En la función asociada al evento creamos una instancia de la clase Raycaster que nos ayudará a gestionar este proceso al que proporcionamos los puntos x e y que ha seleccionado el usuario en la pantalla. Estos puntos son envueltos en una clase proporcionada por Three.js denominada Ray. Posteriormente recorremos los elementos que conforman el lago denominados por la clase Primitive para las cuales llamamos la función raycast, implementado en su totalidad por Three.js con el fin de saber si se ha producido una intersección con la instancia de Primitive y en caso afirmativo obtener los triángulos que conforman los elementos con los que se ha producido dicha intersección. Debido a que el lago está compuesto por un gran número de instancias de Primitives, este proceso no se ejecuta con la rapidez necesaria por lo necesitamos realizar ciertas modificaciones. La primera modificación es muy simple pero mejorará considerablemente la velocidad de este proceso. Esta modificación consiste en disminuir el número de elementos sobre los cuales se tiene que ejecutar este algoritmo. Debido a que solamente necesitamos la superficie para determinar la porción del lago solamente recorreremos los elementos que conforman la superficie a la vez que que fijaremos la cámara por encima del lago para que el usuario no tenga ninguna duda de que elementos puede seleccionar como se muestra en la figura. La segunda modificación es implementar una estructura de datos denominada Bounding Volume Hierarchy que se trata de un árbol en el que los nodos hojas están compuestos por instancias de la clase Primitives y los nodos superiores 48 Capítulo 3. Descripción del Trabajo guarda información del cubo que contiene a todos sus hijos. 3.5.5. Bounding Volume Hierarchy Para la creación de la estructura Bounding Volume Hierarchy creamos dos clases que nos ayudarán a implementar este árbol, la clase Bvh y la clase nodo. Cada vez que importemos un lago al editor debemos crear una instancia Bvh en el que crearemos el árbol sobre el cual solamente realizaremos consultas. La clase Bvh consta de un array de tamaño 2*nPrimitives-1 que representará el árbol y donde se almacenará los nodos La fase de construcción empieza por obtención de las dimensiones de un cubo imaginario capaz de contener a todos los elementos primitivos que componen el lago, posteriormente se ejecuta recursivamente una función que reparte las instancias de la clase Primitives en dos partes hasta que solamente queden dos instancias por repartir. Existen diferentes metodologías para dividir los objetos, en este caso hemos decidido usar la más simple, que consiste en dividir las componentes del lago en función del eje más largo, aunque este método tiene ciertos inconvenientes, en casos en los que los objetos que conforman la escena estén demasiado dispersos entre si (que no es nuestro caso) provocando que se produzcan más llamadas recursivas de las necesarias. Para la implementación de esta estructura hacemos uso principalmente de las siguientes variables. NodoLIst: es un array en el que almacenamos los nodos que conforman el árbol ListPrimitives: lista con instancias de la clase Primitive que conforman la superficie del lago Nodo: clase que guarda la posición en NodoList de, el tamaño del cubo que encapsula todos sus hijos, el número de nodos hoja que contiene y la posición del primer elemento en el array indexLIst IndexList: es un array con los índices del array ListPrimitives. En cada llamada recursiva el subarray establecido por las variables de la clase Nodo (tamaño y primeraPos) nacerán dos hijos que dividirán otra vez el subarray dependiendo del centroide de cada instancia Primitive. Haremos uso de un pequeño ejemplo para esclarecer cualquier duda. Como podemos ver en la figura ?? partimos de un nodo inicial que añadimos al array NodoList, debido a que este nodo contiene todos los elementos de las escena el array indexList no será modificado y elnúmero de elementos que tendrá asignado el nodo es de 4 elementos y una variable apuntando a la primera posición de Nodolist. Tras la primera llamada recursiva dividimos la escena en función del eje más largo, en este caso es el eje x, reordenando en el proceso el array indexlist y obteniendo dos nodos hijos Left y Right que serán añadidos a Nodolist.Ambos nodos contendrán 2 elementos, 3.5. Visualizador 3D(Three.js) 49 Figura 3.17: A really Awesome Image Figura 3.18: Dos últimas llamadas recursivas 50 Capítulo 3. Descripción del Trabajo nodoLeft apuntará a la primera posición de Nodolist y nodoRight apuntará a la tercera posición de NOdolist. Posteriormente realizamos llamadas recursivas por cada nodo.En este caso al quedar dos elementos en ambos nodos hijos solamente tenemos que añadir un nodo hoja al array nodoList por cada elemento. 3.5.6. Optimizaciones En esta sección explicaremos el rendimiento inicial del visualizador así como las implementaciones necesarias para su mejora. 3.5.6.1. Rendimiento inicial Tras importar el modelado del lago al visualizador nos encontramos con un pobre rendimiento del visualizador,presentando varios problemas en los que se incluye un largo tiempo de carga a la hora de importar el lago, poca fluidez a la hora de intentar visualizar diferentes perspectivas del lago. Esta serie de problemas que claramente perjudica la experiencia del usuario nos obliga a investigar las causas de estas mismas. Para ello usamos Stats, un software que se encuentra en GitHub escrito en JavaScript que nos permite evaluar el rendimiento del visualizador proporcionándonos tres diferentes tipos de información necesaria para su evaluación Fps, MS y MB. En nuestro caso solamente utilizamos los FPS que son las siglas para Frames per second que indica el número de imágenes consecutivas que son presentadas por segundo. Todo esto depende del dispositivo en el que se ejecuta, siendo mayor los fps en dispositivos más rápidos. Para ello tenemos que tener en cuenta que el ojo humano es capaz de diferenciar como imágenes únicas cuando los fps están por debajo de 12 fps por lo que para ofrecer la mayor experiencia al usuario hemos apuntado por fps mayor de 30, que en nuestro caso permite al usuario de utilizar el visualizador con fluidez. También hay que tener en cuenta que los fps están relacionados con los Hz del monitor utilizado, que indica la frecuencia con la que el monitor actualiza la imagen. La mayoría de los monitores hoy en día tienen 60 hz por lo que un rendimiento mayor de 60 fps pasará desapercibido para este tipo de monitores. El software Stats nos muestra que los fps en el ordenador utilizado están por debajo de 15 fps, llegando en muchas ocasiones a estar por debajo de 10 fps, esto nos confirma que existe un problema de rendimiento de nuestro visualizador que requiere ser tratado. Para ello necesitamos un mejor entendimiento de como una imagen termina mostrándose en nuestra pantalla. 3.5.6.2. Renderización de una Escena En esta sección explicaremos de forma breve y superficial como un modelo 3d termina siendo mostrado en nuestras pantallas. Esto nos proporcionará del conocimiento necesario para mejorar el rendimiento del visualizador. Podemos dividir el proceso de renderización en tres fases que se comunican entre sí :Aplicación, geome- 3.5. Visualizador 3D(Three.js) 51 Figura 3.19: Transformación de objetos a espacio view tría y rasterización. Cada fase depende de la anterior, por lo que, salvo la primera fase, las demás obtienen la información proporcionada por la fase anterior y, por lo tanto, la velocidad global de este proceso está marcada por la fase más lenta. El proceso de renderizado comienza por la fase de aplicación, que es ejecutada en su totalidad en la cpu y sobre la que tenemos un control total. La selección de colores en función de la temperatura y la interacción con el editor forman parte de esta fase, que una vez finalizada, proporciona a la siguiente fase los objetos que requieren ser renderizados. La siguiente fase es la geométrica, encargada de la mayoría de operaciones relacionadas con polígonos y vértices. Esta fase está dividida en 5 subfases: model and view transform, vertex shading, projection, clip-ping, y screen mapping. Modelo y transformaciones Un modelado puede estar en diferentes espacios, inicialmente se encuentra en el espacio de modelado. En él, el modelado no ha sido sometido a ninguna transformación. Dada su posición en el espacio de modelado se le aplica diferentes transformadas como pueden ser de rotación de escala o de posición, para obtener coordenadas localizadas en el espacio del mundo. Por tanto, en caso de usar varios modelados del mismo tipo, podemos simplemente usar un modelado y aplicar las transformaciones al modelado, para obtener diferentes instancias del modelado en el espacio del mundo, que se trata de un espacio único y compartido entre todos los demás modelados transformados y otros elementos importantes como puede ser la cámara. Debido a que solamente se muestra la perspectiva de la cámara, que tiene una posición en el espacio del mundo y con el fin de facilitar el trabajo de las siguientes fases la cámara es posicionada en el origen, es decir en la posición (0,0,0) y los modelos son sometidos a una serie de transformadas con el fin de mantener la escena a mostrar obteniendo las coordenadas en el espacio vista. Vertex shading Tras obtener los modelos en el espacio view procede a pasar a la fase vertex shading se aplica las modificaciones necesarias para al material del modelado para ofrecer una apariencia más realista, estas modificaciones están relacionadas principalmente al efecto que tiene la luz sobre el material del modelado. 52 Capítulo 3. Descripción del Trabajo Projection Para simular el ojo humano y dar una apariencia aún más realista a los modelados se aplican una transformada de perspectiva que provoca que los objetos más alejados de la cámara sean percibidos más pequeña que los objetos más cercanos tal y como lo percibe el ser humano en la realidad. Cliping Después de este proceso la escena ha de pasar por un proceso denominado cliping en él se realiza un filtro de los modelados que pasan a la fase final, aquellos modelados que se encuentran por completo fuera del polígono de visión no pasaran a la fase final. El proceso de cliping aunque no sea necesario es importante ya que mejora el rendimiento al no tener que renderizar los modelados que no aparezcan en el frustum. Por último hay que transformar las coordenadas (x,y,z) de los modelos que han conseguido llegar a esta fase a coordenadas (x,y) que representen coordenadas de la pantalla y finaliza por un proceso de rasterización en el que se asigna el color a cada pixel. 3.5.6.3. Cambios en el código Gran parte de este complejo proceso es implementado en nuestro caso por Three js que como hemos explicado previamente utiliza a su vez OpenGl por lo que realmente únicamente tenemos acceso de forma completa a la fase aplicación y de forma parcial a la fase geométrica en la subfase de vertex shading. Antes de continuar con la optimización hacemos uso de spector.js que es un software que nos proporciona información sobre una escena de un aplicación que utilice WebGl y que nos puede ser de utilidad a la hora de investigar los posibles motivos por el cual el visualizador ofrece un pobre rendimiento. Podemos apreciar en la figura que el número de draw calls que son el número de llamadas que la cpu realiza a la api de la gpu (Opengl en este caso) es igual al número de cubos mediante el cual queremos representar el lago es decir la cpu realiza 73800 draw calls. Cada draw call supone un coste alto por parte de la cpu independientemente del número de modelos que se quiera dibujar y por la forma en la que la gpu está implementada por lo que podemos deducir el motivo por el cual el visualizador no tiene un buen rendimiento es debido a que la velocidad de la cpu en procesar un draw call es mayor a la velocidad que tarda la gpu en dibujar el modelado requerido por lo nos situamos en la situación en la que la cpu tiene un gran cantidad de datos a procesar y a la gpu se le proporciona pocos datos con los que trabajar desaprovechando su capacidad de paralelismo. Por esta razón disminuir el número de draw calls supondrá una gran mejora de rendimiento. Como hemos visto previamente en caso de utilizar varios modelados del mismo tipo tenemos la posibilidad de crear un solo modelado y a partir de él crear varias instancias. Debido a que inicialmente representamos el lago únicamen- 3.5. Visualizador 3D(Three.js) 53 te usando cubos nos facilita de forma considerable el proceso de instanciamiento. Creamos en la fase de aplicación sobre la cual tenemos control total un cubo usando la clase BoxGeometry que nos proporciona three.js para crear un cubo genérico que es sobre el que vamos a partir para crear el lago. Después hacemos uso de otra clase que nos facilita three.js para realizar las instancias InstancedBufferGeometry en el que indicamos el número de instancias (en este caso son 73800) y asociamos a la clase a aquellos atributos que creamos necesarios para su representación, en este caso proporcionamos tres buffers: posición, color y escala. THree js desconoce la Figura 3.20: Fps del visualizador tras la optimización función de los atributos proporcionados por lo que debemos de realizar dos simples programas denominados vertex shader y fragment shader en el cual se indicara la función estos. Ambos se tratan de dos programas que se ejecutan en gpu y que están programados utilizando un lenguaje de alto nivel que en este caso es el lenguaje Glsl implementado por Opengl. El programa vertex shader se ejecuta en la fase de geometría y se ejecuta por cada vértice del modelado en el hacemos uso de los atributos posición y escala para indicar la posición que en el que aparece cada vértice por otro lado el programa frgment shader se ejecuta en la fase de rasterización y se encarga de indicar el color de los pixeles que ocupa cada objeto. Tras aplicar esta optimización podemos apreciar una mejora considerable de rendimiento obteniendo unos 60 fps que permite al usuario obtener una experiencia más fluida [Introducir Imagen] Usando el software Spector.js podemos apreciar que la razón de esta mejora es la disminución del número de draw calls pasando de 73800 draw calls a un solo draw call pudiendo aprovechar la capacidad de paralelismo de la gpu. Como se ha explicado previamente debido a la necesidad de mejorar el realismo del lago hemos descartado el cubo como objeto para representar el lago y lo hemos sustituido por otros objetos parecidos al cubo pero que no llegan a ser el mismo tipo de geometría por lo que técnicamente se tratan de diferentes objetos. Por esta 54 Capítulo 3. Descripción del Trabajo Figura 3.21: Número de draw calls tras la optimización razón la optimización explicada previamente no puede ser usada aunque gran parte de los conocimientos adquiridos van a ser utilizados. Para ello unificamos todos los vértices en un solo objeto, esto nos permitirá seguir realizando un solo draw call. 3.6. Node.js Node.js es un entorno de tiempo de ejecución de JavaScript que se utiliza para crear aplicaciones escalables del lado del servidor y de red a través de servidores privados virtuales. Ofrece operaciones de entrada/salida (E/S) no bloqueantes y está construido según una arquitectura asincrónica basada en eventos para ayudar a los desarrolladores a crear diversos proyectos de forma eficiente y sencilla. A continuación, exploraremos algunas de sus características y cómo se utiliza para tareas específicas en el backend: 1. Lectura de ficheros. Node.js proporciona módulos como fs (sistema de archivos) que permiten leer y escribir archivos de manera eficiente. Se puede leer contenido de archivos, manipular directorios y gestionar permisos utilizando estas funciones. 2. Ejecución de comandos. Node.js permite ejecutar comandos del sistema operativo directamente desde tu aplicación. Tiene un módulo child_process para ejecutar programas externos, como scripts de shell o utilidades de línea de comandos, lo cual podríamos necesitar para ejecutar simulaciones. 3. Rapidez. Node.js está construido sobre el motor V8 de Google Chrome, que compila JavaScript en código de máquina, que se encuentra altamente optimizado. Su arquitectura es asincrónica y no bloqueante, lo que permite manejar 3.6. Node.js 55 múltiples solicitudes simultáneamente con tiempos de ejecución rápidos y un menor uso de recursos. Considerando todas estas características, decidimos incorporar Node.js a nuestro proyecto a fin de poder optimizar el desarrollo del editor. 3.6.1. Ficheros de datos Node.js es capaz de realizar lecturas de ficheros de datos en diferentes formatos. En nuestro caso, solo necesitamos leer archivos en formato CSV. Consideramos que una de las medidas para optimizar el rendimiento del editor es limitar la cantidad de datos almacenados en el mismo. En una de las primeras versiones que desarrollamos, leíamos los datos provenientes de micro-devs-bloom directamente en el editor, utilizando el método fetch. Inicialmente, nuestras simulaciones no ocupaban un gran tamaño. Sin embargo, a medida que la duración de la simulación aumenta, el tamaño de los datos también incrementa. Por ejemplo, si deseamos visualizar datos de una simulación con una duración de varios años, con mediciones muy frecuentes durante los días, para observar la evolución de las floraciones de cianobacterias, podrían surgir problemas de latencia si el editor almacena demasiados datos. Esta situación puede afectar significativamente el rendimiento y la capacidad de respuesta del editor, haciendo que sea difícil de usar para análisis detallados y prolongados. Considerando estas conclusiones, y con el objetivo de que la aplicación sea escalable a otros lagos y simulaciones, hemos decidido utilizar Node.js para la lectura de datos, limitando el número de datos que se almacenan en el editor. Esto no solo optimiza el rendimiento y la velocidad del editor, sino que también permite manejar simulaciones más largas y complejas sin comprometer la eficiencia del sistema. 3.6.1.1. Lectura de datos para micro-devs-bloom La mejor manera de controlar la cantidad de datos que almacena un editor es limitando su tamaño. Almacenar datos dentro del editor sin control podría limitar su escalabilidad futura, impidiendo su uso en otros cuerpos de agua. Nuestras simulaciones micro-devs-bloom tienen aproximadamente 500 mediciones, lo que no supone un problema para el editor. Considerando que un valor real ocupa 8 bytes, la simulación ocuparía poco más de 4.000 bytes, es decir, unos 4 KB. Para evitar problemas en futuras simulaciones, hemos decidido limitar el tamaño de los datos almacenados en el editor a 50 KB (6250 números reales). La idea es que la lectura de datos sea gestionada por Node.js, y que el editor solicite recursos a medida que avanza la simulación. Esto se logra mediante una ventana deslizante, similar al protocolo TCP, como se muestra en la figura 3.22. En este sistema, el editor actúa como cliente y recibe los datos tras realizar una petición de visualización al servidor. Hemos optado por simplificar el proceso eliminando los mensajes de confirmación, de modo que solo el editor envíe solicitudes de recursos al servidor. Cada solicitud del editor incluye un campo llamado sig, que indica el rango de datos solicitados [sig, sig + 6250). Este enfoque permite controlar 62 Capítulo 4. Caso de Uso Figura 4.3: Reproductor con scroll para configurar el tiempo Figura 4.4: Etiqueta con información al hacer doble click en un punto determinado 4.2.1. Visualización de concentraciones Para visualizar la información del lago, tenemos a nuestra disposición la pestaña concentración. En él debemos de importar dos archivos, el de las concentraciones (temperatura, oxigeno y nitratos) a través del botón Concentraciones y el de la predicción de proliferaciones a través del botón Bloom. Una vez cargados los archivos podemos seleccionar la información que queremos visualizar. Para poder visualizar los cambios que se producen a lo largo del tiempo en el lago de una manera más dinámica, tenemos a nuestra disposición un scroll mostrado en la figura 4.3, el cual podemos modificar de forma manual o pulsando al play. Con el fin de informar al usuario, de las variables relacionadas al lago, el usuario puede hace doble click y le mostrará información relacionada con el punto seleccionado, como se muestra en la figura ??. 4.2.2. SubLago En caso de que la persona a cargo del sistema acuático quiera visualizar información de una zona concreta del lago, el visualizador ofrece la opción de quedarnos con una porción del lago. Para ello es necesario pulsar la pestaña Sublago en la parte derecha del visualizador. Automáticamente la cámara apuntará al centro del lago de forma perpendicular. El usuario podrá seleccionar 4 puntos con el ratón. Al seleccionar el cuarto punto solamente se mostrará la porción seleccionada. 4.2. Lago Washington 63 Figura 4.5: Representación de temperaturas en el visualizador Figura 4.6: Representacion del oxigeno 64 Capítulo 4. Caso de Uso 4.2.3. Visualizar recorrido del USV Para visualizar el recorrido del USV, hemos desarrollado una función dentro de la barra lateral, en la pestaña micro-devs-bloom (figura 4.7. Aquí, damos la opción al usuario de escoger las coordenadas donde quiere que el USV inicie la simulación utilizando el software micro-devs bloom. Las funcionales son las siguientes: 1. Selección de Coordenadas de Inicio. Los usuarios pueden escoger las coordenadas donde desean que el USV inicie la simulación. 2. Ejecución de la Simulación. Al seleccionar Ejecutar, se iniciará la simulación y el botón correspondiente se pondrá en rojo hasta que finalice. Las simulaciones, dependiendo de su tamaño, pueden tardar varios minutos en ejecutarse. Tras finalizar, el botón se pondrá en verde, indicando que la simulación ha terminado. 3. Factor de Escalado. Relacionado con el escalado del lago para una visualización correcta y precisa. Por defecto, el lago se ha escalado 500 unidades. 4. Velocidad del Barco. La velocidad predeterminada es de una unidad, con un intervalo de 200 ms entre cada medición de tiempo. Si se aumenta el factor de escalado, la velocidad disminuye, y si se disminuye el factor, la velocidad aumenta. La relación de velocidad está dada por: 200 / factor ms. 5. Simular USV. Al seleccionar el botón Iniciar Simulación, se inicia la simulación del USV, observándose que se mueve. Si se presiona de nuevo el botón, no tendrá efecto hasta que la simulación termine. Figura 4.7: Interfaz completa micro-devs-bloom 4.3. Embalse de Santillana 65 4.3. Embalse de Santillana Durante la elaboración del proyecto, hemos estado en continuo contacto con el Trabajo de Fin de Grado Análisis de la calidad de aguas en embalses mediante simulación con EEMS. Este proyecto se ubica dentro de este trabajo de investigación, concretamente dentro de la fase de modelado y simulación EEMS. El objetivo inicial era que se nos proporcionase una salida del EEMS con datos de la laguna del Campillo o el embalse de Santillana, para posteriormente probar y mostrar la visualización de dicha simulación. Sin embargo, han tenido algunas dificultades a la hora de obtener la licencia EEMS, y han tenido que utilizar otros métodos para obtener una correcta simulación. Dificultad para obtener la variable nv Los métodos alternativos para generar las simulaciones sin tener la licencia EEMS ha consistido en modificar el archivo del .nc del lago Washington utilizando varias técnicas en Matlab. Una de las mayores dificultades ha sido obtener los vértices que delimitan cada celda. Recordemos que finalmente utilizamos la métrica de celdas, donde básicamente utilizamos la geometría en 2D de cada celda, para reproducirla en 3D. Tras numerosas pruebas, los vértices no correspondían con cada celda, produciendo formas complicadas de visualizar en Blender. Recordemos que la disposición de los vértices en el archivo de datos del lago Washington estaba conformada por 4 vértices dispuestos de la siguiente manera: Vértice 0: unido a 1 y a 3. Vértice 1: unido a 0 y a 2. Vértice 2: unido a 1 y a 3. Vértice 3: unido a 0 y a 3. A partir de esto, se podrían producir los 8 vértices de cada celda para reproducir la figura en 3D. Vértice 0: unido a vértices 1, 3 y 4. Profundidad 0. Vértice 1: unido a vértices 0, 2 y 5. Profundidad 0. Vértice 2: unido a vértices 1, 3 y 6. Profundidad 0. Vértice 3: unido a vértices 0, 2 y 7. Profundidad 0. Vértice 4: unido a vértices 5, 7 y 0. Profundidad 1. Vértice 5: unido a vértices 4, 6 y 1. Profundidad 1. Vértice 6: unido a vértices 5, 7 y 2. Profundidad 1. Vértice 7: unido a vértices 4, 6 y 3. Profundidad 1. 66 Capítulo 4. Caso de Uso Al intentar mostrar estos datos dentro de Blender, no se podría apreciar ninguna figura en concreto, solo figuras que parecían que se cortaban entre sí. Por tanto, decidimos analizar las celdas de este archivo, empezando por la primera celda. En la figura 4.8 se puede observar como la figura se corta a sí misma, sin producir la forma geométrica esperada. Cambiando algunas de las aristas que conectan los vértices, se conseguimos obtener un trapezoide, como se puede ver en la figura 4.9, donde la disposición geométrica queda de la siguiente manera: Vértice 0: unido a 2 y a 3. Vértice 1: unido a 2 y a 3. Vértice 2: unido a 0 y a 1. Vértice 3: unido a 0 y a 1. Aplicando esta forma geométrica a todas las celdas, obtenemos un resultado poco concluyente, que se puede observar en la figura 4.10. Teniendo esto en cuenta y analizando más a fondo los archivos recibidos del otro proyecto, sacamos estas conclusiones: La disposición geométrica de cada celda es diferente, no siguen un patrón claro. Muchas celdas se sobreponen unas sobre otras, cuando no debería ser así. No se puede obtener representaciones fiables sin que los vértices estén dispuestos correctamente. Por tanto, no podemos obtener una visualización del estanque de Santillana o la laguna del Campillo. Figura 4.8: Representación de la primera celda en GeoGebra Solución Sin la salida EEMS, se ha llegado a la solución de representar únicamente una parte del del estanque de Santillana, utilizando parte del lago Washington, cuya geometría si está bien definida. Los resultados se muestran en la figura 4.11 4.3. Embalse de Santillana 67 Figura 4.9: Corrección de aristas de la primera celda en GeoGebra Figura 4.10: Representación fallida utilizando la nueva geometría 68 Capítulo 4. Caso de Uso Figura 4.11: Representación 3D de una parte del estanque de Santillana. Cap´ ıtulo 5 Conclusiones y Trabajo Futuro En este capítulo se recoge la revisión de los objetivos planteados en la sección 1.2, así como las conclusiones que han surgido tras desarrollar el visualizador 3D. También se incluyen propuestas para continuar este proyecto. 5.1. Revisión de los objetivos A lo largo del documento, hemos abordado los distintos objetivos establecidos al comienzo del trabajo. En esta sección, estableceremos una conexión explícita entre los objetivos y los capítulos, secciones y subsecciones redactados. De esta manera, evaluaremos el progreso y logro de cada una de las metas establecidas. Diseño de un visualizador 3D Este objetivo marcaba como meta desarrollar una herramienta de visualización que representara de manera tridimensional las diferentes concentraciones de cianobacterias. Precisamente, en el capítulo 3 se abordó todo el desarrollo del visualizador 3D, permitiendo además otros datos de interés como la temperatura del agua y algunas concentraciones como el oxígeno disuelto en agua. Además, en este capítulo se explica paso a paso las diferentes fases de nuestro proyecto para finalmente poder desarrollar el visualizador. Lo único que ha quedado pendiente es mostrar dentro del visualizador la información de los diferentes sensores de micro-devs-bloom. Integración con modelos computacionales Este objetivo marcaba como meta integrar simuladores especializados (MIKE, COMSOL, EEMS, DEVS-BLOOM) en nuestro sistema. Precisamente, desde el inicio, hemos trabajado con datos provenientes del simulador EEMS para poder representarlo en 3D. Además, hemos integrado el sistema de simulación DEVS-BLOOM en nuestro proyecto utilizando Node.js, de manera que se puede ejecutar y visualizar simulaciones desde el propio visualizador. 69 70 Capítulo 5. Conclusiones y Trabajo Futuro Facilitación de la interpretación de datos Nuestro objetivo desde el inicio fue crear un sistema intuitivo que permitiera a los investigadores y autoridades tomar decisiones de manera rápida y eficaz. Aunque inicialmente consideramos desarrollar una interfaz desde cero, decidimos investigar a fin de encontrar un sistema tridimensional de referencia para este ámbito. Es ahí cuando surge la idea de utilizar la biblioteca Three.js, y decidimos descargar sus recursos. Ahí nos dimos cuenta de que ya contábamos con una base sólida: contenía a modo de ejemplo un editor 3D, si bien solo permitía realizar operaciones básicas como agregar o eliminar figuras predeterminadas, resultaba sumamente usable y fácil de entender. Por ello, decidimos desarrollar el visualizador dentro de esta interfaz existente, logrando así una solución final minimalista y altamente funcional. Capacidad del visualizador para trabajar con archivos CSV o H5 El objetivo secundario de permitir al visualizador trabajar con archivos CSV o H5 ha sido superado con éxito. Todo el visualizador funciona directamente con datos en formato CSV, lo que incluye las concentraciones, la integración con micro-devsbloom y la entrada de Blender. Esto asegura una mayor compatibilidad y facilidad de uso y manejo de los datos. Validad el editor 3D con diferentes casos de uso Se trata de un objetivo secundario marcado a fin de validar el desarrollo del visualizador, ya que, al comparar los resultados obtenidos con los resultados esperados, podemos identificar y corregir posibles errores, garantizando así la precisión y fiabilidad del simulador. Sin embargo, solo hemos tenido acceso a dos casos de uso diferentes, uno con los datos iniciales de partida y otros incompletos provenientes de embalse de Santillana. Por tanto, este objetivo no se ha cumplido en su totalidad. 5.2. Resumen de resultados y trabajo futuro Podemos concluir que se han cumplido con los objetivos generales iniciales. A continuación, se comentan algunas consideraciones acerca de proyecto realizado, así como algunas conclusiones acerca del trabajo futuro. 5.2.1. Resumen del proyecto El proyecto desarrollado trata directamente con datos provenientes de los simuladores de las fases anteriores, como EEMS o DEVS-BLOOM, por lo que no hay ningún problema de compatibilidad de datos con las fases previas. El modelado tridimensional de un lago o estanque, es factible siempre y que los datos provengan de un simulador como EEMS, o simulador similar que produzca la misma salida. 5.2. Resumen de resultados y trabajo futuro 71 Es necesario tener Blender instalado para la creación de la malla del cuerpo de agua, ya que, la biblioteca bpy es exclusiva de Blender. Se pueden ejecutar simulaciones DEVS-BLOOM (en nuestro caso, micro-devsbloom) directamente desde el visualizador, utilizando el servidor de Node.js, sin necesidad de tener que ejecutarlo por la terminal. La interfaz de usuario está pensada para que pueda ser utilizada por cualquier usuario, sin necesidad de que conozca cómo funcionan los sistemas tridimensionales. 5.2.2. Propuestas y trabajo futuro Integrar este visualizador dentro de la aplicación web llamada DEVS-BLOOMWebUI. Esta interfaz ya integra modelos del sistema como el editor de escenarios. Considerar añadir la representación de la velocidad del viento dentro de este visualizador. Realizar análisis de rendimiento y consumo de CPU y memoria RAM durante la ejecución de todas las fases que componen el sistema SMART-BLOOM, a fin de determinar la capacidad mínima necesaria para que un computador realice todo el ciclo de simulación. Esto será necesario para determinar qué tipo de computadoras deberán de tener los centros de monitorización de cianobacterias. Analizar el coste en almacenamiento que suponen todas estas simulaciones en tipo real. Analizar el coste económico que supone desplegar el sistema SMART-BLOOM para cada centro de monitorización. Considera extender este sistema para determinar otros patrones del agua, como detección de sequías, inundaciones o alteración del sistema acuático. 78 Capítulo 5. Conclusiones y Trabajo Futuro Posteriormente, investigué sobre los colores más adecuados para representar las visualizaciones. Fue entonces cuando descubrí las diversas paletas de colores detalladas en la sección 3.4.6. La elección de una paleta de colores adecuada es crucial para garantizar que la información se presente de manera clara y comprensible, facilitando así la interpretación de los datos por parte de los usuarios. Durante la elaboración del proyecto, nos contactaron los autores del Trabajo de Fin de Grado sobre el Análisis de la calidad de aguas en embalses mediante simulación con EEMS. El objetivo principal era visualizar sus resultados. Las primeras propuestas para visualizar las simulaciones que habían desarrollado no fueron muy exitosas, ya que reajustar la dimensionalidad de todas las variables es complicado sin la posibilidad de utilizar directamente el simulador EEMS. En este aspecto, debo dar crédito a Marcos, quien estuvo en contacto constante, realizando simulaciones y compartiéndolas conmigo a través de Google Drive. La cantidad de datos fue tan grande que llegó a quedarse sin espacio, ya que cada simulación pesaba aproximadamente unos 4,1 GB. Mi contribución en esta parte fue probar estas simulaciones, transformar los datos a formato CSV y comunicar los errores relacionados con la dimensionalidad de las variables. También informé sobre la imposibilidad de representar adecuadamente los vértices de las celdas sin la variable nv. Finalmente, tras analizar las conclusiones extraídas de las simulaciones, se decidió representar una parte del estanque de Santillana basando la simulación en la del lago Washington. Durante la búsqueda de información para el desarrollo, propuse utilizar la librería Three.js. Posteriormente, empleamos el editor 3D de ejemplo disponible en la página oficial de Three.js, bajo la licencia MIT. A partir de aquí, organizaba dos reuniones por semana con mi compañero. En el desarrollo de este visualizador, me enfoqué principalmente en implementar micro-devs-bloom. Durante esta fase, fuimos haciendo pruebas con el editor, donde se podía observar cierta latencia cuando había muchos objetos en escena y se cargaban simulaciones. Para optimizar el rendimiento del editor, decidí integrar Node.js dentro del visualizador. Esta implementación fue necesaria para que el editor funcionara de manera independiente de los recursos y datos provenientes de EEMS y micro-devs-bloom. Durante la elaboración y desarrollo de esta memoria, me encargué principalmente de organizar los puntos del documento, asegurando que cada sección y subsección estuviera bien estructurada y cubriera todos los aspectos necesarios del proyecto. También me ocupé de gestionar las tareas, asignando responsabilidades entre mi compañero y yo para que el trabajo se distribuyera de manera equitativa. Mientras completábamos la memoria, revisábamos mutuamente los puntos para corregirnos y mejorar la calidad del trabajo. Todo esto, junto con la ayuda de nuestro tutor, hizo posible que este documento esté redactado correctamente para poder ser presentado. Por lo tanto, a rasgos generales, se puede decir que he participado en cada una de las fases que componen el proyecto, desde la configuración de datos inicial hasta la implementación del visualizador 3D. Esto incluyó el análisis de los datos proporcionados por EEMS, la conversión de estos datos a formatos más utilizables como CSV, y la integración de los resultados en un entorno de modelado adecuado. También me involucré en la búsqueda de herramientas y tecnologías adecuadas, como Three.js, Blender y Node.js y en la implementación del modelado y desarrollo del 5.2. Resumen de resultados y trabajo futuro 79 visualizador. Además de ayudar en el desarrollo de la memoria, también me he encargado de organizar reuniones con mi compañero y de distribuir las diferentes tareas que iban surgiendo entre ambos, estableciendo metas y plazos para evitar retrasos en la finalización de este TFG. Estas reuniones fueron cruciales para coordinarnos de manera eficiente. Por lo tanto, teniendo todo esto en cuenta, me considero satisfecho con la planificación y el trabajo realizado. Fumu Grace Makitu Koudymba Inicialmente debido a nuestra falta de conocimiento respecto al modelado 3d, cada uno tuvimos que investigar por nuestra cuenta. Uno de nuestros primeros objetivos en los que tuvimos que investigar de forma separada fue la creación de un modelo 3d del lago Washington dado una serie de longitudes y latitudes. Ambos conseguimos la representación 3d usando diferentes métodos. En mi caso el método usado fue la la transformación de longitudes y latitudes a posiciones píxeles. Debido a que este método añadía un complejidad innecesario en comparación de mi compañero, este método fue finalmente descartado. Otra de las funciones que mi compañero y yo tuvimos que implementar de forma paralela debido a nuestro desconocimiento inicial fue la representación de la profundidad y la representación de diferentes variables. Para realizar la representación de la profundidad inicialmente añadía un cubo 3d debajo de cada cubo, aunque esta representación ofrecía un resultado poco preciso, era suficiente para poder seguir con la implementación del visualizador. A la hora de realizar la página web, el reparto de trabajo entre mi compañero y yo fue más notable. Inicialmente estuve implementando una aplicación en c++ usando Opengl para la creación de objetos 3d y la librería GLFW para la interfaz de usuario , que posteriormente tuvimos que descartar debido a que aumentaba la complejidad del proyecto de forma innecesaria y la implementación de una pagina web era más adecuada para este proyecto. Inicialmente me encargué de implementar una simple interfaz de usuario de la página web usando html y css, pero debido a que realizar la página web desde cero consumía mucho tiempo la tuvimos que descartar y conservar solamente con la funcionalidad implementada hasta el momento mediante el uso de la librería de Three.js. Una vez establecida el editor Three.js como la base de la página web tanto mi compañero como yo tuvimos que estudiar el código del editor y nos encargamos en trasladar la funcionalidad que habíamos implementado previamente. A lo largo del proyecto estuve encargado de realizar diferentes optimizaciones con respecto al modelo 3d del lago, debido a la gran cantidad de objetos que la conformaban.Para la realización de optimizaciones el libro Real Time Rendering de Tomas Akenine y Eric Haines fue de gran ayuda para la comprender todo el proceso de renderizado y aplicar la recomendaciones para mejorar el rendimiento de aplicaciones que tengan que renderizar algún objeto 3d. Una de la optimizaciones obtenidas de este libro fue el uso de instancias para disminuir la carga de trabajo en la cpu y mejorar el rendimiento general. También me encargué de implementar la funcionalidad de obtener un sublago para ello tuve que investigar de que forma implementar una estructura eficiente que para obtener 80 Capítulo 5. Conclusiones y Trabajo Futuro las zonas deseadas. Una vez realizada toda la implementación, las últimas semanas estuvimos redactando la memoria. Empezamos cada uno redactando su parte de trabajo realizada, y de forma paralela, nos íbamos revisando la parte uno del otro. Durante estas últimas semanas nos hemos reunido con más frecuencia, a pesar de de los exámenes de la convocatoria ordinaria, debido a que debíamos pulir más la memoria para no dejarnos ningún punto sin explicar. En general, siento que nos hemos organizado a fin de repartir las tareas de forma equitativa. En general, me siento muy satisfecho con el trabajo realizado, siento que de verdad he aprendido muchas cosas sobre modelos tridimensionales a la vez que me informaba sobre el proyecto SMART-BLOOM. Bibliografía Y así, del mucho leer y del poco dormir, se le secó el celebro de manera que vino a perder el juicio. (modificar en Cascaras\bibliografia.tex) Miguel de Cervantes Saavedra Akenine-Moller, T.,Haines, E. yHoffman, N. Real-time rendering. AK Peters/crc Press, 2019. Berg, K.,Skulberg, O. M.,Skulberg, R.,Underdal, B. yWillén, T. Observations of toxic blue-green algae (cyanobacteria) in some scandinavian lakes. Acta Veterinaria Scandinavica, vol. 27(3), página 440, 1986. Bury, N.,Eddy, F. yCodd, G. The effects of the cyanobacterium microcystis aeruginosa, the cyanobacterial hepatotoxin microcystin–lr, and ammonia on growth rate and ionic regulation of brown trout. Journal of Fish Biology, vol. 46(6), páginas 1042–1054, 1995. Carmichael, W. W. yGorham, P. R. Anatoxins from clones of anabaena flosaquae isolated from lakes of western canada: With 3 figures and 2 tables in the text. Internationale Vereinigung für Theoretische und Angewandte Limnologie: Mitteilungen, vol. 21(1), páginas 285–295, 1978. Chacón, J.,Andrade, G. A.,Risco-Martín, J. L. yEsteban, S. A bleeding edge web application for early detection of cyanobacterial blooms. Electronics, vol. 13(5), 2024. ISSN 2079-9292. Conlan, C. The blender python API: Precision 3D modeling and add-on development. Apress, 2017. Dirksen, J. et al. Three. js essentials. Packt Publishing, 2014. García, S. I. Cianobacterias y cianotoxinas, impactos sobre la salud humana. Obtenido de www. ataonline. org: http://www. ataonline. org. ar/bibliotecavirtual/documentos_ utilies/Cianobacterias_y_Cianotoxinas. pdf , 2009. 81 82 BIBLIOGRAFÍA Hallegraeff, G. Harmful algal blooms: a global overview. Manual on harmful marine microalgae, vol. 33, páginas 22–50, 2003. Lee, J. J. Awesome graphics libraries. 2023. Disponible en https://github. com/jslee02/awesome-graphics-libraries/commits/master/ (último acceso, Abril, 2024). Mahmood, N. A.,Carmichael, W. W. yPfahler, D. Anticholinesterase poisonings in dogs from a cyanobacterial(blue-green algae) bloom dominated by anabaena flos-aquae. American journal of veterinary research, vol. 49(4), páginas 500–503, 1988. Mardan, A.,Mardan yCorrigan.Practical Node. js. Springer, 2018. Mehner, T. Encyclopedia of inland waters. Academic Press, 2009. Negri, A. P.,Jones, G. J. yHindmarsh, M. Sheep mortality associated with paralytic shellfish poisons from the cyanobacterium anabaena circinalis. Toxicon, vol. 33(10), páginas 1321–1329, 1995. Odriozola, E.,Ballabene, N. ySalamanco, A. Intoxicación en ganado bovino por algas verde-azuladas. Rev. argent. microbiol, páginas 219–24, 1984. Pybus, M.,Hobson, D. yOnderka, D. Mass mortality of bats due to probable blue-green algal toxicity. Journal of Wildlife Diseases, vol. 22(3), páginas 449–450, 1986. Python, A. Blender/python documentation. Blender Index, página 3, 2011. Risco-Martín, J. L.,Esteban, S.,Chacón, J.,Carazo-Barbero, G., Besada-Portas, E. yLópez-Orozco, J. A. Simulation-driven engineering for the management of harmful algal and cyanobacterial blooms. Simulation, vol. 99(10), páginas 1–15, 2023. Sharma, A.,Kosasih, E.,Zhang, J.,Brintrup, A. yCalinescu, A. Digital twins: State of the art theory and practice, challenges, and open research questions. Journal of Industrial Information Integration, vol. 30, 2022. ISSN 2452-414X.