Trilinos is a collection of compatible software packages that support parallel linear algebra computations, solution of linear, non-linear and eigen systems of equations and related capabilities. The majority of packages are written in C++ using object-oriented techniques. All packages are self-contained, with the Trilinos top layer providing a common look-and-feel and infrastructure.


The version 7.0 general release contains 27 packages: Amesos, Anasazi, AztecOO, Didasko, Epetra, EpetraExt, Galeri, IFPACK, Isorropia, Kokkos, Komplex, LOCA, Meros, Moertel, MOOCHO, ML, New_Package, NOX, Pliris, PyTrilinos, RTOp, Rythmos, Stratimikos, Teuchos, Thyra, Triutils, and WebTrilinos.

The limited release contains an additional 5 packages that are available in special situations by request. These are: Belos, Capo, Claps, Jpetra, and Tpetra.

In addition to many new features across most packages, Trilinos Release 7.0 contains nine packages that are being released for the first time:

  • Galeri (distributed linear system generation)
  • Isorropia (repartitioning and rebalancing)
  • Meros (segregated preconditioning)
  • Moertel (Mortar methods)
  • MOOCHO (Multifunctional Object-Oriented arCHitecture for Optimization)
  • Stratimikos (unified set of Thyra-based wrappers to linear solver and preconditioner capabilities)
  • RTOp (reduction/transformation operators)
  • Rythmos (transient integrator for ordinary differential equations and differential-algebraic equations)
  • WebTrilinos (a web-based interface to Trilinos)
Package-specific features for these new packages, as well as many of the other packages are listed below.

More information:

Trilinos website: http://software.sandia.gov/trilinos

External Package Capability

The "external" Trilinos package makes it easy add additional packages that are external to Trilinos to the Trilinos build process. Users who develop additional capabilities on top of and outside of Trilinos may find this tool useful for simplifying their Trilinos interface. Packages that utilize this tool can easily be added to a user's existing set of Trilinos packages.

Instructions for using the external package capability can be found in the Trilinos tarball in packages/external/README or on the web at http://software.sandia.gov/trilinos/external.html.


  • Cleaned the MUMPS interface. Improved memory management by using smart pointers. Dropped the not-so-well-tested single-precision MUMPS. Improved passing of CNTL and ICNTL through the parameter list.
  • Increases the performances of the UMFPACK interface by a factor of at least 2. This means that the time requires by the Amesos wrappers is reduced by 2 -- the time required by UMFPACK still is unaffected.
  • Added to (almost) all classes profiling to evaluate how much time is spent in the amesos wrappers (that is, without considering any of the time spent in the called solver). This time is printed on screen when PrintTiming() is called.
Amesos/Thyra adapters:

What’s New:
  • Timing and output tracing: The Teuchos::TimeMonitor class has been incorporated to time the various factorization and solve operations and produce profiler-like output. In addition, the Teuchos::VerboseObject interface is now supported which allows some informational outputting to be sent to a configurable output stream.


In Trilinos Release 7.0, the Anasazi eigensolver framework has been considerably refactored to provide simpler user interfaces as well as powerful eigensolver developer interfaces.
  • This release provides simpler user interfaces, called solver managers, for three eigensolvers: block Davidson, block Krylov-Schur, and locally-optimal block preconditioned conjugate gradient (LOBPCG).
  • Powerful lower-level interfaces are provided for each eigensolver, enabling the expert user to specialize their own solver manager.
  • Status test mechanisms have been incorporated into the Anasazi framework to give the user and solver manager the flexibility to direct the behavior of the eigensolver.
  • The Anasazi::OrthoManager provides the eigensolver with an abstract interface to orthogonalization and orthonormalization. This enables the user to specialize their own orthogonalization/orthonormalization if those already provided in Anasazi (CGS w/ iterative refinement or SVQB) are not sufficient.
  • Interfaces to linear algebra are provided through the templated traits classes: Anasazi::MultiVecTraits and Anasazi::OperatorTraits. These classes have template specializations for Epetra and Thyra. Testing functionality is also provided for user-written template specializations via the Anasazi::TestMultiVecTraits() and Anasazi::TestOperatorTraits() functions.
  • All Trilinos web documentation and Didasko tutorial have been updated to reflect the changes in the Anasazi framework.

