Excerpt from end of project report, kieranrcampbell [at] gmail.com.

One of the original tasks I was given was to look into the viability of transitioning to one library of standard SANS models that any SANS analysis program, such as Sansview or Sasfit, could commonly use.

At the very least this project would require all models to be written in a common language. Currently Sasfit models are written in C, while Sansview models are written in a mixture of C++ and python. It would therefore make the most sense for a common library to be written in C++, which Sansview could readily access. Sasfit would require a set of modified header files to interface the current function calls with new C++. Furthermore, Sasfit would need to be recompiled using a C++ compiler to avoid linkage issues in naming conventions between C and C++ function calls.

The first step in this was to transition the models in Sansview that were written in C++ in to Python. This was done to two models, \texttt{DABModel} and \texttt{TeubnerStrey?}. However, upon attempting to do the same to a third model it turned out the wrapping process wasn't complex enough to handle some models that include a 'multifactor' selection. I updated the wrapping process to take this into account using a \texttt{MULT\_FACTOR} tag in the C++ header files.

It soon became apparent that this project was huge, and probably warranted a summer of its own. Transitioning all the Sansview models to C++ would probably only take a week or two. However, integrating this with something like Sasfit would take a very long time. Every model would require an individual wrapper to be written, followed by solving any linkage issues. On top of this we would have to liase with the Sasfit team and learn the structure of the entire software as well. I believe this is probably an entire summer internship on its own. If the entire point of a common library is to save the developer some time from coding two models (one for Sasfit, one for Sansview), then this is greatly exceeded by the time taken to write this mechanism, especially when there are at most 20 or 30 models yet to be added. It is therefore recommended to leave the current situation in place and make do with writing two plugins for each model added.