Add DFTB+ as variant #99
Conversation
without MPI (input from Franco)
|
the upstream dftb+ doesnt compile, should we not wait for that to be fixed before setting it here? |
Co-authored-by: Ashwin Kumar Karnad <[email protected]>
|
Thanks, Ashwin. Why do we choose |
spack info dftbplus:
...
Variants:
Name [Default] When Allowed values Description
======================= ==== ============== ===================================================================================================
arpack [off] -- on, off Use ARPACK for excited state DFTB functionality
build_system [makefile] -- makefile Build systems supported by the package
dftd3 [off] -- on, off Use DftD3 dispersion library (if you need this dispersion model)
elsi [off] -- on, off Use the ELSI library for large scale systems. Only has any effect if you build with '+mpi'
gpu [off] -- on, off Use the MAGMA library for GPU accelerated computation
mpi [on] -- on, off Build an MPI-paralelised version of the code.
sockets [off] -- on, off Whether the socket library (external control) should be linked
transport [off] -- on, off Whether transport via libNEGF should be included. Only affects parallel build. (serial version is
...
(might get a failure, see Ashwin's earlier comment)
Ah - I wasn't aware of that. Is there a MR (upstream in spack) to fix dftb+? (With my latest commit we should see the build failing: that would be my other question: what is the problem with dftb+ building in spack.) |
|
|
Okay, let's put this on hold until the DFTB+ changes are merged upstream (either spack/spack#23086 would be good spack/spack#39608). The one from Ashwin would probably be 'better' for us as these changes are already in our local MPSD-spack fork, and the buildbot uses them. |
|
@fangohr Should we maybe just close this and add DFTB+ support once we have finished the transition to CMake? |
Addresses: #98
without MPI (input from Franco)