1 / 8

Trilinos Software Engineering Technologies and Integration Capability Area Overview

This overview provides insight into Trilinos' capabilities, including numerical algorithm interoperability, software integration, Lean/Agile software engineering principles, and backward compatibility considerations.

amybrantley
Download Presentation

Trilinos Software Engineering Technologies and Integration Capability Area Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2009-7512P Trilinos Software Engineering Technologies and Integration Capability Area Overview Roscoe A. Bartlett http://www.cs.sandia.gov/~rabartl/ Department of Optimization & Uncertainty Estimation Trilinos Software Engineering Technologies and Integration Lead Sandia National Laboratories Trilinos User Group Meeting, November 3, 2009 Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company,for the United States Department of Energy under contract DE-AC04-94AL85000.

  2. Trilinos Software Engineering Technologies and Integration • Numerical Algorithm Interoperability and Vertical Integration • Abstract Numerical Algorithms (ANAs) • Thyra (Interoperability and vertical integration of ANAs) • Epetra (Interoperability of element-based numerical algorithms) • General Software Interoperability and Integration • Memory management (Teuchos::RCP, ...) • User input and configuration control (Teuchos::ParameterList, ...) • User introspection (Teuchos::FancyOStream, ...) • Skin packages (wrappers for other languages) • PyTrilinos, ForTrilinos, Ctrilinos • General Software Quality and Design • Separation of “Stable” vs. “Experimental” code • Day-to-day stability of “Stable” code • Lean/Agile Software Engineering Principles and Practices • Internal Trilinos issues • External customer issues

  3. Lean/Agile Software Engineering Principles and Practices • Internal Trilinos development tools principles and practices • Scalability and robustness of build system and test tools • Continuous integration development principles and practices • Release process principles and practices • Integration with customer application codes • Coordination of co-development with customer application codes (i.e. daily integration and asynchronous continuous integration) • Coordination of release schedules with customer application codes • Regulated backward compatibility and smooth upgrades

  4. Backward Compatibility Considerations • Backward compatibility is critical for: • Safe upgrades of Trilinos releases • Composability and compatibility of different software collections

  5. Example of the Need for Backward Compatibility SIERRA Y+1 (released against Trilinos SIERRA Y+1) Xyce J+1 (released against Trilinos X) VTK M+1 (released against Trilinos X+1) Trilinos SIERRA Y+1? • Multiple releases of Trilinos presents a possible problem with complex applications • Solution: • => Provide perfect backward compatibility of Trilinos X through Trilinos SIERRA Y+1

  6. Backward Compatibility Considerations • Backward compatibility is critical for: • Safe upgrades of Trilinos releases • Composability and compatibility of different software collections • Maintaining backward compatibility for all time has downsides: • Testing/proving backward compatibility is expensive and costly • Encourages not changing (refactoring) existing interfaces etc. • => Leads to software “entropy” which kills a software product • A compromise: Regulated backward compatibility (Tentative) • Maintain a window of perfect backward compatibility over major version numbers (e.g. 1-2 years) • Provide “Deprecated” compiler warnings • Example: GCC’s __deprecated__ attribute enabled with • –DTrilinos_SHOW_DEPRCATED_WARNINGS:BOOL=ON • Provide strong automated testing of Trilinos backward compatibility • Drop backward compatibility between major version numbers

  7. Regulated Backward Compatibility for Trilinos (Tentative) • Releases of Trilinos X guarantee backward comparability between releases X.Y and X.Z where Z > Y • Example: Trilinos10.5 is backward compatible with 10.0 through 10.4 • Example: Trilinos 11.X is not compatible with Trilinos 10.Y • Major Trilinos version numbers change every 1-2 years • Example: Major Trilinos versions change every 2 years with 2 releases per year Maintain backward compatibility of 11.0 with only 10.3 but drop all other deprecated code! 11.1 11.2 Dev 10.1 10.2 10.3 Backward compatibility test Dev and current release every night! 10.0 (Sept 2009) 11.0 (Sept 2011) • Actual Target (Tentative): • Keep major Trilinos version number for two years • Put out releases quarterly (with minor releases X.Y.Z as needed)

  8. Trilinos Software Engineering Capabilities Area Webpage http://trilinos.sandia.gov/capability_areas.html

More Related