Zooplankton abundance and size structure in the North Atlantic from MSM26_127-13

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Metadata und statistic analysis of archael and bacterial sequences originating from sediments of the Håkon Mosby mud volcano (Z1-Z3, all habitats)

DNA extraction was carried out as described on the MICROBIS project pages (http://icomm.mbl.edu/microbis ) using a commercially available extraction kit. We amplified the hypervariable regions V4-V6 of archaeal and bacterial 16S rRNA genes using PCR and several sets of forward and reverse primers (http://vamps.mbl.edu/resources/primers.php). Massively parallel tag sequencing of the PCR products was carried out on a 454 Life Sciences GS FLX sequencer at Marine Biological Laboratory, Woods Hole, MA, following the same experimental conditions for all samples. Sequence reads were submitted to a rigorous quality control procedure based on mothur v30 (doi:10.1128/AEM.01541-09) including denoising of the flow grams using an algorithm based on PyroNoise (doi:10.1038/nmeth.1361), removal of PCR errors and a chimera check using uchime (doi:10.1093/bioinformatics/btr381). The reads were taxonomically assigned according to the SILVA taxonomy (SSURef v119, 07-2014; doi:10.1093/nar/gks1219) implemented in mothur and clustered at 98% ribosomal RNA gene V4-V6 sequence identity. V4-V6 amplicon sequence abundance tables were standardized to account for unequal sampling effort using 1000 (Archaea) and 2300 (Bacteria) randomly chosen sequences without replacement using mothur and then used to calculate inverse Simpson diversity indices and Chao1 richness (doi:10.2307/4615964). Bray-Curtis dissimilarities (doi:10.2307/1942268) between all samples were calculated and used for 2-dimensional non metric multidimensional scaling (NMDS) ordinations with 20 random starts (doi:10.1007/BF02289694). Stress values below 0.2 indicated that the multidimensional dataset was well represented by the 2D ordination. NMDS ordinations were compared and tested using Procrustes correlation analysis (doi:10.1007/BF02291478). All analyses were carried out with the R statistical environment and the packages vegan (available at: http://cran.r-project.org/package=vegan), labdsv (available at: http://cran.r-project.org/package=labdsv), as well as with custom R scripts. Operational taxonomic units at 98% sequence identity (OTU0.03) that occurred only once in the whole dataset were termed absolute single sequence OTUs (SSOabs; doi:10.1038/ismej.2011.132). OTU0.03 sequences that occurred only once in at least one sample, but may occur more often in other samples were termed relative single sequence OTUs (SSOrel). SSOrel are particularly interesting for community ecology, since they comprise rare organisms that might become abundant when conditions change.16S rRNA amplicons and metagenomic reads have been stored in the sequence read archive under SRA project accession number SRP042162.

Zooplankton abundance and size structure in the North Atlantic from MSM26_126-10

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_133-7

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_137-17

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_131-4

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_135-10

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Píldoras formativas y videojuegos aplicados al estudio de la Ingeniería Acústica

Las TIC cada vez tienen un mayor impacto social en el mundo de la enseñanza a distancia, están surgiendo nuevos conceptos relacionados con la forma de llevar el aprendizaje a las personas. La generación de contenidos supone una práctica costosa en tiempo, recursos y personas, es por eso la tendencia a que sean reutilizables, accesibles, portables y durables. Es aquí donde toman su importancia las píldoras formativas o de conocimiento, estando asociadas a un concepto y con una duración entre 5 y 15 minutos. Este trabajo pretende desarrollar píldoras formativas a modo de videos de corta duración sobre conceptos acústicos y guiones de prácticas de laboratorio tratados a lo largo del máster. Se desarrollará también a modo de videojuego el guión de una de las prácticas sirviendo como complemento a los videos. El trabajo se divide en dos partes bien diferenciadas, una de estudio teórico tanto de la tecnología para el desarrollo de los videos, que servirá de guía para futuras píldoras, como del contenido de éstos, y otra parte que tratará la implementación y adaptación de los videos y de los videojuegos. SUMMARY ICTs are becoming a greater social impact in the world of distance learning are emerging concepts related to learning how to take people. Content generation is a costly exercise in time, resources and people, is why the tendency to be reusable, accessible, portable and durable. This is where the importance of taking pills training or knowledge, being associated with a concept and with a duration between 5 and 15 minutes. This work aims to develop training pills as a short videos on concepts and scripts acoustic laboratory practices discussed during the Master. Also be developed as a script for a game of serving practices to supplement the videos. The work is divided into two distinct parts, a theoretical study of both the technology for the development of the videos, which will guide future pills, and the content of these, and another part that will address the implementation and adaptation of the videos and of video games.

Multi-microphone recordings (EigenMike32) inside a WFS system (Iosono) through Ambisonics techniques using Matlab

El audio multicanal ha avanzado a pasos agigantados en los últimos años, y no solo en las técnicas de reproducción, sino que en las de capitación también. Por eso en este proyecto se encuentran ambas cosas: un array microfónico, EigenMike32 de MH Acoustics, y un sistema de reproducción con tecnología Wave Field Synthesis, instalado Iosono en la Jade Höchscule Oldenburg. Para enlazar estos dos puntos de la cadena de audio se proponen dos tipos distintos de codificación: la reproducción de la toma horizontal del EigenMike32; y el 3er orden de Ambisonics (High Order Ambisonics, HOA), una técnica de codificación basada en Armónicos Esféricos mediante la cual se simula el campo acústico en vez de simular las distintas fuentes. Ambas se desarrollaron en el entorno Matlab y apoyadas por la colección de scripts de Isophonics llamada Spatial Audio Matlab Toolbox. Para probar éstas se llevaron a cabo una serie de test en los que se las comparó con las grabaciones realizadas a la vez con un Dummy Head, a la que se supone el método más aproximado a nuestro modo de escucha. Estas pruebas incluían otras grabaciones hechas con un Doble MS de Schoeps que se explican en el proyecto “Sally”. La forma de realizar éstas fue, una batería de 4 audios repetida 4 veces para cada una de las situaciones garbadas (una conversación, una clase, una calle y un comedor universitario). Los resultados fueron inesperados, ya que la codificación del tercer orden de HOA quedo por debajo de la valoración Buena, posiblemente debido a la introducción de material hecho para un array tridimensional dentro de uno de 2 dimensiones. Por el otro lado, la codificación que consistía en extraer los micrófonos del plano horizontal se mantuvo en el nivel de Buena en todas las situaciones. Se concluye que HOA debe seguir siendo probado con mayores conocimientos sobre Armónicos Esféricos; mientras que el otro codificador, mucho más sencillo, puede ser usado para situaciones sin mucha complejidad en cuanto a espacialidad. In the last years the multichannel audio has increased in leaps and bounds and not only in the playback techniques, but also in the recording ones. That is the reason of both things being in this project: a microphone array, EigenMike32 from MH Acoustics; and a playback system with Wave Field Synthesis technology, installed by Iosono in Jade Höchscule Oldenburg. To link these two points of the audio chain, 2 different kinds of codification are proposed: the reproduction of the EigenMike32´s horizontal take, and the Ambisonics´ third order (High Order Ambisonics, HOA), a codification technique based in Spherical Harmonics through which the acoustic field is simulated instead of the different sound sources. Both have been developed inside Matlab´s environment and supported by the Isophonics´ scripts collection called Spatial Audio Matlab Toolbox. To test these, a serial of tests were made in which they were compared with recordings made at the time by a Dummy Head, which is supposed to be the closest method to our hearing way. These tests included other recording and codifications made by a Double MS (DMS) from Schoeps which are explained in the project named “3D audio rendering through Ambisonics techniques: from multi-microphone recordings (DMS Schoeps) to a WFS system, through Matlab”. The way to perform the tests was, a collection made of 4 audios repeated 4 times for each recorded situation (a chat, a class, a street and college canteen or Mensa). The results were unexpected, because the HOA´s third order stood under the Well valuation, possibly caused by introducing material made for a tridimensional array inside one made only by 2 dimensions. On the other hand, the codification that consisted of extracting the horizontal plane microphones kept the Well valuation in all the situations. It is concluded that HOA should keep being tested with larger knowledge about Spherical Harmonics; while the other coder, quite simpler, can be used for situations without a lot of complexity with regards to spatiality.

Distributed www programming using (Ciao-) prolog and the pillow library

We discuss from a practical point of view a number of ssues involved in writing distributed Internet and WWW applications using LP/CLP systems. We describe PiLLoW, a publicdomain Internet and WWW programming library for LP/CLP systems that we have designed in order to simplify the process of writing such applications. PiLLoW provides facilities for accessing documents and code on the WWW; parsing, manipulating and generating HTML and XML structured documents and data; producing HTML forms; writing form handlers and CGI-scripts; and processing HTML/XML templates. An important contribution of PÍ'LLOW is to model HTML/XML code (and, thus, the content of WWW pages) as terms. The PÍ'LLOW library has been developed in the context of the Ciao Prolog system, but it has been adapted to a number of popular LP/CLP systems, supporting most of its functionality. We also describe the use of concurrency and a highlevel model of client-server interaction, Ciao Prolog's active modules, in the context of WWW programming. We propose a solution for client-side downloading and execution of Prolog code, using generic browsers. Finally, we also provide an overview of related work on the topic.

A documentation generator for (C)LP systems

We describe lpdoc, a tool which generates documentation manuals automatically from one or more logic program source files, written in Ciao, ISO-Prolog, and other (C)LP languages. It is particularly useful for documenting library modules, for which it automatically generates a rich description of the module interface. However, it can also be used quite successfully to document full applications. A fundamental advantage of using lpdoc is that it helps maintaining a true correspondence between the program and its documentation, and also identifying precisely to what versión of the program a given printed manual corresponds. The quality of the documentation generated can be greatly enhanced by including within the program text assertions (declarations with types, modes, etc. ...) for the predicates in the program, and machine-readable comments. One of the main novelties of lpdoc is that these assertions and comments are written using the Ciao system asseriion language, which is also the language of communication between the compiler and the user and between the components of the compiler. This allows a significant synergy among specification, debugging, documentation, optimization, etc. A simple compatibility library allows conventional (C)LP systems to ignore these assertions and comments and treat normally programs documented in this way. The documentation can be generated interactively from emacs or from the command line, in many formats including texinfo, dvi, ps, pdf, info, ascii, html/css, Unix nroff/man, Windows help, etc., and can include bibliographic citations and images, lpdoc can also genérate "man" pages (Unix man page format), nicely formatted plain ASCII "readme" files, installation scripts useful when the manuals are included in software distributions, brief descriptions in html/css or info formats suitable for inclusión in on-line Índices of manuals, and even complete WWW and info sites containing on-line catalogs of documents and software distributions. The lpdoc manual, all other Ciao system manuals, and parts of this paper are generated by lpdoc.

A system for automatically generating documentation for (C)LP programs

We describe lpdoc, a tool which generates documentation manuals automatically from one or more logic program source files, written in ISO-Prolog, Ciao, and other (C)LP languages. It is particularly useful for documenting library modules, for which it automatically generates a rich description of the module interface. However, it can also be used quite successfully to document full applications. A fundamental advantage of using lpdoc is that it helps maintaining a true correspondence between the program and its documentation, and also identifying precisely to what version of the program a given printed manual corresponds. The quality of the documentation generated can be greatly enhanced by including within the program text assertions (declarations with types, modes, etc.) for the predicates in the program, and machine-readable comments. One of the main novelties of lpdoc is that these assertions and comments are written using the Ciao system assertion language, which is also the language of communication between the compiler and the user and between the components of the compiler. This allows a significant synergy among specification, documentation, optimization, etc. A simple compatibility library allows conventional (C)LP systems to ignore these assertions and comments and treat normally programs documented in this way. The documentation can be generated in many formats including texinfo, dvi, ps, pdf, info, html/css, Unix nroff/man, Windows help, etc., and can include bibliographic citations and images. lpdoc can also generate “man” pages (Unix man page format), nicely formatted plain ascii “readme” files, installation scripts useful when the manuals are included in software distributions, brief descriptions in html/css or info formats suitable for inclusion in on-line indices of manuals, and even complete WWW and info sites containing on-line catalogs of documents and software distributions. The lpdoc manual, all other Ciao system manuals, and parts of this paper are generated by lpdoc.

A documentation generator for logic programming systems

We describe lpdoc, a tool which generates documentation manuals automatically from one or more logic program source files, written in ISO-Prolog, Ciao, and other (C)LP languages. It is particularly useful for documenting library modules, for which it automatically generates a rich description of the module interface. However, it can also be used quite successfully to document full applications. The documentation can be generated in many formats including t e x i n f o, dvi, ps, pdf, inf o, html/css, Unix nrof f/man, Windows help, etc., and can include bibliographic citations and images, lpdoc can also genérate "man" pages (Unix man page format), nicely formatted plain ascii "readme" files, installation scripts useful when the manuals are included in software distributions, brief descriptions in html/css or inf o formats suitable for inclusión in on-line Índices of manuals, and even complete WWW and inf o sites containing on-line catalogs of documents and software distributions. A fundamental advantage of using lpdoc is that it helps maintaining a true correspondence between the program and its documentation, and also identifying precisely to what versión of the program a given printed manual corresponds. The quality of the documentation generated can be greatly enhanced by including within the program text assertions (declarations with types, modes, etc. ...) for the predicates in the program, and machine-readable comments. These assertions and comments are written using the Ciao system assertion language. A simple compatibility library allows conventional (C)LP systems to ignore these assertions and comments and treat normally programs documented in this way. The lpdoc manual, all other Ciao system manuals, and most of this paper, are generated by lpdoc.

The ciao prolog system

Ciao is a public domain, next generation multi-paradigm programming environment with a unique set of features: Ciao offers a complete Prolog system, supporting ISO-Prolog, but its novel modular design allows both restricting and extending the language. As a result, it allows working with fully declarative subsets of Prolog and also to extend these subsets (or ISO-Prolog) both syntactically and semantically. Most importantly, these restrictions and extensions can be activated separately on each program module so that several extensions can coexist in the same application for different modules. Ciao also supports (through such extensions) programming with functions, higher-order (with predicate abstractions), constraints, and objects, as well as feature terms (records), persistence, several control rules (breadth-first search, iterative deepening, ...), concurrency (threads/engines), a good base for distributed execution (agents), and parallel execution. Libraries also support WWW programming, sockets, external interfaces (C, Java, TclTk, relational databases, etc.), etc. Ciao offers support for programming in the large with a robust module/object system, module-based separate/incremental compilation (automatically -no need for makefiles), an assertion language for declaring (optional) program properties (including types and modes, but also determinacy, non-failure, cost, etc.), automatic static inference and static/dynamic checking of such assertions, etc. Ciao also offers support for programming in the small producing small executables (including only those builtins used by the program) and support for writing scripts in Prolog. The Ciao programming environment includes a classical top-level and a rich emacs interface with an embeddable source-level debugger and a number of execution visualization tools. The Ciao compiler (which can be run outside the top level shell) generates several forms of architecture-independent and stand-alone executables, which run with speed, efficiency and executable size which are very competive with other commercial and academic Prolog/CLP systems. Library modules can be compiled into compact bytecode or C source files, and linked statically, dynamically, or autoloaded. The novel modular design of Ciao enables, in addition to modular program development, effective global program analysis and static debugging and optimization via source to source program transformation. These tasks are performed by the Ciao preprocessor ( ciaopp, distributed separately). The Ciao programming environment also includes lpdoc, an automatic documentation generator for LP/CLP programs. It processes Prolog files adorned with (Ciao) assertions and machine-readable comments and generates manuals in many formats including postscript, pdf, texinfo, info, HTML, man, etc. , as well as on-line help, ascii README files, entries for indices of manuals (info, WWW, ...), and maintains WWW distribution sites.

Programmed design of ship forms

This paper describes a new category of CAD applications devoted to the definition and parameterization of hull forms, called programmed design. Programmed design relies on two prerequisites. The first one is a product model with a variety of types large enough to face the modeling of any type of ship. The second one is a design language dedicated to create the product model. The main purpose of the language is to publish the modeling algorithms of the application in the designer knowledge domain to let the designer create parametric model scripts. The programmed design is an evolution of the parametric design but it is not just parametric design. It is a tool to create parametric design tools. It provides a methodology to extract the design knowledge by abstracting a design experience in order to store and reuse it. Programmed design is related with the organizational and architectural aspects of the CAD applications but not with the development of modeling algorithms. It is built on top and relies on existing algorithms provided by a comprehensive product model. Programmed design can be useful to develop new applications, to support the evolution of existing applications or even to integrate different types of application in a single one. A three-level software architecture is proposed to make the implementation of the programmed design easier. These levels are the conceptual level based on the design language, the mathematical level based on the geometric formulation of the product model and the visual level based on the polyhedral representation of the model as required by the graphic card. Finally, some scenarios of the use of programmed design are discussed. For instance, the development of specialized parametric hull form generators for a ship type or a family of ships or the creation of palettes of hull form components to be used as parametric design patterns. Also two new processes of reverse engineering which can considerably improve the application have been detected: the creation of the mathematical level from the visual level and the creation of the conceptual level from the mathematical level. © 2012 Elsevier Ltd. All rights reserved. 1. Introduction