CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Wiki > PHOENICS

PHOENICS

From CFD-Wiki

(Difference between revisions)
Jump to: navigation, search
(New page: The '''PHOENICS''' code is fully self-contained, structured-grid (or body-fitted-coordinates) code with grid generation, solution, and post processing done in a 3-D virtual reality interfa...)
 
(2 intermediate revisions not shown)
Line 1: Line 1:
-
The '''PHOENICS''' code is fully self-contained, structured-grid (or body-fitted-coordinates) code with grid generation, solution, and post processing done in a 3-D virtual reality interface - but one can also learn the Phoenics Input Language (PIL), from which the product first evolved , in order to provide input (and more precise control) via a text editor.  It is written in Fortran, is relatively inexpensive unless (one buys the source code for recompilation), and has a flexible english-language interface for introducing source and sink terms and arbitrary equations (In-Form).  There are many examples in an online library, as well as an existing library of commonly-used shapes (including vehicles and human forms) and a list of materials and gas laws.
+
 
 +
'''Description'''
 +
 
 +
PHOENICS is a general-purpose commercial CFD code which is applicable to steady or unsteady, one- , two- or three-dimensional turbulent or laminar, multi-phase, compressible or incompressible flows using Cartesian, cylindrical-polar or curvilinear coordinates. The code also has a spatial marching integration option to handle parabolic and hyperbolic flows, as well as transonic free jets in the absence of recirculation zones.
 +
 
 +
The numerical procedure is of the finite-volume type in which the original partial differential equations are converted into algebraic finite-volume equations with the aid of discretisation assumptions for the transient, convection, diffusion and source terms. For this purpose, the solution domain is subdivided into a number of control volumes on a mono-block mesh using a conventional staggered-grid approach. All field variables except velocities are stored at the grid nodes, while the velocities themselves are stored at staggered cell-face locations which lie between the nodes.
 +
 
 +
For curvilinear coordinates, the default option is to solve the momentum equations in terms of the covariant projections of the velocity vector into the local grid directions on a structured, mono-block, staggered mesh. An alternative exists to employ the GCV method for curvilinear coordinates, whereby cell-centred Cartesian velocities or covariant velocity projections are solved on a structured mono-block or multi-block mesh. The link description for the latter can handle arbitrary block rotations, and therefore can accommodate an unstructured multi-block grid made from relatively simple, structured blocks.
 +
 
 +
For complex geometries, PHOENICS by default actually uses a Cartesian cut-cell method named PARSOL which provides an automatic, efficient, and flexible alternative to traditional boundary-fitted grid methods using curvilinear coordinates. The Cartesian cut-cell approach uses a background Cartesian or cylindrical-polar grid for the majority of the flow domain with special treatments being applied to cells which are cut by solid bodies, thus retaining a boundary-conforming grid. Specifically, the method computes the fractional areas and volumes, and employs a collection of special algorithms for computing interfacial areas, evaluating wall shear stresses, and for computing advection and diffusion near solid boundaries, etc.
 +
 
 +
The finite-volume equations for each variable are derived by integrating the partial differential equations over each control volume. Fully implicit backward differencing is employed for the transient terms, and central differencing is used for the diffusion terms. The convection terms are discretised using hybrid differencing in which the convective terms are approximated by central differences if the cell face Peclet number is less than 2 and otherwise by upwind differencing. At faces where the upwind scheme is used, physical diffusion is omitted altogether. In addition to the upwind and hybrid differencing schemes, PHOENICS is furnished with an extensive set of higher-order convection schemes, which comprise five linear schemes and twelve non-linear schemes. The linear schemes include CDS, QUICK, linear upwind and cubic upwind. The non-linear schemes employ a flux limiter to secure boundedness. These schemes include SMART, H-QUICK, UMIST, SUPERBEE, MINMOD, OSPRE, MUSCL and van-Leer harmonic.
 +
 
 +
