- Implement the basic structure of the mpi lib
and specialization for arrays, basic types, std::vector
- adapted the array class for the lazy mpi mechanism
- pass tests on arrays :
- scatter, gather on array<long,2> array<complex,2>, etc...
- broadcast
- several files for readibility
- the std::vector coded but not tested.
- generic mecanism implemented and tested (mpi_generic test)
- added several tests for the mpi lib.
- TODO : more tests, doc...
- the flag is really enforce_copy and should force a copy
- for a view : it is false, no change
- for a regular type : it is true, and now this will enforce the
copy in the call of numpy. numpy does it for us.
- The problematic case was when we construct a regular type
from a complicated view in python, which is an array
but is not C contiguous.
(hence the PyArray_Check was false, and the C_Contiguous flag was not set)
Now it is fine, since we ask numpy to systematically copy the data for us
and build a C contigous array.
--> the constructor from python does not support custom memory layout
because numpy only support C and Fortran
Conflicts:
triqs/arrays/impl/indexmap_storage_pair.hpp
- Cleaned of the eigensystems computations (worker is simpler, decision
at runtime, etc..).
- Fix#119 : When the matrix is in C order, the fortran lapack
sees in fact its conjugate, so we need to conjugate the eigenvectors at the end.
NB : not true if the storage order of the matrix is already fortran of course.
- For users : only change is :
H5::H5File in apps. to be replaced by triqs::h5::file, same API.
- using only the C API because :
- it is cleaner, better documented, more examples.
- it is the native hdf5 interface.
- simplify the installation e.g. on mac. Indeed, hdf5 is
usually installed without C++ interface, which is optional.
E.g. EPD et al., brew by default.
Also the infamous mpi+ hdf5_cpp bug, for which we have no clean solution.
- clean the notion of parent of a group. Not needed, better iterate function in C LT API.
- modified doc : no need for C++ bindings any more.
- modified cmake to avoid requiring CPP bindings.
- import arrays in extensions (mako file).
- put import_arrays in converter,
along the lines of our own objects (numpy and triqs uses
the same capsule technique, i.e. the standard technique from python
doc.)
- implement transposed_view for arrays.
- .transpose method for gf
- wrapped to python
- add call op. for GfImTime, using C++
- Added ChangeLog
- rm matrix_stack
- start cleaning old code
- h5/make_h5.... only used in parameters.
- old boost includes before C++11
- remove boost serialization, make macro TRIQS_MAKE_NVP temporarely
- remove boost::is_complex (can be written in 2 lines...)
- move some lib in cpp
- fold was not correct in e.g. passing an int as init instead of a
double (was leading to narrowing in return).
- better return type deduction.
- there was an error in the doc (order of argument in the lambda !)
- add a more complex example (Frobenius norm of matrices).
Changed operator()(int, int...) && for array, and views.
- For const_view and regular type, returns value_type (i.e. a copy).
NB : does make a copy, not a move. Ok for scalar type. TODO: think for complicated types.
This allows codes like :
f(x)(0,0) where f : x-> matrix or const_view
to be correct in clef expression evaluation.
- For _view : return a value_type &, as before to allow :
A(....)(0,0) = rhs;
It is not possible to detect dangling refs in that case at compile time.
Added a security in TRIQS_ARRAYS_DEBUG mode to detect a dangling ref at run time,
i.e. the case where the view is "unique" (ref count ==1).
This would be a quite bad design anyway ...
- also :
- clean operator[] for vector (old workaround for old gcc...)
- add IsView flag in ISP impl class, for the impl. of operator() &&
A(i_)(om_) << ...
for A an array of gf was not working.
Modified the auto_assign of arrays to handle the case when the object
in the array is itself autoassigned.
Using the model of std::vector adapter for clef, which works.
Also fixed the gf for a little details (gf_impl is usually in the expression tree, not gf).
Pb :
M() = rhs; // rhs of type RHS
Currenlty does :
M(i,j) = (i==j ? rhs : RHS{})
Changed to
M(i,j) = (i==j ? rhs : RHS{0*rhs})
If RHS is a double, int ... Same result.
If RHS is a matrix, gf, currently the offdiag elements
are default constructed (i.e. of 0 size !).
Which can break operations later (matrix<matrix<double>>)
After change : all elements have the same size !
- forgot to correct the value_type of matrix_expr, and vector_expr
as was done long ago for arrays...
- also added cases for arrays until dim 10
- TODO : replace this trait in arrays with a tuple tools for any dim..
not urgent.
- gf<cartesian_product<imfreq,imfreq>> was not correct
when out bounds. Fixed evaluator.
- tensor_proxy : fix the trait for algebra which was incorrect.
- TODO: clean code (repetition, put in mesh some windowing).
- little details : code cleaning, clang formatting, along
with documentation writing for c++ gf.
- separated the mesh in small class for better doc.
- work on documentation : reorganize specialisation, ...
std::conj returns a complex according to std.
On gcc, we need to define it (bug?) but on clang libc++
it is an error.
-> one test is still failing : to be decided later
- a(1,ellipsis()) for a an array<T,1> e.g.,
was not compiling.
- also added const_iterator for range to allow simple code :
for (auto i : range {3,6}) ....-> i = 3,4,5 as in python
