Extension for different cells

[koehlerson]

Currently there is no documentation at all how to handle special types of cells. The package should have some sort of interface how cells can be triangulated.

Probably https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/utils.jl#L26-L32, https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/utils.jl#L35, https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/utils.jl#L94-L98 together with a decompose! dispatch as here https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/utils.jl#L112-L207 is all that is needed.

ping @termi-official, @kimauth needs it for e.g. for trusses, so embedded lines and probably cohesive zone elements

[kimauth]

I need it for cohesive elements which have a different node numbering than the Ferrite Quadrilaterals. They're still 4-noded 2D elements though, so I guess it should be enough to tell FerriteViz that it can treat them like Quadrilaterals with a different node numbering somehow?

[koehlerson]

Can you specify how they are subtyped from AbstractCell? Is it AbstractCell{2,4,4}?

[kimauth]

struct CohesiveCell{dim,N,M} <: Ferrite.AbstractCell{dim,N,M}
    nodes::NTuple{N,Int}
end

const CohesiveQuadrilateral = CohesiveCell{2,4,2}

but then I use this node numbering:

3______________4
|              |
1______________2

[termi-official]

I have not put any effort in the docs because this portion is very likely going to change. I think making a custom decompoae function (see https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/utils.jl#L134-L196) is sufficient. You can just go forward and hard code the triangles instead of using the loop which I build. Sometimes it is also fine to just split the quad into 2 triangles instead of 5.

All this methods must do is setting the corrdinages in coord_matrix, ref_coord_matrix and triangle_matrix as well as returning the new indices. For the preallocation you also need to provide a ntriangles overload (see https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/utils.jl#L134-L196). I think that is it.

[kimauth]

Defining decompose and ntriangles indeed let's me plot the grid for my custom elements (and correctly recognizes which sides are faces I think). For plotting a solution I however also run into problems with my interpolations, which are non-standard too. Would be nice if it was possible to just specify the interpolation that should be used for plotting.

[termi-official]

What is the problem you run into? Currently we use the interpolation which is specified in the dof handler (see https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/utils.jl#L2-L6). Or what interface do you need?

Do you possibly have a MWE for your issue?

[kimauth]

Yeah that's exactly the problem. I have various types of pretty custom interpolations on these cohesive elements - they have different dims etc. I'd like to specify the interpolation that should be used for plotting instead of assuming whatever is in the DofHandler is suitable.

[termi-official]

I am not sure this is straight forward to do, because we would need to mirror the functionality of the dof handler internally, since the interpolation does not have any information of the dof mapping between the solution vector and the current element (see cell_dofs field in DofHandler). Maybe I am still misunderstanding something - what exactly is the problem in putting a suitable dof handler into the renderer?

[koehlerson]

We should revive this issue and provide some basic decompose api. Shouldn't be too strict to rely on proper Interpolation and <:AbstractCell definition together with a decomposition in triangles.

Would be nice to visualize https://github.com/kimauth/FerriteCon2022.jl/blob/main/plotting/logo_animation.jl with FerriteViz as a gif for the readme

[termi-official]

I never forgot about the issue. :P Just do not have enough hands here. Before making the user-facing portion for this stuff I need to think a bit more about the tandem tessellation, because I think the current interface will break soon. I think we just want to keep the geometric tessellation and need to tessellate this one according to the interpolation+local solution pair. Right now we never use the solution interpolation information during tessellation, which is a big bummer.

Do you have some concrete suggestion regarding an interface to manage arbitrary additional interpolations for arbitrary grid+dof handler pairs (that can be made reasonable type-stable)?

[koehlerson]

I mean you just need the information of faces (+ how much triangles) and value dispatch from the interpolation on the triangles or am I missing something?

[termi-official]

How do you get the number of triangles for an arbitrary cell with arbitrary interpolations during construction?

[koehlerson]

by an API that the user fulfills for us as e.g. @kimauth could do with CZ elements by dispatching

FerriteViz.ntriangles(c::CZcell) = something FerriteViz.value(ip::CZIP)....

[termi-official]

So, in https://github.com/Ferrite-FEM/FerriteViz.jl/blob/c070140a00907efa1cbf8bb4931556d525b2e363/src/utils.jl#L64-L67 we are currently precomputing the number if triangles (which I know is problematic) and https://github.com/Ferrite-FEM/FerriteViz.jl/blob/c070140a00907efa1cbf8bb4931556d525b2e363/src/utils.jl#L79-L83 we precompute the tessellation of a corresponding linear element. This API is problematic, because, in general, for arbitrary nonlinear geometries we do not know a priori what a good tessellation would look like. So far for the geometrical decomposition.

Now, to make the visualization better, we would need to refine this decomposition for the currently selected field in e.g. solutionplot. Here can go over all fields in a dof handler and compute the finest adaptive tessellation a priori. So this is the step you want to merge into the loops above?

[koehlerson]

I think we are talking about different things. I just want to have a properly documented interface such that plots like the CZ thing works. It would already be an improvement to plot it linearly (as it is done now anyways). Doesn't need to be super complicated for now.

1. ntriangles
2. easier decompose, i.e. some function that is called inside decompose!

and that should be it for the moment

[termi-official]

The manual ntriangles hack should be removed as soon as possible. Regarding the decompose API, we should indeed be able to simplify it. Especially for adaptive tessellation and cut-planes.

Edit: Maybe we can provide some base-primitives for the tessellation (i.e. triangle and quad). However, I cannot think of a good API for general, arbitrary polygons without using NetGen, Gmsh or something in this direction, which will hurt performance.

Edit 2: So, if we start documenting the current interface it basically becomes public and users will start to rely on it. This can make updates for users problematic when we overhaul the interface soon (which I really have to do, but i could not find a good design yet).

[koehlerson]

Edit 2: So, if we start documenting the current interface it basically becomes public and users will start to rely on it. This can make updates for users problematic when we overhaul the interface soon (which I really have to do, but i could not find a good design yet).

I don't mind having a breaking public api if we get more functionality as a trade off for now. People who will use this interface will probably be willing to accept breaking changes.

[termi-official]

Well, maybe we can meet in the middle. I can make a PR with the devdocs and we can refers users with custom elements to the devdocs while leaving the public API for now untouched. What do you think?