The integration procedure results in a coupled set of algebraic finite-volume equations which express the value of a variable at a grid node in terms of the values at neighbouring grid points and the nodal value at the old time level.  For unsteady flows, PHOENICS by default solves each of these equations by an implicit method, but the option exists to revert to an explicit method which is stable only when the Courant number is less than or equal to unity.  The explicit method uses old-time neighbour values, whereas the implicit method uses values at the new time level. Although implicit methods allow a much larger Courant number than the explicit methods, it is not unconditionally stable since the non-linearities in the equations often limit numerical stability.
 +
 
 +
The finite-volume equations are solved iteratively using the SIMPLEST and IPSA algorithms of Spalding, which are embodied in PHOENICS for the solution of single-phase and two-phase flows, respectively. These algorithms are segregated solution methods which employ pressure-velocity coupling to enforce mass conservation by solving a pressure-correction equation and making corrections to the pressure and velocity fields. Multi-phase flows are accommodated using either an Eulerian-Lagrangian method using particle tracking, or an algebraic-slip model. The latter solves mixture continuity and momentum equations, and a volume-fraction equation is solved for each dispersed phase. Algebraic relationships are used for slip velocities relative to the mixture.
 +
 
 +
The default calculation procedure is organised in a slab-by-slab manner in which all dependent variables are solved in turn at the current slab before attention moves to the next higher slab. The slabs are thus visited in turn, from the lowermost to the uppermost, and a complete series of slab visits is referred to as a sweep through the solution domain. For parabolic and hyperbolic calculations, only one such sweep is required, with many iteration cycles at each slab for parabolic cases, and no outflow boundary condition is required because this is an outcome of the solution. For elliptic calculations, many such sweeps are conducted until convergence is attained at the current time level; in addition, the pressure-correction equation is solved in a simultaneous whole-field manner at the end of each sweep. Thereafter the solution proceeds to the next time level where the iterative process is repeated. The option exists to solve each finite-volume equation in a whole-field manner, and this is actually the default when using the automatic convergence control. The default linear equation solver for each finite-volume equation is a modified form of Stone's strongly implicit solver, but the option exists to use a Conjugate Gradient Residuals solver for each equation.
 +
 
 +
The GCV method solves the system of algebraic finite-volume equations by using a conjugate-residual linear solver with LU preconditioning, and it uses a segregated pressure-based solver strategy with an additional correction of the cell-centred momentum velocities. This provides faster convergence than conventional one-step face-velocity corrections. 
 +
 
 +
The numerical solution procedure requires appropriate relaxation of the flow variables in order to procure convergence. Two types of relaxation are employed, namely inertial and linear. The former is normally applied to the velocity variables, whereas the latter is applied to all other flow variables, as and when necessary.
 +
 
 +
The PHOENICS Parallel solver subdivides the solution domain into sub-domains (spatial domain decomposition) and assigns each sub-domain to one processor on a multi-core computer. Each sub-domain has storage overlap ("halo" cells) for data exchange between the various sub-domains. The CFD code then runs simultaneously on all the processors, on its own set of data, and data is exchanged between the various sub-domains ( via the "halo" cells ) using MPI (message-passing interface). A point solver is used for whole-field solution of each of the finite-volume equations.
 +
 
 +
The convergence requirement is that for each set of finite-volume equations the sum of the absolute residual sources over the whole solution domain is less than one percent of references quantities based on the total inflow of the variable in question. An additional requirement is that the values of monitored dependent variables at a selected location do not change by more than 0.1 percent between successive iteration cycles. It is also possible to monitor the absolute values of the largest corrections to each variable anywhere in the domain. Once the largest correction falls to zero, or at least a negligible fraction of the value being corrected, then it can be assumed that convergence has been achieved, even if the sum of the residuals has not fallen below the cut-off.
 +
 
 +
'''2. History'''
 +
 
 +
PHOENICS is a general-purpose Computational Fluid Dynamics code. It was launched commercially in 1981 by Concentration Heat and Momentum Limited in Wimbledon, London, UK as the world's first general-purpose CFD code. The name PHOENICS itself is an acronym for Parabolic, Hyperbolic Or Elliptic Numerical Integration Code Series.
 +
 
 +
 
 +
