Dashboard configurable para la gestión y administración de una instancia de OpenStack

En este documento está descrito detalladamente el trabajo realizado para completar todos objetivos marcados para este Trabajo de Fin de Grado, que tiene como meta final el desarrollo de un dashboard configurable de gestión y administración para instancias de OpenStack. OpenStack es una plataforma libre y de código abierto utilizada como solución de Infraestructura como Servicio (Infrastructure as a Service, IaaS) en clouds tanto públicos, que ofrecen sus servicios cobrando el tiempo de uso o los recursos utilizados, como privados para su utilización exclusiva en el entorno de una empresa. El proyecto OpenStack se inició como una colaboración entre la NASA y RackSpace, y a día de hoy es mantenido por las empresas más potentes del sector tecnológico a través de la Fundación OpenStack. La plataforma OpenStack permite el acceso a sus servicios a través de una Interfaz de Linea de Comandos (Command Line Interface, CLI), una API RESTful y una interfaz web en forma de dashboard. Esta última es ofrecida a través del servicio Horizon. Este servicio provee de una interfaz gráfica para acceder, gestionar y automatizar servicios basados en cloud. El dashboard de Horizon presente algunos problemas como que: solo admite opciones de configuración mediante código Python, lo que hace que el usuario no tenga ninguna capacidad de configuración y que el administrador esté obligado a interactuar directamente con el código. no tiene soporte para múltiples regiones que permitan que un usuario pueda distribuir sus recursos por distintos centros de datos en diversas localizaciones como más le convenga. El presente Trabajo de Fin de Grado, que es la fase inicial del proyecto FI-Dash, pretende solucionar estos problemas mediante el desarrollo de un catálogo de widget de la plataformaWireCloud que permitirán al usuario tener todas las funcionalidades ofrecidas por Horizon a la vez que le ofrecen capacidades de configuración y añaden funcionalidades no presentes en Horizon como el soporte de múltiples regiones. Como paso previo al desarrollo del catálogo de widgets se ha llevado a cabo un estudio de las tecnologías y servicios ofrecidos por OpenStack, así como de las herramientas que pudieran ser necesarias para la realización del trabajo. El proceso de desarrollo ha sido dividido en distintas fases de acuerdo con los distintos componentes que forman parte del dashboard cada uno con una funcion de gestion sobre un tipo de recurso distinto. Las otras fases del desarrollo han sido la integración completa del dashboard en la plataforma WireCloud y el diseño de una interfaz gráfica usable y atractiva.---ABSTRACT---Throughout this document it is described the work performed in order to achieve all of the objectives set for this Final Project, which has as its main goal the development of a configurable dashboard for managing and administrating OpenStack instances. OpenStack is a free and open source platform used as Infrastructure as a Service (IaaS) for both public clouds, which offer their services through payments on time or resources used, and private clouds for use only in the company’s environment. The OpenStack project started as a collaboration between NASA and Rackspace, and nowadays is maintained by the most powerful companies in the technology sector through the OpenStack Foundation. The OpenStack project provides access to its services through a Command Line Interface (CLI), a RESTful API and a web interface as dashboard. The latter is offered through a service called Horizon. This service provides a graphical interface to access, manage and automate cloud-based services. Horizon’s dashboard presents some problems such as: Only supports configuration options using Python code, which grants the user no configuration capabilities and forces the administrator to interact directly. No support for multiple regions that allow a user to allocate his resources by different data centers in different locations at his convenience. This Final Project, which is the initial stage of the FI-Dash project, aims to solve these problems by developing a catalog of widgets for the WireCloud platform that will allow the user to have all the features offered by Horizon while offering configuration capabilities and additional features not present in Horizon such as support for multiple regions. As a prelude to the development of the widget catalog, a study of technologies and services offered by OpenStack as well as tools that may be necessary to carry out the work has been conducted. The development process has been split in phases matching the different components that are part of the dashboard, having each one of them a function of management of one kind of resource. The other development phases have been the achieving of full integration with WireCloud and the design of a graphical interface that is both usable and atractive.

Utilización de métodos de visión artificial para PC como apoyo en la automoción

