dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, May 29, 2006 at 08:30:50PM +0200, Garth N. Wells wrote:
> On Mon, 2006-05-29 at 20:23 +0200, Anders Logg wrote:
> > On Mon, May 29, 2006 at 07:54:12PM +0200, Garth N. Wells wrote:
> > > On Mon, 2006-05-29 at 19:47 +0200, Anders Logg wrote:
> > > > On Mon, May 29, 2006 at 07:40:28PM +0200, Garth N. Wells wrote:
> > > > > On Mon, 2006-05-29 at 19:34 +0200, Anders Logg wrote:
> > > > > > On Mon, May 29, 2006 at 07:29:34PM +0200, DOLFIN wrote:
> > > > > > > One or more new changesets pushed to the primary DOLFIN repository.
> > > > > > > A short summary of the last three changesets is included below.
> > > > > > > 
> > > > > > > changeset:   1960:a7f783f945976c24f7f54d549d3af76c45c30612
> > > > > > > tag:         tip
> > > > > > > parent:      1959:189ad5b395cb410ba6a45d7a4a5f91c9865b0034
> > > > > > > parent:      1958:cce2724314dccaf2c426edabe3ad1d3ea1f004b1
> > > > > > > user:        "Garth N. Wells <g.n.wells@xxxxxxxxxx>"
> > > > > > > date:        Mon May 29 19:29:27 2006 +0200
> > > > > > > files:       
> > > > > > > description:
> > > > > > > merge
> > > > > > > 
> > > > > > > 
> > > > > > > changeset:   1959:189ad5b395cb410ba6a45d7a4a5f91c9865b0034
> > > > > > > parent:      1957:e52484e9ba196d7ec4d5e66fd584c133ee020691
> > > > > > > user:        "Garth N. Wells <g.n.wells@xxxxxxxxxx>"
> > > > > > > date:        Mon May 29 19:27:53 2006 +0200
> > > > > > > files:       src/kernel/function/ConstantFunction.cpp src/kernel/function/DiscreteFunction.cpp src/kernel/function/Function.cpp src/kernel/function/FunctionPointerFunction.cpp src/kernel/function/UserFunction.cpp src/kernel/function/dolfin/ConstantFunction.h src/kernel/function/dolfin/DiscreteFunction.h src/kernel/function/dolfin/Function.h src/kernel/function/dolfin/FunctionPointerFunction.h src/kernel/function/dolfin/GenericFunction.h src/kernel/function/dolfin/UserFunction.h src/kernel/la/dolfin/DenseVector.h
> > > > > > > description:
> > > > > > > Remove all PETSc ifdef's from src/kernel/function. DenseVector is
> > > > > > > used to store discrete values if PETSc is not enabled.
> > > > > > 
> > > > > > Is there no uBlasSparseVector?
> > > > > > 
> > > > > 
> > > > > There is a uBlas sparse vector, but I don't see the point in using it as
> > > > > our vectors are generally not sparse. Does PETSc use sparse storage for
> > > > > vectors? I have the feeling that it doesn't.
> > > > > 
> > > > > Garth
> > > > 
> > > > I don't see a point in sparse vectors either, just thinking about how
> > > > to make it consistent. Now SparseMatrix may or may not work together
> > > > with DenseMatrix (in solve()), depending on whether we compile with PETSc.
> > > > 
> > > 
> > > We'll need to sort out a few wrinkles with the linear solvers. To be
> > > consistent, I might rename "DenseMatrix" "uBlasMatrix" and
> > > "SparseVector" "PETScVector" with appropriate typedef's.
> > 
> > Sounds good.
> > 
> > > Another thing we should start thinking about is keeping track of the
> > > non-zero structure of sparse matrices. For the uBlas compressed row
> > > storage matrix, assembly is about 10 faster if the structure is already
> > > set-up. At the moment, the function clear() destroys this. Not sure what
> > > impact this will have for PETSc matrices.
> > > 
> > > Garth
> > 
> > This is important for PETSc matrices also (even more important I'd
> > guess). Is it enough with the number of nonzeros or is the exact
> > structure needed?
> > 
> > We make a crude estimate in FEM::estimateNonZeros() but we could do
> > much better.
> 
> As long as the estimate of the number of zeros is conservative, it won't
> impact speed, just memory. I'm thinking of the non-zero structure, and
> particularly in the context of nonlinear problems in which the Jacobian
> matrix is assembled many times.
> 
> Garth

The natural would be to do a "dry assembly", which would just loop
over the cells and compute the dof maps. We could then stick these
into an STL (std) map to get the structure. This could then be used to
prepare the sparse matrix and do the real assembly directly into the
sparse matrix.

I think the extra step of computing the nonzero structure would be
small compared to the assembly since we don't compute anything but we
would have to try.

/Anders