dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Aug 19, 2008 at 06:30:35PM +0200, Jed Brown wrote:
> On Tue 2008-08-19 18:24, Anders Logg wrote:
> > 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.
> 
> Is this a problem?  There is already the Function abstraction.
> Operations on functions are defined in terms of the ordering that makes
> sense.  There isn't even any communication required to go between the
> Global vector and the Global+Dirichlet vector.
> 
> Jed

What would this look like? Can you give an example, it feels low-level
to me.

-- 
Anders

Attachment: signature.asc
Description: Digital signature