DevNotes_ModelsWG

INTRODUCTION/MOTIVATION

Analytical models and the fitting of data with said models has long been the heart of how SasView has been used. Thus the sasmodels code was extremely well written early on and separated into its own package with its own repository. The unintended consequence has been that maintenance, development and in particular upgrades has been severely neglected with most time and resources focused on the “main” sasview package (sascalc and gui).

BACKGROUND

Analytical models were at the core of the early SansView which became SasView. An early project moved to develop a plugin model architecture that treated all models, internal or “external” as equal citizens. This had several advantages: Easy (ish) to write a model - most of the heavy lifting is done by the core architecture (kernels). Anybody can contribute a model to the core since all models are the same New models can be easily distributed Around the same time as the sasmodels structure was conceived, a full refactor from the early code to completely separate the GUI from the calculations was undertaken as the next step in the evolution of robust maintainable and extensible project. Because the sasmodels package was already being used by other downstream projects and was also developed quite independently of the GUI, it naturally became the first package to be fully separated. The choice to move it into its own separate repo may or may not have been the best choice.

PURPOSE

By creating a working group to focus on sasmodels needs we hope to address this serious deficiency. As such the work can be initially be divided into two categories: Immediate issues that need addressing, and a longer term commitment of staying on top of new issues and ideas as they arise, suggesting relevant ADRs as appropriate, providing guidance to people interested in contributing to sasmodels, and meet to review (pull) requests

Long term scope (standing committee/Working group):

• Propose changes to sasmodels infrastructure as needed
• Propose what models should be part of distribution and what not or other ideas? (an ADR)
• Propose rules for moving from marketplace to distribution (an ADR)
• Meet regularly to discuss proposed moves from marketplace as they arise
• Managing the model marketplace (and/or other dissemination tools)
• Identify and deploy resources to achieve above aims.

Immediate refactoring projects would include:

• Remove Sasmodels shim from SasView
• Refactor sasmodels (Perhaps using pytorch?)
  • Add Qz correctly (relies on sasdata refactor including that properly)
  • Vol fraction/scale handling???
  • Refactor parameters (non fittable but setable, derived parameters, etc)
  • Refactor integrations to be
  • User settable number of integration terms
  • Plugins chosen by caller (user)
  • Rewritten to be better parallelizable
  • Add/refactor S(Q)
  • Provide locally monodisperse option
  • Provide ability to provide precalculated terms outside of any Q or polydispersity loops .. or allow use of master curves?
  • GUI - allow fitting on data operations
  • GUI - plot final SLD profile (or FT amplitude?)
  • Other as identified
• Marketplace refactor?
  • Add version control to models (i.e. for upgrades or bug fixes)
  • Add fields for which versions of sasmodels the models work/no longer work
  • Integrate documentation properly so it does not get uploaded separately
  • Possibly add new categories such as distribution - kept in a separate section but also version controlled etc.
  • Etc
• Other as identified
  • The existing issues should be mined for immediate actions (or for removal as obsolete, done, or won’t do)