Commit 952804d8 authored by Chris Cantwell's avatar Chris Cantwell

Merge branch 'feature/MovingBodies' into 'master'

Feature/moving bodies

See merge request !448
parents d18ef8d8 9f35d4a3
......@@ -334,8 +334,8 @@ year={2011}
publisher={Birkh{\"a}user}
}
@article{DoKa14,
title={A robust and accurate outflow boundary condition for incompressible flow
simulations on severely-truncated unbounded domains},
title={A robust and accurate outflow boundary condition for incompressible
flow simulations on severely-truncated unbounded domains},
author={S. Dong and G. E. Karniadakis and C. Chryssostomidis},
journal={Journal of Computational Physics},
volume={261},
......@@ -352,4 +352,4 @@ year={2011}
pages = {157--172},
year = 2007,
publisher = {IOS Press}
}
\ No newline at end of file
}
......@@ -1573,6 +1573,71 @@ It is possible to visualise the wall shear stress distribution by running the Fl
\includegraphics[width=12cm]{Figures/WSS.png}
\caption{Non-dimensional wall shear stress distribution.}
\end{center}
\end{figure}
\subsection{finite-strip modeling of flow past flexible cables}
As a computationally efficient model, strip theory-based modeling technique has been proposed previously to predict vortex-induced vibration (VIV) for higher Reynolds number flows. In the strip theory-based model, the fluid flow solution is obtained on a series of 2D computational planes (also called as “strips”) along the riser’s axis direction. These strips then are coupled with each other through structural dynamic model of the riser, and then VIV response prediction is achieved by the strip-structure interactions.In the 2D strip theory, it is assumed that the flow is purely two-dimensional without spanwise correlation, which allows the problems to be split into various 2D planes. A consequence of 2D strip solution under this assumption is that it is unable to reflect the influence of spanwise wake turbulence on the structural dynamics. In order to overcome this shortcoming, we proposed a new module in the framework of Nektar++, in which a spanwise scale is locally allocated to each one of the strips, so that the spanwise velocity correlation is reconstructed in the flow field within each strips. In particular, this model lets the fluid domain to be divided in $N$ strips with thickness ratio of $L_{z}/D$ and evenly distributed along the spanwise ($z$) direction. The gap between the neighboring strips, represented by $L_{g}$, satisfies relation $L_{c}=N(L_{z}+L_{g})$. Since the strip in this model has finite scale in the $z$-direction, we named it as finite strip to distinguish from traditional 2D strip plane. Next, the flow dynamics within each individual strips are modeled by viscous incompressible Navier-Stokes equations, while a tensioned beam model is employed to govern the dynamics of the flexible structures. In this example, we will show how to perform a finite-strip model to predict the vortex-induced vibration responses of flexible cables. Let us consider a vortex-induced vibration of a slender cable with an aspect ratio of $L_z/D$=4$\pi$, which is immersed in uniform flows at Re=100.
\subsubsection{Input File}
The cable with a mass ratio (defined as the ratio of the total oscillating mass to the mass of displaced fluid) of 1 has diameter $D=1$, the 2D mesh is composed of 284 quadrilateral elements. The spanwise direction is split in 16 strips with thickness ratio of $L_c/D$=$\pi$/8 and one pair of complex Fourier modes for each one of the strips. We will use a sixth order polynomial expansion for the spectral element and the input file for this example is \inlsh{CylFlow\_HomoStrip.xml}.
\begin{lstlisting}[style=XMLStyle]
<E COMPOSITE="C[73]" NUMMODES="6" TYPE="MODIFIED" FIELDS="u,v,w,p" />
\end{lstlisting}
To use the finite strip routines we need just to insert a flag of \inlsh{"HomoStrip"} in the solver information as below, in addition, we need to specify the types of vibration and support ends for the cables. In this case, the vibration type is specified as \inlsh{VALUE="CONSTRAINED"}, which means that the cable's vibration is constrained only in the crossflow direction. Other options include \inlsh{VALUE="FREE"} and \inlsh{"FORCED"}, respectively corresponding to the free vibrations in both streamwise and crossflow directions and forced vibration by specified functions given in input file. For the support ends of the cable, another option of \inlsh{VALUE="PINNED-PINNED"} is available for the simulations, which satisfies the condition of zero values of displacements on the support ends.
\subsubsection{Solver information:~}
\begin{lstlisting}[style=XMLStyle]
<SOLVERINFO>
<I PROPERTY="HomoStrip" VALUE="True"/>
<I PROPERTY="VibrationType" VALUE="CONSTRAINED"/>
<I PROPERTY="SupportType" VALUE="FREE-FREE"/>
</SOLVERINFO>
\end{lstlisting}
\subsubsection{Parameters}
All the simulation parameters are specified in the section as follows.
\begin{lstlisting}[style=XMLStyle]
<PARAMETERS>
<P> LZ = PI/8 </P> <!--thickness ratio-->
<P> LC = 4*PI </P> <!--aspect ratio-->
<P> A = 0.025 </P>
<P> omega = 1.0 </P>
<P> PROC_Z = 16 </P>
<P> Strip_Z = 16 </P> <!--number of the strips-->
<P> DistStrip = PI/4 </P> <!--distance of the strips-->
<P> StructStiff = 0.02 </P>
<P> StructRho = 2.0 </P>
<P> CableTension = 8.82 </P>
<P> BendingStiff = 0.0 </P>
<P> FictDamp = 0.0 </P>
<P> FictMass = 3.0 </P>
</PARAMETERS>
\end{lstlisting}
\subsubsection{Running the solver}
In this example we will run the solver in parallel. We can specify the number of the strips by providing an additional flag to the solver, –nsz. In this example, we will run 16 strips, therefore it would be specified as –nsz 16. The solver can now be run as follows
\begin{lstlisting}[style=BashInputStyle]
mpirun -np 16 IncNavierStokesSolver CylFlow_HomoStrip.xml --npz 16 --nsz 16
\end{lstlisting}
The simulation results are illustrated in spanwise vorticity contours in Figure \ref{f:incns:finite-strip-modeling}. The wake response of the cable appears as standing wave patter in the earlier stage and then it transitions into traveling wave response, as shown in this figure.
\begin{figure}
\begin{center}
\includegraphics[width=7cm]{Figures/strip-16-time-100.png}
\includegraphics[width=7cm]{Figures/strip-16-time-600.png}
\caption{Spanwise vorticity contours in standing wave and traveling wave patterns predicted in finite strip modeling.}
\label{f:incns:finite-strip-modeling}
\end{center}
\end{figure}
\subsection{2D direct stability analysis of the channel flow}
......
......@@ -279,7 +279,6 @@ faster.
%
%
\subsubsection{Interpolate scattered point data to a field: \textit{interppointdatatofld} module}
\label{s:utilities:fieldconvert:sub:interppointdatatofld}
To interpolate discrete point data to a field, use the interppointdatatofld module:
%
\begin{lstlisting}[style=BashInputStyle]
......@@ -308,6 +307,8 @@ Each line defines a point, while the first column contains its $x$-coordinate,
the second one contains the $a$-values, the third the $b$-values and so on.
In case of $n$-dimensional data, the $n$ coordinates are specified in the first $n$
columns accordingly.
Note that currently, the \textit{interppointdatatofld} module can only perform
interpolation in one dimension.
%
In order to interpolate 1D data to a $n$D field, specify the matching coordinate in
the output field using the \inltt{interpcoord} argument:
......@@ -320,12 +321,9 @@ FieldConvert -m interppointdatatofld:interppointdatatofld=1 3D-file1.xml \
This will interpolate the 1D scattered point data from \inltt{1D-file1.pts} to the
$y$-coordinate of the 3D mesh defined in \inltt{3D-file1.xml}. The resulting field
will have constant values along the $x$ and $z$ coordinates.
For 1D Interpolation, the module implements a quadratic scheme and automatically
falls back to a linear method if only two data points are given.
A modified inverse distance method is used for 2D and 3D interpolation.
Linear and quadratic interpolation require the data points in the \inlsh{.pts}-file to be
sorted by their location in ascending order.
The Inverse Distance implementation has no such requirement.
In the \inlsh{.pts}-file, all data points must be sorted by their location in ascending order.
The module implements a quadratic interpolation scheme and automatically falls back to a
linear scheme if only two data points are given.
%
%
%
......
......@@ -298,7 +298,7 @@ the Incompressible Navier-Stokes solver,
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 or .pts file formats
(\inltt{<F>}) using the Nektar++ FLD file format
\begin{lstlisting}[style=XMLStyle]
<FUNCTION NAME="ExactSolution">
......@@ -309,31 +309,11 @@ may be specified using expressions (\inltt{<E>}) or imported from a file
</FUNCTION>
\end{lstlisting}
An .fld file is a solution file (in other words an .fld renamed as .rst) where
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.
.pts files contain scattered point data which needs to be interpolated to the field.
For further information on the file format and the different interpolation schemes, see
section~\ref{s:utilities:fieldconvert:sub:interppointdatatofld}.
All filenames must be specified relative to the location of the .xml file.
must be the same as that for the simulation. The filename must be specified
relative to the location of the .xml file.
With the additional argument \inltt{TIMEDEPENDENT="1"}, different files can be
loaded for each timestep. The filenames are defined using
\href{http://www.boost.org/doc/libs/1_56_0/libs/format/doc/format.html#syntax}{boost::format syntax}
where the step time is used as variable. For example, the function
\inltt{Baseflow} would load the files \inltt{U0V0\_1.00000000E-05.fld},
\inltt{U0V0\_2.00000000E-05.fld} and so on.
\begin{lstlisting}[style=XMLStyle]
<FUNCTION NAME="Baseflow">
<F VAR="U0,V0" TIMEDEPENDENT="1"FILE="U0V0_%14.8E.fld"/>
</FUNCTION>
\end{lstlisting}
For .pts files, the time consuming computation of interpolation weights in only
performed for the first timestep. The weights are stored and reused in all subsequent steps,
which is why all consecutive .pts files must use the same ordering, number and location of
data points.
Other examples of this input feature can be the insertion of a forcing term,
\begin{lstlisting}[style=XMLStyle]
......
......@@ -85,15 +85,21 @@ class ForcingMovingBody : public SolverUtils::Forcing
ForcingMovingBody(
const LibUtilities::SessionReaderSharedPtr& pSession);
void CheckIsFromFile();
void CheckIsFromFile(const TiXmlElement* pForce);
void InitialiseCableModel(
const LibUtilities::SessionReaderSharedPtr& pSession,
const Array<OneD, MultiRegions::ExpListSharedPtr> &pFields);
void UpdateMotion(
void InitialiseFilter(
const LibUtilities::SessionReaderSharedPtr& pSession,
const Array<OneD, MultiRegions::ExpListSharedPtr> &pFields,
NekDouble time);
const TiXmlElement* pForce);
void UpdateMotion(
const Array<OneD, MultiRegions::ExpListSharedPtr>& pFields,
const Array<OneD, Array<OneD, NekDouble> > & fields,
NekDouble time );
void TensionedCableModel(
const Array<OneD, MultiRegions::ExpListSharedPtr> &pFields,
......@@ -102,11 +108,16 @@ class ForcingMovingBody : public SolverUtils::Forcing
void EvaluateStructDynModel(
const Array<OneD, MultiRegions::ExpListSharedPtr> &pFields,
const NekDouble &time );
NekDouble time );
void CalculateForcing(
const Array<OneD, MultiRegions::ExpListSharedPtr> &fields);
void MappingBndConditions(
const Array<OneD, MultiRegions::ExpListSharedPtr> &pfields,
const Array<OneD, Array<OneD, NekDouble> > & fields,
NekDouble time );
void EvaluateAccelaration(
const Array<OneD, NekDouble> &input,
Array<OneD, NekDouble> &output,
......@@ -115,55 +126,34 @@ class ForcingMovingBody : public SolverUtils::Forcing
void SetDynEqCoeffMatrix(
const Array<OneD, MultiRegions::ExpListSharedPtr> &pFields);
void OutputStructMotion(
const Array<OneD, MultiRegions::ExpListSharedPtr> &pFields,
const NekDouble &time);
void RollOver(Array<OneD, Array<OneD, NekDouble> > &input);
int m_intSteps;
int m_movingBodyCalls;
int m_NumLocPlane;
int m_VarArraysize;
int m_NumD;
bool m_FictitiousMass;
bool m_homostrip;
NekDouble m_structrho;
NekDouble m_fictrho;
NekDouble m_cabletension;
NekDouble m_bendingstiff;
NekDouble m_structdamp;
NekDouble m_fictdamp;
NekDouble m_structstiff;
NekDouble m_lhom;
NekDouble m_kinvis;
NekDouble m_timestep;
static NekDouble StifflyStable_Betaq_Coeffs[3][3];
static NekDouble StifflyStable_Alpha_Coeffs[3][3];
static NekDouble StifflyStable_Gamma0_Coeffs[3];
int m_movingBodyCalls; ///< number of times the movbody have been called
int m_np; ///< number of planes per processors
int m_vdim; ///< vibration dimension
NekDouble m_structrho; ///< mass of the cable per unit length
NekDouble m_structdamp; ///< damping ratio of the cable
NekDouble m_lhom; ///< length ratio of the cable
NekDouble m_kinvis; ///< fluid viscous
NekDouble m_timestep; ///< time step
///
LibUtilities::NektarFFTSharedPtr m_FFT;
LibUtilities::CommSharedPtr m_comm;
FilterMovingBodySharedPtr m_filter;
/// free vibration or forced vibration types are available
std::string m_vibrationtype;
///
FilterMovingBodySharedPtr m_MovBodyfilter;
/// storage for the cable's force(x,y) variables
Array<OneD, NekDouble> m_Aeroforces;
/// storage for the cable's motion(x,y) variables
Array<OneD, NekDouble> m_MotionVars;
Array<OneD, Array<OneD, NekDouble> > m_zeta;
Array<OneD, Array<OneD, NekDouble> > m_eta;
/// srorage for the velocity in z-direction
Array<OneD, Array<OneD, NekDouble> > m_W;
/// fictitious velocity storage
Array<OneD, Array<OneD, Array<OneD, NekDouble> > > m_fV;
/// fictitious acceleration storage
Array<OneD, Array<OneD, Array<OneD, NekDouble> > > m_fA;
Array<OneD, Array<OneD, Array<OneD, NekDouble> > > m_BndV;
/// matrices in Newmart-beta method
Array<OneD, DNekMatSharedPtr> m_CoeffMat_A;
/// matrices in Newmart-beta method
Array<OneD, DNekMatSharedPtr> m_CoeffMat_B;
/// [0] is displacements, [1] is velocities, [2] is accelerations
Array<OneD, std::string> m_funcName;
......@@ -171,7 +161,12 @@ class ForcingMovingBody : public SolverUtils::Forcing
Array<OneD, std::string> m_motion;
/// do determine if the the body motion come from an extern file
Array<OneD, bool> m_IsFromFile;
/// Store the derivatives of motion variables in x-direction
Array<OneD, Array< OneD, NekDouble> > m_zta;
/// Store the derivatives of motion variables in y-direction
Array<OneD, Array< OneD, NekDouble> > m_eta;
///
Array<OneD, Array< OneD, NekDouble> > m_forcing;
};
}
......
<?xml version="1.0" encoding="utf-8"?>
<test>
<description>3D flexible cylinder flow simulation using homogeneous strip modeling</description>
<executable>IncNavierStokesSolver</executable>
<parameters>CylFlow_HomoStrip.xml</parameters>
<files>
<file description="Session File">CylFlow_HomoStrip.xml</file>
</files>
<metrics>
<metric type="L2" id="1">
<value variable="u" tolerance="1e-12">39.2429</value>
<value variable="v" tolerance="1e-12">2.64207</value>
<value variable="w" tolerance="1e-12">0.0</value>
<value variable="p" tolerance="1e-12">117.976</value>
</metric>
<metric type="Linf" id="2">
<value variable="u" tolerance="1e-12">1.44448</value>
<value variable="v" tolerance="1e-12">0.671004</value>
<value variable="w" tolerance="1e-12">0.0</value>
<value variable="p" tolerance="1e-12">5.6771</value>
</metric>
</metrics>
</test>
This source diff could not be displayed because it is too large. You can view the blob instead.
......@@ -1832,6 +1832,7 @@
<I PROPERTY="HOMOGENEOUS" VALUE="1D"/>
<I PROPERTY="USEFFT" VALUE="FFTW"/>
<I PROPERTY="VibrationType" VALUE="CONSTRAINED"/>
<I PROPERTY="SupportType" VALUE="FREE-FREE"/>
<I PROPERTY="FictitiousMassMethod" VALUE="True"/>
</SOLVERINFO>
<PARAMETERS>
......
......@@ -8,16 +8,16 @@
</files>
<metrics>
<metric type="L2" id="1">
<value variable="u" tolerance="1e-11">8.6117e-06</value>
<value variable="v" tolerance="1e-11">3.04872e-14</value>
<value variable="w" tolerance="1e-11">8.55267e-05</value>
<value variable="p" tolerance="1e-11">9.07916e-05</value>
<value variable="u" tolerance="1e-11">2.53106e-13</value>
<value variable="v" tolerance="1e-11">2.83952e-14</value>
<value variable="w" tolerance="1e-11">7.00669e-14</value>
<value variable="p" tolerance="1e-11">3.58285e-13</value>
</metric>
<metric type="Linf" id="2">
<value variable="u" tolerance="1e-11">0.000369264</value>
<value variable="v" tolerance="1e-11">4.00843e-13</value>
<value variable="w" tolerance="1e-11">0.0022091</value>
<value variable="p" tolerance="1e-11">0.00142775</value>
<value variable="u" tolerance="1e-11">2.56861e-12</value>
<value variable="v" tolerance="1e-11">3.47405e-13</value>
<value variable="w" tolerance="1e-11">5.99992e-13</value>
<value variable="p" tolerance="1e-11">6.1374e-12</value>
</metric>
</metrics>
</test>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment