dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Aug 19, 2008 at 07:27:58AM -0500, Matthew Knepley wrote:
> On Tue, Aug 19, 2008 at 7:06 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Tue, Aug 19, 2008 at 01:49:22PM +0200, Jed Brown wrote:
> >> On Tue 2008-08-19 13:40, Anders Logg wrote:
> >> > On Tue, Aug 19, 2008 at 12:12:50PM +0200, Jed Brown wrote:
> >> > > On Tue 2008-08-19 11:59, Anders Logg wrote:
> >> > > > On Thu, Aug 14, 2008 at 10:10:03PM +0000, Jed Brown wrote:
> >> > > > > One way to implement this is to allocate a vector for Dirichlet values,
> >> > > > > a vector for Homogeneous values, and a Combined vector.  The Homogeneous
> >> > > > > vector is the only one that is externally visible.
> >> > > >
> >> > > > Isn't this problematic? I want the entire vector visible externally
> >> > > > (and not the homogeneous part). It would make it difficult to plot
> >> > > > solutions, saving to file etc.
> >> > > >
> >> > > > Maybe the Function class could handle the wrapping but it would involve a
> >> > > > complication.
> >> > >
> >> > > Right, by `externally visible' I mean to the solution process, that is
> >> > > time-stepping, nonlinear solver, linear solvers, preconditioners.  The
> >> > > vector you are concerned about is the post-processed state which you can
> >> > > get with zero communication.  It is inherently tied to the mesh and
> >> > > anything you do with it likely needs to know mesh connectivity.  I don't
> >> > > think it is advantageous to lump this in with the global state vector.
> >> > >
> >> > > Jed
> >> >
> >> > I don't understand. What is the global state vector?
> >>
> >> The global state vector is the vector that the solution process sees.
> >> Every entry in this vector is a real degree of freedom (Dirichlet
> >> conditions have been removed).  This is the vector used for computing
> >> norms, applying matrices, etc.  When writing a state to a file, this
> >> global vector is scattered to a local vector and boundary conditions are
> >> also scattered into the local vector.  The local vector is serialized
> >> according to ownership of the mesh (you have to do this anyway).
> >>
> >> Jed
> >
> > I'm only worried about how to create a simple interface. Now, one may
> > do
> >
> >  u = Function(...);
> >  A = assemble(a, mesh)
> >  b = assemble(L, mesh)
> >  bc.apply(A, b)
> >  solve(A, u.x(), b)
> >  plot(u)
> >
> > How would this look if we were to separate out Dirichlet dofs?
> 
> This is why we have a restrict/update() paradigm, whereas we have
> different assemblies
> for global vectors. The assemble would produce a system without BCs.
> However, plot()
> must access values in 'u', with restrict() which would give back all
> values including BCs.
> This is how it currently works in PETSc, so we can have this paradigm.
> 
>   Matt

I don't mind restrict()/update() but to me those are low-level
operations that shouldn't be visible in the user-interface.

-- 
Anders

Attachment: signature.asc
Description: Digital signature