La detección de los bordes de líneas en la carretera es una parte muy importante en los sistemas inteligentes de transportación, así como la detección de objetos tal como vehículos, con la finalidad de informar o prevenir a través de una alerta al conductor o al sistema informático. De aquí nace el interés de analizar algunos métodos de visión artificial (VA) que es un subcampo de la inteligencia artificial, cuyo propósito es programar un computador y que este “entienda” una escena o imagen, algunos de los métodos más comunes en la detección de líneas y vehículos (considerados objetos en nuestra investigación) son la transformada de Hough, el método de Canny, clasificador Haar Cascade, filtros de Fourier, etc. Se desarrollará una aplicación de escritorio o PC (Personal Computer) para el reconocimiento de vehículos y las líneas de bordes, el lenguaje de programación utilizado será Python y la biblioteca OpenCV que contiene más de 500 funciones en el campo de visión por computador. La validación del reconocimiento de objetos se la realizará con una prueba de campo. Este resultado apoyará a la automoción (máquina que se desplaza por acción de un motor como el vehículo) con datos que luego pueden ser procesados.

Implementación de plug-ins para REAPER: módulo de reverberación convolutiva en tiempo real y sistema para la medición de respuestas acústicas en salas

Existen en el mercado numerosas aplicaciones para la generación de reverberación y para la medición de respuestas al impulso acústicas. Sin embargo, éstas son de precios muy elevados y/o no se permite acceder a su código y, mucho menos, distribuir de forma totalmente libre. Además, las herramientas que ofrecen para la medición de respuestas al impulso requieren de un tedioso proceso para la generación de la señal de excitación, su reproducción y grabación y, finalmente, su post-procesado. Este procedimiento puede llevar en ocasiones al usuario a cometer errores debido a la falta de conocimientos técnicos. El propósito de este proyecto es dar solución a algunos de los inconvenientes planteados. Con tal fin se llevó a cabo el desarrollo e implementación de un módulo de reverberación por convolución particionada en tiempo real, haciendo uso de software gratuito y de libre distribución. En concreto, se eligió la estación digital de trabajo (DAW. Digital Audio Worksation) REAPER de la compañía Cockos. Además de incluir las funcionalidades básicas de edición y secuenciación presentes en cualquier DAW, el programa incluye un entorno para la implementación de efectos de audio en lenguaje JS (Jesusonic), y se distribuye con licencias completamente gratuitas y sin limitaciones de uso. Complementariamente, se propone una extensión para REAPER que permite la medición de respuestas al impulso de recintos acústicos de una forma completamente automatizada y amigable para el usuario. Estas respuestas podrán ser almacenadas y posteriormente cargadas en el módulo de reverberación, permitiendo aplicar sobre nuestras pistas de audio la respuesta acústica de cualquier recinto en el que se hayan realizado medidas. La implementación del sistema de medida de respuestas se llevó a cabo empleando la herramienta ReaScript de REAPER, que permite la ejecución de pequeños scripts Python. El programa genera un Barrido Sinusoidal Logarítmico que excita el recinto acústico cuya respuesta se desea medir, grabando la misma en un archivo .wav. Este procedimiento es sencillo, intuitivo y está al alcance de cualquier usuario doméstico, ya que no requiere la utilización de sofisticado instrumental de medida. ABSTRACT. There are numerous applications in the market for the generation of reverb and measurement of acoustic impulse responses. However, they are usually very costly and closed source. In addition, the provided tools for measuring impulse responses require tedious processes for the generation and reproduction of the excitation signal, the recording of the response and its final post-processing. This procedure can sometimes drive the user to make mistakes due to the lack of technical knowledge. The purpose of this project is to solve some of the mentioned problems. To that end we developed and implemented a real-time partitioned convolution reverb module using free open source software. Specifically, the chosen software was the Cockos’ digital audio workstation (DAW) REAPER. In addition to the basic features included in any DAW, such as editing and sequencing, the program includes an environment for implementing audio effects in JS (Jesusonic) language of free distribution and features an unrestricted license. As an extension for REAPER, we propose a fully automated and user-friendly method for measuring rooms’ acoustic impulse responses. These will be stored and then loaded into the reverb module, allowing the user to apply the acoustical response of any room where measurement have been taken to any audio track. The implementation of the impulse response measurement system was done using REAPER’s ReaScript tool that allows the execution of small Python scripts. The program generates a logarithmic sine sweep that excites the room and its response is recorded in a .wav file. This procedure is simple, intuitive and it is accessible to any home user as it does not require the use of sophisticated measuring equipment.

Nepfix: on-demand cloud elastic simulation of networks of evolutionary processors