'''Earlier Wiki contribution'''
 +
 
 +
The '''PHOENICS''' code is fully self-contained, structured-grid (or body-fitted-coordinates) code with grid generation, solution, and post processing done in a 3-D virtual reality interface - but one can also learn the Phoenics Input Language (PIL), from which the product first evolved, in order to provide input (and more precise control) via a text editor.  It is written in Fortran, is relatively inexpensive unless (one buys the source code for recompilation), and has a flexible english-language interface for introducing source and sink terms and arbitrary equations (In-Form).  There are many examples in an online library, as well as an existing library of commonly-used shapes (including vehicles and human forms) and a list of materials and gas laws.
   
   
-
The code originated and is maintained by Prof. Spalding and his team at CHAM in the UK, and uses their SIMPLEST algorithm as its primary solver but also has others.  There is an interface to the CHEMKIN fully implicit solver for gas phase chemical reactions.  There are many different convection discretization schemes available, many turbulence models (including Large Eddy Simulation), but it only has first-order time discretization for time-dependent problems.  It can solve deformation equations in solids simultaneously with flow equations for structural load problems - apparently unique to PHOENICS.  Another unique algorithm in PHOENICS is it's Multi-Fluid Model (MFM) which can be used to ''derive'' Probability Density Functions for turbulent flows - although only fairly basic validations of this approach have been done to date.  It has several dedicated program modules for determining heat flows in HVAC systems, computer (laptop) cooling systems, combustors and smelters, and others, as well as some unique, fast algorithms for calculating radiative transfer and inter-wall distances.  A newer module allows moving coordinates and moving objects.
+
The code originated and is maintained by Prof. Spalding and his team at CHAM in the UK, and uses their SIMPLEST algorithm as its primary solver but also has a few others.  There is an interface to the public-domain, industry standard CHEMKIN-II fully implicit solver for gas phase chemical reactions, widely used in the combustion research community.  There are many different convection discretization schemes available, many turbulence models (single and dual equation, Large Eddy Simulation, etc.), but it only has first-order time discretization for time-dependent problems.  It can solve deformation equations in solids simultaneously with flow equations allowing a single, master solution of structural load problems - a capability apparently unique to PHOENICS.  Another unique algorithm in PHOENICS is it's Multi-Fluid Model (MFM) which can be used to ''derive'' Probability Density Functions for turbulent flow problems (although only fairly basic validations of this approach have been done to date).  It has several dedicated program modules for modeling HVAC systems, computer (laptop) cooling systems, combustors and smelters, and others, as well as some unique, fast algorithms for calculating radiative transfer and inter-wall distances.  A newer module allows moving coordinates and moving objects.  It also has at least three algorithms for multiphase flow and particle tracking.
 +
 
 +
Of interest for the Aerospace community: flow-shock modeling can be done but there has been some discussion on the WEB that there appears to be a weakness in the SIMPLEST algorithm which limits practical utility of the code to about MACH 4 ''(this may not actually be true)''.  Shocks can be captured using higher order convection schemes.

Latest revision as of 11:18, 5 July 2013

Description

PHOENICS is a general-purpose commercial CFD code which is applicable to steady or unsteady, one- , two- or three-dimensional turbulent or laminar, multi-phase, compressible or incompressible flows using Cartesian, cylindrical-polar or curvilinear coordinates. The code also has a spatial marching integration option to handle parabolic and hyperbolic flows, as well as transonic free jets in the absence of recirculation zones.

The numerical procedure is of the finite-volume type in which the original partial differential equations are converted into algebraic finite-volume equations with the aid of discretisation assumptions for the transient, convection, diffusion and source terms. For this purpose, the solution domain is subdivided into a number of control volumes on a mono-block mesh using a conventional staggered-grid approach. All field variables except velocities are stored at the grid nodes, while the velocities themselves are stored at staggered cell-face locations which lie between the nodes.

