SEACAS: exo2mat - temporary fix to exo2mat; more work needed, but fixes djvango problem

(From Sierra)
Xpetra: fixed unitialized value usage

Thanks, valgrind!

We were calling CheckConsistency() on a StridedMap _before_ initializing
offset_.
TPetra Refactor: got rid of debug output, compiler warnings; fixed missing function attribute

Removed a number of debug output statements.
Fixed some compiler warnings regarding unused variables and int/size_t comparisons.
Added missing KOKKOS_INLINE_FUNCTION to DeepCopySelectedVectors.
Kokkos WrapperNode: fixed two issues when using the CudaWrapperNode

Added define for KERNEL_PREFIX from classic kokkos, so that legacy functors
can be used with the new CudaNode.

Fixed some issues with creation and destruction of nodes when both
a HostWrapperNode and a CudaWrapperNode are in use. The CudaWrapperNode needs
to initialize/finalize the HostDevice (its mirror_device_type) as well, but needs
to be aware that a HostWrapperNode might have intialized it already or is still in use.
The same is true the other way around.
Kokkos: Add CudaWrapperNode to list of KokkosClassicNodes for the ETI system
Teuchos: TpetraRefactor related needed to add some functions to CUDA ScalarTraits

When compiling with the Kokkos CudaWrapperNode everything is compiled with NVCC,
thus all code is also parsed as device code, even if run only on the host. For that
reason a number of functions needed to be added to the cuda specialisation of
ScalarTraits. Note the random and seedrandom functions are dummies only.
For the same reason the Cuda Variant of the ScalarTraits has to be included by the
non-Cuda variant if compiling with NVCC.
Kokkos: added missing KOKKOS_INLINE_FUNCTION, reduced compile warnings, fixed ArithTraits

ArithTraits: it was not working on several compilers because some defines like INT32_MAX
were not picked up. This is because __STDC_LIMIT_MACROS has to be defined before including
stdint.h to get those defines. Since we can't guarantee that this will allways happen,
I copied the defines from the appropriate file (actually from the MAC version) and put it in.
I also got rid of int64_t and just have explcicitely long and long long specialisations.
On different platforms int64_t is either long or long long (all three can be the same size though).
The same problem in principal exists for int32_t, int and long on 32 bit machines. This is not fixed.

CrsMatrix: fixed missing KOKKOS_INLINE_FUNCTION
MV: fixed some compiler warnings due to size_t/int comparison
Tpetra tests: Make them work with the CudaWrapperNode

when using the CudaWrapperNode everything has to be compiled with NVCC. To make
cmake do that a .cu file has to be added for each .cpp file. It has the same name
but ends on *_CU.cu. The _CU is there to get different object file names for the cpp
variant and the cu variant. The .cu file only includes the .cpp file. Also some ifdefs
are added so that only one of the two variants gets compiled. When KokkosCompat is activated
and Cuda is activated the .cu file is actually compiled (the .cpp file is in this case empty due to
define guards) otherwise the .cpp file.
TPetra tests: didnt actually add the .cu files in last commit.
Zoltan2: fixing ifdef guard
Changing the CMakeLists.txt file to actually run these tests.
Merge branch 'master' of software.sandia.gov:/space/git/Trilinos
Ifpack2: AdditiveSchwarz: Improved public documentation.

setParameters() and setParameterList() now clearly explain that they
have "delta" semantics, namely, that they use current values for any
missing parameters, rather than default values (if current and default
values happen to be different).
Ifpack2: AdditiveSchwarz: Can now pick subdomain solver thru params.

AdditiveSchwarz now lets users choose the subdomain solver by setting a
parameter, and also lets users pass in a sublist of parameters to their
chosen subdomain solver.

AdditiveSchwarz now accepts any of the following parameter names for
choosing the type of the subdomain solver:

  - "inner preconditioner name"
  - "subdomain solver name"
  - "schwarz: subdomain solver name"
  - "schwarz: inner preconditioner name"

The first will give a unified interface with all other Ifpack2
preconditioners that take an "inner" preconditioner (i.e., that have a
setInnerPreconditioner method).  The latter two offer consistency with
AdditiveSchwarz's existing parameter names, which all start with
"schwarz: ".

AdditiveSchwarz now accepts any of the following parameter names for
setting the subdomain solver's parameters:

  - "inner preconditioner parameters"
  - "subdomain solver parameters"
  - "schwarz: subdomain solver parameters"
  - "schwarz: inner preconditioner parameters"

