openfoam userconference 2014 berlin · in the next openfoam major release, enhanced ddes methods...

Copyright © ESI Group, 2013. All rights reserved.Copyright © ESI Group, 2014. All rights reserved.

OpenFoamUserConference 2014

Berlin

October 17, 2014

Copyright © ESI Group, 2014. All rights reserved.

1. DDES enhancements2. SnappyHexMesh Developments3. FoamyHexMesh4. Parallel operation5. Boundedness and MULES

目次


DDES Enhancements

After RANS, Detached-Eddy Simulation (DES) is becoming the new standard inindustry:

• Turbulence modelling is the principal accuracy bottleneck in CFD

• DES addresses this by resolving more and modelling less of the turbulent motion

• Enabled by increases in computing power


EC135 helicopter fuselage

• EU-funded CleanSky project ‘Helides’• RANS, URANS and DES compared

for complex helicopter fuselage at flight Reynolds number

• Configurations with and without landing skids, three angles of attack

• Blind comparison with experimental measurements

Simulation setup:

• Grids of 32M (with skids) generated using NUMECA HEXPRESS

• Spalding wall function, 𝑦𝑦+≈40• DDES based on Menter SST model• Hybrid convection scheme

DDES Enhancements


Prediction of wake topology

• Strong improvement of DES relative to RANS and URANS• Improved prediction of surface pressure in wake region

DDES Enhancements


Prediction of wake topology

DDES Enhancements


In the next OpenFOAM major release, enhanced DDES methods like SA-WALE-DDES and SA-σ-DDES will be available.

Improved DES methods appear promising:- Improved transition to turbulence in free and separated shear layers - Retains practical and robust nature of approach

DDES Enhancements

Presenter

Presentation Notes

SA = Spalart AllMaras �- WALE = Wall Adapting Local Eddy viscosity�- DDES = delayed detached eddy simulation It is well known that DES and similar RANS-LES approaches suffer from a significant delay of transition to turbulence in free and separated shear layers Con questi nuovi methodi la transizione alla turbolenza viene accelerate e risulta essere in maggior agreement con gli esperimenti.


Increasing the level of complexity


Increasing the level of complexity

Several wind directions are automatically tested to investigate which are the most dangerous wind directions with strong downdraft on the helideck (90% of accidents on oil-rigs are related to helipcoter accidents during landing and take-off).


Green Energies related Simulations

Fuel cells analysis

Liquid metal batteries for smart grid storage

http://openfuelcell.sourceforge.net/http://www.ieafuelcell.com/

To contribute and download

Presenter

Presentation Notes

「

http://openfuelcell.sourceforge.net/

http://www.ieafuelcell.com/



Solar Power Tower

Solver : buoyantPimpleFoam, Radiation: Viewfactor, Turbulence model : k-ω-SST


MEXICO project (Model Experiments In Controlled Conditions)


Measurements:between June-July 2014 Place:Large Scale Low Speed Facility (LLF) of the German Dutch Wind Tunnels (DNW)Objective:improve the quality of the database


SnappyHexMesh OF230 new features

Automatic gap refinement:

• Small gaps will form blockages• Difficult to refine manually• Instead: detect and increase surface refinement level

Presenter

Presentation Notes

if cells are not small enough it will block the gaps. You can always look at your mesh and find where to add additional refinement regions but is difficult and time consuming. Instead you can detect the small gaps and increase the refinement level automatically. So for example if you have a geometry floating very near to a surface, you can use automatic gap refinement and you will get some extra refinement in those small gaps. 5


Enhanced thin surface snapping:

• Snap to nearest surface location• Robust but can snap to ’wrong’ side• Instead: snap to nearest intersection


Presenter

Presentation Notes

Another improvement in version 2.3 is to do with snapping on thin surfaces. The current method just snap to the nearest point of nearest triangle of the nearest surface and try to minimize the amount of distorsion. So is quite robust but if you have a very thin surface you can end up snappying on the wrong side of the surface. When there are two surface very close together you can end up with snappying on the wrong side. So now if we detect a situation where 2 surfaces are very close together, we will search for the nearest intersection between the two surfaces, in order to avoid to snap on the wrong side. This is a pretty extreme case, you won't find it very frequently.�(In pratica si aiuta detettando quale sia l'intersezione piu' vicina tra le due superfici in modo da comprendere da che parte bisogna snappare)


