This section defines the movement of the mesh. Currently only static non-conformal interfaces are supported.
Non-conformal meshes are defined using ZONES
and INTERFACES
. Each zone is a domain as
defined in the GEOMETRY
section. For a mesh to be non-conformal it must consist of
at least two zones with different domain tags. These two zones can then be split
by an interface where every interface is defined by two composite entities, we use
LEFT
and RIGHT
notation to distinguish between these. Each zone must contain
either the left or the right interface edge. Zones can contain multiple edges across
different interfaces but must not contain both edges for the same interface. These
left and right interface edges have to be geometrically identical but topologically
disconnected i.e. occupy the same space physically but consist of independent geometry
objects.
Non-conformal interfaces are defined enclosed in the NEKTAR
tag. An example showing two
non-conformal interfaces on a single mesh is below:
Zones must have a type specified, at the moment only ‘FIXED’ interfaces are supported
however in the future there are plans to implement rotating, sliding, and prescribed motion
using the ALE method. It is important for the zone IDs to correspond with the relevant
interface IDs present on the zone, that is if there is an interface with ID 0 there must
also be a zone with ID 0 too. Zone IDs must be unique but interfaces can have the
same ID, e.g. in the example above zone ID 1 has two interfaces attached to it.
The inclusion of an "INTERFACE NAME="..."
allows for specifying a name, which is
used for the debug output when the verbose flag ‘-v’ is specified. This is for user
reference to ensure the non-conformal interfaces are set up correctly, and shows
zone/interface IDs, number of elements in each zone and interface, and connections
between each zone/interface. An example debug output for the above XML is shown
below: