Summit Dec 2013: Difference between revisions
| Line 115: | Line 115: | ||
Berk suggested we be more willing to accept more research-y implementation that might not work as uniformly across all platforms as we traditionally are worried about. In particular, he mentioned Arron Knoll's volume rendering code that will work on a few platforms, but not a whole lot. | Berk suggested we be more willing to accept more research-y implementation that might not work as uniformly across all platforms as we traditionally are worried about. In particular, he mentioned Arron Knoll's volume rendering code that will work on a few platforms, but not a whole lot. | ||
=== Python Scripting === | |||
Alan complains about documentation issues with the Python scripting. | |||
Ken's argument is that the "documentation" should mostly be the trace recorder. If you want to know something, then turn on the trace recorder, do it, and look at the trace. If it is not captured, that is a bug. So the question goes to the mailing list, a bug gets raised, and a developer answers the question. | |||
Alan wants a secondary place to go that gives a list of everything that is available. There is a long discussion on automatically generated discussion. It could be a good start, but there could be some issues on the usefulness of the documentation. | |||
Revision as of 13:48, 5 December 2013
Location: Kitware Inc., Santa Fe, NM
Agenda
| Thursday, Dec 5, 2013 | |
|---|---|
| Time | Item |
| 8:00-10:00 | VTK-m Planning (Ken, Berk, Chris) |
| 10:00-11:00 | VTK-m Changes to ParaView (Berk, Ken, Jim or Chris) |
| 11:00-12:00 | NIH VTK Changes (Berk) |
| 12:00-1:00 | Lunch |
| 1:00-3:00 | Software Engineering Issues (Utkarsh, Alan)
|
| 3:00-4:00 | ParaWeb (Sebastian) |
| 4:00-5:00 | Python scripting simplification |
Topic Suggestions
Add suggestions here, we can then put them on the agenda.
Deprecating Components
- Policy for deprecating code: with changes to Panels and others, we have lot of dead/uncovered/sparing used code. How to deal with it?
- What happens to components like Prism which are not being actively ported to new style?
- How about discarding old panels that don't seem to be used as much e.g. Statistics Inspector
Logging/Tracking
- Better logging/processing of timer logs
- Ability to track memory allocations in VTK
Simplifying Plots
- Making Plots "editable" by interacting in the View rather than having to go to the "View Settings" page.
PVSC Configurations
- Wizards for generating PVSC files?
- included ssh-client? xterm? for open space?
Application Settings
Parallel STL/CSV Writers
- Improve parallel STL CSV writing so that you don't need to collect everything on process 0 (all at once).
- Sounds crazy, but we have a use case to get data in professional graphics tools.
Alan's Talking Points
- ParaView documentation, especially compared to EnSight and VisIt
- Python documentation, especially compared to VisIt.
- ParaView python and scripting. (I will get an e-mail off before then with feedback i heard at SC).
- Statistics. Statistics in parallel. Clearly mark statistics filters that give wrong results in parallel.
- Updating VisIt reader
- 3d view menus. 2d view menus. Toolbars (do we default them off, or on?)
- Efficiently parallelizing CAM reader - and priority.
- Future of Prism
- Do we need another "cleanup release"?
- Probe - interactive. Display X,Y,Z on the 3d view. Display any variable.
- Needed miscellaneous functionality - volume, min, max, average, calculator accessing global data.
- Material interface filter and non AMR data.
- Document how the trace recorder works.
- Create precanned Macros that ship with ParaView?
- Possibly changing the layout of the settings panel to more of a Chrome layout. (This was Utkarsh's idea, I am still on the fence.)
Meeting Notes
VTK-m Changes to ParaView
The path forward to implement VTK-m, we will probably start as plugins to ParaView. Eventually, it will become a core part of the builds. Mostly this is just development work. It is not moving to production yet because there is suddenly a lot of flux in the projects.
The vision is that when you run a filter in ParaView, it will automatically use a VTK-m algorithm on an accelerator when available. Robert Maynard mentioned he had some code working that used the factory mechanism to choose an algorithm. Berk thinks that the final solution will need to be more dynamic. The recent TBB work shows that the direct VTK parallelism can outperform these massive threading algorithms on architectures with modest amount of cores. The general suggestion was to create metafilters that delegate work to concrete instances depending on any number of criteria.
NIH VTK Changes
Main focus is to update the rendering framework of VTK. Support scene graph things better. Make hierarchies, color blocks independently, etc.
Also looking at running on mobile devices (OpenES, WebGL). Make the developer experience as seamlessly as possible. Make it easier to develop new rendering code. Remove excuses on not developing new rendering algorithms in VTK.
Improve volume rendering, especially for image data. Plan to work on AMR data sets. Berk wants to persue perhas using that to implement a dynamic resampling for unstructured data sets.
Probably will be some molecular rendering.
Lots of little things highlighted. Issues with resolutions of data. For example, geospatial data could be offset by kilometers but have resolution lower than meters. Floating point errors ensue.
VTK maintenance component.
High Level Improvements
Berk suggested that we should use the upcoming year to show clear distinctions of ParaView to alternative products.
There were several suggestions of possible things to do, particuarly with rendering (feeding back to the NIH changes). Ambient occlusion was brought up. There is already a form of that with light field.
There could be some improvements with particle rendering. What do you do with millions or billions of particles. From a distance, it is volume rendering, up close it is spheres.
Berk suggested we be more willing to accept more research-y implementation that might not work as uniformly across all platforms as we traditionally are worried about. In particular, he mentioned Arron Knoll's volume rendering code that will work on a few platforms, but not a whole lot.
Python Scripting
Alan complains about documentation issues with the Python scripting.
Ken's argument is that the "documentation" should mostly be the trace recorder. If you want to know something, then turn on the trace recorder, do it, and look at the trace. If it is not captured, that is a bug. So the question goes to the mailing list, a bug gets raised, and a developer answers the question.
Alan wants a secondary place to go that gives a list of everything that is available. There is a long discussion on automatically generated discussion. It could be a good start, but there could be some issues on the usefulness of the documentation.
