What info would be useful? LibraryCharge assignments? CIMH initial charges and chargeincrements (so, more than just "final charge" values? Entire NN structure?
Return a modified Topology or create a new ParameterizationRecord object?
What to do about "duplication" of info? Molecules have charges, and also systems. Should we deduplicate? Who should keep final charges?
Should start by defining what it should do/API needs -- particle index --> ParameterType? (LibraryCharges is one-to-many) JW – Could define an API between charge-assigning PHs and ElectrostaticsHandler. Then, user who wants to query individual charge method could leverage the API and not need an ElectrostaticsHandler. JW – Which object “owns” partial charge? Molecules? FFs? Systems? Sometimes it comes from each 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)
|
MT – Are we in a lot of trouble if we stop using OpenMM systems, since we were using it as a “messenger” between different parameterhandlers? MT – Storing partial charges in Toolkit objects is probably bad, since, if the charges need to live in one single place, they need to be in the System. SB – ParameterHandlers should have input of System, and output of System SB – Could consider having a Molecule SUBCLASS which is capable of taking its own charges and producing librarycharges. MT – Agree with SB on molecule subclass. SB – Should consider saying that “Molecule is anything that can be encoded in SMIRKS”, and there may be strictly-optional extras on top Big questions – Can we change the topology during parameterization? If so, how do we allow access to it later? How should vsites be represented? MT – Not sure how the dependent positions of vsites should be recorded in the System object. But atomic positions will be stored. JW + SB – Best to NOT store vsite positions, but rather have them stored as an intermediate in energy eval.
SB – Vsites shouldn’t be in topology, since they’re derived information based on the interaction between the FF and atomic topology.
|