Add options for sorting b vectors

[sjhong6230]

This pull request adds the option of sorting the b vectors. This resolves the issue #538.

The checkpoint files modified to sorted b vector orders in #498 and #533 were restored to the previous b vector order for backward compatibility.

The default value of order_b_vectors is false. Also, it raises an error if one does not sort the b vectors for Stengel-Spaldin functional or translation invariance.

[qiaojunfeng]

Probably we need to add this check to the library interface w90_input_setopt as well, i.e. after this line

wannier90/src/library_interface.F90

Line 347 in 93f4abf

common_data%comm)

But this will duplicate the same code, pinging @JeromeCCP9 maybe you have a better place of organizing these checks?

[qiaojunfeng]

In addition, there is a binary file libwan2.a got committed into the develop branch in a previous PR, could you delete that file as well?

[JeromeCCP9]

Hi Junfeng! I did that removal in pr #540

[JeromeCCP9]

Dear Seung-Ju and Junfeng,

please can you tell me why we don't simply always sort the b-vectors? (i.e. default kmesh_input%order_b_vectors to T)

Is the sort algorithm ok, or does it scale terribly or so?

This would allow the Stengler-Spalding functional to be activated with only a single option setting, which clearly is preferable. If somebody requires the "not-sorted" behaviour, then they would deliberately choose to deactivate the sorting.

With many thanks,
J.

[qiaojunfeng]

Hi Jerome,

please can you tell me why we don't simply always sort the b-vectors? (i.e. default kmesh_input%order_b_vectors to T)

It is simply because of backward compatibility. The order of b-vectors will influence the mmn file. If we want wannier90 v4 to be able to read mmn files from wannier90 v3 (without user adding this parameter to win file), then we need to default order_b_vectors to false.

Is the sort algorithm ok, or does it scale terribly or so?

I think the scaling is fine.

This would allow the Stengler-Spalding functional to be activated with only a single option setting, which clearly is preferable. If somebody requires the "not-sorted" behaviour, then they would deliberately choose to deactivate the sorting.

It might be a little bit inconvenient (or dangerous) for a user--I ran develop-branch wannier90.x on top of old mmn/eig/chk/win files and got strange position operator.

But since v4 changes a lot, we can default it to true and mention this is a breaking change in the release note to users, then it should be fine.

Best,
Junfeng

[JeromeCCP9]

Hi! I see! Yes, this is more tricky than it seemed :)

Maybe we could look at it the other way around:

w90 sets up it's vectors in whatever order it currently follows (so, the nnkp files will be the same, and so the mmn, etc remain backwards compatible) and if we need sorted b-vectors (eg for the S.S. functional) then we apply this b-vector permutation to the (already readin) mmn, etc?

This way would mean that the ordering exposed to the outside world remains the same as before and it allows the S.S. method to be used for existing mmn, etc, data.

[qiaojunfeng]

w90 sets up it's vectors in whatever order it currently follows (so, the nnkp files will be the same, and so the mmn, etc remain backwards compatible) and if we need sorted b-vectors (eg for the S.S. functional) then we apply this b-vector permutation to the (already readin) mmn, etc?

This way would mean that the ordering exposed to the outside world remains the same as before and it allows the S.S. method to be used for existing mmn, etc, data.

So you mean the S.S. method will explicitly sort bvector after reading the "standard" mmn files? Then this means we can always use the same mmn, that would be the most perfect solution.

The only catch is that, one needs to implement this sorting function after reading mmn when S.S. is enabled, not sure how complex would this cause to the code structure? Also, not only mmn, one also need to sort the uHu, uIu, sHu, sIu files, i.e. all files involving bvectors.

[sjhong6230]

Sorry for the late reply.

So you mean the S.S. method will explicitly sort bvector after reading the "standard" mmn files? Then this means we can always use the same mmn, that would be the most perfect solution.

Actually, the mmn files are not affected by the sorting since mmn files contain the neighbor information for each k points, that is, they contain the neighbor information of nnkp file. Thus, the program automatically finds the right neighbor for mmn files for both cases.

The only catch is that, one needs to implement this sorting function after reading mmn when S.S. is enabled, not sure how complex would this cause to the code structure? Also, not only mmn, one also need to sort the uHu, uIu, sHu, sIu files, i.e. all files involving vectors.

The problems are in uHu, uIu, sHu, sIu files. They do not contain the neighbor information of nnkp file. Thus, the files would not work if they were created with order_b_vectors=F and run with order_b_vectors=T, and vice versa.