8000 Add sparse direct interface by upsj · Pull Request #1082 · ginkgo-project/ginkgo · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add sparse direct interface #1082

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Nov 4, 2022
Merged

Add sparse direct interface #1082

merged 13 commits into from
Nov 4, 2022

Conversation

upsj
Copy link
Member
@upsj upsj commented Jul 18, 2022

This adds an interface to the existing numerical LU and symbolic Cholesky factorization kernel, producing a common Factorization type that can represent all factorizations based on triangular matrices, and a new interface that wraps two triangular solvers initialized from such a Factorization.

Depends on #1171

@upsj upsj added the 1:ST:WIP This PR is a work in progress. Not ready for review. label Jul 18, 2022
@upsj upsj added this to the Ginkgo 1.5.0 milestone Jul 18, 2022
@upsj upsj self-assigned this Jul 18, 2022
@ginkgo-bot ginkgo-bot added mod:all This touches all Ginkgo modules. reg:build This is related to the build system. reg:testing This is related to testing. type:factorization This is related to the Factorizations type:solver This is related to the solvers labels Jul 18, 2022
@upsj upsj force-pushed the numeric_direct_solve branch 2 times, most recently from 9c6e422 to b4be3c5 Compare July 19, 2022 19:07
@upsj upsj force-pushed the sparse_direct_interface branch from 615668c to aa29354 Compare July 19, 2022 19:24
@upsj upsj force-pushed the numeric_direct_solve branch from b4be3c5 to 9ab2e2b Compare July 19, 2022 19:28
@upsj upsj force-pushed the sparse_direct_interface branch from aa29354 to 2b0f8e9 Compare July 19, 2022 19:48
@upsj upsj requested review from a team July 19, 2022 19:49
@upsj upsj added 1:ST:need-feedback The PR is somewhat ready but feedback on a blocking topic is required before a proper review. and removed 1:ST:WIP This PR is a work in progress. Not ready for review. labels Jul 19, 20 8000 22
Comment on lines +103 to +111
using lower_type = gko::solver::LowerTrs<value_type, index_type>;
using upper_type = gko::solver::UpperTrs<value_type, index_type>;

std::unique_ptr<lower_type> lower_solver_;
std::unique_ptr<upper_type> upper_solver_;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just from the language side, this assumes that the direct solver uses some form of LU/Cholesky decomposition. Technically, a QR decomposition would also fit as a direct solver. But the naming of the two factors is ill-suited in that case. Naming-wise, I think using left_solver_ and right_solver_ might be better. I know that we are not considering that case, so this is just a remark that should at some point be noted somewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great point! Do you think Factorization should also be able to store things like QR factorizations/SVD decompositions or similar? I think that may overload them too much. Are sparse QR solvers of practical importance?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Factorization would get too overloaded, atm I feel like it's right at the border. I don't know if sparse QR is relevant for us, perhaps @vasilisge0 knows more about that.

Copy link
Member
@MarcelKoch MarcelKoch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interface-wise I think it looks good. The only discussion point might be the Factorization. I guess using enums for the different types factorizations, instead of something like an abstract interface + implementations, is fine, since we won't add other factorizations in the foreseeable future. Also, I'm not sure about the storage_type as I've stated.

The only real issue I have is that there seem to be no reference tests, but you still compare to that.

@ginkgo-bot ginkgo-bot force-pushed the numeric_direct_solve branch from baa0eeb to 81f0a5d Compare July 22, 2022 11:14
Base automatically changed from numeric_direct_solve to develop July 22, 2022 11:15
@upsj upsj force-pushed the sparse_direct_interface branch from 2b0f8e9 to dd50ed4 Compare August 6, 2022 18:00
@upsj upsj requested a review from MarcelKoch August 6, 2022 18:00
@upsj upsj force-pushed the sparse_direct_interface branch 2 times, most recently from c5ad4b7 to 6010d7e Compare August 6, 2022 18:03
@tcojean tcojean requested review from fritzgoebel and tcojean August 23, 2022 13:37
@tcojean tcojean added the 1:ST:high-importance This issue/PR is of high importance and must be addressed as soon as possible. label Aug 23, 2022
Copy link
Collaborator
@fritzgoebel fritzgoebel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice work!

Copy link
Collaborator
@fritzgoebel fritzgoebel left a comment

Choose a reason for hiding this comment

The reason will be dis 8000 played to describe this comment to others. Learn more.

