[petsc-dev] PetscSection

[Matthew Knepley]

On Fri, Nov 9, 2012 at 9:34 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> On Nov 9, 2012, at 8:12 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> On Fri, Nov 9, 2012 at 7:58 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>> Just an implementation issue. To me the correct abstract model is "indices of an element" etc and whether this is done via a "closure" or listing them etc is just an implementation issue.
>>
>> Right, I don't think it should be visible in the access interface whether the implementation has built an Index (in the DB sense) providing the closure directly or whether it's constructed on the fly from whatever indirect information. There is a meaningful distinction between getting the dofs associated with the element or face _interior_ versus its closure.
>>
>>    I realize this is different than Matt's abstract model. I am not saying my model is better than Matt's (from an abstract mathematicians Matt's is probably better) but I believe my model is much more sellable to the masses (remember very few abstract mathematicians use PETSc :-)).
>>
>> Just a few months ago, you were arguing that (u,v) = \int u conj(v) since that was the Math Convention and PETSc was for Mathematicians.
>
>   touche
>
>>
>>    So we are set? We design and implement a better, more general IS concept?
>>
>> I think so. I think Matt wants still to pull "fields" in, as well as perhaps constraints (for BCs).
>
>    He is wrong, that all belongs in DMs.

You are both right :) I don't care where we put them, but I want BCs
and fields. However, this is no problem.
Right now I do BCs and fields as PetscSections held inside the primary
section. If IS can do what PetscSection
can do, I can jsut use another IS for each one.

>>
>> Now where do we put the convenience interface of accessing a chunk of data in a Vec or array? Or does the new IS interface only give use the index range associated with the block and we as the caller must do the indexing? (I'm not opposed to the latter. It's slight clutter but removes more from the inner loop.)
>
>    Accessing from an array? Maybe
>
>     Accessing from a vector? Unlikely since the destroys the hierarchy of IS below Vec. So that part may need to be in the Vec,  maybe VecGetSection(vec,index tag,is,&values)
>

I actually like it where it is. Stick with DMComplexVecGetClosure()
with no section argument, and then
the DM holds an IS++.

   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