Comments (4)
Do PotentialHandlers need order? I get the sense that energy computation should be order-independent. A System
will only need to know about order in the case of reparameterization, in which case the ForceField
will contain the ordering logic.
from openff-interchange.
The energy evaluation part should not, but the parametrization part should. If that logic stays in the toolkit, then it won't think much changed between the OpenMM System present and OpenFF System future. This might come down to the question of ForceField.create_openff_system
vs. System.parametrize(topology, forcefield, ...)
. A downside of the current monkey-patching is that the responsibility is blurred:
https://github.com/openforcefield/openff-system/blob/f3a48953d50d1b806c7c10f0142cf6f92f70a0be/openff/system/stubs.py#L27-L51
Now, order doesn't need to be enforced, because the Electrostatics
tagged is hacked together to only store the partial charge. But you can see that if it called the other handlers, order would be more relevant, as is in the toolkit now.
from openff-interchange.
Another case: constraints usually don't specify the distance they're to be constrained to.
<Constraints version="0.3">
<!-- constrain all bonds to hydrogen to their equilibrium bond length -->
<Constraint smirks="[#1:1]-[*:2]" id="c1"></Constraint>
</Constraints>
The equilibrium bond length is supposed to be derived from bonds, meaning a constrained bond (i.e. any H-X bond here) will need to be gather information from two separate handlers. The toolkit handles this completely, as far as I can tell, but the details are baked into the create_force
functions (alongside OpenMM details), not only the find_matches
part, which is where the typing step happens. There are several details to consider, which I won't repeat except for copy+pasting
Here's the section of the SMIRNOFF spec:
<Constraints>
Bond length or angle constraints can be specified through a <Constraints>
block, which can constrain bonds to their equilibrium lengths or specify an interatomic constraint distance.
Two atoms must be tagged in the smirks
attribute of each <Constraint>
record.
To constrain the separation between two atoms to their equilibrium bond length, it is critical that a <Bonds>
record be specified for those atoms:
<Constraints version="0.3" >
<!-- constrain all bonds to hydrogen to their equilibrium bond length -->
<Constraint smirks="[#1:1]-[*:2]" />
</Constraints>
Note that the two atoms must be bonded in the specified Topology
for the equilibrium bond length to be used.
To specify the constraint distance, or constrain two atoms that are not directly bonded (such as the hydrogens in rigid water models), specify the distance
attribute (and optional distance_unit
attribute for the <Constraints>
tag):
<Constraints version="0.3">
<!-- constrain water O-H bond to equilibrium bond length (overrides earlier constraint) -->
<Constraint smirks="[#1:1]-[#8X2H2:2]-[#1]" distance="0.9572*angstrom"/>
<!-- constrain water H...H, calculating equilibrium length from H-O-H equilibrium angle and H-O equilibrium bond lengths -->
<Constraint smirks="[#1:1]-[#8X2H2]-[#1:2]" distance="1.8532*angstrom"/>
</Constraints>
Typical molecular simulation practice is to constrain all bonds to hydrogen to their equilibrium bond lengths and enforce rigid TIP3P geometry on water molecules:
<Constraints version="0.3">
<!-- constrain all bonds to hydrogen to their equilibrium bond length -->
<Constraint smirks="[#1:1]-[*:2]" />
<!-- TIP3P rigid water -->
<Constraint smirks="[#1:1]-[#8X2H2:2]-[#1]" distance="0.9572*angstrom"/>
<Constraint smirks="[#1:1]-[#8X2H2]-[#1:2]" distance="1.8532*angstrom"/>
</Constraints>
Constraint section tag version | Required tag attributes and default values | Required parameter attributes | Optional parameter attributes |
---|---|---|---|
0.3 | smirks |
distance |
from openff-interchange.
This is no longer needed after refactoring from Chain of Responsibility to something more like a Builder pattern.
from openff-interchange.
Related Issues (20)
- Electrostatics key mismatch after combination HOT 3
- Positions of `MonovalentLonePair` virtual sites is incorrect (does not affect simulations) HOT 1
- Virtual site parameters can clash if looked up using only SMIRKS HOT 4
- `experimental/openmmforcefields/gaff.ipynb` and `ligand_in_water.ipynb` notebooks broken on OpenFF Docs HOT 1
- units for `Interchange.collection['Bonds'].get_system_parameters()` HOT 2
- Support GROMACS's `3fad` virtual sites
- `get_positions_with_virtual_sites` does not collate virtual sites with molecules HOT 1
- Some combinations of Interchanges do not commute HOT 2
- Improved LAMMPS support. HOT 2
- LAMMPS versions prior to 2023.08.02 are incompatible with Interchange, but may be installed with it HOT 2
- Interchange.to_gromacs() creates a topology with far too many atomtypes, which influences GROMACS performance HOT 4
- Syncing topology and `Interchange` attributes
- Easier indexing into collections
- Look into ordering of charge dictionary
- Combining a Sage interchange with one loaded from OpenMM fails because the electrostatics cutoff is not set by the OpenMM importer, but is checked by the `combine` method HOT 1
- GROMACS writer chokes without unique molecule names HOT 5
- `experimental/openmmforcefields/gaff.ipynb` is failing on openff-docs HOT 3
- Dihedrals lost in `Interchange.from_gromacs` HOT 1
- PACKMOL wrapper with >100,000 atoms HOT 6
- Make `Interchange.topology` required? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openff-interchange.