openfoam merge requestshttps://develop.openfoam.com/Development/openfoam//merge_requests20190619T21:07:00Zhttps://develop.openfoam.com/Development/openfoam//merge_requests/269Integration adjoint20190619T21:07:00ZAdminIntegration adjoint## New adjoint optimisation and tools
A set of libraries and executables creating a workflow for performing
gradientbased 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
gradientbased 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 SpalartAllmaras
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 socalled sensitivity maps) following the
Enhanced Surface Integrals (ESI) formulation, [3].
The software was developed by PCOpt/NTUA and FOSS GP, with contributions from
 Dr. Evangelos PapoutsisKiachagias,
 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 SpalartAllmaras turbulence model for
incompressible flows. Computers & Fluids, 38(8):1528–1538, 2009.
[2] E.M. PapoutsisKiachagias 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. PapoutsisKiachagias, 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/235DigitalFilter Based Synthetic Turbulence Generation Method for LES/DES Inflow20190621T12:10:50ZKutalmış BerçinDigitalFilter Based Synthetic Turbulence Generation Method for LES/DES Inflow### Summary
Velocity boundary condition generating synthetic turbulencealike
timeseries for LES and DES turbulent flow computations.
To this end, two synthetic turbulence generators can be chosen:
...### Summary
Velocity boundary condition generating synthetic turbulencealike
timeseries for LES and DES turbulent flow computations.
To this end, two synthetic turbulence generators can be chosen:
 Digitalfilter methodbased generator (DFM)
\verbatim
Klein, M., Sadiki, A., and Janicka, J.
A digital filter based generation of inflow data for spatially
developing direct numerical or large eddy simulations,
Journal of Computational Physics (2003) 186(2):652665.
doi:10.1016/S00219991(03)000901
\endverbatim
 Forwardstepwise methodbased generator (FSM)
\verbatim
Xie, Z.T., and Castro, I.
Efficient generation of inflow conditions for large eddy simulation of
streetscale flows, Flow, Turbulence and Combustion (2008) 81(3):449470
doi:10.1007/s1049400891515
\endverbatim
In DFM or FSM, a random number set (mostly white noise), and a group
of target statistics (mostly mean flow, Reynolds stress tensor profiles and
lengthscale sets) are fused into a new number set (stochastic timeseries,
yet consisting of the statistics) by a chain of mathematical operations
whose characteristics are designated by the target statistics, so that the
realised statistics of the new sets could match the target.
Random number sets >

DFM or FSM > New stochastic timeseries consisting
 turbulence statistics
