Closed michael-hartmann closed 7 years ago
The problem disappears when using LAPACK and LU decomposition. Therefore the problem is probably related to HODLR.
Maybe this is an issue with rand and srand in the HODL code.
It does not seem to be related to the calls of rand and srand in the HODLR library.
The problem is not related to Drude. Also, casimir_logdetD gives correct results. The function slave also gets the correct input parameters and returns the (maybe wrong) value of logdetD correctly.
don't calling casimir_set_ldim solves the problem - very strange
==8500== Conditional jump or move depends on uninitialised value(s)
==8500== at 0x5FF29D3: __printf_fp_l (printf_fp.c:1212)
==8500== by 0x5FECB81: printf_positional (vfprintf.c:2022)
==8500== by 0x5FEE4A5: vfprintf (vfprintf.c:1677)
==8500== by 0x5FF0EF0: buffered_vfprintf (vfprintf.c:2320)
==8500== by 0x5FEE32C: vfprintf (vfprintf.c:1293)
==8500== by 0x5FF6898: printf (printf.c:33)
==8500== by 0x4020AB: main (casimir_logdetD.c:230)
==8500== Uninitialised value was created by a heap allocation
==8500== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8500== by 0x5B6C6E6: HODLR_Tree
The problem is probably connected with the parameter nLeaf - increasing this parameter might solve this issue.
"nLeaf is the size (number of rows of the matrix) of the smallest block at the leaf level. The number of levels in the tree is given by log_2(N/nLeaf)"
The bug was indeed the uninitialized variable in the HODLR library.
In the MPI program casimir there seems to be some kind of race condition. If there are processes, some values of logdetD(xi,m) for some m are wrong. If only one core is used for the calculation, this problem does not seem to occur.