Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-12-09T20:57:02Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2068Dashboard ride CUDA build fails in config; can't find BLAS2017-12-09T20:57:02ZJames WillenbringDashboard ride CUDA build fails in config; can't find BLAS*Created by: mhoemmen*
The Dashboard CUDA build for ride does not pass the configure process, because it fails to find the BLAS:
https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3264127
@trilinos/framework
## Expecta...*Created by: mhoemmen*
The Dashboard CUDA build for ride does not pass the configure process, because it fails to find the BLAS:
https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3264127
@trilinos/framework
## Expectations
Working ride Dashboard build.
## Current Behavior
The ride build doesn't get through the configure process, because it can't find the BLAS.
## Motivation and Context
Applications use Trilinos on ride with CUDA, and need to see a working Dashboard build.
## Possible Solution
Talk to @micahahoward et al. to see how they build on ride. Match their CMake configuration.
## Steps to Reproduce
1. Gaze upon the Dashboard
2. Behold, the ride build reports an error at configure time
## Related Issues
* Related to #1753, #1699, #1675, #1574, #1216
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1999shylu build failure: gtest/gtest.h: No such file or directory2018-09-21T22:35:28ZJames Willenbringshylu build failure: gtest/gtest.h: No such file or directory*Created by: nschloe*
Since recently, I'm getting build failures like
```
/path/to/packages/shylu/shylu_node/tacho/unit-test/Tacho_TestSerial_double.cpp:1:25:
fatal error: gtest/gtest.h: No such file or directory
#include <gtest/g...*Created by: nschloe*
Since recently, I'm getting build failures like
```
/path/to/packages/shylu/shylu_node/tacho/unit-test/Tacho_TestSerial_double.cpp:1:25:
fatal error: gtest/gtest.h: No such file or directory
#include <gtest/gtest.h>
^
```
on master ([full details](https://launchpadlibrarian.net/345861590/buildlog_ubuntu-zesty-amd64.trilinos_12.13~git201711150649-efee3717-1zesty1_BUILDING.txt.gz)). Installing `libgtest-dev` probably fixes this, but I guess this sort of compile error wants to be intercepted by CMake; see [`FindGTest`](https://cmake.org/cmake/help/v3.0/module/FindGTest.html).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1995Anasazi,Belos,Stratimikos,Teuchos: Remove use of HAVE_COMPLEX macro2017-11-16T21:32:46ZJames WillenbringAnasazi,Belos,Stratimikos,Teuchos: Remove use of HAVE_COMPLEX macro*Created by: mhoemmen*
Anasazi, Belos, and Stratimikos all use the `HAVE_COMPLEX` macro. This is defined (unconditionally!) in `Teuchos_ConfigDefs.hpp`, where a comment marks it as a backwards compatibility measure. This macro pollute...*Created by: mhoemmen*
Anasazi, Belos, and Stratimikos all use the `HAVE_COMPLEX` macro. This is defined (unconditionally!) in `Teuchos_ConfigDefs.hpp`, where a comment marks it as a backwards compatibility measure. This macro pollutes the global namespace; let's get rid of it.
@trilinos/anasazi @trilinos/belos @trilinos/stratimikos @trilinos/teuchos
## Motivation and Context
It's bad to pollute the global namespace with macros, especially if those macros have general, non-namespaced names that could easily collide with other projects' macros. Furthermore, the macro is unconditionally defined, so it is not meaningful.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1994ROL: Patch including <fstream> where needed2017-11-30T19:40:30ZJames WillenbringROL: Patch including <fstream> where needed*Created by: mhoemmen*
Some ROL files implicitly depend on `Teuchos_ConfigDefs.hpp` to include `<fstream>`. It wastes build time to include headers that most files don't need. The attached patch includes `<fstream>` where needed in RO...*Created by: mhoemmen*
Some ROL files implicitly depend on `Teuchos_ConfigDefs.hpp` to include `<fstream>`. It wastes build time to include headers that most files don't need. The attached patch includes `<fstream>` where needed in ROL. "Where needed" is based on enabling TeuchosCore and letting Trilinos' check-in test script enable all downstream packages, including ROL.
Here is the patch:
```
diff --git a/packages/rol/src/sol/sampler/ROL_SampleGenerator.hpp b/packages/rol/src/sol/sampler/ROL_SampleGenerator.hpp
index 7bbcb6b..35f09d1 100644
--- a/packages/rol/src/sol/sampler/ROL_SampleGenerator.hpp
+++ b/packages/rol/src/sol/sampler/ROL_SampleGenerator.hpp
@@ -47,10 +47,11 @@
#include "Teuchos_RefCountPtr.hpp"
#include "ROL_BatchManager.hpp"
#include "ROL_Vector.hpp"
+#include <fstream>
namespace ROL {
-template<class Real>
+template<class Real>
class SampleGenerator {
private:
int begin_;
@@ -72,13 +73,13 @@ public:
virtual ~SampleGenerator() {}
SampleGenerator(const Teuchos::RCP<BatchManager<Real> > &bman)
: begin_(0), bman_(bman) {}
- SampleGenerator(const SampleGenerator<Real> &sampler)
+ SampleGenerator(const SampleGenerator<Real> &sampler)
: begin_(sampler.begin_), bman_(sampler.bman_),
points_(sampler.points_), weights_(sampler.weights_) {}
virtual void update(const Vector<Real> &x) {
begin_ = 0;
- }
+ }
virtual int start(void) {
return begin_;
@@ -104,7 +105,7 @@ public:
virtual std::vector<Real> getMyPoint(const int i) const {
return points_[i];
- }
+ }
virtual Real getMyWeight(const int i) const {
return weights_[i];
```
@trilinos/rol
## Motivation and Context
Including too many header files increases build time and makes code fragile to upstream changes.
## Definition of Done
[ ] Apply the included patch to ROL.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1985Update c standard for Trillinos from c99 to c11.2017-11-13T16:21:59ZJames WillenbringUpdate c standard for Trillinos from c99 to c11.*Created by: prwolfe*
<!--- Provide a general summary of the issue in the Title above. -->
A number of trillinos files do not compile cleanly with c99 and since we are using c++11 I think it would be best to simply advance the c standa...*Created by: prwolfe*
<!--- Provide a general summary of the issue in the Title above. -->
A number of trillinos files do not compile cleanly with c99 and since we are using c++11 I think it would be best to simply advance the c standard as well. This was previously addressed in #1810 and #1974
<!---
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
<!---
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.
-->
All Trilinos codes should build without warnings and links should be expected to complete or fail based on the language specification given.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Builds contain functions that are not available in c99. That creates a warning for an implicit function declaration, and then the link resolves the symbol from the (currently common) standard library. There is nothing guaranteeing that the symbol will continue to be available.
## 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.
-->
Sierra builds are done with warnings-as-errors=on, so all these warnings cause build failures.
## Definition of Done
- [ ] Decide on a common standard for the c language between all the SART codes.
- [ ] Enforce that standard across all codes.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1977Tpetra: Build warning in test2017-11-09T18:23:16ZJames WillenbringTpetra: Build warning in test*Created by: mhoemmen*
There is a build warning in a Tpetra test: `.../Trilinos/packages/tpetra/core/test/HashTable/computeOffsetsFromCounts.cpp(106): warning: function "<unnamed>::ExecSpaceName<Kokkos::Serial>::name" was declared but n...*Created by: mhoemmen*
There is a build warning in a Tpetra test: `.../Trilinos/packages/tpetra/core/test/HashTable/computeOffsetsFromCounts.cpp(106): warning: function "<unnamed>::ExecSpaceName<Kokkos::Serial>::name" was declared but never referenced`. Whether or not it appears depends on which execution spaces Tpetra uses.
@trilinos/tpetra
## Possible Solution
Tie the instantiations of the function in question, to the correct set of enabled execution spaces.
## Steps to Reproduce
I generally see this in a CUDA build.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1900ML: Scary-looking warnings2017-10-25T19:43:00ZJames WillenbringML: Scary-looking warnings*Created by: mhoemmen*
@trilinos/ml Scary-looking warnings:
```
.../Trilinos/packages/ml/src/Operator/ml_op_utils.c:745:21: warning: incompatible pointer types passing 'idx_t **'
(aka 'long **') to parameter of type 'int **' [-...*Created by: mhoemmen*
@trilinos/ml Scary-looking warnings:
```
.../Trilinos/packages/ml/src/Operator/ml_op_utils.c:745:21: warning: incompatible pointer types passing 'idx_t **'
(aka 'long **') to parameter of type 'int **' [-Wincompatible-pointer-types]
ML_gsum_vec_int(&vtxdist,&tpwts,nprocs,matrix->comm);
^~~~~~~~
.../Trilinos/packages/ml/src/Utils/ml_utils.h:197:32: note: passing argument to parameter 'vals' here
void ML_gsum_vec_int(int *vals[], int *vals2[], int, ML_Comm *comm);
^
.../Trilinos/packages/ml/src/Operator/ml_op_utils.c:745:30: warning: incompatible pointer types passing 'idx_t **'
(aka 'long **') to parameter of type 'int **' [-Wincompatible-pointer-types]
ML_gsum_vec_int(&vtxdist,&tpwts,nprocs,matrix->comm);
^~~~~~
.../Trilinos/packages/ml/src/Utils/ml_utils.h:197:45: note: passing argument to parameter 'vals2' here
void ML_gsum_vec_int(int *vals[], int *vals2[], int, ML_Comm *comm);
^
.../Trilinos/packages/ml/src/Operator/ml_op_utils.c:2098:68: warning: implicit conversion from 'double' to 'int' changes
value from 1.0E+11 to 2147483647 [-Wliteral-conversion]
minStencil = ML_gmin_int( (proc_active ? mat->min_nz_per_row : 1e11), comm);
~~~~~~~~~~~ ^~~~
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1888Document best practices for linking apps against Trilinos with CUDA2017-10-25T21:12:28ZJames WillenbringDocument best practices for linking apps against Trilinos with CUDA*Created by: mhoemmen*
@trilinos/framework @trilinos/tpetra
It looks like applications are not linking against Trilinos with CUDA in the way that Trilinos itself builds and links with CUDA. See discussion here: https://github.com/g...*Created by: mhoemmen*
@trilinos/framework @trilinos/tpetra
It looks like applications are not linking against Trilinos with CUDA in the way that Trilinos itself builds and links with CUDA. See discussion here: https://github.com/gahansen/Albany/issues/195
This suggests that Trilinos needs to document best practices for linking applications against Trilinos with CUDA. It could be that applications have multiple good options, in which case Trilinos should document the strengths and weaknesses of each.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1718Undefined LAPACK symbols on OS X 10.12 Sierra2018-07-25T08:02:34ZJames WillenbringUndefined LAPACK symbols on OS X 10.12 Sierra*Created by: plindsa*
I'm a new user trying to build Albany on a MacBook Pro running OS X Sierra. When building Albany (and Trilinos with tests enabled, oddly enough), I get the following error:
Undefined symbols for architecture x86...*Created by: plindsa*
I'm a new user trying to build Albany on a MacBook Pro running OS X Sierra. When building Albany (and Trilinos with tests enabled, oddly enough), I get the following error:
Undefined symbols for architecture x86_64:
"dggsvd", referenced from:
Epetra_LAPACK::GGSVD(char, char, char, int, int, int, int*, int*, double*, int, double*, int, double*, double*, double*, int, double*, int, double*, int, double*, int*, int*) const in libepetra.a(Epetra_LAPACK.cpp.o)
"sggsvd", referenced from:
Epetra_LAPACK::GGSVD(char, char, char, int, int, int, int*, int*, float*, int, float*, int, float*, float*, float*, int, float*, int, float*, int, float*, int*, int*) const in libepetra.a(Epetra_LAPACK.cpp.o)
I’ve tried a few things based on solutions other people having similar problems. The closest one I found was another user trying to build Albany on a mac (https://trilinos.org/pipermail/trilinos-users/2016-March/005397.html). Evidently, the work-around there was to use
-D BUILD_SHARED_LIBS:BOOL=OFF
but I tried that myself and it didn’t work for me. I also tried using g++ and clang++ vs. gcc when compiling, which I did using export CXX, but that didn't help either. Finally, I tried pointing to my Lapack install directory using
-D LAPACK_LIBRARY_DIRS:PATH="${LAPACK_ROOT}"
but that also was no good. Any help or advice on how to proceed would be appreciated.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1800CMake warning : Unparsed arguments2017-10-09T16:50:33ZJames WillenbringCMake warning : Unparsed arguments*Created by: mhoemmen*
@trilinos/amesos2
I just started getting the following warning when configuring Amesos2. It's a CUDA build, but that doesn't appear to matter here.
```
Processing enabled package: Amesos2 (Libs, Tests, Exam...*Created by: mhoemmen*
@trilinos/amesos2
I just started getting the following warning when configuring Amesos2. It's a CUDA build, but that doesn't appear to matter here.
```
Processing enabled package: Amesos2 (Libs, Tests, Examples)
CMake Warning at cmake/tribits/core/package_arch/TribitsGeneralMacros.cmake:283 (MESSAGE):
Arguments are being passed in but not used. UNPARSED_ARGUMENTS =
HEADERS;.../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG/packages/amesos2/src/KLU2/Source/Amesos2_config.h;klu2_analyze_given.hpp;klu2_factor.hpp;klu2_refactor.hpp;klu2_analyze.hpp;klu2_free_numeric.hpp;klu2_scale.hpp;klu2_defaults.hpp;klu2_free_symbolic.hpp;klu2_solve.hpp;klu2_diagnostics.hpp;klu2.hpp;klu2_sort.hpp;klu2_dump.hpp;klu2_kernel.hpp;klu2_tsolve.hpp;klu2_extract.hpp;klu2_memory.hpp
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsAddExecutableAndTest.cmake:165 (TRIBITS_CHECK_FOR_UNPARSED_ARGUMENTS)
packages/amesos2/src/KLU2/Source/examples/CMakeLists.txt:1 (TRIBITS_ADD_EXECUTABLE_AND_TEST)
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1652MueLu: Kokkos_Refactor option should check for upstream dependencies2017-08-31T15:45:30ZJames WillenbringMueLu: Kokkos_Refactor option should check for upstream dependencies*Created by: jhux2*
@trilinos/muelu
The MueLu cmake option `MueLu_ENABLE_Kokkos_Refactor` should include logic that checks that certain upstream dependencies and other cmake options are enabled.
- [ ] `-D MueLu_ENABLE_Experimenta...*Created by: jhux2*
@trilinos/muelu
The MueLu cmake option `MueLu_ENABLE_Kokkos_Refactor` should include logic that checks that certain upstream dependencies and other cmake options are enabled.
- [ ] `-D MueLu_ENABLE_Experimental:BOOL=ON`
- [ ] `-D MueLu_ENABLE_Kokkos_Refactor:BOOL=ON`
- [ ] `-D Xpetra_ENABLE_Experimental:BOOL=ON`
- [ ] `-D Xpetra_ENABLE_Kokkos_Refactor:BOOL=ON`
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1605MueLu Library Truncation with Intel 17.0 Series on KNL with Debugging2018-05-02T17:52:30ZJames WillenbringMueLu Library Truncation with Intel 17.0 Series on KNL with Debugging*Created by: nmhamster*
@trilinos/muelu - guys I am getting the library truncation error again:
```
[100%] Building CXX object packages/muelu/src/CMakeFiles/muelu.dir/Graph/MueLu_LinkedList.cpp.o
[100%] Building CXX object packages...*Created by: nmhamster*
@trilinos/muelu - guys I am getting the library truncation error again:
```
[100%] Building CXX object packages/muelu/src/CMakeFiles/muelu.dir/Graph/MueLu_LinkedList.cpp.o
[100%] Building CXX object packages/muelu/src/CMakeFiles/muelu.dir/Utils/ExplicitInstantiation/MueLu_FacadeClassBase.cpp.o
In file included from /home/sdhammo/git/trilinos-github-repo/packages/muelu/src/MueCentral/MueLu_Level.cpp(50):
/home/sdhammo/git/trilinos-github-repo/packages/muelu/src/MueCentral/MueLu_FactoryManagerBase.hpp(83): warning #858: type qualifier on return type is meaningless
const virtual bool hasFactory(const std::string& varName) const = 0;
^
[100%] Linking CXX executable Belos_Tpetra_LinearSolverFactory.exe
[100%] Built target Belos_Tpetra_LinearSolverFactory
[100%] Linking CXX static library libmuelu.a
/home/projects/x86-64-knl/binutils/2.26.0/bin/ar: libmuelu.a: File truncated
```
This is using Intel 17.0.098 compiler developer pack on our KNL test beds. If you recall, turning on debugging with the '-g' flag and asking for both OpenMP and Serial backends causes this to break. Unfortunately, I need both backends because they are both explicitly used by the application. This error occurs because the library objects exceed 2GB. I think we had this error before but you began to break up the libraries to reduce the size and so it went away for some time.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1524g++ -Wconversion warnings2017-08-02T14:04:38ZJames Willenbringg++ -Wconversion warnings*Created by: bradbell*
Compiling a simple Sacado example using the -Wconversion flag with g++ yields many warnings.
Example 1:
include/Teuchos_ScalarTraits.hpp:180:49: warning: conversion to ‘char’ from ‘int’ may alter its value [-...*Created by: bradbell*
Compiling a simple Sacado example using the -Wconversion flag with g++ yields many warnings.
Example 1:
include/Teuchos_ScalarTraits.hpp:180:49: warning: conversion to ‘char’ from ‘int’ may alter its value [-Wconversion]
static inline char random() { return std::rand(); } // RAB: This version should be used for an unsigned char, not char
~~~~~~~~~^~
Example 2:
include/Teuchos_as.hpp:1318:27: warning: conversion to ‘double’ alters ‘long int’ constant value [-Wfloat-conversion]
t < minVal || t > maxVal,
^
Kludge: Adding the following at the beginning of files that include triinos headers seems to work:
\# if COMPILER_IS_GNUCXX
\# pragma GCC diagnostic ignored "-Wfloat-conversion"
\# pragma GCC diagnostic ignored "-Wconversion"
\# endif
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1133Warnings in Trilinos CUDA build2017-05-26T00:11:02ZJames WillenbringWarnings in Trilinos CUDA build*Created by: bathmatt*
Right now we have 21K unique warnings when we build trilinos with cuda. I've attached a script to show this on shiller when one tries to build panzer. Because of this there is a lot of info lost in these warning...*Created by: bathmatt*
Right now we have 21K unique warnings when we build trilinos with cuda. I've attached a script to show this on shiller when one tries to build panzer. Because of this there is a lot of info lost in these warnings and it would be good to clean them up. I've attached the zip file with all the warnings listed. The worst is stk with boost errors,
If package owners can look at these and help reduce where we can. I'm following @mwglass suggestion to reduce the stk ones by including boost as a system lib. I know @rppawlo is looking at nox and @bartlettroscoe is looking at thyra.
[warn.zip](https://github.com/trilinos/Trilinos/files/841560/warn.zip)
@jwillenbring here is a question, do we want to assign issues to each of these packages to clean them up? Is this a priority?
1 5 117 shards.warn
1 7 144 ifpack2.warn
2 10 257 zoltan2.warn
2 10 257 zoltan.warn
2 10 299 kokkos-kernels.warn
2 14 277 triutils.warn
2 20 362 common.warn
3 15 421 tpetra.warn
3 21 466 aztecoo.warn
4 20 491 piro.warn
4 32 671 kokkos.warn
5 33 601 ml.warn
7 44 906 sacado.warn
8 156 3319 rol.warn
8 44 1276 stratimikos.warn
9 45 978 fei.warn
14 78 1953 belos.warn
14 86 2020 rythmos.warn
16 152 2539 teuchos.warn
17 109 2366 pamgen.warn
22 118 2682 nox.warn
27 137 3496 xpetra.warn
28 232 4968 epetraext.warn
32 501 9306 DrekarResearch.warn
33 257 5658 ifpack.warn
43 427 8170 teko.warn
45 335 7209 epetra.warn
49 257 8162 thyra.warn
70 447 9110 seacas.warn
108 1623 25106 panzer.warn
160 2375 39783 DrekarBase.warn
[config.txt](https://github.com/trilinos/Trilinos/files/841543/config.txt)
**Reproducability Instructions for single packages**
See reproducability instructions [below](https://github.com/trilinos/Trilinos/issues/1133#issuecomment-288105176).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1104ctest -j and kokkos and hwloc2017-03-21T01:55:23ZJames Willenbringctest -j and kokkos and hwloc*Created by: bathmatt*
@nmhamster @rppawlo
Is there any procedure on how to test in parallel on the various systems
https://github.com/kokkos/kokkos/issues/630
points out an issue with openmp and thread binding.
I'm looking for...*Created by: bathmatt*
@nmhamster @rppawlo
Is there any procedure on how to test in parallel on the various systems
https://github.com/kokkos/kokkos/issues/630
points out an issue with openmp and thread binding.
I'm looking for a recipe on what do I configure with, and how do I test for the different platforms. Particularly for openmpi/RHEL, ellis, ride, shiller (cpu and gpu).
What are people using? Are you just reverting to -j1?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1036Piro fails to compile2017-02-03T16:00:49ZJames WillenbringPiro fails to compile*Created by: aprokop*
@trilinos/nox @trilinos/piro
Here is the config:
```cmake
#!/bin/sh
EXTRA_ARGS=$@
ARGS=(
-D CMAKE_BUILD_TYPE=RELWITHDEBINFO
-D BUILD_SHARED_LIBS=ON
### COMPILERS AND FLAGS ###
-D ...*Created by: aprokop*
@trilinos/nox @trilinos/piro
Here is the config:
```cmake
#!/bin/sh
EXTRA_ARGS=$@
ARGS=(
-D CMAKE_BUILD_TYPE=RELWITHDEBINFO
-D BUILD_SHARED_LIBS=ON
### COMPILERS AND FLAGS ###
-D Trilinos_ENABLE_Fortran=OFF
-D CMAKE_CXX_FLAGS="-Wall -Wextra"
### TPLS ###
-D TPL_ENABLE_MPI=ON
-D TPL_ENABLE_BLAS=ON
-D TPL_ENABLE_LAPACK=ON
### ETI ###
-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION=ON
### PACKAGES CONFIGURATION ###
-D Trilinos_ENABLE_ALL_PACKAGES=OFF
-D Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES=OFF
-D Trilinos_ASSERT_MISSING_PACKAGES=OFF
-D Trilinos_ENABLE_TESTS=OFF
-D Trilinos_ENABLE_EXAMPLES=OFF
-D Trilinos_ENABLE_Belos=ON
-D Trilinos_ENABLE_Epetra=ON
-D Trilinos_ENABLE_EpetraExt=ON
-D Trilinos_ENABLE_ML=ON
-D Trilinos_ENABLE_NOX=ON
-D Trilinos_ENABLE_Piro=ON
-D Trilinos_ENABLE_Teuchos=ON
### MISC ###
-D CMAKE_EXPORT_COMPILE_COMMANDS=OFF
-D Trilinos_ENABLE_INSTALL_CMAKE_CONFIG_FILES=OFF
-D Trilinos_DEPS_XML_OUTPUT_FILE=""
)
cmake -GNinja "${ARGS[@]}" $EXTRA_ARGS ../../
```
Here are the errors:
```
../../packages/piro/src/Piro_Epetra_LOCASolver.hpp:49:25: fatal error: LOCA_Epetra.H: No such file or directory
../../packages/piro/src/Piro_Epetra_NOXSolver.hpp:49:24: fatal error: NOX_Epetra.H: No such file or directory
../../packages/piro/src/Piro_Epetra_PerformSolve.cpp:51:42: fatal error: Thyra_EpetraModelEvaluator.hpp: No such file or directory
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/963plans for explicit template instantiation in Intrepid22017-01-05T20:17:26ZJames Willenbringplans for explicit template instantiation in Intrepid2*Created by: jhux2*
Are there plans to add ETI support in Intrepid2? This would help reduce build times in packages that depend on Intrepid2.
@trilinos/intrepid2 *Created by: jhux2*
Are there plans to add ETI support in Intrepid2? This would help reduce build times in packages that depend on Intrepid2.
@trilinos/intrepid2 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/955PyTrilinos: move out SWIG detection to root cmake/2018-06-26T20:36:00ZJames WillenbringPyTrilinos: move out SWIG detection to root cmake/*Created by: aprokop*
ForTrilinos will use SWIG and thus this code could be shared by both.*Created by: aprokop*
ForTrilinos will use SWIG and thus this code could be shared by both.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/854Sacado: Internal compiler error with GCC 4.7.2 (MPI_DEBUG build)2016-11-16T22:25:27ZJames WillenbringSacado: Internal compiler error with GCC 4.7.2 (MPI_DEBUG build)*Created by: mhoemmen*
@trilinos/sacado @etphipp @bmpersc
```
.../Trilinos/packages/sacado/test/performance/fad_kokkos_hierarchical.cpp: In lambda function:
.../Trilinos/packages/sacado/test/performance/fad_kokkos_hierarchical.cpp...*Created by: mhoemmen*
@trilinos/sacado @etphipp @bmpersc
```
.../Trilinos/packages/sacado/test/performance/fad_kokkos_hierarchical.cpp: In lambda function:
.../Trilinos/packages/sacado/test/performance/fad_kokkos_hierarchical.cpp:519:9: internal compiler error: in make_decl_rtl, at varasm.c:1147
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
```
GCC 4.7.2 doesn't like lambdas with Kokkos. Lambdas are kind of essential to what you're doing, if the name means what I think it means, so I'm not sure if this will actually work with GCC 4.7.2 :(https://gitlab.osti.gov/jmwille/Trilinos/-/issues/611Thyra::DetachedVectorView warnings in gcc 6.22017-05-29T13:29:53ZJames WillenbringThyra::DetachedVectorView warnings in gcc 6.2*Created by: rppawlo*
@trilinos/thyra
The Thyra::DetachedVectorView is generating warnings with gcc 6.2 compiler due to exceptions being called in the destructor:
[ 98%] Building CXX object tempus/test/TestModels/CMakeFiles/tempus_te...*Created by: rppawlo*
@trilinos/thyra
The Thyra::DetachedVectorView is generating warnings with gcc 6.2 compiler due to exceptions being called in the destructor:
[ 98%] Building CXX object tempus/test/TestModels/CMakeFiles/tempus_test_models.dir/CDR_Model.cpp.o
In file included from /Users/rppawlo/Trilinos/packages/teuchos/core/src/Teuchos_Assert.hpp:46:0,
from /Users/rppawlo/Trilinos/packages/teuchos/core/src/Teuchos_Array.hpp:50,
from /Users/rppawlo/Trilinos/packages/rtop/src/interfaces/RTOpPack_Types.hpp:49,
from /Users/rppawlo/Trilinos/packages/thyra/core/src/interfaces/operator_vector/fundamental/Thyra_OperatorVectorTypes.hpp:46,
from /Users/rppawlo/Trilinos/packages/thyra/core/src/interfaces/operator_vector/fundamental/Thyra_VectorBase.hpp:46,
from /Users/rppawlo/Trilinos/packages/thyra/core/src/support/nonlinear/model_evaluator/client_support/Thyra_ModelEvaluatorDefaultBase.hpp:45,
from /Users/rppawlo/Trilinos/packages/thyra/core/src/support/nonlinear/model_evaluator/client_support/Thyra_StateFuncModelEvaluatorBase.hpp:45,
from /Users/rppawlo/Trilinos/tempus/test/TestModels/CDR_Model_decl.hpp:4,
from /Users/rppawlo/BUILD/tempus/test/TestModels/CDR_Model.hpp:1,
from /Users/rppawlo/Trilinos/tempus/test/TestModels/CDR_Model.cpp:4:
/Users/rppawlo/Trilinos/packages/thyra/core/src/support/operator_vector/client_support/Thyra_DetachedVectorView.hpp: In instantiation of 'Thyra::DetachedVectorView<Scalar>::~DetachedVectorView() [with Scalar = double]':
/Users/rppawlo/Trilinos/tempus/test/TestModels/CDR_Model_impl.hpp:184:43: required from 'void Tempus_Test::CDR_Model<Scalar>::set_x0(const Teuchos::ArrayView<const T>&) [with Scalar = double]'
/Users/rppawlo/Trilinos/tempus/test/TestModels/CDR_Model.cpp:8:3: required from here
/Users/rppawlo/Trilinos/packages/teuchos/core/src/Teuchos_TestForException.hpp:183:28: warning: throw will always call terminate() [-Wterminate]
throw Exception(omsgstr); \
^
/Users/rppawlo/Trilinos/packages/teuchos/core/src/Teuchos_TestForException.hpp:325:3: note: in expansion of macro TEUCHOS_TEST_FOR_EXCEPTION'
TEUCHOS_TEST_FOR_EXCEPTION(throw_exception_test, std::logic_error, msg)
^~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rppawlo/Trilinos/packages/thyra/core/src/support/operator_vector/client_support/Thyra_DetachedVectorView.hpp:345:9: note: in expansion of macro 'TEUCHOS_TEST_FOR_EXCEPT_MSG'
TEUCHOS_TEST_FOR_EXCEPT_MSG(true, "I don't think non-unit stride has ever been tested!");
^~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rppawlo/Trilinos/packages/teuchos/core/src/Teuchos_TestForException.hpp:183:28: note: in C++11 destructors default to noexcept
throw Exception(omsgstr); \
^
/Users/rppawlo/Trilinos/packages/teuchos/core/src/Teuchos_TestForException.hpp:325:3: note: in expansion of macro TEUCHOS_TEST_FOR_EXCEPTION'
TEUCHOS_TEST_FOR_EXCEPTION(throw_exception_test, std::logic_error, msg)
^~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rppawlo/Trilinos/packages/thyra/core/src/support/operator_vector/client_support/Thyra_DetachedVectorView.hpp:345:9: note: in expansion of macro 'TEUCHOS_TEST_FOR_EXCEPT_MSG'
TEUCHOS_TEST_FOR_EXCEPT_MSG(true, "I don't think non-unit stride has ever been tested!");
^~~~~~~~~~~~~~~~~~~~~~~~~~~