[petsc-users] Fluid-Structure interaction with multiple DMPlex

Sat Jan 8 09:58:07 CST 2022

On Sat, Jan 8, 2022 at 3:05 AM Thibault Bridel-Bertomeu <
thibault.bridelbertomeu at gmail.com> wrote:

> Le ven. 7 janv. 2022 à 19:45, Thibault Bridel-Bertomeu <
> thibault.bridelbertomeu at gmail.com> a écrit :
>
>> Le ven. 7 janv. 2022 à 19:23, Matthew Knepley <knepley at gmail.com> a
>> écrit :
>>
>>> On Fri, Jan 7, 2022 at 12:58 PM Thibault Bridel-Bertomeu <
>>> thibault.bridelbertomeu at gmail.com> wrote:
>>>
>>>>
>>>> Le ven. 7 janv. 2022 à 14:54, Matthew Knepley <knepley at gmail.com> a
>>>> écrit :
>>>>
>>>>> On Fri, Jan 7, 2022 at 8:52 AM Thibault Bridel-Bertomeu <
>>>>> thibault.bridelbertomeu at gmail.com> wrote:
>>>>>
>>>>>> Hi Matthew,
>>>>>>
>>>>>> Le ven. 7 janv. 2022 à 14:44, Matthew Knepley <knepley at gmail.com> a
>>>>>> écrit :
>>>>>>
>>>>>>> On Fri, Jan 7, 2022 at 5:46 AM Thibault Bridel-Bertomeu <
>>>>>>> thibault.bridelbertomeu at gmail.com> wrote:
>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> First of, happy new year everyone !! All the best !
>>>>>>>>
>>>>>>>
>>>>>>> Happy New Year!
>>>>>>>
>>>>>>>
>>>>>>>> I am starting to draft a new project that will be about
>>>>>>>> fluid-structure interaction: in particular, the idea is to compute the
>>>>>>>> Navier-Stokes (or Euler nevermind) flow around an object and _at the same
>>>>>>>> time_ compute the heat equation inside the object.
>>>>>>>> So basically, I am thinking a mesh of the fluid and a mesh of the
>>>>>>>> object, both meshes being linked at the fluid - solid interface.
>>>>>>>>
>>>>>>>
>>>>>>> First question: Are these meshes intended to match on the interface?
>>>>>>> If not, this sounds like overset grids or immersed boundary/interface
>>>>>>> methods. In this case, more than one mesh makes sense to me. If they are
>>>>>>> intended to match, then I would advocate a single mesh with multiple
>>>>>>> problems defined on it. I have experimented with this, for example see SNES
>>>>>>> ex23 where I have a field in only part of the domain. I have a large
>>>>>>> project to do exactly this in a rocket engine now.
>>>>>>>
>>>>>>
>>>>>> Yes the way I see it is more of a single mesh with two distinct
>>>>>> regions to distinguish between the fluid and the solid. I was talking about
>>>>>> two meshes to try and explain my vision but it seems like it was unclear.
>>>>>> Imagine if you wish a rectangular box with a sphere inclusion: the
>>>>>> sphere would be tagged as a solid and the rest of the domain as fluid.
>>>>>> Using Gmsh volumes for instance.
>>>>>> Ill check out the SNES example ! Thanks !
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> First (Matthew maybe ?) do you think it is something that could be
>>>>>>>> done using two DMPlex's that would somehow be spawned from reading a Gmsh
>>>>>>>> mesh with two volumes ?
>>>>>>>>
>>>>>>>
>>>>>>> You can take a mesh and filter out part of it with DMPlexFilter().
>>>>>>> That is not used much so I may have to fix it to do what you want, but that
>>>>>>> should be easy.
>>>>>>>
>>>>>>>
>>>>>>>> And on one DMPlex we would have finite volume for the fluid, on the
>>>>>>>> other finite elements for the heat eqn ?
>>>>>>>>
>>>>>>>
>>>>>>> I have done this exact thing on a single mesh. It should be no
>>>>>>> harder on two meshes if you go that route.
>>>>>>>
>>>>>>>
>>>>>>>> Second, is it something that anyone in the community has ever
>>>>>>>> imagined doing with PETSc DMPlex's ?
>>>>>>>>
>>>>>>>
>>>>>>> Yes, I had a combined FV+FEM simulation of magma dynamics (I should
>>>>>>> make it an example), and currently we are doing FVM+FEM for simulation of a
>>>>>>> rocket engine.
>>>>>>>
>>>>>>
>>>>>> Wow so it seems like it’s the exact same thing I would like to
>>>>>> achieve as the rocket engine example.
>>>>>> So you have a single mesh and two regions tagged differently, and you
>>>>>> use the DmPlexFilter to solve FVM and FEM separately ?
>>>>>>
>>>>>
>>>>> With a single mesh, you do not even need DMPlexFilter. You just use
>>>>> the labels that Gmsh gives you. I think we should be able to get it going
>>>>> in a straightforward way.
>>>>>
>>>>
>>>> Ok then ! Thanks ! I’ll give it a shot and see what happens !
>>>> Setting up the FVM and FEM discretizations will pass by DMSetField
>>>> right ? With a single mesh tagged with two different regions, it should
>>>> show up as two fields, is that correct ?
>>>>
>>>
>>> Yes, the idea is as follows. Each field also has a label argument that
>>> is the support of the field in the domain. Then we create PetscDS objects
>>> for each
>>> separate set of overlapping fields. The current algorithm is not
>>> complete I think, so let me know if this step fails.
>>>
>>
>> Ok, thanks.
>> I’ll let you know and share snippets when I have something started !
>>
>> Talk soon ! Thanks !
>>
>
> Hi Matthew,
>
> I thought about a little something else : what about setting two different
> TS, one for each field of the DM ? Most probably the fluid part would be
> solved with an explicit time stepping whereas the solid part with the heat
> equation would benefit from implicit time stepping. TSSetDM does not allow
> a field specification, is there a way to hack that so that each field has
> its own TS ?
>

