canSAS-XI/Software

Discussion session on Software

Chair : Paul Butler

Session Plenary Overview : Water water everywhere, nor any drop to drink.

Sven-Jannick Wöhnert : <<dpdak slides go here>>

Session Notes

Summary

• It seems that there are a number of packages that are being developed with similar plugin architectures in python
  • A true monoculture is probably not healthy
  • But we do seem to have a horrible history of re-inventing the wheel. Question: what drives that?
    • Could be support issues: Desire to be able to respond to ones users in a timely fashion? --> collaborative software development?
    • Perhaps biggest issue may be lack of good understanding of what exists and/or how to collaborate on it?
      • Even instrument scientists might not know which tool(s) to use. They might thus push tools that are known but may not be the best tool for the job
• Dissemination should work on reaching instrument scientists and potential developers as well as users about what is already there
  • Lots of video tutorials around but should link to them appropriately from portal
  • Youtube for users but also beamline scientists
  • Add citations and activity etc for each software package listed on the canSAS portal page could be a great help in making whats available more accessible
  • Would also be good if most highly used packages moved to top so people don't have to always read through the entire list.
• There is probably a need for special workflows for focused problems that give users the 2-3 parameters they are looking for.
• If all packages are designed as scriptable first they can then more easily be pulled into various frameworks to develop different workflows for different communities for example or in frameworks for correlative/multi-modal analysis. We should try to encourage all package writers to do this. It is really the correct way to be writing software anyway.
• Securing funding for long term maintenance and funding
  • Can we reposition analysis software as infrastructure. In Europe there is an evolving new infrastructure funding model which would support infrastructure indefinitely (presumably as long as it is a useful infrastructure?)
    • PANOSC and the European Open Science Cloud project, EOSC
  • Alternatively Facilities presumably have a need for users to have adequate analysis software. Problem is prohibitive cost. So can we bring the costs into a realistic range?
    • This would probably require collaboratively maintaining and developing the critical packages and/or infrastructure. That would require getting everyone with any effort in SAS analysis software identified and together to discuss “infrastructure” support models.
• Science is going to pretty pictures. Given advances in microscopy and crystallography, SAS software needs to produce 3D pictures more routinely or our community will becomes road kill
  • Molecular Simulation by default gives such images - can we leverage the current interest in that software area?
  • Deep Learning and even correlation analysis could also help this.
  • We should just get all packages to take appropriate image files (CAD? “STEP files?”) and convert to scattering
    • NOTE added in general discussion: Brian Pauw is developing such a package. Can't yet handle contrast because the CAD file type does not support color. Could we use layering? Should co-ordinate with Brian to develop package further for general use, robustness and maintenance.
• Networking grants a great idea and some effort since last canSAS but need grants to do actual work.

contemporaneous notes by Jeff Krzywon available here

Google Doc With Notes

Actions

• Video tutorials for selecting software program(s) - Assigned to: TBD
• Smallangle.org: Separate out highly used software and mark supported vs unsupported - Assigned to: TBD
• Software usage across different facilities - Assigned to: TBD