-
Notifications
You must be signed in to change notification settings - Fork 0
Description
I first introduced the DistributedSingleFieldFEFunction struct:
https://github.com/ghislainb/BcubeParallel/blob/222327b7e46840d7b229beabf12049b401d34402/src/interpolation/fefunction.jl#L5
to be able to specialize the function set_dof_values! to append a update_ghosts after setting the values:
https://github.com/ghislainb/BcubeParallel/blob/222327b7e46840d7b229beabf12049b401d34402/src/interpolation/fefunction.jl#L39
If you don't introduce a custom struct and only rely on the arguments of set_dof_values to dispatch:
function set_dof_values!(f::SingleFieldFEFunction{S,FE}, values; update_ghosts) where {S, FE <: TrialOrTest{S, <: AbstractDistributedSingleFESpace}
update_ghosts(values)
set_dof_values!(f, values) # wrong : infinite recursion !
endthis is a dead-end since you cannot call set_dof_values! on a sub-structure (but we could write feFunction.dofValues = (...), i.e copying the content of Bcube.set_dof_values! in BcubeParallel.set_dof_values).
The problem is that I now want to introduce the different FEFunction constructors (FEFunction(U, dofValues), FEFunction(fU, mesh, f) etc). It would be nice to do
function FEFunction(U <: AbstractDistributedSingleFESpace, args...; update_ghosts = true)
feFunction = FEFunction(U, args...) # wrong : infinite recursion !
# (...)
return DistributedSingleFieldFEFunction(feFunction)
endbut again it's not valid because of infinite recursion.
In summary, we may need to better define what we want from a FEFunction in parallel (set_dof_values with update_ghosts or not?) before choosing an implementation.