AztecOO 3.5

  • Additional scaling capabilities.
  • Improved I/O control.
  • Numerous small "hardening" changes.
AztecOO/Thyra Adapters:

What’s New:
  • Timing and output tracing: The Teuchos::TimeMonitor class has been incorporated to time the various setup and solve operations and produce profiler-like output. In addition, the Teuchos::VerboseObject interface is now supported which allows some informational outputting to be sent to a configurable output.
  • Acceptance of external preconditioner factory object: The AztecOO/Thyra adapters now except an external preconditioner factory object to create preconditioners. This allows Ifpack, ML, and Meros preconditioners to all be used in a seamless way. Any other compatible preconditioner can also be supported as well.
  • General Thyra operator support: Any general Thyra linear operator can now be supported including implementations based on product vector spaces. To be effective, an appropriate preconditioner factory must also be set to create a preconditioner. This is used in Meros to allow AztecOO to be used with the segregated block preconditioners.


  • No significant changes.

Epetra 3.5

  • New Epetra_BasicRowMatrix class: Facilitates easy development of user-defined adapters for the Epetra_RowMatrix interface. Greatly reduces the number of methods that must be be implemented.
  • New Epetra_JadMatrix class (which supercedes Epetra_JadOperator). This classes accepts an existing Epetra_RowMatrix object and creates an Epetra_JadMatrix object. The Epetra_JadMatrix object uses the so-called jagged diagonal data structure to store the sparsematrix coefficients in a format especially suitable for vector processors. Once constructed, the JadMatrix object can be used with any Trilinos package that requires an Epetra_RowMatrix or Epetra_Operator object. This implementation also contains special Cray compiler directives (_Pragma "ivdep") to force optimal vectorization.
  • New Epetra_InvOperator class. A simple class that interprets an existing Epetra_Operator as an inverse operator.
  • New method for Epetra Map and BlockMap objects to cheaply test if a map has 1-to-1 (uniquely-owned) global IDs: This method facilitates easy testing for whether or not a particular map can be used as an input argument to functions that require the map to have uniquely-owned global IDs.
  • New function called Create_OneToOne_Map in Epetra_Util namespace that creates an Epetra_Map with unique global IDs from an existing Epetra_Map that may or may not have unique global IDs.
  • New function called Create_OneToOne_BlockMap in Epetra_Util namespace that creates an Epetra_BlockMap with unique global IDs from an existing Epetra_BlockMap that may or may not have unique global IDs.
  • New function called Create_Root_Map in Epetra_Util namespace that creates an Epetra_Map from an existing Epetra_Map such that all global IDs are collected to the specified root processor and all other processors own no global IDs.
  • New method to compute the Frobenius norm of an Epetra_CrsMatrix or Epetra_VbrMatrix object.
  • Debugging code in Epetra_CrsMatrix to support detailed printing of intermediate matrix-vector multiplication information. This code is compiled if EPETRA_CRS_MATRIX_TRACE_DUMP_MULTIPLY is defined at compile time.
Epetra/Thyra adapters:

What’s New:
  • Refactored for new SPMD classes: The “fake” Epetra/Thyra adapters have been updated for the new Thyra SPMD support software. The names of the conversion functions in Thyra_EpetraThyraWrappers.hpp have also be simplified.

EpetraExt 3.5

  • New class EpetraExt_ProductOperator: Supports implicit composition of multiple Epetra_Operator objects to act as a single operator.
  • New class EpetraExt_BlockCrsMatrix: Supports aggregation of multiple Epetra_CrsMatrix as sub-matrix objects to act as a single matrix.
  • New class EpetraExt_MultiMpiComm: Supports two-level communication where each processor is part of the global communicator and a sum-domain communicator.
  • EpetraExt_MatrixMatrix performance improvements: Substantial improvments to sparse matrix time sparse matrix multiplication for most cases.
  • InOut facilities: Substantial improvement to input and output functions that read and write matrix and vector objects to and from files. Added simplified interfaces that allow distributed matrix construction without requiring the user to define Epetra_Maps. Added support to write the implied matrix coefficients of an Epetra_Operator. Added support for HDF5 and XML formatted files.
  • ModelEvaluator: New capabilities to support generic solution interfaces for linear and non-linear systems via Thyra.
