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

Sat Jan 8 02:04:51 CST 2022

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 ?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220108/82110f93/attachment.html>