DOCSLIB.ORG

The Opendaylight Open Source Project

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Opendaylight Open Source Project UNIVERSIDAD REY JUAN CARLOS Master´ Universitario en Software Libre Curso Academico´ 2014/2015 Proyecto Fin de Master´ The OpenDaylight Open Source Project Autor: Sergio Najib Arroutbi Braojos Tutor: Dr. Gregorio Robles 2 Agradecimientos A mi familia y a mi pareja, por su apoyo incondicional Al equipo de Libresoft de la Universidad Rey Juan Carlos, por su afan´ en ensenar˜ el que´ y el porque´ del Software Libre Dedicatoria Para todos aquellos´ que hacen posible el fenomeno´ del Software Libre 4 (C) 2014 Sergio Najib Arroutbi Braojos. Some rights reserved. This document is distributed under the Creative Commons Attribution-ShareAlike 3.0 license, available in http://creativecommons.org/licenses/by-sa/3.0/ Source files for this document are available at http://github.com/sarroutbi/MFP/opendaylight/ 6 Contents 1 Introduction 19 1.1 Terminology.................................... 19 1.1.1 Open Source Programmable Networking................ 19 1.2 About this document............................... 20 1.2.1 Document structure............................ 20 1.2.2 Scope................................... 21 1.2.3 Methodology............................... 21 2 Goals and Objectives 23 2.1 General Objectives................................ 23 2.2 Subobjectives................................... 23 2.2.1 Acquire competence on OpenDaylight project.............. 23 2.2.2 Analyze OpenDaylight project from an Open Source perspective.... 24 2.2.3 Statistics and measures of the OpenDaylight project.......... 24 3 OpenDaylight: A first view 25 3.1 OpenDaylight Project............................... 25 3.2 SDN........................................ 29 3.2.1 What is SDN?.............................. 29 3.2.2 SDN: Market share and expectations................... 31 3.3 NFV........................................ 34 3.3.1 What is NFV?.............................. 35 3.3.2 SDN/NFV relationship.......................... 36 3.3.3 NFV benefits............................... 37 7 8 CONTENTS 4 OpenDaylight: Economic Aspects 39 4.1 SDN and NFV: A new market.......................... 40 4.2 SDN/NFV with OpenDaylight: Software Cost Reduction............ 43 4.3 SDN/NFV technology: Cost Reduction...................... 45 4.4 OpenDaylight: Economic Aspects to go Open Source.............. 49 4.4.1 Technology Adoption........................... 49 4.4.2 The Operator’s View........................... 51 5 OpenDaylight: Legal Aspects 57 5.1 OpenDaylight License: EPLv1.0......................... 57 5.1.1 History Of The Eclipse Public License.................. 60 5.1.2 Main Features of EPLv1.0........................ 61 5.1.3 Other Software Development Considerations.............. 61 5.2 Other Licensing Considerations......................... 63 5.3 Bylaws...................................... 65 6 OpenDaylight: Governance and Community Management 67 6.1 OpenDaylight Project Governance........................ 67 6.1.1 Technical Steering Committee (TSC).................. 68 6.1.2 Board of Directors............................ 70 6.2 OpenDaylight Community Management..................... 71 6.2.1 Communication Channels........................ 72 6.2.2 Community Tools............................. 73 6.2.3 Marketing and Community Building................... 76 7 OpenDaylight: Technical Aspects 81 7.1 Technical Overview................................ 81 7.2 OpenDaylight Projects.............................. 84 7.3 OpenDaylight Source Code............................ 91 7.4 Release Roadmap................................. 97 8 OpenDaylight: Project Evaluation 103 8.1 Metrics...................................... 104 CONTENTS 9 8.2 Tools and Data Sources.............................. 105 8.3 Metrics Analysis................................. 107 8.3.1 Source Code Metrics........................... 108 8.3.2 Mailing List Activity........................... 117 8.3.3 Q&A Activity............................... 125 8.3.4 Bug discussion and close efficiency................... 131 9 Conclusions 145 9.1 Evaluation..................................... 145 9.2 Lessons learned.................................. 146 9.2.1 Lesson 1: Why Open Source?...................... 146 9.2.2 What I learned.............................. 147 9.2.3 Knowledge and skills acquired in the M.Sc. studies that helped me in this work................................. 147 9.3 Future work.................................... 148 9.3.1 More on.................................... 148 9.3.2 Other aspects............................... 149 9.3.3 Other focuses............................... 149 A EPLv1.0 151 B Bylaws Summary 157 C TSC Charter 173 D TSC Policy 179 E Mail Lists 181 Bibliography 187 10 CONTENTS List of Figures 3.1 SDN 3 Layer Architecture............................ 31 3.2 SDN Market: 2018 SDNCentral estimations................... 33 3.3 Vision of Network Functions Virtualization................... 36 3.4 Network Functions Virtualization relationship with SDN............ 37 4.1 Gartner Hype Cycle................................ 40 4.2 SDN Hype Cycle................................. 42 4.3 Open Source Software: Service Revenue Increase................ 44 4.4 Open Source Software: More potential customers................ 45 4.5 Mobile Backhaul Network Invest Expected................... 46 4.6 2017 SDN CAPEX Reduction Cost....................... 47 4.7 2017 SDN OPEX Reduction Cost........................ 48 4.8 NFV Reduction Cost............................... 49 4.9 Open Source on SDN/NFV - A requirement analysis.............. 54 4.10 Open Systems and Open Source: The SDN linkage............... 55 7.1 OpenDaylight Architecture Diagram....................... 83 7.2 OpenDaylight Controller............................. 86 7.3 OpenDaylight Programming Language Distribution............... 97 7.4 OpenDaylight LOC based Project Distribution.................. 98 7.5 OpenDaylight Hydrogen Architecture Diagram................. 99 7.6 OpenDaylight Helium New Features Diagram.................. 100 7.7 OpenDaylight Projects Life Cycle........................ 101 8.1 OpenDaylight Project Onion Model....................... 114 11 12 LIST OF FIGURES 8.2 OpenDaylight Project Commits Per Month.................... 117 8.3 OpenDaylight Project Mail Messages Per Month................ 124 8.4 OpenDaylight Project Q&A Questions Per Month................ 130 8.5 OpenDaylight Project Q&A Answers Per Month................ 131 8.6 OpenDaylight Bug Status Percentage....................... 135 8.7 OpenDaylight Project Bugs Opened Per Month................. 139 8.8 OpenDaylight Project Bugs Resolved Per Month................ 141 8.9 OpenDaylight Project BMI (Resolved vs. Opened)............... 142 List of Tables 1.1 Structure of this thesis............................... 20 3.1 SDN 2018 Sub-Market Expectations....................... 32 4.1 SDN 2017 OPEX Savings Estimations...................... 48 6.1 Example of OpenDaylight’s OpenDove Project mail lists............ 73 7.1 OpenDaylight projects’ repositories....................... 92 7.2 OpenDaylight projects’ LOC distribution.................... 96 8.1 OpenDaylight top 20 committers......................... 110 8.2 OpenDaylight top 20 committer companies................... 111 8.3 OpenDaylight top 20 most active mail lists.................... 120 8.4 OpenDaylight top 20 mail lists with the most users involved.......... 121 8.5 OpenDaylight top 10 people asking on Q&A OpenDaylight project....... 128 8.6 OpenDaylight top 10 answering people on Q&A OpenDaylight project..... 129 8.7 OpenDaylight top 10 people with higher reputation on Q&A OpenDaylight project129 8.8 OpenDaylight top 10 most BUG resolutive people................ 136 B.1 OpenDaylight Bylaws Summary: Article I.................... 157 B.2 OpenDaylight Bylaws Summary: Article II................... 158 B.3 OpenDaylight Bylaws Summary: Article III................... 158 B.4 OpenDaylight Bylaws Summary: Article IV................... 159 B.5 OpenDaylight Bylaws Summary: Article IV................... 160 B.6 OpenDaylight Bylaws Summary: Article V................... 161 B.7 OpenDaylight Bylaws Summary: Article VI................... 162 13 14 LIST OF TABLES B.8 OpenDaylight Bylaws Summary: Article VI................... 163 B.9 OpenDaylight Bylaws Summary: Article VII.................. 164 B.10 OpenDaylight Bylaws Summary: Article VIII.................. 165 B.11 OpenDaylight Bylaws Summary: Article VIII.................. 166 B.12 OpenDaylight Bylaws Summary: Article IX................... 167 B.13 OpenDaylight Bylaws Summary: Article X................... 168 B.14 OpenDaylight Bylaws Summary: Article XI................... 169 B.15 OpenDaylight Bylaws Summary: Article XII.................. 170 B.16 OpenDaylight Bylaws Summary: Article XIII.................. 171 B.17 OpenDaylight Bylaws Summary: Article XIV.................. 172 E.1 OpenDaylight’s OpenDove Project mail lists................... 186 Summary The main goal of this work is to perform a comprehensive analysis of the OpenDaylight Open Source Project. This collaborative project, hosted by the Linux Foundation, has been created in order to achieve following goal: Develop an Open Source Programmable Networking Plat- form. In this document, a detailed study of many different aspects having to do with a project of this type of characteristics will be analyzed. Examples of these aspects are, for instance, the licensing mechanisms adopted by the project, the community behind the project, descriptive statistics about the project, the economic aspects around the project, the
Load more

