Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-04-09T12:50:24Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4551New STKUnit test failing in ATDM CUDA PT build on white2019-04-09T12:50:24ZJames WillenbringNew STKUnit test failing in ATDM CUDA PT build on white*Created by: fryeguy52*
CC: @trilinos/stk, @kddevin (Trilinos Data Services Product Lead), @bartlettroscoe, @fryeguy52
## Next Action Status
<status-and-or-first-action>
## Description
As shown in [this query](https://test...*Created by: fryeguy52*
CC: @trilinos/stk, @kddevin (Trilinos Data Services Product Lead), @bartlettroscoe, @fryeguy52
## Next Action Status
<status-and-or-first-action>
## Description
As shown in [this query](https://testing.sandia.gov/cdash/queryTests.php?project=Trilinos&filtercombine=and&filtercombine=&filtercombine=and&filtercount=5&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-release-debug-pt&field2=testname&compare2=61&value2=STKUnit_tests_stk_ngp_test_utest_MPI_4&field3=site&compare3=61&value3=white&field4=buildstarttime&compare4=84&value4=2019-03-05T00%3A00%3A00&field5=buildstarttime&compare5=83&value5=2019-02-03T00%3A00%3A00) the test:
* STKUnit_tests_stk_ngp_test_utest_MPI_4
is failing in the builds:
* Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-release-debug-pt
[Test Output on CDash](https://testing.sandia.gov/cdash/testDetails.php?test=69483834&build=4654832)
This looks like a new test that was added on 2019-02-22 and has been failing since
## Current Status on CDash
[The current status and recent history of this test](https://testing.sandia.gov/cdash/queryTests.php?project=Trilinos&date=2019-03-06&filtercombine=and&filtercombine=and&filtercount=5&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-release-debug-pt&field2=testname&compare2=61&value2=STKUnit_tests_stk_ngp_test_utest_MPI_4&field3=site&compare3=61&value3=white&field4=buildstarttime&compare4=84&value4=today&field5=buildstarttime&compare5=83&value5=14%20days%20ago)
## Steps to Reproduce
One should be able to reproduce this failure on ride or white as described in:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
More specifically, the commands given for ride or white are provided at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#ridewhite
The exact commands to reproduce this issue should be:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-release-debug-pt
$ 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
$ bsub -x -Is -q rhel7F -n 16 ctest -j16
```Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4571Long file names in KokkosKernels have broken git clone of Trilinos on Windows2019-03-07T19:52:38ZJames WillenbringLong file names in KokkosKernels have broken git clone of Trilinos on Windows*Created by: bartlettroscoe*
CC: @trilinos/framework, @trilinos/kokkos-kernels
## Description
It appears that the Trilinos git repo has gotten into a state where it can't even be cloned on Windows systems with git.
The CASL PH...*Created by: bartlettroscoe*
CC: @trilinos/framework, @trilinos/kokkos-kernels
## Description
It appears that the Trilinos git repo has gotten into a state where it can't even be cloned on Windows systems with git.
The CASL PHI INF lead @lefebvrera reported the following error when trying to clone the current Trilinos git repo just a short time ago:
```
G:\raq\scale_dev\dev>git clone https://github.com/trilinos/Trilinos.git Trilinos
Cloning into 'Trilinos'...
remote: Enumerating objects: 47, done.
remote: Counting objects: 100% (47/47), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 957120 (delta 17), reused 14 (delta 7), pack-reused 957073
Receiving objects: 100% (957120/957120), 562.05 MiB | 26.56 MiB/s, done.
Resolving deltas: 100% (771153/771153), done.
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_numeric/KokkosSparse_gauss_seidel_numeric_eti_spec_inst_Kokkos_complex_double__size_t_int64_t_LayoutRight_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_double__size_t_int64_t_LayoutLeft_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_double__size_t_int64_t_LayoutRight_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_float__size_t_int64_t_LayoutLeft_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_float__size_t_int64_t_LayoutRight_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
Checking out files: 100% (56578/56578), done.
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4563Amesos2: Umfpack + Superlu compile failure when complex_double enabled2019-03-07T17:31:21ZJames WillenbringAmesos2: Umfpack + Superlu compile failure when complex_double enabled*Created by: ndellingwood*
Reported by Sam Browne via email.
When compiling Trilinos with Amesos2 enabled and Umfpack and Superlu TPLs a compile error results. This is due to ambiguity in matching the templated class `ValueTypeConver...*Created by: ndellingwood*
Reported by Sam Browne via email.
When compiling Trilinos with Amesos2 enabled and Umfpack and Superlu TPLs a compile error results. This is due to ambiguity in matching the templated class `ValueTypeConversionTraits` resulting in candidate specializations in both the Umfpack and Superlu TypeMaps.
Error:
```
/Users/ndellin/Research/trilinos/Trilinos/packages/amesos2/src/Amesos2_Details_registerLinearSolverFactory.cpp:102:1: required from here
/Users/ndellin/Research/trilinos/Trilinos/packages/teuchos/core/src/Teuchos_as.hpp:2830:61: error: ambiguous template instantiation for 'class Teuchos::ValueTypeConversionTraits<SLU::Z::doublecomplex, std::complex<double> >'
return ValueTypeConversionTraits<TypeTo,TypeFrom>::convert(t);
```
Fix is to add full specializations to the SuperLU TypeMap to prevent the ambiguity. PR coming in shortly.
<!---
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/amesos2
<!---
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.
-->
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4560ShyLU/FROSch: Running tests with 1 mpi rank results in runtime error 2019-03-06T19:25:03ZJames WillenbringShyLU/FROSch: Running tests with 1 mpi rank results in runtime error *Created by: chochmuth*
@trilinos/shylu
After fix #4505 it should be possible to run the Thyra_Xpetra_Laplace tests in serial.
However, when running a serial test which solves the harmonic extension with Klu2 I get the following run...*Created by: chochmuth*
@trilinos/shylu
After fix #4505 it should be possible to run the Thyra_Xpetra_Laplace tests in serial.
However, when running a serial test which solves the harmonic extension with Klu2 I get the following runtime error from Amesos2: `Amesos2 Runtime Error: sp_colind returned null`.
For the speacial case of 1 mpi rank we need to check wether to compute extension or not.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4544Belos: Register new Tpetra-specific (pipelined & CA) solvers with SolverFactory2019-03-07T15:49:42ZJames WillenbringBelos: Register new Tpetra-specific (pipelined & CA) solvers with SolverFactory*Created by: mhoemmen*
@trilinos/belos @iyamazaki @jhux2
## Expectations
Users should be able to request any available Belos solver at run time without changing their code. These solvers include the new pipelined and communicati...*Created by: mhoemmen*
@trilinos/belos @iyamazaki @jhux2
## Expectations
Users should be able to request any available Belos solver at run time without changing their code. These solvers include the new pipelined and communication-avoiding solvers implemented specifically for Tpetra.
## Current Behavior
Users must do `extern` declarations for the run-time registration functions for these solvers, and call these functions. See the tests in `belos/tpetra/test/Native` for examples.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4545Belos: Split out run-time SolverFactory registration of Tpetra specialization...2019-03-05T18:11:02ZJames WillenbringBelos: Split out run-time SolverFactory registration of Tpetra specializations of generic Belos solvers, into separate C++ files*Created by: mhoemmen*
@trilinos/belos
## Expectations
`Belos::SolverFactory` needs to build as fast as possible.
## Current Behavior
Instantiation of run-time registration functions for Tpetra specializations of generic Be...*Created by: mhoemmen*
@trilinos/belos
## Expectations
`Belos::SolverFactory` needs to build as fast as possible.
## Current Behavior
Instantiation of run-time registration functions for Tpetra specializations of generic Belos solvers currently happen all in one file. This increases build time and size. Separate out those instantiations into separate C++ files, one file per Belos solver.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4540Is it possible to enable Scalar=float in Tpetra but not downstream (e.g., in ...2019-03-04T22:41:56ZJames WillenbringIs it possible to enable Scalar=float in Tpetra but not downstream (e.g., in MueLu)?*Created by: mhoemmen*
@trilinos/tpetra @trilinos/muelu
I'm asking on behalf of @vbrunini .
*Created by: mhoemmen*
@trilinos/tpetra @trilinos/muelu
I'm asking on behalf of @vbrunini .
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4537Amesos2 does not compile with UMFPACK, SuperLU, complex double, and eti=off2019-03-07T21:17:35ZJames WillenbringAmesos2 does not compile with UMFPACK, SuperLU, complex double, and eti=off*Created by: prwolfe*
Basically the compiler cannot chose from 2 convert functions, but does fine the ETI is on as the instantiation gets only one at a time.
@trilinos/amesos2
## Expectations
Amesos2 should build either with or ...*Created by: prwolfe*
Basically the compiler cannot chose from 2 convert functions, but does fine the ETI is on as the instantiation gets only one at a time.
@trilinos/amesos2
## Expectations
Amesos2 should build either with or without ETI on
## Current Behavior
A build matching https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=4650329 but with ETI=off will fail to compile Amesos2_Details_registerLinearSolverFactory.cpp.o because it cannot pick between
packages/amesos2/src/Amesos2_Umfpack_TypeMap.hpp:98:7: error: candidates are: class Teuchos::ValueTypeConversionTraits<TypeTo, std::complex<double> >
class ValueTypeConversionTraits<TypeTo, std::complex<double>>
and
Trilinos/packages/amesos2/src/Amesos2_Superlu_TypeMap.hpp:192:7: error: class Teuchos::ValueTypeConversionTraits<SLU::Z::doublecomplex, TypeFrom>
class ValueTypeConversionTraits<SLU::Z::doublecomplex, TypeFrom>
These take opposite approaches, but can both fulfill the request.
## Motivation and Context
This was found when checking a trilinos build against Sierra. Customers should be able to build either with or without ETI or one options should be disabled.
I am tagging framework as we need to make sure we have a t least one build that covers this at some level (we currently do all builds with ETI=on as far as I can tell.)
## Definition of Done
Amesos2 compiles both with and without ETI and the requested packages available.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4542Tpetra: Add computeRowOneNorms function2019-03-10T06:10:06ZJames WillenbringTpetra: Add computeRowOneNorms function*Created by: mhoemmen*
@trilinos/tpetra
@vbrunini requests that we add `Tpetra::computeRowOneNorms`. His app has the option to scale linear systems only on the left side, only by row norms. The existing `Tpetra::computeRowAndColum...*Created by: mhoemmen*
@trilinos/tpetra
@vbrunini requests that we add `Tpetra::computeRowOneNorms`. His app has the option to scale linear systems only on the left side, only by row norms. The existing `Tpetra::computeRowAndColumnOneNorms` function already has an option not to compute column norms (set `assumeSymmetric=true`), but it still communicates the row norms to the column Map distribution for symmetric scaling. @vbrunini doesn't even want to communicate the row norms, since he doesn't plan to right-scale with them.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4532Provide correct and accurate Trilinos version info during development to help...2019-04-05T13:37:59ZJames WillenbringProvide correct and accurate Trilinos version info during development to help address changes in backward compatibility*Created by: bartlettroscoe*
CC: @trilinos/framework, @fryeguy52
## Description
The current setup of Trilinos is that it contains a static version-controlled `Version.cmake` file with static version information:
```
SET(Trili...*Created by: bartlettroscoe*
CC: @trilinos/framework, @fryeguy52
## Description
The current setup of Trilinos is that it contains a static version-controlled `Version.cmake` file with static version information:
```
SET(Trilinos_VERSION 12.13)
SET(Trilinos_MAJOR_VERSION 12)
SET(Trilinos_MAJOR_MINOR_VERSION 121300)
SET(Trilinos_VERSION_STRING "12.13 (Dev)")
SET(Trilinos_ENABLE_DEVELOPMENT_MODE_DEFAULT ON) # Change to 'OFF' for a release
```
This info is used to configure the `Trilinos_version.h` file in the build directory that is installed with the contents:
```
#define TRILINOS_MAJOR_VERSION 12
#define TRILINOS_MAJOR_MINOR_VERSION 121300
#define TRILINOS_VERSION_STRING "12.13 (Dev)"
```
The even/odd minor version number (13 currently) does tell the user if one is looking at an (odd-numbere) development version or an (even-numbered) release version but it does not give enough info for codes that use almost continuous integration with Trilinos (e.g. ASC Sierra, ATDM APPs, etc.). For example, Trilinos breaks backward compatibility from time to time which causes downstream customer codes to fail to build or pass all of the tests. In a staged integration processes for customer APPs like ATDM SPARC (see [TRIL-243](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-243) and [TRIL-256](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-256)), the SPARC 'master' code needs to be able to build and pass tests against both their older accepted version of Trilinos and a newer Trilinos version on the 'develop' (or 'master') branch. To accomplish this, when Trilinos 'develop' breaks backward compatibility, APP customer codes need to add ifdefs and other conditional logic to know what version of Trilinos they are pointing to. In particular, they need to know if they are pointing a version of Trilinos before or after a particular version that breaks backward compatibility. For example, they need to be able to write ifdefs like:
```
# if <current-trilinos-version> >= <known-version-that-breaks-x>
# This is a newer version of Trilinos and we need to adjust for that change
...
#else
# This is an older version of Trilinos were our current code works just fine
...
#endif
```
A Trilinos installation needs to be able to advertise its exact development version both at configure-time and at compile-time to enable logic like above.
Whatever solution is provided, it must be able to determine in simple C/C++ processor logic if a version of Trilinos is greater or less than some known version where a break in backward compatibility or a new feature is added. It must work from direct builds of Trilinos and installations of Trilinos as well as from builds and installations created from source tarballs of Trilinos.
NOTE: Comparing git SHA1s is not an option because one must have access to the git repo in order compare versions with < or > comparisons and an installation of Trilinos does not have a full git repo.
## Proposed Solution
One way to provide the desired version info is to add the macro define:
```
#define TRILINOS_VERSION_DATE YYYYMMDDhh
```
which gives a monotonically increasing 10-digit integer for the version of Trilinos in terms of the 4-digit year (`YYYY`), 2-digit month (`MM`), 2-digit day (`DD`) and 2-digit hour (`hh`) that is taken from the git commit date (in UTC).
This 10-digit integer would fit in a 32-bit integer with a max signed value of `2^32/2 - 1` = `2147483647`. Therefore, this could represent the Trilinos version every hour till the end of the year 2147 (or 128 years from now) with the last hour being `2147 12 31 23` = `2147123123`. (Surely 64-bit integers will be handled in all C++ compilers in the year 2148).
This macro could be defined in a **new** file `Trilinos_version_date.h` that would not be included by any Trilinos code or tests (so as to not trigger any rebuilding of any Trilinos libraries or exectuables). This file would only get included by client source files that needs to know the exact fine-grained Trilinos version.
This date would be generated automatically from the git commit date of first-parent commits on the Trilinos 'develop' branch which gives a monotonically increasing date/time stamp. For example, the commit:
```
commit 930294d48f4661013265448c1f254a667c66bf0f
Merge: 6354c01 87054d8
Author: trilinos-autotester <trilinos-autotester@trilinos.org>
Date: Fri Mar 1 19:34:15 2019 -0700
Merge Pull Request #4530 from rppawlo/Trilinos/nox-remove-deprecated-code
Automatically Merged using Trilinos Pull Request AutoTester
PR Title: NOX: remove deprecated code
PR Author: rppawlo
```
has the commit date in UTC:
```
$ env TZ=GMT git log --format="%cd" --date=iso-local -1 930294d
2019-03-02 02:34:15 +0000
```
This date returned from this git command `2019-03-02 02:34:15` could be read in and set the date/time integer:
```
#define TRILINOS_VERSION_DATE 201903020234
```
A 32-bit integer in the C/C++ processor will be able to handle date/time integers of this format and correctly do integer comparisons with them.
To accomplish this, one could configure the file `Version.cmake` into the build directory from the template `Trilinos/cmake/Version.cmake.in` and then put that `Version.cmake` file in the install directory, put it into the source tarball, and also install it into the installation directory from the source tarball. (This would be exactly how this is done for the `<Project>RepoVersion.txt` file, see [here](https://tribits.org/doc/TribitsBuildReference.html#generating-a-project-repo-version-file).) Then `Trilinos_version_date.h` would be generated from `TRILINOS_VERSION_DATE` in the generated `Version.cmake` file.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4526Allow enable of TpetraTSQR to support SPARC2019-03-07T20:19:16ZJames WillenbringAllow enable of TpetraTSQR to support SPARC*Created by: bartlettroscoe*
CC: @mhoemmen, @fryeguy52, @kddevin (Trilinos Data Services Product Lead), @trilinos/tpetra
The SPARC team has requested the enable of the TpetraTSQR subpackage to usage in SPARC. Currently the ATDM Tri...*Created by: bartlettroscoe*
CC: @mhoemmen, @fryeguy52, @kddevin (Trilinos Data Services Product Lead), @trilinos/tpetra
The SPARC team has requested the enable of the TpetraTSQR subpackage to usage in SPARC. Currently the ATDM Trilinos configuration explicitly disables TpetraTSQR by default (because it was not being usesd by SPARC or EMPIRE).
But note that TpetraTSQR is enabled by default in the Trilinos PR builds, for example, as shown in the [GCC 4.8.4 build](https://testing.sandia.gov/cdash-dev-view/viewConfigure.php?buildid=4633913) and [CUDA 9.2 build](https://testing.sandia.gov/cdash-dev-view/viewConfigure.php?buildid=4633967) which showed:
```
Final set of enabled SE packages: ... TpetraTSQR ... 137
```
Therefore, it should be safe to allow the enable of TpetraTSQR in the ATDM Trilinos builds.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4507FEI: Remove Build Warnings2019-03-15T03:39:43ZJames WillenbringFEI: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/fei
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
FEI builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently FEI has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for FEI. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4623057).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4521No Incomplete Cholesky Factorization in Ifpack22019-03-13T15:57:12ZJames WillenbringNo Incomplete Cholesky Factorization in Ifpack2*Created by: davoodansari*
<!---
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: ".
-->
Migrating from E...*Created by: davoodansari*
<!---
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: ".
-->
Migrating from Epetra to Tpetra, unfortunately Ifpack2 does not seem to have an ICT preconditioner available. Symmetric operators occur in many problems and the availability of an ICT (just like legacy Ifpack) is probably more than a nice to have. Any comments about long term plans or advice on short term solution or alternatives is highly appreciated.
Thanks
<!---
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/<teamName>
<!---
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.
-->
## 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.
-->
## 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/4514SEACAS: Remove Build Warnings2019-05-01T18:29:55ZJames WillenbringSEACAS: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/seacas
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
SEACAS builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently SEACAS has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for SEACAS. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4624441).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4512ML: Remove Build Warnings2019-05-01T18:29:13ZJames WillenbringML: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/ml
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
ML builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently ML has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for ML. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4624536).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4515Stokhos: Remove Build Warnings2019-05-01T18:30:02ZJames WillenbringStokhos: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/stokhos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
Stokhos builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently Stokhos has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for Stokhos. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4624610).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4513MueLu: Remove Build Warnings2019-03-07T16:28:26ZJames WillenbringMueLu: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/muelu
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
MueLu builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently MueLu has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for MueLu. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4624484).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4508Ifpack: Remove Build Warnings2019-02-28T16:52:20ZJames WillenbringIfpack: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/ifpack
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
Ifpack builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently Ifpack has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for Ifpack. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4623061).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4506Domi: Remove Build Warnings2019-05-01T18:29:06ZJames WillenbringDomi: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/domi
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
Domi builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently Domi has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for Domi. The CDash report can be found [here](https://testing.sandia.gov/cdash/viewBuildError.php?buildid=4623054).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4509NOX: Remove Build Warnings2019-03-19T18:07:45ZJames WillenbringNOX: Remove Build Warnings*Created by: ZUUL42*
<!---
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: ZUUL42*
<!---
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/nox
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
NOX builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently NOX has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for NOX. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4623125).
## 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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.