dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Nov 02, 2009 at 04:58:44PM +0100, Jed Brown wrote:
> Anders Logg wrote:
> > On Mon, Nov 02, 2009 at 04:31:10PM +0100, Jed Brown wrote:
> >> Anders Logg wrote:
> >>
> >>> The default update procedure would be interpolation.
> >> Which interpolation?  Perhaps the user needs it to be conservative or
> >> preserve some other structure.  What if they want to use different
> >> schemes for different functions on that mesh?
> >
> > The standard interpolation defined by the finite element space. So for
> > example nodal evaluation for Lagrange elements.
>
> This is the natural choice, but it wasn't really a serious question; I
> think it is important that the granularity be finer (so you can apply
> different schemes to different functions defined on a mesh).

We can provide a mechanism for allowing users to define the update
function if there is need for it.

> >> You can't implement refinement in-place anyway.  Providing an interface
> >> that looks in-place just means that users have to rewrite larger pieces
> >> of their code when they need more control.  I would suggest that
> >> refinement produces a new mesh and then provide methods to transfer
> >> functions and solver objects to the new mesh.
> >
> > Perhaps, but it could require quite a bit of work (from the user) to
> > keep track of which objects should be transferred: function spaces,
> > functions, forms.
>
> It is important that the interface allows the user to be involved.
> Transfering a high-level object like a nonlinear solver would transfer
> everything it has a reference to, which means most users would have
> something more like
>
>   new_mesh = mesh.refine
>   new_V = FunctionSpace(new_mesh, V.spec())
>   new_solver = transfer(solver, new_V, interpolation='Conservative')
>   new_f = transfer(other_function, new_V, interpolation='Galerkin')
>
> A further issue with in-place updates is that linear algebra objects
> need to be destroyed and recreated because they can't be changed
> in-place.  This is troublesome when the user holds a reference to any of
> these.

Matrices and vectors are too low in the chain for DOLFIN to take any
kind of responsibility for updating them. What we can do is to make
sure that the following works:

while e > TOL:

  A = assemble(a)
  L = assemble(b)

  solve(A, u.vector(), b)

  mesh.refine()

--
Anders

Attachment: signature.asc
Description: Digital signature