EpetraExt/Thyra adapters:

What’s New:
  • Thyra::EpetraModelEvaluator: This class wraps an EpetraExt::ModelEvaluator object (which deals only in Epetra-based objects) and provides an implementation of the Thyra::ModelEvaluator interface strictly in terms of abstract Thyra objects. Any linear solver and preconditioner can be supported by configuring a EpetraExt::ModelEvaluator object with a compatible linear solver factory object.

Galeri (new)

Understanding, validating, using and developing algorithms and software tools for distributed linear algebra solvers, like Krylov accelerators and preconditioners, requires input data. This data should have three critical properties:
  • reflect real-life applications to a sufficient extent so that we can use them to predict performance;
  • be sufficiently simple to be amenable to mathematical analysis;
  • it is possible to write generators that easily provide instances of these problems.
The goal of the Galeri package is exactly to produce these input data for linear solvers.

As regards real-life applications, we have here selected PDE-type problems. Although Galeri can generate some non-PDE linear systems, surely there is a strong focus on PDE applications. Among them, the Laplace problem is probably the most widely studied application, and a broad range of results are available. For most solvers and preconditioners, often there is a sharp convergence bound that can be used to validate a particular class, or to get a sense of the performances of a new method. A Trilinos package that uses Galeri is the MatrixPortal module of WebTrilinos.

