Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-08-22T19:10:02Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/75SEACSIoss fails to build if Netcdf TPL disabled2017-08-22T19:10:02ZJames WillenbringSEACSIoss fails to build if Netcdf TPL disabled*Created by: bavier*
With master@e9a607a and cmake 3.3.2, and configuring with
```
$ mkdir build && cd build
$ cmake \
-DTrilinos_ENABLE_SEACASIoss:BOOL=ON \
-DTPL_ENABLE_Netcdf:BOOL=OFF \
..
```
configuration completes su...*Created by: bavier*
With master@e9a607a and cmake 3.3.2, and configuring with
```
$ mkdir build && cd build
$ cmake \
-DTrilinos_ENABLE_SEACASIoss:BOOL=ON \
-DTPL_ENABLE_Netcdf:BOOL=OFF \
..
```
configuration completes successfully, but with a warning from Cmake:
```
Processing enabled package: SEACAS (Ioss)
Cmake Warning at cmake/tribits/core/package_arch/TribitsLibraryMacros.cmake:601 (MESSAGE):
WARNING: 'Ioexo_fac' in DEPSLIBS is not a lib defined in the current cmake
project! Such usage is deprecated (and will result in a configure error
soon). If this is an external lib you are trying to link in, it should
likely be handled as a TriBITS TPL. Otherwise, it should be passed in
through IMPORTEDLIBS. However, the only case we have found where
IMPORTEDLIBS had to be used instead of through a proper TriBITS TPL is the
C math library 'm'.
Call Stack (most recent call first):
packages/seacas/libraries/ioss/src/init/CmakeLists.txt:45 (TRIBITS_ADD_LIBRARY)
```
If I then run `make`, I eventually get the following error:
```
[ 99%] Linking CXX executable cth_pressure_map
ld: cannot find -lIoexo_fac
collect2: error: ld returned 1 exit status
```
So it seems that some dependencies are not declared correctly.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/76Get Trilinos to adopt the XSDK configure standards2016-01-14T16:28:03ZJames WillenbringGet Trilinos to adopt the XSDK configure standards*Created by: bartlettroscoe*
Trilinos needs to adopt the updated xSDK configure options (see [SDK-1](https://ideas-productivity.atlassian.net/browse/SDK-1) and [SDK-2](https://ideas-productivity.atlassian.net/browse/SDK-2)). I have thi...*Created by: bartlettroscoe*
Trilinos needs to adopt the updated xSDK configure options (see [SDK-1](https://ideas-productivity.atlassian.net/browse/SDK-1) and [SDK-2](https://ideas-productivity.atlassian.net/browse/SDK-2)). I have this done and integrated into TriBITS (see [TriBITS #107](https://github.com/TriBITSPub/TriBITS/issues/107)) but it needs some review. @jwillenbring, given that you are also funded on the IDEAS project, do you think you can give [TriBITS #107](https://github.com/TriBITSPub/TriBITS/issues/107) a review? You can also manually test that it is behaving according to the [xSDK configure standard](https://docs.google.com/document/d/18028D6nsuhIrCvJnX6c07r8m_Np4SH-aGXMX4svMs1w).
Anyway, I am about to snapshot the updated TriBITS to the Trilinos 'master' branch.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/77Amesos_Mumps.cpp does not build when MPI is disabled2016-01-13T15:29:45ZJames WillenbringAmesos_Mumps.cpp does not build when MPI is disabled*Created by: bavier*
Configuring with cmake 3.3.2 at master@e9a607a with
```
$ mkdir build && cd build
$ cmake \
-DTrilinos_ENABLE_Amesos:BOOL=ON \
-DTPL_ENABLE_MUMPS:BOOL=ON \
..
```
then running `make` produces the follo...*Created by: bavier*
Configuring with cmake 3.3.2 at master@e9a607a with
```
$ mkdir build && cd build
$ cmake \
-DTrilinos_ENABLE_Amesos:BOOL=ON \
-DTPL_ENABLE_MUMPS:BOOL=ON \
..
```
then running `make` produces the following error:
```
/ptmp/trilinos-12.6.1-rc/packages/amesos/src/Amesos_Mumps.cpp: In member function 'virtual int Amesos_Mumps::SymbolicFactorization()':
/ptmp/trilinos-12.6.1-rc/packages/amesos/src/Amesos_Mumps.cpp:478:9: error: 'Epetra_MpiComm' does not name a type
const Epetra_MpiComm* MpiComm = dynamic_cast<const Epetra_MpiComm*>(&Comm());
^
In file included from /gnu/store/gma0ig9v61y7c1rhvaj7qx1ga86wnjs7-gfortran-4.9.3/include/c++/cassert:43:0,
from /ptmp/trilinos-12.6.1-rc/packages/teuchos/core/src/Teuchos_ConfigDefs.hpp:93,
from /ptmp/trilinos-12.6.1-rc/packages/teuchos/core/src/Teuchos_RCPNode.hpp:52,
from /ptmp/trilinos-12.6.1-rc/packages/teuchos/core/src/Teuchos_RCPDecl.hpp:51,
from /ptmp/trilinos-12.6.1-rc/packages/teuchos/core/src/Teuchos_RCP.hpp:58,
from /ptmp/trilinos-12.6.1-rc/packages/amesos/src/Amesos_BaseSolver.h:48,
from /ptmp/trilinos-12.6.1-rc/packages/amesos/src/Amesos_Mumps.h:44,
from /ptmp/trilinos-12.6.1-rc/packages/amesos/src/Amesos_Mumps.cpp:29:
/ptmp/trilinos-12.6.1-rc/packages/amesos/src/Amesos_Mumps.cpp:479:11: error: 'MpiComm' was not declared in this scope
assert (MpiComm != 0);
^
/ptmp/trilinos-12.6.1-rc/packages/amesos/src/Amesos_Mumps.cpp:480:68: error: 'MPI_Comm_c2f' was not declared in this scope
MDS.comm_fortran = (MUMPS_INT) MPI_Comm_c2f(MpiComm->GetMpiComm());
^
```
I would expect configuration to fail, rather than the build to fail, if Amesos_Mumps is not supported when MPI is disabled. On the other hand, MUMPS supports seriail execution, so perhaps it would be best to check for MUMPS's libmpiseq during configuration if TPL_ENABLE_MPI:BOOL=OFF and then adjust Amesos_Mumps accordingly.
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/79importAndFillComplete (and analogous Epetra constructor) for CrsGraph2018-02-21T01:03:07ZJames WillenbringimportAndFillComplete (and analogous Epetra constructor) for CrsGraph*Created by: kddevin*
@trilinos/tpetra
Chris Siefert directed my attention to the new importAndFillComplete utility in Tpetra::CrsMatrix, and an analogous constructor for Epetra_CrsMatrix.
It would be nice (but not urgent) to have ana...*Created by: kddevin*
@trilinos/tpetra
Chris Siefert directed my attention to the new importAndFillComplete utility in Tpetra::CrsMatrix, and an analogous constructor for Epetra_CrsMatrix.
It would be nice (but not urgent) to have analogous capability for CrsGraph.
Tpetra-backloghttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/81Belos: PseudoBlockGmres complex tests failing2016-03-08T20:35:27ZJames WillenbringBelos: PseudoBlockGmres complex tests failing*Created by: mhoemmen*
@trilinos/belos
Belos_bl_gmres_complex_hb_3 and Belos_bl_gmres_complex_hb_4 fail. See e.g., the perseus test on the Dashboard. They fail for me in both MPI debug and non-MPI release builds. The tests in quest...*Created by: mhoemmen*
@trilinos/belos
Belos_bl_gmres_complex_hb_3 and Belos_bl_gmres_complex_hb_4 fail. See e.g., the perseus test on the Dashboard. They fail for me in both MPI debug and non-MPI release builds. The tests in question do NOT exercise either Epetra or Tpetra; they use Belos' custom linear algebra implementation that Belos has long used for testing. I'm not sure how long the tests have been failing. I played with the test executable and matrix, and did get them to converge when I changed the restart length, e.g.,
`/Belos_bl_gmres_complex_hb.exe --verbose --filename=mhd1280a.cua --pseudo --num-restarts=1 --frequency=1 --subspace-length=800 --num-restarts=1000`
Thus, I'm not sure what's going on here. Could it be that the expected convergence rate depends on a particular random right-hand side, and I'm using a different system library's pseudorandom number generator? (I'm using Clang 3.7 on Mac.)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/82Building Trilinos with Kokkos enabled doesn't work on 32-bit machines2016-03-12T13:06:23ZJames WillenbringBuilding Trilinos with Kokkos enabled doesn't work on 32-bit machines*Created by: BarrySmith*
The PETSc ./configure --download-trilinos=1 --with-cxx-dialect=C++11 --download-boost=1 --download-cmake=1
is failing on one of our machines with error message:
In file included from /sandbox/sarich/petsc/ar...*Created by: BarrySmith*
The PETSc ./configure --download-trilinos=1 --with-cxx-dialect=C++11 --download-boost=1 --download-cmake=1
is failing on one of our machines with error message:
In file included from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_Atomic.hpp:208:0,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:50:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp: In instantiation of ‘T Kokkos::Impl::atomic_fetch_oper(const Oper&, volatile T_, typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type) [with Oper = Kokkos::Impl::AndOper<long long unsigned int, const long long unsigned int>; T = long long unsigned int; typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type = const long long unsigned int]’:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:296:69: required from ‘T Kokkos::atomic_fetch_and(volatile T_, T) [with T = long long unsigned int]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:211:64: required from ‘bool Kokkos::Impl::{anonymous}::Bitset<NumBlocks>::reset(int) [with int NumBlocks = 15]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:296:30: required from here
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3: note: template<class T> T Kokkos::atomic_compare_exchange(volatile T_, T, typename Kokkos::Impl::enable_if<((sizeof (T) != 4) && (sizeof (T) != 8)), const T>::type&)
T atomic_compare_exchange( volatile T \* const dest , const T compare ,
^
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3: note: template argument deduction/substitution failed:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp: In substitution of ‘template<class T> T Kokkos::atomic_compare_exchange(volatile T_, T, typename Kokkos::Impl::enable_if<((sizeof (T) != 4) && (sizeof (T) != 8)), const T>::type&) [with T = long long unsigned int]’:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:144:103: required from ‘T Kokkos::Impl::atomic_fetch_oper(const Oper&, volatile T_, typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type) [with Oper = Kokkos::Impl::AndOper<long long unsigned int, const long long unsigned int>; T = long long unsigned int; typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type = const long long unsigned int]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:296:69: required from ‘T Kokkos::atomic_fetch_and(volatile T_, T) [with T = long long unsigned int]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:211:64: required from ‘bool Kokkos::Impl::{anonymous}::Bitset<NumBlocks>::reset(int) [with int NumBlocks = 15]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:296:30: required from here
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3: error: invalid use of incomplete type ‘struct Kokkos::Impl::enable_if<false, const long long unsigned int>’
In file included from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_MemoryTraits.hpp:47:0,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_HostSpace.hpp:53,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_Atomic.hpp:71,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:50:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Traits.hpp:201:8: error: declaration of ‘struct Kokkos::Impl::enable_if<false, const long long unsigned int>’
struct enable_if ;
^
Full output from configure/build is attached
[configure.txt](https://github.com/trilinos/Trilinos/files/95073/configure.txt)
Barry
@sarich
@balay@mcs.anl.gov
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/83TRILINOS_UNUSED_FUNCTION Doesn't work on windows with intel2016-02-05T02:32:33ZJames WillenbringTRILINOS_UNUSED_FUNCTION Doesn't work on windows with intel*Created by: bmpersc*
This looks like an issue with the intel compiler on windows. It seems that Tpetra has run into this before as the same logic for setting TRILINOS_UNUSED_FUNCTION was checking for windows and not setting TRILINOS_UN...*Created by: bmpersc*
This looks like an issue with the intel compiler on windows. It seems that Tpetra has run into this before as the same logic for setting TRILINOS_UNUSED_FUNCTION was checking for windows and not setting TRILINOS_UNUSED_FUNCTION to **unused** in that case. I have attached a patch that should fix this issue. I have two questions though, is this an acceptable solution? And Why is this logic in 3 places in Trilinos(1 in Teuchos and 2 in Tpetra)?
@mhoemmen
[0001-Teuchos-Fix-compile-issue-on-windows-with-intel.patch.txt](https://github.com/trilinos/Trilinos/files/96309/0001-Teuchos-Fix-compile-issue-on-windows-with-intel.patch.txt)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/84Xpetra::MultiVector tests segfaulting after recent changes in Tpetra2016-01-23T03:18:19ZJames WillenbringXpetra::MultiVector tests segfaulting after recent changes in Tpetra*Created by: tawiesn*
The Tpetra stack tests in Xpetra for the MultiVector are segfaulting after the recent changes in the Tpetra::MultiVector:
==29656== at 0x989A7C8: Tpetra::MultiVector<double, int, long long, Kokkos::Compat::Kokk...*Created by: tawiesn*
The Tpetra stack tests in Xpetra for the MultiVector are segfaulting after the recent changes in the Tpetra::MultiVector:
==29656== at 0x989A7C8: Tpetra::MultiVector<double, int, long long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace>, false>::MultiVector(Teuchos::RCP<Tpetra::Map<int, long long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace> > const> const&, Kokkos::DualView<double**, Kokkos::LayoutLeft, Kokkos::OpenMP, void> const&, Kokkos::DualView<double**, Kokkos::LayoutLeft, Kokkos::OpenMP, void> const&) (Tpetra_MultiVector_def.hpp:403)
==29656== Address 0x29d is not stack'd, malloc'd or (recently) free'd
The problem seems to result from one of the changes between the commits a244ea7cf43 and 369d2c3d17da.
In my configuration ETI=on
@trilinos/tpetra
@trilinos/xpetra
@mhoemmen
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/85Ifpack2 : Threaded SGS2016-02-10T20:39:53ZJames WillenbringIfpack2 : Threaded SGS*Created by: srajama1*
Create a Threaded SGS in Ifpack2. This will call KokkosKernels Ifpack2 with a new option for the preconditioner such as SGS-MT.
@trilinos/ifpack2 , @mndevec
*Created by: srajama1*
Create a Threaded SGS in Ifpack2. This will call KokkosKernels Ifpack2 with a new option for the preconditioner such as SGS-MT.
@trilinos/ifpack2 , @mndevec
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.
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/88Adding support for UMFPACK in Amesos22017-06-13T18:06:34ZJames WillenbringAdding support for UMFPACK in Amesos2*Created by: dridzal*
@trilinos/amesos2: The @trilinos/rol team would like to use Amesos2 as the interface to a direct solver that is well suited for solving PDEs in two spatial dimensions. In our experience, UMFPACK works well for th...*Created by: dridzal*
@trilinos/amesos2: The @trilinos/rol team would like to use Amesos2 as the interface to a direct solver that is well suited for solving PDEs in two spatial dimensions. In our experience, UMFPACK works well for these problems. This capability would support the PDE-OPT application development kit and test suite.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/89Belos build issue when Tpetra is disabled2016-05-02T22:34:57ZJames WillenbringBelos build issue when Tpetra is disabled*Created by: jwillenbring*
@pbosler
I was trying to build Belos as part of a new nightly no C++11 build, and it failed in doc/ due to Tpetra not being enabled. Tpetra is an optional dependence for Belos. Here is the error output:
[ 9...*Created by: jwillenbring*
@pbosler
I was trying to build Belos as part of a new nightly no C++11 build, and it failed in doc/ due to Tpetra not being enabled. Tpetra is an optional dependence for Belos. Here is the error output:
[ 95%] Building CXX object packages/belos/doc/parameterList/CMakeFiles/Belos_ValidParameters.dir/createValidParameterList.cpp.o
/home/jmwille/TrilinosTest/Trilinos/packages/belos/doc/parameterList/createValidParameterList.cpp:66:34: error: Tpetra_MultiVector.hpp: No such file or directory
In file included from /home/jmwille/TrilinosTest/Trilinos/packages/belos/doc/parameterList/createValidParameterList.cpp:67:
/home/jmwille/TrilinosTest/Trilinos/packages/belos/doc/parameterList/../../tpetra/src/BelosTpetraAdapter.hpp:83:31: error: Tpetra_Operator.hpp: No such file or directory
In file included from /home/jmwille/TrilinosTest/Trilinos/packages/belos/doc/parameterList/createValidParameterList.cpp:67:
/home/jmwille/TrilinosTest/Trilinos/packages/belos/doc/parameterList/../../tpetra/src/BelosTpetraAdapter.hpp:114: error: ‘::Tpetra’ has not been declared
...
This appears to be due to changes made on Nov 17. Here is the critical subset of my cmake arguments:
-DTrilinos_ENABLE_CXX11=OFF \
-D Trilinos_ENABLE_TESTS:BOOL=ON \
-DCMAKE_C_COMPILER=/usr/lib64/openmpi/bin/mpicc \
-DCMAKE_CXX_COMPILER=/usr/lib64/openmpi/bin/mpic++ \
-DCMAKE_Fortran_COMPILER=/usr/lib64/openmpi/bin/mpif77 \
-DTrilinos_ENABLE_NOX=ON \
-DNOX_ENABLE_LOCA=ON \
-DTrilinos_ENABLE_EpetraExt=ON \
-DEpetraExt_BUILD_BTF=ON \
-DTrilinos_ENABLE_TrilinosCouplings=ON \
-DTrilinos_ENABLE_Ifpack=ON \
-DTrilinos_ENABLE_Isorropia=ON \
-DTrilinos_ENABLE_AztecOO=ON \
-DTrilinos_ENABLE_Belos=ON \
-DTrilinos_ENABLE_Teuchos=ON \
-DTeuchos_ENABLE_COMPLEX=ON \
-DTrilinos_ENABLE_Amesos=ON \
-DAmesos_ENABLE_KLU=ON \
-DTrilinos_ENABLE_Sacado=ON \
-DTrilinos_ENABLE_Zoltan=ON \
-DTrilinos_ENABLE_ALL_OPTIONAL_PACKAGES=OFF \
-DTPL_ENABLE_MPI=ON \
I think it would be possible to basically remove all of the package enables except Belos. You could just ifdef the whole directory essentially if Tpetra isn't enabled, but I wanted to give you the opportunity to be more selective than that.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/90Segfault in Tpetra's writeDenseFile()2016-01-24T13:32:40ZJames WillenbringSegfault in Tpetra's writeDenseFile()*Created by: dridzal*
@trilinos/tpetra: The @trilinos/rol team is using MatrixMarket writers for the PDE-OPT application development kit. It appears that a recent change to Tpetra is causing segaults in writeDenseFile(), in an MPI bui...*Created by: dridzal*
@trilinos/tpetra: The @trilinos/rol team is using MatrixMarket writers for the PDE-OPT application development kit. It appears that a recent change to Tpetra is causing segaults in writeDenseFile(), in an MPI build, for example in the data.hpp file in /rol/example/PDE-OPT/poisson:
void outputTpetraVector(const Teuchos::RCP<const Tpetra::MultiVector<> > &vec,
const std::string &filename) const {
Tpetra::MatrixMarket::WriterTpetra::MultiVector< > vecWriter;
vecWriter.writeDenseFile(filename, vec);
}
We are not sure which recent change in Tpetra caused the issue; it was a day or two after the ROL commit d5bcec2467f9087f0117ae7da1db921b3afc4d6d. If you checkout this sha1, the example in the above directory will run without segfaults, in a parallel MPI build. The issue is not present in a serial build. We have not checked CrsMatrix writers.
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/92Kokkos: invalid use of incomplete type build error on CEE linux2016-01-23T02:18:30ZJames WillenbringKokkos: invalid use of incomplete type build error on CEE linux*Created by: dicengine*
This has been an issue for the last couple days with building VOTD Trilinos. Here are the configure results, build error, and cmake configuration files.
[make.txt](https://github.com/trilinos/Trilinos/files/1007...*Created by: dicengine*
This has been an issue for the last couple days with building VOTD Trilinos. Here are the configure results, build error, and cmake configuration files.
[make.txt](https://github.com/trilinos/Trilinos/files/100780/make.txt)
[cmake.txt](https://github.com/trilinos/Trilinos/files/100781/cmake.txt)
[do-cmake.txt](https://github.com/trilinos/Trilinos/files/100782/do-cmake.txt)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/93Teuchos on Cray with Intel2016-03-12T13:02:10ZJames WillenbringTeuchos on Cray with Intel*Created by: crtrott*
We are tracking problems all over Trilinos which appear to originate in Teuchos, in particular the Output classes. This manifested in multiple down stream packages as segfaults, which according to some extensive de...*Created by: crtrott*
We are tracking problems all over Trilinos which appear to originate in Teuchos, in particular the Output classes. This manifested in multiple down stream packages as segfaults, which according to some extensive debugging seem to happen due to virtual function pointers which are 0.
The same compiler combination (Intel 15 and GCC 4.9.2) is fine on basic Red Hat system. Currently we suspect a compiler bug or something similar in the cray environment. I will add more details later.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/94NetCDF/HDF5 Load Issue with SEACAS/Ioss on Cray (with Intel 15.3 and 16.1)2017-08-22T19:08:32ZJames WillenbringNetCDF/HDF5 Load Issue with SEACAS/Ioss on Cray (with Intel 15.3 and 16.1)*Created by: nmhamster*
Have been encouraged to submit issues for tracking by @maherou.
We are seeing that NALU builds running with VOTD from Trilinos are failing to correctly load Exodus databases on Cray platforms when using the Inte...*Created by: nmhamster*
Have been encouraged to submit issues for tracking by @maherou.
We are seeing that NALU builds running with VOTD from Trilinos are failing to correctly load Exodus databases on Cray platforms when using the Intel 15.3 and 16.1 compiled modules. Not sure where the error is coming from yet but diagnostics are underway. @gsjaardema is involved in conversations.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/96Ifpack2: Improve block Jacobi performance2016-05-23T04:53:59ZJames WillenbringIfpack2: Improve block Jacobi performance*Created by: mhoemmen*
@trilinos/ifpack2 @trilinos/tpetra @amklinv
We want to improve performance of block Jacobi by at least 2x. "Block Jacobi" is what happens when one gives a `Tpetra::Experimental::BlockCrsMatrix` to `Ifpack2::Rel...*Created by: mhoemmen*
@trilinos/ifpack2 @trilinos/tpetra @amklinv
We want to improve performance of block Jacobi by at least 2x. "Block Jacobi" is what happens when one gives a `Tpetra::Experimental::BlockCrsMatrix` to `Ifpack2::Relaxation` and asks for Jacobi. The current implementation of block Jacobi lives in Ifpack2_Relaxation_def.hpp, in the `ApplyInverseJacobi_BlockCrsMatrix` method.
There are two optimizations that come to mind:
1. If the initial guess vector is zero (`ZeroStartingSolution_` is `true`), then on the first (zeroth) sweep, we can replace the sparse mat-vec (`blockMat->apply(Y, A_times_Y)`, line 1166) with a "block scaling" by the inverse of the block diagonal. Compare to non-block Jacobi in lines 1076-1100 of the same file (`ApplyInverseJacobi` method).
2. Currently, we apply the inverse of the block diagonal, by using linear solves (GETRS). It's likely more efficient to precompute the inverse (GETRI) and apply it directly (GEMV). I think this for the following reasons. First, batched GEMV is a simpler kernel and thus easier to optimize. It may even have vendor implementations. Second, not passing the pivots around means less data movement. Third, not passing the pivots around makes interfaces simpler, and thus easier to optimize.
All other optimizations should wait until we know how many sweeps the users want. Block Jacobi relies on `BlockCrsMatrix::apply` (sparse mat-vec) after the first sweep. The logical way to improve performance for multiple sweeps would be to make sparse mat-vec faster. With thread parallelization, we will also need to consider the update and "block scaling" kernels (compare to lines 1111 and 1112 of nonblock Jacobi). It may also pay to merge the sparse mat-vec, update, and block scaling kernels into a single kernel, like we do with block Gauss-Seidel.