HOMARD : General rules |
![]() |
Whatever method of use is selected, general rules are to be complied with in setting up the data, namely
for the following :
Mesh includes nodes, point-meshes, segments, triangles and/or tetrahedrons. It may be of degree 1 or 2.
It must not contain hanging nodes. It may be made up of several pieces.
Meshes mixing volume meshed areas and surface meshed areas can definitely be processed.
These areas may be adjacent or not.
During the refining process there is no mesh adjustment. Therefore,
the initial mesh should be as smooth as possible. Poor initial mesh
would result in poor split meshes. Conversely, the initial mesh may be
coarse. It merely needs to comply with the minimum initial conditions.
Lastly, it would be desirable to have - from the very onset - proper
representation of any curving borders. As border element splitting is
carried out based on border approximation by the initial mesh, fine
tracking of marked curves may not occur systematically. To remedy this, a
specific module for 2D-border tracking is available.
Defining where boundary conditions or source operands are enforced has to be
carried out on entities of dimensions similar to that of the phenomenon
being represented. In other words, in mechanics, a one-off loading should be
defined on a node. For 2D calculation, the definition of behaviors on the
boundary is obtained through boundary edge characterizations rather than
through boundary nodes. Also, in 3D, the behaviors on the outer walls of the
area to be modeled are based on the triangles making up the boundary. In so
doing, one is sure to properly propagate the definitions as mesh is
refined.
One should absolutely not use definitions of boundary conditions by
nodes for this would make it impossible to properly represent the borders
after adaptation. This is demonstrated in the example below.
![]() |
A case of fluid mechanics is to be modeled here, where a flow enters then exits a cavity. This is a 2D model, and boundary conditions are defined classically, through node characterization. On the zoom drawn below, red nodes are for walls and blue nodes for inlet, while black nodes are for free nodes. |
If the mesh needs to be split around the inlet area, new nodes are generated. The problem here is to find out to which category a new node located between a wall node or an inlet node belongs to. If -- left-hand side case -- the wall gets priority, everything is fine. Conversely, if -- right-hand side case -- it is the inlet that gets priority, there is a problem: this results in artificially expanding the inlet, therefore distorting the calculation!
![]() |
![]() |
The management of priorities between data soon becomes impossible : exclusive conventions for all HOMARD-related calculation softwares would have to be set up, while dealing with a combination of many possibilities. Moreover, in 3D, this technique for managing priorities leads to a deadlock. Try and imagine updating characterizations for nodes resulting from the splitting of tetrahedrons in the angle of the domain. Very quickly, it becomes impossible to choose between blue, red and green.
The only viable solution consists in defining boundary conditions on boundary elements. Going back to our 2D example for fluid mechanics, the wall or inclet characteristics are assigned to the boundary edges. In the calculation software, the program can very easily transfer information on edges towards border summits.
![]() |
If mesh refinement is carried out as previously, the new edges take on the same characterization as those out of which they arise : one split wall edge results in two wall edges, and one split inlet edge results in two inlet edges. Consequently, the calculation software has no difficulty setting up the right data on border nodes. |
There is a choice between several types of refinement and unrefinement :
Most of the time, the error indicator is a real-value field defined by
element. It is one of the results of the calculation software. The selection
of elements to be split is carried out by comparing the value of the
indicator to a given threshold.
HOMARD accommodates two extensions to this standard: an error indicator
expressed node and/or error indicator under integer form. Whenever the
indicator is provided by a node, HOMARD assigns the highest error value
encountered on the element nodes to each element. Whenever the indicator is
under integer form, the convention is that 1 is for refinement requests
and 0 for no action.
There is no requirement to provide a value for each and every element: if
no value is assigned to an element, HOMARD defaults the element to a null
error.
HOMARD is able to update fields which are expressed over the mesh. Two cases are available :
[ Top | Control data | Back ]