Ok thanks I'll give this a shot. I was originally trying to do one point with all dof, but one dof per point sounds more strait foreword.
Quoting Matthew Knepley <knepley at gmail.com>: > On Mon, Aug 20, 2012 at 7:47 AM, Colin McAuliffe <cjm2176 at > columbia.edu>wrote: > >> I am just not seeing where in the section such an IS would go. As far as I >> can tell from the functions in vsection.c, the only item in the section >> which is an IS is bcIndices, defining points where bcs are applied. >> > > If you have no structure other than dof, you can make a Section where the > points > just number dofs. Then you just run through the ints p in your IS can call > > PetscSectionSetDof(section, p, 1) > > Then PetscSectionSetUp(). Stick this in a DMSHELL, or really any DM you > want, > and FS will use it. > > Matt > > >> 38 ierr = PetscNew(struct _n_PetscSection, s);CHKERRQ(ierr); >> 39 (*s)->atlasLayout.comm = comm; >> 40 (*s)->atlasLayout.pStart = -1; >> 41 (*s)->atlasLayout.pEnd = -1; >> 42 (*s)->atlasLayout.numDof = 1; >> 43 (*s)->atlasDof = PETSC_NULL; >> 44 (*s)->atlasOff = PETSC_NULL; >> 45 (*s)->bc = PETSC_NULL; >> 46 (*s)->bcIndices = PETSC_NULL; >> 47 (*s)->setup = PETSC_FALSE; >> 48 (*s)->numFields = 0; >> 49 (*s)->fieldNames = PETSC_NULL; >> 50 (*s)->field = PETSC_NULL; >> >> Quoting Matthew Knepley <knepley at gmail.com>: >> >> 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://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://**berkeley.edu/**projects/feap/<http://berkeley.edu/**projects/feap/> >>>>>>>>>>>> > >>>>>>>>>>>> <http://www.**ce.berkeley.edu/****projects/**feap/<http://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://**berkeley.edu/**projects/feap/<http://berkeley.edu/**projects/feap/> >>>>>>>>>>>> > >>>>>>>>>>>> <http://**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://**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://berkeley.edu/**~**sanjay> >>>>>>>>>>> <http://berkeley.**edu/~**sanjay <http://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://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 >>> >>> >> >> >> -- >> 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
