Home

elsA Design and Implementation Tutorial

Contents

1. loop o i in J in k n i in j in k 1 n Ler Lex cer Ler ESE Ler n cells face face face face face face left down back right up front As a consequence of this choice we have exactly the same number of cells nodes and interface in direction I J or K so the total number of interfaces is three time the number of cells inline E_Int ONERA DSNA Design and Implementation Tutorial GeoConnect getNbCell const return _im 1 GHOST_I1 _jm 1 GHOST_J1 _km 1 GHOST_K1 inline E_Int GeoConnect getNbInti const return getNbCell elsA GHOST_I2 GHOST_J2 GHOST_K2 7 2 Address and increment methods The expression of the address methods is directly issued from the following points imin jmin kmin by convention data are always stored first considering the in the case of interfaces we first consider the GHOST_I1 1 imax im 1 GHOST_J1 1 jmax jm 1 GHOST_K1 1 kmax km 1 mon 1 myn the first real non ghost cell corresponds to 1 1 1 GHOST_I2 GHOST_J2 interfaces for GHOST_K2 direction then the mn for i 5 k and finally the k interfaces for i j k mon J then for the IMIN left I interface of cell 1 1 1 corrsponds also to 1 1 1
2. This automatically gives important information upon the programmer s intent and so facilitates code understand ing and maintenance These containers must contain homogeneous collection of floats integers or booleans To fulfill this requirement e sA provides different versions of F1dArray and F1dFiel d the last letter of the class name identifies the contained element type F stands for Float e I stands for Integer B stands for Boolean Note F1dFie1dB is not implemented 6 2 Public interface Externally for application programmers fields are viewed as two dimensional structures e the first dimension index goes from 0 to __size 1 e the second dimension index goes from 1 to _nf 1d if the second dimension is 1 it can be omitted Note The conventions used for first and second dimensions are inconsistent 0 instead of 1 for first index This comes from historical reasons and may be changed in future releases just modify the constant NUMFIELDO defined in FldArray h and recompile The field interface provides all the methods required to do numerical computations ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 27 75 e construction e initialization e copy of an existing field into a new one addition subtraction multiplication See FldFieldF doxygen documentation for additional details 6 2 1 Examples of
3. dataBnd desBnd getF KEY_PRESSURE bnd new BndSubPres grid wind dataBnd eos veal Macro register creation function E_FactBndRegister BndSubPres where to ease notation we have used the macro define E_FactBndRegister className const E_Bool registered className FactBase instance gt registerBnd TbxString className amp create className 12 1 2 5 Putting everything together It remains only to specify how user input is translated into type identifier e The simplest solution would be to ask the user to give the class name directly e Presently we use a more complex solution using an indirection implemented with Python dictionary objects For example ONERA elsA Ref ELSA MDEV 06001 ee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 67 75 Python API DesModel my_model my_model my_mode set turb SPALART Python User my_model model my_model turb spalart Python dictionary file EpKernelClassName py dict_tur BALDWIN TurBlx MICHEL TurAlgMichel SPALART i TUTSA Another example concerning the boundary conditions Python dictionary file EpKernelClassName py dict_bnd FxcCenter inactive BndSupOut FxcCenter outpres BndSubPres s Note User interface manage Tur hierarchy in a different way than
4. corresponding to the treatment of Step 1 These two methods define the polymorphic behaviour of the abstract class BndPhys BndPhys proposes a default implementation for the second method which consists of a simple 0 order extrapolation of wb1 in the ghost layer cells All the classes deriving from BndPhys implement the first method and if necessary the second one Finally we obtain the UML class diagram which presents the traditional tree hierarchical structure organization ONERA elsA Ref ELSA MDEV 06001 RER meee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 53 75 Hall PnichomCimo Enel ni n Bibbia nt BndSubby Hufiell His Biim A Hair Bristol BuiSOu BnisigO hill hiTmgr dl Shen Bl Talal Tues Bled Bully APs MiS Tale Tat Talend Halle Bnd module contains a fairly important number of classes each of one dedicated to a specific type of boundary condition Let us describe for example BndSubP res class which deals with a pressure downstream subsonic boundary This type of boundary condition is associated with the resolution of a system of equations composed of four characteristic relations and of imposed pressure condition Therefore the BndSubPres class includes a local implementati
5. Implicit Residual Smoothing IRS is used in association with centered Jameson s scheme with Runge Kutta 4 step algorithm e LU or LUSSOR are used with both centered and upwind schemes with backward Euler time integration 2 2 3 Calculation strategy The system of mean NS equations mean flow and the system of transport equations turbulent quantities are solved using a decoupled algorithm One carries out the following stages Before entering time loop 1 initialize the turbulent eddy viscosity Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 IDA A Date Jan 10 2006 Page 12 75 Design and Implementation Tutorial DSNA then at each iteration 1 integrate with turbulent eddy viscosity frozen the mean field system using either Jameson s centered scheme with artificial viscosity or an upwind scheme associated with a Runge Kutta algorithm or backward Euler 2 integrate with mean field frozen the turbulent system using the upstream space approx imation according to Roe with Harten entropic correction associated with Runge Kutta or backward Euler algorithm 3 update the turbulent eddy viscosity 2 2 4 Turbulence modeling 2 2 4 1 Modeling assumptions In e sA most turbulent models rely on the Boussinesq hypothesis their common feature is the use of the eddy viscosity which can be calculated either by algebraic turbulence models or using transport equations EARSM models are also available t
6. e Each subclass inherits attributes state and methods behaviour from the superclass Subclasses can add their own data and methods to data and methods inherited from the superclass Subclasses can override that is specialize virtual inherited methods by providing specialized implementa tions for those methods ONERA elsA Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 17 75 When implementing a new specialized subclass developers can reuse the code the implementation defined in superclasses However inheritance is really much more powerful than code factoring which is of course available in any decent language C and Fortran for exemple With the help of inheritance developers can reuse the interface Inheritance greatly simplifies the software extensibility and maintenance tasks The most important polymorphic hierar chies in elsA are Implicit algorithms LhsBase and derived classes Boundary conditions BndBase and derived classes see Bnd component Turbulence models TurBase and derived classes see Tur component Operators fluxes and source terms OperBase and derived classes see Oper component Basically developing a new implicit algorithm a new boundary condition or a new turbulence model amounts to very similar tasks e Starting from the base class interface public and protected the developer must adapt it to his
7. _mutRatioMx E_Float prandtITurb E Float coraputeNearWall lt lt destroy gt gt TuBase TurTransp compute Wall compute Wall _useGradInt E_Bool compMut _coeffMutInit E_Float lt ccomment gt DS compGenTransi lt lt destroya gt Only the virtual isFieldUsed TuTransp methods are computeField compProdK displayed prepareSou isFieldUsed prepareFxd coraputeField setCellN prepareSou isASMO prepareFxd comp MutinModel getSigma lapplpLimitor Q comp DifFluxDens Coeft jgetNbEgtur compdpecTurh comp Tur WallLaw comp Source imiTranspEgQ TurKEps TurKL TurMKFLC2 TurSi TurWL94 _ct2 E Float _e2 E Float _inif2landf22 E Bool _Ct4 E Float _zhengLimitor E_Bool ctl E Float bi E Float JcompTurWalllaw _Ct3 E_ Float Sr E_Float _Ceps2 E Float _sigmal E_ Float iniTranspEq _Ct2 E Float betas E_Float _Cepsl E Float _sigmaK E_Float compMutmodel _Cti E Float _betal E_Float _sigmaEps E Float _kappa E_Float compSource _Cvl E Float _sigmael E Float _sigmaK E_Float compTurWallLaw isFieldUsed _Cw3 E Float _sigmal E Float _modelVersion ModelVersion iniTranspEq compSpecTurh Cw2 E Float compSpecTurb Cru E Float compMutInModel prepareSouf kappa E Float lt lt destroy gt gt kappa E Float compSpecTurb prepareFxd sigma E_ Float TurWL940 corapTurWallLaw compSource computeField _Cb2 E Float iniTranspEg iniTranspEq
8. because they provide e memory usage check control in DEBUG mode we can check that access to container elements is valid e full control over data initialization programmers can choose to initialize newly allocated memory with some bad value or better with Nan Not a number this will insure that access to non initialized memory value can be trapped Subscript index checking and memory initialization control are very helpful to debug newly written code 6 3 Passing field data to Fortran In elsA it is frequenltly necessary to communicate with Fortran 77 subroutine Fortran 77 only knows scalars and arrays and subroutine arguments are always passed by address This means that we must in some way give the address of the piece of memory which is dynamically allocated by a F1dField field to this subroutine to know more about that just look at the next section FldArray internal structure 6 3 1 FldArray internal structure Internally a F1dArray object stores its elements in a contiguous piece of memory This memory is dynamically al located One can see F1IdArray as a convenient wrapper encapsulating raw C pointer managed memory Attribute _data in class FldArray points to this memory This one dimensional arrangement exactly matches the traditional Fortran or C arrangement However it remains to choose a specific ordering between the two directions Presently in elsA the first index increases first this choice corres
9. x SST correction x different treatments of the wall boundary condition wall roughness or 1 y 2 extrap olation BSL k omega Menter model with SST correction option low Reynolds k epsilon Jones and Laudner model high Reynolds k epsilon model with SST correction option e four transport equations multi scale energy spectral flux model 2 2 5 Transition For all the available turbulence models transition effects can be included Transition can be imposed or calculated in the latter case the transition criterion which can be local or non local 2 2 6 Techniques of convergence acceleration e Multigrid technique V cycle or W cycle cell to cell and node to cell prolongation presently multigrid technique can only be used for the resolution of the mean flow e Dual Time Stepping DTS e Low speed preconditionning 2 2 7 Rotation frame and ALE technique In some problems a formulation of the conservative laws in the entrained reference frame can be judi cious existence of a permanent flow in this reference frame In elsA helicopter and turbomachinery applications are treated in the relative entrained frame e in an absolute velocity formulation for the helicopter applications e ina relative velocity formulation for the turbomachinery applications 2 2 8 Types of join boundary In elsA the available types of join boundaries are e coincident adjacent and partially coincident adjacent boundaries e a
10. current description of the problem e EosIdealGas _eos current equation of state e GeoGridBasex _grid current working computational grid An operator has to work on different contexts different grids thermodynamic model so an Oper object cannot be fully configured at construction time Instead when context changes it must be re initialized in such a way that it can work correctly This is precisely the job of OperBase prepare whose signature is virtual void prepare const EosSysEq amp EosElemSysType EosIdealGas eos const GeoGridBase grid The method implementation is very simple it reduces to proper re settings of the class pointer attributes We must clearly distinguish two different operator subtypes both inheriting from OperBase class e OperTerm is responsible for the computation of one right hand side term e Utility operators are used to perform auxiliary computations they are usually called by OperTerm objects Up to now only two gradient operators have been implemented OperGrad and OperGradInt ONERA elsA Ref ELSA MDEV 06001 ee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 45 75 9 1 2 OperGrad class OperGrad and OperGradInt inherit from OperBase OperGrad class provides with the implementation of the computation of gradients on cell centers whereas OperGradInt provides with the implementation of the computation
11. each implicit class has to build and invert the matrix resulting from a specific linearization of the system of equations e Tmo time integration module manages the main iterative pseudo time loop It is probably the most complex part of the kernel since many algorithms have to be taken into account multi block multigrid HMR mesh motion deformation 5 2 6 Factory layer elsA top layer This layer is responsible of the dynamic creation of all kernel objects the Fact module implements several object factories to build object instances from user input data coming from the Python interface Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 RTE Date Jan 10 2006 Page 26 75 Design and Implementation Tutorial DSNA 6 FLD COMPONENT 6 1 Basic numerical containers Fields are the most basic objects manipulated by e sA They are used as containers for the numerical values real integer boolean arising in CFD simulations It is useful to distinguish two general types e FldArray stores numeric values without any location information e FldField stores numeric values defined on a grid In that case it can be also very useful to distinguish between values defined at grid nodes F1dNode values defined at centers of grid cells F1dCe11 values defined at centers of grid interfaces FldInt So we use typedef to express the specificity of each entity for example typedef FldFieldF FldCellF
12. getSigmal computeField _Cb1 E Float compute Wall corplMutInModel isFieldUsed getSigmat comp TurWallLawt corpMutInModel compSpecT urb prepareSouf lt lt destroy gt gt iniTranspEq compSource compSource computeField TuwrMKFLC2 compMutInModel isFieldUsed getSigma lt lt destroy gt gt getNbEqturt compSpecTurb cormputeField isFieldUsed TuKL compSpecTurbOld getNbEgtur prepareSou getNbEqtur compSource getSigma prepareFxd coraputeField FusARE lt lt destroy gt gt c E Float TwKEps _cr2 E Float grtNbEgturt Cort E Float compSpecT wb compSource prepareSou prepareFxd getModConst lt lt destroy gt TwSARC lt create gt TWSARCO 39 75 Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 40 75 elsA Design and Implementation Tutorial TurBase 1 _elemSysOper EosElemSysType_X Tur Transp _mutRatioMx E_Float prandiiTub E Flost _useGradInt E_Bool computeNeaWall _coeffMutInit E_Float lt lt destroy gt gt lt lt destroy gt gt TurBase TurTransp compute Wall compProdK compute Wall isFieldUsed compMut computeField compGenTransi prepareSout isFieldUsed prepare Fxd computeField jgetSigma prepareSou comp DifFluxDens Coefi prepareFxd compSpecTurb setCeUN compSource isASM comp MutinModel apply Limitor Q getNbEgtur O TurKOavtacl comp Tur
13. 0 SAA Date Jan 10 2006 Page 44 75 Design and Implementation Tutorial DSNA 9 OPER COMPONENT Operator classes are dedicated to the computation of space discretization terms Every operator has to compute a Fld FieldF object defined upon a specific geometric entity cell or interface This chapter is dedicated to all operators in elsA e Oper Abstract classes e Fxc Convective fluxes centered scheme upwind schemes and artificial dissipation e Fxd Diffusive fluxes laminar mean flow or turbulent e Sou Source terms turbulence closure relations moving frame dual time stepping method 9 1 Oper Module 9 1 1 OperBase abstract class The general operator mechanism is defined inside OperBase class Important attributes of OperBase are e _geoEntity type of geometric entity where the computation has to be carried out e _borderDepth width of the border region The numerical treatment of an operator is performed on all cells or interfaces using the same numerical scheme on all geometric entities The interior region of the operator is the set of the geometric entities where this current entity treatment is directly correct The border region is the set of geometric entities where a numerical adaptation correction has to be made because of the boundary neighborhood e _elemSysOper identifier of the system of equations The other attributes of this abstract class are pointers e EosSysEq _sysEq
14. D Be Boe bee SEM 4 Se A ESE E EEE GH 21 4 1 9 Post processing 22254 EER SR SEES ASS ask Ta das 21 22 5 1 Classification and Design organization 22 5 1 1 Naming convention aa ca oe Due GEOR DURS NES we ER HE ES 22 Se seer oh tle Ben ae en do don SOBs amp Bake g 22 A ATEN 24 pal dra A AAA SR RS 24 he dra dida duda Sida dida a Sake do de ds 24 books A de D de 6 Bade ge Bade eked ag 24 See devia etre a Pond tena teste Ss tea ete a E 25 5 2 6 Factory layer elsA top layer 25 6 Fld component 26 6 1 Basic numerical containers oa aaa ee 26 6 2 Pilg tet tae un nth Ge Ba ye SRO EO Ra ls Bo Ge dus 26 6 2 1 Examples of Fld client code 21 ee e 28 nt ee No 28 6 3 1 FldArray internal structurel 28 bie Bulg oe Bute dd a Ss ae 9 es ee oe 29 6 3 3 Remark on Fortran convention 30 ONERA le Ref ELSA MDEV 06001 RE TT cute Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page Sige 7 Geo component 31 7 1 Ghost geometric entities 42 ss ue Elus LES RS pa eee ade 31 7 1 1 Ghost cell numbering 4 4 aoe 8000 pue pus du een es ess es 31 7 1 2 Ghost interface numbering 31 7 1 3 Ghost node mesh points numbering 31 pik ae ae Buk Oe oe ae ee Be Yas oe ae 32 7 1 5 Ident
15. E virtual compMutinModel 0 compMu a _tur gt compMut TurKL E eres protected compMutinModel As a consequence adding a new turbulence model will not modify the code of the client class 8 4 How to introduce a new turbulent model 8 4 1 Use of inheritance Object Oriented technology greatly facilitates the introduction of a new turbulence model The developer does not have to have full knowledge of the whole elsA kernel Instead he can focus on a small number of well defined tasks e introduce a new class in the turbulence hierarchy deriving from a base class deriving from TurTransp if it is a new transport equation model deriving from TurAlg if it is an algebraic model or even deriving specializing from from an existing leaf concrete class let s say TurKL to test some specialized TurKL variant e implement a small number of virtual methods e additionaly to ease implementation it may be useful to introduce new private methods and or attributes ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 43 75 Hence OO programming provides a simple framework allowing the programmer to work in a faster and safer way It remains to be seen how turbulent objects are created This is fully discussed in section Factory component Ref ELSA MDEV 06001 elsA ONERA Version Edition 1
16. compute the cell flux balance values 11 1 12 im 1 GHOST_I1 GHOST_I2 13 12 3m 1 GHOST_J1 GHOST_J2 DO n Intl intg intK fluxBal n nfld END DO n0Cell nfCell n ny nCell n 2 nCell lux intI lux intI lux intJ lux intyJ lux intK intK Fh Fh Fh Fh Ph Ph lux inccell inccell inccell Hh o mn ao Hh aa Nee A RS NE A 0 0 1 r r im jm km im jm km im jm km ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 37 75 8 TUR COMPONENT 8 1 Definition of the public interface This section details the design of the turbulence models based on the Boussinesq hypothesis The most important design activity is to identify the classes together with their public interface The UML class diagram is a very useful tool to present e classes e relations between classes e interfaces The first analysis stage is to identify what actions turbulence models are responsible for The aim of turbulence models is to compute e turbulent eddy viscosity e total stress tensor viscosity tensor Reynolds tensor used in momentum and energy equations e possibly other quantities needed for the integration of transport equations source terms coefficients for the computation of the density of the diffusive turbulent fluxes Moreover the
17. createTmoFBEuler and createTmoRKutta whose main task is to call the corresponding constructor Instead of calling directly class constructors objects are created using these creation functions Typically the creation functions look like Derived createXXX return new Derived Note This code assumes that covariant type return is supported by the compiler We can encapsulate this ifdef E_NO_COVARIANT_RETURN Base createXXX else Derived createXXX endif return new Derived ONERA elsA Ref ELSA MDEV 06001 ee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 63 75 12 1 1 5 Refinement of the Factory design The previous example works perfectly well and is probably well adapted when the class hierarchy does not change a lot However the design has some flaws e It performs a switch based on a type tag with the associated drawbacks to add a new class we still have to modify code here implementation of method createTmoStage not just add new code e It introduces magic values directly inside compiled code here two strings E_BACKWARDEULER and E_RK4 The following sections discuss several design improvements 12 1 2 Factory design To remove these disadvantages we have implemented a more advanced design for the Bnd Oper and Tur hierarchy The basic idea is to use pointers to functio
18. design solution must allow association of transition with any turbulence model More precisely depending on algebraic model or transport equation model we have to distinguish which computations have to be made and how they can be made e for algebraic models the computation of the eddy viscosity only requires the knowledge of the conservative vari ables and the distance to wall e for turbulence models using transport equations a system of equations must be integrated Source terms additional coefficients needed to compute the diffusive fluxes and also eddy viscosity have to be computed This analysis shows that the public methods of the turbulence component interface Object Oriented Programming Concepts are 1 compute the eddy viscosity 2 compute the total stress tensor 3 apply transition Methods 2 and 3 can be defined in the same way whatever turbulence model conversely it is clear that the eddy viscosity implementation depends on the model 8 2 Class model Finally we obtain the following UML class diagram which presents a tree hierarchical structure organization e TurBase is the base abstract class its interface declares the pure virtual method compMut InModel Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page elsA 38 75 Design and Implementation Tutorial the concrete non virtual method compMut the concrete method compDiffFluxDens_gradCen the
19. elsA multiblock capability each processor is responsible for the computation of a subset of the blocks belonging to the configuration elsA uses the SPMD Single Program Multiple Data paradigm e each executable runs exactly the same program reading the same Python scripting file Python interpreter is embedded inside each parallel executable each executable is responsible for local file pre and post processing for example if block 3 and 5 are allocated to processor 2 processor 2 is responsible for reading mesh data files corresponding to blocks 3 and 5 This should avoid bottleneck problems arising from centralized I O treatment for example through rank 0 processor in massively parallel computations The mapping between blocks and processors can be done either manually or with the Split module To achieve acceptable load balancing splitting the initial configuration in a larger number of blocks may be necessary This optional splitting stage can also be done through the Split module 4 1 5 Multidisciplinary Coupling Several coupling strategies can be used to couple elsA with other computational software Let us give several examples External coupling basically through file exchange with e SA used in black box in an optimization chain weak coupling with the boundary layer code COULEUR weak coupling with NASTRAN static aeroelastic wing deformation computation Use of a dedicated coupler such as CALCIUM or P
20. of gradients on interface centers These operators do not own the result of their computation e They don t have more attributes than OperBase e They only compute gradients with two overloaded versions of compute whose signature are compute the gradient of the conservative variables void compute FldCellFs amp fldOut const list lt BndPhys gt amp listBnd const list lt JoinBase gt amp listJoin AuxField identOfField MISC and compute the gradient of non conservative variables virtual void compute FldCellF fldOut const list lt BndPhys gt amp listBnd const list lt JoinBase gt amp listJoin const FldCellF fldin AuxField identOfField The gradient or flux computation is performed on all cells or interfaces using the same numerical scheme in the interior and the border region The standard formula may give wrong results or even produce arithmetic exception for the border computation So operator objects must collaborate with boundary objects This collaboration can take two different forms called Strategy 1 and Strategy 2 see also 10 1p e Stategy 1 computation in two stages Gradient or flux computation is performed on all cells or interfaces includ ing those from the border region Then special formula are used to correct the computation on the border region taking into account the boundary treatment OperGrad uses this strategy e Strategy 2 computation in only on
21. programming enables basic numerical treatment in pre or post processing phase such as normal ization directly in the script file thus again avoiding inconsistent data arising from incompatible data coming from different independent tools Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 20 75 Design and Implementation Tutorial DSNA e Users can write specific functions or even Python classes to automate specific tasks e Users can benefit from the large number of additional scientific Python modules available 4 1 3 1 Default value mechanism Users are not required to set explicitly all the control data necessary to define completely a simulation Default parameters are provided through Python dictionary The complete set of default parameters can be customized to suit the requirements specific to a specific user community Python dictionaries can be modified at any time thus allowing dynamic site customization without code recompilation 4 1 3 2 Connecting Python and C Use of SWIG elsA can be viewed as a standard Python module elsA py it can be imported as any other Python module The task of generating the glue code necessary to acces C code from the Python interpreter is done automatically by swig a public domain tool cf p 68 4 1 4 Parallel mode elsA can run in parallel using MPI communication library e SA uses a coarse grained parallelization strategy taking advantage of
22. simple local balances One can argue that the accurate and efficient computation of fluxes and source terms is the most important part of the elsA kernel In e SA the basic unit where these balances are done is the cell which must be hexaedric in 3D The spatial discretization leads to an Ordinary Differential Equation ODE system which is solved using a pseudo unsteady time integration solver This translates into a pseudo time loop Inside this loop Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 AA Date Jan 10 2006 Page 10 75 Design and Implementation Tutorial DSNA e fluxes and source terms are computed e boundary conditions are taken into account e auxiliary quantities such as pressure viscosity are computed if required e timestep can be computed and convergence acceleration techniques may be applied In steady simulations the loop is iterated until convergence or maximum number of iterations 1s reached In unsteady simulations the computation stops when the specified final time is reached 2 1 3 Mesh and Grids Mesh generation is essentially outside the area of e SA meshes created by an external mesh genera tor are given as input e SA uses direct oriented structured meshes Meshes must be 3D structured hexaedric they can be multi zone In that case communication between them is done through join boundaries Mesh objects are not essential inside elsA instead from the mesh point coord
23. the client side the client sends a message this means asking to another object to execute one of its methods e as seen from the receiver side the receiver object executes the corresponding public method 3 3 1 1 Example of collaborative work A diffusive flux object the sender asks a k I turbulent model object the receiver to perform its method TurKL compMut Here the message corresponds to the method FxdFlux message turObject gt compMut 3 4 Class A class is a prototype that defines the attributes and the methods common to all the instances of the class The individual instances are called objects In practice in C a new class is equivalent to a new type A factory is used to manifacture object instances from the class definition Note The factory itself may be an instance usually a unique one a singleton of a specialized class 3 5 Inheritance Object Oriented programming allows classes to be defined in terms of other classes For instance class TurKL inherits from class TurBase TurKL is a subclass of the base class TurBase Similarly TurBase is the superclass base class of all the classes in charge of turbulence modeling Inside inheritance tree methods and data are inherited down through the levels e In abstract classes methods are declared but partially or not implemented Abstract classes define the poly morphic behaviour all the derived classes will provide this behaviour
24. the same numerical scheme in the interior and the border region and without any help of indirection It could seem obvious that using ghost entities should allow to take into account boundary conditions without any need of a specific computation of the border region of a flux operator However precautions have to be taken let us come back to the strategy in the case of a centered flux computation Strategy 1 In that case the strategy is made of the three following steps e Step 1 ghost cell values are filled by the boundary conditions a each boundary condition computes a state wb1 in the center of the boundary interfaces of the considered boundary b this state wb1 is extrapolated zero ordered in the cells adjacent to the boundary e Step 2 operator performs flux computation in the cells including some ghost cells During this phase fluxes on border interfaces are computed taking into account values in these ghost cells e Step 3 border fluxes are corrected for that the operator asks for the state wb1 to each boundary condition this state is then used in the border flux computation 10 1 2 Discussion The third step of this strategy could appear useless and time consuming In fact for certain flux variant skew symetric form convective term it would be possible to avoid the specific border flux computation provided that the suitable extrapolation has been made during the ghost cells filling phase In the case of ske
25. via a statistical approach turbulent fields are decomposed into a sum of mean and fluctuating fields By carrying out the averaging operation upon the NS equations one obtain the Reynolds Average Navier Stokes RANS equations Finally these equations are expressed in the general Arbitrary Lagrangian Eulerian ALE formulation so that arbitrary grid motions rigid system of body de formation can be taken into account A thorough description of the modeling and numerical methods implemented in e SA can be found in the Theoretical Manual ELSA STB 97020 The next section presents briefly the key concepts involved when performing CFD computations with elsA 2 1 Overview 2 1 1 Numerical formulation elsA solves the compressible Navier Stokes viscous and Euler viscous effects neglected equa tions in a cell centered finite volume formulation using space and time discretization In the cell centered approach unknowns are interpreted as mean cell values The central assumption in the numerical formulation used in e SA is the so called Principle of Conservation This principle requires that the equations must be written in conservative form 2 1 2 Discretization The spatial discretization algorithm governs the computation of flux and source terms Fluxes must be computed on each cell interface e Source terms if any are computed inside each computational cell After space discretization these equations are translated in
26. wishes most of the time the interface changes are very limited usually somme additional private attributes and a few private implementation methods e The developer must implement the abstract method s specific to the hierarchy compLhs for the Lhs hierarchy compBoundaryValue for the Bnd hierarchy see How to introduce a new boundary condi tion compMut InModel for the Tur hierarchy see How to introduce a new turbulent model compInterior for the OperFlux hierarchy 3 6 And see other examples http www softwaredesign com objects html Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 18 75 Design and Implementation Tutorial DSNA 4 GENERAL ARCHITECTURE 4 1 elsA library and applications elsA provides an Object Oriented OO CFD library together with a stand alone application elsA x using Python as scripting language 4 1 1 Object Oriented architecture elsA design and implementation are based both on Object Oriented technology e elsA design uses the UML Unified Modeling Language modeling approach to obtain an accurate decomposition of the complex CFD problem into static classes and to model the dynamic interacting objects instances of classes e elsA kernel is implemented in the Object Oriented language C Only the most CPU time consuming computing loops are coded in Fortran without impairing in any way the OO design 4 1 1 1 elSA extensibility elsA O
27. ALM A small number of plugging points have been identi fied and implemented inside e sA and tested Modification of the internal algorithmic structure to obtain full control and efficiency This has been realized for complex fully coupled aeroelastic simulations elsA has been coupled with the structural mechanics code HOST using a proprietary protocol based on CGNS semantics ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 21 75 4 1 6 Optimization module Opt The Opt module implements the discrete Adjoint approach It has been used inside automatic aerodynamic shape opti mization process 4 1 7 Access to CFD databases CGNS DAMAS indexdatabase CFD O database CFD To be written 4 1 8 Log file For each run e SA generates a log file standard output with some basic information e elsA version e precision single or double precision e compiler options DEBUG or optimized version e warning or errors if any Additionaly users can augment the log file by a large number of additional output in fact most post processing available in e sA can be output either to a specific file or to the log file Note In parallel mode to avoid a scrambled log file on some platforms all the computing processors write in an essen tially random order there is one log file associated with each processor with some information given only
28. Bnd or Oper hierarchies in Python API it uses integer identifiers instead of strings this non uniformity should be removed Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 68 75 Design and Implementation Tutorial DSNA 13 DESCP PACKAGE 13 1 Building Python interface with SWIG The special module Api provides all the stuff needed to build the Python interface to elsA Api is not a standard elsA module e there is no library 1ibeApi a or libeApi so e the local template Makefile Make_ob 4 mk deals with additional information to control SWIG operation e to build Python elsA interface SWIG needs special interface files with i extension located in directory Api Wrapper 13 1 1 What is SWIG The output file created by SWIG contains everything that is needed to construct an extension module for the target scripting language To build the final extension module the SWIG output file is compiled and linked with the elsA libraries to create a shared library or a statically linked executable see also ELSA MDEV 3036 13 1 2 cpp like syntax Like C SWIG preprocesses all input files through an enhanced version of the C preprocessor All standard preprocessor features are supported including file inclusion conditional compilation and macros SWIG is a very convenient special preprocessing symbol defined by SWIG when it is parsing an input file SWIG preprocessor symbol class DesBase
29. FactTurb make for turbulent objects Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 62 75 Design and Implementation Tutorial DSNA e finally one can use this type information to call the correct constructor and thus to get an object of the desired type In C creating objects of polymorphic types at runtime is sometimes called the virtual constructor technique Note however that there is no virtual ness here each object creation is a block of statically bound rigid not virtual code 12 1 1 4 A too simple example choice of time integration algorithm At runtime depending upon the state description objects defining the simulation the factory may choose to create either a TmoRKutta object or a TmoFBEuler object file Fact Base FactProblem C TmoStage FactBase createAllTmoStage TmoPbElem amp pbElem DesTimeInteg amp desTimelnteg TmoStage curStage if desTimeInteg gt getS KEY_ODE E_BACKWARDEULER curStage createTmoFBEuler else if desTimeInteg gt getS KEY_ODE E_RK4 curStage createTmoRKutta desTimeInteg else DefError error 2115 error error raiseError Error pbElem setTmoStage curStage return curStage Here the type identifier is a string E_BACKWARDEULER or E_RK4 To every concrete class here TmoFBEuler and TmoRKutta is associated a creation function
30. Factory component However the new boundary treatment is still not accessible from the e sA interpreter The procedure to add a new boundary treatment to the e SA interpreter is fully described in section 12 Ref ELSA MDEV 06001 ONERA aleA RTE De ER hi Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 57 75 11 JOIN COMPONENT 11 1 Definitions The Join package is responsible for the transfer of data between adjacent grids Let us introduce some notations e the current gridis the grid receiving data e the opposite gridis the grid sending data e the depth is the number of rows of cells to retrieve current block t opposite block 11 2 Class diagram 11 2 1 Bridge design pattern JoinBase ba A A JoinAdjacentP A JoinMatchP A JoinMatch JoinMatchParP JoinMatchSeqP 11 2 2 JoinBase Abstract class provides the interface for data transfer services implemented by derived concrete classes Ref ELSA MDEV 06001 ONERA Version Edition 1 0 Date Jan 10 2006 Page 58 75 DSNA 11 2 3 JoinAdjacent Abstract class that provides common services for matching and near matching join 11 3 Characteristics current window we Join opposite window wl Join current window wl opposite window w2 e ajoin per block face or sub face e sequential multigrid parallel geomTransfo AgtTran e spatial periodicit
31. Fld client code 1 Construction of a field which stores the unknowns of the CFD problem ro rou rov row rol Fl E_Int nfld 5 FldCellF wCons ncell nfld Construction of a field which stores fluxes FldIntF flux 3 ncell nfld 2 Construction of a field which stores mesh coordinates FldNoder x ncell 3 FldNodeF y ncell 3 FldNoder z ncell 3 3 FldArray or F1dField can be used to store values without geometric links such as FldArrayF TurKO getModConst const FldArrayF modConst 7 modConst 0 _kappa modConst 1 _sigmal modConst 2 _sigmael modConst 3 _betal modConst 4 _wsigl modConst 5 _betae modConst 6 _Sr 4 To access individual elements a syntax similar to Fortran is used FldArrayF 100 2 3 2 3 14159 assigns pi to the fourth element of component 2 FldArrayF g 100 g 0 2 22 Note F1dAr ray is really an implementation class it would be probably better to avoid using it directly using FldField instead additional memory associated with F1dF ield own attributes is negligible Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 ARA a Date Jan 10 2006 Page 28 75 Design and Implementation Tutorial DSNA 6 2 2 Check of memory access control of memory initialiazation F 1d classes should almost always be preferred to C C arrays see also Prefer Fld objects FldArray FldField to C arrays
32. Ge te wit Bet ory de nae tee tay Bete neh ete eh Ss coeds Gh ap ese Be a 68 13 2 elsA interface building strategy 69 13 21 Technical TETE sa s Un a Un RS tn dr aan denses 70 72 Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 8 75 Design and Implementation Tutorial DSNA 1 INTRODUCTION 1 0 1 Document s purpose The intent of this document is to provide developers with design information necessary to con tribute to elsA software development A companion document Development Process Tutorial ELS A MDEV 03036 provides additional information 1 0 2 Content The document starts with a brief summary of CFD basic concepts chapter 2 and of Object Oriented design chapter B An overview of elsA general architecture is given in chapter 4 then the e SA kernel design is pre sented in chapter 5 Individual modules are described in chapter 6 to 13 with an emphasis over design and implementation technical choices ONERA ale A Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 9 75 2 THEORETICAL BACKGROUND elsA is dedicated to numerical simulation of single species laminar or turbulent including transi tion compressible flows on 3D or 2D or axisymmetric block structured grids The equations to be solved are the Navier Stokes NS equations in which turbulence is modelled
33. Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page 33 75 the JMIN lower J interface of cell 1 1 1 corrsponds also to 1 1 1 the KMIN back K interface of cell 1 1 1 corrsponds also to 1 1 1 ghost geometric entities have to be taken into account for example the indices of the two extreme cells are direction and lastly the k direction j then for k then the mon j interfaces Address methods dealing with index counting and position which are available in class GeoConnect must be used in all the C kernel classes If im jm km are the number of mesh points in the directions 1 j k then the numbering of cells nodes interfaces in the total grid real ghost entities are Address methods adrCell i j k adrInti i j k adrIntj i j k adrIntk i j k adrNode i j k i 1 GHOST t j 1 GHOSI H k 1 GHOST adrCell Increment methods PATA r_J1 _K1 im 1 im 1 jm 1 adrCell i j k adrCell i j k i k nCell 2 nCell adrCell i j k GHOS GHOS GHOS r_T1 TT r_J1 t GHOST GHOST t GHOST r I2 lT I2 _J2 Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA A ee Date Jan 10 2006 Page 34 75 Design and Implementation Tutorial DSNA incrementCell i j k i j im 1 GHOST_I1 GHOST_I2 k im 1 GHOST_I1 GHOST_I2 jm 1 GHOST
34. WallLaw sigmaOmega E Float iniTranspEg0 tauMaxLimitor E_Float _sstConection E_Bool _sigmaD E Float _sigmaK E Float _betaOmega E_Float betak E Float _alphaOmega E Float iniTranspEqO compTurWallLawt corapMutInModel compSpecTurbi compSource isFieldUsed coraputeField getSigmat lt lt destroy gt gt TurKOavtacl getiModConst lt lt destroy gt gt TurKO _zhengLimitor E_Bool Sr E Float _sigmad E_Float betae E_Float _wsigl E_Float _betal E_Float mes _sigrael E_Float Only the virtual _sigmal E Float methods are _kappa E Float displayed compSource lt lt destroy gt gt TurKO set C elIN compTurWallLawt niTranspEa compute Wal compute Wall corapMutInModel compSpecTurb getSigmat isFieldUsed computeField etNbEgtur etModConst TurMTbsl TurKOavtac TurKOMenter _wsig2 E Float _omegaWallProlong E_Bool _modelVersion ModelVersion _beta2 E Float _sstCorection E Bool _wsig2 E_Float _sigmae2 E Float lcompSpecTurb _beta2 E Float _sigraa2 E Float lcomphutInModel _sigmae2 E Float lt lt destroy gt gt computeNearWall _sigraa2 E_ Float M TuwMTbsl compute Wall lt lt destroy gt gt compSpecTwb computeWall TurKOMenter compSource compSource cormpMutInModel getSigma compSpecTurb getModConst compSource lt lt destroy gt co
35. _J1 GHOST_J2 incrementC incrementN increment IJK i j k 11 i j k od 1 3 k If needed inside Fortran subroutines the following statement functions have to be used by including the file Geo Grid GeoAdrF h INTEGER_E idummy jdummy kdummy INTEGER_E im_dummy jm_ dummy km_dummy INTEGER_E adrcell adrcellg inccellg INTEGER_E adrnodeg incnodeg adrcellg idummy jdummy kdummy im_dummy jm_dummy km_dummy amp idummy 1 IFIC1 amp jJdummy 1 JFIC1 im_dummy 1 IFIC1 IFIC2 amp kdummy 1 KFIC1 im dummy 1 IFICI IFIC2 amp jm_dummy 1 JFIC1 JFIC2 adrnodeg idummy jdummy kdummy im_dummy jm_dummy km_dummy amp idummy 1 IFICI amp jdummy 1 JFIC1 im_dummy 1 IFIC1 IFIC2 amp kdummy 1 KFIC1 im dummy 1 IFICI IFIC2 amp jm_dummy 1 JFIC1 JFIC2 incnodeg idummy jdummy kdummy im_dummy jm_dummy km_dummy amp idummy amp jdummy im_dummy 1 IFIC1 IFIC2 amp kdummy im_dummy 1 IFIC1 IFIC2 jm_dummy 1 JFIC1 JFIC2 inccellg idummy jdu mmy kKdummy dummy 1 IFIC14 amp idummy amp jdummy im amp kdummy im _dummy 1 IFIC1 im_dummy jm_dummy km_dummy HIFIC2 HIFIC2 jm_dummy 1 JFICI IJFIC2 These methods address and increment allow to deal with connectivity between cells and interfaces as it is usual in finite volume f
36. al ONERA 71 75 DSNA Direct access to index s alphabetical section headings OS CALCIUM HOST PALM swig 16 A link is to index s alphabetical headings abstract class abutting 20 addressing function C addressing function Fortran Adjoint 17 adjoint approach shape optimization adrcell 30 adressing convention ALE 14 ALE 5 algebraic turbulence model 8 33 B link is to index s alphabetical headings backward Euler 7 base class Base layer 20 begin Fld iterator Blk block 6 block splitting Bnd Boundary condition border 46 boundary 46 boundary condition 6 20 boundary condition design 48 Boussinesq a link is to index s alphabetical headings C CALCIUM 76 CFD 4 CFL 7 CGNS 17 chimera class class 14 compBoundaryValues compBoundaryValuesInGhost component connectivity INDEX convective flux 6 coupler 16 coupling external coupling multidisciplinary 16 cyclic dependency D link is to index s alphabetical headings 67 DAMAS 17 decoupled 6 default value diffusive flux 7 divergence form flux computation DTS 44 DTS 44 DTS Dual time Stepping 9 Dtw 20 Dual Time Stepping 44 E link is to index s alphabetical headings 67 E_FactTurRegister EARSM 8 eddy viscosity elsA py Python mod
37. bject Oriented architecture improves software extensibility through two basic mechanisms e polymorphism developers can design and implement new features such as a new turbulence model a new boundary condition a new implicit time integration algorithm in an independent way By this we mean that code is extended through addition of new files not modified thus greatly decreasing integration time by removing any conflicts e encapsulation Object Oriented technology encourages a clear distinction between private and public part of a component Clients of the component only use the public interface so they will not be affected by any changes in the private implementation part of the component This greatly reduce maintenance costs 4 1 2 elsAinput data To run a computation elsA users must provide e geometric data basically mesh coordinates and possibly geometric coefficients in chimera e topological data connectivity between blocks e physical data to initialize the time iterative loop this physical data may be a constant thermodynamic state or more generally come from data file restart file e definition of boundary conditions this may be only a boundary type identifier or additional data may be needed for example transition data can be prescribed in a fully general way with additional files 4 1 2 1 Definition of mesh points Mesh generation is not addressed by e SA users must provide mesh point coordinates as co
38. by the root rank 0 processor 4 1 9 Post processing 4 1 9 1 Restart files can be generated by specifying a directory name This directory can then be used as input for a subsequent computaion 4 1 9 2 Global residuals With default parameter GLOBAL_RESIDUAL set to YES residuals for the complete configuration are automatically extracted 4 1 9 3 General post processing A very fine control of post processing is available e Local quantities a wide range of local quantities Mach pressure can be extracted e Global quantities global quantities lift drag mass flow residuals are available with a simplified syntax when defined on predefined window families for example one family may correspond to the wing another one to the fuselage Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 22 75 Design and Implementation Tutorial DSNA 5 KERNEL DESIGN 5 1 Classification and Design organization CFD concepts can be classified as geometrical topological numerical and physical concepts In order to solve a CFD problem we have defined a limited number of basic classes responsible of the following actions 1 to take into account the fluid physical properties in the flow 2 to build and control the numerical space region where the system of equations is solved 3 to build the system of equations compute the terms arising from the spatial discretization flux source ter
39. concrete method applyTransition e TurAlg is the base class for algebraic turbulence models the derived classes provide the eddy viscosity compu tation compMut InModel e TurTransp is the base class for transport equation turbulence models the derived classes provide methods to compute the source terms method compSource the coefficients needed to compute the turbulent diffusive fluxes compDifFluxDensCoef and the eddy viscosity compMut InModel The actual turbulence models correspond to concrete classes All the concrete classes belonging to the Tur component ONERA DSNA inherit either from TurAl g or from TurTransp depending of their algebraic or non algebraic nature ompMut TurBase compMutinModek FxdFlux kK compMut aT applyTransition TurTransp TurAlg A A TurKEps TurKL TurSA TurKO TurAlgMichel TurBlx A gt A gt TurTwoLayer i TurWL94 TurKOMenter TurKOavtac TurMTbel 1 1 A TurASM TurMKFLC2 TurMTsst ONERA DSNA elsA Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Design and Implementation Tutorial Page TurBase _eleraSysOper EosElemSysType_X
40. djacent boundary non coincident line e no match boundary e multistage boundary Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 A E Date Jan 10 2006 Page 14 75 Design and Implementation Tutorial DSNA 2 3 Not discussed in this document 2 3 1 Chimera technique 2 3 2 Hierarchical Mesh Refinement HMR ONERA aleA Ref ELSA MDEV 06001 a wd ISA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 15 75 3 WHAT IS OBJECT ORIENTED SOFTWARE 3 1 Object Oriented Programming Concepts If you ve never used an object oriented language before you need to understand the underlying con cepts before you begin writing code You need to understand what an object is what a class is how objects and classes are related and how objects communicate by using messages The next sections sum up the concepts behind object oriented programming 3 2 Object interface encapsulation An object is a software bundle of methods behaviour and attributes data At a given time the set of all the attribute values is called the object state Everything an object can do is expressed through its interface The interface can be seen as a proto cal Providing access to an object only through its interface while keeping the implementation details private implementation masked is called information hiding or encapsulation The benefit is that the private part of an object both private data and
41. e in JMAX _K1 ghost nodes in KMIN GHOST_K2 1 ghost node in KMAX 7 1 3 1 Ghost defaultvalues The default values are GHOST_I1 2 GHOST_I2 2 GHOST_J1 2 GHOST_J2 2 GHOST_K1 2 GHOST_K2 2 Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page 32 75 elsA ONERA ST Design and Implementation Tutorial DSNA Users can change these default values at the beginning of each run by calling DesCfdPb set_ghostcell usu ally to reduce CPU time on some platforms 7 1 4 Simplified example We give here a simple example where the k planes have been neglected 1 I I j oe ae oar ene 1 1 1 EPEE eye a peel a L l I I 1 i sea E f il 1 I E a da l l l j 1 PSA AAA I l j l l 1 n0 18 nf 29 is the correct interval for the computation of all real values Numbering of cells and interfaces GHOSTI1 GHOSTI2 2 GHOSTJ1 GHOSTJ2 2 7 1 5 Identical numbering of cell interface node real cells numbering real and ghost cells numbering real and ghost interfaces numbering The benefit of this choice is that we have a simple relation between cell interface and node indexes which enables easy looping over cells interfaces or nodes DO n n0cell nfcell nil n njl n ncell nkl n 2 ncel ni2 n inccell n32 n nc ince nk2 n 2 nc ince
42. e stage Ghost cells are filled by boundary objects before the gradient com putation such that the standard formula will give the correct result Within this strategy there is no need to use special formula to correct the computation on the border region OperGradInt uses this strategy 9 1 3 OperTerm abstract class Most of the time an operator needs to compute some auxiliary fields before the final computation of fluxes or source term for example the pressure field has to be computed to complete the centered convective flux computation So the stage Computation of an OperTerm is split into two sub stages 1 computation of all the required auxiliary fields by means of the conservative variables 2 computation of fluxes or source terms using these auxiliary fields Auxiliary fields which have to be computed before flux or source term computation have to be identified A specific attribute OperTerm _setOfIdent of type list lt AuxField gt is introduced to store auxiliary field identifiers The method virtual void computeAllField const list lt BndPhys gt listBnd const list lt JoinBase gt listJoin Ra _NULLPTR _NULLPTR A Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 ARA Date Jan 10 2006 Page 46 75 Design and Implementation Tutorial DSNA calls the computeField method for each auxiliary field registered by _setOfIdent Operators compute each registered field th
43. ects involved in a CFD simulation Starting from a description of the simulation expressed through Descp objects coming from the Python script file a small number of factory objects are responsible for the instantiation of all the objects required to run a CFD simulation Basically the work is made through simple test sequences based on attributes of specific description objects depending upon the attribute values a kernel object of a specific class is instantiated and correctly initialized 12 1 1 Factory concept 12 1 1 1 Steady state A very significant advantage of OO software is that it is easy to extend through polymorphism if client code interact with objects using only base abstract class interface adding a new derived class does not require a modification of the existing code the compiler takes care of the underlying switches by calling the correct virtual method of the concrete derived class and the client code has no knowledge of the actual object types concrete classes 12 1 1 2 Initialization stage However of course there is no magic here there must be somewhere in the code where specific derived class objects must be created based on some criteria So when the new derived class is introduced in the hierarchy there must be some modifications To keep the advantage of polymorphic extensibility it is obvious that these modifications must be encapsulated in a single function hopefully a small one or better in a si
44. elsA Ref ELSA MDEV 06001 A si Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 75 75 DIFFUSION SCHEME Archives Secr tariat Logiciel R dacteurs D veloppeurs elsA END of LIST
45. fo elsA DSNA Design and Implementation Tutorial Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page 1 75 Design and Implementation Tutorial cfdpb model numi numerics view check cfd1 compute cfd1 extract Quality For the authors For the reviewers set phymod nstur Approver Function Integration manager Head of design method Quality manager Project head Name M Gazaix A Gazaix Joll s A M Vuillot Visa Software management ELSA SCM Applicability date immediate Diffusion see last page L Cambier Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA ae ae Date Jan 10 2006 Page 2 75 Design and Implementation Tutorial DSNA HISTORY o DATE CAUSE and or NATURE of EVOLUTION edition 1 0 Jan 10 2006 Creation from MDEV 03036 ONERA aleA Ref ELSA MDEV 06001 DRE NE Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutoria Page 3 75 CONTENTS 3 8 1 0 1 Documents purpose lt 4 6448 4s ee4 Fae hee bee eee es 1 0 2 COHEN are vers ee we eee ee eee oe em ed oe a ee eS 8 2 Theoretical background 9 A o irog eh dk a ete OR OR ee eR ee de Bok 6 Bok GBR ag 9 21 1 _ Numerical formulation 4 suc sue sus she a 9 Sate Sh E ua 9 2 1 3 Mesh and ROUE PR SOAS GG a GOES as 10 ee ee ne 10 2 2 1 Space discretization schemes 2054 45 8 be 284 eus set res es 10 on es y
46. g Rules Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page 30 75 elsA Design and Implementation Tutorial ONERA DSNA X Component Y Component Z Component amp W Pr amp fdx fdy fdz IMPLICIT NONE C_IN INTEGER_E ncell negtot neq REAL_E w 0 ncell 1 negtot Conservative Variables REAL_E p O ncell 1 Pressure C_OUT REAL E fdx 0 ncell 1 neq Convective Flux REAL_E fdy 0 ncell 1 neq Convective Flux REAL E fdz 0 ncell 1 neq Convective Flux Laisse DO icell 0 ncell 1 roi ONE w icell rog fdx icell ro w icell roug fdy icell ro w icell rovg fdz icell ro w icell rowg 6 3 3 Remark on Fortran convention In the example above the following convention has been followed in the two dimensional array addressing e the first dimension index varies from 0 to ncel1 1 e the second dimension index varies from 1 to neq This choice has been made here in order to be the same as the C choice but it is not mandatory We could of course also write REAL _E w ncell neqtot C_OUT REAL _E fdx ncell neq REAL_E fdy ncell neq REAL E fdz ncell neq iaa 2 DO icell 1 nce roi ONE w icell rog fdx icell ro w icell roug fdy icell ro w icell rovg fdz icell ro w icel
47. gs Jameson s scheme 6 Join 20 Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 tation Tutorial Page 73 75 K link is to index s alphabetical headings 67 kernel 18 E a link is to index s alphabetical headings 67 layer LES 8 Lhs Left Hand Side 21 load balancing 16 local quantities post processing 17 local timestep 7 Low Speed Preconditioning 9 LU implicit time integration algorithm 7 LUSSOR implicit 50 LUSSOR implicit time integration algorithm 7 _ M link is to index s alphabetical headings 67 map Mask matching join mean flow 7 memory initialization control 24 mesh 6 20 mesh deformation messagee rete BE minmod 43 module 18 MPI T6 20 multiblock 20 Multigrid 9 MUSCL 6 _N link is to index s alphabetical headings 67 naming convention near matching join O link is to index s alphabetical headings 67 object object factory Object Oriented OO 14 ODE 5 Oper 20 operator OperSou Opt component P link is to index s alphabetical headings 67 Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page 74 75 Design and Implementation Tutorial parallel 20 time loop parallel MPI timestep 6 Pcm 20 Tmo 21 physical model layer polymorphic behaviour polymorphism lin
48. gt E_Float Pointer on Virtual constructor of the BndPhys typedef BndPhys PtrVirtConsBnd const DesBoundarye const DesBlockg const DesNumerics const EosIdealGas amp TurBase Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 A oe Date Jan 10 2006 Page 64 75 Design and Implementation Tutorial DSNA const GeoGrid amp E_Int Type identifier typedef TbxString TurTypeld typedef TbxString BndTypeld map of Tur virtual constructors typedef map lt TurTypeld PtrVirtConsTur gt DicoTur typedef map lt BndTypeld PtrVirtConsBnd gt DicoBnd The factory owns dictionaries _a11TurCtor _allBndCtor static DicoTur _allTurCtor static DicoBnd _allBndCtor Each entry is a pair resulting from the association of a name and a pointer to function To every new turbulence class or new boundary condition class corresponds a new entry in this dictionary ClassId createClassName 12 1 2 3 Register a new turbulence model class The factory is scalable because you don t have to modify its code each time you add a new derived class to the system FactBase divides responsibility each new concrete class has to register itself with the factory by calling register Tur and passing it its type identifier and a pointer to its creation function class FactTurb Tur objects instantiation method TurBase make const DesNumerics amp desNumGlb DesMode
49. his class of transport equation models assumes a non linear relation between the Reynolds stress tensor and the velocity gradients in order to provide a better description of the turbulence anisotropy They are characterized by an ASM closure instead of the Boussinesq closure This closure relation is used to express the Reynolds stress tensor Large eddy simulation LES with Smagorinski model has also been introduced in e SA LES allows the use of coarser meshes by resolving directly only the largest scales of the flow while small scales referred to as subgrid scales are represented through a statistical model 2 2 4 2 Algebraic models Among the turbulent models based on the Boussinesq hypothesis the algebraic models are based on an algebraically defined turbulent viscosity according to a mixing length hypothesis Their predic tive value is limited but their advantage is robustness and economy Michel Quemard Durant and Baldwin Lomax models are available 2 2 4 3 Transport equation models Many turbulence models with transport equations are available in e sA Among them e one transport quation Spalart Allmaras model with DES correction option e two transport equations k 1 Smith model k omega model with different options ONERA elsA Ref ELSA MDEV 06001 m Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 13 75 x Zheng limitor cross diffusion term in the omega equation
50. hom amp he Ne do A eet a Ste de 50 E ag Be ide 50 Dada a ba oe bee 50 10 1 3 Additional details 244 225228 8208824 re aa aa 51 ee di dd ee ee 52 10 3 How to introduce a new boundary condition 55 10 3 1 Use OL mheritance 222 si ecb eee PA eee een ee ee ES 55 11 Join component 57 MA A 57 eS a AREA ERAS 57 Se ain eta Bs elas Se et Se ean Sh ee di LUS at as oat 57 PATA 4 ei lee de ie Bi OR p aoe OR ER eh oa bo eh wae 57 1 2 3 JomAdjacent o seca oce moos pani sore p aC eoa go Se we Se ee we eS 58 MERA AA 62h aneit heh eB ee Be a Be ie Aa Be Boke amp BAE Bak Bx ag 58 MEE AA 58 11 4 1 Main methods scsi 58 11 5 Preparation of join for parallelism JoinParBuffer 59 D Ne Nb A ee Se e Bele ag 59 11 5 2 Main m thods Aa 59 ANT GOR RR ap iea i GO RE ME A ae a etes 59 11 7 Agt component Affine Geometry Transformation 59 E a NE E 59 11 7 2 Example 22 eee ee She bbe eh oS 2 4 s og He Des 60 11 7 3 Geometric transformations 60 Bawor OD TSI NS DNS MN Ad dd 60 12 Factory component 61 ee 61 12 1 1 Factory concept 2 a eh a 61 12 1 2 Factory OO a ica bod Bee Bae poai oe oe be Bee AS 63 ONERA Ref ELSA MDEV 06001 AA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 7 75 13 Descp Package 68 Pa a Bote Bowe Boe CA dE Poked 68 ETRE sg a se oe ey oR ws me a I aata aa aS Honor ew 68 e
51. hus avoiding potential errors when duplicating boundary data 4 1 2 4 DAMAS database A tool using as input a DAMAS database is also available Note In future releases it will be optionnaly possible to read mesh coordinates as well as restart data and boundary definition data at least for the usual boundary types directly from a CGNS database 4 1 3 Simulation control elsA users control their CFD simulations through the Python scripting interface This can be done in three ways e interactive text mode this is limited to very basic test cases e through a Graphical User Interface GUI called PyGe sA documented in the PyGelsA Graphical User inter face User s Manual http elsa onera fr ExternDocs user MU 02044 pdf e through a Python script file this is the preferred way for complex simulations It is fully described in the elsA User Reference Manual http elsa onera fr elsA doc refdoc html Using Python as the scripting interface greatly reduces the time required to develop and maintain the user interface Moreover Python provides with a high level versatile programming interface allowing novice as well as expert users to interact with e sA in an optimized way Let us give a small non exhaustive list of useful Python features in the context of CFD simulation e Script files can be splitted in several modules allowing reuse of well tested blocks of settings thus avoiding many potential errors e Simple Python
52. ical numbering of cell interface node 32 7 2 Address and increment methods 33 7 2 1 Example Centered convective fluxes 35 e A ee ER AS 36 S Tur component 37 8 1 Definition of the public mtertacel 2 ace e aoe Pee bbe Hbeweewtee as 37 62 Class model y ci AA ER SMS Se AA amp AA A oe 37 8 3 Polymorphism in turbulence modeling 41 8 4 How to introduce a new turbulent model 42 sl Use of inheritance 2224 ihre he eRe SRE Ree eee ee 42 9 Oper component 44 bee eee oe es a in 44 9 1 1 OperBase abstract class 2252252256 ers Eu whee Se RES 44 clewdeeteedwebeeague ede eo s 5 4 4 aia ed 45 adria hoe Boe hea he oe Be he oe 45 ot be Oe See Eee Gee Se oS Sw Se ES 46 9 1 5 OperSou abstract class 46 AA nc LL Se RIT SAR RES SR BEER Re SSS 46 9 2 1 Centered convective operators ea Due a Bou D a Brave 47 IRL ITR DR DIS doe TR Peteee eee as 47 ER DR TR Ce dd a de 47 93 Exa Module 4 27440 Bene Ain a NA we Bote nd Be At 440448 47 9 3 1 Diffusive flux operators for mean flow or turbulent system 48 Fats ete ee a e 48 9 4 Sou Modales 48 Ref ELSA MDEV 06001 ale A ONERA Version Edition 1 0 eet AAA ees Date Jan 10 2006 Page 6 75 Design and Implementation Tutorie DSNA 9 5 How to introduce a new operator 48 10 Bnd component 50
53. inates elsA is able to build grid objects The conservative relationships are applied to grid cells Grid objects are very important and must be fully mastered by every application developer Grids have two essential roles 1 a grid object provides with the connectivity information topological relations between geo metrical entities cells interfaces nodes and edges 2 a grid object can provide the metrics volume of the cells surface of the cell interfaces 2 2 Description of the main features available 2 2 1 Space discretization schemes 2 2 1 1 Convective fluxes The convective fluxes can be discretized either by a centered scheme with artificial viscosity or by an upwind scheme e Jameson s centered scheme with a choice of several artificial dissipation formulations e upwind schemes van Leer Roe Coquel Liou fluxes are available First order and second order are available when combined with MUSCL extrapolation The additional equations arising from turbulence transport equations are most of the time solved in a decoupled way the convective fluxes of the turbulent system are then discreatized with the Roe scheme in association with the Harten entropic correction ONERA elsA Ref ELSA MDEV 06001 ee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 11 75 2 2 1 2 Diffusive fluxes The discretization of the diffusive fluxes requires the evaluation of the flux densities wh
54. is a concrete TurBase ype TurBasex belonging to this Fxd object method which consists of two stages where _tur is an attribute of t COMpMut TurBase Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 42 75 Design and Implementation Tutorial DSNA compMut InModel applyTransition If transition has to be taken into account the method applyTransition applies the intermittency function on the eddy viscosity in a uniform way for all the models The method applyTransition is then a concrete method implemented in TurBase Conversely computation of the eddy viscosity depends on each particular turbulence model and cannot be implemented in the TurBase abstract class When manipulated in term of this abstract interface defined by TurBase the concrete classes have not to be known by the client classes Client classes are only aware of abstract class Polymorphism allows the correct version of compMut InModel to be called dynamically without any explicit switch coding by the programmer In the example discussed in the preceding sections of the Fxd Tur interaction through the method compMut the client manipulates a pointer or a reference to an instance of a class derived from TurBase TurBase oe Cr i FxdFlux ne compMut public Lies i compMut compMut compMutInModel 4 applyTransition protected l tur applyTransition NG EEE
55. k Bu de etsy A ae okay hig a ee ee bee Fe ee 11 229 C lc lati n stfategyj ass 2 MIN th Be koe A Be aa Boe Bla Bed 11 2 2 4 Turbulence modeling 464 644 seres eee AAA 12 ee Sesh Bt tee et te ee ge Etc te ee Ey Be O 13 eee ee ee ee ee ee ee 13 2 2 7 Rotation frame and ALE technique 13 2 2 8 Types of join boundary 13 2 3 Not discussed in this document 4 444 44946 a am ru me 14 2 3 1 Chimera technique 442 ie net a sit 14 2 3 2 Hierarchical Mesh Refinement HMR 14 15 3 1 Object Oriented Programming Concepts 15 ee Se eee Ge eats eB we Sg Re Se 15 O ne ee Bs aa ee bn de Se Bae SOBs Se Bred ae 15 3 3 1 Messages and methods 22562 s eee e eee ee 16 AR II 16 3 5 Inheritance 0 0c ee ee eee 16 Ref ELSA MDEV 06001 ale A ONERA Version Edition 1 0 E AAA Date Jan 10 2006 Page 4175 Design and Implementation Tutorie DSNA De et etaeetee dee PSI TE A e 17 4 General architecture 18 ve ada as ds de UN Sn da on 18 4 1 1 Object Oriented architecture 18 rera AD ISSUES SS Ut oe ba bee 18 4 1 3 Simulation control 22 42 24 48 ke ua a Baie etant a eS 19 4 1 4 Parallel mode 5 oe desa A e e 20 4 1 5 Multidisciplinary Coupling 20 Sue Le hee ke Be te Den 21 4 1 7 Access to CFD databases CGNS DAMAS 21
56. k is to index s alphabetical headings R link is to index s alphabetical headings RANS 5 reference frame 9 Rhs Right Hand Side 21 Roe s flux 6 Runge Kutta 7 S link is to index s alphabetical headings scripting interface gt Python singleton 12 40 skew symmetric flux computation slope MUSCL 43 solver layer 21 Sou Source term 20 SouDts 44 source term 5 SouTransp space discretization 5 6 20 Spalart Allmaras specialize from a base class Split component SPMD 16 steady 6 subclass superclass SWIG link is to index s alphabetical headings time discretization 5 time integration 7 transition 9 transport equation turbulence model 8 83 Tur TurAlg 34 turbulence turbulence design turbulence modeling 8 TurTransp type type identifier Factory 57 U link is to index s alphabetical headings 67 UML 14 B3 Z8 unsteady 6 upwind scheme 6 V link is to index s alphabetical headings 67 V_cycle 9 velocity formulation 9 virtual 12 57 virtual pure virtual constructor W link is to index s alphabetical headings 67 W cycle 9 Na link is to index s alphabetical headings 67 _Y link is to index s alphabetical headings 67 i Din link is to index s alphabetical headings 67 ONERA DSNA ONERA
57. l rowg 7 ONERA DSNA GEO COMPONENT elsA Design and Implementation Tutorial Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page 31 75 GeoGrid objects are widely used in the CFD kernel because many CFD classes need a pointer on GeoGrid objects GeoGrid is a composition of two classes GeoGridMet rics and GeoConnect It is responsible for e metrics issued from methods of GeoGridMetrics class e index counting and position connectivity issued from methods of GeoConnect class 7 1 Ghost geometric entities The number of ghost entities is controlled through 6 global variables GHOST GHOST GHOST elsA uses the following convention 7 1 1 Ghost cell numbering T_ 11 and GHOST_12 in the I direction _J1 and GHOST_J2 in the J direction Kl and GHOST_K2 in the K direction GHOST_11 ghost cells in IMIN GHOST_12 ghost cells in IMAX GHOST_J1 ghost cells in JMIN GHOST_J2 ghost cells in JMAX GHOST_K1 ghost cells in KMIN GHOST_K2 ghost cells in KMAX Ghost interface numbering e GHOST_I1 ghost interfaces in IMIN GHOST_12 1 ghost interface in IMAX e GHOST_J1 ghost interfaces in JMIN GHOST_J2 1 ghost interface in JMAX e GHOST_K1 ghost interfaces in KMIN GHOST_K2 1 ghost interface in KMAX Ghost node mesh points numbering e GHOST_11 ghost nodes in IMIN GHOST_12 1 ghost node in IMAX GHOST GHOST _J1 ghost nodes in JMIN GHOST_J2 1 ghost nod
58. l amp desModGlb DesBlock amp desBlock const list lt DesBoundary gt amp listDesBnd const list lt DesInit gt amp listInitBlock GeoGrid grid registration E_Bool registerTur TbxString name PtrVirtConsTur pvc FactBase makeTurb File FactTurb C E_Int turbMod desModGlb getI KEY_TURBMOD TbxString trueName _db getTurClassName turbMod turBase _allTurCtor trueName desNSDGlb desModGlb desBlock grid ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 65 75 vectorWindows vecWakes vecWalls vecTurCriteriaFile coeffMutInit if turBase E_NULLPTR DefError error 2180 error error raiseError E_Bool FactTurb registerTur TbxString name PtrVirtConsTur pvc _allTurCtor name pvc The registration itself is performed with startup code code generated by the compiler to initialize global objects before entering main namespace TurBase createTurKL return new TurKL cutvarl cutvar2 muRatioMx prandtlTurb coeffMutInit turcriteria _FactTurRegister TurKL appel de la macro d ebregistrement we where to ease notation we have used the macro define E_FactTurRegister className const E_Bool registered className FactTurb instance gt registerTur TbxString className amp c
59. lux fldiIn fldOut estes list lt BndPhys gt const_iterator itr for itr listBnd begin itr listBnd end itr Fasa 2 a Compute border conservative variables itr points to a boundary object wol stands for the conservative variables on boundary interfaces itr gt compBoundaryValues f1dIn whl 2 b Compute border flux values computeOneBorder fldin itr gt getBndType window whl fldOut OperF Lux is here only aware of abstract class BndPhys But polymorphism allows the correct behaviour of the concrete boundary condition to be taken into account calling dynamically the correct version of compBoundaryValues for each concrete boundary condition pointed by the pointer itr of the list ListBnd 10 3 How to introduce a new boundary condition 10 3 1 Use of inheritance It may happen that developers will have to add a new boundary treatment say BndDev01 to Bnd module This is basically a simple task e The definition of the new class must be written say in the file Bnd Phys BndDev0l h Starting from an existing similar class this stage should be relatively easy In most cases we only have to adapt the specific attributes of the new class Examples of specific attributes BndNS _tWall wall temperature BndTranspir _viw attribute for transpiration condition Wall BndSubInj _pa imposed boundary quantities BndSubInj _ha total pressure total enthalpy BndSubI
60. mplement the following method void compBoundaryValues const FldCellF amp wCons FldIntF amp wbl 2 Immediately after the computation of wb1 a second stage is performed in order to correct the flux values on the border interfaces void OperFlux computeOneBorder const FldCellF amp wCons BndType bndType const GeoWindowStruct window const FldIntF wbl FldIntF amp f1d0ut where e whl is given as input to compute border fluxes e the flux field f1dOut is corrected on the boundary interfaces using wb1 So whatever the flux values were on the border interfaces these values are replaced by new ones Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 52 75 Design and Implementation Tutorial DSNA 10 2 Public interface class model and polymorphism This paragraph is quite similar to subsection Class model in chapter Tur component describing the design of turbulence models Both cases illustrate the subsection Inheritance in chapter What is Object Oriented software which introduces the concept of polymorphism and inheritance Following the previous section Bnd concrete classes have the responsability to implement the two methods declared in the abstract base class BndPhys by virtual void compBoundaryValues const FldCellF amp fld FldIintF amp wbl 0 corresponding to the treatment of Step 3 and virtual void compBoundaryValuesInGhost FldCellF amp fld
61. mputeField TurKOavtac getModConst ONERA DSNA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Design and Implementation Tutorial ONERA Date Jan 10 2006 Page 41 75 DSNA 3 so E 8 2 3 5 E 3 Hdzdsune zie 5 Omron duos 2 Qumbgz quired lt lt Aan sep gt gt aon ddde 2 OrporArmiardooo Ojepoprurinjgr duos S oy A VITONE gos wy g pondi OMSYS ROLL 4 UE Pod Y WTOP Y HOA NS E POT A PUPA PO A ET ROA ypxqaredard 7 pod 4 PAD REA HJU mogaredard pog a dog poa 4 AAA Ojsuonpojazed Oprerqamduzos wold 4 O A Oprarqajnduzos OBS NIET FOX A n Poad 4 merries CPAS NPA jisuerpuagduros 2 pog A XL wy 4 gd Bym Ompyduros mn a a E QEL E pog A mapsqs eog q SOUTENUE Ormaamauros POT A JUITTSA1 JO LSE pora 4 ISDISSUA Oma amduos 9 mya ape pod a eddo asen 1 gt 3 lt lt 0I SIP gt gt E OEA ee ypamautos B Pod Y QU LTPURT oY A ATI xX ad psAgquapqsog 1edos guiaa 9SUGARI equations transport the for ing turbulence modeli ism in 8 3 Polymorph All the classes deriving from the abstract class TurBase share its interface which declares method compMut In elsA the client classes of the turbulence models are the diffusive fluxes F xd and the time integration algorithm Tmo messages as for example Tur the provider and Fxd the client interact using ae tur gt compMut compMut
62. mputed from external tools such as ICEM CFD or NUMECA IGG Note however that mesh deformation algorithms are available ALE fluid structure coupling ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 19 75 A mesh file binary or ASCII Tecplot format must be associated with each block This greatly simplifies the parallel treatment and is inherently scalable to massively parallel computations To improve ergonomy it is advised to put all mesh files in a single directory and to use a consistent file naming In that case users do not have to care about the potentially large number of files they are only aware of the directory name which is just a super file 4 1 2 2 Restart files We use exactly the same mechanism as for mesh files Again the individual files associated with each block can be grouped into a single directory 4 1 2 3 Boundary information The generation of the complete boundary definition information can be time consuming and error prone An automatic script generator is available to generate this information from ICEM CFD input It is often convenient to put boundary definition in a separate Python script file module which is imported by the main driver script e boundary definition are nearly always kept unchanged e several computations with different numerical parameters or Mach number can share boundary definition t
63. ms controls the application of the boundary conditions 4 to control the time evolution of the solution So the kernel has been designed as a set of consistent modules or components A module is responsible for a set of well defined functionalities Ideally developers should be able to work inside a module without having to know the implementation details of any other modules Achieving a good decomposition is very important to improve ease of development and maintenance Moreover this OO model has been split into sub models with the aim to keep dependencies as local as possible These modules are organized into layers in such a way that each layer should only affect the layers above The goal of this organization is to achieve mono directional relationships The advantage is then that the maintenance becomes much easier since one layer s interface affects only the upper layers Avoiding cyclic dependency greatly simplify test policy 5 1 1 Naming convention Each module is identified by a key of 3 to 5 letters the first one being capitalized Inside each module each class name is then prefixed by the key of the module it belongs to Example TurKL belongs to the Tur module 5 2 Overview of the layers elsA kernel includes about 400 classes grouped in 26 modules specialized for a given CFD task These modules are further organized in 6 layers e Base e Geometry Physical model e Space Discretization Solver e Facto
64. near approximation of the solution on each cell is used in the projection stage using slopes and non linear limiters 3 Finally the upwind scheme is applied using the convective function 9 3 Fxd Module The Fxd is responsible for diffusive flux computaions All the classes of the Fxd module inherit from OperF lux class Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 SAA Date Jan 10 2006 Page 48 75 Design and Implementation Tutorial DSNA 9 3 1 Diffusive flux operators for mean flow or turbulent system The classes in charge of diffusive fluxes computation are e FxdLaminar or FxdLaminarInt computes the dissipative fluxes for a Navier Stokes laminar no turbulence problem e FxdTurMeanF low or FxdTurMeanFlowInt computes the dissipative fluxes of the mean flow system for a Navier Stokes turbulent problem e FxdTurTurbVar or FxdTurTurbVarInt computes the dissipative fluxes of the turbulent variable system for a Navier Stokes turbulent problem For turbulent problems the flux density evaluation is delegated to Tur objects For this purpose these operators own an attribute tur of type TurBasex 9 3 2 Diffusive flux operators with different kind of gradients The flux density evaluation needs the computation of gradients All operators of the Fxd module are direct users of the gradient operators presented above Two kinds of gradient operators can be used to evaluate the flux density OperGrad to compute gradien
65. ngle class If not for example if clients were authorized to call derived class constructor directly we would have simply moved the problem from the code using objets to the code creating them This class the factory FactBase or FactTurb in elsA knows about all the different class of the hierarchy and also has the information necessary to create the correct type of object No other parts of the system need to have this information A usually unique public class method defines the interface for creating a family of polymorphic objects Because of the unavoidable coupling between the factory and all the classes of the hierarchy it has to be carefully designed This mechanism is used in elsA to instantiate objects corresponding to several important class hierarchies Bnd Tur Fxc Fxd Lhs and TmoStage 12 1 1 3 Creation of objects at runtime virtual constructor elsA kernel objects are created at runtime depending of user inputs through script files or interactive session Infor mation coming from the user must provide among other things a type identifier This type identifier which can itself be an object helps the factory in creating the appropriate type of object We may sum up the logic through the object type object trade e the user information is coded in the type identifier object which can be an integer a string e this type identifier is exchanged through an indirevtion for the right type lFor example
66. nj _do xyz velocity directions Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page elsA ONERA 56 75 Design and Implementation Tutorial DSNA A constructor BndDev01 BndDev01 must also be coded The specific attributes of the class must be initialized by the constructor e A virtual destructor must be coded In most cases the new class will not call the new operator and the destructor implementation reduces to BndDev01 BndDevOl 5 e BndDev01 compBoundaryValues must be implemented Inside this method it may be convenient to call a Fortran subroutine to perform the numerical computations for numerical efficiency It may also be useful to introduce private methods to help with the main method coding Example void BndSub Lara RadEq compBoundaryValues compAzimutalAverage call of private methods compPressureDistribution wbpres_ call of FORTRAN subroutine for E_Int lint 0 lint lt intNbB lint for E_Int wb1 lint eqind eqInd 6 eqInd lt eqNb eqInd wbs lint egInd wol computation When the preceding steps have been completed it is wise to write a unitary test to check the code correctness see chapter Unitary test cases of ELSA MDEV 03036 It remains to be seen how boundary condition objects can be instantiated when needed in integration tests This is fully discussed in section
67. ns the factory keeps a collection of pointers to creation functions with identical signature each function being responsible of the creation of objects of a single concrete type Using free creation functions instead of class methods simplify the pointer to function management The connexion between type identifier and pointer to function is implemented through an associative container object that is a map The map object which can be viewed as a dictionary stores pairs of key value where key is the type identifier and value is the pointer to creation function 12 1 2 1 Choice of a unique type for type identifier We decide to use string TbxSt ring as the type of type identifier the obvious value associated to the class Some Class is of course the string object st ring SomeClass Whis this choice we solve the problem of finding a unique identifier Using integers for type identifiers would lead to the difficult problem of finding a unused value for every new class 12 1 2 2 Introduction of some typedefs To simplify notations we introduce some typedef for exemple for the Tur and Bnd hierarchies class FactBase Pointer on Virtual constructor of the Turbulence model typedef TurBase PtrVirtConsTur const DesNumSpaceDisc const DesModel const DesBlocke GeoGrid grid vector lt GeoWindowStruct gt amp vector lt GeoWindowStruct gt amp vector lt GeoWindowStruct gt amp vector lt FldiIntI
68. nt is passed by address reference for scalar pointer for array not by value see Calling Fortran subroutine Then in the C method the Fortran subroutine is called by denconvec_ ncell neqTot nbEqMoyComp rho mom ene rhoG momG eneG wCons begin press begin fdx begin fdy begin fdz begin The use of dX begin allows to point on the begining of the piece of memory where the values of the field fax are stored To get this address it is convenient to use the iterator mechanism whose member functions are begin end Notation dX begin stands for fdX begin 1 1 is the default value If it is needed to manipulate the second field corresponding to rou the method begin has to be used with the argument 2 fdX begin 2 It is obvious to see that if we change the two dimensional structure choice first index increases first the method be gin will not provide the same collection of entities In this case and if dimensions of fax are ncell x neq values of fqx will be stored in the following order fox 0 1 dX 0 2 dX 0 3 7 25 EAX O neq fdX ncell 1 1 fdxX ncell 1 neq instead of faX 0 1 fdX 1 1 fdX 2 1 fdX ncell 1 1 fdX 0 neq fdX ncell 1 neq Finally in the Fortran subroutine we find the following implementation T SUBROUTINE denconvec ncell neqtot neq amp ro rou roe amp rog roug roeg See also elsA Codin
69. oe double getF const char key const int getI const char key const const char getS const char key const ifndef SWIG pk E_Float getF const TbxStringg key const pk E_Int getI const TbxStringg key const pk TbxString getS const TbxString amp key const endif 13 1 2 1 SWIG directives Most of SWIG s operation is controlled by special directives that are always preceded by a to distinguish them from normal C declarations These directives are used to give SWIG hints or to alter SWIG s parsing behavior in some manner ONERA elsA Ref ELSA MDEV 06001 RER meee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 69 75 Wrapper DesModel i constant int E_ BALDWIN DesModel E_BALDWIN 0 13 1 2 2 SWIG parser limitations Although SWIG can parse most common C C declarations it does not provide a complete C C parser implementa tion Most of these limitations pertain to very complicated type declarations and certain advanced C features In the event of a parsing error conditional compilation can be used to skip offending code For example ifndef SWIG some bad declarations endif Note Newer versions of SWIG are able to digest most C constructs Workarounds that have been used in the past to build the swigged Python elsA interface are probably useless and should be removed 13 2 elsA interface building stra
70. ompF lux ONERA elsA Ref ELSA MDEV 06001 ee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 49 75 computeOneBorder computeField e Additionaly it may be useful to introduce new private methods and or attributes Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 50 75 Design and Implementation Tutorial DSNA 10 BND COMPONENT The Bnd module is dedicated to the treatment of the physical boundary conditions The join boundaries associated with the matching of two grids are not considered in this module but in Join compo nent This chapter is dedicated to two boundary types e Simple boundary associated with a single window they can express physical properties imposed by underlying physical problem adiabatic or isotherm wall symme try inlet outlet etc Global boundary associated with a group of windows such an object must be able to express the coupling imposed on several grid objects through some constraints Presently different types of global boundaries are implemented in elsA imposed flow rate multistage turboma chinery boundary Boundary objects are heavily used during the iterative loop to implement boundary conditions They are also useful for post processing 10 1 Boundary treatments 10 1 1 Introduction Thanks to ghost entities flux objects compute flux values on all interfaces using exactly
71. on of the compBoundaryValues method taking into account e the s state wbs given by the method createSchemeValues which computes predicted values referenced by scheme vales or s state in the Theoretical Manual of conservative variables on the boundary Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 54 75 Design and Implementation Tutorial DSNA in fact vales on the interface are obtained by some kind of extrapolation from the interior of the domain e the O state wb0 given by the method compLinearisationValues which computes values of conserva tive variables referenced by 0 state in the Theoretical Manual for linearization of characteristic relations these values are often chosen as the scheme values but the coding of this subroutine allows the use of an other set of values e the imposed boundary pressure _pres The implementation is then void BndSubPres compBoundaryValues const FldCellF amp fld FldIntF amp wbl E_Int intNbB _window getNbInt E_Int nint _grid getNbInt E_Int eqNb wbl getNfld FldIntF wbs intNbB eqNb createSchemeValues fld wbs FldIntF wb0 compLinearisationValues amp wbs wbpres_ intNbB nint _window getIndicBorder begin eqNb wb0 gt begin wbs begin wbl begin _pres gt begin _grid getSurf begin grid getSurfNorm begin os getGamma _sens if e
72. ormulation Note adrcellg adrnodeg adrintg will be renamed as adrcell respectively adrnode adrint in future releases ONERA elsA Ref ELSA MDEV 06001 A Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 35 75 n imG 1 left cell of interface n right cell of interface n n nCell imG 1 z n 1 c n n 1 n nCell interface min of cell n numbering of all the cells humbering of all imG im GHOSTI1 GHOSTI2 the interfaces 7 2 1 Example Centered convective fluxes In this example the loop index is an interface index Cell flux density values are used to compute the flux interface values DO n n0Int nfInt int n incl flux int fld 1 2 Qx n fld Qx n inc fld surfx int 1 Oy n 1d 0y n inc f1d surfy int 1 Oz n f1d 0z n inc f1d surfz int 1 END DO with interfaces I p nc incl inccell 1 0 0 im jm km Or nterfaces J p jis nc im 1 GHOST_I1 GHOST_I2 inccel1 0 1 0 im jm km incI nCell nterfaces K p inc im 1 GHOST_I1 GHOST_I2 jm 1 GHOST_J1 GHOST_J2 incell 0 0 1 im jm km 2 nCell incl Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page elsA 36 75 Design and Implementation Tutorial 7 2 2 Example Flux balance ONERA DSNA In this example the loop index is a cell index Interface flux values are used to
73. ose expres sion uses the gradients of velocity temperature and possibly turbulent quantities Gradients can be evaluated either in cell centers or in interface centers 2 2 2 Time integration 2 2 2 1 Explicit stage In the explicit stage the time integration is based either on a 4 step Runge Kutta algorithm or on a backward Euler algorithm In the case of steady flows time can be considered as an iterative parameter allowing to converge towards steady solution If the Runge Kutta time integration scheme is used the convective flux is recomputed for each Runge Kutta step whereas the diffusive fluxes numerical dissipation 1f any and source terms are computed only at the first step in order to save computation time To accelerate convergence the timestep can be a local timestep different from one cell to another The CFL number introduced to ensure the stability of the numerical scheme has to be defined by the user For unsteady applications time accuracy must be preserved a global timestep has to be chosen If the Runge Kutta time integration scheme is used the calculation of the diffusive fluxes numerical dissipation and source terms are done at the first and fourth Runge Kutta steps 2 2 2 2 Implicit stage Implicit time integration methods can strongly reduce the total computational time increasing the numerical stability of the schemes and thus allowing the use of larger timesteps The available implicit methods are
74. ponds to the Fortran way Note that in C we can turn to the other transpose way quite easily we would have to modify the implementation of exactly one method leaving the class interface strictly unchanged Instead of inline E_Float FldArrayF operator E_Int 1 E_Int fld const return _data l fld 1 _size We would have the transpose or swapped implementation TG inline E_Float FldArrayF operator E_Int 1 E_Int fld const return _data fld 1 1 _nfld When the e SA programmer uses a F1d object he uses the public class interface so he doesn t know how the data are actually stored and he should not be disturbed by any modification of the internal structure of the F 1d classes In Fortran obviously it is another matter ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 29 75 6 3 2 Examples If called from inside a C method a Fortran subroutine has first to be declared in a prototype such as extern C void denconvec_ const E_Int amp ncell const E_Int neqtot const E_Int amp neq const E_Int amp ro const E_Int amp rou const E_Int amp roe const E_Int amp rog const E_Int amp roug const E_Int roeg const E_Float consvar const E_Float press E_Float fdx E_Float fdy E_Float fdz It is important to note that each argume
75. private methods can be changed at any time without affecting the other objects that depend on it Encapsulation means any kind of hiding 1 Data hiding data members attributes are kept private 2 Class hiding the actual class is hidden behind an abstract class or interface In fact polymor phism which allows clients to ignore the true object type can be viewed as an encapsulation mechanism 3 Implementation hiding clients are only aware of an opaque pointer or handle see Do not systematically provide accessor methods Encapsulation improves maintenance facilitates extensibility Obviously many examples of encap sulation can be found in e SA see for example section 6 2 p 3 3 Collaboration between objects A single object working isolated from any other objects is usually not very useful Instead an object usually appears as a component of a larger program that contains many other objects Through the collaboration of a large number of relatively simple objects complex behaviour can be achieved This collaborative technique greatly facilitate flexibility and interoperability Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 16 75 Design and Implementation Tutorial DSNA 3 3 1 Messages and methods It is sometimes said in the OO community that objects interact and communicate by sending receiving messages In C messages correspond closely to public methods e as seen from
76. qNb gt 5 for E E H nt eqInd 6 egqInd lt eqNb eqlnd E_Float ptwbl wbl begin eqInd const E_Float ptwbs wbs begin eqInd for E_Int lint 0 lint lt intNbB lint ptwbl lint ptwbs lint Boundary conditions have several client classes e the right hand side Rhs which calls the compBoundaryValuesInGhost FldCellF amp f1d method as a preparation stage to the flux computation e the operators fluxes OperF lux class and gradients which call the compBoundaryValues const Fld CellF amp fld FldIntF amp wb1 method in order to apply the boundary condition on boundary interfaces before computing fluxes or gradients on border interfaces e the LUSSOR implicit method time step computation and artificial dissipation which need the boundary values of the conservative variables to compute the convective spectral radius ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 55 75 For example OperF lux the client and Bnd the provider collaborate to compute fluxes on all the interfaces see Step 3 in the following way void OperFlux compute FldIntF amp fldOut const list lt BndPhys gt amp listBnd const list lt JoinBase gt listJoin EEF 1 Compute interior flux values fldIn conservative variables in cell centers 1dOut flux cell interfaces compF
77. reate className Let us stress again that nowhere in the elsA kernel should the constructor of TurKL be directly called except inside method createTurKL Note The only exception may arise in unitary test s written specially to test TurKL class 12 1 2 4 Register a new boundary condition class The same solution is applied to register a new boundary condition class each new concrete class has to register itself with the factory by calling registerBnad and passing it its type identifier and a pointer to its creation function class FactBase registration FE Bool registerBnd TbxString name PtrVirtConsBnd pvc Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 BR CRIE Date Jan 10 2006 Page 66 75 Design and Implementation Tutorial DSNA E_Bool FactBase registerBnd TbxString name PtrVirtConsBnd pvc _allBndCtor name pvc The registration itself is performed with startup code namespace BndPhys createBndSubPres const DesBoundary desBnd const DesBlockg desBlock const DesNumericsg desNumGlb const EosIdealGas amp eos TurBase tur const GeoGrid amp grid E_Int level GeoWindowStruct windowFine desBnd getDesWindow gt getWindow GeoWindowStruct wind windowFine buildWindowAtLevel level E_Int intNbB wind getNbInt FldIntF dataBnd intNbB Li if desBnd queryF KEY _PRESSUR E
78. rough a call to computeField virtual void computeField AuxField identOfField const list lt BndPhys gt listBnd E_NULLPTR const list lt JoinBase gt listJoin E_NULLPTR computeField is pure virtual and must be implemented by concrete operators Fluxes or source term computation are not implemented at this level This is discussed in the next sections 9 1 4 OperFlux abstract class OperF Lux inherits from OperTerm It implements the major computational method compute according to Strategy 1 void OperFlux compute FldIntF fldOut const list lt BndPhys gt amp listBnd const list lt JoinBase gt listJoin compFlux computeAllBorders This class defines the signature of one of the most important methods of every flux concrete operator virtual void compFlux const FldCellF amp fldIn FldIntF fldOut 0 Knowing the conservative variables on cell centers this method provides with the flux values on the interfaces interior and border region of the operator The OperF lux class supplies also another important method computeAllBorders The goal of this method is to compute flux values on all interfaces of the border region taking into account the boundary conditions For every physical boundary the following scenario is used 1 the computation of the vector wb1 of conservative variables defined on boundary interfaces is delegated to the BndPhys
79. ry top level ONERA Ref ELSA MDEV 06001 elSA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 23 75 Ref ELSA MDEV 06001 elsA ONERA Version Edition 1 0 Date Jan 10 2006 Page 24 75 Design and Implementation Tutorial DSNA 5 2 1 Base layer Base layer gathers all low level modules among which the F1d and P cm modules 5 2 2 Fld data storage classes these classes encapsulate dynamic memory needed to store any computational data Their interface provide with monitoring methods optimized array like syntax much like FORTRAN 90 and methods to communicate with FORTRAN routines F 1d classes are built in order to provide the highest efficiency both in CPU and memory a comparable efficiency could not be achived through STL containers Pom deals with parallel implementation it encapsulates message passing interface presently MPI Geometry layer Geometry layer gathers all geometrical and topological modules 5 2 3 B1k defines the block notion A block corresponds to a region of the discretized physical space defined by a mesh to which are associated boundary and initial conditions Blocks are specialized to take into account grid motion ALE chimera and HMR Hierarchical Mesh Refinement features In most simulations several blocks are needed Geo defines the abstraction of the computational grid provides all geometrical ingredients used by a finite vol
80. s compiling a short main program file Api Wrapper elsA_wrap C that adds your customized commands to the language and starts the interpreter You then link your program with a library to produce a new scripting language executable Although static linking is supported on all platforms this is not the preferred technique for building scripting language extensions In fact there are very few practical reasons for doing this we plan to switch to shared libraries instead Note We still have to take into account platforms that do not provide shared library NEC SX Fujitsu VPP 13 2 1 2 elSA main elsA main is located in file Api Wrapper elsA wrap C To build elsA_wrap C SWIG uses the file Api Wrapper elsAembed_template i int main int argc char argv print banner general information e_log lt lt E_BANNERSTRING1 e_log lt lt Size of Float lt lt sizeof E_Float lt lt Bytes lt lt endl e_log lt lt Size of Integer lt lt sizeof E_Int lt lt Bytes lt lt endl e_log lt lt endl call Python interpreter E_Int py_return Py_Main argc argv ifdef E_MPI PI_Finalize endif e_log lt lt elsA normal run termination lt lt py_return lt lt lt lt endl Modify Api Wrapper elsAembed_template i with great care Date Jan 10 2006 Ref ELSA MDEV 06001 Page elsA Version Edition 1 0 Design and Implementation Tutori
81. tegy This section describes the general approach for building e sA interface with SWIG e Identify the functions i e class methods that you want to wrap It s probably not necessary to access every single function A little forethought can dramatically simplify the resulting scripting language presently Python interface e If you want to access a new C class from the scripting interface create a new interface file extension i Use SWIG s include directive to process an entire C source header file File Api Wrapper DesCfdPb i module DesCfdPb Sl include DesCfdPb g DesCfdPb Config Sconstant int E_1D DesCfdPb E_1D 0 Sconstant int E_2D DesCfdPb E_2D 1 Sconstant int E_3D DesCfdPb E_3D E Sconstant int E_AXI DesCfdPb E_AXI x 3 DesCfdPb Axis Sconstant int EX DesCfdPb E_X 0 Sconstant int E_Y DesCfdPb E_Y 1 Sconstant int E_Z DesCfdPb E_Z Jk Ff Sinclude DesBase g Sinclude DesCfdPb g e Make sure everything in the interface file uses ANSI C syntax e Eliminate unneeded members of C classes using SWIG symbol Ref ELSA MDEV 06001 ONERA Version Edition 1 0 elsA Date Jan 10 2006 Page 70 75 Design and Implementation Tutorial DSNA 13 2 1 Technical details 13 2 1 1 Static linking With static linking you rebuild the scripting language interpreter with extensions The process involve
82. ts on cell centers or OperGradInt object to compute gradients on interface centers FxdF lux and FxdFluxInt are abstract classes which are respectively user of OperGrad and OperGradInt objects All of these operators use Strategy 1 and provides with an implementation of compFlux and computeOne Border 9 4 Sou Module All the classes of the Sou Module inherit from the OperSource class SouDts class is responsible for source terms associated with Dual Time Stepping DTS method It gives a specific implementation of the compute method Here no distinction is done between the interior and the border region e SouTransp class is responsible for source terms associated with transport equation of turbulence model It gives a new implementation of the compute method but delegates the computation to TurTransp objects e SouRelFrameAbs and SouRelFrameRel classes responsible for source term associated with relative frame and respectively absolute or relative velocity formulation 9 5 How to introduce a new operator The developer does not have to know the whole elsA kernel Instead he can focus on a small number of well defined tasks e Introduce a new class in the Oper hierarchy deriving from a base class for example deriving from OperF lux if it is a new flux operator e Define the auxiliary field s required and implement the method to compute it them e Implement a small number of virtual methods compute c
83. two grids TmoSolver Base computeRhs 11 7 Agt component Affine Geometry Transformation Agt module Provides all services required to compute affine geometric transformation permutation translation and rotation e change of reference frame between current and opposite grids e periodicity application 11 7 1 Change of reference frame e AgtIndice is responsible for integer indices computations e AgtFrame deals with reference frames Ref ELSA MDEV 06001 Version Edition 1 0 elsA Date Jan 10 2006 Page 60 75 Design and Implementation Tutorial 11 7 2 Example AgtIndice translation 1 2 3 AgtFrame 2 3 1 translation 2 3 1 gt 0 0 1 d 0 0 1 0 _i 2 gt _i corresponds to the O_j axis j 3 gt _j corresponds to the O_k axis k 1 gt _k corresponds to the O_i axis 11 7 3 Geometric transformations e AgtCoord manages coordinates real e AgtTransfo provides a matrix transformation rotation translation 11 7 4 Example AgtCoord Point Led 2 la y 2 3 3 0 0 AgtCoord Vector 1 1 2 2 3 3 1 0 ONERA DSNA ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 61 75 12 FACTORY COMPONENT 12 1 Fact component encapsulating object creation details The Fact component is an important architectural component It is responsible for the dynamic creation of all kernel obj
84. ule elsA py Python module 16 elsA x 14 encapsulation 11 74 Eos Equation of State explicit 7 external coupling 16 external coupling internal Fe link is to index s alphabetical headings 67 Fact layer Fact module factory factory concept 57 Fld Fld element access Fld numerical values container 22 FldArray i FidField 22 Fidint 22 FidNode 22 fluid structure coupling 14 flux 5 ONERA DSNA Design and Implemen Fortran argument passing from C 24 Fxc 42 Fxc Convective Flux 20 FxcCenter FxcMatNumDiss FxcScaNumDiss FxcUpwind Fxd 43 Fxd Diffusive flux 20 G link is to index s alphabetical headings Geo GeoAdrF h 30 GeoGrid Geometry layer 20 ghost cell 27 ghost geometric entities ghost interface ghost node global quantities post processing 17 global timestep 7 gradient grid 6 grid interface 6 grid motion grid node 6 GUI 15 H link is to index s alphabetical headings handle Harten entropic correction Harten s correction 6 HMR 20 link is to index s alphabetical headings ICEM CFD 14 implicit algorithm y inheritance inheritance hierarchy 13 initial condition interactive text mode 15 interface interior IRS implicit time integration algorithm 7 link is to index s alphabetical headin
85. ume formulation Metrics volume of cells surface of cell interfaces Topological relations between geometrical entities cells interfaces nodes Recently ghost cells have been introduced in elsA Thanks to these ghost cells most indirections have been suppressed in computational loops and important improvement in CPU efficiency has been obtained Dtw gathers all distance and boundary layer integral thickness computations Mask defines concepts used in the Chimera technique Join deals with multi block computations Multi zone interface connectivity can be 1 to 1 abutting 1 to n abutting or mismatched abutting Physical model layer It includes two modules Eos computes quantities such as pressure temperature laminar viscosity Tur deals with turbulence modeling and transition prediction 5 2 4 Space Discretization layer This layer is responsible for the computation of the equation terms and of the boundary conditions Oper each operator class is responsible for the computation of a single term in the CFD equations Fxc convective fluxes F xd diffusive fluxes Sou source terms Bnd deals with boundary conditions ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 25 75 5 2 5 Solver layer This layer is responsible for e Rhs builds the right hand side of the equation system e Lhs gathers implicit methods
86. vergence form flux density evaluated at cell centers is com puted In case of skew symetric form flux is computed directly on interfaces 9 2 2 Dissipative operators In the resolution of the mean flow system one can choose between scalar artificial dissipation flux class FxcScaNum Diss or matrix artificial dissipation flux class FxcMatNumDiss FxcScaNumDiss class defines new implemen tations of both compF lux and computeOneBorder In the resolution of the turbulent system e SA kernel provides two operators to implement the artificial dissipative term e FxcRoeCorr based on MinMod limiter and Harten s entropy correction e FxcScaNumDiss is only available for the Spalart Allmaras turbulent model 9 2 3 Upwind convective operators FxcUpwind inherits from OperF lux class and has two important attributes e FxcLimiter _limiter limiter function to complete MUSCL extrapolation for second order schemes e FxcConvFunc _convFunc the convective function which given left and right states compute convective fluxes on interfaces The strategy used for the computation is close to Strategy 2 FxcUpwind defines a new implementation of the com pute method 1 Primitive variables are computed from conservative variables 2 Left and right values at the cell boundaries are evaluated taking into account the boundary condition at each side of a boundary interface If necessary spatial second order accuracy calculations a li
87. w symetric convective flux such a suitable extrapolation should fill the ghost cells with except for a few ghost interfaces at the beginning and at the end ONERA elsA Ref ELSA MDEV 06001 ee Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 51 75 2 wol w0 where w0 is the conservative state in the real cell adjacent to the considered boundary But several problems could appear e values extrapolated in ghost cells are not necessary physically correct ex negative values of pressure or tempera ture e ghost cells filling would depend on the considered flux operator In conclusion this third step allow to control the flux computation on border interfaces what is fundamental in viscous computations In the following we will note wCons the object of type F1dCe11F storing the conservative variables in cell centers We will discuss the two virtual methods compBoundaryValues and compBoundaryValuesInGhost 10 1 3 Additional details In order to perform Step 1 each boundary class has to implement the virtual method void compBoundaryValuesInGhost FldCellF amp wCons where wCons is used both as input and output This can be considered as a preparation stage to the flux computation Step 3 consists of two stages 1 Knowing the conservative variables on all integration grid points centers of cells compBoundaryValues computes wb1 Each boundary condition has to i
88. x object responsible for the boundary under consideration 2 wb1 is then used to correct the flux computation on the interfaces of the border of the operator The implementation of this last stage is dependent on the concrete flux operator under consideration Generally it uses modified formulas issued from the standard treatment 9 1 5 OperSou abstract class OperSou is an abstract class for source terms This class inherits from OperTerm class 9 2 Fxc Module The Fxc module gathers the concrete centered and upwind convective operators and the artificial dissipation operators ONERA Ref ELSA MDEV 06001 elsA Version Edition 1 0 Date Jan 10 2006 DSNA Design and Implementation Tutorial Page 47 75 9 2 1 Centered convective operators In elsA the centered convective discretization is written as the sum of a simple centered discretization and a numeri cal dissipation term FxcCenter class inherits from OperFlux class and provides with the implementation of the convective centered fluxes The compF lux method is implemented in FxcCenter so that e FxcCenter is able to compute the convective centered flux for mean flow or turbulent system e FxcCenter is able to compute the convective centered flux according to divergence form or a skew symmetric form However since computeOneBorder is not implemented in FxcCenter OperFlux computeOne Border is used To perform the flux computation on all interfaces for the di
89. y through composition 11 4 Interface 11 4 1 Main methods e prepare objects before use prepareJoin e retrieve values cell interface of the opposite grid and put these values in ghost cells of the current grid get IN Values current grid opposite block ONERA elsA DSNA Design and Implementation Tutorial 11 5 Preparation of join for parallelism JoinParBuffer 11 5 1 singleton design pattern e allocates memory for a buffer object JoinBufferP e prepares the buffer object to send and receive data e holds received data until used 11 5 2 Main methods 1 fill buffers with data to send pushCellField 2 send buffers to other processor sendBuf fer 3 get received data get CellBuf fer 4 delete buffers clearBuffer 11 6 Time progress Ref ELSA MDEV 06001 Version Edition 1 0 Date Jan 10 2006 Page 59 75 1 Send and receive conservative variables to and from other processors TmoSetOfSolver fillInGhost Cells 2 Compute all fields pressure spectral radius gradients TmoSolverBas prepareRhs 3 Send and receive all fields to and from other processors TmoSetOfSolver prepareOtherValues 4 Compute fluxes fluxes are computed using Strategy 2 cf since ghost cells are filled in Each grid com putes its own fluxes and conservation is ensured since values are equivalent in the

Download Pdf Manuals

Related Search

Related Contents

10 - Airside Design.indd - Oregon State Library: State Employee  SAILING CRUISER METHOD  Bedienungsanleitung  VeriSilicon GSMC 0.15um Syn. DROM Compiler User's Guide  Une performance fascinante. - Accu-Chek  Audiovox VODEXL10 Owner's Manual  bio Publicidez! biblio  OSM-023 Sucker Rod Elevator - Al  DealBook® for iPad®  URBIA Green - Chaffoteaux  

Copyright © All rights reserved. Failed to retrieve file