search

OrderN / CONQUEST-release

Full public release of large scale and linear scaling DFT code CONQUEST
http://www.order-n.org/
MIT License
94 stars 24 forks source link

Non-halo atom error in set_bucket_module.f90 #306

Closed davidbowler closed 3 months ago

davidbowler commented 3 months ago

Under certain very specific circumstances (when the S range is exactly the size of the cell in one dimension) we get an error from set_bucket_module.f90 which reads ERROR : non-halo atom1 ! in setup_recvME. I thought that we had an existing issue on this (or had fixed it) but it still occurs for the attached 32 atom cell.

I think that the problem is that we extend the PAO range to be an integer number of grid points, and when that fits exactly into the cell there is some rounding error (at least this is my guess!). @tsuyoshi38 do you remember this problem?

The attached files give me the error when run on 1 or 8 processes.

NonHaloAtomError.zip

tsuyoshi38 commented 3 months ago

Under certain very specific circumstances (when the S range is exactly the size of the cell in one dimension) we get an error from set_bucket_module.f90 which reads ERROR : non-halo atom1 ! in setup_recvME. I thought that we had an existing issue on this (or had fixed it) but it still occurs for the attached 32 atom cell.

I think that the problem is that we extend the PAO range to be an integer number of grid points, and when that fits exactly into the cell there is some rounding error (at least this is my guess!). @tsuyoshi38 do you remember this problem?

As I wrote in my e-mail this morning, I also worked for solving this problem last evening and noticed the condition when it happens. I planned to suggest increasing the support function range a little (by RD_ERR) by changing dimens_module. But, I will consider your suggestions (not shown here...) and will reply to you soon.

tsuyoshi38 commented 3 months ago

@davidbowler I have just approved your pull request. Thank you very much for finding the inconsistent points (my bugs) in finding the neighbors of atoms or atom-grid. (I am sorry for my silly bugs. When I coded these parts, I assumed (I think..) that we should not have a pair whose distance is exactly the cutoff. But, I should have decided a rule whether I should consider it as a pair or not in such a case.)

I think.. we did not have the present problem when the range of support functions is not a multiple of grid spacing. With your correction, the problem is probably solved. But. I still think it may be better to have some margin (but much larger than RD_ERR) for support range, to guarantee that all grid points having non-zero value of support functions are within the support range. The present definition should satisfy this, but I should check whether the range is redefined when the lattice parameters change during the NPT simulation. (I will check it later, but I don't have time now.)

davidbowler commented 3 months ago

Fixed by #307