Una Red de Procesadores Evolutivos o NEP (por sus siglas en ingles), es un modelo computacional inspirado por el modelo evolutivo de las celulas, específicamente por las reglas de multiplicación de las mismas. Esta inspiración hace que el modelo sea una abstracción sintactica de la manipulation de information de las celulas. En particu¬lar, una NEP define una maquina de cómputo teorica capaz de resolver problemas NP completos de manera eficiente en tóerminos de tiempo. En la praóctica, se espera que las NEP simuladas en móaquinas computacionales convencionales puedan resolver prob¬lemas reales complejos (que requieran ser altamente escalables) a cambio de una alta complejidad espacial. En el modelo NEP, las cóelulas estóan representadas por palabras que codifican sus secuencias de ADN. Informalmente, en cualquier momento de cómputo del sistema, su estado evolutivo se describe como un coleccion de palabras, donde cada una de ellas representa una celula. Estos momentos fijos de evolucion se denominan configuraciones. De manera similar al modelo biologico, las palabras (celulas) mutan y se dividen en base a bio-operaciones sencillas, pero solo aquellas palabras aptas (como ocurre de forma parecida en proceso de selection natural) seran conservadas para la siguiente configuracióon. Una NEP como herramienta de computation, define una arquitectura paralela y distribuida de procesamiento simbolico, en otras palabras, una red de procesadores de lenguajes. Desde el momento en que el modelo fue propuesto a la comunidad científica en el año 2001, múltiples variantes se han desarrollado y sus propiedades respecto a la completitud computacional, eficiencia y universalidad han sido ampliamente estudiadas y demostradas. En la actualidad, por tanto, podemos considerar que el modelo teórico NEP se encuentra en el estadio de la madurez. La motivación principal de este Proyecto de Fin de Grado, es proponer una aproxi-mación práctica que permita dar un salto del modelo teórico NEP a una implantación real que permita su ejecucion en plataformas computacionales de alto rendimiento, con el fin de solucionar problemas complejos que demanda la sociedad actual. Hasta el momento, las herramientas desarrolladas para la simulation del modelo NEP, si bien correctas y con resultados satisfactorios, normalmente estón atadas a su entorno de ejecucion, ya sea el uso de hardware específico o implementaciones particulares de un problema. En este contexto, el propósito fundamental de este trabajo es el desarrollo de Nepfix, una herramienta generica y extensible para la ejecucion de cualquier algo¬ritmo de un modelo NEP (o alguna de sus variantes), ya sea de forma local, como una aplicación tradicional, o distribuida utilizando los servicios de la nube. Nepfix es una aplicacion software desarrollada durante 7 meses y que actualmente se encuentra en su segunda iteration, una vez abandonada la fase de prototipo. Nepfix ha sido disenada como una aplicacion modular escrita en Java 8 y autocontenida, es decir, no requiere de un entorno de ejecucion específico (cualquier maquina virtual de Java es un contenedor vólido). Nepfix contiene dos componentes o móodulos. El primer móodulo corresponde a la ejecución de una NEP y es por lo tanto, el simulador. Para su desarrollo, se ha tenido en cuenta el estado actual del modelo, es decir, las definiciones de los procesadores y filtros mas comunes que conforman la familia del modelo NEP. Adicionalmente, este componente ofrece flexibilidad en la ejecucion, pudiendo ampliar las capacidades del simulador sin modificar Nepfix, usando para ello un lenguaje de scripting. Dentro del desarrollo de este componente, tambióen se ha definido un estóandar de representacióon del modelo NEP basado en el formato JSON y se propone una forma de representation y codificación de las palabras, necesaria para la comunicación entre servidores. Adicional-mente, una característica importante de este componente, es que se puede considerar una aplicacion aislada y por tanto, la estrategia de distribution y ejecución son total-mente independientes. El segundo moódulo, corresponde a la distribucióon de Nepfix en la nube. Este de-sarrollo es el resultado de un proceso de i+D, que tiene una componente científica considerable. Vale la pena resaltar el desarrollo de este modulo no solo por los resul-tados prócticos esperados, sino por el proceso de investigation que se se debe abordar con esta nueva perspectiva para la ejecución de sistemas de computación natural. La principal característica de las aplicaciones que se ejecutan en la nube es que son gestionadas por la plataforma y normalmente se encapsulan en un contenedor. En el caso de Nepfix, este contenedor es una aplicacion Spring que utiliza el protocolo HTTP o AMQP para comunicarse con el resto de instancias. Como valor añadido, Nepfix aborda dos perspectivas de implementation distintas (que han sido desarrolladas en dos iteraciones diferentes) del modelo de distribution y ejecucion, que tienen un impacto muy significativo en las capacidades y restricciones del simulador. En concreto, la primera iteration utiliza un modelo de ejecucion asincrono. En esta perspectiva asincrona, los componentes de la red NEP (procesadores y filtros) son considerados como elementos reactivos a la necesidad de procesar una palabra. Esta implementation es una optimization de una topologia comun en el modelo NEP que permite utilizar herramientas de la nube para lograr un escalado transparente (en lo ref¬erente al balance de carga entre procesadores) pero produce efectos no deseados como indeterminacion en el orden de los resultados o imposibilidad de distribuir eficiente-mente redes fuertemente interconectadas. Por otro lado, la segunda iteration corresponde al modelo de ejecucion sincrono. Los elementos de una red NEP siguen un ciclo inicio-computo-sincronizacion hasta que el problema se ha resuelto. Esta perspectiva sincrona representa fielmente al modelo teórico NEP pero el proceso de sincronizacion es costoso y requiere de infraestructura adicional. En concreto, se requiere un servidor de colas de mensajes RabbitMQ. Sin embargo, en esta perspectiva los beneficios para problemas suficientemente grandes superan a los inconvenientes, ya que la distribuciín es inmediata (no hay restricciones), aunque el proceso de escalado no es trivial. En definitiva, el concepto de Nepfix como marco computacional se puede considerar satisfactorio: la tecnología es viable y los primeros resultados confirman que las carac-terísticas que se buscaban originalmente se han conseguido. Muchos frentes quedan abiertos para futuras investigaciones. En este documento se proponen algunas aproxi-maciones a la solucion de los problemas identificados como la recuperacion de errores y la division dinamica de una NEP en diferentes subdominios. Por otra parte, otros prob-lemas, lejos del alcance de este proyecto, quedan abiertos a un futuro desarrollo como por ejemplo, la estandarización de la representación de las palabras y optimizaciones en la ejecucion del modelo síncrono. Finalmente, algunos resultados preliminares de este Proyecto de Fin de Grado han sido presentados recientemente en formato de artículo científico en la "International Work-Conference on Artificial Neural Networks (IWANN)-2015" y publicados en "Ad-vances in Computational Intelligence" volumen 9094 de "Lecture Notes in Computer Science" de Springer International Publishing. Lo anterior, es una confirmation de que este trabajo mas que un Proyecto de Fin de Grado, es solo el inicio de un trabajo que puede tener mayor repercusion en la comunidad científica. Abstract Network of Evolutionary Processors -NEP is a computational model inspired by the evolution of cell populations, which might model some properties of evolving cell communities at the syntactical level. NEP defines theoretical computing devices able to solve NP complete problems in an efficient manner. In this model, cells are represented by words which encode their DNA sequences. Informally, at any moment of time, the evolutionary system is described by a collection of words, where each word represents one cell. Cells belong to species and their community evolves according to mutations and division which are defined by operations on words. Only those cells are accepted as surviving (correct) ones which are represented by a word in a given set of words, called the genotype space of the species. This feature is analogous with the natural process of evolution. Formally, NEP is based on an architecture for parallel and distributed processing, in other words, a network of language processors. Since the date when NEP was pro¬posed, several extensions and variants have appeared engendering a new set of models named Networks of Bio-inspired Processors (NBP). During this time, several works have proved the computational power of NBP. Specifically, their efficiency, universality, and computational completeness have been thoroughly investigated. Therefore, we can say that the NEP model has reached its maturity. The main motivation for this End of Grade project (EOG project in short) is to propose a practical approximation that allows to close the gap between theoretical NEP model and a practical implementation in high performing computational platforms in order to solve some of high the high complexity problems society requires today. Up until now tools developed to simulate NEPs, while correct and successful, are usu¬ally tightly coupled to the execution environment, using specific software frameworks (Hadoop) or direct hardware usage (GPUs). Within this context the main purpose of this work is the development of Nepfix, a generic and extensible tool that aims to execute algorithms based on NEP model and compatible variants in a local way, similar to a traditional application or in a distributed cloud environment. Nepfix as an application was developed during a 7 month cycle and is undergoing its second iteration once the prototype period was abandoned. Nepfix is designed as a modular self-contained application written in Java 8, that is, no additional external dependencies are required and it does not rely on an specific execution environment, any JVM is a valid container. Nepfix is made of two components or modules. The first module corresponds to the NEP execution and therefore simulation. During the development the current state of the theoretical model was used as a reference including most common filters and processors. Additionally extensibility is provided by the use of Python as a scripting language to run custom logic. Along with the simulation a definition language for NEP has been defined based on JSON as well as a mechanisms to represent words and their possible manipulations. NEP simulator is isolated from distribution and as mentioned before different applications that include it as a dependency are possible, the distribution of NEPs is an example of this. The second module corresponds to executing Nepfix in the cloud. The development carried a heavy R&D process since this front was not explored by other research groups until now. It's important to point out that the development of this module is not focused on results at this point in time, instead we focus on feasibility and discovery of this new perspective to execute natural computing systems and NEPs specifically. The main properties of cloud applications is that they are managed by the platform and are encapsulated in a container. For Nepfix a Spring application becomes the container and the HTTP or AMQP protocols are used for communication with the rest of the instances. Different execution perspectives were studied, namely asynchronous and synchronous models were developed for solving different kind of problems using NEPs. Different limitations and restrictions manifest in both models and are explored in detail in the respective chapters. In conclusion we can consider that Nepfix as a computational framework is suc-cessful: Cloud technology is ready for the challenge and the first results reassure that the properties Nepfix project pursued were met. Many investigation branches are left open for future investigations. In this EOG implementation guidelines are proposed for some of them like error recovery or dynamic NEP splitting. On the other hand other interesting problems that were not in the scope of this project were identified during development like word representation standardization or NEP model optimizations. As a confirmation that the results of this work can be useful to the scientific com-munity a preliminary version of this project was published in The International Work- Conference on Artificial Neural Networks (IWANN) in May 2015. Development has not stopped since that point and while Nepfix in it's current state can not be consid¬ered a final product the most relevant ideas, possible problems and solutions that were produced during the seven months development cycle are worthy to be gathered and presented giving a meaning to this EOG work.

