dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 21/04/11 16:21, Anders Logg wrote:
> 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.
> 

It's more complicated that just that. Solvers and preconditioners have
*many* specific parameters.

>> 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.


Taking that further, it's not natural that VariationalProblem has a
'solve' member function. If it has a 'solve' member function, then it's
logical can the solver can be supplied.

Garth


> 
> --
> Anders