Commit 1334bf92 authored by Chris Cantwell's avatar Chris Cantwell
Browse files

Added FAQs. Tidied up XML section.

parent a8b463ba
\chapter{Frequently Asked Questions}
\section{Compilation and Testing}
\textbf{Q. I compile Nektar++ successfully but, when I run ctest, all the
tests fail. What might be wrong?}
On Linux or Mac, if you compile the ThirdParty version of Boost, rather than
using version supplied with your operating system (or MacPorts on a Mac), the
libraries will be installed in the \inlsh{ThirdParty/dist/lib} subdirectory of
your Nektar++ directory. When Nektar++ executables are run, the Boost libraries
will not be found as this path is not searched by default. To allow the Boost
libraries to be found set the following environmental variable, substituting
\inlsh{\${NEKTAR\_HOME}} with the absolute path of your Nektar++ directory:
\begin{itemize}
\item On Linux (sh, bash, etc)
\begin{lstlisting}[style=BashInputStyle]
export LD_LIBRARY_PATH=${NEKTAR_HOME}/ThirdParty/dist/lib
\end{lstlisting}
or (csh, etc)
\begin{lstlisting}[style=BashInputStyle]
setenv LD_LIBRARY_PATH ${NEKTAR_HOME}/ThirdParty/dist/lib
\end{lstlisting}
\item On Mac
\begin{lstlisting}[style=BashInputStyle]
export DYLD_LIBRARY_PATH=${NEKTAR_HOME}/ThirdParty/dist/lib
\end{lstlisting}
\end{itemize}
\textbf{Q. How to I compile Nektar++ to run in parallel?}
Parallel execution of all Nektar++ solvers is available using MPI. To compile
using MPI, enable the \inlsh{NEKTAR\_USE\_MPI} option in the CMake
configuration.
On recent versions of MPI, the solvers can still be run in serial when compiled
with MPI. More information on Nektar++ compilation options is available in
Section~\ref{s:installation:source:cmake}.
\textbf{Q. When running any Nektar++ executable on Windows, I receive an error
that zlib.dll cannot be found. How do I fix this?}
Windows searches for DLL files in directories specified in the PATH
environmental variable. You should add the location of the ThirdParty files to
your path. To fix this (example for Windows XP):
\begin{itemize}
\item As an administrator, open ''System Properties'' in control panel, select
the ''Advanced'' tab, and select ''Environment Variables''.
\item Edit the system variable `path` and append
\inlsh{C:\textbackslash path\textbackslash
to\textbackslash nektar++\textbackslash ThirdParty\textbackslash
dist\textbackslash bin}
to the end, replacing
\inlsh{path\textbackslash to\textbackslash nektar++} appropriately.
\end{itemize}
\section{Usage}
\textbf{Q. How do I run a solver in parallel?}
In a desktop environment, simply prefix the solver executable with the
\inlsh{mpirun} helper. For example, to run the Incompressible Navier-Stokes
solver on a 4-core desktop computer, you would run
\begin{lstlisting}[style=BashInputStyle]
mpirun -np 4 IncNavierStokesSolver Cyl.xml
\end{lstlisting}
In a cluster environment, using PBS for example, the \inlsh{mpiexec} command
should be used.
\textbf{Q. How can I generate a mesh for use with Nektar++?}
Nektar++ supports a number of mesh input formats. These are converted to the
Nektar++ native XML format (see Section~\ref{s:xml}) using the
MeshConvert utility (see Section~\ref{s:utilities:meshconvert}. Supported
formats include:
\begin{itemize}
\item Gmsh (.msh)
\item Polygon (.ply)
\item Nektar (.rea)
\item Semtex (.sem)
\end{itemize}
\ No newline at end of file
\section{Installing from Source}
\label{s:installation:source}
\subsection{Linux}
3.4/UserGuide/Compile/Linux
......@@ -10,4 +11,5 @@
3.4/UserGuide/Compile/Windows
\subsection{CMake Option Reference}
\label{s:installation:source:cmake}
3.4/UserGuide/Compile/CMakeOptions
......@@ -63,7 +63,10 @@ The monodomain equation:
\end{align*}
\subsection{Usage}
\lstinline[style=BashInputStyle]{CardiacEPSolver session.xml}
\begin{lstlisting}[style=BashInputStyle]
CardiacEPSolver session.xml
\end{lstlisting}
\subsection{Session file configuration}
\subsubsection{Solver Info}
......
\chapter{Solvers}
\label{c:solvers}
\input{adr}
\input{ape}
......
......@@ -156,15 +156,16 @@ openany, % A chapter may start on either a recto or verso page.
%\newcommand{\shellcommand}[1]{\begin{lstlisting} \#1 \end{lstlisting}
\lstdefinestyle{BashInputStyle}{
language=bash,
basicstyle=\small\sffamily,
basicstyle=\small\ttfamily,
% numbers=left,
% numberstyle=\tiny,
% numbersep=3pt,
frame=,
columns=fullflexible,
backgroundcolor=\color{black!05},
linewidth=0.9\linewidth,
xleftmargin=0.1\linewidth
backgroundcolor=\color{black!10},
linewidth=\linewidth,
xleftmargin=0.05\linewidth,
keepspaces=true
}
\definecolor{gray}{rgb}{0.4,0.4,0.4}
\definecolor{darkblue}{rgb}{0.0,0.0,0.6}
......@@ -194,13 +195,16 @@ openany, % A chapter may start on either a recto or verso page.
frame=,
columns=fullflexible,
backgroundcolor=\color{black!05},
linewidth=0.9\linewidth,
xleftmargin=0.1\linewidth,
linewidth=\linewidth,
xleftmargin=0.05\linewidth,
keepspaces=true
}
\usepackage{tikz}
\newcommand{\inltt}[1]{\tikz[anchor=base,baseline]\node[inner sep=3pt,rounded corners,outer sep=0,draw=black!30,fill=black!10]{\texttt{#1}};}
\newcommand{\inltt}[1]{\tikz[anchor=base,baseline]\node[inner sep=3pt,
rounded corners,outer sep=0,draw=black!30,fill=black!10]{\texttt{#1}};}
\newcommand{\inlsh}[1]{\tikz[anchor=base,baseline]\node[inner sep=2pt,
outer sep=0,fill=black!10]{\texttt{#1}};}
\newcommand{\nekpp}{{\em Nektar++}\xspace}
%%% TABLE OF CONTENTS AND INDEX
......
\section{MeshConvert}
\label{s:utilities:meshconvert}
3.4/Reference/Utilities/MeshConvert
3.4/UserGuide/Tutorial/MeshConvert
\section{Conditions}
The final section of the file defines parameters and boundary conditions which define the nature of the problem to be solved. These are enclosed in the CONDITIONS tag.
The final section of the file defines parameters and boundary conditions which
define the nature of the problem to be solved. These are enclosed in the
\inltt{CONDITIONS} tag.
\subsection{Parameters}
Parameters may be required by a particular solver (for instance time-integration parameters or solver-specific parameters), or arbitrary and only used within the context of the session file (e.g. parameters in the definition of an initial condition). All parameters are enclosed in the PARAMETERS XML element.
\begin{lstlisting}[style=XMLStyle]
Parameters may be required by a particular solver (for instance time-integration
parameters or solver-specific parameters), or arbitrary and only used within the
context of the session file (e.g. parameters in the definition of an initial
condition). All parameters are enclosed in the \inltt{PARAMETERS} XML element.
\begin{lstlisting}[style=XMLStyle]
<PARAMETERS>
...
...
</PARAMETERS>
\end{lstlisting}
A parameter may be of integer or real type and may reference other parameters defined previous to it. It is expressed in the file as
A parameter may be of integer or real type and may reference other parameters
defined previous to it. It is expressed in the file as
\begin{lstlisting}[style=XMLStyle]
<P> [PARAMETER NAME] = [PARAMETER VALUE] </P>
\end{lstlisting}
For example,
\begin{lstlisting}[style=XMLStyle]
......@@ -24,21 +33,28 @@ For example,
\subsection{Solver Information}
These specify properties to define the actions specific to solvers, typically including the equation to solve, the projection type and the method of time integration. The property/value pairs are specified as XML attributes. For example,
\begin{lstlisting}[style=XMLStyle]
These specify properties to define the actions specific to solvers, typically
including the equation to solve, the projection type and the method of time
integration. The property/value pairs are specified as XML attributes. For
example,
\begin{lstlisting}[style=XMLStyle]
<SOLVERINFO>
<I PROPERTY="EQTYPE" VALUE="UnsteadyAdvection" />
<I PROPERTY="Projection" VALUE="Continuous" />
<I PROPERTY="EQTYPE" VALUE="UnsteadyAdvection" />
<I PROPERTY="Projection" VALUE="Continuous" />
<I PROPERTY="TimeIntegrationMethod" VALUE="ClassicalRungeKutta4" />
</SOLVERINFO>
\end{lstlisting}
The list of available solvers in Nektar++ can be found [wiki:Tutorial here].
The list of available solvers in Nektar++ can be found in
Chapter~\ref{c:solvers}.
\subsection{Variables}
These define the number (and name) of solution variables. Each variable is prescribed a unique ID. For example a two-dimensional flow simulation may define the velocity variables using
These define the number (and name) of solution variables. Each variable is
prescribed a unique ID. For example a two-dimensional flow simulation may define
the velocity variables using
\begin{lstlisting}[style=XMLStyle]
<VARIABLES>
<V ID="0"> u </V>
......@@ -48,7 +64,9 @@ These define the number (and name) of solution variables. Each variable is presc
\subsection{Global System Solution Information}
This section allows you to specify the global system solution parameters which is particularly useful when using an iterative solver. An example of this section is as follows:
This section allows you to specify the global system solution parameters which
is particularly useful when using an iterative solver. An example of this
section is as follows:
\begin{lstlisting}[style=XMLStyle]
<GLOBALSYSSOLNINFO>
......@@ -65,7 +83,11 @@ This section allows you to specify the global system solution parameters which i
</GLOBALSYSSOLNINFO>
\end{lstlisting}
The above section specifies that the global solution system for the variables "u,v,w" should use the iIerativeStaticCond approach with the LowEnergyBlock preconditioned and an iterative tolerance of 1e-6. Where as the variable "p" which also si sovlerd with the IterativeStaticCond approach should use the FullLinearSpaceWithLowEnergyBlock and an iterative tolerance of 1e-8.
The above section specifies that the global solution system for the variables
"u,v,w" should use the iIerativeStaticCond approach with the LowEnergyBlock
preconditioned and an iterative tolerance of 1e-6. Where as the variable "p"
which also is solved with the IterativeStaticCond approach should use the
FullLinearSpaceWithLowEnergyBlock and an iterative tolerance of 1e-8.
Other parameters which can be specified include SuccessiveRHS.
......@@ -73,64 +95,96 @@ The parameters in this section override those specified in the Parameters sectio
\subsection{Boundary Regions and Conditions}
Boundary conditions are defined by two XML elements. The first defines the various boundary regions in the domain in terms of composite entities from the GEOMETRY section of the file. Each boundary region has a unique ID and are defined as, for example,
Boundary conditions are defined by two XML elements. The first defines the
various boundary regions in the domain in terms of composite entities from the
\inltt{GEOMETRY} section of the file. Each boundary region has a unique ID and
are defined as, for example,
\begin{lstlisting}[style=XMLStyle]
<BOUNDARYREGIONS>
<B ID="0"> C[2] </B>
<B ID="1"> C[3] </B>
</BOUNDARYREGIONS>
\end{lstlisting}
The second defines the actual boundary condition to impose on that composite region for each of the defined solution variables, and has the form,
\begin{lstlisting}[style=XMLStyle]
The second defines the actual boundary condition to impose on that composite
region for each of the defined solution variables, and has the form,
\begin{lstlisting}[style=XMLStyle]
<BOUNDARYCONDITIONS>
<REGION REF="0">
<D VAR="u" VALUE="sin(PI*x)*cos(PI*y)" />
<D VAR="v" VALUE="sin(PI*x)*cos(PI*y)" />
<D VAR="u" VALUE="sin(PI*x)*cos(PI*y)" /> <D VAR="v"
VALUE="sin(PI*x)*cos(PI*y)" />
</REGION>
</BOUNDARYCONDITIONS>
\end{lstlisting}
Boundary condition specifications may refer to any parameters defined in the session file. The REF attribute corresponds to a defined boundary region. The tag used for each variable specifies the type of boundary condition to enforce. These can be either
- D: Dirichlet
- N: Neumann
- R: Robin
- P: Periodic
[wiki:Reference/BoundaryConditionTypes This page] provides the list of all acceptable boundary condition types and syntax of their declarations.
Boundary condition specifications may refer to any parameters defined in the
session file. The REF attribute corresponds to a defined boundary region. The
tag used for each variable specifies the type of boundary condition to enforce.
These can be either
\begin{itemize}
\item \inltt{D} Dirichlet
\item \inltt{N} Neumann
\item \inltt{R} Robin
\item \inltt{P} Periodic
\end{itemize}
% TODO: document user defined types, etc
Time-dependent boundary conditions may be specified through setting the
\inltt{USERDEFINEDTYPE} attribute. For example,
Time-dependent boundary conditions may be specified through setting the USERDEFINEDTYPE attribute. For example,
\begin{lstlisting}[style=XMLStyle]
<D VAR="u" USERDEFINEDTYPE="TimeDependent" VALUE="sin(PI*(x-t))" />
\end{lstlisting}
Periodic boundary conditions reference the corresponding boundary region with which to enforce periodicity.
The following example provides an example of three boundary conditions for a two-dimensional flow,
Periodic boundary conditions reference the corresponding boundary region with
which to enforce periodicity.
The following example provides an example of three boundary conditions for a
two-dimensional flow,
\begin{lstlisting}[style=XMLStyle]
<BOUNDARYCONDITIONS>
<REGION REF="0">
<D VAR="u" USERDEFINEDTYPE="TimeDependent" VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent" VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<D VAR="u" USERDEFINEDTYPE="TimeDependent"
VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent"
VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<P VAR="p" VALUE=[2]/>
</REGION>
<REGION REF="1">
<D VAR="u" USERDEFINEDTYPE="TimeDependent" VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent" VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<D VAR="u" USERDEFINEDTYPE="TimeDependent"
VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent"
VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<N VAR="p" USERDEFINEDTYPE="H" VALUE="0.0"/>
</REGION>
<REGION REF="2">
<D VAR="u" USERDEFINEDTYPE="TimeDependent" VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent" VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<D VAR="u" USERDEFINEDTYPE="TimeDependent"
VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent"
VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<P VAR="p" VALUE=[0]/>
</REGION>
<REGION REF="3">
<D VAR="u" USERDEFINEDTYPE="TimeDependent" VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent" VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<D VAR="p" USERDEFINEDTYPE="TimeDependent" VALUE="-0.25*(cos(2*x)+cos(2*y))*exp(-4*t*Kinvis)"/>
<D VAR="u" USERDEFINEDTYPE="TimeDependent"
VALUE="-cos(x)*sin(y)*exp(-2*t*Kinvis)" />
<D VAR="v" USERDEFINEDTYPE="TimeDependent"
VALUE="sin(x)*cos(y)*exp(-2*t*Kinvis)" />
<D VAR="p" USERDEFINEDTYPE="TimeDependent"
VALUE="-0.25*(cos(2*x)+cos(2*y))*exp(-4*t*Kinvis)"/>
</REGION>
</BOUNDARYCONDITIONS>
\end{lstlisting}
where the boundary regions which are periodic are linked via their region identifier (Region 0 and Region 2).
Boundary conditions can also be loaded from file, here an example from the Incompressible Navier-Stokes cases,
where the boundary regions which are periodic are linked via their region
identifier (Region 0 and Region 2).
Boundary conditions can also be loaded from file, here an example from the
Incompressible Navier-Stokes cases,
\begin{lstlisting}[style=XMLStyle]
<REGION REF="1">
<D VAR="u" FILE="Test_ChanFlow2D_bcsfromfiles_u_1.bc" />
......@@ -141,7 +195,11 @@ Boundary conditions can also be loaded from file, here an example from the Incom
\subsection{Functions}
Finally, multi-variable functions such as initial conditions and analytic solutions may be specified for use in, or comparison with, simulations. These may be specified using expressions (<E>) or imported from a file (<F>) using the Nektar++ FLD file format
Finally, multi-variable functions such as initial conditions and analytic
solutions may be specified for use in, or comparison with, simulations. These
may be specified using expressions (\inltt{<E>}) or imported from a file
(\inltt{<F>}) using the Nektar++ FLD file format
\begin{lstlisting}[style=XMLStyle]
<FUNCTION NAME="ExactSolution">
<E VAR="u" VALUE="sin(PI*x-advx*t))*cos(PI*(y-advy*t))" />
......@@ -150,9 +208,14 @@ Finally, multi-variable functions such as initial conditions and analytic soluti
<F VAR="u" FILE="session.rst" />
</FUNCTION>
\end{lstlisting}
A restart file is a solution file (in other words an .fld renamed as .rst) where the field data is specified. The expansion order used to generate the .rst file must be the same as that for the simulation. The filename must be specified relative to the location of the .xml file.
A restart file is a solution file (in other words an .fld renamed as .rst) where
the field data is specified. The expansion order used to generate the .rst file
must be the same as that for the simulation. The filename must be specified
relative to the location of the .xml file.
Other examples of this input features can be the insertion of a forcing term,
\begin{lstlisting}[style=XMLStyle]
<FUNCTION NAME="BodyForce">
<E VAR="u" VALUE="0" />
......@@ -162,7 +225,9 @@ Other examples of this input features can be the insertion of a forcing term,
<E VAR="u" VALUE="-(Lambda + 2*PI*PI)*sin(PI*x)*sin(PI*y)" />
</FUNCTION>
\end{lstlisting}
or of a linear advection term
\begin{lstlisting}[style=XMLStyle]
<FUNCTION NAME="AdvectionVelocity">
<E VAR="Vx" VALUE="1.0" />
......@@ -175,7 +240,16 @@ or of a linear advection term
\subsection{Quasi-3D approach}
To generate a Quasi-3D appraoch with Nektar++ we only need to create a 2D or a 1D mesh, as reported above, and then specify the parameters to extend the problem to a 3D case. For a 2D spectral/hp element problem, we have a 2D mesh and along with the parameters we need to define the problem (i.e. equation type, boundary conditions, etc.). The only thing we need to do, to extend it to a Quasi-3D approach, is to specify some additional parameters which characterise the harmonic expansion in the third direction. First we need to specify in the solver information section that that the problem will be extended to have one homogeneouns dimension; here an example
To generate a Quasi-3D appraoch with Nektar++ we only need to create a 2D or a
1D mesh, as reported above, and then specify the parameters to extend the
problem to a 3D case. For a 2D spectral/hp element problem, we have a 2D mesh
and along with the parameters we need to define the problem (i.e. equation type,
boundary conditions, etc.). The only thing we need to do, to extend it to a
Quasi-3D approach, is to specify some additional parameters which characterise
the harmonic expansion in the third direction. First we need to specify in the
solver information section that that the problem will be extended to have one
homogeneouns dimension; here an example
\begin{lstlisting}[style=XMLStyle]
<SOLVERINFO>
<I PROPERTY="SolverType" VALUE="VelocityCorrectionScheme"/>
......@@ -186,7 +260,13 @@ To generate a Quasi-3D appraoch with Nektar++ we only need to create a 2D or a 1
<I PROPERTY="HOMOGENEOUS" VALUE="1D"/>
</SOLVERINFO>
\end{lstlisting}
then we need to specify the parameters which define the 1D harmonic expanson along the z-axis, namely the homogeneous length (LZ) and the number of modes in the homogeneous direction (HomModesZ). HomModesZ corresponds also to the number of quadrature points in the homogenous direction, hence on the number of 2D planes discretized with a specral/hp element method.
then we need to specify the parameters which define the 1D harmonic expanson
along the z-axis, namely the homogeneous length (LZ) and the number of modes in
the homogeneous direction (HomModesZ). HomModesZ corresponds also to the number
of quadrature points in the homogenous direction, hence on the number of 2D
planes discretized with a specral/hp element method.
\begin{lstlisting}[style=XMLStyle]
<PARAMETERS>
<P> TimeStep = 0.001 </P>
......@@ -198,7 +278,11 @@ then we need to specify the parameters which define the 1D harmonic expanson alo
<P> LZ = 1.0 </P>
</PARAMETERS>
\end{lstlisting}
In case we want to create a Quasi-3D approach starting form a 1D spectral/hp element mesh, the procedure is the same, but we need to specify the parameters for two harmonic directions (in Y and Z direction). For Example,
In case we want to create a Quasi-3D approach starting form a 1D spectral/hp
element mesh, the procedure is the same, but we need to specify the parameters
for two harmonic directions (in Y and Z direction). For Example,
\begin{lstlisting}[style=XMLStyle]
<SOLVERINFO>
<I PROPERTY="EQTYPE" VALUE="UnsteadyAdvectionDiffusion" />
......@@ -222,7 +306,14 @@ In case we want to create a Quasi-3D approach starting form a 1D spectral/hp ele
<P> LZ = 2.0 </P>
</PARAMETERS>
\end{lstlisting}
By default the opeartions associated with the harmonic expansions are performed with the Matix-Vector-Multiplication (MVM) defined inside the code. The Fast Fourier Transofrm (FFT) can be used to speed up the operations (if the FFTW library has been compiled in ThirdParty, see the compilation instructions). To use the FFT routines we need just to insert a flag in the solver information as below:
By default the opeartions associated with the harmonic expansions are performed
with the Matix-Vector-Multiplication (MVM) defined inside the code. The Fast
Fourier Transofrm (FFT) can be used to speed up the operations (if the FFTW
library has been compiled in ThirdParty, see the compilation instructions). To
use the FFT routines we need just to insert a flag in the solver information as
below:
\begin{lstlisting}[style=XMLStyle]
<SOLVERINFO>
<I PROPERTY="EQTYPE" VALUE="UnsteadyAdvectionDiffusion" />
......@@ -234,5 +325,11 @@ By default the opeartions associated with the harmonic expansions are performed
<I PROPERTY="USEFFT" VALUE="FFTW"/>
</SOLVERINFO>
\end{lstlisting}
The number of homogenenous modes has to be even. The Quasi-3D apporach can be created starting from a 2D mesh and adding one homogenous expansion or starting form a 1D mesh and adding two homogeneous expansions. Not other options available. In case of a 1D homogeneous extension, the homogeneous direction will be the z-axis. In case of a 2D homogeneous extension, the homogeneous directions will be the y-axis and the z-axis.
The number of homogenenous modes has to be even. The Quasi-3D apporach can be
created starting from a 2D mesh and adding one homogenous expansion or starting
form a 1D mesh and adding two homogeneous expansions. Not other options
available. In case of a 1D homogeneous extension, the homogeneous direction will
be the z-axis. In case of a 2D homogeneous extension, the homogeneous directions
will be the y-axis and the z-axis.
\section{Expansions}
This section defines the polynomial expansions used on each of the defined geometric composites. Expansion entries specify the number of modes, the basis type and have the form
This section defines the polynomial expansions used on each of the defined
geometric composites. Expansion entries specify the number of modes, the basis
type and have the form
\begin{lstlisting}[style=XMLStyle]
<E COMPOSITE="C[0]" NUMMODES="5" FIELDS="u" TYPE="MODIFIED" />
\end{lstlisting}
or, if we have more then one variable
\begin{lstlisting}[style=XMLStyle]
<E COMPOSITE="C[0]" NUMMODES="5" FIELDS="u,v,p" TYPE="MODIFIED" />
\end{lstlisting}
The expansion basis can also be specified by parts, and thus the user is able to increase the quadrature order. For tet elements this takes the form:
The expansion basis can also be specified by parts, and thus the user is able to
increase the quadrature order. For tet elements this takes the form:
\begin{lstlisting}[style=XMLStyle]
<E COMPOSITE="C[0]" BASISTYPE="Modified_A,Modified_B,Modified_C" NUMMODES="3,3,3" POINTSTYPE="GaussLobattoLegendre,GaussRadauMAlpha1Beta0,GaussRadauMAlpha2Beta0" NUMPOINTS="4,3,3" FIELDS="u" />
<E COMPOSITE="C[0]"
BASISTYPE="Modified_A,Modified_B,Modified_C"
NUMMODES="3,3,3"
POINTSTYPE="GaussLobattoLegendre,GaussRadauMAlpha1Beta0,GaussRadauMAlpha2Beta0"
NUMPOINTS="4,3,3"
FIELDS="u" />
\end{lstlisting}
and for prism elements:
\begin{lstlisting}[style=XMLStyle]
<E COMPOSITE="C[1]" BASISTYPE="Modified_A,Modified_A,Modified_B" NUMMODES="3,3,3" POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussRadauMAlpha1Beta0" NUMPOINTS="4,4,3" FIELDS="u" />
<E COMPOSITE="C[1]"
BASISTYPE="Modified_A,Modified_A,Modified_B"
NUMMODES="3,3,3"
POINTSTYPE="GaussLobattoLegendre,GaussLobattoLegendre,GaussRadauMAlpha1Beta0"
NUMPOINTS="4,4,3"
FIELDS="u" />
\end{lstlisting}
\section{Geometry}
This section defines the mesh. It specifies a list of vertices, edges (in two or three dimensions) and faces (in three dimensions) and how they connect to create the elemental decomposition of the domain. It also defines a list of composites which are used in the Expansions and Conditions sections of the file to describe the polynomial expansions and impose boundary conditions.
This section defines the mesh. It specifies a list of vertices, edges (in two or
three dimensions) and faces (in three dimensions) and how they connect to create
the elemental decomposition of the domain. It also defines a list of composites
which are used in the Expansions and Conditions sections of the file to describe
the polynomial expansions and impose boundary conditions.
The GEOMETRY section is structured as
\begin{lstlisting}[style=XMLStyle]
The GEOMETRY section is structured as \begin{lstlisting}[style=XMLStyle]
<GEOMETRY DIM="2" SPACE="2">
<VERTEX>
...
</VERTEX>
<EDGE>
...
</EDGE>
<FACE>
...
</FACE>
<ELEMENT>
...
</ELEMENT>
<CURVED>
...
</CURVED>
<COMPOSITE>
...
</COMPOSITE>
<DOMAIN> ... </DOMAIN>
<VERTEX> ...
</VERTEX> <EDGE> ...
</EDGE> <FACE> ...
</FACE> <ELEMENT> ...
</ELEMENT> <CURVED> ...
</CURVED> <COMPOSITE> ...
</COMPOSITE> <DOMAIN> ... </DOMAIN>
</GEOMETRY>
\end{lstlisting}
It has two attributes:
- DIM: specifies the dimension of the expansion elements.
- SPACE: specifies the dimension of the space in which the elements exist.
These attributes allow, for example, a two-dimensional surface to be embedded in a three-dimensional space. The FACES section is only present when DIM=3. The CURVED section is only present if curved edges or faces are present in the mesh.
\begin{itemize}
\item \inltt{DIM} specifies the dimension of the expansion elements.
\item \inltt{SPACE} specifies the dimension of the space in which the
elements exist.
\end{itemize}
These attributes allow, for example, a two-dimensional surface to be embedded in
a three-dimensional space. The \inltt{FACES} section is only present when
\inltt{DIM}=3.
The \inltt{CURVED} section is only present if curved edges or faces are present
in the mesh.
\subsection{Vertices}
Vertices have three coordinates. Each has a unique vertex ID. They are defined in the file within VERTEX subsection as follows:
\begin{lstlisting}[style=XMLStyle]
<VERTEX>
<V ID="0"> 0.0 0.0 0.0 </V>
...
Vertices have three coordinates. Each has a unique vertex ID. They are defined
in the file within VERTEX subsection as follows:
\begin{lstlisting}[style=XMLStyle] <VERTEX>
<V ID="0"> 0.0 0.0 0.0 </V> ...
</VERTEX>
\end{lstlisting}
VERTEX subsection has three optional attributes: {{{XSCALE}}}, {{{YSCALE}}} and {{{ZSCALE}}}. They specify scaling factors to corresponding vertex coordinates. For example, the following snippet
\begin{lstlisting}[style=XMLStyle]
VERTEX subsection has three optional attributes: \inltt{XSCALE},
\inltt{YSCALE} and \inltt{ZSCALE}. They specify scaling factors to
corresponding vertex coordinates.
For example, the following snippet
\begin{lstlisting}[style=XMLStyle]
<VERTEX XSCALE="5">
<V ID="0"> 0.0 0.0 0.0 </V>
<V ID="1"> 1.0 2.0 0.0 </V>
<V ID="0"> 0.0 0.0 0.0 </V> <V ID="1"> 1.0 2.0 0.0 </V>
</VERTEX>
\end{lstlisting}
defines two vertices with coordinates [[formula( (0.0,0.0,0.0), (5.0,2.0,0.0) )]]. Values of {{{XSCALE}}}, {{{YSCALE}}} and {{{ZSCALE}}} attributes can be arbitrary [wiki:Reference/AnalyticExpressions analytic expressions] depending on pre-defined constants, parameters defined earlier in the XML file and mathematical operations/functions of the latter. If omitted, default scaling factors 1.0 are assumed.
defines two vertices with coordinates $(0.0,0.0,0.0), (5.0,2.0,0.0)$. Values of
\inltt{XSCALE}, \inltt{YSCALE} and \inltt{ZSCALE} attributes can be arbitrary
analytic expressions depending on pre-defined constants, parameters defined earlier in the XML file and
mathematical operations/functions of the latter. If omitted, default scaling
factors 1.0 are assumed.
\subsection{Edges}
Edges are defined by two vertices. Each edge has a unique edge ID. They are defined in the file with a line of the form
Edges are defined by two vertices. Each edge has a unique edge ID. They are
defined in the file with a line of the form
\begin{lstlisting}[style=XMLStyle]
<E ID="0"> 0 1 </E>
\end{lstlisting}
\subsection{Faces}