Intrepid MiniTensor: added comments to document changes in initialization
for spurious warnings in older gcc versions.
Removing using std::string from global namespace

Having Epetra_ConfigDefs.h inject 'using std::string' is a big no no as it
polutes the global namespace.  The immediate motivation for fixing this is
that this was causing warnings in the OpenMPI C++ headers (which are not
correctly namepaced either :-)).

Since this poluted the global namespace for all downstream client code (both
inside and outside of Trilinos), this commit will likely not be the last to
address this issue.
Epetra and others: remove some 'using' statements from Epetra config headers
and fix subsequent errors.  See bug 5945 - Epetra_ConfigDefs.h polluting
global namespace with 'using std::' statements.
Epetra: add note about warning users that certain "using" statements
are no longer in Epetra headers.
Epetra and others: fix errors due to removing some 'using' statements
from Epetra config headers.  The earlier commit
 9fe0b2fd5d6e3c4cd96ecbf230dca9bb0879521a
missed them because PyTrilinos was not compiled then.
SEACAS: ejoin - fix handling of meshes with no timesteps that was broken in last commit

(From Sierra)

Build/Test Cases Summary
Enabled Packages: SEACASEjoin
Disabled Packages: Panzer,PyTrilinos
Enabled all Forward Packages
0) MPI_DEBUG => Skipped configure, build, test due to no enabled packages! => Does not affect push readiness! (-1.00 min)
1) SERIAL_RELEASE => Skipped configure, build, test due to no enabled packages! => Does not affect push readiness! (-1.00 min)
2) MPI_DEBUG_SS => passed: passed=3,notpassed=0 (1.55 min)
3) SERIAL_RELEASE_SS => passed: passed=5,notpassed=0 (1.46 min)
Zoltan2 TaskMapper3 parameters are fixed in Cmakefile.
Merge branch 'master' of software.sandia.gov:/space/git/Trilinos
TriKota: Added missing namespace qualifications

Included ostream and iostream standard headers where appropriate to
ensure that the std::endl and std::cout symbols are declared.
Stokhos: Added missing namespace qualifications
zoltan2 Cmakefile fix.
Merge branch 'master' of software.sandia.gov:/space/git/Trilinos
Piro and build scripts:

1. Added a function to pass a new ML parameter list to
   Piro_NullSpaceUtils.

2. Added a TPL - TPL_ENABLE_BoostAlbLib, that links to all
   the boost libraries needed in a full adaptive Albany build, including
   the SCOREC tools and stk_percept, stk_adapt.

3. Put the set of "typical" build options for such an Albany config in
   sampleScripts/AlbanySettings.cmake

Build/Test Cases Summary
Enabled Packages: TrilinosFramework, Piro
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=109,notpassed=0 (2.47 min)
1) SERIAL_RELEASE => passed: passed=109,notpassed=0 (1.39 min)
2) MPI_RELEASE_SS => passed: passed=121,notpassed=0 (9.43 min)
Piro: Enabled param names from model in LOCASolver

The implementation now correctly handles three cases described in the
documentation of Thyra::ModelEvaluator::get_p_names, namely:
1) No name available (default behavior)
2) One unique name shared by all entries in the vector
3) A name for each entry.

When no name exists, each entry is labeled "Parameter k" where k denotes
the corresponding index in the vector.
NOX/LOCA: Fixed Thyra view of parameter vector

The LOCA abstract interfaces are defined in terms of a simple
ParameterVector class independent from the underlying linear algebra
package in order to achieve generality.

The concrete implementation of the Thyra::Group must convert the data
from the ParameterVector provided by the client and the Stepper to the
subtype of Thyra::VectorBase native to the model evaluator describing
the problem in order to perform the required evaluations.
That is achieved by creating an object implementing Thyra::VectorBase
that is a view of the internal data (a contiguous array) of the
ParameterVector object.

The previous implementation seemed to work flawlessly as long as Epetra
was the linear algebra package, since it relied on the particular
implementation details of the Thyra adapter code for Epetra.
However switching to Tpetra exposed a bug due to faulty assumptions.

The first problem was the use of a non-const view whereas the Thyra
vector is not intended to be used to modify the original ParamVector. In
this particular case, a const view is the correct choice.

The second problem was the wrong assumption that a view object always
remains synchronized with the parent object when the data in the latter
changes. This hypothesis only holds for so-called "direct" views, but
Thyra also allow "detached" views where a temporary copy of the data is
made, leaving the original data free of aliasing. To prevent divergence
between the data in the parent and in the view object, clients are
required to leave the parent unchanged as long as the view exists.

The concrete implementation of Thyra::VectorSpaceBase::createMemberView
used when the underlying linear algebra package is Epetra is the one
from Thyra::DefaultSpmdVectorSpace, which creates "direct" views that
alias the data of the parent object. Therefore, the synchronization
assumption held in that particular case.

However, when Tpetra is the underlying linear algebra engine, there is
(currently) no such specialization for Thyra::TpetraVectorSpace. The
default implementation of Thyra::VectorSpaceBase::createMemberView,
defined in Thyra::VectorSpaceBaseDefault, creates detached views so that
the synchronization assumption is violated, leading to inconsistent
behavior.

The implementation of LOCA::Thyra::Group has been rewritten to avoid
relying on the erroneous hypothesis described above. It is not as
efficient since a new Thyra view must be created every time the parent
LOCA::ParameterVector is updated. However, for an efficient
implementation that allows direct views, the overhead should be small
since there is no bulk data allocation.

A follow-up change to improve the performance for Tpetra would be to
specialize createMemberView in Thyra::TpetraVectorSpace so that it
creates direct views.
NOX/LOCA: Removed duplicated logic in constructors
Stokhos:  Add COO-inspired Kokkos SG tensor and multiply kernel.

This uses a COO-like pattern of paralllelizing over sparse Cijk nonzeros
(as opposed to rows like the CRS pattern), and uses a custom segmented
reduction within shared memory to compute the update for each row.
This provides better performance for smaller problems with fewer
nonzeros per row compared to the CRS approach, but has lower peak
performance.  It also suffers from the same occupancy issues as the CRS
kernel, but I am hopeful it will be more amenable to tiling of the Cijk
tensor.
Stokhos:  Tweak of the CRS multiply kernel launch.

Removed the restriction of at most 9 FEM columns at a time.  This improves
performance for the smaller problem sizes somewhat since occupancy is
already limited by registers (and thus reducing shared memory usage
by loading fewer FEM columns doesn't improve it).
Stokhos:  Added missing std:: in a few places.
Stokhos:  Rework clone example to allow for CPU and GPU ranks.

This allows MPI ranks to run on both the CPU and GPU at the same time by
cloning to the serial node for non-GPU ranks.  Amazingly enough it
actually works.