Documentation

Documentation is available for Trilinos Release 10.4, Release 10.2, Release 10.0, Release 9.0, Release 8.0, Release 7.0, Release 6.0 and Release 5.0, as well as the Development Branch. There is also a Users Guide available in PDF.

• Development Branch The primary focus of the development branch will be adding new packages/modules, and improving automated documentation, portability, robustness and memory management for packages that use the Teuchos::RCP<> class.
• Release 10.4 Improved and expanded HDF5 support for EpetraExt I/O.
• Release 10.2 Updated the wrappers so that the Jacobian can be specified using the NOX.Epetra.Interface.Jacobian base class. The new capability is demonstrated in serial in example script exNOX_2DSim.
• Release 10.0 The major changes to the 10.0 release include CMake build compatibility and the addition of the Pliris and Komplex packages/modules. The handling of shared libraries is now robust, due to CMake.
• Release 9.0 has moved completely to shared libraries. These are built in a somewhat ad-hoc manner, as libtool has not been adopted by the Trilinos package. This change, however, eliminates many bugs associated with runtime type information and symbols crossing shared library boundaries. PyTrilinos docstrings have been greatly improved. They are now auto-generated from the doxygen comments that already exist in Trilinos code. Exception handling has been improved.
• Release 8.0 In the 8.0 release, all of PyTrilinos has been returned to a self-contained package, removing the python sub-directories of the packages that support a python interface. You should therefore use --enable-pytrilinos to enable it; --with-python=path can be used to specify the particular python you wish to compile against; and --enable-python is being deprecated. The NOX wrappers have been re-enabled, and working Anasazi wrappers have been added.
• Release 7.0 As with the 6.0 release, all of the wrapper code is contained within each package, residing in a python subdirectory. PyTrilinos can therefore enabled equivalently with --enable-python[=path] or --with-python[=path]. With version 7.0.6 and later, --enable-pytrilinos works as expected. Note that with future releases, --enable-pytrilinos will be the preferred method for enabling the package, that --with-python=path will be available for specifying the version of python to compile against, and --enable-python will be deprecated. Note that NOX wrappers have been diabled for the 7.0 release.
• Release 6.0 In the 6.0 release, all of the wrapper code is formally a part (python subdirectory) of the package for which it provides python support. Use the equivalent --enable-python or --with-python[=path] configuration options. This will build, compile and link the python wrappers for every enabled package that supports python. The --enable-pytrilinos configuration option is still supported, but of practical use for developers only. PyTrilinos is itself still a Trilinos package, providing utility classes and functions shared by all the PyTrilinos modules, as well as a central repository for documentation. It is automatically enabled when --enable-python or --with-python is specified. Both serial and MPI builds are supported.
• Release 5.0 In the 5.0 release, all of the wrappers are a part of the PyTrilinos package. Trilinos must be configured for a serial build and the Epetra, EpetraExt, NOX and NOX-Epetra packages must all be enabled for the --enable-pytrilinos configuration option to work.
• N.B. For the autotools build system (release 9.0 and earlier), we highly recommend using GNU make and configuring with the --with-gnumake option. It is known that the NOX wrappers will fail to build on certain operating systems if this is not the case.