Asadchev/refactor/math#230
Conversation
asadchev
force-pushed
the
asadchev/refactor/math
branch
12 times, most recently
from
9cee529 to
f544a8c
Compare
| # Find dependencies related to ScaLAPACK | ||
| ################### | ||
|
|
||
| add_compile_definitions( ${MPI_CXX_COMPILE_DEFINITIONS} ) |
There was a problem hiding this comment.
how does this propagate to dependencies? should this be applied to a particular target?
There was a problem hiding this comment.
Shouldn't we be using MPI::MPI_C (not MPI::MPI_CXX, that has some really dumb behaviour for OpenMPI) for this anyways?
| # Find dependencies related to ScaLAPACK | ||
| ################### | ||
|
|
||
| add_compile_definitions( ${MPI_CXX_COMPILE_DEFINITIONS} ) |
There was a problem hiding this comment.
Shouldn't we be using MPI::MPI_C (not MPI::MPI_CXX, that has some really dumb behaviour for OpenMPI) for this anyways?
| ? madness::cblas::Trans | ||
| : madness::cblas::NoTrans); | ||
| const madness::cblas::CBLAS_TRANSPOSE right_op = | ||
| ? blas::Transpose |
There was a problem hiding this comment.
We should probably be using blas::Op::Trans, blas::Op::NoTrans and blas:Op:::ConjTrans to make the transition to blaspp/lapackpp more transparent (e.g. typedef blas::Op Op;). I can make the necessary changes to blacspp and scalapackpp to be more consistent as well
|
|
||
| enum TransposeFlag { NoTranspose, Transpose, ConjTranspose }; | ||
|
|
||
| enum class SVDReturn { |
There was a problem hiding this comment.
I originally had these as strong types to allow for the possibility of typed template specialization for particular combinations (the performant alg choices for thin return / value only may be slightly different than full return, etc). I'm fine keeping the change, but we may find use cases for the strong types later on if we look at more advanced dispatch
| lapack::cholesky(A_eig); | ||
| linalg::rank_local::cholesky(A_eig); | ||
| } | ||
| world.gop.broadcast_serializable(A_eig, 0); |
There was a problem hiding this comment.
Cholesky can be safely replicated with identical inputs (not like XSYEV which has a phase problem), and since make_matrix already seems to be replicating the data, that would save you some communication / synchronization
| using numeric_type = typename detail::array_traits<Array>::numeric_type; | ||
| World& world = A.world(); | ||
| auto A_eig = detail::to_eigen(A); | ||
| auto A_eig = detail::make_matrix(A); |
There was a problem hiding this comment.
Since make_matrix replicates here, wouldn't it make more sense to add a "scatter/gather" type driver rather than "Alltoall` to save on some communication dependencies?
asadchev
force-pushed
the
asadchev/refactor/math
branch
5 times, most recently
from
f25eafe to
9aa9ff3
Compare
- Reorganize rank-local matrix, blas, and linalg - Replace madness::cblas::Transpose by TA::blas::TransposeFlag - Move non-distributed DistArray linalg to TiledArray/algebra/non-distributed
asadchev
force-pushed
the
asadchev/refactor/math
branch
2 times, most recently
from
191e631 to
a70762d
Compare
asadchev
force-pushed
the
asadchev/refactor/math
branch
from
a70762d to
11daf44
Compare
3 participants
No description provided.