Interesting issue. some notes if I may:
- Everything looks fine if you run the two calculations (Graphene1.py and Graphene2.py) including the BS analysis. The two BS objects are thus exactly the same. No errors here.
- Instead something is going wrong when you read one of the two BulkConfiguration (nlread part). The possible bug seems somewhere there, we will investigate.
- Because it seems that the problem is not related to k-points, by using 3x3 k-points and SZP basis set allows you to run on a laptop in less then one minute and makes everything faster.
- I noticed you use UnitCell for your bulk configuration. Why not hexagonal?
Dear Dr. Martinez:
Thank you for your attention.
-Yes.
-I think the problem is not in the nlread part:1.it going wrong without "nlread" in some case;2 repeatedly nlread and nlsave, the same structure can be visualized in VNL.
-Yes, it makes everything faster. However, Dr. Blom said "I re-ran your Graphene1.py script with 27x27 k-points and I then get a perfect match to the expected result.", so 27x27 k-points is used for test.
- If conducted atomic reconstruction and no longer hexagonal, this bug still exists. Carbon atomic system with UnitCell is only used for test. In fact, this bug has been encountered in some other complex systems with other elements such as B, N, Mo, S , Si. Coordinate translation could lead to the disappearance and appearance of bug, and I did not know what kind of initial structure could avoid this bug. All I can do is to call QuantumWise Staffs for Help
, for I do not have the source code can be used to debug.