Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-07-24T20:04:19Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3106Failing ShyLU_DD tests in GCC 4.8.4 OpenMP CI and PR builds somehow pushed to...2018-07-24T20:04:19ZJames WillenbringFailing ShyLU_DD tests in GCC 4.8.4 OpenMP CI and PR builds somehow pushed to 'develop' branch*Created by: bartlettroscoe*
@trilinos/framework, @trilinos/shylu, @searhein, @srajama1 (Trilinos Linear Solvers Product Lead)
The post-push CI build `Linux-GCC-4.8.4-MPI_RELEASE_DEBUG_SHARED_PT_OPENMP_CI` shown [here](https://testin...*Created by: bartlettroscoe*
@trilinos/framework, @trilinos/shylu, @searhein, @srajama1 (Trilinos Linear Solvers Product Lead)
The post-push CI build `Linux-GCC-4.8.4-MPI_RELEASE_DEBUG_SHARED_PT_OPENMP_CI` shown [here](https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=4&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=-MPI_RELEASE_DEBUG_SHARED_PT&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now&field4=buildstarttime&compare4=83&value4=4%20weeks%20ago) failed this morning for the first time in [this CI iteration](https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=3719977&filtercount=4&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&field3=buildstarttime&compare3=83&value3=4%20weeks%20ago&filtercombine=and) due to the failing tests shown [here](https://testing-vm.sandia.gov/cdash/viewTest.php?onlyfailed&buildid=3719977) which were:
|Test Name | Status | Test Time | Details |
| :-- | :-- | :-- | :-- |
| ShyLU_DDFROSch_test_laplacian_epetra_2d_gdsw_MPI_4 | Failed | 1s 170ms | 4s 680ms | Completed (Failed) |
| ShyLU_DDFROSch_test_laplacian_epetra_2d_rgdsw_MPI_4 | Failed | 1s 170ms | 4s 680ms | Completed (Failed) |
| ShyLU_DDFROSch_test_interfacesets_2D_MPI_4 | Failed | 710ms | 2s 840ms | Completed (Failed) |
|ShyLU_DDFROSch_test_interfacepartitionofunity_MPI_4 | Failed | 700ms | 2s 800ms | Completed (Failed) |
Looking at the commits pulled this first CI iteration [here](https://testing-vm.sandia.gov/cdash/viewNotes.php?buildid=3720229#!#note2) it seems likely these failures are due to one of the commits by `Alexander Heinlein <alexander.heinlein@uni-köln.de>` (@searhein).
These failing ShyLU_DD tests did not only impact the post-push CI OpenMP build above but it also impacted the auto PR OpenMP build `PR-<pr-id>-test-Trilinos_pullrequest_gcc_4.8.4-<build-num>`. For example, you can see this in the PR builds:
* [PR-3098-test-Trilinos_pullrequest_gcc_4.8.4-781](https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=3719867)
* [PR-3053-test-Trilinos_pullrequest_gcc_4.8.4-782](https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=3720319)
If you look, it is the same 4 failing tests. If you look at those PR #3098 the changes in that branch don't impact ShyLU_DD or the PR builds in any way.
https://testing-vm.sandia.gov/cdash/viewNotes.php?buildid=3720229#!#note2https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3029Framework: Windows build didn't post again last night2018-06-28T21:05:18ZJames WillenbringFramework: Windows build didn't post again last night*Created by: csiefer2*
... but it did the night before*Created by: csiefer2*
... but it did the night beforehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2812Trilinos Framework: Enable testing against installation builds2018-05-23T20:17:40ZJames WillenbringTrilinos Framework: Enable testing against installation builds*Created by: dridzal*
@trilinos/framework
## Expectations
There should be a capability in Trilinos to run tests and examples against an **installation build** (generated using `make install`). Additionally, nightly builds should i...*Created by: dridzal*
@trilinos/framework
## Expectations
There should be a capability in Trilinos to run tests and examples against an **installation build** (generated using `make install`). Additionally, nightly builds should include at least one installation build.
## Current Behavior
There is no active installation build testing. It appears that some infrastructure exists in Tribits, but it is neither used nor tested.
## Motivation and Context
We find out from _customers_ that our builds are broken. This is unacceptable.
## Definition of Done
(1) Installation build testing enabled and (2) performed nightly.
## Proposed Solution
(1) Develop infrastructure to enable marking of tests and examples with “INSTALLATION_TEST” or a similar label.
(2) Such tests should be able to use additional test-specific headers that are not part of the main installation.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2795Epetra requires C++11 now; update documentation2018-05-22T20:13:48ZJames WillenbringEpetra requires C++11 now; update documentation*Created by: mhoemmen*
I merged the following pull request that fixes GLIBCXX debug checking for deal.II's tests:
https://github.com/trilinos/Trilinos/pull/2783
This pull request introduces a modest C++11 requirement into Epetra. ...*Created by: mhoemmen*
I merged the following pull request that fixes GLIBCXX debug checking for deal.II's tests:
https://github.com/trilinos/Trilinos/pull/2783
This pull request introduces a modest C++11 requirement into Epetra. Please see discussion there for rationale. In particular, no one could come up with a current use case demanding that Epetra be built with a C++98 compiler. Even the Epetra-only MueLu build for Windows requires Teuchos, which in turn requires C++11. More importantly, we have no idea if Epetra builds with a C++98 compiler, since we have not tested this use case for a long time.
@trilinos/epetra @trilinos/framework @trilinos/muelu @maherou @trilinos/tpetra
If y'all have a problem with that, now might be a good time to say something. Otherwise, I hereby declare that Epetra now requires C++11. Next step is to update Epetra's documentation to make this clear.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2698MPI_Finalize slow with CUDA + OpenMPI 2.x (known OpenMPI issue; fixed in 3.1)2018-05-14T18:34:47ZJames WillenbringMPI_Finalize slow with CUDA + OpenMPI 2.x (known OpenMPI issue; fixed in 3.1)*Created by: mhoemmen*
Tpetra::CrsMatrix UnitTests2 takes > 560s in a CUDA 8 release build on K80. Seriously, what's going on? Do I need different `KOKKOS_ARCH` settings? It sure would have been nice to have had some performance trac...*Created by: mhoemmen*
Tpetra::CrsMatrix UnitTests2 takes > 560s in a CUDA 8 release build on K80. Seriously, what's going on? Do I need different `KOKKOS_ARCH` settings? It sure would have been nice to have had some performance tracking so we could have caught this. I don't think this is anything we did; we've only been fixing CUDA issues over time.
```
36/145 Test #36: TpetraCore_CrsMatrix_UnitTests2_MPI_4 ....................................................... Passed 561.02 sec
```
@trilinos/tpetra https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2620Clean up builds and tests for all Primary Tested packages for CUDA build on w...2018-04-25T23:45:07ZJames WillenbringClean up builds and tests for all Primary Tested packages for CUDA build on white/ride*Created by: bartlettroscoe*
**CC:** @trilinos/framework
## Description
This issue is a placeholder for cleaning up the builds and tests for all of the Primary Tested Trilinos packages for the `cuda-debug` build on `white/ride` as...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
## Description
This issue is a placeholder for cleaning up the builds and tests for all of the Primary Tested Trilinos packages for the `cuda-debug` build on `white/ride` as described in https://github.com/trilinos/Trilinos/issues/2464#issuecomment-383646788.
As of 4/23/2018, the build `Trilinos-atdm-white-ride-cuda-debug-pt-all-at-once` on `white` for all 53 of the current Primary Tested Trilinos packages passed the configure but has several build and runtime test failures as shown at:
* https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=3451394
This shows build failures for the packages:
* ROL (@trilinos/rol)
* MiniTensor (@lxmota)
* Zoltan (@trilinos/zoltan)
* TrilinosCouplings (???)
* ShyLU_DD (@trilinos/shylu )
* Domi (@trilinos/domi)
And it shows test failures for the packages:
* Stokhos (@trilinos/stokhos)
* ROL
* Zoltan
* TrilinosCouplings
* Piro (@trilinos/piro)
* FEI (@trilinos/fei)
## Steps to Reproduce
Anyone should be able to reproduce any of these package failures on 'white`'(SON) or 'ride' (SRN) as:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh cuda-debug
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnvSettungs.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_<PackageName>=ON \
$TRILINOS_DIR
$ ninja -j16 -k 999999
$ bsub -x -Is -q rhel7F -n 16 ctest -j16
```
For more details, see:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2597Elevate all packages and SE packages used by ATDM APPs to Primary Tested2019-03-29T19:34:21ZJames WillenbringElevate all packages and SE packages used by ATDM APPs to Primary Tested*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @fryeguy52
**Blocked By:** #4219, #4272
## Description:
Currently, it seems that some of the subpackages used by the ATDM EMPIRE APP are labeled Secondary Tested (ST)....*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @fryeguy52
**Blocked By:** #4219, #4272
## Description:
Currently, it seems that some of the subpackages used by the ATDM EMPIRE APP are labeled Secondary Tested (ST). Since ST is enabled by default with Trilinos in the EMPIRE Trilinos configuration, this makes sense that that would have happened. However, by definition, anything being used by ATDM APPs should be treated as Primary Tested (see [here](http://trac.trilinos.org/wiki/TribitsLifecycleModelOverview#test_categories)).
Therefore, this story is to identify which Trilinos subpackages are really being used by ATDM that are currently categorized as ST and elevate them to PT.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2563Delete old autotester messages2018-04-17T15:43:41ZJames WillenbringDelete old autotester messages*Created by: cgcgcg*
@trilinos/framework
## Expectations
It would be great if the autotester would delete old messages that are not useful anymore. In particular, once a build is done, the message about the start of the build is ...*Created by: cgcgcg*
@trilinos/framework
## Expectations
It would be great if the autotester would delete old messages that are not useful anymore. In particular, once a build is done, the message about the start of the build is superfluous.
More generally, all messages could be condensed into a single message that gets updated. This would avoid having pull requests getting flooded with a bunch of autotester runs..https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2550Pull request testing uses really old OpenMPI 1.6.5 w/ build warnings2018-06-19T17:37:07ZJames WillenbringPull request testing uses really old OpenMPI 1.6.5 w/ build warnings*Created by: mhoemmen*
Here is an example of the resulting build warnings:
https://testing-vm.sandia.gov/cdash/viewBuildError.php?type=1&buildid=3418378
```
In file included from /projects/sems/install/rhel6-x86_64/sems/compiler/...*Created by: mhoemmen*
Here is an example of the resulting build warnings:
https://testing-vm.sandia.gov/cdash/viewBuildError.php?type=1&buildid=3418378
```
In file included from /projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi.h:253:0,
from /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3@2/Trilinos/packages/ml/src/Comm/ml_comm.h:26,
from /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3@2/Trilinos/packages/ml/src/Main/ml_1level.h:31,
from /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3@2/Trilinos/packages/ml/src/Smoother/ml_smoother.h:40,
from /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3@2/Trilinos/packages/ml/src/Main/ml_struct.h:31,
from /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3@2/Trilinos/packages/ml/src/Include/ml_include.h:18,
from /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3@2/Trilinos/packages/ml/test/RefMaxwell/cxx_main.cpp:24:
[CTest: warning matched] /projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi_portable_platform.h:374:34: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
_STRINGIFY(__GNUC__)"."_STRINGIFY(__GNUC_MINOR__)"."_STRINGIFY(__GNUC_PATCHLEVEL__)
^
[CTest: warning matched] /projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi_portable_platform.h:374:63: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
_STRINGIFY(__GNUC__)"."_STRINGIFY(__GNUC_MINOR__)"."_STRINGIFY(__GNUC_PATCHLEVEL__)
^
```
OpenMPI calls their own version 1.6.5 "retired" and the next older one is called "ancient." Sierra uses 1.10.x.
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2502Consistent Documentation2018-04-03T21:49:21ZJames WillenbringConsistent Documentation*Created by: jmgate*
@trilinos/framework
## Expectations
It'd be great if there was a single, comprehensive set of instructions for interacting with Trilinos.
## Current Behavior
At the moment, we have [README.md](https://githu...*Created by: jmgate*
@trilinos/framework
## Expectations
It'd be great if there was a single, comprehensive set of instructions for interacting with Trilinos.
## Current Behavior
At the moment, we have [README.md](https://github.com/trilinos/Trilinos/blob/master/README.md), which people will see rendered when they first navigate to [Trilinos on GitHub](https://github.com/trilinos/Trilinos). This file then links to [CONTRIBUTING.md](https://github.com/trilinos/Trilinos/blob/master/CONTRIBUTING.md), which also shows up linked on the new issue or new pull request creation pages. For instance, on the right-hand-side, at the bottom, you should see:
<img width="237" alt="screen shot 2018-04-03 at 3 43 19 pm" src="https://user-images.githubusercontent.com/20327215/38277489-ceb53f16-3755-11e8-94ad-c2c876e1e153.png">
In addition to these sources, we also have information spread out across the [wiki](https://github.com/trilinos/Trilinos/wiki). For instance, [here](https://github.com/trilinos/Trilinos/wiki/Pull-Request-Workflow) and [here](https://github.com/trilinos/Trilinos/wiki/Committing-Changes-to-the-Trilinos-Repository).
## Motivation and Context
At the very least, we need to make sure all these sources of information stay in sync. From what I've seen of other open source software projects, everything a potential user should need to know should show up in the README.md or CONTRIBUTING.md file. If either of those gets too lengthy and it seems prudent to break the information up over the wiki, everything should still be linked back into those files.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2424Framework: Add Installation testing to nightly tests2018-03-21T14:33:36ZJames WillenbringFramework: Add Installation testing to nightly tests*Created by: william76*
@trilinos/framework
@william76
## Motivation and Context
This morning @jwillenbring and I discussed getting installation testing running again in Trilinos. I think it used to be run a while back but that's...*Created by: william76*
@trilinos/framework
@william76
## Motivation and Context
This morning @jwillenbring and I discussed getting installation testing running again in Trilinos. I think it used to be run a while back but that's fallen into disuse. Having an installation test in the nightlies is gaining attention again and so we should revisit this and make sure we have an installation test in the suite.
## Definition of Done
- [ ] Develop an installation test for the Experimental Track
- [ ] Clean up the test build so it's all greens.
- [ ] Move test build up to a higher track. Nightly or Clean should be the ultimate destination for this test.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2423Framework: Add a GPU test into nightlies2019-02-25T17:12:06ZJames WillenbringFramework: Add a GPU test into nightlies*Created by: william76*
@trilinos/framework
Add GPU testing into a nightly build under the Experimental track to run on a testbed.
## Motivation and Context
Nightly tests currently don't run a GPU build consistently... we'd like...*Created by: william76*
@trilinos/framework
Add GPU testing into a nightly build under the Experimental track to run on a testbed.
## Motivation and Context
Nightly tests currently don't run a GPU build consistently... we'd like to move towards getting a GPU based test into the Nightly Clean track eventually and possibly even into the Pull Request test suite. The first step towards this is to work up a test in the Experimental track that can run the suite on a testbed machine with GPUs and get the errors cleaned up.
## Definition of Done
- [ ] Add GPU test on White (?)
@jwillenbring - per our discussion this morning, I'm adding the issue to track this. https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2344Framework: Develop-to-master promotion needs to test debug CUDA2018-03-22T17:59:27ZJames WillenbringFramework: Develop-to-master promotion needs to test debug CUDA*Created by: mhoemmen*
The change that resulted in #2334 got promoted to master, even though it broke the debug GPU build. (The change fixed another bug, so it was a good thing.) It would help if develop-to-master promotion tested deb...*Created by: mhoemmen*
The change that resulted in #2334 got promoted to master, even though it broke the debug GPU build. (The change fixed another bug, so it was a good thing.) It would help if develop-to-master promotion tested debug CUDA builds.
@trilinos/framework @micahahoward
## Expectations
- Develop-to-master promotion should only happen if all supported builds build.
- CUDA debug and release should be supported builds.
## Motivation and Context
Micah Howard cares about this for his application, and wants to debug on GPUs.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2338Framework: Add "develop-to-master promotion version" macro 2018-04-26T22:18:32ZJames WillenbringFramework: Add "develop-to-master promotion version" macro *Created by: mhoemmen*
Add a macro somewhere in Trilinos, with an integer that gets incremented on each develop-to-master promotion.
@trilinos/framework
## Current Behavior
I can't write code that distinguishes between differe...*Created by: mhoemmen*
Add a macro somewhere in Trilinos, with an integer that gets incremented on each develop-to-master promotion.
@trilinos/framework
## Current Behavior
I can't write code that distinguishes between different Trilinos develop-to-master promotions.
## Motivation and Context
Last commit to Trilinos 12.0 was in 2015. Last minor version release (12.12) was in July 2017. This suggests that major version releases may never happen, and that develop-to-master promotions are now the de facto minor version releases. Thus, Trilinos major version numbers are no longer useful for tracking backwards compatibility issues. #2290 (where a harmless change announced literally 3 years ago may break applications that forward-declare templated classes) highlights the value of being able to distinguish between Trilinos develop-to-master promotions.
This issue hinders Tpetra FY18 goals. @kddevin @trilinos/tpetra
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2295Can the checkin script be used to test/push a branch to fork of Trilinos2018-02-26T17:06:38ZJames WillenbringCan the checkin script be used to test/push a branch to fork of Trilinos*Created by: jhux2*
Question: Can the checkin script be used to test and push a branch on a fork of Trilinos, and if so, what's the procedure for setting this up?
__Context__
I would like to use the checkin script to test changes in...*Created by: jhux2*
Question: Can the checkin script be used to test and push a branch on a fork of Trilinos, and if so, what's the procedure for setting this up?
__Context__
I would like to use the checkin script to test changes in a local branch within my fork of Trilinos. If all tests pass, ideally the script would then automatically push the branch to my fork. After that, I would issue a pull request against trilinos/Trilinos.
@trilinos/framework @bartlettroscoe
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2292Trilinos "Clean" and auto PR builds need a Trilinos_ENABLE_DEBUG=ON build2018-05-30T18:37:02ZJames WillenbringTrilinos "Clean" and auto PR builds need a Trilinos_ENABLE_DEBUG=ON build*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou, @rppawlo
## Description
It would seem that all of the current "Clean" builds of Trilinos shown for example yesterday at:
* https://testing.sandia.gov/cdash/in...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou, @rppawlo
## Description
It would seem that all of the current "Clean" builds of Trilinos shown for example yesterday at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2018-02-21&filtercount=1&showfilters=1&field1=groupname&compare1=61&value1=Clean
all have `Trilinos_ENABLE_DEBUG=OFF` set. You can see this, for example, by looking at the uploaded CMakeCache.txt files for these three builds at:
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3398366##note0
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3398237##note3
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3398203##note3
which all show:
```
Trilinos_ENABLE_DEBUG:BOOL=OFF
```
This is not a good thing because there are a lot of run-time checks turned on with you configure Trilinos with `-DTrilinos_ENABLE_DEBUG=ON`. It catches a lot of undefined and otherwise illegal behavior that a `Trilinos_ENABLE_DEBUG=OFF` does not catch.
Because none of the "Clean" builds have `-DTrilinos_ENABLE_DEBUG=ON` one would assume that none of the auto PR builds have it set either. Therefore, can that auto PR builds have at least one build that has this turned on. And from looking at recent PRs like:
* https://github.com/trilinos/Trilinos/pull/2289#issuecomment-367782068
it looks like the auto PR tester is now only running one build. If that is the case, it is critical that this one build set `-DTrilinos_ENABLE_DEBUG=ON`.
This is a big issue for supporting developers and users of Trilinos and especially for ATDM builds of Trilinos that set `-DTrilinos_ENABLE_DEBUG=ON`. For example, this let skip through defects like #2270.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2231Framework: Update License Information2018-02-08T22:21:18ZJames WillenbringFramework: Update License Information*Created by: csiefer2*
The license information given below is for 11.8/11.14:
https://trilinos.org/download/license/
Can we update this information to the latest release?
@jwillenbring *Created by: csiefer2*
The license information given below is for 11.8/11.14:
https://trilinos.org/download/license/
Can we update this information to the latest release?
@jwillenbring https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2221Pamgen,kokkos-kernels: NVCC build error with -D CMAKE_CXX_USE_RESPONSE_FILE_F...2019-03-05T22:14:10ZJames WillenbringPamgen,kokkos-kernels: NVCC build error with -D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON*Created by: mhoemmen*
kokkos-kernels requires `-D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON` for CUDA builds, even with complex arithmetic disabled.
https://github.com/trilinos/Trilinos/issues/2115#issuecomment-357750048
However...*Created by: mhoemmen*
kokkos-kernels requires `-D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON` for CUDA builds, even with complex arithmetic disabled.
https://github.com/trilinos/Trilinos/issues/2115#issuecomment-357750048
However, Pamgen does not build, given those settings.
@trilinos/kokkos-kernels @trilinos/pamgen @trilinos/framework
CC: @rrdrake @prwolfe
## Expectations
1. Whatever flags kokkos-kernels needs to build on CUDA, they need not to block building other essential packages.
2. kokkos-kernels needs to document its CMake requirements.
3. kokkos-kernels needs to fail at configure time, with an informative message, if the CMake variables that it needs are not set.
## Current Behavior
```
$ make
[ 0%] Linking CXX shared library libpamgen.so
nvcc fatal : No input files specified; use option --help for more information
make[2]: *** [packages/pamgen/src/libpamgen.so.12.13] Error 1
make[1]: *** [packages/pamgen/src/CMakeFiles/pamgen.dir/all] Error 2
make: *** [all] Error 2
```
## Motivation and Context
Many downstream tests, including Belos and Ifpack2, depend on Pamgen. This blocks adequate Trilinos testing on CUDA.
## Steps to Reproduce
```
$ module list
Currently Loaded Modulefiles:
1) sems-env 3) sems-cmake/3.3.2 5) kokkos-cuda/8.0.44
2) kokkos-env 4) sems-gcc/5.3.0 6) kokkos-openmpi/2.0.1/cuda
```
CMake configuration:
```
-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON
-D BUILD_SHARED_LIBS:BOOL=ON
-D Trilinos_ENABLE_OpenMP:BOOL=ON
-D Kokkos_ENABLE_OpenMP:BOOL=ON
-D Tpetra_INST_OPENMP:BOOL=ON
-D Trilinos_SHOW_DEPRECATED_WARNINGS:BOOL=ON
-D Trilinos_ENABLE_Fortran:BOOL=OFF
-D TPL_ENABLE_CUDA:BOOL=ON
-D KOKKOS_ARCH="SNB;Kepler35"
-D Kokkos_ENABLE_Cuda:BOOL=ON
-D Kokkos_ENABLE_Cuda_UVM:BOOL=ON
-D Tpetra_INST_CUDA:BOOL=ON
-D Kokkos_ENABLE_Cuda_Lambda:BOOL=ON
-D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS:BOOL=ON
-D CMAKE_CXX_FLAGS:STRING="-Wall"
-D Trilinos_CXX11_FLAGS:STRING="-std=c++11 --expt-extended-lambda"
-D TPL_ENABLE_MKL:BOOL=OFF
-D TPL_ENABLE_Matio:BOOL=OFF
-D TPL_ENABLE_SuperLU:BOOL=OFF
-D TPL_ENABLE_Zlib:BOOL=OFF
-D TPL_ENABLE_Netcdf:BOOL=OFF
-D TPL_ENABLE_HDF5:BOOL=OFF
-D TPL_ENABLE_ParMETIS:BOOL=OFF
-D TPL_ENABLE_Boost:BOOL=OFF
-D TPL_ENABLE_BoostLib:BOOL=OFF
-D TPL_ENABLE_yaml-cpp:BOOL=OFF
-D TPL_ENABLE_MPI:BOOL=ON
```
## Your Environment
- develop branch, commit 400765e21e17dfb995e0f4a2759ce9c5f961b685 (likely not related)
## Related Issues
* Blocks #2115 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2174Request for a windows nightly build for the Tpetra stack2018-03-09T23:43:55ZJames WillenbringRequest for a windows nightly build for the Tpetra stack*Created by: bmpersc*
@trilinos/framework @trilinos/kokkos @trilinos/tpetra @trilinos/belos @trilinos/muelu
@xyshal @wppowers
The Kokkos issue at kokkos/kokkos#1313 has had some discussion about windows and the tpetra stack. Since ...*Created by: bmpersc*
@trilinos/framework @trilinos/kokkos @trilinos/tpetra @trilinos/belos @trilinos/muelu
@xyshal @wppowers
The Kokkos issue at kokkos/kokkos#1313 has had some discussion about windows and the tpetra stack. Since the testing in question is really beyond the scope of just Kokkos and more of a Trilinos issue we should move any further discussion here.
I have added the package teams that were explicitly mentioned in the Kokkos issue. However, there are probably more packages that would be involved since Muelu has quite a few dependencies.
The Trilinos Framework does have an existing windows test machine that has free cycles so we have hardware to support this. What we are lacking is a driver and buy in from the package teams to support such a build.
What we would need to know is what kind of testing is expected and what kind of support is expected for a windows build.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2160CMake 2.8.12 thinks Intel 15.0.2 build is actually 15.0.0.20150121 and is not...2018-01-29T23:49:04ZJames WillenbringCMake 2.8.12 thinks Intel 15.0.2 build is actually 15.0.0.20150121 and is not supported by Kokkos*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/kokkos
## Description
I was looking over the Intel builds for Trilinos as part of #2142 and I noticed that the build [Linux-intel-15.0.2-MPI_RELEASE_DEV_DownStrea...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/kokkos
## Description
I was looking over the Intel builds for Trilinos as part of #2142 and I noticed that the build [Linux-intel-15.0.2-MPI_RELEASE_DEV_DownStream_ETI_SERIAL-OFF_OPENMP-ON_PTHREAD-OFF_CUDA-OFF_COMPLEX-OFF build](https://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=3329931) that claims to be for Intel 15.0.2 is actually Intel 15.0.0.20150121 and that version is **not** supported by Kokkos as shown in the [configure output](https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3329935):
```
- CMAKE_VERSION='2.8.12.2'
[...]
-- MPI_EXEC='/projects/sems/install/rhel6-x86_64/sems/compiler/intel/15.0.2/openmpi/1.8.7/bin/mpiexec'
-- MPI_EXEC='/projects/sems/install/rhel6-x86_64/sems/compiler/intel/15.0.2/openmpi/1.8.7/bin/mpiexec'
-- CMAKE_C_COMPILER_ID='Intel'
-- CMAKE_C_COMPILER_VERSION='15.0.0.20150121'
-- CMAKE_CXX_COMPILER_ID='Intel'
-- CMAKE_CXX_COMPILER_VERSION='15.0.0.20150121'
CMake Error at packages/kokkos/cmake/kokkos_functions.cmake:72 (message):
Compiler not supported by Kokkos. Required compiler versions:
Clang 3.5.2 or higher
GCC 4.8.4 or higher
Intel 15.0.2 or higher
NVCC 7.0.28 or higher
PGI 17.1 or higher
Call Stack (most recent call first):
cmake/ProjectCompilerPostConfig.cmake:13 (set_kokkos_cxx_compiler)
/home/jenkins/slave/workspace/Kokkos_Trilinos_packages/Trilinos/cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1820 (INCLUDE)
/home/jenkins/slave/workspace/Kokkos_Trilinos_packages/Trilinos/cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
/home/jenkins/slave/workspace/Kokkos_Trilinos_packages/Trilinos/cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:93 (TRIBITS_PROJECT)
-- Configuring incomplete, errors occurred!
```
This configure failure for Kokkos disables Kokkos in all downstream packages and as a result of Kokkos being disabled (and Teuchos being disabled as well due to #2128), the only packages that build any libraries and tests and run any tests are Sacado, Epetra, and Zoltan.
And the problem seems to be that SEMS thinks this is actually Intel 15.0.2 given the SEMS TPL paths like shown in the configure output above that shows the path `/projects/sems/install/rhel6-x86_64/sems/compiler/intel/15.0.2/[...]`.
## Related Issues
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to: #2142
* Part of
* Composed of