Summary

It's exciting that the GSoC project is going to the end. 
My code is available via this link.

During the whole periods, the following milestones are achieved:

• A DUNE-style B-Spline geometry interface including
  GlobalCoordinate center () const
  int corners () constGlobalCoordinate corner (int i) constDune::GeometryType type () const
  bool  affine () constGlobalCoordinate  global (const LocalCoordinate &local) const
  const JacobianTransposed & jacobianTransposed (const LocalCoordinate &local) const
  const JacobianInverseTransposed &  jacobianInverseTransposed (const LocalCoordinate &local) constctype  integrationElement (const LocalCoordinate &local) const
  Among these functions, the global and jacobianTransposed are the two key functions.

• A DUNE-style NURBS geometry interface(same as the previous one)
• A basic DUNE grid manager for B-Spline patch including the follwoing components(classes):
  grid
  leafgridview
  entity
  leafiterator
  indexset
• A basic DUNE grid manager for NURBS patch(same as the previous one)

The following task is not completed yet,

• Make the VTKwriter applicable for the B-Spline and NURBS grid view
  This task involves creating a vertex entity and iterator. I'm still debugging on it.

During the three months, my mentors and the whole community as well were very helpful. They answered my basic question with great patience and always tried to help me with all their effort. I would like to thank for their patience and help first.

Previously I was mainly dealing with algorithms implementation with the help of existing libraries. This is the first time to think from the developer perspective, which requires much more programming skills. It's a good opportunity for me to practice my hands-on skills(meta-programming, interfaces), foster good programming habits(programming style, comments, consistency). As a result, for the first two milestone regarding spline algorithms, although more codes were involves, I faces less challenges. But I encountered much more difficulty for the gird structure construction. On the one hand, this is due to my skill inefficiency; on the other hand, I feel it's the requirement are not quite clear. So in the future, it would be more beneficial for new developer to have a tutorial on how to make a basic DUNE gird. This is my suggestion.

In the end, thanks for google for organizing this awesome event!

Debug the VTKWriter for BSplineGridView

To be added

Continue NURBS gird manager with entity and iterator class

This week I continue my work with NURBS gird manager. The following work have been done

• Created the NURBSGridLeafIterator class
   template<int codim, typename NURBSGridView, typename NURBSEntity>
  class NURBSGridLeafIterato
  which allows iteration over all entities of a NURBSGridView
  
• Modified the NURBSPatch class and NURBSGrid
  to fit the newly-add features
  
• Created a NURBSGridLeafIndexSet
  template<class GridImp>
  class NURBSGridLeafIndexSet
  to return the index of a given entity

• Added test case for NURBS grid

The implementation details are hidden as it is analogous to what I did for BSpline grid.

The next step is to test whether what we had is enough for a VTKwriter. Now in our test code, we iterate over all elements of a BSpline/NURBS grid we created, and writes the resulting geometry manually to a VTK file. DUNE provides a VTKwriter which is able to write the elements of a gridView automatically to a VTK file. But we don't know yet what interfaces are required to make the VTKwriter work expected. So we will try to debug into and see what new classes and functions are needed.

Start making a grid manger for NURBS

This week, I started make the grid manager for the NURBS patch. The idea is the same as the BSpline grid manager, so I am not elaborating the details again.

The following classes were implemented and available in my remote respiratory now:

• NURBSGrid
• NURBSLeafGridView
• NURBSGridEntity

Add IndexSet class for BSpline Grid

Last week was mainly spent on debugging. It would be boring to note all my mistakes down. But some of them are worth mentioning and may be useful for others.

• For the deference function in an iterator class which requires return by reference, the best solution is to have a container of the entities the iterator points to. Creating an entity object in the function which is a temporal object cannot be returned by reference and thus should be avoided. Also, make the iterator class to hold a entity pointer is also problematic as the point can be altered by some iterator functionalities, e.g. "++" operator.
• If a class takes an object of other class as member, it's better to make it a reference.
  For example,
  Class A
  {
  public:
      A(const &B b) : b_(b)
  private:
      const &B b;
  }

In addition, a IndexSet class was made to get the index of a given entity.
template<class GridImp>
class BSplineGridLeafIndexSet
with constructor and index function.

Make B-Spline Grid iterators work

Form last week I continued with the other important features of a DUNE like gird for B-Spline.

• A BSplineGridEntity class
  template<int codim, class GridViewImp> class BSplineGridEntity
represents each valid knot hypercube of a BSpline patch. It wraps a BSplineLeafGridView pointer and a direct index of the knot hypercube.  The  index i indicated the ith valid knot span of all valid knot spans. A geometry function is provides to access the B-Spline geometry operated on this entity(knot span). 

• Completed the BSplineGridLeafIterator class
  Made it a subclass of the ForwardIteratorFacade class using the Barton-Nackman trick. Implemented the deference, equals and increment function which corresponds to the operand overloading of *, == and ++ separately.

• Completed the BSplineLeafGridView class
  with a begin and end function which returns the corresponding BSplineGridLeafIterator object to support range-based for loop.
• Added some new members in the BSplinePatch class
  Namely, a MultiDimensionNet of all valid knots. Pay attention here, each valid knot hypercube is a point of the MultiDimensionNet. The purpose of making such a net is to easily transfer a global knot index into a multidimensional index which is required by the geometry function of BSplinePatch.

Currently, I still have problem with compling the code of above changes. To be specific, the ForwardIteratorFacade class overloads the increment function in a way where a reference of the entity should be returned. But I created an entity locally, which is not possible to return by reference. I will talk to mentor and try to solve this problem.

