VTK/GSoC 2016

From KitwarePublic
Jump to navigationJump to search

Project ideas for the Google Summer of Code 2016

Guidelines

Students

These ideas were contributed by developers and users of VTK and ParaView. If you wish to submit a proposal based on these ideas you should contact the community members identified below to find out more about the idea, get to know the community member that will review your proposal, and receive feedback on your ideas.

The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors. Ideally students will have submitted a patch or two to their project, [instructions are here] as they will have to soon after being accepted, but it is not a requirement for the proposal. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact to apply for any of the proposed projects. The mailing lists can be found on the project pages linked in the preceding paragraph. Please see GSoC proposal guidelines for further guidelines on writing your proposal.

Adding Ideas

When adding a new idea to this page, please try to include the following information:

  • A brief explanation of the idea
  • Expected results/feature additions
  • Any prerequisites for working on the project
  • Links to any further information, discussions, bug reports etc
  • Any special mailing lists if not the standard mailing list for VTK
  • Your name and email address for contact (if willing to mentor, or nominated mentor)

If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.

Project Ideas

Project page, mailing lists, dashboard.

Templated Input Generator for VTK

Brief explanation: Build up an infrastructure that makes it straighforward to bring new scientific data formats into VTK. The infrastructure will handle the complexities of temporal support, parallel processing, composite data structures, ghost levels and the like, and provide easy to use entry points that bring data from the file or other source and populate VTK arrays.

Expected Results: A set of classes that can take an input specification and produce vtk data objects correctly and relatively efficiently. The input specification should be sufficiently abstracted from VTKs data types that users who understand the input format well won't have to understand VTK's complexities in order to use it.

Prerequisites: C++ and probably a scripting language such as Python or Lua.

References: http://www.paraview.org/Wiki/Writing_ParaView_Readers

Mentor(s): Robert Maynard (robert dot maynard at kitware dot com) and/or David DeMarle (dave dot demarle at kitware dot com)

Supporting Solid Model Geometry in VTK

Brief explanation: Traditionally VTK has addressed the visualization needs of post-processed simulation information. Typically in these cases a tessellated mesh represents the geometric domain. This project will extend VTK's role in the simulation lifecycle by investigating approaches that will enable VTK to visualize the parametric boundary representation information used in solid modeling kernels such as CGM and OpenCASCADE (http://www.opencascade.org), which is typical pre-processing description of the geometric domain.

Expected results: A VTK module that interfaces with one or more solid modeling kernels.

Prerequisites: Experience in C++, and data structures. Some experience in VTK, parametric surfaces and solid modeling kernels ideal but not necessary.

Mentor: Bob O'Bara (bob dot obara at kitware dot com).

KiwiViewer on VTK

