Refactor write_tcl_script

[ftclark3]

Description

I would like to refactor frustration.write_tcl_script() to accomplish three goals:

• Support sparse matrices: Generally, the mask and/or distance_matrix arguments may be instances of @cabb99's new SparseMatrix class. In the present state of this branch, all sparse matrices are converted to dense matrices. This is probably fine. The biggest memory issue has always been the Potts model, which basically requires 20x20=400 of these square 2D distance matrix/mask arrays. However, I did add some code to SparseMatrix and write_tcl_script() to get us started if we want to work directly with sparse matrices in the future.
• Make it faster It should be very fast to write the TCL script from the python code and to execute it when loading a molecule in VMD. @cabb99 improved this a lot recently but the line drawing in VMD can still be made much faster by drawing the lines with the lower-level graphics command instead of draw. It can now draw a full frustratogram for NFKB (615 residues) in fractions of a second
• Anchor lines to CA positions instead of hardcoded coordinates: Instead of hard coding the endpoints of the lines when writing the TCL script, we can have the script check the coordinates of the atoms it is supposed to be connecting. This does not seems to affect the drawing efficiency much, at least when combined with the improvements mentioned above. Doing things this way allows you to move the lines along with the molecule if you change the molecule's coordinates (you just need to re-source the script, which is very fast). This would allow you to calculate frustration and write tcl scripts once and manually align structures afterwards as many times as you want.

Questions

• Decide what to do with SparseMatrix in write_tcl_script(): handle directly or always convert to dense? Based on our discussion today, we want to try to directly handle sparse matrices. I should check this further.
• Anchoring lines to atoms instead of hardcoded coordinates has some risks. If the user loads the wrong structure, then the frustratogram will be wrong, possibly in a non-obvious way (but it could also be obviously wrong, drawing lines between residues that are far apart, for example). If the user loads a trajectory like vmd traj -e frustration.tcl, then the lines are drawn based on the final frame. We decided that this is okay

Status

• Carefully test direct sparse matrix handling in write_tcl_script and make it the default behavior
• Ready to go