openModeller A framework for species modeling

openModeller
A framework for species modeling
Fapesp process: 04/11012-0
Partial Report #3 (April 2007 – March 2008)
Index
INTRODUCTION ...................................................................................................1
OBJECTIVES ......................................................................................................1
SUMMARY OF MAIN ACTIVITIES AND RESULTS ........................................................2
Locality data component .......................................................................................2
Locality data server...............................................................................................2
Clients (drivers) that read locality data..................................................................3
Data cleaning ........................................................................................................3
Environmental data component............................................................................4
Pre-analysis component ........................................................................................5
Modeling component .............................................................................................5
Post-analysis component ......................................................................................6
Desktop interface ...................................................................................................7
Web interface ..........................................................................................................7
Integration with TerraLib .......................................................................................8
Evaluation of parallelization techniques and analysis of parallel algorithms
for biodiversity data analysis ................................................................................9
Initial implementation using services architecture ...........................................10
Other developments.............................................................................................10
Model repository .................................................................................................10
Study Cases ..........................................................................................................10
Seminars ...............................................................................................................12
Training .................................................................................................................12
Publications ..........................................................................................................14
Journal papers ....................................................................................................14
Conference papers .............................................................................................15
Other papers .......................................................................................................16
In preparation......................................................................................................16
GENERAL COMMENTS.......................................................................................17
ANNEX 1. CHANGELOG .....................................................................................19
ANNEX 2. ACTIVITIES RELATED TO THE SPECIESLINK NETWORK ...........................21
Centralized data repository .................................................................................21
Centralized query .................................................................................................24
Sensitive data .......................................................................................................27
Future developments ...........................................................................................28
ANNEX 3. REPORT
ON A TOOL TO ANALYZE DATA ON SPECIES DISTRIBUTION USING
PARALLEL PROCESSING ....................................................................................29
ANNEX 4. PARALLEL VERSIONS OF THE PROJECTION FOR COMPUTER CLUSTERS ...45
ANNEX 5. MANUAL FOR THE INSTALLATION OF A SERVICES PLATFORM .................47
1
Introduction
The goal of this project is to develop a framework to facilitate the work of scientists in
predictive modeling of species distribution. The four year project funded by Fapesp
involves three institutions: CRIA (Centro de Referência em Informação Ambiental),
Poli (Escola Politécnica da USP), and INPE (Instituto Nacional de Pesquisas
Espaciais). This report summarizes the activities carried out during the project’s third
year, from April 2007 to March 2008.
Objectives
This project’s original aim is to develop a flexible and robust modeling framework to
predict species distribution. Main objectives are:
• Develop a component-based modeling framework with reusable modules
compliant with web services technology
• Enable use and comparison of different modeling algorithms through the same
framework
• Enable modeling pre-analysis and pos-analysis using specific components
• Develop multiple interfaces (web, desktop, command line, web service)
• Facilitate access to distributed biological and environmental data networks
• Allow usage of high performance computing with species distribution
modeling.
• Carry out use cases to test and validate the framework.
Figure 1 illustrates the original proposal. The project addressed the following
components: locality data, environmental data, pre-analysis, modeling, post analysis,
and interfaces. Study cases testing the framework and training are other important
activities of this project.
USER
Original architecture
Interface (desktop, web, console, soap server, swig wrapper, others)
Pre-analysis
data cleaning
georeferencing
Modeling
Post-analysis
Locality component
Algorithms
Specimen data (occurrence points)
GBIF
speciesLink
Environmental component
Environmental data (layers)
GEOSS
Figure 1. Proposed modeling framework architecture
2
Summary of main activities and results
During the third year of the project there were 8 doctoral students, 3 master students,
6 undergraduate students and 6 fellowships for technical training directly involved
with the project, besides the direct involvement of staff members from each institution
(CRIA, Poli, and INPE).
There were five new releases of the openModeller framework since March 2007 (the
complete changelog can be found in annex 1). Each release included bug fixes and
new features developed during the project. New features included new algorithms
(Support Vector Machines and Envelope Score), a new infrastructure for unit testing,
ROC curve to measure algorithm performance, jackknifing to help choosing
environment layers in modeling experiments, and a new unified compiling strategy for
all platforms. Now both the library and the desktop interface have packages for all
three major platforms: GNU/Linux, Mac OSX and Windows.
The latest version of openModeller Desktop (1.0.6) is getting an average of 600
downloads per month, which confirms the expectation in the beginning of the project
that it would become the most popular interface of the library.
The computer cluster was purchased, installed and is available to researchers.
Different user interfaces are being developed to allow access in a transparent and
friendly way. Research on parallelizing algorithms such as GARP has been
conducted and a first version of this algorithm is available for testing. Soon it will be
available to end users.
The number of publications since the last report includes 7 journal papers, 13
conference papers among others that are in preparation.
The speciesLink network1, which constitutes the main source of species occurrence
data in the Brazilian territory and whose project originated openModeller, almost
doubled the number of records freely and openly available on-line, reaching
approximately 2.3 million records of voucher specimens in February 2008.
There were also two new releases of TerraLib and TerraView that are already
compatible with the latest version of the openModeller framework.
The publicity gained from our regular software releases and interactions with other
individuals and institutions contributed to the use of openModeller by other interfaces
and tools, such as the GBIF portal. The number of international publications that
mention openModeller is continuously increasing2. The number of potential areas for
future collaboration with the wider scientific community now includes institutions such
as NASA.
Locality data component
Locality data server
The fact that CRIA is also responsible for the development of the speciesLink
network3, which today represents the main source of on-line species occurrence data
in Brazil, is an opportunity to develop a locality data service for openModeller. The
development of the network is also crucial for study cases.
1
http://splink.cria.org.br/
http://openmodeller.sourceforge.net/index.php?option=com_content&task=blogcategory&id=10&Itemid=6
3
http://splink.cria.org.br/
2
3
For this purpose, this last year speciesLink changed its architecture from using an
online dynamic distributed search system to a centralized search approach (see
annex 2). A system that periodically searches the network and harvests all new and
modified records and stores them in a central database was designed and
developed. This has improved performance and makes it easier to serve all
speciesLink records for other applications as there is now a single endpoint. The
newest DarwinCore4 version was adopted to map the speciesLink central database
fields. The next step will be to install a TAPIR5 compatible data provider software to
serve this data to openModeller. This development was co-funded by the JRS
Biodiversity Foundation.
Clients (drivers) that read locality data
The openModeller locality component involves a set of generic clients (drivers) that
can read locality data from different sources using different formats. Currently there
are drivers for TAB-delimited text files and Terralib databases. To access the
speciesLink data service, a new driver is being developed to provide direct access to
any TAPIR/DarwinCore provider.
Data cleaning
Ecological niche modeling requires high quality data, so within the openModeller
framework, the idea is to develop an application where users may test data quality.
During the first two years of the project, work was concentrated in developing a more
universal application (data tester). The idea originated in a project that was carried
out in collaboration with GBIF to design and develop an extensible Java framework
for performing tests against XML data sets and reporting on data quality.
At the same time, the development of data-cleaning applications is a continuous
study for the speciesLink network. CRIA’s staff has been developing tools to find data
inconsistencies and typing errors and producing on-line reports for each data
provider (biological collections) for the last 5 years. This field of research has proved
to be very dynamic, and through the constant interaction with collections (the
speciesLink network today has more then 130 collection) new features are frequently
added.
What the team was basically doing was developing applications for the speciesLink
network, that is the main source of species occurrence data on the Internet for Brazil,
and then rewriting the tests to be used by data tester.
This has not proved to be efficient so we have changed our strategy. Last year, work
was concentrated in making the speciesLink network more efficient through a
centralized data repository and in adding new features to the data cleaning
applications. Plans are to develop a Web interface for users to be able to submit data
sets and retrieve reports with data quality evaluations.
The following data fields are currently being checked:
• Names
• Dates
• Locality
• Consistency between Collector, collector number and name between herbaria
4
5
http://www.tdwg.org/activities/darwincore/
http://www.tdwg.org/activities/tapir
4
Brazil does not have a validated list of species names. The data cleaning tools check
names with the Catalogue of Life6 but in a recent study we estimate that less then 5%
of the approximately 204 thousand unique names that are part of the speciesLink
network are included in the Catalogue of Life. For this reason a phonetic database of
names of the network was created to help find typing errors. When a name is
phonetically equal but written differently it is presented as a “suspect record”. The
data cleaning report returns the following information:
• Name (family, genus, species, subspecies),
• Number of records written this way in the collection,
• Number of records written this way in the network,
• Status of this name in the Catalogue of Life, and
• Catalogue number.
Geographic error detection includes checking whether given coordinates are
consistent with the administrative regions provided by the original records, such as
whether the values registered for latitude/longitude fall within the municipality
registered. The system also checks whether data on country – state – municipality
are coherent. Information as to records that have values of latitude or longitude equal
to zero and values that are points in the sea are also shown. If the collection is of
terrestrial species, then all coordinates that occur in the sea are errors. Another tool
to detect possible errors is checking for outliers on latitude and longitude using a
statistical method based on reverse-jackknifing procedure. Additionally, the system
calculates latitude/longitude values to nongeoreferenced records based on the official
coordinates of municipalities in Brazil.
The system also checks the date of the record. Each collection informs the date of
their oldest record, so the system compares this date with the date informed for each
record and also compares the date of the record with the date it was last updated.
Dates prior to the oldest date informed by the collection, and record dates that are
more recent then the date the record was updated are presented as “suspect
records”.
The last feature is of particular interest to herbaria that commonly exchange duplicate
exsiccates. Common fields for duplicates are the collector’s name and number. The
system assumes that if different records from different herbaria have the same
collector’s name and number they are duplicates and therefore should have the
same species name. If not, they are presented as “suspect records”. The results are
presented as a table where duplicate records are shown with the different name and
the name of the specialist responsible for its identification and the identification date.
This way, herbaria can benefit from specialists visits to different herbaria.
Environmental data component
In the future, we envision a system that will serve environmental layers as a service,
such as GBIF and the speciesLink network are serving species occurrence points.
Such a system is under discussion7 and a new protocol called Web Coverage Server
(WCS) is already available for this purpose. New versions of GDAL can optionally
access remote rasters through WCS. The corresponding driver was compiled, tested
and seemed to work properly. Since GDAL can be used by openModeller, this
increases the number of environmental data sources that can be accessed in a
distributed data scenario. Initial tests were limited by the small number of WCS
6
7
http://www.catalogueoflife.org/search.php
see GEO and GEOSS at http://www.earthobservations.org/
5
servers available. To overcome this limitation and gain more knowledge and
experience with WCS, a new WCS server is being developed on top of TerraLib.
CRIA is also investigating ways to manage the large number of environmental layers
accumulated over the years. Each layer represents a different variable and is stored
as an individual file (or directory) in its own raster format. The first attempt was to
create a metadata file containing keywords for each layer. A data harvester program
was then developed to read all metadata files and store this information in a
relational database so that queries could be performed. A prototype web interface
was also developed to display all keywords as tag clouds with incremental filters
being applied after each keyword selection. This approach is still being evaluated
and may be eventually used in the openModeller Web interface.
Pre-analysis component
A jackknife-based procedure is the first technique implemented in openModeller to
help in identifying the most relevant environment layers that can be used in each
modeling experiment. Jackknife is currently implemented as a separate class and it
expects an algorithm as a parameter. The specified algorithm will generate a model
for different subsets of layers (each time excluding one of the layers from the
complete set) and the results are tested with an independent set of points. Jackknife
calculates bias and variance estimates of statistical parameters (we are currently
using model accuracy). In addition, it measures the contribution of each variable
(environment layer) for the chosen parameter estimate (model accuracy). This
method is still being tested in order to find the best openModeller algorithm(s) that
can be used for this purpose.
A second technique implemented in openModeller is the Chi Square method
described at Li, L., et al. (2006) "An Integrated Bayesian Modelling Approach for
Predicting Mosquito Larval Habitats". This method also expects a set of layers as
input. For each pair of layers a contingence matrix is built. This matrix records the
number of occurrences in both layers, considering them categorized in classes. The
Chi-square test is applied with the significance level of 0.05. The algorithm returns,
for each variable, the number of layers with a correlation at the significance level of
0.05.
A generic API to interact in the same way with different pre-analysis techniques
involving input layers is still being studied and discussed. The implementation is
planned for the final year of the project.
Modeling component
openModeller changed its compilation system to use CMake8 so that the same build
system could be used across all platforms. This change allows openModeller to be
more easily deployed in the three major platforms: GNU/Linux, Mac OS X and
Windows. The adoption of a CMake build system for all platforms provides a
significant reduction in maintenance, complexity of the code base, and duplication of
effort. Additionally, for GNU/Linux two packages are now being generated in each
release using the two main formats: Red Hat Package Manager (rpm) and Debian
(deb).
Considering the frequency in which changes are made to the library by different
developers, one of the efforts during the last year was to develop a new infrastructure
8
Cross Platform Make: http://www.cmake.org/
6
for unit testing. Unit tests provide a way to check that specific parts of the source
code are working as expected. Several C++ frameworks for unit tests were
investigated before deciding to use CxxTest9 for the openModeller library. This
process was documented in the openModeller Wiki10. A set of unit tests were
developed with the chosen framework, although they still don’t cover the entire
library. Now that we have documentation about how to write, compile and run unit
tests, the plan is to gradually increase the number of tests and to follow a test-driven
development strategy for future work on the library.
Two new algorithms are available in openModeller: Support Vector Machines (SVM)
and Envelope Score. SVM is a machine learning technique based on concepts from
the statistical learning theory. SVMs have been used in many different applications
that involve pattern recognition. Recently, SVM has also been applied to the problem
of creating species’ distribution models, but there is still considerable scope for
further research. SVMs are known for their good generalization ability and
robustness to high dimensional datasets. The openModeller implementation of SVM
was carried out in a partnership with the “Instituto de Ciências Matemáticas e de
Computação”11 of the University of São Paulo.
Envelope Score is a lax bioclimatic envelope algorithm where the probability of
presence in a specific point is proportional to the number of environment layers
whose envelope (min-max range calculated in model creation) contains the
corresponding environment value for the point. The primary motivation for
implementing Envelope Score was to generate more meaningful models in paleoclimate scenarios, where the traditional Bioclim algorithm produces overly
constrained models. This work was done in collaboration with Chris Yesson from the
University of Reading.
The Aquamaps algorithm already mentioned in the last report (implemented in
collaboration with the Incofish12 project) is currently being updated to incorporate
recent changes made by the authors. After validation, this new version should be
officially released as part of openModeller to become an alternative for modeling
marine organisms. Another change in existing algorithms was the inclusion of the
Chebyshev metric in Environmental Distance.
Another two algorithms are planned for the final year of this project. The first will be
based on Maximum Entropy (MaxEnt) techniques. Maximum entropy has been
successfully applied in many different areas including species’ distribution models.
The second new algorithm will be based on Neural Networks using Multilayer
Perceptron with Backpropagation. When available, both algorithms will be compared
with the existing ones.
Post-analysis component
The Receiver Operating Characteristic (ROC) curve and its associated measure
(AUC - area under the curve) were implemented as part of the openModeller library.
ROC curve data and AUC are now automatically calculated after model creation
using command-line tools, Web Service calls, and the Desktop interface (which
includes a graphical display of the curve). When no absence points are used,
openModeller generates background points to calculate the curve. Besides automatic
calculation for training data, the same class can be used for any extrinsic tests.
9
http://cxxtest.sourceforge.net/
http://openmodeller.cria.org.br/wikis/om/UnitTesting
11
http://www.icmc.usp.br/
12
for more about Incofish see http://www.incofish.org/
10
7
A new method for model validation should be incorporated into the Web Services
interface during the last year of the project. This method will allow any number of
external model validations using any of the available methods (AUC, accuracy or
others) to be performed remotely.
Desktop interface
Two additional releases (1.0.5 & 1.0.6) were made and a third is planned. The
current generation has numerous improvements, including:
• The running of experiments is now threaded so the application remains
responsive and interactive during the running of an experiment. This includes
the ability to browse individual model outputs while the experiment run is still
underway.
• For model preparation, the data fetcher tools have been updated - fetching
data from the new GBIF Rest interface is now possible. In addition, users can
specify minimum size search results. Lastly the data fetcher tools have been
re-implemented as a more user friendly wizard interface.
• Version 1.0.6 now displays an AUC graph and ROC score for each model.
When preparing a model the use of absence data is now supported. In
addition, the visualization of model outputs in the mapping tab shows absence
and presence data with separate symbology (by default red for absence and
green for presence). The environmental values at each presence or absence
point are now presented in a new table tab which has been optimized for large
datasets.
• The model visualization now supports the overlay of a user defined 'context
layer' (vector geographic boundaries) to aid users in placing the model in an
appropriate geographic context.
• Once an experiment is completed, users can visualize the models in a new
thumbnail view with options to sort by algorithm or by taxon. This, for example,
facilitates easy visual comparison of different algorithm outputs for the same
taxon.
• The addition of a new post processing tool allows users to create 'hotspot'
maps and 'consensus' maps. Hotspot maps aggregate the outputs from two or
more models using a specified probability threshold. The result is a raster
showing the number of taxa predicted present per raster cell. The consensus
map tool allows the outputs of multiple algorithms for the same taxon to be
combined to create a single unified raster where the value in each cell
represents the number of algorithms that predict presence for that cell.
• Regular updates were made to ensure that the openModeller Desktop
application remains current and compatible with the most recent version of the
openModeller library.
• The creation of a detailed unit testing framework using QTest and CTest with
similar goals in mind to the test framework being developed for the
openModeller library.
Web interface
Three new prototype Web interfaces involving openModeller were developed during
the last year. Two of them (one in PHP and the other in Flex) were outcomes of the
8
Biogeo Interoperability Workshop13. This workshop was organized by a specific task
group from the TDWG Geospatial Interest Group14 and hosted by CRIA. The aim of
this workshop was actually to test biodiversity and geospatial protocols and data
standards and to investigate how they could interoperate. This was done by
developing two demo applications which basically consisted of Web interfaces
making use of specific Web services. One of the services to be tested was based on
the openModeller Web Services interface (OMWS) developed by the openModeller
team to facilitate remote modeling. The final report of the workshop15 includes
comments about OMWS. Both applications developed during the workshop are Web
interfaces that can generate niche models.
The other prototype was produced in a partnership between CRIA, University of
Colorado and GBIF. The result was also a Web interface making use of specific
services to produce niche models16. However, one of the objectives was to develop a
Java library to access the modeling service so that GBIF could use it. GBIF is
incorporating this functionality into their data portal with a scheduled release in April
2008. Being integrated into the GBIF portal will provide access to openModeller to a
very wide audience.
These prototypes, as well as the first Web interface developed as part of this project,
offered a good opportunity to learn about this kind of interface and to test ideas.
However, we feel that such interface should also be able to interact with
openModeller as a local library, which would require C++ or Python as the
programming language. So a final and full-featured Web interface will be developed
as part of this project during its final year.
Integration with TerraLib
Two new versions of TerraLib and TerraView were released during the last year:
3.1.4 and 3.2.0. The openModeller driver to access TerraLib databases and the
TerraView plugin are currently being updated for compatibility with version 3.2.0 of
TerraLib and TerraView. In this version TerraLib is now built as a dynamic library,
which will help solve previous integration issues with the openModeller library.
TerraView and TerraLib version 3.2.0 allow the integration of new data sources that
are external to the TerraLib database: shapefiles, data collected from WMS servers
and third party TerraLib databases. This will expand the capabilities of using
distributed occurrence and environmental data for TerraView/openModeller users.
TerraView 3.2.0 now includes sample point generation functionality. It allows users to
generate points over the layer of occurrence and/or environmental data in a random
or stratified way. These points can be used to get values from modeling results and
also for post-analysis operations.
The integration between the R and TerraLib is also being updated to the latest
version of TerraLib.
13
http://www.tdwg.org/homepage-news-item/article/geointeroperability-workshop-outcomes/
http://www.tdwg.org/activities/geospatial/
15
http://wiki.tdwg.org/twiki/bin/viewfile/Geospatial/InteroperabilityWorkshop1?rev=1;filename=BioGeoSDIreport.pdf
16
http://dbmuseblade.colorado.edu/gbiftestbed/
14
9
Evaluation of parallelization techniques and analysis of
parallel algorithms for biodiversity data analysis
The following tasks were carried out to improve the performance of openModeller by
applying parallelization techniques:
• Software installation and configuration in the new cluster environment.
• Development of a portal for job submission on the cluster.
• Performance analysis of openModeller.
• Parallelization of one of the existing algorithms (P-GARP).
• Parallelization of the model projection step.
The following tasks are currently in progress:
• Adapt the existing openModeller Web Services scheduler script to submit jobs
to the cluster.
• Merge P-GARP and the parallelized projection into the openModeller code
repository.
• Deploy P-GARP and the parallelized projection in the cluster.
• Develop new strategies to improve the parallel versions.
Four different versions of the original openModeller projection code were produced
and tested. The first version used the OpenMP library17 to parallelize model projection
in multiprocessor computers. Tests were performed in one node of the cluster (each
node has dual processor cores). The initial results were not good (see annex 3 – only
in Portuguese) due to the intensive hard disk access rate of the application. The
other two versions used Message Passing Interface (MPI)18 on the cluster. In version
2, each node of the cluster generates a file in the TIFF format for each part of the
distribution map, and in the end one of the nodes merges all files. In version 3, each
node generates an intermediate custom file for each part of the map. This file
contains the associated probability for each pixel. In the end, one of the nodes
receives these intermediate files from the other nodes to generate the final map.
Version 4 was based on version 3, but without generating intermediate files. The
associated probability for each pixel is stored in a buffer which is transferred to node
0. More details can be found in annex 3 and 4 (only in Portuguese). There was a 5.7
fold reduction in execution time using version 4 with ten nodes compared to the
sequential execution time (sequential version of openModeller running in one node)
when the map extent is limited to Brazil using the Bioclim algorithm. A 3.1 fold
improvement was obtained when the map extent is South America. These versions
are still being studied and improved.
P-GARP is a parallel version of the GARP algorithm designed as part of this project
for efficient use on clusters. The current implementation was tested for correctness
and performance. P-GARP models were successfully compared with GARP models
using the same input. P-GARP is currently available for testing but only for cluster
identified users.
The ideas that were used to develop P-GARP can be applied in the parallelization of
other algorithms to improve performance. P-BestSubsets and HighP-BestSubsets
are parallel versions of the openModeller GARP Best Subsets algorithm, using
GARP and P-GARP, respectively. The design of both new algorithms has been
completed. P-BestSubsets is partially implemented, but is still not available. HighPBestSubsets implementation has not been initiated.
17
18
http://www.openmp.org/drupal/mp-documents/spec25.pdf
http://www.netlib.org/mpi/
10
A Website for job submission to the cluster was built. It provides an interface for end
users to request either a sequential openModeller execution running on one node or
a parallel execution running on several nodes.
Initial implementation using services architecture
To help identify openModeller components that can be processed in alternative
parallel and distributed ways using a high-performance infrastructure, a detailed
performance analysis was carried out during the second year of the project. In this
study the openModeller framework was split into several components and submitted
to a typical workload defined with the help of end users. Results can be found in the
performance analysis online report19 (only available in Portuguese). A Web system
was also developed to collect performance metrics of the openModeller components.
Building on the above mentioned work, studies for establishing a new Service
Oriented Architecture model (or SOA-based) for openModeller were initiated. These
studies were also based on previous studies about architecture and reference
models for openModeller, the SOA reference model, and a comparative study
between precision agriculture and biodiversity modeling information systems (all
published as part of this project). First results include the definition of a reference
architecture for ecological niche modeling and the application of SOA for service
identification in ecological niche modeling and GIS systems.
A new version of openModeller using the new SOA-based architecture is being
developed. Phase 1 consists of providing a service-oriented platform to deliver and
integrate services attending to established SOA requirements. A preliminary version
is available using Jboss, Apache Tomcat, Apache Axis and Apache Ant (all open
source tools) but not yet integrated with openModeller (see annex 5, only available in
Portuguese). The next step consists of breaking openModeller into several separate
services. These will reflect the pre-analysis, modeling and post-analysis stages of the
modeling process.
Other developments
Model repository
Karla Donato Fook's doctoral thesis proposes a Web Services architecture that will
support collaboration in a species distribution modeling network. By using this new
architecture, users will be able to share model instances (definition of parameters,
data used, chosen algorithms) and potential distribution maps. This will allow them to
access other models and compare results. The proposed architecture was partially
implemented. In 2007 two prototypes were released and presented to CRIA and
INPE users for feedback. A first final release is expected to be delivered in April,
2008.
Study Cases
The following studies were carried out in collaboration with CRIA during the period
between March 2007 and February 2008 with the objective of testing the framework,
training and involving users from other institutions, and producing papers to
disseminate openModeller and its applications:
19
http://openmodeller.incubadora.fapesp.br/portal/bolsas/Relatorio-Fapesp.rar
11
•
•
•
•
•
•
Comparison of two different algorithms (GARP and Maxent) in modeling the
potential habitat of manned wolf (Chrysocyon brachyurus). The main objective
was to know the consequences of actual habitat fragmentation for this species.
Renata Kawashima & Eduardo Mantovani (Instituto Nacional de Pesquisas
Espaciais – INPE) and Marinez F. Siqueira (CRIA). Status: published.
Performance test of two different algorithms (GARP and SVM – Support
Vector Machine) in modeling Cerrado tree species (Stryphnodendron
obovatum). The main objective was to compare the accuracy of these
algorithms and test the effect of using a high number of environmental layers
in the process. Ana Carolina Lorena (Universidade Federal do ABC), Renato
De Giovanni (CRIA), André C.P.L.F.Carvalho & Ricardo C. Prati (Universidade
de São Paulo - USP, Campus de São Carlos). Status: accepted.
Application of potential species modeling to known geographic distribution of
Hennecartia omphalandra (Monimiaceae). Marcus Gonzales & Ariane L.
Peixoto, (Escola Nacional de Botânica Tropical – Jardim Botânico do Rio de
Janeiro), and Marinez F. Siqueira (CRIA). Status: in preparation.
Potential distribution modeling of species threatened of extinction from State of
Minas Gerais, Brazil. Luciana H. Yoshino Kamino (Universidade Federal de
Minas Gerais – UFMG) and Marinez F. Siqueira (CRIA). Status: in preparation.
Potential distribution modeling and model validation using openModeller.
Francisco C. Barreto (Universidade Federal de Viçosa – UFV) and Marinez F.
Siqueira (CRIA). Status: in preparation.
Ecological niche modeling in the Brazilian Atlantic Forest: a comparative
evaluation of presence-only methods for modeling the geographic distribution
of anurans. João Gabriel Giovanelli & João Alexandrino (Universidade do
Estado de São Paulo - UNESP, Campus de Rio Claro) and Marinez F.
Siqueira (CRIA).. Status: in preparation.
The following study cases were carried out at INPE:
• Fabio Iwashita’s master thesis assessed the sensibility of species distribution
models according to the precision of locality data. Two algorithms
implemented in openModeller (GARP and BIOCLIM) and Maxent were
evaluated. The paper from this thesis will be submitted in March, 2008
(Iwashita, in preparation).
• For the state of São Paulo, species of genus Croton (Euphorbiaceae) and
species from the Tribo Cynodonteae (Poaceae – Chloridoideae) where studied
in collaboration with the Instituto Botânico de São Paulo (IBt). The first
analysis of the spatial distribution of the Tribo Cynodonteae indicated that the
sampling effort has to be intensified to enable a better understanding of the
biogeography and conservation status of the group (Santos et al., 2007). For
the Croton genus, the importance of the soil variable in species distribution
modeling for this group was analyzed (Caruzo et al. 2007). For both taxa,
experiments considering species distribution models with different algorithms
and variables can be further tested to better discuss the biological processes
related to the species distribution
• A database for studying Arecaceae (Palmae) distribution in Brazil is under
development. Occurrence data from the most important Brazilian and
international herbaria were incorporated into the database. At the moment, a
data cleaning process to correct the geographical coordinates and taxonomic
nomenclature is being performed. The database with Arecaceae occurrence
data will enable a study about the spatial distribution of Brazilian palms and
also help testing openModeller algorithm implementations.
12
•
•
Different environmental data and species distribution algorithms were tested to
achieve better results and optimize modeling procedures. In particular,
Normalized Difference Vegetation Index (NDVI) was used to model the genus
Coccocypselum (Rubiacea) using GARP-OM Best Subsets algorithm and
Maxent (Costa et al., in preparation).
A study case is under preparation to analyze the impact of climate change
over the life forms in the boundaries between savanna and tropical rain forest
in the Brazilian Amazon. A database containing occurrence data from savanna
and forest vegetation is under construction and will be used to model the
current and the predicted distribution of dominant life forms (Box model
algorithm) as well as for a number of selected species using algorithms
implemented in openModeller.
Seminars
In order to integrate the teams and try to make all have a clearer concept of the
project as a whole, a number of seminars and meetings are held. During the last year
of the project three seminars and two general meetings were held.
Date: 14th June, 2007
Location: Poli
Presentations: Using the new interface to submit Condor jobs in the cluster (Nilton
Cézar de Paula, Poli), Plans for Unit Tests in openModeller (Albert Massayuki
Kuniyoshi, Poli), News about openModeller Desktop (Tim Sutton, CRIA), Model
Repository (Karla Fook, INPE).
Date: 16th August, 2007
Location: INPE
Presentations: Support Vector Machines (Ana Carolina Lorena, UFABC), Status of
the cluster environment (César Bravo, Poli), Discussions about the project.
Date: 18th October, 2007
Location: Poli
Presentations: Adaptive Systems (Prof. João José Neto, Poli), AdaptGarp (César
Bravo, Poli), Using openModeller Desktop with the cluster (Tim Sutton, CRIA).
The study group about Biodiversity Modeling that was created at INPE, called
“Referata Biodiversa”20, proceeded with the monthly meetings. Over the last year, the
group discussed issues such as climate changes and potential vegetation models,
spatial dependence in predictive vegetation modeling, status and problems related to
digital database of biological collections, statistical methods to modeling evaluation,
among others. Besides contributing towards the integration of INPE’s team, it also
offers the opportunity of interaction with other groups such as the Instituto de
Biociências (USP) and the Instituto de Botânica de São Paulo (IBt-SP).
Training
Dr. Marinez F. Siqueira from CRIA offered training courses, lectures, and acted as
advisor to graduate students working with openModeller. Last year activities include:
20
http://www.dpi.inpe.br/referata/index.html
13
•
•
•
•
•
•
•
•
•
•
•
Instructor: III course “Potential distribution of species”. Instituto de Pesquisas
Ecológicas – IPE. Nazaré Paulista, SP, Brazil. Apr/2008.
Instructor:
Advanced
course
“Potential
distribution
of
species”.
CENARGEM/EMBRAPA. Feb/2008.
Co-adviser of Luciana H. Yoshino Kamino. PhD degree: Modelagem de
espécies de plantas ameaçadas de extinção de Minas Gerais. Pós-graduação
em Biologia Vegetal. Laboratório de Sistemática Vegetal. Depto de Botânica
/ICB /UFMG. Jan/2008.
Co-adviser of Francisco Candido Cardoso Barreto. PhD Degree. Potential
distribution modeling and models validation in openModeller. Programa de
Pós-Graduação em Entomologia. Universidade Federal de Viçosa - UFV,
Brazil. Feb/2008.
Instructor: II course “Potential distribution of species”. Instituto de Pesquisas
Ecológicas – IPE. Nazaré Paulista, SP, Brazil. Sep/2007.
Instructor: I course “Potential distribution of species”. Instituto de Pesquisas
Ecológicas – IPE. Nazaré Paulista, SP, Brazil. Mar/2007.
Lecture: Modelagem de distribuição geográfica de espécies. In: XVIII Semana
de Estudos da Ecologia. Instituto de Biociências, UNESP, Campus Rio Claro.
10 – 14 September, 2007.
Lecture: Modelagem de distribuição potencial de espécies. In: Faculdades
Integradas Metropolitanas de Campinas – METROCAMP. 6th October, 2007.
Lecture: Acesso a dados de coleções biológicas. In Faculdades Integradas
Metropolitanas de Campinas – METROCAMP. October 6, 2007.
Lecture: Mudanças ambientais: possíveis impactos na biodiversidade. In:
Programa de Extensão da Escola Nacional de Botânica Tropical. Seminários
em Ciência e Tecnologia. Jardim Botânico do Rio de Janeiro. 20th April, 2007.
Lecture: Environmental satellite data: applications in studies of biodiversity.
“Strategies for Open and Permanent Access to Scientific Information in Latin
America: Focus on Health and Environmental Information for Sustainable
Development”. Atibaia, SP. 8-10 May 2007.
Dra. Silvana Amaral presented the openModeller project as part of INPE´s activity in
the following events:
• Visit of the Ministry of Forestry of Indonesia at INPE, June/2007, presentation
entitled “Species Distribution Modeling in the Amazônia”;
• Lecture in the Post-Graduation in Remote Sensing at INPE (24/10/2007), in
the course “Tópicos Especiais em Floresta” (SER 455-3), presentation entitled
“Modelos de Distribuição de Espécies”;
• Rede GEOMA Symposium, Petrópolis-RJ (29-31/10/2007), presenting the
paper “Estudos de Modelagem de Distribuição de Espécies no Componente
Biodiversidade na Rede GEOMA”.
During this year the following people were involved with openModeller through
scholarships and training:
Doctoral students:
• Cristina Giannini, Instituto de Biociências da Universidade de São Paulo
(IB/USP), since 07/2007.
• Elisângela Silva da Cunha Rodrigues, EPUSP (CAPES scholarship), since
07/2007;
• Fabiana Soares Santana, EPUSP, since 02/2007;
14
•
•
•
•
•
Fabrício Rodrigues, EPUSP (CAPES scholarship), since 07/2007;
Francisco Candido Cardoso Barreto, UFV;
Karla Donato Fook, INPE, since 03/2004;
Luciana H, Yoshino Kamino, UFMG;
Nilton Cézar de Paula, EPUSP, since 06/2006.
Master students:
• Fabio Iwashita, INPE Remote Sensing Program, finished in 03/2007 under the
supervision of Dr. Silvana Amaral;
• João Gabriel R. Giovanelli, UNESP, Rio Claro;
• Marcos Gonzales, ENBT/JBRJ.
Undergraduate students during the period of this report:
• Albert Massayuki Kuniyoshi – EPUSP;
• Alex Oshika, student of Computer Engineering – EPUSP;
• Danilo de Jesus da Silva Bellini, student of Electric Engineering – EPUSP
(CNPq scholarship);
• Luciano Bergantini Lippi, student of Computer Engineering – EPUSP;
• Marcos Cabral Santos, student of Computer Engineering – EPUSP (Fapesp
scholarship);
• Mariana Ramos Franco, student of Computer Engineering – EPUSP (Fapesp
scholarship).
FAPESP Technical Training scholarships:
• Alexandre Copertino Jardim, scholarship type TT4, since 10/2007;
• Dr. César Alberto Bravo Pariente, EPUSP, scholarship type TT5, 12/2006 –
12/2007;
• Luciana Satiko Arasato, scholarship type TT3, since 10/2007;
• Missae Yamamoto, scholarship type TT5, since 10/2007;
• Renata Luiza Stange, EPUSP, scholarship type TT4a, since 01/2008;
• Tim Sutton, CRIA, scholarship type TT5, since 05/2006.
Publications
Journal papers
Canhos, V.P., Siqueira, M.F.; Marino, A.; Canhos, D.A.L. “Análise da vulnerabilidade
da biodiversidade brasileira frente às mudanças climáticas globais”. Parcerias
Estratégicas. Centro de Gestão e Estudos Estratégicos. Accepted in March, 2008.
De Marco Jr, P. & Siqueira, M.F. “Como determinar a distribuição potencial de
espécies sob uma abordagem conservacionista?” Megadiversidade, Belo Horizonte.
(Submitted in December 2007).
Muñoz, M.E.S., Giovanni, R., Siqueira, M.F., Sutton, T., Brewer, P., ScachettiPereira, R., Canhos, V.P. & Canhos, D.A.L. “openModeller: A Generic Approach to
Potential Distribution Modelling of Species”. Geoinformatica. (Submitted in December
2007).
Pereira, R. S. & Siqueira, M. F. “Algoritmo Genético para Produção de Conjunto de
Regras (GARP)”. Megadiversidade, Belo Horizonte. (Article in press)
15
Santana, F.S., Bravo, C., Saraiva, A.M. & Correa, P.L.P. “Parallel Genetic Algorithm
for Rule-set Production”. Environmental Modelling and Software. (Submitted in March
2008)
Santana, F. S., Siqueira, M. F., Saraiva, A. M. & Correa, P. L. P. 2008. “A reference
business process for ecological niche modelling”. Ecological Informatics Journal, v. 3
p. 75-86.
Siqueira, M.F. & Durigan, G. 2007. “Modelagem da distribuição geográfica de
espécies lenhosas de cerrado no Estado de São Paulo”. Revista Brasileira de
Botânica. v.30. p239-249.
Siqueira, M.F., Durigan, G., De Marco Jr., P. & Peterson, A.T. “Something from
Nothing: Using Landscape Similarity and Ecological Niche Modeling to Find Rare
Plant Species”. Journal for Nature Conservancy. (Submitted in December 2007)
Conference papers
Amaral, S., Costa, C.B., Iwashita, F., Ximenes, A. & Valeriano, D.M. (2007). “Estudos
de Modelagem de Distribuição de Espécies no Componente Biodiversidade na Rede
GEOMA”. I Simpósio da Rede Geoma, Petrópolis, RJ.
Amaral, S., Costa, C.B. & Rennó, C.D. (2007). “Normalized Difference Vegetation
Index (NDVI) improving species distribution models: an example with the neotropical
genus Coccocypselum (Rubiaceae)”. Anais do XIII Simpósio Brasileiro de
Sensoriamento
Remoto,
Florianópolis,
Brasil,
INPE,
p.
2275-22282
(marte.dpi.inpe.br/col/dpi.inpe.br/sbsr@80/2006/11.15.14.30/doc/2275-2282.pdf).
Araujo, J. M., Correa, P.L.P. & Saraiva, A. M. “A Framework for Species Distribution
Modeling: a performance evaluation approach”, I2TS'2007 Proceedings of the 6th
International Information and Telecommunication Technologies Symposium, Brasília:
IEEE R9, 2007. Editors: Fundação Bardall de Educação e Cultura; Boukerche, A,
Loureiro, A.A.F., Melo, A.C.M.A. and Gondim, P.R.L. p. 111-118. Oral presentation.
Bravo, C., Neto, J.J, & Santana, F.S. “Unifyinig Genetic Representation and
Operators in an Adaptive Framework”. Analysis of Genetic Representations and
Operators, AGRO 2007.
Bravo, C., Neto, J.J, Santana, F.S. & Saraiva, A.M. “Towards an adaptive
implementation of genetic algorithms”. Anais da XXXIII Conferência Latinoamericana
de Informática – CLEI 2007; Taller Latinoamericano de Informática para la
Biodiversidad – INBI 2007, San José, Costa Rica. Proceedings of the CLEI – Centro
Latinoamericano para Estudios en Informatica, 2007. v.1 p. 1-5.
Caruzo, M.B., Costa, C. B., Amaral, S. & Cordeiro, I. (2007). “Aplicação de classes
de solo em modelos de distribuição de espécies: um exemplo com Croton L.
(Euphorbiaceae)”. Paper presented at Congresso Nacional de Botânica, São Paulo.
Kawashita, R.S., Siqueira, M.F. & Mantovani, E. (2007). “Dados do monitoramento
da cobertura vegetal por NDVI na modelagem da distribuição geográfica potencial do
lobo-guará (Chrysocyon bracyurus)”. XIII Simpósio Brasileiro de Sensoriamento
Remoto. Florianópolis, SC. v.13. p.3983 – 3990.
Kuniyoshi, M. A. & Correa, P. L. P. “Aplicação de Testes Unitários no openModeller”,
Anais do 15º Simpósio Internacional de Iniciação Científica da USP, São Carlos,
2007. Abstract. Poster presentation.
Lorena, A. C., Siqueira, M. F., Giovanni, R., Carvalho, A. C. P. L. F. & Prati, R. C.
“Potential Distribution Modelling Using Machine Learning”. In: The Twenty First
International Conference on Industrial, Engineering & Other Applications of Applied
16
Intelligent Systems (IEA/AIE), Wroclaw, Poland. Lecture Notes in Artificial
Intelligence, v. 5027, Springer-Verlag, 2008. (Accepted)
Santana, F. S., Murakami, E., Saraiva, A. M. & Correa, P. L. P. “A comparative study
between precision agriculture and biodiversity modelling information systems”. 6th
Biennal Conference of the European Federation of IT in Agriculture, Glasgow:
C.Parker, S.Skerratt, C.Park, J.Shields, 2007. v. 1. p. 1-6. Oral presentation.
Santana, F. S., Murakami, E., Saraiva, A. M., Bravo, C. & Correa, P. L. P. “Uma
arquitetura de referência para sistemas de informação para modelagem de nicho
ecológico”, Anais do 6º Congresso Brasileiro de Agroinformática – SBIAgro 2007,
Campinas: Embrapa Informática Agropecuária, 2007. Editors: S.Tiernes, L.H.A.
Rodrigues. p. 101-105. Oral presentation.
Santana, F. S., Pinaya, J.L.D., Saraiva, A. M., Correa, P. L. P., Becerra, J.L.R. &
Bravo, C. “Aplicação de SOA para identificação de serviços em sistemas de
modelagem de nicho ecológico e GIS”, I2TS'2007 Proceedings of the 6th
International Information and Telecommunication Technologies Symposium, Brasília:
IEEE R9, 2007. Editors: Fundação Bardall de Educação e Cultura; Boukerche, A,
Loureiro, A.A.F., Melo, A.C.M.A. and Gondim, P.R.L.
Santos, A.L. dos, Wanderley, M.G.L., Bestetti, C.B. & Amaral, S. (2007).
“Diversidade da tribo Cynodonteae (Poaceae: Chloridoideae) no Estado de São
Paulo”. Paper presented at Congresso Nacional de Botânica, São Paulo, SP.
Other papers
Sutton, T., Giovanni, R. & Siqueira, M.F. “Introducing openModeller - A fundamental
niche modelling framework”. OSGeo Journal Volume 1. ISSN 1994-1897. Available
at http://www.osgeo.org/files/journal/final_pdfs/OSGeo_vol1_openModeller.pdf
Franco, M.F. “Arcabouço para distribuição e modelagem de espécies – uma análise
de desempenho”. Scientific Report – FAPESP. FAPESP Process: 2006/03616-9.
July. 2007. 39pp.
Stange, R.L. “Manual de Instalação da Plataforma de Serviços”. Internal Technical
Report, February, 2008. 11pp.
In preparation
Costa, C.B. & Amaral, S., “Presence-only modeling method for predicting species
distribution: an example with the neotropical Rubiaceae genus Coccocypselum P.
Br”. Biota Neotropica.
Giovanelli, J.G.R., Siqueira, M.F., Haddad, C.F.B. & Alexandrino, J. “Ecological niche
modeling in the Brazilian Atlantic Forest: a comparative evaluation of presence-only
methods for modelling the geographic distribution of anurans.
Gonzalez, M., Peixoto, A.L. & Siqueira, M.F. “Chorology of Hennecartia omphalandra
Poisson (Monimiaceae), a Miocene species from the South American Atlantic
Forest”.
Iwashita, F., Amaral, S., Monteiro, A.M.V. “Species distribution models sensibility to
geographical positioning data”. Journal of Biogeography.
Santana, F.S., Sato, L., Bravo, C. & Saraiva, A.M. “Performance improvement
strategies for ecological niche modelling”.
17
General Comments
During the project we found that certain aspects of the architecture would be better if
approached in a different way. Although a fully componentized architecture is still
being researched, we are concentrated on providing a cohesive and simplified Web
Service modeling infrastructure. Instead of creating individual Web Services for each
openModeller component as originally proposed, we are aiming at consolidating the
main functional areas into a single modeling Web Service. We realized that some of
the components, such as the locality and environmental components would be better
implemented with a focus on supplying data to the modeling environment rather than
to end-users. For example, TAPIR, WFS and DiGIR services all provide a robust and
well-established protocol for obtaining occurrence data, so implementing another
service with a similar goal would not make much sense. Similar logic applies to the
environmental component, where protocols such as WCS are already wellestablished. The idea is to be able to retrieve data from these kinds of services. An
additional motivation is to keep the public Web Services API simple in order to ease
integration with third parties and facilitate maintenance. For these reasons, the core
pre and post analysis functionality are being incorporated into the main modeling
Web Service.
USER
New architecture
Interface (desktop, web, console, soap server, swig wrapper, others)
modelling, pre-analysis,post-analysis
Algorithm 1
data cleaning
georeferencing
locality
component
Specimen data (occurrence points)
GBIF
Algorithm 2
openModeller
speciesLink
environmental
component
Algorithm n
Environmental data (layers)
GEOSS
Figure 2. New architecture for openModeller
Another part of the architecture that we are likely to change relates to the data
cleaning component. Originally we conceived a Web Service for data cleaning but we
feel that it is better to work on the existing data cleaning infrastructure of the
speciesLink network. These gains will benefit end users who will retrieve data from
speciesLink using the new openModeller TAPIR driver.
The publicity gained from our regular software releases and interactions with other
individuals and institutions has resulted in a number of potential areas for future
collaboration with the wider scientific community. These include:
18
•
•
•
An informal offer from Dr. Neil Caithness at the University of Oxford (UK) to
host openModeller services at the OxGrid Campus Grid Computing Centre
and the National Grid Service for the UK.
Informal discussions with various people from the American Museum of
Natural History and NatureServe on how we can help them to integrate
openModeller into their current niche modeling processes.
Informal discussions with Brian Hamlin (UC Berkeley, USA) towards including
openModeller in future large scale modeling experiments they are planning.
openModeller has also been selected for the second generation of the LifeMapper21
project being developed by the University of Kansas.
Another initiative using openModeller is a GEOSS22 demonstration project being
developed by GBIF and the Italian National Research Council. The result of this
demonstration project should be used by another project called Ecological Model
Web23 being developed by the Ecological Forecasting Program at NASA.
In addition we have been able to engage with users of our software from various
countries around the world through our users' mailing list and IRC presence. This has
enabled the introduction of a Taiwanese translation of openModeller Desktop which
was contributed by one of our users.
A major concern refers to the continuity of these developments. We consider
openModeller too important an initiative to depend on a project based grant or to be
left solely as an open source initiative without substantial funding. Therefore, this last
year will also be decisive as to planning its continuity and sustainability.
21
http://www.lifemapper.org/
http://www.earthobservations.org/
23
http://www.ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=4422708&arnumber=4423343&index=634
22
19
Annex 1. Changelog
Release 0.5.3 (2008-03-26)
SVN revision: 4209
Fixed bug when GDAL failed to read a raster row (in which case the row used
to have zero values). Now the row is filled with nodata values.
XML request for model creation now supports additional options to filter
occurrences (using spatiallyUnique or environmentallyUnique sampler functions).
Changed nodata value of the default raster type (ByteHFA) to 101.
Masks must now use nodata to indicate masked areas (zeros will not work
anymore).
om_testmodel now generates pseudo-absence points when there are no
absences to be tested.
Display confusion matrix cell values in om_console and om_testmodel.
Renamed getLayerFilename to getLayerPath and getMaskFilename to
getMaskPath in EnvironmentPtr class.
Refactored om_pseudo, om_create and om_project to use the getopts
command line library.
Created man pages for om_pseudo, om_create and om_project.
New parameter in om_pseudo to speficy the proportion of absence points to
be generated.
New algorithm AquaMaps (for marine organisms).
Removed algorithms minimum distance and distance to average since
EnvironmentalDistance provides the same functionality.
"type" property of AlgParamMetadata changed from char * to a new
enumeration called AlgParamDatatype. Values can be Integer, Real and String.
Fixed bug in the environmental distance algorithm: probabilities were negative
for points whose distance to the nearest point was beyond the maximum allowed
distance.
New classes to perform jackknife and chi-square in the environmental layers.
Updated TerraLib drivers for compatibility with TerraLib version 3.2.0.
Release 0.5.2 (2007-10-24)
SVN revision: 3806
Fixed compilation issues under Windows.
Included new command line program to generate pseudo occurrences.
Minor improvements in console tools (absences are now displayed in
om_viewer and om_niche).
Code clean up.
Release 0.5.1 (2007-08-30)
SVN revision: 3661
20
Fixed MSVC compilation problems.
Fixed bug in deserialization of the new GARP algorithm (OM GARP).
Fixed crash in one-class SVM when input points contained absences.
Fixed bug in deserialization of environmental distance algorithm with
Mahalanobis distance.
Implemented serialization/deserialization for the new GARP Best Subsets
(OM GARP).
New algorithm "Envelope Score".
Fixed bug in the pseudo-absence generation of the SVM algorithm when no
absences were passed as a parameter.
Release 0.5 (2007-08-15)
SVN revision: 3527
New algorithm "Support Vector Machines" (C-SVC, nu-SVC and one-class
SVM).
Added support for multiple normalization techniques (two implementations are
available: ScaleNormalizer and MeanVarianceNormalizer).
New method to cancel jobs (model creation or model projection).
Sample serialization is now based on the original (unnormalized) environment
values.
New infrastructure for unit tests using cxxtest.
Release 0.4.2 (2007-05-08)
Included ROC curve as part of model statistics.
Added metric Chebyshev in the Environmental Distance algorithm.
Log object is now a singleton.
Minor bugfixes.
21
Annex 2. Activities related to the speciesLink network
Centralized data repository
During this year, a new architecture was designed to include a centralized data
repository. Figure 1 shows the diagram prior to this activity. All cache nodes include a
DiGIR provider that is also present in collections that are serving data directly to the
DiGIR portal. All queries were distributed and the network was beginning to have
problems with performance. This development was co-financed through a project
with the JRS Biodiversity Foundation.
The former architecture already had a database with a subset of DarwinCore fields In
order to analyze the data and apply data cleaning tools. A webservice application
called mapcria has also been developed to be used by different applications to
dynamically produce maps through a web interface.
Reports
NetworkManager
Manager
Network
mapcria
mapcria
webservice
webservice
Web Site
Site
Web
WMS
WMS
da
ta
Data cleaning
Data cleaning
G
eo
gr
ap
hic
Distributed query
Database
subset
Maps
Maps
PostGIS
PostGIS
DiGIRPortal
Portal
DiGIR
Data analysis
DiGIR
DiGIR
Cache node
Cache node
Cachenode
node
Cache
SOAP
Collections with
a DiGIR provider
Collections with spLinker
Figure 3. Diagram of network architecture
With funding from JRS Biodiversity Foundation and Fapesp the architecture was
altered and now includes a central repository of all data served by the collections.
The repository was installed in a Dell PowerEdge 1900 server, running Linux Fedora
Core 6 operating system. The server has two powerful Intel Xeon 3GHz CPUs with
8GB of RAM memory. The whole system is being developed using open-source
software: the web server is Apache, the database management system is
PostgreSQL and the programming language is Perl.
22
NetworkManager
Manager
Network
Reports
mapcria
mapcria
webservice
webservice
Web Site
Site
Web
WMS
WMS
da
ta
Indicators
Indicators
Data cleaning
Data cleaning
query
G
Centralized
eo
gr
ap
hic
Query interface
Query interface
Maps
Maps
PostGIS
PostGIS
Central Repository
Central Repository
Data Harvester
Data Harvester
Dis
trib
ute
d
qu
ery
Data analysis
DiGIR Portal
DiGIR Portal
DiGIR
DiGIR
Collections with
a DiGIR provider
Cachenode
node
Cache
Cache node
Cache node
SOAP
Collections with
spLinker
Figure 4. speciesLink’s new architecture
Introducing a Central Repository to the architecture also meant developing a data
harvester and a new query interface. The first idea was to store a subset of the
DarwinCore fields selecting only those of interest for data cleaning and ecological
niche modeling applications. As the analysis of fields for different purposes evolves,
the team decided to store all data that was being provided by the collections. This
way the system is already designed to use and provide all fields.
The Central Repository uses PostgreSQL24 on Linux, an open source relational
database system that has more than 15 years of active development and a proven
architecture. CRIA’s team has about 10 years experience with the software that has
proven to be robust with a very good performance, and has a number of resources
available such as transaction control, maintenance of the referential integrity and
automatic triggers. It also has native programming interfaces for C/C++, Java, .Net,
Perl, Python, Ruby, Tcl, ODBC, among others, and good documentation.
Its SQL implementation strongly conforms to the ANSI-SQL 92/99 standards and
supports compound functional indexes which can use any of its B-tree, R-tree, hash,
or GiST storage methods. GiST (Generalized Search Tree) serves as a foundation
for many public projects that use PostgreSQL such as PostGIS. PostGIS is a project
which adds support for geographic objects in PostgreSQL, allowing it to be used as a
spatial database for geographic information systems (GIS). Other advanced features
include table inheritance, a rules systems, and database events. Table inheritance
puts an object oriented slant on table creation, allowing database designers to derive
new tables from other tables, treating them as base classes.
24
http://www.postgresql.org/
23
All these implementations were used in the development of the centralized database.
A general table (splink) was created to store textual data following the DarwinCore
data model and using inheritance mechanisms to create tables for each collection of
the network (figure 3).
Figure 5. Diagram of the main table (splink) with secondary tables for each collection
PostGIS was used to facilitate the creation of maps, making geographic queries more
efficient. A table was created for this specific purpose, using the geographic object
“point” to store all georeferenced data of the network.
The data harvester was developed using Perl and recognizes any changes in the
network through the DiGIR portal that accesses all DiGIR providers. Once a day, the
24
system checks to see if the database has been updated. If there is any change, data
analysis processes (data cleaning, network manager, and indicators) are triggered.
Centralized query
25
A classification system was added to the metadata to enable users to select the type
of collection they wish to search. XML files were created for each collection and
these are used by different applications such as the network manager, indicators,
and the centralized query. Data outputs of the system include selecting what fields
should be presented (small subset, locality, all), in what format (XML, HTML, Excel),
and whether the user wishes to plot the georeferenced data on a map. Below is a
print screen of a query where the collections selected were those that are classified
as “plants, herbarium, and voucher”. Possible options for different outputs are also
shown. This interface was written in Perl and is available in English and Portuguese
languages.
25
available at http://splink.cria.org.br/centralized_search
25
The classification system is also used by both management and monitoring system
and indicators. The next figure shows a print screen of the map that is produced.
Points are plotted with different colors for each collection and layers such as
roadways, rivers, protected areas, among many others can be added.
26
Through the map interface it is now possible to retrieve information about the layers
that were activated.
Figure 6. Occurrence points of a species plotted on a map
27
Figure 7. Information on activated layers where the point is located
Sensitive data
There is a big debate as to what data can be made freely and openly available on the
Internet to all interested and what should be filtered by the collection. Some believe
that if a species is endangered, locality data must be omitted. Others believe that by
including locality data one is enabling others to carry out conservation programs that
involve that specific species. Some collections filter the data or use an application
that reduces the precision of the data. Simply filtering the data can be a problem as
users will not be able to differentiate “no data” from “sensitive data”. Altering its
precisions is also a problem as managing, monitoring, or modeling tools may
produce bad reports or analysis. For the speciesLink network, when a collection
marks the record, or a specific field of the record, as not available, spLinker sends
special values that the system will interpret as “restricted” data and this information
will be shown as such. This means that if a researcher requires that data for his/her
analysis, they know that the data exists and can contact the curator to try and obtain
it. Another feature added to the query is an indication whether the species belongs to
the IUCN or to national and state redlists. The icon sp that runs an application that
integrates all databases at CRIA with other systems appears in red sp if the species
is in one of the redlists.
As a last feature, we have also added a gateway to GBIF data, represented by the
icon . All these features can be seen in figure 6.
28
Figure 8. Records that have their coordinates filtered by the collection and sp indicating the
species is in one of the redlists held at CRIA
Future developments
The next developments to the speciesLink network include
•
Migrate from the current DiGIR protocol to the TAPIR protocol, facilitating an
efficient implementation of DarwinCore extensions making it possible the
implementation of thematic networks such as microbiological, herbaria, etc.
•
Adapt the current centralized database, the mirror database (used by the
cache-nodes), the spLinker software, the harvesting procedures and the
search interface to accommodate DarwinCore extensions such the one
already defined to microbiological collections
•
Adapt the current software, interface and databases to allow the
implementation of different views of the speciesLink content as thematic
networks such as a microbiological or herbaria speciesLink
•
Help new collections to join the network
•
Continue giving support to all participant collections
29
Annex 3. Report on a tool to analyze data on species
distribution using parallel processing
RELATÓRIO DE INICIAÇÃO CIENTÍFICA
TÍTULO: FERRAMENTA PARA ANÁLISE DE DADOS
SOBRE DISTRIBUIÇÃO DE ESPÉCIES UTILIZANDO
PROCESSAMENTO PARALELO
Orientando: Marcos Paulo Pereira Cabral dos Santos
Orientador: Profa. Dra. Liria Matsumoto Sato
Data: 22/06/2007
Instituição: Universidade de São Paulo
Escola Politécnica
Departamento de Engenharia de Computação e Sistemas Digitais
30
1- Introdução
O presente documento consiste no relatório final das atividades realizadas no projeto
de Iniciação Científica no período compreendido entre 01 de setembro de 2006 e 22
de junho de 2007. Durante este período foram realizadas as seguintes atividades:
estudo do paralelismo e suas formas de implementação, estudo da programação
orientada a objetos, familiarização com a ferramenta openModeller, análise e
paralelização do código fonte do OpenModeller usando os sistemas OpenMP e MPI,
bem como uma bateria de testes e depuração do código final obtido.
Foi necessário um adiantamento de dois meses do prazo de entrega, sem
comprometer o que foi proposto no plano inicial. A causa do adiantamento foi minha
aceitação para o Programa de Duplo Diploma entre a Escola Politécnica da
Universidade de São Paulo e a Ecole Centrale de Paris, onde estudarei de julho de
2007 a junho de 2009.
2-Plano Inicial
Os métodos mais usados para a predição de distribuição de espécies são baseados
no conceito de nichos ecológicos [Peterson,2001; Anderson et al. 2002ª,b] que
combinam dados de ocorrência da espécie com as condições ambientais em cada
ponto. Modelos de nichos podem ser projetados em dimensões geográficas para
predizer onde a espécie em análise está presente. Contudo, tais métodos podem
demandar um tempo excessivo de execução. Buscando reduzir o tempo de
execução e conseqüentemente viabilizar a análise de distribuições que requerem
tempo de processamento inviável, como também, permitir análises mais complexas
com a aplicação de diversos algoritmos e considerações diversas sobre os dados
ambientais, este projeto de iniciação científica pretende aplicar o conceito de
paralelismo no módulo de projeção da versão corrente de uma ferramenta já
disponível denominada openModeller. Serão apresentadas três versões de
paralelização do módulo de projeção do Openmodeler:
• Versão
paralela
utilizando
o
sistema
OpenMP
[http://www.openmp.org/drupal/mp-documents/spec25.pdf]
para
um
computador multiprocessador, podendo ser executado em um dos nós
multiprocessadores do cluster. OpenMP é uma interface padrão de diretivas
para os compiladores da lingiuagem C que provê os recursos necessários
para a paralelização de um programa para computadores multiprocessadores
os quais contêm vários processadores e memória compartilhada.
Implementações deste padrão encontram-se disponíveis gratuitamente.
• Versões paralelas utilizando a biblioteca MPI [Snir,2006] para ser executado
utilizando vários nós do cluster. Foram implementadas duas versões. MPI
(Message Passage Interface) é um padrão de interface para comunicação
entre processos distribuídos por passagem de mensagem.
O projeto será realizado em três etapas:
Etapa 1: estudo e familiarização com o sistema openModeller
•
•
Estudo e uso do sistema corrente
Estudo e análise do código do sistema openmodeller corrente
Etapa 2: desenvolvimento da versão paralela utilizando a interface OpenMP.
•
•
•
Definição da Estratégia de Paralelização
Implementação no código do openModeller
Depuração e testes
31
Etapa 3: desenvolvimento das versões paralelas utilizando o sistema MPI
•
•
•
Estudo de programação e familiarização com o sistema MPI
Implementações usando a interface MPI, para cluster de computadores: uma
versão tomando como base a estratégia de paralelismo definida na segunda
etapa e utilizando o código fonte do openModeller e uma segunda adotando
outra estratégia.
Depuração e Testes
Cronograma
Início: 1 de Setembro de 2006
Duração: 12 meses
1
2
3
4
X
X
5
6
X
X
7
8
9
X
X
10
11
X
X
12
Etapa 1
A
B
X
X
Etapa 2
A
B
C
X
Etapa 3
A
B
C
X
Cabe a até o presente momento, apresentar a primeira versão de paralelização do
openModeller.
3-Resumo das atividades realizadas
No início do projeto foram estudados os conceitos básicos de programação paralela
e de programação orientada a objetos em C++ [Stroustrup's,2000]. Depois de
aprendidos os fundamentos do paralelismo, deu-se início a um processo de
familiarização com a biblioteca OpenMP e com a ferramenta de análise de
distribuição de espécies, OpenModeler.
Definiu-se a primeira estratégia de paralelização do código, seguida de sua
implementação e depuração.
Foram apresentados os conceitos básicos de MPI e montadas novas estratégias de
paralelização, uma delas foi utilizada em outra implementação em OpenMP.
Finalmente foram realizados os testes que permitiram concluir sobre o desempenho
das versões.
3.1-Etapas cumpridas
As etapas foram cumpridas conforme o proposto no plano inicial, com exceção da
terceira etapa, quando foi necessário adicionar mais um passo, o de redefinição de
estratégias de paralelização do openModeller.
32
Foi necessária uma redução do prazo de conclusão do projeto para 10 meses,
conforme justificado na introdução e no formulário de encaminhamento deste
relatório.
Etapa 1: estudo e familiarização com o sistema openModeller
•
•
Estudo dos princípios de programação paralela, dos fundamentos de
programação orientada a objetos em C++ , familiarização com o OpenMP e
uso do sistema corrente.
Estudo e análise do código do sistema openmodeller corrente.
Etapa 2: desenvolvimento da versão paralela utilizando a interface OpenMP.
•
•
•
Definição da Estratégia de Paralelização.
Implementação no código do openModeller.
Depuração e testes.
Etapa 3: desenvolvimento das versões paralelas utilizando a interface MPI
•
•
•
•
•
Otimização, Depuração e Testes da implementação com o OpenMP;
Estudo de programação e familiarização com o sistema MPI
Redefinição de estratégias de paralelização do openModeller
Implementação usando a interface MPI, para cluster de computadores,
tomando como base a estratégia de paralelismo redefinida nesta etapa e nova
implementação em OpenMP.
Definição e implementação de uma segunda estratégia gerando-se uma nova
versão.
Cronograma
Início: 1 de Setembro de 2006. Duração: 10 meses
1 2
3
4
5
6
7
Etapa 1
A
x
B
x
Etapa 2
A
x
x
B
x
C
x
Etapa 3
A
x
B
x
C
D
E
8
9
10
x
x
x
x
x
4-Detalhamento das atividades realizadas
Foram realizadas atividades de estudo e a implementação paralela do openModeller
utilizando o sistemas OpenMP e MPI.
33
4.1-Estudos de Programação paralela
Os primeiros conceitos de programação paralela a serem estudados foram os de
Macrotasking, Microtasking e laços paralelos. Como método de aprendizagem,
utilizou-se a resolução de pequenos problemas, como multiplicação de matrizes e
soma de seus elementos utilizando processamento paralelo. As soluções eram
implementadas em linguagem C, com uso da biblioteca CPAR [Sato,1995],
desenvolvida por gerações anteriores do Laboratório de Arquitetura e Programação
de Alto Desempenho, LAHPC-USP. Foi possível de se implementar em CPAR:
macrotarefas e microtarefas, laços parelelos e semáforos.
Depois de ganhar familiaridade com os conceitos de paralelismo, iniciou-se o estudo
do OpenMP, biblioteca para multiprocessadores com memória compartilhada. Os
mesmos problemas que eram resolvidos com CPAR foram resolvidos com OpenMP,
sempre observando quais meios de implementação mudavam de uma biblioteca
para outra.
Foram tópicos relevantes da aprendizagem do OpenMP: região paralela, laços
paralelos, variáveis locais e compartilhadas, seção crítica e barreira.
Para que fosse possível a modificação do código do OpenModeller, foi necessário
aprender programação orientada a objetos em C++, bem como a junção desta linha
de programação com a de paralelismo.
Por último foram estudados os conceitos e aplicações de MPI, conforme será
detalhado mais adiante.
4.2- O openModeller
O openModeller é uma implementação de métodos para a predição de distribuição
de espécies baseados no conceito de nichos ecológicos [SOURCEFORGE,2006].
Tais métodos combinam dados de ocorrência de uma determinada espécie com as
condições ambientais em cada ponto. Eles tentam identificar, através de algoritmos
existentes, quais pontos no espaço ambiental têm condições similares entre.
Agrupados, estes pontos representam um modelo de nicho ecológico, dadas as
dimensões ambientais consideradas. Desta forma pode-se se predizer onde a
espécie poderá ou não manter populações, através das projeções destes nichos em
dimensões geográficas.
Esta ferramenta de modelagem, escrita em linguagem C++ ANSI, recebe como
parâmetros um conjunto de pontos de ocorrência (latitude e longitude) de uma
determinada espécie e um conjunto de mapas de variáveis ambientais. Os
algoritmos utilizados na versão corrente do openModeller são: Bioclim, Climate
Space Model, GARP, Environmental Distance e Minimum Distance.
O funcionamento do software se dá em duas etapas: modelagem e projeção. Na
primeira etapa combinam-se os dados de ocorrência da espécie com as condições
ambientais de cada ponto para se obter, através dos algoritmos já citados, um
modelo que representa a viabilidade da espécie sob determinadas condições
ambientais. Na segunda, o modelo é projetado em dimensões geográficas para
predizer onde a espécie poderá ou não manter populações.
Estão envolvidos no desenvolvimento do openModeller a Escola Politécnica da
Universdade de São Paulo (EPUSP), o Instituto Nacional de Pesquisas Espaciais
(INPE) e o Centro de Referência em Formação Ambiental (CRIA).
34
4.3-OpenMP
Serão brevemente descritas as diretivas do OpenMP que se utilizam na
paralelização do openModeller.
O OpenMP é uma biblioteca que suporta a programação paralela de memória
compartilhada em todas as arquiteturas [www.openmp.org]. Está disponível para as
linguagens C/C++ e Fortran, em plataformas do Unix e do Windows NT. A
implementação do paralelismo em OpenMP se faz da seguinte forma:
A região paralela é implementada pela diretiva #pragma omp parallel { região
paralela}.
Variáveis declaradas e objetos criados dentro da região paralela são tidos como
locais. Variáveis declaradas anteriormente à região paralela devem ser
especificadas como privadas ou compartilhadas logo em seguida da chamada da
região paralela: #pragma omp paralllel private(variáveis locais separadas por vírgula)
shared (variáveis compartilhadas separadas por vírgula). Objetos criados
anteriormente à região paralela são compartilhados, enquanto aqueles criados
dentro dela, são locais.
Laços paralelos são implementados através da diretiva #pragma omp for seguida do
for a ser paralelizado. O total de iterações passa a ser dividido entre os processos.
Para se implementar uma seção crítica usa-se #pragma omp critica { região crítica},
e para se impor uma barreira basta usar a diretiva #pragma omp barrier.
Quando se deseja definir o numero de threads que estará presente numa
determinada região paralela, chama-se a função omp_set_num_threads (número de
processos).
Caso não se especifique o número de threads, ele passa a ser o que está definido
numa variável de ambiente. Caso contrário, o número de threads passa a ser o
número de processadores da máquina. Para sabermos qual thread corrente está
executando o código, usamos a função omp_get_thread_num.
4.3- O MPI- Message Passing Interface
4.3.1-Definições
Massage Passing: conjuntos de processos com acesso a uma memória local. A
troca de informações se dá enviando-as da memória local de um processo para a
memória local de um processo remoto.
MPI: trata-se de uma biblioteca de Message Passing desenvolvida para ambientes
de memória distribuída e que fornece funções básicas para a comunicação entre os
processos. Em suas aplicações, o paralelismo é explícito, isto é, o programador é
responsável pela distribuição de tarefas.
4.3.2- Conceitos básicos de MPI
Rank: cada processo é designado, pelo sistema, por um número inteiro de 0 a N-1
(N é o número de processos), este número é chamado de rank.
Grupos: conjunto ordenado de N processos associado a um comunicador.
35
Comunicador: objeto local que representa o contexto de uma comunicação, isto é,
os processos que podem se contatados. Cada grupo pode ter seu comunicador, e o
comunicador associado a todos os processos é o MPI_COMM_WORLD.
4.3.4.Implementações em MPI
As aplicações em MPI podem ser descritas da seguinte forma:
Um problema é dividido em partes que são distribuídas entre os processos para que
cada um faça a sua computação. Quando esta termina um processo mestre recebe
os cálculos que cada processo escravo realizou e continua a execução do programa
baseando-se nos resultados enviados por cada processo.
4.3.5 Funções do MPI utilizadas na paralelização do
openModeller
MPI_Comm_size: retorna o número de processos. Tem como argumentos o
comunicador e o endereço da variável inteira para onde será retornado o número de
processos.
MPI_Comm_rank: : retorna o número do processo que está realizando determinada
tarefa, podendo ser um número de 0 a n-1 (sendo n o numero total de processos).
Tem como argumentos o comunicador e o endereço da variável inteira para onde
será retornado o número do processo.
MPI_Send e MPI_Recv: rotinas básicas de envio e recebimento de mensagens,
respectivamente. Os parâmetros do MPI_Send são, nessa ordem: Endereço do
dado a ser transmitido, número de itens a ser enviado, tipo de dados, destino,
comunicador usado. Analogamente os argumentos do MPI_recv: endereço do dado
a ser transmitido, número de itens a ser enviado, tipo de dados, destino,
comunicador, status da mensagem.
MPI_Barrier: para os processos que chegarem a um ponto determinado da execução do
programa para até que todos os demais processos os “alcancem”.
5- Estratégias de Paralelização do openModeller
Foi paralelizado o módulo de projeção do openModeller, assim como estava previsto
no plano inicial. O processo de paralelização se deu em etapas: localização do
trecho a ser paralelizado, paralelização, compilação e depuração.
5.1- Primeira estratégia
Na primeira estratégia, implementado em OpenMP, foi paralelizado o módulo de
Projeção do openModeller dividindo-o em blocos de lotes que eram executados
simultaneamente e os processos escreviam o resultado em um único arquivo *.tif- a
saída do programa- que consistia num mapa indicador da existência ou não de
determinada espécie.
5.1.1-Localização do trecho a ser paralelizado
Inicialmente, fez-se uma visão panorâmica do código referente à etapa de projeção,
que está estruturada em módulos e é compilado por partes automaticamente através
de um comando makefile. Deu-se maior atenção às regiões que continham laços
36
longos, que são considerados como regiões que demorariam mais tempo de
computação devido à sua complexidade e que seriam possíveis de serem
paralelizadas.
Não foi encontrado algum laço longo com o número de iterações pré-determinado
(comando for) . Todavia foi encontrado um laço — do tipo while — que tem como
critério de parada uma comparação entre objetos, através da sobrecarga do
operador binário de diferença, algo característico do polimorfismo existente na
linguagem C++. Este laço está presente no arquivo Projector.cpp.
O trecho está apresentado a seguir:
MapIterator it = map->begin();
MapIterator fin;
while( it != fin )
{
(…)
++it;
}
Nota-se que, além da sobrecarga do operador diferença, foi usada, nesse trecho, a
sobrecarga do operador de incremento pré-fixado.
5.1.2-Paralelização
A paralelização do while apresentada na seção 4.4.1 requisitou a proposta de uma
solução não trivial, uma vez que a expressão de condição envolvia uma comparação
entre dois objetos, sendo um deles iterado através do operador “++” pré-fixado e o
outro um objeto final. Além disso, era necessário garantir que cada thread fizesse
uma operação com um objeto distinto.
Para resolver estes problemas primeiramente todo o laço foi aninhado por uma
região paralela. Depois, foram criadas variáveis e objetos auxiliares e
compartilhados entre as threads. A variável e o objeto que eram iterados
continuaram sendo elementos locais. Assim, dentro de uma seção crítica, iterava-se
a variável e o objeto compartilhados e depois atribuía-se os valores atualizados aos
componentes locais. Tais componentes continuavam na comparação do while como
critério de parada. Desta forma, fez-se com que cada thread realizasse uma tarefa
diferente e cada uma parasse quando seus componentes locais atendiam o critério
de parada. Além disso, este procedimento permitiu que, se porventura uma thread
fosse mais lenta que os demais, o número de operações realizado por ela seria
menor. Também vale o dual dessa solução: se alguma thread fosse mais rápida ela
realizaria mais operações.
Em continuidade da resolução do problema, para garantir o processamento de
objetos distintos por cada thread, a variável e o objeto foram iniciados dentro de uma
seção crítica. Foi necessário utilizar duas variáveis e objeto auxiliares do tipo
compartilhado. Esta iniciação foi feita da seguinte maneira:
37
1- a variável auxiliar 1 é iniciada anteriormente à região paralela com o valor zero;
2- dentro da região paralela as threads executam segundo a seguinte
sequênciaInicio da seção crítica:
se a variável auxiliar 1 tem o valor zero, a variável auxiliar 2 e a variável
auxiliar 1 recebe 1, o objeto auxiliar tem os seus atributos atualizados com
valores iniciais;
senão, o valor da variável auxiliar 2 é incrementado assim como os atributos
do objeto auxiliar.
a variável e o objeto locais recebem recebem respectivamente o valor da
variável auxiliar 2 e os atributos do objeto auxiliar.
Instala-se uma barreira.
Fim da seção crítica
O efeito desta lógica é fazer com que somente um processo, aquele que “chegar”
primeiro, inicie variável, os demais apenas teriam acesso ao valor através das
variáveis compartilhadas. Tanto a inicialização como a iteração são feitas em seções
críticas e ocorre um certo aumento no número de operações, variáveis e objetos.
Apesar disso, ganha-se tempo na computação global do laço, posto que quase todo
seu restante é feito na forma paralela.
Mostra-se a seguir como ficaram as partes mais relevantes deste trecho. Observa-se
que em (*) todo o corpo do laço é realizado paralelamente:
int temp_it = 0 ;
MapIterator controle_it ;
int controle_pixels;
int temp_pixels=0;
(...) Definição o número de processos e início da região paralela
omp_set_num_threads(2);
#pragma omp parallel shared(temp_contador,temp_pixels,controle_contador,
controle_pixels,pixelcount,pixelstep)
{
#pragma omp critical
{
if( temp_it == 0)
{
controle_pixels=0;
controle_it=map->begin();
temp_it=1; /*modo de alterar temp_it*/
}
else
{
++controle_it;
controle_pixels++;
}
it=controle_it;
}
#pragma omp barrier
38
while( it != fin ) {
(*)
#pragma omp critical
{ controle_pixels++;
pixels=controle_pixels;
++controle_it;
it=controle_it;
} Fim da seção crítica e do laço.
}
Um trecho do código no corpo do while (*) referente à escrita do resultado da
projeção do modelo do objeto foi encerrado numa seção crítica.
Sample amb;
#pragma omp critical
{
Sample const &amb1 = env->get( lg, lt );
amb=amb1;
}
(…)
#pragma omp critical
{
if( amb.size() == 0 )
map->put(lg,lt);
else
map->put(lg,lt,val);
}
5.1.3-Compilação e Depuração
Na compilação foi utilizado o compilador icc da Intel que oferece a linguagem C++ e
o OpenMP. Na depuração foram detectados e solucionados alguns problemas, em
particular aqueles referentes à necessidade de incluir parte do código em seção
crítica.
5.1.4-Testes e análise de desempenho e nova versão
com OpenMP
A implementação e os testes foram realizados em um computador com um
processador dual core com a finalidade de ser verificada a funcionalidade da
implementação e de realizar uma análise preliminar do desempenho.
Em um primeiro teste, utilizando uma massa de dados pequena, verificou-se a
funcionalidade da implementação com o paralelismo.
Contudo, em um segundo teste, aplicado a uma massa de dados maior, realizado
com a finalidade de se ter uma visão preliminar de desempenho obteve-se um
tempo de execução maior do que o obtido sem a paralelização. Detectou-se que o
ponto de gargalo é o trecho de código referente à gravação do resultado da projeção
do modelo no objeto
Em uma primeira tentativa, aplicando-se a paralelização apresentada na seção
5.1.2, não se teve sucesso. Detectou-se o problema na fase de testes, causado pelo
fato de que o procedimento de escrita no mapa é feito por ponteiros locais com
variáveis de deslocamento compartilhadas. Assim, quando um processo escrevia um
39
ponto no mapa, era tomado como referência o ponto de escrita anterior, mas se
fazia o deslocamento determinado pelos incrementos feitos por todos os processos
e não somente pelo local. Tal impropriedade gerava arquivos muito grandes e
totalmente diferentes dos gerados pela versão seqüencial.
Estudando o código do openModeller, notamos que a saída do modo projeção se
resumia em três campos: a latitude, a longitude e o valor do pixel. O mapa era
gerado imprimindo-se na posição determinada, em escala, pela latitude e longitude o
valor do pixel. Adotou-se, então, estratégia de dividir toda a tarefa entre as threads
com cada um armazenando estes três campos em um arquivo de acesso local ao
processo; assim que todos os processos terminassem suas tarefas, o conteúdo
armazenado seria enviado para a thread 0 e inserido no mapa.
A forma adotada para se armazenar os campos foi um array de struct com tamanho
máximo pré-determinado. Cada thread tem um array local, cujo conteúdo é
descarregado em um arquivo na iminência de seu tamanho ultrapassar o
estabelecido. Quando é terminado o laço da Projeção, todo conteúdo ainda restante
no array é gravado no seu arquivo correspondente e é imposta uma barreira , de
modo que nenhum processo avance para a última etapa, até que todos os demais
tenham realizado suas partes. Na última etapa, a thread 0 recebe os arquivos dos
demais processos e imprime no mapa os pixels correspondentes a cada par de
latitude e longitude.
Quanto a funcionalidade, obteve-se sucesso nesta nova versão. Contudo, conforme
pode-se observar na tabela de resultados apresentada a seguir, que mostra os
resultados de testes executados em um computador dual core, o tempo obtido com
a paralelização é maior do que o seqüencial. Detectou-se que a redução no
desempenho é devido ao acesso simultâneo ao disco do computador, buscando
posições em diferentes blocos no disco, adicionado ao fato do sistema OpenMP com
C++ compartilhar todos os objetos criados pelo processo criador das threads, neste
caso, o processo principal do programa, gerando a necessidade de incluir várias
seções críticas ao longo do código, seqüencializando a execução do programa
nestes pontos. Concluiu-se, então, que independentemente do número de
processadores, não se obteria um bom desempenho. Assim sendo, verificou-se que
a paralelização da etapa de Projeção do OpenModeller não é adequada para
computadores paralelos com memória compartilhada. Como se pretendia oferecer
esta versão com OpenMP para disponibilizar o OpenModeller para computadores
paralelos com memória compartilhada, não se investiu em executá-la em um cluster,
o que exigiria pesquisar a disponibilidade de uma plataforma com OpenMP e C++
para cluster. Preferiu-se continuar a execução do cronograma, partindo para o
desenvolvimento de uma versão utilizando MPI com a aplicação desta mesma
estratégia.
Apresenta-se a seguir os resultados obtidos nos testes:
Plataforma :
1 Processador dual core Intel 3.4 GHz
2 GB de RAM
HD IDE-Sata 160GB
Linux Read Hat versão 2.6
40
Implementação
Processadores/Maquina
Número de Máquinas
tempo (s)
Ganho%
Seqüencial
#
#
185
#
Paralela
2
1
228,5
-23,5135
speed up
0,809628
5.2- Segunda Estratégia com implementação utilizando
MPI
Foi implementada uma segunda estratégia equivalente a apresentada na seção 5.1,
utilizando-se aqui a interface MPI.
5.2.1- Testes e análise de desempenho
O programa contém duas partes. Na primeira, os processos efetuam a
projeção do seu respectivo bloco de pixels e geram um arquivo local ao processo no
qual são armazenados os dados de projeção de cada pixel. Na segunda, é efetuada
a transferência dos dados do arquivo de cada processo, por passagem de
mensagem, para o processo 0, que os insere no mapa, gerando o arquivo final
nome_arquivo.tif.
Para analisar o desempenho foram feitos testes em duas plataformas. Uma
plataforma com processadores mais recentes (dual-core), um tamanho maior de
memória e discos mais velozes e com maior capacidade de armazenamento do que
uma segunda plataforma, que contém porém, um número maior de nós de
processamento. Com os testes na plataforma 1 foi possível analisar o
comportamento da aplicação paralela em um ambiente mais atual. Os testes na
plataforma 2, com um número maior de nós, possibilitou a verificação da saturação
do desempenho com um determinado número de nós.
Plataforma 1:
1 Processador dual core Intel 3.4 GHz
2 GB de RAM
HD IDE-Sata 160GB
Linux Read Hat versão 2.6
Plataforma 2:
1 nó com:
2 Processadores Intel Xeon 2.66 GHz
256 MB de RAM
HD
Linux Debian 2.618
4 nós com:
2 Processadores Intel Xeon 2 GHz
512 MB de RAM
HD
Linux Debian 2.618
41
Plataforma 1
Implementaçã
o
Processos/Nó
Número
Nós
Sequencial
#
de
tempo
(s)
Ganho
%
speed
up
#
185
#
#
1
2
182
1,6
1,0
2
1
158
14,5
1,2
2
2
123
33,5
1,5
2 em uma e 1 em
outra
2
133
28,1
1,4
Paralela
Verificou-se um ganho de desempenho de 1,5 , ou seja, uma redução de 33,5% no
tempo de execução em relação ao tempo seqüencial, processando-se com 4
processos, sendo dois em cada nó. Não foi possível a obtenção de maiores
reduções, devido à seqüencialidade implícita na geração do mapa (
nome_arquivo.tif).
Plataforma 2
Implementação
Número de Processos
tempo (s)
Ganho%
speed up
Sequencial
#
2
3
4
5
6
7
8
9
10
275
384
354
309
271
283
281
255
256
247
#
-39,6
-22,3
-12,3
1,45
-2,91
-2,18
7,27
6,91
10,2
#
0,45
0,78
0,89
1,01
0,97
0,98
1,08
1,07
1,1
Paralela
No cálculo do tempo de execução, selecionou-se o maior tempo gasto pelos
processos. O tempo seqüencial foi obtido pela execução da aplicação no nó com
2.66 GHz.
Para um número maior de processos (8, 9 e 10) houve uma diminuição no tempo de
processamento da etapa 1 acompanhada de um aumento no tempo da etapa 2,
resultando em um pequeno ganho de desempenho. Não foi possível observar com o
número de nós disponíveis, a saturação esperada com um número determinado de
nós, decorrente do aumento de mensagens e do tempo mínimo gasto pela geração
do mapa sem nenhuma troca de mensagens.
42
5.3- Terceira Estratégia com implementação utilizando
MPI
A segunda estratégia baseia-se na divisão das projeções nos pontos do mapa no
módulo de Projeção, onde cada processo efetua a projeção para um bloco de pontos
e escreve em arquivos distintos e a reunião destes é feita pelo processo 0.
O módulo Projeção gera um arquivo *.tif composto de um cabeçalho e o resultado da
projeção. Neste estratégia, manteve-se o cabeçalho e o restante do arquivo foi
dividido em N blocos, onde N é o número de processos. Cada bloco é computado
paralelamente e impresso em um arquivo auxiliar.
Em uma primeira etapa, o primeiro processo escreve o cabeçalho e o último bloco,
gerando o arquivo nome_arquivo.tif (arquivo que conterá o resultado final). O
segundo escreve o cabeçalho e o penúltimo bloco, gerando o arquivo
nome_arquivo_1.tf. O n-ésimo processo escreve o cabeçalho e o primeiro bloco,
gerando o arquivo nome_arquivo_n-1.tif. Como não foi possível escrever
diretamente cada bloco na sua respectiva posição no arquivo correspondente a cada
processo, sem tratar as posições anteriores, devido ao formato e geração do arquivo
.tif, procedemos da seguinte forma: foi impresso o cabeçalho e depois o valor 255 ,
que corresponde a nenhum valor de cor, até chegarmos a posição do primeiro pixel
do bloco. Como os processos não realizam cálculo complexo para imprimir 255, a
computação do trecho inútil é rápida,.cada um deles chega rapidamente a posição
determinada no arquivo.
Em uma segunda etapa é realizada a transferência dos dados de cada bloco
respectivo a cada processo para o processo 0 que os grava no arquivo
nome_arquivo.tif. Esta transferência, realizada através de envio e recebimento de
mensagem, inicia-se pelo processo1, sendo gravado o penúltimo bloco no arquivo
nome_arquivo.tif e termina com a transferência pelo n-ésimo processo (n é o número
de processos), com o processo 0 gravando o primeiro bloco de pixels, e gerandos- o
arquivo final nome_arquivo.tif. Esta operação de inclusão dos blocos, embora
realizada seqüencialmente, demora pouco tempo para ser realizada se comparada
com o tempo de computação total do programa.
Para acelerar o processo, a transferência de dados do arquivo de cada processo
para o processo 0 e a sua inclusão no mapa, foi efetuado a partir da posição
calculada como segue:
posição=total_pixels/N *k , onde k é o número identificador do processo MPI (k=0 a
N-1).
5.3.1- Testes e análise de desempenho
Para analisar o desempenho foram feitos testes na plataforma 1 e plataforma 2,
descritas na seção 5.2.1.
Plataforma 1
Implementaç
ão
Sequencial
Paralela
Processadores/Maqui
na
#
1
2
2
2 em uma e 1 em
outra
Número
Máquinas
de
tempo
(s)
Ganho
%
speed
up
#
2
1
2
185
152
152
116
#
17,8
17,7
37,3
#
1,2
1,2
1,6
2
127
31,3
1,5
43
Obteve-se nos testes na plataforma um ganho de desempenho de cerca de 1,6, ou
seja, uma redução de 37,3 % com 4 processadores, sendo 2 em cada nó. Nestes
testes, pode-se observar um ganho de desempenho decorrente do processamento
paralelo na parte 1 do programa. Não se pode observar, entretanto, o impacto da
comunicação entre nós, presente na transferência dos dados de cada processo para
o processo 0, uma vez que todos os processos se encontram no único nó.
Plataforma 2
número
processos
Seqüencial
2
3
4
5
6
7
8
9
10
de
parte 1
parte 2
323
283
242
228
219
217
210
213
213
2
2
2
2
11
12
11
12
12
Tempo
275
325
285
244
230
230
229
221
225
225
Ganho % speedup
-18,1818
-3,63636
11,27273
16,36364
16,36364
16,72727
19,63636
18,18182
18,18182
0,846154
0,964912
1,127049
1,195652
1,195652
1,200873
1,244344
1,222222
1,222222
A estratégia de acelerar o processamento da parte 2 do programa, efetuando-se a
transferência de cada processo para o processo 0 a partir de uma posição no
arquivo próxima e anterior ao início do respectivo bloco de dados, conforme o
cálculo apresentado, mostrou-se eficiente, resultando em uma estabilidade no
aumento do tempo na parte 2.
Observa-se a saturação no ganho de desempenho com 8 processos, sendo que a
partir deste número de processos não há redução no processamento da parte 1.
Esta saturação é causada pela seqüencialidade na geração do mapa, com a
necessidade de cada processo gravar dados no arquivo nas posições anteriores ao
início do seu respectivo bloco, como também pelo alto custo de acesso ao disco
nesta plataforma.
6-Conclusão
Os estudos realizados sobre C++ e programação paralela proveram a
fundamentação necessária para o desenvolvimento da implementação.
Desenvolveu-se uma versão ainda preliminar utilizando o OpenMP, que demonstrou
a sua funcionalidade mas não apresentou um ganho de desempenho em relação a
versão seqüencial.
A terceira estratégia mostrou-se mais adequada. Contudo, com as plataformas
disponíveis para os testes, não foi possível verificar o seu comportamento em um
cluster com melhores recursos de processamento, disco e comunicação entre os
nós. Esta avaliação será realizada pela equipe do projeto OpenModeller no
momento em que o cluster que foi adquirido e que se encontra ainda em instalação
estiver disponível para uso. Prevê-se um melhor ganho de desempenho,
especialmente devido à conexão de alta velocidade, presente neste cluster, assim
como as características dos recursos de processamento e de armazenamento.
44
Referências Bibliográficas
Anderson, R. P., D. Lew, & A. T. Peterson. 2003. Using intermodel variation in error
components to select best subsets of ecological niche models. Ecological
Modelling 162:211-232.
Anderson, R. P., M. Laverde, & A. T. Peterson. 2002a. Geographical distributions of
spiny pocket mice in South America: Insights from predictive models. Global
Ecology and Biogeography 11:131-141.
Anderson, R. P., M. Laverde, & A. T. Peterson. 2002b. Using niche-based GIS
modeling to test geographic predictions of competitive exclusion and competitive
release in South American pocket mice. Oikos 93:3-16
Ben-Ari, M. 1948. Principles of concurrent and distributed programing.
Peterson, A. T. 2001. Predicting species' geographic distributions based on
ecological niche modeling. Condor 103:599-605.
Peterson, A. T., & K. C. Cohoon. 1999. Sensitivity of distributional prediction
algorithms to geographic data completeness. Ecological Modelling 117:159-164.
Peterson, A. T. & Vieglais., D. A. 2001. "Predicting species invasions using
ecological niche modeling." BioScience 51: 363-371.
Sato, Líria M., Midorikawa, Edson T., Senger, Hermes. 1996. Introdução a
Programação
Paralela
e
Distribuída.<www.unisantos.br/mestrado/informatica/hermes/File/apost.pdf.>
Acessado em 28/09/2006.
Sato, Líria M. 1995. Ambientes de programação para sistemas paralelos e
distribuidos. Tese de Livre-docência da Escola Politécnica da Universidade de
São Paulo (EPUSP).
SOURCE FORGE. Portal do Projeto OpenModeller. Disponível
<http://openmodeller.sourceforge.net>. Acesso em 30/10/2006.
em:
Snir,M., Otto,S., Huss-Lederman,S., Walker,D., Dongarra,J. MPI: the complete
reference. <http://www.netlib.org/utk/papers/mpi-book/mpi-book.html>. Acesso
em 02/06/2006.
Stroustrup's, Bjarme. 2000. The C++ Programing Language (Special Edition).
<http://www.openmp.org/drupal/mp-documents/spec25.pdf> . Tutorial. Extraído em
20/09/2006
45
Annex 4. Parallel versions of the projection for
computer clusters
VERSÕES PARALELAS DA PROJEÇÃO PARA
CLUSTER DE COMPUTADORES
Autora: Liria Matsumoto Sato
1) Introdução
Foram implementadas 4 versões paralelas do Openmodeller. Três delas utilizando a
interface MPI: versão 2, versão 3 e versão 4.
A versão 3 e a versão 4 serão apresentadas neste anexo.As duas versões foram
executadas no cluster do projeto utilizando números variados de processos.
O cluster contém um nó de entrada e 10 nós para processamento das aplicações.
Cada nó contém seu próprio disco, 2 processadores quad Xeon e 8GB de memória
RAM. Nos testes utilizando até 10 processos, cada processo foi alocado em um nó.
Nos testes utilizando mais de 10 processos, mais de um processador foi utilizado em
alguns nós. Analisando-se as tabelas de tempo de execução relativas a cada
versão, apresentadas na seção 2 e seção 3 deste anexo, nota-se a superioridade da
versão2.
Nos testes foram aplicados dois experimentos:
Experimento 1: algoritmo Environmental Distance
map e output map: bio, prec, tmax, tmin
Output mask: Brasil
Total de pixels: 24834568
Experimento 2: algoritmo Environmental Distance
map e output map: bio, prec, tmax, tmin
Output mask: Brasil
Total de pixels: 777600000
O código da implementação original contém uma etapa da aplicação, referente a
geração do arquivo resultante no formato .tif, que exige uma execução seqüencial.
No experimento 2, em um total de tempo de execução seqüencial de 3422
segundos, cerca de 1638 segundos são gastos nesta etapa. Na versão 3 e na
versão 4, obteve-se com 10 nós um tempo de execução menor que 1638 segundos.
Esta redução deve ter decorrido não apenas pelo processamento paralelo como
também possivelmente do melhor uso da memória.
2) Versão 3
Cada nó gera um arquivo intermediário contendo a probabilidade associada para
cada pixel foi proposta e implementada. Nesta versão, o total de pixel foi
particionado em blocos de tamanhos iguais, com o nó 0 executando também o resto
da divisão dos blocos entre os nós. O nó 0 recebe os arquivos intermediários dos
demais nós e gera o arquivo final no formato .tif.
46
A aplicação foi executada no cluster do projeto utilizando-se números variados de
processos.
A tabela 1 e a tabela 2 mostram os tempos de execução obtidos utilizando um
conjunto variado de nós para o experimento 1 e 2 respectivamente.
Seqüencial
231
4 nós
162
8 nós
89
10 nós
83
10 nós
10 nós
(11 proc.)
(12 proc.)
80
72
10 nós (13 proc.)
10 nós
(14 proc.)
67
65
Tabela 1: tempos de execução (em segundos) do experimento 1 (versão 3)
Seqüencial 4
nós
8
nós
3422
10
nós
10 nós
10 nós
(11
proc.)
(12
proc.)
1653
1504
1458
10 nós (13 10 nós (14
proc.)
proc.)
1449
1410
Tabela 2: tempos de execução (em segundos) do experimento 2 (versão 3)
2) Versão 2
Esta versão difere da versão 3, pois aplica uma estratégia em que não há a
necessidade de gerar arquivos intermediários e distribue dinamicamente blocos de
pixels sob demanda de cada nó ao terminar a execução de um bloco. Desta forma, o
tempo de execução desta versão é menor do que a versão 1, pois elimina o tempo
gasto na escrita e leitura dos arquivos intermediários e provê uma distribuição mais
adequada da demanda de processamento. Nesta versão, cada nó requisita um
bloco de pixels ao processo que gerencia a distribuição, processa a projeção para os
pixels do bloco, armazena os resultados em um “buffer”, e após tratar todo o bloco,
transfere para o nó 0 os dados do buffer. A seguir, solicita um novo bloco. O nó 0
abriga o processo que recebe as informações de probabilidade de cada pixels dos
demais nós e gera o arquivo final .tif.
A tabela 3 e a tabela 4 mostram os tempos de execução obtidos utilizando um
conjunto variado de nós para o experimento 1 e 2 respectivamente.
Seqüencial 4
nós
8
nós
10
nós
10 nós
10 nós
(11
proc.)
(12
proc.)
231
61
48
44
41
146
10 nós (13 10 nós (14
proc.)
proc.)
40
40
Tabela 3: tempos de execução (em segundos) do experimento 1 (versão 4)
Seqüencial 4
nós
8
nós
10
nós
10 nós
10 nós
(11
proc.)
(12
proc.)
3422
1299
1201
1163
1151
1988
10 nós (13 10 nós (13
proc.)
proc.)
1120
1117
Tabela 4: tempos de execução (em segundos) do experimento 2 (versão 4)
47
Annex 5. Manual for the installation of a services
platform