dolfin team mailing list archive

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

On 21/06/11 09:56, Anders Logg wrote:
> On Tue, Jun 21, 2011 at 09:45:27AM +0100, Garth N. Wells wrote:
>>
>>
>> On 21/06/11 08:58, Anders Logg wrote:
>>> Thanks for looking into this. So it looks like this will work out
>>> fine. So are there any objections to changing the VariationalProblem
>>> (which depends on the order of arguments) to the more explicit
>>>
>>>   LinearVariationalSolver
>>>   NonlinearVariationalSolver
>>>
>>> *solver* classes (instead of problem classes so that it's consistent
>>> with the way we treat la),
>>
>> What about also having
>>
>>   LinearVariationalProblem
>>   NonlinearVariationalProblem
>>
>> as more-or-less containers for defining the problem. Something that
>> these may be useful for is writing and reading restart files (especially
>> in parallel),
>>
>>   // Create problem
>>   LinearVariationProblem problem(......);
>>
>>   // Write check point
>>   problem.checkpoint("restart_file.hdf5");
>>
>> or
>>
>>   File f("restart_file.hdf5");
>>   f << problem;
>>
>> We could then have a common
>>
>>   VariationalSolver variation_solver(problem, linear_solver, . . . );
>>
>> interface.
> 
> Maybe, but could this not be handled by the solver classes?
> 
> solver = NonlinearVariationalSolver(F, J, etc)
> solver.set_checkpoint("restart_file.hdf5")
> solver.parameters["..."] = ...
> solver.anything_else()
> solver.solve()
> 

Yes, but it would make  he class more complicated and it would be
unclear is the data that defined the problem is being saved (Mesh,
coefficient vectors, dof map) or or of the state of the solver is being
saved (preconditioner, etc).

Martin threw up encapsulating the problem definition and I don't think
that it's been adequately discussed yet for a conclusion to be drawn.

Garth



> --
> Anders