SB – Now that FF supports librarycharges, we could have a utility function that does on-the-fly mapping of charge_from_molecules mols into LibraryCharges. Don’t have to do this using create_openmm_system kwargs, instead it could be a special parameterhandler that eats molecules and makes librarycharges.
JW – Could make mol.to_library_charge
MT – mol.to_librarychargehandler?
MT – Do we envision “molecule charges always win” or “ff always wins”?
SB – We don’t offer an automated way to take charges from molecules. Users will always have to modify their FF to contain the molecules librarycharges
MT – Any solution should preserve ability to load+inspect partial charges on mol
JW – Raises question of whether create_openmm_system should be allowed to modify input FF or Topology? Downside is that current users have been trained to not expect these to change.
MT – Instead of modifying FF, we could make a new thing that isn’t a FF (but has records of what happened).
JW – I don’t love the PArameterizationRecord object, since its scope isn’t well defined.
MT – I actually kinda like it, since it would keep us from having to change input Topology or FF. So it could be some mix of different data structures and a log of “what happened”.
MT – Its jurisdiction could be “everything that would have affected the FF or Topology”
JW – Concerned that the above would make it hard to understand when new features/data should be part of Record object versus Top or FF.
MT – No existing info would go in, just explaining how FF applied to Top.
SB – My thinking on this started when I had to figure out whether a molecule was assigned all-zero charges, or nothing had assigned charges. But System object may solve this, by recording provenance of handlers.
SB – Depending on whether System contains Topology, we could consider that contained topology to be the “final topology”. This “final topology” could contain the conformers that actually were used for charge calc (and final charges themselves(?))
MT – Right now, the parameters don’t know how they came into existence. I haven’t dove into difference between input and final topology.
JW – Could have “column labels” for parameter assignment matrix which have all the essential values for energy calcs (eg, all ElectrostaticsColumnLabel objects would have partial_charge), but each could have extensive additional metadata (like,
ToolkitAM1BCCElectrostaticsColumnLabel would have partial_charge, conformers, orig_handler, and maybe even orig_forcefield. conformers could be a pointer to the System’s “final topology” (the one that’s potentially modified from the input, but which has the actual confs used for charge calc.
ChargeIncrementElectrostaticsColumnLabel could have pointers to partial_charge handler, conformers, orig_charge, final_charge (same as partial_charge), charge_increments (list of chargeincrementhandler.chargeincrementtype objects that were applied to the particle)