canSAS-XI/Software: Difference between revisions
From canSAS
| Line 12: | Line 12: | ||
Highlights from the discussion include: | Highlights from the discussion include: | ||
* It seems that there are a number of packages that are being developed with similar plugin architectures in python | * 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 there does seem to be an insatiable and unstoppable need to re-invent the wheel | ** But there does seem to be an insatiable and unstoppable need for everyone to re-invent the wheel. **Question:** what drives that? | ||
** | *** Desire to be able to respond to ones users in a timely fashion? --> collaborative software development? | ||
*** | *** Desire to get recognition by doing something believed to be better? | ||
*** Perhaps biggest may be lack of good understanding of what exists and/or how to collaborate on it? | |||
**** | * Dissemination should work on reaching instrument scientists and potential developers as well as users about what is already there | ||
* Lots of “advertising needs” | ** Lots of “advertising needs” | ||
* Youtube for users but also beamline scientists | ** Youtube for users but also beamline scientists | ||
* Add citations and activity etc for packages on canSAS portal page | ** Add citations and activity etc for packages on canSAS portal page | ||
* Scriptable packages in python gives first go at correlation | * Scriptable packages in python gives first go at correlation | ||
* | * Securing funding for long term maintenance and funding | ||
** PANOSC and | ** 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?) | ||
* Facilities? | *** PANOSC and ??? | ||
** 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. | |||
* 3D pictures needed or our community becomes road kill | * 3D pictures needed or our community becomes road kill | ||
* Use molecular simulation and correlation analysis. ML could also help | * Use molecular simulation and correlation analysis. ML could also help | ||
Revision as of 14:52, 11 July 2019
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
The session began with a presentation by Sven-Jannick Wöhnert on dpdak
Highlights from the discussion include:
- 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 there does seem to be an insatiable and unstoppable need for everyone to re-invent the wheel. **Question:** what drives that?
- Desire to be able to respond to ones users in a timely fashion? --> collaborative software development?
- Desire to get recognition by doing something believed to be better?
- Perhaps biggest may be lack of good understanding of what exists and/or how to collaborate on it?
- Dissemination should work on reaching instrument scientists and potential developers as well as users about what is already there
- Lots of “advertising needs”
- Youtube for users but also beamline scientists
- Add citations and activity etc for packages on canSAS portal page
- Scriptable packages in python gives first go at correlation
- 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 ???
- 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.
- 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?)
- 3D pictures needed or our community becomes road kill
- Use molecular simulation and correlation analysis. ML could also help
- Get packages to take “STEP files” and convert to scattering
- Workflows for focused problems that give you the 3 parameters that you want
- Networking grants a great idea and some effort since last canSAS but need grants to do actual work.
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
