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

Fri Jan 7 12:22:52 CST 2022

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.

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