Ecosystem Elements


Rapid, efficient production of high-quality, sustainable applications is best accomplished using a rich collection of reusable libraries, tools, lightweight frameworks, and defined software methodologies, developed by a community of scientists who are striving to identify, adapt, and adopt best practices in software engineering. Although the software engineering community has ongoing debate about the precise meaning of terms, in the context of the Extreme-scale Scientific Software Development Kit (xSDK), we define the basic elements of a scientific software ecosystem to include:

  • Domain component: Reusable software that is intended for modest reuse across applications in the same domain. Although this kind of component is a library, the artifacts and processes needed to support a component are somewhat different than for a broadly reusable library.
  • Library: High-quality, encapsulated, documented, tested and multi-use software that is incorporated into the application and used as native source functionality. Libraries can provide control inversion via abstract interfaces, call-backs or similar techniques such that user-defined functionality can be invoked by the library, e.g., a user-defined sparse matrix multiplication routine. Libraries can also provide factories that facilitate construction of specific objects that are related by a base type and later used as an instance of the base type. Libraries can include domain-specific software components that are designed to be used by more than one application.
  • Framework: A software environment that implements specific design patterns and permits the user to insert custom content. Frameworks include documentation, build (compilation), and testing environments.
  • Tool: Software that exists outside of applications, used to improve quality, efficiency, and cost of developing and maintaining applications and libraries.
  • Extreme-scale Scientific Software Development Kit (xSDK): A collection of related and complementary software elements that provide the building blocks, tools, models, processes, and related artifacts for rapid and efficient development of high-quality scientific applications.

Given these basic elements, we define an application code as the following composition:

  • Native data and code:  Every application will have a main program and its own collection of source code and private data. Historically, applications have been primarily composed of native source and data, using libraries for a small portion of functionality, such as solvers. We will work to decrease the amount of native code required to develop an application by extracting and transforming useful native code into libraries, making it available to other applications, making existing libraries easier to use and more interoperable, and providing new libraries in key areas.
  • Component and library function calls: Some application functionality is provided by invoking library functions. We intend to increase usage of libraries as a part of our efforts.
  • Library interface adapters: Advanced library integration often involves invoking the control inversion facilities of the library in order to incorporate application-specific knowledge. In the case of sensitivity analysis, embedded optimization, and related analyses, control inversion via these adapters is essential in order to permit the solver to invoke the application with specific input data.
  • Component and library parameter lists: Libraries tend to provide a broad collection of functionality for which parameters must be set.
  • Shared component and library data: Most libraries require the user to provide nontrivial data objects, such as meshes or sparse matrices, and may provide functions to assist the application in constructing these objects. Unlike parameter list definitions, which represent a narrow interface dependency between the application and library, application-library data interfaces can be very complicated.
  • Documentation, build, and testing content: The application-specific text, data, and source used by the documentation, build, and testing frameworks to produce the derived software documentation, compilation, and test artifacts.