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

Sun Jan 9 10:16:42 CST 2022

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 ?

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