dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Apr 20, 2011 at 10:48:34AM +0100, Garth N. Wells wrote:
>
>
> On 19/04/11 19:21, Anders Logg wrote:
> > Question #153459 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/153459
> >
> >     Status: Open => Answered
> >
> > Anders Logg proposed the following answer:
> > On Tue, Apr 19, 2011 at 09:54:43AM -0700, Johan Hake wrote:
> >> On Tuesday April 19 2011 09:45:58 Chaffra wrote:
> >>> Question #153459 on DOLFIN changed:
> >>> https://answers.launchpad.net/dolfin/+question/153459
> >>>
> >>> Chaffra gave more information on the question:
> >>> The newton_solver is no longer accessible from VariationalProblem. I used
> >>> to be able to set the linear_solver parameters via
> >>> problem.newton_solver().linear_solver().parameters ... Is there a new way
> >>> of doing this?
> >>
> >> I think Garth is the man to answer this, but I recall he removed that options
> >> because it became difficult to maintain as the linear solver can be of many
> >> different types.
> >>
> >> The solution, I think, is to create the linear solver before you create the
> >> NewtonSolver, grab the parameters, create the NewtonSolver, change whatever
> >> parameters to the LinearSolver you need through the grabed paraemters.
> >
> > I think I made a change recently to include the Newton solver
> > parameters in the parameter list for a VariationalProblem.
> >
> > If you use
> >
> >   info(problem.parameters, True)
> >
> > then you should see the parameters for the Newton solver.
> >
> > The solver type and preconditioner cannot be set by parameters at the
> > moment. The problem is that the Newton solver gets these parameters in
> > the constructor. It should use the parameter system instead.
> >
>
> I don't think that it should use the parameter system. It complicates
> the design (because objects can't be created in the constructor), and
> it's not feasible to expose all solver and preconditioner parameters
> from a VariationalProblem object.

I agree it complicates the design but that's how it's handled in other
classes and the way it has to be done in order to use the parameter
system: postpone initialization to when solve() is called so that
parameters can be read.

> The best approach to fine-grained control is to pass a linear solver
> object to VariationalProblem at construction, and set parameters for the
> solver object. NewtonSolver does this.

It does not seem natural that a VariationalProblem can take a solver
object in its constructor.

--
Anders