[petsc-users] Fluid-Structure interaction with multiple DMPlex
Matthew Knepley
knepley at gmail.com
Sun Jan 9 10:07:55 CST 2022
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.
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/f07eb3e2/attachment-0001.html>
More information about the petsc-users
mailing list