[Gmsh] GMSH for Thermal Codes?

Christophe Geuzaine c.geuzaine at ulg.ac.be
Wed Aug 20 06:05:26 CEST 2003


Joe Koski wrote:
> Perhaps I need to work step-by-step through an example, although I'm not
> sure which one. I'm still trying to understand the underlying concepts of
> the code.

Have a look at the first tutorial (tutorial/t1.geo).

The "executive summary" is:

- you first define elementary geometrical entities (points, lines,
surfaces and volumes)
- then, if you need to group elementary entities for some reason (for
example, to define boundary conditions), you define physical entities.

> 
> For the input file of all thermal finite element codes that I have used, the
> mesh input is defined in much the same way as the Gmsh output: first the
> nodes are located (x,y,z), then the elements are defined with node-to-node
> sequences. There then follows a boundary condition portion of the thermal
> code input that applies heat transfer or temperature boundary conditions to
> the various surfaces, or in some cases throughout the entire volume of the
> solid. Examples are constant temperature surfaces, convection heat transfer
> from fluids, thermal radiation interaction with internal and external
> surfaces, and Joulean electrical heating of the entire solid.

You don't need these lists in Gmsh: elements in the output mesh file are 
simply tagged with the appropriate physical entity number--so no 
information is duplicated.

For example, let's say you want to define a simple thermal problem on a
square domain, with Dirichlet boundary conditions on the top and bottom
sides. Here is what your Gmsh input files could look like:

file "definitions.txt":
-----------------------
domain=111;
dirichlet_top=555;
dirichlet_botton=556;


file "square.geo":
------------------
// elementary entities:
Point(1) = {0,0,0,0.3};
Point(2) = {1,0,0,0.3};
Point(3) = {1,1,0,0.3};
Point(4) = {0,1,0,0.3};
Line(1) = {1,2};
Line(2) = {2,3};
Line(3) = {3,4};
Line(4) = {4,1};
Line Loop(1) = {1,2,3,4};
Plane Surface(2) = {1};

// interface to solver:
Include "definitions.txt";
Physical Surface(domain)={2};
Physical Line(dirichlet_top)={3};
Physical Line(dirichlet_bottom)={1};


> 
> The "good" commercial mesh generators permit the boundary conditions to be
> identified during the meshing process either with the geometry phase
> constructs, or to the mesh itself. The "good" meshing codes can translate
> geometry boundary applications to mesh equivalents and creates the necessary
> output lists to define the boundary conditions to the thermal code. It is
> usually easier to apply BCs directly to the geometry that you have just
> created. This is because you built and understood the geometry phase, while
> the meshing algorithm built the mesh. From the users point of view, if the
> meshing code can keep track of the location for application of these BCs,
> then the users life is much easier. This avoids, for example, the problem of
> identifying 20 elements and face numbers arbitrarily numbered by the mesh
> generator from a list of several thousand surfaces. Even with the best
> commercial meshers, application of boundary conditions is often difficult.
> This is because the mesh generator was designed first for structural
> problems, and then adapted for thermal uses later.

Sure, that's how Gmsh works, too. And you can define your physical 
entities interactively (in the GUI) if you want to.

> 
> The question remains whether I am missing something about Gmsh. Is it
> possible to have Gmsh identify all nodes related to a particular geometry
> surface, then provide a node or element list to the user for application of
> boundary conditions? Perhaps this is exactly what the "physical surface"
> concept does. 

Exactly.

> A simple (for the user, not the programmer) approach would be
> to identify surfaces by name during the geometry phase ("front," "left
> side," etc.) and then, while translating from Gmsh to thermal code input,
> specify what boundary conditions are to be applied to the nodes and elements
> of each named surface.

Yep, see above.

Hope this helps,

Christophe

-- 
Christophe A. Geuzaine
Applied and Computational Mathematics, Caltech
geuzaine at acm.caltech.edu - http://geuz.org