Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-11-02T19:50:07Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1933Github Issue / PR / Wiki Backups2017-11-02T19:50:07ZJames WillenbringGithub Issue / PR / Wiki Backups*Created by: csiefer2*
If github becomes unavailable for an extended period of time (for whatever reason), so we have a means by which we can backup issues, pull requests and the wiki? And then be able to restore them to a local resour...*Created by: csiefer2*
If github becomes unavailable for an extended period of time (for whatever reason), so we have a means by which we can backup issues, pull requests and the wiki? And then be able to restore them to a local resource for continued operation during the outage?
Clones are easier to manage, so I do not include them here.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1909Testing gap exists for Epetra642019-01-16T00:30:49ZJames WillenbringTesting gap exists for Epetra64*Created by: rhoope*
I don't think there is any automated testing for builds based on Epetra64.*Created by: rhoope*
I don't think there is any automated testing for builds based on Epetra64.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1877Do automated testing for all Trilinos packages that are being released2017-10-20T12:35:30ZJames WillenbringDo automated testing for all Trilinos packages that are being released*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou
**Description:**
It appears that there are packages that are going out with Trilinos releases that are not included in any of the automated builds of Trilinos, in...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou
**Description:**
It appears that there are packages that are going out with Trilinos releases that are not included in any of the automated builds of Trilinos, including the release branch builds. For example, MOOCHO appears to have been released with Trilinos 12.12 but it does not appear to be tested in any automated builds of Trilinos as shown by, for example:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2017-10-19&subproject=MOOCHO
We can't support packages in releases that don't have any automated testing.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1795Trilinos build error on VS20172017-10-02T14:22:58ZJames WillenbringTrilinos build error on VS2017*Created by: yiyangzhang37*
Hello guys. Not sure if this is the right place to post such problems...
I am trying to build Trilinos on Windows 10 with VS2017. Things seem to be weird as I get a lot of errors like
```
Severity Code...*Created by: yiyangzhang37*
Hello guys. Not sure if this is the right place to post such problems...
I am trying to build Trilinos on Windows 10 with VS2017. Things seem to be weird as I get a lot of errors like
```
Severity Code Description Project File Line Suppression State
Error C2065 'arg_data_ptr': undeclared identifier kokkoscore C:\ProgramData\Trilinos-master\packages\kokkos\core\src\impl\Kokkos_ViewMapping.hpp 2419
```
```
Severity Code Description Project File Line Suppression State
Error C3646 'assign': unknown override specifier kokkoscore C:\ProgramData\Trilinos-master\packages\kokkos\core\src\impl\Kokkos_ViewMapping.hpp 2386
```
```
Severity Code Description Project File Line Suppression State
Error C2668 'Kokkos::atomic_increment': ambiguous call to overloaded function kokkoskernels C:\ProgramData\Trilinos-master\packages\kokkos\core\src\impl\Kokkos_TaskQueue.hpp 229
```
```
Severity Code Description Project File Line Suppression State
Error C2953 'Kokkos::Impl::FunctorAnalysis<PatternInterface,Policy,Functor>::has_final_function<F,>': class template has already been defined kokkoskernels C:\ProgramData\Trilinos-master\packages\kokkos\core\src\impl\Kokkos_FunctorAnalysis.hpp 560
```
```
Severity Code Description Project File Line Suppression State
Error C3646 'pointer_type': unknown override specifier kokkoskernels C:\ProgramData\Trilinos-master\packages\kokkos\core\src\Kokkos_View.hpp 568
```
What should I do? https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1872There isn't an '@trilinos/<packagename>' tag for all packages2017-11-27T15:32:49ZJames WillenbringThere isn't an '@trilinos/<packagename>' tag for all packages*Created by: william76*
@trilinos/framework
Since I'm keeping an eye on the nightlies, etc. when the clean track goes red I'll probably put in a ticket if there doesn't appear to be one about that already. I've noticed that there i...*Created by: william76*
@trilinos/framework
Since I'm keeping an eye on the nightlies, etc. when the clean track goes red I'll probably put in a ticket if there doesn't appear to be one about that already. I've noticed that there isn't an @trilinos/<package> tag for all the packages set up. (i.e., today there is a test failing in FEI and there is no @trilinos/fei tag)
It'd be nice if we had one for every package. If packages have no 'team' then perhaps to the owner or someone who is best able to look at a package and know what's going on in it?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1796Fix Dashboard builds that launch too many OpenMP threads, causing test time-outs2017-10-01T00:10:20ZJames WillenbringFix Dashboard builds that launch too many OpenMP threads, causing test time-outs*Created by: mhoemmen*
@trilinos/framework
Some Dashboard builds have failing tests due to time-outs, because the tests spawn too many OpenMP threads. See, for example, this test:
https://testing.sandia.gov/cdash/testDetails.php...*Created by: mhoemmen*
@trilinos/framework
Some Dashboard builds have failing tests due to time-outs, because the tests spawn too many OpenMP threads. See, for example, this test:
https://testing.sandia.gov/cdash/testDetails.php?test=41662515&build=3135886
which includes the following output:
```
Kokkos::OpenMP::initialize WARNING: You are likely oversubscribing your CPU cores.
Detected: 72 cores per node.
Detected: 4 MPI_ranks per node.
Requested: 36 threads per process.
```
`ascic141` appears to be the one machine on which this occurs:
https://testing.sandia.gov/cdash/index.php?project=Trilinos&subproject=Tpetra
I'm not sure what would be the best way to fix this, but you could always just set the `OMP_NUM_THREADS` environment variable somehow.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1792provide xz release tarballs2018-01-15T15:11:13ZJames Willenbringprovide xz release tarballs*Created by: nschloe*
First of all congratulations on the 12.12.1 release!
When I spotted the tarballs this morning in [the release folder](http://trilinos.csbsju.edu/download/files/) I wondered if you could provide xz-compressed tar...*Created by: nschloe*
First of all congratulations on the 12.12.1 release!
When I spotted the tarballs this morning in [the release folder](http://trilinos.csbsju.edu/download/files/) I wondered if you could provide xz-compressed tarballs instead of bzip2-compressed ones. xz has a higher compression ration and unpacks faster; for Trilinos 12.12.1, the file size goes down from **80MB (bz2)** to **63 MB (xz)**. xz has in fact obsoleted bzip2. The Linux kernel sources are distributed in gz and xz since 2013 (https://www.kernel.org/happy-new-year-and-good-bye-bzip2.html).
![1](https://user-images.githubusercontent.com/181628/31010953-f5e328c2-a50c-11e7-8a79-a55725a80db0.png)
![2](https://user-images.githubusercontent.com/181628/31010962-fa657c9c-a50c-11e7-9002-1ca6b17290ec.png)
(Images from https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/.)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1782Add metis tpl to Trilinos testing2019-02-26T16:43:40ZJames WillenbringAdd metis tpl to Trilinos testing*Created by: bmpersc*
@trilinos/framework The @trilinos/shylu team needs metis to be a tpl for testing to be able to properly test all of their code. The lack of metis actually caused a configure error which was reported in ticket #1780...*Created by: bmpersc*
@trilinos/framework The @trilinos/shylu team needs metis to be a tpl for testing to be able to properly test all of their code. The lack of metis actually caused a configure error which was reported in ticket #1780. An immediate solution was to make the requirement of metis optional with the caveat that we would get a metis tpl setup so that we can eventually run the tests.
@trilinos/shylu can you provide the version of metis you would prefer to have available please? https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1751Discuss and document workflow for directly snapshotting SEACAS into Trilinos ...2018-06-26T12:49:47ZJames WillenbringDiscuss and document workflow for directly snapshotting SEACAS into Trilinos to better serve ATDM*Created by: bartlettroscoe*
**Next Action Status:**
@gdsjaar to implement agreed to workflow on SEACAS github site then start doing new workflow ...
**CC:** @trilinos/framework, @gsjaardema
**Description:**
This story is t...*Created by: bartlettroscoe*
**Next Action Status:**
@gdsjaar to implement agreed to workflow on SEACAS github site then start doing new workflow ...
**CC:** @trilinos/framework, @gsjaardema
**Description:**
This story is to document a discussion and the final workflow for allowing @gsjaardema to directly SEACAS directly into Trilinos/packages/seacas/ in addition to shapshotting SEACAS into Sierra.base/seacas/ and then having that snapshotted from ther into Trilinos/packages/seacas/. The nature of the snapshotting process (i.e. never a merge) eliminates the potential for merge conflicts that might make the snapshotting from Sierra.base/seacas/ to Trilinos/packages/seacas/ more difficult. And this would allow @gsjaardema control to address issues for ATDM customers very quickly and simplify the version control and configuration of Trilinos for ATDM customers. For more background and discussion, see:
* https://software-srn.sandia.gov/jira/browse/SPAR-277
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1745Define labels and rules for Trilinos application issues and metrics2018-11-30T11:23:42ZJames WillenbringDefine labels and rules for Trilinos application issues and metrics*Created by: ibaned*
Please see the discussion between https://github.com/trilinos/Trilinos/issues/1304#issuecomment-329885910 and https://github.com/trilinos/Trilinos/issues/1304#issuecomment-329918877 where I propose the following:
...*Created by: ibaned*
Please see the discussion between https://github.com/trilinos/Trilinos/issues/1304#issuecomment-329885910 and https://github.com/trilinos/Trilinos/issues/1304#issuecomment-329918877 where I propose the following:
> create a few extra issues labels besides "bug", namely "compile error (Trilinos)", "compile error (application)", "compile warning (Trilinos)", "compile warning (application)", "test failure (Trilinos)", "test failure (application)". Then we can collect statistics on how many issues with each label were opened in a particular period of time. I would also expand "(Trilinos)" to be either "(Trilinos/develop)" or "(Trilinos/master)"
Note @bartlettroscoe 's observation:
> before we define any more labels I think we need to better organize them along the lines of #1619.
@maherou @jwillenbring Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1740Discuss, refine, and document subteam/subproject development branches2017-09-29T14:18:39ZJames WillenbringDiscuss, refine, and document subteam/subproject development branches*Created by: bartlettroscoe*
**CC:** @dridzal, @jwillenbring, @maherou
**Description:**
This story is to document a discussion about the subteam/subproject development workflow that I helped the ROL team to set up and how to gener...*Created by: bartlettroscoe*
**CC:** @dridzal, @jwillenbring, @maherou
**Description:**
This story is to document a discussion about the subteam/subproject development workflow that I helped the ROL team to set up and how to generalize it and document it for the benefit of other Trilinos development subteams.
**Definition of Done:**
ToDo: Fill in once discussion is farther along so we can better scope this out
**Tasks:**
* Have initial discussion ...
* Decide on concrete "definition of done" and set of tasks to complete ...
* ???
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1735Windows build compile error2017-09-13T18:11:45ZJames WillenbringWindows build compile error*Created by: bmpersc*
@trilinos/framework Ttere is a compile error coming from the windows builds. The error is:
fatal error C1083: Cannot open compiler generated file: '': Invalid argument
and is affecting the opt and debug buil...*Created by: bmpersc*
@trilinos/framework Ttere is a compile error coming from the windows builds. The error is:
fatal error C1083: Cannot open compiler generated file: '': Invalid argument
and is affecting the opt and debug builds. I did some googling on this error and it seems like this is likely related to a path length being too long for visual studio and instead of truncating the path it just uses the empty string instead.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1725Be able to annotate commit with test results from multiple builds2017-09-13T16:19:10ZJames WillenbringBe able to annotate commit with test results from multiple builds*Created by: mhoemmen*
@trilinos/framework
Here are the relevant parts of the #1304 discussion that led to this:
@tjfulle wrote:
> @bartlettroscoe, this may be addressed elsewhere, but is there a best practice for the case that ...*Created by: mhoemmen*
@trilinos/framework
Here are the relevant parts of the #1304 discussion that led to this:
@tjfulle wrote:
> @bartlettroscoe, this may be addressed elsewhere, but is there a best practice for the case that I want to test on multiple machines before pushing (or opening a PR)? For example, with Tpetra, I want to make sure that the standard checkin tests pass on my RHEL blade (obviously), but also different builds on different architectures. In this case, I may push to a branch on my fork and then update and run tests on the several different machines from that branch. The only way (that I know of) to then report test results is to amend the last commit manually with test results and force push. Perhaps there is a better way?
I wrote:
> @tjfulle I like your thinking :-) . Right now, one must add text manually to the commit message, explaining what tests passed where. We don't necessarily want to annotate every commit with all the information needed to replicate a test, but some brief mention that (e.g.,) it was tested with CUDA in a debug build could be nice.
@bartlettroscoe wrote:
> That would not be too hard to do with crafty usage of the checkin-test.py script. You could run the `checkin-test.py` script on each machine separately (e.g. with `--local-do-all`) for special `--extra-st-builds=<specialBuildNamei>` and then you could copy a subset of the `<specialBuildNamei>/*.out` files and all of the `<specialBuildNamei>/*.success` files to your CEE LAN machine and then the `checkin-test-sems.sh` script could be run with the full list of `--extra-st-builds=<specialBuildName1>,<specialBuildName2>,...` and it would correctly list those extra builds and would amend the top commit message with all of those builds and would also archive the details of those builds to the `trilinos-checkin-tests` email list on push. If you combine the moving of a branch and remote run approach demonstrated in `remote-pull-test-push.sh` and combine that with the aggregation of multiple runs of the `checkin-test.py` script in `checkin-test-crf450-cmake-2.8.11.sh` and add some `scp` commands to copy files back, then you basically have it. One could even write some reusable utility scripts to help drive a process like this so many developers could use it.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1655find_package option COMPONENTS ineffective because of hard-coded includes in ...2017-08-29T12:54:26ZJames Willenbringfind_package option COMPONENTS ineffective because of hard-coded includes in TrilinosConfig.cmake*Created by: jwuttke*
CMake's find_package takes an option COMPONENTS. Usage with Trilinos seems to be documented nowhere, but TrilinosConfig.cmake clearly is intended to support commands like
find_package(Trilinos REQUIRED COMPO...*Created by: jwuttke*
CMake's find_package takes an option COMPONENTS. Usage with Trilinos seems to be documented nowhere, but TrilinosConfig.cmake clearly is intended to support commands like
find_package(Trilinos REQUIRED COMPONENTS Epetra Belos Ifpack)
However, at the bottom of TrilinosConfig.cmake there is a long list that includes all Trilinos subproject CMake files. This overwrites the component selection, and makes it ineffective: the client application will depend on _all_ of Trilinos, not just on the selected components.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1630Recent Kokkos changes require -std=c++11 flag with CUDA 8.0 & GCC 5.32017-09-14T20:34:55ZJames WillenbringRecent Kokkos changes require -std=c++11 flag with CUDA 8.0 & GCC 5.3*Created by: mhoemmen*
@trilinos/framework
It looks like C++11 is not being enabled by default in a CUDA 8.0 + GCC 5.3 build with TpetraCore enabled. When I omit `-std=c++11` from `CMAKE_CXX_FLAGS` in a CUDA 8.0 + GCC 5.3 build wit...*Created by: mhoemmen*
@trilinos/framework
It looks like C++11 is not being enabled by default in a CUDA 8.0 + GCC 5.3 build with TpetraCore enabled. When I omit `-std=c++11` from `CMAKE_CXX_FLAGS` in a CUDA 8.0 + GCC 5.3 build with TpetraCore enabled, I get the following configure-time error:
```
-- MPI_EXEC='/projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpiexec'
-- The C compiler identification is GNU 5.3.0
-- Check for working C compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicc
-- Check for working C compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_C_COMPILER_ID='GNU'
-- CMAKE_C_COMPILER_VERSION='5.3.0'
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx
-- Check for working CXX compiler: /projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx -- broken
CMake Error at /projects/sems/install/rhel6-x86_64/sems/utility/cmake/3.3.2/share/cmake-3.3/Modules/CMakeTestCXXCompiler.cmake:54 (message):
The C++ compiler
"/projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: .../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/gmake" "cmTC_64169/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_64169.dir/build.make
CMakeFiles/cmTC_64169.dir/build
gmake[1]: Entering directory
`.../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_64169.dir/testCXXCompiler.cxx.o
/projects/sems/install/rhel6-x86_64/kokkos/compiler/gcc/5.3.0/openmpi/2.0.1/cuda/8.0.44/bin/mpicxx
-Wall -expt-extended-lambda -o
CMakeFiles/cmTC_64169.dir/testCXXCompiler.cxx.o -c
.../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:1:
warning: identifier ‘static_assert’ is a keyword in C++11
[-Wc++0x-compat]
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:156:1:
warning: identifier ‘decltype’ is a keyword in C++11 [-Wc++0x-compat]
*
^
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:133:29:
error: template argument 1 is invalid
#if defined(__cplusplus) && !defined(__CUDACC_RTC__)
^
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:138:32:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
* *
^
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:15:
error: expected identifier before ‘sizeof’
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:15:
error: expected ‘,’ or ‘...’ before ‘sizeof’
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:140:104:
error: ISO C++ forbids declaration of ‘static_assert’ with no type
[-fpermissive]
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:145:19:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:146:18:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/bin/..//include/cuda_runtime.h:148:49:
warning: variadic templates only available with -std=c++11 or -std=gnu++11
....
```
When I add `-std=c++11` to `CMAKE_CXX_FLAGS`, I am able to configure Trilinos and build TpetraCore library, tests, and examples.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1590Make sure Scalar=float gets tested nightly2017-08-08T22:40:43ZJames WillenbringMake sure Scalar=float gets tested nightly*Created by: mhoemmen*
@trilinos/framework
@vbrunini
It turns out that a Sierra product depends on Scalar=float. This means that Trilinos should add nightly tests with `Trilinos_ENABLE_FLOAT:BOOL=ON`.*Created by: mhoemmen*
@trilinos/framework
@vbrunini
It turns out that a Sierra product depends on Scalar=float. This means that Trilinos should add nightly tests with `Trilinos_ENABLE_FLOAT:BOOL=ON`.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1551Look for SuiteSparse shared libraries too?2017-07-30T02:37:55ZJames WillenbringLook for SuiteSparse shared libraries too?*Created by: ilovezfs*
https://github.com/trilinos/Trilinos/blob/f0350316239aaf41e8e6b82378612aaedf9cc72c/cmake/TPLs/FindTPLCholmod.cmake#L59
Currently Trilinos only looks for the static libraries from SuiteSparse, but the `make inst...*Created by: ilovezfs*
https://github.com/trilinos/Trilinos/blob/f0350316239aaf41e8e6b82378612aaedf9cc72c/cmake/TPLs/FindTPLCholmod.cmake#L59
Currently Trilinos only looks for the static libraries from SuiteSparse, but the `make install` target in SuiteSparse does not install the static libraries, only the shared libraries.
In Homebrew, we're hacking around this for Trilinos by adding this to the SuiteSparse formula:
```
lib.install Dir["**/*.a"]
```
But it would be good if Trilinos were able to build with a stock SuiteSparse installation.
(I have also contracted SuiteSparse upstream to request that `make install` install the static libraries too.)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1543Get Trilinos to build CUDA Clang-only2017-09-10T04:58:08ZJames WillenbringGet Trilinos to build CUDA Clang-only*Created by: mhoemmen*
Need Clang 4.0 and the CUDA 9 driver.
Request from @crtrott .*Created by: mhoemmen*
Need Clang 4.0 and the CUDA 9 driver.
Request from @crtrott .https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1541Framework: Upgrade the buld Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED to ...2018-03-22T17:59:40ZJames WillenbringFramework: Upgrade the buld Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED to GCC 4.8.4 or disable*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
The build `Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED` with configure output shown at:
* https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
The build `Linux-GCC-4.7.2-CONTINUOUS_MPI_OPT_DEV_SHARED` with configure output shown at:
* https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3022476
is still using GCC 4.7.2 shown by:
```
-- CMAKE_C_COMPILER_ID='GNU'
-- CMAKE_C_COMPILER_VERSION='4.7.2'
-- CMAKE_CXX_COMPILER_ID='GNU'
-- CMAKE_CXX_COMPILER_VERSION='4.7.2'
```
Trilinos is no longer supports C++11 builds of Trilinos with GCC versions less than 4.8.4 (see #1453). Therefore, this build needs to be upgraded to GCC 4.8.4. Until this build can be updated, it should be disabled. See history in https://github.com/trilinos/Trilinos/issues/1304#issuecomment-318357060.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1480Headers need to use <mpi.h> instead of "mpi.h"2017-07-14T14:49:43ZJames WillenbringHeaders need to use <mpi.h> instead of "mpi.h"*Created by: bangerth*
We got a bug report for deal.II that in essence shows this error message:
```
In file included from /usr/local/include/ml_epetra_utils.h:42:0,
from /usr/local/include/ml_MultiLevelPre...*Created by: bangerth*
We got a bug report for deal.II that in essence shows this error message:
```
In file included from /usr/local/include/ml_epetra_utils.h:42:0,
from /usr/local/include/ml_MultiLevelPreconditioner.h:86,
from ~/Downloads/dealii/source/lac/trilinos_precondition_ml.cc:33:
/usr/local/include/mpi.h:157:16: error: redefinition of ‘struct MPI_Status’
typedef struct MPI_Status {
^~~~~~~~~~
In file included from ~/Downloads/dealii/build/include/deal.II/base/config.h:328:0,
from ~/Downloads/dealii/include/deal.II/lac/trilinos_index_access.h:19,
from ~/Downloads/dealii/source/lac/trilinos_precondition_ml.cc:16:
/opt/intel/compilers_and_libraries/linux/mpi/include64/mpi.h:679:16: note: previous definition of ‘struct MPI_Status’
```
Note how the conflicting declarations come from `/usr/local/include/mpi.h` and `/opt/intel/compilers_and_libraries/linux/mpi/include64/mpi.h`.
The reason is that the user is compiling with the Intel compiler which, via a `-I` flag, provides the `mpi.h` in `/opt/intel/compilers_and_libraries/linux/mpi/include64`. This resolves all instances of `#include <mpi.h>`.
Maybe in a poor choice, the user installed *both* Trilinos and another MPI installation in `/usr/local`, and so when a Trilinos header uses the double-quoted form `#include "mpi.h"`, the compiler *first* looks into `/usr/local/include` and only then into the paths listed via `-I`. Normally that would do no harm since no `mpi.h` is found, but now it is, and the conflict happens.
The problem is because we have this in `ml_epetra_utils.h`:
```
ifdef ML_MPI
#ifndef EPETRA_MPI
#define EPETRA_MPI
#endif
#include "mpi.h" *****************
#endif
```
This should really be `#include <mpi.h>` instead of the double-quoted form. I find other instances of this bug in the following files:
```
> grep '"mpi.h"' *h
Epetra_Time.h:#include "mpi.h"
MLAPI_Workspace.h:#include "mpi.h"
ml_epetra_utils.h:#include "mpi.h"
ml_smoother.h:#include "mpi.h"
```
These are all bugs waiting to happen.