"ERROR: Negative bin computed" for lattice vectors with negative component?

[acroy]

It seems there is an issue in the serial calculator when a component of one of the lattice vectors is negative. I took the first frame of the nonorth2 example in test_suite-lsq - basically graphene I guess. This works fine with the python example of the serial_chimes_calculator. Then I changed the cell vectors to have 120 degrees instead of 60 and remapped the atom positions into the new cell. Now the calculator fails with "ERROR: Negative bin computed". The files are attached.

As an aside remark, I think it is not good to call exit in the library code as there is no way to catch that in the program calling into the library.

params.txt
input-60.xyz.txt
input-120.xyz.txt

[nirgoldman]

This sounds very much like an issue we fixed with the neighbor lists a couple of years ago. Those changes were merged into the develop branch, and might not have made it into the main branch yet. Please try checking out develop and trying again. Let us know. From: acroy ***@***.***> Reply-To: rk-lindsey/chimes_calculator ***@***.***> Date: Friday, April 19, 2024 at 11:41 AM To: rk-lindsey/chimes_calculator ***@***.***> Cc: Subscribed ***@***.***> Subject: [rk-lindsey/chimes_calculator] "ERROR: Negative bin computed" for lattice vectors with negative component? (Issue #63) It seems there is an issue in the serial calculator when a component of one of the lattice vectors is negative. I took the first frame of the nonorth2 example in test_suite-lsq<https://urldefense.us/v3/__https:/github.com/rk-lindsey/chimes_lsq/tree/main/test_suite-lsq__;!!G2kpM7uM-TzIFchu!1g7UJtFSiV1fhHMo3EsssGZUWpW5b1VrRUWdHO7cwlI1LFKRC9x35vzcU9Dug6T2CwgBbL3-MKQhDzwL97CHaBO0MddN$> - basically graphene I guess. This works fine with the python example of the serial_chimes_calculator. Then I changed the cell vectors to have 120 degrees instead of 60 and remapped the atom positions into the new cell. Now the calculator fails with "ERROR: Negative bin computed". The files are attached. As an aside remark, I think it is not good to call exit in the library code as there is no way to catch that in the program calling into the library. params.txt<https://urldefense.us/v3/__https:/github.com/rk-lindsey/chimes_calculator/files/15044465/params.txt__;!!G2kpM7uM-TzIFchu!1g7UJtFSiV1fhHMo3EsssGZUWpW5b1VrRUWdHO7cwlI1LFKRC9x35vzcU9Dug6T2CwgBbL3-MKQhDzwL97CHaE9Rlpi0$> input-60.xyz.txt<https://urldefense.us/v3/__https:/github.com/rk-lindsey/chimes_calculator/files/15044466/input-60.xyz.txt__;!!G2kpM7uM-TzIFchu!1g7UJtFSiV1fhHMo3EsssGZUWpW5b1VrRUWdHO7cwlI1LFKRC9x35vzcU9Dug6T2CwgBbL3-MKQhDzwL97CHaLcc3Erg$> input-120.xyz.txt<https://urldefense.us/v3/__https:/github.com/rk-lindsey/chimes_calculator/files/15044467/input-120.xyz.txt__;!!G2kpM7uM-TzIFchu!1g7UJtFSiV1fhHMo3EsssGZUWpW5b1VrRUWdHO7cwlI1LFKRC9x35vzcU9Dug6T2CwgBbL3-MKQhDzwL97CHaOdrFwqg$> — Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https:/github.com/rk-lindsey/chimes_calculator/issues/63__;!!G2kpM7uM-TzIFchu!1g7UJtFSiV1fhHMo3EsssGZUWpW5b1VrRUWdHO7cwlI1LFKRC9x35vzcU9Dug6T2CwgBbL3-MKQhDzwL97CHaHj5pGOB$>, or unsubscribe<https://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/AG63FL7RYOZD44B7TEAJVV3Y6FQL3AVCNFSM6AAAAABGPU5D7KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2TGNRWHAYDIMY__;!!G2kpM7uM-TzIFchu!1g7UJtFSiV1fhHMo3EsssGZUWpW5b1VrRUWdHO7cwlI1LFKRC9x35vzcU9Dug6T2CwgBbL3-MKQhDzwL97CHaP5xmjEO$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[acroy]

Nope. Same behavior on develop. (there doesn't seem to be a difference between main and develop?)

[acroy]

I think the problem is that xlo, ylo, zlo are not taken into account when calculating the bin indices:

chimes_calculator/serial_interface/src/serial_chimes_interface.cpp

Lines 615 to 617 in 8cd2bc7

	bin_x_idx = floor( (sys_x[i] + extent_x * n_layers) / search_dist ) + 1;
	bin_y_idx = floor( (sys_y[i] + extent_y * n_layers) / search_dist ) + 1;
	bin_z_idx = floor( (sys_z[i] + extent_z * n_layers) / search_dist ) + 1;

(and a bit further down)

[nirgoldman]

Thanks for your attention to detail. It looks like the neighbor list correction did not get propagated to this repo after all. I should have a PR submitted by Monday.

[nirgoldman]

@acroy: I just submitted a hotfix PR for this issue (#64). I was able to run your test example and got agreement to the sixth decimal place for input-60.xyz and input-120.xyz for the energies and stress tensor components. Please test and let us know if there are additional issues.

[acroy]

Thanks for the quick response! I checked it and your PR fixes my problem. Maybe the input files could be part of the test to avoid regressions?

I haven't checked how the integration into LAMMPS or DFTB works, but does that mean that they have the same problem at the moment?

If you don't mind I will open another issue regarding the usage of "exit". I do think this is problematic (e.g. I was using chimes from a Jupyter notebook and the "negative bin error" killed the kernel).

[nirgoldman]

The same issue could exist with DFTB+ but isn't likely with LAMMPS. ChIMES/LAMMPS integration is achieved through the somewhat simpler chimesFF interface, which doesn't require passing cell lattice vectors to the ChIMES calculator.