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
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