LGTM, the headers could use some documentation for LU and the direct solver.
For the direct solver, the triangular solvers are using the sparselib strategy by default, for matrices where the sync-free factorization works well, the sync-free triangular solves might also work well though, so maybe that could be made configurable?

Copy link
Member
@MarcelKoch MarcelKoch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've only some smaller nits.

Since you created an issue for discussing the improvement of factory parameters, I would suggest that you use here again our 'old' approach to them. I don't think we should mix in discussing the factory parameters into this PR. But that is nothing to hold up this PR.

@upsj
Copy link
Member Author
upsj commented Nov 3, 2022

@MarcelKoch the only macros I could actually use would be GKO_FACTORY_PARAM_*, the others make assumptions that are not valid here. Would that be sufficient until we resolve #1162 ?

@MarcelKoch
Copy link
Member

@upsj sorry for being vague there, yes that is exactly what I meant.

@tcojean
Copy link
Member
tcojean commented Nov 3, 2022

This seems to be hitting the 0:45 job timeout on HoreKa now. Maybe we should increase to 1h. https://gitlab.com/ginkgo-project/ginkgo-public-ci/-/jobs/3269009595.

@upsj upsj force-pushed the sparse_direct_interface branch 2 times, most recently from 99f0b23 to 836234b Compare November 3, 2022 19:49
@upsj upsj added 1:ST:ready-to-merge This PR is ready to merge. and removed 1:ST:need-feedback The PR is somewhat ready but feedback on a blocking topic is required before a proper review. labels Nov 3, 2022
@sonarqubecloud
Copy link
sonarqubecloud bot commented Nov 4, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 49 Code Smells

61.8% 61.8% Coverage
3.8% 3.8% Duplication

@ginkgo-bot
F438 Copy link
Member

Note: This PR changes the Ginkgo ABI:

Functions changes summary: 0 Removed, 0 Changed, 3350 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

For details check the full ABI diff under Artifacts here

@upsj
Copy link
Member Author
upsj commented Nov 4, 2022

rebase!

upsj and others added 13 commits November 4, 2022 19:33
- add/improve comments
- fix formatting
- make constructors explicit

Co-authored-by: Marcel Koch <marcel.koch@kit.edu>
* test factorization apply
* clarify documentation

Co-authored-by: Yu-Hsiang M. Tsai <yhmtsai@gmail.com>
Co-authored-by: Marcel Koch <marcel.koch@kit.edu>
- add comments
- remove unnecessary type aliases
- fix friend declarations

Co-authored-by: Marcel Koch <marcel.koch@kit.edu>
Co-authored-by: Fritz Göbel <fritz.goebel@kit.edu>
@ginkgo-bot ginkgo-bot force-pushed the sparse_direct_interface branch from 0f53e98 to 33f4889 Compare November 4, 2022 19:33
@upsj upsj merged commit 18606f1 into develop Nov 4, 2022
@upsj upsj deleted the sparse_direct_interface branch November 4, 2022 19:36
@ginkgo-bot
Copy link
Member

Error: PR already merged!

tcojean pushed a commit that referenced this pull request Nov 12, 2022
Advertise release 1.5.0 and last changes

+ Add changelog,
+ Update third party libraries
+ A small fix to a CMake file

See PR: #1195

The Ginkgo team is proud to announce the new Ginkgo minor release 1.5.0. This release brings many important new features such as:
- MPI-based multi-node support for all matrix formats and most solvers;
- full DPC++/SYCL support,
- functionality and interface for GPU-resident sparse direct solvers,
- an interface for wrapping solvers with scaling and reordering applied,
- a new algebraic Multigrid solver/preconditioner,
- improved mixed-precision support,
- support for device matrix assembly,

and much more.

