operation.chain assumes your next molecule is going on the last added molecule only about kappa

[ajkerr0]

I think I've figured out that the nextIndexI code in operation.chain doesn't consider cases where the nextIndexI is part of the current molecule1 and not molecule2.

[ajkerr0]

What's happening is chain is used assuming that the next molecule is being attached to molecule2 of the last attachment.

[ajkerr0]

Maybe we should resort to using _combine for non-successive attachments? But I like the idea of forcing a Molecule.configure call when the process is completed. [.configure is] Totally wasteful in a multi-attachment process and takes a considerable amount of time with this large molecules like CNTs.

[ajkerr0]

I could keep chain but switch between the use of nextIndexI with the use of a keyword argument that defaults to not using it? Ultimately a question of design I think.

Maybe _configure should only be called when it is explicitly needed, or make the user call it when needed and want access to those generated attributes. define_energy/gradient_routine is (atm) supposed to be called when needed (like preceeding energy minimization).

[ajkerr0]

I could do something where if the inputted indices are negative, then attach them to molecule1. But that would require the user to know this. It may be more straightforward, however more cluttered, to use a keyword argument that defaults to to something.

[ajkerr0]

Going to close the issue. Documentation should reflect this specific use of .chain now. It was more important to be aware of the function, it was not actually an issue with the code.