Open kimauth opened 1 year ago
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#L328getfielddim
-> https://github.com/Ferrite-FEM/FerriteViz.jl/blob/817048dbc72619f0a70f4a16c267329ebd366f93/src/utils.jl#L329field_offset
-> https://github.com/Ferrite-FEM/FerriteViz.jl/blob/817048dbc72619f0a70f4a16c267329ebd366f93/src/utils.jl#L347getfieldinterpolation
-> https://github.com/Ferrite-FEM/FerriteViz.jl/blob/817048dbc72619f0a70f4a16c267329ebd366f93/src/utils.jl#L332getfieldinterpolation
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 :)
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.
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.
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}
.
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
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
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.
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.
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 .
Here is a list of functions that could constitute a
AbstractDofHandler
interface in the future:find_field(dh, fieldname)
--> return some type of field indexfield_offset(dh, field_index)
getfieldinterpolation(dh, field_index)
getfielddim(dh, field_index)
getfieldnames(dh)
I don't think
getfielddims
andgetfieldinterpolations
are necessary in an interface, they could probably be removed to the point of being internals forMixedDofHandler
.I leave this issue here for future reference, I compiled the list while working on merging the dofhandlers - it needs some more investigation.