Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-07-13T16:51:19Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/485OpenMP Detection Assumes GNU-Style Preprocessor Directive for Fortran (Incomp...2017-07-13T16:51:19ZJames WillenbringOpenMP Detection Assumes GNU-Style Preprocessor Directive for Fortran (Incompatible with IBM XLF)*Created by: nmhamster*
Trilinos OpenMP detection of flags for Fortran compiler does not work correctly with IBM XLF compiler on POWER8 platform. The detection assumes that the `-D` flag works for passing preprocessor defines through to...*Created by: nmhamster*
Trilinos OpenMP detection of flags for Fortran compiler does not work correctly with IBM XLF compiler on POWER8 platform. The detection assumes that the `-D` flag works for passing preprocessor defines through to the compiler. This is not the case for the IBM `xlf`and `xlf90` compilers where `-WF,-D` needs to be used if we expect the C preprocessor to be called. The correct check should be for `-qsmp=omp` to be found although its not clear this is correctly tested for (possible I have missed it in the error output).
```
/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/bin/xlf -O3 -g -qsmp=omp -qsimd=auto -L/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/lib -L/home/projects/pwr8-rhel72/ibm/xl/xlC/13.1.3/lib -lopen-pal -lxl -lxlopt -lxlf90 -lxlfmath -lm -libmc++ -lstdc++ -L/home/projects/pwr8-rhel72/openmpi/1.10.2/xl/13.1.3/cuda/7.5.7/lib -lmpi -O3 -g -qsmp=omp -qsimd=auto -L/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/lib -L/home/projects/pwr8-rhel72/ibm/xl/xlC/13.1.3/lib -lxlf90 -DOpenMP_FLAG_DETECTED -mp CMakeFiles/cmTC_48a9b.dir/src.F.o -o cmTC_48a9b -Wl,-export-dynamic
```
Yields (incorrect behavior) error of:
```
ld: warning: cannot find entry symbol nMP_FLAG_DETECTED; defaulting to 0000000010000860
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/351Teuchos: Improve build time by stripping many includes from Teuchos_ConfigDef...2018-07-20T18:40:48ZJames WillenbringTeuchos: Improve build time by stripping many includes from Teuchos_ConfigDefs.hpp*Created by: mhoemmen*
@trilinos/teuchos @bartlettroscoe @nmhamster
Lines 80-105 of Teuchos_ConfigDefs.hpp include a lot of standard library header files. Just about every Teuchos header file includes Teuchos_ConfigDefs.hpp, and many...*Created by: mhoemmen*
@trilinos/teuchos @bartlettroscoe @nmhamster
Lines 80-105 of Teuchos_ConfigDefs.hpp include a lot of standard library header files. Just about every Teuchos header file includes Teuchos_ConfigDefs.hpp, and many Trilinos packages include a Teuchos header file. Thus, everybody includes all those headers. That increases build time.
We really need to remove those includes. I tried doing something like this in Tpetra_ConfigDefs.hpp once, and it broke a bunch of stuff downstream. In theory, it's their fault that they relied on unnecessary upstream includes. In practice, if we break their build, it interrupts their work and makes them grumpy. Thus, it's important to test EVERY PACKAGE that depends on Teuchos. We really should also test external software that depends on Teuchos or its downstream packages. Examples include Dakota (https://dakota.sandia.gov) and Nalu (https://github.com/spdomin/Nalu). Nevertheless, we need to brace ourselves for some disruption and complaints.
Reduce build times for Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/261using the custom ninja build rebuilds fortran files every time2018-03-01T20:18:01ZJames Willenbringusing the custom ninja build rebuilds fortran files every time*Created by: bathmatt*
@bartlettroscoe
Everytime configure runs all the fortran files are rebuilt using the custom ninja. I edit the cmakefiles.txt in panzer and it recompiles all the fortran files, 1300 or so of them.
*Created by: bathmatt*
@bartlettroscoe
Everytime configure runs all the fortran files are rebuilt using the custom ninja. I edit the cmakefiles.txt in panzer and it recompiles all the fortran files, 1300 or so of them.
Get Trilinos building with CMake + Ninja + Fortranhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/169libstk_mesh_base in 12.6.1 includes references to undefined stk::CommBuffer2016-03-03T17:50:54ZJames Willenbringlibstk_mesh_base in 12.6.1 includes references to undefined stk::CommBuffer*Created by: bavier*
Building examples in TrilinosCouplings from the Trilinos 12.6.1 release tarball leads to the following build failures for me:
```
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference ...*Created by: bavier*
Building examples in TrilinosCouplings from the Trilinos 12.6.1 release tarball leads to the following build failures for me:
```
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBroadcast::communicate()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommSparse::~CommSparse()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::all_reduce_impl(int, unsigned long const*, unsigned long*, unsigned int, int)'
../../../stk/stk_util/stk_util/use_cases/libstk_util_use_cases.so.12.6.1: undefined reference to `stk::BroadcastArg::BroadcastArg(int, int, char**)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBroadcast::CommBroadcast(int, int)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommSparse::CommSparse(int)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBuffer::pack_overflow() const'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::all_reduce(int, void (*)(void*, void*, int*, int*), void*, void*, unsigned int)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommSparse::communicate()'
../../../stk/stk_unit_tests/stk_mesh_fixtures/libstk_mesh_fixtures.so.12.6.1: undefined reference to `stk::parallel_machine_rank(int)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::parallel_machine_barrier(int)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::all_write_string(int, std::ostream&, std::string const&)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBroadcast::send_buffer()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommAll::allocate_buffers(int, unsigned int const*, unsigned int const*)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBroadcast::~CommBroadcast()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommSparse::rank_error(char const*, int) const'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommAll::allocate_buffers(unsigned int, bool, bool)'
../../../stk/stk_util/stk_util/use_cases/libstk_util_use_cases.so.12.6.1: undefined reference to `stk::BroadcastArg::~BroadcastArg()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommAll::rank_error(char const*, int) const'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommAll::communicate()'
../../../stk/stk_unit_tests/stk_mesh_fixtures/libstk_mesh_fixtures.so.12.6.1: undefined reference to `stk::parallel_machine_size(int)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommAll::~CommAll()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBroadcast::recv_buffer()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommAll::CommAll(bool)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBuffer::unpack_overflow() const'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::generate_parallel_unique_ids(unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > const&, unsigned long, int)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommSparse::allocate_buffers()'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommBroadcast::allocate_buffer(bool)'
../../../stk/stk_mesh/stk_mesh/base/libstk_mesh_base.so.12.6.1: undefined reference to `stk::CommAll::CommAll(int, bool)'
collect2: error: ld returned 1 exit status
make[2]: *** [packages/trilinoscouplings/examples/fenl/TrilinosCouplings_fenl_pce.exe] Error 1
```
And similarly for several other examples, though the error seems like it would cause trouble for any use of the stk_mesh_base library.
The issue appears to be that the stk_util_parallel library was disabled in the 12.6.1 release branch: 8fa32589887a1a4dd756a5317f7d669945f215dd, whose comment appears to suggest the intent was to disable the test, rather than removing the library completely?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/144stokhos build failing on mira (trilinos-release-12-6-branch)2016-03-03T17:52:07ZJames Willenbringstokhos build failing on mira (trilinos-release-12-6-branch)*Created by: sarich*
This build is failing on mira.alcf.anl.gov, the master branch is compiling without any problems.
I'm using gcc-4.8.4
```
In file included from /gpfs/mira-fs1/projects/OSCon/sarich/petsc/arch-gcc-downloads/externa...*Created by: sarich*
This build is failing on mira.alcf.anl.gov, the master branch is compiling without any problems.
I'm using gcc-4.8.4
```
In file included from /gpfs/mira-fs1/projects/OSCon/sarich/petsc/arch-gcc-downloads/externalpackages/git.trilinos/build/packages/stokhos/src/Ifpack2_Details_Chebyshev_MP_Vector_Serial.cpp:55:1: required from here
/projects/OSCon/sarich/petsc/arch-gcc-downloads/include/Ifpack2_Details_Chebyshev_def.hpp:707:9: error: 'const class Tpetra::CrsGraph<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial>, false>' has no member named 'getLocalDiagOffsets'
A_crsMat->getCrsGraph ()->getLocalDiagOffsets (diagOffsets_);
^
/projects/OSCon/sarich/petsc/arch-gcc-downloads/include/Ifpack2_Details_Chebyshev_def.hpp:725:11: error: 'const class Tpetra::CrsGraph<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial>, false>' has no member named 'getLocalDiagOffsets'
A_crsMat->getCrsGraph ()->getLocalDiagOffsets (diagOffsets_);
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/103Build failure with superlu_dist2016-03-03T17:37:13ZJames WillenbringBuild failure with superlu_dist*Created by: balay*
We are seeing trilinos build failure [osx] when built with superlu_dist. It appears that packages/amesos2/src/Amesos2_Superludist_TypeMap.hpp is attempting to use both superlu_ddefs.h and superlu_zdefs.h at the same ...*Created by: balay*
We are seeing trilinos build failure [osx] when built with superlu_dist. It appears that packages/amesos2/src/Amesos2_Superludist_TypeMap.hpp is attempting to use both superlu_ddefs.h and superlu_zdefs.h at the same time - causing errors. My understanding is - only one of them should be used - but not both. cc:ing Sherry for clarification.
[builderror.txt](https://github.com/trilinos/Trilinos/files/105697/builderror.txt)
@bsmith@mcs.anl.gov
@sarich@mcs.anl.gov
@xsli@lbl.gov
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/86Consolidate TRILINOS_UNUSED_FUNCTION macro definition in Teuchos2016-03-03T17:53:03ZJames WillenbringConsolidate TRILINOS_UNUSED_FUNCTION macro definition in Teuchos*Created by: mhoemmen*
According to @bmpersc (see Issue #83), the logic for defining TRILINOS_UNUSED_FUNCTION appears twice in Tpetra and once in Teuchos. Since Tpetra depends on Teuchos, it would make sense to consolidate this logic i...*Created by: mhoemmen*
According to @bmpersc (see Issue #83), the logic for defining TRILINOS_UNUSED_FUNCTION appears twice in Tpetra and once in Teuchos. Since Tpetra depends on Teuchos, it would make sense to consolidate this logic in Teuchos. An alternate approach would be for each package to define its own ${PACKAGE}_UNUSED_FUNCTION macro. Either way, we shouldn't try to define the same thing three times. It's not causing build errors but it's error-prone.