- Use a new buffered_function to replace the complicated generator code from ALPS.
- Clean the implementation of the random_generator
- update the documentation
- update to the new python wrapper (could not be done with the previous
version, because of lack of move constructor).
- 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
- an include missing on OS X
- change serialization in the general case where hdf5 can be used,
(version of hdf5 high enough) to use only one buffer,
not a buffer per field.
- put back the mpi_param example.
- new parameter class :
parameters are viewed as form, built in C++, and filled in C++/python.
Each field of the form as a precise C++ type (erased using standard techniques).
First tests ok, to be reread/checked.
TODO : serialization is commented. Lead to long compilation time & large code
due to boost::serialization. Use h5 when possible.
- wrapper :
- separated the converters of the wrapped type in the TRIQS library
- necessary for parameters (it used outside an .so) and potentially
other codes, outside an .so module
When constructing the last unit vector in 2D, the sanity check was wrong because of usage of abs instead of std::abs.
Added method energy_on_bz_path_2 that returns the energy *matrix* at each k point on a given path instead of the eigenvalues of this matrix. The name of the function should be changed (to energy_matrix_on_bz_path?)
Renaming energies_on_bz_path_2 to energy_matrix_on_bz_path
- 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
- bool at_end() for a mesh point means AFTER the last point ,
as end in STL. It was not correct ( +1 missing).
- also the at_end was not computed in the mesh product.
- it slightly changes the test_fit_tail --> just changed the output.
--> did this bug affect other functions/codes ?
- correct previous commit (for scalar gf, the new check was not compiling)
- correct windowing of linear mesh (left point corrected as right point for rounding error
-> code was previously assuming mesh with only positive, fermionic matsubara freqs
-> changed wn_min to n_min (was misleading, since it was an index, not a frequency) / same for <-> max
-> changed doc accordingly
- added test for a 'real-life' GF + corresponding output
- added basic usage documentation for tail fitting from c++. Full implementation details yet to be written
-> Previously, calculation was implicitly assuming a mesh with only positive matsubara frequencies.
-> Added corresponding test
-> Also added test of density calculation with or without correct tail.
- the condition p%2 ==1 was wrong if p<0 (never true!)
- added corresponding test (gf_notail)
Conflicts:
triqs/gfs/imtime.hpp
Fixed by O.P. : already fixed in Laura's pull request ...
- 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).
DRAFT : to be tested further...
- update gf<imfreq>
- write a specific mesh for matsubara frequencies
- now the cast series is :
mesh_pt --> matsubara_freq --> complex<double>
- matsubara_freq is just the matsubara frequency
- arithmetic of the mesh_pt casted to matsubara_freq
- arithmetic of matsubara_freq is casted to complex, except + and -,
which are kept as matsubara_freq.
- evaluator now accept : int, mesh_pt, and matsubara_freq
for matsubara_freq : for negative omega, use conjugation
for omega outside windows, evaluate the tail on omega.
- as a result : g( om - nu) where om, nu are 2 meshes points,
is the extrapolation outside the grid if necessary.
- updated tests
- added evaluation for tail.
