[BUG] AmberPrm reader reorders atoms when molecules are not contiguous in the file

[chryswoods]

Describe the bug
The AmberPrm reader assumes that molecules in a PRMTOP file are written contiguously. It reorders the atoms into molecule/atom rather than file order when a molecule is not contiguous in the file (i.e. if there are multiple protein chains that are separate molecules, and there are bonded metal ions written at the end of all proteins, but which have bonds to individual protein chains. In this case, the metal ions are moved to appear with their protein, which will be a different order to the file order.

This causes problems when this topology is matched with a coordinate file that does not expect the atoms to be reordered (i.e. a RST or CRD file).

Additional context
This is a bug report generated from files shared separately.

[chryswoods]

(note to self)

A possible solution would be to add a System property that marks the topology as being reordered, and giving hints to the coordinate parser as to how to match the coordinates to the atom order. It would be something like system.property("atom_order"), and would be something like index to mean order by the container's atom index, or number to order by the atom number. The default would be index, with number used in this case.

[chryswoods]

(more notes to self)

The change would only need to be made in MoleculeParser (and any frame parsers that use their own logic rather than rely on frame functions defined in MoleculeParser).

The key change would be to inject the reordering at point where frames are pulled from the frame files - the frame should be in an order that matches the index order, meaning re-ordering what is read from the file if the topology was in number order.

The key parts of this class to inject there are;

sire/corelib/src/libs/SireIO/moleculeparser.cpp

Line 1115 in 5867df0

// first, we are going to work with the group of all molecules, which should

sire/corelib/src/libs/SireIO/moleculeparser.cpp

Line 2776 in 5867df0

// data in the same order and that this matches the atomidx order

Fortunately, reordering when reading the frame (and before passing the frame to the rest of the code) should be quick, as it will only be done once and the frame then cached. It could fit into the pipeline of aligning and smoothing.

[chryswoods]

That helped - I've applied the changes in the latest commit which work as described above.