dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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()

--
Anders