[petsc-dev] PetscSection

[Jed Brown]

On Thu, Nov 8, 2012 at 10:31 PM, Matthew Knepley <knepley at gmail.com> wrote:

> This has been redone to remove Jed's objection (see new manual section).
> It now
> uses DM temp arrays,
>
> for(c = cStart; c < cEnd; ++c) {
>    PetscInt numVals;
>    PetscScalar *vals;
>
>    DMComplexVecGetClosure(dm, section, vec, c, &numVals, &vals);
>    /* Compute residual */
>    DMComplexVecRestoreClosure(dm, section, vec, c, &numVals, &vals);
>    DMComplexVecSetClosure(dm, section, resvec, c, vals, ADD_VALUES);
> }
>

My other problem here is that VecGetArray() is potentially expensive (need
to check coherence with other vectors, might not be contiguous for some Vec
implementations).


> > 2. Add DMComplex-specific access routines so the user does not need to
> see
> > the PetscSection. Presumably this would be something like
> > DMComplexGetPointOffset(dm,c,&offset); // offset into owned part of
> global
> > vector?
> > DMComplexGetPointOffsetLocal(dm,c,&loffset); // offset into local vector
>
> This is cumbersome because you must make another DM for every PetscSection
> you want to use.
>

What other sections do users need? A trace space?


> However, I am not completely against this now because
> DMComplexClone()
> is easy and accomplishes this.
>
> [...]

>
> I hate cursors. I had the same experience with them no matter what
> they are called
> (iterators, etc.) You need so much information, that you end up with
> the whole object
> in this "external" thing. I think they never pay off.
>

How do you intend to support many threads calling DMComplexVecGetClosure(),
perhaps each with multiple buffers, without expensive instructions?


>
> These are for multi-field splitting/
>

Clearly, but why do they need to be in PetscSection? We already need DMs
associated with fields.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121108/1247077a/attachment.html>