Contributor_Projects

Current Unclaimed Enhancement Projects

There are many places a code developer can contribute. For people with limited skills or even just new to SasView, a good place to start are the issues on Github labelled "Good First Issue". Beyond that there are a large number of issues, in both the _sasview _AND _sasmodels _repositories (as well as some in other repos), many of which are bugs in need of fixing. There are also a number of "Enhancement" issues (aka Feature Requests).

Here we have collected some of the latter into a few small projects that would be appropriate as short term (a few weeks to a few months) projects, for example, for a summer intern/vacation student. They could also be of interest for anyone who feels like they would like to work on an actual feature rather than a bug and do not have a particularly pressing project of their own. But this list is by no means exhaustive.

• Streamline the installation of marketplace models
  • From the interface in SasView (Tools or somewhere) enter model name
  • The function will download model from the marketplace and install it in the plugin directory, so it is recognizable by SasView
  • This will require developing an interface to the marketplace
  • Note: some of this functionality can be achieved by already existing plugin model manager
• Refactor sasmodels to
  • Implement a non-centrosymmetric particle such as non concentric vesicles (see Henrich).
  • "unroll" the polydispersity loop to take better advantage of GPU
  • To allow for other S(Q) options, in particular the locally monodisperse approximation
  • Better integration strategies (fast integration, adaptive integration - e.g. for very long rods)
  • Allow for model fits to 1D cuts of anisotropic data.
  • Possibly use PyTorch
• Finalize moving all calculations to sascalc and separating it out into its own pypi package
• Improve documentation editor/regeneration
  • Provide rendering on page being edited only separately from final integration into documentation (while working on changes)
  • Make sure SasView does not crash when documentation (especially model documentation) fails to build correctly
  • Build plugin model documentation that has not already been "compiled" everytime SasView is launched
  • Provide menu item or button allowing to copy original documentation back
  • Provide easy means for random user to submit documentation changes back to sasview github as a PR automatically.
• Refactor slicers
  • Provide calculated properties for every ROI defined (box slicer, sector slicer, wedge slicer, annulus slicer et). ROI properties should include: sum I, Ave I, Centroid I, and 2d peak fit with qcenter, I peak (height), width radial, width tangential. Boxsum becomes obsolete then and should be removed.
  • Allow selection of multiple files for batch slicing without plotting them all (GUI)
  • Batch output should contain the 1D file, calculated properties above and metadata of interest (time, field, angle of rotation of sample etc) for each file processed. Design/discussion would be whether the metadata could be all metadata supplied in the original file or be user selectable.
  • Allow multiple slicers of the same type to be defined at once on a single 2D data set. E.g. parallel and perpendicular sectors, multiple boxsums covering different peaks, etc. (GUI and possibly calculations)
  • Provide option of symmetry locking on slicers. E.g. square lattice, hex lattice, twinned hex, etc. (GUI and maybe calculations?)
• Refactor Data Operations
  • Allow for intelligent interpolation when adding or subtracting etc two data sets with nonidentical q points.
  • Allow for scaler * second dataset and an extra background term (data1 (+,-,/,*) scaler1 * data2 + scaler2)
  • Allow to calculate a chain of operation, e.g. the ratio of the difference over the sum of data (data1-data2)/(data1+data2)
  • Allow to perform a defined operation on several data sets (e.g. select a list of data that are treated as data1, similar for data2. If there is only one data set selected for a list, it should be repetitively used until all data in the other list have been treated)
  • Optionally more complex math? is it needed?
  • Provide for quicker/easier interface to do data manipulations (DESIGN required)
• Refactor masking
  • All operations on data (plotting, fitting, P(r), slicers, etc) should be able to respect masked data
  • Need flag to control using or not using masked data
  • Need flag to control visualizing or hiding masked data
  • Need better mask creation tools for both 1D and 2D (DESIGN required)
