Trilinos merge requestshttps://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests2019-05-07T03:24:16Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests/5118Tpetra: Attempt to Fix #51172019-05-07T03:24:16ZJames WillenbringTpetra: Attempt to Fix #5117*Created by: mhoemmen*
@trilinos/tpetra
## Description
First attempt at fixing #5117. NOT ALL THE TESTS PASS with the current changes! The following TpetraCore tests still fail:
```
35 - TpetraCore_CrsGraph_UnitTests0_MPI_4...*Created by: mhoemmen*
@trilinos/tpetra
## Description
First attempt at fixing #5117. NOT ALL THE TESTS PASS with the current changes! The following TpetraCore tests still fail:
```
35 - TpetraCore_CrsGraph_UnitTests0_MPI_4 (Failed)
51 - TpetraCore_CrsMatrix_NonlocalAfterResume_MPI_4 (Failed)
62 - TpetraCore_CrsMatrix_Bug6171_MPI_2 (Failed)
72 - TpetraCore_Albany182_MPI_4 (Failed)
97 - TpetraCore_ImportExport2_UnitTests_MPI_4 (Failed)
99 - TpetraCore_MatrixMarket_Tpetra_CrsMatrix_InOutTest_MPI_4 (Failed)
100 - TpetraCore_MatrixMarket_Tpetra_CrsGraph_InOutTest_MPI_4 (Failed)
101 - TpetraCore_MatrixMarket_Operator_Test_MPI_4 (Failed)
132 - TpetraCore_MatrixMatrix_UnitTests_MPI_4 (Failed)
133 - TpetraCore_AddProfiling_UnitTests_MPI_4 (Failed)
135 - TpetraCore_MultiVector_UnitTests_MPI_4 (Failed)
161 - TpetraCore_RowMatrixTransposer_test_MPI_4 (Failed)
171 - TpetraCore_lesson05_redistribution_MPI_4 (Failed)
175 - TpetraCore_FEMAssembly_InsertGlobalIndicesDP_MPI_4 (Failed)
176 - TpetraCore_FEMAssembly_LocalElementLoopDP_MPI_4 (Failed)
177 - TpetraCore_FEMAssembly_TotalElementLoopDP_MPI_4 (Failed)
189 - TpetraCore_guide_power_method_1_MPI_4 (Failed)
190 - TpetraCore_guide_matrix_fill_1_MPI_4 (Failed)
193 - TpetraCore_guide_data_redist_1_MPI_4 (Failed)
```
## Related Issues
* Closes #5117
https://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests/5115Tpetra: "New RTI" (Reduction Transform Interface), Part 1 (for_each, transform)2019-05-07T08:30:28ZJames WillenbringTpetra: "New RTI" (Reduction Transform Interface), Part 1 (for_each, transform)*Created by: mhoemmen*
@trilinos/tpetra
## Description
Tpetra once had something called the Reduction Transform Interface (RTI). It let users apply a function to each entry of one or two (or three, I think) `Tpetra::Vector`s, an...*Created by: mhoemmen*
@trilinos/tpetra
## Description
Tpetra once had something called the Reduction Transform Interface (RTI). It let users apply a function to each entry of one or two (or three, I think) `Tpetra::Vector`s, and then possibly end with a reduction over the output Vector.
This commit starts anew with RTI, by adding the following features:
1. `withLocalAccess`: Access the local data of a `Tpetra::)Multi)Vector` in a given memory space -- a declarative replacement for DualView-style functions
2. `for_each`: Works like `std::for_each`, but for `Tpetra::(Multi)Vector`
3. `transform`: Works like unary or binary `std::transform`, but for `Tpetra::(Multi)Vector`
(2) and (3) use (1). All of these have extension points so that they can be adapted for other objects, such as CrsGraph or CrsMatrix.
## Motivation and Context
Users want to apply functions entrywise to a Vector or MultiVector. They want to get at the local data, and they want Tpetra to handle the sync and modify flag stuff for them. Tpetra wants the power to do things like lazy allocation (see #333) that go beyond what `Kokkos::DualView` allows. Tpetra wants to protect users from holding on to owning `Kokkos::View` that really belong to Tpetra objects, because that can cause bugs (e.g., if the mesh that produced the linear system has changed) and unnecessary memory usage.
## Next steps
1. Add `transform_reduce` (the "R" in "RTI")
2. Think about how to do kernel fusion with a mixture of Vector and CrsMatrix (or at least provide a "residual" interface)
## Related Issues
* Closes: #3471
* Related to #333, #364, #381, #415, #768, #1424, #1896https://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests/4918Tpetra: Adding Dirichlet condition helper routine2019-04-24T15:53:31ZJames WillenbringTpetra: Adding Dirichlet condition helper routine*Created by: csiefer2*
Auto-PR for SHA 6c3776f*Created by: csiefer2*
Auto-PR for SHA 6c3776fhttps://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests/4782WIP Tpetra: persistent MPI requests2019-04-04T16:31:51ZJames WillenbringWIP Tpetra: persistent MPI requests*Created by: cgcgcg*
@trilinos/tpetra
## Description
This PR adds the option to use persistent MPI communication in Tpetra. The defaults communication option is not changed. I tested this using MueLu, where this can be switched on ...*Created by: cgcgcg*
@trilinos/tpetra
## Description
This PR adds the option to use persistent MPI communication in Tpetra. The defaults communication option is not changed. I tested this using MueLu, where this can be switched on for the solve phase only. There are probably quite a lot of cases where this will not work correctly, so I appreciate feedback! https://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests/4620Tpetra MV: Use specialized KokkosBlas::dot in multiply()2019-03-18T23:33:14ZJames WillenbringTpetra MV: Use specialized KokkosBlas::dot in multiply()*Created by: cgcgcg*
@trilinos/tpetra
## Description
Use a specialized KokkosKernels function in `multiply` when either one of the two factors has only one column.*Created by: cgcgcg*
@trilinos/tpetra
## Description
Use a specialized KokkosKernels function in `multiply` when either one of the two factors has only one column.https://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests/3581Tpetra::Distributor: Fix #35802019-01-23T23:40:53ZJames WillenbringTpetra::Distributor: Fix #3580*Created by: mhoemmen*
@trilinos/tpetra @jjellio
## Description
Fix #3580, by making all instances of the "slow path" in Distributor use a buffer long enough for all the messages, not just one at a time. Ignore the "Send type" a...*Created by: mhoemmen*
@trilinos/tpetra @jjellio
## Description
Fix #3580, by making all instances of the "slow path" in Distributor use a buffer long enough for all the messages, not just one at a time. Ignore the "Send type" and "Barrier between..." options, and always use `MPI_Isend` for sends.
* Closes #3580
## How Has This Been Tested?
Mac, Clang, OpenMPI.https://gitlab.osti.gov/jmwille/Trilinos/-/merge_requests/3398(WIP) Tpetra: Remove template parameters2018-09-11T17:56:43ZJames Willenbring(WIP) Tpetra: Remove template parameters*Created by: mhoemmen*
@trilinos/tpetra
**THIS IS A WORK IN PROGRESS.** Please don't merge this yet.
## Description
Start removing the LocalOrdinal, GlobalOrdinal, and Node template parameters from Tpetra. **THIS IS A WORK I...*Created by: mhoemmen*
@trilinos/tpetra
**THIS IS A WORK IN PROGRESS.** Please don't merge this yet.
## Description
Start removing the LocalOrdinal, GlobalOrdinal, and Node template parameters from Tpetra. **THIS IS A WORK IN PROGRESS.** I've added new versions of the following classes that no longer have any of these template parameters:
- Details::Directory and subclasses
- Directory
- Map
- ImportExportData
- Transfer
- Export
- Import
I wanted these classes to build alongside the current Tpetra classes, so I could test and compare them, and have a gradual porting path. (Note use of `::Tpetra` to pull in enums etc. from the Tpetra namespace, that I didn't want to duplicate. My goal is to avoid duplication whenever possible.) To prevent namespace drama, all new classes live in an entirely new namespace (TpetraNew), that is not nested in the Tpetra namespace.
I currently have tests for Map and Directory. The tests build and pass on my laptop. Testing Export and Import will take a bit more work, since very few of the current tests for these classes work in isolation. (Most of them depend on MultiVector, Vector, etc. and exercise DistObject.)
This was not very hard to do; it was mostly just tedious. The most important change is that the "decl" and "def" header files go away. Instead, there's a true header file (e.g., `Tpetra_Map.hpp`) and a .cpp file that actually has the implementation in it (no more explicit template instantiation (ETI)). We will still need ETI machinery for classes templated on Scalar or Packet, but we will be able to simplify the CMake logic for ETI quite a bit.
## Next steps
The next class to convert is DistObject. That will be the first class to convert that will retain a template parameter (Packet).
I can defer changing Distributor, since it does not depend on the usual three template parameters; however, I have some future plans to hide Distributor's implementation that I can discuss elsewhere.
After DistObject will come RowGraph and CrsGraph. After those, will come Operator, then all of the other DistObject subclasses and the various functions that work with them. (The latter two will need to happen simultaneously -- e.g., for nonmember functions that work on CrsMatrix.)
## Risks
1. _Build size and time increase_: We could avoid this by making TpetraNew a new Tpetra subpackage. That way, it would be a separate library, and users could avoid linking to it.
2. _Merging with other work_, such as @DrBooom 's incoming changes.
3. _Huge amount of work downstream_ to use this: We could mitigate and make this a gradual porting exercise with conversion functions, e.g., between old and new versions of the same data structure.
## Related Issues
* Closes #57, #2548