- Notifications
You must be signed in to change notification settings - Fork91
Contributing Ideas
This page contains ideas for interested contributors that would liketo get involved with the development ofG+Smo. You are mostlywelcome to send your own ideas onGitHub issues.
We group the ideas under 3 umbrellas.
Extensions and plugins:
This group regards the creation of a link or interface betweenG+Smo and other open-sourcesoftware. This is done in G+Smoeither by writing plugins forthird-party software (thus exportingfunctionality from G+Smo), or by creating extensions that importfunctionality from or link to other code. The general aim is touseG+Smo to provide CAD data processing tools to thenumerical simulation community and to provide simulation tools tothe world of geometric design.Efficiency and computation:
This group collects ideas relatedto computational mathematics. The potential student is expectedto have a background in both mathematics and computerprogramming.Web interface and file formats:
This group is aboutdeveloping components of a web-based front-end toG+Smo, aswell as adding support for more file formats.
ParaView is an open-source data analysis and visualizationapplication, built on top of the VTK library. It is a standard toolfor visualization in the numerical simulation community, e.g. fordisplaying the solution of finite element analysis, creatinganimations for time-dependent phenomena, processing volumetric data,and so on. However, it lacks built-in support for B-spline geometryrepresentation (curves, surfaces, tri-variate volumes). Certainly, onecan generate a mesh out of a B-spline geometry and create a !ParaViewinput file. This is howG+Smo currently outputs visualizationdata to ParaView.
This project aims at implementing a plugin (dynamic library) forinputting and processingG+Smo data to ParaView. The first step is thedevelopment of a plugin that contains a Reader forG+Smo's splinedata file format. Apart from visualizing the spline geometry, onecould display the control net of a B-spline geometry and alsovisualize the parameter domain together with the knot-lines orknot-planes, using ParaView filters. Finally, a writer will allow us towrite back spline data from within !ParaView. The final goal would beto contribute this plugin to ParaView.
This idea regards the bi-directional communication betweenG+Smoand CAD/CAM software. In particular, we aim at developing a pluginfor open-source CAD applications. Promising possibilities includeBRL-CAD andBlender.
We are looking for students that have successfully worked in the pastwith other open-source projects and have experience with them.However, the source code should be developed in the G+Smo repository,use the API of the CAD system and linked dynamically with it aftercompilation.
In this project we would like to wrapG+Smo's spline classes andpartial differential equation (PDE) discretization tools withPython. The strategic decision that we need to make first regardschoosing one of several possible options to port the functionality inPython, and evaluate its pros and cons.
The idea is to getG+Smo tospeak the Unified Form Language(UFL).Python UFL is a domainspecific language for declaring finite element discretizations ofvariational forms. It offers a syntax which is close to mathematicalnotation that allows choosing finite element spaces and definingexpressions for weak forms. The task in this project is to extend thelanguage to isogeometric function spaces, which are supported inG+Smo.
A half-edge data structure is an efficient structure for representingthe incidence information about the vertices, edges and faces of amesh. We would like to develop a general purpose half-edge datastructure implementation withinG+Smo; use this structure to improvethe efficiency and reduce code redundancy of mesh operations.
The half-edge data structure is the basis of surface-based boundaryrepresentations. As a second step one can re-build the B-rep class ofG+Smo on top of the general purpose half-edge data structure. In doingso, we can move B-rep operations (eg. feature detection algorithm) tothe half-edge structure, so that it becomes available and re-usable toother parts of the code.
Our nightly build show a code coverage of around 60 percent comingfrom our (around 130) test programs. This percentage can be improved.Moreover, our tests are hand-made and do not adhere a general testingframework.
In this project the goal is to introduce a test unit and verificationframework toG+Smo.Such frameworks predefine assertions, levels of severity of testfailure, various options for running the tests, automated test reportgeneration, and so on.A big number of open-source possibilities exist, for instanse googletest, Catch, !UnitTest++, xUnit++ suite and many others.Before starting such a project, we should carefully choosethe most suitable frameworkfor our needs.
Communication with our developer's base is going to be vital for thesecond stage this project. The student should get in touch with theauthors of the current unit tests and get a rough idea of what eachtest does. Subsequently, the tests should be upgraded to the newframework, while improving the coverage by adding more tests when needed.
This idea suggests the parallelization of time consuming parts of thecode.
The first task that we should parallelize is the matrix generation ofa discretized PDE. This process is inheritly parallel, since itinvolves a loop over the cells of a domain, followed by a localcomputation on each cell individually. Then follows the accumulationof the local result to a global sparse matrix.
Secondly, the solution of the resulting sparse linear system is acomputationally expensive procedure that needs to be distributed tomany processing units (CPUs or GPUs). Open-source parallel linearsystem solver packages such asSuperLU orsparsesuite willbe employed for this task.
The efficiency and advantage of the parallel code will be demonstratedby a number of computationally demanding simulation examples. Theparallel computing infrastructure is available for effective trial andtesting of these ideas.
This project idea is inspired by other geometric model databases, such asAim@Shape repositoryorGeorgia Tech's geometric models archive.It regards the setup of a web database of isogeometric spline geometry and simulationdata. The core task is the setup of a suitable web development toolkit(eg. Wt/Wt::Dbo, CppCMS/CppDB, or others) to support the web-site.The data processing will be done by aG+Smo process running inthe background, providing thumbnail generation, real-time computationsand visualization and conversion of uploaded data.
There is already an interesting collection of isogeometric data sets,including B-spline planar domains, surfaces, multi-patch volumetricdata, boundary-represented solids, PDE benchmarks,boundary value problems with manufactured solutions, and so on, that we aim atadding to the database. In addition, the visitors of the web portalwill be able to contribute data, uploaded in various file formats. Theinternal representation and download format will be the open-source XMLformat ofG+Smo.
WebGL opens new horizons to webprogramming and visualization. This idea suggests thesetup of a web viewer for isogeometric data. It consists of developinga WebGL plugin that will communicate withG+Smo to generate outputsuitable for WebGL.
The viewer can be realized by means of different available tools,eg. usingthree.js,Babylon.jsorwitty to name a few. This choice is animportant decision before starting the development of the viewer. Oneshould make sure that the chosen framework meets our needs, forinstance it enables easy communication with a dynamic library,it is suitable for spline data display, allows for user interaction, and so on.
An important feature of a library related to CAD and simulation isfile input and output. Several file formats are supported by ourlibrary, eg. the !OpenNurbs, Siemens NX and the Object File Format.Several file formats are not yet supported, most importantly:
- the X3D format
- the STEP file format
- the IGES file format
Seehttp://www.wotsit.org for detailed information on each of them.
Moreover, for supporting the webfront-end, it would be useful to export formats including
- The PNG or JPG image format
- Povray ray tracer format
A related task is to introduce data compression for the library'snative XML format, in order to reduce the size of the XML files on thehard disk.