On Tue, Jun 21, 2011 at 10:05:10AM +0100, Garth N. Wells wrote:
>
>
> 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.
Could we postpone that decision to later, until it's time to to
implement the set_checkpoint functionality and such?
I looks to me like it can be added later without affecting the
currently suggested interface. If we have
LinearVariationalSolver solver(a, L, u, bc, ...);
we could later add (in addition):
LinearVariationalSolver solver(problem);
where problem is a LinearVariationalProblem.
--
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