Sistema domótico controlado por mensajería instantánea Whatsapp para personas con discapacidad

El presente PFC tiene como objetivo el desarrollo de un gestor domótico basado en el dictado de voz de la red social WhatsApp. Dicho gestor no solo sustituirá el concepto dañino de que la integración de la domótica hoy en día es cara e inservible sino que acercará a aquellas personas con una discapacidad a tener una mejora en la calidad de vida. Estas personas, con un simple comando de voz a su aplicación WhatsApp de su terminal móvil, podrán activar o desactivar todos los elementos domóticos que su vivienda tenga instalados, “activar lámpara”, “encender Horno”, “abrir Puerta”… Todo a un muy bajo precio y utilizando tecnologías OpenSource El objetivo principal de este PFC es ayudar a la gente con una discapacidad a tener mejor calidad de vida, haciéndose independiente en las labores del hogar, ya que será el hogar quien haga las labores. La accesibilidad de este servicio, es por tanto, la mayor de las metas. Para conseguir accesibilidad para todas las personas, se necesita un servicio barato y de fácil aprendizaje. Se elige la red social WhatsApp como interprete, ya que no necesita de formación al ser una aplicación usada mayoritariamente en España y por la capacidad del dictado de voz, y se eligen las tecnologías OpenSource por ser la gran mayoría de ellas gratuitas o de pago solo el hardware. La utilización de la Red social WhatsApp se justifica por sí sola, en septiembre de 2015 se registraron 900 millones de usuarios. Este dato es fruto, también, de la reciente adquisición por parte de Facebook y hace que cumpla el primer requisito de accesibilidad para el servicio domotico que se presenta. Desde hace casi 5 años existe una API liberada de WhatsApp, que la comunidad OpenSource ha utilizado, para crear sus propios clientes o aplicaciones de envío de mensajes, usando la infraestructura de la red social. La empresa no lo aprueba abiertamente, pero la liberación de la API fue legal y su uso también lo es. Por otra parte la empresa se reserva el derecho de bloquear cuentas por el uso fraudulento de su infraestructura. Las tecnologías OpenSource utilizadas han sido, distribuciones Linux (Raspbian) y lenguajes de programación PHP, Python y BASHSCRIPT, todo cubierto por la comunidad, ofreciendo soporte y escalabilidad. Es por ello que se utiliza, como matriz y gestor domotico central, una RaspberryPI. Los servicios que el gestor ofrece en su primera versión incluyen el control domotico de la iluminación eléctrica general o personal, el control de todo tipo de electrodomésticos, el control de accesos para la puerta principal de entrada y el control de medios audiovisuales. ABSTRACT. This final thesis aims to develop a domotic manager based on the speech recognition capacity implemented in the social network, WhatsApp. This Manager not only banish the wrong idea about how expensive and useless is a domotic installation, this manager will give an opportunity to handicapped people to improve their quality of life. These people, with a simple voice command to their own WhatsApp, could enable or disable all the domotics devices installed in their living places. “On Lamp”, “ON Oven”, “Open Door”… This service reduce considerably the budgets because the use of OpenSource Technologies. The main achievement of this thesis is help handicapped people improving their quality of life, making independent from the housework. The house will do the work. The accessibility is, by the way, the goal to achieve. To get accessibility to a width range, we need a cheap, easy to learn and easy to use service. The social Network WhatsApp is one part of the answer, this app does not need explanation because is used all over the world, moreover, integrates the speech recognition capacity. The OpenSource technologies is the other part of the answer due to the low costs or, even, the free costs of their implementations. The use of the social network WhatsApp is explained by itself. In September 2015 were registered around 900 million users, of course, the recent acquisition by Facebook has helped in this astronomic number and match the first law of this service about the accessibility. Since five years exists, in the internet, a free WhatsApp API. The OpenSource community has used this API to develop their own messaging apps or desktop-clients, using the WhatsApp infrastructure. The company does not approve officially, however le API freedom is legal and the use of the API is legal too. On the other hand, the company can block accounts who makes a fraudulent use of his infrastructure. OpenSource technologies used in this thesis are: Linux distributions (Raspbian) and programming languages PHP, Python and BASHCSRIPT, all of these technologies are covered by the community offering support and scalability. Due to that, it is used a RaspberryPI as the Central Domotic Manager. The domotic services that currently this manager achieve are: Domotic lighting control, electronic devices control, access control to the main door and Media Control.

