- synchronize the scalar interval value with the integer version.
This ensures that the interval() method returns the correct
representative value.
- added clear() method to reset to 'always' (pass-through)
- ensure that the updateControl is "non-sticky" on re-read,
even if we do not support runtime-modifiable here
STYLE: add syntax example (wingMotion), but with updateInterval 1
The adjoint library is enhanced with new functionality enabling
automated shape optimisation loops. A parameterisation scheme based on
volumetric B-Splines is introduced, the control points of which act as
the design variables in the optimisation loop [1, 2]. The control
points of the volumetric B-Splines boxes can be defined in either
Cartesian or cylindrical coordinates.
The entire loop (solution of the flow and adjoint equations, computation
of sensitivity derivatives, update of the design variables and mesh) is
run within adjointOptimisationFoam. A number of methods to update the
design variables are implemented, including popular Quasi-Newton methods
like BFGS and methods capable of handling constraints like loop using
the SQP or constraint projection.
The software was developed by PCOpt/NTUA and FOSS GP, with contributions from
Dr. Evangelos Papoutsis-Kiachagias,
Konstantinos Gkaragounis,
Professor Kyriakos Giannakoglou,
Andy Heather
[1] E.M. Papoutsis-Kiachagias, N. Magoulas, J. Mueller, C. Othmer,
K.C. Giannakoglou: 'Noise Reduction in Car Aerodynamics using a
Surrogate Objective Function and the Continuous Adjoint Method with
Wall Functions', Computers & Fluids, 122:223-232, 2015
[2] E. M. Papoutsis-Kiachagias, V. G. Asouti, K. C. Giannakoglou,
K. Gkagkas, S. Shimokawa, E. Itakura: ‘Multi-point aerodynamic shape
optimization of cars based on continuous adjoint’, Structural and
Multidisciplinary Optimization, 59(2):675–694, 2019
- when using VTK from ParaView sources it can better to tag them as
such, but simultaneously not mask the ParaView with hardware
rendering.
The additional ParaView_MESA_DIR variable allows this.
The balance of library and path setup is unaffected by this.
DOC: update doc/BuildIssues
- `Pkt` was directed to `GName` to allow wall functions
are usable by kkLOmega model
- `Pkt` was changed to a non-const object, so that omegaWallFunc
can modify `Pkt` at the wall, if need be.
- Elementwise backward compatibility was checked by
pimpleFoam/RAS/ellipsekkLOmega
- New implementation was checked by changing omega:hole boundary
in pimpleFoam/RAS/ellipsekkLOmega to omegaWallFunction
QRMatrix (i.e. QR decomposition, QR factorisation or orthogonal-triangular
decomposition) decomposes a scalar/complex matrix \c A into the following
matrix product:
\verbatim
A = Q*R,
\endverbatim
where
\c Q is a unitary similarity matrix,
\c R is an upper triangular matrix.
Usage
Input types:
- \c A can be a \c SquareMatrix<Type> or \c RectangularMatrix<Type>
Output types:
- \c Q is always of the type of the matrix \c A
- \c R is always of the type of the matrix \c A
Options for the output forms of \c QRMatrix (for an (m-by-n) input matrix
\c A with k = min(m, n)):
- outputTypes::FULL_R: computes only \c R (m-by-n)
- outputTypes::FULL_QR: computes both \c R and \c Q (m-by-m)
- outputTypes::REDUCED_R: computes only reduced \c R (k-by-n)
Options where to store \c R:
- storeMethods::IN_PLACE: replaces input matrix content with \c R
- storeMethods::OUT_OF_PLACE: creates new object of \c R
Options for the computation of column pivoting:
- colPivoting::FALSE: switches off column pivoting
- colPivoting::TRUE: switches on column pivoting
Direct solution of linear systems A x = b is possible by solve() alongside
the following limitations:
- \c A = a scalar square matrix
- output type = outputTypes::FULL_QR
- store method = storeMethods::IN_PLACE
Notes
- QR decomposition is not unique if \c R is not positive diagonal \c R.
- The option combination:
- outputTypes::REDUCED_R
- storeMethods::IN_PLACE
will not modify the rows of input matrix \c A after its nth row.
- Both FULL_R and REDUCED_R QR decompositions execute the same number of
operations. Yet REDUCED_R QR decomposition returns only the first n rows
of \c R if m > n for an input m-by-n matrix \c A.
- For m <= n, FULL_R and REDUCED_R will produce the same matrices
- handle zero or negative values as being identical to 1.
As per timeStep control and what the comments suggested.
- drop old outputTime enumeration, since this is covered by the
writeTime enumeration and a corresponding Enum name.
- support construction of a "pass-through" control object that always
executes and add some method to test for these conditions and be able
to output some meaning full information.
Eg,
if (ctrl.execute())
{
if (!ctrl.always())
{
Info<< "Sampling executed based on " << ctrl.type() << nl;
}
...
}
To produce "Sampling executed based on runTime"
Calculates the acoustic power due to the volume of isotropic turbulence
using Proudman's formula
The acoustic power \f$ P_A \f$ [W/m3] in terms of turbulence \f$ k \f$
and \f$ \epsilon \f$ is given as:
\f[
P_A = alpha_\epsilon \rho \epsilon M_t^5
\f]
where \f$ alpha_\epsilon \f$ is a constant (0.1) and
\f[
M_t = \frac{\sqrt{2 k}}{a_0}
\f]
with \f$ a_0 \f$ the speed of sound. The acoustic power is also output in
dB using:
\f[
L_P = 10 \log \frac{P_A}{P_ref}
\f]
where \f$ P_ref \f$ is a constant (1e-12 W/m3)
Usage
Example of function object specification to calculate the Proudman acoustic
power
proudmanAcousticPower1
{
type proudmanAcousticPower;
libs ("libfieldFunctionObjects.so");
...
// Required additional entries for incompressible calculations
rhoInf 1.225;
aRef 340;
}
Where the entries comprise:
Property | Description | Required | Default value
type | type name: proudmanAcousticPower | yes |
rhoInf | Freestream density for incompressible cases | no |
aRef | Reference spped of sound for incompressible cases | no |
alphaEps | Model coefficient | no | 0.1
Note
- The freestream density and reference speed of sound are only necessary
when a thermodynamics package is unavailable, typically for incompressible
cases.
- Allows user-defined control of when the mesh motion occurs,
which can be especially useful in situations where the mesh motion
is much slower than any of the fluid physics.
For example, in constant/dynamicMeshDict:
updateControl runTime;
updateInterval 0.5;
to have mesh motion triggered every 1/2 second.
Note that the _exact_ time that the mesh motion actually occurs may
be slightly differently since the "runTime" triggering is fuzzy in
nature. It will trigger when the threshold has been crossed, which
will depend on the current time-step size.
- The -Wno-deprecated-copy flag for gcc-9.2.0
In the future we may indeed wish to explicitly request default
generated constructors and assignment operators, but at the moment
these are still acceptable.
- The -Wno-alloc-size-larger-than flag for mingw compilations
Related to differences in PTRDIFF_MAX vs SIZE_MAX on the target.
Several issues related to this can be found in the gcc bug reports
and on stackoverflow etc.
COMP: delay evaluation of fieldToken enumeration types
- lazy evaluation at runTime instead of compile-time to make the code
independent of initialization order.
Otherwise triggers problems on gcc-4.8.5 on some systems where
glibc is the same age, or older.
Feature particle patch postpro filtering
### Summary
Adds options to write particle-patch interactions to file, and to select particle fields to post-process for the `patchPostProcessing` cloud function object
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
Cloud patch interaction models:
Optionally write patch interaction statistics, e.g. number and mass of particles that stick, escape etc. to file using the optional `writeToFile` entry, e.g.
```
localInteractionCoeffs
{
patches
(
"(walls|cyc.*)"
{
type rebound;
}
"inlet|outlet"
{
type escape;
}
);
// New optional entry
writeToFile yes;
}
```
Cloud function objects:
New `fields` optional entry can be used to select which particle fields to post-process; if empty or the entry is not given all fields are written (to provide backwards compatibility)
```
patchPostProcessing1
{
type patchPostProcessing;
// Optional new entry
fields (position "U.*" d T nParticle);
maxStoredParcels 20;
patches
(
cycLeft_half0
cycLeft_half1
);
}
```
See the `$FOAM_TUTORIALS/lagrangian/reactingParcelFilm/filter` tutorial for an example
### Risks
Low risk
See merge request Development/openfoam!301
Feature expressions
### Summary
This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([Swiss-Army-Knife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely the ability to use text-based expressions instead of coding in C++ for the following cases:
- expression-based boundary conditions (also known as _groovy_ boundary conditions)
- expression-based 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,
special-purpose 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
custom-defined `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 name-clash 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`.
See merge request Development/openfoam!300
Limits fields to user-specified min and max bounds
Usage
Example of function object specification:
limitFields1
{
type limitFields;
libs ("libfieldFunctionObjects.so");
...
fields (U);
limit max;
max 100;
}
Where the entries comprise:
Property | Description | Required | Default
type | type name: limitFields | yes |
fields | list of fields to process | yes |
limit | bound to limit - see below | yes |
min | min limit value | partly |
max | max limit value | partly |
The "limit" entry can take the value:
- min : specify a minimum value
- max : specify a maximum value
- both : specify a minimum value and a maximum value
The optional 'fields' entry can be used to limit which particle fields are
written to file. If empty/not specified, all properties are written to
maintain backwards compatibility.
patchPostProcessing1
{
type patchPostProcessing;
maxStoredParcels 20;
fields (position "U.*" d T nParticle);
patches
(
cycLeft_half0
cycLeft_half1
);
}
- replace stringOps::toScalar with a more generic stringOps::evaluate
method that handles scalars, vectors etc.
- improve #eval to handle various mathematical operations.
Previously only handled scalars. Now produce vectors, tensors etc
for the entries. These tokens are streamed directly into the entry.
