SOMD refactoring

[lohedges]

When adding functionality to SOMD multiple files need to be updated: openmmmdintegrator.h, openmmmdintegrator.cpp, openmmfrenergyst.h, openmmfrenergyst.cpp, openmmfrenergydt.h, openmmfrenergydt.cpp.

These files contain a lot of duplicated functionality that would be better served through a common base class. At present it is very time consuming to add any new feature since it will need to be duplicated in multiple places. In addition, subtle naming convention differences between the files, e.g. openmm_context vs context_openmm means that you can't simply copy and paste between files. Also, in some cases objects are accessed directly, while in other cases they are accessed through a pointer. In some files functionality, e.g. updateBoxDimensions, is encapsulated as a method, where in others in is inlined directly in the code.

While I understand that this is not a direct priority, some effort in this direction would greatly simplify any future development. I would also strongly advise any students working on any SOMD modifications to merge from the feature_triclinic branch (or devel when I've made a pull request) to avoid a large number of merge conflicts in future.

[jmichel80]

A big code cleanup is overdue, but it has been difficult to align this effort with current projects. It would be better to revisit the implementation in line with OpenMM's current functionality that should make the definition of custom non bonded forces easier than when we wrote the original implementation.
openmmfrenergydt.* do not work and should be removed

[lohedges]

Thanks for the info. I was also wondering how much of SOMD could be implemented using the Python APIs for Sire and OpenMM. (Perhaps there is required functionality that isn't exposed to Python.) That could make development / maintenance a lot easier.

[jmichel80]

I fully agree with what you write. I suspect everything we would need is in the OpenMM Python API. There may be problems with the Sire Python API as not all functionality may be exposed in a straightforward manner. Perhaps @chryswoods has more thoughts about this.
In any case a refactoring would be a significant amount of work that needs careful planning.