Recommended publications
  • Defect Tracking System Project Documentation
    Defect Tracking System Project Documentation Tottering Barr azotise some Faust and gyps his surplices so sweetly! Northrup remains impellent after Sigfried havers nominally or fluorescing any good-byes. Remus orientalize thunderously? So much like automation and project defect tracking documentation but not win any kind of the organization tries to track the list by the beginning development team and let an. The amount of tracking system project defect tracking system! All comments are moderated before publication and desire meet our guidelines. Testing is a lousy part of mature software life cycle, and recent trends in software engineering evidence the importance all this activity all survey the development process. Diving deeper into program language theory is a great way data grow outside a developer. Your comment has been received. Bug reporting by the Web and email. Her homeland of interests are Wireless Networks and Database Management Systems. As projects grow in size and complexity, the limits of an Excel story for tracking issues begin to show which quickly. Thank who for using our services. Ten reports engine is a few lines of system project defect tracking documentation appears every single pane contains the. Defect tracking is responsible system authority is applied for any system software so run system performs well. User interface and learning curve the system user interfaces are more user friendly than others. Switch to fullscreen mode always show business bug attributes at once. Some custom structure for large body usually, evaluating and tracking system project defect documentation related documents, planning with your development organization efficiently and eliminate bad.
    [Show full text]
  • Common Tools for Team Collaboration Problem: Working with a Team (Especially Remotely) Can Be Difficult
    Common Tools for Team Collaboration Problem: Working with a team (especially remotely) can be difficult. ▹ Team members might have a different idea for the project ▹ Two or more team members could end up doing the same work ▹ Or a few team members have nothing to do Solutions: A combination of few tools. ▹ Communication channels ▹ Wikis ▹ Task manager ▹ Version Control ￭ We’ll be going in depth with this one! Important! The tools are only as good as your team uses them. Make sure all of your team members agree on what tools to use, and train them thoroughly! Communication Channels Purpose: Communication channels provide a way to have team members remotely communicate with one another. Ideally, the channel will attempt to emulate, as closely as possible, what communication would be like if all of your team members were in the same office. Wait, why not email? ▹ No voice support ￭ Text alone is not a sufficient form of communication ▹ Too slow, no obvious support for notifications ▹ Lack of flexibility in grouping people Tools: ▹ Discord ￭ discordapp.com ▹ Slack ￭ slack.com ▹ Riot.im ￭ about.riot.im Discord: Originally used for voice-chat for gaming, Discord provides: ▹ Voice & video conferencing ▹ Text communication, separated by channels ▹ File-sharing ▹ Private communications ▹ A mobile, web, and desktop app Slack: A business-oriented text communication that also supports: ▹ Everything Discord does, plus... ▹ Threaded conversations Riot.im: A self-hosted, open-source alternative to Slack Wikis Purpose: Professionally used as a collaborative game design document, a wiki is a synchronized documentation tool that retains a thorough history of changes that occured on each page.
    [Show full text]
  • Tuto Documentation Release 0.1.0
    Tuto Documentation Release 0.1.0 DevOps people 2020-05-09 09H16 CONTENTS 1 Documentation news 3 1.1 Documentation news 2020........................................3 1.1.1 New features of sphinx.ext.autodoc (typing) in sphinx 2.4.0 (2020-02-09)..........3 1.1.2 Hypermodern Python Chapter 5: Documentation (2020-01-29) by https://twitter.com/cjolowicz/..................................3 1.2 Documentation news 2018........................................4 1.2.1 Pratical sphinx (2018-05-12, pycon2018)...........................4 1.2.2 Markdown Descriptions on PyPI (2018-03-16)........................4 1.2.3 Bringing interactive examples to MDN.............................5 1.3 Documentation news 2017........................................5 1.3.1 Autodoc-style extraction into Sphinx for your JS project...................5 1.4 Documentation news 2016........................................5 1.4.1 La documentation linux utilise sphinx.............................5 2 Documentation Advices 7 2.1 You are what you document (Monday, May 5, 2014)..........................8 2.2 Rédaction technique...........................................8 2.2.1 Libérez vos informations de leurs silos.............................8 2.2.2 Intégrer la documentation aux processus de développement..................8 2.3 13 Things People Hate about Your Open Source Docs.........................9 2.4 Beautiful docs.............................................. 10 2.5 Designing Great API Docs (11 Jan 2012)................................ 10 2.6 Docness.................................................
    [Show full text]
  • Návrh a Implementace Rozšíření Do Systému Phabricator
    Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Na tomto místě se v tištěné práci nachází oficiální podepsané zadání práce a prohlášení autora školního díla. Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Lukáš Jagoš Vedoucí práce: Martin Komenda i Poděkování Srdečně chci na tomto místě poděkovat vedoucímu mé diplomové práce RNDr. Martinu Komendovi, Ph.D. za cenné náměty a odborné vedení. Dále chci poděkovat Mgr. Matěji Karolyi za všestrannou po- moc při implementaci praktické části práce a Ing. Mgr. Janu Krejčímu za zpřístupnění testovacího serveru a technickou podporu. iii Shrnutí Diplomová práce se zabývá nástroji pro projektové řízení. V teore- tické části jsou vymezeny pojmy projekt a projektové řízení. Poté jsou představeny vybrané softwarové nástroje pro projektové řízení a je provedeno jejich srovnání. Pozornost je zaměřena na systém Phabrica- tor, který je v práci detailně popsán. V praktické části je navrženo rozšíření Phabricatoru na základě analýzy potřeb a sběru požadavků. Výsledkem je rozšířující modul po- skytující přehledné informace o úkolech z pohledu času a náročnosti, čímž zefektivní jejich plánování a proces týmové spolupráce. iv Klíčová slova projektové řízení, Phabricator, PHP, reportovací modul, SCRUM v Obsah 1 Projektové řízení 3 1.1 Projekt a projektové řízení ..................3 1.2 SW nástroje pro projektové řízení ...............4 1.3 Přehled nástrojů z oblasti řízení projektů ...........6 1.3.1 Phabricator .
    [Show full text]
  • Project Management Software March 2019
    PROJECT MANAGEMENT SOFTWARE MARCH 2019 Powered by Methodology CONTENTS 3 Introduction 5 Defining Project Management Software 6 FrontRunners (Small Vendors) 8 FrontRunners (Enterprise Vendors) 10 Runners Up 22 Methodology Basics 2 INTRODUCTION his FrontRunners analysis minimum qualifying score of 3.96 Tis a data-driven assessment for Usability and 3.91 for User identifying products in the Project Recommended, while the Small Management software market that Vendor graphic had a minimum offer the best capability and value qualifying score of 4.55 for Usability for small businesses. For a given and 4.38 for User Recommended. market, products are evaluated and given a score for Usability (x-axis) To be considered for the Project and User Recommended (y-axis). Management FrontRunners, a FrontRunners then plots 10-15 product needed a minimum of 20 products each on a Small Vendor user reviews published within 18 and an Enterprise Vendor graphic, months of the evaluation period. based on vendor business size, per Products needed a minimum user category. rating score of 3.0 for both Usability and User Recommended in both In the Project Management the Small and Enterprise graphics. FrontRunners infographic, the Enterprise Vendor graphic had a 3 INTRODUCTION The minimum score cutoff to be included in the FrontRunners graphic varies by category, depending on the range of scores in each category. No product with a score less than 3.0 in either dimension is included in any FrontRunners graphic. For products included, the Usability and User Recommended scores determine their positions on the FrontRunners graphic. 4 DEFINING PROJECT MANAGEMENT SOFTWARE roject management software and document management, as well Phelps organizations manage as at least one of the following: time and deliver projects on time, on tracking, budgeting, and resource budget and within scope.
    [Show full text]
  • Customization of an Enterprise Request Management System
    ISSN (Online) 2393-8021 ISSN (Print) 2394-1588 International Advanced Research Journal in Science, Engineering and Technology Vol. 2, Issue 2, February 2015 Customization of an Enterprise request Management System 1 2 3 4 Ashna Shah , Chinmay Balutkar , Bhargavee Singh , Rajesh. B. Singh Student, Computer Department, Sinhgad Institute Of technology, Lonavala, India 1,2,3 Associate Professor, Computer Department, Sinhgad Institute Of technology, Lonavala, India4 Abstract: Information provided in issue reports are relevant and complete in order to help resolve issues quickly. However, often such information trickles to developers after several iterations of communication between End user and reporters. This paper addresses the concerns of Customization of an Enterprise management system by proposing for handling of the issues such as bugs, query and enhancements. As a proof-of-concept, we also demonstrate a prototype interactive enterprise request management system that gathers relevant information from the user and identifies files that need to be fixed to resolve the issues. The main contribution of this application is in the domain of business as we are developing Enterprise request Management System. Keywords: Bugs, Issues, query, enhancement. I. INTRODUCTION The use of Enterprise Request Management Systems as a to the issue and again will report the issue to the reporter. tool to organize maintenance activities is widespread. The Developer then will handle the issues and will fix them. systems serve as a central repository for monitoring the This system will help to manage the issues in the business progress of issue reports, requesting additional information domain by fixing them. The issues might be a bug, query from reporters, and discussing potential solutions for or the enhancement.
    [Show full text]
  • Onapp Admin Guide
    2.0 Admin Guide 2.0 Admin Guide Contents 0. About This Guide ............................................................................................... 5 1. OnApp Overview ................................................................................................ 6 1.1 Servers ................................................................................................................... 6 1.2 Networks ................................................................................................................ 7 1.3 Templates .............................................................................................................. 8 1.4 Virtual Machines .................................................................................................... 8 1.5 Scalability .............................................................................................................. 8 1.6 Availability and Reliability .................................................................................... 8 1.7 Security .................................................................................................................. 9 1.8 API and Integration ............................................................................................... 9 2. OnApp Hardware & Software Requirements ................................................. 10 2.1 Hypervisor Servers ............................................................................................. 10 2.2 Control Panel Server ..........................................................................................
    [Show full text]
  • Atlassian Is Primed to Widen Its Appeal Beyond IT
    Seth Agulnick, [email protected] REPORT Atlassian Is Primed to Widen Its Appeal Beyond IT Companies: CA, CRM, GOOG/GOOGL, HPE, IBM, JIVE, MSFT, NOW, ORCL, TEAM, ZEN February 11, 2016 Report Type: Initial Coverage ☐ Previously Covered Full Report ☐ Update Report Research Question: Will Atlassian’s workflow tools continue to grow quickly with software development teams while also expanding into new use cases? Summary of Findings Silo Summaries . Atlassian Corp. Plc’s (TEAM) tracking and collaboration tools, widely 1) Atlassian Software Users considered the best-in-class for software development, are gaining JIRA and Confluence are both effective tools for team traction among nontechnical teams. collaboration. JIRA can be customized to suit nearly any team’s development process, though setup is . The company’s two flagship products, JIRA and Confluence, are complicated. Confluence is much easier to use and slowly being rolled out in departments like human resources, sales, tends to be deployed more widely. Atlassian’s biggest customer support and product management. These represent a advantage is the way all of its software pieces work together. Atlassian products—which already are being much larger market than Atlassian’s traditional core in IT. branched out beyond software development—can grow . JIRA was praised for its flexibility and advanced customization even further with business teams. options, though the latter trait makes setup and maintenance a challenge. It has great potential for sales growth with any business 2) Users of Competing Software Three of these five sources said Atlassian’s JIRA is not team that needs to track numerous tasks through a multistage the right fit for every company.
    [Show full text]
  • Executing Informal Processes
    Institute of Architecture of Application Systems Executing Informal Processes C. Timurhan Sungur, Uwe Breitenbücher, Frank Leymann, and Johannes Wettinger Institute of Architecture of Application Systems, University of Stuttgart, Germany {lastname}@iaas.uni-stuttgart.de C. Timurhan Sungur, Uwe Breitenbücher, Frank Leymann, and Johannes Wettinger. 2015. Executing Informal Processes. In Proceedings of iiWAS ’15, December 11-13, 2015, Brussels, Belgium. DOI: http://dx.doi.org/10.1145/2837185.2837225 @inproceedings: {Sungur2015a, author = {Sungur, Celal Timurhan and Breitenb\"ucher, Uwe and Leymann, Frank and Wettinger, Johannes}, title = {Executing Informal Processes}, booktitle = {The 17th International Conference on Information Integration and Web-based Applications {\&} Services, {IIWAS} '15, Brussels, Belgium, December 11-13, 2015}, year = {2015}, publisher = {ACM} } © ACM 2015 This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version is available at ACM: http://dx.doi.org/10.1145/2837185.2837225 Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Executing Informal Processes C. Timurhan Sungur, Uwe Breitenbücher, Frank Leymann, and Johannes Wettinger Institute of Architecture of Application Systems University of Stuttgart 70569 Stuttgart, Germany [email protected] ABSTRACT Keywords Processes involving knowledge workers, such as decision- Informal processes, agent-centered processes, human-centric making processes, research processes, development processes, processes, process execution, TOSCA, APIfication maintenance processes, etc.
    [Show full text]
  • Letter, If Not the Spirit, of One Or the Other Definition
    Producing Open Source Software How to Run a Successful Free Software Project Karl Fogel Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel Copyright © 2005-2021 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license. Version: 2.3214 Home site: https://producingoss.com/ Dedication This book is dedicated to two dear friends without whom it would not have been possible: Karen Under- hill and Jim Blandy. i Table of Contents Preface ............................................................................................................................. vi Why Write This Book? ............................................................................................... vi Who Should Read This Book? ..................................................................................... vi Sources ................................................................................................................... vii Acknowledgements ................................................................................................... viii For the first edition (2005) ................................................................................ viii For the second edition (2021) .............................................................................. ix Disclaimer .............................................................................................................. xiii 1. Introduction ...................................................................................................................
    [Show full text]
  • Frameworks, Algorithms and Scalable Technologies for Mathematics (Fastmath))
    SciDAC Institute First Year Progress Report Frameworks, Algorithms and Scalable Technologies for Mathematics (FASTMath)) Principal Investigator: Lori Diachin Lawrence Livermore National Laboratories Livermore, CA 94551 [email protected] Senior Investigators: Mihai Anitescu, Lois McInnes,Todd Munson, Argonne National Laboratory Barry Smith, Tim Tautges Ann Almgren, John Bell, Phil Colella, Sherry Li, Lawrence Berkeley National Laboratory Esmond Ng, Brian Van Straalen, Chao Yang Milo Dorr, Rob Falgout, Jeff Hittinger, Mark Miller, Lawrence Livermore National Laboratory Carol Woodward, Ulrike Yang Mark Shephard, Onkar Sahni, Seegyoung Seol Rensselaer Polytechnic Institute Karen Devine, Vitus Leung, Glen Hansen, Sandia National Laboratories Jonathan Hu, Siva Rajamanickam, Andy Salinger Mark Adams Columbia University Dan Reynolds Southern Methodist University Jim Demmel UC Berkeley Carl Ollivier-Gooch University of British Columbia Contents 1 FASTMath Overview 1 2 Executive Summary of Progress to Date 2 3 FASTMath Technologies: First Year Progress and Plans 4 3.1 Tools for Problem Discretization . 4 3.1.1 Structured grid technologies. 4 3.1.2 Unstructured grid technologies. 6 3.1.3 Particle methods. 10 3.1.4 Time discretization. 10 3.2 Tools for Solution of Algebraic Systems . 11 3.2.1 Iterative solution of linear systems. 11 3.2.2 Direct solution of linear systems. 15 3.2.3 Nonlinear systems. 17 3.2.4 Eigensystems. 17 3.2.5 DVI methods. 19 3.3 High-Level Integrated Technologies . 20 3.3.1 Mesh/solver interactions. 20 3.3.2 Mesh-to-mesh coupling methods. 21 3.3.3 Full analysis codes and UQ processes using unstructured grid technologies. 22 3.3.4 Software Strategies.
    [Show full text]
  • Guide to Open Source Solutions
    White paper ___________________________ Guide to open source solutions “Guide to open source by Smile ” Page 2 PREAMBLE SMILE Smile is a company of engineers specialising in the implementing of open source solutions OM and the integrating of systems relying on open source. Smile is member of APRIL, the C . association for the promotion and defence of free software, Alliance Libre, PLOSS, and PLOSS RA, which are regional cluster associations of free software companies. OSS Smile has 600 throughout the World which makes it the largest company in Europe - specialising in open source. Since approximately 2000, Smile has been actively supervising developments in technology which enables it to discover the most promising open source products, to qualify and assess them so as to offer its clients the most accomplished, robust and sustainable products. SMILE . This approach has led to a range of white papers covering various fields of application: Content management (2004), portals (2005), business intelligence (2006), PHP frameworks (2007), virtualisation (2007), and electronic document management (2008), as well as PGIs/ERPs (2008). Among the works published in 2009, we would also cite “open source VPN’s”, “Firewall open source flow control”, and “Middleware”, within the framework of the WWW “System and Infrastructure” collection. Each of these works presents a selection of best open source solutions for the domain in question, their respective qualities as well as operational feedback. As open source solutions continue to acquire new domains, Smile will be there to help its clients benefit from these in a risk-free way. Smile is present in the European IT landscape as the integration architect of choice to support the largest companies in the adoption of the best open source solutions.
    [Show full text]