Enhanced layer shrinking:

• Layers created by shrinking mesh and adding layers in gap• Shrinking algorithm uses distance between surfaces• . . . even if it is far away• Instead: limit distance with nMedialAxisIter


Presenter

Presentation Notes

The layer are added by shrinking the mesh. The shrink is done by using a medium surface algorithm�You can limit the amount of opposite surfaces that see each other, in this way Shriking and squash is limited to a smaller area.�[nota come nella figura nonOrthonality si riduca a zero dappertutto a patto di essere sufficientemente lontani (10 celle) dalla parete in cui e' stato inserito il boundary layer.]


Enhanced layer coverage statistics• fields with boundary values• . . . nSurfaceLayers number of layers• . . . thickness overall thickness• . . . thicknessFraction overall thickness as fraction of wanted thickness


Presenter

Presentation Notes

there are some additional statistics about the boundary layer coverage that we can post-process: we can easily see what number of layers, in the picture here is presented the fraction of the thickness, 0 means no layers have been added, 1 means that they have been added to the thickness you wanted, less means that there was not enough space.


Enhanced layer coverage statistics• table with statistics• . . . thickness overall thickness• . . . thicknessFraction overall thickness as fraction of wanted thickness


Presenter

Presentation Notes

you can get the same idea just in a table format.


In the next major release you can expect:

• Improved multi-region meshing• Improved feature snapping by splitting faces• Ability to add layers to faceZones• Compatibility with dynamic refinement/unrefinement

SnappyHexMesh Current Developments

Presenter

Presentation Notes

Now I will present some new features that are now under development:


Multi-region meshing• Note: regions are defined using cellZones• . . .with faceZones on region boundaries

Present behaviour• cellZones and faceZones specified through closed surfaces• . . . hard to do nested cellZones• . . . neighbouring cellZones create inconsistent faceZones

New behaviour• specify locationsInMesh (plural)• . . . each location defines a region (cellZone)• . . . faceZones between regions automatically synthesised• . . . optional patchType specification for faceZones• . . . optional locationsOutsideMesh to warn for leaks


Presenter

Presentation Notes

We will have a new locationOutsideMesh that will warn you for leaks, : in this way if there is a small gap and snappy enters through it, you will be warm and you can go back to repair your cad geometry without waiting the snappy finishes and discover the bad news in paraview. Moreover locationInMesh becomes plural locationsInMesh and multi-region meshing becomes easier.


Multi-region meshing• In practice: nested regions much easier. . .


Presenter

Presentation Notes

you give location and the name of the cellZone�none stands for location in mesh of the background mesh. �in the picture you can see several cellZone with one them (the light yellow one) encapsulated into another cellZone.



Snapping: splitting boundary faces in feature snapping• Present behaviour align boundary edges with feature edges• New behaviour split boundary faces to create new boundary edges

Presenter

Presentation Notes

Feature Snappying works by aligning boundary edges with surfaces edges�We can split boundary faces to create more edges so we have to distort mesh less. And this favorites a better layer insertion of the boundary layer. �For example in the flange picture on the left:�Blue means layers have not been added, red means layers have been added�By generating these boundary faces and by giving less distorsion to the mesh it becomes easier to add boundary layers (on the right almost everything becomes red -> layer insertion successful almost everywhere).


SnappyHexMesh Developments

Layers on faceZones

• Present behaviour layers only on patches• New behaviour layers on faceZones

Presenter

Presentation Notes

this is about layers on faceZones. Specificando anche faceZoneA ottieni i 2 layers on the left side. Specificando anche faceZoneA_slave ottieni i 2 layers anche nella porzione a destra.



Layers on faceZones

• Present behaviour layers only on patches• New behaviour layers on faceZones


SnappyHexMesh Research

Offset surface layer addition: • Layer addition currently uses mesh shrinking

snappyHexMesh layer addition

Presenter

Presentation Notes

you get areas where you cannot create enough space to insert the layer.



Offset surface layer addition• Layer addition currently uses mesh shrinking• Currently investigating using offset surfaces

Offset surface generation

Presenter

Presentation Notes

instead we can add an offset surface



Offset surface layer addition• Layer addition currently uses mesh shrinking• Currently investigating using offset surfaces• . . . uses extrudeMesh from geometry to offset surface

Adding extrusion between original mesh and geometry

Presenter

Presentation Notes

and then (slide 17-71) you use extrudeMesh to generate the layers.


foamyHexMesh

• foamyHexMesh fully functional and can be run in parallel• ... requires user evaluation!• Users should find many dictionary inputs familiar e.g. geometry

Presenter

Presentation Notes

Then FoamyHexMesh : it now outthere, fully functional and can be run in parallel. Please try it and submit eventual bug report to openFoam Mantis portal. Many dictionaries of foamy are quite similar to those of snappy. Some differences are that with foamyHexMesh You don't have to run any featureExtract method since aligning to the feature is so inherent to the method�(defaultCellSize = size of the mesh)


foamyHexMesh

• foamyHexMesh in action. . .

Animation illustrating the point motion algorithm

Presenter

Presentation Notes

The animation shows how the cells cristillize towards the hex-shape.


Parallel operation

Three steps to parallel matrix solvers

1 Processor patch communication• Swap neighbouring processor cell values

2 Solve each processor domain• Solve local cells

3 Calculate statistics (global reductions)• . . . Same on all processors• . . . By transferring to single processor and back

Presenter

Presentation Notes

Now some observations about parallel operation The three steps:�the first step is exchange of data between the neighbouring processors. �then second step: we use those values to solve the internal domain�third step: we calculate statistics where some values are sent to one processor, which then are sent back.


Parallel operation

Use more processors?• Fewer cells per domain, faster to solve?• . . .More communication in steps 1 and 3,• . . .More neighbouring processors,• . . .More processor faces v.s. cells (internal faces),• . . .More explicit meaning worse convergence

Worst case: agglomeration in GAMG solver• Combines (clusters of) cells• Number of cells at coarsest level very low (10?)• Some agglomeration of processor faces• At coarsest level CG solver

• Few cells• With lots of processor faces• Still same cost of global reductions

Presenter

Presentation Notes

So if we want to solver faster we will use more processors, fewer cells for domain should be quicker to solve. But these requires more communications in steps 1 and especially step 3, like for the global reduction of the statistic value residuals. This [statistic values] check time increases with the increasing number of domains. You must likely have worse decomposition, less cells, more processor faces, �The worst case will be GAMG solver because there you combine clusters of cells and you end up with very low number of cells at coarsest level. But at the same time you will have lots of processor faces and you still run on the same number of processors. [picture] As you agglomerate more complex meshes the ratio of the number of interfaces faces divided by number of Cells increases So the amount of communication increases. �As in the picture at 11 cluster rate number, without agglomeration you can end up with more than 4 processor faces per cell.


Parallel operation

• Few cells (work) with lots of processor faces (communication)• Agglomerate across processors!

• Remove communication• More implicitness, less iterations in CG solver• Idle unused processors

• At what level to agglomerate which processors• ‘Normal’, cell agglomeration: combine strongly coupled cells• Choice of processorAgglomerators

• none: no agglomeration, display statistics only• manual: select at what level which processors to combine• masterCoarsest: coarsest level on master processor• eager: at every level combine two neighbouring processors (keep number of

cells constant)• cellFaceRatio: uses faceAreaPair cell-agglomeration method, weighted on

number of inter-processor faces

Presenter

Presentation Notes

We have now a processorAgglomerator: is a set of algorithm that tells decide when to combine which processors. � The option "none" does not do anything, just bring a table,� the interesting one is masterCoarsest level that at the coarsest level send everything to master processor. � "eager" at every level can decide which processors communicate most to each other and can combine those


Parallel operation

masterCoarsest

Presenter

Presentation Notes

The picture here just show you two processors, we cluster our cells down to three cells for processor, and here the result that we get using the masterCoarsest algorithm


Parallel operation example

• 3.2M cells, pisoFoam• 23 nodes, varying from 1 core to 4 cores per node• 140k down to 35k cells per core• Cluster: Intel E5-1650, QDR Infiniband and Gigabit Ethernet• Using masterCoarsest processor agglomeration

Extract from fvSolution

Presenter

Presentation Notes

in this example we just choose the agglomeration method "masterCoarsest" that send everything to the master processor.�(in the p solver of fvSolution) we have the "agglomerator" that does cell agglomeration � agglomerator faceAreaPair;�and we have the "processorAgglomerator" that does processor agglomearation :� processorAgglomerator masterCoarsest;�nota come il numero di celle at the coarsest level nCellsInCoarsestLevel sia settato a 50, quindi visto che si parte da 35k cells per core, mi sembra che sia il 50 a determinare il fatto che poi il numero di Level (nel processo di clustering) venga 11. Avessi messo un nCellsInCoarsestLevel piu' piccolo, avresti ottenuto un numero di livelli piu' alto


Parallel operation example

Presenter

Presentation Notes

As you can see once we reach level 10 the masterCoarsest agglomerator send all cells to the master processor


Parallel Launch

• Effect of processor agglomeration

Presenter

Presentation Notes

The Infiniband results are practically coincidents, since the communication is very fast you don't get very much improvement after the agglomeration process. But in the case of a (la sigla TCP = transmission control Protocol) GigaBitEthernet connection where communication speed is lower, there is quite a difference�And the advantage in time is essentially due to the global reduction (less communication in the step 3 we where speaking above) you can make thanks to agglomeration.


Boundedness and MULES

MULES = Multi-dimensional Universal Limiter for Explicit Solution

FVM does not guarantee boundedness.

With MULES we can guarantee boundedness:- MULES explicit with sub-cycling- MULES implicit with limiter iteration- MULES predictor-corrector Recommended and available from OF220- MULES for 2nd-order transport - MULES for 2nd order time... UNDER DEVELOPMENT- MULES for non-orthogonal diffusion correction... UNDER DEVELOPMENT- MULES for coupled variables... UNDER DEVELOPMENT

The future of finite-volume for bounded properties is MULES.

- MULES introduces significant code complexity - requires some core reorganization of OpenFOAM to preserve convenient top-level finite-volume language and to ease maintenance.

Presenter

Presentation Notes

Finite Volume method guarantees conservation (what goes out of one cell must go into the neighbour cell) but it does not guarantee boundedness. For example in a multiphase solver, you could end up with a phase fraction that goes over 1. This would cause generation or removal of the other phase and generate unphysical density. One solution to avoid this problem is to apply MULES limiter to the fluxes. If we limit the fluxes we can guarantee boundedness and conservation. To integrate MULES into OpenFOAM currently openCFD is doing some core reorganization of OpenFOAM. Some of the required work is done like Mules explicit with sub-cycling that's done, that's been out from few years now. MULES implicit with limiter iteration is there but I would not recommended because MULES predictor corrector is better. Mules for second order transport yes, it's there. MULES for 2nd order time, this is now in progress. MULES for non-orthogonal diffusion correction is in progress. MULES for coupled variable is in progress (the MULES for coupled variables is required because with independent limiters tranport is incosistent and we get unphysical derived properties. But there is a solution. We construct the limiters for each of the variables and then we combine the limiters by minimizing over the coupled variable set. We apply the combined limiter to all coupled variables in the set). The future of finite-volume for bounded properties in Henry Weller view is MULES.


Final remarks

- All developments will be undertaken on behalf of the OpenFOAM foundation- Copyright transferred to the OpenFOAM Foundation - Released publicly under the GPLv3

For those interested in Discrete Particle Method:

Check MPPICFoam much faster than DPMFoam

Presenter

Presentation Notes

Of coarse all the previous developments presented will be released as usual under the public license GPLv3. For those intereste in Discrete Particle Method check MPPICFoam (Multi-Phase Particle In Cell): it has an approach that is similar to DPMFoam solver but it is much faster.


Thank you for

Your attention

Presenter

Presentation Notes

Potremmo poi anche aggiungere William Brainbridge and the news MPPICFoam much faster then DPM approach.

openfoam userconference 2014 berlin · in the next openfoam major release, enhanced ddes methods...

Documents