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

Matthew Knepley knepley at gmail.com
Sun Jan 9 10:24:13 CST 2022 

On Sun, Jan 9, 2022 at 11:16 AM Thibault Bridel-Bertomeu <
thibault.bridelbertomeu at gmail.com> wrote:

> Le dim. 9 janv. 2022 à 17:08, Matthew Knepley <knepley at gmail.com> a
> écrit :
>
>> On Sun, Jan 9, 2022 at 10:53 AM Thibault Bridel-Bertomeu <
>> thibault.bridelbertomeu at gmail.com> wrote:
>>
>>> Le dim. 9 janv. 2022 à 15:38, Matthew Knepley <knepley at gmail.com> a
>>> écrit :
>>>
>>>> On Sun, Jan 9, 2022 at 7:49 AM Thibault Bridel-Bertomeu <
>>>> thibault.bridelbertomeu at gmail.com> wrote:
>>>>
>>>>> Le dim. 9 janv. 2022 à 13:05, Matthew Knepley <knepley at gmail.com> a
>>>>> écrit :
>>>>>
>>>>>> On Sat, Jan 8, 2022 at 2:13 PM Thibault Bridel-Bertomeu <
>>>>>> thibault.bridelbertomeu at gmail.com> wrote:
>>>>>>
>>>>>>> However if you use IMEX for strong coupling of the two physics
>>>>>>> solved in each field, then it means you need to write a single set of PDEs
>>>>>>> that covers everything, don’t you ?
>>>>>>> If I want to solve Euler equations in one PetscDS and heat equation
>>>>>>> in the other one, then I need to write a global set of equations to use the
>>>>>>> IMEX TS , right ?
>>>>>>>
>>>>>>
>>>>>> The way I think about it. You would have explicit terms for Euler,
>>>>>> and they would also be confined to one part of the domain, but that just
>>>>>> impacts how you do the residual integral. You do assemble a combined
>>>>>> residual for all dogs, however, which I think is what you mean.
>>>>>>
>>>>>
>>>>> Hmm I'm not quite sure yet, probably because I haven't really started
>>>>> implementing it and I am not familiar with finite elements in PETSc.
>>>>> The way I see it is that a TS expects to be solving dU/dt = F, that's
>>>>> why I'm imagining that even with two domains with two different physics,
>>>>> one has to write the problem under the previous form. And when it comes to
>>>>> a FVM version of Euler + a FEM version of heat eqn, I'm not quite certain
>>>>> how to write it like that.
>>>>> Am I making any sense ? ô_o
>>>>>
>>>>
>>>> Oh, if you have boundary communication, then formulating it as one
>>>> system is difficult because different cells in supposedly the same DS would
>>>> have different unknowns, yes. IB solves this by defining the other
>>>> fields over the whole of each subdomain. Schwarz methods make two different
>>>> problems and then pass values with what I call an "auxiliary field".
>>>> You are right that you have to do something.
>>>>
>>>
>>> Let's imagine that we read in a Gmsh mesh into a DMPlex.
>>> That Gmsh mesh has two physical volumes so the DMPlex will a priori show
>>> two labels and therefore (?) two fields, meaning we can work with two
>>> SubDMs.
>>> Each SubDM basically matches a region of the whole mesh in this case.
>>> Now each SubDM can have its own DS and we can also attribute each DM to
>>> a TS.
>>> We can therefore solve the two problems, say one for fluid dynamics the
>>> other for heat eqn.
>>>
>>> The only thing I am not sure about (actually I haven't coded anything
>>> yet so I'm not sure of anything but ...) is the following.
>>> The two SubDMs come originally from the same DM right. Say we work in
>>> 3D, then the two SubDM must share a layer of triangles (and the segments
>>> and vertices that go along with them). That layer of triangles exist in
>>> both SubDM and is a boundary in both SubDM.
>>> How do I tell, for instance, the fluid SubDM that the information it
>>> needs on that layer of triangles comes from the other SubDM ? And vice
>>> versa ? Is it possible to create two SubDMs from the same DM that somehow
>>> still know each other after the creation ?
>>> Example 23 from SNES does not do that kind of thing right ? The "top"
>>> and "bottom" pieces are quite independent or am I misunderstanding sth ?
>>>
>>
>> The way I see it working is that you compose the maps from the original
>> space to each subDM on the boundary. Then, when you get one solution, you
>> can map it to points on the boundary of the other solution, which you use
>> as an auxiliary field.
>>
>
> Okay yes, I get what you mean. Is there a method in PETSc to do such
> things ? Does it have to do with IS ?
>

Yes, we can do it. It is just IS manipulation.

  Thanks,

    Matt


> Thanks !
> Thibault
>
>
>>
>>   Thanks,
>>
>>      Matt
>>
>>
>>> Thanks !!
>>>
>>> Thibault
>>>
>>>
>>>>   Thanks,
>>>>
>>>>      Matt
>>>>
>>>>
>>>>> Thanks,
>>>>> Thibault
>>>>>
>>>>>
>>>>>>   Thanks,
>>>>>>
>>>>>>     Matt
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Thibault
>>>>>>>
>>>>>>> Le sam. 8 janv. 2022 à 20:00, Matthew Knepley <knepley at gmail.com> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> On Sat, Jan 8, 2022 at 1:30 PM Thibault Bridel-Bertomeu <
>>>>>>>> thibault.bridelbertomeu at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Yes I was wondering about different time steps as well because
>>>>>>>>> usually implicit integration moves much faster.
>>>>>>>>> But if it not implemented, then maybe going the « weak coupling »
>>>>>>>>> road with a sub-DM is the way.
>>>>>>>>> Can I ask how you proceed in the rocket engine code you are
>>>>>>>>> writing ? IMEX ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right now it is IMEX, but we are explicitly substepping particles.
>>>>>>>> Not sure what the final thing will be.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>
>>>>>>>>     Matt
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thibault
>>>>>>>>>
>>>>>>>>> Le sam. 8 janv. 2022 à 19:22, Matthew Knepley <knepley at gmail.com>
>>>>>>>>> a écrit :
>>>>>>>>>
>>>>>>>>>> I do not know how. Right now, composable TS does not work all the
>>>>>>>>>> way.
>>>>>>>>>>
>>>>>>>>>>   Matt
>>>>>>>>>>
>>>>>>>>>> On Sat, Jan 8, 2022 at 1:03 PM Mark Adams <mfadams at lbl.gov>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Can you subcycle with IMEX?
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Jan 8, 2022 at 10:58 AM Matthew Knepley <
>>>>>>>>>>> knepley at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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/>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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/>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> 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/20220109/2c6f985e/attachment-0001.html>

More information about the petsc-users mailing list