IGA implementation

[potto1]

There are the two concepts FEM and IGA. In FEM almost everything is implemented on a reference element. In IGA the geometry is described by NURBS and NO reference elements are defined. In order to take a further step towards a functioning IGA implementation I would like to discuss the following architecture consisting of three classes:

1. Class MeshIga
2. Changes in the class Nurbs (Nurbs.h)
3. Class UnitMeshIga

1. Class MeshIga: This class stores the Nurbs geometry for each DOF

template <int TDimParameter>
class MeshIga
{
public:
    MeshIga() = default;

    MeshIga(const MeshIga&) = delete;
    MeshIga& operator=(const MeshIga&) = delete;

    MeshIga(MeshIga&&) = default;
    MeshIga& operator=(MeshIga&&) = default;

    Group<NodeSimple> NodesTotal()
    {
        throw Exception(__PRETTY_FUNCTION__, "Iga - Not implemented yet!");
    }

    Group<NodeSimple> NodesTotal(DofType d)
    {
        throw Exception(__PRETTY_FUNCTION__, "Iga - Not implemented yet!");
    }

    Group<ElementCollectionIga<TDimParameter>> ElementsTotal()
    {
        throw Exception(__PRETTY_FUNCTION__, "Iga - Not implemented yet!");
    }
public:
    DofContainer<Nurbs<TDimParameter>> mDofNurbs;
    ValueVector<ElementCollectionIga<TDimParameter>> mElements;
};

• The control points (aka nodes) are stored in the class Nurbs<TDimParameter> in a ValueVector (see below)
• The elements extracted from the mDofNurbs are stored in mElements

2. Changes in the class Nurbs (Nurbs.h):

• The Nurbs class should store the control points (like MeshFem) and not the pointers
• So far the class Nurbs may only represent curves and surfaces, thus the data structures holding the control points and weights should be represented by a vector and tensor product calculations are applied to access the desired control point or weight (like reshape in python)

  ValueVector<NodeSimple> mControlPoints;
  ValueVector<double> mWeights;

  3. UnitMeshIga:

• Lines and rectangles may be represented as a Nurbs with only one element
• Procedures like knot insertion increases the element number and are implemented in the class Nurbs

[TTitscher]

Sounds good. And just as a reminder: As long as ElementIga implements ElementInterface, everything like assembly/numbering/visualization/... should be fine. So there is no need to follow the implementation of MeshFem just for the reason of the two to look similar. Just some hints to think about:

• Following the idea of @Psirus in your previous issue #187, we could rather name the methods ControlPointsTotal(), which I would like.

• Maybe there is no problem in copying MeshIga and copy construction/assignment may be allowed, if that helps somehow

  • A MeshFem copy is a problem because nodes are saved by reference at the elements. In your case they seem to be stored by value and coping could IMO be allowed.

• A std::vector may replace the ValueVector in some cases. (Definitely for mWeights).

• The methods from UnitMeshIga could go into MeshIga.

  • For MeshFem there are currently three ways of creating meshes, separated into three files. Manually adding nodes/elements (basic features of MeshFem.h), by importing them from gmsh (MeshGmsh.h) or by the static UnitMeshFem.h methods.

• How about private members? They allow a more controlled usage of the class. So maybe only member functions modify the Nurbs/Elements and const access to would be enough.

  • MeshFem has public members to grant straight forward access to the various mesh creation methods. (Mainly out of lazyness in the early design. Adding a AddNode and AddElement may avoid this...)

Edit: Just to be clear: There is no need to implement everything mentioned in the points above. It should only remind you to implement things how they fit best for MeshIga. This is exactly the reason why everything "above" the mesh (cells, assembly...) works with ElementInterface instead of MeshFem or ElementIga. So there is no MeshInterface or MeshBase and you can really do whatever fits best for the problem.

[joergfunger]

Looks good. There is just a question on how to store different patches. How would this be achieved?