Desarrollo de una aplicación web para la reducción de ruido del sonido grabado de un disco de vinilo

Las grabaciones digitales de discos de vinilo, al ser un medio de almacenamiento de sonido analógico, están afectadas por ruido de diversos tipos, debido al deterioro de la superficie con el tiempo y con su reproducción. Aunque algunos programas de edición de audio permiten hacer una reducción de ruido sobre esas grabaciones, muchos consumidores de música en vinilo los desconocen, encuentran complicado su uso o quieren evitar la instalación de programas adicionales en su ordenador. Este proyecto consiste en el desarrollo de una aplicación web que pretende acabar con estos impedimentos y ofrecer un medio sencillo y eficaz para la reducción de ruido, ejecutable a través de un navegador, que simplifique el proceso de cara al usuario. El funcionamiento es sencillo: un usuario sube un archivo de audio al servidor, éste lo procesa y lo devuelve al cliente. El servidor, en la fase de procesamiento de señal, realiza una reducción de ruido mediante una puerta de ruido en el dominio de la frecuencia, desarrollada en lenguaje Python, y diseñada en función de un estudio previo de diversas muestras de ruido. En el proyecto se pueden distinguir tres bloques: la caracterización del ruido que afecta a grabaciones de discos de vinilo, el desarrollo de un algoritmo que realice la reducción de ruido correspondiente y el desarrollo de la aplicación web. En este documento se recogen los fundamentos de cada uno de los bloques, tratando de resumir las bases de su funcionamiento y de justificar cada una de las decisiones tomadas, como la tecnología empleada, el valor de algunos parámetros, la estructura del código o los pasos seguidos en cada algoritmo.

