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.128.35.214
Lock expires at: 2026/04/01 22:09 (7 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, general description of OOFEM input files for solving flow problems can be found. Fully general description of OOFEM input file (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_tau60_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 under consideration, type of solver and exported variables are specified. In the second section there is a mesh descriptions. That means list of nodes with its numbers, coordinates and boundary conditions and list of elements specifying its type, numbers of connecting nodes, it's appropriate material and eventually its load. In the third section description of materials, boundary conditions and related entities is done.

  * **First section**
 In first section (first seven lines), there is description of type of problem under consideration, type of solver and exported variables are specified. 

First line specifies the location of OOFEM output file. Note, that the path must be an absolute path. 

Second line is for user comment. There can be any description of solved problem, OOFEM ignores that line.

Third line describes type of solver and it's parameters. Some of them are genereal and necessary for all solvers, some of them are specific for concrete solver.
Note, that order of keywords is not determined!!! 


^  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.|