Changes in b vector order

[qiaojunfeng]

I noticed that the order of b vectors has changed in develop branch, probably due to #533 and #498?

@sjhong6230 Is this indeed an incompatibility change (wrt the old version), to make sure those two PRs work? Thanks!

If so, probably we need to add an entry for this in the v4.0 release announcement.

--- a/gaas.nnkp.old
+++ b/gaas.nnkp.new
@@ -1,20 +1,20 @@
-File written on 20Jan2025 at 19:50:46
+# File written on 20Jan2025 at 19:50:32

 begin nnkpts
    8
-     1     2      0   0   0
-     1     3      0   0   0
-     1     5      0   0   0
-     1     8      0   0   0
-     1     2      0   0  -1
-     1     3      0  -1   0
-     1     5     -1   0   0
-     1     8     -1  -1  -1
-     2     1      0   0   0
-     2     4      0   0   0
-     2     6      0   0   0
-     2     1      0   0   1
-     2     7      0   0   1
-     2     4      0  -1   0
-     2     6     -1   0   0
-     2     7     -1  -1   0
+       1       2      0   0   0
+       1       3      0   0   0
+       1       5      0   0   0
+       1       8      0   0   0
+       1       2      0   0  -1
+       1       3      0  -1   0
+       1       5     -1   0   0
+       1       8     -1  -1  -1
+       2       1      0   0   1
+       2       4      0   0   0
+       2       6      0   0   0
+       2       7      0   0   1
+       2       1      0   0   0
+       2       4      0  -1   0
+       2       6     -1   0   0
+       2       7     -1  -1   0

[sjhong6230]

Yes. Since translation invariance and Stengel-Spaldin functional both sum over k-points before b vectors, the order of b vectors should be the same for all k-points.

Thus, I added the kmesh_sort subroutine, and the b vector order in the benchmark file was changed.

Also, the order of elements for the uHu checkpoint files was chabged.

Please let me know if there are some issues with these orders.

[qiaojunfeng]

Thanks @sjhong6230 for the quick reply!

In theory there is no problem with changing the order, it's just a bit unfortunate that we could not reuse the old mmn files anymore.
Have you deleted the old subroutine for generating b vectors? If not and if it's easy, maybe we could add one input parameter to restore the old behaviour (we could still default to the new order)?
But if this is complex and causing difficulties in maintainability, then it's fine, we just need to announce the changes for the new release.

[sjhong6230]

Restoring the old behavior would be easy since the reordering is done in kmesh_sort subroutine, which is done as a post-processing after kmesh_get. Thus, we only need to add one input parameter to disable/enable this subroutine. I think order_b_vectors would be a good name. (true for the reordering, false for the old behavior)

Also, since Stengel-Spaldin functional and translation-invariance works with only sorted kmesh, we should raise an error if order_b_vectors is false for these cases.

[qiaojunfeng]

Sounds good, with this we can maintain some backward compatibility. Would you be willing to create a PR for this? Thanks!

[jryates]

Having discussed this with @JeromeCCP9 I'm proposing the following solution.

We keep the new ordering. We add in a new routine which detects if we have the old or new ordering.

If we are using MV then nothing changes - we can read old or new files without issue.
If we are using SS then we detect if we have an old file - and abort with a helpful error message.

We will need to have some appropriate tests.