If you face an issue, please first check our [known issues page](https://github.com/ginkgo-project/ginkgo/wiki/Known-Issues) and the [open issues list](https://github.com/ginkgo-project/ginkgo/issues) and if you do not find a solution, feel free to [open a new issue](https://github.com/ginkgo-project/ginkgo/issues/new/choose) or ask a question using the [github discussions](https://github.com/ginkgo-project/ginkgo/discussions).

Supported systems and requirements:
+ For all platforms, CMake 3.13+
+ C++14 compliant compiler
+ Linux and macOS
  + GCC: 5.5+
  + clang: 3.9+
  + Intel compiler: 2018+
  + Apple LLVM: 8.0+
  + NVHPC: 22.7+
  + Cray Compiler: 14.0.1+
  + CUDA module: CUDA 9.2+ or NVHPC 22.7+
  + HIP module: ROCm 4.0+
  + DPC++ module: Intel OneAPI 2021.3 with oneMKL and oneDPL. Set the CXX compiler to `dpcpp`.
+ Windows
  + MinGW and Cygwin: GCC 5.5+
  + Microsoft Visual Studio: VS 2019
  + CUDA module: CUDA 9.2+, Microsoft Visual Studio
  + OpenMP module: MinGW or Cygwin.


Algorithm and important feature additions:
+ Add MPI-based multi-node for all matrix formats and solvers (except GMRES and IDR). ([#676](#676), [#908](#908), [#909](#909), [#932](#932), [#951](#951), [#961](#961), [#971](#971), [#976](#976), [#985](#985), [#1007](#1007), [#1030](#1030), [#1054](#1054), [#1100](#1100), [#1148](#1148))
+ Porting the remaining algorithms (preconditioners like ISAI, Jacobi, Multigrid, ParILU(T) and ParIC(T)) to DPC++/SYCL, update to SYCL 2020, and improve support and performance ([#896](#896), [#924](#924), [#928](#928), [#929](#929), [#933](#933), [#943](#943), [#960](#960), [#1057](#1057), [#1110](#1110),  [#1142](#1142))
+ Add a Sparse Direct interface supporting GPU-resident numerical LU factorization, symbolic Cholesky factorization, improved triangular solvers, and more ([#957](#957), [#1058](#1058), [#1072](#
C95D
1072), [#1082](#1082))
+ Add a ScaleReordered interface that can wrap solvers and automatically apply reorderings and scalings ([#1059](#1059))
+ Add a Multigrid solver and improve the aggregation based PGM coarsening scheme ([#542](#542), [#913](#913), [#980](#980), [#982](#982),  [#986](#986))
+ Add infrastructure for unified, lambda-based, backend agnostic, kernels and utilize it for some simple kernels ([#833](#833), [#910](#910), [#926](#926))
+ Merge different CUDA, HIP, DPC++ and OpenMP tests under a common interface ([#904](#904), [#973](#973), [#1044](#1044), [#1117](#1117))
+ Add a device_matrix_data type for device-side matrix assembly ([#886](#886), [#963](#963), [#965](#965))
+ Add support for mixed real/complex BLAS operations ([#864](#864))
+ Add a FFT LinOp for all but DPC++/SYCL ([#701](#701))
+ Add FBCSR support for NVIDIA and AMD GPUs and CPUs with OpenMP ([#775](#775))
+ Add CSR scaling ([#848](#848))
+ Add array::const_view and equivalent to create constant matrices from non-const data ([#890](#890))
+ Add a RowGatherer LinOp supporting mixed precision to gather dense matrix rows ([#901](#901))
+ Add mixed precision SparsityCsr SpMV support ([#970](#970))
+ Allow creating CSR submatrix including from (possibly discontinuous) index sets ([#885](#885), [#964](#964))
+ Add a scaled identity addition (M <- aI + bM) feature interface and impls for Csr and Dense ([#942](#942))


Deprecations and important changes:
+ Deprecate AmgxPgm in favor of the new Pgm name. ([#1149](#1149)).
+ Deprecate specialized residual norm classes in favor of a common `ResidualNorm` class ([#1101](#1101))
+ Deprecate CamelCase non-polymorphic types in favor of snake_case versions (like array, machine_topology, uninitialized_array, index_set) ([#1031](#1031), [#1052](#1052))
+ Bug fix: restrict gko::share to rvalue references (*possible interface break*) ([#1020](#1020))
+ Bug fix: when using cuSPARSE's triangular solvers, specifying the factory parameter `num_rhs` is now required when solving for more than one right-hand side, otherwise an exception is thrown ([#1184](#1184)).
+ Drop official support for old CUDA < 9.2 ([#887](#887))


Improved performance additions:
+ Reuse tmp storage in reductions in solvers and add a mutable workspace to all solvers ([#1013](#1013), [#1028](#1028))
+ Add HIP unsafe atomic option for AMD ([#1091](#1091))
+ Prefer vendor implementations for Dense dot, conj_dot and norm2 when available ([#967](#967)).
+ Tuned OpenMP SellP, COO, and ELL SpMV kernels for a small number of RHS ([#809](#809))


Fixes:
+ Fix various compilation warnings ([#1076](#1076), [#1183](#1183), [#1189](#1189))
+ Fix issues with hwloc-related tests ([#1074](#1074))
+ Fix include headers for GCC 12 ([#1071](#1071))
+ Fix for simple-solver-logging example ([#1066](#1066))
+ Fix for potential memory leak in Logger ([#1056](#1056))
+ Fix logging of mixin classes ([#1037](#1037))
+ Improve value semantics for LinOp types, like moved-from state in cross-executor copy/clones ([#753](#753))
+ Fix some matrix SpMV and conversion corner cases ([#905](#905), [#978](#978))
+ Fix uninitialized data ([#958](#958))
+ Fix CUDA version requirement for cusparseSpSM ([#953](#953))
+ Fix several issues within bash-script ([#1016](#1016))
+ Fixes for `NVHPC` compiler support ([#1194](#1194))


Other additions:
+ Simplify and properly name GMRES kernels ([#861](#861))
+ Improve pkg-config support for non-CMake libraries ([#923](#923), [#1109](#1109))
+ Improve gdb pretty printer ([#987](#987), [#1114](#1114))
+ Add a logger highlighting inefficient allocation and copy patterns ([#1035](#1035))
+ Improved and optimized test random matrix generation ([#954](#954), [#1032](#1032))
+ Better CSR strategy defaults ([#969](#969))
+ Add `move_from` to `PolymorphicObject` ([#997](#997))
+ Remove unnecessary device_guard usage ([#956](#956))
+ Improvements to the generic accessor for mixed-precision ([#727](#727))
+ Add a naive lower triangular solver implementation for CUDA ([#764](#764))
+ Add support for int64 indices from CUDA 11 onward with SpMV and SpGEMM ([#897](#897))
+ Add a L1 norm implementation ([#900](#900))
+ Add reduce_add for arrays ([#831](#831))
+ Add utility to simplify Dense View creation from an existing Dense vector ([#1136](#1136)).
+ Add a custom transpose implementation for Fbcsr and Csr transpose for unsupported vendor types ([#1123](#1123))
+ Make IDR random initilization deterministic ([#1116](#1116))
+ Move the algorithm choice for triangular solvers from Csr::strategy_type to a factory parameter ([#1088](#1088))
+ Update CUDA archCoresPerSM ([#1175](#1116))
+ Add kernels for Csr sparsity pattern lookup ([#994](#994))
+ Differentiate between structural and numerical zeros in Ell/Sellp ([#1027](#1027))
+ Add a binary IO format for matrix data ([#984](#984))
+ Add a tuple zip_iterator implementation ([#966](#966))
+ Simplify kernel stubs and declarations ([#888](#888))
+ Simplify GKO_REGISTER_OPERATION with lambdas ([#859](#859))
+ Simplify copy to device in tests and examples ([#863](#863))
+ More verbose output to array assertions ([#858](#858))
+ Allow parallel compilation for Jacobi kernels ([#871](#871))
+ Change clang-format pointer alignment to left ([#872](#872))
+ Various improvements and fixes to the benchmarking framework ([#750](#750), [#759](#759), [#870](#870), [#911](#911), [#1033](#1033), [#1137](#1137))
+ Various documentation improvements ([#892](#892), [#921](#921), [#950](#950), [#977](#977), [#1021](#1021), [#1068](#1068), [#1069](#1069), [#1080](#1080), [#1081](#1081), [#1108](#1108), [#1153](#1153), [#1154](#1154))
+ Various CI improvements ([#868](#868), [#874](#874), [#884](#884), [#889](#889), [#899](#899), [#903](#903),  [#922](#922), [#925](#925), [#930](#930), [#936](#936), [#937](#937), [#958](#958), [#882](#882), [#1011](#1011), [#1015](#1015), [#989](#989), [#1039](#1039), [#1042](#1042), [#1067](#1067), [#1073](#1073), [#1075](#1075), [#1083](#1083), [#1084](#1084), [#1085](#1085), [#1139](#1139), [#1178](#1178), [#1187](#1187))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1:ST:high-importance This issue/PR is of high importance and must be addressed as soon as possible. 1:ST:ready-to-merge This PR is ready to merge. mod:all This touches all Ginkgo modules. reg:build This is related to the build system. reg:testing This is related to testing. type:factorization This is related to the Factorizations type:solver This is related to the solvers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0