Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-11-08T16:41:56Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3625Framework: Separate merge from test execution in PullRequestLinuxDriver.sh2018-11-08T16:41:56ZJames WillenbringFramework: Separate merge from test execution in PullRequestLinuxDriver.sh*Created by: william76*
@trilinos/framework
Currently, if `cmake/std/PullRequestLinuxDriver.sh` is modified it might not work properly for the Develop->to->Master if the script has been changed since the 'version' of the script bein...*Created by: william76*
@trilinos/framework
Currently, if `cmake/std/PullRequestLinuxDriver.sh` is modified it might not work properly for the Develop->to->Master if the script has been changed since the 'version' of the script being run will be the one that exists on master. If the change adds a new test, the dev->to->master test will fail because the if-then-else statement comparing job names for the new job won't exist in this piece:
```bash
if [ "Trilinos_pullrequest_gcc_4.8.4" == "${JOB_BASE_NAME:?}" ] ; then
source ${TRILINOS_DRIVER_SRC_DIR}/cmake/std/sems/PullRequestGCC4.8.4TestingEnv.sh
ierror=$?
if [[ $ierror != 0 ]]; then
echo "There was an issue loading the gcc environment. The error code was: $ierror"
exit $ierror
fi
elif [ ... ]
# other tests...
else
ierror=42
echo "There was an issue loading the proper environment. The error code was: $ierror"
exit $ierror
fi
```
In the case where an additional entry to this switch statement is made and is on the develop branch but not on the master branch, the script will fail because Jenkins is running the version of the script that lives on master because the script performs the merge of the test branch into master.
As part of a revamp of the PR driver script(s), we should split out the part of the script that merges the test branch into the master branch from the rest so that we can merge the develop branch into master separately from testing it within the Jenkins test.
@jwillenbring I didn't spend a ton of time writing this issue up... did I miss anything?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3611Sundance no longer configures with updated Trilinos and TriBITS2018-11-13T16:02:19ZJames WillenbringSundance no longer configures with updated Trilinos and TriBITS*Created by: bartlettroscoe*
@trilinos/framework
The package Sundance stored in the extra repo https://github.com/trilinos/Sundance does not configure with the current version of Trilinos 'develop'. The only automated Trilinos build...*Created by: bartlettroscoe*
@trilinos/framework
The package Sundance stored in the extra repo https://github.com/trilinos/Sundance does not configure with the current version of Trilinos 'develop'. The only automated Trilinos build that actually pulls in Sundance is the build `Linux-GCC-4.9.3-openmpi-1.8.7_Debug_DEV_Werror` posting the the "Experimental" CDash group shown today at:
* https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&parentid=4038223
In this build, Sundance fails to configure showing the configure failure [here](https://testing.sandia.gov/cdash-dev-view/viewConfigure.php?buildid=4042789) which shows the configure failure:
```
Processing enabled package: Sundance (Libs, Tests, Examples)
adding Playa/src
-- DEPLIBS=''
adding Playa/tests
CMake Error at packages/Sundance/cmake/AddTestBatch.cmake:8 (PARSE_ARGUMENTS):
Unknown CMake command "PARSE_ARGUMENTS".
Call Stack (most recent call first):
packages/Sundance/Playa/tests/Operator/CMakeLists.txt:20 (ADD_TEST_BATCH)
```
TriBITS removed the deprecated function `PARSE_ARGUMENTS()` a long time ago in the TriBITS commit TriBITSPub/TriBITS@e7bfe1a5337f11a3b070a7a272032f6de430b482 on 5/19/2017 and was snapshotted to Trilinos 'develop' in the commit 12c4cf6defd5b5f4572a4ab52bb2920d24f4061b on 6/1/2017. That means that **Sundance has likely not been able to configure against the Trilinos 'develop' branch in over 16 months**!
But when the package-by-package mode was being used for this build as recently as 9/21/2018 shown [here](https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&parentid=3959759&filtercount=2&showfilters=1&field1=buildstarttime&compare1=83&value1=4%20weeks%20ago&filtercombine=and), that configure failure only killed the build and testing of the Sundance package and therefore all of the other packages still got built and tests run. But when switching to the all-at-once mode as part of #1761 on 10/10/2018, that Sundance configure failure now stops the build and testing of all of the Trilinos packages. Therefore, this issue must be addressed.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3510Kokkos: ‘bit_scan_reverse’ is not a member2018-09-27T15:42:01ZJames WillenbringKokkos: ‘bit_scan_reverse’ is not a member*Created by: dridzal*
@trilinos/kokkos
## Current Behavior
```
/home/dridzal/development/SYNC-PR/trilinos-fork/Trilinos/packages/kokkos/core/src/impl/Kokkos_spinwait.cpp: In function ‘void {anonymous}::kokkos_internal_yield(unsig$...*Created by: dridzal*
@trilinos/kokkos
## Current Behavior
```
/home/dridzal/development/SYNC-PR/trilinos-fork/Trilinos/packages/kokkos/core/src/impl/Kokkos_spinwait.cpp: In function ‘void {anonymous}::kokkos_internal_yield(unsig$
/home/dridzal/development/SYNC-PR/trilinos-fork/Trilinos/packages/kokkos/core/src/impl/Kokkos_spinwait.cpp:70:15: error: ‘bit_scan_reverse’ is not a member of ‘Kokkos$
switch (Kokkos::Impl::bit_scan_reverse((i >> 2)+1u)) {
```
## Expectations
Trilinos should build.
## Motivation and Context
Can't sync ROL and Trilinos until this is fixed.
## Steps to Reproduce
Build Trilinos using the default SEMS checkin-test (pre-push) environment.
## Your Environment
Default SEMS checkin-test environment.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3445ThreadPool: Removal of ThreadPool from Trilinos2019-01-16T00:18:47ZJames WillenbringThreadPool: Removal of ThreadPool from Trilinos*Created by: kddevin*
@trilinos/stk @trilinos/framework @bartlettroscoe
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Cho...*Created by: kddevin*
@trilinos/stk @trilinos/framework @bartlettroscoe
<!---
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
Soon we will remove ThreadPool from the Trilinos code base.
Users of ThreadPool should respond to this issue ASAP with questions/concerns.
Within Trilinos, STKClassic depends on ThreadPool; STKClassic is also targeted for removal #3444 .
STKSearch claims a dependence on ThreadPool, but, in truth, does not need it; this claim of dependence will be removed.
## Motivation and Context
ThreadPool is no longer supported; it has been replaced by the far superior Kokkos toolkit.
Users of ThreadPool can migrate to Kokkos.
Removing unsupported, obsolete code is necessary to effectively maintain the Trilinos code base.
## Definition of Done
ThreadPool removed from stk_search dependencies
ThreadPool source code removed
STKClassic source code removed
STK/Trilinos integration and testing completed
## Possible Solution
Removal of ThreadPool is preferred.
If, for some reason, #3444 cannot be done, ThreadPool will move into the stk_classic directory to prevent further adoption by applications.
## Related Issues
* Is blocked by #3444
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3444STK: Removal of STKClassic (stk_classic) from Trilinos and STK2018-09-25T14:41:22ZJames WillenbringSTK: Removal of STKClassic (stk_classic) from Trilinos and STK*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/stk @trilinos/framework
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
Soon we will remove STKClassic (a.k.a. stk_classic) from the STK and Trilinos repos.
Users who depend on STKClassic should respond to this issue ASAP with questions and concerns. Thanks!
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## 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.
-->
STKClassic is no longer supported; it has been replaced by the superior capabilities in STK.
Current STKClassic users can migrate to STK capabilities.
Removing unsupported, obsolete code is necessary to maintain the Trilinos code base.
## Definition of Done
Code and build options removed from Trilinos and STK code bases.
Remove unbuilt/untested trilinoscouplings/examples/example_Poisson_stkclassic.cpp
Remove ifdef-ed out stk_classic code from trilinoscouplings/examples/example_Poisson_stk.cpp
STK/Trilinos integration and tests complete.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3440Framework: Add link to PR Test Replication to Autotester message2018-11-07T17:49:20ZJames WillenbringFramework: Add link to PR Test Replication to Autotester message*Created by: william76*
@trilinos/framework @allevin
It's come up that it would be tremendously helpful to the developer community if a link were provided to the wiki page: https://github.com/trilinos/Trilinos/wiki/Reproducing-PR-Te...*Created by: william76*
@trilinos/framework @allevin
It's come up that it would be tremendously helpful to the developer community if a link were provided to the wiki page: https://github.com/trilinos/Trilinos/wiki/Reproducing-PR-Testing-Errors in the test-result message the autotester kicks out.
I think a good place for this would be right after the `CDash Test Results for PR# NNNN.` link. Something like:
```
CDash Test Results for PR# NNNN.
Wiki: How to Reproduce PR Testing Builds and Errors
```
This would be especially useful to folks who are infrequent committers who might not be as familiar with navigation around the CDash system, etc.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3407Framework: Recent STK update breaks ROL's downward dependency testing2018-09-13T18:52:12ZJames WillenbringFramework: Recent STK update breaks ROL's downward dependency testing*Created by: dridzal*
@trilinos/framework @trilinos/stk @trilinos/panzer @trilinos/rol
## Expectations
Restore ROL's downward dependency testing.
## Current Behavior
https://testing-vm.sandia.gov/cdash/viewBuildError.php?buil...*Created by: dridzal*
@trilinos/framework @trilinos/stk @trilinos/panzer @trilinos/rol
## Expectations
Restore ROL's downward dependency testing.
## Current Behavior
https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=3913799
Build error:
`/ascldap/users/dridzal/development/TEST/rol-trilinos/Trilinos/packages/stk/stk_util/stk_util/parallel/CommNeighbors.cpp: In member function ‘virtual ompi_communicator_t* stk::CommNeighbors::setup_neighbor_comm(stk::ParallelMachine, const std::vector<int>&, const std::vector<int>&)’: /ascldap/users/dridzal/development/TEST/rol-trilinos/Trilinos/packages/stk/stk_util/stk_util/parallel/CommNeighbors.cpp:81:30: error: ‘MPI_UNWEIGHTED’ was not declared in this scope const int* weights = (int*)MPI_UNWEIGHTED;
^
/ascldap/users/dridzal/development/TEST/rol-trilinos/Trilinos/packages/stk/stk_util/stk_util/parallel/CommNeighbors.cpp:86:43: error: ‘MPI_Dist_graph_create_adjacent’ was not declared in this scope info, reorder, &neighborComm); ^ /ascldap/users/dridzal/development/TEST/rol-trilinos/Trilinos/packages/stk/stk_util/stk_util/parallel/CommNeighbors.cpp: In member function ‘virtual void stk::CommNeighbors::perform_neighbor_communication(MPI_Comm, const std::vector<unsigned char>&, const std::vector<int>&, const std::vector<int>&, std::vector<unsigned char>&, std::vector<int>&, std::vector<int>&)’: /ascldap/users/dridzal/development/TEST/rol-trilinos/Trilinos/packages/stk/stk_util/stk_util/parallel/CommNeighbors.cpp:221:71: error: ‘MPI_Neighbor_alltoall’ was not declared in this scope (void*)recvCountsPtr, 1, MPI_INT, neighborComm); ^ /ascldap/users/dridzal/development/TEST/rol-trilinos/Trilinos/packages/stk/stk_util/stk_util/parallel/CommNeighbors.cpp:236:78: error: ‘MPI_Neighbor_alltoallv’ was not declared in this scope (void*)recvBufPtr, recvCountsPtr, recvDisplsPtr, MPI_BYTE, neighborComm); ^`
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
## Possible Solution
I believe that MPI that is loaded for ROL's nightly testing (1.6.5??) no longer works for STK. This needs to be updated ASAP. I simply call
`$TRILINOS_DIR/cmake/load_sems_dev_env.sh "default"`
so the issue must be in load_sems_dev_env or the definition of "default". I wonder why others are not seeing this issue. Is the "default" abandoned or renamed? On the other hand, pre-push test scripts seem to work just fine ... how are they different?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3373PR testing instability2018-11-15T20:22:39ZJames WillenbringPR testing instability*Created by: jwillenbring*
@trilinos/framework
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
We need PR testing fo...*Created by: jwillenbring*
@trilinos/framework
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
We need PR testing for Trilinos that runs reliably not only currently, but also when we continue to scale up the testing to include additional builds.
## Current Behavior
There are two primary causes of instability in the PR testing currently:
1) Communication issues
2) Machine overloading issues
We have seen a number of distinct types of communication issues. Here is a partial list:
a) clone/Fetch timeouts on GitHub
b) clone/fetch timeouts on internal gitlab-ex
c) failed reporting of results to CDash
d) Failure to communicate PR info from GitHub issues to autotester
e) Failure to communicate from autotester back to GitHub issues
Machine overloading issues have shown up in the form of internal compiler errors and test timeouts.
## 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 need to be able to run our PR testing in parallel (multiple PR testing at the same time and also multiple builds for each PR at the same time). If the environment won't scale, we will not be able to test PRs fast enough to make the system practical.
## 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.
-->
Communication errors occur on average less than one time per day. Machine overload issues occur less than twice a week.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
We are looking into several possible solutions.
1) Reducing the -j for builds so we don't run into compiler errors
2) Reducing the number of available executors on testing nodes so that fewer tests can run at the same time
3) Speaking with networking staff about why operations are timing out
4) Reducing the number and/or frequency of PR testing instances to reduce the average communication traffic.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3347stk broken in clean Linux-gcc-4.8.4-MPI_Release_gcc_4.8.4_openmpi_1.8.7_DEV b...2018-09-04T13:32:57ZJames Willenbringstk broken in clean Linux-gcc-4.8.4-MPI_Release_gcc_4.8.4_openmpi_1.8.7_DEV build*Created by: prwolfe*
Looks like the recent import of stk (commit de635abc146449dc1c4dbbea65cefda91946755e) caused failures in the Linux-gcc-4.8.4-MPI_Release_gcc_4.8.4_openmpi_1.8.7_DEV build.
<!---
Provide a general summary of the...*Created by: prwolfe*
Looks like the recent import of stk (commit de635abc146449dc1c4dbbea65cefda91946755e) caused failures in the Linux-gcc-4.8.4-MPI_Release_gcc_4.8.4_openmpi_1.8.7_DEV build.
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
Gcc 4.8.4 does not support brace-list initialization which is used in one of the unit tests. This was turned off in the PR testing, but looks like it was missed in this build. See commit 465f04753fcb8e6bf7047cc03d1cce54e254d25f for details.
@trilinos/framework
@trilinos/stk
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3346SEACAS not included files...in neither src directory nor install directory2018-11-30T03:12:47ZJames WillenbringSEACAS not included files...in neither src directory nor install directory*Created by: kyungjoo-kim*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
@trilinos/seacas...*Created by: kyungjoo-kim*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
@trilinos/seacas
After I installed Trilinos with SEACAS and compile a code against them, I have cmake error reporting following packages are missing.
```
CMake Error at /home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/SEACASConfig.cmake:146 (INCLUDE):
INCLUDE could not find load file:
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASTxtexo/SEACASTxtexoConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASNumbers/SEACASNumbersConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASMapvar-kd/SEACASMapvar-kdConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASMapvar/SEACASMapvarConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASMapvarlib/SEACASMapvarlibConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASExplore/SEACASExploreConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASGrepos/SEACASGreposConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASGenshell/SEACASGenshellConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASGen3D/SEACASGen3DConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASGjoin/SEACASGjoinConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASEx1ex2v2/SEACASEx1ex2v2Config.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASExotxt/SEACASExotxtConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASAlgebra/SEACASAlgebraConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASSuplib/SEACASSuplibConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASSupes/SEACASSupesConfig.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASExoIIv2for32/SEACASExoIIv2for32Config.cmake
/home/kyukim/Work/lib/trilinos/install/white/empire/release-k80-cuda-9.2/lib/cmake/SEACAS/../SEACASExodus_for/SEACASExodus_forConfig.cmake
```
CMakeCache output indicates SEACAS has dependency on those packages
```
SEACAS_FULL_ENABLED_DEP_PACKAGES:INTERNAL=SEACASTxtexo;SEACASNumbers;SEACASNemspread;SEACASNemslice;SEACASMapvar-kd;SEACASMapvar;SEACASMapvarlib;SEACASExplore;SEACASGrepos;SEACASGenshell;SEACASGen3D;SEACASGjoin;SEACASEx1ex2v2;SEACASExo_\
format;SEACASExotxt;SEACASExomatlab;SEACASExodiff;SEACASEpu;SEACASEjoin;SEACASConjoin;SEACASAprepro;SEACASAlgebra;SEACASSuplibCpp;SEACASSuplibC;SEACASSuplib;SEACASSupes;SEACASAprepro_lib;SEACASChaco;SEACASIoss;SEACASNemesis;SEACASExoIIv\
2for32;SEACASExodus_for;SEACASExodus;Pamgen;Zoltan;Kokkos;KokkosAlgorithms;KokkosContainers;KokkosCore
```
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
Trilinos cmake system should be compiled with other cmake system used by applications. The dependence on missing packages should be configured correctly.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
cmake looks up missing packages.
## 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.
-->
This does not compile with other applications that rely on cmake e.g., empire.
## Definition of Done
Corrrect cmake dependence.
- check install directory ``${INSTALL_DIR}/lib/cmake/SEACASConfig.cmake``
- check if it does not include ``INCLUDE("${CMAKE_CURRENT_LIST_DIR}/../SEACASTxtexo/SEACASTxtexoConfig.cmake") `` as well as all other packages listed above.
- or check CMakeCache does not include dependency on the packages above.
## Steps to Reproduce
Configure Trilinos with SEACAS
```
cmake \
-D BUILD_SHARED_LIBS:BOOL=${SHARED_LIBS} \
-D CMAKE_BUILD_TYPE:STRING=${BUILD_TYPE} \
-D CMAKE_C_COMPILER:FILEPATH="mpicc" \
-D CMAKE_C_FLAGS:STRING="${EXTRA_C_FLAGS}" \
-D CMAKE_CXX_COMPILER:FILEPATH="mpicxx" \
-D CMAKE_CXX_FLAGS:STRING="${EXTRA_CXX_FLAGS}" \
-D CMAKE_Fortran_COMPILER:FILEPATH="mpif77" \
-D CMAKE_Fortran_FLAGS:STRING="${EXTRA_F77_FLAGS}" \
-D CMAKE_SKIP_RULE_DEPENDENCY:BOOL=ON \
-D CMAKE_INSTALL_PREFIX:PATH=${INSTALL_DIR} \
-D CMAKE_VERBOSE_MAKEFILE:BOOL=OFF \
-D Trilinos_CXX11_FLAGS:STRING="-std=c++11" \
-D Trilinos_ENABLE_INSTALL_CMAKE_CONFIG_FILES:BOOL=ON \
-D Trilinos_VERBOSE_CONFIGURE:BOOL=OFF \
-D Trilinos_ENABLE_DEBUG:BOOL=OFF \
-D Trilinos_ENABLE_EXAMPLES:BOOL=${EXAMPLE} \
-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \
-D Trilinos_ENABLE_Fortran:BOOL=OFF \
-D Trilinos_ENABLE_STRONG_CXX_COMPILE_WARNINGS:BOOL=OFF \
-D Trilinos_ENABLE_STRONG_C_COMPILE_WARNINGS:BOOL=OFF \
-D Trilinos_ENABLE_SHADOW_WARNINGS:BOOL=OFF \
-D Trilinos_ENABLE_TESTS:BOOL=${TEST} \
-D Trilinos_ENABLE_ALL_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_OpenMP:BOOL=${USE_OPENMP} \
-D Trilinos_ENABLE_Amesos:BOOL=ON \
-D Trilinos_ENABLE_Amesos2:BOOL=ON \
-D Trilinos_ENABLE_Belos:BOOL=ON \
-D Trilinos_ENABLE_KokkosCore:BOOL=ON \
-D Trilinos_ENABLE_KokkosAlgorithms:BOOL=ON \
-D Trilinos_ENABLE_ML:BOOL=ON \
-D Trilinos_ENABLE_MueLu:BOOL=ON \
-D Trilinos_ENABLE_Panzer:BOOL=ON \
-D Trilinos_ENABLE_Pamgen:BOOL=ON \
-D Trilinos_ENABLE_SEACAS:BOOL=ON \
-D Trilinos_ENABLE_SEACASIoss:BOOL=ON \
-D Trilinos_ENABLE_SEACASEx2ex1v2:BOOL=OFF \
-D Trilinos_ENABLE_Shards:BOOL=ON \
-D Trilinos_ENABLE_STK:BOOL=ON \
-D Trilinos_ENABLE_STKMesh:BOOL=ON \
-D Trilinos_ENABLE_STKUtil:BOOL=ON \
-D Trilinos_ENABLE_STKTopology:BOOL=ON \
-D Trilinos_ENABLE_STKSearch:BOOL=OFF \
-D Trilinos_ENABLE_STKTransfer:BOOL=OFF \
-D Trilinos_ENABLE_STKDoc_tests:BOOL=OFF \
-D Trilinos_ENABLE_STKUnit_tests:BOOL=OFF \
-D Trilinos_ENABLE_STKUnit_test_utils:BOOL=OFF \
-D Trilinos_ENABLE_Stokhos:BOOL=OFF \
-D Trilinos_ENABLE_Stratimikos:BOOL=ON \
-D Trilinos_ENABLE_Teko:BOOL=ON \
-D Trilinos_ENABLE_Tempus:BOOL=ON \
-D Trilinos_ENABLE_Zoltan:BOOL=ON \
-D Trilinos_ENABLE_Zoltan2:BOOL=ON \
-D EpetraExt_ENABLE_HDF5:BOOL=OFF \
-D Kokkos_ENABLE_OpenMP:BOOL=${USE_OPENMP} \
-D Kokkos_ENABLE_Pthread:BOOL=${USE_PTHREADS} \
-D Kokkos_ENABLE_Cuda_UVM:BOOL=${USE_CUDA} \
-D Kokkos_ENABLE_Cuda_Lambda:BOOL=${USE_CUDA} \
-D Kokkos_ENABLE_Debug_Bounds_Check:BOOL=${BOUNDS_CHECK} \
-D MueLu_ENABLE_Experimental:BOOL=ON \
-D Panzer_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \
-D Panzer_ENABLE_TESTS:BOOL=OFF \
-D Phalanx_KOKKOS_DEVICE_TYPE:STRING="${NODE_TYPE}" \
-D Phalanx_SHOW_DEPRECATED_WARNINGS:BOOL=OFF \
-D SEACASExodus_ENABLE_MPI:BOOL=ON \
-D TeuchosCore_ENABLE_yaml-cpp:BOOL=ON \
-D Xpetra_ENABLE_Experimental:BOOL=ON \
-D TPL_ENABLE_GLM:BOOL=OFF \
-D TPL_ENABLE_Matio:BOOL=OFF \
-D TPL_ENABLE_SuperLU:BOOL=OFF \
-D TPL_ENABLE_X11:BOOL=OFF \
-D TPL_ENABLE_MPI:BOOL=ON \
-D TPL_ENABLE_BLAS:BOOL=ON \
-D TPL_BLAS_LIBRARIES:FILEPATH="-lblas" \
-D TPL_ENABLE_Boost:BOOL=ON \
-D Boost_INCLUDE_DIRS:FILEPATH="${BOOST_ROOT}/include" \ \
-D Boost_LIBRARY_DIRS:FILEPATH="${BOOST_ROOT}/lib" \
-D TPL_ENABLE_BoostLib:BOOL=ON \
-D BoostLib_INCLUDE_DIRS:FILEPATH="${BOOST_ROOT}/include" \
-D BoostLib_LIBRARY_DIRS:FILEPATH="${BOOST_ROOT}/lib" \
-D TPL_ENABLE_CUDA:BOOL=${USE_CUDA} \
-D TPL_ENABLE_CUSPARSE:BOOL=${USE_CUDA} \
-D TPL_ENABLE_LAPACK:BOOL=ON \
-D TPL_LAPACK_LIBRARIES:FILEPATH="-llapack" \
-D TPL_ENABLE_HDF5:BOOL=ON \
-D HDF5_INCLUDE_DIRS:FILEPATH="${HDF5_ROOT}/include" \
-D HDF5_LIBRARY_DIRS:FILEPATH="${HDF5_ROOT}/lib" \
-D TPL_HDF5_LIBRARIES:FILEPATH="${HDF5_LIBS}" \
-D TPL_ENABLE_Netcdf:BOOL=ON \
-D Netcdf_INCLUDE_DIRS:FILEPATH="${NETCDF_ROOT}/include" \
-D TPL_Netcdf_LIBRARIES:FILEPATH="${NETCDF_LIBS};${NETCDF_LIBS}" \
-D TPL_ENABLE_yaml-cpp:BOOL=ON \
-D yaml-cpp_LIBRARY_DIRS="${YAMLCPP_ROOT}/lib" \
-D KOKKOS_ARCH="Power8;Kepler37" \
$TRILINOS_DIR
```
## Your Environment
on WHITE
```
module load devpack/20180521/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
module load yamlcpp/0.5.3/gcc/7.2.0
```
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant repo SHA1s:**
- **Relevant configure flags or configure script:**
- **Operating system and version:**
- **Compiler and TPL versions:**
Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3306Failure of ATDM build script on waterman2019-01-09T23:48:45ZJames WillenbringFailure of ATDM build script on waterman*Created by: keitat*
I am seeing the latest version of ATDM build script is not working on waterman.
## Expectations
I am following the instruction of budding on internal machines, but it's not working.
## Current Behavior
[kn...*Created by: keitat*
I am seeing the latest version of ATDM build script is not working on waterman.
## Expectations
I am following the instruction of budding on internal machines, but it's not working.
## Current Behavior
[knteran@waterman11 buildTrilinos]$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh kt_cuda
Error, hostname = 'waterman11' not recognized as a known ATDM system name!
## Steps to Reproduce
```
module load devpack/20180517/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
export TRILINOS_DIR=your directory
source $TRILINOS_DIR/cmake/std/atdm/load-env.sh job name
```
## Your Environment
```
[knteran@waterman11 buildTrilinos]$ module list
Currently Loaded Modulefiles:
1) binutils/2.30.0 8) valgrind/3.12.0 15) pnetcdf-exo/1.9.0/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
2) gcc/7.2.0 9) openblas/0.2.20/gcc/7.2.0 16) netcdf-exo/4.6.1/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
3) cuda/9.2.88 10) metis/5.0.1/gcc/7.2.0 17) parmetis/4.0.3/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
4) java/ibm/sdk/8.0.0 11) zlib/1.2.8 18) boost/1.65.1/gcc/7.2.0
5) numa/2.0.11 12) hdf5/1.8.20/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88 19) superlu-dist/4.3.0/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
6) openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88 13) cgns/20180517/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88 20) devpack/20180517/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
7) cmake/3.6.2 14) matio/1.5.11/gcc/7.2.0
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3285Transition to new site testing-vm.sandia.gov/cdash/2018-08-30T18:09:35ZJames WillenbringTransition to new site testing-vm.sandia.gov/cdash/*Created by: bartlettroscoe*
CC: @trilinos/framework
## Next Action Status
PR #3305 merged on 8/16/2018 that submits only to testing-vm.sandia.gov/cdash/. Redirect from https://testing.sandia.gov/cdash/ to https://testing-vm.san...*Created by: bartlettroscoe*
CC: @trilinos/framework
## Next Action Status
PR #3305 merged on 8/16/2018 that submits only to testing-vm.sandia.gov/cdash/. Redirect from https://testing.sandia.gov/cdash/ to https://testing-vm.sandia.gov/cdash/ completed on 8/30/2018. Next: Change all wiki references of https://testing-vm.sandia.gov/cdash/ to https://testing.sandia.gov/cdash/?
## Description
This Story is to plan and track efforts to switch from the existing testing.sandia.gov/cdash/ site to the new just approved testing-vm.sandia.gov/cdash/ site (see https://gitlab.kitware.com/snl/project-1/issues/33). The machine testing.sandia.gov is old and needs to be retired and the new site testing-vm.sandia.gov/cdash/ supports all-at-once configure/build/test/submit and lots of other improvements and bug fixes.
## Tasks
* [x] Test and approve testing-vm.sandia.gov/cdash/ (see https://gitlab.kitware.com/snl/project-1/issues/33)
* [x] Turn on CDash emails from testing-vm.sandia.gov/cdash/
* [x] Send out email to trilinos-developers warning about the transition and stopping of sending CDash data to testing.sandia.gov shortly.
* [x] Submit and merge to 'develop' a PR that stops dual submits to testing.sandia.gov/cdash/ by updating `Trilinos/CTestConfig.cmake`.
* [x] Update Trilinos wiki pages to change from testing.sandia.gov to testing-vm.sandia.gov (can do this with a git clone of the wiki repo).
* [x] Update 'master' from 'develop' with the updated `Trilinos/CTestConfig.cmake` file.
* [x] Wait a day or more and verify that no data is submitted to testing.sandia.gov/cdash/ over a full 24-hour testing day period (to any CDash project on that site). (Or verify that no dual submits will occur after putting in redirect testing.sandia.gov/cdash/ to testing-vm.sandia.gov/cdash/.)
* [x] Transition to testing-vm.sandia.gov/cdash/ and turn off testing.sandia.gov/cdash/ (all together)
* [x] Set up a URL redirect from testing.sandia.gov/cdash/ to testing-vm.sandia.gov/cdash/ (effectively taking testing.sandia.gov offline)
* [x] Send out email to Trilinos developers announcing the transition is complete
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3265Problems with autotester SHA1s passed into get-changed-trilinos-packages.sh i...2018-09-13T18:50:18ZJames WillenbringProblems with autotester SHA1s passed into get-changed-trilinos-packages.sh in Trilinos auto-tester*Created by: bartlettroscoe*
@trilinos/framework, @william76
## Next Action Status
PR #3258 merged on 8/14/2018 which should fix this and this seems to be fixed as noted in closed #3133.
## Description
There seems to be a ...*Created by: bartlettroscoe*
@trilinos/framework, @william76
## Next Action Status
PR #3258 merged on 8/14/2018 which should fix this and this seems to be fixed as noted in closed #3133.
## Description
There seems to be a problem with the Trilinos autotester in passing in the right range of commits to the `get-changed-trilinos-packages.sh` script (see #3133 and #3218). The evidence for this is the PR testing iteration for PR #3260 which only changes files under the `cmake/std/atdm/` directory yet it triggered the enable of several Trilinos packages as shown in [this PR iteration this morning](https://testing-vm.sandia.gov/cdash/viewConfigure.php?buildid=3815005) which shows:
```
loading initial cache file /scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.8.4/packageEnables.cmake
-- Setting Trilinos_ENABLE_ALL_PACKAGES = ON
-- Setting Trilinos_ENABLE_Belos = ON
-- Setting Trilinos_ENABLE_Ifpack2 = ON
-- Setting Trilinos_ENABLE_Piro = ON
-- Setting Trilinos_ENABLE_ROL = ON
-- Setting Trilinos_ENABLE_TpetraCore = ON
```
My guess is that the Python script is passing in the git SHA1 for the tip of the 'develop' branch instead of the base commit that the topic branch is created off of.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3133Get Trilinos auto PR testing code to use TriBITS-based package enable logic2018-09-13T18:49:19ZJames WillenbringGet Trilinos auto PR testing code to use TriBITS-based package enable logic*Created by: bartlettroscoe*
CC: @william76, @jwillenbring
## Next Action Status
With the merge of PR #3258 8/14/2018 this should be complete. As of 9/12/2018 no problems have been reported in last 4+ weeks so all is good!
...*Created by: bartlettroscoe*
CC: @william76, @jwillenbring
## Next Action Status
With the merge of PR #3258 8/14/2018 this should be complete. As of 9/12/2018 no problems have been reported in last 4+ weeks so all is good!
## Description
This story is to get the Trilinos auto PR testing code to use TriBITS-based logic for determining what to enable and test based on files that are changed in the PR branch.
The benefits of making this change are:
* When the set of Primary Tested packages changes, the code will automatically adjust
* Specialized logic can be applied to determine if all packages need to be tested or not. For example, if files are changed under `Trilinos/cmake/ctest/drivers` then that should not trigger the auto PR tester to test all of Trilinos.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/3120Weird MPI run-time error in Dashboard build using ancient OpenMPI version2019-04-01T21:46:38ZJames WillenbringWeird MPI run-time error in Dashboard build using ancient OpenMPI version*Created by: mhoemmen*
@trilinos/tpetra @trilinos/framework
I noticed that Tpetra's "ReadTriples" test showed a failure on one Dashboard build:
https://testing-vm.sandia.gov/cdash/testDetails.php?test=50492359&build=3725219
Th...*Created by: mhoemmen*
@trilinos/tpetra @trilinos/framework
I noticed that Tpetra's "ReadTriples" test showed a failure on one Dashboard build:
https://testing-vm.sandia.gov/cdash/testDetails.php?test=50492359&build=3725219
The failure looks spurious, possibly due to a full `/tmp` filesystem:
```
[ascic114:11890] opal_os_dirpath_create: Error: Unable to create the sub-directory (/tmp/openmpi-sessions-trilinos@ascic114_0/49948) of (/tmp/openmpi-sessions-trilinos@ascic114_0/49948/0/0), mkdir failed [1]
[ascic114:11890] [[49948,0],0] ORTE_ERROR_LOG: Error in file util/session_dir.c at line 107
[ascic114:11890] [[49948,0],0] ORTE_ERROR_LOG: Error in file util/session_dir.c at line 402
[ascic114:11890] [[49948,0],0] ORTE_ERROR_LOG: Error in file ess_hnp_module.c at line 638
--------------------------------------------------------------------------
It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_session_dir failed
--> Returned value Error (-1) instead of ORTE_SUCCESS
--------------------------------------------------------------------------
```
I also noticed that the build uses OpenMPI 1.8.7. @prwolfe and/or @rrdrake reported to me that Sierra skipped over that version of OpenMPI in favor of 1.10.x, because 1.8.y caused tests to fail. 1.8 is also a retired version of OpenMPI. (So is 1.10, but at least it's a bit newer.) We should get rid of that build or update the OpenMPI version.
## Expectations
Nobody tests with OpenMPI versions that old. OpenMPI doesn't support them, and neither Sierra nor ATDM apps use them.
## Possible Solution
1. Eliminate that build, or
2. update its OpenMPI version.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2995Framework: Autotester may be busted?2018-06-21T13:54:55ZJames WillenbringFramework: Autotester may be busted?*Created by: csiefer2*
Been waiting 5 hours now for the testing to finish... See #2988
@trilinos/framework *Created by: csiefer2*
Been waiting 5 hours now for the testing to finish... See #2988
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2974Trilinos GCC 4.8.4 PR build and running of tests is broken2018-06-19T20:25:41ZJames WillenbringTrilinos GCC 4.8.4 PR build and running of tests is broken*Created by: bartlettroscoe*
@trilinos/framework, @eric-c-cyr, @rppawlo, @trilinos/nox
## Expectations
The GCC 4.8.4 auto PR build should work unless the PR code itself is broken.
## Current Behavior
The GCC 4.8.4 auto PR bu...*Created by: bartlettroscoe*
@trilinos/framework, @eric-c-cyr, @rppawlo, @trilinos/nox
## Expectations
The GCC 4.8.4 auto PR build should work unless the PR code itself is broken.
## Current Behavior
The GCC 4.8.4 auto PR build has broken NOX test builds and all of the tests in every package fail, starting in the auto PR testing iteration build last night:
* https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=3627737&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Pull%20Request&field2=buildstarttime&compare2=84&value2=NOW&field3=buildstarttime&compare3=83&value3=1%20week%20ago&filtercombine=and
YOu can see the NOX failures at:
* https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=3627737
And all of the tests fail because `--bind-to none` is being used with `mpiexec` with OpenMP 1.6.5 as shown, for example, at:
* https://testing-vm.sandia.gov/cdash/testDetails.php?test=48792061&build=3627756
which shows the commandline:
```
"/projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.8.4/openmpi/1.6.5/bin/mpiexec \"--bind-to\" \"none\" \"-np\" \"1\" \"/scratch/trilinos/workspace/trilinos-folder/Trilinos_pullrequest_gcc_4.8.4/pull_request_test/packages/kokkos-kernels/unit_test/KokkosKernels_blas_serial.exe\" \"--gtest_filter=-serial.gemm_double\"
```
As described in #2462 and #2788, you can't use those options with OpenMPI 1.6.5. OpenMPI 1.10.1 is the only version in the SEMS env where those options work (see #2462 and #2788).
It is important to fix this ASAP since every PR build will fail and therefore no one will be able to merge any PRs until this gets fixed.
## Motivation and Context
I can't merge my PR #2964.
## Definition of Done
PR builds are working unless code changes break them.
## Possible Solution
Use the source and *.cmake scripts in #2788. That will fix it.
## Steps to Reproduce
## Your Environment
N.A. This is the auto PR testing having this issue.
## Related Issues
* Blocks: #2964
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2788Replace existing GCC 4.8.4 auto PR serial Kokkos build with updated GCC 4.8.4...2018-08-01T20:50:44ZJames WillenbringReplace existing GCC 4.8.4 auto PR serial Kokkos build with updated GCC 4.8.4 + OpenMPI 1.10.1 + OpenMP configuration*Created by: bartlettroscoe*
CC: @trilinos/framework
## Description
This story is to solicit a review of the GCC 4.8.4 + OpenMPI 1.10.1 + OpenMP build which is currently submitting to CDash shown at:
* https://testing-vm.sandi...*Created by: bartlettroscoe*
CC: @trilinos/framework
## Description
This story is to solicit a review of the GCC 4.8.4 + OpenMPI 1.10.1 + OpenMP build which is currently submitting to CDash shown at:
* https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&date=2018-05-20&filtercombine=and&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=GCC-4.8.4-OpenMPI-1.10.1-MpiReleaseDebugSharedPtOpenMP&field2=buildstarttime&compare2=84&value2=now
merged in PRs #2694 and #2851 and then to consider swapping out the existing GCC 4.8.4 auto PR build with this build.
This build 100% matches the agreed-upon GCC 4.8.4 PR build described in #2317 and #2462 . And this build also uses ninja as well, and therefore adds that testing to PR testing (and greatly speeds up the build). This would be a PR build that tests Trilinos with OpenMP enabled and an updated version of OpenMPI compared to the existing auto PR builds.
The key files to review and be used in the auto PR tester are:
* [GCC-4.8.4-OpenMPI-1.10.1-MpiReleaseDebugSharedPtOpenMP_env.sh](https://github.com/trilinos/Trilinos/blob/develop/cmake/std/GCC-4.8.4-OpenMPI-1.10.1-MpiReleaseDebugSharedPtOpenMP_env.sh): Just source this to load env
* [GCC-4.8.4-OpenMPI-1.10.1-MpiReleaseDebugSharedPtOpenMP.cmake](https://github.com/trilinos/Trilinos/blob/develop/cmake/std/GCC-4.8.4-OpenMPI-1.10.1-MpiReleaseDebugSharedPtOpenMP.cmake): Just include this in the CMake configure `-C <base-path>` and enable any packages you want
Hopefully the auto PR testing infrastructure will allow these two files to be plugged in pretty easily.
The other files that are also of some interest (but don't need to be used in auto PR testing) are:
* [ctest_std_driver.cmake](https://github.com/trilinos/Trilinos/blob/develop/cmake/ctest/drivers/sems_ci/ctest_std_driver.cmake): Generic ctest -S driver for any build using this model
* [ctest_std_driver.sh](https://github.com/trilinos/Trilinos/blob/develop/cmake/ctest/drivers/sems_ci/ctest_std_driver.sh): Generic bash/Jenkins driver for any build using this model
* [ctest_GCC-4.8.4-OpenMPI-1.10.1-MpiReleaseDebugSharedPtOpenMP.sh](https://github.com/trilinos/Trilinos/blob/develop/cmake/ctest/drivers/sems_ci/ctest_GCC-4.8.4-OpenMPI-1.10.1-MpiReleaseDebugSharedPtOpenMP.sh): Specific Jenkins driver
These files shows how easy it is to set up a system based on `<build_name>` with a env script `<build_name>_env.sh` and set of CMake settings `<build_name>.cmake` and then drive everything from local builds to ctest -S/Jenkins drivers. Hopefully the auto PR system can be set up this way to make it easy to add new auto PR builds and also make it easy for developer to reproduce these builds.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2767Question: generating file "TrilinosConfig.cmake"2018-05-16T22:47:40ZJames WillenbringQuestion: generating file "TrilinosConfig.cmake"*Created by: jhux2*
Is there a Trilinos cmake option that suppresses the creation/installation of the file `TrilinosConfig.cmake`? I am trying to figure out why my build of Trilinos does not have this file.
@trilinos/framework *Created by: jhux2*
Is there a Trilinos cmake option that suppresses the creation/installation of the file `TrilinosConfig.cmake`? I am trying to figure out why my build of Trilinos does not have this file.
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2726Please disable the "Allow rebase merging" merge button2018-10-25T15:17:22ZJames WillenbringPlease disable the "Allow rebase merging" merge button*Created by: bartlettroscoe*
@trilinos/framework
Can someone with the GitHub permissions please uncheck the "Allow rebase merging" option under the "Merge button" section at the page:
* https://github.com/trilnos/Trilinos/setting...*Created by: bartlettroscoe*
@trilinos/framework
Can someone with the GitHub permissions please uncheck the "Allow rebase merging" option under the "Merge button" section at the page:
* https://github.com/trilnos/Trilinos/settings
?
That will stop people from rebasing and then fast-forward merging a bunch of commits on the 'develop' branch. For example, currently, someone with 30 commits on their topic branch could rebase all of these commits and fast-forward merge them to 'develop'. If those commits badly broke an ATDM build for example, then we would have to back out 30 commits, one `git revert <sha1>` at a time.
By disabling this option, the options of "Merge" and "Squash" are still available, which is all we want/need.
If the topic branch has more than one commit, and they are well-formed "Separate Changes" (see [workflows(7)](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/gitworkflows.html)), then you really should select the "Merge" option. But if you have multiple commits, and they are kind of a mess, then you might as well select the "Squash" option. (But people really should be cleaning up their topic branches before their final topic branch push as described [here](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#bookmark=id.5lteak78cig8)).
If you only have one commit on your topic branch, then it is silly to create a merge commit for this. In that case, you should select "Squash". When you select "Squash" with a single commit, GitHub populates the squash commit summary and log text the same as for the single commit. Therefore, it is equivalent to rebasing a single commit in this case. And a single squashed commit is as easy to revert as a single merge commit. In fact, a single squash commit is easier to revert because you don't need to provide the parent index with `git revert -m <sha>`. You can just call `git revert <sha1>`.
## Definition of Done
* Uncheck the button "Allow rebase merging" on the page https://github.com/trilnos/Trilinos/settings
## Possible Solution
* Uncheck the button "Allow rebase merging" on the page https://github.com/trilnos/Trilinos/settings
Improve productivity, stability, and quality of Trilinos