Idea collection for a dofhandler interface

[kimauth]

Here is a list of functions that could constitute a AbstractDofHandler interface in the future:

• find_field(dh, fieldname) --> return some type of field index
• field_offset(dh, field_index)
• getfieldinterpolation(dh, field_index)
• getfielddim(dh, field_index)
• getfieldnames(dh)

I don't think getfielddims and getfieldinterpolations are necessary in an interface, they could probably be removed to the point of being internals for MixedDofHandler.

I leave this issue here for future reference, I compiled the list while working on merging the dofhandlers - it needs some more investigation.

[koehlerson]

thinking of FerriteViz I would need all of the mentioned methods

• find_field -> https://github.com/Ferrite-FEM/FerriteViz.jl/blob/817048dbc72619f0a70f4a16c267329ebd366f93/src/utils.jl#L328
• getfielddim -> https://github.com/Ferrite-FEM/FerriteViz.jl/blob/817048dbc72619f0a70f4a16c267329ebd366f93/src/utils.jl#L329
• field_offset -> https://github.com/Ferrite-FEM/FerriteViz.jl/blob/817048dbc72619f0a70f4a16c267329ebd366f93/src/utils.jl#L347
• getfieldinterpolation -> https://github.com/Ferrite-FEM/FerriteViz.jl/blob/817048dbc72619f0a70f4a16c267329ebd366f93/src/utils.jl#L332

getfieldinterpolation would be quite important in this use case. We introduced the function barrier _transfer_solution for it since otherwise lots of entities are type unstable. So, to clarify: I agree in all of the proposed methods and want to highlight the need for it with concrete examples :)

[termi-official]

Just to clarify my understanding here, what is field_index? If it is only an int, then this might be ambiguous, because different FieldHandlers can have different interpolations at the same field index.

[termi-official]

Another thing which we might want to consider is what should getfieldinterpolation return. Think for example about P adaptivity or virtual elements, where the Interpolation on each element (not field) is possibly different.

[kimauth]

Just to clarify my understanding here, what is field_index? If it is only an int, then this might be ambiguous, because different FieldHandlers can have different interpolations at the same field index.

field_index could be something different for each implementation, the requirement would just be that the other functions can take it in. E.g. for the current DofHandler it would be an Int, but for the current MixedDofHandler it would be a Tuple{Int, Int}.

[koehlerson]

A use case that should be supported, imo, is the use of a dh which is <: AbstractDofHandler, a field_name and a dof vector to iterate over the field. This use case occurs in FerriteViz, where we assume to get a dh and a field_name to plot the field.

To make this work we need to get all fieldhandlers that contribute to the given field with the given field name. Take for instance this example from the test suite: https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/test/test_mixeddofhandler.jl#L437-L485

Here, I would like to have a function getfieldhandlers (or named differently) that returns an iterateable object which contains all fieldhandlers that are relevant to :v. In case of a "normal" field without subdomains a iterateable object of length one should be returned with a fieldhandler that defines the field over the whole domain

[koehlerson]

I tested the interface of https://github.com/Ferrite-FEM/Ferrite.jl/pull/621 and the following example: https://github.com/Ferrite-FEM/FerriteViz.jl/blob/mk/mixeddofhandler/docs/src/ferrite-examples/mixedgrid.jl

I included the getfieldhandlers function in FerriteViz for the moment: https://github.com/Ferrite-FEM/FerriteViz.jl/blob/mk/mixeddofhandler/src/utils.jl#L316-L334

The defined interface of https://github.com/Ferrite-FEM/Ferrite.jl/pull/621 + the getfieldhandlers seems to be sufficient for the use case described above

[termi-official]

Maybe I am understanding the purpose of the thread wrong, but what about celldofs[!] and dof_range? Further, I would not include that renumber! is part of the general interface.

[termi-official]

In https://github.com/Ferrite-FEM/FerriteDistributed.jl/blob/9748b37ef8d0c1079cadc2fb03f3f4f5df166815/src/NODDofHandler.jl (currently private to Ferrite org) we have more candidates for the dof handler interface emerging.

[termi-official]

I think we can also approach this issue after 1.0 release, as it is technically non-breaking, since we never defined an interface @fredrikekre .