Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2016-06-30T15:13:17Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/473Migrate checklists to GitHub Trilinos Developer site2016-06-30T15:13:17ZJames WillenbringMigrate checklists to GitHub Trilinos Developer site*Created by: jwillenbring*
**Next Action Status:**
Updating the new developer checklist ...
**CC:** @trilinos/framework
**Description:**
The process checklists need to be moved from the old developer website to the new Trilinos Dev...*Created by: jwillenbring*
**Next Action Status:**
Updating the new developer checklist ...
**CC:** @trilinos/framework
**Description:**
The process checklists need to be moved from the old developer website to the new Trilinos Developer GitHub wiki.
**Tasks:**
1. Update the new-developer checklist ... IN PROGRESS..
2. ???
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/321Using Ninja with nvcc_wrapper re-compiles sources every time2017-12-11T18:16:12ZJames WillenbringUsing Ninja with nvcc_wrapper re-compiles sources every time*Created by: bradking*
Discussion in #261 found the problem can be reproduced with stock CMake and Ninja, so I'm starting a new issue for it since it is independent of the custom (Fortran-supporting) CMake and Ninja versions reported th...*Created by: bradking*
Discussion in #261 found the problem can be reproduced with stock CMake and Ninja, so I'm starting a new issue for it since it is independent of the custom (Fortran-supporting) CMake and Ninja versions reported there. Here are steps to reproduce on Linux:
``` console
$ export PATH=/path/to/Trilinos/packages/kokkos/config:$PATH
$ export OMPI_CC=gcc-4.9
$ export OMPI_CXX=nvcc_wrapper
$ export NVCC_WRAPPER_DEFAULT_COMPILER=g++-4.9
$ export CC=mpicc CXX=mpicxx
$ mpicxx -showme:version
mpicxx: Open MPI 1.10.2 (Language: C++)
$ nvcc --version
...
Cuda compilation tools, release 7.0, V7.0.27
$ cmake --version
cmake version 3.5.2
$ (cd ../Trilinos; git rev-parse HEAD)
9289740d06a6b708e9fc75cad9e2b71615e6dd66
$ cmake ../Trilinos -GNinja -DTrilinos_ENABLE_Fortran=OFF -DTrilinos_ENABLE_Gtest=ON -DTPL_ENABLE_Matio=OFF
$ ninja commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o
[1/1] Building CXX object commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o
$ ninja -t deps commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o
commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o: #deps 1, deps mtime 1461877501 (VALID)
/tmp/tmpxft_00003d40_00000000-14_gtest-all.ii
$ ninja -d explain commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o
$ ninja -d explain commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o
ninja explain: output /tmp/tmpxft_00003d40_00000000-14_gtest-all.ii of phony edge with no inputs doesn't exist
ninja explain: /tmp/tmpxft_00003d40_00000000-14_gtest-all.ii is dirty
[1/1] Building CXX object commonTools/gtest/CMakeFiles/gtest.dir/gtest/gtest-all.cc.o
```
The compiler wrappers somehow use a temporary already-preprocessed `.ii` file as input to the `g++-4.9` call. This causes the `-MD` option to generate a depfile listing only the temporary file. Ninja records this dependency and then cannot find it on the next build.
**Tasks:**
1. Diagnose the problem [Done]
2. Postulate a solution ([see](https://github.com/trilinos/Trilinos/issues/321#issuecomment-215820056)) [Done]
3. Modify nvcc_wrapper to better generate dependencies for Ninja ([see](https://github.com/trilinos/Trilinos/issues/321#issuecomment-215820056)) ...
4. Verify working with Trilinos+Drekar build ...
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/452Decide on how to handle multi-repos with Trilinos both short-term and long-term2016-08-29T16:42:49ZJames WillenbringDecide on how to handle multi-repos with Trilinos both short-term and long-term*Created by: bartlettroscoe*
**Next Action Status:**
???
**CC:** @trilinos/framework
**Blocking:** #440, #176
**Description:**
When Trilinos was trimmed down and moved to GitHub, several extra repos were split out into their own r...*Created by: bartlettroscoe*
**Next Action Status:**
???
**CC:** @trilinos/framework
**Blocking:** #440, #176
**Description:**
When Trilinos was trimmed down and moved to GitHub, several extra repos were split out into their own repos like MOOCHO, Sundance, CTrilinos, ForTrilinos, Mesquite, etc. There was a plan for managing these extra repos using the support for extra repos added for TriBITS to support CASL VERA development in the Goolge Doc [Proposal for trimming down Trilinos repo](https://docs.google.com/document/d/1hbki9KN4ErCChWcvAFBnOsJcPLuDJtPi8xaNq3ETyRo/edit?usp=drive_web) which was started in late 2014 or so. Given that Trilinos was split up, I (@bartlettroscoe) assumed that the plan listed in that document was a reasonable approach to get these extra repos for inserted packages back into automated testing and for distribution in Trilinos releases (because CASL VERA has been doing this for years). Based on this assumption, I created the issue #176 to get this working for Trilinos, CCing the other Trilinos Framework team members. I think did some work on this approach and got many of these inserted packages back under automated testing and added full support for the usage of the TriBITS `clone_extra_repos.py` and `gitdist` scripts. However, my assumption that there was agreement to use the the TriBITS approached used by CASL VERA as an initial way to address multiple repositories in Trilinos was not founded. It seems that others did not agree with that decision.
Therefore, this Trilinos GitHub ticket is to drive and document the discussion of this topic and the decisions on how Triilnos should deal with multiple repos, both short-term and long-term.
https://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/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.