Spatial network surrogates for disentangling complex system structure from spatial embedding of nodes

ACKNOWLEDGMENTS MW and RVD have been supported by the German Federal Ministry for Education and Research (BMBF) via the Young Investigators Group CoSy-CC2 (grant no. 01LN1306A). JFD thanks the Stordalen Foundation and BMBF (project GLUES) for financial support. JK acknowledges the IRTG 1740 funded by DFG and FAPESP. MT Gastner is acknowledged for providing his data on the airline, interstate, and Internet network. P Menck thankfully provided his data on the Scandinavian power grid. We thank S Willner on behalf of the entire zeean team for providing the data on the world trade network. All computations have been performed using the Python package pyunicorn [41] that is available at https://github.com/pik-copan/pyunicorn.

Gene content phylogeny of herpesviruses

Clusters of orthologous groups [COGs; Tatusov, R. L., Koonin, E. V. & Lipman, D. J. (1997) Science 278, 631–637] were identified for a set of 13 completely sequenced herpesviruses. Each COG represented a family of gene products conserved across several herpes genomes. These families were defined without using an arbitrary threshold criterion based on sequence similarity. The COG technique was modified so that variable stringency in COG construction was possible. High stringencies identify a core set of highly conserved genes. Varying COG stringency reveals differences in the degree of conservation between functional classes of genes. The COG data were used to construct whole-genome phylogenetic trees based on gene content. These trees agree well with trees based on other methods and are robust when tested by bootstrap analysis. The COG data also were used to construct a reciprocal tree that clustered genes with similar phylogenetic profiles. This clustering may give clues to genes with related functions or with related histories of acquisition and loss during herpesvirus evolution.

