openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-11-23T09:43:22Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/556Draft: unsteady adjoint functionality2023-11-23T09:43:22ZVaggelis PapoutsisDraft: unsteady adjoint functionality### Summary
Introduced unsteady adjoint functionality. Currently supports full storage of the primal time-series or utilization of binomial checkpointing.
This branch also serves as a fetching point for the profiling and improvement o...### Summary
Introduced unsteady adjoint functionality. Currently supports full storage of the primal time-series or utilization of binomial checkpointing.
This branch also serves as a fetching point for the profiling and improvement of the unsteady adjoint code during the exaFoam project.
### Details of new models
- The unsteady adjoint equations are integrated backwards in time. Since each adjoint time-step requires the primal solution of that time-step to be known, schemes for managing the storage/retrieval of the entire flow series are necessary. These are implemented through the primalStorage class and its derived ones. The latter manipulate a new class of fields, called compressedGeometricFields, which provide hooks for compressing/decompressing a field during the time integration of the primal/adjoint equations. The method used for compressing/decompressing is run-time selectable.
- The current commit provides the shortGeometricField implementation which avoids the storage of patchFields that can be retrieved from the internalField (e.g. coupled, zeroGradient, symmetry, etc), to cut on the storage requirements. More elaborate compression approaches will be included in the future, during the exaFoam project.
- Two primalStorage options are included: compressedFullStorage and binomialCheckPointing.
- compressedFullStorage stores the entire flow time-series, potentially by compressing each time-step (only the above-mentioned short approach is available for the moment).
- binomialCheckPointing is based on the homonymous algorithm proposed in
\verbatim
Wang, Q., Moin, P., & Iaccarino, G..
Minimal Repetition Dynamic Checkpointing Algorithm for
Unsteady Adjoint Calculation (2009).
SIAM Journal on Scientific Computing, 31(4), 2549-2567.
10.1137/080727890,
\endverbatim
which stores the solution of the flow equations in a predefined
number of time-steps, named checkpoints. During the
backwards-in-time integration of the adjoint equations, if the
primal solution at a certain time-step is not available, it is
retrieved by re-computing the primal flow field starting from the
closest checkpoint. Checkpoints are optimally distributed
throughout the time-series to invoke the least number of flow
recomputations during the backwards-in-time solution of the
adjoint equations. Binomial checkpointing is the current state of
the art though its re-computation cost frequently amounts for an
extra solution of the flow equations in medium-to-large cases.
- The adjoint to the PISO and PIMPLE solvers, along with their solverControl variants, are additionally included.
- Objective functions are integrated in time, through appropriate entries in the dictionaries defining them.
Authored by Andreas Margetis and reviewed by Vaggelis Papoutsis, with earlier contributions from Dr. Ioannis Kavvadias.v2312Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/555overset modifications: allow overset pacthes overlap, allow fringe faces walk...2022-11-14T15:49:00ZSergio Ferrarisoverset modifications: allow overset pacthes overlap, allow fringe faces walk, mass conservation update### Summary
This merge addresses three main topics:
1) Allow overset patches displace outside the background domain.
2) Allow fringe faces away from the HOLE cells in the background domain
3) Some option to improve mass conservation in...### Summary
This merge addresses three main topics:
1) Allow overset patches displace outside the background domain.
2) Allow fringe faces away from the HOLE cells in the background domain
3) Some option to improve mass conservation in overset
1) overset patches can displace outside the domain. The problem of selecting the correct donors was addressed creating a new type of cell type named "POROUS". In these cells, DONORS can't be selected as they lay close to the end of the background domain. Any attempt to find a suitable donor proved to be unstable. Therefore these cells are not interpolated but let connected withing its mesh and solved locally. As these cells are normally close to wall without a proper BC applied , if left unweighted they lead to divergency, to avoid this a small damping effect is introduce using fvOption. Tests showed that damping U is robust enough to keep U-p stable.
Tutorials:
/tutorials/multiphase/overInterDyMFoam/twoSquaresOutDomain/
/tutorials/incompressible/overPimpleDyMFoam/rotatingSquare/
The fvOption is as:
limitU
{
type velocityDampingConstraint;
active true;
selectionMode cellType;
UMax 0;
C 1;
}
A constant C of '1' seems to be working generally. Of course , the solution on this cell is not accurate as an artificial porous cell is being introduced, on the other hand, cells next to wall will damp U anyway by shear stress.
NOTE: This feature was tested for inverseDistance, trackingInverseDistance, volumeWeight cell stencils. This approach does not support the overlapping of two inset meshes on top of the background mesh.
2) Allow fringe faces away from the HOLE cells in the background domain
In the overset approach is advantageous if the interpolated cells are far removed from areas were the flow experiences large gradients. Specially next to HOLES cells created by the inset mesh on the background mesh. Initially, the INTERPOLATED cells where located next to the
HOLES cells. This created a extra burden to the solver to solve for continuity which resulted in pressure peaks.
As a result we developed a way to make a 'walk' away from the HOLE cells into the bulk of the domain in order to interpolate smoother fields.
To use a different layers for the interpolated cells In the fvSchemes is specified:
oversetInterpolation
{
method inverseDistance;
searchBox (0 0 0)(0.1 0.1 0.1);
searchBoxDivisions (130 130 1);
holeLayers 4;
useLayer 2;
}
`holeLayers` specifies how many layer out of the HOLE cells will be walked. The code will report an average ratio of the volume on each mesh, ideally one. In the obove set up the walk will be done for 4 layers and layer 2 will be used.
Tutorial :
tutorials/incompressible/overPimpleDyMFoam/simpleRotor/
tutorials/multiphase/overInterDyMFoam/floatingBody/
tutorials/multiphase/overInterDyMFoam/rigidBodyHull/
The following is a typical improvement expected on residuals for p:
![pResNoLayers](/uploads/185098ed4e69c09aa6b78271076be9ff/pResNoLayers.png)
![pRes4Layers](/uploads/7f22e45f76cc5010463f8e781bef0606/pRes4Layers.png)
NOTE: This feature was tested for inverseDistance, trackingInverseDistance, volumeWeight cell stencils
This feature was not extensibly tested to work with 1) (overlapping patches). So, the walks to find the layers could need to be reviewed.
3) Some options to improve mass conservation in overset
The overset solvers were updated to make them more consistent. Experimental keyword were removed. i.e:
massFluxInterpolation
ddtCorr
correctPhi
The new option `oversetAdjustPhi` adds a flux correction outside the pressure Eq. This flag adjusts the flux in and out of the fringes faces in the inner loop of PIMPLE.
This feature is still experimental as the outcome of this approach is still under investigation.
It proved to work in some cases. The flag is specified in the fvSolution:
tutorials/multiphase/overInterDyMFoam/simpleRotor/
PIMPLE
{
momentumPredictor no;
nOuterCorrectors 1;
nCorrectors 3;
nNonOrthogonalCorrectors 0;
oversetAdjustPhi true;
}
the mass conservation with and without oversetAdjustPhi for the above tutorial case:
![NonOuterMassCorr](/uploads/635ecca36e8ce847314f9dda3ea6974b/NonOuterMassCorr.png)
![outerMassCorr](/uploads/3929f131a440f7f1e0403eec8665a9e4/outerMassCorr.png)
The other option for mass conservation is the implicit correction specified on the field patch as:
free
{
type overset;
massCorrection true;
value uniform 300;
}
The overset patch was made an lduInterface in order to have a hook inside the linear solver to add a sum(phi) = 0 on fringe faces. It is important to note that this restriction is added in a Amul function and in the linear solvers the actual variable being converged is to the field itself but a pre-condition variable, only the first residuals are calculated using p and its flux. Therefore, the application of this restriction have some theoretical gaps. Nonetheless, the flux balance on these faces out of the linear solver DO satisfy sum(phi) = 0.
See example for overLaplacian
tutorials/basic/overLaplacianDyMFoam/1DheatTransferMassConservation/
Switching oh/off the massCorrection flag results in a better flux across the overset patch.
This approach wasn't very successful when applied to overInterFoam cases and more study might be needed, even when the sum(phi) does go to zero, the overall conservation is not fully conserved.
NOTE: It was observed that using interpolated cells as donors is possible as far as the relative number is not too large. By default `allowInterpolatedDonors` is true. But under some circumstance the user might prefer not to use them.v2212Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/554BUG: setTurbulenceFields: update processor boundaries (fixes #2527)2022-07-04T15:26:56ZKutalmış BerçinBUG: setTurbulenceFields: update processor boundaries (fixes #2527)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/553ENH: oscillatingLinearMotion: add optional phase- and vertical-shift entries2022-07-04T15:27:59ZKutalmış BerçinENH: oscillatingLinearMotion: add optional phase- and vertical-shift entriesThe governing equation of `oscillatingLinearMotion` for the displacement was changed to with `Function1` input entries:
```math
y = A\, sin(B (t + C)) + D
```
where:
```
y | Displacement [m] (vector)
A | Ampl...The governing equation of `oscillatingLinearMotion` for the displacement was changed to with `Function1` input entries:
```math
y = A\, sin(B (t + C)) + D
```
where:
```
y | Displacement [m] (vector)
A | Amplitude [m] (vector)
B | Radial velocity [rad/s] (scalar)
C | Phase-shift to left [s] (scalar)
D | Vertical shift [m] (vector)
```
EP1925Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/552ENH: multiFieldValue: add divide and cmptDivide operations2022-07-01T12:55:33ZKutalmış BerçinENH: multiFieldValue: add divide and cmptDivide operationsAdds two new options into `multiFieldValue` FO:
divide | Divide first entry by values
cmptDivide | Divide first entry by componentwise values
EP1898Adds two new options into `multiFieldValue` FO:
divide | Divide first entry by values
cmptDivide | Divide first entry by componentwise values
EP1898Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/551Update of view factor generation using 2AI and 2LI methods plus CGAL for ray ...2022-08-12T08:53:39ZSergio FerrarisUpdate of view factor generation using 2AI and 2LI methods plus CGAL for ray tracing### Summary
This view factors generation application uses a combined approach of
double area integral (2AI) and double linear integral (2LI). 2AI is used
when the two surfaces are 'far' apart and 2LI when they are 'close'.
...### Summary
This view factors generation application uses a combined approach of
double area integral (2AI) and double linear integral (2LI). 2AI is used
when the two surfaces are 'far' apart and 2LI when they are 'close'.
The distance between faces is calculating a ratio between averaged areas and the distance between face
centres. 2LI is integrated along edges using Gaussian quadrature with a given tolerance.
This approach doesn't use face agglomeration as pre-processing step.
Optional new feature can be used to solve the system of equations from the s2s system using the
standard iterative linear solvers in OpenFOAM.
### Resolved bugs
The old method used 2AI and agglomeration for all the view fators. The 2AI is not accurate for faces which
are in close proximity. The agglomeration process proved to be problematic concerning the face centre and normal calculation.
### Details of new models
The extra inputs in the s2s dictionary are:
GaussQuadTol 0.1; // GaussQuad integral error tolerance (default : 0.01). Used to decide when to increase order of integration.
distTol 8; // relative distance (default : 8). For <distTol : use 2LI, >distTol : use 2AI
alpha 0.22; // Constant model use for common edges for 2LI (default : 0.22). Approx for integral value of duplicate edges.
intTol 1e-2; // (m) Interval tolerance. This is used for ray shooting from
// face centre to face centre plus `intTol` in order to avoid the ray to hit the same face where it was originated. (default : 1e-2)
The default values are generally reasonable for a wide range of cases.
The optional iterative linear solver is specified in the radiationProperty dictionary:
```
viewFactorCoeffs
{
smoothing false; // Use for closed surfaces where sum(Fij) = 1
constantEmissivity true;
nBands 1;
useDirectSolver false; // Use direct solver on master or fully parallel iterative solver
}
```
NOTE: In this development face agglomeration is not needed. The model will create an identity list if it is not present. Thus, it is not necessary for the user to run `faceAgglomerate`. But, the framework for using faceagglomeration was left inside the model as it can be needed in later stages.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/550s2s linear system solution using lduMatrix2022-06-15T12:26:28ZSergio Ferrariss2s linear system solution using lduMatrix s2s linear system solution using lduMatrix for qr s2s linear system solution using lduMatrix for qrv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/549support surface writer output transform (#2505)2022-06-13T11:37:19ZMark OLESENsupport surface writer output transform (#2505)- this allows the "relocation" of sampled surfaces. For example,
to reposition into a different coordinate system for importing
into CAD.
- incorporate output scaling for all surface writer types.
This was previously done on an a...- this allows the "relocation" of sampled surfaces. For example,
to reposition into a different coordinate system for importing
into CAD.
- incorporate output scaling for all surface writer types.
This was previously done on an adhoc basis for different writers,
but with now included in the base-level so that all writers
can automatically use scale + transform.
Example:
```
formatOptions
{
vtk
{
scale 1000; // m -> mm
transform
{
origin (0.05 0 0);
rotation axisAngle;
axis (0 0 1);
angle -45;
}
}
}
```
An example of transform in action. Used to reposition the output slices:
![transform-surfaceWrite](/uploads/69bf67dbc06c8622a008d84eed4dd8cc/transform-surfaceWrite.png)v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/548species and heat adsorption BC's and fvOption source2022-06-14T11:28:42ZSergio Ferrarisspecies and heat adsorption BC's and fvOption sourceImplementation of species and heat adsorption BC's.
Implementation of a fvOption source on cells attached to patchesImplementation of species and heat adsorption BC's.
Implementation of a fvOption source on cells attached to patchesv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/547ENH: DMD: add multi-patch input functionality2022-06-08T13:23:09ZKutalmış BerçinENH: DMD: add multi-patch input functionalityEP#1796, EP#1873
### Summary
This feature allows users to specify multiple patches in DMD calculations:
```
DMD1
{
// Optional entries
// Option-1
patch <word>;
// Option-2
patches ...EP#1796, EP#1873
### Summary
This feature allows users to specify multiple patches in DMD calculations:
```
DMD1
{
// Optional entries
// Option-1
patch <word>;
// Option-2
patches (<wordRes>);
}
```
The DMD snapshots concatenate each patch field, e.g. for velocity field:
`(u1 v1 w1 u2 v2 w2 u1_o v1_o w1_o u2_o v2_o w2_o)`
where "1" and "2" indicate different patches, "u v w" different components of a vector, and "o" the previous DMD step.
Also, the most expensive parts of the `STDMD` implementation were identified and reworked resulting in various reductions in calculation runtime.
For example, the timing of the standard "cylinder2D" tutorial (i.e. with all `STDMD` function objects are active), the duration of the parallel 12-processor simulation has been reduced from ~200secs to ~80secs during local tests, approximately a ~60% reduction.
Another test of DrivAer was reported to provide approximately 10x speedup.
### Tests
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/546ENH: new tabulated anisotropic solid transport model2022-06-08T12:59:50ZKutalmış BerçinENH: new tabulated anisotropic solid transport modelEP1878
#### Summary
This feature allows users to specify tabulated anisotropic thermal conductivity
properties for solid thermodynamics with an optional coordinate system specification.
The transport model is called `tabulatedAnIso`, ...EP1878
#### Summary
This feature allows users to specify tabulated anisotropic thermal conductivity
properties for solid thermodynamics with an optional coordinate system specification.
The transport model is called `tabulatedAnIso`, and as an example, the model
is specified in `thermophysicalProperties` file as follows:
```
thermoType
{
type heSolidThermo;
mixture pureMixture;
transport tabulatedAnIso;
thermo hTabulated;
equationOfState icoPolynomial;
specie specie;
energy sensibleEnthalpy;
}
mixture
{
specie
{
molWeight 50;
}
transport
{
kappa table
(
// T kappa
( 200 (80 80 80) )
( 400 (80 80 80) )
);
// kappa <Function1<scalar>>;
}
thermodynamics
{
Hf 0;
Cp
(
( 200 450)
( 400 450)
);
Sf 0;
}
equationOfState
{
rhoCoeffs<8> (8000 0 0 0 0 0 0 0);
}
}
coordinateSystem
{
type cylindrical;
origin (0 0 0);
rotation
{
type cylindrical;
axis (1 0 0);
}
}
```
#### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/545ENH: setTurbulenceFields: new automatic initialisation method for turbulence ...2022-06-14T13:22:18ZKutalmış BerçinENH: setTurbulenceFields: new automatic initialisation method for turbulence fields#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau** for providing the governing equations for `setTurbulenceFields`, elaborate suggestions and critical recommendations. Highly appreciated.
#### Aim...#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau** for providing the governing equations for `setTurbulenceFields`, elaborate suggestions and critical recommendations. Highly appreciated.
#### Aim
Implement and evaluate the two-step automatic initialization procedure for RANS computations introduced by Manceau (n.d.).
#### Methodology
- Plane channel flow at ReTau=180, 395, 590 (Moser et al., 1991) and =4179 (Lozano-Duran & Jimenez, 2014)
- NASA Turbulence Modelling Resource on various physics:
- 2DCC: 2D Convex curvature boundary layer
- 2DML: 2D Mixing layer
- 2DB: 2D Bump-in-channel
- 2DZP: 2D Zero pressure gradient flat plate
- 2DANW: 2D Airfoil near-wake
#### Results
**2DML: 2D Mixing layer**
<img src="/uploads/e00398017af9f013108c7ecb5dd288cb/Screenshot_from_2022-05-31_11-25-20.png" width="75%" height="75%">
<img src="/uploads/f1866890400631b1306f31713c981074/Screenshot_from_2022-05-31_11-25-30.png" width="75%" height="75%">
**Plane channel flow, ReTau=4179**
<img src="/uploads/f085f52634d45a085bd90d05da3be854/Screenshot_from_2022-05-31_11-31-54.png" width="75%" height="75%">
### Meta-data
EP#1805
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error
### Discussion
- The initialisation method may help to improve convergence in the first `O(10)` time steps, and fidelity of results.
- The initialisation method does not take input turbulence intensity and/or input viscosity ratios (mut/mu) into account.v2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/544ENH: EBRSM: new elliptic-blending Reynolds-stress turbulence model2022-06-08T10:41:01ZKutalmış BerçinENH: EBRSM: new elliptic-blending Reynolds-stress turbulence model#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau**, **Dr. Michael Karl Stoellinger**, and **Dr. Ardalan Javadi** for their contributions, elaborate suggestions and help, and critical recommendations....#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau**, **Dr. Michael Karl Stoellinger**, and **Dr. Ardalan Javadi** for their contributions, elaborate suggestions and help, and critical recommendations. Highly appreciated.
#### Aim
Implement and evaluate the elliptic-blending Reynolds-stress turbulence models proposed by [Manceau (2015) - Appendix C](https://doi.org/10.1016/j.ijheatfluidflow.2014.09.002).
#### Methodology
- Plane channel flow at ReTau=180, 395, 590 (Moser et al., 1991) and =4179 (Lozano-Duran & Jimenez, 2014)
- NASA Turbulence Modelling Resource on various physics:
- 2DCC: 2D Convex curvature boundary layer
- 2DML: 2D Mixing layer
- 2DB: 2D Bump-in-channel
- 2DZP: 2D Zero pressure gradient flat plate
- 2DANW: 2D Airfoil near-wake
#### Results
**Plane channel flow, ReTau=180**
<img src="/uploads/6c9899cad5929f65d869d3d63a90c55f/all_setups_yPlus_vs_uPlus.png" width="25%" height="25%">
<img src="/uploads/6520c01105e1aaa63434d67badf9b83e/all_setups_yPlus_vs_Ruu.png" width="25%" height="25%">
<img src="/uploads/1f99612fea236e501b1c117c43b3a694/all_setups_yPlus_vs_Rvv.png" width="25%" height="25%">
<img src="/uploads/439522e1fa9c3735e0cd244b1369e297/all_setups_yPlus_vs_Rww.png" width="25%" height="25%">
<img src="/uploads/52a8f9c9f28106cea6abe6ce7c33bad4/all_setups_yPlus_vs_Ruv.png" width="25%" height="25%">
<img src="/uploads/9b2f1e92fabff3104609ae03bbdd51fd/all_setups_yPlus_vs_epsilonPlus.png" width="25%" height="25%">
<img src="/uploads/c1d4cddd0b62a53bd317c655d3da9e48/all_setups_yPlus_vs_kPlus0.png" width="25%" height="25%">
<img src="/uploads/5056b4ce464c70c2c9d4b7c3037f1382/yPlus_vs_f.png" width="25%" height="25%">
**Plane channel flow, ReTau=4179**
<img src="/uploads/ad6eec1e96e581e4f617487a3fb092c3/all_setups_yPlus_vs_uPlus.png" width="25%" height="25%">
<img src="/uploads/3f5b20a7fe449a1964e8a937ddaafe50/all_setups_yPlus_vs_Ruu.png" width="25%" height="25%">
<img src="/uploads/2ffc52fe7918911d3cfcc8873bdf737b/all_setups_yPlus_vs_Rvv.png" width="25%" height="25%">
<img src="/uploads/8f9a7156be4fdf8e185535fff44ff845/all_setups_yPlus_vs_Rww.png" width="25%" height="25%">
<img src="/uploads/1cd605e4beb3c201fdce620b94e45559/all_setups_yPlus_vs_Ruv.png" width="25%" height="25%">
<img src="/uploads/8016b8dcc9a4ac15878e4351afb5107c/yPlus_vs_f.png" width="25%" height="25%">
**2DCC: 2D Convex curvature boundary layer**
<img src="/uploads/98cf3ae928d18f353728139aff7e90ac/all_setups_u_vs_y.png" width="25%" height="25%">
<img src="/uploads/362d12cc1f2386a13b493310bd4fe5b5/all_setups_Ruu_vs_y.png" width="25%" height="25%">
<img src="/uploads/1ed623a0b9a551169db65812d170f927/all_setups_Rvv_vs_y.png" width="25%" height="25%">
<img src="/uploads/c62dbb4686d4e4f4f190f8be87c4d7cf/all_setups_Ruv_vs_y.png" width="25%" height="25%">
<img src="/uploads/c1af0cb694fc137cd04273b464721fe4/x_vs_Cf_bottom.png" width="25%" height="25%">
<img src="/uploads/f2f1b39122d2c97dbf7d146cd30274b5/x_vs_Cp_bottom.png" width="25%" height="25%">
**2DML: 2D Mixing Layer**
<img src="/uploads/725943103926d796e672bbe984661fc6/all_setups_u_vs_y.png" width="25%" height="25%">
<img src="/uploads/25fb821f6490576c16e60d9e2c7c76ed/all_setups_Ruu_vs_y.png" width="25%" height="25%">
<img src="/uploads/8733ada0f7d73afbc7c0765dcbec5b52/all_setups_Rvv_vs_y.png" width="25%" height="25%">
<img src="/uploads/1cb31d6fda8b755f3d85accdaee2f876/all_setups_Rww_vs_y.png" width="25%" height="25%">
<img src="/uploads/a4cc5479508bb025d19c8c5d7539ab65/all_setups_Ruv_vs_y.png" width="25%" height="25%">
### Meta-data
EP#1805
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error
### Discussion
- In general, `EBRSM` yields better predictions for `R` and turbulence quantities in comparison to `kOmegaSST` model.
- But _not always_: For example, for `2DML: 2D Mixing Layer`, the `R` predictions of `EBRSM` is worse than those of `kOmegaSST`. The reason seems to be that the `EBRSM` could not reach the target convergence levels for this specific case.
- Predictions for `U` are similar.
- In general, less stable than `kOmegaSST`.
- For example, `2DZP: 2D Zero pressure gradient flat plate` and `2DANW: 2D Airfoil near-wake` cases are unstable.
- Initial values/initialisations seem to be important to
`EBRSM` in terms of numerical stability
and fidelity.
- The two-step automatic initialisation method proposed by (Manceau (n.d.)) should be preferred
over precursor simulations.
- Low-quality mesh cases are challenging,
especially meshes with high-aspect ratios
are prone to instabilities.
- Max relaxation factor for `R=0.4`. Avoid `R~O(0.05)` at all costs.
- Realizability conditions are not
automatically satisfied.
- Multiphase and compressible cases are
not explored by the academia.
### Future work
- Test scope should be extended further for:
- Multiphase-flow cases
- Compressible flow cases
- Dynamic-mesh cases
- Overset meshes
- Mesh (un)refinements
- Collated-data format
- Hybrid and single precisions
- New methods should be developed to stabilise `EBRSM` for low-quality meshes.v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/543Adding external heat to greyDiffusive BC and new Doses FO2022-05-27T09:15:36ZSergio FerrarisAdding external heat to greyDiffusive BC and new Doses FO### Summary
Adding Lagrangian dose function object. Additional external radiative heat flux to ray greyDiffusive BC for fvDOM
### Details of new models (If applicable)
qRadExt and qRadExtDir new optional entries to specified heat flu...### Summary
Adding Lagrangian dose function object. Additional external radiative heat flux to ray greyDiffusive BC for fvDOM
### Details of new models (If applicable)
qRadExt and qRadExtDir new optional entries to specified heat flux. This is added to the closest ray direction.
If qRadExtDir is not specified the heat flux is add normal to the face.
### Risks
Minimalv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/542General enhancement to icoReactingMultiphaseInterFoam solver, sub-models and ...2022-06-22T09:18:53ZSergio FerrarisGeneral enhancement to icoReactingMultiphaseInterFoam solver, sub-models and FO's1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models i...1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models in FO's. This new lib was added to all the thermal solvers
3) Adding new diffusion-based mass transfer model to icoReactingMultiphaseInterFoam
4) Improving consistency of Hf between phases (updated tutorials entries)
5) HeatFlux and htc FO's are available to use with icoReactingMultiphaseInterFoam
NOTE: There is memory leak problem at the end of the run when using icoReactingMultiphaseInterFoam and 'fieldFunctionObjects' is loaded usng lddOpen. NEED TO BE REVIEWEDv2206Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/541New function objects2022-05-25T23:18:21ZAndrew HeatherNew function objects## New function objects
### multiFieldValue
- Previously, the `multiFieldValue` function object was limited to operate on lists of `fieldValue` function objects.
- Any function objects that generate results can now be used, e.g.
```
p...## New function objects
### multiFieldValue
- Previously, the `multiFieldValue` function object was limited to operate on lists of `fieldValue` function objects.
- Any function objects that generate results can now be used, e.g.
```
pressureAverage
{
type multiFieldValue;
libs (fieldFunctionObjects);
operation average;
functions
{
inlet
{
type surfaceFieldValue;
operation areaAverage;
regionType patch;
name inlet;
fields (p);
writeFields no;
writeToFile no;
log no;
resultFields (areaAverage(inlet,p));
}
outlet
{
type surfaceFieldValue;
operation areaAverage;
regionType patch;
name outlet;
fields (p);
writeFields no;
writeToFile no;
log no;
}
average
{
type valueAverage;
functionObject testSample1;
fields (average(p));
writeToFile no;
log no;
}
}
}
```
Test case : [filter-multiFieldValue.tgz](/uploads/8a6ad51f582260e625ebbebe5313580f/filter-multiFieldValue.tgz) - see `system/pressureDifference` function object
### particleZoneInfo
Reports cloud information for particles passing through a specified cell zone.
Example usage:
```
cloudFunctions
{
particleZoneInfo1
{
type particleZoneInfo;
cellZone leftFluid;
// Optional entries
//writer vtk;
}
}
```
Results are written to file:
- `\<case\>/postProcessing/lagrangian/\<cloudName\>/\<functionName\>/\<time\>`
```
# cellZone : leftFluid
# time : 1.0000000000e+00
#
# origID origProc (x y z) time0 age d0 d mass0 mass
```
Where
- `origID` : particle ID
- `origProc` : processor ID
- `(x y z)` : Cartesian co-ordinates
- `time0` : time particle enters the `cellZone`
- `age` : time spent in the `cellZone`
- `d0` : diameter on entry to the `cellZone`
- `d` : current diameter
- `mass0` : mass on entry to the `cellZone`
- `mass` : current mass
If the optional `writer` entry is supplied, cloud data is written in the specified format.
During the run, output statistics are reported after the cloud solution, e.g.:
```
particleZoneInfo:
Cell zone = leftFluid
Contributions = 257
```
Here, `Contributions` refers to the number of incremental particle-move contributions recorded during this time step. At write times, the output is extended, e.g.:
```
particleZoneInfo:
Cell zone = leftFluid
Contributions = 822
Number of particles = 199
Written data to "postProcessing/lagrangian/reactingCloud1/
```
Test case: [filter-particleZoneInfo.tgz](/uploads/4872ea54688374b5a7e475015f3efe93/filter-particleZoneInfo.tgz) - see `constant/reactingCloud1Properties`v2206Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/540ENH: QRMatrix: refactor the QR decomposition algorithms2022-05-31T17:01:01ZKutalmış BerçinENH: QRMatrix: refactor the QR decomposition algorithms##### Summary
EP1874
##### Resolved bugs
#2212
##### Risks
API of QRMatrix has been changed.
##### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltest##### Summary
EP1874
##### Resolved bugs
#2212
##### Risks
API of QRMatrix has been changed.
##### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/539ENH: norm: add new field function object2022-05-27T11:58:44ZKutalmış BerçinENH: norm: add new field function objectEP1871
<img src="/uploads/3a948c9898bfea03397a550370578d30/image.png" width="50%" height="50%">
<img src="/uploads/656a0375d29062e3bed28a0b6d6bb78b/image.png" width="50%" height="50%">
<img src="/uploads/99411e71d94ea8e2f98e28e8412ca7...EP1871
<img src="/uploads/3a948c9898bfea03397a550370578d30/image.png" width="50%" height="50%">
<img src="/uploads/656a0375d29062e3bed28a0b6d6bb78b/image.png" width="50%" height="50%">
<img src="/uploads/99411e71d94ea8e2f98e28e8412ca720/image.png" width="50%" height="50%">
<img src="/uploads/27a831d096d9368dffdfd06da7bf301e/image.png" width="50%" height="50%">
<img src="/uploads/49e80a7e4480b71fafdf6b115e7ef837/image.png" width="50%" height="50%">
<img src="/uploads/a215b20f7b5af40c947277050e183c5c/image.png" width="50%" height="50%">
##### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/538redistributePar support for point fields and area fields2022-05-25T13:13:04ZMark OLESENredistributePar support for point fields and area fieldsv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/537New solid body motion mesh update optimisations2022-05-19T16:19:48ZAndrew HeatherNew solid body motion mesh update optimisations### Summary
New/refactored code to enable partial geometry updates for solid-body motion cases.
### Details of new models (If applicable)
Adds a new `solidBody` geometry scheme, applicable for e.g. rotating AMI/ACMI cases:
```
geomet...### Summary
New/refactored code to enable partial geometry updates for solid-body motion cases.
### Details of new models (If applicable)
Adds a new `solidBody` geometry scheme, applicable for e.g. rotating AMI/ACMI cases:
```
geometry
{
type solidBody;
// Optional
partialUpdate yes; // default = yes
cacheMotion yes; // default = yes
}
```
Instead of performing a complete mesh clear-out we selectively update only the geometry attached to moving points, under the assumption that there are no topological updates/the motion can be described as solid-body motion.
Performance improvements (time) are case specific, e.g. the smaller the fraction of moving cells compared to the total cell count, the larger the benefit for the mesh update phase.
The additional entries control:
- `partialUpdate` : if set to `false`, perform a complete mesh clear-out on mesh changes
- `cacheMotion` : if set to `true`, cache the addressing for the moving points, faces and cells across all time steps
**Backwards compatibility**
The `basic` option is the default and is applied if the `geometry` sub-dictionary is not supplied:
```
geometry
{
type basic;
}
```
Selecting this option should recover v2112 (and earlier versions) behaviour.
### Risks
- Refactored mesh updates
- mesh flux is now calculated by the `fvGeometryScheme`
- Added partial geometry updates
- see `primitiveMeshTools.H` functions `updateFaceCentresAndAreas` and `updateCellCentresAndVols`
- Need to test `snappyHexMesh` cases - the updates did not initially play nicely with the layer addition phase
### Testing
- Tests performed on:
- `pimpleFoam/RAS/propeller tutorial`
- `singleWheel` (internal)v2206Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com