dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Oct 03, 2011 at 05:41:42PM +0100, Garth N. Wells wrote:
> On 3 October 2011 17:17, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Fri, Sep 30, 2011 at 02:17:29PM -0700, Johan Hake wrote:
> >> On Friday September 30 2011 14:12:37 Anders Logg wrote:
> >> > On Fri, Sep 30, 2011 at 12:25:16PM -0700, Johan Hake wrote:
> >> > > On Friday September 30 2011 09:56:41 Anders Logg wrote:
> >> > > > On Fri, Sep 30, 2011 at 08:05:21AM -0700, Johan Hake wrote:
> >> > > > > On Friday September 30 2011 07:26:16 noreply@xxxxxxxxxxxxx wrote:
> >> > > > > > ------------------------------------------------------------
> >> > > > > > revno: 6319
> >> > > > > > committer: Anders Logg <logg@xxxxxxxxx>
> >> > > > > > branch nick: work
> >> > > > > > timestamp: Fri 2011-09-30 16:23:08 +0200
> >> > > > > >
> >> > > > > > message:
> >> > > > > >   Add options finalize_tensor/finalize_tensors to Python assemble
> >> > > > > >
> >> > > > > > functions. Note change of name of option reset_sparsity -->
> >> > > > > > reset_sparsities for assemble_system for consistency with option
> >> > > > > > name in
> >> > > > >
> >> > > > > Maybe change back to reset_sparsity for both functions instead, as
> >> > > > > the sparsity pattern only is built for Matrices?
> >> > > >
> >> > > > I thought about it but noticed that init_global_tensor is called for
> >> > > > both so "reset_sparsities" is consistent with "finalize_tensors".
> >> > >
> >> > > Yes, but the SpartistyPatternBuilder::build just build a sparsity pattern
> >> > > for Tensors with rank 2 or larger.
> >> >
> >> > Yes, but it may potentially do so.
> >> >
> >> > Anyway, perhaps it is more important to keep the arguments to the two
> >> > assemble functions as similar as possible. So we change to
> >> > reset_sparsity and finalize_tensor for both arguments in all assemble
> >> > functions.
> >>
> >> Yes I initially thought of this too, but the other arguments differ so much
> >> anyhow so I was not sure the point was valid, but I guess it still is.
> >>
> >> > ok?
> >>
> >> Yes!
> >
> > Done + the other changes discussed earlier: making assemble_foo
> > functions public and add PETScMatrix::apply("flushx").
> >
>
> What does GenericMatrix::apply("flush") do?

Nothing in general. The mode option is undocumented (as it has been
before) for GenericMatrix/Tensor, but it is (now) documented for
PETScMatrix and EpetraMatrix.

Different backends may support different values for the mode.

For PETScMatrix:

/// add    - corresponding to PETSc MatAssemblyBegin+End(MAT_FINAL_ASSEMBLY)
/// insert - corresponding to PETSc MatAssemblyBegin+End(MAT_FINAL_ASSEMBLY)
/// flush  - corresponding to PETSc MatAssemblyBegin+End(MAT_FLUSH_ASSEMBLY)

For EpetraMatrix:

/// add    - corresponding to Epetra GlobalAssemble(Add)
/// insert - corresponding to Epetra GlobalAssemble(Insert)

It would be good to have a common set of valid modes but it's not
worse than it was before when PETSc ignored the mode and Epetra
supported "add" and "insert".

--
Anders