Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2020-07-22T01:04:27Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4964Tempus: Output After Passing Output Time2020-07-22T01:04:27ZJames WillenbringTempus: Output After Passing Output Time*Created by: ccober6*
Would like to output when the timestep steps over the output time, and do not adjust the timestep size to exactly "land" on the output time.*Created by: ccober6*
Would like to output when the timestep steps over the output time, and do not adjust the timestep size to exactly "land" on the output time.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4963Intrepid2 and Panzer build errors in new cuda-10.1 builds on 'white'2020-07-22T01:04:27ZJames WillenbringIntrepid2 and Panzer build errors in new cuda-10.1 builds on 'white'*Created by: bartlettroscoe*
CC: @trilinos/intrepid2, @trilinos/panzer @mperego (Trilinos Discretizations Product Lead), @bartlettroscoe, @fryeguy52
<Checklist>
<???: Add label "client: ATDM">
<???: Add label "ATDM Sev: Blocker" (...*Created by: bartlettroscoe*
CC: @trilinos/intrepid2, @trilinos/panzer @mperego (Trilinos Discretizations Product Lead), @bartlettroscoe, @fryeguy52
<Checklist>
<???: Add label "client: ATDM">
<???: Add label "ATDM Sev: Blocker" (by default but could be other "ATDM Sev: XXX")>
<???: Add label "type: bug"?>
<???: Add label for affected packages (e.g. "pkg: MueLu", "pkg: Tpetra", "pkg: Kokkos", etc.)>
<???: Add label "PA: ???Project Area???" (e.g. "PA: Linear Solvers", "PA: Data Services")>
<???: Add milestone "Initial cleanup of new ATDM ..." or "Keep promoted ATDM ...">
<???: Once GitHub Issue is created, add entries for tests to TrilinosATDMStatus/*.csv files>
## Next Action Status
<status-and-or-first-action>
## Description
As shown [here on CDash](https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&parentid=4917892), there are many build failures in Intrepid2 and Panzer shown in the new build:
* `Trilinos-atdm-white-ride-cuda-10.1-gnu-7.2.0-release-debug`
that as been set up on 'white' (see [TRIL-245](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-245)).
This starts with build errors in Intrepid2 as shown [here](https://testing.sandia.gov/cdash-dev-view/viewBuildError.php?buildid=4917897) that look like:
```
/home/jenkins/white/workspace/Trilinos-atdm-white-ride-cuda-10.1-gnu-7.2.0-release-debug/SRC_AND_BUILD/Trilinos/packages/intrepid2/src/Discretization/Basis/Intrepid2_HCURL_TET_In_FEMDef.hpp:451:64: error: invalid conversion from ‘Intrepid2::ordinal_type* {aka int*}’ to ‘Intrepid2::ordinal_type {aka int}’ [-fpermissive]
tags[i_card+1][0] = 2; // face dof
```
The build errors in Panzer look to be these same errors coming from Intrepid2.
## Current Status on CDash
* [Trilinos-atdm-white-ride-cuda-10.1-gnu-7.2.0-release-debug Intrepid2 build summary last 5 days](https://testing.sandia.gov/cdash-dev-view/index.php?project=Trilinos&date=2019-04-19&filtercount=3&showfilters=1&filtercombine=and&field1=subprojects&compare1=93&value1=Intrepid2&field2=buildname&compare2=61&value2=Trilinos-atdm-white-ride-cuda-10.1-gnu-7.2.0-release-debug&field3=buildstarttime&compare3=83&value3=5%20days%20ago)
## Steps to Reproduce
One should be able to reproduce this failure on the machine 'white' as described in:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
More specifically, the commands given for the system 'white' are provided at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#ridewhite
The exact commands on 'white' to reproduce this issue should be:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh \
Trilinos-atdm-white-ride-cuda-10.1-gnu-7.2.0-release-debug
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnv.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_Intrepid2=ON \
$TRILINOS_DIR
$ make NP=16
```
Initial cleanup of new ATDM builds of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4970Tempus: Add accessor to WrapperModelEvaluator2020-07-22T01:04:27ZJames WillenbringTempus: Add accessor to WrapperModelEvaluator*Created by: ccober6*
## Enhancement
@trilinos/tempus
For a segregated linear solve, EMPIRE needs access to the WrapperModelEvaluator to get to alpha and beta. Adding simple accessors to it.*Created by: ccober6*
## Enhancement
@trilinos/tempus
For a segregated linear solve, EMPIRE needs access to the WrapperModelEvaluator to get to alpha and beta. Adding simple accessors to it.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4973Trilinos seacas build issue on mayer with ARM compiler2020-07-22T01:04:26ZJames WillenbringTrilinos seacas build issue on mayer with ARM compiler*Created by: ikalash*
I'm encountering a build error when trying to build Trilinos develop on mayer with the ARM compiler (module load devpack-arm/20190201). Here is the error:
```
[ 41%] Building CXX object packages/seacas/libraries...*Created by: ikalash*
I'm encountering a build error when trying to build Trilinos develop on mayer with the ARM compiler (module load devpack-arm/20190201). Here is the error:
```
[ 41%] Building CXX object packages/seacas/libraries/ioss/src/CMakeFiles/Ioss.dir/Ioss_Node.C.o
[ 41%] Linking CXX executable nem_slice
Scanning dependencies of target mapvar
[ 41%] Building Fortran object packages/seacas/applications/mapvar/CMakeFiles/mapvar.dir/getbnd.f.o
[ 41%] Building Fortran object packages/seacas/applications/mapvar/CMakeFiles/mapvar.dir/mapvar.f.o
F90-S-0029-Illegal hexadecimal constant: Seehttps://github.com/gsjaardema/seacas/packages (/mscratch/albany/mayer/nightlyCDashTrilinos/repos/Trilinos/packages/seacas/applications/mapvar/mapvar.f: 417)
F90-S-0034-Syntax error at or near non-decimal constant 0 (/mscratch/albany/mayer/nightlyCDashTrilinos/repos/Trilinos/packages/seacas/applications/mapvar/mapvar.f: 417)
F90-S-0029-Illegal hexadecimal constant: Seehttps://github.com/gsjaardema/seacas/packages (/mscratch/albany/mayer/nightlyCDashTrilinos/repos/Trilinos/packages/seacas/applications/mapvar/mapvar.f: 428)
F90-S-0034-Syntax error at or near non-decimal constant 0 (/mscratch/albany/mayer/nightlyCDashTrilinos/repos/Trilinos/packages/seacas/applications/mapvar/mapvar.f: 428)
0 inform, 0 warnings, 4 severes, 0 fatal for mapvar
[ 41%] Building Fortran object packages/seacas/applications/mapvar/CMakeFiles/mapvar.dir/mklstv.f.o
[ 41%] Built target nem_slice
[ 41%] Building Fortran object packages/seacas/applications/mapvar/CMakeFiles/mapvar.dir/mkrnk.f.o
[ 41%] Building Fortran object packages/seacas/applications/mapvar/CMakeFiles/mapvar.dir/rank.f.o
[ 41%] Building Fortran object packages/seacas/applications/mapvar/CMakeFiles/mapvar.dir/srchge.f.o
[ 41%] Building Fortran object packages/seacas/applications/mapvar/CMakeFiles/mapvar.dir/srchgt.f.o
Scanning dependencies of target mapvar-kd
[ 41%] Building Fortran object packages/seacas/applications/mapvar-kd/CMakeFiles/mapvar-kd.dir/mapvar-kd.f.o
F90-S-0029-Illegal hexadecimal constant: Seehttps://github.com/gsjaardema/seacas/packages (/mscratch/albany/mayer/nightlyCDashTrilinos/repos/Trilinos/packages/seacas/applications/mapvar-kd/mapvar-kd.f: 285)
F90-S-0034-Syntax error at or near non-decimal constant 0 (/mscratch/albany/mayer/nightlyCDashTrilinos/repos/Trilinos/packages/seacas/applications/mapvar-kd/mapvar-kd.f: 285)
```
According to my colleague @jewatkins, the build worked just fine on April 9. Our configure script is attached.
[do-cmake-trilinos-arm-serial.txt](https://github.com/trilinos/Trilinos/files/3099602/do-cmake-trilinos-arm-serial.txt)
@trilinos/seacas
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4976ifpack - add an interface for a hypre set function taking int ** arguments to...2019-06-08T15:27:25ZJames Willenbringifpack - add an interface for a hypre set function taking int ** arguments to Ifpack_Hypre*Created by: jthano*
## Enhancement
@trilinos/ifpack
Ifpack_Hypre does not currently include an interface for a hypre parameter set function taking an int** argument. The only such set function in hypre is HYPRE_BoomerAMGSetGridRela...*Created by: jthano*
## Enhancement
@trilinos/ifpack
Ifpack_Hypre does not currently include an interface for a hypre parameter set function taking an int** argument. The only such set function in hypre is HYPRE_BoomerAMGSetGridRelaxPoints and there was a comment declaring this set function obsolete. However, this function will no longer be obsolete as it is being used for AIR AMG which can be found in the AIR branch of the development hypre repo. The AIR branch will be merged into master in the near future.
I have already added an interface for int** functions in my fork of Trilinos. I am creating this issue because the contribution guidelines state an issue should be created first and then referred to in a pull request. https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4979Dakota public distribution site down?2019-06-08T15:27:25ZJames WillenbringDakota public distribution site down?*Created by: ikalash*
Is the Dakota public distribution site (https://dakota.sandia.gov/sites/default/files/distributions/public) down? Our nightly Albany tests are supposed to pull dakota as follows:
wget -nv --no-check-certificat...*Created by: ikalash*
Is the Dakota public distribution site (https://dakota.sandia.gov/sites/default/files/distributions/public) down? Our nightly Albany tests are supposed to pull dakota as follows:
wget -nv --no-check-certificate https://dakota.sandia.gov/sites/default/files/distributions/public/dakota-6.9-release-public.src.tar.gz -v
and this operation started to fail over the weekend. I tried it on a non-Sandia machine and get the same issue, so I don't think it's a proxy thing. Also when I try to access the website, I get "Problem loading page" message. Perhaps the site moved?
@trilinos/trikota
@briadam
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4982MueLu: MueLu_Helmholtz2DParallel_MPI_4 failing on ATDM complex builds2019-06-08T15:27:25ZJames WillenbringMueLu: MueLu_Helmholtz2DParallel_MPI_4 failing on ATDM complex builds*Created by: fryeguy52*
## Bug Report
CC: @trilinos/muelu, @srajama1 (Trilinos Linear Solvers Product Lead), @bartlettroscoe, @fryeguy52
## Next Action Status
## Description
As shown in [this query](https://testing.sandia...*Created by: fryeguy52*
## Bug Report
CC: @trilinos/muelu, @srajama1 (Trilinos Linear Solvers Product Lead), @bartlettroscoe, @fryeguy52
## Next Action Status
## Description
As shown in [this query](https://testing.sandia.gov/cdash/queryTests.php?project=Trilinos&filtercombine=and&filtercombine=&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=5&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm-&field2=buildname&compare2=63&value2=-complex-&field3=testname&compare3=65&value3=MueLu_Helmholtz2DParallel_MPI_4&field4=buildstarttime&compare4=84&value4=2019-04-22T00%3A00%3A00&field5=buildstarttime&compare5=83&value5=2019-03-23T00%3A00%3A00) the test:
* MueLu_Helmholtz2DParallel_MPI_4
has been failing since 2019-01-11 in the builds:
* Trilinos-atdm-sems-rhel7-intel-17.0.1-openmp-complex-shared-debug
* Trilinos-atdm-sems-rhel7-gnu-7.2.0-openmp-complex-shared-release-debug
* Trilinos-atdm-sems-rhel7-intel-17.0.1-openmp-complex-shared-release-debug
* Trilinos-atdm-sems-rhel7-clang-3.9.0-openmp-complex-shared-release-debug
new commits on 2019-04-11 can be found [here](https://testing.sandia.gov/cdash/viewNotes.php?buildid=4867040#!#note2)
## Current Status on CDash
[results for the current testing day](https://testing.sandia.gov/cdash/queryTests.php?project=Trilinos&filtercombine=and&filtercombine=&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=5&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm-&field2=buildname&compare2=63&value2=complex&field3=testname&compare3=65&value3=MueLu_Helmholtz2DParallel_MPI_4&field4=buildstarttime&compare4=84&value4=today&field5=buildstarttime&compare5=83&value5=yesterday)
## Steps to Reproduce
One should be able to reproduce this failure on with a sems rhel6 environment as described in:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
More specifically, the commands given for with a sems rhel6 environment are provided at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#sems-rhel6-environment
The exact commands to reproduce this issue should be:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh Trilinos-atdm-sems-rhel6-gnu-7.2.0-openmp-complex-shared-release-debug
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnv.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_MueLu=ON \
$TRILINOS_DIR
$ make NP=16
$ ctest -j8
```
Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4989Muelu: MueLu_Maxwell3D-Tpetra_MPI_4 failing on atdm complex build2019-06-08T15:27:25ZJames WillenbringMuelu: MueLu_Maxwell3D-Tpetra_MPI_4 failing on atdm complex build*Created by: fryeguy52*
## Bug Report
CC: @trilinos/muelu, @srajama1 (Trilinos Linear Solvers Product Lead), @bartlettroscoe, @fryeguy52
<Checklist>
<???: Add label "ATDM">
<???: Add label "bug"?>
<???: Add label for affected pa...*Created by: fryeguy52*
## Bug Report
CC: @trilinos/muelu, @srajama1 (Trilinos Linear Solvers Product Lead), @bartlettroscoe, @fryeguy52
<Checklist>
<???: Add label "ATDM">
<???: Add label "bug"?>
<???: Add label for affected packages (e.g. "MueLu", "Tpetra", "Kokkos", etc.)>
<???: Add milestone "Initial cleanup of new ATDM builds of Trilinos" or "Keep promoted ATDM builds of Trilinos clean">
<???: Once GitHub Issue is created, add entries for tests to TrilinosATDMStatus/*.csv files>
<???: Add label "PA: ???Project Area???" (e.g. "PA: Linear Solvers", "PA: Data Services")>
## Next Action Status
<status-and-or-first-action>
## Description
As shown in [this query](https://testing.sandia.gov/cdash/queryTests.php?project=Trilinos&filtercombine=and&filtercombine=&filtercombine=and&filtercount=5&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Trilinos-atdm-sems-rhel7-intel-17.0.1-openmp-complex-shared-release-debug&field2=testname&compare2=61&value2=MueLu_Maxwell3D-Tpetra_MPI_4&field3=site&compare3=61&value3=sems-rhel7&field4=buildstarttime&compare4=84&value4=2019-04-22T00%3A00%3A00&field5=buildstarttime&compare5=83&value5=2019-03-23T00%3A00%3A00) the test:
* MueLu_Maxwell3D-Tpetra_MPI_4
is failing in the build:
* Trilinos-atdm-sems-rhel7-intel-17.0.1-openmp-complex-shared-release-debug
## Current Status on CDash
[Test results last 5 days](https://testing.sandia.gov/cdash/queryTests.php?project=Trilinos&filtercombine=and&filtercombine=&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=4&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Trilinos-atdm-sems-rhel7-intel-17.0.1-openmp-complex-shared-release-debug&field2=testname&compare2=61&value2=MueLu_Maxwell3D-Tpetra_MPI_4&field3=site&compare3=61&value3=sems-rhel7&field4=buildstarttime&compare4=83&value4=5%20days%20ago)
## Steps to Reproduce
One should be able to reproduce this failure on with a sems rhel6 environment as described in:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
More specifically, the commands given for with a sems rhel6 environment are provided at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#sems-rhel6-environment
The exact commands to reproduce this issue should be:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh Trilinos-atdm-sems-rhel7-intel-17.0.1-openmp-complex-shared-release-debug
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnv.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_MueLu=ON \
$TRILINOS_DIR
$ make NP=16
$ ctest -j8
```
Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4992Amesos2 does not support Epetra with Tpetra_INST_INT_INT=OFF2019-06-08T15:27:25ZJames WillenbringAmesos2 does not support Epetra with Tpetra_INST_INT_INT=OFF*Created by: mhoemmen*
## Bug Report
@trilinos/amesos2 @rppawlo @kddevin
### Description
Amesos2 does not support Epetra with `Tpetra_INST_INT_INT=OFF`.
### Steps to Reproduce
1. Set `Tpetra_INST_INT_INT=OFF` and `Amesos2_...*Created by: mhoemmen*
## Bug Report
@trilinos/amesos2 @rppawlo @kddevin
### Description
Amesos2 does not support Epetra with `Tpetra_INST_INT_INT=OFF`.
### Steps to Reproduce
1. Set `Tpetra_INST_INT_INT=OFF` and `Amesos2_ENABLE_Epetra=ON`
2. Watch Amesos2 complain and fail to implement the feature
This is related to #3234. That issue was about Amesos2 failing to catch its failure to implement this feature.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5019MueLu: Epetra unit-tests try to run with kokkos-refactored factories2019-06-08T15:27:25ZJames WillenbringMueLu: Epetra unit-tests try to run with kokkos-refactored factories*Created by: lucbv*
## Bug Report
@trilinos/muelu
### Description
Some unit-tests are currently being run with both Epetra and kokkos refactor, which is supported. But these tests are also asking for the kokkos factories in MueLu ...*Created by: lucbv*
## Bug Report
@trilinos/muelu
### Description
Some unit-tests are currently being run with both Epetra and kokkos refactor, which is supported. But these tests are also asking for the kokkos factories in MueLu because of the `Kokkos_Refactor_On_By_Default` variable being set ON by default when `MueLu_ENABLE_KokkosCore` is ON too.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5011Xpetra broke Albany and SPARC nightly builds2019-06-08T15:27:25ZJames WillenbringXpetra broke Albany and SPARC nightly builds*Created by: ikalash*
Looks like we have a compilation error in our nightlies when compiling against a new develop Trilinos:
```
from /.../trilinos-install-serial-intel-release/include/Piro_SolverFactory.hpp(97),
...*Created by: ikalash*
Looks like we have a compilation error in our nightlies when compiling against a new develop Trilinos:
```
from /.../trilinos-install-serial-intel-release/include/Piro_SolverFactory.hpp(97),
from /.../Albany/src/Albany_SolverFactory.cpp(24):
/.../trilinos-install-serial-intel-release/include/Xpetra_CrsMatrixFactory.hpp(54): catastrophic error: cannot open source file "Xpetra_TpetraCrsMatrix.hpp"
#include "Xpetra_TpetraCrsMatrix.hpp"
^
```
http://cdash.sandia.gov/CDash-2-3-0/viewBuildError.php?buildid=84042
@trilinos/xpetra https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5038Tpetra: Spurious unused function warnings (iallreduceIntRaw, makeValidVerbose...2019-06-08T15:27:25ZJames WillenbringTpetra: Spurious unused function warnings (iallreduceIntRaw, makeValidVerboseStream)*Created by: mhoemmen*
## Bug Report
@trilinos/tpetra @ajpowelsnl
### Description
```
.../include/Tpetra_CrsMatrix_def.hpp:89:3: error: 'std::shared_ptr<Tpetra::Details::CommRequest> Tpetra::{anonymous}::iallreduceIntRaw(const ...*Created by: mhoemmen*
## Bug Report
@trilinos/tpetra @ajpowelsnl
### Description
```
.../include/Tpetra_CrsMatrix_def.hpp:89:3: error: 'std::shared_ptr<Tpetra::Details::CommRequest> Tpetra::{anonymous}::iallreduceIntRaw(const int&, int&, Teuchos::EReductionType, const Teuchos::Comm<int>&)' defined but not used [-Werror=unused-function]
iallreduceIntRaw (const int& localValue,
^~~~~~~~~~~~~~~~
```
This is spurious. See discussion [here](https://github.com/trilinos/Trilinos/issues/3178#issuecomment-482171111
). However, it appears to block Sierra/Trilinos promotion, so I'll fix it.
There's another spurious unused function warning involving `makeValidVerboseStream` in `Ifpack2_ImportExportData_def.hpp`.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5025MueLu: MMKernel test failing on Cuda2019-06-08T15:27:25ZJames WillenbringMueLu: MMKernel test failing on Cuda*Created by: lucbv*
## Bug Report
@trilinos/muelu @jjellio
### Description
The MMKernelDriver is not compiling with Cuda enabled on geminga.
This seems to be caused by raw openmp calls in the driver, maybe adding appropriate guar...*Created by: lucbv*
## Bug Report
@trilinos/muelu @jjellio
### Description
The MMKernelDriver is not compiling with Cuda enabled on geminga.
This seems to be caused by raw openmp calls in the driver, maybe adding appropriate guards would fix these?
### Steps to Reproduce
Look at [this build](https://testing.sandia.gov/cdash/buildSummary.php?buildid=4960432) on gemingahttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/5029TrilinosCouplings: Build error (missing header file)2019-06-08T15:27:25ZJames WillenbringTrilinosCouplings: Build error (missing header file)*Created by: mhoemmen*
## Bug Report
@trilinos/trilinoscouplings
### Description
```
.../Trilinos/packages/trilinoscouplings/examples/fenl/fenl_ensemble.hpp:156:18: error: ‘PseudoBlockCGSolMgr’ in namespace ‘Belos’ does not name ...*Created by: mhoemmen*
## Bug Report
@trilinos/trilinoscouplings
### Description
```
.../Trilinos/packages/trilinoscouplings/examples/fenl/fenl_ensemble.hpp:156:18: error: ‘PseudoBlockCGSolMgr’ in namespace ‘Belos’ does not name a template type
const Belos::PseudoBlockCGSolMgr<Sc, V, O>* cg_solver =
^
.../Trilinos/packages/trilinoscouplings/examples/fenl/fenl_ensemble.hpp:158:9: error: ‘cg_solver’ was not declared in this scope
if (cg_solver != 0)
^
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5047Framework: Cannot push or pull from github2019-06-08T15:27:25ZJames WillenbringFramework: Cannot push or pull from github*Created by: csiefer2*
csiefer@mymachine> git pull --rebase
You don't exist, go away!
fatal: The remote end hung up unexpectedly
(It worked yesterday, FYI)*Created by: csiefer2*
csiefer@mymachine> git pull --rebase
You don't exist, go away!
fatal: The remote end hung up unexpectedly
(It worked yesterday, FYI)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2416Tpetra::Details::computeOffsets*: Missing fence for UVM2018-03-20T17:02:13ZJames WillenbringTpetra::Details::computeOffsets*: Missing fence for UVM*Created by: mhoemmen*
@bathmatt reported an issue with `Tpetra::Details::computeOffsetsFromCounts` on CUDA:
https://github.com/trilinos/Trilinos/blob/a60ff45d9f0180d8782904546eb10165d15031af/packages/tpetra/core/src/Tpetra_Details_c...*Created by: mhoemmen*
@bathmatt reported an issue with `Tpetra::Details::computeOffsetsFromCounts` on CUDA:
https://github.com/trilinos/Trilinos/blob/a60ff45d9f0180d8782904546eb10165d15031af/packages/tpetra/core/src/Tpetra_Details_computeOffsets.hpp#L373
Note that the function returns an entry of a `CudaUVMSpace` array on host, without an intervening fence. `Tpetra::Details::computeOffsetsFromConstantCount` has the same issue. @bathmatt says that changing the following line:
https://github.com/trilinos/Trilinos/blob/a60ff45d9f0180d8782904546eb10165d15031af/packages/tpetra/core/src/Tpetra_Details_computeOffsets.hpp#L371
to say `if (std::is_same<Kokkos::HostSpace,` fixes the issue. The following line in `computeOffsetsFromConstantCount` would need to change accordingly:
https://github.com/trilinos/Trilinos/blob/a60ff45d9f0180d8782904546eb10165d15031af/packages/tpetra/core/src/Tpetra_Details_computeOffsets.hpp#L461
@trilinos/tpetra https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1624Panzer: Update Integrator_BasisTimesVector2017-09-05T23:25:58ZJames WillenbringPanzer: Update Integrator_BasisTimesVector*Created by: jmgate*
The `panzer::Integrator_BasisTimesVector` class needs to be updated to support the new `CONTRIBUTES` style `Evaluator`, as per #1575. An example of the changes to be made can be found in the `panzer::Integrator_Bas...*Created by: jmgate*
The `panzer::Integrator_BasisTimesVector` class needs to be updated to support the new `CONTRIBUTES` style `Evaluator`, as per #1575. An example of the changes to be made can be found in the `panzer::Integrator_BasisTimesScalar` class.
@trilinos/panzerhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/177Tpetra BCRS: Replace LittleBlock and LittleVector with unmanaged LayoutRight ...2016-05-24T18:46:15ZJames WillenbringTpetra BCRS: Replace LittleBlock and LittleVector with unmanaged LayoutRight Kokkos::View*Created by: mhoemmen*
@trilinos/tpetra @trilinos/ifpack2
@crtrott @kyungjoo-kim @amklinv
In Tpetra::Experimental::BlockCrsMatrix, replace LittleBlock and LittleVector with _unmanaged_ LayoutRight `Kokkos::View` (of rank 2 resp. 1). ...*Created by: mhoemmen*
@trilinos/tpetra @trilinos/ifpack2
@crtrott @kyungjoo-kim @amklinv
In Tpetra::Experimental::BlockCrsMatrix, replace LittleBlock and LittleVector with _unmanaged_ LayoutRight `Kokkos::View` (of rank 2 resp. 1). Please retain the typedefs little_block_type, const_little_block_type, little_vec_type, and const_little_vec_type, but use `Kokkos::View` for these instead of LittleBlock resp. LittleVector.
You _must_ use LayoutRight, because users' code explicitly assumes LayoutRight. Later we can relax this assumption, but for now please retain it. Please specify LayoutRight explicitly in the View types, because otherwise it will have the wrong layout with Cuda (whose default layout is LayoutLeft).
Please note that this will affect Ifpack2 as well as Sierra Aero (please contact the relevant developers of the latter to ensure that we don't break their code). Some Ifpack2 solvers (in particular, block ILU(k)) use these classes and depend on the particular form of their constructors. For example, LittleBlock's constructor takes two strides -- a row stride and a column stride. Thus, this is not an entirely trivial change in Ifpack2. However, all use of these classes in Tpetra and Ifpack2 assumes unit-stride LittleVector and row-major LittleBlock, so you may make this assumption when modifying code.
These changes will have the following beneficial effects:
1. Less code to compile (four classes per (Scalar, LocalOrdinal) combination, as well as templated BLAS 1, 2, and 3 functions)
2. Simplify transition of Tpetra BlockCrsMatrix to a completely Kokkos-based implementation, thus facilitating good manycore performance
They incur the risk of slightly more struct copy overhead (`Kokkos::View` has a bit more state than LittleBlock and LittleVector) in computational kernels, but kernels might not want to pass structs around anyway for best performance.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2459Tpetra: Add scope guard for initialize/finalize2018-07-06T19:46:14ZJames WillenbringTpetra: Add scope guard for initialize/finalize*Created by: mhoemmen*
Add a scope guard for Tpetra::initialize / Tpetra::finalize. Imitate the corresponding Kokkos solution: https://github.com/kokkos/kokkos/issues/1479
@trilinos/tpetra
## Motivation and Context
Users are ...*Created by: mhoemmen*
Add a scope guard for Tpetra::initialize / Tpetra::finalize. Imitate the corresponding Kokkos solution: https://github.com/kokkos/kokkos/issues/1479
@trilinos/tpetra
## Motivation and Context
Users are used to `Teuchos::GlobalMPISession`, which is a scope guard. Naïve conversion to `Tpetra::initialize` / `Tpetra::finalize` may result in forgetting to call `Tpetra::finalize` before premature exit of `main`. Premature exit may be either by `return` or by throwing an exception.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/489Remove redundant TriBITS includes in CMakeLists.txt files2016-12-01T14:24:56ZJames WillenbringRemove redundant TriBITS includes in CMakeLists.txt files*Created by: bartlettroscoe*
**Next Action Status:**
Changes accepted for SEACAS github repo. Changes for native Trilinos packages pushed. Next: Wait for STK to make changes in native repo and Kokkos to accept PR ...
**CC:** @trilin...*Created by: bartlettroscoe*
**Next Action Status:**
Changes accepted for SEACAS github repo. Changes for native Trilinos packages pushed. Next: Wait for STK to make changes in native repo and Kokkos to accept PR ...
**CC:** @trilinos/framework
**Description**
A long time ago, TriBITS added all the includes needed to process project, repository, and package files to the TriBITS.cmake file. This avoids the need to include the same files over and over again in user `*.cmake` and `CMakeLists.txt` files. This removes clutter and speeds up configures.
There is a single script in TriBITS that automatically does this upgrade:
TriBITS/refactoring/remove_std_tribits_includes_r.sh
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2931MueLu: error building RefMaxwell on CUDA when KokkosRefactor=ON2018-06-16T01:58:50ZJames WillenbringMueLu: error building RefMaxwell on CUDA when KokkosRefactor=ON*Created by: aprokop*
@trilinos/muelu @cgcgcg
## Expectations
Muelu builds using CUDA.
## Current Behavior
The build fails using CUDA 8.0 with the following errors:
```
/home/xap/code/trilinos/packages/muelu/adapters/xpet...*Created by: aprokop*
@trilinos/muelu @cgcgcg
## Expectations
Muelu builds using CUDA.
## Current Behavior
The build fails using CUDA 8.0 with the following errors:
```
/home/xap/code/trilinos/packages/muelu/adapters/xpetra/MueLu_RefMaxwell_def.hpp(652): error: device code does not support exception handling
/home/xap/code/trilinos/packages/muelu/adapters/xpetra/MueLu_RefMaxwell_def.hpp(676): error: device code does not support exception handling
```
The code in question is obviously off as it does
```c++
TEUCHOS_ASSERT_EQUALITY(P11colind(m),jNew);
```
which could throw which is not possible on device.
Removing those lines makes the code compile, but a better solution is probably needed.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2100Configuration fails: CMake Error: CMake can not determine linker language for...2018-08-22T15:19:35ZJames WillenbringConfiguration fails: CMake Error: CMake can not determine linker language for target: blotlib*Created by: yurivict*
This error occurs when ```-DTPL_ENABLE_Netcdf=ON```:
```
-- Configuring done
CMake Error: CMake can not determine linker language for target: blotlib
CMake Error: CMake can not determine linker language for ...*Created by: yurivict*
This error occurs when ```-DTPL_ENABLE_Netcdf=ON```:
```
-- Configuring done
CMake Error: CMake can not determine linker language for target: blotlib
CMake Error: CMake can not determine linker language for target: blotlib
CMake Error in packages/seacas/applications/blot/CMakeLists.txt:
Exporting the target "blotlib" is not allowed since its linker language
cannot be determined
```
Version: 12-12-1 on FreeBSD 11.1
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/914panzer not building under clang2017-03-24T15:32:21ZJames Willenbringpanzer not building under clang*Created by: bathmatt*
Getting an error on panzer with clang.
using sems-clang/3.9.0
@jmgate @eric-c-cyr @rppawlo
Probably won't get to this, this year but
FAILED: packages/panzer/dof-mgr/src/CMakeFiles/panzer-dof-mgr.di...*Created by: bathmatt*
Getting an error on panzer with clang.
using sems-clang/3.9.0
@jmgate @eric-c-cyr @rppawlo
Probably won't get to this, this year but
FAILED: packages/panzer/dof-mgr/src/CMakeFiles/panzer-dof-mgr.dir/Panzer_Filtered_UniqueGlobalIndexer.cpp.o
/projects/sems/install/rhel6-x86_64/sems/compiler/clang/3.9.0/openmpi/1.10.1/bin/mpicxx -I. -Ipackages/panzer/dof-mgr/src -I/home/mbetten/Trilinos/Trilinos/packages/panzer/dof-mgr/src -Ipackages/panzer/core/src -I/home/mbetten/Trilinos/Trilinos/packages/panzer/core/src -I/home/mbetten/Trilinos/Trilinos/packages/teuchos/comm/src -I/home/mbetten/Trilinos/Trilinos/packages/teuchos/parameterlist/src -Ipackages/teuchos/core/src -I/home/mbetten/Trilinos/Trilinos/packages/teuchos/core/src -Ipackages/kokkos/core/src -I/home/mbetten/Trilinos/Trilinos/packages/kokkos/core/src -I/projects/sems/install/rhel6-x86_64/sems/tpl/boost/1.59.0/clang/3.9.0/base/include -Ipackages/phalanx/src -I/home/mbetten/Trilinos/Trilinos/packages/phalanx/src -Ipackages/intrepid2/refactor/src -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Cell -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Discretization/Basis -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Discretization/FunctionSpaceTools -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Discretization/Integration -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Orientation -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Shared -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Shared/../../../core/src/Shared/MiniTensor -I/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src -Ipackages/shards/src -I/home/mbetten/Trilinos/Trilinos/packages/shards/src -Ipackages/sacado/src -I/home/mbetten/Trilinos/Trilinos/packages/sacado/src -I/home/mbetten/Trilinos/Trilinos/packages/sacado/src/template -I/home/mbetten/Trilinos/Trilinos/packages/sacado/src/parameter -I/home/mbetten/Trilinos/Trilinos/packages/sacado/src/mpl -Ipackages/teuchos/kokkoscomm/src -I/home/mbetten/Trilinos/Trilinos/packages/teuchos/kokkoscomm/src -Ipackages/teuchos/kokkoscompat/src -I/home/mbetten/Trilinos/Trilinos/packages/teuchos/kokkoscompat/src -I/home/mbetten/Trilinos/Trilinos/packages/teuchos/remainder/src -Ipackages/teuchos/remainder/src -I/home/mbetten/Trilinos/Trilinos/packages/teuchos/numerics/src -Ipackages/kokkos/algorithms/src -I/home/mbetten/Trilinos/Trilinos/packages/kokkos/algorithms/src -Ipackages/kokkos/containers/src -I/home/mbetten/Trilinos/Trilinos/packages/kokkos/containers/src -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/core/ext -Ipackages/tpetra/core/ext -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/core/inout -Ipackages/tpetra/core/inout -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/core/src -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/core/src/kokkos_refactor -Ipackages/tpetra/core/src -Ipackages/tpetra/kernels/src -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/kernels/src -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/kernels/src/impl -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/classic/LinAlg -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/classic/NodeAPI -Ipackages/tpetra/classic/NodeAPI -Ipackages/tpetra/classic/src -I/home/mbetten/Trilinos/Trilinos/packages/tpetra/classic/src -Ipackages/epetra/src -I/home/mbetten/Trilinos/Trilinos/packages/epetra/src -std=c++11 -g -MD -MT packages/panzer/dof-mgr/src/CMakeFiles/panzer-dof-mgr.dir/Panzer_Filtered_UniqueGlobalIndexer.cpp.o -MF packages/panzer/dof-mgr/src/CMakeFiles/panzer-dof-mgr.dir/Panzer_Filtered_UniqueGlobalIndexer.cpp.o.d -o packages/panzer/dof-mgr/src/CMakeFiles/panzer-dof-mgr.dir/Panzer_Filtered_UniqueGlobalIndexer.cpp.o -c /home/mbetten/Trilinos/Trilinos/packages/panzer/dof-mgr/src/Panzer_Filtered_UniqueGlobalIndexer.cpp
In file included from /home/mbetten/Trilinos/Trilinos/packages/panzer/dof-mgr/src/Panzer_Filtered_UniqueGlobalIndexer.cpp:45:
In file included from /home/mbetten/Trilinos/Trilinos/packages/panzer/dof-mgr/src/Panzer_Filtered_UniqueGlobalIndexer.hpp:46:
In file included from /home/mbetten/Trilinos/Trilinos/packages/panzer/dof-mgr/src/Panzer_UniqueGlobalIndexer.hpp:51:
/home/mbetten/Trilinos/Trilinos/packages/teuchos/core/src/Teuchos_RCP.hpp:288:5: error: cannot initialize a member subobject of type 'const Tpetra::Map<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Threads, Kokkos::HostSpace> > *' with an rvalue of type 'const Tpetra::Map<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > *'
: ptr_(r_ptr.get()), // will not compile if T is not base class of T2
^ ~~~~~~~~~~~
/home/mbetten/Trilinos/Trilinos/packages/panzer/dof-mgr/src/Panzer_Filtered_UniqueGlobalIndexer_impl.hpp:116:9: note: in instantiation of function template specialization 'Teuchos::RCP<const Tpetra::Map<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Threads, Kokkos::HostSpace> > >::RCP<const Tpetra::Map<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > >' requested here
= Tpetra::createNonContigMap<LO,GO>(ownedIndices,getComm());
^
1 error generated.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/329Missing ETI for Amesos2Wrapper breaks linking of Ifpack2 and all downstream p...2016-05-02T21:11:11ZJames WillenbringMissing ETI for Amesos2Wrapper breaks linking of Ifpack2 and all downstream packages*Created by: tawiesn*
> This issue appears to be this commit:
>
> https://github.com/trilinos/Trilinos/commit/4312d673edacb4b4aa82d0b0fa47b9738bfd980f#diff-4c11d37d5b774d63c2acd88a73299d88
>
> which introduced BlockRelaxation< row_mat...*Created by: tawiesn*
> This issue appears to be this commit:
>
> https://github.com/trilinos/Trilinos/commit/4312d673edacb4b4aa82d0b0fa47b9738bfd980f#diff-4c11d37d5b774d63c2acd88a73299d88
>
> which introduced BlockRelaxation< row_matrix , SparseContainer < row_matrix , Amesos2Wrapper<row_matrix> > > without ETI of BlockRelaxation on that set of template parameters.
>
> -Eric
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1599missing Kokkos_OpenMPNode in xpetra2017-08-14T23:20:41ZJames Willenbringmissing Kokkos_OpenMPNode in xpetra*Created by: lucbv*
@trilinos/xpetra @trilinos/muelu
While working on an unrelated (#1597) pull request I discovered that Xpetra does not compile if the following configuration is chosen:
```
-D Trilinos_ENABLE_Kokkos=OFF \
-D Tril...*Created by: lucbv*
@trilinos/xpetra @trilinos/muelu
While working on an unrelated (#1597) pull request I discovered that Xpetra does not compile if the following configuration is chosen:
```
-D Trilinos_ENABLE_Kokkos=OFF \
-D Trilinos_ENABLE_Tpetra=OFF \
-D Trilinos_ENABLE_OpenMP=ON \
```
This might happen if you want openmp with the Epetra stack.
The problem is that in ```xpetra/src/FakeKokkos``` a class is missing for ```Kokkos_OpenMPWrapperNode``` which then create problems with typedef of EpetraNode.
A simple fix is to create said class.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2334Tpetra: Remove `Teuchos::as` call from device kernel2018-03-06T00:36:38ZJames WillenbringTpetra: Remove `Teuchos::as` call from device kernel*Created by: mhoemmen*
See Line 2272 of `tpetra/core/ext/TpetraExt_MatrixMatrix_def.hpp`:
https://github.com/trilinos/Trilinos/blob/ecd9196b7f185a50a88fa3e0a33df293b723b95d/packages/tpetra/core/ext/TpetraExt_MatrixMatrix_def.hpp#L227...*Created by: mhoemmen*
See Line 2272 of `tpetra/core/ext/TpetraExt_MatrixMatrix_def.hpp`:
https://github.com/trilinos/Trilinos/blob/ecd9196b7f185a50a88fa3e0a33df293b723b95d/packages/tpetra/core/ext/TpetraExt_MatrixMatrix_def.hpp#L2272
`Teuchos::as` is host only. The call likely only builds because of compiler inlining. In some configurations, though, `Teuchos::as` throws on overflow. Throwing exceptions is forbidden in CUDA device code. See my comment here: https://github.com/trilinos/Trilinos/pull/2332/files#r172092273
@trilinos/tpetra https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3069Stokhos build failure for CUDA 8.0 Debug build on white/ride2018-11-30T03:20:52ZJames WillenbringStokhos build failure for CUDA 8.0 Debug build on white/ride*Created by: bartlettroscoe*
CC: @trilinos/stokhos, @rppawlo (Trilinos Nonlinear Solvers Product Lead)
## Next Action Status
PR #3100 merged on 7/13/2018 resulted in 100% clean build (but not tests), including Stokhos, on 7/14/201...*Created by: bartlettroscoe*
CC: @trilinos/stokhos, @rppawlo (Trilinos Nonlinear Solvers Product Lead)
## Next Action Status
PR #3100 merged on 7/13/2018 resulted in 100% clean build (but not tests), including Stokhos, on 7/14/2018.
## Description
The creation of the Stokhos library `libstokhos_muelu.a` fails in the CUDA 8.0 debug build `Trilinos-atdm-white-ride-cuda-debug-pt-all-at-once` 'white' and 'ride'. The build error output for the build this morning shown [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=3688768) on 'white' shows:
```
/usr/bin/ar: packages/stokhos/src/libstokhos_muelu.a: File truncated
```
## Steps to reproduce
This build error can reproduced on 'white' or 'ride' as described in the document:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
The specific instructions for 'white' or 'ride' are given at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#ridewhite
The one difference is that this build of all of the Primary Tested Trilinos packages (that includes more package than are being used by ATDM APPs currently) does not exclude any Trilinos packages and tweaks a few other settings so it uses the file `Trilinos/cmake/std/atdm/ATDMDevEnvAllPtPackages.cmake` instead of the file `ATDMDevEnv.cmake`.
After cloning Trilinos, the following commands should reproduce the build failure:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh cuda-debug
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnvAllPtPackages.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_Stokhos=ON \
$TRILINOS_DIR
$ make NP=16
```
I (@bartlettroscoe) just tired this on 'white' and I was able to reproduce the same build failure shown on CDash shown above.
Initial cleanup of new ATDM builds of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2340MueLu: Link error with Kokkos (& Tpetra) disabled2018-04-10T15:59:55ZJames WillenbringMueLu: Link error with Kokkos (& Tpetra) disabled*Created by: mhoemmen*
```
CMakeFiles/MueLu_UnitTests.dir/TentativePFactory.cpp.o: In function `MueLuTests::TentativePFactory_NoQROption_UnitTest<double, int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>::runUnitTestImpl(Teuchos::basi...*Created by: mhoemmen*
```
CMakeFiles/MueLu_UnitTests.dir/TentativePFactory.cpp.o: In function `MueLuTests::TentativePFactory_NoQROption_UnitTest<double, int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>::runUnitTestImpl(Teuchos::basic_FancyOStream<char, std::char_traits<char> >&, bool&) const':
.../Trilinos/packages/muelu/test/unit_tests/TentativePFactory.cpp:333: undefined reference to `Teuchos::RCP<Xpetra::Map<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode> > Galeri::Xpetra::CreateMap<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>(Xpetra::UnderlyingLib, std::string const&, Teuchos::RCP<Teuchos::Comm<int> const> const&, Teuchos::ParameterList&)'
CMakeFiles/MueLu_UnitTests.dir/UnsmooshFactory.cpp.o: In function `MueLuTests::UnsmooshFactory_UnsmooshTentativeP_UnitTest<double, int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>::runUnitTestImpl(Teuchos::basic_FancyOStream<char, std::char_traits<char> >&, bool&) const':
.../Trilinos/packages/muelu/test/unit_tests/UnsmooshFactory.cpp:91: undefined reference to `Teuchos::RCP<Xpetra::Map<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode> > Galeri::Xpetra::CreateMap<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>(Xpetra::UnderlyingLib, std::string const&, Teuchos::RCP<Teuchos::Comm<int> const> const&, Teuchos::ParameterList&)'
CMakeFiles/MueLu_UnitTests.dir/VariableDofLaplacianFactory.cpp.o: In function `MueLuTests::VariableDofLaplacianFactory_VarLaplConstructor2_UnitTest<double, int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>::runUnitTestImpl(Teuchos::basic_FancyOStream<char, std::char_traits<char> >&, bool&) const':
.../Trilinos/packages/muelu/test/unit_tests/VariableDofLaplacianFactory.cpp:137: undefined reference to `Teuchos::RCP<Xpetra::Map<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode> > Galeri::Xpetra::CreateMap<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>(Xpetra::UnderlyingLib, std::string const&, Teuchos::RCP<Teuchos::Comm<int> const> const&, Teuchos::ParameterList&)'
CMakeFiles/MueLu_UnitTests.dir/VariableDofLaplacianFactory.cpp.o: In function `MueLuTests::VariableDofLaplacianFactory_VarLaplPtent_UnitTest<double, int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>::runUnitTestImpl(Teuchos::basic_FancyOStream<char, std::char_traits<char> >&, bool&) const':
.../Trilinos/packages/muelu/test/unit_tests/VariableDofLaplacianFactory.cpp:235: undefined reference to `Teuchos::RCP<Xpetra::Map<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode> > Galeri::Xpetra::CreateMap<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>(Xpetra::UnderlyingLib, std::string const&, Teuchos::RCP<Teuchos::Comm<int> const> const&, Teuchos::ParameterList&)'
CMakeFiles/MueLu_UnitTests.dir/Repartition.cpp.o: In function
`MueLuTests::Repartition_CoordinateMap_UnitTest<double, int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>::runUnitTestImpl(Teuchos::basic_FancyOStream<char, std::char_traits<char> >&, bool&) const':
.../Trilinos/packages/muelu/test/unit_tests/Repartition.cpp:855: undefined reference to `Teuchos::RCP<Xpetra::Map<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode> > Galeri::Xpetra::CreateMap<int, int, Kokkos::Compat::KokkosOpenMPWrapperNode>(Xpetra::UnderlyingLib, std::string const&, Teuchos::RCP<Teuchos::Comm<int> const> const&, Teuchos::ParameterList&)'
collect2: error: ld returned 1 exit status
make[2]: *** [packages/muelu/test/unit_tests/MueLu_UnitTests.exe] Error 1
make[1]: *** [packages/muelu/test/unit_tests/CMakeFiles/MueLu_UnitTests.dir/all] Error 2
make: *** [all] Error 2
```
@trilinos/muelu https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2339MueLu test fails to build when Tpetra is disabled2018-03-05T21:46:32ZJames WillenbringMueLu test fails to build when Tpetra is disabled*Created by: mhoemmen*
MueLu only optionally depends on Tpetra, but it fails to build when Tpetra (actually Kokkos, but Tpetra requires Kokkos) is disabled. Here is the build error I get:
```
[ 98%] Building CXX object packages/muelu...*Created by: mhoemmen*
MueLu only optionally depends on Tpetra, but it fails to build when Tpetra (actually Kokkos, but Tpetra requires Kokkos) is disabled. Here is the build error I get:
```
[ 98%] Building CXX object packages/muelu/test/unit_tests/CMakeFiles/MueLu_UnitTests.dir/Galeri.cpp.o
.../Trilinos/packages/muelu/test/unit_tests/Galeri.cpp:59:40: fatal error: TpetraCore_ETIHelperMacros.h: No such file or directory
#include <TpetraCore_ETIHelperMacros.h>
^
compilation terminated.
```
@trilinos/muelu
## Related Issues
* Blocks #2273 (downstream testing)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2131Test Zoltan2_OrderingScotch_MPI_4 hanging on crf4502018-03-20T12:54:42ZJames WillenbringTest Zoltan2_OrderingScotch_MPI_4 hanging on crf450*Created by: bartlettroscoe*
**CC:** @trilinos/zoltan2
## Description
The test `Zoltan2_OrderingScotch_MPI_4` is only run in automated builds associated with the CI build run on the machine `ceerws1113` linked to from [here](https...*Created by: bartlettroscoe*
**CC:** @trilinos/zoltan2
## Description
The test `Zoltan2_OrderingScotch_MPI_4` is only run in automated builds associated with the CI build run on the machine `ceerws1113` linked to from [here](https://github.com/trilinos/Trilinos/wiki/Policies--%7C-Testing#post_push_ci_testing) and the [checkin-test-sems.sh](https://github.com/trilinos/Trilinos/wiki/Policies-%7C-Safe-Checkin-Testing) script. This test is currently passing fine when run on the machine `ceerws1113` as shown here:
* https://testing.sandia.gov/cdash/queryTests.php?project=Trilinos&date=2018-01-04&limit=0&filtercount=2&showfilters=1&filtercombine=and&field1=testname&compare1=61&value1=Zoltan2_OrderingScotch_MPI_4&field2=buildstarttime&compare2=84&value2=now
However, for some reason, this test started hanging on my machine `crf450`. It is blocking my push with the checkin-test-sems.sh script. The test shows the output:
```
Starting everything
UserInputForTests, Read: ./simple_ordering.mtx
UserInputForTests, Read: ./simple_ordering_coord.mtx
NumRows = 25
NumNonzeros = 25
NumProcs = 4
Going to solve
Ordering does not support distributed matrices.
Ordering does not support distributed matrices.
Ordering does not support distributed matrices.
```
and then just hangs and times-out at 300s. The passing test shown, for example, at:
* https://testing.sandia.gov/cdash/testDetails.php?test=43287778&build=3314362
shows that same output and the line:
```
Scotch Ordering test with 4 processes has test return code 0 and is exiting in the PASSED state
```
The version of Trilinos I used to test this was:
```
commit 052a35ccf89d09ae9d1ca13f40ee469f84aafcb3
Author: Jonathan Hu <jhu@sandia.gov>
Date: Thu Jan 4 15:49:05 2018 -0800
Testing: geminga: disable complex for cuda builds
This commit removes scalar type complex<double> from the configure line,
pending resolution of github issue #2115.
M cmake/ctest/drivers/geminga/TrilinosCTestDriverCore.geminga.gcc-cuda.cmake
M cmake/ctest/drivers/geminga/ctest_linux_nightly_mpi_release_muelu_kokkos_refactor_cuda_geminga.cmake
```
I produced this on crf450 with:
```
./checkin-test-sems.sh --no-enable-fwd-packages --enable-packages=Zoltan2 --local-do-all
```
with that above version of Trilinos.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1223Intrepid2 now produces a lot of warnings under gcc and even more under cuda2017-05-09T22:35:48ZJames WillenbringIntrepid2 now produces a lot of warnings under gcc and even more under cuda*Created by: bathmatt*
compiling panzer produces warnings in intrepid2 under these flags. We need to clean these up to keep things clean going forward
-Wnarrowing and -Wdeprecated-declarations
examples are
```
/home/mbetten/T...*Created by: bathmatt*
compiling panzer produces warnings in intrepid2 under these flags. We need to clean these up to keep things clean going forward
-Wnarrowing and -Wdeprecated-declarations
examples are
```
/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Cell/Intrepid2_CellToolsDefJacobian.hpp:172:80: warning: narrowing conversion of ‘jacobian.Kokkos::Experimental::DynRankView<DataType, Properties>::dimension<int>(0)’ from ‘
std::enable_if<true, long unsigned int>::type {aka long unsigned int}’ to ‘long int’ inside { } [-Wnarrowing]
/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Cell/Intrepid2_CellToolsDefJacobian.hpp:172:80: warning: narrowing conversion of ‘jacobian.Kokkos::Experimental::DynRankView<DataType, Properties>::dimension<int>(1)’ from ‘
std::enable_if<true, long unsigned int>::type {aka long unsigned int}’ to ‘long int’ inside { } [-Wnarrowing]
/home/mbetten/Trilinos/Trilinos/packages/intrepid2/refactor/src/Shared/Intrepid2_ArrayToolsDefTensor.hpp:793:99: warning: narrowing conversion of ‘output.Kokkos::Experimental::DynRankView<DataType, Properties>::dimension<int>(0)’ from ‘s
td::enable_if<true, long unsigned int>::type {aka long unsigned int}’ to ‘long int’ inside { } [-Wnarrowing]
...
/home/mbetten/Trilinos/Trilinos/packages/panzer/disc-fe/src/evaluators/Panzer_BasisValues_Evaluator_impl.hpp:106:3: warning: ‘void PHX::EvaluatorWithBaseImpl<Traits>::addDependentField(const PHX::MDField<SrcDataT, SrcTag0, SrcTag1, SrcTa
g2, SrcTag3, SrcTag4, SrcTag5, SrcTag6, SrcTag7>&) [with DataT = double; Tag0 = panzer::IP; Tag1 = panzer::Dim; Tag2 = void; Tag3 = void; Tag4 = void; Tag5 = void; Tag6 = void; Tag7 = void; Traits = panzer::Traits]’ is deprecated [-Wdepr
ecated-declarations]
/home/mbetten/Trilinos/Trilinos/packages/panzer/disc-fe/src/evaluators/Panzer_BasisValues_Evaluator_impl.hpp:106:3: warning: ‘void PHX::EvaluatorWithBaseImpl<Traits>::addDependentField(const PHX::MDField<SrcDataT, SrcTag0, SrcTag1, SrcTa
g2, SrcTag3, SrcTag4, SrcTag5, SrcTag6, SrcTag7>&) [with DataT = Sacado::Fad::DFad<double>; Tag0 = panzer::IP; Tag1 = panzer::Dim; Tag2 = void; Tag3 = void; Tag4 = void; Tag5 = void; Tag6 = void; Tag7 = void; Traits = panzer::Traits]’ is
deprecated [-Wdeprecated-declarations]
/home/mbetten/Trilinos/Trilinos/packages/panzer/disc-fe/src/evaluators/Panzer_BasisValues_Evaluator_impl.hpp:107:3: warning: ‘void PHX::EvaluatorWithBaseImpl<Traits>::addDependentField(const PHX::MDField<SrcDataT, SrcTag0, SrcTag1, SrcTa
g2, SrcTag3, SrcTag4, SrcTag5, SrcTag6, SrcTag7>&) [with DataT = double; Tag0 = panzer::Cell; Tag1 = panzer::IP; Tag2 = panzer::Dim; Tag3 = panzer::Dim; Tag4 = void; Tag5 = void; Tag6 = void; Tag7 = void; Traits = panzer::Traits]’ is dep
recated [-Wdeprecated-declarations]
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/401Epetra_IntSerialDense_test_MPI_1 Fails on POWER8 using GCC 5.3.0 (OpenMP/Seri...2016-07-20T14:50:44ZJames WillenbringEpetra_IntSerialDense_test_MPI_1 Fails on POWER8 using GCC 5.3.0 (OpenMP/Serial Backend Only, No CUDA)*Created by: nmhamster*
```
$ ctest -V -R Epetra_IntSerialDense_test_MPI_1
UpdateCTestConfiguration from :/home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/DartConfiguration.tcl
Parse Config file:/home/sdhammo/git/trilino...*Created by: nmhamster*
```
$ ctest -V -R Epetra_IntSerialDense_test_MPI_1
UpdateCTestConfiguration from :/home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/DartConfiguration.tcl
Parse Config file:/home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/DartConfiguration.tcl
Add coverage exclude regular expressions.
SetCTestConfiguration:CMakeCommand:/home/projects/pwr8-rhel72/cmake/3.4.3/bin/cmake
UpdateCTestConfiguration from :/home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/DartConfiguration.tcl
Parse Config file:/home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/DartConfiguration.tcl
Test project /home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 145
Start 145: Epetra_IntSerialDense_test_MPI_1
145: Test command: /home/projects/pwr8-rhel72/openmpi/1.10.2/gcc/5.3.0/cuda/8.0.21/bin/mpiexec "-np" "1" "/home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/packages/epetra/test/IntSerialDense/Epetra_IntSerialDense_test.exe" "-v"
145: Test timeout computed to be: 1500
145: Epetra in Trilinos 12.7 (Dev)
145:
145:
145: ==================================================================
145: Testing vector error-reporting.
145: Expect error messages if EPETRA_NO_ERROR_REPORTS is not defined.
145: ==================================================================
145: Checking Epetra_IntSerialDenseVector(-1)Checked OK.
145:
145: Checking Epetra_IntSerialDenseVector(Copy, int*, -3)Checked OK.
145:
145: Checking Epetra_IntSerialDenseVector(Copy, 0, 5)Checked OK.
145:
145: Checking Size(-2)
145: Checked OK.
145:
145: Checking Resize(-4)
145: Checked OK.
145: [white20:80587] *** Process received signal ***
145: [white20:80587] Signal: Segmentation fault (11)
145: [white20:80587] Signal code: Address not mapped (1)
145: [white20:80587] Failing at address: 0x40
145: [white20:80587] [ 0] [0x3fff814f0478]
145: [white20:80587] [ 1] /home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/packages/epetra/test/IntSerialDense/Epetra_IntSerialDense_test.exe(_Z16vectorExceptionsbb+0x764)[0x1006c604]
145: [white20:80587] [ 2] /home/sdhammo/git/trilinos-github-repo/build-power8-gcc-no-cuda/packages/epetra/test/IntSerialDense/Epetra_IntSerialDense_test.exe(main+0x94)[0x100674f4]
145: [white20:80587] [ 3] /lib64/power8/libc.so.6(+0x24580)[0x3fff80b74580]
145: [white20:80587] [ 4] /lib64/power8/libc.so.6(__libc_start_main+0xc4)[0x3fff80b74774]
145: [white20:80587] *** End of error message ***
145: --------------------------------------------------------------------------
145: mpiexec noticed that process rank 0 with PID 80587 on node white20 exited on signal 11 (Segmentation fault).
145: --------------------------------------------------------------------------
1/1 Test #145: Epetra_IntSerialDense_test_MPI_1 ...***Failed 1.06 sec
0% tests passed, 1 tests failed out of 1
Label Time Summary:
Epetra = 1.06 sec (1 test)
Total Test time (real) = 1.52 sec
The following tests FAILED:
145 - Epetra_IntSerialDense_test_MPI_1 (Failed)
Errors while running CTest
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/288Ifpack2: Build and test new threaded coloring Gauss-Seidel by default2017-01-06T20:29:55ZJames WillenbringIfpack2: Build and test new threaded coloring Gauss-Seidel by default*Created by: mhoemmen*
@trilinos/ifpack2 @kddevin @jdbooth
Right now, enabling Ifpack2's new threaded coloring Gauss-Seidel requires enabling "experimental" CMake options (both off by default) in both KokkosKernels and Ifpack2. It wo...*Created by: mhoemmen*
@trilinos/ifpack2 @kddevin @jdbooth
Right now, enabling Ifpack2's new threaded coloring Gauss-Seidel requires enabling "experimental" CMake options (both off by default) in both KokkosKernels and Ifpack2. It would make sense to build and make this new capability available by default, even if it is not the default Gauss-Seidel implementation.
Tpetra-FY17-Q2https://gitlab.osti.gov/jmwille/Trilinos/-/issues/745KLU2 in Amesos2 has a significant memory leak2016-11-02T16:28:38ZJames WillenbringKLU2 in Amesos2 has a significant memory leak*Created by: dridzal*
When using KLU2 in Amesos2 in sequential mode, i.e.,
-- allocate matrix;
-- perform symbolic factorization once;
-- update matrix values and rerun numeric factorization repeatedly;
there is a memory leak that...*Created by: dridzal*
When using KLU2 in Amesos2 in sequential mode, i.e.,
-- allocate matrix;
-- perform symbolic factorization once;
-- update matrix values and rerun numeric factorization repeatedly;
there is a memory leak that appears linear in size with respect to the number of numeric factorizations.
Discussed with @hkthorn , who is currently helping the @trilinos/amesos2 team sort out other issues. Heidi will take a look at it.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/17Panzer: undefined reference to `boost::system::system_category()'2017-07-28T07:43:38ZJames WillenbringPanzer: undefined reference to `boost::system::system_category()'*Created by: nschloe*
With
```
cmake \
-DTrilinos_ENABLE_Panzer:BOOL=ON \
-DTPL_ENABLE_MPI:BOOL=ON \
-DTrilinos_ENABLE_TESTS:BOOL=ON \
-DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=OFF \
-DSEACASExodus_ENABLE_MPI:BOOL=OFF \
...*Created by: nschloe*
With
```
cmake \
-DTrilinos_ENABLE_Panzer:BOOL=ON \
-DTPL_ENABLE_MPI:BOOL=ON \
-DTrilinos_ENABLE_TESTS:BOOL=ON \
-DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=OFF \
-DSEACASExodus_ENABLE_MPI:BOOL=OFF \
../../source-upstream/
```
I'm getting the linking error
```
../../src/libpanzer_stk.a(Panzer_STKConnManager.cpp.o): In function `_GLOBAL__sub_I_Panzer_STKConnManager.cpp':
Panzer_STKConnManager.cpp:(.text.startup+0x4b): undefined reference to `boost::system::generic_category()'
Panzer_STKConnManager.cpp:(.text.startup+0x57): undefined reference to `boost::system::generic_category()'
Panzer_STKConnManager.cpp:(.text.startup+0x63): undefined reference to `boost::system::system_category()'
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/11Zoltan: outdated-autotools-helper-file2015-11-30T19:33:34ZJames WillenbringZoltan: outdated-autotools-helper-file*Created by: nschloe*
Zoltan still ships autotools helper files with the sources, and they are quite old. Debian marks them as [`outdated`](https://lintian.debian.org/tags/outdated-autotools-helper-file.html):
```
trilinos source: outd...*Created by: nschloe*
Zoltan still ships autotools helper files with the sources, and they are quite old. Debian marks them as [`outdated`](https://lintian.debian.org/tags/outdated-autotools-helper-file.html):
```
trilinos source: outdated-autotools-helper-file packages/zoltan/config/config.guess 2012-01-01
trilinos source: outdated-autotools-helper-file packages/zoltan/config/config.sub 2012-01-01
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/13Teuchos: class std::auto_ptr' is deprecated2017-05-14T02:04:21ZJames WillenbringTeuchos: class std::auto_ptr' is deprecated*Created by: nschloe*
Since C++11, [auto_ptr is deprecated](http://www.cplusplus.com/reference/memory/auto_ptr/); Teuchos still uses it:
```
/«PKGBUILDDIR»/packages/teuchos/comm/src/Teuchos_CommHelpers.cpp:232:12: warning: 'template<cl...*Created by: nschloe*
Since C++11, [auto_ptr is deprecated](http://www.cplusplus.com/reference/memory/auto_ptr/); Teuchos still uses it:
```
/«PKGBUILDDIR»/packages/teuchos/comm/src/Teuchos_CommHelpers.cpp:232:12: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/27@ShyLU : Testing the github team features for issues. Dummy issue.2015-11-24T17:30:09ZJames Willenbring@ShyLU : Testing the github team features for issues. Dummy issue.*Created by: srajama1*
Dummy issue.
*Created by: srajama1*
Dummy issue.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/20FEI: no match for 'operator<< (GCC 5.2.1)2015-11-20T23:18:58ZJames WillenbringFEI: no match for 'operator<< (GCC 5.2.1)*Created by: nschloe*
When configuring Trilinos with
``` sh
cmake \
.. \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DCMAKE_BUILD_TYPE=None \
-DCMAKE_C_COMPILER=mpicc \
-DCMAKE_CXX_COMPILER=mpicxx \
-DCMA...*Created by: nschloe*
When configuring Trilinos with
``` sh
cmake \
.. \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DCMAKE_BUILD_TYPE=None \
-DCMAKE_C_COMPILER=mpicc \
-DCMAKE_CXX_COMPILER=mpicxx \
-DCMAKE_Fortran_COMPILER=mpif90 \
-DBUILD_SHARED_LIBS:BOOL=ON \
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DTrilinos_LIBRARY_NAME_PREFIX:STRING=trilinos_ \
-DTrilinos_INSTALL_INCLUDE_DIR:PATH=include/trilinos/ \
-DTrilinos_USE_GNUINSTALLDIRS:BOOL=ON \
-DTrilinos_ENABLE_DEVELOPMENT_MODE:BOOL=OFF \
-DTrilinos_ENABLE_ALL_PACKAGES:BOOL=ON \
-DTrilinos_ENABLE_SECONDARY_TESTED_CODE:BOOL=ON \
-DTrilinos_ASSERT_MISSING_PACKAGES:BOOL=OFF \
-DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \
-DTrilinos_ENABLE_Didasko:BOOL=OFF \
-DTrilinos_ENABLE_Gtest:BOOL=OFF \
-DTrilinos_ENABLE_CTrilinos:BOOL=OFF \
-DTrilinos_ENABLE_ForTrilinos:BOOL=OFF \
-DTrilinos_ENABLE_Mesquite:BOOL=OFF \
-DTrilinos_ENABLE_MOOCHO:BOOL=OFF \
-DTrilinos_ENABLE_Optika:BOOL=OFF \
-DTrilinos_ENABLE_Phdmesh:BOOL=OFF \
-DTrilinos_ENABLE_PyTrilinos:BOOL=OFF \
-DTrilinos_ENABLE_Sundance:BOOL=OFF \
-DTrilinos_ENABLE_STKClassic:BOOL=OFF \
-DTrilinos_ENABLE_STKDoc_tests:BOOL=OFF \
-DTrilinos_ENABLE_STKSearch:BOOL=OFF \
-DTrilinos_ENABLE_STKUnit_tests:BOOL=OFF \
-DTrilinos_ENABLE_ThreadPool:BOOL=OFF \
-DTrilinos_ENABLE_EXAMPLES:BOOL=OFF \
-DTrilinos_ENABLE_TESTS:BOOL=OFF \
-DSEACAS_ENABLE_NETCDF4_SUPPORT:BOOL=ON \
-DSEACASExodus_ENABLE_MPI:BOOL=OFF \
-DTPL_ENABLE_BinUtils:BOOL=ON \
-DTPL_ENABLE_Boost:BOOL=ON \
-DTPL_ENABLE_HDF5:BOOL=OFF \
-DTPL_ENABLE_Matio:BOOL=OFF \
-DTPL_ENABLE_MATLAB:BOOL=OFF \
-DTPL_ENABLE_MPI:BOOL=ON \
-DTPL_ENABLE_MUMPS:BOOL=ON \
-DTPL_ENABLE_ParMETIS:BOOL=OFF \
-DTPL_ENABLE_Scotch:BOOL=ON \
-DTPL_Scotch_INCLUDE_DIRS:PATH=/usr/include/scotch/ \
-DTPL_ENABLE_SuperLU:BOOL=ON \
-DSuperLU_INCLUDE_DIRS:PATH=/usr/include/superlu/ \
-DTPL_ENABLE_TBB:BOOL=ON \
-DTPL_ENABLE_X11:BOOL=OFF \
-DTPL_ENABLE_Zlib:BOOL=ON
```
(can perhaps be stripped down) and when using GCC 5.2.1, one gets the compile error
```
[...]
/«PKGBUILDDIR»/packages/fei/test_utils/snl_fei_tester.cpp:526:65: error: no match for 'operator<<' (operand types are 'std::basic_ostream<char>' and 'std::ostringstream {aka std::__cxx11::basic_ostringstream<char>}')
fei::console_out() << "ERROR opening solution output file " << fileName << FEI_ENDL;
^
/«PKGBUILDDIR»/packages/fei/test_utils/snl_fei_tester.cpp:526:65: note: candidate: operator<<(int, int) <built-in>
/«PKGBUILDDIR»/packages/fei/test_utils/snl_fei_tester.c
```
The full log is [here](https://launchpadlibrarian.net/214282732/buildlog_ubuntu-wily-amd64.trilinos_12.3~201508121416-wily1_BUILDING.txt.gz).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/25Kokkos, Panzer, STK, Teuchos, Thyra, Tpetra: Some files overridden on install2017-10-26T19:24:16ZJames WillenbringKokkos, Panzer, STK, Teuchos, Thyra, Tpetra: Some files overridden on install*Created by: nschloe*
On a "full" Trilinos configuration
```
cmake \
-DTrilinos_LIBRARY_NAME_PREFIX:STRING="trilinos_" \
-DCMAKE_INSTALL_PREFIX:PATH=/opt/trilinos/full/ \
-DCMAKE_BUILD_TYPE:STRING=Debug \
-DCMAKE_SKIP_RPATH:BOO...*Created by: nschloe*
On a "full" Trilinos configuration
```
cmake \
-DTrilinos_LIBRARY_NAME_PREFIX:STRING="trilinos_" \
-DCMAKE_INSTALL_PREFIX:PATH=/opt/trilinos/full/ \
-DCMAKE_BUILD_TYPE:STRING=Debug \
-DCMAKE_SKIP_RPATH:BOOL=ON \
-DBUILD_SHARED_LIBS:BOOL=ON \
-DTrilinos_INSTALL_INCLUDE_DIR:PATH=include/trilinos/ \
-DTrilinos_USE_GNUINSTALLDIRS:BOOL=ON \
-DTrilinos_ENABLE_ALL_PACKAGES:BOOL=ON \
-DTrilinos_ENABLE_SECONDARY_STABLE_CODE:BOOL=ON \
-DTrilinos_ENABLE_PyTrilinos:BOOL=OFF \
-DSEACASExodus_ENABLE_MPI:BOOL=OFF \
-DTPL_ENABLE_BinUtils:BOOL=ON \
-DTPL_ENABLE_Boost:BOOL=ON \
-DTPL_ENABLE_HDF5:BOOL=OFF \
-DTPL_ENABLE_Matio:BOOL=OFF \
-DTPL_ENABLE_MATLAB:BOOL=OFF \
-DTPL_ENABLE_MPI:BOOL=ON \
-DTPL_ENABLE_MUMPS:BOOL=ON \
-DTPL_ENABLE_ParMETIS:BOOL=OFF \
-DTPL_ENABLE_Scotch:BOOL=ON \
-DTPL_Scotch_INCLUDE_DIRS:PATH=/usr/include/scotch/ \
-DTPL_ENABLE_TBB:BOOL=ON \
-DTPL_ENABLE_X11:BOOL=OFF \
-DTPL_ENABLE_Zlib:BOOL=ON \
../../source-upstream/
```
there a many files which are installed "twice", i.e., `make install` creates more than one file with the same name in the same location, effectively overriding everything that wasn't installed last. This may lead to serious bugs. For the above configuration, one gets
```
$ sort install_manifest.txt | uniq --count --repeated
2 /opt/trilinos/full/include/trilinos/KokkosCompat_ClassicNodeAPI_Wrapper.hpp
2 /opt/trilinos/full/include/trilinos/KokkosCompat_TMM.hpp
2 /opt/trilinos/full/include/trilinos/KokkosCompat_View_def.hpp
2 /opt/trilinos/full/include/trilinos/KokkosCompat_View.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_AdaptiveSaMLParameterListInterpreter.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_config.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_FactoryFactory.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_MLParameterListInterpreter.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_ParameterListInterpreter.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_RefMaxwell.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_ShiftedLaplacian.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_ShiftedLaplacianOperator.hpp
2 /opt/trilinos/full/include/trilinos/MueLu_TpetraOperator.hpp
2 /opt/trilinos/full/include/trilinos/Panzer_config.hpp
3 /opt/trilinos/full/include/trilinos/STKClassic_config.h
2 /opt/trilinos/full/include/trilinos/stk_io/IossBridge.hpp
2 /opt/trilinos/full/include/trilinos/stk_io/util/Gears.hpp
2 /opt/trilinos/full/include/trilinos/stk_io/util/Gmesh_STKmesh_Fixture.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Bucket.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/BulkData.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/BulkModification.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Comm.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/DataTraitsClass.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/DataTraitsEnum.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/DataTraits.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Entity.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/EntityKey.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/FieldBase.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Field.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/FieldParallel.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/FieldRelation.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/FieldRestriction.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/FieldState.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/FieldTraits.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/FindRestriction.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/GetBuckets.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/GetEntities.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Ghosting.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/baseImpl/BucketRepository.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/baseImpl/EntityRepository.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/baseImpl/FieldBaseImpl.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/baseImpl/FieldRepository.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/baseImpl/PartImpl.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/baseImpl/PartRepository.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Iterators.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/MemoryUsage.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/MetaData.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Part.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/PropertyBase.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Property.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Relation.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Selector.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/SetOwners.hpp
2 /opt/trilinos/full/include/trilinos/stk_mesh/base/Types.hpp
2 /opt/trilinos/full/include/trilinos/stk_search/BoundingBox.hpp
2 /opt/trilinos/full/include/trilinos/stk_search/CoarseSearch.hpp
2 /opt/trilinos/full/include/trilinos/stk_search/IdentProc.hpp
2 /opt/trilinos/full/include/trilinos/stk_search/OctTree.hpp
2 /opt/trilinos/full/include/trilinos/stk_search/OctTreeOps.hpp
2 /opt/trilinos/full/include/trilinos/stk_search/SearchTypes.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/Mapv.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/Option.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/Platform.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/PrintTable.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/PrintTimer.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/SlibDiagWriter.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/String.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/StringUtil.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/Timer.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/TimerMetricTraits.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/WriterExt.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/WriterOStream.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/WriterParser.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/diag/WriterRegistry.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/CPUTime.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/FormatMemorySize.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/FormatTime.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/LogControl.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/OutputLog.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/ProgramOptions.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/ReportHandler.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/RuntimeDoomed.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/RuntimeMessage.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/RuntimeWarning.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/environment/WallTime.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/BroadcastArg.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/DistributedIndex.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/MPI.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/ParallelComm.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/Parallel.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/ParallelIndex.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/ParallelInputStream.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/parallel/ParallelReduce.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/stk_config.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/Array.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/Bootstrap.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/Callback.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/ci_string.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/ci_traits.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/config_google.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/CSet.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/densehashtable.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/FeatureTest.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/Foreach.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/Fortran.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/hashtable-common.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/IndentStreambuf.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/IndexList.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/libc_allocator_with_realloc.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/MallocUsed.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/Marshal.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/NamedPair.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/nested_iterator.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/nested_range.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/Null_Streambuf.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/PairIter.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/Pool.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/RadixSort.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/random_access_iterator_wrapper.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/Range.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/SameType.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/SimpleArrayOps.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/sparseconfig.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/sparsehashtable.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/StaticAssert.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/string_case_compare.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/TeeStreambuf.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/tokenize.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/TypeList.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/TypeListMap.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/type_traits_google.h
2 /opt/trilinos/full/include/trilinos/stk_util/util/TypeUtil.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/VecMap.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/VecSet.hpp
2 /opt/trilinos/full/include/trilinos/stk_util/util/vectorization.hpp
2 /opt/trilinos/full/include/trilinos/TeuchosKokkosCompat_config.h
2 /opt/trilinos/full/include/trilinos/Thyra_MueLuPreconditionerFactory.hpp
2 /opt/trilinos/full/include/trilinos/Thyra_XpetraLinearOp.hpp
2 /opt/trilinos/full/include/trilinos/Tpetra_CrsMatrixSolveOp.hpp
```
Tpetra-backloghttps://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/28@trilinos/shylu : One more dummy issue for testing. Sorry for the spam.2015-11-24T18:49:04ZJames Willenbring@trilinos/shylu : One more dummy issue for testing. Sorry for the spam.*Created by: srajama1*
Dummy issue.
*Created by: srajama1*
Dummy issue.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/29Kokkos test2016-03-06T13:29:03ZJames WillenbringKokkos test*Created by: kyungjoo-kim*
Kokkos testing in Trilinos does not work. It looks like the cmake does not properly include src directory in Kokkos. The configuration that I use is okay with the old Sandia repo.
Kyungjoo
```
cd ...*Created by: kyungjoo-kim*
Kokkos testing in Trilinos does not work. It looks like the cmake does not properly include src directory in Kokkos. The configuration that I use is okay with the old Sandia repo.
Kyungjoo
```
cd
/nfshome/kyukim/Work/lib/trilinos/build/shylu/compton/intel-test/packages/kokkos/example/query_device
&& /home/software/intel/ics_install/impi/4.1.1.036/intel64/bin/mpiicpc
-O3 -g -mavx -opt-report=5 -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3
-DNDEBUG
-I/nfshome/kyukim/Work/lib/trilinos/build/shylu/compton/intel-test
-I/nfshome/kyukim/Work/lib/trilinos/build/shylu/compton/intel-test/packages/kokkos/example/query_device
-I/nfshome/kyukim/Work/lib/trilinos/trunk/packages/kokkos/example/query_device
-o CMakeFiles/KokkosExample_query_device.dir/query_device.cpp.o -c
/nfshome/kyukim/Work/lib/trilinos/trunk/packages/kokkos/example/query_device/query_device.cpp
icpc: remark #10397: optimization reports are generated in *.optrpt
files in the output location
/nfshome/kyukim/Work/lib/trilinos/trunk/packages/kokkos/example/query_device/query_device.cpp(47):
catastrophic error: cannot open source file "Kokkos_Macros.hpp"
#include <Kokkos_Macros.hpp>
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/32Tpetra: Overload CrsMatrix::sumIntoLocalValues to take Kokkos::View instead o...2015-11-29T06:39:19ZJames WillenbringTpetra: Overload CrsMatrix::sumIntoLocalValues to take Kokkos::View instead of Teuchos::ArrayView *Created by: mhoemmen*
@trilinos/tpetra
Add an overload of `Tpetra::CrsMatrix::sumIntoLocalValues` to take the input arrays as unmanaged `Kokkos::View`, instead of as Teuchos::ArrayView.
*Created by: mhoemmen*
@trilinos/tpetra
Add an overload of `Tpetra::CrsMatrix::sumIntoLocalValues` to take the input arrays as unmanaged `Kokkos::View`, instead of as Teuchos::ArrayView.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/34Xpetra: many tests fail when Epetra, Tpetra, and OpenMP enabled2016-01-18T21:53:14ZJames WillenbringXpetra: many tests fail when Epetra, Tpetra, and OpenMP enabled*Created by: mhoemmen*
@trilinos/xpetra
When Epetra is enabled, Xpetra uses `Kokkos::Compat::KokkosSerialWrapperNode` as its Node type. (This corresponds to the `Kokkos::Serial` execution space.) There would be nothing particularly ...*Created by: mhoemmen*
@trilinos/xpetra
When Epetra is enabled, Xpetra uses `Kokkos::Compat::KokkosSerialWrapperNode` as its Node type. (This corresponds to the `Kokkos::Serial` execution space.) There would be nothing particularly wrong with that, except that if Tpetra is also enabled, Xpetra then tries to instantiate Tpetra for that Node type. This is a problem because Tpetra does not necessarily enable that Node type. For example, if OpenMP is enabled (`Trilinos_ENABLE_OpenMP=ON`), Tpetra only enables the OpenMP Node type (`Kokkos::Compat::KokkosOpenMPWrapperNode`) by default.
My recent commit fixed the MPI_DEBUG build due to the above issue:
https://github.com/trilinos/Trilinos/commit/64c7185b0b60411f65757ad3abc1c333470bdf83
but it does NOT fix several failing tests. My guess is that the test failures are related.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/37Belos::MultiVecTraits for Tpetra: Avoid using REDUCE_SUM in MvTransMv2015-12-01T15:45:27ZJames WillenbringBelos::MultiVecTraits for Tpetra: Avoid using REDUCE_SUM in MvTransMv*Created by: mhoemmen*
@trilinos/belos
@amklinv
The Tpetra specialization of Belos::MultiVecTraits::MvTransMv uses Teuchos::REDUCE_SUM. This is the only MultiVecTraits method implementation for Tpetra that uses this enum. Either PE...*Created by: mhoemmen*
@trilinos/belos
@amklinv
The Tpetra specialization of Belos::MultiVecTraits::MvTransMv uses Teuchos::REDUCE_SUM. This is the only MultiVecTraits method implementation for Tpetra that uses this enum. Either PETSc or Hypre appears to define a REDUCE_SUM macro, which causes build errors when colliding with this enum. While this is really an issue with PETSc or Hypre not namespacing their macros, we should be able to deal with this in Belos, and simplify the code at the same time.
1. Keep the branch of the code for the single vector case (Tpetra::MultiVector::multiply might not optimize for that case)
2. Otherwise, call Tpetra::MultiVector::multiply. View the input SerialDenseMatrix as a MultiVector and use a replicated Map.
Here is how you create the MultiVector to view the SerialDenseMatrix.
1. Create an empty Kokkos::DualView. Get device_type from Tpetra::MultiVector.
2. Create an HostSpace Kokkos::View (FIXME: Figure out how to specify at run time that the View is unmanaged, comparable to Teuchos::rcpFromRef -- I think you can just invoke the constructor that takes a raw pointer and dimensions, and everything will be ok).
3. Set the DualView's h_view field to the new View that you created in Step 2.
4. Mark the DualView as modified on host (actually you don't have to, because of UVM).
5. Give the DualView to Tpetra::MultiVector's constructor, along with a globally replicated Map.
In the source code of Tpetra::MultiVector::multiply, this is Case 2 (where C is "local," i.e., globally replicated over the same communicator as the input MultiVectors). Belos does something weird: namely, it calls multiply on a MultiVector with a "SerialComm." Thus, the multiply() method doesn't actually get to do the communication that it knows how to do (it calls "reduce()" internally). Just let MultiVector::multiply do what it knows how to do, by letting C have a globally replicated Map with the same communicator as A and B.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/36Tpetra: Consolidate neighbor discovery (globalAssemble vs. Distributor)2016-11-02T20:56:45ZJames WillenbringTpetra: Consolidate neighbor discovery (globalAssemble vs. Distributor)*Created by: mhoemmen*
@trilinos/tpetra
Tpetra::Crs{Graph, Matrix}::globalAssemble have a redundant and suboptimal implementation of (MPI) neighbor discovery. Consolidate with Tpetra::Distributor.
*Created by: mhoemmen*
@trilinos/tpetra
Tpetra::Crs{Graph, Matrix}::globalAssemble have a redundant and suboptimal implementation of (MPI) neighbor discovery. Consolidate with Tpetra::Distributor.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/35Tpetra::CrsMatrix::globalAssemble: Purge unnecessary barriers2016-11-02T20:56:55ZJames WillenbringTpetra::CrsMatrix::globalAssemble: Purge unnecessary barriers*Created by: mhoemmen*
@trilinos/tpetra
There are two unnecessary barriers after waitAll in Tpetra::CrsMatrix::globalAssemble. It should be possible to purge these barriers, for the following reasons:
1. The reduceAll at the start of...*Created by: mhoemmen*
@trilinos/tpetra
There are two unnecessary barriers after waitAll in Tpetra::CrsMatrix::globalAssemble. It should be possible to purge these barriers, for the following reasons:
1. The reduceAll at the start of the method precludes reëntrant calls that would mix up message tags.
2. If we want to be cautious about tags, we may take Distributor's approach, and specify distinct tags for each of the two rounds of point-to-point communication.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/39Tpetra: Replace sync/modify with 'use'2017-09-06T23:05:12ZJames WillenbringTpetra: Replace sync/modify with 'use'*Created by: mhoemmen*
@trilinos/tpetra @crtrott
Tpetra::MultiVector currently implements "dual view" semantics through the sync / modify methods. Each takes a space as a template parameter. `X.sync<Space>()` ensures that X's data a...*Created by: mhoemmen*
@trilinos/tpetra @crtrott
Tpetra::MultiVector currently implements "dual view" semantics through the sync / modify methods. Each takes a space as a template parameter. `X.sync<Space>()` ensures that X's data are up-to-date in space `Space`, and `X.modify<Space>()` marks X's data as modified in that space.
We would like to change this syntax as follows:
```
X.use (Space1, Space2, ..., SpaceN, ReadAndOrWrite);
```
where `Space1`, ..., `SpaceN` are instances of memory spaces (execution space?), and `ReadAndOrWrite` is an enum that takes one of the following values: `ReadOnly`, `WriteOnly`, or `ReadWrite`. This is a declarative syntax, vs. the imperative syntax that sync and modify implement. It is only a syntax change; the underlying implementation and semantic possibilities would not change.
The typical use case is to "use" a Tpetra object in one space at a time. For example:
```
X.use (Cuda (), WriteOnly);
fillOnCudaDevice (X); // write-only device code
X.use (Host (), ReadOnly);
hostOnlyLegacyCode (X); // read-only access on host
X.use (Cuda (), ReadWrite);
modifyOnCudaDevice (X);
```
The above semantics using the sync / modify syntax look like this:
```
fillOnCudaDevice (X); // don't sync first
X.sync<Host> ();
hostOnlyLegacyCode (X); // read-only; don't call modify first
X.sync<Cuda> ();
X.modify<Cuda> ();
modifyOnCudaDevice (X);
```
Calling `use` with multiple memory spaces effectively syncs to all of them. This allows (read-only) access to the data in concurrent kernels running from the different spaces.
Furthermore, we would like Tpetra objects' constructors to take optional (memory?) space arguments, to control where Tpetra initially allocates memory. Allocation in at least certain memory spaces would be lazy -- that is, Tpetra would only allocate if using in those memory spaces. For example (hypothetical), we might not like to allocate in HBM memory initially:
```
Tpetra::Vector<...> X (map, Capacity ()); // don't allocate in HBM initially
```
Tpetra-backloghttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/38Anasazi::MultiVecTraits for Tpetra: Avoid using REDUCE_SUM in MvTransMv2015-12-01T15:45:27ZJames WillenbringAnasazi::MultiVecTraits for Tpetra: Avoid using REDUCE_SUM in MvTransMv*Created by: mhoemmen*
@trilinos/anasazi
This is the Anasazi version of Issue #37.
*Created by: mhoemmen*
@trilinos/anasazi
This is the Anasazi version of Issue #37.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/41Tpetra::CrsMatrix::getLocalDiagCopy: Kokkos-parallelize diagonal extraction2016-05-18T04:53:27ZJames WillenbringTpetra::CrsMatrix::getLocalDiagCopy: Kokkos-parallelize diagonal extraction*Created by: mhoemmen*
@trilinos/tpetra Performance tests with Nalu discovered that Ifpack2::Relaxation Jacobi setup had a sequential section in CrsMatrix::getLocalDiagCopy (the two-argument version, though it's easy enough to optimize ...*Created by: mhoemmen*
@trilinos/tpetra Performance tests with Nalu discovered that Ifpack2::Relaxation Jacobi setup had a sequential section in CrsMatrix::getLocalDiagCopy (the two-argument version, though it's easy enough to optimize the one-argument version too). Nalu developers experimented with putting a parallel_for loop around diagonal extraction in getLocalDiagCopy, and it worked great.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/42some releases untagged2015-12-03T21:36:46ZJames Willenbringsome releases untagged*Created by: nschloe*
On https://github.com/trilinos/Trilinos/releases, we have a good overview of the tags. The current release 12.4.2 and also 12.4.0 are missing. There may be more.
*Created by: nschloe*
On https://github.com/trilinos/Trilinos/releases, we have a good overview of the tags. The current release 12.4.2 and also 12.4.0 are missing. There may be more.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/44MueLu: Epetra examples won't build unless Tpetra_INST_SERIAL=ON2016-05-18T19:44:36ZJames WillenbringMueLu: Epetra examples won't build unless Tpetra_INST_SERIAL=ON*Created by: mhoemmen*
@trilinos/muelu
When I enable TpetraCore and all forward dependencies (including secondary stable packages), and turn on OpenMP, the build fails in MueLu with link errors, due to "missing" Tpetra Serial instanti...*Created by: mhoemmen*
@trilinos/muelu
When I enable TpetraCore and all forward dependencies (including secondary stable packages), and turn on OpenMP, the build fails in MueLu with link errors, due to "missing" Tpetra Serial instantiations.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/47Tpetra: (numProcs == 1 && nonlocals_.size() > 0) with incorrect base2015-12-07T20:03:08ZJames WillenbringTpetra: (numProcs == 1 && nonlocals_.size() > 0) with incorrect base*Created by: nschloe*
The following code
``` c++
#include <Teuchos_DefaultComm.hpp>
#include <Tpetra_CrsMatrix.hpp>
int main ( int argc, char *argv[] )
{
Teuchos::GlobalMPISession session(&argc, &argv, NULL);
auto comm = Teuchos:...*Created by: nschloe*
The following code
``` c++
#include <Teuchos_DefaultComm.hpp>
#include <Tpetra_CrsMatrix.hpp>
int main ( int argc, char *argv[] )
{
Teuchos::GlobalMPISession session(&argc, &argv, NULL);
auto comm = Teuchos::DefaultComm<int>::getComm();
const int numGlobal = 8;
auto map = Teuchos::rcp(new Tpetra::Map<int>(numGlobal, 0, comm));
std::vector<Teuchos::Tuple<int,4>> tuples =
{
Teuchos::tuple(2, 3, 4, 5),
Teuchos::tuple(4, 5, 6, 7),
Teuchos::tuple(2, 3, 6, 7),
Teuchos::tuple(2, 3, 8, 9),
Teuchos::tuple(4, 5, 8, 9)
};
// build graph
auto graph = Teuchos::rcp(new Tpetra::CrsGraph<int, int>(map, map, 0));
for (size_t k = 0; k < tuples.size(); k++) {
for (int i = 0; i < 4; i++) {
graph->insertGlobalIndices(tuples[k][i], tuples[k]);
}
}
graph->fillComplete();
// fill matrix
auto A = Teuchos::rcp(new Tpetra::CrsMatrix<double,int,int>(graph));
A->setAllToScalar(0.0);
auto vals = Teuchos::tuple(1.0, 1.1, 1.2, 1.3);
for (size_t k = 0; k < tuples.size(); k++) {
for (int i = 0; i < 4; i++) {
A->sumIntoGlobalValues(tuples[k][i], tuples[k], vals);
}
}
A->fillComplete();
return EXIT_SUCCESS;
}
```
errors out at the very last `fillComplete` with
```
terminate called after throwing an instance of 'std::runtime_error'
what(): /build/trilinos-xMfrMq/trilinos-12.5~20151207030212/packages/tpetra/core/src/Tpetra_CrsMatrix_def.hpp:3596:
Throw number = 2
Throw test that evaluated to true: (numProcs == 1 && nonlocals_.size() > 0)
Tpetra::CrsMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace>, false>::fillComplete: cannot have nonlocal entries on a serial run. An invalid entry (i.e., with row index not in the row Map) must have been submitted to the CrsMatrix.
```
A fix is to manually go through the `tuples` list, find out the lowest entry, and put that into `Tpetra::Map` instead of `0`. Perhaps this value is something that Tpetra can fill in for me.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/46Tpetra: offsetView of offsetView buggy2016-10-05T15:39:28ZJames WillenbringTpetra: offsetView of offsetView buggy*Created by: jthies*
@trilinos/tpetra
*Created by: jthies*
@trilinos/tpetra
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/50Tpetra::BlockCrsMatrix: Add LU factorization, solve, & inverse for small dens...2016-01-19T22:44:44ZJames WillenbringTpetra::BlockCrsMatrix: Add LU factorization, solve, & inverse for small dense blocks*Created by: mhoemmen*
@trilinos/tpetra
Add GETRF (LU factorization), GETRS (solve linear system(s) using results of GETRF), and GETRI (compute explicit matrix inverse, using results of GETRF) for LittleBlock in BlockCrsMatrix.
GETRI ...*Created by: mhoemmen*
@trilinos/tpetra
Add GETRF (LU factorization), GETRS (solve linear system(s) using results of GETRF), and GETRI (compute explicit matrix inverse, using results of GETRF) for LittleBlock in BlockCrsMatrix.
GETRI will help accelerate block Jacobi (a.k.a. point implicit), by pushing solve costs to setup and making computation during the actual apply step just little dense matrix-vector multiplies. This should be easier to vectorize.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/51Tpetra::BlockCrsMatrix: Use Kokkos::View<Scalar***> for the "diagonal graph"2016-01-30T10:49:49ZJames WillenbringTpetra::BlockCrsMatrix: Use Kokkos::View<Scalar***> for the "diagonal graph"*Created by: mhoemmen*
@trilinos/tpetra
It would be a lot more efficient to use `Kokkos::View<Scalar***>` for the "diagonal graph," than to use BlockCrsMatrix. We don't need any of that generality; we just need to take a subview of ea...*Created by: mhoemmen*
@trilinos/tpetra
It would be a lot more efficient to use `Kokkos::View<Scalar***>` for the "diagonal graph," than to use BlockCrsMatrix. We don't need any of that generality; we just need to take a subview of each block and apply its inverse. Also, don't store the diagonal graph in BlockCrsMatrix itself; store it in the preconditioner.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/53Thyra -Werror build broken2015-12-14T16:19:56ZJames WillenbringThyra -Werror build broken*Created by: bartlettroscoe*
@mhoemmen, I believe your commit:
```
89a3771 "Thyra::TpetraVectorSpace: Get rid of unnecessary private fields."
Author: Mark Hoemmen <mhoemme@sandia.gov>
Date: Sat Dec 5 22:43:22 2015 -0700 (5 days ago)
...*Created by: bartlettroscoe*
@mhoemmen, I believe your commit:
```
89a3771 "Thyra::TpetraVectorSpace: Get rid of unnecessary private fields."
Author: Mark Hoemmen <mhoemme@sandia.gov>
Date: Sat Dec 5 22:43:22 2015 -0700 (5 days ago)
M packages/thyra/adapters/tpetra/src/Thyra_TpetraVectorSpace_decl.hpp
M packages/thyra/adapters/tpetra/src/Thyra_TpetraVectorSpace_def.hpp
```
caused these -Werror build errors shown in the below email. Can you please fix this?
Are you on the thyra-regression mail list?
-Ross
> -----Original Message-----
> From: thyra-regression-bounces@software.sandia.gov [mailto:thyra-
> regression-bounces@software.sandia.gov] On Behalf Of CDash
> Sent: Friday, December 11, 2015 12:11 AM
> To: thyra-regression@software.sandia.gov
> Subject: [Thyra-Regression] FAILED (b=4): Trilinos/Thyra - Linux-GCC-4.7.2-
> MPI_DEBUG_Werror_DEV - Nightly
>
> A submission to CDash for the project Trilinos has build errors.
> You have been identified as one of the authors who have checked in changes
> that are part of this submission or you are listed in the default contact list.
>
> Details on the submission can be found at
> http://testing.sandia.gov/cdash/buildSummary.php?buildid=2264582
>
> Project: Trilinos
> SubProject: Thyra
> Site: muir.sandia.gov
> Build Name: Linux-GCC-4.7.2-MPI_DEBUG_Werror_DEV
> Build Time: 2015-12-10T22:05:57 MST
> Type: Nightly
> Errors: 4
>
> _Error_
> packages/thyra/adapters/tpetra/test/TpetraThyraWrappers_UnitTests.cpp
> (http://testing.sandia.gov/cdash/viewBuildError.php?type=0&buildid=22645
> 82)
> In file included from /nightly/hudson/slave/workspace/trilinos-nightly-
> muir/MPI_DEBUG_Werror_DEV/Trilinos/pacg++: error:
> CMakeFiles/ThyraTpetraAdapters_Simple2DTpetraModelEvaluatorUnitTests.
> dir/Simple2DTpetraModelEvaluator_UnitTests.cpp.o: No such file or
> directory
> packages/thyra/adapters/tpetra/test/Simple2DTpetraModelEvaluator_UnitT
> ests.cpp
> (http://testing.sandia.gov/cdash/viewBuildError.php?type=0&buildid=22645
> 82)
> In file included from /nightly/hudson/slave/workspace/trilinos-nightly-
> muir/MPI_DEBUG_Werror_DEV/Trig++: error:
> CMakeFiles/ThyraTpetraAdapters_TpetraThyraWrappersUnitTests.dir/Tpetr
> aThyraWrappers_UnitTests.cpp.o: No such file or directory
>
> -CDash on testing.sandia.gov
> ---
>
> Thyra-Regression mailing list
> Thyra-Regression@software.sandia.gov
> https://software.sandia.gov/mailman/listinfo/thyra-regression
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/54Tpetra,Ifpack2: Add GEMM for small dense blocks2015-12-18T17:39:26ZJames WillenbringTpetra,Ifpack2: Add GEMM for small dense blocks*Created by: mhoemmen*
@trilinos/tpetra @amklinv @jhux2 @csiefer2
Ifpack2's incomplete LU factorization wants a matrix-matrix multiply (GEMM, in BLAS terms) for small dense matrices (the "blocks" in Tpetra's BlockCrsMatrix). The exis...*Created by: mhoemmen*
@trilinos/tpetra @amklinv @jhux2 @csiefer2
Ifpack2's incomplete LU factorization wants a matrix-matrix multiply (GEMM, in BLAS terms) for small dense matrices (the "blocks" in Tpetra's BlockCrsMatrix). The existing implementation (at the top of Ifpack2_Experimental_RBILUK_decl.hpp) assumes a particular layout of blocks.
This is like Issue #50, in that the eventual goal is to make all of these computational kernels available in KokkosKernels. We're starting by putting the kernels in the Tpetra::Experimental namespace.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/63Tpetra::Distributor: Inheriting from VerboseObject<Distributor> causes crash ...2015-12-24T23:20:42ZJames WillenbringTpetra::Distributor: Inheriting from VerboseObject<Distributor> causes crash in Import ctor w/ various Intel compiler versions*Created by: mhoemmen*
@trilinos/tpetra @amklinv
With Intel 15.0.4 and Intel 16, using either Intel MPI or OpenMPI 1.8, the Tpetra::Import constructor crashes. Micah chased this down and found out that the Tpetra::Distributor instanc...*Created by: mhoemmen*
@trilinos/tpetra @amklinv
With Intel 15.0.4 and Intel 16, using either Intel MPI or OpenMPI 1.8, the Tpetra::Import constructor crashes. Micah chased this down and found out that the Tpetra::Distributor instance that Import creates inherits from Teuchos::VerboseObjectTpetra::Distributor (looks weird, I know, but this is how one is supposed to use VerboseObject), and that VerboseObject's constructor was getting into a weird multiply segfaulting infinite loop when calling initializeVerboseObjectBase().
Some versions of the Intel compiler have trouble with name resolution in certain cases. On a hunch, I made Distributor no longer inherit from VerboseObject, and that fixed the problem. Yay!
Thus, the fix is to remove Distributor's inheritance from VerboseObject. This was pretty easy to do but I want to make sure that Distributor's ParameterList still accepts a "VerboseObject" sublist (see e.g., line 430 of Tpetra_Distributor.cpp).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/60build failure: multiple definition of `void Xpetra::Jacobi2015-12-18T20:54:06ZJames Willenbringbuild failure: multiple definition of `void Xpetra::Jacobi*Created by: nschloe*
The current master fails to build with
```
[...]
Wl,-Bdynamic ../../kokkos/algorithms/src/libtrilinos_kokkosalgorithms.so.12.5 ../../kokkos/core/src/libtrilinos_kokkoscore.so.12.5
CMakeFiles/trilinos_stokhos_muel...*Created by: nschloe*
The current master fails to build with
```
[...]
Wl,-Bdynamic ../../kokkos/algorithms/src/libtrilinos_kokkosalgorithms.so.12.5 ../../kokkos/core/src/libtrilinos_kokkoscore.so.12.5
CMakeFiles/trilinos_stokhos_muelu.dir/sacado/kokkos/pce/muelu/MueLu_SaPFactory_UQ_PCE_Serial.cpp.o: In function `Xpetra::TpetraCrsGraph<int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >::getMap() const':
/«PKGBUILDDIR»/packages/stokhos/src/sacado/kokkos/pce/Sacado_UQ_PCE.hpp:145: multiple definition of `void Xpetra::Jacobi<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >(double, Xpetra::Vector<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > const&, Xpetra::Matrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > const&, Xpetra::Matrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > const&, Xpetra::Matrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >&, bool, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
```
Full details (including configuration) [at Launchpad](https://launchpadlibrarian.net/230424356/buildlog_ubuntu-xenial-amd64.trilinos_12.5~20151218030407-xenial1_BUILDING.txt.gz).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/65unexpected (and silent) sumIntoGlobalValues failure2016-01-04T16:00:47ZJames Willenbringunexpected (and silent) sumIntoGlobalValues failure*Created by: nschloe*
@trilinos/tpetra
I have a larger application code in which I build up a matrix by looping over the edges of a mesh and sum values into the matrix for each of the two end points. I found that some indices aren't co...*Created by: nschloe*
@trilinos/tpetra
I have a larger application code in which I build up a matrix by looping over the edges of a mesh and sum values into the matrix for each of the two end points. I found that some indices aren't correctly inserted when running on more than one processes.
I could boil it down to
``` c++
#include <Teuchos_DefaultComm.hpp>
#include <Tpetra_CrsMatrix.hpp>
int main ( int argc, char *argv[] )
{
Teuchos::GlobalMPISession session(&argc, &argv, NULL);
// Initialize MPI
auto comm = Teuchos::DefaultComm<int>::getComm();
// build map in which process K owns row K
std::vector<int> ids = {comm->getRank()};
auto map = Teuchos::rcp(new Tpetra::Map<int>(-1, ids, 0, comm));
const int globalSize = map->getGlobalNumElements();
// insert indices from all processes
auto graph = Teuchos::rcp(new Tpetra::CrsGraph<int, int>(map, map, 0));
for (int i = 0; i < globalSize; i++) {
for (int j = 0; j < globalSize; j++) {
graph->insertGlobalIndices(i, Teuchos::tuple(j));
}
}
graph->fillComplete();
// fill matrix
auto A = Teuchos::rcp(new Tpetra::CrsMatrix<double,int,int>(graph));
A->setAllToScalar(0.0);
for (size_t k = 0; k < globalSize; k++) {
const int num = A->sumIntoGlobalValues(
k,
Teuchos::tuple(0, 1),
Teuchos::tuple(0.33, 1.55)
);
std::cout << "added from @" << comm->getRank() << " in row " << k << ": "
<< num
<< std::endl;
}
A->fillComplete();
return EXIT_SUCCESS;
}
```
When run on two procs, I'm getting
```
$ mpiexec -n 2 ./test
added from @0 in row 0: 1
added from @0 in row 1: 2
added from @1 in row 0: 2
added from @1 in row 1: 1
```
I would have expected that two entries are inserted for each `sumIntoGlobalValues`. The `insertGlobalIndices` I thought makes sure that the corresponding "slots" are present in the respective processes. Apparently, that's not the case.
When checking out the actual values after `A->fillComplete()` with
``` c++
Teuchos::Array<int> cols(100);
Teuchos::Array<double> vals(100);
size_t numss;
for (size_t k = 0; k < globalSize; k++) {
A->getGlobalRowCopy(k, cols, vals, numss);
std::cout << "@" << comm->getRank()
<< ", row " << k
<< ", num columns " << numss
<< ", columns ";
for (size_t kk = 0; kk < numss; kk++) {
std::cout << cols[kk] << " ";
}
std::cout << ", values ";
for (size_t kk = 0; kk < numss; kk++) {
std::cout << vals[kk] << " ";
}
std::cout << std::endl;
}
```
I'm getting
```
@0, row 0, num columns 2, columns -1 0 , values 0 0.66
@0, row 1, num columns 0, columns , values
@1, row 0, num columns 0, columns , values
@1, row 1, num columns 2, columns -1 1 , values 0 3.1
```
On a side node, is there a way to make Tpetra throw when this happens? Having to check the return value to assert correct operation seems a little Epetry.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/68describe with extreme verbosity only shows info on process 02016-01-07T00:49:11ZJames Willenbringdescribe with extreme verbosity only shows info on process 0*Created by: nschloe*
The output of
``` c++
#include <Teuchos_DefaultComm.hpp>
#include <Teuchos_VerboseObject.hpp>
#include <Tpetra_Map.hpp>
int main ( int argc, char *argv[] )
{
Teuchos::GlobalMPISession session(&argc, &argv, NULL...*Created by: nschloe*
The output of
``` c++
#include <Teuchos_DefaultComm.hpp>
#include <Teuchos_VerboseObject.hpp>
#include <Tpetra_Map.hpp>
int main ( int argc, char *argv[] )
{
Teuchos::GlobalMPISession session(&argc, &argv, NULL);
auto comm = Teuchos::DefaultComm<int>::getComm();
Tpetra::Map<int,int> map(23, 0, comm);
auto out = Teuchos::VerboseObjectBase::getDefaultOStream();
map.describe(*out, Teuchos::VERB_EXTREME);
return EXIT_SUCCESS;
}
```
when run on two procs is
```
$ make && mpiexec -n 2 ./tpetra-test
Process 0:
My number of entries: 12
My minimum global index: 0
My maximum global index: 11
My global indices: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]
```
The same goes for vectors, probably other types.
https://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/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/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/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/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/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/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/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/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/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/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.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/99NetCDF library configuration2017-08-22T19:08:06ZJames WillenbringNetCDF library configuration*Created by: gsjaardema*
The configuration of the NetCDF library, specifically for parallel builds, is becoming more complex and can cause build issues or reduced functionality if configured incorrectly. For example:
- NetCDF can be bu...*Created by: gsjaardema*
The configuration of the NetCDF library, specifically for parallel builds, is becoming more complex and can cause build issues or reduced functionality if configured incorrectly. For example:
- NetCDF can be built with or without HDF5 support. If built without HDF5, then the compression and netcdf-4 parallel support isn't available
- NetCDF can be built with or without parallel-netcdf (pnetcdf) support. If built without pnetcdf, then parallel capabilities for netcdf-3 files is not enabled.
- Exodus requires that NC_MAX_DIMS and NC_MAX_VARS be increased from their default values. If not changed, then some medium complex models cannot be created or read (See https://github.com/gsjaardema/seacas/blob/master/NetCDF-Mapping.md)
- NetCDF can be built with or without parallel support.
Currently, a developer will build HDF5 with its options; build parallel-netcdf if needed; and then build netcdf -- hopefully pointing it to the correct hdf5 and parallel-netcdf and setting the correct configure options. Then, the developer will configure Trilinos and has to also specify some of these options correctly so that the Exodus library in the SEACAS package will build with the correct capabilities.
This is error-prone and can be difficult to determine what part of the build/configuration was done incorrectly. The stand-alone seacas project (https://github.com/gsjaardema/seacas.git) has some cmake modules that will query the installed NetCDF library and determine whether it was built with no-hdf5, serial hdf5, or parallel hdf5; whether it was built with or without parallel-netcdf; and whether it has the correct values for NC_MAX_DIMS and NC_MAX_VARS. The module then sets the correct cmake variables.
These cmake modules are in the `cmake/modules` in the seacas github repository referenced above.
I would like to propose using these modules, or a variant of them in Trilinos to reduce the complexity of configuring the NetCDF and Exodus libraries.
@trilinos/seacas
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/100SEACAS Stray character prevents compilation2016-02-02T21:59:32ZJames WillenbringSEACAS Stray character prevents compilation*Created by: crtrott*
Hi
after the current update of seacas I get the following errors:
```
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:1:1: error: expected identifier or \u2018(\u2019 before \u2018/\u2019 token
/h...*Created by: crtrott*
Hi
after the current update of seacas I get the following errors:
```
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:1:1: error: expected identifier or \u2018(\u2019 before \u2018/\u2019 token
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:8:32: warning: character constant too long for its type [enabled by default]
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:16:65: error: unknown type name \u2018you\u2019
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:16:74: error: expected \u2018=\u2019, \u2018,\u2019, \u2018;\u2019, \u2018asm\u2019 or \u2018__attribute__\u2019 before \u2018not\u2019
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:25:1: error: stray \u2018@\u2019 in program
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:25:1: error: stray \u2018@\u2019 in program
In file included from /home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:27:0:
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.h:3:40: error: invalid suffix "AL85000" on integer constant
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.h:27:61: error: unknown type name \u2018LOSS\u2019
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.h:27:69: error: expected \u2018=\u2019, \u2018,\u2019, \u2018;\u2019, \u2018asm\u2019 or \u2018__attribute__\u2019 before \u2018USE\u2019
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.h:28:22: error: unknown type name \u2018OR\u2019
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.h:28:34: error: expected \u2018=\u2019, \u2018,\u2019, \u2018;\u2019, \u2018asm\u2019 or \u2018__attribute__\u2019 before \u2018INTERRUPTION\u2019
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:28:41: warning: extra tokens at end of #include directive [enabled by default]
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c: In function \u2018adler\u2019:
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:37:21: warning: declaration of \u2018adler\u2019 shadows a global declaration [-Wshadow]
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c:37:8: warning: shadowed declaration is here [-Wshadow]
```
Deleting the license header from both
```
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.c
/home/crtrott/Trilinos/packages/seacas/libraries/suplib/adler.h
```
Fixes that, so I guess its just an issue with a windows character or so coming in.
@trilinos/seacas
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/97libmuelu.a is Zero Length with Intel 15.5/16.1 Compiler when Building with Debug2018-03-03T00:41:23ZJames Willenbringlibmuelu.a is Zero Length with Intel 15.5/16.1 Compiler when Building with Debug*Created by: nmhamster*
We have seen a few builds where libmuelu.a is zero length or 8 bytes in length when installed. The common situation appears to be with roughly the packages required for NALU but also when CMAKE_BUILD_TYPE is set ...*Created by: nmhamster*
We have seen a few builds where libmuelu.a is zero length or 8 bytes in length when installed. The common situation appears to be with roughly the packages required for NALU but also when CMAKE_BUILD_TYPE is set to DEBUG and the compiler flags are set to -O3 -g. In all sightings so far we have been using either the Intel 15.3, 15.5 or 16.1 compilers. Looking at the object files some of these are quite large making me wonder if the collective size is exceeding limits somewhere in the archive/library building process. The result is that Muelu objects are not found in the library and linking fails. If CMAKE_BUILD_TYPE is set to RELEASE the library builds correctly and linking proceeds as expected.
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/104Tpetra::Vector::normWeighted emits a deprecated warning2016-01-28T08:20:41ZJames WillenbringTpetra::Vector::normWeighted emits a deprecated warning*Created by: mhoemmen*
@trilinos/tpetra
Tpetra::Vector::normWeighted is deprecated. There's nothing wrong with deprecation. However, the method calls its parent class' method MultiVector::normWeighted, which is also deprecated. Eve...*Created by: mhoemmen*
@trilinos/tpetra
Tpetra::Vector::normWeighted is deprecated. There's nothing wrong with deprecation. However, the method calls its parent class' method MultiVector::normWeighted, which is also deprecated. Even though nothing calls Vector::normWeighted any more, some compilers still emit a deprecated warning when building it, because it calls a deprecated method. This breaks builds that turn on warnings as errors.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/105Tpetra::Details::FixedHashTable: copyOffsets does incorrect host access from ...2016-01-28T13:44:04ZJames WillenbringTpetra::Details::FixedHashTable: copyOffsets does incorrect host access from CUDA*Created by: mhoemmen*
Tpetra::Details::FixedHashTable: Fix CUDA crash
@trilinos/tpetra
FixedHashTable implements Tpetra::Map's conversion from global to local
indices for the noncontiguous Map case, among other things. It has a
"cop...*Created by: mhoemmen*
Tpetra::Details::FixedHashTable: Fix CUDA crash
@trilinos/tpetra
FixedHashTable implements Tpetra::Map's conversion from global to local
indices for the noncontiguous Map case, among other things. It has a
"copy constructor" which converts between instances on different Kokkos
devices. This constructor uses the copyOffsets internal function, which
lives in Tpetra_Details_FixedHashTable_decl.hpp. copyOffsets copies
FixedHashTable::ptr_ -- the offsets array (corresponds to the 'ptr'
array in CSR) -- from one device to another. Different devices may use
different offset types, so copyOffsets can't just use Kokkos::deep_copy.
It also checks for overflow. Thus, it uses a custom parallel_reduce
functor, CopyOffsets (note initial capital).
The CopyOffsets functor is templated on the input and output View types.
It assumes that the output View's execution space can access the input
View's memory space. This is a bug. For example, if the output View's
execution space is Kokkos::Cuda, it cannot access host memory
(Kokkos::HostSpace). (That's the wrong direction for CUDA UVM.) This
is why the Dashboard was showing a failed test: the test was throwing in
this case, because Kokkos was catching the incorrect access at run time.
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/112Compiler warnings for Amesos2_Superludist_FunctionMap.hpp2016-02-12T00:48:49ZJames WillenbringCompiler warnings for Amesos2_Superludist_FunctionMap.hpp*Created by: BarrySmith*
/Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/bin/mpicxx -o ex63.o -c -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g -O3 -I/Users/petsc/petsc.clone-4/include -I/Users/petsc/petsc.clone-4...*Created by: BarrySmith*
/Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/bin/mpicxx -o ex63.o -c -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g -O3 -I/Users/petsc/petsc.clone-4/include -I/Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include `pwd`/ex63.cxx
In file included from /Users/petsc/petsc.clone-4/src/ksp/ksp/examples/tutorials/ex63.cxx:68:
In file included from /Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2.hpp:45:
In file included from /Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2_Factory.hpp:102:
In file included from /Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2_Superludist.hpp:47:
In file included from /Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2_Superludist_decl.hpp:58:
/Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2_Superludist_FunctionMap.hpp:285:17: warning: comparison of constant 67 with expression of type 'SLUD::DiagScale_t' is always false [-Wtautological-constant-out-of-range-compare]
char eq = AMESOS2_SLUD_GET_EQUED(*equed);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2_Superludist_FunctionMap.hpp:71:98: note: expanded from macro 'AMESOS2_SLUD_GET_EQUED'
# define AMESOS2_SLUD_GET_EQUED(ds) (((ds)==SLUD::NOEQUIL) ? 'N' : ((ds)==SLUD::ROW) ? 'R' : ((ds)=='C') ? SLUD::COL : SLUD::BOTH)
```
~~~~^ ~~~
```
/Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2_Superludist_FunctionMap.hpp:306:17: warning: comparison of constant 67 with expression of type 'SLUD::DiagScale_t' is always false [-Wtautological-constant-out-of-range-compare]
char eq = AMESOS2_SLUD_GET_EQUED(*equed);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/petsc/petsc.clone-4/arch-osx-xsdk-opt/include/Amesos2_Superludist_FunctionMap.hpp:71:98: note: expanded from macro 'AMESOS2_SLUD_GET_EQUED'
# define AMESOS2_SLUD_GET_EQUED(ds) (((ds)==SLUD::NOEQUIL) ? 'N' : ((ds)==SLUD::ROW) ? 'R' : ((ds)=='C') ? SLUD::COL : SLUD::BOTH)
```
~~~~^ ~~~
```
2 warnings generated.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/111Tpetra::Details::FixedHashTable: With CUDA, empty table's hasDuplicateKeys() ...2016-01-30T10:26:57ZJames WillenbringTpetra::Details::FixedHashTable: With CUDA, empty table's hasDuplicateKeys() returns true*Created by: mhoemmen*
@trilinos/tpetra This relates to Tpetra::Details::FixedHashTable. With the CUDA device type only, an empty table's hasDuplicateKeys() returns true. It should return false.
*Created by: mhoemmen*
@trilinos/tpetra This relates to Tpetra::Details::FixedHashTable. With the CUDA device type only, an empty table's hasDuplicateKeys() returns true. It should return false.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/117New "MT Gauss-Seidel" does not seem to work from within MueLu2016-01-30T21:34:28ZJames WillenbringNew "MT Gauss-Seidel" does not seem to work from within MueLu*Created by: aprokop*
@trilinos/ifpack2 @srajama1 @mndevec
In MueLu, we have a driver that allows us to run arbitrary input decks (located in muelu/test/scaling, MueLu_Driver.exe, enabled when MueLu tests are enabled). In particular, ...*Created by: aprokop*
@trilinos/ifpack2 @srajama1 @mndevec
In MueLu, we have a driver that allows us to run arbitrary input decks (located in muelu/test/scaling, MueLu_Driver.exe, enabled when MueLu tests are enabled). In particular, it is possible to test Ifpack2 smoothers with MueLu input deck by constructing a one level hierarchy.
I tried running the driver with the following input deck:
``` xml
<ParameterList name="MueLu">
<Parameter name="max levels" type="int" value="1"/>
<Parameter name="coarse: type" type="string" value="RELAXATION"/>
<ParameterList name="coarse: params">
<Parameter name="relaxation: type" type="string" value="Gauss-Seidel"/>
</ParameterList>
</ParameterList>
```
running it like this `./MueLu_Driver.exe --xml=onelevel-2_np4.xml --solver=standalone`. Here, `standalone` means use MueLu to iterate, so this is essentially a fixed point iteration solver. The result with regular Gauss-Seidel shows expected convergence:
```
iter: 0 residual = {9.99999999999999778e-01}
iter: 1 residual = {2.91355224068349961e-01}
iter: 2 residual = {1.03112694566287258e-01}
iter: 3 residual = {4.24030494030126423e-02}
iter: 4 residual = {2.09351268542225487e-02}
iter: 5 residual = {1.23958077884280798e-02}
iter: 6 residual = {8.39363169782942654e-03}
iter: 7 residual = {6.18796307752396586e-03}
iter: 8 residual = {4.81762942015303165e-03}
iter: 9 residual = {3.89531035831334332e-03}
iter: 10 residual = {3.23934079863641899e-03}
```
I then changed `Gauss-Seidel` in the input deck to `MT Gauss-Seidel` and here is the result:
```
iter: 0 residual = {9.99999999999999778e-01}
iter: 1 residual = {9.99999999999999778e-01}
iter: 2 residual = {9.99999999999999778e-01}
iter: 3 residual = {9.99999999999999778e-01}
iter: 4 residual = {9.99999999999999778e-01}
iter: 5 residual = {9.99999999999999778e-01}
iter: 6 residual = {9.99999999999999778e-01}
iter: 7 residual = {9.99999999999999778e-01}
iter: 8 residual = {9.99999999999999778e-01}
iter: 9 residual = {9.99999999999999778e-01}
iter: 10 residual = {9.99999999999999778e-01}
```
This is definitely not the expected behavior. Even if coloring changes the convergence, it should still converge, right?
I would be happy to work with anybody to fix this issue.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/114importAndFillComplete problem in CUDA build2017-08-09T23:08:01ZJames WillenbringimportAndFillComplete problem in CUDA build*Created by: kddevin*
@trilinos/tpetra
@trilinos/zoltan2
I sent this email to the Tpetra experts last week; I'm adding it as an issue so that I don't forget about it. This issue causes three Zoltan2 tests to fail in Christian's CUDA...*Created by: kddevin*
@trilinos/tpetra
@trilinos/zoltan2
I sent this email to the Tpetra experts last week; I'm adding it as an issue so that I don't forget about it. This issue causes three Zoltan2 tests to fail in Christian's CUDA build on perseus.
Chris Siefert said he would take a look and help debug.
I recently modified Zoltan2 code to use importAndFillComplete. It is
working almost everywhere, but we have failures in Christian's CUDA
build.
Here is the error that is thrown:
lowCommunicationMakeColMapAndReindex: Cannot figure out if PID is owned.
/space/jenkins/slave/workspace/Trilinos_perseus_gcc_4.7.2_cuda_7.5.18/MPI_R
ELEASE_DEV_DownStream_ETI_SERIAL-OFF_OPENMP-OFF_PTHREAD-OFF_CUDA-ON_COMPLEX
-ON/Trilinos/packages/tpetra/core/src/Tpetra_Import_Util2.hpp:1174:
Throw number = 1
Throw test that evaluated to true: PID == -1
The call to lowCommunicationMakeColMapAndReindex is called from
transferAndFillComplete.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/118Performance of looping over Tpetra CrsMatrix rows2016-06-13T22:56:17ZJames WillenbringPerformance of looping over Tpetra CrsMatrix rows*Created by: aprokop*
@trilinos/tpetra @jhux2 @mhoemmen @crtrott
Let me first admit that I am very likely doing something wrong.
I wrote a simple driver (located at muelu/test/perf_test_kokkos, which essentially finds the number of n...*Created by: aprokop*
@trilinos/tpetra @jhux2 @mhoemmen @crtrott
Let me first admit that I am very likely doing something wrong.
I wrote a simple driver (located at muelu/test/perf_test_kokkos, which essentially finds the number of nonzeros in a CrsMatrix by looping through rows and adding lengths. It considers three scenarios:
- Looping through Xpetra layer abstraction (something MueLu is very interested in)
- Looping directly through Tpetra/Epetra
- Looping through the local Kokkos CrsMatrix
The results were somewhat unexpected for me. I was running with a single MPI rank with OpenMp OMP_NUM_THREADS=1, disabled HWLOC (so that Kokkos respects this). Here are some results:
For Tpetra
```
Loop #1: Xpetra/Tpetra 0.05980 (1)
Loop #2: Tpetra 0.05867 (1)
Loop #3: Kokkos-1 0.00274 (1)
Loop #4: Kokkos-2 0.00214 (1)
```
For Epetra
```
Loop #1: Xpetra/Epetra 0.01933 (1)
Loop #2: Epetra 0.01385 (1)
Loop #3: Kokkos-1 0.00427 (1)
Loop #4: Kokkos-2 0.00213 (1)
```
So it seems to me that using local Kokkos matrix has absolutely be the way, as it is ~30 times faster than through Tpetra, and ~6 times faster than through Epetra.
I would like to know if anybody done any performance studies like this, or what could be the reason.
If I am doing something that is completely wrong, I would also like to know that.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/121Tpetra::Row{Graph,Matrix}: Add non-Teuchos versions of get{Global,Local}Row{C...2017-08-01T00:02:32ZJames WillenbringTpetra::Row{Graph,Matrix}: Add non-Teuchos versions of get{Global,Local}Row{Copy,View}*Created by: mhoemmen*
@trilinos/tpetra
get{Global,Local}Row{Copy,View} need versions that take either raw pointers, and/or Kokkos::View.
This affects RowGraph, RowMatrix, CrsGraph, CrsMatrix, and BlockCrsMatrix. Remember that these...*Created by: mhoemmen*
@trilinos/tpetra
get{Global,Local}Row{Copy,View} need versions that take either raw pointers, and/or Kokkos::View.
This affects RowGraph, RowMatrix, CrsGraph, CrsMatrix, and BlockCrsMatrix. Remember that these methods are pure virtual methods in the Tpetra::Row{Graph,Matrix} subclasses, so we have to add new methods with _different_ _names_, otherwise they will shadow the old methods. This will cause lots of compiler warnings, for good reason: virtual method inheritance works by name, not by function signature. Furthermore, we can't just change the methods' arguments, without breaking backwards compatibility. Remember that users may have written their own subclasses of Tpetra::Row{Graph,Matrix}. Thus, we have to come up with new method names. How about:
- get{Local,Global}Row{Copy,View}Raw for raw pointers, and
- get{Local,Global}Row{Copy,View}K for Kokkos::View (unmanaged of course)?
Tpetra-backloghttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/123Inconsistent default execution spaces between kokkos and tpetra2016-04-01T14:29:12ZJames WillenbringInconsistent default execution spaces between kokkos and tpetra*Created by: rppawlo*
@trilinos/tpetra
We are having some failures in panzer that have been tracked back to inconsistent default execution spaces between tpetra and kokkos. Panzer uses the tpetra default default execution space, but ...*Created by: rppawlo*
@trilinos/tpetra
We are having some failures in panzer that have been tracked back to inconsistent default execution spaces between tpetra and kokkos. Panzer uses the tpetra default default execution space, but panzer depends on intrepid2 which uses the default execution space from kokkos.
When a user does not specify the kokkos and tpetra execution spaces explicitly, there is a high probability that the execution spaces are mismatched. The Threads TPL usually is automatically enabled due to ctest examining the environment (if not set explicitly in configure). Kokkos will choose a pthread execution space if TPL_ENABLE_Pthread is on. Tpetra, though, sees both a serial and the pthread execution spaces available, but chooses serial instead of pthread:
```
# Don't turn on both Serial and Threads by default. Prefer Serial,
# because Threads is a last resort. Of course, users may still
# enable Threads explicitly, by setting TPETRA_INST_PTHREAD=ON.
IF (HAVE_TPETRA_INST_SERIAL_DEFAULT AND HAVE_TPETRA_INST_PTHREAD_DEFAULT)
GLOBAL_SET(HAVE_TPETRA_INST_PTHREAD_DEFAULT OFF)
ENDIF ()
```
So what happens is that in trilinos ci testing, Panzer tests assume serial space from Tpetra default, but the intrepid2 kernels default to Threads and the tests fail because the threads space is not initialized by panzer tests.
All currently failing panzer tests are due to this. I tried switching panzer over to use the kokkos default node type, but then the tests fail to build because tpetra does not build the pthread node under ETI.
I know we can fix this by going into all our trilinos nightly testing configure scripts and explicitly specifying a consistent execution space, but I believe this is going to be an issue for Trilinos users in general. Many don't use kokkos and don't know to set the execution spaces and make sure that they are consistent across packages. Can we set the defaults consistently across packages (for Tpetra to directly key off of Kokkos), yet still allow users to override the default execution spaces in each package.
By the way - we have cases where application codes need both serial and pthread spaces. DTK only cares about MPI communication and is therefore hard coded to a Serial execution space in Tpetra (to avoid having to push templates through the entire stack). Albany uses DTK for multiphysics coupling but is also Kokkos aware and wants to use kokkos in a parallel execution space internally.
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/125SEACAS: crashes on KNL with OpenMP enabled during compilation. 2018-09-11T15:47:32ZJames WillenbringSEACAS: crashes on KNL with OpenMP enabled during compilation. *Created by: crtrott*
This is the start for tracking an issue on KNL where the mesh load in Nalu crashes when seacas got compiled with OpenMP enabled (even though it seems Seacas doesn't actually use OpenMP). I tracked it down to libIos...*Created by: crtrott*
This is the start for tracking an issue on KNL where the mesh load in Nalu crashes when seacas got compiled with OpenMP enabled (even though it seems Seacas doesn't actually use OpenMP). I tracked it down to libIoss.a. If I just link Nalu against the serial version of that library (while using the OpenMP ones for everything else) it works.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/124Amesos2::SuperLU_DIST 4.3 segfault2016-02-23T21:10:46ZJames WillenbringAmesos2::SuperLU_DIST 4.3 segfault*Created by: jdbooth*
Tested SuperLU_DIST 4.3 (Newest as of December 31 2015).
GCC 4.9 with both Trilinos DEBUG + -O0 and SuperLU_DIST debuglvl = 2
Segfaults if using more than 1 mpi-rank.
Memory error most likely on Amesos2 sid...*Created by: jdbooth*
Tested SuperLU_DIST 4.3 (Newest as of December 31 2015).
GCC 4.9 with both Trilinos DEBUG + -O0 and SuperLU_DIST debuglvl = 2
Segfaults if using more than 1 mpi-rank.
Memory error most likely on Amesos2 side.
@trilinos/amesos2
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/128MueLu: build errors when enabling MueLu_ENABLE_Kokkos_Refactor2016-02-05T04:19:43ZJames WillenbringMueLu: build errors when enabling MueLu_ENABLE_Kokkos_Refactor*Created by: mhoemmen*
@trilinos/muelu
When I enable MueLu_ENABLE_Kokkos_Refactor, I get build errors:
.../Trilinos/packages/muelu/src/Graph/MueLu_Aggregates_kokkos_def.hpp:111:51: error: no member named 'getLocalView' in 'Xpetra::Ve...*Created by: mhoemmen*
@trilinos/muelu
When I enable MueLu_ENABLE_Kokkos_Refactor, I get build errors:
.../Trilinos/packages/muelu/src/Graph/MueLu_Aggregates_kokkos_def.hpp:111:51: error: no member named 'getLocalView' in 'Xpetra::Vector<int, int, int,
Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Threads, Kokkos::HostSpace> >'
auto procWinner = procWinner_ ->template getLocalView<DeviceType>();
~~~~~~~~~~~ ^
.../Trilinos/packages/muelu/src/Graph/MueLu_Aggregates_kokkos_def.hpp:110:51: error: no member named 'getLocalView' in 'Xpetra::Vector<int, int, long
long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Threads, Kokkos::HostSpace> >'
auto vertex2AggId = vertex2AggId_->template getLocalView<DeviceType>();
The only reason I'm trying this is that I would like to enable the Xpetra vs. Epetra vs. Tpetra vs. Kokkos fill benchmark, mentioned in Issue #118. However, the benchmark is only enabled if MueLu_ENABLE_Kokkos_Refactor is ON.
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/129Simplify MueLu Stratimikos interface2016-02-14T20:00:36ZJames WillenbringSimplify MueLu Stratimikos interface*Created by: tawiesn*
There are two versions of Stratimikos::enableMueLu: a templated version and a non-templated version. The non-templated version traditionally is misunderstood as supporting only Epetra, leading to the fact that user...*Created by: tawiesn*
There are two versions of Stratimikos::enableMueLu: a templated version and a non-templated version. The non-templated version traditionally is misunderstood as supporting only Epetra, leading to the fact that users tend to call both versions. Registering MueLu twice in Stratimikos complicates user's life and is not necessary.
We should have only routine enableMueLu which is called by the user/application for any desired set of template parameters using appropriate names in Stratimikos (e.g. MueLu-longlong instead of MueLu-Tpetra). The Stratimikos interface is independent from Epetra/Tpetra (but it throws if you use Epetra with e.g. the GO=long interface).
The only reason to keep the non-templated enableMueLu routine would be because of backwards compatibility. Even then, we have to simplify the code in there (calling the templated routine).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/130error: 'isExperimental' was not declared in this scope2016-02-05T02:52:08ZJames Willenbringerror: 'isExperimental' was not declared in this scope*Created by: nschloe*
Commit 12896cfacbb5f051e27e7a4175b6a8c522f3a7f7 introduces the build error
```
packages/ifpack2/src/Ifpack2_RILUK_decl.hpp:673:32: error: 'isExperimental' was not declared in this scope
new_riluk->isExperimenta...*Created by: nschloe*
Commit 12896cfacbb5f051e27e7a4175b6a8c522f3a7f7 introduces the build error
```
packages/ifpack2/src/Ifpack2_RILUK_decl.hpp:673:32: error: 'isExperimental' was not declared in this scope
new_riluk->isExperimental_ = isExperimental;
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/133MueLu does not build with Epetra disabled2016-02-08T16:08:42ZJames WillenbringMueLu does not build with Epetra disabled*Created by: etphipp*
@trilinos/muelu
Buiding MueLu with Epetra disabled results in this build error:
In file included from /home/etphipp/Trilinos/Trilinos/packages/muelu/adapters/stratimikos/Thyra_MueLuPreconditionerFactory_decl.hpp...*Created by: etphipp*
@trilinos/muelu
Buiding MueLu with Epetra disabled results in this build error:
In file included from /home/etphipp/Trilinos/Trilinos/packages/muelu/adapters/stratimikos/Thyra_MueLuPreconditionerFactory_decl.hpp:84:0,
from /home/etphipp/Trilinos/Trilinos/packages/muelu/adapters/stratimikos/Thyra_MueLuPreconditionerFactory_def.hpp:49,
from /home/etphipp/Trilinos/build/opt_mpi_stokhos_nocuda/packages/muelu/adapters/ExplicitInstantiation/Thyra_MueLuPreconditionerFactory.cpp:52:
/home/etphipp/Trilinos/Trilinos/packages/muelu/adapters/xpetra/MueLu_CreateXpetraPreconditioner.hpp:18:36: fatal error: MueLu_EpetraOperator.hpp: No such file or directory
#include <MueLu_EpetraOperator.hpp>
I commented out the include of MueLu_EpetraOperator.hpp and it appeared to compile since Epetra does not appear to be used directly in that file. However I did not test if it works with Epetra enabled.