Compact stellarators with modular coils

Compact stellarator designs with modular coils and only two or three field periods are now available; these designs have both good stability and quasiaxial symmetry providing adequate transport for a magnetic fusion reactor. If the bootstrap current assumes theoretically predicted values a three field period configuration is optimal, but if that net current turns out to be lower, a device with two periods and just 12 modular coils might be better. There are also attractive designs with quasihelical symmetry and four or five periods whose properties depend less on the bootstrap current. Good performance requires that there be a satisfactory magnetic well in the vacuum field, which is a property lacking in a stellarator-tokamak hybrid that has been proposed for a proof of principle experiment. In this paper, we present an analysis of stability for these configurations that is based on a mountain pass theorem asserting that, if two solutions of the problem of magnetohydrodynamic equilibrium can be found, then there has to be an unstable solution. We compare results of our theory of equilibrium, stability, and transport with recently announced measurements from the large LHD experiment in Japan.

Phylogenetic relationships among group II intron ORFs

Group II introns are widely believed to have been ancestors of spliceosomal introns, yet little is known about their own evolutionary history. In order to address the evolution of mobile group II introns, we have compiled 71 open reading frames (ORFs) related to group II intron reverse transcriptases and subjected their derived amino acid sequences to phylogenetic analysis. The phylogenetic tree was rooted with reverse transcriptases (RTs) of non-long terminal repeat retroelements, and the inferred phylogeny reveals two major clusters which we term the mitochondrial and chloroplast-like lineages. Bacterial ORFs are mainly positioned at the bases of the two lineages but with weak bootstrap support. The data give an overview of an apparently high degree of horizontal transfer of group II intron ORFs, mostly among related organisms but also between organelles and bacteria. The Zn domain (nuclease) and YADD motif (RT active site) were lost multiple times during evolution. Differences in domain structures suggest that the oldest ORFs were concise, while the ORF in the mitochondrial lineage subsequently expanded in three locations. The data are consistent with a bacterial origin for mobile group II introns.

On the origin of and phylogenetic relationships among living amphibians

The phylogenetic relationships among the three orders of modern amphibians (Caudata, Gymnophiona, and Anura) have been estimated based on both morphological and molecular evidence. Most morphological and paleontological studies of living and fossil amphibians support the hypothesis that salamanders and frogs are sister lineages (the Batrachia hypothesis) and that caecilians are more distantly related. Previous interpretations of molecular data based on nuclear and mitochondrial rRNA sequences suggested that salamanders and caecilians are sister groups to the exclusion of frogs. In an attempt to resolve this apparent conflict, the complete mitochondrial genomes of a salamander (Mertensiella luschani) and a caecilian (Typhlonectes natans) were determined (16,656 and 17,005 bp, respectively) and compared with previously published sequences from a frog (Xenopus laevis) and several other groups of vertebrates. Phylogenetic analyses of the mitochondrial data supported with high bootstrap values the monophyly of living amphibians with respect to other living groups of tetrapods, and a sister group relationship of salamanders and frogs. The lack of phylogenetically informative sites in the previous rRNA data sets (because of its shorter size and higher among-site rate variation) likely explains the discrepancy between our results and those based on previous molecular data. Strong support of the Batrachia hypothesis from both molecule- and morphology-based studies provides a robust phylogenetic framework that will be helpful to comparative studies among the three living orders of amphibians and will permit better understanding of the considerably divergent vertebral, brain, and digit developmental patterns found in frogs and salamanders.

