koehlerson / fesolvers.jl Goto Github PK

Maybe it is a good idea to interface against SciML, because they already have quite some infrastracture which we can reuse. The current design also has already some similarities with the design of their "Problem - Solver" pairs. This way we can also try to gain some momentum on SciML/OrdinaryDiffEq.jl#1570 which possibly unlocks a range of interesting solvers for time-dependent problems, whose semi-discretization with finite element methods often simply leads to ODEs or DAEs. See e.g. https://ferrite-fem.github.io/Ferrite.jl/stable/examples/ns_vs_diffeq/ for a first simple example.

These are some thoughts/experiences I have obtained from generalising the solvers in my Five.jl package.

I think every solver will have some sort of time step loop + updating variables + exporing stuff, so that could be abstracted out, see here in Five: https://github.com/lijas/Five.jl/blob/da1ed34cb6bbd7326166c773081d29200dee86c9/src/solvers/solver.jl#L41
I think that creates code sharing between solvers that are reasonable.

Then each solver can implement a step!(::AbstractSolver, state, femodel), which advanced the state by some amount (decided by the solver itself). For example https://github.com/lijas/Five.jl/blob/da1ed34cb6bbd7326166c773081d29200dee86c9/src/solvers/newton_solver.jl#L23
I think this generalises for most solvers.

The ::State data type is pretty important. Everything that is needed to advance the system forward should be included in it(ie states + time derivatives). In this way, one can do stuff like "state"-saving (for restarts etc), or pass the state between different solvers etc.
https://github.com/lijas/Five.jl/blob/da1ed34cb6bbd7326166c773081d29200dee86c9/src/Five.jl#L106