Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-09-22T17:41:49Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3430Build fails: Swig source step of building PyTrilinos fails with execvp: /bin/...2018-09-22T17:41:49ZJames WillenbringBuild fails: Swig source step of building PyTrilinos fails with execvp: /bin/sh: Argument list too long*Created by: casparvl*
@trilinos/pytrilinos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package nam...*Created by: casparvl*
@trilinos/pytrilinos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
I am trying to build Trilinos 12.10.1 with python support. I ran into this issue (https://github.com/trilinos/Trilinos/issues/2434) where the build fails with an error 'execvp: /bin/sh: Argument list too long'. I fixed that by setting the suggested
```
CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON
CMAKE_CXX_USE_RESPONSE_FILE_FOR_INCLUDES=ON
CMAKE_CXX_USE_RESPONSE_FILE_FOR_LIBRARIES=ON
```
Which works well for the compilation part. However, the 'Swig source' step triggers the same error message, and clearly, doesn't respect these CMake flags.
`[ 94%] Swig source /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/packages/PyTrilinos/src/LOCA.Epetra.Interface.i
cd /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/src && /hpc/eb/RedHatEnterpriseServer7/SWIG/3.0.12-foss-2017b-Python-2.7.14/bin/swig -python -I/scratch/sha
red/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/doc/Doxygen -noproxydel -outdir PyTrilinos/LOCA/Epetra -c++ -I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-201
7b-Python-2.7.14/trilinos-12.10.1-Source/BUILD -I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/src`
[[[cut out a few hundred lines here]]]
`-I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD
/packages/teuchos/remainder/src -I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/packages/teuchos/numerics/src -o /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python
-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/src/LOCA.Epetra.InterfacePYTHON_wrap.cpp /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/packages/PyTrilinos/src/LOCA.Epetra.I
nterface.i
make[2]: execvp: /bin/sh: Argument list too long
make[2]: *** [packages/PyTrilinos/src/LOCA.Epetra.InterfacePYTHON_wrap.cpp] Error 127
make[2]: Leaving directory `/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD'
make[1]: *** [packages/PyTrilinos/src/CMakeFiles/PyTrilinos_LOCA_Epetra_Interface.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD'`
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Other then shortening the prefix on my end (which is tricky because I use EasyBuild as a build system, which produces somewhat long prefixes), is there anything that could be done on your end to fix this issue?
I can imagine even a shorter prefix is just a temporary relief, as future versions may trigger even _more_ includes. Thus, I think a more permanent solution for these excessively long command lines may be needed on your end anyway.
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
To reproduce: pick a long enough prefix (and possibly build enough of Trilinos' components to get a long link line).
## Related Issues
<!---
If applicable, let us know how this bug is related to any other open issues:
-->
* Follows up on (somewhat) related issue https://github.com/trilinos/Trilinos/issues/2434
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3473Panzer: Integrator_DivBasisTimesScalar needs test to exercise field multipliers2018-09-20T16:27:31ZJames WillenbringPanzer: Integrator_DivBasisTimesScalar needs test to exercise field multipliers*Created by: rppawlo*
The Integrator_DivBasisTimesScalar currently has no test that exercises the field multipliers.
Definition of done: Field Multipliers are exercised in unit testing.*Created by: rppawlo*
The Integrator_DivBasisTimesScalar currently has no test that exercises the field multipliers.
Definition of done: Field Multipliers are exercised in unit testing.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3465Xpetra: expose full Tpetra writeDenseFile and writeSparseFile interface2018-09-18T22:24:15ZJames WillenbringXpetra: expose full Tpetra writeDenseFile and writeSparseFile interface*Created by: jhux2*
The class `Xpetra::IO` currently only allows calling `Tpetra::MatrixMarket::Writer<crsmatrix_type>::writeDenseFile` and `Tpetra::MatrixMarket::Writer<crsmatrix_type>::writeSparseFile`
with the filename and object....*Created by: jhux2*
The class `Xpetra::IO` currently only allows calling `Tpetra::MatrixMarket::Writer<crsmatrix_type>::writeDenseFile` and `Tpetra::MatrixMarket::Writer<crsmatrix_type>::writeSparseFile`
with the filename and object. Tpetra itself provides additional string parameters whose values are written into the MatrixMarket header.
Xpetra's interfaces should be expanded to match Tpetra's.
@trilinos/xpetrahttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3456PyTrilinos: Conflicting types in Teuchos_BLAS_wrapper.hpp2018-10-25T16:48:26ZJames WillenbringPyTrilinos: Conflicting types in Teuchos_BLAS_wrapper.hpp*Created by: wfspotz*
@trilinos/pytrilinos
@trilinos/teuchos
@trilinos/kokkos-kernels
## Expectations
I expect to build PyTrilinos without compilation errors
## Current Behavior
I have a wrapper file that `#include`s the he...*Created by: wfspotz*
@trilinos/pytrilinos
@trilinos/teuchos
@trilinos/kokkos-kernels
## Expectations
I expect to build PyTrilinos without compilation errors
## Current Behavior
I have a wrapper file that `#include`s the header `MLAPI_MultiVector.h` which gives the compilation error
/Development/Trilinos/packages/teuchos/numerics/src/Teuchos_BLAS_wrappers.hpp:173:13: error: conflicting types for 'daxpy_'
void PREFIX DAXPY_F77(const int* n, const double* alpha, const double x[], const int* incx, double y[], const int* incy);
^
/Development/Trilinos/packages/teuchos/numerics/src/Teuchos_BLAS_wrappers.hpp:78:21: note: expanded from macro 'DAXPY_F77'
#define DAXPY_F77 F77_BLAS_MANGLE(daxpy,DAXPY)
^
/Development/Trilinos/MPI/packages/teuchos/core/src/Teuchos_config.h:10:37: note: expanded from macro 'F77_BLAS_MANGLE'
#define F77_BLAS_MANGLE(name,NAME) name ## _
^
<scratch space>:23:1: note: expanded from here
daxpy_
^
/Development/Trilinos/packages/kokkos-kernels/src/impl/tpls/KokkosBlas1_axpby_tpl_spec_decl.hpp:49:17: note: previous declaration is here
extern "C" void daxpy_( const int* N, const double* alpha,
## Definition of Done
I can get the PyTrilinos package to build and all of the PyTrilinos tests to pass.
## Possible Solution
I'm not sure why this conflicting type declaration is occurring, but it is clearly related to macro expansion. Based on `git blame` of `Teuchos_BLAS_wrapper.h` I'm hoping either @jwillenbring or @hkthorn might have some idea what the problem could be. PyTrilinos can present some unique configuration issues.
## Steps to Reproduce
If it gets to this, I can help someone set up their environment to build PyTrilinos.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3453Tpetra: unreliable test condition in ScopeGuard tests2019-01-29T23:35:22ZJames WillenbringTpetra: unreliable test condition in ScopeGuard tests*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/tpetra @trilinos/kokkos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Current Behavior
The following tests fail on white for a CUDA build:
31 - TpetraCore_Core_initialize_where_user_initializes_mpi_MPI_4 (Failed)
32 - TpetraCore_Core_ScopeGuard_where_user_initializes_mpi_MPI_4 (Failed)
35 - TpetraCore_Core_initialize_where_tpetra_initializes_kokkos_MPI_1 (Failed)
36 - TpetraCore_Core_ScopeGuard_where_tpetra_initializes_kokkos_MPI_1 (Failed)
37 - TpetraCore_Core_initialize_where_user_initializes_kokkos_MPI_1 (Failed)
38 - TpetraCore_Core_ScopeGuard_where_user_initializes_kokkos_MPI_1 (Failed)
39 - TpetraCore_Core_initialize_where_tpetra_initializes_mpi_and_user_initializes_kokkos_MPI_2 (Failed)
40 - TpetraCore_Core_ScopeGuard_where_tpetra_initializes_mpi_and_user_initializes_kokkos_MPI_2 (Failed)
These tests rely on Kokkos not writing to std::cerr during Kokkos::initialize. However, for reasons unrelated to proper/improper use of Kokkos::initialize, Kokkos may write to std::cerr. E.g.,
"Captured output: Kokkos::Cuda::initialize WARNING: running kernels compiled for compute capability 3.5 on device with compute capability 3.7 , this will likely reduce potential performance."
In this case, all the initialization took place correctly (so the test should have passed), but Kokkos issued a warning to std::cerr (so the test failed).
Since Tpetra cannot control what Kokkos writes to std::cerr, this condition is not a reliable way to determine whether these tests pass or fail.
A side note: The test goes on to say "Captured output is empty!" when they should say "Captured output is NOT empty!" The incorrect message is confusing, but secondary to the unreliable test condition.
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
On white:
module purge
module load openmpi/2.1.2/gcc/7.2.0/cuda/9.2.88
module load cmake/3.9.6
module load openblas/0.2.20/gcc/7.2.0
module load boost/1.65.1/gcc/7.2.0
module load cuda/9.2.88
module load netcdf-exo/4.4.1.1/openmpi/2.1.2/gcc/7.2.0/cuda/9.0.176
export NVCC_WRAPPER_DEFAULT_COMPILER=`which g++`
echo ${NVCC_WRAPPER_DEFAULT_COMPILER}
TRILINOS_SRC="/home/Trilinos"
export OMPI_CXX=${TRILINOS_SRC}/packages/kokkos/bin/nvcc_wrapper
which mpic++
mpic++ --version
export PATH=${PATH}:${TRILINOS_SRC}/packages/kokkos/bin
cmake \
-DTPL_ENABLE_MPI=ON \
-DMPI_BASE_DIR=${MPI_ROOT} \
-DBLAS_LIBRARY_DIRS=${OPENBLAS_ROOT}/lib \
-DLAPACK_LIBRARY_DIRS=${OPENBLAS_ROOT}/lib \
-DNetcdf_LIBRARY_DIRS=${NETCDF_ROOT}/lib \
-DBoostLib_LIBRARY_DIRS=${BOOST_ROOT}/lib \
-DTPL_ENABLE_Matio=OFF \
-DTrilinos_ENABLE_ALL_PACKAGES=OFF \
-DTrilinos_ENABLE_Tpetra=ON \
-DTpetra_ENABLE_TESTS=ON \
-DTpetra_ENABLE_EXAMPLES=ON \
-DCMAKE_INSTALL_PREFIX=${TRILINOS_SRC}/tmp \
-D Trilinos_ENABLE_CUDA=ON \
-D TPL_ENABLE_CUDA=ON \
-D Tpetra_INST_CUDA:BOOL=ON \
-DCMAKE_CXX_FLAGS="--expt-extended-lambda" \
-DKokkos_ENABLE_Cuda_UVM:BOOL=ON \
$TRILINOS_SRC
make -j 8
ctest -j4
## Related Issues
#3095
## Additional Information
This issue is low priority and will likely not be fixed unless it becomes a blocker for other developers.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3435Framework: Autotester console output unhelpful2018-09-13T17:27:05ZJames WillenbringFramework: Autotester console output unhelpful*Created by: csiefer2*
Can we make this more useful to the developer?
See this PR:
https://github.com/trilinos/Trilinos/pull/3429
We get this unhelpful output:
17) atdm-ninja_fortran/1.7.2
MPI type = sems-mpich/3.2
CDash Track...*Created by: csiefer2*
Can we make this more useful to the developer?
See this PR:
https://github.com/trilinos/Trilinos/pull/3429
We get this unhelpful output:
17) atdm-ninja_fortran/1.7.2
MPI type = sems-mpich/3.2
CDash Track = Pull Request
*** Generating set of Trilinos enables given modified packages from
*** git commit origin/develop to HEAD
TRILINOS_DIR=/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
TRILINOS_SCRIPTS_DIR=/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos/cmake/std/../..
TRIBITS_DIR=/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos/cmake/std/../../cmake/tribits
A) Generate the Trilinos Packages definition and depencencies XML file
Wrote the file 'TrilinosPackageDependencies.xml'
B) Get the set of changed files
Current directory: /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
git diff --name-only origin/develop..HEAD > /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/changed-files.txt
Wrote file 'changed-files.txt'
Current directory: /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1
C) Get the unfiltered list of changed Trilinos packages (including 'ALL_PACKAGES')
CHANGED_PACKAGES_FULL_LIST='MueLu'
D) Filter list of changed packages to get only the PT packages
CHANGED_PACKAGES_PT_LIST='MueLu'
E) Generate the *.cmake enables file
Wrote file 'packageEnables.cmake'
Enabled packages:
-- Setting Trilinos_ENABLE_MueLu = ON
Build name = PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836
Cur dir = /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/TFW_testing_single_configure_prototype
Source dir = /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
Binary dir = /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/pull_request_test
Parallel level = 18
skip_by_parts_submit = OFF
skip_single_submit = ON
skip_update_step = ON
skip_upload_config_files = OFF
skip_clean_build_dir = OFF
Subproject count = 53
Dashboard model = Experimental
Dashboard track = Pull Request
Running configuration:
/projects/sems/install/rhel6-x86_64/atdm/binary-install/cmake-3.11.1-Linux-x86_64/bin/cmake
-C "/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos/cmake/std/PullRequestLinuxIntelTestingSettings.cmake"
-C "/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/packageEnables.cmake"
-DTrilinos_ENABLE_TESTS:BOOL=ON
-G "Ninja"
/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
CTEST_DROP_LOCATION = /cdash/submit.php?project=Trilinos
CDash URL1 = https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&display=project&filtercount=3&showfilters=1&filtercombine=and&field1=site&compare1=61&value1=ascic158&field2=buildname&compare2=61&value2=PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836&field3=buildstamp&compare3=61&value3=20180912-0916-Pull Request
CDash URL2 = https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&display=project&filtercount=2&showfilters=0&filtercombine=and&field1=buildname&compare1=61&value1=PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836&field2=buildstamp&compare2=61&value2=20180912-0916-Pull Request
CDash URL3 = https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercount=2&showfilters=0&filtercombine=and&field1=buildname&compare1=61&value1=PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836&field2=buildstamp&compare2=61&value2=20180912-0916-Pull Request
Starting configure step.
Each . represents 1024 bytes of output
.................................................. Size: 50K
.................................................. Size: 100K
.................................... Size of output: 135K
configure submit error = 0
Configure suceeded.
Starting build step.
Each symbol represents 1024 bytes of output.
.................................................. Size: 49K
.................................................. Size: 99K
.................................................. Size: 149K
.................................................. Size: 199K
.................................................. Size: 249K
.................................................. Size: 299K
.................................................. Size: 349K
.................................................. Size: 400K
.................................................. Size: 449K
.................................................. Size: 499K
.................................................. Size: 549K
.................................................. Size: 599K
.................................................. Size: 649K
.................................................. Size: 699K
.......... Size of output: 709K
Build succeeded.
build submit error = 0
Starting testing step.
CMake Error at /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/TFW_testing_single_configure_prototype/simple_testing.cmake:193 (message):
Test failed with error -1
test submit error = 0
File upload submit error = 0
Single configure/build/test failed. The error code was: 255
Build step 'Execute shell' marked build as failure
Finished: FAILUREhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3428MueLu w/ INT_INT=OFF INT_LONG_ON=ON & Epetra ON2018-10-09T19:08:31ZJames WillenbringMueLu w/ INT_INT=OFF INT_LONG_ON=ON & Epetra ON*Created by: csiefer2*
Background: we want to build Tpetra with a single global ordinal. If Epetra is still enabled, how is this handled downstream in Xpetra and MueLu?
First off, the ETI system does not build an INT/INT MueLu:
``...*Created by: csiefer2*
Background: we want to build Tpetra with a single global ordinal. If Epetra is still enabled, how is this handled downstream in Xpetra and MueLu?
First off, the ETI system does not build an INT/INT MueLu:
```
-- MueLu ETI support enabled
-- <float, int, int> : OFF
-- <double, int, int> : OFF
-- <double, int, long> : OFF
-- <double, int, long long> : ON
-- <complex, int, int> : OFF
-- HAVE_MUELU_SERIAL : ON
-- HAVE_MUELU_PTHREAD : OFF
-- HAVE_MUELU_OPENMP : OFF
-- HAVE_MUELU_CUDA : OFF
```
Next the MueLu Driver fails in... unexpected ways...
```
csiefer@lightsaber> ./MueLu_Driver.exe --linAlgebra=Epetra
Skip running with Epetra since both Epetra and Tpetra are enabled but Tpetra is not instantiated on double, int, int.
```
```
csiefer@lightsaber> ./MueLu_Driver.exe --linAlgebra=Tpetra
```
(works fine)
[jhux2: edited formatting]https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3415Xpetra: Don't create new Belos::{MultiVec,Operator}Traits specializations; ju...2018-09-11T00:03:06ZJames WillenbringXpetra: Don't create new Belos::{MultiVec,Operator}Traits specializations; just use Belos::{MultiVec, Operator}*Created by: mhoemmen*
@trilinos/muelu @trilinos/xpetra @trilinos/belos @lucbv
Xpetra creates specializations of Belos::MultiVecTraits and Belos::OperatorTraits for Xpetra types, in order for MueLu to use Belos. This instantiates B...*Created by: mhoemmen*
@trilinos/muelu @trilinos/xpetra @trilinos/belos @lucbv
Xpetra creates specializations of Belos::MultiVecTraits and Belos::OperatorTraits for Xpetra types, in order for MueLu to use Belos. This instantiates Belos all over again for all possible template parameter combinations that Xpetra instantiates. Xpetra could instead implement subclasses of `Belos::MultiVec<Scalar>` and `Belos::Operator<Scalar>`, and use the existing instantiations of Belos for those types.
## Motivation and Context
Goal: Only build Belos once per Scalar type.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3390STK build errors on ATDM rhel6 gcc 7.2 build2018-10-09T18:00:24ZJames WillenbringSTK build errors on ATDM rhel6 gcc 7.2 build*Created by: fryeguy52*
CC: @trilinos/stk , @kddevin (Trilinos Data Services Product Lead), @bartlettroscoe
## Next Action Status
Jenkins job driving this build was disabled on 9/8/2018 (see [here](https://jenkins-srn.sandia.go...*Created by: fryeguy52*
CC: @trilinos/stk , @kddevin (Trilinos Data Services Product Lead), @bartlettroscoe
## Next Action Status
Jenkins job driving this build was disabled on 9/8/2018 (see [here](https://jenkins-srn.sandia.gov/view/Trilinos%20ATDM/job/Trilinos-atdm-sems-gcc-7-2-0/jobConfigHistory/)). Next: Watch for build not being submitted to CDash starting 9/9/2018 ...
## Description
As shown in [this query](https://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2018-09-03&filtercombine=and&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Trilinos-atdm-sems-gcc-7-2-0&field2=buildstarttime&compare2=84&value2=now&field3=buildstarttime&compare3=83&value3=2018-8-15) There are 3 build failures in STK that began on 8/21/2018 and are still failing. On CDash the failures are the following:
Error building CMakeFiles/STKUnit_tests_util_parallel_UnitTest.dir/UnitTestCommNeighbors.cpp.o
Error building libstk_util_parallel.so.12.13
Error building CMakeFiles/stk_util_parallel.dir/CommNeighbors.cpp.o
[output here](https://testing.sandia.gov/cdash/viewBuildError.php?buildid=3855137#)
These failures are occurring in the build:
* Trilinos-atdm-sems-gcc-7-2-0
some examples of the kind of errors in the output
```
‘MPI_UNWEIGHTED’ was not declared in this scope
...
‘MPI_Dist_graph_create_adjacent’ was not declared in this scope
...
‘MPI_Neighbor_alltoall’ was not declared in this scope
```
## Steps to Reproduce
One should be able to reproduce this failure on the machine <supported-atdm-machine> as described in:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
More specifically, the commands given for the system <supported-atdm-system> are provided at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#sems-rhel6-environment
The exact commands to reproduce this issue should be:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh intel-opt-openmp
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnv.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_STK=ON \
$TRILINOS_DIR
$ make NP=16
$ ctest -j16 \
```Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3326ShyLU - FROsch: cerr was not declared in this scope2018-08-22T08:05:09ZJames WillenbringShyLU - FROsch: cerr was not declared in this scope*Created by: ZeeD26*
In several files that are part of the ShyLU - FROsch package `cerr` is used without either declaring `using namespace std` or `using std::cerr`, which leads to errors on compilation.*Created by: ZeeD26*
In several files that are part of the ShyLU - FROsch package `cerr` is used without either declaring `using namespace std` or `using std::cerr`, which leads to errors on compilation.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3362TPetra timers not stackable, 2018-10-12T22:23:50ZJames WillenbringTPetra timers not stackable, *Created by: bathmatt*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
If one enables the...*Created by: bathmatt*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
If one enables the tpetra timers you find that they are started and stopped not in a sequence. You stop a timer when it isn't the last one started. You are probably keeping RCPs to timers..
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/tpetra
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
Expect the timers to be on a stack.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
I can't get timing info from tpetra,
Here is error message
```
ctest -R PanzerAdaptersSTK_projection
*********************************************************************
WARNING: Overlapping timers detected!
A TimeMonitor timer was stopped before a nested subtimer was
stopped. This is not allowed by the StackedTimer. This corner case
typically occurs if the TimeMonitor is stored in an RCP and the RCP is
assigned to a new timer. To disable this warning, either fix the
ordering of timer creation and destuction or disable the StackedTimer
support in the TimeMonitor by setting the StackedTimer to null
with:
Teuchos::TimeMonitor::setStackedTimer(Teuchos::null)
*********************************************************************
```
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
->
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
1. Enable tpetra timers -D Tpetra_ENABLE_MMM_Timings=ON
1. Enable panzer tests
1. Run panzer tests ctest -R PanzerAdaptersSTK_projection
1. Shake fist angrily at computer.
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant repo SHA1s:**
- **Relevant configure flags or configure script:**
- **Operating system and version:**
- **Compiler and TPL versions:**
## Related Issues
<!---
If applicable, let us know how this bug is related to any other open issues:
-->
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to
* Part of
* Composed of
## Additional Information
<!---
Anything else that might be helpful for us to know in addressing this issue:
* Configure log file:
* Build log file:
* Test log file:
* When was the last time everything worked (date/time; SHA1s; etc.)?
* What did you do that made the bug rear its ugly head?
* Have you tried turning it off and on again?
-->
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3360Trilinos PR testing needs a build with KOKKOS_ENABLE_DEPRECATED_CODE=OFF2018-08-27T17:35:56ZJames WillenbringTrilinos PR testing needs a build with KOKKOS_ENABLE_DEPRECATED_CODE=OFF*Created by: mhoemmen*
@trilinos/framework
Trilinos developers keep adding use of deprecated Kokkos functions back into Trilinos. See e.g., #3358. They do so because no PR test builds disable deprecated Kokkos functions, and becau...*Created by: mhoemmen*
@trilinos/framework
Trilinos developers keep adding use of deprecated Kokkos functions back into Trilinos. See e.g., #3358. They do so because no PR test builds disable deprecated Kokkos functions, and because Trilinos enables deprecated Kokkos functions by default. If we disable deprecated Kokkos functions in at least one PR test build, Trilinos developers will learn not to rely on those functions.
## Motivation and Context
See Sierra Ticket 19694.
## Possible Solution
In at least one PR test build, set KOKKOS_ENABLE_DEPRECATED_CODE=OFF.
## Related Issues
* Related to #3358 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3350Amesos: limit of dimension or nonzero-entries of the matrix?2018-08-25T03:17:55ZJames WillenbringAmesos: limit of dimension or nonzero-entries of the matrix?*Created by: freaklovesmango*
I had a matrix with a dimension over 2.5 Million and it works for Amesos with the Pardiso Solver, the number of nonzeros was about 200 Million). However, as I changed the Solver to the Klu solver, it didn't...*Created by: freaklovesmango*
I had a matrix with a dimension over 2.5 Million and it works for Amesos with the Pardiso Solver, the number of nonzeros was about 200 Million). However, as I changed the Solver to the Klu solver, it didn't work anymore. The resulted vector was filled with zeros.
So my question is why and has Amesos (or one of its Solver Library) a general constraint in either the dimension or number of nonzeros of the matrix?https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3328Teko: make Epetra dependency optional2018-08-21T19:41:52ZJames WillenbringTeko: make Epetra dependency optional*Created by: ibaned*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that any...*Created by: ibaned*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/teko
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
It should be possible to install Teko without having to build Epetra, if one is using only Tpetra-stack solvers.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
We have reports that Teko depends on `ThyraEpetraAdapters`, which requires building Epetra.
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
Applications that use only Tpetra-stack tools would prefer not to spend time compiling the Epetra stack.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3323Panzer: add better error handling for teko coordinate callback interface2018-08-20T11:35:07ZJames WillenbringPanzer: add better error handling for teko coordinate callback interface*Created by: rppawlo*
When the teko callback interface is used to register coordinate support, if the "Coordinates" field name can't be found in the DOF manager it assumes that it must be in the auxiliary DOF Manager and just accesses t...*Created by: rppawlo*
When the teko callback interface is used to register coordinate support, if the "Coordinates" field name can't be found in the DOF manager it assumes that it must be in the auxiliary DOF Manager and just accesses the object. If the aux_blocked_ugi_ is null then we get a seg fault. Additionally even if it exists, we need to add a check to make sure the field exists in the aux_blocked_ugi_ object.
This is for the file:
Panzer_STK_ParameterListCallbackBlocked_impl.hpp:141
@trilinos/panzer
@egphill https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3282Random test failure for KokkosAlgorithms_UnitTest_MPI_1 in ATDM build?2018-11-30T11:16:53ZJames WillenbringRandom test failure for KokkosAlgorithms_UnitTest_MPI_1 in ATDM build?*Created by: bartlettroscoe*
CC: @trilinos/kokkos, @fryeguy52, @kddevin (Trilinos Data Services Product Lead)
## Next Action Status
The test `KokkosAlgorithms_UnitTest_MPI_1` is expected to randomly fail occasionally as a comprise...*Created by: bartlettroscoe*
CC: @trilinos/kokkos, @fryeguy52, @kddevin (Trilinos Data Services Product Lead)
## Next Action Status
The test `KokkosAlgorithms_UnitTest_MPI_1` is expected to randomly fail occasionally as a comprise between test runtime and not randomly failing more often. Next: Match for this failing test more and decide how to handle it longer-term (such as treating it as "expected may fail" as part of #2933) ....
## Description
The test `KokkosAlgorithms_UnitTest_MPI_1` looks to have had a random failure in the ATDM Trilinos build `Trilinos-atdm-hansen-shiller-intel-opt-serial` shown [here](https://testing-vm.sandia.gov/cdash/testDetails.php?test=52067584&build=3819525) which shows the output:
```
[ RUN ] serial.Random_XorShift1024
Test Seed:1533901314858176575
Test Scalar=int
-- Testing randomness properties
Pass: 1 1 -2.75867e-05 -4.42521e-05 0.000158617 || 0.000502704
-- Testing 1-D histogram
Density 1D: 7.26597e-05 0.0178458 0.00132233 || 0.051031 2035 2407 || 2159.68 2198.22 || 18.2798 -0.159026
-- Testing 3-D histogram
Density 3D: 7.26597e-05 -0.00698725 -3.92889e-05 || 0.051031 1e+64 -1e+64
Test Scalar=unsigned int
-- Testing randomness properties
Pass: 1 1 1.68802e-05 9.3101e-05 -8.45415e-05 || 0.000502704
-- Testing 1-D histogram
Density 1D: 7.26597e-05 -0.00149644 -0.000557499 || 0.051031 2025 2373 || 2201.52 2198.22 || -7.70686 -0.159026
-- Testing 3-D histogram
Density 3D: 7.26597e-05 -0.00456695 -0.00055943 || 0.051031 1e+64 -1e+64
Test Scalar=int64_t
-- Testing randomness properties
Pass: 1 0 1.89669e-05 0.000837141 -0.000265228 || 0.000502704
-- Testing 1-D histogram
Density 1D: 7.26597e-05 -0.0166374 0.00138102 || 0.051031 2005 2386 || 2235.41 2198.22 || 19.0912 -0.159026
-- Testing 3-D histogram
Density 3D: 7.26597e-05 0.000533505 -0.000342069 || 0.051031 1e+64 -1e+64
/home/jenkins/hansen/workspace/Trilinos-atdm-hansen-shiller-intel-opt-serial/SRC_AND_BUILD/Trilinos/packages/kokkos/algorithms/unit_tests/TestRandom.hpp:426: Failure
Value of: 1
Expected: test_int64.pass_var
Which is: 0
[ FAILED ] serial.Random_XorShift1024 (1840 ms)
[ RUN ] serial.SortUnsigned
[ OK ] serial.SortUnsigned (2699 ms)
[----------] 3 tests from serial (8593 ms total)
[----------] Global test environment tear-down
[==========] 3 tests from 1 test case ran. (8593 ms total)
[ PASSED ] 2 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] serial.Random_XorShift1024
1 FAILED TEST
```
There was no updates to Kokkos from previous day for this build as shown [here](https://testing-vm.sandia.gov/cdash/viewNotes.php?buildid=3819519#!#note6). Therefore, one would assume this is a random failure of some type.
## Steps to reproduce
One should be able to produce this build and run this test on either 'hansen' or 'shiller' as described at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
More specifically, one can follow the instructions at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#shillerhansen
and use the build name `intel-opt-serial` enable the package `Kokkos` as:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh intel-opt-serial
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnv.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_Kokkos=ON \
$TRILINOS_DIR
$ make NP=16
$ srun ctest -j16
```
But given that this test looks to have randomly failed, it might be hard to reproduce.
Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3286Zoltan2 test zoltanCompare may fail with Tpetra_INST_INT_INT=OFF2018-08-17T22:45:21ZJames WillenbringZoltan2 test zoltanCompare may fail with Tpetra_INST_INT_INT=OFF*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/zoltan2
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Zoltan2 test zoltanCompare may fail with Tpetra_INST_INT__INT=OFF due to differences in the way 64-bit are represented in the test’s interface to Zoltan and Zoltan2’s interface to Zoltan. Failing component tests are PHG. The different representations of 64-bit ids lead to different hash values and different visit orders and, thus, different partitions in the test. We will need to fix the test to use the same representation as the Zoltan2 interface.
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
- [ ] First do this.
- [ ] Then do that.
- [ ] Also this other thing.
-->
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
I saw this failure on mac with Tpetra_INST_INT__INT=OFF
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant repo SHA1s:**
- **Relevant configure flags or configure script:**
- **Operating system and version:**
- **Compiler and TPL versions:**
## Related Issues
* Related to #3194
## Additional Information
<!---
Anything else that might be helpful for us to know in addressing this issue:
* Configure log file:
* Build log file:
* Test log file:
* When was the last time everything worked (date/time; SHA1s; etc.)?
* What did you do that made the bug rear its ugly head?
* Have you tried turning it off and on again?
-->https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3276Trilinos auto PR tester stability issues2019-05-02T13:20:11ZJames WillenbringTrilinos auto PR tester stability issues*Created by: bartlettroscoe*
@trilinos/framework
## Description
Over the last few weeks and months, the Trilinos auto PR tester has seen several cases where one or more PR builds for a given PR testing iteration failed to produce ...*Created by: bartlettroscoe*
@trilinos/framework
## Description
Over the last few weeks and months, the Trilinos auto PR tester has seen several cases where one or more PR builds for a given PR testing iteration failed to produce results on CDash or showed build or test failures that were not related to the changes on that particular PR.
This Story is to log these fails and keep track of them in order to provide some statistics about these cases in order to inform how to address them. This should replace making comments in individual PRs that exhibit these types of problems like #3260 and #3213.
## PR Builds Showing Random Failures
Below are a few examples of the stability problems (but are not all of the problems).
| PR ID | Num PR Builds to reach passing | First test trigger | Start first test| Passing test | Merge PR |
| --: | --: | --: | --: | --: | --: |
| #3258 | 2 | [8/8/2018 2:35 PM ET](https://github.com/trilinos/Trilinos/pull/3258#issue-207098955) | [8/8/2018 2:44 PM](https://github.com/trilinos/Trilinos/pull/3258#issuecomment-411510956) | [8/8/2018 9:15 PM ET]() | Not merged |
| #3260 | 4 | [8/8/2018 5:22 PM ET](https://github.com/trilinos/Trilinos/pull/3260#issue-207141537) | [8/8/2018 6:31 PM ET](https://github.com/trilinos/Trilinos/pull/3260#issuecomment-411574370) | [8/10/2018 4:13 AM ET](https://github.com/trilinos/Trilinos/pull/3260#issuecomment-412010497) | [8/10/2018 8:25 AM](https://github.com/trilinos/Trilinos/pull/3260#event-1782381644) |
| #3213 | 3 | [7/31/2018 4:30 PM ET](https://github.com/trilinos/Trilinos/pull/3213#issue-205233060) | [7/31/2018 4:57 PM ET](https://github.com/trilinos/Trilinos/pull/3213#issuecomment-409365522) | [8/1/2018 9:48 AM ET](https://github.com/trilinos/Trilinos/pull/3213#issuecomment-409580677) | [8/1/2018 9:53 AM ET](https://github.com/trilinos/Trilinos/pull/3213#event-1765281809) |
| #3098 | 4 | [7/12/2018 12:52 PM ET](https://github.com/trilinos/Trilinos/pull/3098#issue-201063953) | [7/12/2018 1:07 PM ET](https://github.com/trilinos/Trilinos/pull/3098#issuecomment-404582631) | [7/13/2018 11:12 PM ET](https://github.com/trilinos/Trilinos/pull/3098#issuecomment-404994581) | [7/14/2018 10:59 PM ET](https://github.com/trilinos/Trilinos/pull/3098#event-1733896640) |
| #3369 | 6 | [8/29/2018 9:08 AM ET](https://github.com/trilinos/Trilinos/pull/3369#issue-211746901) | [8/29/2018 9:16 AM ET](https://github.com/trilinos/Trilinos/pull/3369#issuecomment-416948915) | [8/31/2018 6:09 AM ET](https://github.com/trilinos/Trilinos/pull/3369#issuecomment-417618824) | [8/31/2018 8:33 AM ET](https://github.com/trilinos/Trilinos/pull/3369#event-1820478271) |
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3272package_subproject_list.cmake static in Trilinos PR tester?2018-08-09T19:58:47ZJames Willenbringpackage_subproject_list.cmake static in Trilinos PR tester?*Created by: bartlettroscoe*
@trilinos/framework,
Is the file package_subproject_list.cmake used at:
https://github.com/trilinos/Trilinos/blob/0df591fd6d9b9ccd91bd2695cc22665aa468886d/cmake/std/PullRequestLinuxDriver.sh#L206
st...*Created by: bartlettroscoe*
@trilinos/framework,
Is the file package_subproject_list.cmake used at:
https://github.com/trilinos/Trilinos/blob/0df591fd6d9b9ccd91bd2695cc22665aa468886d/cmake/std/PullRequestLinuxDriver.sh#L206
statically generated and require manual updating? If so, that would explain why the PR builds are not testing the new PT package TrilinosFrameworkTests.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3263Test ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1 randomly failing in CI and...2018-08-09T19:59:42ZJames WillenbringTest ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1 randomly failing in CI and PR GCC 4.8.4 + OpenMP builds*Created by: bartlettroscoe*
@trilinos/shylu, @trilinos/framework, @srajama1 (Trilinos Linear Solvers Product Lead)
## Expectations
A test should not fail unless a changes is made to break it. A test should not randomly fail.
...*Created by: bartlettroscoe*
@trilinos/shylu, @trilinos/framework, @srajama1 (Trilinos Linear Solvers Product Lead)
## Expectations
A test should not fail unless a changes is made to break it. A test should not randomly fail.
## Current Behavior
Looking at the four most recent failures of the test `ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1` in [this query](https://testing-vm.sandia.gov/cdash/queryTests.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=4&showfilters=1&filtercombine=and&field1=testname&compare1=61&value1=ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1&field2=status&compare2=62&value2=passed&field3=status&compare3=62&value3=notrun&field4=buildstarttime&compare4=84&value4=now) the test appears to be randomly failing in the GCC 4.8.4 OpenMPI builds. In the most recent case, this test broke the auto PR GCC 4.8.4 + OpenMP build in PR #3260. IN each of the last for failures of this test dating back to 6/28/2018, they all fail showing:
```
....
[ RUN ] CrsMatrixBase.matrixmarket
unknown file: Failure
C++ exception with description "View bounds error of view ap ( 13 < 13 )
Traceback functionality not available
" thrown in the test body.
[ FAILED ] CrsMatrixBase.matrixmarket (23 ms)
...
[ FAILED ] 1 test, listed below:
[ FAILED ] CrsMatrixBase.matrixmarket
1 FAILED TEST
```
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
## Definition of Done
The test `ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1` is fixed to make it so that it does not randomly fail or is removed for CI and auto PR testing.
## Possible Solution
Fix it so that it does not randomly fail or remove it from CI and auto PR testing.
## Steps to Reproduce
See https://github.com/trilinos/Trilinos/wiki/Reproducing-PR-Testing-Errors.
## Your Environment
Standard SEMS GCC 4.8.4 auto PR build env (see above).