For curvilinear coordinates, the default option is to solve the momentum equations in terms of the covariant projections of the velocity vector into the local grid directions on a structured, mono-block, staggered mesh. An alternative exists to employ the GCV method for curvilinear coordinates, whereby cell-centred Cartesian velocities or covariant velocity projections are solved on a structured mono-block or multi-block mesh. The link description for the latter can handle arbitrary block rotations, and therefore can accommodate an unstructured multi-block grid made from relatively simple, structured blocks.

For complex geometries, PHOENICS by default actually uses a Cartesian cut-cell method named PARSOL which provides an automatic, efficient, and flexible alternative to traditional boundary-fitted grid methods using curvilinear coordinates. The Cartesian cut-cell approach uses a background Cartesian or cylindrical-polar grid for the majority of the flow domain with special treatments being applied to cells which are cut by solid bodies, thus retaining a boundary-conforming grid. Specifically, the method computes the fractional areas and volumes, and employs a collection of special algorithms for computing interfacial areas, evaluating wall shear stresses, and for computing advection and diffusion near solid boundaries, etc.

The finite-volume equations for each variable are derived by integrating the partial differential equations over each control volume. Fully implicit backward differencing is employed for the transient terms, and central differencing is used for the diffusion terms. The convection terms are discretised using hybrid differencing in which the convective terms are approximated by central differences if the cell face Peclet number is less than 2 and otherwise by upwind differencing. At faces where the upwind scheme is used, physical diffusion is omitted altogether. In addition to the upwind and hybrid differencing schemes, PHOENICS is furnished with an extensive set of higher-order convection schemes, which comprise five linear schemes and twelve non-linear schemes. The linear schemes include CDS, QUICK, linear upwind and cubic upwind. The non-linear schemes employ a flux limiter to secure boundedness. These schemes include SMART, H-QUICK, UMIST, SUPERBEE, MINMOD, OSPRE, MUSCL and van-Leer harmonic.

The integration procedure results in a coupled set of algebraic finite-volume equations which express the value of a variable at a grid node in terms of the values at neighbouring grid points and the nodal value at the old time level. For unsteady flows, PHOENICS by default solves each of these equations by an implicit method, but the option exists to revert to an explicit method which is stable only when the Courant number is less than or equal to unity. The explicit method uses old-time neighbour values, whereas the implicit method uses values at the new time level. Although implicit methods allow a much larger Courant number than the explicit methods, it is not unconditionally stable since the non-linearities in the equations often limit numerical stability.

The finite-volume equations are solved iteratively using the SIMPLEST and IPSA algorithms of Spalding, which are embodied in PHOENICS for the solution of single-phase and two-phase flows, respectively. These algorithms are segregated solution methods which employ pressure-velocity coupling to enforce mass conservation by solving a pressure-correction equation and making corrections to the pressure and velocity fields. Multi-phase flows are accommodated using either an Eulerian-Lagrangian method using particle tracking, or an algebraic-slip model. The latter solves mixture continuity and momentum equations, and a volume-fraction equation is solved for each dispersed phase. Algebraic relationships are used for slip velocities relative to the mixture.

The default calculation procedure is organised in a slab-by-slab manner in which all dependent variables are solved in turn at the current slab before attention moves to the next higher slab. The slabs are thus visited in turn, from the lowermost to the uppermost, and a complete series of slab visits is referred to as a sweep through the solution domain. For parabolic and hyperbolic calculations, only one such sweep is required, with many iteration cycles at each slab for parabolic cases, and no outflow boundary condition is required because this is an outcome of the solution. For elliptic calculations, many such sweeps are conducted until convergence is attained at the current time level; in addition, the pressure-correction equation is solved in a simultaneous whole-field manner at the end of each sweep. Thereafter the solution proceeds to the next time level where the iterative process is repeated. The option exists to solve each finite-volume equation in a whole-field manner, and this is actually the default when using the automatic convergence control. The default linear equation solver for each finite-volume equation is a modified form of Stone's strongly implicit solver, but the option exists to use a Conjugate Gradient Residuals solver for each equation.

