[petsc-dev] PetscSection

[Barry Smith]

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.

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