Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2016-11-21T19:08:37Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/819Add @jjellio to Trilinos organization please2016-11-21T19:08:37ZJames WillenbringAdd @jjellio to Trilinos organization please*Created by: mhoemmen*
Thanks! :-D
Blocks: #820*Created by: mhoemmen*
Thanks! :-D
Blocks: #820https://gitlab.osti.gov/jmwille/Trilinos/-/issues/805Test scripts for apollo, ride, shiller, and artemis incorrectly enable pthreads2017-02-11T23:31:41ZJames WillenbringTest scripts for apollo, ride, shiller, and artemis incorrectly enable pthreads*Created by: jhux2*
@bmpersc It appears that the nightly test scripts for ride, artemis, and schiller are always enabling Pthreads because of this line:
```
"-DKokkos_ENABLE_Pthreadi:BOOL=$ENV{JENKINS_DO_PTHREAD}"
```
I've fixed t...*Created by: jhux2*
@bmpersc It appears that the nightly test scripts for ride, artemis, and schiller are always enabling Pthreads because of this line:
```
"-DKokkos_ENABLE_Pthreadi:BOOL=$ENV{JENKINS_DO_PTHREAD}"
```
I've fixed this with commit b260ac05.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/778NetCDF find tool ignoring include/lib paths2016-11-03T22:15:11ZJames WillenbringNetCDF find tool ignoring include/lib paths*Created by: bathmatt*
On hansen I set the netcdf path to use pnetcdf. Tribits ignores this
cmake \
-DTPL_ENABLE_MPI=ON \
-DMPI_BASE_DIR=/projects/sems/install/rhel6-x86_64/sems/compiler/gcc/5.3.0/openmpi/1.10.1 \
-DTrilin...*Created by: bathmatt*
On hansen I set the netcdf path to use pnetcdf. Tribits ignores this
cmake \
-DTPL_ENABLE_MPI=ON \
-DMPI_BASE_DIR=/projects/sems/install/rhel6-x86_64/sems/compiler/gcc/5.3.0/openmpi/1.10.1 \
-DTrilinos_ENABLE_Panzer=ON \
-D TPL_ENABLE_Netcdf:BOOL=ON \
-D TPL_ENABLE_HDF5:BOOL=ON \
-D TPL_ENABLE_Boost:BOOL=ON \
-D TPL_ENABLE_BoostLib:BOOL=ON \
-D Netcdf_INCLUDE_DIRS:FILEPATH="${PNETCDF_ROOT}/include" \
-D HDF5_INCLUDE_DIRS:FILEPATH="${HDF5_ROOT}/include" \
-D Boost_INCLUDE_DIRS:FILEPATH="${BOOST_ROOT}/include" \
-D Netcdf_LIBRARY_DIRS:FILEPATH="${PNETCDF_ROOT}/lib" \
-D HDF5_LIBRARY_DIRS:FILEPATH="${HDF5_ROOT}/lib" \
-D Boost_LIBRARY_DIRS:FILEPATH="${BOOST_ROOT}/lib" \
-D BoostLib_LIBRARY_DIRS:FILEPATH="${BOOST_ROOT}/lib" \
/home/mbetten/Trilinos/Trilinos
which should be set to the pnetcdf, not the netcdf
-bash-4.1$ echo $PNETCDF_ROOT
/home/projects/x86-64-haswell-nvidia/pnetcdf/1.6.1/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.18
as you can see here on this link line
/home/projects/x86-64-haswell-nvidia/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.18/bin/mpicxx -pedantic -Wall -Wno-long-long -Wwrite-strings -pedantic -Wall -Wno-long-long -Wwrite-strings -pedantic -Wall -Wno-long-long -Wwrite-strings -Wshadow -Woverloaded-virtual -std=c++11 -O3 -DNDEBUG CMakeFiles/cth_pressure_map.dir/cth_pressure_map.C.o CMakeFiles/cth_pressure_map.dir/vector3d.C.o -o cth_pressure_map -rdynamic libio_info_lib.a ../init/libIonit.a ../transform/libIotr.a ../heartbeat/libIohb.a ../generated/libIogn.a ../pamgen/libIopg.a ../exo_fac/libIoexo_fac.a ../exo_fpp/libIofx.a ../exodus/libIoex.a ../libIoss.a ../../../exodus/libexodus.a /home/projects/x86-64-haswell-nvidia/netcdf/4.3.3.1/gcc/4.8.4/cuda/7.5.18/lib/libnetcdf.a ../../../../../pamgen/src/libpamgen_extras.a ../../../../../pamgen/src/libpamgen.a ../../../../../zoltan/src/libzoltan.a -lm ../../../../../kokkos/algorithms/src/libkokkosalgorithms.a ../../../../../kokkos/containers/src/libkokkoscontainers.a ../../../../../kokkos/core/src/libkokkoscore.a /usr/lib64/libdl.so /home/projects/x86-64-haswell-nvidia/hdf5/1.8.15/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.18/lib/libhdf5.a /usr/lib64/libz.so /home/projects/x86-64-haswell-nvidia/hdf5/1.8.15/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.18/lib/libhdf5_hl.a
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/764Create 12.10 release2016-12-16T16:12:33ZJames WillenbringCreate 12.10 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 hav...*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:
1. 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.
2. 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 "<short message about tag>" <tag name>
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.
3. Create a branch
To create a branch, from anywhere in your clone type
Command: cmake/tribits/python_utils/gitdist branch <branch name>
For the Trilinos release version XYZ mentioned above, the branch name should be
trilinos-release-XYZ-branch.
4. 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 <branch name>
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.
5. 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.
6. 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 "<short message about tag>" <initial tag name>
For the Trilinos release version XYZ mentioned above, the initial tag name
should be initial-trilinos-release-XYZ-branch.
7. 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 <local branch name>:<public branch name>
This will push the branch named <local branch name> and the new commits on it
from your clone to origin with the name <public branch name>. Note that you can
rename the branch by giving a different name for <public branch name>, 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
8. 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/<name of branch>
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 <name of branch>
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 <name of tag>
'''https://gitlab.osti.gov/jmwille/Trilinos/-/issues/702 Add new cdash "Nightly" build tracks/groups2017-05-08T14:56:44ZJames Willenbring Add new cdash "Nightly" build tracks/groups*Created by: jwillenbring*
@trilinos/framework @maherou
We spoke on Tuesday morning about creating a new track for test results in CDash for build that must pass. Currently, we have nightly, release, and experimental. The focus of thi...*Created by: jwillenbring*
@trilinos/framework @maherou
We spoke on Tuesday morning about creating a new track for test results in CDash for build that must pass. Currently, we have nightly, release, and experimental. The focus of this ticket will be to create a new track, tentatively called "clean" for builds that we want to require to be 100% clean. For builds that are more than experimental, but people don't want to enforce 100% clean status, they could continue to use nightly. When a nightly build is clean, we can promote it. Part of this would also be to not notify people of failures on the nightly track anymore.
Please comment if you would prefer a different strategy. The goal is to establish an expectation that certain builds must always pass. If they aren't passing, they need to move to a different track, the build needs to be modified, or hopefully in most cases, the defect reflected in the failure will be fixed.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/701Why does TriBITS' ETI add Nodes to list of manglings / typedefs, even when I ...2016-10-12T17:32:39ZJames WillenbringWhy does TriBITS' ETI add Nodes to list of manglings / typedefs, even when I don't want them there?*Created by: mhoemmen*
I'm using the ETI system for KokkosKernels. I don't want the manglings and typedefs to include Node types, because those don't exist in KokkosKernels. I just want to strip those out. How do I do that? I even c...*Created by: mhoemmen*
I'm using the ETI system for KokkosKernels. I don't want the manglings and typedefs to include Node types, because those don't exist in KokkosKernels. I just want to strip those out. How do I do that? I even cleared out list_of_manglings and eti_typedefs at the top of tpetra/kernels/cmake/ExplicitInstantiationSupport.cmake, and the Node types came back!!!
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/562Cdash Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES OFF Question2016-12-10T03:21:22ZJames WillenbringCdash Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES OFF Question*Created by: MicheldeMessieres*
This question is about the intended behavior of Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES for cdash tests.
**Summary:**
Is the intention that EXTRA_CONFIGURE_OPTIONS can be used to turn off Trilinos_ENABLE_...*Created by: MicheldeMessieres*
This question is about the intended behavior of Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES for cdash tests.
**Summary:**
Is the intention that EXTRA_CONFIGURE_OPTIONS can be used to turn off Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES? I think this is the intention but the current setup seems to override this with a hard coded ON setting in TribitsCTestDriverCore.cmake.
This apparently means we cannot run a manual configuration build with Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES OFF which will behave identically to a cdash test run with Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES OFF.
**Details:**
TribitsCTestDriverCore.cmake explicitly sets this value to ON:
SET(${PROJECT_NAME}_ENABLE_ALL_OPTIONAL_PACKAGES ON)
Then package dependencies are calculated which depend on that value:
TRIBITS_ADJUST_AND_PRINT_PACKAGE_DEPENDENCIES()
Then EXTRA_CONFIGURE_OPTIONS are applied. I believe EXTRA_CONFIGURE_OPTIONS is the proper place we would want to turn Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES off but the above sequence means that the dependencies are calculated before reading this value.
An example would be running a cdash test with Zoltan2 and Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES set OFF in EXTRA_CONFIGURE_OPTIONS.
This will still result in attempts to build Thyra which would not occur for a manual configuration build. Note this then leads to some build errors for cdash only which I haven't looked into yet but I expect are directly related to this setting.
Amending my own comment here: Simply removing the hard-coded Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES=ON setting probably does not work as expected - I will have to investigate that further.
There are only a few cases of EXTRA_CONFIGURE_OPTIONS using Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES OFF currently in the repo.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/545PyTrilinos library being exported when it shouldn't be2016-12-13T03:33:26ZJames WillenbringPyTrilinos library being exported when it shouldn't be*Created by: bmpersc*
Bill Spotz reported that the export system for Trilinos is exporting the PyTrilinos library which is a problem since it depends on the python library. This causes linking errors when people use find_package(Trilino...*Created by: bmpersc*
Bill Spotz reported that the export system for Trilinos is exporting the PyTrilinos library which is a problem since it depends on the python library. This causes linking errors when people use find_package(Trilinos) to get all the necessary information for Trilinos. The PyTrilinos library is in the list of Trilinos libraries, but it won't ever link. The sticking point here is that this library needs to be installed to work properly, but should not be in the export files.
I'm not sure of the right way to solve this. Should this be a special option passed in to the tribits_add_library? would doing that have impact on linking other things that are currently working? Maybe this should be a post processing step stripping it out for only the export. We'll need to look into the right way to do this.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/541Many automated tests are not appearing on the dashboard2016-08-15T17:04:38ZJames WillenbringMany automated tests are not appearing on the dashboard*Created by: jhux2*
@tawiesn @aprokop @bartlettroscoe The MueLu nightly dashboard is no longer reporting tests from our two main test machines, geminga and enigma. The tests from those two machines last appeared on August 1st. I don't...*Created by: jhux2*
@tawiesn @aprokop @bartlettroscoe The MueLu nightly dashboard is no longer reporting tests from our two main test machines, geminga and enigma. The tests from those two machines last appeared on August 1st. I don't know if it's related, but there was an automated tribits snapshot into Trilinos on that same day. Below is an error reported from tribits on geminga that appears to be related this issue.
```
Traceback (most recent call last):
File
"/home/aprokop/code/trilinos-test/trilinos/cmake/ctest/drivers/geminga/../cron_driver.py",
line 23, in <module>
tdd_driver.run_driver(this_path, repo_path)
File
"/data/code/trilinos-test/trilinos/cmake/tribits/dashboard_driver/tdd_driver.py",
line 271, in run_driver
"CTEST_BINARY_DIRECTORY" : tddDashboardRootDir+"/TDD_BUILD",
File
"/data/code/trilinos-test/trilinos/cmake/tribits/dashboard_driver/tdd_driver.py",
line 182, in invoke_ctest
extraEnv = environment
File
"/data/code/trilinos-test/trilinos/cmake/tribits/dashboard_driver/../python_utils/GeneralScriptSupport.py",
line 469, in echoRunSysCmnd
print(" Appending environment:" + extraEnv + "\n")
TypeError: cannot concatenate 'str' and 'dict' objects
Ending nightly Trilinos development testing on geminga: Fri Aug 5
03:00:02 MDT 2016
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/536Setup testing for intel 162016-08-30T16:25:46ZJames WillenbringSetup testing for intel 16*Created by: bmpersc*
Need to setup testing using intel 16 compilers to support KNL platforms.
*Created by: bmpersc*
Need to setup testing using intel 16 compilers to support KNL platforms.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/494Trilinos_ENABLE_FORTRAN=OFF still complains that it can't find Fortran compiler2016-07-13T13:36:28ZJames WillenbringTrilinos_ENABLE_FORTRAN=OFF still complains that it can't find Fortran compiler*Created by: leonavery*
I'm trying to build trilinos on a Mac, thus without Fortran. I thought this would be straightforward. I start with `cmake -D Trilinos_ENABLE_FORTRAN=OFF trilinos-12.6.3-Source`, which creates a bunch of output th...*Created by: leonavery*
I'm trying to build trilinos on a Mac, thus without Fortran. I thought this would be straightforward. I start with `cmake -D Trilinos_ENABLE_FORTRAN=OFF trilinos-12.6.3-Source`, which creates a bunch of output that I attach below. The key point, though, is that it ends with
```
CMake Error at cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1669 (ENABLE_LANGUAGE):
No CMAKE_Fortran_COMPILER could be found.
Tell CMake where to find the compiler by setting either the environment
variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
path to the compiler, or to the compiler name if it is in the PATH.
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
-- Configuring incomplete, errors occurred!
See also "/Users/lavery/Documents/OneDrive/fenics/CMakeFiles/CMakeOutput.log".
See also "/Users/lavery/Documents/OneDrive/fenics/CMakeFiles/CMakeError.log".
```
I also tried to fool it with CMAKE_Fortran_COMPILER=/usr/bin/true, but it's too smart for that.
So how do I build without Fortran? I assume the existence of the Trilinos_ENABLE_FORTRAN=OFF option means this is supposed to be possible -- what am I doing wrong?
Thanks.
[trilinos_cmake.TXT](https://github.com/trilinos/Trilinos/files/360057/trilinos_cmake.TXT)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/493Anasazi: BSD license?2016-07-12T17:56:47ZJames WillenbringAnasazi: BSD license?*Created by: mhoemmen*
@csiefer2 requested that I post the following issue, since he's having troubles logging into Github.
Anasazi reportedly still has an LGPL license. A customer requested a BSD license for Anasazi.
*Created by: mhoemmen*
@csiefer2 requested that I post the following issue, since he's having troubles logging into Github.
Anasazi reportedly still has an LGPL license. A customer requested a BSD license for Anasazi.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/492Anasazi: BSD license?2017-03-30T20:46:15ZJames WillenbringAnasazi: BSD license?*Created by: mhoemmen*
@csiefer2 asked me to post this issue since he's having trouble logging into Github.
Customer requests BSD license for Anasazi, which reportedly has an LGPL license.
*Created by: mhoemmen*
@csiefer2 asked me to post this issue since he's having trouble logging into Github.
Customer requests BSD license for Anasazi, which reportedly has an LGPL license.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/491create 12.8 release2016-09-27T17:03:07ZJames Willenbringcreate 12.8 release*Created by: bmpersc*
Following checklist below and updating as needed:
```
rev 2016/01
```
Creating a New Trilinos (Release) Branch with GIT
A GIT branch can be used to maintai...*Created by: bmpersc*
Following checklist below and updating as needed:
```
rev 2016/01
```
Creating a New Trilinos (Release) Branch 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:
1. 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/packages
git clone git@github.com:trilinos/CTrilinos
git clone git@github.com:trilinos/ForTrilinos
git clone git@github.com:trilinos/mesquite
git clone git@github.com:trilinos/moocho
git clone git@github.com:trilinos/optika
git clone git@github.com:trilinos/sundance
1. 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: git tag -a -m "<short message about tag>" <tag name>
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.
1. Create a branch
To create a branch, from anywhere in your clone type
Command: git branch <branch name>
For the Trilinos release version XYZ mentioned above, the branch name should be
trilinos-release-XYZ-branch.
1. 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: git checkout <branch name>
To verify that the preceding command was successful, type
Command: git branch
The branch you are on will have a '*' infront of it.
1. 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.
After making these changes you will want to configure in a directory outside of
the repository you are working in. This is to update the files that are
dependent on the Version.cmake file as well as any other updates that
may have been made.
Finally, git commit the changes. In the commit message, note that branch name
is listed.
1. 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: git tag -a -m "<short message about tag>" <initial tag name>
For the Trilinos release version XYZ mentioned above, the initial tag name
should be initial-trilinos-release-XYZ-branch.
1. 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: git push origin <local branch name>:<public branch name>
This will push the branch named <local branch name> and the new commits on it
from your clone to origin with the name <public branch name>. Note that you can
rename the branch by giving a different name for <public branch name>, 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: git push --tags
1. 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/<name of branch>
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 <name of branch>
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 <name of tag>
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/489Remove redundant TriBITS includes in CMakeLists.txt files2016-12-01T14:24:56ZJames WillenbringRemove redundant TriBITS includes in CMakeLists.txt files*Created by: bartlettroscoe*
**Next Action Status:**
Changes accepted for SEACAS github repo. Changes for native Trilinos packages pushed. Next: Wait for STK to make changes in native repo and Kokkos to accept PR ...
**CC:** @trilin...*Created by: bartlettroscoe*
**Next Action Status:**
Changes accepted for SEACAS github repo. Changes for native Trilinos packages pushed. Next: Wait for STK to make changes in native repo and Kokkos to accept PR ...
**CC:** @trilinos/framework
**Description**
A long time ago, TriBITS added all the includes needed to process project, repository, and package files to the TriBITS.cmake file. This avoids the need to include the same files over and over again in user `*.cmake` and `CMakeLists.txt` files. This removes clutter and speeds up configures.
There is a single script in TriBITS that automatically does this upgrade:
TriBITS/refactoring/remove_std_tribits_includes_r.sh
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/482Set up robust portable pre-push and post-push CI tools and process based on t...2017-09-14T20:30:50ZJames WillenbringSet up robust portable pre-push and post-push CI tools and process based on the SEMS Dev Env*Created by: bartlettroscoe*
**Next Action Status:**
New CI build is pushed to 'develop', new post-push CI server is running, and new checkin-test-sem.sh script ready for more testing and review ... Note going to pursue other extensi...*Created by: bartlettroscoe*
**Next Action Status:**
New CI build is pushed to 'develop', new post-push CI server is running, and new checkin-test-sem.sh script ready for more testing and review ... Note going to pursue other extensions (e.g. mac OSX, tcsh, etc.). See https://github.com/trilinos/Trilinos/issues/482#issuecomment-266124179. Next: Leave in review til 1/1/2017 then close.
**Blocked By:** #158, #410, #362
**Blocking:** #380
**Related To:** #370, #475, #476
**CC:** @trilinos/framework
**Description:**
Trilinos has not had an effective pre-push CI development process for many years. When the checkin-test.py script was first created (back in 2008 or so), the primary stack of packages was based on Epetra and the main external dependencies were C/C++/Fortran compilers and BLAS and LAPACK. Those dependencies and the major Trilinos customers at the time were used to select the initial set of Primary Tested (initially called Primary Stable) packages that is being used to this day. However, since that time, many new Trilinos packages have been added and important Trilinos customers are relying on many of these newer packages (e.g. SEACAS, STK, Tpetra, Phalanx, Panzer, etc.). In addition, these new Trilinos packages require more dependencies than just BLAS and LAPACK and now TPLs like Boost, HDF5, NetCDF, ParMETIS, SuperLU and others used by Trilinos are also very important to many Trilinos customers.
Another problem with the current pre-push CI testing processes with Trilinos is that Trilinos developers have a variety of different types of machines, OSs, versions of compilers, TPL implementations, etc. that they use to develop on and push changes for Trilinos. This has resulted in people who tried to use the checkin-test.py script to suffer failed pushes due to failing tests on their machine not triggered by their changes. In contract, projects that have a uniform pre-push CI testing env don't experience these types of problems. One example of such a project is CASL VERA that uses TriBITS and the checkin-test.py script and has a set of uniform development machines where developers almost never see tests that fail in their build of the code that passed on another developer's build. Therefore, the only failed builds and tests are due to their own local changes. In that project, there is no trepidation to running the checkin-test.py script and everyone uses it uniformly for nearly every push.
Another problem with the current CI testing process for Trilinos is that the post-push CI server that posts to CDash enables a different set of packages and TPLs from what the pre-push CI build does (and of course uses different compilers, MPI, etc.). Therefore, a CI build/test failure seen on CDash may not be seen with the checkin-test.py script locally and visa vera. This makes it difficult for developers to determine if the failures they are seeing on their own machine are due to their local changes or due differences with the env on their machine compared to the machine running the CI build posting to CDash, if it is due to a different set of enabled packages and TPL or something else.
As a result, the stability of the main Trilinos development branch (now the 'develop' branch, see #370) has degraded from what it was 5+ years ago. This is a problem because Trilinos needs to have a more stable 'develop' branch in order to more frequently update from the 'develop' branch to the 'master' branch (see #370).
This story is to address all of these shortcomings of the current Trilinos CI testing process. The new SEMS Dev Env (#158) provides an opportunity to create a fairly portable (at least for SNL staff members) uniform pre-push and post-push CI testing environment for the first time.
Here is the plan for setting up a more effective CI process based on the SEMS Dev Env, the checkin-test.py script, and CTest/CDash:
1. **Select a standard pre-push CI build env based on the SEMS Dev Env:** Currently, GCC 4.7.2 and OpenMPI 1.6.5 are being used for the post-push CI build that posts to CDash. These selections should be reexamined and potentially changed. This will be used to create a standard `load_ci_sems_dev_env.sh` script, which just calls the `local_sems_dev_env.sh` script with the selections.
2. **Select an expanded/revised set of Primary Tested (PT) packages and TPLs:** This revised set should be based on the most important packages and TPLs to current Trilinos customers. Any important TPL not already supported by the SEMS Dev Env may need to be added (i.e. to the Trilinos space under the /projects/ NFS mount). Revising the set of PT packages and TPLs is being addressed in #410.
3. **Set up a standard checkin-test-sems.sh script that all Trilinos developers can use to push changes to the Trilinos 'develop' branch:** This should automatically load the correct standard SEMS Dev Env by sourcing `load_ci_sems_dev_env.sh`. This should likely only run a single build of Trilinos to speed up the testing/push process. (If there is a single build is would likely include `-DTPL_ENABLE_MPI=ON -DCMAKE_BULD_TYPE=RELEASE -DTriinos_ENABLE_DEBUG=ON -DBUILD_SHARED_LIBS=ON -DTrilinos_ENABLE_EXPLICIT_INSTANTIATION=ON -DTrilinos_ENABLE_FLOAT=OFF -DTrilinos_ENABLE_COMPLEX=OFF`. See #362 about turning off float and complex gy default.)
4. **Change the main post-push CI server that posts to CDash to use the exact same build as the default builds for the checkin-test-sems.sh script:** This is needed to catch the violations of the [additive test assumption of branches](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#bookmark=id.d1jneh8ubsyn). This can also be used to alert Trilinos developers when there are failures in the standard CI build or to verify that failures they are seeing are not their doing. If other post-push CI builds are desired, like non-MPI serial and full release builds, then those can be added as extra CI builds (we just need extra machines for that).
After this Story is complete, then we can create new Stories to get Trilinos developers to use the checkin-test-sems.sh script and to commit to keeping the CI build(s) 100% all the time with "Stop the Line" urgency to fix.
**Definition of Done:**
- An initial implementation for `load_ci_sems_dev_env.sh` and `checkin-test-sems.sh` that provides a viable CI build based on the SEMS Dev Env.
- Documentation for `load_ci_sems_dev_env.sh` and `checkin-test-sems.sh` has been written and has been reviewed by a few Trilinos developers.
- The post-push CI build of Trilinos uses the same `load_ci_sems_dev_env.sh` env and the same default build(s) as defined in the `checkin-test-sems.sh` script.
- Review the setup and documentation for the `checkin-test.py` script itself to determine what improvements that might help with usability and adoption.
**Decisions that need to be made:**
- What default timeout should be selected for pre-push tests (e.g. 3 minutes)?
- Should there just be an MPI_RELEASE_DEBUG_SHARED default build or also some serial build listed in --default-builds?
- What version of GCC and OpenMPI should be used?
- What other set of TPLs really should be added beyond what is provided in the SEMS Dev Env (e.g. a 64-bit build of Scotch without pthreads enabled, see [this comment in #476](https://github.com/trilinos/Trilinos/issues/476#issuecomment-230135162)).
- ???
**Tasks:**
1. Create drafts for `load_ci_sems_dev_env.sh` and `checkin-test-sems.sh` [Done]
2. Discuss this Story at a Trilinos Leaders Meeting Done]
3. Work #410 to select the updated set of PT packages and TPLs [Done]
4. Work #362 to disable float and complex by default [Done]
5. Select the new set (or just one) `--default-builds` for the `checkin-test.py` and therefore the `checkin-test-sems.sh` script" [Done]
- Make updates to Trilinos and checkin-test.py script on branch `better-ci-build-482` ... IN PROGRESS ...
- Get proposed changes reviewed (quickly) [Done]
- Create wiki documentation for usage `checkin-test-sems.sh` [Done]
- Commit changes to 'develop' branch [Done]
6. Create a new post-push CI build on crf450 that uses the identical CI build as `checkint-test-sems.py --local-do-all` [Done]
- Set up cron job or Jenkins job to run the build [Done]
- Run the CI build for several days and have people review it [Done]
8. Have updated CI process and documentation reviewed ... In Progress ...
9. Update the existing Jenkins CI build to use the new CI build and then remove the CI build on crf450 ...
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/483Cdash is backed up again2016-07-26T19:38:04ZJames WillenbringCdash is backed up again*Created by: bmpersc*
our cdash installation is backed up by about a day again. It looks like this started saturday night. I'm working on getting it processing again.
*Created by: bmpersc*
our cdash installation is backed up by about a day again. It looks like this started saturday night. I'm working on getting it processing again.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/479Domi web presence missing2016-07-01T13:56:34ZJames WillenbringDomi web presence missing*Created by: bmpersc*
The Domi package doesn't have any pages on the Trilinos.org site currently. Bill Spotz sent the following email regarding Domi's web presence.
Jim, Brent,
I assume this just got buried in the normal course of thi...*Created by: bmpersc*
The Domi package doesn't have any pages on the Trilinos.org site currently. Bill Spotz sent the following email regarding Domi's web presence.
Jim, Brent,
I assume this just got buried in the normal course of things, so I am going to nag again. Domi is not a listed package on the trilinos.org site, but it is officially released, so it should be. I don't really read perl, so it isn't obvious to me if I/we modify doc/build_docs.pl or some other database-type file to do this. Domi has a doc/build_docs script, but that doesn't seem to be sufficient. What else needs to be done?
Thanks,
Bill
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/472release 12.6.4 bug fix tarball2016-07-22T22:14:36ZJames Willenbringrelease 12.6.4 bug fix tarball*Created by: bmpersc*
There are a number of patches to 12.6 that need to be released including one fix that is needed for issue #469.
*Created by: bmpersc*
There are a number of patches to 12.6 that need to be released including one fix that is needed for issue #469.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/471Cdash is not showing results2016-06-29T14:14:48ZJames WillenbringCdash is not showing results*Created by: bmpersc*
Cdash doesn't seem to be showing its results. However, the checking I've done indicates that the submissions have been received and are not backed up. It is unclear why they are not showing on the dashboard. I will...*Created by: bmpersc*
Cdash doesn't seem to be showing its results. However, the checking I've done indicates that the submissions have been received and are not backed up. It is unclear why they are not showing on the dashboard. I will need to dig into this more