VTK/GSoC 2016: Difference between revisions

From KitwarePublic
< VTK
Jump to navigationJump to search
(Created page with "Project ideas for the Google Summer of Code 2016 == Guidelines == === Students === These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [ht...")
 
Line 41: Line 41:


'''Brief explanation''':
'''Brief explanation''':
Build up an infrastructure that makes it trivial to bring new scientific data formats into VTK and ParaView. 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.
Build up an infrastructure that makes it trivial 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:'''
'''Expected Results:'''

Revision as of 15:36, 26 January 2016

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.

Computational Biology (Molecular Dynamics) In Situ Visualization

Brief explanation: Computational Biology involves using computer simulations to study biological problems using molecular dynamics and other techniques. Of particular interest is [GROMACS], a versatile package to perform molecular dynamics, i.e. simulate the Newtonian equations of motion for systems with hundreds to millions of particles. It is primarily designed for biochemical molecules like proteins, lipids and nucleic acids that have a lot of complicated bonded interactions. GROMACS is optimized to run on distributed memory clusters with recent support for GPU and SSE optimization. These GROMACS supercomputing simulations produce enormous (terabytes) file output to be analyzed post process by tools that only read the trajectory (position, velocity, and forces) or coordinate (molecular structure) information, and simply guess at the topology rather than using the simulations topology defined in GROMACS.

This project would provide a baseline implementation of ParaView Catalyst for molecular in situ visualization and data analysis embedded in GROMACS based on GROMACS' computed topology and trajectory information.

Expected results: The result would be ParaView Catalyst adaptors, example python scripts, and new advanced visualization techniques for GROMACS in order to enhance the computational biology workflow.

Prerequisites: C++ and python experience required, some experience with VTK and ParaView ideally, but not required.

Mentor: Marcus D. Hanwell (mhanwell at kitware dot com).

Templated Input Generator for VTK

Brief explanation: Build up an infrastructure that makes it trivial 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: Brad Davis (brad dot davis 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)

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, Shadows, Reflection, etc etc.
  • interface to high quality rendering engines