Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-08-15T01:35:32Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/440Switch to 'develop'/'master' branch in all repos listed in ExtraRepositoriesL...2018-08-15T01:35:32ZJames WillenbringSwitch to 'develop'/'master' branch in all repos listed in ExtraRepositoriesList.cmake*Created by: bartlettroscoe*
## Next Action Status:
???
**Blocked By:** #370, #176, #452
## Description:
As described in [this comment](https://github.com/trilinos/Trilinos/issues/370#issuecomment-224391677) in #370, the cu...*Created by: bartlettroscoe*
## Next Action Status:
???
**Blocked By:** #370, #176, #452
## Description:
As described in [this comment](https://github.com/trilinos/Trilinos/issues/370#issuecomment-224391677) in #370, the current implementation of the `TRIBITS_CTEST_DRIVER()` function will clone and use the 'master' branch of the extra repos even if `Trilinos_BRANCH=develop` or `trilinos-release-X-Y-branch`, etc. That is not consistent with treating this set of repos as "one big repo".
Therefore, this story is to switch all of the extra repos listed in Trilinos/cmake/ExtraRepositoriesList.cmake over to the 'develop'/'master' workflow that will be released or used by outside users. Any extra repo that is not going to switch over to the 'develop'/'master' workflow should not be listed in that file and should not be part of automated testing of Trilinos or Trilinos releases. More can be discussed about this but that basics are simple.
## Tasks:
1. Implement TriBITSPub/TriBITS#130 in TriBITS (This will result in `Trilinos_BRANCH=<branch>` getting checked out in each extra repo as well as the base Trilinos repo.) **[DONE]**
2. Determine what extra repos currently listed in ExtraRepositoriesList.cmake should continue being tested and perhaps released and which should not.
3. For those repos listed in ExtraRepositoriesList.cmake (i.e. that will continue to be tested and perhaps released), add a 'develop' branch.
4. Transition to the 'develop'/'master' workflow for all of the extra repos listed in ExtraRepositoriesList.cmake (in one push to the Trilinos 'develop' branch):
a. Update 'develop' branch from 'master' branch in all these extra repos and then lock down 'master' branch like for the main Trilinos git repo in #370.
b. Update the process that updates the Trilinos 'develop' branch to the 'master' branch also update from the 'develop' to the 'master' branches in these extra repos as well.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/380Improve testing for updating from 'develop' branch to 'master' branch by quer...2018-03-01T22:52:35ZJames WillenbringImprove testing for updating from 'develop' branch to 'master' branch by querying CDash results*Created by: bartlettroscoe*
**Next Action Status:**
Waiting for #370 to be completed before getting started on this ...
**Blocked By:** #370
**CC**: @jwillenbring, @bmpersc, @mhoemmen, @trilinos/framework
**Description:**
...*Created by: bartlettroscoe*
**Next Action Status:**
Waiting for #370 to be completed before getting started on this ...
**Blocked By:** #370
**CC**: @jwillenbring, @bmpersc, @mhoemmen, @trilinos/framework
**Description:**
The Story #370 implemented the initial transition to the 'develop'/'master' branch workflow using just a simple automated job that just does one build with the checkin-test.py script and then pushes the updated 'master' branch. This is a follow-on Story to put the infrastructure and the process in place to beef up the level of testing that needs to pass before updating the 'master' branch. The approach will be to take advantage of the new CDash API that allows you to download CDash query results as a JSON data-structure and then use a Python script to inspect it and make sure all of the targeted builds and packages all passed.
This has already been implemented for CASL VERA in the Python script `vera_cdash_pass_fail.py`. This script is run as:
```
$ cd VERA/
$ ./cmake/ctest/drivers/vera_cdash_pass_fail.py --date=2016-04-28
…
Getting data from:
https://casl-dev.ornl.gov/testing/api/v1/index.php?project=VERA&date=2016-04-28&filtercount=4&showfilters=1&filtercombine=and&field1=groupname&compare1=61&value1=Nightly&field2=subprojects&compare2=92&value2=VUQCore&field3=subprojects&compare3=92&value3=VUQDemos
VERA builds failed!
Error, the build {u'buildname': u'Linux-GCC-4.8.3-MPI_RELEASE_SHARED_HEAVY', u'test': {u'fail': 2, u'timefull': 44707, u'time': u'12h 25m 7s ', u'notrun': 0, u'pass': 1750}, … } failed!
…
FINAL: One of the VERA or VERADriver builds on 2016-04-28 FAILED
```
This script uses the reusable Python module:
```
tribits/ci_support/CDashQueryPassFail.py
```
The script `vera_cdash_pass_fail.py` does one query of the `VERA` CDash project and one of the `VERADriver` CDash project (created using the TriBITS Dashboard Driver (TDD) system). The `VERA` CDash query is shown above and it is examined to make sure that all of the expected builds are present and that there are no failing configures, builds or tests. The `VERADriver` query is done to make sure that all of the outer CTest driver builds ran and there was no failures (e.g. timeouts). Without querying the `VERADriver` project to make sure that none of the CTest drivers timed out, then having all passing `VERA` builds is not sufficient (because packages may have never been tested).
Because Trilinos uses Jenkins to run CTest build drivers, a query of Jenkins may be needed to ensure that none of the selected builds timed out. However, it appears that Jenkins supports a [remote API](https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API) so developing queries of Jenkins should be possible as well.
**Tasks:**
1. Upgrade the Trilinos CDash server to a current version that supports the new CDash API interface. (NOTE: This might also require upgrading the server hardware and env so that it can handle the required volume of Trilinos CDash submits.)
2. Develop a Python script `trilinos_cdash_pass_fail.py` that will run and inspect one or more queries of Trilinos CDash project and return false if any of these queries show failures. Also, do queries of the Jenkins CDash drivers to make sure that the outer CTest driver invocations don't timeout or otherwise fail.
3. Select a (small) initial set of Trilinos builds and set of packages in one or more CDash queries that must pass before updating the 'master' branch from the 'develop' branch. (NOTE: Adding these extra builds are likely to be separate stories. The story will be just to set up the infrastructure to query CDash correctly and get just a small number of extra builds in the initial set. Every new build you add creates "value" and can therefore be its own Story.)
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/374Create a list of supported compilers/ TPLs2016-05-20T21:47:02ZJames WillenbringCreate a list of supported compilers/ TPLs*Created by: jwillenbring*
@trilinos/framework @jhux2 @crtrott
At the 2016 Trilinos Spring Developer meeting it was mentioned that a list of supported compilers/TPLs would be useful. This has been mentioned before. Maintaining this li...*Created by: jwillenbring*
@trilinos/framework @jhux2 @crtrott
At the 2016 Trilinos Spring Developer meeting it was mentioned that a list of supported compilers/TPLs would be useful. This has been mentioned before. Maintaining this list would be difficult. At the meeting, it was suggested that perhaps the current CDash builds would represent the supported versions. However, digging in and finding all TPL versions would be difficult.
Another suggestion was to maintain a shorter list of versions at least known to work. This would also take effort to maintain, but potentially wouldn't be as bad.
I would like to have a little more discussion in this ticket before deciding on a specific path-forward. Feel free to mention other interested people.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/372Revise new developer checklist2016-10-05T18:59:41ZJames WillenbringRevise new developer checklist*Created by: jwillenbring*
**CC:** @trilinos/framework
**Description:**
The new developer checklist needs to be revised. In particular, to be up-to-date with the move to GitHub. Mentors can now decide when new students should get pus...*Created by: jwillenbring*
**CC:** @trilinos/framework
**Description:**
The new developer checklist needs to be revised. In particular, to be up-to-date with the move to GitHub. Mentors can now decide when new students should get push access.
https://software.sandia.gov/trilinos/developer/sqp/checklists/newTrilinosDeveloper201508.txt
**Tasks:**
1. Initial update of checklist [Done]
2. Have set out for review and collect updates ... IN PROGRESS ...
3. Publish checklist to final location ...
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/361Make Explicit Template Instantiation (ETI) the default with Trilinos2016-09-16T18:51:09ZJames WillenbringMake Explicit Template Instantiation (ETI) the default with Trilinos*Created by: bartlettroscoe*
**Description:**
This story is to do the planning and the work necessary to make Trilinos build with explicit template instantiation (ETI) enabled by default. If you don't have ETI enabled but instead use ...*Created by: bartlettroscoe*
**Description:**
This story is to do the planning and the work necessary to make Trilinos build with explicit template instantiation (ETI) enabled by default. If you don't have ETI enabled but instead use the default implicit template instantation process, the build times for Trilinos can be massive. In addition, some compilers (e.g. Intel) will even crash when you try to use implicit template instantiation with Trilinos.
Whenever a Trilinos user complains about build times or the compiler crashing, our first response is to tell them to enable ETI and every Trilinos developer and experienced user pretty much pretty exclusively enables ETI.
**Tasks:**
???
Reduce build times for Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/268Revise "Getting Started" section of Trilinos.org website2016-04-05T03:36:36ZJames WillenbringRevise "Getting Started" section of Trilinos.org website*Created by: maherou*
The "Getting Started" section of Trilinos documentation needs revision.
It also needs better visibility from the main trilinos.org page and from the GitHub site.
Specific changes:
- Provide a short write up about h...*Created by: maherou*
The "Getting Started" section of Trilinos documentation needs revision.
It also needs better visibility from the main trilinos.org page and from the GitHub site.
Specific changes:
- Provide a short write up about how to manage debug vs. release builds when using TriBITS.
- Update the Cmake reference content.
Put it on our Trilinos GitHub Quickstart webpage.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/251Remove MeshingGenie2016-03-30T16:40:33ZJames WillenbringRemove MeshingGenie*Created by: nschloe*
As highlighted in bug #247, MeshingGenie is obsolete and should be removed from Trilinos.
*Created by: nschloe*
As highlighted in bug #247, MeshingGenie is obsolete and should be removed from Trilinos.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/182Implement Project-Wide Issue Management System2017-02-09T01:19:51ZJames WillenbringImplement Project-Wide Issue Management System*Created by: jwillenbring*
@maherou @bartlettroscoe @trilinos/framework
We need to implement a project-wide issue management system. It must work for both development-funded efforts, which are being required to apply more rigor to thei...*Created by: jwillenbring*
@maherou @bartlettroscoe @trilinos/framework
We need to implement a project-wide issue management system. It must work for both development-funded efforts, which are being required to apply more rigor to their issue tracking efforts, and for research-funded efforts, which will have more flexibility in use of the issue tracker. The system should have the following characteristics:
Usable: The system should not impose a heavy burden on Trilinos developers. Developers are familiar with a basic issue tracking system, and generally comfortable with using one. The extra requirements for the system should not require large additional time investments. For example, when filing or accepting a ticket, applying labels, estimating effort, assigning, etc shouldn't take more than a few extra minutes.
Well-defined: The process should be documented. Because of the traceability requirement listed below, it is important that certain parts of the process be followed carefully.
Traceable: A primary objective of the new issue management system is that customer requirements be traceable all the way to implementation and delivery. Requirements should be translated into specific issues in an epic-story-task hierarchy to support this traceability for large deliverables.
Visible: Current status should be easily visible for stakeholders, including customers, users, developers, and management.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/113TriBITS picking up the wrong boost libraries.2016-02-25T15:41:18ZJames WillenbringTriBITS picking up the wrong boost libraries.*Created by: bathmatt*
Building STK_classic is finding the wrong boost. I set to a specific version of boost and try to compile and I'm getting missing symbols. The include is being propagated but the libs are not even thoush I am set...*Created by: bathmatt*
Building STK_classic is finding the wrong boost. I set to a specific version of boost and try to compile and I'm getting missing symbols. The include is being propagated but the libs are not even thoush I am setting both
-D TPL_Boost_LIBRARY_DIRS:FILEPATH="${BOOST_BASE_DIR}/lib" \
and
-D TPL_Boost_LIBRARIES="${BOOST_BASE_DIR}/lib/libboost_program_options.so;${BOOST_BASE_DIR}/lib/libboost_system.so" does not
I still get the system libs.
/home/projects/x86-64-haswell-nvidia/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.7/bin/mpicxx -std=c++11 -g -O0 CMakeFiles/STKClassic_stk_algsup_unit_tests.dir/UnitTestAlgorithmRunner.cpp.o CMakeFiles/STKClassic_stk_algsup_unit_tests.dir/UnitTestCudaMgr.cpp.o CMakeFiles/STKClassic_stk_algsup_unit_tests.dir/UnitTestMain.cpp.o CMakeFiles/STKClassic_stk_algsup_unit_tests.dir/UnitTest_helpers.cpp.o -o STKClassic_stk_algsup_unit_tests.exe -rdynamic ../stk_algsup/libstkclassic_algsup.a ../../stk_mesh/stk_mesh/fixtures/libstkclassic_mesh_fixtures.a ../../stk_mesh/stk_mesh/fem/libstkclassic_mesh_fem.a ../../stk_mesh/stk_mesh/base/libstkclassic_mesh_base.a ../../stk_util/stk_util/unit_test_support/libstkclassic_util_unit_test_support.a ../../stk_util/stk_util/parallel/libstkclassic_util_parallel.a ../../stk_util/stk_util/diag/libstkclassic_util_diag.a ../../stk_util/stk_util/environment/libstkclassic_util_env.a ../../stk_util/stk_util/util/libstkclassic_util_util.a ../../../../seacas/libraries/exodus/cbind/libexodus.a ../../../../fei/support-Trilinos/libfei_trilinos.a ../../../../fei/base/libfei_base.a ../../../../belos/tpetra/src/libbelostpetra.a ../../../../belos/epetra/src/libbelosepetra.a ../../../../belos/src/libbelos.a ../../../../ml/src/libml.a ../../../../galeri/src-epetra/libgaleri-epetra.a ../../../../tpetra/core/ext/libtpetraext.a ../../../../tpetra/core/inout/libtpetrainout.a ../../../../tpetra/core/src/libtpetra.a ../../../../tpetra/kernels/src/libtpetrakernels.a ../../../../kokkos/algorithms/src/libkokkosalgorithms.a ../../../../kokkos/containers/src/libkokkoscontainers.a ../../../../tpetra/classic/LinAlg/libtpetraclassiclinalg.a ../../../../tpetra/classic/NodeAPI/libtpetraclassicnodeapi.a ../../../../tpetra/classic/src/libtpetraclassic.a ../../../../ifpack/src/libifpack.a ../../../../amesos/src/libamesos.a ../../../../epetraext/src/libepetraext.a ../../../../seacas/libraries/ioss/src/init/libIonit.a ../../../../seacas/libraries/ioss/src/transform/libIotr.a ../../../../seacas/libraries/ioss/src/heartbeat/libIohb.a ../../../../seacas/libraries/ioss/src/generated/libIogn.a ../../../../seacas/libraries/ioss/src/pamgen/libIopg.a ../../../../seacas/libraries/ioss/src/exo_fac/libIoexo_fac.a ../../../../seacas/libraries/ioss/src/exo_par/libIopx.a ../../../../seacas/libraries/ioss/src/exo_fpp/libIofx.a ../../../../seacas/libraries/ioss/src/exodus/libIoex.a ../../../../seacas/libraries/ioss/src/libIoss.a ../../../../seacas/libraries/exodus/cbind/libexodus.a -Wl,-Bstatic -lnetcdf -Wl,-Bdynamic -L/home/projects/x86-64-haswell-nvidia/netcdf-exo/4.3.3.1/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.7/lib -lnetcdf -L/home/projects/x86-64-haswell-nvidia/hdf5/1.8.15/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.7/lib -lhdf5_hl -lhdf5 -lz -ldl ../../../../pamgen/src/libpamgen_extras.a ../../../../pamgen/src/libpamgen.a ../../../../aztecoo/src/libaztecoo.a ../../../../triutils/src/libtriutils.a ../../../../epetra/src/libepetra.a ../../../../shards/src/libshards.a ../../../../zoltan/src/libzoltan.a -lm ../../../../sacado/src/libsacado.a ../../../../teuchos/kokkoscomm/src/libteuchoskokkoscomm.a ../../../../teuchos/kokkoscompat/src/libteuchoskokkoscompat.a ../../../../teuchos/remainder/src/libteuchosremainder.a ../../../../teuchos/numerics/src/libteuchosnumerics.a -L/home/projects/x86-64-haswell/lapack/3.5.0/gcc/4.8.4 -llapack -L/home/projects/x86-64-haswell/blas/20150602/gcc/4.8.4 -lblas ../../../../teuchos/comm/src/libteuchoscomm.a ../../../../teuchos/parameterlist/src/libteuchosparameterlist.a ../../../../teuchos/core/src/libteuchoscore.a ../../../../kokkos/core/src/libkokkoscore.a -lcudart -lcublas -lcufft -lboost_program_options -lboost_system -lmpi_usempi -lmpi_mpifh -lgfortran -lquadmath
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/87Address handling of CMAKE_BUILD_TYPE, -O0 for debug builds, etc.2016-07-14T18:47:58ZJames WillenbringAddress handling of CMAKE_BUILD_TYPE, -O0 for debug builds, etc.*Created by: bartlettroscoe*
It seems there is some confusion/unhappiness with the way that Trilinos (through TriBITS) is dealing with `CMAKE_BUILD_TYPE` and the insertion or not of -O0 for "Debug" (or "DEBUG") builds.
For the way the ...*Created by: bartlettroscoe*
It seems there is some confusion/unhappiness with the way that Trilinos (through TriBITS) is dealing with `CMAKE_BUILD_TYPE` and the insertion or not of -O0 for "Debug" (or "DEBUG") builds.
For the way the CMake and TriBITS manipulates compiler flags, see ["Selecting compiler and linker options"](https://trilinos.org/docs/files/TrilinosBuildReference.html#selecting-compiler-and-linker-options) in the [Trilinos Build Reference](https://trilinos.org/docs/files/TrilinosBuildReference.html).
On one hand, we want TriBITS (and therefore Trilinos) to keep with raw CMake behavior intact as much as possible (so that people who know CMake already will know how to work with Trilinos), but that would mean that -O0 would **not** show up in "Debug" builds. On the other hand, we should override default raw CMake behavior when raw CMake behavior it is actually counter-intuitive (in which case you would add -O0 to "Debug" builds). But then that gets TriBITS into the business of knowing how to set compiler flags for all compilers and on platforms. Do we want to step on the CMake's communities ties like this? Do we really want to own this?
This Issue Ticket is to log the discussion of this topic and potentially come up with some action to address this in a way that makes people (by some definition) happy.
**Tasks:**
1. Add `-DNDEBUG` to C and C++ RELEASE compiler flags by default for GCC (see [below](https://github.com/trilinos/Trilinos/issues/87#issuecomment-232754822)) [Done]
2. Add `-O0` to C, C++, and Fortran debug flags for Intel builds ...
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/45Download with mandatory sign-up2016-05-19T23:32:19ZJames WillenbringDownload with mandatory sign-up*Created by: nschloe*
There are many straightforward ways to get Trilinos nowadays:
- `git clone` from GitHub
- [download a release from GitHub](https://github.com/trilinos/Trilinos/releases)
- get it from [Debian](https://tracker.debia...*Created by: nschloe*
There are many straightforward ways to get Trilinos nowadays:
- `git clone` from GitHub
- [download a release from GitHub](https://github.com/trilinos/Trilinos/releases)
- get it from [Debian](https://tracker.debian.org/pkg/trilinos)
- get it from the [nightly PPA](https://launchpad.net/~nschloe/+archive/ubuntu/trilinos-nightly/)
Oh, and of course the [official download page](https://trilinos.org/download/) which [requires you to sign up before download](https://trilinos.org/oldsite/download/login.html?tid=tr12042bz2). Rather than helping the distribution of Trilinos, the sign-up hinders it. The gain that one supposedly gets from that is a user statistics, but in the light of the alternative download methods listed above, this statistic is practically worthless.
I suggest to remove the sign-up requirement from the download page.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/33build docs out-of-source2016-11-30T14:25:30ZJames Willenbringbuild docs out-of-source*Created by: nschloe*
Currently, the invocation of
```
doc/build_docs.pl
```
builds the entire documentation in-source, where it's hard to get rid of once built. This presents a difficulty, for example, when compiling for Debian...*Created by: nschloe*
Currently, the invocation of
```
doc/build_docs.pl
```
builds the entire documentation in-source, where it's hard to get rid of once built. This presents a difficulty, for example, when compiling for Debian. The docs, like the compiled object files, should be built outside of the source tree. (Perhaps even during the `make` process?)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/24duplicate TPL adapters2016-03-23T06:14:42ZJames Willenbringduplicate TPL adapters*Created by: nschloe*
In Trilinos, TriBits takes care of some of the TPL integration via the files in
```
cmake/tribits/common_tpls/FindTPL*.cmake
```
Their counterparts in
```
cmake/TPLs/FindTPL*.cmake
```
are redundant and should ...*Created by: nschloe*
In Trilinos, TriBits takes care of some of the TPL integration via the files in
```
cmake/tribits/common_tpls/FindTPL*.cmake
```
Their counterparts in
```
cmake/TPLs/FindTPL*.cmake
```
are redundant and should probably be removed.