Things that could do with some time spent on them at the codecamp

[lucas-wilkins]

Here's some things I was thinking about working on at the codecamp.

Look and feel:

• Text sizes, icons, etc
• Flexible/better use of space
• Tooltips and menubars

Plots (see my other post)

[rozyczko]

In general, user friendliness and consistency of interacting with GUI elements. Yes, this is a very important issue and I've had some ideas about the redesign in places.

[lucas-wilkins]

Just a reminder for myself on this strand: icons for everything, contextual menus, and other menu stuff. Toolbars. Window docking options.

[krzywon]

Generalize Data1D/Data2D and better manage units

[krzywon]

We need to discuss https://github.com/orgs/SasView/discussions/2187, including the possibility of combining everything back into the main SasView\sasview repo (sasmodels, too!).

[rozyczko]

Refactoring FittingWidget into something more maintainable. The size of this class is ridiculous.
Start with splitting off polydisp and magnetic state.

[lucas-wilkins]

These all sound like great suggestions, and are somewhat synergetic.

Maybe at the start of the code camp we have some preliminary discussions, not a meeting to plan out the details, but present our ideas to each other, discuss how they might fit with each other, size up the work, check for any potential collisions, maybe specify some priorities.

[butlerpd]

As discussed this morning, a topic for discussion could be (should be? at some point?) whether we really need to continue supporting python models with C code embedded in the python. Currently there are three types of models: those written in pure python, those written in python and C where the C code is in a proper .c file linked through a source statement in the python file, and C code embedded in the python where the def Iq function contains the C code. At this point most models bundled with the installer are python + C while most user plugins (and a fair number of those on the marketplace) are pure python models. There are currently extremely few, if any, models with embedded C. This version has been deemed by many to be too hard to read and in fact most remaining models still using that method were converted to "proper" C and python a year or two ago.

The issues to consider as I understand them:

• Is it more useful or more confusing to have 3 different methods (i.e. benefit vs cost to users)?
• Maintenance -- do we have to maintain 3 different kernels in sasmodels for this? or is the C kernel significantly more complicated because of this?
• Not all features handled by C are handled by the pure python kernel. What about embedded C?
• Related to this, why do we not support all functions in all kernels? Is this a technology issue? a choice based on maintenance issues? something else.

[pkienzle]

Some points to inform the sasmodels discussion:

• Models can be python or C.
• The C can be split in separate files as sources=[…], or included in the model.py file as c_code="""…""" and/or Iq = """…body…""".
• Embedding C code in the .py file means you only have to manage a single file when sharing a C model.
• The Iq = """…body…""" form creates the C function signature from the parameter table so the two stay consistent. This hasn't been maintained, so it is missing support for radius_effective and Fq. Since it is a documented interface, dropping it may cause some plugin models to break.
• There is an unmerged python to C translator for C models implemented as python.
• The 1D model has Fq for shapes vs Iq for shape independent rotational averages.
• The 2D model has either Iqac or Iqabc, depending on shape symmetry. The calculation engine rotates (qx, qy, 0) into (qa, qb, qc) so that the model doesn't have to consider angles.
• There is still code to handle old-style Iqxy(...) calls where each model needs to handle shape orientation for itself. I don't know if there are any tests for them, so this interface may no longer function.
• The C models use kerneldll, kernelcl or kernelcuda as the calculation engine. These all share the same C code for implementing polydispersity and β calculations, with ugly C proprocessor tricks to handle the different engines.
• Python models use a completely separate calculation engine in kernelpy, which is why some features take longer to appear for python models.
• More precise P@S interaction models will require significant restructuring of the calculation kernels to move P*S into the integral. This will happen first in the C kernels and maybe never in the python kernel.

[rozyczko]

• Remove stale and merged branches.

Straightforward but requires some discussion.

[lucas-wilkins]

I was also thinking about some issue maintenance.

[wpotrzebowski]

GPU support on Mac (particularly for Metal). Benchmark on existing models.

[wpotrzebowski]

Keeping math/documentation consistent with code

[astellhorn]

Also, it would be nice to discuss things that can be done regarding magnetic SANS at the code camp, following our ideas we collected at the mSANS workshop. We already had the idea that it might be fast to insert multiple wedge slicers based on Ellis' work, maybe we can even speak about / plan / insert more.