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/5047Framework: Cannot push or pull from github2019-06-08T15:27:25ZJames WillenbringFramework: Cannot push or pull from github*Created by: csiefer2*
csiefer@mymachine> git pull --rebase
You don't exist, go away!
fatal: The remote end hung up unexpectedly
(It worked yesterday, FYI)*Created by: csiefer2*
csiefer@mymachine> git pull --rebase
You don't exist, go away!
fatal: The remote end hung up unexpectedly
(It worked yesterday, FYI)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5027Framework: Installation Testing2019-05-06T16:59:22ZJames WillenbringFramework: Installation Testing*Created by: william76*
## Enhancement
@trilinos/framework
@bartlettroscoe
@jwillenbring
As part of the roadmap towards implementing a backwards compatibility test to the Trilinos testing suite we need to first get Installation...*Created by: william76*
## Enhancement
@trilinos/framework
@bartlettroscoe
@jwillenbring
As part of the roadmap towards implementing a backwards compatibility test to the Trilinos testing suite we need to first get Installation Testing up and running.
This will require some updates to [TriBiTS][1] to support some of the installation testing capabilities that we will need. @bartlettroscoe can fill in more details on what we're needing to do there.
[1]: https://tribits.org/Improve productivity, stability, and quality of Trilinoshttps://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/4809Framework: Non-framework machines no longer able to report to Cdash2019-04-09T23:16:48ZJames WillenbringFramework: Non-framework machines no longer able to report to Cdash*Created by: csiefer2*
And for that matter, the entire Nightly track is gone. SAD!
(Originally noticed by @lucbv)
@trilinos/framework
@trilinos/tpetra This will impact deprecation work after the release if it is not resolved...*Created by: csiefer2*
And for that matter, the entire Nightly track is gone. SAD!
(Originally noticed by @lucbv)
@trilinos/framework
@trilinos/tpetra This will impact deprecation work after the release if it is not resolved by then.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4775Trilinos PR testing missed Ifpack2 compile issue2019-04-01T16:23:52ZJames WillenbringTrilinos PR testing missed Ifpack2 compile issue*Created by: prwolfe*
From issue #4742
> Hmmm, this is short on details, but I just ran into an issue when using a recent master checkout of Trilinos.
>
> Basically lines 2472 and 2478 in the file packages/ifpack2/src/Ifpack2_Blo...*Created by: prwolfe*
From issue #4742
> Hmmm, this is short on details, but I just ran into an issue when using a recent master checkout of Trilinos.
>
> Basically lines 2472 and 2478 in the file packages/ifpack2/src/Ifpack2_BlockTriDiContainer_impl.hpp are using a const instance of a class (Kokkos::TeamPolicy) to call a const function for a non-const instance. Being named a "set" function I tried removing the "const" from the call in Ifpack2_BlockTriDiContainer_impl.hpp and got a clean build.
>
> The $6 question is how did this get through Trilinos testing and how do we fix that. This is a very simple issue which should have been caught early.
>
> _Originally posted by @prwolfe in https://github.com/trilinos/Trilinos/issues/4742#issuecomment-478109186_
>
This issue is to resolve what is missing in the testing and how to resolve that.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4614PR test timeouts preventing PRs from passing2019-03-18T23:29:57ZJames WillenbringPR test timeouts preventing PRs from passing*Created by: ndellingwood*
@trilinos/framework
The following test timeouts have resulted in several PRs failing and requiring re-test:
```
PanzerAdaptersSTK_PoissonInterfaceExample_2d_diffsideids_MPI_1
ROL_example_PDE-OPT_0ld_ad...*Created by: ndellingwood*
@trilinos/framework
The following test timeouts have resulted in several PRs failing and requiring re-test:
```
PanzerAdaptersSTK_PoissonInterfaceExample_2d_diffsideids_MPI_1
ROL_example_PDE-OPT_0ld_adv-diff-react_example_02_MPI_4
ROL_example_PDE-OPT_navier-stokes_example_01_MPI_4
```
Of immediate consequence is that this is preventing PR #4608 from completing and merging in, which will result in any Cuda PR testing that involves Ifpack2 from passing.
The tests timing out above, along with #4608 in some cases which is also unable to complete PR testing due to these tests timing out is preventing PR completion of PRs #4609, #4603, #4604, #4601, #4597, ...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/4600Teuchos: Some CMake checks happen at run time unconditionally; this hinders c...2019-03-19T15:14:17ZJames WillenbringTeuchos: Some CMake checks happen at run time unconditionally; this hinders cross compilation*Created by: mhoemmen*
@trilinos/teuchos @trilinos/framework @theguruat12 @vbrunini @rrdrake
@theguruat12 and I found that `teuchos/CMakeLists.txt` does some checks that involve running code. That's normally OK, except that it's no...*Created by: mhoemmen*
@trilinos/teuchos @trilinos/framework @theguruat12 @vbrunini @rrdrake
@theguruat12 and I found that `teuchos/CMakeLists.txt` does some checks that involve running code. That's normally OK, except that it's not OK for cross compilation. For example, when building KNL-specific binaries on a login node that's not KNL, a lot of tests (like `HAVE_TEUCHOS_BLASFLOAT`) will incorrectly report back false. This will break the build if `Scalar=float` is enabled, which @vbrunini needs.
@theguruat12 and I have prototyped a fix that seems to work. It follows the preexisting Trilinos idiom of letting users set CMake options in advance, if they want to avoid CMake tests that run code. I will submit a PR soon that implements this fix.https://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/4537Amesos2 does not compile with UMFPACK, SuperLU, complex double, and eti=off2019-03-07T21:17:35ZJames WillenbringAmesos2 does not compile with UMFPACK, SuperLU, complex double, and eti=off*Created by: prwolfe*
Basically the compiler cannot chose from 2 convert functions, but does fine the ETI is on as the instantiation gets only one at a time.
@trilinos/amesos2
## Expectations
Amesos2 should build either with or ...*Created by: prwolfe*
Basically the compiler cannot chose from 2 convert functions, but does fine the ETI is on as the instantiation gets only one at a time.
@trilinos/amesos2
## Expectations
Amesos2 should build either with or without ETI on
## Current Behavior
A build matching https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=4650329 but with ETI=off will fail to compile Amesos2_Details_registerLinearSolverFactory.cpp.o because it cannot pick between
packages/amesos2/src/Amesos2_Umfpack_TypeMap.hpp:98:7: error: candidates are: class Teuchos::ValueTypeConversionTraits<TypeTo, std::complex<double> >
class ValueTypeConversionTraits<TypeTo, std::complex<double>>
and
Trilinos/packages/amesos2/src/Amesos2_Superlu_TypeMap.hpp:192:7: error: class Teuchos::ValueTypeConversionTraits<SLU::Z::doublecomplex, TypeFrom>
class ValueTypeConversionTraits<SLU::Z::doublecomplex, TypeFrom>
These take opposite approaches, but can both fulfill the request.
## Motivation and Context
This was found when checking a trilinos build against Sierra. Customers should be able to build either with or without ETI or one options should be disabled.
I am tagging framework as we need to make sure we have a t least one build that covers this at some level (we currently do all builds with ETI=on as far as I can tell.)
## Definition of Done
Amesos2 compiles both with and without ETI and the requested packages available.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4492Framework: Disable the non- dev->master PR tests in the Clean Track2019-02-25T17:28:41ZJames WillenbringFramework: Disable the non- dev->master PR tests in the Clean Track*Created by: william76*
Description
-----------
We've moved the develop -> master pull request jobs to report to the Clean track.
Since we are no longer using the old "Clean" jobs to determine the develop -> master merge, we should...*Created by: william76*
Description
-----------
We've moved the develop -> master pull request jobs to report to the Clean track.
Since we are no longer using the old "Clean" jobs to determine the develop -> master merge, we should remove them from the Clean track.
@jwillenbring I'm assuming you wanted me to remove these tests entirely since they're somewhat redundant with the PR testing for dev->master. If you would rather these be moved to the Nightly track instead, please let me know.
@trilinos/framework FYI
Task(s)
--------
- [x] Remove Linux-gcc-7.3.0-MPI_Release_gcc_7.3.0_openmpi_1.10.1_DEV
- [x] Remove Linux-gcc-4.8.4-MPI_Release_gcc_4.8.4_openmpi_1.10.1_DEV
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/4424Framework: Parameterize CDash Tracks for Pull Request Tests2019-02-25T17:11:05ZJames WillenbringFramework: Parameterize CDash Tracks for Pull Request Tests*Created by: william76*
@trilinos/framework
We discussed parameterizing the PR testing drivers so we can specify in the Jenkins job which track we'd like the tests to go to.
I'm testing this [on my fork][1], but I added a parameter...*Created by: william76*
@trilinos/framework
We discussed parameterizing the PR testing drivers so we can specify in the Jenkins job which track we'd like the tests to go to.
I'm testing this [on my fork][1], but I added a parameter `PULLREQUEST_CDASH_TRACK` which, if set and non-empty will set the `CDASH_TRACK` variable that's used inside the `PullRequestLinuxDriver-Test.sh` script.
I'm running a quick test using my jenkins simulator and it looks like it's working as intended... using '0000' as the PR number, it's showing up in the Clean track [here][2].
### Tasks
- [x] Update `PullRequestLinuxDriver-Test.sh` to take in a parameter for the desired CDash track to report results to.
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_cuda_9.2][3]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_4.8.4][4]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_4.9.3][5]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_4.9.3_SERIAL][6]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_7.2.0][7]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_7.3.0][8]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_intel_17.0.1][9]
- [x] Update PR Driver configuration in the autotester.
FYI: @jwillenbring
[1]: https://github.com/william76/Trilinos/blob/parameterized-pr-cdash-track/cmake/std/PullRequestLinuxDriver-Test.sh#L298-L312
[2]: 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-0000-test&field2=buildstarttime&compare2=84&value2=NOW
[3]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_cuda_9.2/
[4]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_4.8.4/
[5]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_4.9.3/
[6]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_4.9.3_SERIAL/
[7]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_7.2.0/
[8]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_7.3.0/
[9]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_intel_17.0.1/
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4404Switch to C bindings of BLAS & LAPACK?2019-02-15T22:57:28ZJames WillenbringSwitch to C bindings of BLAS & LAPACK?*Created by: mhoemmen*
@trilinos/framework
@mwglass pointed out that:
- Trilinos, kokkos-kernels, Sierra, ATDM, etc. all spent a lot of effort deducing and maintaining Fortran mangling of BLAS and LAPACK, yet
- the BLAS (and...*Created by: mhoemmen*
@trilinos/framework
@mwglass pointed out that:
- Trilinos, kokkos-kernels, Sierra, ATDM, etc. all spent a lot of effort deducing and maintaining Fortran mangling of BLAS and LAPACK, yet
- the BLAS (and even LAPACK)[
http://netlib.org/lapack/#_standard_c_language_apis_for_lapack] come with standard C bindings.
Why don't we all switch to the C bindings? That would get rid of all that mangling deduction code.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/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