[petsc-users] Field split questions

Colin McAuliffe cjm2176 at columbia.edu
Mon Aug 13 16:06:37 CDT 2012 

> 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?

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/>
>>>>>> >
>>>>>>
>>>>>>
>>>>>> 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

More information about the petsc-users mailing list