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.

[jryates]

These is my latest thoughts, following further discussion with @JeromeCCP9

To summarise my understanding:

• The currently committed code has changed the order of the b-vectors - this enables the SS version of the spread, and the translationally invariant position operator.
• The Mmn matrix is robust to b-vector ordering. This means that wannier90.x is compatible with old input files (and indeed v3.0 will work with v4x files)
• The incompatibility arises with postw90.x and anything that uses uHu and similar files.
• The uHu (etc) files do not, by themselves, contain sufficient information to detect what b-vector ordering is used.

My proposal

• v4.x will always use the new ordering.
• We don't allow users to change the ordering.
• There will be no backward or forwards compatibility issue with any wannier90.x calculation.
• We need to prevent postw90.x calculations reading old input files and giving the wrong answer.
• The only way I can see to do this is to write a routine to parse the ordering from the Mmn file - and to compare to the program's own ordering. If this differs we stop the calculation (to be safe we could do this for all of postw90.x but with careful testing we could limit this to spin-hall, orbital magnetisation and gyro-tropic?
• One could write routines to re-order the uHu data after reading. I suggest that this is more effort than it is worth.

So, I am proposing declining this PR - and I will make a new one which has a routine to detect non-v4.x ordering from the Mmn files.

Comments welcome!