2020-03-26 Software Scientist Onboarding notes (Thompson version)
Open Force Field onboarding day 3
Wagner
Dotson
Health of the infrastructure
QCSubmit
Doesn't exist yet, being built by Horton, who is very careful
QCPortal
Best corner of the infra, beautifully built by Smith @ MolSSI
QCFractal
In decent shape
Many issues with file systems
Property Estimator
ForceBalance
Frequent pain point
Many heterogenous interfaces, file I/O, etc.
Fundamental issue of representing molecules: can't have all 3
QM - nuclei, charges, not really much else
cheminformatics - "graph"-like object, atoms, elements, bonds,
sterochemistry, aromaticity (everything needed to type using SMIRKS)MM - parametrized system (i.e. including force field)
CMILES
Bridge between QM and cheminformatics (for the interop between QCA and the cheminformatics that ForceBalance needs)
informatics has "allowed" operations, i.e. SMIRKS searching, serialization
this bridges some operations into QM world
QCA has particular criteria for defining two molecules being the "same", which may differ from informatics definitions
QCA criteria is coordinates being similar enough (for purposes of looking up in the DB if a molecule already has QM data)
http://docs.qcarchive.molssi.org/projects/QCElemental/en/stable/model_molecule.html#molecular-hash
Bridge breaks some small % of the time
i.e. proton transfer in QM optimization, resulting in a different informatics
would also break MM parametrization
stereochemistry
charge method in MM world can depend on sterochemical conformation
"stereogenic groups"
can be covered in SMILES, but can change during QM, breaking the bridge
i.e. scanning over a trivalent nitrogen, flipping its chirality though angle of planes
Useful barrier to study in MM world, QCA can do the torsion drive, CMILES representation is different before and after
Further edge case of being completely planar, i.e. between chirality
Lots of scattered glue for various conversion, some value in unifying at least conversions? I.e. any QM->MM representation is done in the same way across people, projects, labs, etc.
Dotson raised an issue on the QM->MM conversion weeks ago in which Wagner detailed the problem, had a hard time finding it
Build process
gh/omnia-md/omnia-recipes
Many deprecated recipes, not really a problem since most things don't depend on each other
Goal is to migrate everything to conda-forge, no small feat but Jaime is making great progress
Major pain point is OpenMM, legacy reasons based around OpenMM's build system conflicting with conda-forge's preference
Once OpenMM can migrate, the levee breaks and the rest of the stack can migrate (hopefully!)
openforcefield #286: Wagner wrote thorough docs on the standard release process
Another time: we will work on improving developer docs (perhaps on another wiki)