Currently we rely on dlib only for their fitting routines. This is a big dependency to have just for performing fitting. We should consider using a more specialized library, or even implementing our own algorithm.

We will have to perform a lot of matrix multiplications for rotating atomic coordinates in our rigid-body optimization. Perhaps it could benefit from more efficient instructions. Perhaps it is bottlenecked by the distance calculations anyway.

Currently each Image owns its own storage vector. We should consider making the ImageStack own all storage space, allowing for more efficient iteration.

In contrast to GCC, the MSVC compiler apparently does not output unhandled exception messages to the terminal, but instead outputs some cryptic crash dumps. Since we rely heavily on these exceptions for error messaging, we probably should add a try/catch block around the main code blocks in the executables.

There is no reason to always carry around the plotting information when we instantiate a Histogram or SimpleDataset. Instead a PlotOptions object should be instantiated whenever a plot is made.

To be more generally useful in sasview, we need to dynamically be able to change the bin widths for highly ordered structures, and to extend the q-range to both lower and higher values than what is currently allowed.

The precompiled Windows executables should be signed before being released.

Currently only a single TER record is supported. I am unsure if this is even relevant though.

Progress:

• SAXS fitter
• EM fitter
• Rigidbody optimizer

Implementing a simple unit class would get rid of conversion-errors and make it clearer to potential users what kind of values are being returned. We don't do a lot of these, though.

Using the squared distances saves a lot of square-root calculations in our tightest loops.

Currently we download the specification file for each residue from the RCSB database, and expect the atom names (e.g. CA, OXT) to match these perfectly. However, some programs seems to use the remoteness indicators instead, which may not necessarily match the names in these specification files.

We should consider adding support for this by reconstructing each residue when downloaded and add these additional aliases to the parsed master file.

The em_fitter_gui is partially broken for Windows, and should probably receive more proper tests. Currently the following errors are present:

• Adding the map file first seems to cause crashing.
• At the end of a fit the program crashes, likely due to being unable to plot the results.
• Removing the resource folder from scope causes weird graphical issues. This will likely happen on Linux as well. Perhaps the most important resource files should be compiled into bytecode and distributed directly with the executable.

By request I implemented an early version of body-specific hydration targets, to allow for less hydration molecules on the flexible strands of a protein. While the implementation is working, it could be more efficient. Specifically, using distance calculations to determine which body a given hydration molecule belongs to is horribly inefficient, and should be reworked.

Currently the ImageStack fitting process can consume a lot of memory; so much that the operating system may terminate the program. The main culprit is the generation of the dummy structure, containing a ton of Atom instances. We can alleviate this by using introducing a reduced SimpleAtom class, since we have do not need most of the additional information contained within the complete Atom class.

There seems to be a factor 2 of difference between the fitted hydration scattering power between the PartialHistogramManagers and the usual HistogramManagers. This should be investigated further.

Currently plots are created through custom "plot script files" handled by an external Python invocation of the plot.py script. It would be a significant improvement to be able to do everything internally instead, which would save us a lot of trouble, both with the coding itself, but also security-wise since I imagine the Windows Smartscreen is not too happy about those external command-line invocations we're currently making.

Possible alternatives:
https://github.com/alandefreitas/matplotplusplus

Currently we only support x86-64 intrinsics. We should consider adding support for arm64 by expanding the CompactCoordinatesData class with additional ARM NEON intrinsics.

Currently the distances are calculated up to 4 times depending on which plots are enabled. This is obviously supremely unnecessary. Some kind of caching should be implemented.

Currently the resource folder must be located in the same directory as the executable itself, otherwise the interface will look weird due to missing symbols. Perhaps the most important resource files should be compiled into bytecode and be distributed within the executable itself.

As an emergency solution, a minimum size of 1000x1000x1000 has been added for the grid when used in conjunction with the rigidbody optimizer. This was necessary to avoid potential crashes with long flexible proteins, where the initial closed size is not indicative of the total open size. When the structure is opened up during the optimization, the grid will be too small and trigger crashes.

There must be a better way to solve this. Perhaps it should be a user-adjustable parameter, in which case a better error message should be triggered.