mapping affected by charge assignation

[ijpulidos]

While implementing validation tests for partial charge assignation in the NEQ cycling protocol in OpenFreeEnergy/feflow#49 we have seen some difficulties in debugging an issue that is generated by "naively" attempting to use a LigandAtomMapping object that was generated before the partial charges assignation, resulting in very obscure NaN results downstream when minimizing with OpenMM.

From a code standpoint it is completely understandable that by doing this we are modifying the underlying components and therefore the previously generated mapping doesn't refer to the same components, hence the need to generate it again with the newly modified components. What I find hard to grasp about this approach is that I consider that a protocol developer (and a protocol user) would not expect partial charge assignation to change anything in the atom mapping used in the transformation. This subtle underlying relation between the two is very surprising for me.

I consider this to be a real footgun that potentially creates hard to debug issues downstream. It is possible to work around this using specific validations in protocols, but I believe that a more general approach upstream (in gufe) is probably desired. Considering that it's potentially not only with partial charge assignation but any type of parameters or properties that can be changed in the underlying data types.

In general, I think we should also consider discouraging the use of components from the mapping objects.