Topology update calls #85
Conversation
…atomtype functionals, connectiontype functionals. Global topology update calls
…tead, make an empty list and add as you iterate
topology/tests/test_topology.py
Outdated
| top.add_site(site1) | ||
| site2 = Site(name='site2', atom_type=atomtype) | ||
| top.add_site(site2) | ||
| top.update_top() |
There was a problem hiding this comment.
I think we should have some asserts before this call so we can be sure we're updating what we want to update
…pdate toplogy, assert some change
|
Just recording a few general comments:
This approach of storing high-level summarizes of many low-level details will be useful for many things in the future, but now #52 #80 (similar ideas) are good examples |
topology/core/site.py
Outdated
| @@ -29,6 +29,18 @@ def __init__(self, | |||
| self._connections = list() | |||
|
|
|||
| def add_connection(self, other_site): | |||
There was a problem hiding this comment.
Hmm. this could get confusing since site and top have the same method name.
What would be the difference if someone used top.add_connection but the connectionType was just None
topology/core/topology.py
Outdated
|
|
||
| @property | ||
| def connection_type_functionals(self): | ||
| return [ctype.potential_function for ctype in self.connection_types] |
There was a problem hiding this comment.
ctype is very close in name to the python standard lib ctypes
might be better to call this contype?
| self.update_connection_list() | ||
| self.update_connection_types() | ||
|
|
||
| def update_atom_types(self): |
There was a problem hiding this comment.
This is fine for right now, but I can see this being an issue with a large system and you only change one atom type.
…ring the code to be more organized
|
Summary of what
Design concerns:
This seems like a parallelism issue. So I'd like to get some opinions on how we should handle all these attributes (uniformly go with method 1, 2, or 3? Or handle all these attributes differently). Furthermore, we have some attributes in topology like |
|
For example, one option is that we never store information about bonds, angles, bondtypes, angletypes. We merely store the entire connection_list, connection_types. Upon a call to |
|
@ahy3nz Thinking about it more, I'm definitely confusing the purpose of topology with that of mBuild. I agree that validation functions in topology would be great. |
… as we add things
…s if adding redundant objects. Re-work update functions to not 'reset and rebuild' lists, just 'append' to the lists if something new presents itself
…include update site list function (might not be necessary?)
|
I think this is ready for review. We have copious Still some design/syntactical discussion that might be worth having: #85 (comment) |
|
Just a few scattered ideas (good luck following my thoughts):
It's hard to say until we get to experimenting with large systems, but I have a strong suspicion that the following are both true:
A potential problem with automatically finding connections is that strictly speaking, many systems include tons of dihedrals even though only a small amount of them matter. On naming conventions, I prefer On the neighbor-searching idea: I'm leaning toward keeping it how it is right now, but I would like to be sure of it.
Just to be clear, are you pointing out that this is the way it is or it's the way it should be? Because I think it's the way it should be ... maybe. It makes sense to have parts of an angle exist as bonds, but I guess there may be cases in which full force field parametrization includes a few un-parametrized parts? |
|
That was an unfortunate misclick - not only is this a good PR but I wasn't even done writing my comment |
|
@mattwthompson I completely agree. topology is just a container. The other stuff (i.e. automatically finding angles) should be handled by mBuild or some similar program. I still think the searching could be good for sanity checks, like @ahy3nz mentioned, but adding connections and bonds should be limited to just those specific functions since searching through the connection list will become prohibitively expensive as the size of the system grows. |
|
Summary:
I think this is ready for review |
|
Is there something up with angles? >>> from topology.external.convert_parmed import from_parmed
>>> from topology.utils.io import get_fn
>>> import parmed as pmd
>>> struct = pmd.load_file(get_fn('ethane.top'), xyz=get_fn('ethane.gro'))
>>> top = from_parmed(struct)
>>> struct.angle_types
TrackedList([
<AngleType; k=37.500, theteq=110.700>
<AngleType; k=33.000, theteq=107.800>
])
>>> top.angle_types
[]
>>> top.angle_type_expressions
[]
>>> top.bond_type_expressions
[0.5*k*(r - r_eq)**2]
>>> top.atom_type_expressions
[4*epsilon*(-sigma**6/r**6 + sigma**12/r**12)]Other than this, I agree with the above comment, tests are passing for me, and I think this is good to merge |
|
Oh that's because I didn't update the parmed converter, one moment.. |
|
Should be good now. I did my due diligence for verifying units (notice pmd.angletype k uses rad, but pmd.angletype theteq uses deg). I encourage others to call me out on any of these unit/off-by-two discrepancies. #31 |
|
💥 |
#84
Tests included