Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-06-08T15:27:26Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/5070Framework: Autotester runs not reporting2019-06-08T15:27:26ZJames WillenbringFramework: Autotester runs not reporting*Created by: csiefer2*
#5067 #5066
@trilinos/framework @jwillenbring @william76 *Created by: csiefer2*
#5067 #5066
@trilinos/framework @jwillenbring @william76 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5058Trilinos Framework: Change GCC 4.8.4 PR build to use static libraries2019-06-08T15:27:26ZJames WillenbringTrilinos Framework: Change GCC 4.8.4 PR build to use static libraries*Created by: jwillenbring*
## Enhancement
@trilinos/framework
Our PR testing does not currently include any static library builds. There are important use cases for static libraries, so we want to change one build to use static lib...*Created by: jwillenbring*
## Enhancement
@trilinos/framework
Our PR testing does not currently include any static library builds. There are important use cases for static libraries, so we want to change one build to use static libraries. The GCC 4.8.4 MPI build has been chosen for this enhancement to the PR test suite.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5034Framework: apparent problem during PR cmake configure for CUDA2019-04-29T19:00:46ZJames WillenbringFramework: apparent problem during PR cmake configure for CUDA*Created by: jhux2*
@trilinos/framework The [results](https://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=1&showfilters=1&field1=buildname&compare1=65&value1=PR-5028) for PR #5028 are showing a lot of tests not run f...*Created by: jhux2*
@trilinos/framework The [results](https://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=1&showfilters=1&field1=buildname&compare1=65&value1=PR-5028) for PR #5028 are showing a lot of tests not run for CUDA. The cmake log has the following. Is this perhaps a bug in the configure script itself?
```
Finished configuring Trilinos!
Total time to configure Trilinos: 1m53.234s
-- Configuring done
CMake Warning:
Value of Trilinos_ENABLE_TESTS contained a newline; truncating
-- Generating done
CMake Warning:
Value of Trilinos_ENABLE_TESTS contained a newline; truncating
-- Build files have been written to: /home/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_cuda_9.2/pull_request_test
```
@trilinos/framework @bartlettroscoe @william76 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5031Framework: PR Reproduction Instructions Failing2019-04-29T17:24:35ZJames WillenbringFramework: PR Reproduction Instructions Failing*Created by: csiefer2*
Finished configuring Trilinos!
-- Configuring incomplete, errors occurred!
With no errors showing up in the cmake output (joy!).
GCC 4.9.3, as it turns out.*Created by: csiefer2*
Finished configuring Trilinos!
-- Configuring incomplete, errors occurred!
With no errors showing up in the cmake output (joy!).
GCC 4.9.3, as it turns out.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4810spack: Does a spack Trilinos variant exist for enabling CUDA support?2019-04-05T12:52:18ZJames Willenbringspack: Does a spack Trilinos variant exist for enabling CUDA support?*Created by: cwsmith*
I'd like to install Kokkos with the CUDA backend, via Trilinos, with spack. We use CMake for our projects that depend on Kokkos, hence the install via Trilinos.
Is there a branch of spack with a variant that en...*Created by: cwsmith*
I'd like to install Kokkos with the CUDA backend, via Trilinos, with spack. We use CMake for our projects that depend on Kokkos, hence the install via Trilinos.
Is there a branch of spack with a variant that enables CUDA in Trilinos/Kokkos?
Thank-you,
Cameronhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4752Switch Trilinos to the semantic versioning standard?2019-03-28T15:43:58ZJames WillenbringSwitch Trilinos to the semantic versioning standard?*Created by: bartlettroscoe*
@trilinos/framework
## Description
The Semantic Versioning Standard (https://semver.org) is a better and more standard way to name releases and versions leading up to a release. Instead of the curren...*Created by: bartlettroscoe*
@trilinos/framework
## Description
The Semantic Versioning Standard (https://semver.org) is a better and more standard way to name releases and versions leading up to a release. Instead of the current even/odd minor version numbering that is currently used by Trilinos, on could consider switching to:
* Current release: `trilinos-X.Y.Z`
* Next major release version: `trilinos-(X+1).Y.0`
* Next minor release version: `trilinos-X.(Y+1).0`
* Next patch release version: `trilinos-X.Y.(Z+1)`
* Development version leading up to next minor release `trilinos-X.(Y+1).0-dev.Q`
The development version tag `trilinos-X.(Y+1).0-dev.Q` can be generated using `git --describe --match="trilinos-X.(Y+1)*"` (more details later in this Issue).
This is consistent with First, two SemVer items https://semver.org/#spec-item-9:
> A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
and https://semver.org/#spec-item-11:
> Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence). Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0. Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
The SemVer standard says that `trilinos-X.Y.0-dev.Q` is **before** the release `trilinos-X.Y.0`. Therefore, `trilinos-X.Y.0-dev.Q` is the Qth development version leading up to `trilinos-X.Y.0`.
Therefore, we have the ordering:
* `trilinos-X.Y.0-dev.Q` < `trilinos-X.Y.0` < `trilinos-X.Y.Z` (for `Z` > `0`)
This outlined in more detail in [Addition of release branches](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#heading=h.xav3ed16muxt).
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4631Trilinos PR tester is broken and blocking merges2019-04-03T20:43:39ZJames WillenbringTrilinos PR tester is broken and blocking merges*Created by: jhux2*
@trilinos/framework
@jwillenbring
For example, PR #4625 is blocked, although when I [query](https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&f...*Created by: jhux2*
@trilinos/framework
@jwillenbring
For example, PR #4625 is blocked, although when I [query](https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=PR-4625-test&field2=buildstarttime&compare2=84&value2=NOW) the PR dashboard, everything is green. The issue looks like something internal to the tester:
### Trilinos_pullrequest_gcc_4.9.3_SERIAL # 1102 ###
```
[EnvInject] - Loading node environment variables.
Building remotely on ascic115-trilinos (trilinos-32 trilinos-sandybridge trilinos-any) in workspace /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3_SERIAL
[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
Cloning the remote Git repository
Cloning repository https://github.com/trilinos/Trilinos
> git init /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3_SERIAL/Trilinos # timeout=10
Fetching upstream changes from https://github.com/trilinos/Trilinos
> git --version # timeout=10
Setting http proxy: wwwproxy.sandia.gov:80
> git fetch --tags --progress https://github.com/trilinos/Trilinos +refs/heads/*:refs/remotes/origin/* # timeout=25
> git config remote.origin.url https://github.com/trilinos/Trilinos # timeout=10
> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url https://github.com/trilinos/Trilinos # timeout=10
Fetching upstream changes from https://github.com/trilinos/Trilinos
Setting http proxy: wwwproxy.sandia.gov:80
> git fetch --tags --progress https://github.com/trilinos/Trilinos +refs/heads/*:refs/remotes/origin/* # timeout=25
> git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision 0fcd5c0f00e8fd204f2f7d40cfd3d4ca3f3e4537 (refs/remotes/origin/develop)
> git config core.sparsecheckout # timeout=10
> git checkout -f 0fcd5c0f00e8fd204f2f7d40cfd3d4ca3f3e4537
Commit message: "Merge Pull Request #4601 from mhoemmen/Trilinos/Fix-4600"
> git rev-list --no-walk 0fcd5c0f00e8fd204f2f7d40cfd3d4ca3f3e4537 # timeout=10
[Trilinos_pullrequest_gcc_4.9.3_SERIAL] $ /bin/env bash /tmp/jenkins1100506649378124791.sh
git version 1.7.1
Initialized empty Git repository in /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3_SERIAL/TFW_single_configure_support_scripts/.git/
Initialized empty Git repository in /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.9.3_SERIAL/TFW_testing_single_configure_prototype/.git/
error: The requested URL returned error: 403 Forbidden while accessing https://prwolfe:n17v8WYsMB2iT1Gz2aY1@gitlab.sandia.gov/20855/TFW_testing_single_configure_prototype.git/info/refs
fatal: HTTP request failed
Build step 'Execute shell' marked build as failure
Archiving artifacts
Finished: FAILURE
```
### Trilinos_pullrequest_gcc_7.2.0 ###
```
[EnvInject] - Loading node environment variables.
Building remotely on ascic113-trilinos (trilinos-32 trilinos-sandybridge trilinos-any) in workspace /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_7.2.0
Cloning the remote Git repository
Cloning repository https://github.com/trilinos/Trilinos
> git init /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_7.2.0/Trilinos # timeout=10
Fetching upstream changes from https://github.com/trilinos/Trilinos
> git --version # timeout=10
using GIT_SSH to set credentials Trilinos ssh key
Setting http proxy: wwwproxy.sandia.gov:80
> git fetch --tags --progress https://github.com/trilinos/Trilinos +refs/heads/*:refs/remotes/origin/* # timeout=20
> git config remote.origin.url https://github.com/trilinos/Trilinos # timeout=10
> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url https://github.com/trilinos/Trilinos # timeout=10
Fetching upstream changes from https://github.com/trilinos/Trilinos
using GIT_SSH to set credentials Trilinos ssh key
Setting http proxy: wwwproxy.sandia.gov:80
> git fetch --tags --progress https://github.com/trilinos/Trilinos +refs/heads/*:refs/remotes/origin/* # timeout=20
> git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision 8a245a088486093eec8db445726da47bbc975c0a (refs/remotes/origin/develop)
> git config core.sparsecheckout # timeout=10
> git checkout -f 8a245a088486093eec8db445726da47bbc975c0a
Commit message: "Merge pull request #4496 from trilinos/csiefer-afdf07e"
> git rev-list --no-walk 77f2fc3e9e07197ed1a364a5c8d8a2ed75a1b331 # timeout=10
[Trilinos_pullrequest_gcc_7.2.0] $ /bin/env bash /tmp/jenkins39252355682801808.sh
git version 1.7.1
Initialized empty Git repository in /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_7.2.0/TFW_single_configure_support_scripts/.git/
Initialized empty Git repository in /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_7.2.0/TFW_testing_single_configure_prototype/.git/
error: The requested URL returned error: 403 Forbidden while accessing https://prwolfe:n17v8WYsMB2iT1Gz2aY1@gitlab.sandia.gov/20855/TFW_testing_single_configure_prototype.git/info/refs
fatal: HTTP request failed
Build step 'Execute shell' marked build as failure
Archiving artifacts
Finished: FAILURE
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4621Allow Trilinos users to set Labels2019-03-18T12:45:16ZJames WillenbringAllow Trilinos users to set Labels*Created by: bartlettroscoe*
@trilinos/framework
The instructions for creating new GitHub issues at:
* https://github.com/trilinos/Trilinos/wiki/Managing-Trilinos-Project-Issues
and even the GitHub issue template at:
* http...*Created by: bartlettroscoe*
@trilinos/framework
The instructions for creating new GitHub issues at:
* https://github.com/trilinos/Trilinos/wiki/Managing-Trilinos-Project-Issues
and even the GitHub issue template at:
* https://raw.githubusercontent.com/trilinos/Trilinos/master/.github/ISSUE_TEMPLATE.md
tells users to set Issue Labels but it it is reported in https://github.com/trilinos/Trilinos/issues/4616#issuecomment-472939081 that users can't actually set labels.
Is there any reason we can't allow users to set labels on Trilinos GitHub Issues like they are being told to do?
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4571Long file names in KokkosKernels have broken git clone of Trilinos on Windows2019-03-07T19:52:38ZJames WillenbringLong file names in KokkosKernels have broken git clone of Trilinos on Windows*Created by: bartlettroscoe*
CC: @trilinos/framework, @trilinos/kokkos-kernels
## Description
It appears that the Trilinos git repo has gotten into a state where it can't even be cloned on Windows systems with git.
The CASL PH...*Created by: bartlettroscoe*
CC: @trilinos/framework, @trilinos/kokkos-kernels
## Description
It appears that the Trilinos git repo has gotten into a state where it can't even be cloned on Windows systems with git.
The CASL PHI INF lead @lefebvrera reported the following error when trying to clone the current Trilinos git repo just a short time ago:
```
G:\raq\scale_dev\dev>git clone https://github.com/trilinos/Trilinos.git Trilinos
Cloning into 'Trilinos'...
remote: Enumerating objects: 47, done.
remote: Counting objects: 100% (47/47), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 957120 (delta 17), reused 14 (delta 7), pack-reused 957073
Receiving objects: 100% (957120/957120), 562.05 MiB | 26.56 MiB/s, done.
Resolving deltas: 100% (771153/771153), done.
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_numeric/KokkosSparse_gauss_seidel_numeric_eti_spec_inst_Kokkos_complex_double__size_t_int64_t_LayoutRight_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_double__size_t_int64_t_LayoutLeft_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_double__size_t_int64_t_LayoutRight_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_float__size_t_int64_t_LayoutLeft_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
error: unable to create file packages/kokkos-kernels/src/impl/generated_specializations_cpp/gauss_seidel_symbolic/KokkosSparse_gauss_seidel_symbolic_eti_spec_inst_Kokkos_complex_float__size_t_int64_t_LayoutRight_Cuda_CudaHostPinnedSpace_CudaHostPinnedSpace.cpp: Filename too long
Checking out files: 100% (56578/56578), done.
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4461Framework: Autotester Occasionally Refuses to Do Inspection2019-03-08T17:10:35ZJames WillenbringFramework: Autotester Occasionally Refuses to Do Inspection*Created by: csiefer2*
Which means you can't merge a tested, approved PR.
This can be 'fixed' by throwing on 'AT: RETEST' and burning another 4 hours of testing time (if the test machines all work), but this is getting annoying.
@...*Created by: csiefer2*
Which means you can't merge a tested, approved PR.
This can be 'fixed' by throwing on 'AT: RETEST' and burning another 4 hours of testing time (if the test machines all work), but this is getting annoying.
@trilinos/framework @william76 @jwillenbring https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4421Framework: new version of gtest with gmock and gtest_main2019-02-18T19:00:39ZJames WillenbringFramework: new version of gtest with gmock and gtest_main*Created by: rppawlo*
@trilinos/framework - is there any chance someone could upgrade the gtest version in Trilinos to the most recent release and make sure to include gmock and gtest_main? Since gtest is installed as part of Trilinos, ...*Created by: rppawlo*
@trilinos/framework - is there any chance someone could upgrade the gtest version in Trilinos to the most recent release and make sure to include gmock and gtest_main? Since gtest is installed as part of Trilinos, some external apps are interested in leveraging this.
@jwillenbring @bathmatt https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4272The package Pliris needs to be elevated from ST to PT since it is being used ...2019-01-26T04:04:51ZJames WillenbringThe package Pliris needs to be elevated from ST to PT since it is being used by ATDM APP Gemma*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The Gemma configuration of Trilinos currently enables the Tril...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The Gemma configuration of Trilinos currently enables the Trilinos package `Pliris` (see [TRIL-255](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-255)). However, the package `Pliris` is currently declared `ST` (Secondary Tested) and therefore is not included in any Trilinos PR builds.
Since an important internal Trilinos customer (i.e Gemma) is using `Pliris`, [by definition](http://trac.trilinos.org/wiki/TribitsLifecycleModelOverview#test_categories), it needs to be elevated from Secondary Tested (ST) to Primary Tested (PT). Otherwise, `Pliris` will not get enabled in Trilinos PR builds and therefore will not protect SPARC (see #2597).
## Proposed Solution
Update the line:
```
Pliris packages/pliris ST
```
to be
```
Pliris packages/pliris PR
```
in the file
* `Trilinos/PackagesList.cmake`
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4269Propose new Trilinos release model2019-03-03T18:38:58ZJames WillenbringPropose new Trilinos release model*Created by: mhoemmen*
@trilinos/framework @maherou @jwillenbring @bartlettroscoe
PR https://github.com/trilinos/Trilinos/pull/4259 led to a discussion about Trilinos versions, deprecation, and the Trilinos release model. I wanted ...*Created by: mhoemmen*
@trilinos/framework @maherou @jwillenbring @bartlettroscoe
PR https://github.com/trilinos/Trilinos/pull/4259 led to a discussion about Trilinos versions, deprecation, and the Trilinos release model. I wanted to summarize that here, and propose the following:
- Drop the official policy (which we haven't followed for years anyway)
- Embrace the current de facto policy (which I'll summarize below)
- Help users write code that works with multiple Trilinos package "versions"
# Official policy
Here is Trilinos' official policy:
1. Minor release every quarter
2. Major release every year
3. Backwards compatibility breaks only at major releases
4. If you want to break an interface, you must deprecate it the last minor release before a major release
When was the last time we did any of this? At least three years? We made a 12.14 release _tag_, but I wouldn't call that a "release" in any sense. @crtrott and I spent a ridiculous effort in Tpetra not to break backwards compatibility when we converted it to use Kokkos 2.0; the utter lack of interest in the release policy post 12.0 makes me feel like that was a waste of time.
# De facto policy
@ikalash, @rrdrake, @theguruat12, @micahahoward, @rppawlo, or @trilinos/framework may wish to chime in, but I would summarize the de facto "Trilinos versioning" policy for many internal applications as follows:
1. App either forks Trilinos, or picks a Trilinos "master" branch commit.
2. App defines its own acceptance testing for Trilinos.
3. When an app wants to update its Trilinos, it uses acceptance tests to decide when to merge / pull.
Many apps facilitate this by testing the app nightly against current master Trilinos.
4. Apps put pressure on Trilinos as needed to support their goals. Individual Trilinos developers use guidance from their managers to prioritize.
This implies that apps define their own "Trilinos versions." Apps actually get work done with this model. That, along with open access to Trilinos' repo on GitHub, likely explains the lack of enthusiasm for official Trilinos releases. I've gotten about as many complains about deprecation warnings ("hey, we can't build warning-free") as I've gotten about actual interface changes, so it's likely less effort just to break the build than it is to do an official deprecation (how long? who knows, since no official releases!).
# Help users write code that works with multiple Trilinos "versions"
What's missing from this model is a way for an app to work correctly with multiple Trilinos package versions at once. For example:
```c++
void my_app_function () {
#if PACKAGE_FOO_VERSION < SOME_MINIMUM
old_foo_function ();
#else
new_foo_function ();
#endif
}
```
A few packages have added this feature themselves. For example, Kokkos has a CMake option and macro to help manage deprecation. Tpetra just recently added this.
# Proposal
I propose the following:
1. Support the current de facto policy (see above).
2. Packages that have enough users to care, should define their own release cycle and policies.
3. Such packages should define macros to enable or disable deprecated code.
4. Such packages should define macros to test the version number in code. Version number can be whatever the package wants, as long as users can test when it increases.
The only packages that would need to opt in, are packages with external users who care about this policy, and whose interfaces change. Kokkos does all of these but (4), and (4) isn't hard (Kokkos has an outstanding issue to implement it).
# Summary
1. Embrace what we're doing now anyway.
2. Packages who care can add their own version macros.
What do y'all think?Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4254Teuchos errors in Werror build2019-02-01T22:24:19ZJames WillenbringTeuchos errors in Werror build*Created by: jwillenbring*
@trilinos/teuchos
@bartlettroscoe @hkthorn @mhoemmen
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labl...*Created by: jwillenbring*
@trilinos/teuchos
@bartlettroscoe @hkthorn @mhoemmen
<!---
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
Teuchos should build warning free as a matter of code quality, and because of important customer requirements. We are currently using the following cxxflags for this build:
`-Wall -ansi -pedantic -Werror -Wno-unknown-pragmas -Wno-narrowing -Wno-pragmas -Wno-delete-non-virtual-dtor`
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently Teuchos has a number of warnings that are promoted to errors in this build as seen [here](https://testing.sandia.gov/cdash/viewBuildError.php?buildid=4448361).
## 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.
-->
We are working to set up dev->master and pull request builds that use these flags for GCC 7.2 to protect the code from the introduction of more warnings. We are starting with some low-level packages as some warnings from these packages have the potential to impact packages downstream in this build.
## 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.
-->
Teuchos builds warning free with the flags above for GCC 7.2.
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
The GitHub Trilinos fork
jwillenbring/Trilinos
has a branch
jwillenbring-PR-Werror-2
that can be merged in to test via submitting a PR. If that is done, only the Teuchos changes should be merged for now (not the PR test definition changes). Alternatively, @jwillenbring can test any proposed solutions if you prefer.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4240Licensing of ML package is unclear2019-01-22T17:25:08ZJames WillenbringLicensing of ML package is unclear*Created by: Multimath*
Hi,
The licensing for the ML package is unclear. At the top of the COPYRIGHT file it claims to be licensed under the LGPL, but afterwards there is a section starting at:
https://github.com/trilinos/Trilinos...*Created by: Multimath*
Hi,
The licensing for the ML package is unclear. At the top of the COPYRIGHT file it claims to be licensed under the LGPL, but afterwards there is a section starting at:
https://github.com/trilinos/Trilinos/blob/4f15e6fb356295d8ba1e022e94d8b0bad732e082/packages/ml/COPYRIGHT#L82
which states: "Commercialization of this product is prohibited without notifying the
Department of Energy (DOE) or Sandia National Laboratory or Lawrence
Livermore National Laboratory (LLNL)."
Adding restrictions to the LGPL changes it to a weird chimeric not-really-open-source license (or maybe even not a license at all, see URL https://opensource.stackexchange.com/a/4985 ); if notification is important to you, I suggest that you change the prohibition to a request which explains the importance (if, for example, funding for the project development/maintenance is allocated based on the extent of such commercialization, I think that most users would comply with notification).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4238Disable Fortran in one of the Trilinos PR builds2019-01-31T20:57:09ZJames WillenbringDisable Fortran in one of the Trilinos PR builds*Created by: bartlettroscoe*
CC: @trilinos/framework, @mhoemmen, @rppawlo, @bathmatt, @jmgate, @fryeguy52
There are several projects that disable Fortran when building Trilinos. Currently, the EMPIRE ATDM Trilinos configuration dis...*Created by: bartlettroscoe*
CC: @trilinos/framework, @mhoemmen, @rppawlo, @bathmatt, @jmgate, @fryeguy52
There are several projects that disable Fortran when building Trilinos. Currently, the EMPIRE ATDM Trilinos configuration disables Fortran. (But that will chance once we fully merge the SPARC and EMPIRE ATDM Trilinos configurations since the SPARC configuration enables Fortran.) The Drekar developers disable Fortran in their configurations (which is not likely to change). Also, many people who build on Macs disable Fortran (since Macs don't come with a Fortran compiler by default).
Therefore, it is important for Trilinos to support a Fortran-less configuration and build. Therefore, at least one of the Trilinos PR builds needs to set `Trilinos_ENABLE_Fortran=OFF`.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4219Elevate ShyLU_Node from ST to PT since it is being used by SPARC?2019-01-26T04:05:03ZJames WillenbringElevate ShyLU_Node from ST to PT since it is being used by SPARC?*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The current SPARC Trilinos configuration explicitly enables `S...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The current SPARC Trilinos configuration explicitly enables `ShyLU_Node` subpackage `ShyLU_NodeHTS` (see [here](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-212?focusedCommentId=25503&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25503). Therefore, ATDM Trilinos builds supporting SPARC are enabling ShyLU_Node, for example, as shown [here](https://testing.sandia.gov/cdash-dev-view/viewConfigure.php?buildid=4427483) showing:
```
...
-- Setting Trilinos_ENABLE_ShyLU_NodeHTS=ON
-- Setting Trilinos_ENABLE_ShyLU_NodeTacho=ON
-- Setting Trilinos_ENABLE_ShyLU_Node=ON
...
Final set of enabled packages: ... ShyLU_Node ... 41
Final set of enabled SE packages: ... ShyLU_NodeHTS ShyLU_NodeTacho ShyLU_Node ... 112
```
So it looks like `ShyLU_NodeTacho` may be getting implicitly enabled by accident. (We will need to see if SPARC actually using `ShyLU_NodeTacho` or not.) But `ShyLU_NodeTacho` is already declared to be `PT` (Primary Tested) but `ShyLU_NodeHTS` is currently declared to be `ST` (Secondary Tested).
In any case, since an important internal Trilinos customer (i.e SPARC) is using `ShyLU_NodeHTS`, [by definition](http://trac.trilinos.org/wiki/TribitsLifecycleModelOverview#test_categories), it needs to be elevated from Secondary Tested (ST) to Primary Tested (PT). Otherwise, `ShyLU_NodeHTS` will not get enabled in Trilinos PR builds and therefore will not protect SPARC (see #2597).
## Proposed Solution
Update the line:
```
HTS hts ST OPTIONAL
```
to be
```
HTS hts PT OPTIONAL
```
in the file
* Trilinos/packages/shylu/shylu_node/cmake/Dependencies.cmake
https://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/4092Framework: recent change affecting commit messages?2018-12-19T19:47:28ZJames WillenbringFramework: recent change affecting commit messages?*Created by: jhux2*
@trilinos/framework
The commit messages, as seen [here](https://github.com/trilinos/Trilinos/commits/develop), have changed over the past day or so. The most recent messages are of the form
`Merge pull reques...*Created by: jhux2*
@trilinos/framework
The commit messages, as seen [here](https://github.com/trilinos/Trilinos/commits/develop), have changed over the past day or so. The most recent messages are of the form
`Merge pull request #XXYY from <some branch>`
Previously, the messages had the first line of the actual commit message, which in my opinion is more helpful.
Is this due to an intentional change in the scripts, or is it perhaps just related to recent PR instabilities?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.