Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.
Currently locked by: 47.79.200.246
Lock expires at: 2025/07/08 17:23 (5 min)
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
==== Input File Description ====

Here, a description of OOFEM input files related to flow problems, can be found. The complete and general description of OOFEM input format (for all problems) can be found here: [[http://www.oofem.org|www.oofem.org]] 

As a sample input file, input file for V-funnel simulation is choosen:

{{:tailorcrete:vfunnel_tau40_mu20_beta0.2_oofem.in|}}

In general, OOFEM input file can be (imaginary) divided into three main sections. In the first section specifications about type of problem solved, including specification of type of solver and exported variables, are to be provided. 
In the second section, the computational mesh is specified. This includes specification of nodes (with associated coordinates and boundary conditions) and specification of individual elements (with their type, nodal connectivity, materials and eventually applied loadings). 
In the third section, description of material models, initial and boundary conditions is done.



===First section===
 In the first section (consisting of the first seven lines), the specifications related to type of problem solved, type of solver and exported variables are provided. 

The first line specifies the path to output file containing textual output with simulation results.  
The second line is intended to name the simulation. It can contain any description of solved problem, OOFEM ignores that line.

The third line describes type of problem, its parameters, and numerical solver. Note, that the order of keyword-value pairs is optional !! 

^  Keyword   ^  Possible values   ^   Description of function   ^
|  supg  |   -   | The type of solved problem/type of solving (numerical) scheme. Here, **//supg//** represents name of solver for incompressible Navier-Stokes equations. It is a fully stabilized numerical scheme with Stramline-Upwind/Petrov-Galerkin and Pressure-Stabilizing/Petrov-Galerkin stabilizations. |
|  nsteps  |  integer number  | Number of time steps.|
|  lstype  |  0, 1  | Determines "linear solver type". For example "0" is for direct solver, "1" is for iterative solver. |
|  smtype  |  0, 1,..,10  | Determines "storage of matrix". Number "0" is symmetric skyline, "1" is unsymmetric skyline (note, that supg scheme leads to unsymmetric "stiffness" matrix), "2" is for "compressed column" storage etc. See OOFEM documentation for details.|
|  stype  |  0, 1  | Concrete choice of ITERATIVE solver. Here, "0" is for Cojugate Gradients, "1" is for GMRES (note, that since "stifness matrix" is unsymmetric, Conjugate Gradients doesn't work).|
|  lsprecond  |  0, 1, 2...  | Determines type of preconditioner for solving linear algebraic system. With "0", void preconditioner is used, "1" is for diagonal preconditioner, "2" is for ILU (incomplete LU decomposition).|
|  deltaT  |  real number  | Length of time step|
|  renumber  |  0, 1  | Is the "flag" which cause renumbering of equations due to improve efficiency of solving the system of equations.|
|  renumberflag  |  0, 1  | Is the same as **//renumber//**, but it is done at each time step. This is useful for example when boundary conditions are changing (opening of the gate of L-Box).|
|  alpha  |  0 - 1  | Different numerical scheme for time integration can be chosen(generalized mid-point family). For example "0" means "Forward Euler", "0.5" is for "trapezoidal rule", "2/3" for "Galerkin method", or "1" for "Backward Euler method". Note that for "alpha" greater that 0.5 the method is unconditionally stable but requires matrix inversion. |
|  maxiter  |  integer number  | Determines number of iterations of non-linear solver (Newton-Raphson method).|
|  lsiter  |  integer number  | Determines number of iterations for solver of system of linear algebraic equations (iterative solver).|
|  miflag  |  1, 2  |Governs handling with interface. It can be equal to "1" for "Volume Of Fluid" method, or "2" for "Level Set Method".|
|  nmodules  |  1  |Is a flag for creating *.vtk output (Paraview).|
|  refmatpolyx and refmatpolyy  |  vector valued  |By these variables, polygon describing initial position of interface between fluids can be entered. These parameters are vector valued, while first number governs number of columns. Rest of the numbers are coordinates of that polygon|

Next line, starting vtkxml determines number and type of variables for export to *.vtk file for postprocessing (Paraview). Here, **//primvars//** means primary variables. Again, it is a vector and therefore the first number indicates number of columns, while the rest of numbers determines type of variables. In presented file, "4" means velocity vector, "5" means pressure. **//vars//** means other variables (not directly computed). Here, "43" means Volume Of Fluid, "45" Level set function.

On the next line, type of the domain is specified. It determines the number of dofs per node etc. Next line, the last one from first section, describes number of time_steps etc for printing into oofem output file.





===Second section ===

In the second section mesh geometry is specified. In first line of second section (globally counting it is 8. line) number of mesh entities (elements, nodes...) and other items.  

^  Keyword   ^  Possible values   ^   Description of function   ^
|  ndofman  |  integer number  |Number of mesh nodes|
|  nelem  |  integer number  | Number of elements in the mesh|
|  ncsrosssect  |  integer number  | Number of crosssections. This is important for structural mechanics. In fluid mechanics it is meaningless. However, it has to be specified|
|  nmat  |  integer number  | Number of materials. Note, that for two-fluid flow there has to be 3 materials. One master material, so called "twofluidmat" which governs tho slave materials, for instance Binghamfluid (for concrete) and newtonianfluid (for air)|
|  nbc  |  integer number  | Number of boundary conditions. This means number of types of BC. Here, different type means not just Dirichlet or Neumann. Each value of Dirichlet BC has to be specified independently. Similarly fo Neumann BC.|
|  nic  |  integer number  | Number of initial conditions. Same rules as for BC.|
|  nltf  |  integer number  | Number of "load time functions". Useful for time depending load and BC's. |

After that, list of nodes and elements is specified. Basic syntax is always the same.

**node:** node 1 coords 3 2.250000e+02 0.000000e+00 0.000000e+00 bc 3 1 4 0

^  Keyword   ^  Possible values   ^   Description of function   ^
|  node  |  integer number  |Serial number of the node.|
|  coords  |  vector valued  |Coordinates of the node. It is a vector, first number determines number of columns, the rest are x,y,z coordinates.|
|  bc  |  vector valued  |Boundary condition corresponding to the node. Again, first number determines number of columns, the rest specifies concrete choice of BC for each degree of freedom.|

Similarly for the elements:

**element:** tr1supg 1 nodes 3 9 41 340 crosssect 1 mat 1 bodyloads 1 3 boundaryLoads 2 5 1

^  Keyword   ^  Possible values   ^   Description of function   ^
|  tr1supg  |  integer number  |It is the name of corresponding element and it's number.|
|  nodes  |  vector valued  |Specification of nodes corresponding to the element.|
|  crosssect  |  integer number  |Number of crosssection corresponding to the element. It is meaningless in fluid mechanics, so it is empty crosssection all time.|
|  mat  |  integer number  |Number of material corresponding to the element.|
|  bodyloads  |  vector valued  |Represents body load acting to the element. First number determines number of columns, rest of the numbers represents corresponding type of body load (specified in third section)|
|  boundaryLoads  |  vectro valued  | Represents load on the boundary on the element. The rules are the same as for bodyloads.|





===Third section===

In the third section, specification of **//crosssections, materials, boundary//** and **//initial conditions//** and **//loadtimefunctions//** is done.

Since general description of these parameters is little bit complicated, we refer interested reader to [[http://www.oofem.org|www.oofem.org]] for further details. Here, only quick description of lines in presented file will be given.

^  Entity  ^  parameters in presented file  ^  Description  ^
|  emptycs  |  1  |Emptycs means "void crosssection". (it has no meaning in fluid dynamics, but it has to be specified)|
|  twofluidmat  |  1 mat 2 2 3  |Twofluidmat is name of "master material" for two fluid flow. It coordinates compilation of diffusive temrs depending where the gausspoint is (concrete or air). Number "1" means that it is a first material. Parameter **//mat//** is a vector containing numbers of materials governed by twofluidmat (note, that the first number specifies number of columns). Here, Twofluidmat has two "slaves materials with numbers "2" and "3".|
|  newtonianfluid  |  2 d 0.000001 mu 0.001  |Description of newtonian fluid. It is the second material, **//d//** is density, **//mu//** means viscosity.|
|  binghamfluid2  |   3 d 0.0000023 mu0 0.02 tau0 0.04 muinf 0.001  |Description of Bingham fluid. It is the third material, **//d//** is for density, **//mu0//** is plastic viscosity and **//tau0//** is yield stress. **//muinf//** is some minimal value of mu due to numerical problems.|
|  BoundaryCondition  |  1 loadtimefunction 1 prescribedvalue 0.0 valtype 5  | Description of first type of BC (Dirichlet BC). It uses loadtimefunction no. 1 and the prescribed value is 0.0. **//valtype//** is specification of physical meaning of BC. Number "5" means velocity.|
|  Deadweight  |  3 components 2 0.0 -9810 loadTimeFunction 1 valtype 2  |This is type of body load. It is considered as a boundary condition, so it shares the numbering with previous item. It is the third BC. **//components//** is the body load vector with 2 components (x and z direction).|
|  ConstantEdgeLoad  |  5 ndofs 2 loadtype 4 loadTimeFunction 1 components 2 0 0 properties 1 a 0.2  |This is specification of boundary load. Numbering is shared with all boundary conditions, this is fifth one. **//ndofs//** must be equal to the number of corresponding dofs, in this case it is 2 (components of velocity). **//loadtype//** specifies type of BC, for example flux, convection, etc. Number "4" means "Slip with friction" boundary condition. **//loadtimefunction//** and **//components//** are the same meaning like before. **//properties//** stores coefficient of friction, here it is equal 0.2|
|  ConstantFunction  |  1 f(t) 1.0  | Specification od loadtime function. This is just constant function, sine there are BC's not depending on time. It is the first function with value equal to "1" |
| UsrDefLTF  |  2 f(t) "1-(t>0.04)"  | User defined load time function. It is the second load time function. "1-(t>0.04)" means, that it is active for time greater than 0.04.|