NOX/LOCA version 10.2 will be release as part of Trilinos 10.2 in March 2010.
-
We have fixed a long standing issue with nox regarding overloading of the std::ostream operator. If you are compiling nox and get a compile/link error that fails to find the "operator<<" method on one of your classes, then you need to move your overloaded std::ostream function for that object into the correct namespace (the same namespace as the object it is operating on).
The following artice by Herb Sutter explains this issue:
Herb Sutter Article
NOX/LOCA version 10.0 will be release as part of Trilinos 10.0 in September 2009.
-
NOX has been changed over to use the cmake build system. The autotools have been deprecated and will be completely removed in the next release.
NOX/LOCA version 9.0 will be release as part of Trilinos 9.0 in September 2008.
-
No major changes to nox/loca.
NOX/LOCA version 8.0 will be release as part of Trilinos 8.0 in early September 2007. Current changes/additions:
-
All Manager classes have been replaced with Factories. This change clarifies what occurs during reset calls and simplifies object management. No more handles. The factories return "Generic" base class objects.
-
A new concrete implementation of the group/vector has been added to support Thyra objects. Thyra is a set of abstract interfaces designed to provide developers of abstract numerical algorithms a single point of contact with codes. It plays the same role as the NOX::Abstract::Group and NOX::Abstract::Vector play in NOX. More information on Thyra can be found at Thyra. The group leverages the Stratimikos library to build the linear solver and preconditioner. In the future, we plan to move away from the direct Epetra support class as the Thyra wrappers gain more functionality. Examples can be found in nox/test/epetra/Thyra_2Dsim directory.
-
A wrapper called Thyra::NOXNonlinearSolver has been added that derives from the Thyra::NonlinearSolverBase class. This allows abstract numerical agorithms to use NOX as the nonlinear solver through a Thyra abstract interface. In particular, NOX can now be used by Rythmos.
-
A NOX::StatusTest::Factory has been added to allow for the construction of an entire status test set via a parameter list. Please use the nonmember functions to build parameter lists instead of using the Factory object directly.
-
The NOX::Utils object can now take a parameter sublist to enable the print options specified with the "Output Information" parameter. Previously the user had to sum the print options into an integer that was set in the parameter list. Now the user can just specify a sublist of print options for the "Output Information" parameter. Setting the integer still works. Here is an example:
p.
set(
"Output Processor", printProc);
p.
set(
"Output Precision", 3);
p.
set(
"Output Stream", outputstream);
p.
set(
"Error Stream", outputstream);
info.
set(
"Details",
true);
info.
set(
"Outer Iteration StatusTest",
true);
info.
set(
"Outer Iteration",
true);
-
Removed all instances of enumerated types from the parameter list. This was causing problems with the python interfaces. Enumerated type are now std::string types.
-
The RefCountPtr class in Teuchos was changed to RCP to shorten the amount of code. All instances of RefCountPtr should be changed to RCP. There is a script available in Teuchos to automatically make this change to any package.
NOX/LOCA version 7.0 will be release as part of Trilinos 7.0 in early September 2006. NOX and LOCA have undergone many important changes between the 6.0 and 7.0 release:
-
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::RCP 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.
-
Build options have changed. please run "configure --help" to see the new options.
-
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.
NOX/LOCA 4.1 is being released as part of Trilinos 6.0 on September 1st 2005.
General release 4.1 notes:
-
NOX and LOCA now use the new export makefile system. When compiled and installed into the prefix directory, two new makefiles will appear: Makefile.export.nox and Makefile.export.nox.macros. These files contain all variables needed my a simple Makefile to build and link against nox. All major packages in Trilinos now support this feature.
-
NOX and LOCA's examples now work in a consistent manner with the tests. The examples and tests can be enabled or disabled with the flags –enable-nox-tests and –enable-nox-examples. The specific examples that will be compiled depend on which support packages are enabled (lapack, epetra, petsc, belos, tsf). You no longer need to specify specific example support like –enable-nox-epetra-examples.
LOCA release 4.1 notes:
-
A constraint tracking feature has been added to LOCA where the user can specify additional algebraic constraints that must be satisfied along with the residual. Examples include boundary conditions, phase conditions in periodic orbits, etc. The resulting Newton system can be efficiently solved using the QR method discussed below. This capability is only available using the LOCA::NewStepper also discussed below.
-
A QR method for solving augmented systems of equations in parallel has been added, and is an extension of the Householder method already available to systems with more than one augmented row/column. This method allows bordered systems of equations to be solved in roughly the same time as original system and is well-conditioned even when the original system is nearly singular. This capability is only available using the LOCA::NewStepper discussed below.
-
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. This process is mostly, but not fully complete. This functionality is available by choosing the LOCA::NewStepper for continuation instead of the original LOCA::Stepper. However pitchfork and Hopf continuation are currently not available in the new framework. Documentation for this new framework can be found on the New LOCA Framework page.
-
LOCA's interface to eigensolvers has changed slightly and now uses a strategy interface approach instead of relying on the group to provide computeEigenvalues() and saveEigenvalues() methods. This provides a more natural decoupling of the parallel linear algebra data structures (i.e., the group) from the eigensolver method/package (eigensolver strategy object). The use of strategy interfaces instead of group methods is a major theme in the new LOCA framework, and is discussed more fully on the new framework page.
-
Teuchos::RCP support has been added to improve software quality. For the most part, ref-count pointers are only used in the new framework.
-
Many regression tests have been added to improve software quality.
-
Libtool support has been removed from LOCA due to portability issues.
-
Python support is temporarily disabled in this release due to a major refactor of the build system for python wrappers in Trilinos.
LOCA portability notes:
-
There currently is a portability issue with LOCA to the Solaris platform using the Sun Forte 7 compilers. LOCA builds on this platform but does not run correctly. It appears the problem is compiler related as the virtual table for some LOCA objects is not setup correctly. All of the LOCA examples and any LOCA tests involving continuation runs fail with a segmentation fault. It is not known whether LOCA runs correctly when built with version 10 of the Sun compilers. See bugzilla bug 1238 for more information on this issue.
NOX release 4.0 notes:
-
A new Tensor based solver that is independent of the linear solver is now implemented (in the prerelease section).
-
Inexact Trust Region Techniques are fully supported (also in the prerelease section).
-
Improved support for Epetra objects - The NOX::EpetraNew::Group should be used in place of the NOX::Epetra::Group. In the future we will be phasing out the NOX::Epetra::Group and replace it with NOX::EpetraNew::Group.
-
A multi-physics technique for code coupling has been demonstrated in the test/epetra/Multiphysics directory. This will be expanded to a generic capability in the next year.