The GCV method solves the system of algebraic finite-volume equations by using a conjugate-residual linear solver with LU preconditioning, and it uses a segregated pressure-based solver strategy with an additional correction of the cell-centred momentum velocities. This provides faster convergence than conventional one-step face-velocity corrections.

The numerical solution procedure requires appropriate relaxation of the flow variables in order to procure convergence. Two types of relaxation are employed, namely inertial and linear. The former is normally applied to the velocity variables, whereas the latter is applied to all other flow variables, as and when necessary.

The PHOENICS Parallel solver subdivides the solution domain into sub-domains (spatial domain decomposition) and assigns each sub-domain to one processor on a multi-core computer. Each sub-domain has storage overlap ("halo" cells) for data exchange between the various sub-domains. The CFD code then runs simultaneously on all the processors, on its own set of data, and data is exchanged between the various sub-domains ( via the "halo" cells ) using MPI (message-passing interface). A point solver is used for whole-field solution of each of the finite-volume equations.

The convergence requirement is that for each set of finite-volume equations the sum of the absolute residual sources over the whole solution domain is less than one percent of references quantities based on the total inflow of the variable in question. An additional requirement is that the values of monitored dependent variables at a selected location do not change by more than 0.1 percent between successive iteration cycles. It is also possible to monitor the absolute values of the largest corrections to each variable anywhere in the domain. Once the largest correction falls to zero, or at least a negligible fraction of the value being corrected, then it can be assumed that convergence has been achieved, even if the sum of the residuals has not fallen below the cut-off.

2. History

PHOENICS is a general-purpose Computational Fluid Dynamics code. It was launched commercially in 1981 by Concentration Heat and Momentum Limited in Wimbledon, London, UK as the world's first general-purpose CFD code. The name PHOENICS itself is an acronym for Parabolic, Hyperbolic Or Elliptic Numerical Integration Code Series.


Earlier Wiki contribution

The PHOENICS code is fully self-contained, structured-grid (or body-fitted-coordinates) code with grid generation, solution, and post processing done in a 3-D virtual reality interface - but one can also learn the Phoenics Input Language (PIL), from which the product first evolved, in order to provide input (and more precise control) via a text editor. It is written in Fortran, is relatively inexpensive unless (one buys the source code for recompilation), and has a flexible english-language interface for introducing source and sink terms and arbitrary equations (In-Form). There are many examples in an online library, as well as an existing library of commonly-used shapes (including vehicles and human forms) and a list of materials and gas laws.

The code originated and is maintained by Prof. Spalding and his team at CHAM in the UK, and uses their SIMPLEST algorithm as its primary solver but also has a few others. There is an interface to the public-domain, industry standard CHEMKIN-II fully implicit solver for gas phase chemical reactions, widely used in the combustion research community. There are many different convection discretization schemes available, many turbulence models (single and dual equation, Large Eddy Simulation, etc.), but it only has first-order time discretization for time-dependent problems. It can solve deformation equations in solids simultaneously with flow equations allowing a single, master solution of structural load problems - a capability apparently unique to PHOENICS. Another unique algorithm in PHOENICS is it's Multi-Fluid Model (MFM) which can be used to derive Probability Density Functions for turbulent flow problems (although only fairly basic validations of this approach have been done to date). It has several dedicated program modules for modeling HVAC systems, computer (laptop) cooling systems, combustors and smelters, and others, as well as some unique, fast algorithms for calculating radiative transfer and inter-wall distances. A newer module allows moving coordinates and moving objects. It also has at least three algorithms for multiphase flow and particle tracking.

Of interest for the Aerospace community: flow-shock modeling can be done but there has been some discussion on the WEB that there appears to be a weakness in the SIMPLEST algorithm which limits practical utility of the code to about MACH 4 (this may not actually be true). Shocks can be captured using higher order convection schemes.

My wiki