dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Jun 21, 2011 at 11:20:20AM +0200, Anders Logg wrote:
> 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.

Looks like it's needed for the adaptive algorithms so I will add those
classes also (LinearVariationalProblem, NonlinearVariationalProblem).

--
Anders