Lex:
I developed my FSI code based on the FENothing framework used in step-46.
Step-46 shows how to identify the interface between the fluid and solid
domain. Also it shows how to set constraints on variables and how to assemble
terms on the interface. I just used the same logic in my FSI
Ananya:
I am running "cmake ." and "make", followed by "mpirun -np 4 ./step-17 " in
the step directory.
Mpirun is working on step-40 and step-42, but not on step-17 and step-18.
That makes sense, because steps 40 and 42 do not use METIS.
I have also installed Dealii 9.5 using Candii. In
Wolfgang,
I am running "cmake ." and "make", followed by "mpirun -np 4 ./step-17 "
in the step directory.
Mpirun is working on step-40 and step-42, but not on step-17 and step-18.
I have also installed Dealii 9.5 using Candii. In this installation I am
able to mpirun step-17
and step-18.
On 9/12/23 23:29, Ananya Bijaya wrote:
I have installed Dealii 9.4.2 using "spack install dealii" on Ubuntu 20.04
inside WSL. When I try to mpirun step-17 and step-18 I either encounter an
error message (attached at the end) when the number of cores is more than two
or for two cores the
[Standard bla bla: I am not a lawyer]
Generally speaking, yes.
If you happen to use deal.II with any of the GPL only derivatives (such
as GMSH, or more importantly, P4est) then the "effective" license for
deal.II would be GPL [1,2,3].
But generally this is only of concern if you
- distribute
Hi.
The function
GridIn::read_msh
uses the Gmsh-api internally to read a mesh from file. However, Gmsh is
distributed under GPL and not LGPL.
Does this mean that one can not use this function if one wants to use
deal.II under LGPL?
Best,
Simon
--
The deal.II project is located at
