dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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