-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autogenerate modification auto-mappings #604
base: master
Are you sure you want to change the base?
Conversation
@pckroon this seems to cause a flood of warnings:
|
Alright, that is a problem, since the modification mappings are known. I'll dig a bit |
It currently produces the following errors:
The missing |
…es get a 'charge_group'
Alright, this should fix most of the mess, at least regarding charge groups. The AA modifications are still missing some critical data, such as charge and atom types. |
mod_to_out[mod_idx] = out_idx # pylint: disable=undefined-loop-variable | ||
graph_out.nodes[out_idx].update(modification.nodes[mod_idx].get('replace', {})) # pylint: disable=undefined-loop-variable | ||
graph_out.nodes[out_idx]['modifications'] = graph_out.nodes[out_idx].get('modifications', []) | ||
if modification not in graph_out.nodes[out_idx]['modifications']: | ||
graph_out.nodes[out_idx]['modifications'].append(modification) | ||
|
||
# FIXME Jank here to ensure the charge_group attributes look reasonable | ||
charge_group_start = max(graph_out.nodes[mod_to_out[idx]].get('charge_group', 1) for idx in anchors) if anchors else 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is 1 a good default value? Shouldn't all residues at this stage have a charge group?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should? Yes. But I've been bitten by that word too often. Note that the number picked here does get incremented by the number of nodes before this in the modification. Admittedly it's not great, but it's ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't spot anything obvious but had some questions. However, I must admit I hardly comprehend the mapping module so no guarantees. But I assume you tested this? Perhaps worth to add an integration test instead of patching the code coverage with unit tests
|
||
# Time to collect the attributes to set. Start by grabbing all the | ||
# attributes we already have. | ||
node_attrs = deepcopy(graph_out.nodes[out_idx]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
deepcopy because of the graph attribute?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. And paranoia.
for node in graph_out: | ||
for attr in attribute_must: | ||
if attr not in graph_out.nodes[node]: | ||
# We can skip `node`, since if it had the attribute required we | ||
# wouldn't be in this mess to begin with. | ||
# Set a depth_limit to keep the runtime within bounds. | ||
close_nodes = (v for (u, v) in nx.bfs_edges(graph_out, source=node, depth_limit=3)) | ||
for template_node in close_nodes: | ||
if attr in graph_out.nodes[template_node]: | ||
graph_out.nodes[node][attr] = deepcopy(graph_out.nodes[template_node][attr]) | ||
LOGGER.warning("Atom {} did not have a {}, so we took " | ||
"it from atom {} instead.", | ||
format_atom_string(graph_out.nodes[node]), | ||
attr, | ||
format_atom_string(graph_out.nodes[template_node]), | ||
type="inconsistent-data") | ||
break |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get how this can be the case. Is that for hydrogen modifications?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This happens whenever a output particle is made up of only nodes that were reconstructed by repair graph. So unless there's entire sidechains missing you generally only see this with atomistic models, which is why this remained hidden for so long.
I tested this roughly (make an atomistic 1ubq, see if the resulting itp looks mostly reasonable by staring at it). |
@pckroon we're almost there just one ingredient missing: we need to patch the rtp paser to generate all missing dihedrals and pairs do you want to take a stab at it? I'm not saying a complete rewrite just patch |
Doesn't https://github.com/marrink-lab/vermouth-martinize/blob/master/vermouth/gmx/rtp.py#L257 already generate all the dihedrals? (Should, anyway). |
for lysozyme I'm missing like 4000 dihedrals, all angles, and a bunch of bonds. I think Jon just makes the dihedrals for links? Also for charmm cmaps are missing |
No description provided.