[petsc-dev] PetscSection

[Matthew Knepley]

On Fri, Nov 9, 2012 at 12:19 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Thu, Nov 8, 2012 at 10:58 PM, Matthew Knepley <knepley at gmail.com> wrote:
>>
>> 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.
>
>
> We normally do one VecGetArray(), then iterate over the whole local part.
> That's different from doing it in an inner loop. Many other packages do it
> in inner loops (overloading operator[] is popular among some), but that
> restricts the Vec types that can perform well with that package.

These are only intended for local vectors, for which I see no reason
to use anything but contiguous.

>>
>> > What other sections do users need? A trace space?
>>
>> Blaise uses a couple for every problem. We have several in PyLith
>> (ground surface,
>> fault).
>
>
> What is the difference between using a PetscSection for each thing and using
> an IS for those points on the feature? I guess just the extra indirection
> (IS) versus more duplication (a PetscSection is heavier than an IS).

They actually have topology, and we do integrals on them, and they get
output. Using
IS, as I said to Barry, is not good enough.

>>
>> >
>> > 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.
>
>
> You need separate buffers per thread, but we can make DMGetWorkArray() have
> a separate cache per thread. VecGetArray() is still not trivially cheap
> because we need atomics. Maybe I'm being overly paranoid, but I don't like
> the granularity that imposes.
>
>>
>> >>
>> >>
>> >> These are for multi-field splitting/
>> >
>> >
>> > Clearly, but why do they need to be in PetscSection? We already need DMs
>> > associated with fields.
>
>
> Answering my own question: the distinction between DM and Section is that
> the latter can address a discontinuous part of a Vec so addressing by field
> does not imply a copy.
>
>>
>>
>> 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.
>
>
> It's still not clear to me why they are needed. If PetscSection is
> user-visible, can't they just be different Sections?
> DMComplexGetFieldSection(dm,field,&fsection);

My point is that it has to go somewhere. Right now, that somewhere is inside the
PetscSection. If we take it out, they must end up in the DM, which is
alright, but
involves a little rewriting. This is not a big issue for me.

   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