On Mon, Aug 20, 2012 at 7:17 AM, Colin McAuliffe <cjm2176 at columbia.edu>wrote:
> Yes, just call DMSetDefaultSection(). However, note that you will have >> everything sized >> correctly, but handling topology and iteration for the residual >> calculation >> would be completely >> up to you. >> >> Matt >> > > It would be really great to define the initial data layout using IS to > define the equation numbers of the splits, while letting the new DM stuff > handle creating all the nested splits given command line options. Is > something like this possible? > This is just what I say above. Is something not working? Matt > Colin > > Quoting Matthew Knepley <knepley at gmail.com>: > > On Mon, Aug 13, 2012 at 4:06 PM, Colin McAuliffe <cjm2176 at columbia.edu >> >wrote: >> >> No, No, No. You do not have to write a DM implementation. >>> >>>> >>>> You just have to define the data layout in a PetscSection and attach it >>>> to >>>> the DM with DMSetDefaultSection. >>>> >>>> Matt >>>> >>>> >>> Does use of the PetscSection mean that it is neccesary to define a >>> DMMesh? >>> In other >>> words is there a way to create the data layout for the physics without >>> having to specify >>> any information about the mesh? >>> >>> >> Yes, just call DMSetDefaultSection(). However, note that you will have >> everything sized >> correctly, but handling topology and iteration for the residual >> calculation >> would be completely >> up to you. >> >> Matt >> >> >> Thanks >>> Colin >>> >>> >>> >>> Quoting Matthew Knepley <knepley at gmail.com>: >>> >>> On Thu, Aug 9, 2012 at 10:22 AM, Dmitry Karpeev <karpeev at mcs.anl.gov> >>> >>>> wrote: >>>> >>>> >>>> >>>>> On Thu, Aug 9, 2012 at 10:02 AM, Colin McAuliffe < >>>>> cjm2176 at columbia.edu >>>>> >wrote: >>>>> >>>>> Sanjay, thanks for the reply but I am avoiding using blocked format >>>>> >>>>>> since >>>>>> my problem has 10 dofs per node but only has either dofs 1-3 or 4-10 >>>>>> active >>>>>> on a particular node. If I use block the equations I run out of memory >>>>>> pretty quickly on my machine but can get to reasonable sized problems >>>>>> with >>>>>> the unblocked format. >>>>>> >>>>>> Matt, sorry I am not getting this, but I am still not sure how the DM >>>>>> interface works. I can see in the function PCFieldSplitSetDefaults >>>>>> that >>>>>> there is an initial call to DMCreateFieldDecomposition and subsequent >>>>>> calls >>>>>> to DMCreateSubDM based on the command line options. What I am missing >>>>>> is >>>>>> how the first call to DMCreateFieldDecomposition is able to figure out >>>>>> which equations belong to which field just from command line info such >>>>>> as >>>>>> -pc_fieldsplit_0_fields 2,0. Where/how are the fields 2 and 0 defined? >>>>>> >>>>>> This might change slightly in the near future in petsc-dev to allow >>>>>> >>>>> one to >>>>> define splits using named fields. >>>>> In any event, there has to be DM support to implement the >>>>> decompositions >>>>> over a particular mesh/problem over that mesh. >>>>> With DMDA you can essentially get combinations of strided fields in >>>>> each >>>>> split. DMCOMPOSITE allows you >>>>> to pull out combinations of the subproblems that were put in there to >>>>> begin with. If you have your own mesh, you have to write >>>>> a DM implementation around it to expose the available fields. >>>>> >>>>> >>>>> No, No, No. You do not have to write a DM implementation. >>>> >>>> You just have to define the data layout in a PetscSection and attach it >>>> to >>>> the DM with DMSetDefaultSection. >>>> >>>> Matt >>>> >>>> >>>> Dmitry. >>>> >>>>> >>>>> >>>>> Thanks >>>>>> >>>>>> Colin >>>>>> >>>>>> >>>>>> Quoting Matthew Knepley <knepley at gmail.com>: >>>>>> >>>>>> On Thu, Aug 9, 2012 at 9:21 AM, Sanjay Govindjee <s_g at berkeley.edu> >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> Colin, >>>>>>> >>>>>>> I you block the equations in FEAP, then the restrained BCs are >>>>>>>> 'included' in assembled PETSc matrix (these dofs have rows that are >>>>>>>> zero >>>>>>>> modulo a value of unity on the diagonal and the restrained value on >>>>>>>> the >>>>>>>> right-hand side). >>>>>>>> >>>>>>>> >>>>>>>> However, this is not necessary with the DM interface. >>>>>>>> >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> >>>>>>> -sg >>>>>>> >>>>>>> >>>>>>>> On 8/9/12 8:41 AM, Colin McAuliffe wrote: >>>>>>>> >>>>>>>> From what I can gather from the petsc-dev source it looks like the >>>>>>>> >>>>>>>> commands in 4) will then generate the splits using strided blocks. >>>>>>>>> The >>>>>>>>> problem with that is the fortran code I am using (FEAP) uses petsc >>>>>>>>> to >>>>>>>>> assemble and solve the linear problem within its own nonlinear and >>>>>>>>> time >>>>>>>>> stepping schemes. The linear problem that petsc solves already has >>>>>>>>> boundary >>>>>>>>> conditions applied to it so petsc only sees the active >>>>>>>>> (unrestrained) >>>>>>>>> equations. So then in general fields can't be extracted from the >>>>>>>>> active >>>>>>>>> equations using strided blocks and I am stuck with generating the >>>>>>>>> index >>>>>>>>> sets defining the splits on my own. Will it still be possible to >>>>>>>>> make >>>>>>>>> use >>>>>>>>> of the new DM functions in this case? >>>>>>>>> >>>>>>>>> FEAP website: >>>>>>>>> http://www.ce.berkeley.edu/********projects/feap/<http://www.ce.berkeley.edu/******projects/feap/> >>>>>>>>> <http://www.**ce.berkeley.edu/****projects/**feap/<http://www.ce.berkeley.edu/****projects/feap/> >>>>>>>>> > >>>>>>>>> <http://www.ce.**berkeley.edu/****projects/feap/<http://berkeley.edu/**projects/feap/> >>>>>>>>> <http://www.**ce.berkeley.edu/**projects/**feap/<http://www.ce.berkeley.edu/**projects/feap/> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> <http://www.ce.**berkeley.edu/****projects/feap/<http://berkeley.edu/**projects/feap/> >>>>>>>>> <http://**berkeley.edu/projects/feap/<http://berkeley.edu/projects/feap/> >>>>>>>>> > >>>>>>>>> <http://www.ce.**berkeley.edu/**projects/feap/<http://berkeley.edu/projects/feap/> >>>>>>>>> <http://www.ce.**berkeley.edu/projects/feap/<http://www.ce.berkeley.edu/projects/feap/> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> Colin >>>>>>>>> >>>>>>>>> >>>>>>>>> Quoting Matthew Knepley <knepley at gmail.com>: >>>>>>>>> >>>>>>>>> On Wed, Aug 8, 2012 at 10:51 PM, Matthew Knepley < >>>>>>>>> knepley at gmail.com >>>>>>>>> > >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 8, 2012 at 10:23 PM, Colin McAuliffe < >>>>>>>>>> cjm2176 at columbia.edu >>>>>>>>>> >>>>>>>>>> >wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks all, regarding use of DM in 3.3, is the procedure now to >>>>>>>>>>> create >>>>>>>>>>> >>>>>>>>>>> the fields with PCFieldSplitSetIS and then use >>>>>>>>>>> >>>>>>>>>>>> DMCreateFieldDecompositionDM >>>>>>>>>>>> to create a new DM based from the new fields and the DM for the >>>>>>>>>>>> original >>>>>>>>>>>> problem? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1) Use petsc-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 2) PCFieldSplitSetIS() is independent. This allows you to define >>>>>>>>>>> splits >>>>>>>>>>> however you want, but then recursive gets harder >>>>>>>>>>> >>>>>>>>>>> 3) In 3.3., it uses DMCreateFieldDecompositionDM() to split all >>>>>>>>>>> fields >>>>>>>>>>> apart at once >>>>>>>>>>> >>>>>>>>>>> 4) In petsc-dev, it uses DMCreateSubDM() which can split off any >>>>>>>>>>> combination of fields, which from the command line is something >>>>>>>>>>> like >>>>>>>>>>> >>>>>>>>>>> -pc_fieldsplit_0_fields 2,0 -pc_fieldsplit_1_fields 1,3 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I should have shown recursive: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -fieldsplit_0_pc_type fieldsplit >>>>>>>>>> >>>>>>>>>> will split 2,0 into two blocks. >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Colin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>>> Colin McAuliffe >>>>>>>>>>>> PhD Candidate >>>>>>>>>>>> Columbia University >>>>>>>>>>>> Department of Civil Engineering and Engineering Mechanics >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> ------------------------------********----------------- >>>>>>>> >>>>>>>> Sanjay Govindjee, PhD, PE >>>>>>>> Professor of Civil Engineering >>>>>>>> Vice Chair for Academic Affairs >>>>>>>> >>>>>>>> 779 Davis Hall >>>>>>>> Structural Engineering, Mechanics and Materials >>>>>>>> Department of Civil Engineering >>>>>>>> University of California >>>>>>>> Berkeley, CA 94720-1710 >>>>>>>> >>>>>>>> Voice: +1 510 642 6060 >>>>>>>> FAX: +1 510 643 5264 >>>>>>>> s_g at berkeley.edu >>>>>>>> http://www.ce.berkeley.edu/~********sanjay<http://www.ce.berkeley.edu/~******sanjay> >>>>>>>> <http://www.ce.**berkeley.edu/~****sanjay<http://www.ce.berkeley.edu/~****sanjay> >>>>>>>> > >>>>>>>> <http://www.ce.**berkeley.edu/**~**sanjay<http://berkeley.edu/~**sanjay> >>>>>>>> <http://www.ce.**berkeley.edu/~**sanjay<http://www.ce.berkeley.edu/~**sanjay> >>>>>>>> > >>>>>>>> >< >>>>>>>> http://www.ce.berkeley.edu/~******sanjay<http://www.ce.berkeley.edu/~****sanjay> >>>>>>>> <http://www.ce.**berkeley.edu/~**sanjay<http://www.ce.berkeley.edu/~**sanjay> >>>>>>>> > >>>>>>>> <http://www.ce.berkeley.**edu/**~sanjay<http://www.ce.** >>>>>>>> berkeley.edu/~sanjay <http://www.ce.berkeley.edu/~sanjay>> >>>>>>>> > >>>>>>>> > >>>>>>>> ------------------------------********----------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Colin McAuliffe >>>>>> PhD Candidate >>>>>> Columbia University >>>>>> Department of Civil Engineering and Engineering Mechanics >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> -- >>>> 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 >>>> >>>> >>>> >>> >>> -- >>> Colin McAuliffe >>> PhD Candidate >>> Columbia University >>> Department of Civil Engineering and Engineering Mechanics >>> >>> >> >> >> -- >> 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 >> >> > > > -- > Colin McAuliffe > PhD Candidate > Columbia University > Department of Civil Engineering and Engineering Mechanics > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120820/f9e3a123/attachment.html>
