partitioned Hilbert space

[supermarche]

Dear all,

we ran into a segmentation fault in cthyb starting from a particular G0 [6x6 block Gf] employing dfttools and the simple hk_converter. If there is a small shift in the k-mesh away from the high-symmetry points, the auto-partition method seems to fail (uninitialized variables) and the subsequently called complete_init creates a segmentation fault:

BT >>>>>>>>>>>>>>>>>

==11059== Process terminating with default action of signal 11 (SIGSEGV) ==11059== Access not within mapped region at address 0x36CC87800 ==11059== at 0x1A28B51A: _ZNK5triqs13hilbert_space19imperative_operatorINS0_13hilbert_spaceEdLb0EEclINS0_5stateINS0_17sub_hilbert_spaceEdLb0EEEJEEET_RKS8DpOT0 (in /home/hoeppner/src/TRIQS/install_triqs/lib/libcthyb_c.so) ==11059== by 0x1A2846B2: cthyb::sorted_spaces::complete_init(triqs::utility::many_body_operator const&) (in /home/hoeppner/src/TRIQS/install_triqs/lib/libcthyb_c.so) ==11059== by 0x1A2866E6: cthyb::sorted_spaces::sorted_spaces(triqs::utility::many_body_operator const&, triqs::hilbert_space::fundamental_operator_set const&) (in /home/hoeppner/src/TRIQS/install_triqs/lib/libcthyb_c.so) ==11059== by 0x1A202314: cthyb::solver_core::solve(cthyb::solve_parameters_t const&) (in /home/hoeppner/src/TRIQS/install_triqs/lib/libcthyb_c.so) ==11059== by 0x19F3E727: SolverCore_solve(object, object, _object*) (in /home/hoeppner/src/triqs_1.2/INSTALL/lib/python2.7/site-packages/pytriqs/applications/impurity_solvers/cthyb/cthyb.so) ==11059== by 0x4EDEF15: PyObject_Call (in /usr/lib64 ... <<<<<<<<<<<<<<< BT <<<<<<<<<<<<<<<<<<

However, if the shift in the k-mesh is not present, or we don't use the auto-partitioning scheme (partition_method = 'none'), the calculation runs smoothly. With other one-particle Hamiltonians and a small shift in the k-mesh, the calculations are running, too.

I attached a plot of the diagonal elements of G0

and plot of the differences of all elements of G0 with / without an offset of the k-mesh:

As you can the see, the differences in G0 are tiny. I appreciate any helpful comment.

All the best, Marc

[aichhorn]

Hi Marc, The position of the k-points enters only through the H(k) that you provide in the input. So the reason has to be in the Hamiltonian. You wrote that you have a 6x6 matrix as input, but is this a full 6x6 matrix? Or in other words, what is your local one-particle Hamiltonian? If it contains off-diagonal comlex terms, then the solver is not supposed to work, and 6x6 looks like t2g with spin orbit, where you have exactly those terms present.

[supermarche]

Hi Markus,

greetings to Graz ; ) May I ask, why the impurity solver is not supposed to work? I thought since the rewrite complex matrix elements aren't a problem anymore (besides the usual "sign-problem" one runs into). I am aware that k-points enter only implicitly via the extraction of G_loc, thus I was surprised to face a problem in partitioning the Hilbert space. The local interaction has been the same Kanamori-like Hamiltonian in all cases.

Back to the problem above: you are correct that this is a full 6x6 matrix, i.e. the impurity problem is not treated as block diagonal (for example in spin space). The segfault happens without explicit complex off-diagonal elements, i.e. without spin-orbit interaction, too.

All the best, Marc

[aichhorn]

The problem has to come from symmetries of the local Hamiltonian and/or hybridisation functions. What I mean is that the k-summed quantities exhibit some symmetries such as degeneracies, or matrix elements being zero for symmetry reason. You checked that all this is still fulfilled by the shifted k-mesh, right? I can only guess that the auto-partition algorithm might have problems with this almost-fulfilled symmetries... I did not check the code, so I really don't know.

[supermarche]

Exactly, I suspect the failure to be somewhere inside the auto-partitioning scheme / initializing the sub-spaces. If there is time I'll check the displayed differences w and w/o the k offset (see above) in detail.

[krivenko]

Hello Marc, Could you try to reproduce the segfault using partition_method = "quantum_numbers" and an appropriate set of quantum numbers (total number of particles)?

[supermarche]

Hello Igor,

if we use the partition_method = "quantum_numbers" and supply the corresponding conserved observables (like total particle number), it runs smoothly. Thanks for pointing this out.

Marc

[phansmann]

Hi everyone,

As a matter of fact the k-integrated H(k) does have finite complex values. We understand (now) that this is currently not handled by the solver... Probably its moot right now to discuss whether or not this is the reason for the segfault and we should move on to discuss how to handle complex off-diagonal entries in H_loc (B-fields, SOC, inversion-less CF, ...)

Cheers, Philipp

[supermarche]

Just as a comment: the Hamiltonian we were using to "create" the segfault did not have any complex element, just a signed +-0.0000. This is due to writing the Hamiltonian in a fixed floating point format before the readin via HK_converter. Thus noise of the imaginary part of the Hamiltonian after the Fourier transform is transformed to a signed zero, which in my opinion should not effect anything. However, of course, adding SOC would introduce complex off-diagonal terms.

Best, Marc

[krivenko]

Hello Marc,

1. Priyanka made a commit to the library with a potential fix to your issue. Please reinstall the library, the solver, and try once more.
2. If the problem persist, show us the exact local Hamiltonian. It is printed out by cthyb, when verbosity >= 2.

[supermarche]

Hello Igor,

I recompiled triqs and cthyb with your modifications, however the problem persists. In principle, the local Hamiltonian in my run should only include chemical potential terms, since I choose U,J=0 (for test reasons). In case of a "segfault configuration" it looks like: -0.266165_C^+(ud,0)C(ud,0) + -0.266165_C^+(ud,1)C(ud,1) + 2.43056e-14_C^+(ud,2)C(ud,4) + 0.0736244_C^+(ud,2)C(ud,2) + 2.43056e-14_C^+(ud,3)C(ud,5) + 0.0736244_C^+(ud,3)C(ud,3) + 0.0736244_C^+(ud,4)C(ud,4) + 2.43056e-14_C^+(ud,4)C(ud,2) + 0.0736244_C^+(ud,5)C(ud,5) + 2.43056e-14_C^+(ud,5)C(ud,3)

The problem seems to be that there are contributions which are slightly larger than the 100 x DBL_EPSILON being the threshold for is_zero(value). Increasing the threshold removes the segmentation fault, but I suppose it will come back for smaller shifts again. The local Hamiltonian is fine in that case: -0.265775_C^+(ud,0)C(ud,0) + -0.265775_C^+(ud,1)C(ud,1) + 0.0740137_C^+(ud,2)C(ud,2) + 0.0740137_C^+(ud,3)C(ud,3) + 0.0740137_C^+(ud,4)C(ud,4) + 0.0740137_C^+(ud,5)C(ud,5)

The small differences in the prefactors are due to the employed numerical accuracy in order to determine mu. For me it is fine to choose a slightly larger shift in order to stay at 100 x DBL_EPSILON, however I think a variable is not initilized in case of the segmentation fault which should be present afterwards (case: there is only one large partition of the Hilbert space).

All the best, Marc

[krivenko]

krivenko/triqs@37f4a252b188b7cc381967f662204c07e3e66200 fixes this issue for me. Please test and cherry-pick to the main repository.

[supermarche]

That's it, thanks!

[krivenko]

Ok, now we can close this one.