VisIt 2.0 big ticket discussion
- 1 VisIt 2.0 Big Ticket Discussion
- 1.1 Create new sources
- 1.2 Create pipelines from database forward
- 1.3 Separate plot rendering and implied ops
- 1.4 Enhance rendering infrastructure
- 1.5 Reorganize GUI
- 1.6 Higher dimensional support, discrete and continuous
- 1.7 New OO Python API
- 1.8 Level of detail, multires
- 1.9 New parallelism types
- 1.10 Multiple viewports
- 1.11 More expression support throughout
- 1.12 Major component reorganization
- 1.13 Enhance Expression Language
- 1.14 Improved/more caching
- 1.15 Infrastructure for pre-computing time intensive derived data
VisIt 2.0 Big Ticket Discussion
Create new sources
- Description: Create new sources from new geometry, as operator side-effects, at intermediate points in the pipeline, from lineouts, or from queries
- new analysis capabilities, major ease of use improvements, wide applicability
- just the effort involved
- in addition to the infrastructure, there's work for each way we could potentially add new sources
Create pipelines from database forward
- Description: grab a DB variable, add some operators, and finally add a plot
- Definitely allows us to be smarter about restricting plots/operators, e.g. can't volume render a one-dimensional data set.
- Could allow operators to easily add new variables without having them create entire new sources.
- We could use this as an opportunity to let users choose a variable (or "default") when adding operators. E.g. Open "rect3d", add Isosurface of "p", add Pseudocolor or "u".
- Maybe even the ability to remove the restriction of only a single "primary variable" for a plot, e.g. scatter plot, without using a wizard. That's harder.
- Would allow you to switch plot type without copying (and possibly re-executing) the entire network.
- We could probably wrap the new functionally to mirror the old use case if necessary.
- the effort involved
- bigger user change, not everyone may want it
- letting operators create new sources as a side effect could accomplish some of the same thing, albeit in a slightly more convoluted fashion
- Cyrus - A solid implementation of this functionally would need to provide memory usage info, and management (delete/save to disk) of active sources.
- Jeremy - I think the management is a great idea, but I'm not sure that "creating new sources" necessarily implies having them be in-memory. Even if a source was effectively stored as a list of instructions, it would still have the same value. In other words, if a new source was a lineout of an existing plot, we could theoretically re-execute it just like we re-execute a read from a database, just relying on caching to save re-execution like we use it to save on reads. (A discussion of caching behavior may be warranted for 2.0 as well, but that's a broader scope than just creating new sources.)
- Cyrus - One of my expected use cases for this would be to distill some horribly huge dataset and keep the smaller result around for further processing preferably in memory or else nothing has really changed from the export database case. I think reusing networks w/ caching is also a great feature (one I strongly support) but it wont help in this case. (Note: this discussion is kind of a hybrid of db forward networks & create new sources)
- Jeremy - Right; I've been assuming you're talking about a combination of this with creating new sources, which definitely might make sense. We probably agree, but we'll have to talk more about use cases and specifics assuming we decide to add this for 2.0.
Separate plot rendering and implied ops
- Description: Some plots, like Surface, could easily have been composed by saying "Combine the Elevate operator, Pseudocolor plot, and Mesh plot". The Molecule simply renders vertices as spheres and line segments as cyliners or lines. But both of these are custom renderers....
- Easier to create new plots.
- Less specialized plot coding.
- Although it requires a lot of code and crowds the interface, having some specialization of plots makes for fewer clicks for users, so we still want the specialization in some way. In other words, it's not yet clear what the benefit to users really is other than faster delivery in the future.
Cyrus - If we can easily create data flow networks (with an editor for say advanced users) we could create "Macro" Networks to provide the functionally with less code and wrap it with same friendly face. I think in general making filters more flexible/reusable and limiting special case paths would be a good goal.
Enhance rendering infrastructure
- Description: Add new rendering modes, e.g. "OpenGL", "Mesa", "Raytraced", and "Radiosity". Rework internals to add new features like real-time Fog, real-time Shadows, bump- and texture-mapping.
- It would make presentation-quality rendering much easier than the manual process.
- It would allow more informative data exploration without switching to SR -- depth cuing and shadows are actually informative, not just pretty.
- Some internals, like handling of ambient and specular, is hard for custom renders.
- Could provide big speedups and allow special shaders to be more easily used.
- The current infrastructure is limiting us, but may be impossible to remove without removing VTK from that section.
- Cyrus - VisIt is largely dependent on VTK - I was wondering if anyone has tried (or should) assess at how large an effort it would be to migrate away from VTK ?
- Jeremy - There are some good reasons to do this, e.g. address missing capabilities in the underlying data model. (Something as simple as Molecular data is a total hack and has some big problems.) But keeping VTK support gets us VTK filters, and using VTK is probably perceived as a "good thing", so removing it entirely might not be a good idea. If we do want to remove it entirely, I'd argue that migrating away from it might not be as good a solution as writing a new tool from scratch, and with the help of "VTK<->NewToolAPI" (or AVT<->NewToolAPI) converters we could import a lot of existing VisIt code without having to immediately re-write it. I think if we want to talk about long term plans, this has to be something we consider.
- Description: Get rid of the MeshTV-isms, such as plot/operator menus, selected files, only one Attrib window open at a time, overall layout, the now superfluous "PlotAtts" and "OperatorAtts" menus. Go to MDI or Dock windows with Adobe-like toolbars.
- Not all the MeshTV-isms that VisIt inherited were good. 2.0 is the only time we can change this.
- Making big user-visible enhancements lets users (and developers!) feel like we delivered on a 2.0.
- Change is scary for users.
Higher dimensional support, discrete and continuous
- Description: Two things: more continuous dimensions (for abstract data, parameter studies), and more discrete dimensions (for time, vibration mode, "model" (PDB file), partition of data (small multiples)).
- Support more kinds of data.
- More discrete dimensions might be a lot of work -- it was hard enough to get *one* discrete dimension right.
- More than 3 continuous dimensions aren't supported by VTK.
New OO Python API
- Description: Create a new Python API that's object-oriented or relies less on internal Viewer state.
- Would make using the Python API much easier.
- If done at a lower level, like replacing the viewer proxy, would make custom VisIt-derived apps easier.
- the effort/payoff tradeoff
Level of detail, multires
- Description: Level-of-detail, multi-res, or even simply lower-quality quick-rendering representations for all input data. Maybe let the DB serve one up if it can -- e.g some HDF5 files could use hyperslab-reads to create a good one quickly.
- Much better user interaction, faster rendering, interactive use of tools.
- inconsistency between the support for various database types
- might take time to calculate anyway
New parallelism types
- Description: New of parallelism, e.g. parallelize over time on single-domain problems.
- Allow parallelism that scales better for some tasks.
- Description: Multiple viewports, multiple windows on one scene, "small multiples" (many plots in one window with small tweaks to each plot).
- Some big new features, like small multiples.
- Small multiples will require more than just multiple-viewport support.
- Not enough benefits listed in "pro" column yet. I know there are more reasons to do it than just small multiples. --Jeremy 11:35, 14 January 2009 (CST)
More expression support throughout
- Description: Integrate expressions/queries, and maybe even operators to some degree. Use expressions in some attributes.
- Big, convenient features, like "Slice(Mesh, intercept=MaxLocationQuery(density))".
- Integration within AttributeGroups might be a huge effort.
- Even a more basic level of integration will still be work.
Major component reorganization
- Description: E.g. allow engine to be a library for clients, link proxies or servers as libraries.
- Could allow widespread adoption of VisIt as a library, not just a tool. Aid in longevity.
- Allow to share address space with clients, etc
- Upheaval to component interfaces.
Enhance Expression Language
- Description: Examples: comparators as symbols ("if(a < b)" instead of "if(lt(a,b)"). Stop differentiating between Arrays and Vectors and Colors in the language. Or allow more advanced constructs, such as looping. Fix quoting.
- Make things more intuitive for the users by look more like C or python, for example.
- Add new functionality.
- We have most of the functionality already, and one could argue it's not too bad.
- And for new features, that'd be quite hard, and we already have plugins. E.g. how would we provide reduction or stencil access? What good would loops do?
- This isn't a huge item, but if we're going to do it, it should be for 2.0. In other words, if we're not doing it, we need to decide that now, too. --Jeremy 14:25, 14 January 2009 (CST)
- Of course, making expressions be plugins would *definitely* be a worthwhile endeavor IMHO.
- Description: Operators can take a long time to calculate. Examples are complex expression or the isosurface operator. In many cases it is desirable to cache intermediate results.
- Requested by several users (APDEC, ...)
- Improved performance
- This may be doable without interface changes, so could possibly be part of a regular release
- Having a pipeline as a new source may be a way to implement this when new sources are cached.
Infrastructure for pre-computing time intensive derived data
- Description: Some additional data structures (e.g., contour tree) can take a long time to calculate and can be used at many place (like, e.g., MIR). Add more generic support to calculate these data structures, ... early in the pipeline so that expressions, operators, etc. can use it
- Use of derived data at various places. E.g., contour tree in expression (connected components, ...) operators (isosurface), plots (contour tree, isosurface, ...)
- Probably big effort, in particular if completely general
--Jeremy 14:24, 14 January 2009 (CST)