Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-01-28T15:26:19Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4234Teuchos::ArrayView constructor should set its pointer to null if input pointe...2019-01-28T15:26:19ZJames WillenbringTeuchos::ArrayView constructor should set its pointer to null if input pointer is nonnull but length is zero*Created by: mhoemmen*
@trilinos/teuchos @trilinos/tpetra @kddevin @jhux2 @csiefer2
See #4225 discussion.
## Expectations
It should be trivial to create a Teuchos::ArrayView from an std::vector or (host) Kokkos::View. Users s...*Created by: mhoemmen*
@trilinos/teuchos @trilinos/tpetra @kddevin @jhux2 @csiefer2
See #4225 discussion.
## Expectations
It should be trivial to create a Teuchos::ArrayView from an std::vector or (host) Kokkos::View. Users should not have to test whether the pointer is null if the length is zero.
## Related Issues
* Related to #4225
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4237kokkos-kernels: now requires fortran to configure2019-01-23T16:05:59ZJames Willenbringkokkos-kernels: now requires fortran to configure*Created by: rppawlo*
A change to kokkos-kernels last week now makes the package require fortran. This has brought down testing suite for Drekar that use the type2 stack but does not enable fortran. We are trying to avoid requiring user...*Created by: rppawlo*
A change to kokkos-kernels last week now makes the package require fortran. This has brought down testing suite for Drekar that use the type2 stack but does not enable fortran. We are trying to avoid requiring users to have to use the kitware hacked ninja to get fortran support. Was this dependency change intended? https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4235Albany builld broken due to missing KokkosKernels_FortranMangling.h header2019-01-25T00:21:58ZJames WillenbringAlbany builld broken due to missing KokkosKernels_FortranMangling.h header*Created by: ikalash*
Here is the error:
```
/home/ikalash/nightlyAlbanyTests/Results/Trilinos/build/install/include/KokkosBlas1_dot_tpl_spec_decl.hpp:50:10: fatal error: KokkosKernels_FortranMangling.h: No such file or directory
```...*Created by: ikalash*
Here is the error:
```
/home/ikalash/nightlyAlbanyTests/Results/Trilinos/build/install/include/KokkosBlas1_dot_tpl_spec_decl.hpp:50:10: fatal error: KokkosKernels_FortranMangling.h: No such file or directory
```
You can see more details on the Albany dashboard, e.g., http://cdash.sandia.gov/CDash-2-3-0/viewBuildError.php?buildid=80609 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4221SPARC source build error from Tpetra_Experimental_BlockCrsMatrix_decl.hpp -We...2019-02-05T19:30:57ZJames WillenbringSPARC source build error from Tpetra_Experimental_BlockCrsMatrix_decl.hpp -Werror for shadowing warning with Clang 5.0.1 build*Created by: bartlettroscoe*
CC: @trilinos/tpetra, @kddevin (Trilinos Data Services Product Lead), @mhoemmen, @bartlettroscoe, @fryeguy52, @micahahoward, @sebrowne
## Next Action Status
Looks like PR #4226 merged to 'develop' on...*Created by: bartlettroscoe*
CC: @trilinos/tpetra, @kddevin (Trilinos Data Services Product Lead), @mhoemmen, @bartlettroscoe, @fryeguy52, @micahahoward, @sebrowne
## Next Action Status
Looks like PR #4226 merged to 'develop' on 1/23/2019 has fixed these build errors with SPARC as shown in the new SPARC 'master' + Trilinos 'develop' testing process being set up in [TRIL-243](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-243). In particular, the 100% clean SPARC 'master' builds (against Trilinos from 1/31/2019) shown [here](http://compsim-dashboard.sandia.gov/cdash/index.php?project=SPARC&date=2019-01-31&filtercount=1&showfilters=1&field1=groupname&compare1=61&value1=Trilinos%20Integration) proves this.
## Description
As of the Trilinos 'develop' version 882d842b73dc475291b1e2945a9ba532577e2f1d, the Clang 5.0.1 build of SPARC (using the `cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt` build of Trilinos) is broken which uses -Werror in the build showing the build error:
```
In file included from /scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Xpetra_TpetraBlockCrsMatrix.hpp:53:
In file included from /scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Tpetra_Experimental_BlockCrsMatrix.hpp:1:
/scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Tpetra_Experimental_BlockCrsMatrix_decl.hpp:757:3: error: 'Tpetra::Experimental::BlockCrsMatrix<double, int, long long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >::packAndPrepareNew' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
packAndPrepareNew (const SrcDistObject& sourceObj,
^
../include/linsys/MatrixTpetraBlockCrs.h:71:25: note: in instantiation of template class 'Tpetra::Experimental::BlockCrsMatrix<double, int, long long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >' requested here
return tpetra_mat_->getNodeNumRows() * block_size_;
^
/scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Tpetra_DistObject_decl.hpp:823:5: note: hidden overloaded virtual function 'Tpetra::DistObject<char, int, long long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >::packAndPrepareNew' declared here: type mismatch at 3rd parameter ('Kokkos::DualView<packet_type *, buffer_device_type> &' (aka 'DualView<char *, Device<Kokkos::Serial, Kokkos::HostSpace> > &') vs 'Kokkos::DualView<impl_scalar_type *, buffer_device_type> &' (aka 'DualView<double *, Device<Kokkos::Serial, Kokkos::HostSpace> > &'))
packAndPrepareNew (const SrcDistObject& source,
^
In file included from ../src/hofd-aero/AlgorithmComputeResidualVolumeCCHOFD.C:8:
In file included from ../include/hofd-core/StructuredCCHOFDDiscretization.h:11:
In file included from ../include/disc-core/StructuredDiscretization.h:11:
In file included from ../include/sparc-util/Array4D.h:27:
In file included from ../include/sparc-util/ProjectDefs.h:28:
In file included from /scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Xpetra_TpetraBlockCrsMatrix.hpp:53:
In file included from /scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Tpetra_Experimental_BlockCrsMatrix.hpp:1:
/scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Tpetra_Experimental_BlockCrsMatrix_decl.hpp:765:3: error: 'Tpetra::Experimental::BlockCrsMatrix<double, int, long long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >::unpackAndCombineNew' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
unpackAndCombineNew (const Kokkos::DualView<const local_ordinal_type*, device_type>& importLIDs,
^
/scratch/rabartl/SPARC.base/sparc/Trilinos/cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt/include/Tpetra_DistObject_decl.hpp:889:5: note: hidden overloaded virtual function 'Tpetra::DistObject<char, int, long long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >::unpackAndCombineNew' declared here: type mismatch at 2nd parameter ('const Kokkos::DualView<const packet_type *, buffer_device_type> &' (aka 'const DualView<const char *, Device<Kokkos::Serial, Kokkos::HostSpace> > &') vs 'const Kokkos::DualView<const impl_scalar_type *, buffer_device_type> &' (aka 'const DualView<const double *, Device<Kokkos::Serial, Kokkos::HostSpace> > &'))
unpackAndCombineNew (const Kokkos::DualView<const local_ordinal_type*, device_type>& importLIDs,
^
2 errors generated.
```
Not clear when this first started failing since we don't have automated builds of SPARC 'master' against Trilinos 'develop' running yet (see [TRIL-243](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-243)).
## Current Status on CDash
Can't see this on CDash yet. Instead, must build SPARC 'master' against Trilinos 'develop' as described below.
## Steps to Reproduce
Follow the directions [here](https://snl-wiki.sandia.gov/display/CoodinatedDevOpsATDM/Building+ATDM+APPs+Against+Local+Installs+of+Trilinos#BuildingATDMAPPsAgainstLocalInstallsofTrilinos-BuildingandTestingSPARCAgainstLocalTrilinosInstallation) for building SPARC 'master' against Trilinos 'develop'. use the build name `cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt`. To run just that build, use:
```
$ cd sparc/
$ ./sparc-tril-dev-scripts/build_and_test_atdm_trilinos_and_sparc.sh \
cee-rhel6_clang-5.0.1_openmpi-1.10.2_serial_static_opt
```
Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4212Zoltan2: MJ does not work with integer coordinates2019-01-28T15:26:20ZJames WillenbringZoltan2: MJ does not work with integer coordinates*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/zoltan2 @MicheldeMessieres
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
MJ should function when users provide scalar_t = int coordinates (e.g., (i.,j) indices of matrix entries) to be partitioned.
## Current Behavior
MJ requires scalar_t = float or double. MJ uses the users' scalar_t as the data type for cuts and ratios. When scalar_t = int, MJ segfaults with division by zero or hangs, due to truncation of differences of coordinates, etc.
## Possible Solution
Possible solutions:
- throw an error if users provide scalar_t = int; require users to copy their int data to float or double before calling MJ
- allow users to provide scalar_t = int, but define an internal coordinate type as double and use that throughout the code; copy the user's int coordinates into the internal coordinate type and proceed
- do a massive overhall of MJ to use scalar_t in some places and internal coordinate type where needed.
I prefer the second solution over the first, but it will require more work; it will likely require changes related to #4211 as well. The third solution would cause many code diffs, which would complicated the eventual merge of @MicheldeMessieres' work on GPU-enabled MJ.
## Steps to Reproduce
A test is already written: zoltan2/test/partition/mj_int_coordinates.cpp.
## Related Issues
#4211 #4207
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4211Zoltan2 coordinateModelPartBox should store doubles, not scalar_t2019-01-28T15:26:15ZJames WillenbringZoltan2 coordinateModelPartBox should store doubles, not scalar_t*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: kddevin*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/zoltan2
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
coordinateModelPartBox is used for storing bounding box info for the parts in a geometric partition. These boxes can be searched, then, for pointAssign and boxAssign functionality for, say, contact detection or particle methods. One would expect the union of the boxes to cover the entire geometric domain given to the partitioner.
## Current Behavior
Currently, coordinateModelPartBox stores bounding box info using the user's scalar_t. However, if the user provides scalar_t = int, the box boundaries could be truncated so that a complete cover of the domain is not achieved. Plus, there likely will be compiler issues in having scalar_t = int that would have to be resolved.
## Motivation and Context
Trying to use scalar_t=int with geometric partitioning causes problems in MJ and in use of the coordinateModelPartBox. For example, one might give scalar_t=int to partition the (i,j) indices of a matrix.
In truth, there is no reason to use the users' scalar_t in coordinateModelPartBox. The data type is a coordinate, which we can define to be double. We might allow the constructor to be templated on other types, but we should store doubles. Users should not specify the type of values that we are computing. (See #1312)
## Definition of Done
Remove template parameters to coordinateModelPartBox; define coordinate type to be stored as double; update code and interface.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4225Tpetra: ImportExport2_UnitTest & FixedHashTable tests fail in debug mode; Teu...2019-01-28T15:26:22ZJames WillenbringTpetra: ImportExport2_UnitTest & FixedHashTable tests fail in debug mode; Teuchos::ArrayView ctor issue*Created by: mhoemmen*
@trilinos/tpetra @trilinos/teuchos @bartlettroscoe @ibaned
Some Tpetra tests have been failing in debug mode. For example, FixedHashTable's test fails. `Teuchos::ArrayView`'s constructor that takes a pointer...*Created by: mhoemmen*
@trilinos/tpetra @trilinos/teuchos @bartlettroscoe @ibaned
Some Tpetra tests have been failing in debug mode. For example, FixedHashTable's test fails. `Teuchos::ArrayView`'s constructor that takes a pointer and a length throws, because the length is zero but the pointer is nonnull. When I stop `ArrayView`'s constructor from throwing, the test passes just fine.
This is a bit of a problem, because `Kokkos::View` permits a View with a zero length to have a nonnull pointer. I can see the value of the test, but it is a bit troublesome to have to do an extra test to convert from `Kokkos::View` to `Teuchos::ArrayView`. Furthermore, `std::vector` behaves just like `Kokkos::View`, in that `.data()` need not return `nullptr` if the vector's length is zero.
My plan was to go through Tpetra, find all instances of that constructor, and fix them. I plan to modify the relevant conversion functions in the TeuchosKokkosCompat subpackage, and only use those. However, it seems like this could lead to trouble when attempting obvious conversions from `std::vector` to `Teuchos::ArrayView`. Should we consider removing this debug test?
See e.g., https://github.com/trilinos/Trilinos/issues/184 .
## Expectations
Conversions from zero-length `std::vector` or `Kokkos::View` to `Teuchos::ArrayView` should not require an extra branch just to make the pointer null if the length is zero.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4202Xpetra: Is there an equivalent to Epetra's ReplaceDiagonalValues()?2019-02-19T15:49:29ZJames WillenbringXpetra: Is there an equivalent to Epetra's ReplaceDiagonalValues()?*Created by: mayrmt*
@trilinos/xpetra
@lucbv
In Epetra, the diagonal of a matrix can be replaced by `Epetra_CrsMatrix::ReplaceDiagonalValues()`. Is there an equivalent routine in Xpetra?
I know how to extract a copy of the diag...*Created by: mayrmt*
@trilinos/xpetra
@lucbv
In Epetra, the diagonal of a matrix can be replaced by `Epetra_CrsMatrix::ReplaceDiagonalValues()`. Is there an equivalent routine in Xpetra?
I know how to extract a copy of the diagonal via `Xpetra::Matrix::getLocalDiagCopy()`, but I couldn't find a mechanism to specifically replace the diagonal.
I can think of a workaround using `Xpetra::Matrix::replaceLocalValues()` with proper row and col addressing, i.e. col being an array with just a single entry, namely the row index.
## Related Issues
* Part of #4084
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4220Minitensor produces compiler warnings with nvidia compiler 2019-02-02T15:43:50ZJames WillenbringMinitensor produces compiler warnings with nvidia compiler *Created by: khpierson*
There are a number of warnings coming from the Trilinos package: MiniTensor.
The Sierra team would like these removed by the next Trilinos integration.
Would that be possible?
Thanks,
-Kendall
Here is ...*Created by: khpierson*
There are a number of warnings coming from the Trilinos package: MiniTensor.
The Sierra team would like these removed by the next Trilinos integration.
Would that be possible?
Thanks,
-Kendall
Here is a list of some of the warnings, note, I would expect Trilinos to already be seeing these warnings when building with nvidia (provided our compiler flags are the same across SIERRA and Trilinos.
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_Utilities.i.h(280): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_Utilities.i.h(283): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_Utilities.i.h(286): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_Utilities.i.h(289): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_Utilities.i.h(295): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_LinearAlgebra.t.h(112): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_LinearAlgebra.t.h(120): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_LinearAlgebra.t.h(124): warning #111-D: statement is unreachable
/sierra/dev/continuous_integration/frame02/sierra.code/TPLs_src/Trilinos_flat_headers/include/MiniTensor_LinearAlgebra.t.h(164): warning #111-D: statement is unreachablehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4208ShyLu/FROSch: improve run-time error in case of missing packages2019-02-18T16:38:11ZJames WillenbringShyLu/FROSch: improve run-time error in case of missing packages*Created by: mayrmt*
@trilinos/shylu
@searhein
## Expectations
Provide a more meaningful error message in case that a certain (optional) Trilinos package has been chosen as subdomain solver, but is not included into the build con...*Created by: mayrmt*
@trilinos/shylu
@searhein
## Expectations
Provide a more meaningful error message in case that a certain (optional) Trilinos package has been chosen as subdomain solver, but is not included into the build configuration.
## Current Behavior
I'm attempting to use MueLu as coarse solver for FROSch's GDSW preconditioner. This requires the cmake option `-D ShyLU_DDFROSch_ENABLE_MueLu:BOOL=ON`. However, without this option the subdomain solver is not recognized and the error message is just `FROSCH_ASSERT(false,"SolverType unknown...");`.
Taking MueLu as an example as implemented [here](https://github.com/trilinos/Trilinos/blob/develop/packages/shylu/shylu_dd/frosch/src/Tools/FROSch_SubdomainSolver_def.hpp#L123):
```
#ifdef HAVE_SHYLU_DDFROSCH_MUELU
} else if (!ParameterList_->get("SolverType","Amesos").compare("MueLu")) {
// ... calling MueLu setup here ...
}
#endif
else {
FROSCH_ASSERT(false,"SolverType unknown...");
}
```
The check, whether `"MueLu"` has been set as `"SolverType"` in the parameter list is already guarded by `#ifdef HAVE_SHYLU_DDFROSCH_MUELU`, so we can't tell the user that MueLu is required, but not enabled by the build configuration.
## Motivation and Context
Telling the user that a package is required, but has not been enabled in the build configuration helps to figure out, why an error occurs and points to possible solutions.
## Definition of Done
- [ ] Improve error message such that it contains details about missing packages.
## Possible Solution
We could move the `#ifdef HAVE_SHYLU_DDFROSCH_MUELU` inside the parameter check. This detects that MueLu has been asked for, but is not enabled. We can throw an error then that contains much more details. Maybe something along the lines of:
```
} else if (!ParameterList_->get("SolverType","Amesos").compare("MueLu")) {
#ifdef HAVE_SHYLU_DDFROSCH_MUELU
// ... calling MueLu setup here ...
#else
FROSCH_ASSERT(false, "SolverType is chosen as MueLu, but MueLu is not enabled to work with FROSch. Modify your build configuration to enable MueLu inside ShyLU_DDFROSch!
#endif
}
else {
FROSCH_ASSERT(false,"SolverType unknown...");
}
```
## Steps to Reproduce
1. Disable MueLu inside FROSch by setting `-D ShyLU_DDFROSch_ENABLE_MueLu:BOOL=OFF` in the configure script
1. Set the coarse solver's `"SolverType"` to `"MueLu"`
1. Run any test based on `ShyLU_DDFROSch_thyra_xpetra_laplace.exe`.
## Additional Information
I described the issue for MueLu here, but a similar strategy could be applied to all other package dependencies, namely Amesos, Amesos2, and Belos.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4199Tpetra: CrsMatrix NonlocalAfterResume test fails2019-01-19T22:42:04ZJames WillenbringTpetra: CrsMatrix NonlocalAfterResume test fails*Created by: mhoemmen*
@trilinos/tpetra @kddevin
I'm working on a fix for this.
## Current Behavior
`Tpetra::CrsMatrix`'s "NonlocalAfterResume" test is failing for me, on GCC 4.9.3 with OpenMPI 1.10.1 and OpenMP enabled. It lo...*Created by: mhoemmen*
@trilinos/tpetra @kddevin
I'm working on a fix for this.
## Current Behavior
`Tpetra::CrsMatrix`'s "NonlocalAfterResume" test is failing for me, on GCC 4.9.3 with OpenMPI 1.10.1 and OpenMP enabled. It looks like something is attempting to create a `Teuchos::ArrayView` with nonnull pointer and zero length. `Teuchos::ArrayView`'s constructor forbids this in debug mode.
## Motivation and Context
I discovered this while working on a fix for #4194.
## Possible Solution
Fix `getArrayViewFromDualView` in `tpetra/core/src/Tpetra_Util.hpp`, so that it replaces the pointer with `nullptr` if the length is zero. Kokkos no longer promises that the result of `.data()` is nonnull if the pointer is nonnull. See the now closed Kokkos issue https://github.com/kokkos/kokkos/issues/1870 for details.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4194Amesos2 tests don't build with ETI OFF2019-01-28T16:55:30ZJames WillenbringAmesos2 tests don't build with ETI OFF*Created by: mhoemmen*
@trilinos/amesos2
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documenta...*Created by: mhoemmen*
@trilinos/amesos2
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
- [ ] First do this.
- [ ] Then do that.
- [ ] Also this other thing.
-->
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant repo SHA1s:**
- **Relevant configure flags or configure script:**
- **Operating system and version:**
- **Compiler and TPL versions:**
## Related Issues
<!---
If applicable, let us know how this bug is related to any other open issues:
-->
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to
* Part of
* Composed of
## Additional Information
<!---
Anything else that might be helpful for us to know in addressing this issue:
* Configure log file:
* Build log file:
* Test log file:
* When was the last time everything worked (date/time; SHA1s; etc.)?
* What did you do that made the bug rear its ugly head?
* Have you tried turning it off and on again?
-->
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4190Enable Kokkos profiling cmake options by default in ATDM configurations2019-01-15T12:41:12ZJames WillenbringEnable Kokkos profiling cmake options by default in ATDM configurations*Created by: jhux2*
I would like to request that the two options
```
-D Kokkos_ENABLE_Profiling=ON
-D Teuchos_KOKKOS_PROFILING:BOOL=ON
```
be added to the various ATDM cmake configurations. These are required to get useful informa...*Created by: jhux2*
I would like to request that the two options
```
-D Kokkos_ENABLE_Profiling=ON
-D Teuchos_KOKKOS_PROFILING:BOOL=ON
```
be added to the various ATDM cmake configurations. These are required to get useful information from the Kokkos profiling tools. These are currently set to `OFF` by the ATDM configuration script (at least on waterman).
This means that after I do
```
source $TRILINOS_DIR/cmake/std/atdm/load-env.sh
```
I also have to remember to enable both options in my configure script.
From what I understand, having the two options `ON` by default will have negligible impact on performance *unless* you explicitly start profiling using the Kokkos tools.
@trilinos/framework
@srajama1 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4186Tpetra: BlockCrsMatrix packAndPrepareNew build error with complex enabled2019-01-16T17:41:54ZJames WillenbringTpetra: BlockCrsMatrix packAndPrepareNew build error with complex enabled*Created by: mhoemmen*
I’ll fix it. Am typing on a phone.
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "Pac...*Created by: mhoemmen*
I’ll fix it. Am typing on a phone.
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/tpetra @kyungjoo-kim
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
- [ ] First do this.
- [ ] Then do that.
- [ ] Also this other thing.
-->
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant repo SHA1s:**
- **Relevant configure flags or configure script:**
- **Operating system and version:**
- **Compiler and TPL versions:**
## Related Issues
<!---
If applicable, let us know how this bug is related to any other open issues:
-->
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to
* Part of
* Composed of
## Additional Information
<!---
Anything else that might be helpful for us to know in addressing this issue:
* Configure log file:
* Build log file:
* Test log file:
* When was the last time everything worked (date/time; SHA1s; etc.)?
* What did you do that made the bug rear its ugly head?
* Have you tried turning it off and on again?
-->
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4173MueLu: StructuredAggregation, improve prolongator graph2019-01-19T21:40:56ZJames WillenbringMueLu: StructuredAggregation, improve prolongator graph*Created by: lucbv*
@trilinos/muelu
## Expectations
The prolongator graph computed by the structured aggregation factory should be directly usable to construct the prolongator. For this to work we need to take into account how many...*Created by: lucbv*
@trilinos/muelu
## Expectations
The prolongator graph computed by the structured aggregation factory should be directly usable to construct the prolongator. For this to work we need to take into account how many dofs per node the problem has.
## Current Behavior
The structured aggregation factory can compute the graph of the prolongator however it does it correctly only for the scalar PDE case. The prolongator factory then has to recreate a graph taking into account multiple dofs per node.
## Motivation and Context
This will cut redundant work happening in aggregation and prolongator computation, thus improving performance. Also directly computing the prolongator graph means that if one wants to reset the MueLu preconditioner using reuse, aggregation will be skipped completely.
## Definition of Done
1. declare `dofsPerNode` an input parameter in StructuredAggregationFactory
2. modify the prolongatorGraph computation such that it can be used by the prolongator constructorhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4174Many (50-80) Panzer tests failing on all ATDM cuda builds2019-01-21T21:01:52ZJames WillenbringMany (50-80) Panzer tests failing on all ATDM cuda builds*Created by: fryeguy52*
CC: @trilinos/panzer, @mperego (Trilinos Discretizations Product Lead), @bartlettroscoe, @fryeguy52
## Next Action Status
<status-and-or-first-action>
## Description
As shown in [this query](https://...*Created by: fryeguy52*
CC: @trilinos/panzer, @mperego (Trilinos Discretizations Product Lead), @bartlettroscoe, @fryeguy52
## Next Action Status
<status-and-or-first-action>
## Description
As shown in [this query](https://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=4&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm&field2=buildname&compare2=63&value2=cuda&field3=buildstarttime&compare3=83&value3=2019-01-11&field4=buildstarttime&compare4=84&value4=2019-01-12) about half of the Panzer tests started failing on 2019-01-11 on all the cuda 9.2 ATDM builds the failures are too numerous to list here but the largest groups are:
* `PanzerAdaptersSTK_*`
* ` PanzerDiscFE_*`
* ` PanzerDofMgr_*`
* ` PanzerMiniEM_MiniEM-BlockPrec_*`
the affected builds are:
* Trilinos-atdm-waterman-cuda-9.2-debug
* Trilinos-atdm-waterman-cuda-9.2-opt
* Trilinos-atdm-waterman-cuda-9.2-release-debug
* Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-debug
* Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-release
* Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-release-debug
the tests are failing with segmentation faults
```
0. tFilteredUGI_equivalence_test_UnitTest ... --------------------------------------------------------------------------
mpiexec noticed that process rank 0 with PID 0 on node white22 exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------
```
@rppawlo there were a couple new commits that touched panzer files that you made yesterday. Can you see if these are what caused the new failures?
```
cf5e5a3: Panzer: hack for gcc 4.8 compiler
1333649: Panzer: fix all shadow warnings
```
## Current Status of these builds on CDash
The status of these builds for the current testing day can be found at:
https://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercombine=and&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm&field2=buildname&compare2=63&value2=cuda
## Steps to Reproduce
One should be able to reproduce this failure on ride or white as described in:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md
More specifically, the commands given for ride or white are provided at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#ridewhite
The exact commands to reproduce this issue should be:
```
$ cd <some_build_dir>/
$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh Trilinos-atdm-white-ride-cuda-9.2-gnu-7.2.0-release
$ cmake \
-GNinja \
-DTrilinos_CONFIGURE_OPTIONS_FILE:STRING=cmake/std/atdm/ATDMDevEnv.cmake \
-DTrilinos_ENABLE_TESTS=ON -DTrilinos_ENABLE_Panzer=ON \
$TRILINOS_DIR
$ make NP=16
$ bsub -x -Is -q rhel7F -n 16 ctest -j16
```
Keep promoted "ATDM" builds of Trilinos cleanhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4169Tempus: FPEs caused by use of std::numeric_limits::max()2019-01-18T17:47:52ZJames WillenbringTempus: FPEs caused by use of std::numeric_limits::max()*Created by: ccober6*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
EMPIRE identified FPE...*Created by: ccober6*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
EMPIRE identified FPEs in Tempus when using std::numeric_limits::max() to initialize variables with a default value.
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/tempus
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
Should be able to run without FPEs.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Replace std::numeric_limits::max() with "reasonable" large default values.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4133Amesos2 using "amesos2_cholmod" solver generates wrong results2019-01-04T04:59:27ZJames WillenbringAmesos2 using "amesos2_cholmod" solver generates wrong results*Created by: davoodansari*
Hi everyone
Spent some time compiling metis, chomod and on top of that trilinos (amesos2 with cholmod enabled).
Then I modified one of the examples to see if the "amesos2_cholmod" solver is actually accessib...*Created by: davoodansari*
Hi everyone
Spent some time compiling metis, chomod and on top of that trilinos (amesos2 with cholmod enabled).
Then I modified one of the examples to see if the "amesos2_cholmod" solver is actually accessible.
To my surpride, the solver generates wrong results, i.e. [-2.88889; 2.25; -5.66667; 3.4; 3.77778; 4.66667] instead of [1 2 3 4 5 6]. Below is the code and the actual output. Any ideas what can be wrong?
Any advice is highly appreciated
Thanks
output:
--------------------------------------------------
Kokkos::OpenMP::initialize WARNING: OMP_PROC_BIND environment variable not set
In general, for best performance with OpenMP 4.0 or better set OMP_PROC_BIND=spread and OMP_PLACES=threads
For best performance with OpenMP 3.1 set OMP_PROC_BIND=true
For unit testing set OMP_PROC_BIND=false
Amesos2 using 3P solver: amesos2_cholmod
Amesos2 version 0.3d - 07/28/2011
code:
--------------------------------------------------
Solution :
"Tpetra::MultiVector":
Template parameters:
Scalar: double
LocalOrdinal: int
GlobalOrdinal: int
Node: Serial/Wrapper
Global number of rows: 6
Number of columns: 1
Process 0 of 1:
Local number of rows: 6
Column stride: 6
Values:
[-2.88889; 2.25; -5.66667; 3.4; 3.77778; 4.66667]
int main(int argc, char *argv[])
{
Tpetra::ScopeGuard tpetraScope(&argc,&argv);
typedef double Scalar;
typedef Tpetra::Map<>::local_ordinal_type LO;
typedef Tpetra::Map<>::global_ordinal_type GO;
typedef Tpetra::CrsMatrix<Scalar,LO,GO> MAT;
typedef Tpetra::MultiVector<Scalar,LO,GO> MV;
using Tpetra::global_size_t;
using Teuchos::tuple;
using Teuchos::RCP;
using Teuchos::rcp;
const int s=9;
const char* solverNames[10] = {"shylubasker", "basker", "klu2", "superlu_dist", "superlu_mt", "superlu", "pardiso_mkl", "lapack", "mumps", "amesos2_cholmod"};
// Before we do anything, check that SuperLU is enabled
if( !Amesos2::query(solverNames[s]) )
{
std::cerr << solverNames[s] << " not enabled. Exiting..." << std::endl;
return EXIT_SUCCESS; // Otherwise CTest will pick it up as failure, which it isn't really
}
else std::cout << "Amesos2 using 3P solver: " << solverNames[s] << std::endl;
Teuchos::RCP<const Teuchos::Comm<int> > comm = Tpetra::getDefaultComm();
size_t myRank = comm->getRank();
std::ostream &out = std::cout;
out << Amesos2::version() << std::endl << std::endl;
const size_t numVectors = 1;
// create a Map
global_size_t nrows = 6;
RCP<Tpetra::Map<LO,GO> > map = rcp( new Tpetra::Map<LO,GO>(nrows,0,comm) );
RCP<MAT> A = rcp( new MAT(map,3) ); // max of three entries in a row
/*
* We will solve a system with a known solution, for which we will be using
* the following matrix:
*
* [ [ 7, 0, -3, 0, -1, 0 ]
* [ 2, 8, 0, 0, 0, 0 ]
* [ 0, 0, 1, 0, 0, 0 ]
* [ -3, 0, 0, 5, 0, 0 ]
* [ 0, -1, 0, 0, 4, 0 ]
* [ 0, 0, 0, -2, 0, 6 ] ]
*
*/
// Construct matrix
if( myRank == 0 )
{
A->insertGlobalValues(0,tuple<GO>(0,2,4),tuple<Scalar>(7,-3,-1));
A->insertGlobalValues(1,tuple<GO>(0,1),tuple<Scalar>(2,8));
A->insertGlobalValues(2,tuple<GO>(2),tuple<Scalar>(1));
A->insertGlobalValues(3,tuple<GO>(0,3),tuple<Scalar>(-3,5));
A->insertGlobalValues(4,tuple<GO>(1,4),tuple<Scalar>(-1,4));
A->insertGlobalValues(5,tuple<GO>(3,5),tuple<Scalar>(-2,6));
}
A->fillComplete();
// Create random X
RCP<MV> X = rcp(new MV(map,numVectors));
//X->randomize();
/* Create B
*
* Use RHS:
*
* [[-7]
* [18]
* [ 3]
* [17]
* [18]
* [28]]
*/
RCP<MV> B = rcp(new MV(map,numVectors));
int data[6] = {-7,18,3,17,18,28};
for( int i = 0; i < 6; ++i )
{
if( B->getMap()->isNodeGlobalElement(i) )
{
B->replaceGlobalValue(i,0,data[i]);
}
}
// Create solver interface to Superlu with Amesos2 factory method
RCP<Amesos2::Solver<MAT,MV> > solver = Amesos2::create<MAT,MV>(solverNames[s], A, X, B);
solver->symbolicFactorization().numericFactorization().solve();
/* Print the solution
*
* Should be:
*
* [[1]
* [2]
* [3]
* [4]
* [5]
* [6]]
*/
RCP<Teuchos::FancyOStream> fos = Teuchos::fancyOStream(Teuchos::rcpFromRef(out));
*fos << "Solution :" << std::endl;
X->describe(*fos,Teuchos::VERB_EXTREME);
*fos << std::endl;
// We are done.
return 0;
}
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4119Teuchos: StackedTimer missing a pushRegion for kokkos profiling2019-01-07T17:42:18ZJames WillenbringTeuchos: StackedTimer missing a pushRegion for kokkos profiling*Created by: jewatkins*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that ...*Created by: jewatkins*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/teuchos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
StackedTimer should work with kokkos profiling tools
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
space time stack throws a seg fault because there's no pushRegion in the top level timer
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
Removing the stacked timer or changing the kokkos profiler to run a profile is not practical. It's better to fix the stacked timer.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Unless I'm mistaken, it's currently only possible to start the top level timer via the constructor of StackedTimer. Either the constructor needs a pushRegion or the user should be able to start the top level timer explicitly (start() has a pushRegion).
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
I think any code with the stacked timer should segfault if run with kokkos profiling tools
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4150Using magnitudeType for coordinates in MueLu2019-01-12T03:56:30ZJames WillenbringUsing magnitudeType for coordinates in MueLu*Created by: etphipp*
@trilinos/muelu @kliegeois
MueLu developers,
I have a student, @kliegeois, working on a modification of one of Stokhos' scalar types that changes Teuchos::ScalarTraits::magnitudeType to something other than ...*Created by: etphipp*
@trilinos/muelu @kliegeois
MueLu developers,
I have a student, @kliegeois, working on a modification of one of Stokhos' scalar types that changes Teuchos::ScalarTraits::magnitudeType to something other than a builtin type, and we are running into many issues in MueLu, where magnitudeType is feely converted to/from double. The issue seems to be that the interface for mesh coordinates takes vectors of magnitudeType, but the implementation often assigns these values to double types. We started converting most of this code to use magnitudeType throughout, but this is becoming untenable and we are wondering what the right path forward is.
It seems to me that using magnitudeType for coordinates is something of an abuse of what magnitudeType is supposed to represent, since it is supposed to represent magnitudes (i.e., real, non-negative numbers). What would you think of introducing a new type trait for coordinates that would compute the coordinate type from the scalar type, but be divorced from magnitudeType? This could be done using Teuchos::ScalarTraits (e.g., Teuchos::ScalarTraits::coordinateType), or MueLu could introduce its own trait, something like:
```
// Default implementation where CoordinateTraits<Scalar>::type == Scalar
template <class Scalar>
struct CoordinateTraits {
typedef Scalar type;
};
// Specialization for std::complex<>
template <class T> {
struct CoordinateTraits< std::complex<T> > {
typedef T type;
};
```
Then Stokhos would then provide its own specialization where CoordinateTraits<>::type is a builtin type.
To me, this seems like the right way to do this. If someone wanted to use, e.g., extended precision types, then magnitudeType would be extended precision (and therefore not safely convertible to double), but it seems very unlikely that anyone would want the coordinate type to be extended precision.