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)