Brief explanation: KiwiViewer (http://www.kiwiviewer.org) is a model viewer for VTK datasets that runs on iOS and Android devices. It is built from a cross compiled version of an older release of VTK coupled with VES (http://www.vtk.org/Wiki/VES), a lightweight rendering library that runs on OpenGL ES. The most recent release of VTK supports iOS and Android directly, so bringing KiwiViewer up to date with full featured rendering would open up many visualization capabilities.

Expected results: A new version of KiwiViewer.

Prerequisites: Experience developing for mobile platforms and C++.

Mentor: Tim Thirion (tim dot thirion at kitware dot com).

OpenFOAM Catalyst adaptor

Brief explanation: OpenFOAM (http://www.openfoam.org) is a premier open source Computational Fluid Dynamics (CFD) simulation package. ParaView/Catalyst (http://www.paraview.org/Wiki/ParaView/Catalyst/Overview) is a VTK based in-situ visualization framework that tightly couples visualization capabilities to arbitrary simulation code. Updates to the data import path between OpenFOAM and VTK would give extreme scalability to OpenFOAM because data products would never need to be written to disk. It would also facilitate live data and computational steering connections that let the scientist see new results while they are being generated.

Expected results: A Catalyst adaptor contributed to either the OpenFOAM or ParaView communities. Two feasible starting points to begin the work are the existing vtkOpenFOAM readers and and the vtkFOAM FOAM-to-VTK exporter.

Prerequisites: Experience developing in C++, experience with CFD.

Mentor: Andy Bauer (andy dot bauer at kitware dot com) and Takuya Oshima (oshima at eng dot niigata-u dot ac dot jp)

Direct mapped Polyhedral input cells from OpenFOAM

Brief explanation: OpenFOAM is an Open Source Computational Fluid Dynamics (CFD) package. OpenFOAM runs on unstructured meshes that are composed of polyhedral cells. Polyhedral support is now provided with VTK although this is not supported by all filters. The default option within the OpenFOAM reader is to decompose polyhedral cells into the other VTK primitive types. The OpenFOAM reader also lacks support for ghost cells when reading in parallel.

Expected results: An updated OpenFOAM reader with support for ghost cells when reading in parallel where the default output is a polyhedral cells. Test cases should be created for many of the common filters and polyhedral related bugs should be fixed.

Prerequisites: Experience developing in C++.

Mentor: Paul Edwards (paul dot m dot edwards at intel dot com)


Better Package management Support for Java

Brief explanation: VTK is widely used across many communities (C++, Python, Java) but VTK is lacking integration into each community package management. It is true in Java with Maven but also in Python with PIP. We will focus on the Java side as the requirements for using VTK with Java might seems foreign for many Java developers. Therefore it would be nice to remove that barrier by smoothing out the bumps and complexity to run a VTK application inside a Java environment. The first step would be to embed within the VTK Java library a better native library loading mechanism similar to what was done with Jogl. Then provide a set of prebuild version of VTK for the 3 major platforms and publish them on a public Maven repository which will allow any Java developer to simply declare its dependency using Maven and not wory about setting environment variable or build native code.

Expected results: Automatic publication of pre-compiled VTK library across all platform (OS X, Windows, Linux) via Maven with an automated system library loading. The building of those library will be performed using our CMake SuperBuild infrastructure with our traget platform dashboards.

Prerequisites: Experience with Java while having knowledge in C++.

Mentor: Sebastien Jourdain (sebastien dot jourdain at kitware dot com)

Better Package management Support for Python

Brief explanation: VTK is widely used across many communities (C++, Python, Java) but VTK is lacking integration into each community package management. It is true in Java with Maven but also in Python with PIP. Therefore it will be interesting to provide a PIP support for VTK, which could then allow anyone to simply deploy VTK within their Python environment via a simple command line or a requirement.txt file.

Expected results: Deployment of the VTK library with its native counter part managed via pip install for usage within the system Python or a Python Virtual Environment.

Bonus results: Similar action with the ParaView library which also provide a Python wrapping.

Prerequisites: Experience with Python.

Mentor: Sebastien Jourdain (sebastien dot jourdain at kitware dot com)

VTK/ParaView integration into Jupyter / iPython notebooks

Brief explanation: VTK and ParaView are native scientific libraries used for data processing and visualization. Beeing Python Wrapped, VTK/ParaView can be used within any Python environment such as iPython notebooks. But currently nothing is done to ease interactive 3D visualization within an iPython notebooks. Relying on the VTK/ParaViewWeb stack, we want to enable it.

Expected results: Provide an integration path into iPython notebooks while enabeling a set of helper commands to start/stop/edit interactive visualization within a notebook either for VTK or ParaView or both.

Prerequisites: Experience with Python, VTK and Web.

Mentor: Sebastien Jourdain (sebastien dot jourdain at kitware dot com)

Half Baked Ideas

(contact Dave DeMarle if you would like to work on one of these or an idea of your own and I will find you a good mentor to work out a solid GSoC proposal with)

  • make concave polydata "just work" (i.e. render correctly) with minimal impact on common case speed
  • an add on framework to help VTK using applications keep track of units
  • lua wrapping, lua programmable filters
  • advanced rendering algorithms with OpenGL2 back end - Ambient occlusion, Reflection, etc etc.
  • interface to high quality rendering engines
  • select point cloud workflow such as surface reconstruction, and fundamental algorithms for curvature estimation, etc.
  • flying edges extended for other structured data types (structured grids, rectilinear grid) and also to structured clipping
Retrieved from "https://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2016&oldid=58994"