test gfv2 fails

[aichhorn]

The test gfv2 fails on ubuntu12.04 , obviously due to a diff problem. In the part with lazy assign 2 I get:

(inverse(G(inf))) ---> tail/tail_view: min/smallest/max = -1 -1 6 ... Order -1 = [[(1,0),(0,0)] [(0,0),(1,0)]] ... Order 0 = [[(2.3,0),(0,0)] [(0,0),(2.3,0)]] ... Order 1 = [[(3.55618e-17,0),(0,0)] [(0,0),(3.55618e-17,0)]] ... Order 2 = [[(-7.55212e-16,0),(0,0)] [(0,0),(-7.55212e-16,0)]] ... Order 3 = [[(-3.55401e-15,0),(-0,0)] [(-0,0),(-3.55401e-15,0)]] ... Order 4 = [[(1.93647e-15,0),(0,0)] [(0,0),(1.93647e-15,0)]] ... Order 5 = [[(1.44308e-14,0),(0,0)] [(0,0),(1.44308e-14,0)]] ... Order 6 = [[(9.90874e-16,0),(0,0)] [(0,0),(9.90874e-16,0)]]

All the small numbers maybe should be zeros in order to pass the test. gfv2_output.err is empty.

[parcollet]

Hi Markus, Strange on my 12.04 it works with gcc, clang and icc !? What is your compiler ? Indeed, I should not compare those small numbers ...

[aichhorn]

It occurs on my laptop with gcc 4.6.3 on ubuntu 12.04. It does not occur with gcc 4.7.2 on our debian machines. On the other hand, with 4.7.2 I get a problem with det_manipc1, which is not there on my laptop with ubuntu. Test fails with 'Exception', and the output is the following:

---

i = 0 size = 0 insert1 x,y = 3.44949 9.40913 det = (-0.647047,0) == (-0.647047,0) assert_close (-0.647047,0) (-0.647047,-0) 0 1e-06 assert_close (-0.647047,0) (-0.647047,0) 0 1e-06

---

i = 1 size = 1 insert1 x,y = 4.62844 5.50449 det = (0.798304,-0) == (0.262815,-0) assert_close (0.798304,-0) (0.798304,0) 2.22045e-16 1e-06 terminate called after throwing an instance of 'triqs::runtime_error' what(): Triqs runtime error at //afs/itp.tugraz.at/user/aichhorn/work/Codes/TRIQSgithub/triqs/arrays/asserts.hpp : 37

Trace is :

./det_manipc1 void triqs::arrays::assert_all_closetriqs::arrays::inverse_lazy<triqs::arrays::matrix_view<std::complex<double, 0ull, 0ull>>, triqs::arrays::matrix_viewstd::complex<double, 0ull, 0ull> >(triqs::arrays::inverse_lazytriqs::arrays::matrix_view<std::complex<double, 0ull, 0ull>> const&, triqs::arrays::matrix_viewstd::complex<double, 0ull, 0ull> const&, double, bool) 0x410 [0x42f440] ./det_manipc1 test::check() 0x27d [0x43052d] ./det_manipc1 test::run() 0x8f8 [0x435078] ./det_manipc1 main 0x59 [0x41b9e9] /lib/x86_64-linux-gnu/libc.so.6 __libc_start_main 0xfd [0x2b93a4ca7ead] ./det_manipc1 [0x41ba79]

assert_all_close error :

.. A = inverse( [[(-1.23377,0),(-0.629274,0)] [(-0.850963,0),(-0.647047,0)]])

.. B= [[(-0.810527,0),(0.788264,0)] [(1.06596,0),(-2.58217,0)]]

.. Residue is r = 2.17192

[parcollet]

Same compiler, same 12.04 here (64 bits). Strange. Anyway, I will fix these small numbers. The det_manipc1 is also on my mac, where I traced it to a bug in BLAS1 zdot routine on OS X. Apparently, the pb appears also on weiss... I will rewrite this routine in C++, it is about one line anyway...

wien2kconvert fails here however :

GROUP "Dens_Mat_below" { < ATTRIBUTE "TRIQS_HDF5_data_scheme" { < DATATYPE H5T_STRING { < STRSIZE 14; < STRPAD H5T_STR_NULLPAD; < CSET H5T_CSET_ASCII; < CTYPE H5T_C_S1; < } < DATASPACE SCALAR < DATA { < (0): "PythonListWrap" < } < } etc.... is missing in the file produced on my 12.04... ANy idea ?

[aichhorn]

Hmmm, there should be no field called 'Dens_Mat_below'. With the new naming convention I changed the name of this field to 'dens_mat_below'. In the archive wien2k_convert.output.h5 in the repository the field is indeed called 'dens_mat_below' (in the subgroup SumK_LDA_ParProj). Can it be that you compare your output to an older version of wien2k_convert.output.h5?

[parcollet]

Ok, the archive was reopen in the test, not removed and I had an old archive which contained old stuff... cleaning the files, the test now pass.

[mferrero]

I confirm that the det_manipc1 also fails on weiss with the same output as show by Markus above. This is nasty, it is not crashing like on the mac, but gives wrong results...

[parcollet]

Fixed in 97fd505. Can you retry and close ? It nows works on my mac.

[mferrero]

Now det_manipc1 works fine on weiss! The problem with gfv2 still needs to be fixed.