Geometry Discretization
=======================

|FOURC| is a versatile tool which can handle Finite element as well as meshless (particle) methods.
Naturally, the geometry of particles is very different from finite element representations,
thus the geometry sections are detailed here separately as well.
The definition of particles can be found :ref:`here <particledefinition>`.

.. _finiteelementrepresentation:

Finite Element Discretization
-----------------------------
The basic ingredient of a finite element model is its geometrical representation,
which is discretized by a mesh consisting of elements and nodes.

In general, one may define a finite element mesh in two ways:

- Very simple, namely brick-shaped, meshes can be defined by a single command,
  which defines a structured mesh of this brick with equally spaced nodes
  and a given number of elements in each direction. This is called the **domain definition** in the following.
  See :ref:`below<domaindefinition>` how it works.
- All other meshed are to be generated by external pre-processing software, see section :ref:`preprocessing`.
  In the |FOURC| input file, the mesh is included by node and element definitions.
  Of course, one may define the mesh node by node and element by element by hand, see below (:ref:`nodedefinition`)

Additional, the nodes may be grouped into sets, in order to apply boundary and/or interface conditions to them.
See :ref:`here <geometrysets>` how these sets are defined.

.. _domaindefinition:

Domain definition
~~~~~~~~~~~~~~~~~

A meshing domain including all necessary nodes and elements is generated as shown here ::

   ----------STRUCTURE DOMAIN
   LOWER_BOUND  <xmin> <ymin> <zmin>
   UPPER_BOUND  <xmax> <ymax> <zmax>
   INTERVALS   <num_ele_x> <num_ele_y> <num_ele_z>
   ROTATION <angle_x> <angle_y> <angle_z>
   ELEMENTS    <elementtype> <elementshape> <element_parameters>
   PARTITION   auto|structured

For example, one may generate a structural discretization as a brick with width=10, depth=5 and height=3 units
with 150 cube-shaped linear elements by

::

   ----------STRUCTURE DOMAIN
   LOWER_BOUND  0 0 0
   UPPER_BOUND  10 5 3
   INTERVALS   10 5 3
   ROTATION 0 0 0
   ELEMENTS    SOLID HEX8 MAT 1 KINEM nonlinear
   PARTITION   structured

The same meshing strategy can be used for the following discretizations::

   -------STRUCTURE DOMAIN
   -----------FLUID DOMAIN
   -------------ALE DOMAIN
   -----LUBRICATION DOMAIN
   -------TRANSPORT DOMAIN
   ----------THERMO DOMAIN
   ------------CELL DOMAIN
   ------CELLSCATRA DOMAIN


.. _nodedefinition:

Node definition
~~~~~~~~~~~~~~~~

The nodes are read in by the section

::

   --------NODE COORDS

Within this section, the nodes are read one per line. There are different types of nodes:

- General nodes (NODE)
- Control points for nurbs geometry (CP)
- Nodes with addition fiber information (FNODE)

All node coordinates must be given with three coordinates, even if the problem is 1D or 2D::

   NODE <ID> COORD <coord-x> <coord-y> <coord-z> [ROTANGLE <coord-yz> <coord-xz> <coord-xy>]
   CP <ID> COORD <coord-x> <coord-y> <coord-z> <weight>
   FNODE <ID> COORD <coord-x> <coord-y> <coord-z> [FIBER1|FIBER2|FIBER3|CIR|TAN|RAD|HELIX|TRANS] <further parameters>

.. _geometrysets:

Element definition
~~~~~~~~~~~~~~~~~~~

Elements depend strongly on the discretization. However, the general structure is the same for all of them::

    <number> <elementtype> <celltype> <nodeconnectivity> <further parameters>

- ``number`` must be unique.
- ``elementtype`` depends on the discretization.
- ``celltype`` defines the shape of the element as explained in the :ref:`cell type reference <celltypes>`.
- ``nodeconnectivity`` contains this element's node numbers ;
  the total number of nodes given here must be in accordance with the cell type.
- ``further parameters`` depend on the discretization as well.

Geometry sets
~~~~~~~~~~~~~

Geometry sets, to which constraints can be attributed, are defined in separate geometric entities, that is

- Volumes
- Surfaces
- Lines
- Nodes

Geometry sets are always defined by the nodes defining the respective entity.

