[petsc-dev] PetscSection

[Matthew Knepley]

On Thu, Nov 8, 2012 at 11:52 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 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).

I don't care about expensive VecGetArray(). We do it absolutely
everywhere in PETSc.
We recommend that users do it. This is not a real objection.

>>
>> > 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?

Blaise uses a couple for every problem. We have several in PyLith
(ground surface,
fault).

>>
>> 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?

GetClosure() is not a problem. All threads are reading from the same
topology, and
writing to separate output buffers. SetClosure() needs to be locked.

>>
>>
>> These are for multi-field splitting/
>
>
> Clearly, but why do they need to be in PetscSection? We already need DMs
> associated with fields.

Someone needs to know the splitting. If you had a DM, this info is
still stuck down
somewhere, so that DM is holding other DMs.

   Matt

--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener