internal go contact map #643
Conversation
- local generation of contact map guaranteed to reproduce one from server - -go argument now accepts either path for file from server, or no argument to use the native implementation
- sometimes vermouth reads in atoms/residues in a strange order. This is seems to go especially weird for heteromers for some reason that I can't figure out. So, we sort out how we deal with reading the system by using a residue graph and making sure we read each residue node in order - Also deal with missing OXT atoms if we have a contact with a modified atom. This is a definite source of error in the implementation in the server, which strictly assumes canonical pdb atom names and order - NB: above error also causes issues for contact map files when the CA atom is not the first one listed. This doesn't actually affect us, because 1) we note CA directly, 2) it's not actually needed for the contact map in the end. - fix up some other imports/linting
vermouth/rcsu/contact_map.py
Outdated
| for node in G.nodes: | ||
| # we only need these for writing at the end | ||
| resnames.append(G.nodes[node]['resname']) | ||
| resids.append(G.nodes[node]['resid']) | ||
| chains.append(G.nodes[node]['chain']) | ||
| nodes.append(G.nodes[node]['_res_serial']) | ||
|
|
||
| res_pos = [] | ||
| for subnode in sorted(G.nodes[node]['graph'].nodes): |
There was a problem hiding this comment.
I suggest not sorting, and just building a dict of graph_idx: array_idx
vermouth/rcsu/contact_map.py
Outdated
| return cogs, vdw_list, atypes, coords, res_serial, resids, chains, resnames, nodes, ca_pos, nresidues, G | ||
|
|
||
|
|
||
| def calculate_contact_map(cogs, vdw_list, atypes, coords, res_serial, |
There was a problem hiding this comment.
It's starting to shape up very nicely! Awesome work so far.
For the next pass, besides the comments, could you also have a look at the functions you create, and decide whether those will have a use beyond the go map? If not, mark them as private (prefix a _).
Some functions also need a lot of arguments, and return a lot of different things. Do you think there's any chance we could simplify that?
…earranged dictionary
|
That should be all the more minor points addressed, the main one being how to improve the atom2res function. (had to push this now because my laptop keeps losing the .git in my clone somehow?! feel free to ignore until I've addressed everything) We have to use I've had a look at using dictionaries instead for the atomic resolution arrays. I'm still not sure it's possible/advisable with the way I've currently written it? Or at least, I'd rather get all the other jobs above sorted and revisit that later if we think there might be substantial advantage. I agree, the arrays are pretty sparse - but they aren't completely, which is slightly annoying. |
changed file writer to deferred file writer added cli to write file if desired changed function names for internal use made bond_type a global variable and removed function corrected error in sphere generation moved system merging to martinize2
|
I think that's as much as we need for now. some other things to deal with:
|
- nodes -> res_idx - now specify name of contact map file to be written with changes to -go-file-write
Calculate the contact map for the go model without an externally generated input file.
CLI changes:
-gonow accepts either a file in the standard form, or just-goto calculate internally.implementation of the contact map: