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/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/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/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/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/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
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/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/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/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/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/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 Trilinos