For the geometric entities, there are two options to create the node sets:
One may either define the sets by the contained nodes,
or by their specific location as minimum or maximum position. The latter works quite well for rectangular/cubicle structures, for which the nodes are expressed as corners, lines are edges, and surfaces are sides, see below.

If the extreme locations are used, one may enter entities like this::

   --DNODE-NODE TOPOLOGY
   CORNER <discretization> x+|x- y+|y- z+|z- DNODE <setnumber>
   --DLINE-NODE TOPOLOGY
   EDGE <discretization> y+|y- z+|z- DLINE <setnumber>  // for an edge along x axis
   EDGE <discretization> x+|x- z+|z- DLINE <setnumber>  // for an edge along y axis
   EDGE <discretization> x+|x- y+|y- DLINE <setnumber>  // for an edge along z axis
   --DSURF-NODE TOPOLOGY
   SIDE <discretization> x+|x- DSURFACE <setnumber>     // for the surface at xmin/xmax
   SIDE <discretization> y+|y- DSURFACE <setnumber>     // for the surface at ymin/ymax
   SIDE <discretization> z+|z- DSURFACE <setnumber>     // for the surface at zmin/zmax
   --DVOL-NODE TOPOLOGY
   VOLUME <discretization> DVOL <setnumber>             // for a whole discretization

for all other cases, one defines the set node by node::

   --DNODE-NODE TOPOLOGY
   NODE <nodenumber> DNODE <pointsetnumber>
   ...
   --DLINE-NODE TOPOLOGY
   NODE <nodenumber> DLINE <linesetnumber>
   ...
   --DSURF-NODE TOPOLOGY
   NODE <nodenumber> DSURFACE <surfacesetnumber>
   ...
   --DVOL-NODE TOPOLOGY
   NODE <nodenumber> DVOL <volumesetnumber>
   ...

.. _particledefinition:

Particle Discretization
------------------------

Currently, two different particle methods are implemented: DEM (discrete element method) and SPH (smoothed particle hydrodynamics).
For both methods, particles are simply defined by their spatial position and optionally by their radius (only available for DEM).
A unique global ID is assigned to each particle automatically during runtime.
Thus, the definition is very simple ::

    ------------------PARTICLE
    TYPE <typestring> POS <x> <y> <z> [RAD <radius>]

The ``TYPE`` keyword provides a particle phase, to which a material can be assigned in the section :ref:`PARTICLE DYNAMIC <SECparticledynamic>`,
see the keyword :ref:`PHASE_TO_MATERIAL_ID <SECparticledynamic>`.

For DEM, the phases **phase1** and **phase2** may be defined.

For SPH, the following phases may be defined to represent different physical behavior:

- phase1
- phase2
- boundaryphase
- rigidphase
- neumannphase
- dirichletphase

Note that with SPH the particles are allowed to change their phase during a simulation based on the input parameter ``PHASECHANGETYPE`` and ``PHASECHANGEDEFINITION`` in the section :ref:`PARTICLE DYNAMIC/SPH <SECparticledynamic_sph>`.

For SPH the radius corresponds to the cutoff radius of the smoothing kernel. Since the cutoff radius is assumed to be constant this is the only option available.

For the DEM, the particles are assumed to have a spherical shape with a given radius.

By default, the radius of the particles are defined in the material definition for both DEM and SPH.

However, as mentioned above, with DEM the radius can also be defined individually per particle.
To do so one has to define the option ``INITIAL_RADIUS`` in :ref:`PARTICLE DYNAMIC/DEM <SECparticledynamic_dem>`::

    ------------------PARTICLE DYNAMIC/DEM
    INITIAL_RADIUS    RadiusFromParticleInput

Additionally, it is possible to define a normal or a log-normal distribution of the radius, defined by two parameters, :math:`\mu` and :math:`\sigma`.
The parameter :math:`\mu` is defined by the initial radius in the material definition,
while the parameter :math:`\sigma` is defined by the parameter ``RADIUSDISTRIBUTION_SIGMA`` in :ref:`PARTICLE DYNAMIC/DEM <SECparticledynamic_dem>`::


    ------------------PARTICLE DYNAMIC/DEM
    INITIAL_RADIUS            NormalRadiusDistribution|LogNormalRadiusDistribution
    RADIUSDISTRIBUTION_SIGMA  <variation>