openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2019-12-13T20:04:27Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/303ENH: Added new function object to compute the Proudman acoustic power2019-12-13T20:04:27ZAndrew HeatherENH: Added new function object to compute the Proudman acoustic power@Roger @Prashant - can you confirm this OK to go in? and any test case/updated tutorial that can be provided?
---
# Details of the new function object:
Calculates the acoustic power due to the volume of isotropic turbulence
usi...@Roger @Prashant - can you confirm this OK to go in? and any test case/updated tutorial that can be provided?
---
# Details of the new function object:
Calculates the acoustic power due to the volume of isotropic turbulence
using Proudman's formula
The acoustic power P_A [W/m3] in terms of turbulence k and \epsilon is given as:
P_A = alpha_\epsilon \rho \epsilon M_t^5
where alpha_\epsilon is a constant (0.1) and
M_t = \frac{\sqrt{2 k}}{a_0}
with a_0 the speed of sound. The acoustic power is also output in
dB using:
L_P = 10 \log \frac{P_A}{P_ref}
where P_ref 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.v1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/302ENH: Added new scaledFixedValue boundary condition2019-12-11T10:45:32ZAndrew HeatherENH: Added new scaledFixedValue boundary conditionAdds new `scaledFixedValue` boundary condition
This condition applies a scalar multiplier to the value of another
boundary condition.
Usage
Property | Description | Required | Default value
scale ...Adds new `scaledFixedValue` boundary condition
This condition applies a scalar multiplier to the value of another
boundary condition.
Usage
Property | Description | Required | Default value
scale | Time varing scale | yes |
patch | patchField providing the raw patch value | yes |
Example of the boundary condition specification to scale a reference
velocity of (15 0 0) supplied as a fixedValue by a table of values
that ramps the scale from 0 to 1 over 1 second:
```
<patchName>
{
type scaledFixedValue;
scale table
(
( 0 0)
( 1.0 1.0)
(100.0 1.0)
);
patch
{
type fixedValue;
value uniform (15 0 0);
}
}
```v1912Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/301Feature particle patch postpro filtering2019-12-10T15:53:15ZAndrew HeatherFeature 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 mode...### 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 riskv1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/300Feature expressions2019-12-10T12:10:28ZMark OLESENFeature 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 ...### 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`.v1912Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/265ENH: add PDRsetFields utility2019-12-17T10:07:43ZMark OLESENENH: add PDRsetFields utility- the PDRsetFields utility processes a set of geometrical obstructions
to determine the equivalent blockage effects.
These fields are necessary inputs for PDRFoam calculations.
![simple-cage](/uploads/6782621d04c86e360314258cc...- the PDRsetFields utility processes a set of geometrical obstructions
to determine the equivalent blockage effects.
These fields are necessary inputs for PDRFoam calculations.
![simple-cage](/uploads/6782621d04c86e360314258cc96f3bc0/simple-cage.png)v1912Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/284Issue 1454 post process2019-10-17T12:26:30ZAdminIssue 1454 post processUpdated `postProcess` for mesh changes to update the function objects instead of performing a full clear-outUpdated `postProcess` for mesh changes to update the function objects instead of performing a full clear-outv1912AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/272Feature mixed precision2019-08-13T11: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 on-the-fly. 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 32-bit 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<>())
{
// Non-native 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/298Feature zipfields2019-11-18T09: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/273Feature cloud improvements2019-08-06T13:32:03ZMark OLESENFeature cloud improvementsThe main impact of the changes are the addition of nParcels() as a base-level 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 base-level 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 zero-initialized 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/296BUG: RASModelVariables::SpalartAllmaras cannot be combined with an...2019-11-19T11: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/297BUG: adjointSolverName not set correctly in adjointWallVelocityLowRe (fixes #...2019-11-19T11:08:58ZVaggelis PapoutsisBUG: adjointSolverName not set correctly in adjointWallVelocityLowRe (fixes #1502)v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/242Reacting heterogeneous cloud2019-05-02T18:40:27ZSergio FerrarisReacting heterogeneous cloud### Summary
New reacting heterogeneous cloud, solver and tutorial.
This cloud is formed of pure solid particles which reacts with the carrier phase.
It is derived from reacting cloud.
### Resolved bugs (If applicable)
(Links to issues...### Summary
New reacting heterogeneous cloud, solver and tutorial.
This cloud is formed of pure solid particles which reacts with the carrier phase.
It is derived from reacting cloud.
### Resolved bugs (If applicable)
(Links to issues)
### Details of new models (If applicable)
The only available reacting heterogeneous model is Heteregeneous noncatalytic reaction MUCS approach.
Reference:
D. Papanastassiou and G. Bitsianes, Modelling of Heterogeneous Gas-
Solid Reactions, Metallurgical Transsactions, 480. Volume 4. 1973
### Risks
(Possible regressions?)
(Changes to user inputs?)v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/228Feature run time control triggers2019-01-24T05:50:29ZAdminFeature run time control triggersExtends the `runTimeControl` function object to set 'trigger' values, that can be used to start other function objects. For example, to run for 100 steps after the average drag coefficient converges (reported by a `forceCoeffs` function...Extends the `runTimeControl` function object to set 'trigger' values, that can be used to start other function objects. For example, to run for 100 steps after the average drag coefficient converges (reported by a `forceCoeffs` function object) the following could be used:
```
runTimeControl1
{
type runTimeControl;
libs ("libutilityFunctionObjects.so");
conditions
{
condition1
{
type average;
functionObject forceCoeffs1;
fields (Cd);
tolerance 1e-3;
window 20;
windowType exact;
}
}
satisfiedAction setTrigger;
trigger 1;
}
runTimeControl2
{
type runTimeControl;
libs ("libutilityFunctionObjects.so");
controlMode trigger;
triggerStart 1;
conditions
{
condition1
{
type maxDuration;
duration 100;
}
}
satisfiedAction end;
}
```
See the `$FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar tutorial`v1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/257Introduced changes required to make isoAdvector and interIsoFoam work with...2019-06-13T20:48:01ZJohan RoenbyIntroduced changes required to make isoAdvector and interIsoFoam work with...Introduced changes required to make isoAdvector and interIsoFoam work with morphing meshes: 1) In the alphaEqn.H U is made relative to mesh motion before the interface advection step, 2) in isoAdvection::advect() alpha must be multiplied...Introduced changes required to make isoAdvector and interIsoFoam work with morphing meshes: 1) In the alphaEqn.H U is made relative to mesh motion before the interface advection step, 2) in isoAdvection::advect() alpha must be multiplied by Vsc0()/Vsc(). Implementation tested and verified with 1) a spherical interface in a cubic domain with no flow, where the domain walls are squeezed together and 2) a spherical interfacee inside the sloshingCylinder, again with no flow, so the sphere should stay spherical, which it does.v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/246ENH: functionObject: refactored co-ordinate system usage and new forceCoeffs ...2019-06-13T14:47:10ZKutalmış BerçinENH: functionObject: refactored co-ordinate system usage and new forceCoeffs members* If applied: This commit on top of the current forceCoeffs allows the user to compute:
* Side force coefficient whose direction in curl(lift,drag),
* Yaw moment coefficient whose rotation axis in dir(lift),
* Roll moment coef...* If applied: This commit on top of the current forceCoeffs allows the user to compute:
* Side force coefficient whose direction in curl(lift,drag),
* Yaw moment coefficient whose rotation axis in dir(lift),
* Roll moment coefficient whose rotation axis in dir(drag)
* Also, for developers:
* Destructor is = default
* Some divisions were replaced by multiplications
* Some repetitive multiplications were reduced to a single oper
* Name change: momentCoeff -> pitchMomentCoeff
* Order of output is reorganised as moments(pitch,yaw,roll) and forces(lift,drag,side)
* For force coefs, the front and rear axles' contributions are computed
* Verification: Passed sanity checks and valgrind-memcheck
* What's next:
* Update for the Extended code guide entry
* Related:
* Designated pitch, yaw, roll orientation can be seen in:
en.wikipedia.org/wiki/Yaw_(rotation)#/media/File:Flight_dynamics_with_text.pngv1906AdminAdminhttps://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/243Feature reflective solar load2019-05-02T09:45:46ZSergio FerrarisFeature reflective solar load### Summary
Adding reflecting fluxes to Solar load radiation model.
Adding functionality to the boundary radiation models and new
place holder for basic wall types such as transparent, opaqueDiffusive,
opaqueReflective. Radiation wall ...### Summary
Adding reflecting fluxes to Solar load radiation model.
Adding functionality to the boundary radiation models and new
place holder for basic wall types such as transparent, opaqueDiffusive,
opaqueReflective. Radiation wall models are now runtime selectable.
Adding multi-band capabilities to VF model and improving the set up
for using solar loads in VF and fvDOM radiation models.
### Details of new models (If applicable)
The new entry is useReflectedRays = true in the radiationProperties.
This calculates the reflected rays on reflective walls. It can handle first reflection
on surfaces. Not multiple reflection are considered.
The wall boundary type "opaqueReflective" handles specular reflection which a proportion
of diffusive heat flux
### Risks
(Possible regressions?)
The boundaryRadiationProperties entries key words are "type", not "mode". But a backward
compatibility reading was introduced.v1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/236Feature postpro2019-02-20T19:43:43ZMark OLESENFeature postpro### Summary
Extension of insitu visualization (runTimePostProcessing):
- parallel rendering
- direct use of VTK cutting plane and iso-surface filters
- *live* access to simulation data such as lagrangian clouds and geometry patches...### Summary
Extension of insitu visualization (runTimePostProcessing):
- parallel rendering
- direct use of VTK cutting plane and iso-surface filters
- *live* access to simulation data such as lagrangian clouds and geometry patches
- the ability to use stored surfaces and fields originating from another function object (eg, sampledSurfaces)
Significant cleanup and reimplementation of the surface sampling function object and all the surface writers to allow per-surface format specification. Added support for `.vtp` output of sampled surface with multiple fields in a single file.
Stored surface information can now be used for other field calculations (eg, `surfaceFieldValue`)
Images and description of the new functionality are attached to issue #1206v1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/266Feature vof update solvers2019-06-07T08:38:37ZSergio FerrarisFeature vof update solversNew chtMultiRegionTwoPhaseEulerFoam solver, plus corresponding BC's. Integrated MULES and CMULES new interfaces and the corresponding multiphase solvers and tutorials. All multiphase Euler tutorials are updated.
Inter type of tutorials h...New chtMultiRegionTwoPhaseEulerFoam solver, plus corresponding BC's. Integrated MULES and CMULES new interfaces and the corresponding multiphase solvers and tutorials. All multiphase Euler tutorials are updated.
Inter type of tutorials have been tested (to confirm the correct modification of new MULESinterfaces)
New library src/phaseSystemModels for the phases systems, sub-models, BC's, turbulence of the solver twoPhaseReactingEulerFoam and multiphaseReactingEulerFoam. This lib was taken out of the Euler solvers and located on /srcv1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/231Function object updates2019-01-31T17:00:02ZAdminFunction object updatesRenamed the `residuals` function object to `solverInfo` since it now generates:
* residual fields
* solver type
* initial residual
* final residual
* number of solver iterations
* convergecnce flag
Added new `continuityError` function ...Renamed the `residuals` function object to `solverInfo` since it now generates:
* residual fields
* solver type
* initial residual
* final residual
* number of solver iterations
* convergecnce flag
Added new `continuityError` function object. Example usage:
continuityError1
{
type continuityError;
libs ("libfieldFunctionObjects.so");
...
writeToFile yes;
log yes;
phi phi;
}
\endverbatimv1906AdminAdmin