Closed aichhorn closed 11 years ago
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 ...
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
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 ?
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?
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.
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...
Fixed in 97fd505. Can you retry and close ? It nows works on my mac.
Now det_manipc1 works fine on weiss! The problem with gfv2 still needs to be fixed.
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.