On May 16, 2011, at 9:27 PM, Dmitry Karpeev wrote: > On Mon, May 16, 2011 at 9:24 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >> >> On May 16, 2011, at 9:16 PM, Dmitry Karpeev wrote: >> >>> On Mon, May 16, 2011 at 8:26 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >>>> >>>> On May 16, 2011, at 5:57 PM, Matthew Knepley wrote: >>>> >>>>> On Sat, May 14, 2011 at 10:14 PM, Barry Smith <bsmith at mcs.anl.gov> >>>>> wrote: >>>>> >>>>> In preparation for adding field information to PetscLayout (as >>>>> discussed below in the previous email) I have fixed up PETSc-dev so that >>>>> VecDuplicate(), MatDuplicate() and MatGetVecs() results in new objects >>>>> that reference the previous PetscLayouts (rather than produce new ones). >>>>> Also, inspired by a comment of Dmitry I have put the >>>>> ISLocalToGlobalMapping mapping and bmapping objects into the PetscLayout >>>>> so that each individual Vec and Mat doesn't need to mess with them. >>>>> Please report any problems and if you find places where new vectors are >>>>> created directly rather than by duplication etc report this as well. Note >>>>> that these changes are all good things to do independent of putting field >>>>> information into the PetscLayout. >>>>> >>>>> For FEM stuff (like mixed elements, higher order, complicated bases), I >>>>> need layout information that maps >>>>> >>>>> mesh piece ---> (size, offset) >>>> >>>> I have no idea what a mesh piece is nor how it can be indicated by only >>>> a size and an offset :-) >>>> >>>> Anyways, my thought is for "approach specific" stuff like this; one >>>> would put it in an object and then attach the object to the PetscLayout >>>> with ComposeObject. Now given any vector or matrix you can just pull out >>>> the particular information out of the PetscLayout which is shared by all >>>> the (associated) Vecs and Matrices. Only universally meaningful stuff like >>>> the fields would go directly into the PetscLayout. >>> >>> Is PetscLayout a bona fide PetscObject now, so that composition is possible? >> >> No, good point. Perhaps it will have to be converted. Damn I've spent 15 >> years trying to avoid making it a PetscObject (we'll still keep it as a >> private class not for general public use :-). > > It can be a private PetscObject, couldn't it? Making it a real object > would make a lot of things easier, I think. > If greater reuse can be obtained this way, it may outweigh whatever > additional overhead PetscObject imposes on PetscLayout. > > Another question: from what you wrote in this thread it looks like > full namespaces (e.g., Vec --> PetscVec) is under way. > Is that so?
No, some one suggested it might be a good idea to get it done now rather than later. I haven't decided to do it yet. > > Dmitry. > >> >> >> Barry >> >>> >>> Dmitry. >>> >>> >>>> Barry >>>> >>>> >>>> >>>>> >>>>> I made a separate structure to contain this info, but it sounds like this >>>>> suped-up PetscLayout could contain it >>>>> instead. Is that feasible? >>>>> >>>>> Matt >>>>> >>>>> At this point I could add a PetscLayoutSetFields() or similar beasty. >>>>> Some possibilities >>>>> >>>>> PetscLayoutAddField(PetscLayout,name?,IS) to allow incrementally >>>>> putting them in or >>>>> >>>>> PetscLayoutSetFields(PetscLayout,n,names[]?,IS[]) to set them all at >>>>> once >>>>> >>>>> and how would we get them into the PetscLayout that we usually don't >>>>> access directly. Have a >>>>> >>>>> PetscVecSetFields(Vec,n,names[]?,IS[]) and >>>>> PetscMatSetFields(Mat,n,names[]?,IS[]). >>>>> >>>>> One natural place to have set this information up is with the DMs. >>>>> For example DMDA with dof > 1 would have be default dof stride >>>>> fields; to allow other possibilities there could be DMDASetFields(). Also >>>>> Vecs and Mats with bs > 1 could be default get similar bs stride fields >>>>> by default. >>>>> DMComposite would by default have a field for each of the >>>>> composed DMs perhaps. >>>>> Likely each DM object should keep the root PetscLayouts that it >>>>> uses to create its vectors and matrices so all of its creations share a >>>>> common layout rather than the current model where each newly created vec >>>>> or mat from a DM gets a new PetscLayout (hmm, maybe I should fix the >>>>> first). >>>>> >>>>> >>>>> Another issue is that there are other places where field information >>>>> should eventually be propagated. For example VecGetSubVector() and >>>>> MatGetSubMatrix/Matrices() new vectors matrices should get this >>>>> information from their parents (this way nesting of >>>>> fieldsplit/bjacobi/asm/etc solvers will become much easier and more >>>>> automatic). And redoing all the VecStrideXXX() routines to be more >>>>> general for fields. >>>>> >>>>> Comments, suggestions, corrections? >>>>> >>>>> Barry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On May 14, 2011, at 11:51 AM, Barry Smith wrote: >>>>> >>>>>> >>>>>> I have a proposal for a moderate/major change for how we handle >>>>>> knowledge of subfields/splits in PETSc. >>>>>> >>>>>> Currently one can call PCFieldSplitSetIS() or PCFieldSplitSetFields() >>>>>> to indicate the splitting of vectors(fields) into subvectors(subfields). >>>>>> But, in fact, the knowledge of what splits make sense really comes in >>>>>> the generation of the vectors and matrices and it is bad that the user >>>>>> needs to stash that information somewhere and then bring it out and >>>>>> attach it to the PCFieldSplit. It is especially annoying if one is using >>>>>> a fieldsplit inside, say a multigrid preconditioner, and one has to >>>>>> somehow get that information down into the inner PC. >>>>>> >>>>>> I propose an alternative. All Vecs and Mats currently have associated >>>>>> PetscLayouts and when a Vec or Mat is duplicated the new Vec or Mat has >>>>>> that same PetscLayout. I propose each PetscLayout have associated with >>>>>> it an optional set of IS indicating the subfields/subvectors (note that >>>>>> this is sort of already true when you set a blocksize larger than 1 the >>>>>> PCFieldSplit will by default use the strides for subfields). Thus >>>>>> PCFieldSplit can get directly from its matrix the appropriate default >>>>>> splits. Similarly the VecStrideXXX() operations can be made more >>>>>> general becoming VecSubVecXXX(). We also add VecGetSubVec() to get >>>>>> appropriated sized subvectors easily. >>>>>> >>>>>> The end result will be a relatively small change in the PETSc API and >>>>>> for most users little or absolutely no change, but the power to compose >>>>>> easily will really increase. >>>>>> >>>>>> Comments, objections, improvements? >>>>>> >>>>>> Do this before or after the next release? (I guess the conventional >>>>>> wisdom answer would be after?). >>>>>> >>>>>> >>>>>> Barry >>>>>> >>>>>> >>>>>> BTW: It is true that parallel vectors and matrices share the PetscLayout >>>>>> from their parent object (via VecDuplicate/MatDuplicate) but this is not >>>>>> true to sequential Vec and Mat. Before adding Field information to >>>>>> PetscLayouts I would need to change all the sequential duplicates to get >>>>>> a reference to their parents PetscLayout instead of creating a new one. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> >> >>