Turbulence statistics >
The main difference between DFM and FSM is that the latter replaces the
streamwise convolution summation in DFM by a simpler and a quantitatively
justified equivalent procedure in order to reduce computational costs.
Accordingly, the latter potentially brings resource advantages for
computations involving relatively large lengthscale sets and small
timesteps.
### Resolved bugs (If applicable)
Verified for `serial`, `scotchparallel (4)`, `hierar.parallel (1 2 2)`, `hierar.parallel (1 2 4)`, `serialrestart`, and `parallelrestart` in terms of input Reynolds stress tensor components through `channel395DFSEM` tutorial (onecell domain).
Checked for various possible (commonly encountered) wrong inputs, e.g. arbitrary Reynolds stress tensor components.
### Details of new models (If applicable)
**The model input**:
1. Spatialvariant Reynolds stress symmetric tensor (6components)
2. Spatialvariant mean velocity profile
3. Spatialinvariant (for now) integrallength scale tensor (9components)
**The model output**: Stochastic timeseries involving the statistics of the model input sets.
**The model computation has four subsequent steps:**
1. Generation of randomnumber sets obeying the standard normal probability distribution function
2. Analytical computation of digitalfilter coefficients as a function of integrallength scales in either Gaussian or exponential form
3. Convolution summation between randomnumber sets and digitalfilter coefficients
4. Embedment of Reynolds stress tensor and mean velocity input into the digitalfiltered randomnumber sets via elementwise multiplication and summation
**Fidelity**:
Preliminary statisticallystationary results from a channelheight profile on the patch (onecell domain `channel395DFSEM` case: `hierar.parallel (1 2 4)`):
![stress](/uploads/8dce71846496e6bbc87aca3c78c52bcb/stress.png)
Preliminary **notstatistically developed** (0.6 sec run, ongoing) with **nonoptimal input** results from full `channel395DFSEM` case:
![DG1](/uploads/49f04599abdd34ec9adec65166c8908f/DG1.png)
**Performance**:
Preliminary comparisons with DFSEM suggests that the current model is ~1.8x faster for the `channel395DFSEM` tutorial.
### Risks
1. Model is itself not divergencefree (yet convertible); therefore, should not be preferred for aeroacoustic applications as is. Nonetheless, the mass flow rate correction reduces the inlet pressure fluctuations to the level of Poletto et al.'s DFSEM (quantified and verified by Bercin in comparison to Moser et al'. DNS data for pressure fluctuations and correlations).
2. For now, Taylor's frozen turbulence hypothesis is applied in the streamwise direction.
3. For now, `bilinear interpolation` is not fully functional.
4. Code duplications with DFSEM exist for template funcs.
5. For now, integrallength scale set (9components) is spatialinvariant across patch.
6. Further verification is ongoing through highorder statistics from Moser et al.'s DNS data, e.g. correlations, kinetic energy budget, enstrophy and so on.AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/270Feature simplify fatal error20190717T19:34:00ZMark OLESENFeature simplify fatal errorUses the newly introduced `FatalErrorInLookup` and `FatalIOErrorInLookip` (issue #1362) for cleaner and more consistent handling of lookup errors (especially for the runTime selectable mechanism).Uses the newly introduced `FatalErrorInLookup` and `FatalIOErrorInLookip` (issue #1362) for cleaner and more consistent handling of lookup errors (especially for the runTime selectable mechanism).AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/273Feature cloud improvements20190806T13:32:03ZMark OLESENFeature cloud improvementsThe main impact of the changes are the addition of nParcels() as a baselevel virtual in cloud, which enables quick querying of any derived cloud without the hassle of attempting to cast the regIOobject into any particular `Cloud<Particl...The main impact of the changes are the addition of nParcels() as a baselevel virtual in cloud, which enables quick querying of any derived cloud without the hassle of attempting to cast the regIOobject into any particular `Cloud<ParticleType>` type. Similarly, the zeroinitialized constructors make it much easier to generate any particle type before filling out with more details and adding to a cloud.v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/272Feature mixed precision20190813T11:07:08ZMark OLESENFeature mixed precisionThis set of changes makes it easier to identify and manage binary reading from different representations. For example, a binary file written from an OpenFOAM installation with WM_SP, WM_LABEL_SIZE=32 can be read back as WM_DP and/or WM_L...This set of changes makes it easier to identify and manage binary reading from different representations. For example, a binary file written from an OpenFOAM installation with WM_SP, WM_LABEL_SIZE=32 can be read back as WM_DP and/or WM_LABEL_SIZE=64. This is managed internally by using the "arch" information that is included in the binary output files. For example,
```
FoamFile
{
version 2.0;
format binary;
class vectorField;
arch "LSB;label=32;scalar=64";
location "constant/polyMesh";
object points;
}
```
On reading, the size information is used to determine if the label/scalar sizes in the file correspond to the *native* version of the currently active OpenFOAM installation. If the values are identical, the binary file reading is as always. If, however, there is a discrepancy between the label/scalar sizes in the file and the current OpenFOAM sizes, the values will be read in the raw format and converted onthefly. This adds no additional memory overhead, but can potentially result in somewhat lower reading speeds. There are some additional operations when narrowing the representation (eg, reading in double but saving as float) to avoid underflow and overflow, but it cannot work magic. If your input file has 1e10 faces, the addressing will not fit into a signed or unsigned 32bit integer.
To manage the reading, the new trait structures `is_contiguous`, `is_contiguous_label`, `is_contiguous_scalar` are used. For data payloads that comprise homogenous base types (ie, the lowest level component is entirely scalar or label) the Detail::readContiguous is used for managing the reading in a uniform manner. For heterogeneous data types, the author of the class must address this individually. This is typically in the following form:
```
if (is.format() == IOstream::ASCII)
{
is >> start_ >> end_ >> level_ >> i_ >> j_ >> k_;
}
else if (!is.checkLabelSize<>()  !is.checkScalarSize<>())
{
// Nonnative label or scalar size
is.beginRawRead();
readRawScalar(is, start_.data(), vector::nComponents);
readRawScalar(is, end_.data(), vector::nComponents);
readRawLabel(is, &level_);
readRawLabel(is, &i_);
readRawLabel(is, &j_);
readRawLabel(is, &k_);
is.endRawRead();
}
else
{
is.read
(
reinterpret_cast<char*>(&start_),
sizeofFields_
);
}
```
### Limitation
Changes in the endian type are not handled.v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/274BUG: add a warning in star4ToFoam for .cel files containing only shell entries (#1425)20190905T08:21:19ZKutalmış BerçinBUG: add a warning in star4ToFoam for .cel files containing only shell entries (#1425)AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/277add stringOps::toScalar and '#eval' dictionary directive20190930T19:54:46ZMark OLESENadd stringOps::toScalar and '#eval' dictionary directiveThe #eval directive is similar to the #calc directive, but for evaluating string expressions into scalar values using an internal parser for the evaluationThe #eval directive is similar to the #calc directive, but for evaluating string expressions into scalar values using an internal parser for the evaluationAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/278Integration of OpenFOAM.org  Wall functions20191003T10:34:11ZKutalmış BerçinIntegration of OpenFOAM.org  Wall functionsAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/279TUT: add Allclean script into bump2D20191003T11:00:07ZKutalmış BerçinTUT: add Allclean script into bump2DAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/280improvements to stringOps::expand operations20191008T12:38:29ZMark OLESENimprovements to stringOps::expand operations added numerical evaluation in string expansion
 refactored expansion code to use common multiparameter backend added numerical evaluation in string expansion
 refactored expansion code to use common multiparameter backendAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/284Issue 1454 post process20191017T12:26:30ZAdminIssue 1454 post processUpdated `postProcess` for mesh changes to update the function objects instead of performing a full clearoutUpdated `postProcess` for mesh changes to update the function objects instead of performing a full clearoutv1912AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/245ENH: FO: Lamb vector and its divergence20191108T07:11:42ZKutalmış BerçinENH: FO: Lamb vector and its divergence If applied:
This commit allows the user to compute:
 the Lamb vector (https://en.wikipedia.org/wiki/Lamb_vector),
 (optionally) its divergence
 onthefly or via postProcess utility
 for a... If applied:
This commit allows the user to compute:
 the Lamb vector (https://en.wikipedia.org/wiki/Lamb_vector),
 (optionally) its divergence
 onthefly or via postProcess utility
 for a given volVectorField (one per functionObject entry)
 Why:
The motivation is the literaturereported quantitative connection
between the Lamb vector (divergence) and the spatially localised
instantaneous fluid motions, e.g. high and lowmomentum fluid
parcels, which possess considerable level of capacity to affect
the rate of change of momentum, and to generate forces such as drag.
 Verification:
 Smoothwall plane channel flow case (Moser et al. 1999) by
 Curtis et al. (2008) On the Lamb vector divergence
in Navier–Stokes flows, doi:10.1017/S0022112008002760
 What's next:
 The verificationshow case
 Extended code guide entry titled "Lamb vector"
 Related:
 "fvc::curl(U)^U" is computed twice when "divergence_" is on.
It will be reduced one.AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/291ENH: interpolationTable improvements20191108T15:45:19ZMark OLESENENH: interpolationTable improvements reduce code duplication, support returning multiple interpolations
as a Field reduce code duplication, support returning multiple interpolations
as a FieldAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/292bug1108turbulentDFSEMInlet20191113T12:55:48ZKutalmış Berçinbug1108turbulentDFSEMInletAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/295bug1459turbulentInflow20191114T14:35:14ZKutalmış Berçinbug1459turbulentInflowpassed regression tests except inletCell sampling where I have changed the sampling method from face to midPoint to enable sampling from the cell centres thereat.passed regression tests except inletCell sampling where I have changed the sampling method from face to midPoint to enable sampling from the cell centres thereat.AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/298Feature zipfields20191118T09:35:31ZMark OLESENFeature zipfieldsAdds _"zip" fields_ function for combining component fields together and _"unzip" fields_ function for splitting a field into its component parts.Adds _"zip" fields_ function for combining component fields together and _"unzip" fields_ function for splitting a field into its component parts.v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/297BUG: adjointSolverName not set correctly in adjointWallVelocityLowRe (fixes #1502)20191119T11:08:58ZVaggelis PapoutsisBUG: adjointSolverName not set correctly in adjointWallVelocityLowRe (fixes #1502)v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/296BUG: RASModelVariables::SpalartAllmaras cannot be combined with an...20191119T11:09:23ZVaggelis PapoutsisBUG: RASModelVariables::SpalartAllmaras cannot be combined with an...BUG: RASModelVariables::SpalartAllmaras cannot be combined with an fvMotionSolver diffusivity which depends on wall distances (fixes #1501)BUG: RASModelVariables::SpalartAllmaras cannot be combined with an fvMotionSolver diffusivity which depends on wall distances (fixes #1501)v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/293Feature single precision solve type20191119T11:10:08ZMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comFeature single precision solve typeAdds functionality to SPDP mode:
 all (field) summations done in double precision (end result still single precision)
 mesh face areas, face centres, cell volumes and cell centres calculated in double precision (but still stored in sin...Adds functionality to SPDP mode:
 all (field) summations done in double precision (end result still single precision)
 mesh face areas, face centres, cell volumes and cell centres calculated in double precision (but still stored in single precision)
 some mesh checks done in double precisionAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/300Feature expressions20191210T12:10:28ZMark OLESENFeature expressions### Summary
This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([SwissArmyKnife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely ...### Summary
This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([SwissArmyKnife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely the ability to use textbased expressions instead of coding in C++ for the following cases:
 expressionbased boundary conditions (also known as _groovy_ boundary conditions)
 expressionbased setFields (also known as _funky_ set fields)
The idea of what we currently term *expressions* was pioneered by
(Bernhard Gschaider) and is now firmly established in `swak4Foam`.
Among other things, expressions attempt to bridge the gap between
using standard, predefined boundary conditions and writing dedicated,
specialpurpose ones. Although part of this gap is now covered within
OpenFOAM by using dynamically compiled user coding (eg, coded boundary
conditions), there remains substantial areas where it can be
significantly more convenient to have a series of predefined functions
and expression sytax with some access to base OpenFOAM field
functionality that enables rapid deployment of boundary conditions, or
customdefined `setFields` without writing code.
A significant portion of `swak4Foam` expressions has been adapted for
direct integration into OpenFOAM. During the integration and rewrite,
we have tried to pare things down to a smaller subset with the aim of
covering 90% or more of the common cases. The remaining cases are left
to be reassessed for extending the *expressions* functionality in the
future, but they also may be better served with other approaches (eg,
with coded conditions) that were not available when `swak4Foam` was
originally conceived.
To the greatest extent possible, the integrated *expressions* have
been designed to avoid name clashes with `swak` so it should remain
possible to use the most recent versions of `swak` without problem.
### Risks
 New functionality, so low chance of regression.
 The scope of the functionality will be revised in the future
### Naming (for `swak4Foam` users)
The following are the *expressions* correspondences to `swak`:
 The `exprFixedValue` and `exprGradient` boundary conditions are
roughly equivalent to the _groovy_ boundary conditions.
 The utilities `setExprFields` and `setExprBoundaryFields` are
roughly equivalent to the _funky_ utilities of similar name.
The naming of the boundary conditions and utilities not only reflects
the slightly different input requirements, but simultaneously seeks to
avoid any potential nameclash with `swak4Foam` in a mixed
environment.
The names for the boundary condition dictionary entries tend be
shorter and slightly different (eg, `valueExpr` vs `valueExpression`)
to serve as a small reminder that the *expressions* syntax is slightly
different than the *groovy* equivalents. It also allows the user to
fashion dictionary entries that are sufficient for **both** boundary
condition variants and quickly toggle between them simply by changing
the boundary condition `type`.v1912Andrew HeatherAndrew Heather