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 <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
