As described in #3291, simple installation of ABACUS through Spack had been implemented and waiting to be merged into Spack mainline( https://github.com/spack/spack/pull/42974 );
however, as an important usage -- automating unit test -- of Spack, unit test of ABACUS had not been implemented in current pull, partly because they are not compatible with Release builds.
This issue talks about which, and how unit tests of ABACUS should be implemented in Spack.
Describe the solution you'd like
This issue targets in giving solution to :
building & running a set of Release-compatible ABACUS unit test within a Spack Release build;
building & running full set of ABACUS unit test under their desired build flags within a Spack build;
a Spack-based multi-toolchain ABACUS CI workflow.
To achieve these target, these questions need to be answered:
which unit tests are currently desired by ABACUS CI?
under which configuration and environment should tests above be compiled and runned?
which unit tests are compatible with cmake Release (i.e. CXXFLAGS=-O3 -NDEBUG) configure option?
what do ABACUS need for automated CI except for unit test themselves, e.g. desired environments and platforms?
Task list only for developers
[ ] Notice possible changes of behavior
[ ] Explain the changes of codes in core modules of ESolver, HSolver, ElecState, Hamilt, Operator or Psi
Notice Possible Changes of Behavior (Reminder only for developers)
No response
Notice any changes of core modules (Reminder only for developers)
No response
Notice Possible Changes of Core Modules (Reminder only for developers)
No response
Additional Context
Currently no draft of ABACUS test by Spack had been implemented.
To run test for a software soft, run:
$ spack test run soft
For examples of implemented test with soack, see magma and hdf5.
Task list for Issue attackers (only for developers)
[ ] Review and understand the proposed feature and its importance.
[ ] Research on the existing solutions and relevant research articles/resources.
[ ] Discuss with the team to evaluate the feasibility of implementing the feature.
[ ] Create a design document outlining the proposed solution and implementation details.
[ ] Get feedback from the team on the design document.
[ ] Develop the feature following the agreed design.
[ ] Write unit tests and integration tests for the feature.
[ ] Update the documentation to include the new feature.
[ ] Perform code review and address any issues.
[ ] Merge the feature into the main branch.
[ ] Monitor for any issues or bugs reported by users after the feature is released.
[ ] Address any issues or bugs reported by users and continuously improve the feature.
Background
As described in #3291, simple installation of ABACUS through Spack had been implemented and waiting to be merged into Spack mainline( https://github.com/spack/spack/pull/42974 ); however, as an important usage -- automating unit test -- of Spack, unit test of ABACUS had not been implemented in current pull, partly because they are not compatible with
Release
builds.This issue talks about which, and how unit tests of ABACUS should be implemented in Spack.
Describe the solution you'd like
This issue targets in giving solution to :
Release
-compatible ABACUS unit test within a SpackRelease
build;To achieve these target, these questions need to be answered:
Release
(i.e.CXXFLAGS=-O3 -NDEBUG
) configure option?Task list only for developers
Notice Possible Changes of Behavior (Reminder only for developers)
No response
Notice any changes of core modules (Reminder only for developers)
No response
Notice Possible Changes of Core Modules (Reminder only for developers)
No response
Additional Context
Currently no draft of ABACUS test by Spack had been implemented. To run test for a software
soft
, run:For examples of implemented test with soack, see
magma
andhdf5
.Task list for Issue attackers (only for developers)