Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-05-03T22:46:33Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2464Set up a CUDA build for an auto PR build2019-05-03T22:46:33ZJames WillenbringSet up a CUDA build for an auto PR build*Created by: bartlettroscoe*
CC: @trilinos/framework, @mhoemmen, @rppawlo, @ibaned, @crtrott, @nmhamster
## Description
This Issue is to scope out and track efforts to set up a CUDA build of Trilinos to be used as an auto PR buil...*Created by: bartlettroscoe*
CC: @trilinos/framework, @mhoemmen, @rppawlo, @ibaned, @crtrott, @nmhamster
## Description
This Issue is to scope out and track efforts to set up a CUDA build of Trilinos to be used as an auto PR build as described in https://github.com/trilinos/Trilinos/issues/2317#issuecomment-376551457.
For this build it was agreed to use that ATDM build on `white` that is currently running and submitting to CDash. Questions about how to extend this build to be used as an auto PR build include:
* Should all of the PT package tests be built and run or just the ones that the current ATDM build of Trilinos builds and runs? (Things can be set up to either way.)
* Does the machine 'white' have enough computing capacity in order to handle the load of builds needed for Trilinos PR testing?
* Are the Jenkins jobs running the builds using the `bsub` command robust enough to be a reliable PR build?
## Tasks:
1. Clean up the existing CUDA build on `white` until it is 100% clean [Done]
1. Set up an all-at-once nightly build that enables all PT package that submits to CDash "Specialized" [Done]
1. Clean up the all-at-once nightly build for all PT packages (disable whatever should be disabled) ...
1. ???
## Related Issues:
* Part of: #2317
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2426Framework: PR testing should enable complex by default2019-02-12T22:44:07ZJames WillenbringFramework: PR testing should enable complex by default*Created by: mhoemmen*
PR (pull request) testing should enable complex by default. This is because at least two major internal customers need complex arithmetic to work.
I know it takes longer to build but it seems like PR testing s...*Created by: mhoemmen*
PR (pull request) testing should enable complex by default. This is because at least two major internal customers need complex arithmetic to work.
I know it takes longer to build but it seems like PR testing should test the most used build configurations.
@trilinos/framework @prwolfe @rrdrake @rppawlo
Improve productivity, stability, and quality of Trilinoshttps://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/2307Component "Pike" not found2018-02-28T16:58:38ZJames WillenbringComponent "Pike" not found*Created by: ecurtin2*
Hello,
I'm trying to build the demo in $TRILINOS_DIR/demos/buildAgainstTrilinos/build
I built trilinos by going into $TRILINOS_DIR and executing the following do-make.sh in that directory.
gcc/g++/gfortan ...*Created by: ecurtin2*
Hello,
I'm trying to build the demo in $TRILINOS_DIR/demos/buildAgainstTrilinos/build
I built trilinos by going into $TRILINOS_DIR and executing the following do-make.sh in that directory.
gcc/g++/gfortan versions are all 5.4.0
```
mkdir build
cd build
cmake -Bbuild .. \
-DCMAKE_C_COMPILER=/usr/bin/gcc \
-DCMAKE_CXX_COMPILER=/usr/bin/g++ \
-DCMAKE_Fortran_COMPILER=/usr/bin/gfortran \
-DTrilinos_ENABLE_ALL_PACKAGES=ON \
-DCMAKE_INSTALL_PATH=/home/evan/local \
-DCMAKE_INSTALL_PREFIX=/home/evan/local \
make -j3 install
wait
cd ..
```
When I try to run the do-cmake in $TRILINOS_DIR/demos/buildAgainstTrilinos/build
```
rm CMakeCache.txt
cmake \
-D Trilinos_PREFIX:PATH=/home/evan/local \
-D CMAKE_VERBOSE_MAKEFILE:BOOL=ON \
..
```
I get the following error:
```
CMake Warning at /home/evan/local/lib/cmake/Trilinos/TrilinosConfig.cmake:158 (MESSAGE):
Component "Pike" NOT found.
Call Stack (most recent call first):
CMakeLists.txt:11 (FIND_PACKAGE)
CMake Error at /home/evan/local/lib/cmake/Trilinos/TrilinosConfig.cmake:221 (include):
include could not find load file:
/home/evan/local/lib/cmake/Trilinos/../Pike/PikeConfig.cmake
Call Stack (most recent call first):
CMakeLists.txt:11 (FIND_PACKAGE)
Found Trilinos! Here are the details:
Trilinos_DIR = /home/evan/local/lib/cmake/Trilinos
Trilinos_VERSION = 12.13
Trilinos_PACKAGE_LIST = Pike;TrilinosCouplings; **[...Long list of packages]**
Trilinos_LIBRARIES = trilinoscouplings;stokhos_muelu; **[...Long List of packages]**
Trilinos_INCLUDE_DIRS = /home/evan/local/include
Trilinos_LIBRARY_DIRS = /home/evan/local/lib
Trilinos_TPL_LIST = DLlib;X11;Matio;Netcdf;Boost;LAPACK;BLAS;Pthread
Trilinos_TPL_INCLUDE_DIRS =
Trilinos_TPL_LIBRARIES =
Trilinos_TPL_LIBRARY_DIRS =
Trilinos_BUILD_SHARED_LIBS = FALSE
End of Trilinos details
-- Checking if MPI is enabled in Trilinos:
-- Checking if MPI is enabled in Trilinos: MPI NOT ENABLED
-- Looking for Epetra:
-- Looking for Epetra: -- found, compiling with -DMYAPP_EPETRA
-- Configuring incomplete, errors occurred!
See also "/home/evan/local/Trilinos/demos/buildAgainstTrilinos/build/CMakeFiles/CMakeOutput.log".
```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/2312Issues to be address before making automated PR testing and merging mandatory2018-03-27T14:09:26ZJames WillenbringIssues to be address before making automated PR testing and merging mandatory*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @rppawlo, @maherou, @srajama1
## Description:
There has been recent discussion about when the time to make automated PR testing and merging system being developed by the @t...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @rppawlo, @maherou, @srajama1
## Description:
There has been recent discussion about when the time to make automated PR testing and merging system being developed by the @trilinos/framework team mandatory. From my own experience and conversations with other people, the following issues would need to be addressed before that can occur:
* Update and streamline the builds used by the automated PR testing system (to make sure that we are getting the needed testing, having the builds not take too many computer resoruces, and getting the biggest bang for our buck in protecting important functionality.) (see #2317)
* **STATUS:** ???
* Post all build results to CDash to see exactly what is getting tested and what the failures are (and allow it to be reviewed before the final merge).
* Complete the upgrade of the new CDash version that supports all-at-once configure, build, test, and submit (see https://gitlab.kitware.com/snl/project-1/issues/33).
* **STATUS:** Currently, the PR build results are being submitted to the trial testing-vm.sandia.gov/cdash site and the Framework team is okay with the stability of that site for managing PR builds so this is not currently considered an impediment.
* Upgrade the minimum version of CMake used by Trilinos from 2.8.11 to 3.10 in order to take advantage of all-at-once configure, build, test, and submit to new CDash version. (Also, once the auto PR testing is using CMake 3.10 it will allow CMake code in packages that does not work with older versions of CMake and therefore will destabilize other builds of Trilinos unless we force the upgrade).
* **STATUS:** This can be done later. For now, this might allow CMakeLists.txt files to get pushed that will break the configure of Trilinos with older CMake versions but the current post-push CI build and other nightly builds would catch that.
* Make it easy and obvious how to reproduce the exact auto PR builds and results shown on CDash and to allow people to run these locally even **before** they post their PR if they would like (e.g. #2295)
(Which includes making the env and/or machine accessible to all Trilinos developers, see https://github.com/trilinos/Trilinos/issues/2317#issuecomment-369987520.)
* **STATUS:** ???
* Auto-merge with final staged testing before merge to ‘develop’ (i.e. avoid violations of the [additive test assumption of branches](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#bookmark=id.d1jneh8ubsyn) that resulted #2264).
* **STATUS:** Currently plan is to mark older PRs as "Stale" but not strictly guarantee stability of 'develop' due to violations of the "additive test assumption of branches"?
* Auto wiping the build directory when requested so that it will deal with cases where you need to build from scratch (e.g. when Panzer files get update such as described in https://github.com/trilinos/Trilinos/issues/1304#issuecomment-355786180 and https://github.com/trilinos/Trilinos/issues/1304#issuecomment-356053919).
* **STATUS:** Currently a complete build from scratch with each PR build is being done to address this. With this implementation, this is not an impediment.
* Address cases where no packages get enabled and therefore no tests are run. Will the auto PR system mark them as "passed" and allow the PR to be merged?
* **STATUS:** ???
* Document the PR and auto testing process so people can understand how to use it correctly and understand why it is firing off tests in some cases and not in other cases.
* **STATUS:** ???
* Ensure the current testing infrastructure will scale when everyone is required to use topic branches for pushing anything (even documentation changes). For example, will this scale when there are 20 active PRs being edited at the same time? When there are more and more topic branches, how long with the lags be before things get tested and eventually merged?
* **STATUS:** This will be addressed by "Update and streamline the builds used by the automated PR testing system" above?
Other issues that should be resolve (quickly) after initial adoption:
* Remove manual updates of the list of packages from mapping of directories to packages. (e.g. use self-maintaining existing code in TriBITS tools for that?). If you don’t things will not get tested correctly without manual intervention to constantly keep that manual list up to date.
The motivation for this issue was conversations with @rppawlo, @jwillenbring and the [2018-02-28 Trilinos Planning meeting](https://docs.google.com/document/d/1JClLSR3n79XJT_yLPPoQv_e3rJToHxl8fUzRYojtY5Y/edit)
## Related Issues
* Related to: #1154, #1304
* Composed of: #2317
## Tasks:
1. Define the set of builds to be used in the auto PR system with a working group (#2317). See #2317 ...
1. Complete and robustify the submitting of results to CDash (there is a start to this but it is having problems, see https://github.com/trilinos/Trilinos/pull/2310#issuecomment-369390502).
1. ???
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2317Select set of builds for initial mandatory auto PR testing process2018-10-02T00:35:41ZJames WillenbringSelect set of builds for initial mandatory auto PR testing process*Created by: bartlettroscoe*
**CC:** @trilinos/framework
## Next Action Status
This ship has sailed on "Initial" a long time ago. The only remaining build in the CUDA PR build and that is being tracked in #2464.
## Descriptio...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
## Next Action Status
This ship has sailed on "Initial" a long time ago. The only remaining build in the CUDA PR build and that is being tracked in #2464.
## Description
This story is to involve interested members of the Trilinos team to collaborate to select the best build configurations in order to allow the new Trilinos auto PR testing and merging tool and process (#1155) to become the mandatory way to test and push to the main Trilinos ‘develop’ branch (#2312). This selection must be done considering that there are limited computing resources (on the Jenkins build farms) to run automated builds. So while we would like to run many different useful builds as part of pre-push automated PR testing, we have to be strategic about what builds we run where to not overwhelm current capacity. As more build machines are added to the Jenkins build farm, more builds can be added to the auto PR testing process.
This story is a follow on from the action item:
* ACTION (Ross): Set up a separate meeting to discuss what that build / those builds (if more than one) should be
in the [2018-02-26 Trilinos Planning Meeting](https://docs.google.com/document/d/1JClLSR3n79XJT_yLPPoQv_e3rJToHxl8fUzRYojtY5Y/edit#bookmark=id.9wrhu8wvpblx).
The set of Trilinos team members interested in being part of this discussion (and meetings) include:
* @mhoemmen
* @crtrott
* @william76
* @bartlettroscoe
* @rppawlo
* @ibaned
* @jwillenbring
* @bmpersc
Since this selection of these builds will impact every Trilinos developer and every close customer and collaboration of Trilinos, it is important that we get input from many different people in making this selection.
## Definition of Done
* Document conversation between Trilinos developers on the selection of these builds
* New build configurations selected (with actual Trilinos configuration files)
* Trial builds of Trilinos posted to CDash for the chosen configurations
## Related Issues
* Related to: #1154
* Part of: #2312
* Composed of: #2462, #2463, #2464
## Task
1. Find initial selection of team members interested to discuss this topic **[DONE]**
1. Set up and have meeting with working group **[DONE]**
1. Create initial set of builds in meeting **[DONE]**
1. Create concrete *`.cmake` files for each proposed configuration and set up nightly builds sumitting to "Specialized" CDash Track/Group:
a. GCC 4.8.4: See #2462
b. Intel 17.x: See #2463
c. CUDA: See #2464
1. ???
Improve productivity, stability, and quality of Trilinoshttps://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/2264Four MueLu tests broken in CI build in push to MueLu on 2/19/20182018-03-30T14:43:23ZJames WillenbringFour MueLu tests broken in CI build in push to MueLu on 2/19/2018*Created by: bartlettroscoe*
**CC:** @trilinos/muelu, @trilinos/framework
## Next Action Status
The original failure was caused due to a violation of the [additive test assumption of branches](https://docs.google.com/document/d/1...*Created by: bartlettroscoe*
**CC:** @trilinos/muelu, @trilinos/framework
## Next Action Status
The original failure was caused due to a violation of the [additive test assumption of branches](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#bookmark=id.d1jneh8ubsyn) due to a 10 day time lag between when the branch was tested and when it was merged. See https://github.com/trilinos/Trilinos/pull/2171#issuecomment-367530716 and #2312.
## Description
The push of the merge commit:
```
commit 22e7f91ed633a22d6d44baf46d8f1e4fca7bfb3e
Merge: 52f3559 d851185
Author: Luc Berger <lberge@sandia.gov>
Date: Mon Feb 19 15:38:53 2018 -0700
Merge pull request #2171 from lucbv/develop
MueLu_structured_aggregation
```
broke the standard CI build as shown at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=3395403&
which involved breaking the four tests:
* MueLu_UnitTestsEpetra_MPI_1
* MueLu_UnitTestsEpetra_MPI_4
* MueLu_UnitTestsTpetra_MPI_1
* MueLu_UnitTestsTpetra_MPI_4
This was the only merge commit pulled in the CI iteration as shown at:
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3395404##note3
Therefore, I will back out this merge commit and run the checkin-test-sems.sh script to fix this ASAP (but I will only run the MueLu test to speed this up). Since the CI build passed before this merge commit was pushed, that should be enough testing. Otherwise, everyone's automated PR testing for changes to MueLu or upsstream from MueLu will fail because of this.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2255Trilinos CDash site not sending out emails since 1/30/2018?2018-02-20T00:18:39ZJames WillenbringTrilinos CDash site not sending out emails since 1/30/2018?*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @zackgalbreath
## Description
It looks like the Trilinos CDash site is no longer sending out any CDash error emails. I have not gotten a CDash error email since 1/30/2018...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @zackgalbreath
## Description
It looks like the Trilinos CDash site is no longer sending out any CDash error emails. I have not gotten a CDash error email since 1/30/2018. The standard CI build shown at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=66&value1=-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now
has been falling since 20:03 UTC 2/15/2018. Yet, I did not receive any CDash error emails for these failures.
This is also breaking all of the “Clean” builds as shown at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2018-02-18
This likely also explains why the PR testing is failing right now (but we can’t see why).
Is there a way to verify that the CDash site attempted to send out CDash error emails? I looked at the CDash log file and I could not find any records of any emails getting sent out.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2254Test Stokhos_TpetraCrsMatrixUQPCEUnitTest_Serial[_MPI_4] fails standard CI bu...2018-11-30T03:20:52ZJames WillenbringTest Stokhos_TpetraCrsMatrixUQPCEUnitTest_Serial[_MPI_4] fails standard CI build and several other builds including the ATDM build Trilinos-atdm-sems-gcc-7-2-0*Created by: bartlettroscoe*
**CC:** @trilinos/stokhos, @trilinos/framework
## Next Action Status
@csiefer2's commits 115e829 and 859157d were reverted with the commit 61b3d9677. Next: @csiefer2 to fix the problem and push new co...*Created by: bartlettroscoe*
**CC:** @trilinos/stokhos, @trilinos/framework
## Next Action Status
@csiefer2's commits 115e829 and 859157d were reverted with the commit 61b3d9677. Next: @csiefer2 to fix the problem and push new commits that pass the standard CI build and the auto PR build ...
## Description
The test `Stokhos_TpetraCrsMatrixUQPCEUnitTest_Serial_MPI_4` (and the non-MPI version `Stokhos_TpetraCrsMatrixUQPCEUnitTest_Serial`) is failing in the new `Trilinos-atdm-sems-gcc-7-2-0` build and several other builds a shown at:
* https://testing-vm.sandia.gov/cdash/testSummary.php?project=1&name=Stokhos_TpetraCrsMatrixUQPCEUnitTest_Serial_MPI_4&date=2018-02-18
This started failing in the standard CI build starting with the build 20180215-2003-Continuous as shown at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=66&value1=-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now
* https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=66&value1=-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now
This is also breaking all of the "Clean" builds as shown at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2018-02-18
The failure is showing:
```
*** glibc detected *** /scratch/rabartl/Trilinos.base/SEMSCIBuild/BUILD/packages/stokhos/test/UnitTest/Stokhos_TpetraCrsMatrixUQPCEUnitTest_Serial.exe: double free or corruption (!prev): 0x00000000029c7b80 ***
```
Since when does glibc detect double delete and abort?
Initial cleanup of new ATDM builds of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2237Framework: Windows builds not reporting to dashboard2018-02-13T22:47:17ZJames WillenbringFramework: Windows builds not reporting to dashboard*Created by: csiefer2*
Again*Created by: csiefer2*
Againhttps://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/2203Framework: Windows Testing is Down Again2018-01-31T22:14:07ZJames WillenbringFramework: Windows Testing is Down Again*Created by: csiefer2*
Yeah, that.*Created by: csiefer2*
Yeah, that.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2190Can't clone from 'nightly' Trilinos repo on SON Jenkins build farm2018-11-15T20:39:28ZJames WillenbringCan't clone from 'nightly' Trilinos repo on SON Jenkins build farm*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @jwillenbring, @bmpersc
## Description
As described in more detail in:
* https://software-sandbox.sandia.gov/jira/browse/TRIL-171
It seems that jobs submitted to the...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @jwillenbring, @bmpersc
## Description
As described in more detail in:
* https://software-sandbox.sandia.gov/jira/browse/TRIL-171
It seems that jobs submitted to the SON Jenkins build farm from the site `jenkins-son.sandia.gov` cannot clone from the repo `software.sandia.gov:/space/git/nightly/Trilinos`. There are no Trilinos jobs running from Jenkins site that clone from `software.sandia.gov:/space/git/nightly/Trilinos`, they all clone from this GitHub site (see https://software-sandbox.sandia.gov/jira/browse/TRIL-171?focusedCommentId=19762&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-19762).
Could the problem be that the entity account 'jenkins' has not been given access to the Trilinos repo on SSG as per:
* https://sems.sandia.gov/confluence/display/SEMSKB/Jenkins%3A+Setting+up+repository+access+in+a+job
?
Note that once you are running in a script that that process can't clone either (as I showed in the experiment documented in https://software-sandbox.sandia.gov/jira/browse/TRIL-171?focusedCommentId=19778&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-19778).
## Defintion of Done
* The outer Jenkins process and the inner script (i.e. ctest- S script) can clone from `software.sandia.gov:/space/git/nightly/Trilinos`
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2185Framework: Windows Build Not Posting To Dashboard2018-01-31T22:14:48ZJames WillenbringFramework: Windows Build Not Posting To Dashboard*Created by: csiefer2*
Again*Created by: csiefer2*
Again