[petsc-users] Field split questions
Colin McAuliffe
cjm2176 at columbia.edu
Tue Aug 21 07:51:51 CDT 2012
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
More information about the petsc-users
mailing list