Preparation for a B-Spline grid manager

As I said in the previous post, we decided to skip the inverse mapping temporarily and move towards to the construction of a B-Spline DUNE grid. The final goal is to have all necessary grid components and interfaces to make the VTKwriter work.

For the past two weeks, I spent quite some time to understand the dune gird interface. My original plan was to imitate the OneDGrid. So I read almost all the source code of  the OneDGrid and the common grid interface. Then I found it was a too ambitious plan. DefaultGridView requires a rather complete gird traits which is not easy for me to achieve in a short time. After a late discussion with my mentor, I realized I took a lot of detours and it's important to report my problems and doubts directly when I had them.

Then we tried to build a rather basic B-Spline gird manager. Here I list what I achieved last week:

• A BSplineGrid class
  which wraps the BSplineLeafGridView
• A BSplineLeafGridView class
  which wraps the BSplinePatch and offers access to BSplineGirdLeafIterator
• A BSplineGirdLeafIterator class
  which is a iterator to visit all leaf element(knot spans)

For this week, I'm going to continue with BSplineGridEntity class and more contents of BSplineGirdLeafIterator class.

NURBS geometry interface

Then let's have a look at how to generalize the B-Spline geometry nterface to NURBS. You may probably know that NURBS is a projective B-Spline in higher dimension space. Analytically, NURRBS can be expressed by B-Splines with weights of control points. When all the weights are the same, a NURBS is degenerated into a B-Spline.

I try to make use of  property and correlate each NURBS object with a B-Spline object. Then most functions can be decomposed into three steps: first lift the NURBS to the corresponding B-Spline in the one dimension higher space, then do all computation on this B-Spline using the implemented B-Spline functions, project the B-Spline back to the NURBS, But for derivative, it's a bit tricky. I will talk it later.

So of course, a NURBS patch should also contain the weight gird corresponding to the control gird in addition to other information which a B-Spline patch requires.

Fig.2. A NURBS suface with same control points but different weights as Fig.1.

B-Spline geometry interface

Hello all,

In the past few weeks, I have almost finished a complete B-Spline geometry interface and NURBS as well except for the inverse.

In this post, I'm going to describe the important aspects of the B-Spline geometry interface. As you can easily get all the functions required for a DUNE geometry interface, I am not going to elaborate all of them here. But I would like to specifically point out the mathematical model behind some tricky functions in case you want to review the code later. 

1, LocalCoordinate global (const GlobalCoordinate &global) const

The function defines the mapping from the parameter space to the physical space. In isogemetric analysis, each valid(not repeated knots) knot span acts as an element. From definition, we know that a pth-order B-Spline geometry is a weighted sum of all the control points, where the weights are the p-th order basis functions defined on the given knot vector. Normally, we need to build the whole basis function pyramid from the bottom to top to get the p-th order basis we need. But actually for a specific parameter, most values in the pyramid are zeros and the nonzero values will form  an inverted triangle. We also store the knot differences in another triangle as we may need them quite often both for the evaluation and other operations(e.g. derivatives of the basis functions). So together they form an (p+1) by (p+1) table. Please check "The NURBS book" for more details about this algorithm. The computation of the p+1 non-vanishing basis functions of order p are achieved via the getBasis function. Then in the global function, the control points corresponding to the non-zero basis functions will be picked and multiplied with the them.

Fig.1. A B-Spline surface

2.JacobianTransposed jacobianTransposed (const LocalCoordinate &local) const

This function requires all first partial derivative of the B-Spline geometry. And the B-Spline derivative can boil down into the derivative of the basis function. The derivative of a p-th order B-Spline function requires two neighboring (p-1)order B-Spline basis functions. Similar to the computation of the basis functions, we only compute the non-zero basis derivatives. So we can reuse the table build by the getBasis function. We need to compute the derivative vector for each parameter variable, decided by the dimensionality of the B-Spline geometry. Each time, we replace the basis function by the derivative of the basis function with respect to a certain parameter in the original B-Spline definition formula.

Some other interface functions like the inverse mapping  and the volume are very challenging in B-Spline scenarios and also not quite useful, so we decided to skip them and move forward to other more important functionalities.

Project description and timelines

I'm Xinyun Li, a master student of Medical Engineering in Erlangen university, Gemrnay.  It's great honor for me to have the chance to contribute to DUNE as a GSoC student. DUNE is a modular toolbox for solving partial differential equations (PDEs) with grid-based methods. This summer, I'm going to work on spline geometries for  isogeometric analysis. 


Project description
Isogeometric analysis is a finite element technique that allows to solve partial differential equations defined on spline surfaces. This is useful because a lot of geometries used in engineering are directly available in this format, and the grid generation step can be skipped. However, no Dune grid implementation is currently able to represent spline geometries. The goal of this project is to develop such a grid manager for the special case of spline surfaces representable as a single tensor-product patch.

Project milestones and timelines:
1.Implement the complete Geometry interface in the B-spline prototype(4 weeks)
   Here is a documentation of Dund geometry interface. I am supposed to implement all members listed there. 
2.Generalize the geometry interface from B-splines to NURBS(4 weeks)
2.Add iterator access and index sets to the above two grids to help ascess the gird elements more easily. (3 weeks)
Due to my personal schedules, I'm not able to work full time in July. So I would like to strat earlier and end earlier. I started working from mid April and have have already got some outcomes. 

Difficulties:
Among all the interface functions, the inverse mapping is the most challenging one. Because the forward mapping is a recursive process. So I think it's analytically impossible. We need to find other ways to get the solution.
Besides,  all functions require integration over the physical space is non-triveil.  A linear solver may be needed.