Kokkos: Added ThreadsWrapperNode to the instantiated Kokkos nodes: i.e. tests will be build
Damping parameters min_all and max_all should be magnitudes; if it's
a scalar, it throws an exception for complex numbers.
Something weird is happening. When this test for exception is active,
the innerMatrix_.is_null() is flagged, and I get an exception saying
that the innerMatrix_ is null. However, when I comment this out, the
code runs and solves the problem just fine. For now, I am commenting
it out, and I think this is OK because there is already another test
for exception in place for the inner matrix... but it is disturbing
nonetheless. 
MueLu: removed unused DistanceLaplacianFactory
MueLu: minor cleanup
MueLu: Hierarchy: fixing a dependency problem in the Setup

Was trying to switch the Simple Emin test back on, but encountered this
problem.

Recent (few weeks ago) changes to handle smoother dependencies properly
exposed this problem. Some coarse solvers may require some other data
besides "A". For instance, ProjectorSmoother requires both "A" and
"Nullspace". However, "Nullspace" was erased after the coarseRAP.Build()
call as we did the coarse solver DeclareInput too late to preserve the
data. The typical trace in this situation looked like this:

 MueLu::Level(0)::GetFactory(Aggregates, 0): No FactoryManager
   during request for data "     Aggregates" on level 0 by factory TentativePFactory
   during request for data "              P" on level 1 by factory EminPFactory
   during request for data "              P" on level 1 by factory TransPFactory
   during request for data "              R" on level 1 by factory RAPFactory
   during request for data "              A" on level 1 by factory TentativePFactory
   during request for data "      Nullspace" on level 2 by factory NullspaceFactory
   during request for data "      Nullspace" on level 2 by factory NullspacePresmoothFactory
   during request for data "      Nullspace" on level 2 by factory ProjectorSmoother
   during request for data "    PreSmoother" on level 2 by factory NoFactory

I tried to move the requests of smoothers and direct solvers before
calling the Build method. It seems to work, but there are several
potential issues there:

  1. We may need to construct more data than is truly necessary, due to
     trying to satisfy both smoother and direct solver dependencies.

  2. It still does not help if the data we want is too exotic for anyone
     else to want it.

I don't think 1) poses a problem at our selection of algorithms. 2) is
much more serious issue, and is much more general. It seems that all the
Hierarchy data falls loosely into two categories: the data which we
*need* on all levels, and the data which we may *want* on some level.
The first category contains standard culprits: A, R, P, Aggregates, ...
The second category contains Coordinates, or Nullspace on the coarsest
level. The current implementation of the Hierarchy is poorly suited for
the second category, as we deal with at most three levels. That means
that if we suddenly need coordinates on level 5, there is no way to
construct them. Currently, we hack around this by using RAP transfer
factories to transfer optional stuff.

The optional data problem comes up once in a while. One of the possible
solutions would be to keep all factory managers and all the data until
the end of the construction, and then do the clean up. That would allow
us to transfer, say, coordinates from level 0 to level 5 if we want to.
I don't know how expensive this idea is, or why the original
implementation was chosen to deal with only three levels.
Ifpack2: Diagonal: Removed unimplemented applyMat method.

For some reason, Diagonal had a method, applyMat, which was
unimplemented.  Its documentation claims that it applies the original
input matrix A to a multivector.  This method was not inherited from any
base class of Diagonal.  It's also unnecessary, since one may call
getMatrix() on the Diagonal instance and apply it oneself.  Thus, I'm
removing it.
Ifpack2: Diagonal: Prepared class to implement Details::CanChangeMatrix.

The class is now ready to implement Details::CanChangeMatrix, so that it
can be a suitable subdomain solver for AdditiveSchwarz, or a suitable
inner preconditioner for any other nested preconditioner.  It does not
yet implement Details::CanChangeMatrix; that will happen in my next
commit.
Ifpack2: Diagonal: Now implements Details::CanChangeMatrix.

Diagonal now implements Details::CanChangeMatrix.  This makes it fully
legitimate as a subdomain solver for AdditiveSchwarz, or as an inner
preconditioner for any other nested preconditioner.

The only single-level preconditioner left to make implement
Details::CanChangeMatrix is RILUK.  This will be a bit tricky, as the
semantics of the class might not necessarily conform with those of the
other Ifpack2 classes.
Ifpack2: IlukGraph: Fixed potential segfaults.

constructFilledGraph() was doing the usual &x[0] thing for
Teuchos::Array x, in a few places.  This is a bad idea if x.size() == 0.
I fixed the issue and simplified the code at the same time, yay!  Of
course this could only come up if the graph didn't have entries in the
upper or lower triangle for that row, but I still prefer correct code
that probably never executes to incorrect code that probably never
executes.

