VisIt has evolved from a simple prototype into the application that we have today and perhaps we could have done some things differently. In addition, the machines that we run on are starting to look different. Here is a list of ideas that I've jotted down over the past couple of years would be nice to include in UberVisIt. These are in no particular order:
- Asynchronous mdserver/engine interfaces
- would allow for multiple engines to do progress simultaneously
- would allow for regular viewer behavior -- no more waiting for engine output and hoping the vis window remains responsive.
- Make viewer teach client about the state object structures so we can write clients in other languages without having to provide state object plugins. Viewer would send attribute subject descriptions to client where the client could assemble them into a tree data structure of all of VisIt's state. Xfer could update into this structure.
- Make the viewer UI be created via a plugin or shared library that implements the UI components. This could allow us to implement different viewer UI's more effectively. It also could allow us to create a UI that embeds the viewer in another application's main window. Example: embed the viewer into a Java app.
Make the viewer callable without a client[reverse launch] Make it easier to create new clients. Plugins and startup sequence are complex for a client right now.[embedded viewer apps]
- Perhaps make a kvisit that looks like a koffice application with MDI, koffice look & feel.
- Make it possible to incorporate all components in a single address space, if desired. All components would share the event loop or execute on different threads.
- Add pipe connection mode for local host connections
- Add shared memory communication between viewer/engine for local connections so we could allocate our VTK objects into it, making transfer from engine to viewer unnecessary. This could be a large speed increase on local Windows systems with largish datasets.
- Allow for parallelism over time -- with speculation if there are enough procs. This, along with the millions of procs requirement, means that there will need to be several master processes within the entire program group and they can coordinate the actions of their slaves. It might even be that some procs perform specialized roles. We could make the mpi communicator part of the pipeline attributes so it gets used instead of global communicator. This could also help with parallel error handling.
- Parallel error handling
- Engine interruption that works in parallel
- Allow for the engine's components to be multithreaded instead of MPI to make lighter-weight use of multicore procs. This would remove requirement for MPI on platforms like Windows, which would be a good feature.
- Streaming from data read to SR rendering so we don't have to have all of the dataset in core at once.
- MPI and threaded engine to run on 1.5M cores.
- Animated plots (e.g. balls along a stream line, textured flow, bending beams)
- Textures for things like the FilledBoundary plot (procedural textures, ...) Example: FilledBoundary plot of geological strata could use different procedural textures for different strata.
- Faster vis window that dispatches events better to our event handlers. -- Might need to be completely re-written?
- Render to texture and then texture a single polygon on the screen for when we're not interacting via rotation, etc. This would not really cost anything but it would make expose events much cheaper.
- Fast pick mode (rasterize values into an image and display balloon with the data as you mouse over)
- Scriptable GUI, customizable menus
- File readers: less work in constructor. Change to "Identify" method that tries to do the hard work of identifying the first file.
- Allow nested .visit file or .visit file composed of many file formats
- Allow for .visit file to union 2+ file formats together to create combined metadata. The database would then route requests for a variable to the right plugin for the file being accessed.
Make it possible to statically link a version of the code[done] Cross-platform make system (cmake)[done]
- Cross-platform testing
Ability to get more metadata about dataset to show in the plot attributes. An example would be showing a histogram in the Volume plot attributes. We'd like this before the real plot is executed[done PlotInfoAttributes]
- More intelligent caching/compression of actors
- Add dictionary to pipeline contract so plots/operators/expressions can tack on different data for enabled components and database readers.
- Multiple viewports
- Heck, make the vis window be a web page or powerpoint-like environment that can have vis-windows as elements. This assumes an integrated annotation mode.
- Good text and font support in OpenGL rendering, Greek fonts, equation rendering
Python-based expressions and queries[Cyrus did it for 2.0]
- Expression plugins
- Query plugins
- Control query output format via style sheet...
- Expressions that can be dynamically compiled and concatenated into a new expression that operates on data all at once. For example, expression classes could have a virtual method that returns whether they operate on just a local array element. The expression could also have a method to return its C++ code as a string. If all of the expressions used to make up an expression have true for that method and all of the data is the same (zonal, nodal) then the C++ code from all of the expressions could be combined into a new C++ expression that could be dynamically compiled and applied to the data once, saving memory and probably making the calculation faster. This process could be used on subtrees of an expression if the whole expression does not meet the criteria outlined.
- Execute different branches of expression tree on multiple processors when dealing with single block data if procs > 1. This would allow some concurrency when executing expression sub-trees with no dependencies.
- Better caching of pipelines on the engine.
- Better library organization and coding practices. Use namespaces.
- Low res preview image/dataset while rotating plots
- Collaborative vis environment -- users have viewers at different sites that look at same data using same compute engine resource. Implement chat, scribble on vis window pen, etc.
- Edge, face data
- Higher order elements
- Ability to save the output of a plot as a new database from which further plots could be made.
- Add a tab in the File Selection Window to better support finding simulations as they are currently implemented
- Ability to connect VisIt to external file systems (LDAP, ftp) so we could retrieve data from storage or data warehouses.
- Finish LIC plot, make it fast.
- Pervasive use of advanced OpenGL rendering capabilities
- DirectX implementation of graphics rendering for windows?
- AMR with no holes at patch boundaries -- automatically create intermediate mesh to deal with the resolution changes
- Improved display of file metadata in File information window (tree view)
- Operator that reads Paraview's XML files so it would be able to mimic any pipeline that can be set up in Paraview.
- Simplify AVT inheritance. Could sink/source go away? Maybe everything is just a filter?
- Add support for meshless variables and extend expression language to manipulate them. Specifically, a meshless variable would be an array read from the database that is not associated with any mesh. As an array, it could have N dimensions so indexing the individual elements is necessary. Slicing/copying elements to new meshless arrays is needed as are expressions to combine multiple meshless arrays into meshes. Example: take x,y,z arrays and make a point mesh or rectilinear mesh. Also, map meshless array onto a mesh like conn_cmfe.
- Make it possible to use query output in annotations
- Ability to add associations to custom tools. For example, support adding custom movie encoders, text editors, 1d-plotting, etc.
- Embed VisIt "document" in a MS document and be able to edit the plots in-line within Word/PowerPoint, etc. I saw this once with Visio, a diagram editing app.
- Package VisIt a version of VisIt that can be used from a Web page. That is, the remote side of VisIt could serve up images for a web site. Maybe a pure Java lightweight viewer could communicate with a full-blown compute engine on a remote computer. Requires Java implementation of EngineProxy, maybe a daemon.
- Take a VisIt plot/operator pipeline and encapsulate it into a new plot and give the user controls for designing a custom UI for it.
- Take a VisIt plot/operator pipeline and give the user enough controls to drill down into the pipeline, showing the various filters that make up each plot/operator. This would give the user a network designer interface.
- Keyframing of absolutely everything. This requires the viewer state to be much more centralized.
- Unlimited undo capability in gui/viewer, benefits from more centralized state
- Ability to redistribute data among processors, redecomposing a problem when appropriate. Mostly, I'd like automatic support for decomposing single block data among many processors
- Ability to delegate certain operations to the data reader.
- Is it possible to have VisIt's viewer connect to a front end engine manager that would intercept engine RPC's and dynamically recompile a small, static engine based on the requested pipeline? This is geared towards getting VisIt working on machines with simple OS, small memory. Could we allocate nodes and then keep running other programs into them? I can allocate procs using MOAB and then do multiple sruns with different programs. Could the "engine manager" do this by spawning srun commands with the tiny engine programs.
- Agressive platform-specific optimization of certain filters.
- When in SR mode, only process domains that fit in the current current view. If view changes, process any missing data and cache.
- Ruler that can be inserted into a scene for sense of scale and for measuring.
Improved libsim (there's a wiki page for this in here somewhere)[done]
- Would it be possible or desirable to provide Python wrappers for AVT filters so you could create small Python programs (similar to visitconvert) to do custom analysis?
- Should the engine executable be Python and then we just "import visitengine", set up an engine, and execute? I ask because as Python filters are added, we need a Python interpreter somewhere. We'd currently have to embed that interpreter in the engine somewhere, which is kind of a sucky approach. It might be better to just have the engine be Python.
- Add Earth plot that lets you pick various data files for earth texture, ocean temp, bathymetry, cloud cover, height, etc that lets us render a beautiful Earth with data. It would be sweet if we could map GIS vector data to it (roads, country outlines).
- Add a Cartography operator that lets us apply various Cartographical map projections to data.