Improving efficiency of code in smirky - for future move proposal tools

[bannanc]

I wanted to get an issue started for this that can be used for documentation. I continue to believe that it isn't worth investing significant time into speeding up SMIRKY now, but certain functions from this code will likely carry over to future move proposal engines.

This issue will focus on places that the code can be more efficient, not making "smarter" chemical moves, though that is also going to be important.

At the OFF meeting this week, Daniel Smith has been helping me diagnose what is causing the code to be slow. We've identified the get_typed_molecules as a particularly problematic part of the code, it scales as N^4.

[davidlmobley]

FTR, what does that part do and why does it scale that way?

[davidlmobley]

(Aside from "getting typed molecules", I mean. Is this the part which types the molecules? And what's N? The number of molecules or the number of types?)

[bannanc]

I think the N in this case is referring to molecules, so the exact scaling will change with number of molecules and number of types which is likely why torsions are so much slower, there are many more torsions/molecule than other parameters.

This is typing the molecules with the current list of smirks patterns. Daniel seemed to have some ideas that would speed it up.

[bannanc]

Moved to chemper issue#12