Only 1 Movecheck failed, is Z2 it still reliable?

[sliutheory]

Dear Developer, I am not sure whether this is an issue.

For my system, even though a very small min_neighbour_dist=0.00001 was used, there was still one failed Movecheck. Poscheck and Gapcheck are both fine.

Following are other parameters |gap_tol: 0.3 | |init_result: None | |iterator: range(10, 35, 4) | |load: True | |load_quiet: True | |min_neighbour_dist: 1e-05 | |move_tol: 0.3 | |num_lines: 101 | |pos_tol: 0.01

I am wondering is there anyway to fix this issue? Is the Z2 calculated still reliable?

Thank you!

[greschd]

Hi,

In general the results are not reliable even if only a single check failed. If you inspect the Wannier charge centre evolution (with z2pack.plot.wcc), I would guess that there is a discontinuity where the move check fails.

The most common cause for this is that the band gap is closed at some point on the surface to be calculated - to be specific, on the line where the move check fails. In that case, the invariants are not well-defined, because the fiber bundle spanned by the occupied states is not smooth.

So, the first thing to check would be whether the system in question actually has a (direct) band gap on the entire surface.

[greschd]

To find gap closures, you may use the NodeFinder tool: https://github.com/greschd/NodeFinder

[falsafi123]

Dear Developer, I have a same problem, would you guide me to improve my results? This is my output. Thanks in advance

|                Calculation finished in 9d 3h 21m 54s                 |
+----------------------------------------------------------------------+

+----------------------------------------------------------------------+
|                         ==================                           |
|                         CONVERGENCE REPORT                           |
|                         ==================                           |
|                                                                      |
|                         Line Convergence                             |
|                         ================                             |
|                                                                      |
|                             PosCheck                                 |
|                             --------                                 |
|                             PASSED: 18 of 19                         |
|                             FAILED: 1 of 19                          |
|                                                                      |
|                         Surface Convergence                          |
|                         ===================                          |
|                                                                      |
|                             GapCheck                                 |
|                             --------                                 |
|                             PASSED: 16 of 18                         |
|                             FAILED: 2 of 18                          |
|                                                                      |
|                             MoveCheck                                |
|                             ---------                                |
|                             PASSED: 14 of 18                         |
|                             FAILED: 4 of 18                          |
+----------------------------------------------------------------------+

Z2 topological invariant at kx = 0: 1 Z2 topological invariant at kx = 0.5: 0

[falsafi123]

Is there any way to continue the calculations or I should restart them? Because this calculation took almost 2 months. Thanks

[greschd]

Hi @falsafi123

First off, yes, you can restart -- the relevant inputs are init_result, or alternatively save_file and load: http://z2pack.ethz.ch/doc/2.1/reference/surface.html#z2pack.surface.run

I think this issue is slightly different, since from the number of lines it seems you are using a larger min_neighbour_dist. In principle you could

• increase the upper limit of the iterator (to solve the PosCheck issue)
• reduce min_neighbour_dist (try to solve the GapCheck and MoveCheck issues)

Both these things will increase the total runtime, so I'm not sure if that is feasible in your case. Maybe converting the system to an effective (e.g. tight-binding) model first would be possible?

The convergence criteria implemented in Z2Pack also tend to err on the side of caution, maybe you can decide by looking at the Wannier charge center evolution that the calculation is "good enough".

[greschd]

Of course, the advice above about making sure the system has a direct band gap still applies.

[falsafi123]

Thank you very much for your fast reply, May I have your email address please? I had some questions, Thanks

[greschd]

Sure, greschd@gmx.ch

[sliutheory]

Thank you, Dominik.

In my case, the system of interest has a gap, though a tiny one, 0.0065 eV. I checked the band structure along high-symmetry lines. Moreover, I carefully checked the gap by using small kpoint spacing. The gap looks like a real one.

Given that I already use a very small min_neighbour_dist=1e-05, it is not clear to me whether there is a way to fix this failed move. See below.

[greschd]

If the band gap is real, you should be able to solve the issue by further decreasing min_neighbour_dist. It's not too uncommon to have very small values of min_neighbour_dist when the band gap is so small.

The reason for this is that the Berry flux is concentrated strongly around the point with a small band gap - so the Wannier charge centers still move continuously, but the change is very quick.

[sliutheory]

Dear Dominik,

I looked into the wcc evolution and find something strange. I already used very small min_neighbour_dist: 1e-08 As you can see, the crossing occurs around k= 0.03. But Z2pack is adding a lot of lines around 0.06746, though there the largest gap position changes smoothly (at least based on my eye...)

[greschd]

Indeed, the gap changes pretty smoothly there. However, the gap position is taken into account only in the "gap check" - the "move check" considers the movement of all WCC. It seems there are (two?) WCC that change abruptly at this value.

[greschd]

This could be either a physical or numerical problem. The potential numerical problem is that the WCC positions themselves are not converged enough. You can try reducing pos_tol, and increasing the upper limit of the iterator if needed.

[greschd]

The physical problem can be approached again by checking for band gap closure - it could well be that the band gap closure is not on a high-symmetry line.

[falsafi123]

Dear Dominik, I am very grateful to you for your help, I have been involved with these questions for a long time and I really thank you for your help. Would you please take a look at my WCC that I sent? In the case of my structure, there is a small gap too, after applying SOC, so maybe we can hope that Chern insulation will be realized? Do you think there is no problem if I have some questions to ask in the future? Thank you very much, Best regards, Nafiseh

On Fri, Apr 17, 2020 at 1:02 AM Dominik Gresch notifications@github.com wrote:

The physical problem can be approached again by checking for band gap closure - it could well be that the band gap closure is not on a high-symmetry line.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Z2PackDev/Z2Pack/issues/87#issuecomment-614879287, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPZFPEJPALRGUH5XYDBTYLRM5TM3ANCNFSM4MICPBRA .