Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-10-23T23:58:36Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3700Framework / TriBITS: download-cmake.py no longer points to a valid cmake2018-10-23T23:58:36ZJames WillenbringFramework / TriBITS: download-cmake.py no longer points to a valid cmake*Created by: csiefer2*
This guy: Trilinos/cmake/tribits/python_utils/download-cmake.py
Tries to download this: http://cmake.org/files/v2.8/cmake-3.10.0-Linux-i386.tar.gz
Which give ye ol' 404.
I discovered this in an initial se...*Created by: csiefer2*
This guy: Trilinos/cmake/tribits/python_utils/download-cmake.py
Tries to download this: http://cmake.org/files/v2.8/cmake-3.10.0-Linux-i386.tar.gz
Which give ye ol' 404.
I discovered this in an initial setups of nightly testing on one of my machines.
@bartlettroscoe https://gitlab.osti.gov/jmwille/Trilinos/-/issues/453Send out summary email of failing Trilinos Nightly builds and tests at end of...2018-10-11T14:04:09ZJames WillenbringSend out summary email of failing Trilinos Nightly builds and tests at end of each testing day*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Related to:** #380
**Description:**
At a meeting last week between Jim W. (@jwillenbring), Brent P. (@bmpersc), Erik S. and myself (@bartlettroscoe), Erik mentioned that one ...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Related to:** #380
**Description:**
At a meeting last week between Jim W. (@jwillenbring), Brent P. (@bmpersc), Erik S. and myself (@bartlettroscoe), Erik mentioned that one of the internal projects had/has a process where they send out a summary email at the end of each testing day that summarizes the failing tests. This email is seen by every developer on the project, the project lead, and the manager. If these tests are allowed to fail day after day, then the project lead (and then the managers) will step in and provide motivation and encouragement for the development team to help address the issues.
With the current CDash setup that is used by Trilinos, a targeted email goes out for every configure, build, or test failure for a package as soon as the results are uploaded and processed by the CDash. This email is targeted to the email list that is attached to a given Trilinos package. This gives that package team a heads up about the failure as soon as it is known. While this is good because it alerts the targeted people as soon as possible, one can't see the fully set of failures at the end of a testing day without going directly to CDash and looking.
This Story is to implement a process where a single email would be send out at the end of each testing day (e.g. at 1 am after the last testing day ended at 12 pm) to all of the Trilinos developers, project leads, and responsible managers with the full list of failing tests for the Nightly Trilinos builds. As described for the other internal SNL project described above, having this feature would help to elevate the importance of keeping the Nightly builds clean and therefore would support beefing up the testing to promote from the 'develop' branch to the 'master' branch.
There are several ways to implement this:
1) Add this as an official feature to CDash and pay Kitware to add it.
2) Implement this as a python script that reads from CDash using the new CDash API.
In my opinion, it would be pretty easy to implement option-2 above given the new CDash API that returns a JSON file for any CDash PHP page. This would be very similar to the script `send_kanban_wip_reminder_emails.py` which I (Ross) wrote for CASL PHI that queries the Trac DB and then creates a customized HTML-formatted email with a nice formatted table. My guess is that writing a script like this could be done in about 4 hours, including some unit tests to define and protect this functionality. You would then set up a cron job to run this script at the same time at the end of each testing day.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1255Add TPLs for Amesos2 in Nightly Builds2018-10-01T19:30:39ZJames WillenbringAdd TPLs for Amesos2 in Nightly Builds*Created by: srajama1*
We need to add SuperLU-Dist, SuperLU and UMFPACK as part of nightly tests.
@jwillenbring @krcb @MicheldeMessieres @trilinos/framework *Created by: srajama1*
We need to add SuperLU-Dist, SuperLU and UMFPACK as part of nightly tests.
@jwillenbring @krcb @MicheldeMessieres @trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3501Framework: Windows build not posting to dashboard2018-09-29T03:06:13ZJames WillenbringFramework: Windows build not posting to dashboard*Created by: csiefer2*
Again.*Created by: csiefer2*
Again.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3523install gitdist with trilinos install2018-09-27T17:02:35ZJames Willenbringinstall gitdist with trilinos install*Created by: rppawlo*
Is there any way we can get gitdist installed into the bin directory during trilinos installs? Might need a configure flag to enable/disable this capability?
@bartlettroscoe
@bathmatt *Created by: rppawlo*
Is there any way we can get gitdist installed into the bin directory during trilinos installs? Might need a configure flag to enable/disable this capability?
@bartlettroscoe
@bathmatt https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3515Framework: POSIX compatibility of build scripts2018-09-26T22:37:23ZJames WillenbringFramework: POSIX compatibility of build scripts*Created by: cgcgcg*
@trilinos/framework
## Expectations
It would be nice if the build scripts would work on all shells, and not just on bash. Examples of things that seem to create trouble are comparisons with `==` instead of `=` ...*Created by: cgcgcg*
@trilinos/framework
## Expectations
It would be nice if the build scripts would work on all shells, and not just on bash. Examples of things that seem to create trouble are comparisons with `==` instead of `=` and usage of the variable `BASH_SOURCE`.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3447download for Trilinos 12.12.1 is broken?2018-09-20T16:12:53ZJames Willenbringdownload for Trilinos 12.12.1 is broken?*Created by: boegel*
When I try to download Trilinos 12.12.1 via https://trilinos.org/download/, I end up with a broken link.
I considered downloading from https://github.com/trilinos/Trilinos/releases instead, but the source tarball...*Created by: boegel*
When I try to download Trilinos 12.12.1 via https://trilinos.org/download/, I end up with a broken link.
I considered downloading from https://github.com/trilinos/Trilinos/releases instead, but the source tarball tagged there for 12.12.1 seems to be something entirely different (e.g. `CTrilinos` is not in there).
Is the broken download via the website a known problem?
Is there another way to download the same `trilinos-12.12.1-Source.tar.gz` that was available via https://trilinos.org/download?
@trilinos/packagehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3435Framework: Autotester console output unhelpful2018-09-13T17:27:05ZJames WillenbringFramework: Autotester console output unhelpful*Created by: csiefer2*
Can we make this more useful to the developer?
See this PR:
https://github.com/trilinos/Trilinos/pull/3429
We get this unhelpful output:
17) atdm-ninja_fortran/1.7.2
MPI type = sems-mpich/3.2
CDash Track...*Created by: csiefer2*
Can we make this more useful to the developer?
See this PR:
https://github.com/trilinos/Trilinos/pull/3429
We get this unhelpful output:
17) atdm-ninja_fortran/1.7.2
MPI type = sems-mpich/3.2
CDash Track = Pull Request
*** Generating set of Trilinos enables given modified packages from
*** git commit origin/develop to HEAD
TRILINOS_DIR=/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
TRILINOS_SCRIPTS_DIR=/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos/cmake/std/../..
TRIBITS_DIR=/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos/cmake/std/../../cmake/tribits
A) Generate the Trilinos Packages definition and depencencies XML file
Wrote the file 'TrilinosPackageDependencies.xml'
B) Get the set of changed files
Current directory: /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
git diff --name-only origin/develop..HEAD > /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/changed-files.txt
Wrote file 'changed-files.txt'
Current directory: /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1
C) Get the unfiltered list of changed Trilinos packages (including 'ALL_PACKAGES')
CHANGED_PACKAGES_FULL_LIST='MueLu'
D) Filter list of changed packages to get only the PT packages
CHANGED_PACKAGES_PT_LIST='MueLu'
E) Generate the *.cmake enables file
Wrote file 'packageEnables.cmake'
Enabled packages:
-- Setting Trilinos_ENABLE_MueLu = ON
Build name = PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836
Cur dir = /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/TFW_testing_single_configure_prototype
Source dir = /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
Binary dir = /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/pull_request_test
Parallel level = 18
skip_by_parts_submit = OFF
skip_single_submit = ON
skip_update_step = ON
skip_upload_config_files = OFF
skip_clean_build_dir = OFF
Subproject count = 53
Dashboard model = Experimental
Dashboard track = Pull Request
Running configuration:
/projects/sems/install/rhel6-x86_64/atdm/binary-install/cmake-3.11.1-Linux-x86_64/bin/cmake
-C "/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos/cmake/std/PullRequestLinuxIntelTestingSettings.cmake"
-C "/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/packageEnables.cmake"
-DTrilinos_ENABLE_TESTS:BOOL=ON
-G "Ninja"
/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/Trilinos
CTEST_DROP_LOCATION = /cdash/submit.php?project=Trilinos
CDash URL1 = https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&display=project&filtercount=3&showfilters=1&filtercombine=and&field1=site&compare1=61&value1=ascic158&field2=buildname&compare2=61&value2=PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836&field3=buildstamp&compare3=61&value3=20180912-0916-Pull Request
CDash URL2 = https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&display=project&filtercount=2&showfilters=0&filtercombine=and&field1=buildname&compare1=61&value1=PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836&field2=buildstamp&compare2=61&value2=20180912-0916-Pull Request
CDash URL3 = https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercount=2&showfilters=0&filtercombine=and&field1=buildname&compare1=61&value1=PR-3429-test-Trilinos_pullrequest_intel_17.0.1-836&field2=buildstamp&compare2=61&value2=20180912-0916-Pull Request
Starting configure step.
Each . represents 1024 bytes of output
.................................................. Size: 50K
.................................................. Size: 100K
.................................... Size of output: 135K
configure submit error = 0
Configure suceeded.
Starting build step.
Each symbol represents 1024 bytes of output.
.................................................. Size: 49K
.................................................. Size: 99K
.................................................. Size: 149K
.................................................. Size: 199K
.................................................. Size: 249K
.................................................. Size: 299K
.................................................. Size: 349K
.................................................. Size: 400K
.................................................. Size: 449K
.................................................. Size: 499K
.................................................. Size: 549K
.................................................. Size: 599K
.................................................. Size: 649K
.................................................. Size: 699K
.......... Size of output: 709K
Build succeeded.
build submit error = 0
Starting testing step.
CMake Error at /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_intel_17.0.1/TFW_testing_single_configure_prototype/simple_testing.cmake:193 (message):
Test failed with error -1
test submit error = 0
File upload submit error = 0
Single configure/build/test failed. The error code was: 255
Build step 'Execute shell' marked build as failure
Finished: FAILUREhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3360Trilinos PR testing needs a build with KOKKOS_ENABLE_DEPRECATED_CODE=OFF2018-08-27T17:35:56ZJames WillenbringTrilinos PR testing needs a build with KOKKOS_ENABLE_DEPRECATED_CODE=OFF*Created by: mhoemmen*
@trilinos/framework
Trilinos developers keep adding use of deprecated Kokkos functions back into Trilinos. See e.g., #3358. They do so because no PR test builds disable deprecated Kokkos functions, and becau...*Created by: mhoemmen*
@trilinos/framework
Trilinos developers keep adding use of deprecated Kokkos functions back into Trilinos. See e.g., #3358. They do so because no PR test builds disable deprecated Kokkos functions, and because Trilinos enables deprecated Kokkos functions by default. If we disable deprecated Kokkos functions in at least one PR test build, Trilinos developers will learn not to rely on those functions.
## Motivation and Context
See Sierra Ticket 19694.
## Possible Solution
In at least one PR test build, set KOKKOS_ENABLE_DEPRECATED_CODE=OFF.
## Related Issues
* Related to #3358 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/440Switch to 'develop'/'master' branch in all repos listed in ExtraRepositoriesL...2018-08-15T01:35:32ZJames WillenbringSwitch to 'develop'/'master' branch in all repos listed in ExtraRepositoriesList.cmake*Created by: bartlettroscoe*
## Next Action Status:
???
**Blocked By:** #370, #176, #452
## Description:
As described in [this comment](https://github.com/trilinos/Trilinos/issues/370#issuecomment-224391677) in #370, the cu...*Created by: bartlettroscoe*
## Next Action Status:
???
**Blocked By:** #370, #176, #452
## Description:
As described in [this comment](https://github.com/trilinos/Trilinos/issues/370#issuecomment-224391677) in #370, the current implementation of the `TRIBITS_CTEST_DRIVER()` function will clone and use the 'master' branch of the extra repos even if `Trilinos_BRANCH=develop` or `trilinos-release-X-Y-branch`, etc. That is not consistent with treating this set of repos as "one big repo".
Therefore, this story is to switch all of the extra repos listed in Trilinos/cmake/ExtraRepositoriesList.cmake over to the 'develop'/'master' workflow that will be released or used by outside users. Any extra repo that is not going to switch over to the 'develop'/'master' workflow should not be listed in that file and should not be part of automated testing of Trilinos or Trilinos releases. More can be discussed about this but that basics are simple.
## Tasks:
1. Implement TriBITSPub/TriBITS#130 in TriBITS (This will result in `Trilinos_BRANCH=<branch>` getting checked out in each extra repo as well as the base Trilinos repo.) **[DONE]**
2. Determine what extra repos currently listed in ExtraRepositoriesList.cmake should continue being tested and perhaps released and which should not.
3. For those repos listed in ExtraRepositoriesList.cmake (i.e. that will continue to be tested and perhaps released), add a 'develop' branch.
4. Transition to the 'develop'/'master' workflow for all of the extra repos listed in ExtraRepositoriesList.cmake (in one push to the Trilinos 'develop' branch):
a. Update 'develop' branch from 'master' branch in all these extra repos and then lock down 'master' branch like for the main Trilinos git repo in #370.
b. Update the process that updates the Trilinos 'develop' branch to the 'master' branch also update from the 'develop' to the 'master' branches in these extra repos as well.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3263Test ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1 randomly failing in CI and...2018-08-09T19:59:42ZJames WillenbringTest ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1 randomly failing in CI and PR GCC 4.8.4 + OpenMP builds*Created by: bartlettroscoe*
@trilinos/shylu, @trilinos/framework, @srajama1 (Trilinos Linear Solvers Product Lead)
## Expectations
A test should not fail unless a changes is made to break it. A test should not randomly fail.
...*Created by: bartlettroscoe*
@trilinos/shylu, @trilinos/framework, @srajama1 (Trilinos Linear Solvers Product Lead)
## Expectations
A test should not fail unless a changes is made to break it. A test should not randomly fail.
## Current Behavior
Looking at the four most recent failures of the test `ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1` in [this query](https://testing-vm.sandia.gov/cdash/queryTests.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=4&showfilters=1&filtercombine=and&field1=testname&compare1=61&value1=ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1&field2=status&compare2=62&value2=passed&field3=status&compare3=62&value3=notrun&field4=buildstarttime&compare4=84&value4=now) the test appears to be randomly failing in the GCC 4.8.4 OpenMPI builds. In the most recent case, this test broke the auto PR GCC 4.8.4 + OpenMP build in PR #3260. IN each of the last for failures of this test dating back to 6/28/2018, they all fail showing:
```
....
[ RUN ] CrsMatrixBase.matrixmarket
unknown file: Failure
C++ exception with description "View bounds error of view ap ( 13 < 13 )
Traceback functionality not available
" thrown in the test body.
[ FAILED ] CrsMatrixBase.matrixmarket (23 ms)
...
[ FAILED ] 1 test, listed below:
[ FAILED ] CrsMatrixBase.matrixmarket
1 FAILED TEST
```
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
## Definition of Done
The test `ShyLU_NodeTacho_Tacho_TestSerial_double_MPI_1` is fixed to make it so that it does not randomly fail or is removed for CI and auto PR testing.
## Possible Solution
Fix it so that it does not randomly fail or remove it from CI and auto PR testing.
## Steps to Reproduce
See https://github.com/trilinos/Trilinos/wiki/Reproducing-PR-Testing-Errors.
## Your Environment
Standard SEMS GCC 4.8.4 auto PR build env (see above).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3272package_subproject_list.cmake static in Trilinos PR tester?2018-08-09T19:58:47ZJames Willenbringpackage_subproject_list.cmake static in Trilinos PR tester?*Created by: bartlettroscoe*
@trilinos/framework,
Is the file package_subproject_list.cmake used at:
https://github.com/trilinos/Trilinos/blob/0df591fd6d9b9ccd91bd2695cc22665aa468886d/cmake/std/PullRequestLinuxDriver.sh#L206
st...*Created by: bartlettroscoe*
@trilinos/framework,
Is the file package_subproject_list.cmake used at:
https://github.com/trilinos/Trilinos/blob/0df591fd6d9b9ccd91bd2695cc22665aa468886d/cmake/std/PullRequestLinuxDriver.sh#L206
statically generated and require manual updating? If so, that would explain why the PR builds are not testing the new PT package TrilinosFrameworkTests.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1155Implement automated pull request testing for Trilinos2018-08-01T20:51:58ZJames WillenbringImplement automated pull request testing for Trilinos*Created by: jwillenbring*
@trilinos/framework
@allevin is planning to develop a capability that will allow for testing of Trilinos pull request prior to having the changes applied to the develop branch. This story will track that w...*Created by: jwillenbring*
@trilinos/framework
@allevin is planning to develop a capability that will allow for testing of Trilinos pull request prior to having the changes applied to the develop branch. This story will track that work. A rough outline for the work is as follows:
1) Adapt some existing scripts that test the pull requests for another project to be more general and serve the Trilinos case.
2) Deploy on a limited, opt-in basis.
3) Deploy on a full basis for all Trilinos develop branch modifications.Improve productivity, stability, and quality of Trilinoshttps://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/3175Framework: Windows Testing is Down Again2018-07-24T14:39:28ZJames WillenbringFramework: Windows Testing is Down Again*Created by: csiefer2*
That.*Created by: csiefer2*
That.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3118Kokkos CMake error (fixed in kokkos:develop)2018-07-16T15:37:16ZJames WillenbringKokkos CMake error (fixed in kokkos:develop)*Created by: mhoemmen*
@trilinos/kokkos @trilinos/framework
## Current Behavior
At least one Trilinos build on the Dashboard shows the following CMake error:
```
CMake Error at packages/kokkos/cmake/kokkos_functions.cmake:50 (s...*Created by: mhoemmen*
@trilinos/kokkos @trilinos/framework
## Current Behavior
At least one Trilinos build on the Dashboard shows the following CMake error:
```
CMake Error at packages/kokkos/cmake/kokkos_functions.cmake:50 (string):
Syntax error in cmake code at
/home/jenkins/slave/workspace/Trilinos_apollo_gcc_4.9.3_cuda_8.0.44/MPI_RELEASE_DEV_DownStream_ETI_SERIAL-ON_OPENMP-OFF_PTHREAD-OFF_CUDA-ON_COMPLEX-OFF/Trilinos/packages/kokkos/cmake/kokkos_functions.cmake:50
when parsing string
[0-9]+\.[0-9]+\.[0-9]+$
Invalid escape sequence \.
Call Stack (most recent call first):
cmake/ProjectCompilerPostConfig.cmake:34 (set_kokkos_cxx_compiler)
/home/jenkins/slave/workspace/Trilinos_apollo_gcc_4.9.3_cuda_8.0.44/Trilinos/cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1847 (INCLUDE)
/home/jenkins/slave/workspace/Trilinos_apollo_gcc_4.9.3_cuda_8.0.44/Trilinos/cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
/home/jenkins/slave/workspace/Trilinos_apollo_gcc_4.9.3_cuda_8.0.44/Trilinos/cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
```
This is https://github.com/kokkos/kokkos/issues/1661 , which has been fixed in kokkos:develop by Kokkos PR https://github.com/kokkos/kokkos/pull/1662 .
## Possible Solution
Wait until the next Kokkos promotion into Trilinos.
## Related Issues
* Related to https://github.com/kokkos/kokkos/issues/1661https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3105Random timeouts in auto PR builds2018-07-13T14:33:40ZJames WillenbringRandom timeouts in auto PR builds*Created by: bartlettroscoe*
@trilinos/framework
## Expectations
Tests will not fail or timeout unless changes in a PR branch cause the failures or timeouts.
## Current Behavior
Several auto PR build iterations have been fa...*Created by: bartlettroscoe*
@trilinos/framework
## Expectations
Tests will not fail or timeout unless changes in a PR branch cause the failures or timeouts.
## Current Behavior
Several auto PR build iterations have been failing for a while due to random timeouts in various auto PR builds. For example, the first PR testing iteration in my PR #3104 failed last night due to random timeouts as shown [here](https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=PR-3104-test&field2=buildstarttime&compare2=84&value2=NOW). It is impossible for that one change to have impacted these test timeouts in any way.
You can see timeouts impacting other PR testing iterations as well in just the last 12 days in [this query](https://testing-vm.sandia.gov/cdash/queryTests.php?project=Trilinos&date=2018-07-12&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=3&showfilters=1&filtercombine=and&field1=buildstarttime&compare1=83&value1=2018-07-01&field2=groupname&compare2=61&value2=Pull%20Request&field3=details&compare3=63&value3=timeout). This shows 12 tests timing out in 3 different PRs over the last 12 days. Looking at the numbering of the builds, it seems likely that up to 4 or 5 PR testing iterations failed due to this issue. (It is hard to know how many PR testing iterations failed due to these random timeouts due to the naming of the PR builds since it is hard to differentiate different PR testing iterations in the same PR or to match up which builds of different compilers match up to the same PR testing iteration). Also, it is possible that some of these timeouts were due to changes in the PR branch.
## Motivation and Context
We want PR testing iterations to only fail if they are triggered by changes in the specific topic branch being tested.
While 4 or 5 failed PR testing iterations over 12 days may not seem like a lot, when combined with randomly failing tests (see #3103) and randomly failures in the Jenkins jobs (git pull fails, etc.), these add up to make the auto PR testing pretty unstable.
## Definition of Done
* Eliminate randomly failing tests.
## Possible Solution
The likely cause is that the Jenkins build farm machines are being overloaded. The very setup of the Jenkins site allows for this to occur because jobs can use more cores (i.e. "executors") than they declare and therefore overload the machine. Many of these timeouts occur late at night or in the early morning when the Jenkins build farm machines are likely to be processing nightly jobs.
## Steps to Reproduce
Hard to reproduce because these are random failures. I wish we had load statistics on these Jenkins build farm machine so that we could know when these we see timeouts like this.
Improve productivity, stability, and quality of Trilinoshttps://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/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/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