This is a BACKWARDS INCOMPATIBLE CHANGE to AdditiveSchwarz's parameters.
AdditiveSchwarz used to pass its input parameter list directly to its
subdomain solver, rather than attempting to extract a sublist.  This
prevents nesting the same type of preconditioner, and is also not
idiomatic use of Teuchos::ParameterList.  (The point of sublists is that
you can use them to express a hierarchy of numerical algorithms.)  I
have fixed the AdditiveSchwarz unit tests (see the last two of the four
changed files in this commit).  However, this commit might possibly
break MueLu::SchwarzSmoother.  I don't have a good way to test this,
since the Helmholz tests in MueLu do not build by default.

This commit aims towards the ultimate goal of removing the second
template parameter (LocalInverseType) from AdditiveSchwarz.  At this
point, the second template parameter is almost completely superfluous.
I have not removed it yet in order to preserve backwards compatibilty.
My plan is to introduce a default second template parameter value,
namely the appropriate specialization of Ifpack2::Preconditioner.  This
will indicate run-time - only choice of the subdomain solver's type.
I will then encourage users to omit the second template parameter and
specify the subdomain solver using the input ParameterList.
Ifpack2: AdditiveSchwarz: Second template parameter is now optional.

Recent changes to AdditiveSchwarz have made its second template
parameter, LocalInverseType (the type of the subdomain solver),
superfluous.  The subdomain solver's type can be controlled entirely at
run time, by calling setParameters or setInnerPreconditioner.  This
commit makes LocalInverseType optional.  Its default value is the
appropriate specialization of Ifpack2::Preconditioner, which signifies
that AdditiveSchwarz will determine the type of the subdomain solver at
run time.

I've fixed explicit instantiation for AdditiveSchwarz appropriately,
but kept explicit instantiation for LocalInverseType=ILUT, in order to
preserve backwards compatibility.

Note that Factory is still not quite right.  In order for
AdditiveSchwarz to allow arbitrary preconditioner nesting (e.g.,
AdditiveSchwarz in AdditiveSchwarz, ILUT in Krylov in AdditiveSchwarz,
etc.), Factory needs to take a ParameterList (or at least a string name
of the inner preconditioner) and create the inner preconditioner for
AdditiveSchwarz itself.  Thus, Factory will need an overload of create()
that takes a ParameterList.

I also took the opportunity to fix SupportGraph link errors that only
showed up with explicit instantiation, and when I enabled MueLu.

Build/Test Cases Summary
Enabled Packages: Ifpack2, Amesos2, MueLu
Enabled all Forward Packages
0) MPI_DEBUG => Test case MPI_DEBUG was not run! => Does not affect push readiness! (-1.00 min)
1) SERIAL_RELEASE => Test case SERIAL_RELEASE was not run! => Does not affect push readiness! (-1.00 min)
2) MPI_DEBUG_SS => FAILED: passed=52,notpassed=39 => Not ready to push! (5.87 min)
3) SERIAL_RELEASE_SS => FAILED: passed=44,notpassed=30 => Not ready to push! (0.53 min)
Other local commits for this build/test group: 8f12d3d, 553f2f3
WARNING: Forced the push!
Adding missing labels in Ifpack_Amesos.cpp
Adding some timers to Ifpack_AdditiveSchwarz.h
Adding conditional compilation of timers in Ifpack_AdditiveSchwarz

To enable timers in Ifpack_AdditiveSchwarz use -DTIMING_OUTPUT_SUBCOMM
New class in Ifpack: Ifpack_DynamicFactory

The goal of Ifpack_DynamicFactory class avoiding circular dependency
problems with building Ifpack compatible preconditioners which embed
other Ifpack preconditioners.

The new factory has the same behaviour and interface as the Ifpack
standard factory (Ifpack.h, Ifpack.cpp).

By default it is able to build and preconditioner that the standard
factory can build. The difference is that new preconditioners which
implement the Ifpack_Preconditioner interface can be registered with
the dynamic factory at run-time, as long as a suitable builder function
is provided.

As such, new preconditioners, from packages which depend on Ifpack
(such as ShyLU) can be built, without package Ifpack depending on
these packages.
Ifpack_DynamicFactory in ML

Replaced all instances of Ifpack (the old factory class) in ML
with Ifpack_DynamicFactory