When an object with __hdf_write__ was written in an archive, the
corresponding key was not cached. Therefore, one could not access
the object which had just been written.
- clef : fix a little bug in storage when evaluating
(was using the wrong trait to deduce storage type).
- gf : block :
- added reinterpret_scalar_valued_gf_as_matrix_valued
for block function
- cleaned make_block_gf_view_from_vector
- added make_block_gf_view_from_vectormake_block_gf_view_from_vector_of_cython_proxy
and changed the cython accordingly because it requires a slightly different syntax.
- updated tests
- gf : cleaned some template.
- lazy_fourier and co --> fourier
- ex fourier --> make_gf_from_fourier to make a new gf
- = fourier (g) works only iif lhs is a view, like scalar.
- updated python (commented fourier method).
- Make more general constructors for the gf.
gf( mesh, target_shape_t)
- remove the old make_gf for the basic gf.
- 2 var non generic gf removed.
- clean evaluator
- add tensor_valued
- add a simple vertex test.
- clean specialisation
- Fix bug introduced in 1906dc3
- forgot to resize the gf in new version of operator =
- Fix make_singularity in gf.hpp
- clean resize in operator =
- update h5 read/write for block gf
- changed a bit the general trait to save *all* the gf.
- allows a more general specialization, then a correct for blocks
- NOT FINISHED : need to save the block indice for python.
How to reread ?
Currently it read the blocks names and reconstitute the mesh from it.
Is it sufficient ?
- clean block constructors
- block constructors simplest possible : an int for the number of blocks
- rest in free factories.
- fixed the generic constructor from GfType for the regular type :
only enable iif GfType is ImmutableGreenFunction
- multivar. fix linear index in C, and h5 format
- linear index now correctly flatten in C mode
(was in fortran mode), using a simple reverse of the tuple in the folding.
- fix the h5 read write of the multivar fonctions
in order to write an array on dimension # variables + dim_target
i.e. without flattening the indices of the meshes.
Easier for later data analysis, e.g. in Python.
- merge matrix/tensor_valued. improve factories
- matrix_valued now = tensor_valued<2>
(simplifies generic code for h5).
- factories_one_var -> factories : this is the generic case ...
only a few specialization, code is simpler.
- clef expression call with rvalue for *this
- generalize matrix_proxy to tensor and clean
- clean exception catch in tests
- exception catching catch in need in test
because the silly OS X does not print anything, just "exception occurred".
Very convenient for the developer...
- BUT, one MUST add return 1, or the make test will *pass* !!
- --> systematically replace the catch by a macro TRIQS_CATCH_AND_ABORT
which return a non zero error code.
- exception : curry_and_fourier which does not work at this stage
(mesh incompatible).
- gf: clean draft of gf 2 times
- comment the python interface for the moment.
- rm useless tests
This is a fix for issue #18. The type float128 doesn't exist on 32-bit
machines. I removed it from the matrix_stack.pyx detection of a scalar.
modified: pytriqs/gf/local/matrix_stack.pyx
A trivial cythonized version of the c++ random_generator class.
Useful to get the names of the generators from the python.
new file: pytriqs/random/*
new file: doc/reference/python/random/*
Now the tail have a fixed size. It actually makes everything simpler. I took
order_min = -1 and order_max = 8. This makes the tails compatible with the
previous implementation. However we might want to change this to something like
-10, 10 so that they are self-contained. This commit should also fix issue #11.
I added a version.hpp and updated the version.py so that
one can find the version of the library either from the
c++ or the python (if there is python support).
modified: CMakeLists.txt
modified: cmake/TRIQSConfig.cmake.in
modified: pytriqs/version.py.in
modified: triqs/CMakeLists.txt
new file: triqs/version.hpp.in
gcc has a pb because the template mesh<Variable,Opt>
has the name same as the gf mesh method (!).
Clang is fine however on this...
Solution : rename the template mesh<...> to gf_mesh...
Not very elegant, but ok.
- necessary otherwise the class gf and the namespace have
the same name, leading to some confusion, and need to qualify
some functions (specially on gcc).
Same naming conventions as arrays.
- The old code, which was in the solvers,
is used in several apps (dft, ctqmc_hyb).
It is really a lib, even though it is now superseded
by Igor and Andrey's library...
(to be deprecated at some point).