• Make simultaneous/constrained fitting less cumbersome to use. Probably best done by implementing simpler use cases?
  • Perhaps the most common would be a single model where all the parameters are fixed, floating independently or constrained to be the same across all data sets
    • GUI Design could be a single page like a batch fit or behave like the current constrained/simultaneous fit.
    • Whatever the case, this simplified page could just look the same as a normal fit page where the model is chosen and the parameters either fixed or floating. For floating parameters another checkbox could be provided for constraining them to be the same for all fits across all models.
  • A slight variant of the above use case would be simultaneous fitting of curves where all the parameters should be identical except the scale (and maybe the background). In this case however the scale might want to be constrained such that the variation is kept within some bounds (e.g. all within 10% of each other). This would be for example when fitting different configurations or the same sample run at multiple sources (but not mixing x-ray and neutron). This should probably be implemented in the same interface as a single broad "use case."
  • Another common use case would be "complex" constraints within a single data set/fit (e.g L = 10*R). This may be doable with the current fitpage dropdown constraint interface but may need a bit more work? or just better documentation?
• Refactor the model marketplace
  • Provide versioning of models. this allows for updating a model without deleting the previous version which may have been used in a paper or in case the change is due to a change in the sasmodels API for example (so the old model works with an older version of SasView while the new version is required for the latest SasView version).
  • Provide a field describing which versions of SasView the particular model works with. (see above)
  • Provide a licensing field. SasView is a BSD type license which precludes inclusion of models using gpl licensed code for example. However, these can be placed on the marketplace and downloaded by the user, but they should be aware of the license restrictions if any.
  • Allow for different types of plugins to be managed and curated (e.g. distribution functions)
  • Provide a DOI for each model (and display it on the website)
  • Auto generate the example plot for the default parameters - probably do at upload to make rendering faster on the website
  • Auto generate renderable documentation from the model file assuming it includes documentation.

Enhancement Projects currently being worked on

• Plot Refactoring (ILL with help from subgroup of developers)
  • This has morphed into a much larger refactor project with overlapping dependency pieces (like data object refactoring). Below are just some of the earlier ideas that should also be covered in this major refactor
  • See discussion https://github.com/orgs/SasView/discussions/2475 *Refactor plot transforms (Guinier, Porod, Kratky, Holtzer, etc)
    • The transform should apply to the whole plot not just the current data on the plot. In particular, a plot used for fits should also transform the fit curve.
    • This should probably live in the plotting section of the code and be general to every plot?
    • Probably need a better nomenclature?
    • Should this be separated out from the linearized fitting?
  • Collect all plots related to one type of analysis (e.g. fit plot, residuals, goodness of fit plots, and distribution plots) into a single tabbed structure. Note discussion #2475
    • Scaling (log/linear) should probably be independent to each tab?
• Integrate the hypergeometric function approach to fitting models (Michael Wagener - and ILL interns Dorian Lozano and Nouhaila Agouzal)
  • Do initial benchmarking of potential gains to zeroth order using this approach - see final report
  • Explore how to maximize speed in the context of the sasmodels/sasview API
  • Explore options for using the hypergeometric function approach to polydisperse systems within the context of the sasmodels API
  • Refactor sasmodel as appropriate -- preferably in a backwardly (non breaking) compatible way
• Model editing enhancements project (Paul Butler)
  • Simple Model Editor refactor (GUI - PluginDefinition)
    • Simple model editor needs a second code box to define the form_volume function. Currently the user has to know to go back into the generated code to add that function when they define polydisperse parameters.
    • Edit the templates to make ER and VR available even without polydispersity (these are required for S(Q)
    • edit the templates to include all the flags with default values
    • Add extensive comments in the code to tell the user what each piece does and how to change it.
    • Allow the creation of a c file from the model editor tool
    • Provide c function entries to the template (commented out with documentation)
    • Add more/better debugging features. In particular had support for C code debugging (see https://github.com/SasView/sasview/issues/2803)
  • Create a Reparameterization Model Editor GUI similar to the simple model editor to facilitate the reparameterization
  • Refactor mixture model editor. The first step is to agree basic design/architecture. Two options currently:
    • Keep existing method of using an editor to create a new persistent model (saved to disk etc)
      • In this case need to refactor the GUI to allow for more than a single model
      • In this case need to consider how mixture models are saved in project and analysis files
      • In this case need to consider how to include a mixture model into a mixture model
    • Only create mixture models on the fly at fit time as part of the fitpage infrastructure.
• Remote fitting interface (Jeff Krzywon)
  • Create web-based API to send fits to
  • Create server infrastructure to allow GPU-based fits
  • Fully scriptable interface for SasView