[petsc-users] Nesting splits based on IS
Matthew Knepley
knepley at gmail.com
Sun Apr 18 17:19:36 CDT 2021
On Sun, Apr 18, 2021 at 2:49 PM Karin&NiKo <niko.karin at gmail.com> wrote:
> Thanks for the advice.
> But I do not find tests using DMShell and DMCreateSubDM.
> So does the idea of writing a new version
> of src/ksp/ksp/examples/tutorials/ex43.c make sense?
>
It's a somewhat complicated example, but I guess it would show how to do it.
Thanks,
Matt
> Thanks,
> Nicolas
>
> Le dim. 18 avr. 2021 à 20:38, Matthew Knepley <knepley at gmail.com> a
> écrit :
>
>> On Sun, Apr 18, 2021 at 2:20 PM Karin&NiKo <niko.karin at gmail.com> wrote:
>>
>>> Dear Matt and Barry,
>>>
>>> Unfortunately DM is not used in our PETSc interface,which is essentially
>>> based on the assembly matrix.
>>> As Matt mentioned, the trick could be to define a DMShell in order to
>>> expose the splits we internally build based on IS.
>>> If I understand well, I have to play around with
>>> DMShellSetCreateFieldDecomposition. Unfortunately, I do not find tests
>>> using this method. Am I missing something ?
>>>
>>
>> I would not use that function. I would use DMCreateSubDM().
>>
>> Thanks,
>>
>> Matt
>>
>>
>>> Perhaps a good starting point would be to write a test
>>> like src/ksp/ksp/examples/tutorials/ex43.c in which one would consider the
>>> algebraic data to be known (the matrix and the IS) and would set up a
>>> DMShell (with an appropriate call to DMShellSetCreateFieldDecomposition).
>>> Does that make sense?
>>>
>>> Thanks,
>>> Nicolas
>>>
>>> Le dim. 18 avr. 2021 à 15:54, Matthew Knepley <knepley at gmail.com> a
>>> écrit :
>>>
>>>> On Sat, Apr 17, 2021 at 6:13 PM Barry Smith <bsmith at petsc.dev> wrote:
>>>>
>>>>>
>>>>> So you would like to be able to create three IS in your code and
>>>>> attach them with names to the PC. Then have -pc_fieldsplit_XXX_fields be
>>>>> able to utilize the attached IS by name and use them to define the blocks.
>>>>>
>>>>>
>>>>> This is all doable and could be added to PCFIELDSPLIT without too
>>>>> much code, new code. The code would be largely like
>>>>> PCFieldSplitSetRuntimeSplits_Private.
>>>>>
>>>>> The recursive part may also be doable but I think your syntax below
>>>>> is not exactly right. You would need something like
>>>>>
>>>>> -fieldsplit_0_pc_type fieldsplit // split the first PC into a
>>>>> fieldsplit
>>>>> -fieldsplit_0_pc_fieldsplit_0_fields xxx
>>>>> -fieldsplit_0_fieldsplit_0_pc_type jacobi
>>>>> -fieldsplit_0_pc_fieldsplit_1_fields yyy
>>>>> etc
>>>>>
>>>>> this would split the first field into two fields and use jacobi on the
>>>>> first field.
>>>>>
>>>>> The problem is what to use for labelling the xxx and the yyy?
>>>>>
>>>>> I think one could achieve this by having the PCFIELDPLIT attach to
>>>>> each of its split PCs the appropriate modified IS with names attached to
>>>>> them. There are two cases,
>>>>>
>>>>> when building the split uses first all the entries from
>>>>> fieldsplit_v_, then from fieldsplit_p_ then the new ISs it needs to attach
>>>>> to the first split PC are two sets of integers the first from 0 to the
>>>>> len(v)-1 and the second from len(v) to len(v)+len(p)-1.
>>>>>
>>>>> when building the split it interlaces the indices from v and p
>>>>> (interlacing only make sense if the size of v and p is the same). Then the
>>>>> new v would be {0,2,4,...} and p would be {1,3,...}.
>>>>>
>>>>> If you are ambitious and would like to add this to fieldsplit.c we'd
>>>>> be very happy to receive an MR. It might even lead to allowing us to simply
>>>>> how the PCFIELDPLIT interacts with DMs. If all the split type, stride,
>>>>> named, etc are handle in a single consistent manner.
>>>>>
>>>>
>>>> Barry, this is already working with DMs, which I think is the right way
>>>> to do this.
>>>>
>>>> Here is the code:
>>>>
>>>>
>>>> https://gitlab.com/petsc/petsc/-/blob/main/src/ksp/pc/impls/fieldsplit/fieldsplit.c#L420
>>>>
>>>> The DM must respond to DMCreateSubDM(). The interface is that the call
>>>> provides a list of fields [f_0, f_1, ...]
>>>> and the DM returns an IS for that combination and a subdm for it. The
>>>> subdm part is what allows you to do this
>>>> recursively, since you make the same call on the subdm.
>>>>
>>>> If you use a PetscSection to keep track of the data layout, the code to
>>>> do field selection is already done:
>>>>
>>>>
>>>> https://gitlab.com/petsc/petsc/-/blob/main/src/dm/interface/dmi.c#L105
>>>>
>>>> which can just be called from the DMCreateSubDM() implementation.
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>>
>>>>> Barry
>>>>>
>>>>>
>>>>>
>>>>> > On Apr 17, 2021, at 11:53 AM, Karin&NiKo <niko.karin at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Dear PETSc users,
>>>>> >
>>>>> > I use the fieldsplit PC in an application where the splits are
>>>>> programmatically defined by IS using PCFieldSplitSetIS. Then the user can
>>>>> specify its own PC at runtime using PETSc options.
>>>>> > My question : is it possible to define nested splits in this case as
>>>>> it can be done with strided splits (see snes/examples/tutorials/ex19.c with
>>>>> test suffix fieldsplit_4).
>>>>> >
>>>>> > In order to be perfectly clear : let's say I have a 3 fields problem
>>>>> : velocity (v split), pressure (p split) and temperature (t split).
>>>>> > What I would like to do is something like the following but it fails
>>>>> :
>>>>> >
>>>>> > -ksp_type fgmres
>>>>> > -pc_fieldsplit_type multiplicative
>>>>> > -pc_type fieldsplit -pc_fieldsplit_0_fields fieldsplit_v_,
>>>>> fieldsplit_p_ -pc_fieldsplit_1_fields fieldsplit_t_
>>>>> >
>>>>> > -prefix_push fieldsplit_0_
>>>>> > -ksp_type fgmres
>>>>> > -pc_fieldsplit_schur_factorization_type upper
>>>>> > -pc_type fieldsplit
>>>>> > -pc_fieldsplit_type schur
>>>>> > -pc_fieldsplit_schur_precondition a11
>>>>> > -prefix_pop
>>>>> >
>>>>> > -prefix_push fieldsplit_1_
>>>>> > -ksp_type fgmres
>>>>> > -pc_type jacobi
>>>>> > -prefix_pop
>>>>> >
>>>>> > -prefix_push fieldsplit_v_
>>>>> > -ksp_type fgmres
>>>>> > -pc_type gamg
>>>>> > -prefix_pop
>>>>> >
>>>>> > -prefix_push fieldsplit_p_
>>>>> > -ksp_type fgmres
>>>>> > -pc_type jacobi
>>>>> > -prefix_pop
>>>>> >
>>>>> > I thank you for your help,
>>>>> > Nicolas
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>> https://www.cse.buffalo.edu/~knepley/
>>>> <http://www.cse.buffalo.edu/~knepley/>
>>>>
>>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/
>> <http://www.cse.buffalo.edu/~knepley/>
>>
>
--
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
https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20210418/248dac6e/attachment.html>
More information about the petsc-users
mailing list