Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-01-10T21:50:23Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4154Framework: Windows tests need updated cmake2019-01-10T21:50:23ZJames WillenbringFramework: Windows tests need updated cmake*Created by: csiefer2*
For the first time in forever, windows tests are posting to cdash. But we've got an out-of-date cmake there.
Can we get this updated?
CMake Error at CMakeLists.txt:62 (CMAKE_MINIMUM_REQUIRED):
CMake 3.10.0...*Created by: csiefer2*
For the first time in forever, windows tests are posting to cdash. But we've got an out-of-date cmake there.
Can we get this updated?
CMake Error at CMakeLists.txt:62 (CMAKE_MINIMUM_REQUIRED):
CMake 3.10.0 or higher is required. You are running version 3.8.1
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4071Framework: Change Autotester Default Behavior When Sub-Tests Fail2018-12-18T17:07:33ZJames WillenbringFramework: Change Autotester Default Behavior When Sub-Tests Fail*Created by: csiefer2*
@trilinos/framework
Since this is far from the first Intel compiler issue we've had, I propose adding logic to the PR system to have it approve PRs if the Intel compiler dies before reaching configure of Trili...*Created by: csiefer2*
@trilinos/framework
Since this is far from the first Intel compiler issue we've had, I propose adding logic to the PR system to have it approve PRs if the Intel compiler dies before reaching configure of Trilinos AND the gcc tests pass.
The logic behind this is to keep non-code Intel compiler fails from creating a "stop the line" condition in which framework team members need to drop everything and fix the Intel issue du jour.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4069Framework: Intel Autotester is Woofing2018-12-20T15:56:10ZJames WillenbringFramework: Intel Autotester is Woofing*Created by: csiefer2*
Status Flag 'Pull Request AutoTester' - Failure: Timed out waiting for job Trilinos_pullrequest_intel_17.0.1 to start: Total Wait = 603
Other jobs have been previously started - We must stop them...
*Created by: csiefer2*
Status Flag 'Pull Request AutoTester' - Failure: Timed out waiting for job Trilinos_pullrequest_intel_17.0.1 to start: Total Wait = 603
Other jobs have been previously started - We must stop them...
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4065Framework: Remove unused parameters from Pull Request Jenkins Jobs2018-12-21T00:17:37ZJames WillenbringFramework: Remove unused parameters from Pull Request Jenkins Jobs*Created by: william76*
@trilinos/framework
### Issue
Last week I ran into an issue where the various Jenkins jobs that are run by the autotester for Pull Request testing had different stets of parameters. This was confusing so I ...*Created by: william76*
@trilinos/framework
### Issue
Last week I ran into an issue where the various Jenkins jobs that are run by the autotester for Pull Request testing had different stets of parameters. This was confusing so I made a pass through to synchronize all of them with the union of all the parameters from the different jobs. So now we have a bunch of parameters that aren't used in these jenkins jobs.
### Backstory
As discussed in our standup, the backstory on the extra parameters is that we initially pulled these jobs from the `parameterized build` and thought we might use them but then we decided against it because using these parameters might be difficult for developers to use to try and replicate builds that failed.
### Done Criteria
- [x] **Trilinos_pullrequest_gcc_4.8.4**: Remove parameters: `COMPILER_MODULE`, `MPI_MODULE`, `JENKINS_BUILD_TYPE`, `JENKINS_COMM_TYPE`, `JENKINS_JOB_TYPE`, `JENKINS_DO_COMPLEX`
- [x] **Trilinos_pullrequest_gcc_4.9.3**: Remove parameters: `COMPILER_MODULE`, `MPI_MODULE`, `JENKINS_BUILD_TYPE`, `JENKINS_COMM_TYPE`, `JENKINS_JOB_TYPE`, `JENKINS_DO_COMPLEX`
- [x] **Trilinos_pullrequest_gcc_4.9.3_SERIAL**: Remove parameters: `COMPILER_MODULE`, `MPI_MODULE`, `JENKINS_BUILD_TYPE`, `JENKINS_COMM_TYPE`, `JENKINS_JOB_TYPE`, `JENKINS_DO_COMPLEX`
- [x] **Trilinos_pullrequest_gcc_7.3.0**: Remove parameters: `COMPILER_MODULE`, `MPI_MODULE`, `JENKINS_BUILD_TYPE`, `JENKINS_COMM_TYPE`, `JENKINS_JOB_TYPE`, `JENKINS_DO_COMPLEX`
- [x] **Trilinos_pullrequest_intel_17.0.1**: Remove parameters: `COMPILER_MODULE`, `MPI_MODULE`, `JENKINS_BUILD_TYPE`, `JENKINS_COMM_TYPE`, `JENKINS_JOB_TYPE`, `JENKINS_DO_COMPLEX`
- [x] Verify that all Jenkins pull request jobs are consistent in their parameters.
- [x] Modify `cmake/std/PullRequestLinuxDriver-Test.sh` to remove the printouts of these environment variables.
- [x] Verify that the test scripts running the tests in `cmake/std` for pull request have no uses of these parameters.
- [x] Run a local test prior to PR testing.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4037Framework: Update PR testing script to prevent PR's to master from any branch...2019-02-25T17:15:40ZJames WillenbringFramework: Update PR testing script to prevent PR's to master from any branch other than develop*Created by: william76*
@trilinos/framework
@william76
Add a guard in the PR test driver script to auto-fail any Pull Request with `master` as the destination branch if the source branch is anything other than `develop`.
This w...*Created by: william76*
@trilinos/framework
@william76
Add a guard in the PR test driver script to auto-fail any Pull Request with `master` as the destination branch if the source branch is anything other than `develop`.
This will prevent accidentally getting PR's from a topic branch directly to master without going through develop first.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4034Framework: PR Tester GCC 7.2.0 Build Always Fails2018-12-18T22:26:12ZJames WillenbringFramework: PR Tester GCC 7.2.0 Build Always Fails*Created by: csiefer2*
And as a result all PRs are currently stuck in limbo.
For example:
https://github.com/trilinos/Trilinos/pull/4028
https://github.com/trilinos/Trilinos/pull/4027
https://github.com/trilinos/Trilinos/pull/40...*Created by: csiefer2*
And as a result all PRs are currently stuck in limbo.
For example:
https://github.com/trilinos/Trilinos/pull/4028
https://github.com/trilinos/Trilinos/pull/4027
https://github.com/trilinos/Trilinos/pull/4026
@trilinos/framework @jwillenbring @ZUUL42 @william76 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3959Website: Trilinos Capability Area Information Out of Date2018-12-08T17:52:21ZJames WillenbringWebsite: Trilinos Capability Area Information Out of Date*Created by: csiefer2*
Information on Trilinos product leads still lists the old capability areas:
https://trilinos.org/capability-areas/
https://trilinos.github.io/capability-areas.html
This leaves people who don't know who is i...*Created by: csiefer2*
Information on Trilinos product leads still lists the old capability areas:
https://trilinos.org/capability-areas/
https://trilinos.github.io/capability-areas.html
This leaves people who don't know who is in charge of what no way of finding that information out.
@trilinos/framework
@trilinos/linear-solvers
@trilinos/trilinos-web-portal https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3958Trilinos needs automated coverage testsing2019-05-02T17:46:20ZJames WillenbringTrilinos needs automated coverage testsing*Created by: bartlettroscoe*
@trilinos/framework
Trilinos currently has no coverage testing. The last coverage build posted to CDash was for MueLu back on 8/20/2018 as shown in [this query](https://testing.sandia.gov/cdash-dev-view...*Created by: bartlettroscoe*
@trilinos/framework
Trilinos currently has no coverage testing. The last coverage build posted to CDash was for MueLu back on 8/20/2018 as shown in [this query](https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&date=2018-11-28&filtercount=2&showfilters=1&filtercombine=and&field1=hascoverage&compare1=1&value1=&field2=buildstarttime&compare2=84&value2=now).
We need regular automated coverage builds posting to CDash.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3934Framework: CDash interprets failed shared library load as a "not run" rather ...2018-11-29T23:14:51ZJames WillenbringFramework: CDash interprets failed shared library load as a "not run" rather than as a fail*Created by: csiefer2*
@trilinos/framework @trilinos/muelu
As I discovered from our testing, if a program cannot find a shared library at run time (and the test fails to run), cdash reports that as a "Not Run" which has no useful sc...*Created by: csiefer2*
@trilinos/framework @trilinos/muelu
As I discovered from our testing, if a program cannot find a shared library at run time (and the test fails to run), cdash reports that as a "Not Run" which has no useful screen output. This case really ought to be a run failure, so we can see the effect of the failed library load.
See:
https://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=4215058https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3930Significant frequent CDash submit failures to testing-vm.sandia.gov/cdash Tri...2019-01-21T20:35:38ZJames WillenbringSignificant frequent CDash submit failures to testing-vm.sandia.gov/cdash Trilinos project starting mid 11/2018*Created by: bartlettroscoe*
@trilinos/framework, @fryeguy52
## Next Action Status
After addressing jenkins-srn.sandia.gov builds crashing by moving start times (see [TRIL-237](https://sems-atlassian-son.sandia.gov/jira/browse/TR...*Created by: bartlettroscoe*
@trilinos/framework, @fryeguy52
## Next Action Status
After addressing jenkins-srn.sandia.gov builds crashing by moving start times (see [TRIL-237](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-237)), we finally saw a day 12/19/2018 with full build and test results on CDash. Still are seeing some problems here and there but they are being addressed in other issues (see https://gitlab.kitware.com/snl/project-1/issues/79 and https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-237).
## Description
Starting around 11/18/2018 or so, we started to see significant numbers of CDash submit failures. This has resulted in up to 9 out of 30 promoted ATDM Trilinos builds not submitting test results as shown, for example, [on CDash on 11/25/2018](https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&date=2018-11-25&filtercount=1&showfilters=1&field1=buildname&compare1=65&value1=Trilinos-atdm-). You can see that these seem to be CDash submit failures from looking at the Jenkins output. And we see not just failures to submit test results (but that is the most common submit failure) but we also see failures to submit 'update' and 'configure' results in:
* https://jenkins-son.sandia.gov/view/Trilinos%20ATDM/job/Trilinos-atdm-hansen-shiller-cuda-8.0-opt/184/consoleFull
showing:
```
00:25:14 Submit files (using http)
00:25:14 Send to track: ATDM
00:25:14 Using HTTP submit method
00:25:14 Drop site:http://testing-vm.sandia.gov/cdash/submit.php?project=Trilinos
00:27:21 Submit failed, waiting 3 seconds...
00:27:24 Retry submission: Attempt 1 of 5
00:28:06 Submission failed: Checksum failed for file. Expected 9cc616d7c7444ddd408b2aa89977a0b8 but got 636f51bd65019e2d3d39d4fdb012ef00.
00:28:06 Submit failed, waiting 3 seconds...
00:28:09 Retry submission: Attempt 2 of 5
00:28:44 Submission failed: Checksum failed for file. Expected 9cc616d7c7444ddd408b2aa89977a0b8 but got d41d8cd98f00b204e9800998ecf8427e.
00:28:44 Submit failed, waiting 3 seconds...
00:28:47 Retry submission: Attempt 3 of 5
00:29:34 Submission failed: Checksum failed for file. Expected 9cc616d7c7444ddd408b2aa89977a0b8 but got 64fec38d5fd635493fd311dc65ff631c.
00:29:34 Submit failed, waiting 3 seconds...
00:29:37 Retry submission: Attempt 4 of 5
00:30:04 Submission failed: Checksum failed for file. Expected 9cc616d7c7444ddd408b2aa89977a0b8 but got d41d8cd98f00b204e9800998ecf8427e.
00:30:04 Submit failed, waiting 3 seconds...
00:30:07 Retry submission: Attempt 5 of 5
00:32:14 Error when uploading file: /home/jenkins/hansen/workspace/Trilinos-atdm-hansen-shiller-cuda-8.0-opt/SRC_AND_BUILD/BUILD/Testing/20181125-0400/Configure.xml
00:32:14 Error message was: Failed to connect to testing-vm.sandia.gov port 80: Connection timed out
00:32:14 Problems when submitting via HTTP
```
and failures to submit 'build' results in:
* https://jenkins-son.sandia.gov/view/Trilinos%20ATDM/job/Trilinos-atdm-hansen-shiller-cuda-9.0-debug/183/consoleFull
showing:
```
11:50:15 Submit files (using http)
11:50:15 Send to track: ATDM
11:50:15 Using HTTP submit method
11:50:15 Drop site:http://testing-vm.sandia.gov/cdash/submit.php?project=Trilinos
11:50:51 Submission failed: Checksum failed for file. Expected b6b1936e73c4fcda5459c4c3305718ad but got f33c85574fc1714cb55e743d00c37f63.
11:50:51 Submit failed, waiting 3 seconds...
11:50:54 Retry submission: Attempt 1 of 5
11:53:01 Submit failed, waiting 3 seconds...
11:53:04 Retry submission: Attempt 2 of 5
11:55:11 Submit failed, waiting 3 seconds...
11:55:14 Retry submission: Attempt 3 of 5
11:57:22 Submit failed, waiting 3 seconds...
11:57:25 Retry submission: Attempt 4 of 5
11:57:45 Submission failed: Checksum failed for file. Expected b6b1936e73c4fcda5459c4c3305718ad but got d41d8cd98f00b204e9800998ecf8427e.
11:57:45 Submit failed, waiting 3 seconds...
11:57:48 Retry submission: Attempt 5 of 5
11:58:35 Submission failed: Checksum failed for file. Expected b6b1936e73c4fcda5459c4c3305718ad but got 4822ffa741a1777a465e8cfdd7764c97.
11:58:35 Uploaded: /home/jenkins/hansen/workspace/Trilinos-atdm-hansen-shiller-cuda-9.0-debug/SRC_AND_BUILD/BUILD/Testing/20181125-0400/Build.xml
11:58:35 Errors occurred during submission.
```
and of course failures to submit 'test' results in:
* https://jenkins-son.sandia.gov/view/Trilinos%20ATDM/job/Trilinos-atdm-hansen-shiller-gnu-debug-openmp/286/consoleFull
showing:
```
Submit files (using http)
Send to track: ATDM
Using HTTP submit method
Drop site:http://testing-vm.sandia.gov/cdash/submit.php?project=Trilinos
Submission failed: Checksum failed for file. Expected 4a3869a85b2dacb9947d040b2c22673d but got f898f5520369486d65c0a4e5bf510f8b.
Submit failed, waiting 3 seconds...
Retry submission: Attempt 1 of 5
Submission failed: Checksum failed for file. Expected 4a3869a85b2dacb9947d040b2c22673d but got f6d6ed6443bb76d6f2ecdf8c9103c065.
Submit failed, waiting 3 seconds...
Retry submission: Attempt 2 of 5
Submission failed: Checksum failed for file. Expected 4a3869a85b2dacb9947d040b2c22673d but got bf51a2e520d51fc30a9a06459bbf88e9.
Submit failed, waiting 3 seconds...
Retry submission: Attempt 3 of 5
Submission failed: Checksum failed for file. Expected 4a3869a85b2dacb9947d040b2c22673d but got c8f2a8d360b11a165ebd854dd3676604.
Submit failed, waiting 3 seconds...
Retry submission: Attempt 4 of 5
Submission failed: Checksum failed for file. Expected 4a3869a85b2dacb9947d040b2c22673d but got a1292fc160823ef0142d7f01a960dd47.
Submit failed, waiting 3 seconds...
Retry submission: Attempt 5 of 5
Submission failed: Checksum failed for file. Expected 4a3869a85b2dacb9947d040b2c22673d but got 94252fe24f52c3dafae1f00fe671ad4c.
Uploaded: /home/jenkins/hansen/workspace/Trilinos-atdm-hansen-shiller-gnu-debug-openmp/SRC_AND_BUILD/BUILD/Testing/20181125-0400/Test.xml
Errors occurred during submission.
```
But this is not only impacting the ATDM Trilinos builds. For example, if you look at the submits of the "Clean" builds since 11/01/2018 shown [here](https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&date=2018-11-25&filtercount=2&showfilters=1&filtercombine=and&field1=groupname&compare1=61&value1=Clean&field2=buildstarttime&compare2=83&value2=2018-11-01), you can see test results missing as far back as 11/16/2018 and more recently we see significant numbers of missing test results on 11/22/2108, 11/25/2018 and today on 11/26/2018.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3906Create plan and process for Trilinos testing with new compilers before import...2018-12-07T16:59:59ZJames WillenbringCreate plan and process for Trilinos testing with new compilers before important Trilinos customers*Created by: bartlettroscoe*
@trilinos/framework
Trilinos needs to be testing with newer compiler versions as they come out so that we our customers start testing with newer compilers. That way Trilinos is not always playing catch-...*Created by: bartlettroscoe*
@trilinos/framework
Trilinos needs to be testing with newer compiler versions as they come out so that we our customers start testing with newer compilers. That way Trilinos is not always playing catch-up. We need a plan for doing this and we need a process for doing this.
An example of what happens right now is demonstrated in #3497 and #3499 with the upgrade of ATS-1 ('mutrino', 'trinity') from Intel 17 to Intel 18.
NOTE: I marked this with the label 'epic' since that is what this is.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3900Can't download trilinos2019-01-16T17:44:33ZJames WillenbringCan't download trilinos*Created by: VictorEijkhout*
Connecting to trilinos.csbsju.edu (trilinos.csbsju.edu)|152.65.160.65|:80... failed:*Created by: VictorEijkhout*
Connecting to trilinos.csbsju.edu (trilinos.csbsju.edu)|152.65.160.65|:80... failed:https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3857Framework: Add Wiki entry to describe useful email filters to help with githu...2018-11-19T22:53:59ZJames WillenbringFramework: Add Wiki entry to describe useful email filters to help with github spam*Created by: william76*
@trilinos/framework
A conversation came up today in our meeting with @bartlettroscoe about the email spam being sent out by github, especially since we started using the PR tester, which adds a few comments t...*Created by: william76*
@trilinos/framework
A conversation came up today in our meeting with @bartlettroscoe about the email spam being sent out by github, especially since we started using the PR tester, which adds a few comments to every PR, which generates an email each time. We thought a wiki article for Trilinos would be useful to go over useful email filter settings to help cut down the spam.
Generally speaking, I think what many people do is they filter out all the spam unless there is an @mention to them or a team they're on... but I think many people don't do this. So an article we can point people to would be useful.
This relates to some old issues #1674 #668 Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3832Framework: Add GCC 7.3 MPI dev->master and PR builds2018-12-05T17:18:40ZJames WillenbringFramework: Add GCC 7.3 MPI dev->master and PR builds*Created by: jwillenbring*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note th...*Created by: jwillenbring*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/framework
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
We want to have dev->master and PR builds that use GCC 7.3.
## 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.
-->
Due to key customer requirements, GCC 7.2 is an important compiler for Trilinos to build cleanly with. The closest version we currently have on the SEMS NFS mount is 7.3, so we are going to use that, at least for the time being.
Eventually we want to add warnings as errors flags to this build too, but that will be covered in a separate ticket.
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
- [ ] First do this.
- [ ] Then do that.
- [ ] Also this other thing.
-->
Definition of Done is that there is a PR build in place and a dev->master build in place, building cleanly (prior to the changes being tested in that instance).
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
1) Create files for GCC 7.3 analogous to Trilinos/cmake/std/PullRequestLinuxGCC4.9.3TestingSettings.cmake
Trilinos/cmake/std/sems/PullRequestGCC4.9.3TestingEnv.sh
and get those files into the develop branch
2) Modify the autotester config file for dev->master testing to include this build and run the build once to detect any issues. It might be good to set up a parameterized build for 7.3 to find most issues before doing this.
3) Once the dev->master build is clean, repeat the process at the PR level.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3830Framework: Stop builds with unsuported compilers2018-11-13T15:40:31ZJames WillenbringFramework: Stop builds with unsuported compilers*Created by: lucbv*
@trilinos/framework @bartlettroscoe
## Expectations
I am not sure it makes sense to keep the following nightly build:
ascic 144: [Linux-gcc-4.7.2-MPI_Release_gcc_4.7.2_openmpi_1.8.7_DEV](https://testing.sandia....*Created by: lucbv*
@trilinos/framework @bartlettroscoe
## Expectations
I am not sure it makes sense to keep the following nightly build:
ascic 144: [Linux-gcc-4.7.2-MPI_Release_gcc_4.7.2_openmpi_1.8.7_DEV](https://testing.sandia.gov/cdash/buildSummary.php?buildid=4152501)
## Current Behavior
The build is failing at configure time, it returns the following error message:
```
CMake Error at packages/kokkos/cmake/kokkos_functions.cmake:68 (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
```
## Motivation and Context
This might free up a bit the machines and make the dashboard more readable.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3813PR build Trilinos_pullrequest_gcc_4.9.3_SERIAL and the nightly "Clean" build ...2018-11-06T21:47:30ZJames WillenbringPR build Trilinos_pullrequest_gcc_4.9.3_SERIAL and the nightly "Clean" build Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV are not the same*Created by: bartlettroscoe*
CC: @dridzal, @crtrott, @srajama1
@trilinos/framework,
It looks like the PR build `Trilinos_pullrequest_gcc_4.9.3_SERIAL` and the nightly "Clean" build `Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV` ...*Created by: bartlettroscoe*
CC: @dridzal, @crtrott, @srajama1
@trilinos/framework,
It looks like the PR build `Trilinos_pullrequest_gcc_4.9.3_SERIAL` and the nightly "Clean" build `Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV` are **NOT** the same!
The configuration for the PR build `Trilinos_pullrequest_gcc_4.9.3_SERIAL` for this PR shown [here](https://testing-vm.sandia.gov/cdash/viewConfigure.php?buildid=4141632) shows the Pthread TPL being explicitly enabled:
```
Explicitly enabled TPLs on input (by user): Pthread BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib DLlib 10
...
Final set of enabled TPLs: Pthread BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib DLlib 10
```
but the nightly "Clean" build `Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV` shown [here](https://testing.sandia.gov/cdash-dev-view/viewConfigure.php?buildid=4142839) shows that the Pthread is **not** being explicitly enabled:
```
Explicitly enabled TPLs on input (by user): BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib DLlib 9
...
Final set of enabled TPLs: BLAS LAPACK Boost Zlib HDF5 Netcdf SuperLU BoostLib X11 DLlib 10
```
This explains how code got onto 'develop' that was allowed to break the "Clean" non-MPI SERIAL build (see #3773 and #3803)
I thought the goal of the adding a (non-MPI) SERIAL PR build was to guarantee that the nightly "Clean" SERIAL would be clean?
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3783PyTrilinos: How can I get the MPI include directory in a robust way?2018-10-31T18:44:06ZJames WillenbringPyTrilinos: How can I get the MPI include directory in a robust way?*Created by: wfspotz*
@trilinos/pytrilinos @trilinos/framework
## Expectations
In PyTrilinos, I have a python script that generates a SWIG interface file. That SWIG interface file needs to know where the `mpi.h` header file is, so ...*Created by: wfspotz*
@trilinos/pytrilinos @trilinos/framework
## Expectations
In PyTrilinos, I have a python script that generates a SWIG interface file. That SWIG interface file needs to know where the `mpi.h` header file is, so I can parse it and extract `MPI_VERSION`. I developed some logic to find it that worked for me, but it is not robust enough to work for all users. How can I obtain the MPI include path for finding `mpi.h` in a robust way?
## Current Behavior
In #3618 the user specifies his MPI configuration with
-D TPL_ENABLE_MPI:BOOL=ON
-D MPI_EXEC:FILEPATH=/opt/apps/xalt/0.6/bin/ibrun
but my script specifies the path to `mpi.h` incorrectly.
## Motivation and Context
Here is what I do. I start with a file `get_teuchos_rcp.py.in` that will get copied to the build directory with `cmake` variable substituted in. It has the following function defined to correctly interpret `cmake` boolean variables:
def cmake_bool(value):
if value.upper() in ("", "0", "FALSE", "N", "NO", "OFF"):
return False
return True
I then define python variable `WITH_MPI` (among many others) using
WITH_MPI = cmake_bool("${TPL_ENABLE_MPI}")
I then use this logic to define python variable `MPI_BASE_DIR`:
MPI_BASE_DIR = "${MPI_BASE_DIR}"
if WITH_MPI:
if MPI_BASE_DIR == "":
MPI_BIN_DIR = os.path.split("${MPI_CXX_COMPILER}")[0]
MPI_BASE_DIR = os.path.split(MPI_BIN_DIR)[0]
All this leads to supporting the following function:
def get_mpi_version():
header = os.path.join(MPI_BASE_DIR, "include", "mpi.h")
version = ""
for line in open(header, 'r').readlines():
if "MPI_VERSION" in line:
version = line.split()[2]
break
return version
But the assumption that `mpi.h` lives in `MPI_BASE_DIR/include` is wrong, because in my user's case, the actual path does not have an `include` suffix.
## Definition of Done
When the user in #3618 can build PyTrilinos at his installation, which is TACC.
## Possible Solution
Does the `cmake` logic that looks for MPI have logic that extracts the location of the `mpi.h` file? If not, could it be added?
## Related Issues
* Blocks #3618
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3778Framework: Autotester for master merge does not delete branches after merge2018-11-14T15:49:38ZJames WillenbringFramework: Autotester for master merge does not delete branches after merge*Created by: csiefer2*
The branch list is littered with merged branches like this guy:
master_merge_20181018_074226
After getting on my case about automatically generated branch proliferation, I'd like to return the favor :stuck_...*Created by: csiefer2*
The branch list is littered with merged branches like this guy:
master_merge_20181018_074226
After getting on my case about automatically generated branch proliferation, I'd like to return the favor :stuck_out_tongue:
@trilinos/framework
@william76 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3773GCC 4.9.3-SERIAL fails in nightly clean test2018-11-07T15:48:47ZJames WillenbringGCC 4.9.3-SERIAL fails in nightly clean test*Created by: william76*
@trilinos/kokkos-kernels
An error showed up in the [gcc 4.9.3 SERIAL build on 10/25][1], which means the issue likely was introduced sometime on 10/24.
The errors I'm seeing are:
```
libkokkoskernels_g...*Created by: william76*
@trilinos/kokkos-kernels
An error showed up in the [gcc 4.9.3 SERIAL build on 10/25][1], which means the issue likely was introduced sometime on 10/24.
The errors I'm seeing are:
```
libkokkoskernels_gtest.so.12.13: undefined reference to `pthread_key_create'
libkokkoskernels_gtest.so.12.13: undefined reference to `pthread_getspecific'
libkokkoskernels_gtest.so.12.13: undefined reference to `pthread_key_delete'
libkokkoskernels_gtest.so.12.13: undefined reference to `pthread_setspecific'
collect2: error: ld returned 1 exit status
```
I was out of town for the past week... @jwillenbring do you know if anything @trilinos/framework related changed on our configurations that would cause an undefined reference to things like `pthread_key_create`?
@trilinos/kokkos-kernels was anything merged into Trilinos that is using any new features from pthreads that might require a newer version of pthreads on the testing machines?
I also found [this StackOverflow issue][2] which was related to someone linking libgtest incorrectly... were any changes that might relate to gtest stuff in KokkosKernels pushed into Trilinos on 10/24?
[1]: https://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2018-10-25&filtercount=2&showfilters=1&filtercombine=or&field1=groupname&compare1=63&value1=Clean&field2=groupname&compare2=63&value2=Continuous
[2]: https://stackoverflow.com/questions/21116622/undefined-reference-to-pthread-key-create-linker-errorhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3771Framework: Who switched the packages labels and why?2018-10-30T23:12:42ZJames WillenbringFramework: Who switched the packages labels and why?*Created by: csiefer2*
Our labels just went from "MueLu" to "packages: MueLu"
Anyone care to explain?
@trilinos/framework*Created by: csiefer2*
Our labels just went from "MueLu" to "packages: MueLu"
Anyone care to explain?
@trilinos/framework