Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-01-18T18:43:54Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1830Investigate why windows tests stop submitting2018-01-18T18:43:54ZJames WillenbringInvestigate why windows tests stop submitting*Created by: bmpersc*
@trilinos/framework The windows testing has stopped submitting for no discernible reason. The root cause was that the jenkins process stopped, but there was no indication of why. The method I'd put in place to ensu...*Created by: bmpersc*
@trilinos/framework The windows testing has stopped submitting for no discernible reason. The root cause was that the jenkins process stopped, but there was no indication of why. The method I'd put in place to ensure that the process stays running didn't help here and now seems to no longer exist on the machine. We need to investigate why.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1829Framework: Windows Build Not Posting To Dashboard2017-11-30T00:03:51ZJames WillenbringFramework: Windows Build Not Posting To Dashboard*Created by: csiefer2*
See title*Created by: csiefer2*
See titlehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1823Fill out CONTRIBUTING.md2017-11-08T17:59:06ZJames WillenbringFill out CONTRIBUTING.md*Created by: jmgate*
A the moment, `CONTRIBUTING.md` just has some placeholder text in it. We need to fill it out such that potential contributors understand what is expected when interacting with Trilinos. I can take a crack at this,...*Created by: jmgate*
A the moment, `CONTRIBUTING.md` just has some placeholder text in it. We need to fill it out such that potential contributors understand what is expected when interacting with Trilinos. I can take a crack at this, but I won't be able to start on it till late next week.
@jwillenbring, @bmpersc, any requests as to content?
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1793Running checkin testing script without SANDIA SEMS modules2017-10-10T19:42:47ZJames WillenbringRunning checkin testing script without SANDIA SEMS modules*Created by: searhein*
Is there a way to run the testscript on my laptop, which does not have the SANDIA SEMS modules?*Created by: searhein*
Is there a way to run the testscript on my laptop, which does not have the SANDIA SEMS modules?https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1774"make install" no longer appears to install TrilinosConfig.cmake2017-09-26T17:43:34ZJames Willenbring"make install" no longer appears to install TrilinosConfig.cmake*Created by: etphipp*
It appears to me that "make install" no longer installs TrilinosConfig.cmake in install_path/lib/cmake/Trilinos as it used to. In that directory I only have a file called TrilinosConfigVersion.cmake. Is this inte...*Created by: etphipp*
It appears to me that "make install" no longer installs TrilinosConfig.cmake in install_path/lib/cmake/Trilinos as it used to. In that directory I only have a file called TrilinosConfigVersion.cmake. Is this intentional somehow? How are users of Trilinos supposed to link Trilinos into their application with cmake?https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1761Upgrade minimum required version of CMake to allow for TriBITS refactorings2018-10-27T14:15:18ZJames WillenbringUpgrade minimum required version of CMake to allow for TriBITS refactorings*Created by: bartlettroscoe*
**CC:** @trilinos/framework
## Description
This story is to drive the upgrade of the minimum version of CMake required to configure Trilinos. Currently the minimum version is 2.8.11 which was first t...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
## Description
This story is to drive the upgrade of the minimum version of CMake required to configure Trilinos. Currently the minimum version is 2.8.11 which was first tagged way back May 15, 2013 (i.e. more than 4 years ago). Upgrading the minimum version of CMake will allow us to take advantage of newer CMake features to refactor and simplify a lot of code in TriBITS.
The reason that this issue is being listed in the Trilinos GitHub repo and not the TriBITS repo is that Trilinos is the TriBITS customer that limits the upgrades of CMake. The other projects where TriBITS is used like CASL VERA and ATDM could upgrade CMake much easier (and really could almost track the most current CMake version).
## Tasks
1. Make annoucement to trilinos-users and trilinos-developers to upgrade min version to 3.10 **[Done]**
2. Change all Trilinos jobs posting to CDash to use CMake 3.10+
- Change all SEMS-based modules to use CMake 3.10.3 **[Done]**
- Upgrade the windows builds to use CMake 3.10+ [installed, not tested due to other issues]
- Upgrade ATDM Trilinos builds on 'mutrino' to use CMake 3.10+ ... Merged in PR #3051 **[Done]**
3. Change the minimum version of CMake to 3.10+ in Trilinos/CMakeLists.txt **[Done]**
4. Switch the mode of Trilinos to the all-at-once mode for configure, build, test, and submit **[Done]**
5. Watch for and help address developer and user issues with transition to CMake 3.10+ ... **IN PROGRESS ...**
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1755Tpetra fails to Configure CUDA in Nightly build on Apollo2017-09-30T16:51:42ZJames WillenbringTpetra fails to Configure CUDA in Nightly build on Apollo*Created by: william76*
@trilinos/tpetra
Linux-gcc-4.9.3-MPI_RELEASE_DEV_DownStream_ETI_SERIAL-ON_OPENMP-OFF_PTHREAD-OFF_CUDA-ON_COMPLEX-OFF has been failing the Nightly build since 9/12.
It looks like it's a cmake error on CUD...*Created by: william76*
@trilinos/tpetra
Linux-gcc-4.9.3-MPI_RELEASE_DEV_DownStream_ETI_SERIAL-ON_OPENMP-OFF_PTHREAD-OFF_CUDA-ON_COMPLEX-OFF has been failing the Nightly build since 9/12.
It looks like it's a cmake error on CUDA:
```
Processing enabled package: Epetra (Libs)
Did not find new version of lapack. dggsvd3 is not available.
Processing enabled package: Tpetra (Classic, TSQR, Core, Tests, Examples)
CMake Error at packages/tpetra/CMakeLists.txt:39 (MESSAGE):
If building with CUDA, Tpetra requires that you set
Kokkos_ENABLE_Cuda_Lambda:BOOL=ON, if it is not already ON by default. For
details, please refer to Trilinos issue #1682
(https://github.com/trilinos/Trilinos/issues/1682). You should also make
sure, at least with CUDA_VERSION 7.5 or 8.0, to add
"--expt-extended-lambda" to CMAKE_CXX_FLAGS.
-- Configuring incomplete, errors occurred!
See also "/home/jenkins/slave/workspace/Trilinos_apollo_gcc_4.9.3_cuda_8.0.44/MPI_RELEASE_DEV_DownStream_ETI_SERIAL-ON_OPENMP-OFF_PTHREAD-OFF_CUDA-ON_COMPLEX-OFF/BUILD/CMakeFiles/CMakeOutput.log".
See also "/home/jenkins/slave/workspace/Trilinos_apollo_gcc_4.9.3_cuda_8.0.44/MPI_RELEASE_DEV_DownStream_ETI_SERIAL-ON_OPENMP-OFF_PTHREAD-OFF_CUDA-ON_COMPLEX-OFF/BUILD/CMakeFiles/CMakeError.log".
```
Link to one of the fails:
https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3103572
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1746Set up Trilinos builds to test new all-at-once CMake/CTest/CDash feature2018-11-13T21:44:06ZJames WillenbringSet up Trilinos builds to test new all-at-once CMake/CTest/CDash feature*Created by: bartlettroscoe*
**Next Action Status:**
A single all-at-once build from ceerws1113 been going on for a few weeks. Next: Set up dual submits to testing.sandia.gov/cdash and testing-vm.sandia.gov/cdash/ to help test new s...*Created by: bartlettroscoe*
**Next Action Status:**
A single all-at-once build from ceerws1113 been going on for a few weeks. Next: Set up dual submits to testing.sandia.gov/cdash and testing-vm.sandia.gov/cdash/ to help test new site with lots of data then set up a few more all-at-once builds going to different tracks ...
**CC:** @trilinos/framework
**Description:**
This story is to track effort to set up new automated Trilinos builds to provide data to help test the new all-at-once configure, build, test, and submit feature in CMake/CTest and CDash. For more details, see:
* https://gitlab.kitware.com/snl/project-1/issues/8
* https://gitlab.kitware.com/snl/project-1/issues/33
The detailed evaluation of this version of CMake/CTest and CDash will take place in https://gitlab.kitware.com/snl/project-1/issues/33.xhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1737md5 checksum changed for 12.10.12017-09-21T15:53:17ZJames Willenbringmd5 checksum changed for 12.10.1*Created by: davydden*
just noticed that `md5` checksum changed for https://github.com/trilinos/Trilinos/archive/trilinos-release-12-10-1.tar.gz from `40f28628b63310f9bd17c26d9ebe32b1` to `667333dbd7c0f031d47d7c5511fd0810`. Can you plea...*Created by: davydden*
just noticed that `md5` checksum changed for https://github.com/trilinos/Trilinos/archive/trilinos-release-12-10-1.tar.gz from `40f28628b63310f9bd17c26d9ebe32b1` to `667333dbd7c0f031d47d7c5511fd0810`. Can you please confirm that this is a desired change and the tarball was not compromized.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1645Dashboard failures, possibly due to incorrectly configured test platform2017-10-27T04:18:34ZJames WillenbringDashboard failures, possibly due to incorrectly configured test platform*Created by: mhoemmen*
@trilinos/framework @trilinos/tpetra
ascic141, build name `Linux-gcc-4.9.3-Sierra_MPI_release_DEV_ETI_SERIAL-ON_OPENMP-OFF_PTHREAD-ON_CUDA-OFF_COMPLEX-ON`, has 21 Tpetra test failures. Here is the latest list...*Created by: mhoemmen*
@trilinos/framework @trilinos/tpetra
ascic141, build name `Linux-gcc-4.9.3-Sierra_MPI_release_DEV_ETI_SERIAL-ON_OPENMP-OFF_PTHREAD-ON_CUDA-OFF_COMPLEX-ON`, has 21 Tpetra test failures. Here is the latest list:
https://testing.sandia.gov/cdash/viewTest.php?onlyfailed&buildid=3072459
They all generate the following output:
```
p=0: *** Caught standard std::exception of type 'std::runtime_error' :
Constructing View and initializing data with uninitialized execution space
Traceback functionality not available
```
I was wondering at first whether the tests were using the default execution space instead of their Node's execution space. However, check out the following failing test output:
https://testing.sandia.gov/cdash/testDetails.php?test=40862107&build=3072459
This is supposed to be for the default Node, yet the test is failing. It looks like this could be a broken configuration.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1628CUDA config & build are broken2017-08-21T00:44:24ZJames WillenbringCUDA config & build are broken*Created by: mhoemmen*
@trilinos/framework
I'm not sure if this is a Kokkos (@crtrott, @dsunder, @ibaned ) issue, a Trilinos issue, or a SEMS issue (@jgfouca), but something recently (as of last week) totally messed up CUDA builds f...*Created by: mhoemmen*
@trilinos/framework
I'm not sure if this is a Kokkos (@crtrott, @dsunder, @ibaned ) issue, a Trilinos issue, or a SEMS issue (@jgfouca), but something recently (as of last week) totally messed up CUDA builds for me. This is blocking #1569, #1606, #1367, #1623, and a bunch of other issues. It is delaying testing and acceptance of @tjfulle 's and @brian-kelley 's hard work.
When I run `make`, I get this (replace `...` here and elsewhere with the path to Trilinos' source directory):
```
[ 0%] Building CXX object packages/kokkos/core/src/CMakeFiles/kokkoscore.dir/impl/Kokkos_hwloc.cpp.o
cd .../../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/packages/kokkos/core/src && /projects/sems/install/rhel6-x86_64/sems/compiler/gcc/5.3.0/base/bin/g++ -Dkokkoscore_EXPORTS -pedantic -Wall -Wno-long-long -Wwrite-strings -Wall -std=c++11 -expt-extended-lambda -std=c++11 -fopenmp -g -O0 -fPIC -I/scratch/prj/Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL -I.../../Trilinos/CHECKIN-CUDA-8.0/MPI_DEBUG_REAL/packages/kokkos/core/src -I.../Trilinos/packages/kokkos/core/src -I/projects/sems/install/rhel6-x86_64/kokkos/compiler/cuda/8.0.44/include -o CMakeFiles/kokkoscore.dir/impl/Kokkos_hwloc.cpp.o -c .../Trilinos/packages/kokkos/core/src/impl/Kokkos_hwloc.cpp
In file included from .../Trilinos/packages/kokkos/core/src/impl/Kokkos_hwloc.cpp:50:0:
.../Trilinos/packages/kokkos/core/src/Kokkos_Macros.hpp:170:40: error: ‘__device__’ does not name a type
#define KOKKOS_INLINE_FUNCTION __device__ __host__ inline
^
.../Trilinos/packages/kokkos/core/src/impl/Kokkos_Error.hpp:73:1: note: in expansion of macro ‘KOKKOS_INLINE_FUNCTION’
KOKKOS_INLINE_FUNCTION
^
```
Notice that it's running `g++` directly, not `nvcc` or `mpicxx` or anything like that. I am using the SEMS modules on my workstation, `artemis`. Here is the list of loaded modules:
```
$ module list
Currently Loaded Modulefiles:
1) sems-env 3) sems-cmake/3.3.2 5) kokkos-cuda/8.0.44
2) kokkos-env 4) sems-gcc/5.3.0 6) kokkos-openmpi/2.0.1/cuda
```
Here is the output of `nvcc --version`:
```
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2016 NVIDIA Corporation
Built on Sun_Sep__4_22:14:01_CDT_2016
Cuda compilation tools, release 8.0, V8.0.44
```
Here is the output of `echo $OMPI_CXX`:
```
.../Trilinos/packages/kokkos/config/nvcc_wrapper
```
Here is the output of `mpicxx --version`:
```
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2016 NVIDIA Corporation
Built on Sun_Sep__4_22:14:01_CDT_2016
Cuda compilation tools, release 8.0, V8.0.44
```
Here are my relevant CMake options:
```
-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON
-D BUILD_SHARED_LIBS:BOOL=ON
-D Trilinos_ENABLE_OpenMP:BOOL=ON
-D Trilinos_SHOW_DEPRECATED_WARNINGS:BOOL=ON
-D Trilinos_ENABLE_Fortran:BOOL=OFF
-D CMAKE_VERBOSE_MAKEFILE:BOOL=ON
-D CMAKE_Fortran_LINK_EXECUTABLE:FILEPATH=""
-D TPL_ENABLE_CUDA:BOOL=ON
-D Kokkos_ENABLE_Cuda_UVM:BOOL=ON
-D Tpetra_INST_CUDA:BOOL=ON
-D Kokkos_ENABLE_Cuda_Lambda:BOOL=ON
-D Kokkos_ENABLE_CXX11_DISPATCH_LAMBDA:BOOL=ON
-D CMAKE_CXX_FLAGS:STRING="-Wall -std=c++11 -expt-extended-lambda"
-D CMAKE_BUILD_TYPE:STRING=DEBUG
-D Kokkos_ENABLE_DEBUG:BOOL=ON
-D Teuchos_ENABLE_DEBUG:BOOL=ON
-D CMAKE_CXX_FLAGS_DEBUG:STRING="-Os"
-D Tpetra_INST_SERIAL:BOOL=OFF
-D Teuchos_ENABLE_COMPLEX:BOOL=OFF
-D Trilinos_ENABLE_COMPLEX_FLOAT:BOOL=OFF
-D Trilinos_ENABLE_COMPLEX_DOUBLE:BOOL=OFF
```
I have the same trouble with my CUDA 7.5 build. Thus, this issue also hinders #1278, because we are supposed to keep supporting CUDA 7.5 until at least the next minor release.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1600Ifpack2 tests broken in standrd CI build starting 8/11/20172017-08-30T20:00:08ZJames WillenbringIfpack2 tests broken in standrd CI build starting 8/11/2017*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/intrepid2, @kyungjoo-kim
**Description:**
The package Intrepid2 is now showing a build failure in the CI build with the first breaking CI iteration yesterday sho...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/intrepid2, @kyungjoo-kim
**Description:**
The package Intrepid2 is now showing a build failure in the CI build with the first breaking CI iteration yesterday shown at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=3050255
The build failures shown at:
* https://testing.sandia.gov/cdash/viewBuildError.php?buildid=3050256
show:
```
/scratch/rabartl/Trilinos.base/SEMSCIBuild/Trilinos/packages/intrepid2/refactor/unit-test/Orientation/Serial/test_orientationtools_coeff_matrix.cpp:54:54: fatal error: test_orientationtools_tet_coeff_matrix.hpp: No such file or directory
#include "test_orientationtools_tet_coeff_matrix.hpp"
^
compilation terminated.
```
Looking at the new commits pulled for this CI iteration at:
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3050256##note0
we see that the following commits have caused this break:
```
70c425a: Intrepid2 - tested with triangle hcurl and hdiv
Author: Kyungjoo Kim <kyukim@sandia.gov>
Date: Fri Aug 11 15:18:41 2017 -0600
M packages/intrepid2/refactor/src/Orientation/Intrepid2_OrientationTools.hpp
M packages/intrepid2/refactor/src/Orientation/Intrepid2_OrientationToolsDefMatrixData.hpp
M packages/intrepid2/refactor/unit-test/Orientation/Serial/test_orientationtools_coeff_matrix.cpp
M packages/intrepid2/refactor/unit-test/Orientation/test_orientationtools_hex_coeff_matrix.hpp
M packages/intrepid2/refactor/unit-test/Orientation/test_orientationtools_quad_coeff_matrix.hpp
M packages/intrepid2/refactor/unit-test/Orientation/test_orientationtools_tri_coeff_matrix.hpp
d9897aa: Intrepid2 - hcurl and hdiv of triangle and tet always requires orientation
Author: Kyungjoo Kim <kyukim@sandia.gov>
Date: Fri Aug 11 15:17:24 2017 -0600
M packages/intrepid2/refactor/src/Discretization/Basis/Intrepid2_HCURL_TET_In_FEM.hpp
M packages/intrepid2/refactor/src/Discretization/Basis/Intrepid2_HCURL_TET_In_FEMDef.hpp
M packages/intrepid2/refactor/src/Discretization/Basis/Intrepid2_HCURL_TRI_In_FEM.hpp
M packages/intrepid2/refactor/src/Discretization/Basis/Intrepid2_HDIV_TET_In_FEM.hpp
M packages/intrepid2/refactor/src/Discretization/Basis/Intrepid2_HDIV_TRI_In_FEM.hpp
98561e5: Intrepid2 - triangle hcurl and hdiv orientation setup tested
Author: Kyungjoo Kim <kyukim@sandia.gov>
Date: Fri Aug 11 13:38:24 2017 -0600
M packages/intrepid2/refactor/src/Orientation/Intrepid2_OrientationToolsDefCoeffMatrix_HCURL.hpp
M packages/intrepid2/refactor/src/Orientation/Intrepid2_OrientationToolsDefCoeffMatrix_HDIV.hpp
M packages/intrepid2/refactor/unit-test/Orientation/Serial/test_orientationtools_coeff_matrix.cpp
M packages/intrepid2/refactor/unit-test/Orientation/test_orientationtools_tri_coeff_matrix.hpp
```
Looking at the push log for Trilinos we see the push:
```
Fri Aug 11 15:20:17 MDT 2017
commit 70c425ab810664a6470bc02d4e0c58ed15b130c4
Author: Kyungjoo Kim <kyukim@sandia.gov>
AuthorDate: Fri Aug 11 15:18:41 2017 -0600
Commit: Kyungjoo Kim <kyukim@sandia.gov>
CommitDate: Fri Aug 11 15:18:41 2017 -0600
Intrepid2 - tested with triangle hcurl and hdiv
Commits pushed:
70c425a Intrepid2 - tested with triangle hcurl and hdiv
d9897aa Intrepid2 - hcurl and hdiv of triangle and tet always requires orientation
98561e5 Intrepid2 - triangle hcurl and hdiv orientation setup tested
```
As you can see from that push log, there is no evidence that the [checkin-test-sems.sh](https://github.com/trilinos/Trilinos/wiki/Policies-|-Safe-Checkin-Testing) script was used to test and push this change.
This is just a test failure, and not a library failure. However, anyone trying to use the checkin-test-sems.sh script to push changes to any of the following packages upstream from Ifpack2 will have their push stopped due to this failing test build:
* Kokkos Teuchos KokkosKernels RTOp Sacado Epetra Shards Triutils Tpetra TrilinosSS EpetraExt Thyra Xpetra Galeri Amesos Pamgen
Therefore, this needs to be fixed ASAP or this test needs to be disabled so that it does not stop other people's pushes.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1583Issue and Pull Request Templates?2017-11-08T20:43:02ZJames WillenbringIssue and Pull Request Templates?*Created by: jmgate*
@trilinos/framework, has Trilinos ever considered adding `ISSUE_TEMPLATE.md` and `PULL_REQUEST_TEMPLATE.md` files to the repository to attempt to standardize the information we get in an issue or pull request? If y...*Created by: jmgate*
@trilinos/framework, has Trilinos ever considered adding `ISSUE_TEMPLATE.md` and `PULL_REQUEST_TEMPLATE.md` files to the repository to attempt to standardize the information we get in an issue or pull request? If you like, I can mock some up (I have for GitLab, [here](https://gitlab.sandia.gov/jmgate/testingTemplates)), but it occurred to me that this may have come up before and was decided against for some reason.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1571Add a CMake option & test for whether MPI is CUDA aware2017-08-14T18:54:33ZJames WillenbringAdd a CMake option & test for whether MPI is CUDA aware*Created by: mhoemmen*
@trilinos/tpetra @trilinos/framework
Add a CMake option, and a configure-time test, for whether MPI is CUDA aware (edited 13 Aug 2017 from "MPI supports CUDA"). "MPI is CUDA aware" (edited 13 Aug 2017 from "M...*Created by: mhoemmen*
@trilinos/tpetra @trilinos/framework
Add a CMake option, and a configure-time test, for whether MPI is CUDA aware (edited 13 Aug 2017 from "MPI supports CUDA"). "MPI is CUDA aware" (edited 13 Aug 2017 from "MPI supports CUDA") means that the MPI implementation knows how to read from and write to CUDA buffers, that is, memory allocated using `cudaMalloc` (in Kokkos, a View with memory space `Kokkos::CudaSpace`). See #1088 for justification and discussion.
OpenMPI provides a command-line test as of 1.7.3:
```
$ ompi_info --parsable --all | grep mpi_built_with_cuda_support:value
mca:mpi:base:param:mpi_built_with_cuda_support:value:true
```
and an API as of 2.0.0: https://www.open-mpi.org/faq/?category=runcuda#mpi-cuda-aware-support
We need a CMake option as well as a test, in order to support cross-compilation. Otherwise, users building on a different platform than where they plan to run would have no way to tell Trilinos that the MPI implementation on which they plan to run is CUDA aware (edited 13 Aug 2017: "supports CUDA").https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1517Create 12.12 release2018-01-24T18:24:27ZJames WillenbringCreate 12.12 release*Created by: bmpersc*
Following checklist below and updating as needed:
'''
rev 2016/07
Creating a New Trilinos (Release) Branch with GIT
Note: these instructions have been updated to use gitdist from the copy of
tribits insi...*Created by: bmpersc*
Following checklist below and updating as needed:
'''
rev 2016/07
Creating a New Trilinos (Release) Branch with GIT
Note: these instructions have been updated to use gitdist from the copy of
tribits inside of the Trilinos repo. All of the commands assume that you will
need the full path to gitdist, however, if you have setup your PATH or an alias
that may be unnecessary. Also, as of the time of this writing, there is a known
issue with gitdist that it ignores optika. It is assumed this is a bug and the
commands for Optika have been omitted. If this issue persists and Optika is still
released you will need to cd into packages/optika and run most of these commands
by hand there, replacing gitdist with git.
A GIT branch can be used to maintain a version of the code that is different
than the primary development branch. This process describes how to create a
Trilinos release branch, but the steps can easily be generalized to apply to
other types of branches. There are eight steps in creating a Trilinos release
branch:
Clone Trilinos
You need to be in a clean state in order to branch Trilinos. It is best if you
start from a fresh clone, but any repository that is up-to-date and in a clean
state (no modified/untracked/etc files) can be used. This does mean that you can
not make changes and have them apply to the branch unless you have commited them
first. You will also need to clone each of the external repos that we release.
These repos will need to be cloned into the packages directory.
The list of external projects as of 1/12/2016 is:
CTrilinos
ForTrilinos
mesquite
moocho
optika
Sundance
To clone a copy of Trilinos type:
Command: git clone git@github.com:trilinos/Trilinos
cd Trilinos
./clone_extra_repos.py --not-extra-repos=preCopyrightTrilinos
Despite the default for clone_extra_repos.py being "Nightly" it apparently always
clones preCopyright unless told not to.
Tag the working copy
The existing branch is now tagged to mark the point where the new branch will
diverge. This will need to be done for every external repository as well as the
Trilinos repository. To do this, from anywhere in your clone type
Command: cmake/tribits/python_utils/gitdist tag -a -m ""
For a release branch, tag name should be root-of-trilinos-release-XYZ-branch,
where XYZ is the release number with the component numbers separated by hyphens
instead of periods. For example for release 3.1.13, XYZ should be 3-1-13.
Create a branch
To create a branch, from anywhere in your clone type
Command: cmake/tribits/python_utils/gitdist branch
For the Trilinos release version XYZ mentioned above, the branch name should be
trilinos-release-XYZ-branch.
Update to convert the working copy to the new branch
The act of creating a new branch does not change the existing working copy to
a that branch. To make this switch type
Command: cmake/tribits/python_utils/gitdist checkout
To verify that the preceding command was successful, type
Command: cmake/tribits/python_utils/gitdist branch
The branch you are on will have a '*' infront of it.
Updates to make to the code when branching
When creating a new Trilinos release branch, the Trilinos version number needs
to be updated in the Trilinos/Version.cmake file. The values for
Trilinos_MAJOR_VERSION, Trilinos_MAJOR_MINOR_VERSION, Trilinos_VERSION_STRING,
and Trilinos_VERSION need to be updated. Also the Trilinos_REPOSITORY_BRANCH
will need to be set to the correct branch name and Trilinos_TESTING_TRACK will
need to be set to the correct cdash track. As well as
${PROJECT_NAME}_ENABLE_DEVELOPMENT_MODE will need to be set to OFF. This file
also needs to be updated on the master branch, However only the version numbers
should be changed to reflect the new development version.
Finally, git commit the changes. In the commit message, note that branch name
is listed.
Tag the new branch
It is a good idea to tag the branch at this point so that the initial state of
the branch is easily retrievable. To perform this step, type
Command: cmake/tribits/python_utils/gitdist tag -a -m ""
For the Trilinos release version XYZ mentioned above, the initial tag name
should be initial-trilinos-release-XYZ-branch.
Make the branch and tags public
At this point none of these changes, tags or the branch will be publicly
available we need to push them to the public repository, which should be origin.
There is a special way that you have to push branches to the public repository.
To push the branch type
Command: cmake/tribits/python_utils/gitdist push -u origin :
This will push the branch named and the new commits on it
from your clone to origin with the name . Note that you can
rename the branch by giving a different name for , but
recommend not doing this unless you need to fix the name of the branch for some
reason.
Tags are easier to push, you can push them one at a time like the branch, but it
is easier to push all of them at once. To push the tags type
Command: cmake/tribits/python_utils/gitdist push --tags
Test the new branch
It is a good idea to test the new branch to help make sure that the above
process has been completed properly. As a part of the general release process,
many tests need to be run. This step simply refers to running a few simple
sanity checks (for example, build a few Trilinos packages and run ctest for
those packages) to work out any obvious problems before the branch is subjected
to the more complete test suite.
Reference on related git commands:
When you clone Trilinos you get a copy of every branch and tag that is on the
public repository. However, you do not have a local copy of the branch (unless
you used eg to clone) until you set it up. To checkout a different branch of
Trilinos, from the repository you just cloned type
Command: git checkout --track origin/
This will create a local branch for the given branch and check it out for you.
In addition any changes made to this branch will be pushed back to the correct
branch on origin when you push. This is what is called a tracking branch. Once
you have created a local tracking copy of a branch you won't have to do it again
in the same clone. Instead if you want to go to a different branch, back to
master for instance, and want to checkout the branch again you only need to type
command: git checkout
Tags, like branches, are all copied to your local repository when you clone.
Checking out a tag is similar to checking out a branch, but since tags only
point to a specific commit you do not need to create a local copy of the tag,
you only need to type
command: git checkout
'''https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1493Change many `Trilinos_` to `${PROJECT_NAME}_` references to proejct-level Tri...2017-07-21T00:22:22ZJames WillenbringChange many `Trilinos_` to `${PROJECT_NAME}_` references to proejct-level TriBITS vars so that meta builds with Trilinos work*Created by: jmgate*
Ran into this issue in @trilinos/sacado's `CMakeLists.txt` file:
```
TRIBITS_ADD_OPTION_AND_DEFINE(
Sacado_ENABLE_CXX11
HAVE_SACADO_CXX11
"Enable C++11 support in Sacado."
"${Trilinos_ENABLE_CXX11}"
...*Created by: jmgate*
Ran into this issue in @trilinos/sacado's `CMakeLists.txt` file:
```
TRIBITS_ADD_OPTION_AND_DEFINE(
Sacado_ENABLE_CXX11
HAVE_SACADO_CXX11
"Enable C++11 support in Sacado."
"${Trilinos_ENABLE_CXX11}"
)
```
When configuring without passing `-D Trilinos_ENABLE_CXX11:BOOL=ON`, `Sacado_ENABLE_CXX11` apparently gets set to `OFF`. I thought `Trilinos_ENABLE_CXX11` was supposed to be `ON` by default. In `Trilinos/CMakeLists.txt`, I see
```
SET(Trilinos_ENABLE_CXX11_DEFAULT ON)
```
but it doesn't look like `Trilinos_ENABLE_CXX11_DEFAULT` is used anywhere else in the project, though a handful of packages *do* look for `Trilinos_ENABLE_CXX11`.
**First question:** @trilinos/framework, should `_DEFAULT` be removed from that line in `Trilinos/CMakeLists.txt`?
**Next question:** Should packages (@trilinos/sacado and @trilinos/stokhos look to be the only ones I can find) switch `Trilinos_ENABLE_CXX11` to `${PROJECT_NAME}_ENABLE_CXX11`, along the lines of #1488?
**Final Question:** I'm configuring Trilinos as part of a larger meta-project, where I have `-D ${metaProjectName}_ENABLE_CXX11:BOOL=ON`. Is there perhaps a step I missed such that `Trilinos_ENABLE_CXX11` gets set to `${metaProjectName}_ENABLE_CXX11`?https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1482SEACASAprepro_lib_aprepro_lib_unit_test Not Run2017-08-22T19:10:58ZJames WillenbringSEACASAprepro_lib_aprepro_lib_unit_test Not Run*Created by: ibaned*
Hello, I was running the `checkin_test_sems` script for a very trivial change and it failed because the test `SEACASAprepro_lib_aprepro_lib_unit_test` did not run. Any ideas why that might be? I made no CMake change...*Created by: ibaned*
Hello, I was running the `checkin_test_sems` script for a very trivial change and it failed because the test `SEACASAprepro_lib_aprepro_lib_unit_test` did not run. Any ideas why that might be? I made no CMake changes whatsoever, only MueLu source files changed (see #1479 )
```
FAILED: Trilinos/MPI_RELEASE_DEBUG_SHARED_PT: passed=422,notpassed=1
Fri Jul 7 18:17:11 MDT 2017
Enabled Packages: MueLu
Disabled Packages: PyTrilinos,Claps,TriKota
Enabled all Forward Packages
Hostname: ceerws1113
Source Dir: /scratch/daibane/Trilinos/cmake/tribits/ci_support/../../..
Build Dir: /scratch/daibane/Trilinos/CHECKIN/MPI_RELEASE_DEBUG_SHARED_PT
CMake Cache Varibles: -DTrilinos_TRIBITS_DIR:PATH=/scratch/daibane/Trilinos/cmake/tribits -DTrilinos_ENABLE_TESTS:BOOL=ON -DTrilinos_TEST_CATEGORIES:STRING=BASIC -DTrilinos_ALLOW_NO_PACKAGES:BOOL=OFF -DDART_TESTING_TIMEOUT:STRING=300.0 -DBUILD_SHARED_LIBS=ON -DTrilinos_DISABLE_ENABLED_FORWARD_DEP_PACKAGES=ON -DTrilinos_TRACE_ADD_TEST=ON -DTrilinos_ENABLE_SECONDARY_TESTED_CODE:BOOL=OFF -DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/MpiReleaseDebugSharedPtSettings.cmake,cmake/std/BasicCiTestingSettings.cmake -DTrilinos_ENABLE_MueLu:BOOL=ON -DTrilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=ON -DTrilinos_ENABLE_ALL_FORWARD_DEP_PACKAGES:BOOL=ON -DTrilinos_ENABLE_PyTrilinos:BOOL=OFF -DTrilinos_ENABLE_Claps:BOOL=OFF -DTrilinos_ENABLE_TriKota:BOOL=OFF
Make Options: -j10
CTest Options: -j5
Pull: Passed (0.00 min)
Configure: Passed (1.33 min)
Build: Passed (104.14 min)
Test: FAILED (18.63 min)
99% tests passed, 1 tests failed out of 423
Label Time Summary:
MueLu = 327.52 sec (56 tests)
Panzer = 307.62 sec (129 tests)
Piro = 31.64 sec (12 tests)
ROL = 1007.75 sec (133 tests)
SEACAS = 0.21 sec (2 tests)
Stokhos = 107.68 sec (75 tests)
TrilinosCouplings = 47.16 sec (19 tests)
Total Test time (real) = 1117.85 sec
The following tests FAILED:
1 - SEACASAprepro_lib_aprepro_lib_unit_test (Not Run)
Errors while running CTest
Total time for MPI_RELEASE_DEBUG_SHARED_PT = 124.11 min
```
@trilinos/framework @trilinos/seacashttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1467Inconsistent gcc version load by configure and load_sems_dev_env.sh2017-06-30T17:20:41ZJames WillenbringInconsistent gcc version load by configure and load_sems_dev_env.sh*Created by: lucbv*
@bartlettroscoe
I am having some issues this morning with the different compiler versions loaded by various trilinos script.
When I load the sems-environment with:
```source cmake/load_sems_dev_env.sh```
it sets...*Created by: lucbv*
@bartlettroscoe
I am having some issues this morning with the different compiler versions loaded by various trilinos script.
When I load the sems-environment with:
```source cmake/load_sems_dev_env.sh```
it sets the compiler to gcc-4.8.4
However after I run my configure script, in which I do not set the compiler since I rely on cmake to detect it, here is what my environment looks like:
```
Currently Loaded Modulefiles:
1) sems-env 4) sems-git/2.10.1 7) sems-boost/1.63.0/base 10) sems-hdf5/1.8.12/parallel 13) sems-superlu/4.3/base
2) sems-python/2.7.9 5) sems-gcc/4.9.3 8) sems-yaml_cpp/0.5.3/base 11) sems-netcdf/4.3.2/parallel
3) sems-cmake/3.5.2 6) sems-openmpi/1.6.5 9) sems-zlib/1.2.8/base 12) sems-parmetis/4.0.3/parallel
```
Finally I get this type of warning when I compile:
```/projects/sems/install/rhel7-x86_64/sems/compiler/gcc/4.8.5/openmpi/1.6.5/include/mpi_portable_platform.h:374:63: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]```
which reports gcc-4.8.5 as compiler?
I am attaching my configure script in case it yields any clues.
[configure_trilinos.sh.txt](https://github.com/trilinos/Trilinos/files/1115771/configure_trilinos.sh.txt)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1453Change standard pre-push and post-push CI build from GCC 4.9.3 to 4.8.42018-04-06T00:51:56ZJames WillenbringChange standard pre-push and post-push CI build from GCC 4.9.3 to 4.8.4*Created by: bartlettroscoe*
**Related Issues:** #1341, #1363, #1390, #482
**CC:** @trilinos/framework
**Description:**
This story is to downgrade the standard CI build of Trilinos from GCC 4.9.3 to GCC 4.8.4. The reasons for...*Created by: bartlettroscoe*
**Related Issues:** #1341, #1363, #1390, #482
**CC:** @trilinos/framework
**Description:**
This story is to downgrade the standard CI build of Trilinos from GCC 4.9.3 to GCC 4.8.4. The reasons for doing this are numerous:
1) There are still platforms where GCC 4.9.3 is not available but GCC 4.8.4 is present that need C++11 builds of Trilinos (see #1363). (Therefore, we need to protect the GCC 4.8.4 build of Trilinos and the best way to do that is with the CI build.)
2) GCC 4.8.4 is the native GCC compiler on the SNL COE RHEL 7. (Therefore, customers like Xyce should have no problem delivering to customers on standard SNL COE RHEL 7 systems that require broad deployment at SNL., see #1390.)
3) GCC 4.8.4 provides full support for C++11 language features and works with CUDA 7.5 (but not the full C++11 standard library, see #1363 ). (Therefore, Kokkos and Tpetra developers should not be constrained on what C++11 language features they use any more than they would with GCC 4.9.3.)
4) GCC 4.8.4 seems to be a good stand-in for GCC 4.9.3 (i.e. we don’t seem to see many failures on one that are not reported on the other). (Therefore, if the CI build passes with GCC 4.8.4 is will also likely pass with GCC 4.9.3 which is important for Sierra)
5) GCC 4.8.4 does not generate warnings for OpenMPI 1.6.5 header files the way that GCC 4.9.3 does (see #1341). (Which will help us remove the rest of the warnings being generated by Trilinos so we can add -Werror for this build which will help in upgrading Trilinos to Sierra and other customers which require clean -Werror builds.)
6) The SEMS env provides a full GCC 4.8.4 stack on SNL COE RHEL 6 as well. (Therefore, developers can continue to test and push to Trilinos ‘develop’ on both RHEL 6 or RHEL 7 machines.)
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1449Teko build failure in CI build starting 6/22/20172017-06-23T12:56:44ZJames WillenbringTeko build failure in CI build starting 6/22/2017*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teko
**Description:**
There is a new Teko build failure in the standard CI build `Linux-GCC-4.9.3-MPI_RELEASE_DEBUG_SHARED_PT_CI` that showed up this morning in ...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teko
**Description:**
There is a new Teko build failure in the standard CI build `Linux-GCC-4.9.3-MPI_RELEASE_DEBUG_SHARED_PT_CI` that showed up this morning in the first CI build:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2961386
Looking at the build failure details at:
* https://testing.sandia.gov/cdash/viewBuildError.php?buildid=2961631
we see:
```
Error copying file "/scratch/rabartl/Trilinos.base/SEMSCIBuild/Trilinos/packages/teko/tests/data/lsc_B_2.mm" to "/scratch/rabartl/Trilinos.base/SEMSCIBuild/BUILD/packages/teko/tests/data/lsc_B_2.mm".
```
Somehow, no Teko test failed. There were no commits to the Teko package pulled in this CI iteration shown at:
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=2961631##note1
that would explain these failures.
The failure looks to be due to a race condition in two targets that are copying these files as shown in the file:
Trilinos/packages/teko/tests/CMakeLists.txt
which shows:
```
SET(TEST_DRIVER_DATA_FILES
lsc_B_2.mm
...
)
...
TRIBITS_COPY_FILES_TO_BINARY_DIR(testdriver_copyfiles
SOURCE_FILES ${TEST_DRIVER_DATA_FILES}
SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/data"
DEST_DIR "${CMAKE_CURRENT_BINARY_DIR}/data"
EXEDEPS testdriver
)
TRIBITS_COPY_FILES_TO_BINARY_DIR(testdriver_tpetra_copyfiles
SOURCE_FILES ${TEST_DRIVER_DATA_FILES}
SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/data"
DEST_DIR "${CMAKE_CURRENT_BINARY_DIR}/data"
EXEDEPS testdriver_tpetra
)
```
The problem is that you have two separate targets that are copying the same files. That is asking for a disk copy conflict with two processes trying to copy the same files to the same location.
That explains why the copy of this file failed but the tests still pass. It is because one of the targets copied the file correctly and therefore the tests were allowed to run.