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?
Thanks,
Nicolas
Le dim. 18 avr. 2021 à 20:38, Matthew Knepley <knep...@gmail.com> a écrit :
> On Sun, Apr 18, 2021 at 2:20 PM Karin&NiKo <niko.ka...@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 <knep...@gmail.com> a
>> écrit :
>>
>>> On Sat, Apr 17, 2021 at 6:13 PM Barry Smith <bsm...@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.ka...@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/>
>
