Pol Febrer Calabozo

Done! Everything is there, including docs. You can reorganize the docs as you wish.

I want to push this forward to use it for QM/MM geometries, should I start a new branch and create a separate PR?

Hmm but wouldn't it be ambiguous, because the neighbor of `ia` is not fully defined by `ja`? You need the supercell indices to have the connection fully described. Unless of...

The way I see it the finder should just find. If someone later wants to convert the indices according to a given auxiliary cell and a given ordering convention they...

I don't know what you agreed to, but to me it doesn't look like we agree :sweat_smile:

Ah ok, yes on `Geometry.close` I think keeping the current behavior is the way to go!

And what should the finder do, return `nsc` as well? If the neighbors are requested only for a given atom, how can the finder know `nsc`? `nsc` in SIESTA is...

So `nsc` should be determined before using the finder? And the finder should not return neighbors outside that auxiliary cell? I think both things can coexist. There can be a...

I like the idea that the finder returns this class! But do you think that `Geometry.close` needs to be changed? This can be something that the finder returns and then...

Hmm but changing this in `close` would be chaos for everyone, no? :sweat_smile: Also I think there is fine, because it's something more tied to the `Geometry` class. I see...