Galeri's Matrix generation capabilities can help to make examples shorter and easier to read, since they can produce challenging linear systems in a few code lines. Therefore, the attention of the example's reader is not distracted by complicated instructions aiming to build this or that linear system. Since most linear algebra packages of Trilinos use Galeri, users will quickly become familiar with it. Galeri is used in the examples of the Amesos, IFPACK, and ML packages. For more details, please check the Galeri web page (http://software.sandia.gov/trilinos/packages/galeri).

Ifpack 3.1

  • New class Ifpack_Chebyshev: Chebyshev polynomial preconditioner with point diagonal scaling
  • New class Ifpack_DiagPreconditioner: Simplifies construction and use of diagonal preconditioners.
  • New functionality to test if Teuchos ParameterList values are valid for Ifpack preconditioner.
  • Changed the hash table class for ICT and ILUT. The latter is then much faster than the previous version. The new class has a better memory usage and it is simpler to modify and extend.
  • Fixed a few memory leaks in the ILU factorization class.
  • Added support for UseTranspose(true) in Ifpack_AdditiveSchwarz, Ifpack_ILUT and Ifpack_Amesos.
  • Thyra preconditioner factory adapters for Ifpack are new for this release.

Isorropia 1.0 (new)

  • initial release, version 1.0
  • Isorropia is a Trilinos interface to Zoltan repartitioning/balancing capabilities
  • requires Zoltan version 2
  • several example programs illustrate usage
  • doxygen documentation on Trilinos website

Kokkos 1.1

  • New experimental interface to OSKI optimized kernels.

  • Komplex 1.1

  • No significant changes.

  • LOCA

    • Many of the internals of LOCA have been rewritten to more fully support multi-parameter continuation, constraint tracking, higher-order predictors and advanced bifurcation algorithms. The old framework has been completely removed, and therefore all users must upgrade their interface to the new framework. For a brief description of the new framework, see the New LOCA Framework page. In addition, some of the parameter list entries that control LOCA have changed. See the LOCA Parameter Reference Page for a description of the new parameter list structure.
    • A minimally augmented turning point formulation has been added to LOCA. This method appears to be significantly faster and more robust than the turning point methods based on the Moore-Spence formulation.
    • A modified pitchfork bordering method has been added to LOCA, which is similar to the modified turning point method already available. This method avoids the singular matrix solves in the original pitchfork bordering method.
    • Parallel and serial Hopf support has been added to LOCA.

    Meros 1.0 (new)

    Meros is a segregated preconditioning package. It provides scalable block preconditioning for problems that couple simultaneous solution variables such as Navier-Strokes problems.

    The source documentation can be found on the Meros web page: http://software.sandia.gov/Trilinos/packages/meros/

    For more information, see Trilinos/packages/meros/README-MEROS


    • Fixed a subtle translation problem between ML's handling of ghost unknowns and Epetra's. This could only happen in parallel.
    • Added a constructor for Maxwell's equations that takes the mass and curl-curl terms separately.
    • Added support for (linear) matrix-free aggregation-based multilevel preconditioners. Using the new class ML_Epetra::MatrixFreePreconditioner, one can construct a preconditioner just by applying the operator --- no access to the operator entries is require. The class requires the graph of the operator, and the number of PDE equations, which is supposed to be constant for all grid points.
    • Added a direct wrap for Epetra_CrsGraph objects.
    • Substantially improved the ML/Epetra wrappers: if the ML_Operator is a wrapper of an Epetra object, then ML automatically takes the Epetra pointer stored in the data field of the ML_operator, and avoid an additional RowMatrix wrapper. This makes the ML code faster, and some smoothers must faster: for example IFPACK relaxation smoothers are now competitive with ML's internal ones for the finest-level matrix.
    • Minor fixes to ml_RowMatrix: NumMyCols() was not correct.
    • Added support for additional prolongator smoother sweeps (higher degree polynomial smoothing). This should be used with aggressive coarsening (e.g., METIS, ParMETIS).
    • Thyra preconditioner factory adapters for ML are new for this release.

    Moertel (new)

    • Supplies capabilities for nonconforming mesh tying and contact formulations in 2 and 3 dimensions using Mortar methods.
    • Uses dual and standard Mortar methods to construct Lagrange multiplier constraints for nonconforming interfaces.
    • Serves as a programming language for other types of mesh tying approaches.

    MOOCHO (new)

    MOOCHO is collection of software for the solution of large-scale simulation-constrained optimization problems using primarily reduced-space successive quadratic programming algorithms.

    Known issues:
    • Incomplete support for all Thyra::ModelEvaluator options: All of the bells and whistles for the different possible modes for simulation-constrained optimization through the Thyra::ModelEvaluator classes are not yet in place. Right now, the code handles the cases of exact direct sensitivities, finite difference direct sensitivities and adjoint sensitivities with some caveats. For example, even through the direct sensitivity method only requires the application of the operator DgDx (ModelEvaluator notation) onto vectors, the current implementation requires that a vector for transpose(DgDx ) be explicitly returned. In the next release of Trilinos, all modes should be fully supported without imposing undue requirements on the application.
    • Outdated linear algebra and model interfaces: MOOCHO currently uses its own linear algebra layer called AbstractLinAlgPack that actually predates (and helped to inspire) Thyra. In the next release, it is highly possible that MOOCHO will be refactored to use a linear algebra layer based directly on Thyra and perhaps the new Thyra handle layer which will help to help other Trilinos developers to be able to understand and develop algorithms in MOOCHO. This refactoring is also likely to radically change the NLP interfaces to move to a single ModelEvaluator-like interface that will allow for faster prototyping of new optimization algorithms.


    • No significant changes.


    • NOX is now using reference counted smart pointers (RCPs) for memory management. Passing an RCP wrapped object through a method call implies a persisting relationship. We are using the Teuchos::RefCountPtr object for the RCP.
    • The NOX::Parameter::List has been removed. We are now using the Teuchos::ParameterList object. This has the same functionality with minor changes to the syntax of method calls.
    • NOX now has a non-optional dependency on the Teuchos package (also part of Trilinos). While it can be built stand-alone, we recomend building NOX as part of Trilinos with the teuchos library enabled to simplify dependencies.
    • NOX and LOCA now generate Makefiles that users can include in their own makefiles to get all dependencies correct. For example if NOX is built with Epetra support enabled, nox depends on epetra, aztecoo and ifpack headers and libraries. To keep the user from having to learn about those packages so they can link nox into their codes, just include the NOX file Makefile.export.nox file to get variables that have all sub package dependencies correct. In the installation directory, look at the files include/Makefiles.export.nox and include/Makefiles.export.nox.macros. The important flags in Makefile.export.nox are NOX_INCLUDES, NOX_LIBS, LOCA_INCLUDES, and LOCA_LIBS flags. The Makefile.export.nmox.macros file contains the compiler flags that were used to build the NOX and LOCA packages. It is very important to use consistent flags when linking your application against Trilinos.
    • Multivector support is no longer a configure option, but is automatically built as part of the library.
    • The epetra interfaces (NOX::Epetra::Interface namespace) have been changed. They now take an Epetra_Operator as an argument when evaluating the Jacobian and preconditioner objects. While this is redundant for our base epetra group (since it shares the same operator between groups), this allows users to override the eptra group and use separate operators for each group if desired.
    • There are 2 options for creating an Ifpack preconditioners. The original code where the "Preconditioner" option in the "Linear Solver" sublist was set to "Ifpack" and the new ifpack code "New Ifpack". The original option explicitly constructs an ifpack ilu object that has since been deprecated and will most likely be removed in the next release (Trilinos 8.0). The option "New Ifpack" uses the new ifpack factory object. You can now create a parameter list that directly uses the ifpack factory arguments and can create any ifpack preconditioner (not limited to ILU). We recommend switching to the "New Ifpack" preconditionerr interface asap.
    • In the epetra support, the preconditioner options "AztecOO", "New Ifpack", and "ML" allow users to recompute the preconditioner using the same graph so that preconditioner memory is not allocated and destroyed each linear solve. The new "Linear Solver" sublist key is "Preconditioner Reuse Policy" with the possible values "Rebuild", "Reuse", and "Recompute". If you choose "Rebuild", this is what nox has done in previous releases - destroy, reallocate and recompute the preconditioner for each linear solve. "Reuse" wil use the same preconditioner for every linear solve. "Recompute" will recompute the preconditioner, but will try to efficiently reuse any objects that don't need to be destroyed. How efficient the "Recompute" option is depends on the type of preconditioner. For example if we are using ILU in Ifpack, the graph that is allocated does not need to be destroyed and recomputed even though the computation will recompute the factorization when the matrix changes. These changes support native Aztec, Ifpack and ML preconditioners.

    Pliris 1.1

    • Added a new method - Solve. This allows a user to split the factor and solve for a dense matrix. This is useful when the right hand side is changing in the numerical simulation.
    • A test case has been added to test this functionality.

    PyTrilinos 3.0

    PyTrilinos 3.0 is a significant structural change from version 2.0, although most of these changes will be invisible to the typical user. "PyTrilinos" used to refer to both a python package (here using the python definition of package, meaning "a module of modules") and to a small Trilinos package (here using the Trilinos definition of package, meaning a set of one or more related compiled libraries) of utility classes that helped to enable the python modules.

    The classes that used to comprise the PyTrilinos library have either been eliminated or moved to other Trilinos packages. The PyTrilinos Trilinos package now serves to enable certain cleanup functions. The most important of these is to fix a problem seen with MPI builds, where bad_cast exceptions can be raised because the python extension modules are linked to static libraries.

    If you are building Trilinos on Linux or Mac OS X and have enabled both python and MPI, the PyTrilinos package will go back and create dynamic versions of various Trilinos libraries (e.g., libepetra.so). These get stored in your build directory under


    PyTrilinos then goes back again and re-links the python extension modules (e.g. _Epetra.so) to these new dynamic libraries. This has eliminated several (but not all) problems seen when running PyTrilinos scripts in parallel.

    Note that if you wish to run python test scripts *prior* to installing Trilinos, you need to tell your shell how to find the dynamic libraries. You do this by setting an environment variable, either



    for Linux and Mac OS X respectively, to include the directory that contains the dynamic libraries. When you invoke mpirun, you must export this environment variable. For example,

    mpirun -x LD_LIBRARY_PATH -np 4 testVector.py -t

    When you run "make install", the dynamic libraries will get installed as well. Depending on where you specify installation, this may eliminate the need to specify and export these environment variables.

    Several other changes have been made since PyTrilinos 2.0/Trilinos 6.0:
    • As the first part of these release notes indicate, MPI is explicitly supported. This support was considered "experimental" in PyTrilinos 2.0.
    • The build process has been significantly improved. PyTrilinos now uses the export Makefiles that are supported by many Trilinos packages, and this has greatly helped in using accurate lists of include paths, library paths and libraries. Furthermore, the PyTrilinos build system now parses Makefiles directly to obtain the values of user-configured variables, eliminating another source of build error.
    • NumPy support. PyTrilinos has been upgraded from compatibility with the now-obsolete Numeric module to its successor, NumPy. As of this writing, NumPy is in beta testing for release 1.0. PyTrilinos is compatible with NumPy 0.9.6 and 0.9.8, and has been tested against NumPy 1.0b, versions 2 and 4.
    • Much focus has been placed on improving the Epetra module. Previously, many Epetra class methods were wrapped, but if they had pointers in the argument list representing C arrays, these methods could not actually be used in python. A large percentage of these methods have been updated. Any python sequence can be used in place of input array arguments, and NumPy arrays are returned for output arrays.
    • More Epetra array-like classes now doubly-inherit from NumPy arrays. These classes are:
      • Epetra.IntSerialDenseMatrix
      • Epetra.IntSerialDenseVector
      • Epetra.IntVector
      • Epetra.MultiVector
      • Epetra.SerialDenseMatrix
      • Epetra.SerialDenseVector
      • Epetra.Vector
      When you instantiate one of these classes, the resulting object can also be treated as and will be recognized as a NumPy array. This creates a high-degree of compatibility with other python packages, such as SciPy, matplotlib, etc.
    • Exception handling added. Not all cases are yet handled, but many of the common ones are, and an infrastructure is in place for PyTrilinos developers to convert C++ exceptions into python exceptions.
    • The Teuchos module has been added and ParameterLists are explicitly handled now, but python dictionaries can be used in their place. Also, nested dictionaries are now recognized as sub-lists, greatly increasing the usefulness of this feature.
    • The Galeri module has been added.
    • For Trilinos release 7.0, the NOX module has been disabled. We have been unable to keep up with the significant changes made in the NOX package, but we are working on it. Hopefully, this module will be re-enabled in a minor future update, 7.0.x.
    • Documentation has been expanded. The documentation section of the PyTrilinos web site now covers prerequisites, build notes and has an individual page for each module covering differences between the C++ and python interfaces.

    RTOp (new)

    RTOp (reduction/transformation operators) provides the basic mechanism for implementing vector operations in a flexible and efficient manner. This software was basically refactored out of Thyra from the last release of Trilinos 6.0 since MOOCHO, and in the future Tpetra, directly depends on RTOp but not Thyra. Contained in RTOp is:
    • a small number of interoperability interfaces
    • support software including code for the parallel SPMD mode based on only Teuchos::Comm (and not MPI directly)
    • a library of pre-implemented RTOp subclasses for everything from simple AXPYs and norms, to more specialized vector operations.

    Rythmos 1.0 (new)

    Rythmos is a transient integrator for ordinary differential equations and differential-algebraic equations with support for explicit, implicit, one-step and multi-step algorithms. The fundamental design of Rythmos is aimed at supporting operator-split algorithms, multi-physics applications, block linear algebra, and adjoint integration.

    New Features:
    • Everything is new. This is the first release for Rythmos.
    • Implicit Backward Differentiation Formula Stepper: This stepper provides a re-implementation of the implicit algorithms in the LLNL Sundials code CVODE. This is an implicit BDF integrator for ODEs which uses variable step-sizes and variable-orders first through fifth.
    • Explicit Runge-Kutta Stepper: This stepper provides a four stage fourth order explicit RK steper with fixed step-sizes provided by the application. Full variable step-size support and application provided Butcher tableaus will be supported in the next release.
    • Forward Euler Stepper: This stepper provides the explicit forward Euler algorithm with fixed step-sizes provided by the application. Full variable step-size support will be in the next release.
    • Backward Euler Stepper: This stepper provides the implicit backward Euler algorithm with fixed step-sizes provided by the application. This class supports ODEs and DAEs. Full variable step-size support will be in the next release.
    Known Issues:
    • Currently Rythmos does not have an interface to NOX. This will be provided through an EpetraExt::ModelEvaluator interface in NOX in the next release. Therefore the nonlinear solving capabilities in Rythmos are limited to a simple undampened Newton iteration in Thyra::TimeStepNewtonNonlinearSolver.
    • The InterpolationBuffer base class is just starting to be developed and has not been compiled or tested in any way yet. It is provided as an example of what the interface could look like and where the integrator class will be derived from.
    • An integrator class does not yet exist. It will depend on the InterpolationBuffer class and both of these will be completed in the next release. Therefore users should use the Stepper class directly to step differential equations forward in time. When this class is implemented it will enable solving operator-split and multi-physics problems.
    • The Explicit Taylor Polynomial Stepper is in active development and under current research. It is provided only as an example interface. This stepper may be completed in the next release.

    Stratimikos (new)

    Stratimikos is a set of wrappers of common linear solver functionality through Thyra. In this initial release, Stratimikos provides the “Façade” class Thyra::DefaultRealLinearSolverBuilder that provides a single parameter list (i.e. Teuchos::ParameterList) driven interface to much of the linear solver and preconditioner capability contained in Trilinos. For example, the class Thyra::DefaultRealLinearSolverBuilder is the recommended way to access the linear solver adapters in Amesos/Thyra, AztecOO/Thyra, and Belos/Thyra (not in Trilinos 7.0) as well as the preconditioner adapters in Ifpack/Thyra and ML/Thyra. With a single parameter list that can be read from an XML file, the user can select for a wide variety of different linear solver and preconditioner combinations.

    Known issues:
    • Incomplete parameter validation and inconsistent use of parameter lists: While many of the parameter lists and sublists accepted by the Stratimikos façade class Thyra::DefaultRealLinearSolverBuilder are fully validated and will write default parameter values when missing in the input parameter list such as for AztecOO/Thyra, other sublists for other solvers are not. This is not specifically a Stratimikos issue but instead is an issue for the core code in Ifpack, ML, and Amesos.


    In Trilinos Release 7.0, the Teuchos tools package has some additional functionality available to Trilinos developers and users:
    • This release provides a simple XML parser that is compiled by default when eXpat is not available, enabling the perpetual use of Teuchos' XML utilities like XML-ParameterList reading and writing in any code. Also, the Teuchos' XML utilities are now built by default.
    • Complex scalar-type support is built by default for scalar-type templated utilities like the ScalarTraits, BLAS, LAPACK, and SerialDenseMatrix.
    • A reference-counted class similiar to RefCountPtr designed to manage an array of objects is available, called ArrayRefCountPtr.


    What's New:
    • Implicit Linear Operators: Thyra now includes support software that implements implicit zero, identity, diagonal, added, multiplied, scaled/adjoint, and blocked linear operators that complement the existing product vector space and (multi)vector subclasses. These implicit operators allow you to create arbitrarily complex, nested, linear operators that are useful in a variety of contexts (e.g. Schur complement solvers, block preconditioners, time/space discretizations etc.). Look for these in the “ANA Operator/Vector Support” collection and click on “ANA Development Support” link.
    • Removal of explicit MPI support/dependence: The separate serial and MPI support software collections for vector spaces, vectors, multi-vectors and linear operators have been merged into a single set of SPMD support software that is only dependent on the small new Teuchos::Comm interface. This got rid of a lot of duplicate code and will allow for other more specialized implementations of communication.
    • Java-like handle classes supporting Matlab-like operator overloading: Thyra now includes a set of Java-like handle classes for wrapping vector spaces, vectors and linear operators and allowing you to write expressions like y=x+alpha*z and y=beta*A*x + B*y that don’t result in any unnecessary temporary copies unless required.. The linear operator handle class also provides full support for the implicit linear operator subclasses described above. Look for these in the “ANA Operator/Vector Support” collection and click on “ANA Development Support” link.
    • Zero-based indexing: All of Thyra has been changed from largely 1-based indexing to completely zero-based indexing. This especially impacted the multi-vector column access and subview functions. Therefore, any current users are cautioned to carefully review their codes to see what impact this will have. Note that most single-vector ANAs will not be affected by this change at all since there is not such indexing used in these types of algorithms.
    • Compile-time enabled runtime checks: Almost all runtime tests in Thyra-related software must be explicitly enabled by adding –enable-teuchos-debug to the configure line. This replaces having to manually define a _DEBUG macro as was required in the last release of Trilinos. We highly recommend that this flag be turned on by all users and developers while developing with Thyra-related software. Once a program is working and you want to run timed studies, then you should remove –enable-teuchos-debug, and turn up the compiler optimization flags.
    • Expanded linear solver and preconditioner factory interfaces: The Thyra linear solver interfaces in Trilinos 6.0 have been refined to now include the concept of a preconditioner factory. Adapters are found in Amesos, AztecOO, Ifpack and ML.
    • Nonlinear model evaluator: The Thyra::ModelEvaluator interface now supports functionality for simulation-constrained optimization (i.e. as used by MOOCHO).
    Known issues:
    • Long compilation times: Compilation times for the examples and tests can be very excessive on older machines or when using some compilers. The reason for this is that Thyra is entirely templated code currently and uses implicit template instantiation. Therefore, when every *.cpp test/example file is compiled, the compiler has to parse and analyze every header and create instantiations over and over again. In the future, the option of performing explicit template instantiation will be available and this will greatly speed up the build process but will also inhibit some of the flexibility of supporting different Scalar types and might complicate the build process. In the mean time for this release, to speed up the builds for Trilinos, users might consider adding –disable-thyra-tests and –disable-thyra-examples to the configure line.
    • Wrong behavior of explicit element access functions: The behavior of the Thyra::[Multi]VectorBase::acquireDetachedView(…) functions is not consistent with the nature of abstract numerical algorithms (ANA) in single program multiple data (SPMD) mode. The current behavior facilitates the interoperability of abstract vectors in an SPMD configuration without requiring lots of dynamic casts but is the wrong behavior from the ANA perspective. This will be corrected in the next version of the release and specialized interfaces will be developed for (multi)vector-(multi)vector interoperability and the behavior of the functions Thyra::[Multi]VectorBase::acquireDetachedView(…) will be the same in every process of an SPMD, or any other type, of runtime configuration. Therefore, users are warned to isolate any code that depends on the current behavior of the Thyra::[Multi]VectorBase::acquireDetachedView(…) functions since this behavior will change on the next release. Note that most user code will never use these functions so this future refactoring this should cause serious problems for users.
    • Unnecessary temporary creation in handle layer code: The performance of handle-based code can be less efficient that nonhandle-based code in some cases, such as the creation of extra temporary vectors. This may be fixable in later releases through more careful consideration operator evaluation logic. In the mean time, studying the current implementation and some experimentation may help.
    • Does not compile on IBM xlC compiler: Thyra and all Thyra-related software can not be compiled on the IBM AIX C++ compiler (i.e. xlC). The problem is that this C++ compiler gets tripped up with calling one version of an overloaded virtual function and declares the call to be ambiguous (which about 6 other distinct compilers consider the call to be non-ambiguous). Specifically, it declares that a call to the acquireDetachedView(…) function to be ambiguous. The next release of Thyra might remove the overloaded functions and replace them with distinct names.
    • ConstHandle classes will be removed: The handle layer (e.g. Thyra::[Const]Vector, Thyra::[Const]LinearOperator etc.) is likely to change after the initial release of Trilinos 7.0. The change will involve getting rid of the ConstHandle classes and going to a runtime protection of const involving just a single Handle class (e.g. Thyra::Vector and Thyra::LinearOperator). Any code that uses the two-class handle system [Const]Handle should have no little problem being updated after the refactoring. In fact, typedefs could allow all user code to be recompiled without change in most cases (but an actual code change would be a better long term solution).


    • No significant changes.

    WebTrilinos (new)

    WebTrilinos is a scientific portal, a web-based environment to use several Trilinos packages through the web. If you are teaching sparse linear algebra, you can use WebTrilinos to present code snippets and simple scripts, and let the students execute them from their browsers. If you want to test linear algebra solvers, you can use the MatrixPortal module, and you just have to select problems and options, then plot the results in nice graphs.

    From the user's perspective, the only component required to use WebTrilinos is any browser and an internet connection. Then, (simple) C++ and Python programs can be written on a web form, executed on a server, and the output is sent back to the user's browser. Code snippets for most of Trilinos and PyTrilinos packages are already available in convenient repositories. WebTrilinos also contains a problem solving environment (PSE) for the analysis of linear algebra solvers, like direct solvers, Krylov solvers, and preconditioners. This environment is called MatrixPortal.

    To be installed, WebTrilinos requires the following:
    1. a web server, like Apache;
    2. PHP installed on the web server;
    3. an installed version of Trilinos, with the following packages: Teuchos, Epetra, EpetraExt, AztecOO, IFPACK, Amesos, ML, Galeri, PyTrilinos (and, of course, WebTrilinos itself);
    4. the PyChart package;
    5. the convert *nix tool to convert image files.
    WebTrilinos comes with a set of easy-to-use tools that suggest the configuration options. For more details, please check the WebTrilinos web page.