Question for dofs generation in DofHandler

[zkk960317]

There is such a complicated procedure used in the dofs generation in DofHandler. Its idea is to loop through the cell list and push new dofs, and keep track of visited vertices, edges, and faces to make sure there are no duplicates.
However, it is simpler to create dofs based on the node list and then assign dofs to cells according to their node information. A simple example is shown below.

    numfields = lastindex(dh.field_names)
    num_node_dofs = sum([dh.field_dims[i] for i in 1:numfields])

    nnodes = getnnodes(dh.grid)
    node_dofs = 1:nnodes*num_node_dofs
    cell_dofs = Int[]
    cell_dofs_offset = [1]

    for (ci, cell) in enumerate(getcells(dh.grid))
        for node in cell.nodes
            di = (node - 1) * num_node_dofs # start dof - 1
            append!(cell_dofs, node_dofs[di+1:di+num_node_dofs])
        end
        push!(cell_dofs_offset, lastindex(cell_dofs) + 1)
    end

In addition, the nodes in a cell is by default arranged in the order of vertices, edges, and surfaces by default. Moreover, the above code may only work for the default interpolation. So there exists another question, is it necessary to use an interpolation higher or lower than the order of the cell.

There must be some other consideration in DofHandler, but I don't really understand it, so I'm hoping someone will clear it up.

[koehlerson]

I think what you are proposing is only valid for Lagrangian type of interpolations where the order of the geometric interpolation matches the one of the finite element field (which is not necessarily the case). There are other elements, where the dofs are associated to edges even though there is no node in the middle of the edge see e.g. https://defelement.com/elements/raviart-thomas.html

[zkk960317]

Thanks your comment @koehlerson. Is it possible to create a separate function for distributing dofs for Lagrange interpolation. Its can improve performance, after all Lagrange interpolation is the most commonly used.
The following is a test.
Method 1 refers to the default method in DofHanler, Method 2 refers to the method commented above.
For 5000*5000 Quadrilateral cells. Method 1: 3.99 s; Method 2: 3.36 s.
For 5000*5000 QuadraticQuadrilateral cells. Method 1: 27.54 s; Method 2: 6.68 s.
For cells with face nodes, the advantages of method 2 are obvious. Predictably, the gap is even larger for higher-order 3D cells.

[koehlerson]

I think it's important to scale those numbers by the time one solution of the linear system of equations take. I tested 3000x3000 quadrilaterals on my laptop which already takes 77s for the most simplistic elliptic scalar problem. Not sure how long it is for the QuadraticQuadrilaterals since any larger system doesn't fit in my memory.

While it is in principle possible to split the algorithms by the kind of finite element space you are using, the benefit is rather small, since this isn't the bottleneck of the overall simulation time

[termi-official]

It probably makes sense to provide some special dof handler for this case which makes the assumption that

1. We have only isoparametric interpolations
2. We have a single subdomain covering the whole domain

This will also allow to directly load some VTK files.
However, this requires resolving #622 first.

Note that Ferrite already provides functionality to reorder dofs. See https://ferrite-fem.github.io/Ferrite.jl/stable/reference/dofhandler/#Dof-renumbering .

[fredrikekre]

I also think it is simpler to always use the same strategy for the distribution instead (even if that strategy is in some cases a bit too complicated, perhaps).