2020-05-15 QC Data Meeting notes

TorsionDrive inputs

CS

• Before you submit, conformers generated by OpenEye need to be checked

  • Problem doesn’t seem to be of chemical nature, more that the actual data can be scrambled

• Sometimes weird things happen with fragmenter, unclear if there’s some OE magic that can fix it

• Some obscure bug about positions getting set to 0, unfruitful discussion between CS and OE support, ended up using a workaround in fragmenter; when this was used, it was noted in comments

• TG: Where in fragmenter are these workarounds?

Indicies

CS

Indices may not line up between fragmenter input (parent molecule) and fragment output (fragment molecule)

Checking done by taking fragment, checking indices against parent molecule, and re-generating mapping by canonical cmiles mapping

MCSC (maximum substructure matching? something like that; it’s in OE) can be used as a check for when CS is not around for direct input

fragments know parent smiles, which is not reliably sufficient for re-constructing fragments

TG: Need not just the information, but scripts that are used to generate

Charges

CS

CS: Right now, charges are done by summing up formal charges. Something about multiplicity

Job index <--> atom indices in torsion

CS

We have job index, which stores indices of atoms in torsion being driven. This could be used as a backwards double-check if both are given

Bug from last week

TG: How to re-create the process of finding the most recent bug?

CS: Compared indices of fragment and parent molecule

Wishlist

TG: What do you wish you had?

CS: What I’d want is a dict that maps indices between parent and fragment molecule

TG: Agree, have the provenance but that does not include this information

JH: Do we want fragmenter to return this dictionary?

CS: Yes

JH: When you’re doing a drive, but without fragments, how do you pick dihedral indices?

CS: I’ve never done that work, LPW and group have some rules about picking dihedrals. One way is in-house LPW scripts, another is using OE to select all rotatable bonds

Pulling data

CS: Would be nice to visualize torsion drives. You get the energy, but hard to do science without being about to visualize the drive.

JH: Can do now with Molecule.visualize() if the conformers can be made into a trajectory. Example code somewhere, behavior will be made into a more discrete function at some point

Another request

CS: Would be really nice if you could get a MM torsion drive with torsion parameters set to 0.

TG: Would need to be during submission. Would require

1. QCE doing MM energies (in progress, DD and JH)

2. QCE doing proper partially-constrained torsion drives with MM (existing interest from many groups)

3. Being able to submit a modified force field to the archive

May tie in to functionality currently in ForceBalance

QCSubmit

TG: Seems like QCSubmit does a lot of work with downloading/gathering QCA data, how does it work?

JH: Wanted data for each type of collection (OptimizationCollectionResult, TorsionDriveCollectionResult). Shows example notebook of making one of these classes, downloading metadata in about a second. Locally these classes look about the same as their QCA counterparts; have the same results in them, etc.

TG: How is data downloaded?

JH: (more or less describes what TG did last summer but with a different list of things downloaded in each molecule)

JH/TG: Could allow options to pick what (torsions, hessians, etc.) are actually downloaded

TG: Would be nice to be able to combine datasets. Did this previously with a tree structure that uses iterators to interact with data

JH: Data are collapsed here by default, although keeps initial db id so could be de-collapsed.

Generally agreement TG+JH to work together on building something to better store/search through QC data

TG: Notes that a lot of QCSubmit classes are pretty similar to QCFractal classes in structure. Any particular features that motivated this?

JH: Not necessarily, but wanted to keep it feeling similar to QCFractal