General updates | JM - solvation methodologies? Trying to figure out how to solvate box with a protein+ligand for new toolkit showcase. JW – I think I used pdbfixer’s solvate functioanlity for this before (not Modeller). This is OK to deal with all sorts of junk. If it can do the protein but not the ligand, it may be worth solvating just the protein, then putting in the lgiand and deleting any clashing waters.
JM - from_polymer_pdb refactor? JW – Some reasons I like the current functionality OpenMM has a great PDB reader but it can only provide connectivity for things it knows about (namely protein residues). So for other things the user will need to provide CONECT records A lot of people have workflows that result in non-canonical PDBs being made (lots of tools make PDBs with “incorrect” atom names, but where the element can be inferred) I get the sense that perceiving inter-residue bonds is really hard, and I like that OpenMM handles them for us. If we tried to roll our own functionality, that would be one place where our functionality depends on correct PDB hierarchy info. I’d very much prefer that our functionality never depends on PDB hierarchy info.
Priorities for our PDB reading functioanlity Load a spec-compliant protein PDB containing a HIS residue Load a protein PDB containing an HID residue Load a spec-complaint non-protein PDB containing a non-protein residue Load a non-protein PDB containing a misnamed non-protein residue Not require us to directly parse PDB
Scenarios: (General) – Basically, the tradeoff is that we EITHER need atom names specified, OR CONECT records provided, in order to successfully assign the chemical graph of a polymer. JW – I’ve found that a lot of the materials world doesn’t do residue names at all, and don’t use unique atom names JM – Basically, if we’re going to accept HID as a histidine, then we’re already not spec-compliant. Also it’s worth noting that OMM renames HID to HIS JW – Do we need to roll our own PDB parser if something doesn’t match OpenMM’s input expectations? JM – The UX will be a lot better if we do atom names - Right now we can’t tell users which residue template came closest to matching their unknown residue. Also, the assumptions going into atom name matching are much easier to explain. JW – Element graph matching will let us load non-spec-compliant structures from the materials science world, and there are lots of biophysics programs that also give the wrong atom/residue names.
Summary: There are benefits to both. JW wants to get the release candidate out the door as soon as possible so we’ll do the initial release with element-matching. But since we’re only supporting “vanilla” proteins in this release, we can change the matching behavior/backend later when we’ve discussed it more.
|