Constraints in Avogadro2

Development
1

Follow up of Command Scripts JSON documentation - #7 by kantundpeterpan

It would be cool to have the interface from Avogadro1 (or something similar/better) to implement the addition of constraints.

A new json entry might do the trick for passing the constraints to scripts for fixing certain coordinates (position, distance, angle, torsion):

{'constraints':
   { 
    'position':[atom_id1, atom_id2,...],
    'distance':[(atom_id1, atom_id2, dist1'),...]
    'angle':[(atom_id1, atom_id2, atom_id3, angle1),...],
    'dihedral':[(atom_id1, atom_id2, atom_id3, atom_id3, torsion1),...]
   }
}

Together with being able to pass multiple fileformats, it should be straightforward to implement these constraints using the appropriate functions in RDKit before minimization.

I would also like to get these functionality using the Parsley forcefield/OpenMM but the implementation seems not as straightforward.

2

Yeah, Iā€™m not 100% sold on the user interface. Iā€™d like to adopt the Atom / Bond / Angle / Torsion spreadsheets from Avogadro 1 and then make it possible to add a constraint from that dialog.

Ideas welcome.

The JSON seems reasonable. The catch is:

  • Implementing the UI
  • Adding the constraint code to the new force field engine
  • Passing the constraints into CJSON and other sources. (commands, generators, etc.)

I can imagine it would be nice to pass the constraints to QM interfaces to enable constrained optimization in Gaussian / Orca, etc.

3

OpenMM integration would be very nice - beyond Python are you willing to do some C++? If so, Iā€™m happy to give some pointers.

4

Keeping the spreadsheet dialog from Avogadro1 was exactly what I had in mind.

I admit that I did not think at all about the QM input generators - I agree that it would be nice to be able to apply the constraints there, too. I have only some modest experience with MOPAC, setting the optimization flags for specific coordinates is rather tedious within the input file itself (maybe I miss a trick or two).
What comes to my mind is something like ASE. That could provide a generic interface for implementing constraints but might also bring a loss in flexibility further down the line because of the calculator interfaces implemented there.

5

Definitely willing to do some C++ - but no experience. I would like to try but thatā€™s something in the longer term. My knowledge of C++ is superficial to point that I was even confused by the expression ā€œgive some pointersā€ (in combination with an insufficient command of English :smile:).

6

It has been a while, finally I tried to port the Constraints dialog from Avogadro 1.2 to Avogadro2.

image
image1226Ɨ958 93.3 KB

I added a constraints attribute to the QtGui::Molecule class definition to store the constraints - maybe there is a more ā€œplug-inicā€ way of doing that ? Basically it is the code from Avogadro 1.2 adapted as a Plugin for Avogadro2. As this ismy first attempt of programming in C++ it is probably quite a mess and needs some review.

On top of that would it would also be my first contribution to a an open-source project - so, what would be the next step to proceed (pull request?)?

1 Like
7

Yes, the next step would be submitting a pull request and we can help you through review / cleanup.

This would be great incentive for me to finish the force field work with constraints. :slight_smile:

8

I am still working on an implementation of the Constraint class itself. In the beginning I had something really simply that was basically just an array of numbers

constraint = (constraint_type, value, atom1, atom2 ā€¦)

But I figured that it would be more convenient to somehow link the constraint directly to the atoms, so that changes in the molecule would automatically be reflected in the contraints. But I am having some trouble to understand how the atoms are actually stored - are there any ā€œAtom objectsā€ that persist and that have their characteristics updated upon molecule changes?

9

Your data structure is essentially what I drafted, using an enum for the constraint type (distance, angle, torsion)

Atoms are stored as indexes. That makes it a bit difficult to track constraints - there probably needs to be some code particularly to update constraints when atoms are removed.

Happy to help work through some of that.

10

For tracking the constraints I stored the uniqueIDs of the atoms so that the current indices can easily be retrieved.