Sorry for the slow reply here. On Wed, Aug 31, 2016 at 8:49 AM, Julian Andrej <j...@tf.uni-kiel.de> wrote:
> I have looked into that a bit more today and it seems there is > everything we need available (finally). Then i'd have another question > regarding the use of FEMSystem. What would be the actual use case of > choosing FEMSystem vs. the approach in most examples? I have used the > normal example approach because my projects were pretty much just "a > single usecase". Our specific approach would be to have one physics > model and then test and combine different algorithms from variying > research fields (model order reduction / control theory) on that, so > we would interact with the RHS and Jacobian matrices a lot (thats the > reason we want to access the raw PETSc objects). FEMSystem automates things like the element loop, assembly into the global solution and Jacobian objects, etc. so that the user only has to supply element level evaluations of the residual and Jacobian. Further, it abstracts away things like the nonlinear solver (DiffSolver) and the time stepping schemes (TimeSolver) to be able to modify those independently of the "Physics" that you're using. So, the trade-off is there's more infrastructure to help get you going, but perhaps requires more/different work if you want more flexibility, e.g. if you want to muck with the solver, you'd have to subclass DiffSolver to implement your own thing. Just FYI, the GRINS code (https://grinsfem.github.io) that Roy and I develop/use (but any of the bad design decisions are my fault) is built around FEMSystem; Roy and I have a paper on this in press in SISC. ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
