Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-01-06T17:44:29Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/176Add multi-repository support to Trilinos for inserted packages2017-01-06T17:44:29ZJames WillenbringAdd multi-repository support to Trilinos for inserted packages*Created by: bartlettroscoe*
**Next Action Status:**
Configure of MOOCHO, Mesquite, etc. fail due to wrong base directory. Next: Debug configure problems when running under CTest driver script.
**Blocked By:** #158
**Relates To:** SE...*Created by: bartlettroscoe*
**Next Action Status:**
Configure of MOOCHO, Mesquite, etc. fail due to wrong base directory. Next: Debug configure problems when running under CTest driver script.
**Blocked By:** #158
**Relates To:** SEMS JIRA Issue [TRIL-50](https://sems-jira.sandia.gov/browse/TRIL-50), #440, #452
**CC:** @bmpersc, @jwillenbring
**Description:**
As part of the effort to trim down the Trilinos git repo as part of the move to GitHub, several Trilinos packages (MOOCHO, CTrilinos, ForTrilinos, Sundance, Mesquite, etc.) were filtered out of the main Trilinos git repo and were given their own GitHub repos. The plan for adding them back into the automated builds is documented in the Google Doc [Proposal for trimming down Trilinos repo](https://docs.google.com/document/d/1hbki9KN4ErCChWcvAFBnOsJcPLuDJtPi8xaNq3ETyRo/edit#heading=h.k7j4h5jkz5en).
Note that all of the support for managing multiple repos already exists in TriBITS and has been used for CASL VERA development for many years. For an overview, see ["Multi-Repository Support"](https://tribits.org/doc/TribitsDevelopersGuide.html#multi-repository-support).
**Definition of Done:**
All Trilinos packages that were pulled out but still plan to be tested and released are back running under automated testing and will be automatically included in future releases (using `clone_extra_repos.py` and `gitdist`).
**Tasks:**
1. Add Trilinos packages back as ["Inserted Packages"](https://docs.google.com/document/d/1fLSz7FM8hzmIfr84jQ9B9-C7eXhdLBu0aUyXfKS3XCU/edit) (This is so that they will be defined as TriBITS packages in a way that does not interfere with other "Extra Packages" in "Extra Repos", e.g. through `-DTrilinos_EXTRA_REPOSITORIES=<repo0>,<repo1>,...`). See [below](https://github.com/trilinos/Trilinos/issues/176#issuecomment-220968040) [Done]
2. Add wiki page to Trilinos GitHub wiki site describing the handling of extra repos (e.g. `clone_extra-repos.py`, `gitdist`, etc.)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/172Create ATTBDevEnv.cmake module to automatically use loaded env for Advanced T...2017-04-18T18:45:13ZJames WillenbringCreate ATTBDevEnv.cmake module to automatically use loaded env for Advanced Technology Test Bed platforms*Created by: bartlettroscoe*
Just like we want to do for SEMS environments (see #158), we want to create a file called ATTBDevEnv.cmake (stands for Advanced Technology Test Bed Development Environment) that will define the TriBITS CMake...*Created by: bartlettroscoe*
Just like we want to do for SEMS environments (see #158), we want to create a file called ATTBDevEnv.cmake (stands for Advanced Technology Test Bed Development Environment) that will define the TriBITS CMake variables to find all of the right libraries and include directories when the ATTB environment is loaded.
The basic idea is that a developer will load a single module like:
```
$ module load devpack/openmpi/1.10.0/gcc/4.8.4/cuda/7.5.18
```
and that module will load a bunch of other modules. These modules will define a bunch of environment variables of the form `<TPLName>_ROOT` (where `<TPLName>` = `HDF5`, `METIS`, `PNETCDF`, etc.). Under these you would find:
```
${<TPLName>_ROOT}/include/
${<TPLName>_ROOT}/lib/
```
(or whereever the libraries exist).
In addition, the modules set up the variables pointing to the MPI compiler wrappers like `MPICC`, `MPICXX`, and `MPIFC`.
In addition, the top-level module would define the environment variable `ATTB_ENV` which would be set and will be non-empty when the env is loaded (later we can look at the value of `ATTB_ENV` to be able to point to different versions of the env). The goal behind the ATTB_ENV is that we would put in automatic logic like:
```
IF (NOT "${ENV{ATTB_ENV}}" STREQUAL "")
INCLUDE(<some-base>/ATTBDevEnv.cmake)
ENDIF()
```
The idea would be to have Trilinos (or even TriBITS in some smart way) run this block of code and be able to automatically pick up the dev env and set the TriBITS CMake TPL vars correctly so someone could just load the top-level module and then configure Trilinos with:
```
cmake -DTPL_ENABLE_MPI=ON -DTPL_ENABLE_Netcdf=ON ... \
-DTrilinos_ENABLE_SECACAS=ON -DTrilinos_ENABLE_Panzer=ON ... \
... \
${TRILINOS_DIR}
```
and it would automatically know where to find the include dirs and libraries for all of the TPLs enabled (implicitly or explicitly).
What makes this tricky is that the ATTB env is set up to only use static libraries. But they build all of these with `-fPIC` so you should still be able to build shared libraries in Trilinos and downstream.
CC list: @rppawlo, @bathmatt, @nmhamster
**Next Action Status**
Trilinos now automatically detects and sets up for ATTB dev env on `hansen` and `shiller`. Testing on other machine (see below) ...
**Tasks:**
1. Get configure scripts for Trilinos+Drekar [Done]
2. Create ATTBDevEnv.cmake that successfully configures and builds Trilinos+Drekar [Done]
3. Set up Trilinos+Drekar to automatically include ATTBDevEnv.cmake on ATTB machine `hansen` [Done]
4. Get ATTBDevEnv.cmake working on `shiller` [Done]
5. See about setting policy https://cmake.org/cmake/help/v3.5/policy/CMP0060.html, test on Shiller and Hanssen and require CMake 3.3+ …
6. Get working with `OMPI_CXX=nvcc_wrapper` on `hansen` and `shiller` ...
7. Add `-march=core-avx2` to `CMAKE_[C|CXX|Fortran]_FLAGS` to improve vectorization ...
8. Get ATTBDevEnv.cmake working on `shepard`:
- Module `devpack/openmpi/1.10.0/intel/16.1.056/cuda/none` is missing It is missing `BLAS_ROOT` and `LAPACK_ROOT` ...
9. Get ATTBDevEnv.cmake working on `white` ...
10. Get ATTBDevEnv.cmake working on `ride` ...
11. Test full Trilinos+Drekar configure on all ATTB machines:
- `hansen`
- `shiller`
- `shepard`
- `white`
- `ride`
- ???
12. Document configuration of Trilinos using ATTBDevEnv.cmake on "Heterogeneous Advanced Architecture Platforms (HAAPs)" wiki page ...
13. Set up Nightly builds posted to Trilinos CDash on ATTB platforms and hand over builds to SEMS team to run with Jenkins ...
Advanced Technology Test Bed Issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/158Create a SEMSDevEnv.cmake file to automatically use loaded SEMS dev env2016-12-10T03:52:02ZJames WillenbringCreate a SEMSDevEnv.cmake file to automatically use loaded SEMS dev env*Created by: bartlettroscoe*
**Next Action Status:**
Working and providing value as part of new checkin-test-sems.sh script and CI build (see #482)
**CC list:** @rppawlo, @bathmatt, @jgfouca, @jwillenbring, @gdsjaar, @trilinos/fra...*Created by: bartlettroscoe*
**Next Action Status:**
Working and providing value as part of new checkin-test-sems.sh script and CI build (see #482)
**CC list:** @rppawlo, @bathmatt, @jgfouca, @jwillenbring, @gdsjaar, @trilinos/framework
**Blocking:** #410, #370
**Description:**
This story will be to create a SEMSDevEnv.cmake file that once included (with -DTrilinos_CONFIGURE_OPTIONS_FILES=<path>/SEMSDevEnv.cmake), then TriBITS will automatically pick up the right compilers and TPL locations.
In addition, it would be desirable for the Trilinos configure to automatically pick up the loaded SEAMS env (like is done on the ATTB machines using the `ATTB_ENV` env var, see #172).
In addition to just providing the `SEMSDevEnv.cmake` module, this story will also scope out what might be useful for a standard Trilinos dev env. However, a new story will be created to refine what a new expanded Trilinos Primary Tested build of TPLs and Packages will look like.
**List of TPLs and other requirements needed for a standard Trilinos CI build:**
This following list is the current consensus for this the standard Trilinos CI build (this list is updated as consensus changes).
- CMake 3.5.2 (There are huge speed advantages in using CMake 3.5.2 vs. 2.8.11) ([see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-222986351))
- GCC 4.8.4 (@crtrott, [see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-207526974))
- OpenMPI 1.8.7 (@crtrott, [see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-207526974))
- Python 2.7.9 (the only version of 2.x, x > 6 provided by SEMS dev env)
- OpenMP (i.e. Pthreads) (@crtrott, [see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-207526974))
- BLAS and LAPACK, provided by system? ([see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-207500008))
- Boost v1.55.0? ([see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-227600114))
- Zlib 1.2.8 (the version provided by SEMS)
- HDF5 v1.8.12 (the version provided by SEMS, used by SEMS NetCDF 4.3.2)
- NetCDF 4.3.2? (the version provided by SEMS)
- ParMETIS v4.0.3 built with 32-bit index types (@kddevin, [see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-207566543))
- SuperLU 4.3 (used by several Trilinos packages)
- Scotch v6.0.3 built with 32-bit index types (@kddevin, [see](https://github.com/trilinos/Trilinos/issues/158#issuecomment-207566543))
**Tasks:**
1. Get opinions on what TPLs should be included in the `SEMSDevEnv.cmake` module (targeting a standard Trilinos pre-push CI build) [Done]
2. Write out `SEMSDevEnv.cmake` to automatically set up Compilers TPLs for a given loaded SEMS env (using `module load <avail>`) by reading env vars starting with `SEMS_`. (see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-229527446)) [Done]
3. Create a `load_sems_dev_env.sh` module that can be called as `source load_sems_dev_env.sh [<compiler-and-version>] [<openmpi-and-version>]`, for example `source load_sems_dev_env.sh gcc/4.9.2 openmpi/1.10.1` (where `<compiler-and-version>` and `<openmpi-and-version>` are given defaults if not provided). (see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-229527446)) [Done]
4. Test out on full shared lib MPI and serial builds of Trilinos with all Secondary Tested packages enabled that can be given this set of TPLs. (but forgot to enable Scott and ParMETIS TPLs, see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-229527446)) [Done]
5. Automatically load `SEMSDevEnv.cmake` if it is detected that the SEMS dev env is loaded. (see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-229527446)) [Done]
6. Enable Scotch and ParMETIS TPLs in shared lib build and test with packages that support them ... Zoltan and Zoltan2 tests fail as expected (see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-229999257) and #475 and #476) [Done]
7. Test and get working all-static builds (i.e. build static libs and use static TPL libs) ... see commit c334dd6 [Done]
8. Investigate issues with Scotch and ParMETIS ... SEMS provides inconsistent 32-bit Scotch and 64-bit ParMETIS (see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-230135927)) [Done]
9. Try to enable SuperLU 4.3 (see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-230485338)) [Done]
10. Finish documentation on [Trilinos GitHub Wiki](https://github.com/trilinos/Trilinos/wiki/SEMS-Dev-Env) (see [below](https://github.com/trilinos/Trilinos/issues/158#issuecomment-230569893)) [Done]
11. Have documentation and implementation reviewed (see [a](https://github.com/trilinos/Trilinos/issues/158#issuecomment-232864091), [b](https://github.com/trilinos/Trilinos/issues/158#issuecomment-233073800), [c](https://github.com/trilinos/Trilinos/issues/158#issuecomment-233136006), [d](https://github.com/trilinos/Trilinos/issues/158#issuecomment-233315765), [e](https://github.com/trilinos/Trilinos/issues/158#issuecomment-237663100), and [f](https://github.com/trilinos/Trilinos/issues/158#issuecomment-237746406)) ... Will fix any problems if they come up. [Done]Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/156Netcdf and HDF5 ordering2017-03-30T11:51:37ZJames WillenbringNetcdf and HDF5 ordering*Created by: ambrad*
[configure.txt](https://github.com/trilinos/Trilinos/files/147581/configure.txt)
I'm creating an issue to track the problem of netcdf and hdf5 lib ordering.
For the record, let's remember that order matters only fo...*Created by: ambrad*
[configure.txt](https://github.com/trilinos/Trilinos/files/147581/configure.txt)
I'm creating an issue to track the problem of netcdf and hdf5 lib ordering.
For the record, let's remember that order matters only for .a libs. If we have at least libnetcdf.so, then order doesn't matter.
In what follows I summarize what seem to be the key points. I specify SEACAS, Netcdf, and HDF5 as follows:
-D Trilinos_ENABLE_SEACAS:BOOL=ON \
-D TPL_ENABLE_X11:BOOL=OFF \
-D TPL_ENABLE_Matio:BOOL=OFF \
-D Trilinos_ENABLE_SEACASIoss:BOOL=ON \
-D Trilinos_ENABLE_SEACASExodus:BOOL=ON \
-D TPL_ENABLE_Netcdf:BOOL=ON \
-D Netcdf_INCLUDE_DIRS:PATH="$NETCDFDIR/include" \
-D Netcdf_LIBRARY_DIRS:PATH="$NETCDFDIR/lib" \
-D TPL_ENABLE_HDF5:BOOL=ON \
-D HDF5_INCLUDE_DIRS:PATH="$HDF5DIR/include" \
-D HDF5_LIBRARY_DIRS:PATH="$HDF5DIR/lib" \
-D Trilinos_DUMP_LINK_LIBS=ON \
The DUMP_LINK_LIBS flag shows that exodus has the right order:
-- exodus:LINK_LIBS='/usr/local/parallel/lib/libnetcdf.so;/usr/local/parallel/lib/libhdf5.a;/usr/local/lib/libz.so'
and indeed the corresponding link.txt file has the right lib ordering. But, for example, nem_slice does not necessarily. Its dump output is
-- nem_slice:LINK_LIBS='suplib_cpp;suplib;chaco;exodus;zoltan'
which does not include the TPLs on which exodus depends. The corresponding link.txt has HDF5 and Netcdf in the wrong order:
... /usr/local/parallel/lib/libhdf5.a /usr/local/lib/libz.so /usr/local/parallel/lib/libnetcdf.so ...
(Note that libnetcdf is shared, so this particular build goes through without a problem.)
Historically, in the case that the libs are all .a, we have hardcoded lib ordering like this:
```
-DTPL_ENABLE_Netcdf:STRING=ON \
-DNetcdf_INCLUDE_DIRS:PATH="${NETCDF_ROOT}/include" \
-DNetcdf_LIBRARY_DIRS:PATH="${NETCDF_ROOT}/lib" \
-DTPL_Netcdf_LIBRARIES="${NETCDF_ROOT}/lib/libnetcdf.a;${HDF5_ROOT}/lib/libhdf5_hl.a;${HDF5_ROOT}/lib/libhdf5.a;${ZLIB_ROOT}/lib/libz.a" \
-DTPL_ENABLE_HDF5:STRING=ON \
-DHDF5_INCLUDE_DIRS:PATH="${HDF5_ROOT}/include" \
-DTPL_HDF5_LIBRARIES:PATH="${HDF5_ROOT}/lib/libhdf5_hl.a;${HDF5_ROOT}/lib/libhdf5.a;${ZLIB_ROOT}/lib/libz.a" \
```
This has assured that all link.txt files are correct. A fix for this issue would permit the simple specification without providing full-path libs explicitly.
Attached is a text file containing the cmake script, configuration output, and selected cats of link.txt files.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/149boostlib defines not being respected.2016-03-16T15:08:31ZJames Willenbringboostlib defines not being respected.*Created by: bathmatt*
On hansen I'm working on building trilinos and I have set every thing I can think of to set the boost library paths.
dir-debug (gcc) 20 $ grep BoostL configure-drekar.sh
-D TPL_ENABLE_BoostLib=ON \
-D TPL_BoostLi...*Created by: bathmatt*
On hansen I'm working on building trilinos and I have set every thing I can think of to set the boost library paths.
dir-debug (gcc) 20 $ grep BoostL configure-drekar.sh
-D TPL_ENABLE_BoostLib=ON \
-D TPL_BoostLib_INCLUDE_DIRS:FILEPATH="${BOOST_BASE_DIR}/include" \
-D TPL_BoostLib_LIBRARY_DIRS:FILEPATH="${BOOST_BASE_DIR}/lib" \
-D TPL_BoostLib_LIBRARIES="${BOOST_BASE_DIR}/lib/libboost_program_options.so;${BOOST_BASE_DIR}/lib/libboost_system.so" \
However, cmake ignores this and just uses -lboost_system as shown below. This happens on lots of different systems, hansen, chama are just two I can think of. I have a long email thread with Ross but that hit a dead end.
[config.out.txt](https://github.com/trilinos/Trilinos/files/138446/config.out.txt)
/home/projects/x86-64-haswell/openmpi/1.10.0/gnu/4.9.3/bin/mpicxx -std=c++11 -fopenmp -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 -lboost_program_options -lboost_system ../../../../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 -lboost_program_options -lboost_system ../../../../kokkos/core/src/libkokkoscore.a -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lgfortran -lquadmath
I even went so far as to edit the cmake dependencies file
-bash-4.1$ git diff
diff --git a/packages/stk/stk_classic/cmake/Dependencies.cmake b/packages/stk/stk_classic/cmake/Dependencies.cmake
index 0c16502..b7cd94d 100644
--- a/packages/stk/stk_classic/cmake/Dependencies.cmake
+++ b/packages/stk/stk_classic/cmake/Dependencies.cmake
@@ -4,5 +4,5 @@ SET(TEST_REQUIRED_DEP_PACKAGES SEACASExodus)
SET(TEST_OPTIONAL_DEP_PACKAGES)
SET(LIB_REQUIRED_DEP_TPLS Boost BoostLib)
SET(LIB_OPTIONAL_DEP_TPLS OpenNURBS)
-SET(TEST_REQUIRED_DEP_TPLS)
+SET(TEST_REQUIRED_DEP_TPLS BoostLib)
SET(TEST_OPTIONAL_DEP_TPLS gtest)
-bash-4.1$
dir-debug (gcc) 23 $ cmake --version
cmake version 3.3.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/142Framework: Create GitHub tag for Thyra2016-02-15T17:56:10ZJames WillenbringFramework: Create GitHub tag for Thyra*Created by: mhoemmen*
Please :-) Issue #3 needs this.
*Created by: mhoemmen*
Please :-) Issue #3 needs this.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/138Add Trilinos Developer Instructions for GitHub Issues and waffle.io2016-02-14T05:24:25ZJames WillenbringAdd Trilinos Developer Instructions for GitHub Issues and waffle.io*Created by: jwillenbring*
@maherou has asked me to write up some instructions for using GitHub Issues and waffle.io. I am going to do this on a Trilinos GitHub wiki page. I am going to use the IDEAS Jira instructions as a guide.
*Created by: jwillenbring*
@maherou has asked me to write up some instructions for using GitHub Issues and waffle.io. I am going to do this on a Trilinos GitHub wiki page. I am going to use the IDEAS Jira instructions as a guide.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/127Compile Issues with Boost Includes on IBM POWER8 with XL 13.1.3 Compiler2016-05-11T13:43:25ZJames WillenbringCompile Issues with Boost Includes on IBM POWER8 with XL 13.1.3 Compiler*Created by: nmhamster*
Build errors seen in Trilinos VOTD when compiling using IBM XL 13.1.3 compiler. Recording for logging purposes, discussion on-going with IBM team for approach to fix this.
```
/home/projects/power8/boost/1.59.0/...*Created by: nmhamster*
Build errors seen in Trilinos VOTD when compiling using IBM XL 13.1.3 compiler. Recording for logging purposes, discussion on-going with IBM team for approach to fix this.
```
/home/projects/power8/boost/1.59.0/openmpi/1.10.1/ibm/13.1.3/cuda/7.5.7/include/boost/type_traits/type_with_alignment.hpp:111:11: error:
pasting formed 'BOOST_PP_LIST_IS_CONS_(', an invalid preprocessing token
/home/projects/power8/boost/1.59.0/openmpi/1.10.1/ibm/13.1.3/cuda/7.5.7/include/boost/type_traits/type_with_alignment.hpp:64:30: note: expanded from macro 'BOOST_TT_ALIGNMENT_TYPES'
BOOST_TT_ALIGNMENT_STRUCT_TYPES)
^
/home/projects/power8/boost/1.59.0/openmpi/1.10.1/ibm/13.1.3/cuda/7.5.7/include/boost/type_traits/type_with_alignment.hpp:58:9: note:
expanded from macro 'BOOST_TT_ALIGNMENT_STRUCT_TYPES'
BOOST_PP_LIST_TRANSFORM(BOOST_TT_HAS_ONE_T, \
^
/home/projects/power8/boost/1.59.0/openmpi/1.10.1/ibm/13.1.3/cuda/7.5.7/include/boost/preprocessor/list/transform.hpp:25:79: note:
expanded from macro 'BOOST_PP_LIST_TRANSFORM'
# define BOOST_PP_LIST_TRANSFORM(op, data, list) BOOST_PP_TUPLE_ELEM(3,
2, BOOST_PP_LIST_FOLD_RIGHT(BOOST_...
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/120trilinos.org: insecure connectivity2017-04-26T16:33:08ZJames Willenbringtrilinos.org: insecure connectivity*Created by: nschloe*
trilinos.org is served only with HTTPS (which is good), but all kinds of things are misconfigured. For one, the server only supports TLS 1.0.
![mess](https://cloud.githubusercontent.com/assets/181628/12703640/5ba4...*Created by: nschloe*
trilinos.org is served only with HTTPS (which is good), but all kinds of things are misconfigured. For one, the server only supports TLS 1.0.
![mess](https://cloud.githubusercontent.com/assets/181628/12703640/5ba480c8-c848-11e5-84d9-04ec542e69f4.png)
Check out https://www.ssllabs.com/ssltest/analyze.html?d=trilinos.org for more details.
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/101Enable MKL TPL but then CMake Reports BLAS Not Found2017-10-22T19:03:44ZJames WillenbringEnable MKL TPL but then CMake Reports BLAS Not Found*Created by: nmhamster*
Probably not doing this correctly. I have enabled the MKL TPL but when CMake is busy configuring it then reports BLAS is not found. Given that MKL provides BLAS routines at good performance, should this error occ...*Created by: nmhamster*
Probably not doing this correctly. I have enabled the MKL TPL but when CMake is busy configuring it then reports BLAS is not found. Given that MKL provides BLAS routines at good performance, should this error occur? Is correct to disable BLAS if I am using MKL?
```
Processing enabled TPL: MKL (enabled explicitly, disable with -DTPL_ENABLE_MKL=OFF)
-- Searching for libs in MKL_LIBRARY_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64'
-- Searching for a lib in the set "mkl_rt":
-- Searching for lib 'mkl_rt' ...
-- Found lib '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64/libmkl_rt.so'
-- TPL_MKL_LIBRARIES='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64/libmkl_rt.so'
-- Searching for headers in MKL_INCLUDE_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64'
-- Searching for a header file in the set "mkl.h":
-- Searching for header 'mkl.h' ...
-- Found header '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include/mkl.h'
-- Found TPL 'MKL' include dirs '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include'
-- TPL_MKL_INCLUDE_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include'
Processing enabled TPL: Pthread (enabled explicitly, disable with -DTPL_ENABLE_Pthread=OFF)
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
Processing enabled TPL: MPI (enabled explicitly, disable with -DTPL_ENABLE_MPI=OFF)
Processing enabled TPL: BLAS (enabled by TeuchosNumerics, disable with -DTPL_ENABLE_BLAS=OFF)
-- Searching for libs in BLAS_LIBRARY_DIRS=''
-- Searching for a lib in the set "blas blas_win32":
-- Searching for lib 'blas' ...
-- Searching for lib 'blas_win32' ...
-- ERROR: Did not find a lib in the lib set "blas blas_win32" for the TPL 'BLAS'!
-- ERROR: Could not find the libraries for the TPL 'BLAS'!
-- TIP: If the TPL 'BLAS' is on your system then you can set:
-DBLAS_LIBRARY_DIRS='<dir0>;<dir1>;...'
to point to the directories where these libraries may be found.
Or, just set:
-DTPL_BLAS_LIBRARIES='<path-to-libs0>;<path-to-libs1>;...'
to point to the full paths for the libraries which will
bypass any search for libraries and these libraries will be used without
question in the build. (But this will result in a build-time error
if not all of the necessary symbols are found.)
-- ERROR: Failed finding all of the parts of TPL 'BLAS' (see above), Aborting!
-- NOTE: The find module file for this failed TPL 'BLAS' is:
/home/sdhammo/git/trilinos-github-repo/cmake/tribits/common_tpls/FindTPLBLAS.cmake
which is pointed to in the file:
/home/sdhammo/git/trilinos-github-repo/TPLsList.cmake
TIP: One way to get past the configure failure for the
TPL 'BLAS' is to simply disable it with:
-DTPL_ENABLE_BLAS=OFF
which will disable it and will recursively disable all of the
downstream packages that have required dependencies on it, including
the package 'TeuchosNumerics' which triggered its enable.
When you reconfigure, just grep the cmake stdout for 'BLAS'
and then follow the disables that occur as a result to see what impact
this TPL disable has on the configuration of Trilinos.
CMake Error at cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake:127 (MESSAGE):
ERROR: TPL_BLAS_NOT_FOUND=TRUE, aborting!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1556 (TRIBITS_PROCESS_ENABLED_TPL)
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:209 (TRIBITS_PROCESS_ENABLED_TPLS)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/91CMake issue with shared libraries, --prefix on Apple2017-02-09T01:14:34ZJames WillenbringCMake issue with shared libraries, --prefix on Apple*Created by: BarrySmith*
Suggest you add a
set(CMAKE_INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib")
to appropriate CMAKE files. Otherwise with a prefix build and shared libraries on Apple the rpath within the shared libraries is n...*Created by: BarrySmith*
Suggest you add a
set(CMAKE_INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib")
to appropriate CMAKE files. Otherwise with a prefix build and shared libraries on Apple the rpath within the shared libraries is not properly reset when the shared libraries are copied over to the installed locations.
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/78Create 12.6 branch2016-04-06T21:01:49ZJames WillenbringCreate 12.6 branch*Created by: bmpersc*
*Created by: bmpersc*
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/74Can we turn off GlobalOrdinal = int in all Tpetra stack packages?2017-08-07T03:27:13ZJames WillenbringCan we turn off GlobalOrdinal = int in all Tpetra stack packages?*Created by: mhoemmen*
**Next action Status:**
Next: Better scope this story and create plan to exclude `GO=int` from the explicit instantations of Trilinos when possible (i.e. when Epetra is disabled, see #313).
**Blocked By:** #313...*Created by: mhoemmen*
**Next action Status:**
Next: Better scope this story and create plan to exclude `GO=int` from the explicit instantations of Trilinos when possible (i.e. when Epetra is disabled, see #313).
**Blocked By:** #313
**Description:**
It would be nice to be able to build the Tpetra enabled templated stack with just `GO = long ling int` and skip `GO = int`. This story will investigate this and then, if possible, work up a plan to make this happen.
**Tasks:**
???
Tpetra-backloghttps://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/26Trilinos/README.md way out of date2016-06-20T12:58:14ZJames WillenbringTrilinos/README.md way out of date*Created by: bartlettroscoe*
The file Trilinos/README.md that is displayed as the first thing people see on GitHub is way out of date (and has been for many months or more). Most of the links are broken and the file names are way out o...*Created by: bartlettroscoe*
The file Trilinos/README.md that is displayed as the first thing people see on GitHub is way out of date (and has been for many months or more). Most of the links are broken and the file names are way out of date. This does not make for a good first impression for new people coming to look at Trilinos on GitHub. At the very least, this should be gutted and just point to trilinos.org. Then, if someone has time, this can be filled out.
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.