I also fixed some issues involving IlukGraph's GraphType template
parameter.  As the class was written before this commit, GraphType could
only be Tpetra::CrsGraph, because the class was creating internal graphs
and assuming Tpetra::CrsGraph's constructor and methods.  In this
commit, I changed all of the graphs that IlukGraph creates to be
Tpetra::CrsGraph explicitly.  I'll have to go over the class'
expectations of the input graph more carefully in order to check whether
I can relax it to a Tpetra::RowGraph, or whether I must leave it as a
Tpetra::CrsGraph.  If I can relax the input graph to a Tpetra::RowGraph,
then I can force the class to require that GraphType be a
Tpetra::RowGraph specialization, which is the most general.

All of this is meant to be preparation for making RILUK implement
Details::CanChangeMatrix.  It's going to be tricky.
Ifpack2: Refactored and improved documentation of internals of RILUK.

Refactored interface of IlukGraph, so that it looks more like the other
Ifpack2 preconditioners (even though it's not a preconditioner itself).
Added Doxygen documentation to RILUK and IlukGraph header files (so that
Doxygen will generate their class documentation).  Improved class
documentation of RILUK and IlukGraph.  Reformatted code to improve
readability.
Ifpack2: AdditiveSchwarz: Fixed default inner prec initialization.

Before, by default, AdditiveSchwarz would always create an ILUT inner
preconditioner if (a) Details::OneLevelFactory didn't know how to create
a LocalInverseType instance, and (b) the user didn't call
setInnerPreconditioner() with a nonnull argument before calling
initialize() on the AdditiveSchwarz instance.  This could be confusing
to users who expected the inner preconditioner to be a LocalInverseType,
and got an ILUT instead.  This commit fixes that behavior, so
AdditiveSchwarz throws with an informative error message in this case.
The error message explains to users two ways that they can make the
inner preconditioner a LocalInverseType instance.

Build/Test Cases Summary
Enabled Packages: Ifpack2
0) MPI_DEBUG => passed: passed=23,notpassed=0 (0.50 min)
1) SERIAL_RELEASE => passed: passed=18,notpassed=0 (0.09 min)
Other local commits for this build/test group: e3d5687, 7936863, c0d6b59, d7b7051, 8fdbf5d
Kokkos,Tpetra: Added ArithTraits prototype.

ArithTraits will be what Tpetra uses in place of Teuchos::ScalarTraits.
There's nothing wrong with Teuchos::ScalarTraits, but Tpetra needs class
methods that can be marked as CUDA device functions and that make sense
to call in parallel.  Furthermore, Kokkos needs a traits class that does
not have any package dependencies.

I have tested the ArithTraits class independently, with Clang 3.2, gcc
4.2.1, and CUDA 5.5, all on MacOS X 10.7.5.  There may be issues with
other operating systems and / or compilers, due to possible implicit
assumptions about built-in integer types.  The .cu and .cpp files are
tests that build, run, and "pass."  They do not depend on a unit test
framework, but the return value indicates success or failure.  I found
some interesting issues with std::pow() with std::complex<float>
arguments using gcc 4.2.1 that could use some experimentation.  (3^3 is
really inaccurate in complex arithmetic, for example.)  Those tests are
disabled explicitly in Kokkos_ArithTraitsTests.cpp for now.

Nothing uses this class yet.  Please feel free to experiment with it,
though.  I recommend reading the public documentation first.

Build/Test Cases Summary
Enabled Packages: Tpetra
0) MPI_DEBUG => passed: passed=23,notpassed=0 (0.50 min)
1) SERIAL_RELEASE => passed: passed=18,notpassed=0 (0.09 min)
LOCA: fix error in adaptive stepper

1. The stepper strategy was being inadvertently re-created each
   mesh adaptation step - preventing changes to the step increment.

2. Fix redefinition warning on HAVE_CONFIG_H from TriKota - added an
   undef prior to the inclusion of the Dakota file that defines it.

3. Turn off TPL_ENABLE_Matio in the standard Albany build options file.

Build/Test Cases Summary
Enabled Packages: TriKota, NOX
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=181,notpassed=0 (7.61 min)
1) SERIAL_RELEASE => passed: passed=181,notpassed=0 (12.35 min)
2) MPI_RELEASE_SS => passed: passed=184,notpassed=0 (3.44 min)
Putting Ifpack::Krylov through Additive Schwarz in parallel, and changing
the default inner preconditioner type. Also, three guys in Intrepid should be
scalars, not doubles... this was causing a build issue with Drekar.
Piro/LOCA: clean up stepping logic during mesh adaptation.
Piro/LOCA: More minor changes in diagnostic output when using mesh adaptation.

Changed three instances of "double" to "Scalar" in Intrepid_HGRAD_TET_COMP12_FEMDef.hpp
that were causing a compile error in Sacado.

Clean up a few whitespaces at end of lines.

Build/Test Cases Summary
Enabled Packages: Intrepid, NOX, Piro
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=313,notpassed=0 (10.51 min)
1) SERIAL_RELEASE => passed: passed=313,notpassed=0 (5.89 min)
2) MPI_RELEASE_SS => passed: passed=325,notpassed=0 (10.10 min)
Other local commits for this build/test group: 4858e70