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/> >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >>>>>>> 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://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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120814/e80e259d/attachment.html>
