> You just have to define the data layout in a PetscSection and attach it to > the DM with DMSetDefaultSection. > > Matt
Ok I understand the procedure for defining the initial field layout, thanks for the help! In the documentation for 3.3p2 there is a not that PetscSectionCreate is not available in fortran, is this still the case for petsc-dev? 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/> >>>>>> > >>>>>> >>>>>> >>>>>> 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> >>>>> > >>>>> ------------------------------****----------------- >>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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