I see at least two options here:

1. Split the problems:

    You can use DMCreateSubDM() to split off part of a problem and use a
solver on that. I have done this for problems with weak coupling.

2. Use IMEX

    For strong coupling, I have used the IMEX TSes in PETSc. You put the
explicit terms in the RHS, and the implicit in the IFunction.

  Thanks,

     Matt

> Thanks
>
> Thibault
>
>
>> Thibault
>>
>>
>>>   Thanks,
>>>
>>>      Matt
>>>
>>>
>>>> Thanks,
>>>>
>>>> Thibault
>>>>
>>>>
>>>>>   Thanks,
>>>>>
>>>>>      Matt
>>>>>
>>>>>
>>>>>> Thanks !
>>>>>>
>>>>>> Thibault
>>>>>>
>>>>>>
>>>>>>>   Thanks,
>>>>>>>
>>>>>>>      Matt
>>>>>>>
>>>>>>>
>>>>>>>> As I said it is very prospective, I just wanted to have your
>>>>>>>> opinion !!
>>>>>>>>
>>>>>>>> Thanks very much in advance everyone !!
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Thibault
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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/>
>>>>>>>
>>>>>> --
>>>>>> Thibault Bridel-Bertomeu
>>>>>> —
>>>>>> Eng, MSc, PhD
>>>>>> Research Engineer
>>>>>> CEA/CESTA
>>>>>> 33114 LE BARP
>>>>>> Tel.: (+33)557046924
>>>>>> Mob.: (+33)611025322
>>>>>> Mail: thibault.bridelbertomeu at gmail.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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/>
>>>>>
>>>> --
>>>> Thibault Bridel-Bertomeu
>>>> —
>>>> Eng, MSc, PhD
>>>> Research Engineer
>>>> CEA/CESTA
>>>> 33114 LE BARP
>>>> Tel.: (+33)557046924
>>>> Mob.: (+33)611025322
>>>> Mail: thibault.bridelbertomeu at gmail.com
>>>>
>>>
>>>
>>> --
>>> 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/>
>>>
>> --
>> Thibault Bridel-Bertomeu
>> —
>> Eng, MSc, PhD
>> Research Engineer
>> CEA/CESTA
>> 33114 LE BARP
>> Tel.: (+33)557046924
>> Mob.: (+33)611025322
>> Mail: thibault.bridelbertomeu at gmail.com
>>
> --
> Thibault Bridel-Bertomeu
> —
> Eng, MSc, PhD
> Research Engineer
> CEA/CESTA
> 33114 LE BARP
> Tel.: (+33)557046924
> Mob.: (+33)611025322
> Mail: thibault.bridelbertomeu at gmail.com
>

-- 
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/20220108/cd7686e9/attachment-0001.html>