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
