openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-06-23T07:39:56Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/588Draft: New renumbering based on Hamiltonian path2023-06-23T07:39:56ZAlon ZameretDraft: New renumbering based on Hamiltonian path### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visi...### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visits each cell exactly once. The Hamiltonian path approach tries to find such a path and renumber the mesh accordingly. This method ensures that after the mesh renumbering, consecutive cells in memory will likely share a common geometrical face. This in turn may allow for more efficient memory access and better vectorization performances when traversing the mesh.
![2D_Cylinder_Hpath](/uploads/90b36b3ca4136da32aaa93090c9300c0/2D_Cylinder_Hpath.png)
### Usage
Described below is the renumberMethodDict example used to apply Hamiltonian path renumbering:
```
method hpath;
hpathCoeffs
{
layered true;
}
```
The 'layered' argument (default true) controls whether the algorithm will separate the mesh cells into different 'layers' (otherwise, all cells are considered to be within the same layer). The layer separation approach is known to obtain better results and improved run-time for 3D cases, while 2D cases where a simpler Hamiltonian path may exist will benefit from avoiding the layer separation.
The algorithm will than try to find an Hamiltonian path traversing through all the cells sharing the same layer, and report the Hamiltonian path accuracy obtained.
The path accuracy is defined as the percentage of consecutive cells in the renumbered order that share a common face.v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/587Draft: New decomposition method (multiNodeDecomp)2023-06-23T07:40:04ZAlon ZameretDraft: New decomposition method (multiNodeDecomp)### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users contro...### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users control over the properties of each node within the decomposition tree, as opposed to multi-level decomposition which supports level-based modifications.
### Details of new decomposition method
The multiNodeDecomp method adds the following capabilities:
1. Support decomposition to un-even nodes by changing the number of children of each node. For example:
```
multiNodeCoeffs {
method metis;
domains (3 4);
domains[0] (8);
}
```
In the example above, the mesh will be decomposed into 3 domains, where the first domain (domain[0]) will be further decomposed into 8 subdomains, while the remaining 2 domains will be decomposed into 4 subdomains only.
This will result in a total of 20 subdomains.
Note that the user passes a list value, which allows to have a different number of levels under different branches of the decomposition tree.
2. Simplified interface for decomposition weights - uniform/relative weight distribution may be used to initialize the weight of each node. The user may later overwrite any of the nodes weight.
```
weightsInitialization relative;
weight[0][3] 2;
```
'Uniform' initialization will recursively set all of the nodes weights to 1, while the 'Relative' initialization sets each nodes weight to the number of leaves in its decomposition subtree.
The weight of a node is then used during its parent's decomposition to control the sub-mesh size it will receive.
3. Modify the nodes decomposition method:
```
method[2] {
method scotch;
coeffs {
...
}
}
```
This will overwrite the method of the third subdomain of the root to use scotch and the given coefficients.
### Syntax
multiNodeDecomp supports setting the decomposition properties above on a level scope (parameter[] value) or on a node scope (parameter[#nodeIndex] value).
The square brackets indicate indices of the children we want to modify (0 based indexing). The user may specify ranges by using a hyphen ([0-3]) or specifying all of the children by using empty brackets ([]).v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/511Update of interIsoFoam and isoAdvection extending to work with porous media2021-12-13T17:11:35ZJohan RoenbyUpdate of interIsoFoam and isoAdvection extending to work with porous mediaExtension of isoAdvection and interIsoFoam to deal with a porous medium
occupying part of the cell volumes and described by a porosity volScalarField
taking values larger than 0 (cell full of solid) and less than or equal to one
(cell f...Extension of isoAdvection and interIsoFoam to deal with a porous medium
occupying part of the cell volumes and described by a porosity volScalarField
taking values larger than 0 (cell full of solid) and less than or equal to one
(cell full of fluid).
The current implementation deals with both the advection part of the problem
and the modification of the UEqn (p_rghEqn needs no changes).
The aim of the implementation is to make it invisible to the user who does not
work with porosity both in terms of efficiency, memory usage and code complexity.
It would be preferable if the required interIsoFaom changes could be done without
touching the solver files, e.g. implementing the UEqn modifications as an fvOption.
This seems to be impossible because we need to modify the existing terms in the
UEqn and the fvMatrix is build from right to left meaning the fvOption cannot
touch e.g. the fvm::div(rhoPhi,U)-term. The chosen solution is therefore to add an
#include "UEqnAddPorosity.H" line to the UEqn.H file AFTER the UEqn is constructed.
The activation of porosity treatment is controlled by a bool parameter called
porosityEnabled in a constant/porosityProperties dictionary. This is disabled by default.
If it is enabled the user must provide a porosity volScalarField in the 0 time dir.
The isoAdvection class has two new data members: porosityPtr_ to the porosity field,
is nullptr by default, and a bool called porosityEnabled_ (default false) read
from the constant/porosityProperties by the isoAdvection constructor.
It has been necessary to introduce "if (porosityEnabled_)" lines various places in
the code but most places this is not inside loops over cells or faces so it is
cheap. An exception is in the isoAdvection bounding functions but these are only
called for very few cells so this should not be very expensive.
At this point I am not sure that the interplay with the source terms Su and Sp.
These should probably also be divided by porosity when alpha is updated.
The interIsoFoam solver now reads the porosityEnabled bool in constant/
porosityProperties,reads the porosity field if needed and the porosity parameters
for the Darcy-Forchheimer force and added mass force from the constant/
porosityProperties dict.
I have introduced a porousAlphaCourantNo.H and porousCourantNo.H file as
replacements for alphaCourantNo.H and CourantNo.H to correct the adaptive time
stepping so it accounts for the increased flow velocity in porous cells if
porosity is enabled.
Also the "Phase-1 volume fraction" write out has been modified to take porosity
properly into account.
There are two test cases included:
1. discInConstantPorousFlow which is the same as discInConstantFlow but with a
porous zone in the middle of the domain where the disc elongates and moves faster.
2. A porousDamBreak testing porosity implementation and comparing with exp. data.
This code contribution is joined work between:
- Konstantinos Missios
- Niels Gjøl Jacobsen
- Henning Scheufler
- Johan Roenby
Johan Roenby, December 2021v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/504Added functionality for smoothing the sensitivity derivatives2021-12-09T09:18:37ZAndrew HeatherAdded functionality for smoothing the sensitivity derivatives### Summary
Adjoint-based sensitivity maps can now be optionally smoothed using a Laplace-Beltrami operator.
When computing sensitivity maps on surface meshes generated from industrial
geometries, the outcome might appear noisy, especi...### Summary
Adjoint-based sensitivity maps can now be optionally smoothed using a Laplace-Beltrami operator.
When computing sensitivity maps on surface meshes generated from industrial
geometries, the outcome might appear noisy, especially if a volume-to-surface
approach is used for meshing, like the one utilised by snappyHexMesh. Even
though the sensitivity map is technically correct, the noisy patterns that
appear might make the extraction of useful information challenging.
This new feature facilitates the interpretation of the sensitivity map in such cases.
### Details of new models
The sensitivity map can be smoothed using a Laplace-Beltrami operator of the form
```math
\tilde{m} - \frac{\partial}{\partial x_j}\left[R^2\frac{\partial \tilde{m}}{\partial x_j}\right] = m
```
where $`\tilde{m}`$ is the smoothed sensitivity map, $`m`$ is the original
sensitivity map and $`R`$ a smoothing radius. The latter is computed as a
multiple of the average 'length' of the boundary faces, if not provided by the
user explicitly.
The above-mentioned equation is solved on the part of the surface mesh defined
by the patches on which the sensitivity map is computed, using the finiteArea
infrastructure of OpenFOAM.
If an faMesh is provided, it will be used; otherwise it will be created on the
fly based on either an faMeshDefinition dictionary in system or one constructed
internally based on the sensitivity patches.
From an optimisation point of view, this smoothing can alternatively be seen as computing the sensitivity derivatives $`\frac{\delta J}{\delta b_i}`$ of the objective function $`J`$ w.r.t. a different set of design variables $`b_i, i\in[1,N]`$, defined as
```math
x_i = x_i^{init} + \tilde{b_i} \\
\tilde{b_i} - \frac{\partial}{\partial x_j}\left[R^2\frac{\partial \tilde{b_i}}{\partial x_j}\right] = b_i
```
where $`x_i`$ are the coordinates of the updated geometry and $`\tilde{b_i}`$ a smooth displacement field. In other words,
no loss of accuracy is incurred by the smoothing; instead, sensitivities are computed w.r.t. a different set of design variables.
### Examples
An example of a noisy sensitivity map and its smoothed variants using different $`R`$ values is presented below, taken from the updated motorbike tutorial under
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike,
![portFront](/uploads/c7a772e62d98ea0a34414c7cd05ffa1c/portFront.png)
![port](/uploads/ec1bb55d3255e3dd403818ec21c09245/port.png)
![top](/uploads/9ddc8a60520cedba99780974f71e422f/top.png)
### Risks
No risks are foreseen. To enable the smoothing, the `smoothSensitivities` bool should be set to `true`, along with some optional entries.
```
sensitivities
{
type surfacePoints;
patches (motorBikeGroup);
includeSurfaceArea false;
smoothSensitivities true;
meanRadiusMultiplier 10; // Optional, defaults to 10. Controls the smoothing radius
iters 2000; // Optional, defaults to 500
}
```
Since the Laplace-Beltrami equation is solved using the finiteArea framework, `faSchemes` and `faSolution` should be present under `system`.
The smoothed sensitivity map is written in the `smoothedSurfaceSens + adjointSolverName + sensitivityFormulation` file, under the current time-step.
### References
The notion of sensitivity smoothing using a Laplace-Beltrami operator was used throught the seminal works of Antony Jameson. A reference can be found in
Vassberg J. C., Jameson A. (2006). Aerodynamic Shape Optimization Part I: Theoretical Background. VKI Lecture Series, Introduction to Optimization and Multidisciplinary Design, Brussels, Belgium, 8 March, 2006.v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/450ENH: update geoVoF module (#2076)2021-06-24T16:48:11ZHenning ScheuflerENH: update geoVoF module (#2076)@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the test...@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the testsuite is not included in the commits but is available in issue #2076.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/393ENH: BilgerMixtureFraction: New function object2020-12-15T08:55:31ZKutalmış BerçinENH: BilgerMixtureFraction: New function object### Summary
A contribution by a community member, @g3.
See https://develop.openfoam.com/Development/openfoam/-/issues/1915
### Details of new models (If applicable)
See https://develop.openfoam.com/Development/openfoam/-/issues/1915...### Summary
A contribution by a community member, @g3.
See https://develop.openfoam.com/Development/openfoam/-/issues/1915
### Details of new models (If applicable)
See https://develop.openfoam.com/Development/openfoam/-/issues/1915#note_49598
### Risks
N/A
### ~~WIP issues~~
- ~~The FO needs info from `specieComposition()`: see [the line](https://develop.openfoam.com/Development/openfoam/-/blob/feature-Bilger-mixture-fraction-fo/src/thermophysicalModels/reactionThermo/functionObjects/BilgerMixtureFraction/BilgerMixtureFraction.C#L278)~~
- ~~The function can be called through `ThermoType` (i.e. `thermoPhysicsTypes.H`), but there are too many template-template classes thereat. This would create a very long and thus annoyingly redundant piece of repeating code.~~
- ~~Instead, `ReactionThermo` could be used. But `ReactionThermo` does not have access to the info. Even in `TDACChemistryModel`, `specieComposition` was fetched through `ThermoType`.~~
- ~~Note that if `ReactionThermo` is used, some solvers may not run the FO.~~
[Bat-signal](https://en.wikipedia.org/wiki/Bat-Signal): @andy @Sergiov2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/349CONT: Addition of compressibleIsoInterFoam and PLIC2020-06-22T11:17:41ZSergio FerrarisCONT: Addition of compressibleIsoInterFoam and PLICContribution by Henning Scheufler and Johan Roenby. Headers reviewed. Rebased to the latest develop.
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tuto...Contribution by Henning Scheufler and Johan Roenby. Headers reviewed. Rebased to the latest develop.
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tutorials associated with the solvers
This implementation was carried out by Henning Scheufler (DLR) and Johan
Roenby (DHI), following :
\verbatim
Henning Scheufler, Johan Roenby,
Accurate and efficient surface reconstruction from volume fraction data
on general meshes, Journal of Computational Physics, 2019, doi
10.1016/j.jcp.2019.01.009
\endverbatim
The integration of the code was carried out by Andy Heather and Sergio
Ferraris from OpenCFD Ltd.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/330SUBMODULE: added OpenQBMM submodule - see #15222020-01-25T02:11:02ZAndrew HeatherSUBMODULE: added OpenQBMM submodule - see #1522### Summary
Adds the OpenQBMM library from https://www.openqbmm.org/
OpenQBMM is a suite of solvers to simulate polydisperse multiphase flows using
Quadrature-Based Moment Methods (QBMM).
Main author: Alberto Passalacqua @alber...### Summary
Adds the OpenQBMM library from https://www.openqbmm.org/
OpenQBMM is a suite of solvers to simulate polydisperse multiphase flows using
Quadrature-Based Moment Methods (QBMM).
Main author: Alberto Passalacqua @albertop
### Details of new models (If applicable)
OpenQBMM implements methods to describe polydisperse multiphase flows, from the simplest size evolution of non-inertial particles in a carrier fluid to more complex cases with bubbles in a gas-liquid system and inertial particles in a gas-particle flow. These capabilities are implemented in a suite of solvers, among which:
- `pbeFoam` solves a population balance equation in a single control volume. This solver is useful to test kernel functions in the population balance equation and to solve spatially homogeneous problems. Example cases can be found in OpenQBMM/validation/pbeFoam/ which show the validation cases discussed in E. Madadi-Kandjani, A. Passalacqua, An extended quadrature-based moment method with log-normal kernel density functions, Chemical Engineering Science. 131 (2015) 323–339. https://doi.org/10.1016/j.ces.2015.04.005.
- `pbeTransportFoam` allows a frozen flow field to be used to solve a population balance equation with pre-imposed flow motion. A validation case is available in OpenQBMM/validation/pbeTransportFoam/serraTaylorCouette/ and discussed in A. Passalacqua, F. Laurent, E. Madadi-Kandjani, J.C. Heylmun, R.O. Fox, An open-source quadrature-based population balance solver for OpenFOAM, Chemical Engineering Science. 176 (2018) 306–318. https://doi.org/10.1016/j.ces.2017.10.043.
- `buoyantPbePimpleFoam` allows a transient flow with population balance equation to be modelled.
- `polydisperseBubbleFoam` is a specialized solver for gas-liquid flows with evolution of the bubble size due to coalescence and breakup. Bubbles can have a velocity distribution also accounting for polycelerity, with bubbles with different sizes in the same control volume allowed to have different velocities. Example cases are available in OpenQBMM/validation/polydisperseBubbleFoam/ while the implementation is discussed in the article J.C. Heylmun, B. Kong, A. Passalacqua, R.O. Fox, A quadrature-based moment method for polydisperse bubbly flows, Computer Physics Communications. 244 (2019) 187–204. https://doi.org/10.1016/j.cpc.2019.06.005.
- `denseAGFoam` implements an anisotropic Gaussian model for dense gas-particle flows. Implementation details are discussed in B. Kong, R.O. Fox, A solution algorithm for fluid–particle flows across all flow regimes, Journal of Computational Physics. 344 (2017) 575–594. https://doi.org/10.1016/j.jcp.2017.05.013.
- The solvers in the `velocityDistribitionTransport` implement quadrature-based moment methods for velocity distributions. These methods are suitable to describe disperse flows with non-equilibrium velocity distributions, such as crossing jets of particles or droplets. The `diluteVdfTransportFoam` solver implements the quadrature-based velocity distribution transport algorithm for a disperse phase, not coupled to a carrier fluid. One-way coupling between the disperse phase and the carrier fluid is implemented `oneWayCoupledVdfTransportFoam`. In both solvers, the particle size can evolve in space and time and particles can interact through collisions.
### Risks
Low - added as a submodulev2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/269Integration adjoint2019-06-19T21:07:00ZAdminIntegration adjoint## New adjoint optimisation and tools
A set of libraries and executables creating a workflow for performing
gradient-based optimisation loops. The main executable (adjointOptimisationFoam)
solves the flow (primal) equations, followe...## New adjoint optimisation and tools
A set of libraries and executables creating a workflow for performing
gradient-based optimisation loops. The main executable (adjointOptimisationFoam)
solves the flow (primal) equations, followed by the adjoint equations and,
eventually, the computation of sensitivity derivatives.
Current functionality supports the solution of the adjoint equations for
incompressible turbulent flows, including the adjoint to the Spalart-Allmaras
turbulence model and the adjoint to the nutUSpaldingWallFunction, [1], [2].
Sensitivity derivatives are computed with respect to the normal displacement of
boundary wall nodes/faces (the so-called sensitivity maps) following the
Enhanced Surface Integrals (E-SI) formulation, [3].
The software was developed by PCOpt/NTUA and FOSS GP, with contributions from
- Dr. Evangelos Papoutsis-Kiachagias,
- Konstantinos Gkaragounis,
- Professor Kyriakos Giannakoglou,
- Andy Heather
and contributions in earlier version from
- Dr. Ioannis Kavvadias,
- Dr. Alexandros Zymaris,
- Dr. Dimitrios Papadimitriou
[1] A.S. Zymaris, D.I. Papadimitriou, K.C. Giannakoglou, and C. Othmer.
Continuous adjoint approach to the Spalart-Allmaras turbulence model for
incompressible flows. Computers & Fluids, 38(8):1528–1538, 2009.
[2] E.M. Papoutsis-Kiachagias and K.C. Giannakoglou. Continuous adjoint methods
for turbulent flows, applied to shape and topology optimization: Industrial
applications. 23(2):255–299, 2016.
[3] I.S. Kavvadias, E.M. Papoutsis-Kiachagias, and K.C. Giannakoglou. On the
proper treatment of grid sensitivities in continuous adjoint methods for shape
optimization. Journal of Computational Physics, 301:1–18, 2015.
## Integration
Integration into the official OpenFOAM release by OpenCFDv1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/205Feature iso advector AMR2018-06-13T13:44:39ZJohan RoenbyFeature iso advector AMR1. interIsoFoam rewritten based on the new interFoam including DyM functionality.
2. isoAdvection, isoCutFace and isoCutCell classes modified to work with AMR (dynamicRefineFvMesh).
3. Refactoring of isoAdvection, isoCutFace and isoCut...1. interIsoFoam rewritten based on the new interFoam including DyM functionality.
2. isoAdvection, isoCutFace and isoCutCell classes modified to work with AMR (dynamicRefineFvMesh).
3. Refactoring of isoAdvection, isoCutFace and isoCutCell (not related to AMR functionality).
4. Included damBreakWithObstacle test case for interIsoFoam with dynamicRefineFvMesh.
5. Added discInConstantFlowCyclicBC case for interIsoFoam to confirm proper behaviour with cyclic BC's (not AMR related).
I have tested the changes by compiling, running all interIsoFoam tutorials and verified visually that everything looks OK.
Known issue: isoCutFace sometimes gives a warning related to an edge being cut multiple times by the isoFace (There are around 20 such warnings in the damBreakWithObstacle log). It does not seem to have any effect on the results. I have not so far been able to locate the cause of these warnings.
Best regards
Johanv1806AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/182WIP: Integration of IH Cantabria wave modelling contributions2019-10-03T10:38:02ZAdminWIP: Integration of IH Cantabria wave modelling contributions## New code
New wave generation model:
- `streamFunction`: based on Fenton's Fourier approximation
New interFoam-based solver:
- `interPorousFoam`: alternative method to include porosity effects, to be used with new `fvOptions` (se...## New code
New wave generation model:
- `streamFunction`: based on Fenton's Fourier approximation
New interFoam-based solver:
- `interPorousFoam`: alternative method to include porosity effects, to be used with new `fvOptions` (see below)
New `fvOptions`:
- `multiphasePorositySource`: porosity for multiphase flows
- `mangrovesSource`: mangrove interaction, i.e. drag and turbulence contributions for k-epsilon based models
## Test cases:
- interPorousFoam/porousDamBreak
- interPorousFoam/mangroves
## References:
Solitary wave attenuation by vegetation patches.
Maza, M, Lara, J.L., & Losada, I.J. (2016)
Advances in Water Resources. Vol.98, pp. 159-172
https://doi.org/10.1016/j.advwatres.2016.10.021
Tsunami wave interaction with mangrove forests: A 3-D numerical approach.
Maza, M, Lara, J.L., & Losada, I.J. (2015)
Coastal Engineering. Vol.98, pp. 33-54
https://doi.org/10.1016/j.coastaleng.2015.01.002
## Code integration
- Initial code supplied in commits e0682d67 and 2124eb88; and integrated into OpenFOAM by OpenCFDv1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/119INT: Integration of isoAdvector and supporting material2017-06-21T16:22:26ZAdminINT: Integration of isoAdvector and supporting materialCommunity contribution from Johan Roenby, DHI
IsoAdvector is a geometric Volume-of-Fluid method for advection of a
sharp interface between two incompressible fluids. It works on both
structured and unstructured meshes with no requir...Community contribution from Johan Roenby, DHI
IsoAdvector is a geometric Volume-of-Fluid method for advection of a
sharp interface between two incompressible fluids. It works on both
structured and unstructured meshes with no requirements on cell shapes.
IsoAdvector is as an alternative choice for the interface compression
treatment with the MULES limiter implemented in the interFoam family
of solvers.
The isoAdvector concept and code was developed at DHI and was funded
by a Sapere Aude postdoc grant to Johan Roenby from The Danish Council
for Independent Research | Technology and Production Sciences (Grant-ID:
DFF - 1337-00118B - FTP).
Co-funding is also provided by the GTS grant to DHI from the Danish
Agency for Science, Technology and Innovation.
The ideas behind and performance of the isoAdvector scheme is
documented in:
Roenby J, Bredmose H, Jasak H. 2016 A computational method for sharp
interface advection. R. Soc. open sci. 3: 160405.
[http://dx.doi.org/10.1098/rsos.160405](http://dx.doi.org/10.1098/rsos.160405)
Videos showing isoAdvector's performance with a number of standard
test cases can be found in this youtube channel:
https://www.youtube.com/channel/UCt6Idpv4C8TTgz1iUX0prAA
Project contributors:
* Johan Roenby <jro@dhigroup.com> (Inventor and main developer)
* Hrvoje Jasak <hrvoje.jasak@fsb.hr> (Consistent treatment of
boundary faces including processor boundaries, parallelisation,
code clean up
* Henrik Bredmose <hbre@dtu.dk> (Assisted in the conceptual
development)
* Vuko Vukcevic <vuko.vukcevic@fsb.hr> (Code review, profiling,
porting to foam-extend, bug fixing, testing)
* Tomislav Maric <tomislav@sourceflux.de> (Source file
rearrangement)
* Andy Heather <a.heather@opencfd.co.uk> (Integration into OpenFOAM
for v1706 release)
See the integration repository below for the full set of changes
undertaken as part of the integration into OpenFOAM v1706
https://develop.openfoam.com/Community/Integration-isoAdvectorVersion v1706https://develop.openfoam.com/Development/openfoam/-/merge_requests/118Integration of rhoPimpleAdiabaticFoam from CFD Sofware E+F GmbH2017-06-29T20:02:26ZSergio FerrarisIntegration of rhoPimpleAdiabaticFoam from CFD Sofware E+F GmbHSolver for low Mach no. flows with adiabatic thermodynamics and updated
pressure-velocity coupling given by the RCM interpolation procedure
described in
Knacke, T. (2013).
Potential effects of Rhie & Chow type interpolation...Solver for low Mach no. flows with adiabatic thermodynamics and updated
pressure-velocity coupling given by the RCM interpolation procedure
described in
Knacke, T. (2013).
Potential effects of Rhie & Chow type interpolations in airframe
noise simulations. In: Schram, C., Dénos, R., Lecomte E. (ed):
Accurate and efficient aeroacoustic prediction approaches for
airframe noise, VKI LS 2013-03.
Original code supplied by Thilo Knacke, CFD Software E+F GmbH
contact: info@cfd-berlin.com
Integrated into OpenFOAM by OpenCFD Ltd.Version v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/482BUG: DMD: write snapshot0 at start times2021-08-04T09:23:51ZKutalmış BerçinBUG: DMD: write snapshot0 at start times### Summary
* 4cb6bc83f0 - ENH: makeSolidReaction: modify macros to allow new models <Kutalmis Bercin>
* 4afdfe756e - TUT: hopper: parameterise blockMeshDict content (#2134) <Bas Nieuwboer>
* 4c96647af2 - BUG: DMD: write snapshot0 at s...### Summary
* 4cb6bc83f0 - ENH: makeSolidReaction: modify macros to allow new models <Kutalmis Bercin>
* 4afdfe756e - TUT: hopper: parameterise blockMeshDict content (#2134) <Bas Nieuwboer>
* 4c96647af2 - BUG: DMD: write snapshot0 at start times (fixes #2122) <Kutalmis Bercin>
### Resolved bugs (If applicable)
EP#1413; EP#1414; EP#1629
#2122
### Risks
- For 4afdfe756e, negligible: https://develop.openfoam.com/Development/openfoam/-/issues/2134#note_53319
- For the others, N/AAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/387Miscellaneous code changes - Nov 202020-11-13T09:22:38ZKutalmış BerçinMiscellaneous code changes - Nov 20PS: approval/feedback please @mark @Sergio @andy @Prashant
heatTransferCoeff -> @SergioPS: approval/feedback please @mark @Sergio @andy @Prashant
heatTransferCoeff -> @SergioAndrew HeatherAndrew Heather