Le 31 janv. 2014 à 10:46, Anders Logg <[email protected]> a écrit :
> I still don't see the point. How can you not accomplish that by
> creating a subclass of NonlinearProblem directly, instead of via an
> additional wrapper layer in the form of NonlinearDiscreteProblem?
>
Yes, I agree you can. But the codes (about 10 lines) would be always the same
in 90% of cases.
> It sounds like what you are asking for is an interface in between
> NonlinearProblem and NonlinearVariationalProblem, which takes care of
> assembly, but leaves nonlinear solve to the user. By the same
> reasoning, we could add yet another interface which takes care of
> nonlinear solve but leaves assembly to the user...
Yes this is exactly what of I was asking (and Patrick too, if I correctly
understood its message).
Let's say a default implementation of NonlinearProblem taking as input
something like NonlinearVariationalProblem.
But I understand that it is necessary and sane that you and Garth make design
choices to reduce the (too many) ways of formulating problems and the
interfaces to maintain.
After all it is really a minor point. It is reasonable that if someone want to
work at low level, he stays low-level both in assembling and solving and takes
care of copying and pasting its default implementation of NonlinearProblem.
In any case the discussion was useful for me. That led me thinking also that
there may be some issues to care of about the way of imposing non-homogenous
boundary conditions when using PETScSNESSolver. And the control of
NonlinearProblem assembling could be indeed useful in those cases.
Corrado
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
