1. Aimee Stewart (KU) astewart@ku.edu Nadya Williams (UCSD) nadya@sdsc.edu

3. Lifemapper Data library – Climate Observed IPCC Predicted Future Climate – Species Occurrence Points Potential habitat maps Tools – LmSDM: Species Distribution Modeling – LmRAD: Range and Diversity GBIF

4. LmSDM: Species Distribution Modeling Species Occurrence Data Potential Habitat Environmental Data

5. LmRAD: Range and Diversity Species Habitat Data Presence Absence Matrix (PAM) Range and Diversity Quantifications Multi-species analyses

6. External Clients QGIS, Browser, Python Client Visualize, Explore, Analyze LmDbServer Pipeline Data updater Job tracker Climate Predicted habitat PAM assembly Maps & Models LmWebServer Website REST Web Services Submit job Request data Post result LmCompute Actual/Virtual cluster LmSDM LmRAD LmCompute Actual/Virtual cluster LmSDM LmRAD LmCompute Actual/Virtual cluster LmSDM LmRAD Species KU SDSC UF

9. Increase availability and flexibility of Lifemapper Server as a complete system – reduce cost of installing/configuring/replicating and ease burden of integrating hardware and software Enable a fast “workflow” from software update to server availability: – Minimize time spent on software build and configuration – Automate most hands-on tasks. – Essential: have test cases for all installed components and their configuration Prepare for greater quantity and quality of data and complexity of operations – From low resolution climate data to high resolution satellite imagery for Mt. Kinabalu – From simple single-species SDM experiments to multi- species macro-ecology experiments with more species This work is a part of PRAGMA’s “Resources and Data” working group Build production server Development Production Lifemapper http://lifemapper.org https://github.com/lifemapper/ Rocks http://www.rocksclusters.org Pragmagrid GitHub https://github.com/pragmagrid/lifemapper https://github.com/pragmagrid/lifemapper-server

10. Manual hands-on tasks: Software packages build Custom scripts User work-around Repetitive tedious functions Tracking errors, exceptions and problems Automation is no longer nice to have it is a must have that allows to: Know your system real-time status: what is installed, what version, configuration, data population Robust system: can reliably build and rebuild Address complexity of configuring – no more manual settings What issues need to be documented? Facilitate easy-to-use solution to provide seamless integration of hw/sw Allow to virtualize infrastructure to improve hw utilization and scalability Enable operational efficiency and flexibility: deployment and operation of virtual servers Enables to clone multiple servers Time

11. Lifemapper LM code Hdf44/hdf5 Subversion Cmake Byacc Libraries Gdal Geos Mod_python SpatialIndex Tiff LM data Dependencies Postgresql Pgdg repo Server Client Devel Contrib Openssl Postgis Geos Proj Pgbouncer Python modules Cheetah Cherrypy Cython Psycopg2 Pylucene Rtree Mapserver Elgis repo Vera fonts Fribidi Total: 56 RPMS Configuration Pgbouncer Postgresql Postgis LM components

12. Scripts for hands-on tasks (previously done only once): Software build Data population Configuration Monitoring Troubleshooting For build and post-install stages for installed components and their configuration during the. Datasets to emulate application’s run-time workflow Large changes in the build process Differences in dependencies and configuration between Linux flavors: Ubuntu vs. CentOS Simplify, harden and streamline code What are SW installation defaults and configuration Application “minimal resources” requirements (i.e. what memory/disk/network/other is needed for application to work) changed with different hardware and data Can not make any assumptions about the system Software refactoring Need automation Need unit tests

13. Data integration – generalize more to use heterogeneous datasets from different sources Cloud approach – Extend and leverage with PCC and PRAGMA_Boot Virtualized environment testing – Storage system – Performance estimates – What I/O volume can we handle without degraded performance? – Check for “storage I/O blender effect” Need to define requirements for – performance – data storage – data management Need to “translate” application/data requirements when application is moved from physical to virtual servers – Is there a bottleneck? – What is needed for IO-intensive application (database)?

14. Acknowledgements This work is funded in part by National Science Foundation and NASA grants PRAGMA US NSF 1234953 Lifemapper US NSF EPSCoR 0553722 US NSF EPSCoR 0919443 US NSF EHR/DRL 0918590 US NSF BIO/DBI 0851290 US NSF OCI/CI-TEAM 0753336 US NASA NNX12AF45A Rocks US NSF OCI-1032778 US NSF OCI-0721623

15. Aimee Stewart (KU) astewart@ku.edu Nadya Williams (UCSD) nadya@sdsc.edu