Perspectives on archaeal diversity, thermophily and monophyly from environmental rRNA sequences.

Phylogenetic analysis of ribosomal RNA sequences obtained from uncultivated organisms of a hot spring in Yellowstone National Park reveals several novel groups of Archaea, many of which diverged from the crenarchaeal line of descent prior to previously characterized members of that kingdom. Universal phylogenetic trees constructed with the addition of these sequences indicate monophyly of Archaea, with modest bootstrap support. The data also show a specific relationship between low-temperature marine Archaea and some hot spring Archaea. Two of the environmental sequences are enigmatic: depending upon the data set and analytical method used, these sequences branch deeply within the Crenarchaeota, below the bifurcation between Crenarchaeota and Euryarchaeota, or even as the sister group to Eukaryotes. If additional data confirm either of the latter two placements, then the organisms represented by these ribosomal RNA sequences would merit recognition as a new kingdom, provisionally named "Korarchaeota."

The root of the universal tree and the origin of eukaryotes based on elongation factor phylogeny.

The genes for the protein synthesis elongation factors Tu (EF-Tu) and G (EF-G) are the products of an ancient gene duplication, which appears to predate the divergence of all extant organismal lineages. Thus, it should be possible to root a universal phylogeny based on either protein using the second protein as an outgroup. This approach was originally taken independently with two separate gene duplication pairs, (i) the regulatory and catalytic subunits of the proton ATPases and (ii) the protein synthesis elongation factors EF-Tu and EF-G. Questions about the orthology of the ATPase genes have obscured the former results, and the elongation factor data have been criticized for inadequate taxonomic representation and alignment errors. We have expanded the latter analysis using a broad representation of taxa from all three domains of life. All phylogenetic methods used strongly place the root of the universal tree between two highly distinct groups, the archaeons/eukaryotes and the eubacteria. We also find that a combined data set of EF-Tu and EF-G sequences favors placement of the eukaryotes within the Archaea, as the sister group to the Crenarchaeota. This relationship is supported by bootstrap values of 60-89% with various distance and maximum likelihood methods, while unweighted parsimony gives 58% support for archaeal monophyly.

Randomness and degrees of irregularity.

The fundamental question "Are sequential data random?" arises in myriad contexts, often with severe data length constraints. Furthermore, there is frequently a critical need to delineate nonrandom sequences in terms of closeness to randomness--e.g., to evaluate the efficacy of therapy in medicine. We address both these issues from a computable framework via a quantification of regularity. ApEn (approximate entropy), defining maximal randomness for sequences of arbitrary length, indicating the applicability to sequences as short as N = 5 points. An infinite sequence formulation of randomness is introduced that retains the operational (and computable) features of the finite case. In the infinite sequence setting, we indicate how the "foundational" definition of independence in probability theory, and the definition of normality in number theory, reduce to limit theorems without rates of convergence, from which we utilize ApEn to address rates of convergence (of a deficit from maximal randomness), refining the aforementioned concepts in a computationally essential manner. Representative applications among many are indicated to assess (i) random number generation output; (ii) well-shuffled arrangements; and (iii) (the quality of) bootstrap replicates.

Calculating the probability of multitaxon evolutionary trees: bootstrappers Gambit.

The reconstruction of multitaxon trees from molecular sequences is confounded by the variety of algorithms and criteria used to evaluate trees, making it difficult to compare the results of different analyses. A global method of multitaxon phylogenetic reconstruction described here, Bootstrappers Gambit, can be used with any four-taxon algorithm, including distance, maximum likelihood, and parsimony methods. It incorporates a Bayesian-Jeffreys'-bootstrap analysis to provide a uniform probability-based criterion for comparing the results from diverse algorithms. To examine the usefulness of the method, the origin of the eukaryotes has been investigated by the analysis of ribosomal small subunit RNA sequences. Three common algorithms (paralinear distances, Jukes-Cantor distances, and Kimura distances) support the eocyte topology, whereas one (maximum parsimony) supports the archaebacterial topology, suggesting that the eocyte prokaryotes are the closest prokaryotic relatives of the eukaryotes.