Typed vector and tensor
Description
I started to work on this in the context of #1076 and in sync with what I did with #1075. My idea was to set up some types of plumed to be more flexible and usable in contexts like sycl, cuda, openACC or targetted openMP. Then I dropped this for a while, but I thought it could be interesting to bring it out again.
Most of the problems this new approach gives are in the friend functions within the vector and the tensor, they give strange warnings. I think due to the fact that I am declaring friend functions like
template<typename U, unsigned m> U dotProduct(const VectorGeneric<U, m>&,const VectorGeneric<U, m>&); to a template<typename T, unsigned n> VectorGeneric<T, n>, with all types and all dimensions. On one hand, I do not think is a problem, but on the other hand, it does make me a little uncomfortable.
If I understood correctly those functions are declared friend to appear in the documentation page of Tensor/Vector, maybe by putting \ingroup TOOLBOX in their docstring they will appear in the toolbox, or in another doxygen module and we can remove the friend declarations.
In any case the part with the friend-declared functions must be finished because I applied two different approaches in Vector and Tensor: in tensor, I eliminated the friend nearly all the friend declarations because I was having an hard time in trying to compile with all of them.
I also added a .data() method to access the underline array in both classes. This new method should be used in place of the various &variable[0] to get the pointer to the first element of the array. But as now, I did not refactored it in the code (but I am using something similar in #1075 ).
Target release
I would like my code to appear in release 2.10
Type of contribution?
- [X] changes to code or doc authored by PLUMED developers, or additions of code in the core or within the default modules
- [ ] changes to a module not authored by you
- [ ] new module contribution or edit of a module authored by you
Copyright
- [X] I agree to transfer the copyright of the code I have written to the PLUMED developers or to the author of the code I am modifying.
- [ ] the module I added or modified contains a
COPYRIGHTfile with the correct license information. Code should be released under an open source license. I also used the commandcd src && ./header.sh mymodulenamein order to make sure the headers of the module are correct.
Tests
- [X] I added a new regtest or modified an existing regtest to validate my changes.
- [ ] I verified that all regtests are passed successfully on GitHub Actions.
Quick note, replace VectorGeneric<T,N> with VectorTyped<T,N> to avoid breaking existing code, as we discussed
Quick note, replace
VectorGeneric<T,N>withVectorTyped<T,N>to avoid breaking existing code, as we discussed
I force-pushed to align with existing code, and to have clearer commits
I have to set up a few benchmarks and redo the documentation, to keep the not-member functions in the wanted pages
Now this is passing cppcheck (hopefully), but I had to remove the static_asserts with the clearer error message
@GiovanniBussi I think I should also add local_ssyevr? Or I can keep it as a TODO?
@Iximiel @GiovanniBussi is this ready to merge? The CI issue is not clearly related to the PR I think but there is an old comment from Daniele unaswered
local_ssyevr
@Iximiel if possible and easy I would add local_ssyevr. so that diagMatSym can be used also on single precision vectors. Thanks!
local_ssyevr
@Iximiel if possible and easy I would add local_ssyevr. so that
diagMatSymcan be used also on single precision vectors. Thanks!
I added ssyevr to Tensor.h, then for adding the tests for it I modified the calls to blas/lapack in Matrix.h
rt-lowest-eigenpair has a built in benchmark for the diagonalization, I think it is interesting that (at least on my machine) the new lowestEigenpairSym is faster for double than for float
(diagMatSym behave as expected)