Summit Dec 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) What is/isn't working What's falling of todo?
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

• ParaView Settings 2.0

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.

By this summer, we want to have some VTK-m functionality in ParaView.

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.

Min/Max in Find Data

Would like a min/max function in find data. It would be nice to have it per block or all blocks. Also want to be able to see where it is.

Finding quartiles would also be good. Not quite as important as min/max, but there is a lot of interest in them.

There was a discussion on how find data works when finding over time. For example, what does it mean to find the maximum value over time? Berk suggested that the selection itself contains time. Then a filter like extract selection could load data at that time step and get the appropriate data.

Ken suggested that a find over all time can extract the point or cell at whatever time step it is in and show that at whatever time step you are. That could be valuable even if things are moving around.

Global variables in the calculator

Some of Alan's customers need to perform computations on global variables. The array calculator does not support global variables, and it should.

This also devolved into a discussion of Berk evangelizing the Python calculator. There was some discussion that not many people do not know how it works. It was suggested that the array calculator controls should be added to the Python calculator properties panel. Alan also suggested that the filter gets shown more prominently (for example, on the common filters toolbar). You might also consider removing Python from the name so as to no scare users off.

LANL Feature Requets

With the work in the RAGE code, they are having problems with the cube axis. They want to zoom in to a particular region of interest and still see the axes. This can be hacked by setting a "Custom Axis Origin". In 2D, they want to be able to fix the axes in screen space as they zoom and pan. They also want something similar in 3D, but it is unclear how that would behave so further discussions are necessary.

The PISTON plugin needs some work. The plugin needs to have regression tests added that are run on some pipelines. ParaView needs to support the OpenMP backend in addition to CUDA. They also need the Python wrapping to work with the PISTON plugin so that it can be used with Catalyst.

Better Python. Integration with things like iPython.

Olie has problem with finding old Python servermanager binding when Googling for ParaView Python.

There should be a way to point the Programmable filter to a file rather than always type a Python script in that stupid text window.